#ubuntu-devel 2005-09-12
<elmo> robitaille: err?
<jbailey> elmo: Can you pls. sync bzr from Debian unstable?
<elmo> [BLACKLISTED - LOOP BACK]  Daniel Robitaille: <robitaille@ubuntu.com> --> robitaille@ubuntu.com. [276] 
<elmo> robitaille: ^--
<dmk> good night all
<robitaille> elmo,  I switched my prefered LP to my ubuntu address.... I guess your cron job didn't like it.  I'll switch it back to something else
<elmo> robitaille: well, it's a forwarding service - it'll forward it to whatever your prefered email is?
<elmo> robitaille: or did you not want an ubuntu.com email?
<siretart> elmo: btw, do members get automatically @ubuntu.com emails or is there manual interaction involved?
<elmo> siretart: it's an automated cron job
<elmo> well, that's not quite true
<elmo> semi-automated
<siretart> running how ofen?
<siretart> ah.. I see
<elmo> not sure yet, probably hourly or so
<robitaille> elmo I wanted people to see my ubuntu address only when looking at my LP page;  I have switched LP back to another address
<robitaille> so hopefully my @ubuntu address will come back in a hour
<elmo> robitaille: ah, hmm
<elmo> FWIW, there's a spec to not let you do that, although I can see why you'd want to
<ogra> mvo, hey, also on isdn ? 
<Nafallo> hmm, we should be able to mark which addresses should be shown.
<Nafallo> and the ubuntu.com one could popup when you are a member :-)
<mvo> ogra: i hate my regular network
<black_> hello peope
<black_> people
<mvo> (and it hates me too apparently)
<ogra> mvo, me too
<black_> someone speak spanish?
<black_> y need an X file explorer to install in my ubuntu hoary
<ogra> mvo, poke \sh to poke the ISP guys :)
<black_> which you recomend?
<\sh> I just read it
<HrdwrBoB> black_: #ubuntu-es
<\sh> but I'm on holiday ,-)
<HrdwrBoB> or #ubuntu
<Nafallo> black_: #ubuntu probably :-)
<HrdwrBoB> this isn't a support channel
<black_> ok
<black_> sorry
<black_> you are rigth
<mvo> ogra: it looks like it's my router ... I'm too tired to look into it right now
<elmo> jbailey: done
<ogra> mvo, for me the DSLAM in the headend died again it seems... 
<jbailey> elmo: Thanks.
<mvo> ogra: again? didn't it died last week?
* ogra would really prefer to bundle 10 ISDN lines but ENOFLATRATE
<ogra> mvo, apparently its still not fixed completely... the line drops once every two days for some hours...
<\sh> good night gentlemen :)
<mvo> \sh_away: good night
<ogra> night \sh 
<mdz>  *    GDMflexiserver - run a flexible server
<mdz>  *    (c)2001 Queen of England
* mdz blinks
<mdz> I didn't know her majesty had contributed to gdm
<ogra> lol
<Lathiat> haha
<Keybuk> the gdm author is nuts
<Keybuk> I figured he was 12 from his changelog entries
<Keybuk> but he's actually a 50yo college professor or something
<carlos> mvo, pong
<mvo> carlos: I wanted to ask about the synaptic pot-file changes (only one per directoty), but that can wait until tomorrow
<carlos> mvo, ok
<robitaille> mdz,  maybe gdm was partly written by someone working for the english government?  At work, whatever I code for the Canadian government is also copyright by the crown, i.e, the queen of england
<robtaylor> mm. i get bus errors in gtk today, is that known about?
<jdub> Keybuk: george is our age (but no longer maintains gdm)
<jdub> Keybuk: he's also a crazy czech
<jdub> deeply, deeply crazy
<mdz> Kamion: weird, just switching to vt1 and back before shutdown makes everything work for me
<mdz> BenC: around?
<mdz> BenC: I need a kernel perspective on this vt switching issue on the live CD
* lamont__ wonders if there is a delayed-upload queue for ubuntu anywhere...
<lamont__> and I bet the answer is "no"
<mdz> Kamion: what is happening in my case is that it is ending up on vt2 rather than vt1
<mdz> I sort of suspect a race between X and gdm both trying to go back to the old vt
<mdz> gdm tries to switch to vt1 and succeeds, but I am on vt2 when the smoke clears
<mdz> vt2 is the console used for the boot process because vt1 is mangled by bterm
<mdz> switching to vt1 before starting X would be a workaround
* lamont__ -> home
<mdz> I think X might need the same treatment I gave usplash, to avoid going back to the old vt if it's been changed by the user since starting
<jdub> ha ha
<jdub> someone's got their RT replying to ubuntu-users
<ogra> yay, no overflowed edubuntu CDs anymore and a empty report :)
<bddebian> ogra: Nice
<ogra> yup
<bddebian> elmo: you around?
<elmo> kind of
<bddebian> Do you know if you have my key already or do I need to mail keyring?
<elmo> mail to keyring
<bddebian> OK, thx
<bddebian> Done
<desrt> it's comical how non-functional freenode is
<bddebian> desrt: ?
<desrt> it's blocking me from sending private /msg's
<ogra> desrt, register
<bddebian> Is your nick registered?
<desrt> because privmgs spam has become a problem
<desrt> no.  it's not.
<Lathiat> you ened to register with nickserv
<Lathiat> and you can set unfiltered on to receive messages from non-registered users
<Lathiat> desrt: and to be honest, every network has the same problem, its a shame its apparently gotten so bad they had to go this far
* desrt has been spammed once on efnet
* Lathiat used to run a 400 users network that had enough trouble to keep him busy... 
* desrt gets spammed on freenode every 12 seconds by lilo and his ever-changing hostmask crack of the day
<Lathiat> bags nto running a 25,000 user network
<desrt> you just can't /ignore that guy
* Lathiat laughs 
<bddebian> hehe
<desrt> the ignore is good for like 2 and a half minutes until he comes up with a new standard hostmask format
<Lathiat> his hostmask is pretty constant, ti did change recently
<Lathiat> anyway off to uni i go
<desrt> Lathiat; cheers
<bddebian> Damnit, now why doesn't tagcoll show up in the archive?
<bddebian> Sources shows 1.3-1 and the buildlogs are OK but the binaries are still 0.99 ??
<Lathiat> bddebian: how long since it built? takes a bit of time for things to go through you know
<bddebian> 21:22
<bddebian> Maybe it's just because I annoyed elmo today? :-)
<ogra> did you ?
<bddebian> I think a little.  But they were all valid sync requests afaict.  Though I am disappointed with regina-normal.
<bddebian> Hmm, same for stellarium but I don't even see the -3 buildlogs for stellarium.
<bddebian> lamont: ping
<bddebian> Damn I hate this time of day
<bddebian> There is a bug on Malone (2077) requesting an update of libdv which is in main.  Before I get in trouble again, how should this be handled?
<bddebian> Same for lirc
<mjg59> http://lists.userlinux.com/pipermail/discuss/2005-September/007376.html is fun
<mjg59> No idea why it ended up on the Userlinux list
<mjg59> (Userlinux summary: Still no userlinux)
<bddebian> Heh
<jdub> daniels: ping
<daniels> jdub: represent
<jdub> daniels: dude, my i855crt stuff still isn't working right
<jdub> i get hideous colours on my vga output
<daniels> define 'hideous colours'
<mjg59> jdub: Uhm, yeah, that actually seems to be usplash
<daniels> and when did it stop 'working right'?
<daniels> oh, sweet, SEP
<jdub> daniels: long before guadec
<mjg59> Oh, maybe not, then
<mjg59> Hurrah. Not my fault.
<jdub> daniels: because i talked to you about it then, too
<daniels> jdub: my powers of recall are weak
<jdub> though it appeared to be some strange interaction with a second screen then
<mjg59> daniels: I get it too - switch to CRT out and the background colours are psychadelic
<jdub> hideous colours == washed out, psychadelic, rainbow, etc.
<jdub> (means i can't use my laptop for presentations)
<daniels> wow, sweet
<mjg59> daniels: Test on your X40
<daniels> i think I have an idea of what that might be
<mjg59> I'm not using i855crt any more, and it still happens
<daniels> mjg59: not using i855crt -> dual head defined in xorg.conf?
<mjg59> daniels: No
<mjg59> daniels: Hitting fn+f7
<mjg59> The BIOS does the switch now
<jdub> mine doesn't do that
<mjg59> jdub: Yours should do
<jdub> daniels: is it configuration fixable?
<jdub> mjg59: nein
<jdub> fn-f8 on mine, doesn't do anything
<mjg59> jdub: Uhm. It's worked fine for me on previous X300s.
<jdub> maybe if i've been abusing i855crt it won't work?
<mjg59> Hm. Possible.
<mjg59> jdub: You've seen that weird Tom Lord email on userlinux-discuss?
<jdub> yeah
<jdub> funny
<bob2> no
<bob2> echan
<jdub> i should probably get a move on
<jdub> mjg59: nm/nm-applet doesn't survive sleep
* daniels frowns at his VBIOS.
<jdub> and of course, restarting nm means restarting dbus
<mjg59> jdub: nm? Nothing to do with me, I'm afraid
<jdub> which is VERBOTEN
<jdub> mjg59: no, but you may have insight to help fix it
<mjg59> But the version in the archive survives fine here
<jdub>  *** 0.4.1+cvs20050817-1 0
<jdub>         100 /var/lib/dpkg/status
<jdub>      0.4.1+cvs20050618-3 0
<jdub>         500 http://archive.ubuntu.com breezy/universe Packages
<jdub> 
<jdub> hmm
<jdub> must have newer from j^
<mjg59> Yeah, I have the archive one
<mjg59> Which occasionally disconnects me from the world, but other than that seems to work
<mjg59> Also, you should play with gnome-power-manager
<jdub> i did a bit
<daniels> maybe it's time for another pull from HEAD, because fn+f7 is okay here
<jdub> but a while back
<jdub> ok, gotta go
<daniels> jdub: wait
<daniels> jdub: i demand to know the version of xserver-xorg-driver-i810
<jdub> mjg59: oh!
<jdub> mjg59: it is because i am on my base station
<mjg59> daniels: Hmm. Yeah, it's ok here too now.
<jdub> mjg59: and it seems to break all of that
<jdub> daniels: 6.8.2-56
<jdub> mjg59: it doesn't do anything when i press sleep, either
<mjg59> jdub: On the dock? Suck.
<mjg59> I don't /remember/ that being a problem
<daniels> okay, so i855crt is broken, but fn+f7 is okay
<daniels> i *think* I know what this is
<jdub> mjg59: can i help through figuring out dock stuff?
<daniels> sweet jesus
<mjg59> jdub: Hm. Running the latest kernel?
<jdub> latest breezy bits
<mjg59> Can you grab http://free.linux.hp.com/~awilliam/acpi/dev_acpi/dev_acpi-20041026.tar.bz2 and build the userspace stuff
<mjg59> Then run eventwatch
<mjg59> Wait for the initial splurge to die down, then try pressing keys and see if anything gets generated
<mjg59> You know what the best thing about having had no mail today is?
<mjg59> I haven't got a new bug yet
<daniels> right, i855-crt is out of sync with the new pipe handling code
<jdub> hrm, how do i get a modules/*/build directory again?
<daniels> tbh, I have no desire to fix it, since fn-fX should work and work better
<mjg59> jdub: You shouldn't need one
<mjg59> Just do make eventwatch
<jdub> yeah, it wants dev_acpi built
<mjg59> Nngh
<mjg59> Hack teh makefile
<mjg59> Or install linux-headers-`uname -r`
<jdub> nono, it *really* wants dev_acpi
<jdub> #include "dev_acpi.h"
<jdub> #define DEVICE "/dev/acpi"
<mjg59> jdub: Yeah. That's fine, but it doesn't need it *built*
<mjg59> dev_acpi is in the kernel
<jdub> hrm
<jdub> hrm
<jdub> eventwatch.c:36:27: error: acpi/acconfig.h: No such file or directory eventwatch.c:37:33: error: acpi/platform/acenv.h: No such file or directory
<jdub> yeah, need headers
<mjg59> Hngh.
<mjg59> Right.
<jdub> dum de dum
<daniels> i need to turn more xorg problems into acpi problems
<jdub> daniels: there's still an i855crt problem!
<daniels> jdub: fuck i855crt
<jdub> heh
<daniels> jdub: it's a really nasty hack
<jdub> ie. once fn-f8 works, you don't care?
<daniels> yeah
<jdub> ok
<daniels> because fn-f7 works here
<mjg59> We mostly needed i855crt because the BIOS stuff was broken in older i810 driver code
<mjg59> Now it has more int10 goodness!
<daniels> keeping the i855crt codebase painfully in sync with the i810 driver is not my idea of a good time
* jdub watches eventmode spew
<daniels> mjg59: don't make me quote you on that
<mjg59> daniels: You can't see my facial expression
<jdub> sec
<jdub> cab
<jdub> will do rest on the way ;)
<mjg59> Heh
<mjg59> See you
<daniels> mjg59: la la la la I'm not listening
<bddebian> heh
<jdub> mjg59: ping
<jdub> eh
<jdub> slow
<jdub> mjg59: nothgng when ipess keys
<jdub> still in dock
<jdub> in cab
<jdub> ping anyone?
<desrt> pong?
<bob2> mjg59 may be looking for more whiskey to ease the int10 pain
<jdub> ah thanks
<jdub> yay gprs
<jdub> boo mjg59 
<mjg59> jdub: Hm.
<jdub> heh
<mjg59> jdub: Fn+escape doesn't produce anything?
<jdub> my volume things work
* mjg59 blames BIOS brokenness
<jdub> fn-esc is suspend, doesn't work
<mjg59> And nothing in eventwatch?
<jdub> no output
<mjg59> Gah
<mjg59> No idea, I'm afraid
<jdub> anything else that gets output?
<jdub> closing lid doesn't
<mjg59> Does closing the lid lock the screen?
<jdub> no
* ajmitch noticed last night that closing the lid doesn't properly turn off his screen
<jdub> will reboot in dock to make sure
<daniels> yay acpi broken
<bob2> this with your x1?
<mjg59> jdub: Ok. Does pressing the sleep key cause interrupt 9 to increment?
<jdub> hold on
<jdub> eventmode is in D state
<jdub> bob2: x300
<jdub> can't kill it
<jdub> er, eventwatch
<jdub> rebooting
<marcin_ant> hi all
<marcin_ant> could someone tell me why nautilus-sendto on breezy doesn't have bluetooth support?
<marcin_ant> is this unstable or something? or just it compiled without bluetooth and no one cares?
<ajmitch> bluez-utils was only recently promoted to main
<ajmitch> does the nautilus-sendto code depend on gnome-bluetooth?
<marcin_ant> ajmitch, the thing is that nautilus-sendto depends on gnome-bluetooth
<shackan> it does
<marcin_ant> and it doesn't compile with bt support because there is no gnome-bluetooth.pc file in gnome-bluetooth package
<ajmitch> and gnome-bluetooth is in universe
<marcin_ant> (propably it requires some gnome-bluetooth headers or something)
<ajmitch> I don't believe it's being promoted to main, as it's quite late in the cycle
<jsgotangco> why not? its just not going into our feature
* shackan was supposed to write a gnome-bluetooth replacement this summer...
<marcin_ant> so because gnome-bluetooth is not in main repository then you don't have bt support in nautilus-sendto?
<ajmitch> marcin_ant: didn't you say that nautilus-sendto required gnome-bluetooth to compile?
<marcin_ant> it requires to compile BT plugin
<ajmitch> right, so as it stands now, we won't have it
<shackan> it's optional, it has also email and IM plugins afaik
<ajmitch> that decision may change
<shackan> until when may this change ?
<marcin_ant> ajmitch, so it pretty sucks that you don't include pretty nice feature to your package only because you don't like it's dependency
<marcin_ant> ajmitch, and in fact I could understant this
<marcin_ant> ajmitch, but then it could be nice to have something like nautilus-sendto-bluetoothplugin package in universe 
<ajmitch> marcin_ant: yes, and that could be possible
<shackan> sad to admit it's partially my fault
<Lathiat> it would have to be a separate source package, however
<ajmitch> something similar was done with php4 packaging
<Lathiat> and gstreamer-plugins
<ajmitch> I'd like to see it, as I've got some bluetooth devices
<shackan> ajmitch, I was the student assigned to bluetooth support
<ajmitch> shackan: ah right
<marcin_ant> ajmitch, another thing that bluetooth support is on top of breezy goals in wiki...
<shackan> (for that Google thingie)
<Lathiat> shackan: were you not able to complete it?
<ajmitch> marcin_ant: yes, and feature freeze began last month - things not ready by then didn't make it in
<shackan> spent time writing the dbus bluetooth daemon from scratch
<ajmitch> shackan: ouch :)
<shackan> you bet
<marcin_ant> shackan, and what it gives to end user?
<marcin_ant> shackan, for example I wish to have pretty simple feature from my k700i cell phone in ubuntu
<marcin_ant> shackan, this feature is an access to files stored on my phone via bluetooth and ftp protocol
<marcin_ant> shackan, in windows I got shortcut in windows-explorer (bluetooth places) and I can copy/move/remove files just like on ftp account
<mdz> daniels: what is the ATI driver/DRI version mismatch that was mentioned in the colony 4 thread
<mdz> ?
<shackan> to the programmer, it gives an easier api to handle those devices than the actual low level bluez, and a clear separation of the core stuff from the gui tools, so we can have a Gtk gui and a Qt one without changing the underlying stuff
<marcin_ant> shackan, is there a chance to have this functionality with nautilus? obex/ftp protocol?
<shackan> marcin_ant, you ever tries the obexftp gnome-vfs module ?
<shackan> *tried
<marcin_ant> shackan, no I use gnome-obex-send and gnome-obex-server
<mdz> daniels: never mind, saw the bug
<marcin_ant> shackan, is this the same?
<shackan> marcin_ant, what you mention is gnome-bluetooth, which is very limited right now
<daniels> mdz: i have the fix (new l-r-m with the nvidia and fglrx stuff) in hand, just need a couple of people to get back to me on nvidia legacy stuff
<marcin_ant> shackan, apt-getting obexftp
<Lathiat> daniels: will do so this afternoon
<Lathiat> daniels: however, im fairly sure its the kernel driver that has a cry given it has the pci ids and writes in dmesg
<ajmitch> marcin_ant: understood, I have the same model phone beside me on the desk :)
<ajmitch> daniels: how legacy do you need?
* ajmitch has geforce2 mx
<daniels> ajmitch: not supported by the current driver
<marcin_ant> ajmitch, nice :)
<daniels> ajmitch: perfect!
<marcin_ant> ajmitch, and how you transfer files to and from this phone?
<daniels> ajmitch: could you please try to modprobe nvidia from the current version (7667 or 7674, the former is in l-r-m) and tell me if the kernel driver bombs or not?
<shackan> obex ftp is just a cli program, like your command line ftp, more or less ( only that directory listing is formatted and xml-like format :) I don't know if there's a package for the vfs module ( I haven't tried it anyway, just studied its source code )
<ajmitch> daniels: I'll have to do it later, since it's my home box, running 2.6.12-6
<ajmitch> and all I can say at the moment is that it works on that kernel
<marcin_ant> shackan, right - I cannot see obexftp gnome-vfs package too
<daniels> ajmitch: sure
<daniels> ajmitch: okay, thanks
<marcin_ant> anyway it could be nice have two things in ubuntu 1. nautilus-sendto with BT support
<shackan> I wanted to do that, but run out of time with other things
<marcin_ant> and 2. some gui tool to scan bt neighbourhood, and scan available services and for example mount obexftp device as yet another 'drive'
<shackan> ah, that one can be done
<shackan> I'm already on it actually
<shackan> only the 'mount' part is missing
<marcin_ant> of course propably support for com ports via BT and gprs connectivity is more important
<marcin_ant> but I could say that support for syncml via bluetooth in evolution is important too
<marcin_ant> shackan, I know how to scan devices with gnome-bluetooth manager - but it doesn't show available services
<shackan> http://shackan.altervista.org/service_panel.png
<shackan> take a look
<marcin_ant> shackan, and I can scan these services with cli tools
<shackan> I know
<marcin_ant> shackan, but I don't know how to mount this obexftp device...
<shackan> I had to do that without cli tools
<shackan> and I relegated all the low level stuff to my daemon now
<marcin_ant> shackan, is this bluetooth browser available somewhere?
<shackan> yes, but installation of gui and daemon is a but cumbersome now, since I didn't have time to write the debs
<marcin_ant> shackan, (btw I know that I shouldn't talk about it out loud but today I installed SP2 on my XP box and MS drivers for MSI6967 BT dongle... really great stuff, good and intuitive UI)
<ajmitch> shackan: hand the deb creation to MOTUs who might have some spare time for it
<marcin_ant> shackan, any repository? cvs/svn?
<ajmitch> shackan: no guarantees of getting in, but we'll try :)
<shackan> if you convince my menthor to give me the money I can continue development :)
<shackan> marcin_ant, http://svn.berlios.de/viewcvs/bluetool/trunk/ but I discourage you to checkout
<marcin_ant> shackan, btw did you get money from google? (just courious)
<shackan> of course not
<marcin_ant> shackan, of course not yet or of course not because it didn't qualify to get money?
<shackan> seems I've worked two months 24/7 for free (anyway, I'm getting OT)
<marcin_ant> in fact I think that this SoC thing is pretty strange - a lot of PR on start
<marcin_ant> and then it is absolutely quiet...
<shackan> it couldn't get production level stuff by 1st september, and apparently unlike other google projects couldn't continue it after deadline
<marcin_ant> shackan, I see
<marcin_ant> shackan, btw where are you from? italy?
<shackan> anyway I wish I hadn't written 14000 lines of code for nothing, but mine its just a rant
<shackan> yes, italy
<wasabi> For nothing?
<wasabi> You have 14,000 lines of code. That's not nothing.
<shackan> wasabi, they dont pay the rent
<marcin_ant> wasabi, you cannot give this code at shop for food ;)
<mjg59> shackan: There was a deadline. That's the way the world works.
<marcin_ant> I wonder if there is some bounty available from canonical for further development on this BT project
<mjg59> marcin_ant: It's quite likely that there will be. Bluetooth support on the desktop is greatly lacking.
<shackan> that's not the point, today I found out with my menthor that if I had spoken earlier about my being late on schedule they could have let me through, but since I'm bloody dumbass and I was aiming too high even hoping to get it on time...
<jsgotangco> marcin_ant, its in the wiki BreezyBounties
<marcin_ant> jsgotangco, sure but as google bounty
<jsgotangco> ah
<jsgotangco> 14,000 lines of code can still be used for Breezy +1
<marcin_ant> and in fact I'm not interested since it is too difficult for me - but I would like to work on calendarsynchronization bounty
<marcin_ant> anyway does anyone here know something about money from canonical?
<bob2> it tastes better than regular money
<shackan> jsgotangco, they can be used for what you want, you can also print them and use it as toilet paper as far as I'm concerned, I got the good news today and I don't care anymore about what will come of that
<marcin_ant>  shackan, could get 4500 from google - and propably canonical bounties are not so high
<mjg59> marcin_ant: The right way to work on the calendar synchronisation stuff is to get involved in opensync
<shackan> uhm, "good news" was ironical of course
<mjg59> marcin_ant: If there is any more money, already having written some code will make it much more likely that you'll be picked
<shackan> marcin_ant, seems I can't get google money anymore
<shackan> but, again, I'm getting OT here
<marcin_ant> mjg59, well the thing is that calendar synchronization is breezy bounty (related with opensync and evo) and it is propably gnome bounty (novell)
<marcin_ant> mjg59, (but I'm not sure if it is still available)
<mjg59> marcin_ant: As a summer of code bounty? No. But as an Ubuntu one, almost certainly
<marcin_ant> mjg59, I've been talking with jbailey about it some time ago and I thing that problem is that propably no one knows what is this goal about
<mjg59> marcin_ant: Basically, make opensync work
<marcin_ant> mjg59, no CalendarSynchonization wasn't google bounty
<ajmitch> opensync packages will be built for debian real soon now, according to their list
<mjg59> marcin_ant: Get opensync into a state where it supports syncml, whatever protocol it is that WinCE uses, and PalmOS
<Lathiat> funky
<Lathiat> opensync is looking good
<shackan> I didn't have anything about calendar synchronization
<Lathiat> irmc would be nice too
<ajmitch> Lathiat: yeah, I've been on their list watching since it started up
<mjg59> And can synchronise all of those against Evo
<marcin_ant> mjg59, syncml synchronization is one thing
<marcin_ant> mjg59, and this bounty http://www.gnome.org/bounties/Calendar.html#127538 is propably a little different
<mjg59> Yes, that's quite different
<mjg59> Though it could probably be done via opensync
<marcin_ant> mjg59, and afaik there are two different ideas - ical and caldav
<mjg59> marcin_ant: Yeah. They're not what the Ubuntu bounty is about.
<marcin_ant> mjg59, well true
<marcin_ant> mjg59, the only thing is to write plugins to opensync
<shackan> bah, its 5:10 am anyway
<marcin_ant> mjg59, anyway I need to go to bed
<mjg59> marcin_ant: And integrate into the desktop
<marcin_ant> shackan, hehe we are in the same time zone ;)
<shackan> :)
<shackan> you from?
<marcin_ant> shackan, and we should better go to sleep
<marcin_ant> shackan, Poland
<shackan> bah, I've coded until 5am for two months
<shackan> it's hard to regain regular sleeping habits
<marcin_ant> shackan, I usually goto bed at 4 am... coding at night ;)
<shackan> moreover, disappointment for being fired today took my appetite and sleep far far away
<shackan> but we're OT again...
<mpt> shackan needs a hug
* shackan needs just money
<mpt> well, yeah, that too
<bob2> I bet mpt is good at both
* marcin_ant needs money too
<marcin_ant> so we need to launch #ubuntu-money channel :)
<mpt> bob2: Sweet-talking will get you nowhere
* bob2 writes up a MPTHugDonationSpec
<daniels> mjg59: oh, by the way
<daniels> mjg59: there should be a new shiny interesting option in i810-land for you, I think
<bob2> what is fn-f3 supporsed to do, anyway?
<mjg59> daniels: Mmm?
<daniels> mjg59: ah, nevermind
<mjg59> Damnit, don't tempt me like that
<daniels> need to harass alanh to commit vesa-mode-table-rewriting
<mjg59> Nnngh.
<mjg59> Yes.
<mjg59> It *works*
<mjg59> Pls provide code k thx bi
<daniels> he
<daniels> h
<daniels> i'll ask him today
<daniels> i swear if anyone else bzip2s a Xorg.0.log, I'm going to explode
<HrdwrBoB> lol
* bddebian whips out bzip2
* dilinger wonders why breezy is attempting to run mmx instructions on his VIA machine
<Lathiat> daniels: .. ?
<dilinger> actually, scratch that.  cpuinfo claims it supports mmx
<Lathiat> daniels: uh, why?
<daniels> Lathiat: because it's a pain in the arse for me to look at the log
<daniels> Lathiat: it's a false economy, since all you save is like 50kB, and attachments aren't mailed out to people
<Lathiat> heh
<Lathiat> well uh
<Lathiat> i'll rzip my next one 
<Lathiat> :)
<daniels> don't compress it at all
<daniels> just attach
<mjg59> I'll pad it with nulls
<daniels> mjg59: i know you do it because you care
<bddebian> mjg59: :-)
<bur[n] er> would a nautilus bug be pertinent for ubuntu bugs or should I go straight to gnome's bugzilla?  it's just sftp:// crash happy, even in 2.12
<desrt> Failed to fetch http://ca.archive.ubuntu.com/ubuntu/dists/breezy/universe/source/Sources.gz  MD5Sum mismatch
<desrt> O_o
* desrt knows martin is awake :P
<robitaille> bur[n] er,  depends; do you think it is an ubuntu-specific bug, or gnome specific.  If you're not sure, just fill up a bugzilla bug report.
* bur[n] er isn't sure... thanks robitaille (as a side note, luc robitaille was a great hockey player for the kings ages ago)
<lamont> bddebian: pong
<bddebian> Doh, how'd I know you'd pong when I was going to bed.. :-)
<bddebian> lamont: Is ctsim and/or stellarium hung up?
<robitaille> bur[n] er,  he still plays for them last time I heard.   
<lamont> universe/science/stellarium_0.6.2-3ubuntu1: Dep-Wait by buildd+king [optional:out-of-date] 
<lamont>   Dependencies: xlibmesa-gl-dev
<lamont> bddebian: so is that something that's fixed and clearing will help?
<bddebian> Well I had elmo sync -3 from Debian, then -3ubuntu1 should fix the xlibmesa-gl-dev dep..
<lamont> ok
<lamont> bddebian: cleared
* lamont -> sleep
<bddebian> Kick-ass, thanks lamont Did ctsim even show up.
<bddebian> Whoops, sorry, nm
<lamont> it's marked installed...
<bddebian> Hmm, OK.  Thanks again.  Gnight
<crimsun> argh
<Burgundavia> Kamion, thanks for the hint
<fabbione> morning
<ajmitch> morning fabbione 
<fabbione> desrt: sorry that i had to go away so fast yesterday
<fabbione> what were you looking for?
<desrt> fabbione; patch testing :P
<desrt> it's damned difficult to find someone with an acpi laptop and a few spare minutes
<fabbione> i have a laptop, but it's very old...
<desrt> it's ok
<desrt> martin will probably be awake soon
<desrt> then he can deal with it :P
<fabbione> ok :)
<desrt> it's sort of a shame that the lot of us own powerbooks/ibooks :P
<fabbione> desrt: i am planning to buy one soon
<daniels> just get an x40
* bur[n] er likes his compaq x1000
<fabbione> daniels: no.. i want a powerbook
<fabbione> i need something != i386 | m68k
<desrt> fabbione; i tried to get mjg59 to buy me one.  i was too late though :(
<fabbione> desrt: don't be upset ... plenty of people didn't get one.. me included
* desrt starting to become a little disenfranchised with apple lately
<daniels> fabbione: ... why?
<fabbione> daniels: because i have like 8 i386 at home...
<fabbione> i want something that's not i386
<desrt> get a tadpole :)
<fabbione> new arch .. new problems .. new challenges
<daniels> getting other architectures at home would seem to be a better solution
<daniels> since you always have other machines to use at home when something goes arong
<daniels> wrong, even
<daniels> not so on the road
<daniels> and i386 is the only way to get a laptop that's both reliable and not shit
<fabbione> daniels: the same way i fix i386, i can fix ppc
<PlutoPrime> I'm on a pentium m laptop right now
<fabbione> daniels: if the hw breaks down, there is not much you can do anyway
<bur[n] er> as much as i prefer amd, pentium m's are the best... good battery life & speed & temp & fan noise is low
<PlutoPrime> I was watching the cpu-step meter and watching a movie full screen was stuck at 600mhz which I found impressive... glad the desktop x86 is getting speed-step
<PlutoPrime> save a lot of power and noise
<pitti> Good morning
<daniels> pitti: morning
<desrt> pitti; word.
<Chipzz> fabbione: I have sparc and pa-risc here :P
<Chipzz> and an m68k xterm
<daniels> i have our three supported architectures here, so I'm happy
<Chipzz> (as a matter of fact of have more running non-i386 than running i386 :)
<daniels> (i386 laptop, amd64 desktop, powerpc desktop machine that's not used as a desktop, sparc that just runs sid)
<Chipzz> oh and an arm (I think) linksys accesspoint :)
<Chipzz> if that counts
<Chipzz> (it runs linux though :P)
<fabbione> daniels: i only have i386/sparc/m68k... hence the need to add a ppc
<fabbione> Chipzz: hppa and ia64 will come soon i hope
<Treenaks> daniels: PCIE ATI cards not having DRI is a known bug?
<daniels> fabbione: don't forget amd64
<Chipzz> fabbione: I think I should be able to obtain an alpha
<fabbione> daniels: yeah.. one thing at a time :)
<daniels> Treenaks: yeah, we don't have PCIE support in the DRM, which sucks
<Chipzz> m68k/ppc should be easy
<desrt> daniels; did you get a chance to test that patch?
<Treenaks> daniels: ok
<fabbione> Chipzz: eh.. alpha has been donated to me, but it never arrived here :(
<Chipzz> I think the hardest would be mips and mipsel
<daniels> desrt: no, not yet
<Chipzz> I had the chance to buy and SGI once, but I didn't have the money back then :/
<fabbione> Chipzz: ps2 has mips
<daniels> mips and mipsel don't even really work anyway
<pitti> jdub: is your double CD-ROM problem solved in gnome-vfs2 2.12.0-0ubuntu1?
<fabbione> hey pitti
<pitti> Hi my dear fabbione! :-)
<fabbione> pitti: i think you forgot to forward the patch in attachment to BenC
<Chipzz> daniels: well there are buildd's for them, so I suppose they do... ;P
<desrt> pitti; there's some acpid loving for you in bugzilla
<pitti> fabbione: uh, did I?
<fabbione> pitti: anyway the agreement is that i will do hoary and he will do breezy
<fabbione> pitti: it looks like..
<pitti> fabbione: ok, I send him the patch
<pitti> desrt: cool! I do that immediately after preview
<Chipzz> hmmm s390
<Chipzz> what's that even?
<desrt> pitti; might want to wait for some testing, actually...
<desrt> pitti; so far, completely untested :P
<Chipzz> fabbione: as the main processor or as a coprocessor?
<daniels> Chipzz: yes, but that's no great metric.  all of the mipsel binaries uploaded during a two or three-month period once were completely broken.
<fabbione> Chipzz: main afaik
<fabbione> Chipzz: i have a ps2 here, but no money to buy the linux kit
<daniels> Chipzz: and the toolchain breaks so frequently on mips* that you're lucky if half the archive builds.  look at the built-package stats for them.
<Chipzz> daniels: well that's the toolchain, not linux itself ;P
<daniels> Chipzz: s390 is a mainframe, you don't want that
<Chipzz> *g*
<Chipzz> daniels: weird, as a lot of textbooks take mips as the example to explain computer (processor) architecture
<daniels> Chipzz: yes, and a lot of people use modular kernels as a nice computer science example in academia.
<Chipzz> "Computer Architecture - A Quantitative Approac" which is laying next to my bed does, for example
* fabbione would really love to get back his E10000
<Chipzz> daniels: good point :)
<jdub> pitti: looks good to me
<pitti> jdub: yay
<PlutoPrime> I was wondering is hal 0.54 going to make it to breezy?
<pitti> PlutoPrime: probably not, I rather backport now
<jdub> ogra: when will xscreensaver get s/Someone else.../Switch user.../ ? :)
<bob2> is that picture of me going to last in to the final release of breezy?
<jdub> no, ogra's asked for new images
<bob2> dang
<jsgotangco> lol
<tritium> daniels: got a minute?
<Treenaks> picture of bob2?!
* Treenaks will never lock his screen again ;)
<Nafallo> /note to self: _sleep_ in the nights, be _awake_ in daytime
<Nafallo> Treenaks: apt-get install gnome-screensaver ;-)
<jsgotangco> Treenaks, yeah, you'll see bob2, chmj and jdub
<Treenaks> Nafallo: unless you're planning on migrating to the other side of the planet
<Treenaks> jsgotangco: *eep*
<fabbione> Nafallo: hey.. did you get my messages from yesterday?
<jsgotangco> that was probably taken after the smackdown in UDU
<Treenaks> jsgotangco: I want UBZ :)
<bob2> I look too concious for it to be UDU
<Nafallo> fabbione: mplayer? yepp. uploaded some hour or so after that.
<fabbione> Nafallo: ok
<Nafallo> * The "fabbione told me to..." release.
<Nafallo> :-)
<fabbione> oh yeah i see it now
<fabbione> i missed the mail to -changes
<Nafallo> hmm, evo needs hilight-support then ;-)
<Treenaks> Are there python-bindings for the plugin layer yet?
<Nafallo> hmm, I'll have to find my coffeine-pills
<Treenaks> Nafallo: whoa, that's strong coffee then
<Nafallo> Treenaks: 200mg should do ;-)
* Treenaks sticks to tea, earl grey, hot
<bob2> I'm not sure if it's creepier that you remember it or that I do
<daniels> tritium: sort of
<daniels> tritium: what's up?
<daniels> jsgotangco: i think jbailey's in that picture too
<jdub> i thought it was mvo
<daniels> oh yeah
<daniels> yeah, it is
<daniels> i started off thinking it was jbailey and ended up with probably-mvo
<tritium> daniels: I'm testing a Toshiba Tecra A2.  Blacklisting evdev restores speed/tapping to my touchpad (re: #14480)
<Nafallo> marilize: hi! what's the status on the 400 CDs? are they sent?
<daniels> tritium: hrm.  and you've got xorg-driver-synaptics 0.14.3+revertedto+0.13.6-0ubuntu1 installed?
<daniels> tritium: if so, then I'll cheerfully declare it a kernel bug and move on with my life
<tritium> daniels: let me verify that...
<niran> wow. if i scroll gedit too fast, it crashes. fun.
<jsgotangco> i still have 0.14.3-1ubuntu1
<tritium> daniels: no, 0.14.3-1ubuntu1
<daniels> hrm, 'sec
<tritium> sure
<daniels> okay, new version uploaded that should fix -0ubuntu1's FTBFS :P
<tritium> okay
<jsgotangco> k we'll just wait
<marilize> Nafallo: Hi, email address you placed the order with?
<tritium> thanks, daniels 
<tritium> I'll try that, and not blacklist evdev
<tritium> hey dholbach :)
<dholbach> good morning
<dholbach> hey michael
<daniels> ;win 38
<dholbach> hey daniel :)
<Nafallo> marilize: nafallo@magicalforest.se for SFD
<Mithrandir> \sh_away: pong
<Nafallo> marilize: so if they are not sent, there is not much point in doing so :-P
<dholbach> morning tollef
<jsgotangco> Nafallo, burn 'em!
* Nafallo tickles Mithrandir a bit
<Nafallo> jsgotangco: 400 CDs on a laptop? :-P
<jsgotangco> oh
<jsgotangco> you can start now
<Nafallo> we do have 100 copies of TheOpenCD :-P
* Mithrandir tickles Nafallo back
<Nafallo> Mithrandir: ey! :-)
<marilize> Nafallo: you'le get if early next week, too late?
<Nafallo> marilize: SFD is this weekend
<wickedpuppy> hi guys does anyone here know who should i contact for bootloading ubuntu ??
<Treenaks> wickedpuppy: what do you mean?
<Treenaks> wickedpuppy: a bug in the bootloader?
<marilize> Nafallo: I'll have to speak to Mako to see if he can do something for you....
<Treenaks> wickedpuppy: preloaded ubuntu on new systems?
<Nafallo> marilize: send him with the cds? :-)
<marilize> Nafallo: maybe with a rocket :)
<Nafallo> hehe
<jsgotangco> good luck on taking him out of boston heh
<Nafallo> jsgotangco: ;-)
<tritium> good night
* pitti eagerly waits for today's CD set
<Nafallo> pitti: ? anything special on them? :-)
<pitti> Nafallo: well, if everything goes well, they become the preview isos
<pitti> (I assume)
<jsgotangco> hmm
<jsgotangco> i just rsync'ed and it works nicely
<Nafallo> pitti: yay! :-)
<Treenaks> colony4 is broken on my old laptop
<Treenaks> it stalls in stage2 when "Downloading 854 of 858 (0s remaining)"
<jsgotangco> hmmm
<jsgotangco> that is strange
<Treenaks> when running aptitude
<jsgotangco> it should have been solved a few days after Colony 3
<Treenaks> jsgotangco: this is a very old/slow machine
<Treenaks> jsgotangco: 600MHz
<jsgotangco> wow just like my PDA
<jsgotangco> (well almost)
<ajmitch> Treenaks: perhaps a re-burn is in order
<Treenaks> ajmitch: this CD worked last night on my OTHER laptop
<ajmitch> or check the cd integrity, since I had that problem & a new cd made it all happy
<ajmitch> that's the other laptop :)
<ajmitch> some drives don't like some cds
<Mithrandir> mvo: it appears that the update-notifier notification isn't xinerama-aware?
<Treenaks> ajmitch: it's ancient, so it might not like this CDRW
* dholbach thinks . o O  { poor mvo }
<ajmitch> Treenaks: I think we should be booting off usb storage ;)
<Treenaks> ajmitch: no way
<Treenaks> ajmitch: the thing only has 1 USB port, and it's USB 1.1
<mvo> Mithrandir: possible, what are the symptoms?
<rob^> juat a quick question: does gstreamer0.8-dvd do the same job as libdvdcss/2?
<bob2> no
<Mithrandir> mvo: the notification is spread across both monitors.
<rob^> so we are still having issues with dvd playback then 
<rob^> ?
<Treenaks> rob^: patent-wise: yes
<bob2> yes, ubuntu cannot play encrypted dvds
<bob2> and probably never will be able to
<rob^> ok thanks.. just checking incase I had to change the faq
<ajmitch> rob^: bug various governments to let us
<rob^> (before freeze)
<rob^> ajmitch, yeah
<jsgotangco> start with au
<jsgotangco> and the other au state
<mvo> Mithrandir: that sounds like a bug in the notification-daemon. would you mind to file a bug?
<Mithrandir> mvo: willdo
<dholbach> morning seb128! :)
<mvo> Mithrandir: thanks
<pitti> Hi seb128
<pitti> Hey dholbach 
<dholbach> pitti: :)
<sivang> hey dholbach , pitti , seb128 
<pitti> Hi sivang 
<dholbach> hey sivang 
<ajmitch> hi sivang 
<sivang> hey ajmitch 
<sivang> ajmitch: 'sup ?
<ajmitch> sivang: package fixing :)
<sivang> ajmitch: cool, I need to let someone review my gnome-applets patch, lpi is almost all over the place :)
<ajmitch> heh
<sivang> jdub: I've forwarded you the reply I got from my IBM contact, let me know if this helps.
<pef> hi
<ajmitch> hi pef 
<pitti> Hi carstenh 
<dholbach> hey carstenh :)
<carstenh> hi pitti, hi dholbach 
<pitti> Kamion: will we get a new CD set today, or shall we go and mass-test  20050906.1 as preview candidate?
<pitti> well, no, that would miss some gnome packages
<daniels> pitti: security releases aren't automated at the embargo date, right?
<pitti> daniels: no
<daniels> pitti: good
<mvo> Kamion: is it too late for http://paste.ubuntulinux.nl/1972?
<daniels> tritium: cool, thanks
<tepsipakki> hmm, should the gnome-menu-names be translatable?
<tepsipakki> applications, places, system
<tepsipakki> I got a complaint from a colleague (fedora-fan) that the finnish translation is not complete, but he tried hoary and I'm now testing colony4-live
<tepsipakki> and gnome-2.12 should have 100% complete Finnish translation..
<seb128> hi pitti dholbach sivang mvo etc 
<dholbach> hehe :)
<seb128> mdz: around?
<mdz> seb128: yes
<seb128> mdz: gnumeric is not technically a part of GNOME but could we update from 1.5.4 to 1.5.5? Or after preview?
<mdz> seb128: but only for a short                     
<mdz> time
<mdz> seb128: after preview, yes
<seb128> mdz: btw we have GNOME 2.12.0 now, everything is uploaded
<seb128> k, thanks
<pitti> seb128: you rock
<mdz> seb128: excellent
<daniels> Kamion: damn your ability to discern the difference between the numbers 8 and 0
<infinity> seb128 : Poke me violently if any of it isn't building.
<torkel> seb128: is there any reason why gnome-screensaver is not compiled to look for xscreensaver hacks?
<mvo> mdz: if you have time (probably after preview) it would be nice if you could have a look at #14842 and tell me what you think about it
<seb128> torkel: because the focus is/was GNOME 2.12 and nobody spend some work on it to figure what to do for that
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with breezy) | #ubuntu for support and general discussion/ | #ubuntu-motu for getting involved in development | http://www.ubuntulinux.org/wiki/DeveloperResources | Colony 4 is released: http://cdimage.ubuntu.com/releases/breezy/colony-4/ | Preview blocker:  http://bugzilla.ubuntu.com/show_bug.cgi?id=14851 | https://wiki.ubuntu.com//HelpingWithBugs | MOM/NDA producing bad diffs
<seb128> infinity: thanks  according to the build logs everything is fine
<seb128> pitti, mdz: thanks :)
<mdz> mvo: we could revert the rename
<mdz> mvo: it was sort of pointless
<seb128> jamesh: ping?
<mvo> mdz: ok, that sounds good to me. shall I do that now or after preview?
<torkel> seb128: there is a configure option for it. Rodrigo Moya added support for it in 0.0.10
<mdz> mvo: after
<mvo> mdz: thanks
<seb128> torkel: I know, but I'm just too busy with GNOME 2.12.0 atm to work on this 
<torkel> seb128: k
<seb128> torkel: xscreensaver should be splitted too
<seb128> torkel: to make a -data package
<seb128> but that's for after 5.10
<Mez> mdz: out of curiosity: seeing as breezy is already in UVF ... when can we start doing breezy backports, and will we be able to keep abckportinhg to hoary too (through direct upload or similar)
<seb128> breezy backports ...
<daniels> breezy isn't even released!!
<seb128> what do you want to backport? there is no new distro
<infinity> Mez : Where would we backport them FROM?
<Mez> infinity: I'm on about after release when things start rolling for breezy +1
<Mez> (aka - after breexy+1 starts - how long is it going to take for the infrastructure to be shuffled wound ot allow backports for breexy)
<Mez> infinity: did you get round to bootstrapping mono for backports yet?
<dholbach> infinity: could you give gnome-cups-manager back?
<sivang> dholbach: are you going to work on #6224 ?
<seb128> mdz: maybe we want to consider the patch from #14579 before preview? 
<infinity> Mez : Ugh, no.  Been too busy with breezy work, sorry.  I have an email with detailed directions in my INBOX, right?
<Mez> should have
<Mez> I snt it 11 days ago
<dholbach> sivang: not yet - i'm updating a bunch of packages
<slomo> hi... do we have someone here who can help me with cvs? :) i need to checkout a whole repository with all changes until a given date
<bob2> this doesn't sound like an ubuntu-development question
<infinity> dholbach : Given back.
<seb128> slomo: man cvs, / "-D"
<dholbach> infinity: thank you
<slomo> seb128: thanks, i'll try :)
<ogra> bob2, convince elmo to close his april 1st bug to keep your pic in the screensaver :)
<mdz> seb128: it looks mostly like refactoring. what is the substance of the change?
<fabbione> hey mdz.. 
<fabbione> still awake?
<infinity> dholbach : Dude, fast-user-switch-applet tries to install files into the base system.  BAD.
<infinity> dholbach : See the failed build logs.
<mdz> Mez: backports for breezy should be possible in a similar timeline as uploads to breezy+1
<dholbach> infinity: updated it already, thanks
<mdz> fabbione: I spoke 20 seconds before you asked, so yes ;-)
<fabbione> mdz: well you might as well woke up earlier than usual _P
<fabbione> mdz: clearly i saw you are here...just surprised about the time ;)
<mdz> I am about to go to sleep
<fabbione> mdz: good night
<mdz> back in 7
<Mez> mdz: sweet - do we have a name for breezy+1 yet
<mdz> night
<fabbione> Mez: nonameyet
<Mez> fabbione: :P
<seb128> mdz: creating new group instead of using the existant one
<seb128> mdz: if you have several instance of the same apps (ie: opening several epiphany windows or nautilus windows), the differents windows should not use the action group
<ogra> night mdz
<seb128> s/the action group/the same action group/
<seb128> mdz: is that ok if I get an approval of jamesh on the patch too?
<sivang> seb128: discussing lpi stuff, or other interesting GUI issues?
<seb128> sivang: what?
<WaterSevenUb> mvo, is it ok to remove "ubuntu" reference in PT translation of .desktop file of "hwdb-client"? Otherwise is too long: "Base de dados de dispositivos Ubuntu" I think.
<\sh> morning
<ogra> WaterSevenUb, yup, thats ok.... 
<WaterSevenUb> ogra, thanks :)
<mvo> WaterSevenUb: yes, it will be removed upstream anyway (right, ogra?)
<ogra> WaterSevenUb, i'll do a de-branding upload after preview anyway
<\sh> grmpf.
<ajmitch> \sh: good morning ;)
<\sh> hey ajmitch 
<sivang> seb128: nothing sorry, I bursted into discussion. 
<WaterSevenUb> mvo, hhhmm.... GIMP is prepared for translation of .desktop through the POT file but that little necessary string is not translated in this file:-) The main template of GIMP is not available in Rosetta so ... one should be patient until it is or can I send an updated .po file?
<sivang> seb128: tell me how that looks? http://muse.19inch.net/~sivan/lpint/gnome-applets/ , if you need a debdiff as well, I will make one.
<mvo> carlos: gimp is not available in rosetta?
<carlos> mvo, don't know, It should unless it has any problem with the automatic imports
<mvo> WaterSevenUb: you could just update the pt.po file, does that sound ok?
<\sh> hmmm..is it normal, that evolution takes a century to realize that a network is not available anymore?
<Mithrandir> Kamion: ok to upload http://err.no/patches/siege_2.61-1_2.61-1ubuntu1_etc_siegerc_ftbfs.diff ?
<Lathiat> evolution sucks at thigns like that
<seb128> sivang: seems to be ok, but priority is on the CD for this week and GNOME 2.12 atm, I'll work on this later
<WaterSevenUb> mvo, well... it sounds ok to me if sounds ok to Carlos :)
<\sh> Lathiat: any workarounds? socket timeout adjustments or something? 
<carlos> WaterSevenUb, it's ok, Rosetta will get it with the next import
<Lathiat> \sh: yeh use thunderbird ;p
<Kamion> mvo: that synaptic change is post-preview now, I think
<mvo> Kamion: ok, thanks
<Kamion> Mithrandir: looks like post-preview
<Kamion> damnit, if I paid *attention* to my live CD testbed it would help
<dholbach> brb
<Mithrandir> Kamion: ok.
<Kamion> pitti: I doubt this morning's CDs will be final; we may get final ones out later today
<pitti> Kamion: ok, thanks; I test them anyway to check for other issues
* Kamion goes to apply quick-fix to ubuntu-artwork so it looks less silly
<Kamion> (the browser start page)
<daniels> Kamion: um, xorg -58 may be very, very helpful to have for preview
<\sh> Lathiat: ah know...when kmail ;)
<Kamion> daniels: yes, doors aren't quite shut yet
<\sh> s/know/no/ ,-)
<daniels> Kamion: okay, cool.  i think it should fix the most of these mysterious failed-to-create-config-file failures, although fucked if I know why they haven't been occurring since warty if the breakage I diagnosed is the root of all our problems (I just sledgehammer-fixed it).
<\sh> daniels: did u know about those xterm enhancements of SuSE? (u-bugs: #11316)
<daniels> \sh: that's why I assigned it to you ;) i don't really care too much about it, which is why I procrastinated fixing it
<\sh> daniels: well...he should send me those app-defaults to have a look...
<daniels> he did :P it's in the original submission
<daniels> *charClass:  33:48,37:48,43:48,45-47:48,64:48,126:48,95:48
<\sh> daniels: I know, but I'm lazy ;) I will include it and test it this afternoon..right now I'm too lazy ;)
<WaterSevenUb> mvo, what about firefox.desktop, ok to send too?:) 
<\sh> argl..whats up with my dsl
<doko> mvo: the avm capi stuff doesn't work for me well. On the combined card, I get the ISDN connection, but no DSL connection
<sivang> seb128: sure np, thanks. I'l ping you up if I do any changes to it until then. Regarding the CD - you mean testing the installer etc? 
<seb128> cf topic
<pitti> Kamion: initrd-tools fails to install on powerpc, which yields a nasty installer error; known issue or shall I file a bug?
<infinity> Why is the installer installing it at all?
<Kamion> pitti: the error message might say it's initrd-tools but it's lying
<Kamion> (which is because the alternatives involved losing translations)
<pitti> Kamion: the log complains that usplash was not found
<Kamion> heh
<Kamion> ok, will fix
<pitti> but I guess that's unimportant
<Kamion> that probably makes it fail
<pitti> Kamion: you know the cause? or do you need any logs?
<pitti> bootstrap.log doesn't actually look bad
<Kamion> I know the cause, fixing, thanks
<pitti> ok, great
<daniels> Kamion: the xorg change, while small, localised, and obviously correct to mine eyes, hasn't been *rigorously* tested, so if you could ping me when you have images so I can test, that'd be great, thanks
<jdub> GOOD MORNING FREEDOM LOVERS!
<pitti> Hi jdub
<dholbach> hey jdub 
<ajmitch> morning jdub 
<pitti> it's always refreshing to see you :-)
<bob2> jdub: plug in the webcame!
<ajmitch> a good jolt to wake us up :)
<jdub> bob2: ha ha
<jdub> bob2: didn't bring it
<bob2> jdub: bah
<jdub> but you are on the big screen at the sydney gnome release party :-)
<jdub> SAY HELLO
<bob2> jdub: I want to party vicariously
<daniels>  __  __ _____ _     ____   ___  _   _ ____  _   _ _____   _  _   
<daniels> |  \/  | ____| |   | __ ) / _ \| | | |  _ \| \ | | ____| | || |  
<daniels> | |\/| |  _| | |   |  _ \| | | | | | | |_) |  \| |  _|   | || |_ 
<daniels> | |  | | |___| |___| |_) | |_| | |_| |  _ <| |\  | |___  |__   _|
<daniels> |_|  |_|_____|_____|____/ \___/ \___/|_| \_\_| \_|_____|    |_|  
<daniels> 
<daniels>  _  __   _______ 
<daniels> | | \ \ / /  ___|
<daniels> | |  \ V /| |_   
<daniels> | |___| | |  _|  
<daniels> |_____|_| |_|    
<daniels> 
<daniels> er, whoops, thought this was a rather different -- significantly less on-topic -- channel.  sorry. :)
<daniels> but my point holds.
<pitti> daniels: "lyf"?
<daniels> pitti: ppl wot uze 4 r mre lkly 2 uze 'lyf' 2
<lifeless> rotfl
<pitti> daniels: 4h, 1 s33
<bob2>       _      _                _                            
<bob2>   ___| |_ __| |     __ _  ___| |_   _   _  ___  _   _ _ __ 
<bob2>  / __| __/ _` |    / _` |/ _ \ __| | | | |/ _ \| | | | '__|
<bob2> | (__| || (_| |_  | (_| |  __/ |_  | |_| | (_) | |_| | |   
<bob2>  \___|\__\__,_( )  \__, |\___|\__|  \__, |\___/ \__,_|_|   
<bob2>               |/   |___/            |___/                  
<lifeless> HELLO
<bob2>               _                         
<bob2> __      _____| |__   ___ __ _ _ __ ___  
<bob2> \ \ /\ / / _ \ '_ \ / __/ _` | '_ ` _ \ 
<bob2>  \ V  V /  __/ |_) | (_| (_| | | | | | |
<lifeless> ...
<bob2>   \_/\_/ \___|_.__/ \___\__,_|_| |_| |_|
<daniels> (what have I started.)
<bob2> 
<pitti> Hi lifeless, welcome to the channel of love
<lifeless> apparnetly :)
<shackan> what's up this morning ?
<lifeless> a party
<daniels> figlet
<dholbach> GNOME 2.12 - woohoo :)
<shackan> is it "let your 4 yo son play with the keyboard" day ?
<Mithrandir> jdub: ENOBEER!
<Mithrandir> (at least here)
<\sh> dholbach & seb128: congrats you rock :) 
<dholbach> \sh: thank you :)
<pitti> Kamion: I now get a question with a list of available kernels; is that just a consequence of the second try (after the failed first attempt) or a genuine new bug?
<marcin_ant> shackan, it's propably "let your 2 yo old doughter and 12 yo old son play with the keyboard" day ;)
<shackan> good morning marcin_ant 
<marcin_ant> shackan, yo
<marcin_ant> shackan, I'm up (at last)
<shackan>  I see
<pitti> Kamion: probably the former, so nevermind
<sivang> OMG, daniels what the hell? :)
<sivang> daniels: how do you make thos big letters?
<JaneW> bob2!
<bob2> janew!
<pitti> sivang: figlet
<JaneW> :)!
<daniels> bob2: clearly, the correct reponse is /exec -o figlet janew\!
<bob2> JaneW: better start work on your visa ;)
<sivang> hAPPY GNOME RELEASE DAY EVERYBODY!
<JaneW> I am, I am!
<JaneW> bob2: but I hear Canadian's are more welcoming of South Africans than Australians are :P
<JaneW> bob2: and the visa form is only 2 pages long (not *11*)
<bob2> JaneW: hey, I offered to smuggle you in a suitcase if claire gave me a round the world ticket
<JaneW> ;)
<bob2> clearly .au is 11/2 times more awesome than canadia
<daniels> yes, because clearly what all the Australians need is *more* time on a plane.
* JaneW makes note that thank claire
<jdub> seb128: did you see fer's releases?
<Mithrandir> blender is warn-o-rama
<spayne> seb128: i got the Clearlooks Metacity problem sorted
* hunger read about an author that answered "Is that still required?" when asked about a criminal record by an australian customs officer.
<spayne> ogra: i got the Clearlooks Metacity problem sorted
<ogra> spayne, what wa it ?
<ogra> was even
<spayne> ogra: I had to reinstall from Colony 4 - i think it was an Xorg problem
<spayne> ogra: as some other problems have gone as well
<seb128> jdub: on #commits only, is there any tarball somewhere?
<Kamion> hunger: making jokes with customs officers is strictly for those who don't actually mind whether they get into the country or not
<spayne> ogra: i think it was the Xorg installed with C3 that caused it
<seb128> spayne: what wasit?
<spayne> seb128: well, i don't actually know but i suspect it was Xorg because the system which had the latest packages
<spayne> seb128: transparencies didn't work and the metacity had this problem
<seb128> k
<spayne> seb128: but thanks anyway ;-)
<seb128> jdub: that's ok now
<\sh> daniels: this charClass is it: double-click and highlite, or mouse-hover and highlite?
<pitti_live> ogra: hm, it seems that thunderbird is not on the live CD; I thought it was?
<ogra> pitti_live, it is in ship
<Kamion> pitti_live: yes, the kernel question is a consequence of the debconf priority being dropped due to the earlier failure; not a bug
<hunger> Kamion: I fully agree... I never joke while in an airport. Not even about fellow travelers:-)
<Kamion> Hmph. I have a working live CD with most things happening on tty1 (yay) but for some reason X can't start (boo)
<pitti> Kamion: hm, which arch? I just tested amd64 and powerpc, both worked fine (modulo the shutdown vt issue)
<Diziet> If I ask the submitter of a bug for more information, I put the bug in NEEDINFO.  Should I also assign it to the submitter ?
<infinity> No.
<infinity> Unless you also expect the submitter to upload a fix.
<Diziet> Right.
<Kamion> pitti: i386; it works fine without my hacks
<Kamion> pitti: the shutdown vt issue is what I'm working on
<Diziet> Bugzilla really does encourage vacuous bug reports.
<Kamion> Grr, and when I turn on gdm's debug support it all works. I think it must be a timing thing.
<Diziet> I assume it's not rude to refer people to http://www.chiark.greenend.org.uk/~sgtatham/bugs.html.
<Kamion> not if done politely :-)
<Diziet> :-).
<daniels> Kamion: did you see the if (!first) suggestion for gdm?
<ogra> Diziet, also https://wiki.ubuntu.com//HelpingWithBugs
<jsgotangco> daniels, 2 X updates in less than 2 hours? im impressed =)
<Kamion> daniels: yeah, but it seems orthogonal to the thing mdz asked me to look at
<Kamion> ogra: isn't that for people doing bug triage, not for people reporting bugs?
<ogra> Kamion, its called helping with bugs ;)
<Mithrandir> Kamion: how do you feel about breaking UVF for blender?  it fixes the FTBFS.
<Diziet> HelpingWithBugs> Ah, useful, thank you.  Kamion: for me to read, not for the submitters :-).
<ogra> Mithrandir, ftbfs ? 
<daniels> Kamion: hmm?  it seems to wait until X has finished until gdm itself shuts down, which would presumably fix the problem ...
<Mithrandir> ogra: fails to build from source.
<ogra> Mithrandir, i know what that means...
<ogra> when blender entered edubuntu it built ? 
<Mithrandir> ogra: no longer
<Mithrandir> ogra: http://bugzilla.ubuntu.com/show_bug.cgi?id=14594
<daniels> Kamion: (if the problem is, as mdz says, gdm dies and switches to vt1, then X dies and switches to vt2)
<infinity> Failed during -autotest.
<Kamion> Diziet: ah :)
<Diziet> Those standard responses suggest to read a GNOME HOWTO which links directly to Gnome's bugzilla.  Surely this will result in misdirected reports ?
<Kamion> Mithrandir: I don't object, but after preview please
<ogra> Mithrandir, oh, ok ... if Kamion agrees...
<Mithrandir> Kamion: ok, post-preview.
<Kamion> daniels: yes, but I'm working on trying to make the startup sane (i.e. use tty1)
<Kamion> daniels: either approach would fix the problem, and ideally we'd do both
<Diziet> Do we have a `bugzilla helper' of our own ?
<Diziet> If not then our standard responses should probably refer to SGT's essay and not to the Gnome pages.
<Kamion> daniels: making the startup sane would mean that X would switch back to vt1 rather than vt2 which would resolve the clash with gdm
<ogra> Diziet, we want our own page one day... there was just nobody finding the time yet
<daniels> Kamion: right, which would be best from my angle at least
<daniels> Kamion: with my current, er, arrangement, I don't have time to be attacking complex and hairy bugs like this
<Diziet> ogra: Right.  Mind if I change the wiki page BugResponses to refer to SGT's essay instead of the Gnome one ?
<ogra> Diziet, please let this approve by mdz, he choose to link the gnome page there on advice of seb128_ 
<Diziet> ogra: OK.
<Mithrandir> Kamion: http://err.no/patches/unifont_1.0-1_1.0-1ubuntu1_builddep_ftbfs.diff ; ok to upload after preview is out?
<Kamion> Mithrandir: sure
<Mithrandir> Kamion: I'm just nagging you because mdz's mail to -devel said everything had to be approved; I can ask later if you get interrupted by it.
<ogra> Mithrandir, or collect a list to mail it ? ;)
<Mithrandir> ogra: bah, I don't like mail
<Kamion> Mithrandir: no, that's fine
<ogra> heh
<Kamion> I'm capable of ignoring IRC while working if necessary ;)
<mvo> is installing onto s-ata (with both p-ata and s-ata drives in the machine) supposed to work? it hangs here after the first reboot ..
<Kamion> infinity: what was the nature of germinate's conniption fit? (qt-x11-free)
<Kamion> at this point seed workarounds are probably better than uploads
<bob2> I cannot believe #1940 is still open
<Kamion> mvo: I believe that's one of the hard cases in hotplug
<mvo> Kamion: hm, do we have a open bug for it?
<Kamion> mvo: dunno, I know that at least some of those cases were fixed in hoary
<Kamion> isn't that what we held the hoary preview for, more or less?
<Kamion> infinity: is vernadsky hooker ross yellow still the right list of buildds for daily d-i builds?
<mvo> Kamion: hm, I think that was a different problem 
<mvo> (not sure though)
<mvo> Kamion: it looks like http://bugzilla.ubuntu.com/show_bug.cgi?id=1750 (but I didn't changed the bios between cdrom boot and install). it seems like grub always give hda -> (hd0) even if the bios boots from s-ata first :/
<Lathiat> mine says that too altho it works fine
<Kamion> mvo: unfortunately I know of no fix, and it's even more difficult without appropriate hardware; if you want to investigate that one, you're very welcome
<pef> a diff.gz of a source package contains autotools-dev stuff, can I do something ? (I'm packaging a new version)
<mvo> Kamion: ok, I'll have a look 
<Mithrandir> seb128_: you're probably already aware of it, but there's a new gnomemeeting out which should solve 11960
<seb128_> Mithrandir: new gnomemeeting requires a new pwlib which is not packaged by Debian yet. And I don't use it, so I don't want to push that now ... feel free to do it if you use them and are ok with the new versions
<Mithrandir> seb128_: I've used them in the past, at least, and that bug is at least marked as RC, so..
<seb128_> Mithrandir: how is it RC?
* dholbach is lunching and dogwalking after that...
<Mithrandir> seb128_: hence my "marked as RC" instead of "is RC".
<seb128_> yeah, but he's "major" with no milestone ... is that "marked as RC"? Anyway we will update gnomemeeting but after preview probably
<Mithrandir> seb128_: well, it's one of the bugs which show up when I click the "RC bugs" search in bugzilla.
<Mithrandir> seb128_: anyway, if you are on it and will fix in a bit, that's fine and I'll leave it to you
<tepsipakki> hmm, any idea why I get MD5Sum mismatch from Packages.gz on our mirror although the mirror was just synced and the sums are the same?
<tepsipakki> that's apt-get update complaining
<seb128_> Mithrandir: right, the RC query match "major" too. Feel free to tackle it if you want, that's fine with me. If you don't we will get gnomemeeting updated before 5.10 anyway, so it'll get fixed
<infinity> Kamion : That was just bringing back a patch that got dropped in the last QT upload.
<infinity> Kamion : And yes, vernadsky(i386), ross(powerpc), yellow(amd64), hooker(ia64) are the current DI daily machines.
<mvo> tepsipakki: are you behind a proxy/transparent-proxy?
<Kamion> infinity: thanks, I like to check from time to time
<tepsipakki> mvo: no
<infinity> Kamion : Anyhow, the QT upload should be harmless, it only touched control.
<infinity> Kamion : OTOH, germinate may have stopped fitting if we finally removed all the obsolete GL/GLU stuff from universe.  The previous uploads were operating under the assumption that we only want (primary) dependencies on the One True Mesa in main.
<Kamion> you said germinate had a conniption fit, I was wondering what it was
<Kamion> since we have some germinate workarounds in the seeds already
<infinity> Kamion : And Qt is the only package in main that's regressed since those fixes were uploaded.
<infinity> Kamion : It had connptions in the past.  TBH, I'm not sure if it still is having any.  (basically, bringing in more mesa stuff than we want, or trying to, because libqt3-mt-dev depended on old xlibmesa/*xorg* packages..)
<Kamion> ok
<tepsipakki> had to sync the mirror again, now it doesn't complain anymore..
<tepsipakki> let the installations roll ;)
<pitti> argh
<pitti> mvo: ping
<mvo> pitti: pong
<pitti> mvo: just doing a hoary->breezy upgrade test (insert breezy CD, click automatic upgrade)
<pitti> mvo: on upgrading libc6, I get the "Do you with to restart services" question
<mvo> Kamion: test-install of current daily on amd64 w. sata works here (modulo the grub problem I'm looking at right now)
<mvo> pitti: ok
<pitti> mvo: but I don't see it unless I open the terminal
<pitti> mvo: I had the terminal already open, though
<pitti> mvo: will this just block forever until the user opens the terminal window and presses Enter?
<mvo> pitti: hrm, right. it will open the terminal after ~30sec of no chnages on the terminal. but that's still pretty bad
<pitti> mvo: ok, but that's at least a good fallback; thanks
<pitti> mvo: much better than just sitting around indefinitely
<mvo> pitti: do you think we could use debconf for the prompting?
<pitti> mvo: it reacts to debconf?
<mvo> pitti: *ick*, the hoary version may not have the timeout-handling yet
<mvo> pitti: yes, it handles debconf with the gtk frontend
<mvo> much nicer indeed
<pitti> mvo: ah, ok
<pitti> mvo: so eventually we should convert the libc question to debconf
<Kamion> is attempting to use debconf at that point safe?
<Kamion> (not saying it isn't, just checking)
<Mithrandir> yeah, should be fine
<pitti> at that point, the new libc is already fully installed
<Kamion> k
<pitti> Kamion: hoever, the apt process itself still uses the old one
<Kamion> it still needs a fallback in case debconf is not installed, since libc6 is below debconf in the dependency chain
<pitti> but since debconf communicates over a socket, that shouldn't lead to problems, or should it?
<pitti> Kamion: hm, the fallback could just be to restart services (it's the default answer)
<Kamion> debconf communicates over stdio not a socket
<Kamion> and it is launched from the libc6 postinst
<Kamion> or would be, if you used debconf there
<pitti> anyway, I file a bug for later
<Kamion> as in, debconf will be started up effectively at the start of the libc6 postinst
<Kamion> and libc6.postinst will be run as a debconf confmodule
<mjg59> Kamion: So, I think we tracked down the problem with the missing sata drive
<pitti> jbailey: did you disable bz email? You should have been in CC for two bug mails, bug I always get "Excluding:  jbailey@ubuntu.com" on the confirmation page (#14889)
<jbailey> pitti: I've disabled it for ones where it's assigned to me.  It should send them when it's CC:'d
<jbailey> Which bug number?
<pitti> jbailey: ah, ok, then it's not a bz bug
<pitti> jbailey: #14889
<jbailey> Wow, 15k bugzilla mails.
<jbailey> Insane.
<jbailey> pitti: Basically with all the cc:'s and such, my email gets swamped making it useless, so I rely on queries to show me what's changed since the last time I looked at the list.
<jbailey> Order by last modified is sweet. =)
<jbailey> pitti: To quickly answer the question here (I'll do so in the bug mail as well), nothing in Debian's "base" can use debconf.
<zul> slacker
<jbailey> Since debconf itself is not part of base.
<pitti> jbailey: ah, right
<pitti> jbailey: but we could use it if it is already installed?
<jbailey> IF we don't have that constraint in Ubuntu, I'd love to convert it.
<lamont> jbailey: but if present, you could use it...
<Kamion> jbailey: (it's possible to use debconf optionally)
<jbailey> We could, but then it's two code paths to maintain.
<pitti> jbailey: basically we have the same, but we could check for it
<jbailey> We (the Debian glibc team) had decided not to do this in order to encourage people to put debconf into base.
<lamont> yeah, and 90% of the use would be down the debconf path, and get pre-prompted, etc,
<Kamion> debconf is in base, actually, even in Debian; it's just not in required
<jbailey> required, right.
<Kamion> and actually, with new debootstrap it moved into required, although it's not clear whether it will stay there
<jbailey> Exactly.  In practice it would be always used, which is sucky.
<Kamion> but having libc6 depend on it will always be sticky, no matter what
<jbailey> It's tempting to just add a depends on it, and let people slug it out on debian-devel. =)
<Kamion> I really don't think it's safe for libc6 to depend on debconf
<ajmitch> jbailey: no need to incite another flamewar
<Kamion> way too circular
<Kamion> that libc6 <-> libdb1-compat depends was bad enough
<jbailey> Kamion: I don't see how it's any worse than depending on grep, sed, or awk (all of which we do)
<Kamion> but debconf depends on a slew of other stuff
<Kamion> jbailey: debconf isn't essential; grep, sed, awk are
<jbailey> joeyh had suggested cdebconf
<Kamion> cdebconf isn't up to the task
<Kamion> not yet, at any rate
<Kamion> maybe one day, but don't hold your breath too long
<jbailey> Right.
<jbailey> So I'll put this hack into Ubuntu it you want, but it likely wont' go into the Debian apckage.
<Kamion> grep, sed, awk are all packaged such that they work while unconfigured
<Kamion> it's not so easy to do that with debconf
<jbailey> The solution so far for the installer was that it runs in non-interactive mode.
<Kamion> and in fact sometimes it will definitely fail while unconfigured (although it falls back relatively safely to other things)
<Kamion> worse, if you don't Depends: debconf, or if you have a circular dependency on debconf, you can't guarantee that debconf will be configured when your postinst is run
<jbailey> Right, it would need to be setup to work in an unconfigured state.
<Kamion> which can't be done at the moment because perl-modules doesn't work while unconfigured
<Kamion> at least, not across major perl upgrades; which is pretty much unfixable as long as perl-base/perl-modules/perl are separate packages (there's always a point where perl-base is at 5.8 but perl-modules is still at 5.6, say)
<jbailey> Right.
<jbailey> And cdebconf is too far away to get something useful out of it.
<sivang> Kamion: nice to finally look at garminate's code , and the funny readme there. 
<pitti> jbailey: ok, if it's not feasible, just close it; for the breezy->breezy+1 upgrade, the problem is mitigated anyway by the automatic console opening
<Kamion> cdebconf (a) has substantially lower code quality than debconf in many places; (b) is not nearly so well-tested; (c) has explicitly differing semantics in a few places (e.g. seen+backup handling); (d) isn't up to parity on frontend support
<Kamion> sivang: the README is Scott's, not mine
<Kamion> I've never got round to updating it
<jbailey> pitti: It's not that it's not feasible.  I just worry about the untested code path in the future.
<jbailey> AS I said, I'm willing to hack it for Ubuntu, I just likely won't put it into the Debian bits.
<jbailey> I'd rather spend the spare time trying to make cdebconf work and solve the problem properly.
* Keybuk can't even remember writing a "funny README" for it
<Kamion> 2004-04-24 01:20:37 GMT Scott James Remnant <scott@netsplit.com>        patch-3
<Kamion>     Summary:
<Kamion>       add README for LaMont
<Keybuk> yeah, I just don't remember it being a "funny" one
<jbailey> Kamion: Sure, but this is a sucky situation for other required packages.  Debian policy now has 'should' for the debconf requirement.  It needs to be made to work.  (which is why I say I'd rather spend my time in Debian doing so rather than hacking workarounds)
<Keybuk> though I guess my ordinary writing style could be considered funny by some ;)
<ivoks> daniels: ping
<Kamion> jbailey: of course, it's always fine (and preferable) for required packages not to prompt at all where they can get away with it. :)
<daniels> ivoks: mmm?
<ivoks> daniels: i need you for a second...
<daniels> ivoks: ...
<ivoks> daniels: one user told me that after installing hoary he got 1900x1600 resolution with 60hz refresh rate
<daniels> ivoks: right ...
<daniels> ivoks: let me guess -- amd64?
<ivoks> daniels: eh.. don't know arch...
<ivoks> daniels: will ask
<daniels> ivoks: that happens on amd64, it sucks
<ivoks> daniels: it's CRT, so 60hz is.. uhm :)
<ivoks> daniels: ok
<ivoks> daniels: thanks for your time and knowledge :)
<daniels> np
<daniels> time to make some soup to freeze and head to bed
<tepsipakki> is this the right place to ask about U. Foundation and it's funding?
<tepsipakki> my boss is a real ass(tm), and needs convincing
<tepsipakki> oh, pardon my language
<womble> tepsipakki: It's probably as good as place as any to ask.
<tepsipakki> ok
<pitti> mvo: did you see the mail on u-d about the untrusted language support packages? Does that problem really still exist? ("Problems during installing support for spanish language")
<Diziet> Is there anyone who would like an extra pair of hands to help with something ?  I'm running out of todo list ...
<Kamion> pitti: I was going to have a quick look at that today, but if somebody would like to check if that's reproducible that would be good
<pitti> Kamion: I try at my next install, I'm currently doing an upgrade
<lamont> pitti: if it's other than them hitting the window of a couple minutes every half hour...
<mvo> Kamion, pitti: I have seen it, I can try to reproduce it now
<pitti> mvo: I will also try, maybe it was really just a mirror race
<Kamion> (please fire stuff in Diziet's direction if you're overloaded!)
<pitti> Diziet: indeed I have something - you recently dealt with the dpkg conffile bug, right?
<pitti> Diziet: on upgrade, I still the the Xman question
<pitti> Diziet: (and Xmore, etc)
<pitti> Diziet: the patch hasn't been applied yet? or doesn't it work?
<Diziet> pitti: mdz decided it was too close to preview freeze to put it in.
<Diziet> I've tested it myself and it does make the questions go away.
<pitti> Diziet: ok, fine; will we see it for the final?
<pitti> cool
<Diziet> I'm certainly hoping so, but you'd have to talk to mdz :-).
<pitti> ok, thanks
<tepsipakki> well, on the press-release it is said that Mark made the initial funding, but what happens when that is spent, who or what is responsible for funding the Foundation?
<tepsipakki> (duh, took a while to write)
<bob2> emailing info@canonical.com might be simpler
<tepsipakki> heh
<pitti> sjoerd: ping
* Kamion wonders if he should attempt to suck Diziet into installer hacking in lieu of any other suggestions
<sivang> Kamion: in your scripts building images, does make -C britney/update_out expects the local mirror at /update_out ?
<Diziet> I'd be happy to help.
<Kamion> sivang: no, update_out's full of code
<Kamion> sivang: at least provided you built the arch config from configs/devel
<pitti> Diziet: do you happen to know about ethernet drivers? I got #14802 assigned for some reason, but I'm relatively clueless about it
<mvo> Kamion: is it a known problem that resizing a ext3 partition does not show a progress bar? I remember a bugreport about it
<pitti> Diziet: but nevermind if that is nothing for you
<mvo> ping mjg59 
<mvo> Kamion: thanks :)
<Diziet> pitti: I can try and debug ethernet drivers if you like; not that it's my specialist topic or anything.  Tell you what, I'll take the buck and see where I get.
<pitti> Diziet: this case is in fact a good use case for an "expert" list :-)
<Kamion> (https://bugzilla.ubuntu.com/buglist.cgi?keywords=installer&resolution=--- is the list of open installer bugs, FWIW.)
<Kamion> Mostly I need to fix up the OEM installer harder and do something with the various recently-opened partitioning bugs.
<bddebian> Morning
<pitti> Hi bddebian 
<Kamion> well, s/I need/somebody needs/
<bddebian> Howdy pitti
<pitti> Diziet: I think Kamion's bugs are certainly more important, though :-)
<Diziet> pitt: Did you ask on #ubuntu-kernel about that ethernet driver bug ?  It looks like the kind of thing that someone will have seen before.
<pitti> nope, I didn't touch the bug at all 
<Diziet> k: Blimey, what a buglist.
<bddebian> pitti: Is 7.5.8 gonna stay for postgre or will the default be 8 for breezy?
<ajmitch> morning bddebian 
<bddebian> Heya ajmitch.
<pitti> daniels: after hoary->breezy upgrade I get the dreaded "Do you want the X or Gnome keyboard settings" dialog
<Kamion> Things like #14204, #14236, #14564 are urgent to at least diagnose
<Kamion> Diziet: tell me about it
<pitti> oh, he is not here any more
<pitti> bddebian: "postgresql" is just a transition package; postgresql-8.0 is available in main
<pitti> bddebian: the transition package does a clean hoary->breezy upgrade, it is not suitable for installing from scratch
<bddebian> pitti: Hmm.  Well my problem is with building postgresql-plruby which depends postgresql < 7.5.  Am I safe with 7.5.8 or should I try to build with 8?  Or do you want to take care of it? ;-)
<Diziet> kamion: Some of those will require some to and fro with the submitters.  But I'm happy to take whichever of them you want rid of.
<sjoerd> pitti: pong
<Diziet> The NTFS one should be quite easy for me to reproduce here.
<pitti> mvo: when installing/upgrading without network, I only see "English" in the language selector, although there are more packs on the CD; known bug?
<pitti> mvo: ah, I suppose you check for "language-support-*" and not for language-pack-*"?
<mvo> pitti: yes, it checks what language are installable
<pitti> mvo: with CD only that is quite confusing
<mvo> pitti: IIRC it checks for both
<pitti> mvo: not for me
<bddebian> Any of you going to happen to look at Malone bugs too?  There are several main bugs on there also.
<mvo> pitti: right. what should it do instead?
<pitti> mvo: well, check for both pack and support and offer the installable ones
<pitti> mvo: for the missing support packages there shoud not be a checkbox, of course
<mjg59> Kamion: Does the installer actually include ahci.ko?
<mvo> pitti: ok, I'm doing a install without network right now and I'll check it then (in spanish, it looks "interessting" for me :)
<pitti> but at least I could install the translations
<pitti> mvo: I do a german installation at the next opportunity, to check for the auth bug
<bddebian> pitti: Are you ignoring me or do you just not want to answer that question? ;-)
<pitti> bddebian: sorry, was busy
<bddebian> pitti: NP.  I am just a nudge. :-)
<pitti> bddebian: you shuold not depend on "postgresql" in the first place; depend on the matching postgresql-X.Y version instead
<pitti> bddebian: since that is a server package, you need to build it for a particular server, or spit out packages for all available ones
<Kamion> mjg59: <cjwatson@riva /mirror/ubuntu/pool/main/l/linux-source-2.6.12>$ for x in *.udeb; do dpkg -c "$x" | grep ahci; done
<Kamion> mjg59: (i.e. "no")
<Kamion> <cjwatson@riva /mirror/ubuntu/pool/main/l/linux-source-2.6.12>$
<mjg59> Kamion: Ok. That may be our problem, then.
<pitti> bddebian: I recently did it for "plr", maybe you want to steal some ideas from it
<mjg59> Kamion: We should be including ahci, and ahci should be loaded before ata_piix is
<bddebian> pitti: Well "I" don't but the package does. :-)  OK, thanks.
<Kamion> Diziet: if you have an NTFS partition handy, you're certainly more than welcome to take that one
<pitti> bddebian: in any case server-side extensions need serious rework, or you limit them to build for one particular version (8.0 preferably)
<pitti> sjoerd: do you have a recent hal and dbus running on debian? does h-d-m react to new/removed devices?
<Kamion> bddebian: I think I've looked for installer bugs in Malone precisely once ever
<bddebian> Kamion: Well get to it. ;-)
<Kamion> mjg59: I assume that should go in usb-modules, like it sounds?
<Kamion> bddebian: main bugs should be filed in Bugzilla at the moment; then they will actually get to me.
<mjg59> Kamion: No, it's a SATA driver
<sjoerd> pitti: debian doesn't have python2.4-gnome2 yet, so i don't know
<Kamion> mjg59: oh, ok, sata-modules then
<bddebian> Kamion: I know but I have been trying to triage bugs on Malone and there are a TON of main bugs.
<pitti> sjoerd: ah, ok
<pitti> mvo: would you be fine to be the auto-assignee for language-selector, btw?
<Diziet> Aaargh, I hate bugzilla.  I edited the wrong bug.
<mjg59> Kamion: But then I don't know which one the installer will try to load first
<Diziet> Or did I ?
<Kamion> mjg59: it's up to hotplug
<Kamion> not the installer
<Diziet> No, bugzilla is just teleporting me away like it does and I'm unduly alarmed.
<elmo> Diziet: bugzilla has a habit of dump you into the next bug in the list of bugs you were looking at after you commit a change 
<mjg59> Kamion: Ah, right. Nngh.
<mjg59> Kamion: This is almost certainly going to result in pain
<Kamion> mjg59: can we tell the difference between machines that work with ata_piix and machines that don't by PCI id?
<Kamion> bddebian: I honestly don't have time to poll for bugs in a bug tracker that isn't properly set up yet to mail bug reports to the proper people
<Kamion> when it notifies me of my bugs, I'll pay attention to them
<mjg59> Kamion: No
<mjg59> Kamion: It's the same chip. It may be in one of two modes, depending on how the BIOS has programmed it and how it's wired up
<mvo> pitti: yes
<mjg59> ahci should always fail to load if it can't drive it
<mjg59> The same doesn't seem to be true of ata_piix
<pitti> Kamion: can you please set mvo as the default assignee for language-selector?
<mvo> pitti, Kamion: I can do this myself, give me a minute
<bddebian> Kamion: Understood, I am just frustrated with trying to understand what to do with those bugs.  I originally started moving them to bugzilla but it sounds like long-term goal is to use Malone anyway.  Just ignore me, I'm venting. :-)
<pitti> mvo: oh, we can do that? how?
<ogra> pitti, s/we/mvo/
<Kamion> Diziet: (I'm assuming you meant to assign #14236 to you, so did so)
<pitti> ogra: ah, nice
<sivang> mvo: saw my addition tho the bug report about adding languages?
<mvo> pitti: I asked mdz for various default assignement and he gave me compedit :)
<ogra> pitti, he's privileged :)
<Diziet> k: Yes, so I see.  Bugzilla was just confusing me gratuitously.
<mvo> sivang: yes, haven't had time for it yet
<pitti> ogra: /me bows :-)
* mvo keeps forgeting where the bl*** options are found in bz
<ogra> pitti, me too for our new upcoming bugmaster *g*
<\sh> ogra: bddebian? ,-)
* mvo runs ... fast
<ogra> \sh, mvo :)
<ajmitch> ogra: you're handing it over to mvo ?
<ogra> ajmitch, yup... done...
<sivang> who is our new bugmaster?
<ajmitch> yay, someone else to bug ;)
* mvo points with his finger to dholbach
<\sh> ogra: let bddebian do it ;) he knows now malone and how to triage and he will understand bugzilla afap
<mvo> pitti: spanish install (without net, cd-only) worked without problems here, I'll answer the mail now
<ogra> mvo, perfect !
<pitti> mvo: ok, then that's certainly a mirror race then?
<pitti> mvo: oh, wait
<pitti> mvo: I thought this occurred when downloading language-support-en? so, with network?
<pitti> mvo: s/en/es/
<bddebian> Hey, what am I getting volunteered for now?? :-)
<mvo> pitti: one problem may be a non-working network in stage2 (but a working one in stage1). this can lead to trouble like this
<mvo> pitti: hm, I recheck
* ogra doesnt have this with edubuntu
<bddebian> lamont: ping
<Kamion> mvo: could be related to the recent bugs about wireless configuration not getting carried over
<mvo> Kamion: that sounds plausible. one problem is that a failed apt update will result in broken signatures :/
<infinity> mvo : Which sucks, BTW.
<infinity> mvo : Do you have a handle on a way to work around/fix that?
<infinity> mvo : fe: download all lists to a tempt directory, verify them, and only move them in place if they verify?
<elmo> hey did you guys see the bug lars reported on apache in debian about it mangling Releases.gpg?
<Kamion> Does anyone here have a system that exhibits #13250?
<infinity> elmo : I did, but I haven't had a chance to look at/verify it.
<bddebian> Damn, I had a question for infinity about a Malone bug but now I can't remember the package. :-(
<infinity> bddebian : php4, adding gdbm support?
<infinity> (It's the only Malone bug assigned to me, afair, so that's a fair guess)
<\sh> Kamion: I had this behaviour only one time: when my harddrive was changed and it wasn't connected properly ;)
<infinity> elmo : mod_magic_mime is weird voodoo.  But adding control chars to the headers is probably not intended. :)
<bddebian> infinity: Yeah, is that fixed?
<\sh> elmo: can you please sync kxdocker-data (0.12-1) from debian unstable, thx (universe)
<infinity> bddebian : No, it'll be fixed in the next Debian upload, and I'll sync it.
<elmo> infinity: oh is it not something enabled by default?
<infinity> elmo : No.
<bddebian> infinity: OK, thanks
<bddebian> elmo: Not to bug you, just asking.  Do you know if my key made it to keyring@ ?
<elmo> infinity: oh, whine, I Was hoping it was the source of all our mirror out-of-sync problems ;-)
<elmo> bddebian: I'll let you know when it is
<bddebian> elmo: OK, thx
<elmo> \sh: done
<Kamion> \sh: probably a different bug then
<\sh> elmo: thx :)
<\sh> Kamion: yeah...the controller can't give the correct HD data to the kernel...hardware bug
<Kamion> \sh: not all partitioner failures are #13250. :)
<infinity> elmo : mime_magic shouldn't be enabled by default anywhere.  It's scary voodoo that uses file(1)-style heauristics to guess mime-types.
<infinity> elmo : Which is hell on CPU load, among other things.
<mvo> infinity: I have a fix that will just reverify the indexes after a failed/partial download. 
<infinity> elmo : So, I doubt many mirrors would be anabling it.
<\sh> Kamion: as I said :) the issue is the same..but the source of the problem was something else...
<torkel> ogra: ping?
<ogra> torkel, pong ?
<infinity> elmo : However, "weird mirror sync issues" could be caused by people doing rsync runs that ignore timestamps.  daniels was doing that on our local mirror here, which breaks horribly, since Releases will almost always have identical file SIZE but new timestamps.
<torkel> ogra: guess you know what I'm going to ask... :-)
<infinity> elmo : Funny how those hashes are always the same length. :)
<ogra> openafs ?
<torkel> ogra: yeah
<torkel> ogra: any news?
<ogra> torkel, i had no time to testbuild it yet...
<elmo> infinity: duh
<torkel> ogra: ok. A sync from unstable should be enough, but I guess you want to do a build it yourself?
<infinity> elmo : "duh" all you want, but he must have got the idea from somwhere, and I doubt he's the only one who does it. :)
<ogra> torkel, i want to be sure it builds
<Diziet> kamion: If I say `go back' in the partitioner, it seems to do the same as `done setting up the partition'.
<mvo> Kamion: is there anything I can do to help you with #13489?
<torkel> ogra: I does. I have been running a local build of it for almost two weeks. (including running the kernel module with 2.6.12-8)
<Kamion> Diziet: the alternative, presumably, being "Cancel"?
<torkel> ogra: and I'm currently rebuilding it in a pbuild, just to verify that i builds
<torkel> not that I'm sure that I'm trustworthy enough...
<Kamion> Diziet: I think that's arguably fair enough; it's a dialog that instantly applies its changes in several cases (e.g. when you're resizing)
<Kamion> although partman does have provision for cancelling operations
<Diziet> kamion: There isn't a `cancel'.  That looks like the cancel button but it doesn't do what cancel normally does.
<Kamion> mm, I can see your point
<Kamion> at the moment you have to explicitly undo changes from the main partman display
<Kamion> but a more fine-grained per-partition undo would be useful
<Lathiat> err
<Lathiat> anyone ever seen sudo refuse to work because you adjusted yoru clock too far into the future?
<Lathiat> i synced mine to the right time not it just says "timestamp too far in the future" whenever i try to do anything
<Diziet> I don't mind whether it actually has a cancel, but it shouldn't have a button that looks like cancel but doesn't.
<ogra> nope, only if no hostname is set
<Lathiat> hostname is fine and even if thats buggere dup itl still work it just whinges lots
<Lathiat> well.. this is usefull
* netjoined: irc.freenode.net -> kornbluth.freenode.net
* netjoined: irc.freenode.net -> kornbluth.freenode.net
* netjoined: irc.freenode.net -> calvino.freenode.net
<infinity> Lathiat : In case the netsplit ate my response, "try sudo -k"
<Kamion> Diziet: ok, it ought to be reasonably straightforward to disable backup for just that screen; could you file a bug on partman and I'll do that after preview?
<Diziet> Did you see my comment about the partition listing, too ?
<Kamion> No.
<Diziet> > Also, the main screen has a `go back' which does something different to `undo' (= cancel) and `finish partitioning' (= confirm).  I think this is likely to be at odds with most users' mental model.
<Diziet> > (by main screen I mean the list of partitions)
<Diziet> (Why are we using this shit-for-brains network anyway?)
<sivang> now when I tak on bugs, do I assign them to myself in launchapd or in b.u.c ? (for example, main bugs)
<Kamion> Diziet: hmm, yes, backup in the whole of partman is pretty screwed and it could probably stand to be disabled there as well (although I'll have to check the exact details).
<Diziet> I'll file a bug :-).
<Diziet> In the ubuntu bugzilla ?
<\sh> pitti: can u elaborate in a couple of sentences how the export of rosetta is working? and if it's possible to import .po files in rosetta ?
<Diziet> Weird.  This NTFS partition shows up, with a mount point, etc., but when I select `Use as', NTFS isn't one of the options.
<Kamion> The first half of the bug you mentioned is common to both Debian and Ubuntu; the second half may be partly Ubuntu-specific - so yes, the Ubuntu bugzilla's best.
<pitti> \sh: in principle, rosetta will export a big tarball with all translations (optional: ... that changed after date X)
<pitti> \sh: langpack-o-matic (a collection of scripts) will take this tarball and generate the language-pack-*[-base]  packages from that
<pitti> \sh: however, the exported tarballs still have some flaws
<\sh> pitti: what if there are already translated things (so .po files are existing in the upstream code), is it possible to import .po files?
<pitti> \sh: you imnport po files to Rosetta for ages, BTW
<pitti> \sh: Yes, Rosetta will merge them
<Kamion> NTFS is a hard case, I think, since we don't know how to format it, so we can only offer it in "use as" if it's already NTFS
<\sh> pitti: then there was a bug today ,-)
* Kamion greps. Hmm. I'm surprised nobody's reported that before, as there doesn't seem to be any support in partman for displaying it properly
<Kamion> Sweet! My fix for #14851 works fine now.
<pitti> Kamion: congrats, nice to hear
<Diziet> kamion: Indeed.  I suspect that this is where some of the problem is coming from.
<Kamion> Diziet: I think we'll need to add support for ntfs to partman-basicfilesystems, cribbing from its existing code for ext2 and fat, and making sure that the valid_filesystems/ntfs script doesn't print anything when given the argument 'formatable' (sic)
<Kamion> that would hopefully be sufficient ...
* Diziet finds http://wiki.debian.net/?DebianInstaller.  Ah, excellent.
<lamont> bddebian: si?
<bddebian> lamont: Sorry man, can you please check geomview
* lamont goes to look at people.u.c/~lamont/buildLogs/Lists/breezy.all.*
* lamont --pretend-avail's xlibmesa-gl-dev again
<lamont> you know, if the debian package has xlibmesa-gl-dev in it's build-depends, you can just upload the -ubuntu1 version without bothering with the sync, right?
<lamont> (making sure that you use the debian .orig.tar.gz, of course
<bddebian> lamont: The ubuntu1 version should be using libgl1-mesa-dev
<lamont> right.
<bddebian> lamont: I didn't sync that one
<lamont> ah, ok
* lamont withdraws his whacking stick
<mjg59> elmo: Haha
<bddebian> I synced stellarium only because -3 fixed an gcc4 build failure
<Kamion> mdz: please merge colin.watson@canonical.com--2005/casper--vtfix--0
<mjg59> elmo: I was wondering why Bruce had suddenly gained a London phone number
<Kamion> mdz: (I've uploaded that)
<bddebian> Hello sabdfl
<mjg59> sabdfl: Having fun?
<sabdfl> busted
<mjg59> Haha
<silbs> mjg59: we all enjoyed it
<sabdfl> we're pretty much in hysterics over here
<mjg59> You had me going for a bit
<Keybuk> didn't they split up? :p
* bddebian is lost as usual
* Lathiat too
<Keybuk> bddebian: me too, I wouldn't worry about it
<infinity> Kamion : Speaking of NTFS, after preview, I'd like to get a newer ntfstools in and stress-test it to hell and back.
<infinity> Kamion : Our version is a bit crusty, and the Debian maintainer seems to have recently woken up from a deep slumber and uploaded newer stuff to sid.
<bddebian> heh
<pitti> Kamion: time for new images then?
<sabdfl> mjg59: you denialist, we totally had you hooked
<mjg59> sabdfl: Haha
<sabdfl> did I not hang up the phone properly?
<bddebian> WTH is C++abi2-dev ?
<mjg59> sabdfl: No
<sabdfl> oops
<mjg59> sabdfl: You said "It was good to get to speak to you" and then elmo exploded
<sabdfl> i pressed a button, we thought we'd hung up
<Kamion> pitti: soon, yeah
<mjg59> Haha
<sabdfl> great site, btw
<dholbach> re
<mjg59> Of course, it's entirely plausible that I /will/ get a phonecall from Bruce...
<sabdfl> more likely ian
<Kamion> oh man, you used a speakerphone for a troll call? :)
<Keybuk> has mjg59 been blogging again?
<HiddenWolf> It's so nice to be out of the loop. ;)
<sivang> HiddenWolf: indeed :)
<mjg59> Keybuk: www.dccalliance.biz
<HiddenWolf> Lost connection to MySQL server during query in /home/osnews/web/connect.php on line 11
* HiddenWolf grins
<sivang> sabdfl: yo, 'sup? what is this all about? :-)
<sabdfl> Kamion: well, wanted the rest of the office to hear both sides. but then cocked up the hangup.
<Kamion> mjg59: score
<jdub> wow. .biz.
<sabdfl> sivang: just fun and games
<sivang> sabdfl: hehe :) and the talked Bruce, is Prens presumably
<sabdfl> i can't wait for dcc.xxx
* mvo is away for a bit
<sivang> ops I think I misspelled his name
<jdub> mjg59: ha ha ha
<jdub> mjg59: nicely done
<ogra> *grin*
<jdub> nicely as in evil
* sivang smells world takeover
<Diziet> mjg59++
<Keybuk> I'm so glad I put down my drink before I read that
<Keybuk> mjg59: you are a very bad man
<\sh> mvo: ping where is "Translate this Application" from launchpad integration translated? ,-)
<sivang> \sh: which app?
<\sh> sivang: firefox
<sivang> \sh: oh :-)
<sivang> \sh: not yet imported in I think
<\sh> sivang: is it translated in ff for ff or it's globally translated for the launchpad integration stuff?
<sivang> \sh: sorry? 
<\sh> sivang: I think this string "Translate this Application" is inside of the launchpad integration libs
<sivang> \sh: it is
<sivang> \sh: what do you want with it?
<\sh> sivang: and not related to one application like firefox...because I have it in every app
<sivang> \sh: sure, that's was the main design goal :)
<\sh> sivang: there was a question from a upstream dev, where those things are translated..
<sivang> \sh: in the launchpad integration translation domain
<\sh> ok..
<sivang> \sh: sorry, in the lpi helper lib translation domain
<sivang> \sh: so if it will appear in launchpad eventually, it would probably fall under the translation page of pkg "liblaunchpad-integration" or something similar
<\sh> sivang: good :) sounds promising :)
<sivang> \sh: it is , actually it sets the grounds to add any menu item we want from a central location, after the application have been patched with it. the actions themselves are controlled from the helper lib.
<\sh> sivang: yeah..I'm implementing it later this evening in gajim ;)
<elvirolo> hi all
<bddebian> Hello elvirolo
<elvirolo> is it a known bug that the network settings cannot be changed (in kcontrol) ? if I change the settings from dhcp to static IP, for instance, and then apply the settings, it goes back to dhcp
<sivang> \sh: is it universe pkg?
<sivang> \sh: in any case, if you need help, let me know
<Lathiat> hrm is it just me... or does PPPoE no longer bring up the interface it wants to use
<\sh> sivang: 1) yes universe 2) I had a talk with mvo how to integrate it nicely in python :) not a big issue i think
<Lathiat> and it did in hoary
<sivang> \sh: ah nice, so you're using the python bindings.
<\sh> sivang: yeah..gajim is a jabber client in python :)
<sivang> \sh: cool :)
<\sh> sivang: Nafallo and I are working on it together with upstream to get it into main for breezy+1 ;-) and it's a base for doing some really nasty stuff together with shtoom ;)
<\sh> sivang: lets say: if Google comes asap with a XMPP JEP for SIP Signalling then we can merge two application into one :) 
<sivang> \sh: ah, nice, shtoom is for Voip right? 
<\sh> sivang: yepp
<sivang> \sh: as for the other buzz words, I don;t know any of them apart for maybe SIP :)
<\sh> sivang: I mean we're here completly alone, so I can reveal my plans here without revealing any secrets: Nafallo and I are planning the World Domination ,-)
<sivang> \sh: ok ok, but what are XMPP JEP ?
<sivang> \sh: sorry for my ignorance, but i's rather wide..:)
<\sh> sivang: standards for IETF XMPP Protocols...they are proposals
<sivang> \sh: ah, so you're taking me in the recursive acronym definition, aren't ya? :-)
<Nafallo> hmm
<Nafallo> xchat needs gpg-support ;-)
<sivang> Nafallo, \sh : kidding + tired
<\sh> sivang: Extensible Messaging and Presence Protocol (XMPP)
<\sh> sivang: that's the protocol behind jabber 
<sivang> \sh: I see, that will be very nice then. This is already a breezy+1 goal? (I wasn't aware that we had started setting up goals for that)
<dholbach> infinity: do i get  http://people.ubuntu.com/~lamont/buildLogs/Test/Lists/  right? there are currently 1061 packages test-built and >95% built nicely?
<\sh> sivang: well...ShtoomVoip was a breezy goal and defered to breezy+1
<\sh> sivang: I took it over from thom
<\sh> sivang: so it will stay for breezy+1 and I hope I get a running environment for it in a short time...
<lamont> dholbach: it's like this:
<lamont> Total 27 package(s) in state Building.
<lamont> Total 14 package(s) in state Dep-Wait.
<lamont> Total 2 package(s) in state Failed.
<lamont> Total 1016 package(s) in state Installed.
<lamont> Total 2 package(s) in state Uploaded.
<lamont> Total 1061 package(s)
<Lathiat> \sh: i'd consider using gnomemeeting now that it has SIP
<pitti> seb128_, dholbach: do you plan a poppler sync with Debian soon, or a normal upload? I'm asking because of #14524; it's easy and no big deal, and does not warrant an extra upload
<dholbach> lamont: yes, that's where i got my information from
<Lathiat> \sh: shtoom has some nasty problems, like 2second audio delay on intel laptop sound chipsets
<lamont> 27 failures (since the buildd's are basically done), 14 packages that depwaited... if they aren't also dep-wait in breezy, then that's a failure too.;
<\sh> Lathiat: no...shtoom is python so it was sabdfl idea ;) 
<Lathiat> \sh: sure, but it sucks
<Lathiat> gnomemeeting doesnt suck
<lamont> 2 packages that were marked failed, and 2 that failed to make it into the archive --> bad packaging
<\sh> Lathiat: no it's working at least with my voip provider ;)
<seb128_> pitti: I've uploaded poppler today ...
<Lathiat> \sh: the ui is horrid, i get  2 seconds audio delay on both my laptops which makes it useless, its prone to randomly dying
<pitti> seb128_: synced with Debian?
<Lathiat> i mean i'd like to see it work nice...
<bddebian> lamont: Can you make a list so I can check if any are mine?
<\sh> Lathiat: the UI we will take care about it
<lamont> dholbach: for that list, Failed --> not ours --> arch not in arch list
<seb128_> pitti: no, but do we care about this bug? I would close it
<Lathiat> the audio delay is the killer.. i was chatting with one of the devs and they have no idea
<pitti> seb128_: as I said, it's not a big deal
<\sh> Lathiat: thats alsa 
<lamont> bddebian: http://people.ubuntu.com/~lamont/buildLogs/Test/Lists/breezy.all.i386 is the list
<bddebian> Oh
<Lathiat> \sh: sure, but it needs to work..
* bddebian feels stupid as usual
<pitti> seb128_: just wanted to know whether there was a pending upload, but ok; I downgrade it
<seb128_> pitti: close it
<dholbach> lamont: so the rest is yet to come
<\sh> Lathiat: yes...and it depends on python-alsa stuff
<lamont> but with only 1061 packages, you'll find that there are no universe packages there...
<Lathiat> \sh: so python-alsa sucks?
<seb128_> pitti: we don't care, it's transitionned on all arch and we will sync later, no need to keep bugzilla noise
<pitti> seb128_: ok
<mpt> \sh / Nafallo: Will either of you be at UBZ?
<\sh> Lathiat: all codecs are plugged into shtoom 
<lamont> dholbach: only 1061 source packages exist in that archive --> universe wasn't imported yet, and probably won't be until post-preview release
<dholbach> lamont: i thought there 'd be some heavy complete rebuild action going on
<\sh> mpt: if I can get a sponsorship I hope yes
<dholbach> lamont: i see - thank you :)
<\sh> mpt: if not, I hope nafallo can go
<Lathiat> \sh: and if so, what can be done about it?
<\sh> Lathiat: kick upstream for python-alsa ;9
<lamont> dholbach: with 3 buildd's per architecture, it goes pretty fast, but they all take 30 packages or so at a shot, so it can slow down the throughput of a single (critical for preview release) package if they're chunking through a full universe rebuild.
<lamont> of course, that's just my guess...
<bddebian> Heh, none of them are mine :-)
<dholbach> lamont: sounds reasonable
<lamont> bddebian: if you drop the "Test/" from that, then you get the real archive status
<lamont> and, of course s/i386/$whatever/
<lamont> :-)
<Lathiat> lamont: is it possible to restrict it to 2 of the 3 or something?
<lamont> Lathiat: there are several main packages that take hours to build.
<lamont> but yes, it would be possible
<\sh> Lathiat: but we will work closely with `anthony and the other guys from shtoom together
<lamont> just annoying
<Lathiat> \sh: ok well i'd love to see it work, if i can be of any assistance on that audio problem.. be good to get it solved.
<Nafallo> \sh: you know I can't go to UBZ
<bddebian> lamont: What are you trying to say? ;-)
<Nafallo> :-/
<lamont> bddebian: many of your questions to me of late could be answered by looking at p.u.c/~lamont/buildLogs/Lists/breezy.all.*
<lamont> with the knowledge that bad dep-waits don't clear automatically, and that packages marked Building are either Building or Failed.
<lamont> (in fact, that's how I've been answering them....
* lamont really needs to write up a page on interpretting wanna-build list output
<bddebian> lamont: OK, sorry, I'll do my own looking from now on.
<lamont> bddebian: I don't mind the occasional question, so no big deal
<jdub> seb128_: ping
<seb128_> jdub: PONG
<jdub> seb128: hey - have you built fer's latest releases?
<jdub> not worried about packages, just whether you've built them or not
<\sh> Nafallo: ah yes...
<\sh> Nafallo: I forgot
<\sh> Nafallo: so we have to find a backup ,-)
<\sh> ogra: ;)
<seb128> jdub: they have been packaged/uploaded yep
* Nafallo looks for sbackup ;-)
<seb128> jdub: you want to force them for 2.12.0 without doing a build with them? :)
<\sh> or i have to win a price in the lottery asap ;)
<bddebian> \sh: :-)
<jdub> seb128: yes, wanted to konw if they've been tested
<dholbach> jdub: what do you think of us - building is ok... but testing???
<bddebian> lamont: Is there anyway to tell when these were submitted? I.E. torcs is Dep-Wait?
<lamont> sigh... what did dpkg --print-gnu-build-architecture turn into?  Keybuk ?
<lamont> bddebian: well, sorta..
<lamont> buildLogs/t/torcs contains a directory-per-version.  The hightest version number (not alpha sort, dpkg order...) will be the last time the package was tried...
<lamont> dep-waited packages are never tried until the dep-wait is cleared (either by the package arriving in the archive, or me pretending it's available)
<seb128> jdub: you are rolling GNOME 2.12.0 yourself ?
<jdub> seb128: just checking for the GNOME release
<elmo> mvo: did you have any luck  diagnosis silbs stuff?
<elmo> s/stuff/upgrade problems/
<tseng> jdub: are we there yet?
<mvo> elmo: yes, we fix it after preview
<seb128> jdub: k
<jdub> tseng: on the way
<mvo> elmo: #14842 (if you are interessted)
<bddebian> lamont: Can't be. buildlogs/t/torcs says ubuntu2 and the Dep-Wait is on ubuntu4.  Or am I confused again?
<lamont> bddebian: new uploads of a dep-waited package are _NOT_ even tried --> no log
<lamont> so ubuntu2, if you look at the log, will show that it failed for want of the dep-waited package.
<lamont> dep-wait target, rather
<lamont> so -ubuntu3 and -ubuntu4 have never been tried.
<bddebian> Ahhh
<lamont> if your upload fixed the bad build-dep, then you have to poke lamont/infinity to get it cleared.
<bddebian> I don't remember which revision I uploaded at this point, that was ages ago. :-)
<lamont> bddebian: OTOH, if it really does need that package before it builds, then fixing said package so that it finally arrives in the archive will automatically release torcs for building.
<elmo> mvo: ok, cool, thanks
<elmo> mvo: btw the bug doesn't mention synaptic
<elmo> mvo: which also has the problem, and synaptic's the default PM (right?)
* lamont finds a really neato breezy-autotest "successful" failure.
<lamont> dpkg --contents xaw3dg_1.5+E-8_i386.deb | grep -v usr/share
<lamont> drwxr-xr-x root/root         0 2005-09-07 10:07:39 ./
<lamont> drwxr-xr-x root/root         0 2005-09-07 10:07:39 ./usr/
<lamont> drwxr-xr-x root/root         0 2005-09-07 10:07:38 ./usr/X11R6/
<lamont> what's wrong with that picture? :-)
<mvo> elmo: it's really a bug in the dist-upgrade code in apt, the "correct" package would be "libapt-pkg" or something like that. but I can add that info too
<bddebian> lamont: Well plib1.8.3-pic isn't in the archive, it's replaced by 1.8.4-pic so what do I need to do?
<jdub> lamont: the date, clearly.
<elmo> mvo: I don't mean the package so long as your description; but I don't mind, as long as you're aware :)
<lamont> jdub: I was kinda hoping the package would contain a .so and such, you see.  So were all the packages that Build-Depend on it...
<lamont> bddebian: assuming that the package doesn't build-depend: plib1.8.3-pic, you poke me to pretend that plib1.8.3-pic is available.  which I will now do.
<mvo> elmo: I added a short comment, but the fact that apt/synaptic<->aptitude use different dist-upgrade algorithms gives me a headache since some time now, so I won't forget :)
<lamont> bddebian: done
<elmo> heh, ok
<ogra> Kamion, is making my ltsp-client-builder udeb depending on archive-copier ok as i understand the udeb order in the installer is done via dependencys ? 
<ogra> Kamion, if i'm wrong, how do i make sure the udeb gets installed while the CD is still mounted ?
<Keybuk> lamont: dpkg-architecture ...
<Diziet> lamont: Dammit, does no-one know about `set -e' any more ?
* Diziet reads stuff in partman.  No, it looks like not.
<\sh> elmo: ping -> legal question regarding debian packages distributed-net (http://packages.debian.org/unstable/misc/distributed-net)
<\sh> or anyone else with legal background ;)
<mjg59> \sh: Yup?
<elmo> don't trust him
<\sh> mjg59: are we allowed to distribute this package as well, or is it debian only?
<elmo> he's with the dccallaince
<\sh> because there is a note in the debian/copyright file
<elmo> \sh: we can't distribute stuff with a license specific to debian
<elmo> I excluded a bunch of stuff from the initial non-free import for that reason
<\sh> elmo: ahhh...thats why gkrelldnet is in ubuntu but distributed-net as install-dep not
<\sh> hmmmm...
<Diziet> What I really need is a dvd of the breezy preview to prime my local mirror.
<Diziet> That is, one including universe.
<Kamion> ogra: that sounds inappropriate; use XB-Installer-Menu-Item in your control file as well
<mjg59> \sh: Doesn't look like it
<Kamion> ogra: er, "as well" -> "instead
<Kamion> "
<ogra> Kamion, thanks :)
<mjg59> elmo: Hater
<Kamion> Diziet: partman's sh use is generally abysmal, much worse than the rest of the installer
<\sh> elmo/mjg59: do u think we can get an acknowledgement from upstream for including it? or is it at all against the ubuntu copyright policy?
<ogra> Kamion, but that means my template file has to have a menu entry etc, right ? 
<Kamion> ogra: just make sure it's before prebaseconfig
<ogra> oki
<Kamion> ogra: yes, "Build LTSP chroot" should be a step in the main menu
<ogra> oki
<Kamion> ogra: feel free to run the source package past me when you have something to show
<ogra> Kamion, any cool way to test it without an extra build ? 
<elmo> \sh: you could if you want - but is it really relevant these days and/or worth spending time on?
<lamont> Keybuk: thanks
<lamont> Diziet: heh
<ogra> Kamion, i'll have, tonight
<\sh> elmo: if it's my will I could send gkrelldnet to the morque ,-)
<Diziet> -anarres:work> find partman-* -type f | xargs egrep -l '^#! ?/bin/sh$' | xargs egrep -L 'set -e' | wc -l
<Diziet> 151
<ogra> Kamion, s/build/cdbuild
<Kamion> ogra: it's a bit awkward for udebs containing templates
<\sh> elmo: cause a package which is not installable is a foobar package imho
<Kamion> ogra: you can modify a CD image locally to add your udeb, and boot with anna/choose_modules=ltsp-installer (or whatever)
<HiddenWolf> seb128, ping
<ogra> Kamion, ok, thanks...
<Kamion> Diziet: just don't start looking at shell quoting in partman :-/
<mdz> morning
<ogra> Kamion, err, all udebs i have looked at contain debconf templates 
<Kamion> elmo: could you switch dists/breezy/Release to say "Preview", please?
<mjg59> jbailey: Did you have a chance to think about the USB/hibernate interaction?
<ogra> morning mdz 
<Kamion> ogra: that may be true
<bddebian> Hello mdz
<Kamion> ogra: (and really I mean "debconf templates not already in udebs that anna can load for you", but never mind)
<seb128> HiddenWolf: pong 
<jdub> mdke: ping
* lamont-away -> office
<Kamion> mdz: can we lock down unapproved uploads now until preview release?
<Diziet> kamion: Shell quoting is going to be less of a problem, surely ?  Most of the values it deals with are identifier-like.
<Diziet> mdz: Hello.
<HiddenWolf> seb128, I have a .sxc file that defaults to file-roller when I press enter on it in Nautilus.
<elmo> Kamion: done
<mdz> elmo: thanks
<Kamion> Diziet: most of, but not all - I had to fix a bug recently in the handling of partition labels
<elmo> that was done to the Releases string change
<elmo> not the lock down
<elmo> but lock down is easy to do
<HiddenWolf> seb128, nautilus recognises it correctly as an openoffice calc file, btw
<Diziet> kamion: Niiice.
<mdz> Kamion: feeling good about the resolution of 14851?
<mdz> Kamion: did you happen to check it into arch for me to merge?
<seb128> HiddenWolf: is that a zip file too?
<jbailey> mjg59: I don't think there's much to think about.  I'll have to attempt the recover before I init USB and suck it up that we have no way of knowing whether the bus scan is complete.
<HiddenWolf> seb128, yes, all ooo files are .zips in disguise, but I'd expect it to default to OOO2-calc since it's installed.
<Kamion> mdz: 15:51 < Kamion> mdz: please merge colin.watson@canonical.com--2005/casper--vtfix--0
<Kamion> mdz: I'm just running it through on amd64 now
<elmo> \sh:  there's a bunch of packages like that, i.e. alot of what came from contrib in Debian
<elmo> \sh: but whether you guys want to keep them or not, is ultimately up to you
<seb128> HiddenWolf: right click on the file, properties, open with
<HiddenWolf> seb128, I know, but shouldn't that be default?
<mjg59> jbailey: Ok
<seb128> HiddenWolf: sure it is, but your description it no useful
<seb128> HiddenWolf: please open a bug with a file example
<mdz> I haven't tested the live cd on powerpc in a while; hope it still works
<HiddenWolf> seb128, right.
<\sh> elmo: I will discuss this during motu meeting..
<Kamion> mdz: nor I, actually, I'll do so in a moment
<Kamion> I had difficulty with the last test I did on powerpc though; I think my CD drive needs cleaning
<seb128> are we going to have a language-pack update before preview?
<Kamion> seb128: pitti left earlier, so that may be difficult; I don't know if anyone else can drive the langpack-o-matic
<mdz> elmo: please do the lock down
<xTina> *sigh* is there something wrong with dpkg 1.10.27ubuntu1.1? I'm getting random unpacking errors when doing fully automated and thus repeatable installs ("no such file or directory", "free(): invalid pointer", "dpkg-deb --fsys-tarfile returned error code 2" ...). I ran installations on multiple machines in parallel, some went just fine, while others got tons of error when unpacking the packages. If I don't dist-upgrade before i
<mdz> Kamion: I'll do a test once we have images with casper 1,12
<seb128> Kamion: hum, right, thanks
<mdz> xTina: you saw those errors on more than one machine?
<xTina> mdz: Yes, I did.
<Kamion> mdz: I've just started a livefs build; I'll do CD builds after that
<HiddenWolf> seb128: Attachment #3593  to Bug #14905 Created
<xTina> mdz: I've been at this problem for more than 3 days now :(
<seb128> HiddenWolf: thanks
<xTina> mdz: I have a lab with 74 machines I'm trying to install Ubuntu on.
<mdz> Kamion: is everything up-to-date buildd-wise?
<mdz> xTina: it hasn't happened to me anywhere
<Kamion> mdz: I haven't checked
<elmo> mdz: just mian?
<mdz> elmo: yes
<Kamion> no, stuff like libgnome is still building, so we'll need another round of builds later
<xTina> mdz: It seems to happen when I try to install tons of packages in one swoop, like apt-get install kubuntu-desktop. Then unpacking fails at random packages, sometimes on almost all machines, sometimes on none. The only reliable way to avoid is, is to not upgrade before doing those custom installs. Which strongly makes me suspect something's wrong with dpkg.
<elmo> mdz: done
<Kamion> xTina: worth trying 1.10.27ubuntu2?
<Kamion> (hoary-updates)
<xTina> Kamion: Doesn't make a difference, tried that.
<Kamion> ok
<Kamion> (of course that wouldn't be as random as what you're describing)
<Diziet> Random errors is very strange.
<mdz> xTina: it sounds awfully like a hardware problem
<Diziet> Very tempting to blame the hardware.
<Kamion> are all the machines identical (in terms of vendor, components, etc.)?
<xTina> yep
<xTina> Well, some have a DVD burner, but they fail too.
<Kamion> I'm thinking more of CPU, RAM, disk
<mjg59> xTina: It's possible that there's a kernel issue with the hardware
<xTina> yeah, that's all the same
<Kamion> or filesystem problems?
<mjg59> xTina: sometimes motherboard chipsets behave in slightly odd ways
<mdz> 1.1 was just a recompile of ubuntu1 anyway
<mjg59> xTina: It would be helpful if you could test Breezy on one of the machines and see if it exhibits the same symptoms
<xTina> might be, but as I said, nothing happens unless I dist-upgrade before apt-get install'ing our list of additional packages.
<mjg59> Hmm
<Kamion> have you tried things like compiling a kernel on them?
<mdz> xTina: there are a lot of packages other than dpkg which would be upgraded
<Kamion> that used to be a pretty good stress-test of RAM, although perhaps not so much any more
<xTina> mjg59: I tried that, but the netinstall that's on the colony-3 CD complains about not being able to download additional kernel modules.
<xTina> mdz: You mean when doing the dist-upgrade after a plain hoary install?
<Kamion> xTina: the netboot installer goes out of date quickly; use the one in the archive (/dists/breezy/main/installer-*/current/)
<Kamion> xTina: or the one on Colony 4 will be fine
<pef> bye
<Kamion> mdz: live/i386 and live/amd64 are both fine with the #14851 fix
<xTina> Kamion: ok, I will try that
<seb128> HiddenWolf: that's because default list point to openoffice1 apps, will be updated
<HiddenWolf> seb128, right.
<seb128> carlos: pong
<mdz> Kamion: fantabulous, thanks for that
<Kamion> burning live/powerpc now to have a look
<Diziet> mdz: I sent you a mail about wanting more stuff to do.  Since then I asked Kamion and have ended up reading lots of partman code.  But I still think it would be good for me to have (say) more bugs to deal with or something.
<Kamion> mdz: I can borg Diziet into installer hacking if you *like*, but "here, take some of my bugs" isn't necessarily an appropriate response from a mentor when asked for help finding stuff to do :-)
<sivang> oh not again..
<Kamion> oops, he's split
<Diziet> Joy.
<sivang> Kamion: why not, pitti tells me that all the time :)
<Kamion> mdz: I can borg Diziet into installer hacking if you *like*, but "here, take some of my bugs" isn't necessarily an appropriate response from a mentor when asked for help finding stuff to do :-)
<ogra> hrm
<Diziet> mdz: Did you see my earlier comment ?  I'll repeat it ...
<Diziet> > mdz: I sent you a mail about wanting more stuff to do.  Since then I asked Kamion and have ended up reading lots of partman code.  But I still think it would be good for me to have (say) more bugs to deal with or something.
<Kamion> sivang: sure, but Diziet's being paid and so people might be entitled to have other plans
<mdz> Diziet: there are *lots* of bugs in bugzilla; how can it be that you don't have enough?
* mdz -> meeting
<Diziet> Should I be tra...  damn.
<Kamion> mdz: it's not exactly obvious where effort should most effectively be applied, if you're floating rather than having a list of stuff assigned to you by default
<mdz> Diziet: you should be subscribed to ubuntu-bugs
<Diziet> Yes, I am, and I've been looking at the traffic there.  See my mail.
<bddebian> Kamion: Amen to that :-)
<Robot101> Diziet: go and convince the Debian kernel team they want to use mkinitramfs and not any other weird thing :)
<Diziet> Of the traffic there that's not people discussing bugs they're already working on, it's just the odd `New:' bug really.
<Kamion> Diziet: that said, search for high-severity bugs ...
<mdz> Diziet: a New bug which is assigned to debzilla is up for grabs
<sivang> Robot101: lol :)
<mdz> highest impact bugs deserve highest priority
<Diziet> Bugzilla has the `RC Bugs' list.  Am I supposed to be trawling through that ?
<Diziet> The proportion of bugs assigned to debzilla is pretty low.
<Diziet> And many of those seem to be really poor reports to which the best response is a polite version of `please send an actual bug report'.
* Kamion goes to wind down for a bit before this evening's CD-build-and-test marathon
<jdub> Kamion: scotch on the rocks!
<Diziet> Also, am I supposed to be making a distinction between things in main and things in universe ?
<ogra> jdub, *shudder* ... you put frozen water into scotch ? 
<sivang> mdz: do you consider printing bugs important (most of the bugs on g-c-m are low prio for example) , or is there areas requiring more attention?
<mdz> sivang: it depends on the bug
<mdz> Diziet: that's a big part of triage, and it's work which needs to be done
<mdz> Diziet: incomplete bug reports need to be improved or rejected
<mdz> I'll respond to your email when I can
<mdz> Diziet: HelpingWithBugs covers some of this, too
<Diziet> Yes, I read that, but it's more a suggestion of things to do to bugs rather than a way to choose bugs to pay attention to.
<Diziet> triage> Sure.  If that's what you want me to be doing I can do that.  Is the bugzilla `RC Bugs' list a sensible place to start ?
<Kamion> When I'm doing general triage, I generally either start with the RC bugs list or with a particular set of packages that interest me.
<sivang> mdz: I'd like to take on #6224, but I'd like to know if it is important enough.
<mdz> sivang: I'm unable to reproduce that bug; I replug my printer all the time
<WaterSevenUb> kamion, apt-get source debconf - has the pt.po and the strings "ubuntu configuration" which are the ones that appear in the post-install of breezy... assuming that is the correct package I'm looking at and assuming that there are translations, why are there not being used during install?
<Kamion> WaterSevenUb: there's a bug in debconf->cdebconf passthrough; I noticed it myself the other day. I'll dig into it and fix it after preview
<WaterSevenUb> kamion, the problem is related to that bug?
<Kamion> WaterSevenUb: the problem *is* that bug :-)
<WaterSevenUb> kamion, lol... and is that related to the "time zone configuration" not being translated too?
<Kamion> yeah, same bug
<sivang> mdz: so we can tag it EWORKFORME ?
<WaterSevenUb> kamion, ok, I can rest in peace now:)
<Kamion> anything that's run in /target rather than in the main installer environment seems to be having translation troubles
<Kamion> WaterSevenUb: hang on though, you said "post-install"; at what stage exactly did you see "Ubuntu configuration"?
<mdz> sivang: no, we should ask for more information and a test with breezy
<WaterSevenUb> kamion, after the reboot after installation, when the system is booting for the first time appears a graphical interface which on top says "ubuntu configuration".
<WaterSevenUb> kamion, "time zone configuration" problem is before reboot of course....
<Kamion> graphical? really?
<WaterSevenUb> kamion, eheh... ok..... pseudo graphical? :)
<WaterSevenUb> kamion, I mean... not black and white text;)
<Kamion> WaterSevenUb: ah, that is a different bug
<sivang> mdz: ok, sure. then I'll try to reproduce and /or ask for specific brand fo the printer in question, maybe it is a make specific issue
<Kamion> WaterSevenUb: debconf is incorrectly having its translations stripped and put into language packs, which aren't installed yet at that stage
<WaterSevenUb> kamion, hhmm... I'm lost. "Time zone configuration" problem is related to the above problem you mentioned before and "Ubuntu configuration" to the one you just mentioned?
<Kamion> debconf-i18n rather
<Kamion> WaterSevenUb: correct
<Kamion> WaterSevenUb: sorry, when you first mentioned the bug with "Ubuntu Configuration" I assumed it was pre-reboot
<WaterSevenUb> kamion, thanks. Should we take any step to get "ubuntu configuration" bug solved? The first one I assume it will be corrected by you after preview....
<Kamion> WaterSevenUb: I've just sent mail to Martin Pitt about the second bug
<Kamion> he should be able to deal with it shortly
<xTina> btw, is http://archive.ubuntulinux.org/ubuntu/dists/breezy/main/installer-i386/current/doc/manual/en/apcs01.html the newest version of this document, or is there a newer one somewhere?
<WaterSevenUb> kamion, thanks:) 
<Kamion> xTina: yeah, that's current
<WaterSevenUb> monteiro, kamion rocks;)
<monteiro> yes ;)
<Kamion> although it is also out of date according to one of my bug reports; I need to look over it
<xTina> Kamion: Hm. Preseeding the locale as it's described there doesn't seem to work for me in colony-4.
<xTina> Kamion: Also, that URL: http://www.debian.org/releases/breezy/example-preseed.txt probably isn't correct ;)
<Kamion> xTina: yeah, that's one of the out-of-date bits - change "preseed/locale" to "debian-installer/locale"
<Kamion> xTina: heh, true - I'll fix all that up at the same time, thanks
<xTina> Kamion: ah, ok :)
<Kamion> most of the rest looks moderately reasonable
<Diziet> Do we care about a missing build-depends on a package implied by ubuntu-base ?
<phlaegel> desrt: ping
<desrt> pong
<xTina> Kamion: I guess there's no significant changes in regard to partman's handling of expert recipes in breezy, or is there?
<phlaegel> I take it you're the gnome-applets release guy?
<Kamion> Diziet: yes, if it's not a direct/indirect dependency of build-essential
<WaterSevenUb> kamion, at a give stage during breezy installation appears the message "Download language support" or something similar... any idea what is the package responsible for this? We are suspecting that there is a problem also... but needs further investigation.
<desrt> phlaegel; ya.  is there a problem? :/
<Kamion> Diziet: the buildds don't install all of ubuntu-base
<Diziet> kamion: is there an easy way to tell ?
<Kamion> xTina: no
<phlaegel> desrt: wondering about bug 12573... the stock applet is completely useless as is
<desrt> ubuntu bug?
<\sh> xTina: tuxtina.de? 
<phlaegel> desrt: I was surprised to see it release with it :-) 
<phlaegel> desrt: yep
<Kamion> Diziet: if it's Priority: required (according to Packages) or in the buildd list near the top of /usr/lib/debootstrap/scripts/breezy, it's build-essential
<xTina> \sh: yep
<desrt> uhhh
<Kamion> WaterSevenUb: archive-copier; that's translated into pt_BR but not pt
<desrt> phlaegel; ya.  that's pretty freakin' serious
<Kamion> WaterSevenUb: happy to take a pt.po for that at cjwatson@ubuntu.com
<\sh> xTina: interessting documents on your page :) 
<desrt> phlaegel; it will be fixed for breezy.  thanks for bringing it to my attention.
<WaterSevenUb> kamion, eheh... you were fast;)
<phlaegel> desrt: no problem :-)
<xTina> \sh: what in particular?
<Kamion> WaterSevenUb: well, I wrote archive-copier ...
<\sh> xTina: linuxinstallation_folien.pdf e.g.
<WaterSevenUb> kamion, still.. you guessed it;)
<\sh> xTina: update this one for ubuntu now ,)
<xTina> \sh: Oh, we did our last install party with ubuntu as the default distribution. It just wasn't me who did the slides ;)
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with breezy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://www.ubuntulinux.org/wiki/DeveloperResources | Colony 4 is released: http://cdimage.ubuntu.com/releases/breezy/colony-4/ | https://wiki.ubuntu.com//HelpingWithBugs | MOM/NDA producing bad diffs | Preview freeze in effect; no uploads to main without prior approval
<\sh> xTina: but looks like :)
<sivang> seb128: so we will get gnome-applets last drop for lpi after preview?
<xTina> \sh: 2001? Our last install party was in 2004 :)
<dholbach> mdz: i will upload glibmm and libgnomevfsmm next week, ok? those two just dropped in this evening
<xTina> \sh: http://fachschaft.informatik.uni-stuttgart.de/studium/infmisc/archiv/ws04/installparty.pdf
<Diziet> So I have an alleged FTBFS bug, imported from bugzilla, about a missing build-depends on bzip2 (which doesn't appear to be build-essential).  But the current source appears to have been built successfully by our buildd.
<\sh> xTina: I should take a better look on the statusline of my ff
<mdz> dholbach: seb128 said everything was uploaded
<mdz> dholbach: for 2.12.0
<dholbach> mdz: those are not of major importance - c++ bindings
<WaterSevenUb> kamion, there is a warning # THIS FILE IS AUTOMATICALLY GENERATED FROM THE MASTER FILE
<WaterSevenUb> kamion, should we be worried about this or just make .po file?
<mdz> dholbach: are they 2.12.0 or not?
<Kamion> WaterSevenUb: don't worry about it, I'll take care of it
<dholbach> mdz: and the changes are mostly the the version number
<WaterSevenUb> kamion, ok... give us 15 minutes;)
<Diziet> Should I upload a new version with it fixed (after the preview is out) ?
<\sh> gnarf...I'm not a wiki editor 
<Kamion> Diziet: yes, that would be appropriate after preview; the buildds don't always start from a totally clean slate
<Diziet> k: Right.
<Kamion> (Launchpad buildds will start from a clean chroot every time, I'm told.)
<mdz> dholbach: is there any hope of fixing xchat so that it doesn't continue pulsing the taskbar forever and ever?
<dholbach> mdz: will have a look around
* Kamion -> dinner
<tritium> I've already gotten used to Alt-Tabbing away from and back to xchat to eliminate the pulsing
<ogra> seb128, see the pre last paragrph: http://lists.ubuntu.com/archives/edubuntu-devel/2005-September/000488.html
<ogra> its still there :/
<ogra> even on new installs
<desrt> phlaegel; i've found the patch that introduced the regression
<desrt> phlaegel; if push comes to shove, i'll just back out the patch
<mdke> jdub, still here?
* sivang out, be back later
<jdub> mdke: yeah
<mdke> jdub, sup?
<jdub> mdke: what's with the 'misleading information' stuff on BBBT page?
<\sh> mdz: use irssi
<mdke> jdub, nothing really, I just removed "ItalianTeam" because people might think that the locoteam will be there. No biggie
<mdke> I have this error which is blocking my dist-upgrade in breezy http://pastebin.com/357252 I can't see anything in bugzilla, is it known?
<Keybuk> mdke: isn't known; but looks like libdjvulibre15 needs to conflict/replace libdjvulibre1
<mdke> Keybuk, i'll file a bug then. Do you know how I can workaround it?
<Keybuk> that's strange ...
<Keybuk> it already does have one
<Keybuk> what version of libdjvulibre1 do you have installed?  (dpkg-query -W libdjvulibre1)
<mdke> libdjvulibre13.5.14-5
<jdub> mdke: that was my impression
<jdub> mdke: that members of the loco team would be coming along
<mdke> jdub, i thought it was open to all italian community members... the guy who wrote you is not in the team
<mdke> so i figured to leave it open to more people, i'd remove the "team" reference
<mdke> one out of four of us in the locoteam can make it I think
<jdub> isn't the loco team open to anyone interested in ubuntu in italy?
<mdke> Keybuk, what is the bug #?
<Keybuk> +Conflicts: libdjvulibre1 (= 3.5.14-6), libdjvulibre1c2
<Keybuk> +Replaces: libdjvulibre1 (= 3.5.14-6), libdjvulibre1c2
<Keybuk> weird
<mdke> jdub, the team is made up of 4 members, a bit like the Community Council. The community in general is open to anyone interested in ubuntu in Italy
<Keybuk> it has a specific version of the next one
<Keybuk> mdke: no bug#, just looking at the package changelog
<Keybuk> file a bug saying those conflict/replace needs to be a little less specific ;)
<Keybuk> or if mdz approves, I can just fix that now <g>
<mdke> Keybuk, ok shall I file it against libdjvulibre1c2?
<jdub> mdke: weird :)
<Keybuk> this isn't a hoary->breezy bug though, it's a part-breezy -> breezy
<\sh> cxx trans
<mdz> Keybuk: then it should wait until after preview
<Keybuk> agreed
<mdke> jdub, the community got big so we developed that system
<mdke> jdub, i made a translation explaining it here: https://wiki.ubuntu.com/ItalianCommunityStructure
<Keybuk> . o O { my god, that's a difficult package name to type! }
<mdke> yeah
<Keybuk> mdz: actually, it does affect hoary->breezy too by the looks of it
<Keybuk> that needs to be a <= not an =
<Keybuk> (hoary's package includes the conflicting file too)
<mdz> Keybuk: since uploads are locked down, go ahead and upload
<mdke> Keybuk, ok i've filed it at #14909
<seb128> mdz, dholbach: speaking about what? *mm?
<mdz> Keybuk: if we have to process other uploads anyway, we'll let it in
<mdz> seb128: yep
<dholbach> seb128: yep
<mdke> jdub, feedback on the system is always appreciated :)
<seb128> mdz: they are not a part of the desktop, but a part of the bindings platform .... we have GNOME 2.12.0 (desktop)
<mdke> Keybuk, i'd still appreciate a workaround if you know one, I can't dist-upgrade and it's a few weeks since my last one
<seb128> not sure on how much about *mm stuff, they are not used a lot
<seb128> ogra: what about this mail?
<Keybuk> mdke: dpkg --force-depends --remove libdjvulibre1
<Keybuk> mdke: dpkg --unpack /var/cache/apt/archives/libdjvulibre15_*.deb
<seb128> oh, the education menu, not sure about it
<Keybuk> (in that order -- then run the upgrade again)
<ogra> seb128, the dissapearing menu stuff
<seb128> sivang: what about applets?
<mdke> Keybuk, magic, cheers
<seb128> ogra: if you have the issue you are welcome to track it
<seb128> jdub: around?
<mdz> Kamion: are those livefs builds finished?
<ogra> seb128, i'll do... its just strange, since it only disappears occasionally...
<HiddenWolf> seb128, nautilus doesn't update file size regularly for me. Only when I bring it up after minimised or when manually refreshing it. known bug?
<ogra> seb128, there is no pattern for it...
<HiddenWolf> seb128, watching a file download...
<seb128> HiddenWolf: what file size? properties one?
<HiddenWolf> seb128, 'size' column in nautilus
<seb128> HiddenWolf: not sure abou that, search on bugzilla.gnome.org, there is probably a bug about it
<HiddenWolf> seb128, i'll browse
<seb128> mdz: bindings are mm, java, perl, pygtk .. we have pygtk uptodate and I would say others don't really matter. If dholbach wants to update *mm that's fine (and is no likely to break something since they are not used a lot and frozen upstream too) but that can wait after preview
<jdub> seb128: yo
<seb128> jdub: do we care about *mm 2.12.0 tarballs?
<seb128> jdub: have bindings the same schedule as the desktop for GNOME ?
<Lathiat> seb128: i thought some of that got uploaded already?
<jdub> seb128: yes
<jdub> seb128: murray's were late
<mdke> i'm also getting update errors with console-data, base-config and ubuntu-minimal. These have been here for at least a month, is everyone else getting em?
<dholbach> Lathiat: most of it, two are missing
<elmo> mdz/kamion: 'helena -m breezy' does something useful
<seb128> jdub: "yes we care" or "yes that's the same schedule" or "yes to both"? :)
<jdub> seb128: yes to both ;)
<seb128> bah
<seb128> k :)
<mdke> ah it is bug #13134 but it doesn't seem to have been assigned to anyone yet
<seb128_> grumpf, dsl hangup
<mdz> jdub: in this case, care implies "care for preview purposes"
<jdub> which is a no
<seb128_> mdz: does anybody out of pitti has language-pack clue? The current GNOME translations are quite laggy and that would be nice to have them updated
<mdz> seb128_: no, I don't think anyone else can build them at this time
<mdz> lamont: ?
<mdz> seb128_: have all 2.12 packages been built?
<lamont> mdz: I'm not sure - I might be able to figure it out, but I wasn't instructed or anything...
<seb128_> mdz: yep
<mdz> lamont: where does it live and how do I get access to it?
<lamont> the un-merged tarballs are http://people/~lamont/translations/....
<lamont> but those need to be merged, and I'm still not clear on the algorithm that pitti has planned for that...
<mdz> sent an SMS to pitti
<WaterSevenUb> kamion, you have email :)
<WaterSevenUb> kamion, sorry for taking 30 min instead of 15 ;)
<mvo> mdz: I can call pitti on his mobile if you want
<mdz> mvo: does he not receive SMS?
<mdz> mvo: sure, try him
<mdz> he is calling me now
<mvo> mdz: ok
<desrt> BenC; sup
<mdz> ok
<mdz> language pack story: we can't build updated langpacks until pitti makes some fixes to the scripts
<jdub> gnome 2.12 has been released
<dhonn> cool
<jdub> the very loud second hand is ticking now :-)
<mdz> so we can proceed with testing candidates tonight, and if all goes well, we can roll in updated langpacks in the morning, do another test cycle and go
<mvo> congrats jdub 
<mdz> jdub: congratulations
<dhonn> http://gnome.org/
<seb128_> jdub: congrats :)
<ogra> yay jdub 
<jdub> seb128_: give elijah the love this time 'round :-)
<dhonn> always on time 
<mdz> has anyone had hotplug exceed the default usplash timeout?
<mdz> or anything other than module-init-tools?
<desrt> when is preview happening?
<ogra> desrt, tomorrow if we match the schedule
<desrt> seb128_; i have a fix for one of your bugs that you might want to consider, then
<seb128_> desrt: consider for when?
<desrt> seb128_; for preview
<ogra> that must be a very serious one then :)
<seb128_> desrt: which one? I doubt we do new uploads now, that would delay the CD build probably
<desrt> oh.  ok.  forget it then
<seb128_> what is the bug?
<desrt> the fix will be in 2.12.1 anyway
<desrt> http://bugzilla.ubuntu.com/show_bug.cgi?id=12573
<seb128_> I've no stopper on my list
<desrt> gtik basically completely doesn't work
<desrt> but not many people use it :P
<seb128_> oh, right
<seb128_> that's a detail :)
<desrt> :)
<seb128_> will be fixed for 5.10 anyway
<desrt> ya
<desrt> davyd and i are gonna try and get 2.12.1 out on time for 5.10
<seb128_> the schedule is made to ship 5.10 with GNOME 2.12.1
<seb128_> so if you roll the tarball for GNOME 2.12.1 that's ok
<mdz> slomo: what was the date of the tech board meeting where you proposed yourself for MOTU?
<slomo> mdz: uh... wait... the tb meeting just before july 27th iirc
<mdz> slomo: I need the exact date
<ogra> mdz, he was added to the motu group on aug 25th, since the meeting must have been tuesday, it was the 22th
<slomo> mdke: 26th
<Lathiat> check the wiki logs :)
<slomo> mdz even...
<ogra> err 23th
<slomo> ogra: my logs say 26th ;)
<ogra> oh, didnt we meet on tuesday ?
<ogra> slomo, but i dont add people in advance to the motu group.... 
<mdz> slomo: thanks
<slomo> ogra: jul 26th
<ogra> ergh, ok
* ogra hides in a corner
<slomo> ogra: np :)
<mpt> jdub: In gnome.org/index.html, change "550" to "401"
<mpt> otherwise the "smoother graphics & antialiasing" is unintentionally amusing
<bddebian> elmo: pingeage
<jdub> mpt: it's updating right now
<jdub> thank you
<jdub> fiftieth time
* jdub yells at stupid non-make-sensible crap in the web build
<ogra> jdub, btw, did you see this bug ? http://bugzilla.ubuntu.com/show_bug.cgi?id=14622
<dholbach> brb
<froud> whose the address for training and certification development?
<jbailey> froud: What are you looking for?  There's a few different people.
<froud> who is the head?
<jdub> froud: speak to jane silber/
<froud> kk
<froud> thx
<bddebian> elmo: If/when you come around can you please sync libdebtags1, debtags, and tagcoll 1.4 from experimental.  I have been asked to bring in 1.4 rather than try to merge debtags 1.3.  Thanks a million.
<Kamion> mdz: oh yeah, ages ago
<Kamion> mdz: is this a preview-candidate install CD build happening now?
<Kamion> mdz: live/powerpc wouldn't start X for me (claiming bogus PCI bus ID), but I don't trust my results there because I was getting EIO on /usr/bin/less and /bin/more
<mdz> Kamion: yes
<mdz> Kamion: live build is already done, burning ow
<mdz> now
<mdz> OW BURNING
<lu|release> there are creams for that now.
<tseng> mdz: ive been hacking on livecds all day, i can now partially appreciate your painful burden
<tseng> edit, compress, mkiso, burn, test, rinse, repeat
<lu|release> tseng: another mono livecd?
<mdz> tseng: x3 architectures ;-)
<lu|release> tseng: and apologies in advance; I could not fix beagle on the gnome liveCD in time. :/
<jdub> how well does your burner cope after the rinse stage?
<tseng> lu|release: a demo for work
<tseng> lu|release: damn, too bad.
<tseng> jdub: after a bit of sizzling it seems to do alright
<lu|release> tseng: yeah
<lu|release> tseng: next release I guess
<lu|release> (which probably won't be my baby, for better or for worse)
<tseng> lu|release: jhill is hacking on another
<tseng> lu|release: (mono cd)
<lu|release> tseng: cool
<mvo> ping mjg59 
<mjg59> Hi
<mvo> mjg59: I was wondering if it would be worthwhile to use the lrmi code to help grub figuring the device_map. what do you think?
<mjg59> mvo: If there are any BIOS calls that would help, then probably
<mjg59> But bear in mind that lrmi is x86 only - it won't work on amd64
<mvo> mjg59: yes, that is essentially the problem. figure the bios disk order (#1750). I have some prototype code (based on vbetool), but I seem to be unable to give the thing a real-mode buffer where the bios can write the drive info into :/
<mjg59> mvo: Where's the code?
<mvo> mjg59: on my hdd, I can put it on people.u.c if you are interessted/have time
<mjg59> mvo: Please - I can take a quick look now
<mvo> mjg59: http://people.ubuntu.com/~mvo/vbetool-0.3.tar.gz
<mvo> mjg59: hm, I should probably rename that :)
<mvo> mjg59: http://www.ctyme.com/intr/rb-0715.htm
<mjg59> mvo: The LRMI_alloc_real should do what you want, I think
<mvo>  is the relevant real-mode interrupt
<mvo> mjg59: I use it and get "invalid parameter", no idea currently why
<mjg59> mvo: Hrm. No real idea then, I'm afraid
<mvo> mjg59: ok, thanks for having a look
<mdz> Kamion: framebuffer on powerpc seems hosed
<mdz> Kamion: at the point where it used to switch to vt2, the display remains unchanged (progress bar at 100%) and the console is unusable
<mdz> it was this kind of behavior that caused me to use vt2 originally; I'm surprised it worked for you on i386/amd64
<Kamion> mdz: I think it must have worked for me because usplash cleared all the debris out of the way
<Kamion> but it definitely did work
<WaterSevenUb> kamion, got the email?
<Kamion> WaterSevenUb: I've been busy sorting out a child's dinner.
<WaterSevenUb> kamion, :)
<Kamion> WaterSevenUb: so thank you, and yes I've got it - probably won't be able to deal with it until tomorrow though
<Kamion> mdz: I'm surprised though, killing bterm did seem to help
<Kamion> but perhaps usplash obscured the issue
<mdz> Kamion: so it seems that we either need to fix bterm to clean up after itself, figure out how to clean up after it in casper, or fix this in X
<mdz> or perhaps get usplash working on powerpc ;-)
<Kamion> the latter's kind of a tempting approach
<Kamion> because I don't see why it should be hard - after all it just uses bogl, which works fine on powerpc
<Kamion> mjg59: what problems did you run into making usplash work on powerpc?
<mdz> Kamion: something about the framebuffer mode
<Kamion> oh, bogl_move
<mdz> Kamion: I assume when it worked for you, the first few startup messages were obscured, though?
<mdz> i.e., you never saw "Starting Ubuntu..."
<Kamion> mdz: yeah
<Kamion> I didn't really register that at the time, because that situation seemed preferable :)
<jbailey> Kamion: It actually crashes usplash from a null pointer dereference.
<Kamion> i.e. no text console
<mdz> Kamion: it does eventually start X of course, but I doubt many people would wait that long
<Kamion> mdz: on powerpc?
<mdz> Kamion: yes
<Kamion> mdz: an alternative hack is to have the last thing on the progress bar be "Starting live system, please wait..."
<mdz> it's just the console output which is hosed; it still boots
<mdz> Kamion: haha
<Kamion> so even if it doesn't get cleaned up, at least it says "please wait"
<Kamion> ok, how hard can it be to implement move on cfb
<jbailey> Kamion: mjg59 said that it should be just a memmove with some fiddling to take colour depth into account.
<ogra> mdz, i called out a contest for the screensaver dialog background...3 submissions so far...
<Kamion> jbailey: the vga16 version isn't even that clever - it's pixel-by-pixel
<mjg59> Kamion: The only issue is implementing the move function
<mjg59> Possibly also something to deal with centring the picture
<Kamion> ok, I'll hide in a cave and do that then
<Kamion> but first, COFFEE
<mdz> Kamion: did you happen to test with framebuffer=false?
<Kamion> mdz: no
<Kamion> does it break hideously? :(
<mdz> no, I'll test that, then
<mdz> haven't tried it ye
<mdz> t
<mdz> Kamion: heh, works, but ends up with white text on a BRIGHT RED background for the boot
<mdz> Kamion: did you remove the reset call which was there?
<Kamion> what reset call where?
<Kamion> there was a clear, I left that alone
<pitti> mdz: howdy, going to fix langpacks now :-)
<Kamion> mjg59: what's the easiest way to test usplash without having to install it and reboot and stuff?
<dholbach> hey pitti 
<jbailey> mjg59: Run usplash &, and call usplash_write "STATUS $@"
<jbailey> mjg59: Replace $@ with text you want to appear.
<jbailey> Kamion: ^^
<jbailey> I'll figure out who I'm talking to yet.
<pitti> Kamion: new pkgstriptranslations uploaded (with debconf-i18n blacklist)
<pitti> Kamion: is this preview-critical? if so, I ask lamfinity to install it ASAP and upload a new debconf
<Kamion> jbailey: hmm. well, that hung my system
<Kamion> pitti: no, it's not
<Kamion> it can wait until after preview, when I'll need to upload debconf at some point anyway
<Kamion> (probably)
<Kamion> oh, no, sort of working now
<mjg59> Backgrounding usplash from an interactive shell tends to work badly
<mjg59> Kamion: You probably want to ssh in and test it
<Kamion> I've been doing sudo sh -c './usplash & sleep 1; ./usplash_write stuff; sleep 1; ...; wait'
<Kamion> text drawing doesn't seem to be working, and as you say nor is centring
<Kamion> at least PROGRESS works though
<mjg59> Text drawing will do a move call first
<mjg59> So if that's going wrong, it may well segfault
<Kamion> it's not segfaulting at least
<pef> hello
<mdz> pitti: good morning :-)
<pitti> Hi mdz
<mdz> Kamion: updated translations aren't necessarily critical for preview, but awfully nice to have
<mdz> Kamion: were you able to confirm one way or another whether X was borked on one of your systems?
<pitti> mdz: I have two options: build packs from scratch to make them smaller and make elmo cry, or build updates which make them bigger and throw out some from CDs
<mdz> pitti: what is the basis of elmo's crying?
<pitti> mdz: a big mirror hit mostly
<mdz> pitti: the pain will not last
<hughsie> mjg59: i hear you patched g-p-m to do some cool ubuntu'y stuff. you got a link to the diff?
<mdz> we need to roll new packs when we have a high volume of changes; it's part of the design
<pitti> yep
<mdz> pitti: we'll have to do it again when we get rosetta exports, presumably
<CarlFK> justs installed breezy.  logged in as user, did: system, admin, users.  ksudo: entered something (not sure what). dialog went away, no message, no User/groups dialog.  waited 10 seconds.  try again: sys/admin/users - this time no ksudo, no dialog, no Users - nothing.  (repeated 3 times just to be sure.
<pitti> yes, therer is certainly a fair number of accumulated updates
<CarlFK> any idea whas going on?
<Kamion> mdz: unfortunately not
<Kamion> mdz: I think there's only one translation affected in practice by the debconf-i18n thing pitti mentioned, and I don't think it's important enough to go through that dance
<Kamion> but langpacks, certainly
<mdz> Kamion: I'm not concerned about the debconf thing, but all the upstream translations we're currently missing because langpacks are outdated
<mvo> CarlFK: what happens if you run ksudo user-admin in a termianl? any usefull output
<mdz> they're supposed to get us more up-to-date translations, not fewer ;-)
<mdz> mvo,CarlFK: #ubuntu, please
<CarlFK> checking...
<Kamion> mdz: definitely
<dholbach> brb
<doko> xchat is quitting on it's own ... hrm ...
<mdz> mjg59: do you know what it is that bterm isn't doing at shutdown which leaves the console in a broken state?
<Kamion> mjg59: ok, so move works now, it's just the text drawing that mysteriously doesn't work
<HiddenWolf> doko, you are the OO.org guy, right?
#ubuntu-devel 2005-09-13
<CarlFK> mdz - #ubuntu is bit noisy now.  I am trying to form a good bug report.  isn't this the proper #?
<doko> HiddenWolf: I pretend it to be
<mdz> CarlFK: no, see /topic
<HiddenWolf> doko, interested in a .ppt that makes OOo2 choke?
<Kamion> mjg59: my mistake, text drawing works fine. Why does STATUS draw text in the background colour?
<mdz> CarlFK: it is not noisy in here and we try to keep it that way ;-)
<pitti> HiddenWolf: you mean, really badly choke?
<doko> sure, but that's not that unusual
<HiddenWolf> pitti, doko, like in become totally unresponsive.
<CarlFK> mdz - dont you think "bug report"  is more dev than support?
<HiddenWolf> pitti, just tried opening it after the last crash. I've got a nice big grey 1.9.125 screen at the moment, nothing in it, nothing happening.
<mdz> CarlFK: it isn't a bug report until you know what the problem is.  until then, it's a support request.  your cooperation in helping us maintain a productive development environment is appreciated
<CarlFK> okee dokee
<CarlFK> last Q: what package gets bugged for gksudo ?
<HiddenWolf> mdz, what about if you know what the problem is, but not how to debug it, or which component to file on?
<pitti> CarlFK: gnome-system-tools, according to your description; gksudo seems to work fine
<mdz> HiddenWolf: then you ask for help in #ubuntu
<CarlFK> pitti - guessing you missed my posts in #ubuntu ;)
<HiddenWolf> mdz, ok
<HiddenWolf> doko, is there a bug to that extent I can up the .ppt to?
<doko> HiddenWolf: no, please open a new one
<HiddenWolf> doko, Attachment #3602  to Bug #14919 Created
<mdz> Riddell: how are the kubuntu CDs looking?
<mdz> Riddell: ready for preview?
<Kamion> mjg59: OK, this looks like it works now. Do you want to look over a diff, or shall I just upload once I've done a full test?
<mdz> zul: do you have two launchpad accounts (zul and zulcss)?  if so, you should merge them
<mdz> zul: you seem to be using one for motu and another for ubuntu-dev
* pitti finally has a fresh and juicy translation tarball
<pitti> ... and broken
<mdz> Kamion: I don't think we needed busybox-killall; we're already using the real root at that point
<mdz> pitti: how broken?
<doko> just tried to boot a recent breezy-i386 live cd. it did fail, because it couldn't read the casper-udeb. bad disk, or other problem?
<pitti> mdz: some missing imported tarballs, I can work around that
<mdz> doko: bad disc
<mdz> Kamion: I suspect that chvt 2; killall bterm; wait for bterm to die; chvt 1 might be a workaround
<Riddell> mdz: when I tested the daily install build from today it had a kernel fault on the second part of the installer, going back to the install build from a couple of days ago it suddently got the same fault even though it was fine at the time
<pitti> infinity, lamont: it seems that some buildds stopped exporting their translation tarballs; e.g. vernadsky stopped at 20050902
<pitti> infinity, lamont-away: this means that I'm missing some translations; I can work around this for now, but could you please look at that?
<mdz> Riddell: hardware changed?
<mdz> Riddell: I assume the ubuntu builds exhibit the same problem
<mdz> Riddell: if you want to take advantage of the stability of the preview freeze for kubuntu, it needs to be ready to release at the same time
<Riddell> mdz: same hardware
<Riddell> mdz: ubuntu build is still downloading
<Kamion> mdz: ah, oops, didn't think of that
<Kamion> mdz: I'll try that chvt hack in a moment
<Riddell> I've made a couple of changes to the seeds, Kamion could you run a re-build on kubuntu
<mdz> Kamion: where does the bterm in d-i come from?
<Kamion> mdz: bogl
<Kamion> Riddell: running
<pitti> lamont-away, infinity: looking a bit closer, it seems that some buildds don't even call pkgstriptranslations any more (e. g. control-center_1\:2.12.0-0ubuntu1_20050904-1510-i386-successful). boggle
<Riddell> thanks
<mdz> Kamion: so my ideas are four: get usplash working as a workaround (you), try to get bterm to clean up after itself (me), fix X (daniels), chvt hack (you).   anything else I missed that someone ought to try?
<Kamion> if bterm can't be made to clean up after itself, then make casper do it
<Kamion> although I suspect that will be harder
<Kamion> or the casper progress bar workaround :-)
<Kamion> but those are both fallback options so we probably don't need to look at them right now
<Kamion> Riddell: erm, did you want to have your new kubuntu-meta in there too?
<Riddell> Kamion: yes, is it not?
<Kamion> Riddell: uploads are currently by approval only, and this is enforced - i.e. your kubuntu-meta_0.51 upload is sitting in a queue waiting for approval
<Riddell> right, sorry.  can you approve?
<Kamion> yes, just looking
<Kamion> well, I can when cron.daily isn't running, will have to wait a few minutes
<Kamion> I don't really want to randomly kelly stuff into the archive while archive maintenance is going on
<elmo> you can kelly stuff while apt-ftparchive's running, fyi
<elmo> the thing to avoid is kelly vs kelly or kelly vs jenna
<elmo> but given the speed of cron.daily on the new dl385 it might not matter
<jbailey> Can I request that milestone 6.04 be added to Bugzilla?  It would be nice to be able to start pruning out bugs that I don't intend to fix for Breezy that are too invasive.
<Kamion> oh, I can? in that case done
<Riddell> mjg59 et al: will it be possible to get different usplash artwork for kubuntu?
<Kamion> Riddell: it should be a simple matter of programming (I think) but at the moment it's still compiled into the usplash binary
<jbailey> Riddell: the png file gets compiled into usplash with png2bogl right now.  I don't know if it's trivial to make it dlopen'able at runtime rather than compiled in.
<ogra> Riddell, we'll need separate packages for edu/kubuntu for now i guess
<mdz> Kamion: what do I pass for the argument to bterm -f?
<bddebian> Riddell: Don't know if you saw but I asked elmo to sync debtags et al 1.4 from experimental (just for you ;-) )
<Kamion> mdz: pick /lib/unifont.bgf out of bterm-unifont.udeb
<Riddell> bddebian: rocking
<bddebian> Riddell: Well that doesn't mean he'll do it.  I'm on his list. ;-)
<mdz> Kamion: where does that come from?  I don't see it in bogl
<elmo> grr
<Riddell> ogra: well it's the rebuilding the initfs that's the difficult bit I think
<elmo> Kamion: SendEnv LANG LC_* is satanic
<Kamion> mdz: bterm-unifont is a separate source package
<Kamion> elmo: it's the only way to make things even have a chance of working properly for a lot of people
<ogra> Riddell, the is done on install... just change your sed to depend on kusplash
<ogra> seed even
<Kamion> the workaround for problems with that SendEnv is much easier than the workaround for problems without it
<elmo> kamion: it breaks with some non-openssh servers
<Kamion> elmo: gah, really?
<elmo> yeah
<Kamion> I thought that wasn't supposed to happen with ssh2
<Kamion> (nice theory)
<zul> someone call my name?
<dholbach> zul: i think mdz did
<zul> oh crud :)
<zul> mdz: ping
<dholbach> zul: he referred to your launchpad IDs :)
<zul> ah ok
<mdz> <mdz> zul: do you have two launchpad accounts (zul and zulcss)?  if so, you should merge them
<mdz> <mdz> zul: you seem to be using one for motu and another for ubuntu-dev
<Kamion> it just opens an env channel and sends name/value pairs down it
<elmo> debug1: Sending env LANG = en_GB
<elmo> dispatch_protocol_error: type 100 seq 7
<elmo> buffer_get: trying to get more bytes 4 than in buffer 0
<elmo> if I stop it sending env stuff, works fine
<Kamion> an env channel for each variable, actually
<elmo> granted, the other end is some non-free sshd, but still - it's hardware, I don't have much choice
<Kamion> elmo: I'll check the RFCs sometime when I'm less busy
<elmo> kamion: sure, I just wanted to whine
<Kamion> see whether openssh is straying outside them
<jbailey> zul: Carefule when merging accounts.  There's a bug where it doesn't merge you onto teams properly.
<zul> i didnt know i had two accounts in the first place
<pitti> Riddell: are you still here for a while to test new language packs?
<mdz> wtf
<mdz> bogl-bterm works, but when I build it from source it doesn't
<mdz> "bogl: don't know screen type 4"
<BenC> anyone know a direct contact for amd64 kernel bugs?
<Riddell> pitti: yep
<pitti> Riddell: http://people.ubuntu.com/~pitti/langpacks/
<pitti> Riddell: I built main/gnome for de and main/gnome/kde for fr
<pitti> Riddell: I don't expect any breakage, but testing can never hurt at this stage :)
<mdz> oh
<mdz> mjg59: I think bogl needs the same fix you did to usplash
<mdz> mjg59: for dpkg-architecture or such
<mdz> I wonder how many other  LURKING EVIL BUGS there are from that
* mdz glares at Keybuk
<mdz> mjg59: do you have that patch handy?
<mdz> bah, I bet he's asleep
<mdz> DEB_BUILD_GNU_CPU is what I assume it wants
<Riddell> pitti: is there any change or just updates?
<pitti> Riddell: no structural changes, just updated translations
<pitti> language-pack*-de works fine for me
<pitti> Riddell: awaiting your confirmation, then I can upload the lot
<mdz> Kamion: ok, fixed bterm
<Riddell> pitti: working here
<pitti> Riddell: thanks
<pitti> mdz: ok, a 250 MB worth of language pack upload waits for me pressing Enter
<pitti> mdz: is acknowledging so many packages manually fine for you? or do you temporarily enable uploads again?
<Riddell> pitti: is changing kde-i18n-xx to depend on language-pack-kde-xx the right thing to do (post preview)?
<mdz> pitti: note that all uploads require manual approval currently
* mdz reads his screen now
<mdz> pitti: it is fine
* pitti pulls the trigger
<dholbach> good night guys
<ajmitch> mdz: universe has an exception there, I hope?
<ajmitch> I'd hate to flood your queue with universe stuff
<mdz> ajmitch: only applies to main
<ajmitch> ok, great
<pitti> mdz: ok, I have the sizes of the old packs, and as soon as they have built, I will record the sizes of the new ones; then I can fill up the CDs if there are no objections
<mdz> pitti: I assume this pkgstriptranslations needs to go in as well?
<pitti> mdz: Kamion said it was not preview critical; it just disables stripping of debconf-i18n
<pitti> mdz: OTOH, it does not change any code, just the blacklist, so it won't hurt either
<TheMuso> c
<mdz> Kamion: bogl uploaded
<mdz> Kamion: I'm also going to change casper to use reset, to handle the non-fb case more gracefully
<pitti> mdz: upload rave finished
<mdz> pitti: oh, there were more?
<mdz> I already processed the ones which were in the queue
<pitti> mdz: the script just finished, yes
<mdz> damn
<mdz> I already ran cron.daily
<zul> night night
<pitti> night zul
<seb128> hey pitti
<seb128> pitti: you have updated the language-packs?
<pitti> seb128: yes, just pulled, generated, uploaded, still hot and fresh :-)
<seb128> pitti: you rock :)
<Riddell> cdimage.ubuntu.com doesn't want to let me connect
<pitti> seb128: thanks :-) I didn't want to be the preview blocker, so I grabbed a taxi back home
<pitti> Riddell: seems to WFM
<Riddell> WFM?
<elmo> works for me
<seb128> pitti: oh, you were out and went back specially for that ? :(
<Riddell> works remotely but not locally with any web browser
<Kamion> mdz: rock on
<Kamion> mdz: can I upload usplash? it works on powerpc now
<Kamion> (I'm IRCing from a live CD booted with usplash working perfectly)
<Kamion> so presumably having fixed the problem on three fronts it might actually go away
<Kamion> I haven't tried out the chvt hack yet
<mdz> pitti: ok, all processed now
<mdz> Kamion: can I see the diff?  is it a noop on non-powerpc?
<pitti> cool
<mdz> Kamion: new bogl udebs should be in the archive at :33 with a little luck; can you turn the d-i crank at that time?
<mdz> hmm, looks like it may not make it actually
<mdz> nm, there they are
<mdz> in unchecked now
<Kamion> mdz: http://people.ubuntu.com/~cjwatson/tmp/usplash-powerpc.diff
<Kamion> mdz: it's a no-op with the exception of the extra centring code
<Kamion> which is relatively obviously a no-op iff bogl_xres == 640 && bogl_yres == 480
<Kamion> (which should always be true on vga16fb)
<Riddell> Kamion: is the kubuntu iso build still going?
<Kamion> Riddell: no, because I was waiting for kubuntu-meta binaries to arrive in the archive
<Kamion> Riddell: I've started it now
<Riddell> groovy
<Kamion> mdz: doesn't that "static int quit" in bterm need to be "static volatile int quit"? You're modifying it from a signal handler.
<Kamion> although the two tests are probably far enough apart that the optimiser won't decide not to retest quit
<mdz> Kamion: it probably should be, yes
<Kamion> mdz: the chvt hack doesn't work very well (I end up on tty2 with the previous contents still visible), but I assume it doesn't matter any more since you've fixed bterm
<Kamion> d-i building
<Kamion> mdz: if I do 'while killall bterm; do sleep 1; done; chvt 2; chvt 1', it almost works, but I get "Bummer, could not run '/sbin/debian-installer': No such file or directory" just above "Starting Ubuntu"
<Kamion> a more elegant loop would probably avoid that most of the time, but it's probably not worth it
<mdz> Kamion: I've this nagging feeling that we ought to be waiting for bterm to exit
<mdz> though I suppose the worst that would happen would be losing some early console messages
<Kamion> if that's the worst, we can sort it out post-preview
<Kamion> I tend to agree with you that we should be waiting
<Kamion> I've uploaded usplash with that powerpc patch; approve/deny as you see fit
<mdz> it should exit very quickly anyway, since I check immediately after the select
<lamont-away> pitti: which machine?
* lamont-away will look at vernadsky shorlty
<pitti> elmo: oh, we have 4 NEW language packs, I just seeded them; can you please NEW them?
<pitti> lamont-away: I just noticed vernadsky, I didn't check the other ones
<jbailey> mjg59: http://people.ubuntu.com/~jbailey/usplash.tgz has a usplash that allows runtime replacement of the png.  The png requires a bit of prep, not much.  And, erm, please forgive the kubuntu logo. =)
<ogra> heh
<elmo> pitti: nothing in NEW
<pitti> elmo: hmm, I got 4 mails (gnome-ku, gnome-ku-base, kde-rw, kde-rw-base)
<pitti> elmo: but maybe mdz already processed them
<pitti> thanks anyway
<mdz> pitti: I processed both the new and non-new packs
<pitti> ah, thanks
<mdz> Kamion: you tested your patched usplash on non-powerpc? or do I need to?
<Kamion> pitti: btw, please tell me when you add new language-pack-* (I don't care about new language-pack-{gnome,kde}-* if there was already a corresponding language-pack-*), because I need to update the choices list of base-config/language-packs when that happens
<Kamion> mdz: haven't yet, can do so on i386 in just a few minutes
<pitti> Kamion: ok, will do; the two mentioned above already had language-pack-*
<mdz> Kamion: d-i finished yet?
<lamont-away> pitti: I'll check all of them.
<tritium> mdz, are you in the San Jose, CA area?
<pitti> lamont-away: did you find the reason on vernadsky?
<mdz> tritium: no
<pitti> lamont-away: the export might not actually be broken, but I wonder why pkgstriptranslation is not called
<tritium> mdz, okay, thought you were, and I'm on travel here
<mdz> I don't actually know any Ubuntu folk in the bay area, though I'm sure there are some
<lamont-away> pitti: only vernadsky was disabled
<lamont-away> pitti: odds are we rebuilt the chroot.. that or your package overwrote the config file... :-)
<tritium> I guess I was confused ;)
<mdz> Kamion: presumably x<640 or y<480 were already hopeless before you touched it?  does it bomb out somewhere if that's true?
<elmo> I assume I should process this d-i?
<pitti> Hi daniels
<elmo> kamion/mdz: ^--
<mdz> elmo: please
<bddebian> Ah, elmo is still here..
<mdz> Kamion: btw, awty now knows how to peek at jackass too
<daniels> pitti: morning
<daniels> Kamion: btw, feel free to release when you feel like it
<elmo> (done)
<mdz> Kamion: happy to roll in the new usplash once you've verified it on i386
<mdz> man down
<elmo> turn the boat around
<mdz> Riddell: did Kamon trigger new kubuntu livefs builds for you too?
<daniels> elmo: 'if you kids don't shut up, I'm turning this bloody boat around!'
<mdz> Riddell: or do I need to do so?
<elmo> daniels: dude, we lost the first mate
<bddebian> Uhm down boys and girls :-)\
<bddebian> elmo: Did you happen to see my note about debtags et al?
<pitti> mdz: ok, new langpacks are in the archive
<mdz> elmo: talked to colin; he's offline and also done for the night
<mdz> new casper is in too
<mdz> I'll roll new CDs
<pitti> mdz: I checked and compared their total size, it's only 3 MB smaller than the previous set, so seed adjustments are not worth the trouble IMHO
<elmo> mdz: pfft, what a part timer
<elmo> bddebian: can you mail me?  I'm disinclned to do universe syncs tonight
<pitti> mdz: unless there is something urgent, I'd go to sleep now; my mobile is on in case of another emergency :-)
<bddebian> elmo: NP, thx
<mdz> pitti: good night
<bddebian> elmo: @ubuntu email or other?
<mdz> I think I'm probably going to wait for europe to wake up before even considering a release
<pitti> mdz: will test images tomorrow morning
<mdz> I'll test overnight
<elmo> bddebian: @ubuntu or @canonical is fine
<pitti> yes, that would be nice
<pitti> good night!
<mdz> elmo: if you want to plan to be around for the release, now would probably be a good time to sleep as well
<elmo> mdz: ok
<tseng> jdub: does planet eventually blacklist me if the server is down?
<mjg59> Gosh, lots of usplash stuff
<mjg59> jbailey: Riddell: I'll check over the runtime replacement stuff in the morning, if that's ok?
<mjg59> mdz: The dpkg-architecture patch was just to add i486 to the list where it should be using vga16
<mdz> mjg59: did that oo
<mdz> too
<Gman_> mjg59, thoughts on toshiba laptops?
<mdz> mjg59: it also seemed to exchange DEB_HOST_ARCH with DEB_HOST_GNU_CPU or whatever
<mdz> I just mimicked what usplash did, and it seemed to work 
<mdz> infinity: around?
<infinity> mdz : Yup.
<mdz> infinity: cron.daily is finishing up, with a new ubuntu-meta.  if we could get the powerpc binaries uploaded in time for :03, that would save me some time
* infinity goes to hunt them down.
<mdz> should be showing up in wanna-build momentarily
<infinity> 0.70?
<mdz> non-powerpc architectures are unimportant
<mdz> yes
<infinity> katie has a lock right now, so your timing is impeccable.
* infinity waits.
<mdz> should be done now
<mdz> infinity: are you equipped for CD testing?
<mdz> this set is looking pretty compelling so far
<mjg59> Gman_: Most of them seem ok - there's minor problems with a couple of the Tecras at the moment, but I'm optimistic
<tritium> Gman_, we're working the Tecra issues...
<Gman_> mjg59, was thinking about getting a tecra m3
<Gman_> they seem light, and have a decent battery length
<jsgotangco> the Tecras don't reboot atm
<jsgotangco> heh
<jsgotangco> but overall all function swork
<infinity> mdz : Uploaded.  As for CD testing, I'm equipped, but low on bandwidth.  We have a full mirror, if you're generating jigdo files.
<Gman_> jsgotangco, good to know
<mdz> infinity: jigdo files are available
<mjg59> Gman_: At the moment, we seem to have problems with them rebooting if the ipw2200 driver is loaded
<mjg59> Other than that, things should work fine
<tritium> Well, the Tecra A2 reboots if you don't enable ipw2200 ;)  (but that's no fun)
<mjg59> I'm looking into that - it may be easy enough to fix in the ipw2200 driver
<mdz> I need to roll new live CDs due to a powerpc issue, which is what ubuntu-meta was about
<infinity> <nod>
<mjg59> mdz: When are we aiming for preview?
<mdz> but the install CDs are untested as yet
<mdz> mjg59: 8 Sep
<jsgotangco> oohhh
<jsgotangco> that's a few hours from now
<jsgotangco> (its already sep 8 here)
<tritium> Well, I only had 48 oz. of beer tonight.  I have a few more hours of testing left in me...
<Gman_> mjg59, ipw220 being the wireless driver?
<mjg59> Gman_: Yeah
<infinity> I can't test on powerpc, due to my PPC machine being unable to boot from CD (ancient OldWorld G3 motherboard), but I should be able to test live on amd64 and live/install on i386.
<mjg59> Gman_: It seems to reboot fine if you unload it first, so I have a reasonable idea how it can be sorted
<infinity> Maybe install on amd64 too, if I can find some free space.
<mjg59> Gman_: Of course, if you're wanting to run JDS, I'll need to try to get these patches upstream :)
<mjg59> mdz: Cool.
<Gman_> mjg59, might well be running solaris it seems :/
<Gman_> mjg59, but just wanted to know if you had any swearwords for toshiba, but it seems not :)
<mjg59> Gman_: Unf. If you're running Solaris, all bets are off. 
<mjg59> ACPI works wonderfully under Linux, but...
<Gman_> mjg59, :)
<mdz> i386 and amd64 livefs seem good
<mjg59> (I hear you may have all sorts of internal magic, but still)
<Gman_> jsgotangco, you like the m2?
<jsgotangco> Gman_, i use an M2
<mdz> I'll only rebuild powerpc and then roll new live CDs which should be equivalent on amd64 and i386, and add usplash on powerpc
<Gman_> mjg59, the m2 works fine with solaris, or so i've heard
<mjg59> Gman_: I don't believe we've actually tested with an M3, but the rest of the Tecra range seems good
<mjg59> So unless they've switched the hardware, life should be fine
<Gman_> ok, cool
<jsgotangco> Gman_, the M2 generally works, although it has an upstream issue with the nvidia geforce go for external display
<Gman_> thanks heaps guys
<mjg59> Gman_: So, do you have working ACPI suspend with Solaris? :)
<Gman_> mjg59, apparently so, at least on the ferraris
<mjg59> Gman_: Wow. There's nothing public on that side of things yet, as far as I can tell.
<daniels> yeah, the acer ferrari stuff seems to be the flavour of the month at solaris
<mjg59> (nnngh Acer)
<jsgotangco> gaahh
<jsgotangco> the carbon fiber model looks rad though
<mjg59> I will be greatly amused if Solaris supports Acers out of the box
<Gman_> mjg59, how well it works, i don't know
<Gman_> mjg59, but it's starting to get integrated into nevada, which is solaris 10
<mjg59> Gman_: Well, there's little to no ACPI support in the Opensolaris tree
<mjg59> But it'd be nice if that improved
<mjg59> I only really run on laptops now - it'd be nice to be able to run Solaris
<Gman_> think it's either recent, or well, just a bunch of hacks
<mjg59> Heh
<mjg59> What /would/ be nice would be if we could cooperate with Sun over this
<Gman_> part of frkit
<mjg59> It'd suck to have to be clean-rooming each others source to figure out which bugs we're working around
<Gman_> yeah :/
<mjg59> (I'm entirely happy to work with CDDL guys over this sort of stuff)
<Gman_> there's talk of either a device driver or x86 community being started
<Gman_> so that may help being more public about it
<mjg59> Ok, cool
<jdub> i love being a turtle
<diego> this has probably been asked about 300 times today, but is the preview release on schedule?
<jdub> diego: yep!
<mdz> new install CDs building, to get usplash/powerpc
<diego> jdub: nice, on schedule enough to give me an estimated time?
<mdz> diego: that has less to do with the schedule than whether we find any last-minute problems
<mdz> diego: and we find those faster the more people test ;-)
* mdz kicks jigdo in the groin
* diego dives and saves jigdo's balls the pain
<diego> well, good luck and have fun then, I can't wait to try it out
<jdub> mdz: bonus, i'll have to do a test install on my toilet seat
<mdz> jigdo adds an extra 30 minutes to each install CD build cycle
<ficusplanet> jdub, Is "The Fridge" launching with Breezy's final release or the preview?
<jdub> ficusplanet: on the anniversary of warty's preview release, our first public outing :-) (so, in between)
<mdz> it will be another 1.5 hours before I have a set of CDs with the known bug fixed, though it was fixed 20 minutes ago
<jsgotangco> mdz, i know this is asking too much but is there any chance can we extend the documentation freeze?
<ficusplanet> jdub, Ah, cool.
<mdz> jdub: please do; I'll shout when the CDs are ready
<jdub> mdz: ok
<mdz> jsgotangco: extend it?  it lasts until the final release
<mdz> it wouldn't make much sense to extend it beyond that ;-)
<jsgotangco> mdz, err you mean we don't have a freeze?
<ajmitch> jsgotangco: you want the freeze shortened, right?
<mdz> jsgotangco: I mean that today, we begin a freeze period during which we avoid changes which would require documentation updates
<jsgotangco> ok i got the freeze right then
<mdz> are you saying you want it to start sooner next time?
<jsgotangco> no no
<jsgotangco> i was just thinking about the translators
<jdub> http://atomchip.com/_wsn/page4.html <- heh
<jsgotangco> because some of our docs are still quite unpolished
<jsgotangco> we all thought we stop writing on the 8th
<mjg59> heh
<mjg59> Someone at zdnet.com.au reads planet Debian
<mdz> jsgotangco: oh, that aspect of the freeze
<mdz> jsgotangco: yes, that was also part of the plan, to give translators time to translate documentation
<jdub> mjg59: brendon or renai?
<mjg59> Dunno
<mjg59> Ooh
<mjg59> Someone in Progeny read dccalliance.biz
<jdub> haha
<infinity> Yay!
<jdub> just wait until they attack you with their TRADEMARK DOGS OF WAR!
<mjg59> jdub: As "Bruce" pointed out to me earlier, we have no right of parody
<jdub> oh, the prank call?
<mjg59> Heh
<mjg59> Yes
<mjg59> That was fun
<jdub> dude, you totally need to get your hands on one of these QUANTUM LAPTOPS
<mjg59> "Why has Bruce suddenly gained a London phone number and a strange accent?"
<jdub> with ATOMCHIP
<wickedpuppy> anyone ever got error while booting like "Kernel Panic , init not found" ??? I passed init=/init to kernel but still having this error
<jay> you don't have to pass init.  you need to make sure root= is right htough
<jay> err i thought this was #ubuntu
<wickedpuppy> i did ask in #ubuntu
<jay> better place for that question ;)
* infinity refreshes /main/ on his mirror, while he waits for mdz's CD builds to finish up.
<wickedpuppy> i know this is devel chan sorry ... but nobody reply me there
<whiprush> jdub: http://slashdot.org/comments.pl?sid=161495&cid=13505179
<whiprush> heh
<tritium> jdub, any stops on your U.S. tour set yet?
<jsgotangco> yes 2.12 is out
<mdz> jsgotangco: the idea was to give more time for translating documentation, since it takes a long time to translate
<jsgotangco> mdz, ok got it we have 2 docs ready atm we'll cook up a release notes later
<tritium> jsgotangco, is there any doc/translation work in Tagalog that my wife could help out with?
<jsgotangco> tritium, sure we had tl for hoary
<jsgotangco> we'll make po files
<tritium> jsgotangco, I'll see if she'd like to get involved in that capacity
<jsgotangco> tritium, it's hard heh
<tritium> the work?  or the convincing?
<jsgotangco> the actual work, there is just not enough good tl words for technical docs
<jsgotangco> debian-tl is doing good progress though
<tritium> Oh, that makes sense
<jdub> tritium: see the wiki page for people who've told me about their petitions so far :)
<jdub> whiprush: ha ha ha ha ha ha
<tritium> jdub, okay, thanks.  I'd like to get you to come to Albuquerque to talk at Sandia if I can generate a good amount of interest
<crimsun> jdub: yeah don't worry, we want you to speak at red hat hq, too =)
<jdub> tritium: do a petition that isn't just blog comments :-)
<jdub> crimsun: yes, that was an amusing one :-)
<tritium> jdub, okay...I'm working on it
<jdub> crimsun: i have full encouragement from the power that be (singular, sabdfl) to go ;-)
<crimsun> jdub: c'mon down
<crimsun> (or up, I suppose?)
<jdub> very up, at least geographically ;)
<diego> good night all
<crimsun> :)
<daniels_mobile> Telstra suck.
<infinity> s
<daniels_mobile> ...
<jsgotangco> and expensive
<daniels_mobile> Yes. And screwing up our lines as I speak.
<daniels_mobile> Yay for WAP to IRC gateways.
<daniels_mobile> Should really get my laptop down with GPRS through my phone, too.
<infinity> WAP-to-IRC is just so wrong.  Maybe it's time to put down the phone and back away from IRC.
<infinity> I may just have the technology to, y'know, phone you if you're needed.
<daniels_mobile> So X hasn't exploded and killed preview? Good news.
<infinity> ... yet.
<daniels_mobile> If only someone came up with a way to use the mobile phone for voice communication!
<bob2> you could do voip over IRC over WAP
<infinity> bob2 : Why are you still allowed to breathe?
<bob2> it's my wit and charm
<infinity> Oh look, the new dailes hit cdimage, finally.
<infinity> dailies, too.
<daniels_mobile> Don't knock it, it's a good idea.
<infinity> mdz : Are we hoping this one is good enough to be released unchanged as preview?
<mdz> infinity: unfortunately not, since I forgot to update the label
<infinity> Huzzah.
<mdz> there goes another 70 minutes, thanks jigdo!
<infinity> But other than that? :0
<daniels_mobile> Yay.
<mdz> I successfully installed the last one on amd64 and powerpc
<mdz> this one is basically unchanged on i386 and amd64,
<mdz> and only adds usplash on powerpc
<mdz> new live CDs are building now, same story
<infinity> Alright.  I'll jigdo it and pound it a bit, but unfortunately not on powerpc.
<mdz> after that, I'll do another install build just to get the labels right
<daniels_mobile> Seeing if sync ranges get written out when they shouldn't would be rad.
<mdz> daniels_mobile: the current CDs have the latest xorg and would be suitable for testing that
<infinity> daniels_mobile : under what circumstances would I expect that to happen?
<daniels_mobile> Infinity - monitors with DDC. But shouldn't happen.
<daniels_mobile> On i386 or powerpc. Not and64.
<daniels_mobile> My Pegasos can be used but it takes a fair bit me work and net boot.
<daniels_mobile> T9 can blow me.
<infinity> Mmm, local mirror + jigdo = love.
<daniels_mobile> BBL.
<mdz> new PREVIEW CANDIDATE live CDs are up
<mdz> http://cdimage.ubuntu.com/daily-live/current/
<infinity> amd64-OVERSIZED ... That looks healthy.
* fabbione rsync
<fabbione> morning guys
<infinity> Hrm.  Is there no clever way to do jigo-ish stuff for livecds?
<desrt> preview candidate? :)
<desrt> morning fabbio
<fabbione> desrt: yo
<fabbione> are install cd up too?
<jsgotangco> hmmm
<jsgotangco> yay
<mdz> infinity: yes, we call it "rsync" :-P
<hmrocha> hello
<mdz> fabbione: yes, but not candidates yet
<mdz> wrong iso label
<hmrocha> i'm having a big trouble with ubuntu
<mdz> so we wait for jigdo another hour
<hmrocha> i trying to deploy ubuntu in all pc's of my faculty
<fabbione> mdz: ok
* fabbione skips install 
<mdz> hmrocha: I appreciate your situation, but this channel isn't the right place to ask for help (see the topic)
<hmrocha> ok, sorry
<hmrocha> i thought developers could help me more easily
<hmrocha> because i think you're the ones that decided to make this like it it
<mdz> hmrocha: the developers are busy preparing the preview release
<mdz> hmrocha: feel free to ask your question if you want to know the reason why something is as it is, but if you need technical support, it needs to be elsewhere
<hmrocha> why only the users in group audio can play audio?
<hmrocha> i changed all files in /dev to group students, but they still can't use totem to play files
<mdz> because it is a security vulnerability to allow everyone access to audio devices
<hmrocha> all files that had group audio
<mdz> add your students to group audio
<hmrocha> the students are stored in AD
<hmrocha> its not very easy
<hmrocha> AD == Microsoft Active Directory
<hmrocha> there are no users in the machines
<mdz> add the users to group audio in active directory, then
<hmrocha> hmmm, i don't know how to do that, but i'll look into that
<hmrocha> thanks
* lamont -> sleep
<mdz> mjg59: around?
<mdz> who here has a laptop with a funky widescreen LCD?
<mdz> 1280x800, that sort of thing
<mdz> infinity: can I get a copy of the patch daniel gave you, via email?
<bob2> jblack has some widescreen sony horror if you're desperate
<mdz> infinity: he just called and explained
<mdz> bob2: I think he's likely to be asleep
<bob2> pretty sure his sleeping pattern is on par with you atm ;)
<ajmitch> he was around a few minutes ago
<jblack> I hear you're asking for people with weird screens.
<mdz> jblack: exactly
<infinity> mdz : See this snippet for how it works:
<infinity> mdz : http://cerberus.0c3.net/~adconrad/resolutions.sh
<mdz> in a bit, we'll need some testing done
<jblack> I have a dual-head setup that gives me something like 3360 x 1024
<infinity> mdz : I'm patching zorg itself right now (but that shell script proves the fix)
<infinity> s/zorg/xorg/
<mdz> infinity: wouldn't it be simpler to use sort -n |uniq ?
<mdz> s/wouldn't it/it would/
<mdz> jblack: I mean an actual display with a funny size, like a widescreen laptop
<jblack> The lcd itself is 1920x1200
<mdz> jblack: perfect test case
<jblack> The lcd on the laptop is 1920x1200. The attached monitor, giving dual head, is 1600x1024 or some such.
<mdz> 1920x1200 is one of the modes that is affected
<jblack>  What do you need, exactly? 
<infinity> mdz : Yeah, sort -nr | uniq should do the same thing.  This was the crack daniels fed me over the phone. :)
<infinity> mdz : Your choice, either can be uploaded in a matter of seconds.
<infinity> mdz : The former fix is already signed and waiting, mind you.
<mdz> infinity: sort -nr |uniq is more readable and intuitive
<infinity> Alright, will re-roll with that, then.
<mdz> though, your version does seem like it might sort differently
<infinity> Oh, wait.
<infinity> Yes, I just noticed.
<mdz> does sort -nr get the x,y ordering right?
<infinity> sotr -nr | uniq will get the y out of order.
<mdz> ok
<mdz> infinity: please send a debdiff to me
<infinity> Daniel's crazy invocatoin seems to get both in order.
<infinity> Sent.
<mdz> infinity: ok, let's do it
<infinity> Uploading.
<infinity> Here, katie, katie, katie.
<jblack> What did you guys need from me?
<mdz> jblack: I need you to test the current live CD and confirm the bug, and then test a new live CD with a fix in about an hour
<mdz> jblack: http://cdimage.ubuntu.com/daily-live/current/
<jblack> If I went to sleep now, I'd get 5 1/2 hours of sleep. If I download a cd an hour from now, that'll be... 4 hours of sleep.
<jblack> I suppose I can do that.
<infinity> Sleep is for the weak.
<bob2> s/weak/!week/
<infinity> Besides, I'm not allowed to sleep at all next week, I suspect, so you can sacrifice some time this week. :)
<jblack> Hopefully somebody will remember the next time I ask for help with ubuntu.
<mdz> jblack: if you can't do it, you can't do it, but so far you're the only person we've found who can test this propely
<mdz> jblack: your call
<jblack> Better somebody internal gets a fritzed laptop then 10k people on the outside. Lets be a team. =) 
<infinity> Hey there, daniel's phone.
<daniels_mobile> infinity: to confirm.
<mdz> infinity: accepted, will be picked up at :33
<infinity> You need to stop thinking on public transport.  Bugfix-by-phone is... Just wrong.
<mdz> jblack: it's definitely not a risk to your laptop
<jblack> Oh, ok. 
<mdz> it's just booting a live CD to test the X autoconfiguration
<infinity> daniels_mobile : I cobbled upa quick shell script to test the fix, and it seems to DTRT, packages rolled, uploaded, and ACCEPTED, will build at :33.
<daniels_mobile> sort -u -t x -k 1,1nr -k 2,2nr
<jblack> You never know. That acpi problem that the upstairs laptop caused the mini-laptop upstairs to break for a month. 
<daniels_mobile> Excellent.
<infinity> daniels_mobile : Yeah, except my -u is at the end of the argument list, not the beginning.  Makes no difference, though.
<jblack> I ended up having to pull the battery and power and let the battry drain to get it to boot again.
<mdz> infinity: need a keyboard break; send me an SMS when the binaries are uploaded
<infinity> daniels_mobile : But yea, I didn't really trust my ears, hence the shell test first.
<jblack> internal cmos battery.
<infinity> mdz : Does your phone accept email?... I have nothing to SMS from here. (girlfriend has the mobile phone)
<daniels_mobile> OK, that's fine. Thanks.
<infinity> mdz : Meh, I'll just direct dial and hang up. :)
<infinity> daniels_mobile : What got uploaded was this: "sort -t x -k1,1nr -k2,2nr -u" ... So, except for formatting, you're spot on.
<infinity> daniels_mobile : We experimented with "sort -nr | uniq", until we realised that got the Y component of X,Y out of order in some cases.
<daniels_mobile> Mad phone skills.
<daniels_mobile> Right. This sorts by the first part before the x ...
<infinity> daniels_mobile : Yeah, I deciphered what it did while I was testing it. :)
<daniels_mobile> ... then by the component after x as a tie break.
<infinity> daniels_mobile : Mostly cause I have issues randomly changing code I don't understand, so I... Uhh.. Don't until I understand it.
<daniels_mobile> Heh.
<infinity> 3 hours of silence on breezy-changes, and then one lone xorg upload.  You must be so proud.
<bob2> hm, I've never lasted until preview before dist-upgradeing
<daniels_mobile> I win at the last-minute upload game!
<jsgotangco> the last minute upload borked my resoultion =)
<daniels_mobile> WHAT?!?
<jsgotangco> Nvidia GeForce Go 5200 blurry rez at 1024x768
<infinity> Not the same last minute upload.
<jsgotangco> ahh
<infinity> The one we're talking about hasn't built yet.
* jsgotangco patiently waits for xorg salvation
<daniels_mobile> I'd love more details on that. Actually ... I see why. I think.
<infinity> daniels_mobile : Don't even start thinking about another upload.
<infinity> daniels_mobile : Or, if you do, do it QUICK. :)
<daniels_mobile> Set DEBUG_XORG_PACKAGE=yes, and just dpkg -i it. If my hunch is right, you'll get 'not probing; writing out sync ranges'.
<daniels_mobile> If so, only affects upgrades, so we don't need to block preview on it. Simple fix.
<infinity> jsgotangco ---^
<jsgotangco> hmm hold on
<daniels_mobile> 'it' is the xserver-xorg package, in this case.
<infinity> And we're finally building.
<jsgotangco> daniels, humans 1 xorg 0
<daniels_mobile> So it says that?
<jsgotangco> it does
<daniels_mobile> Excellent. Easy fix. Only bites upgrades, not new installs, so not preview-critical. Will upload after preview's released.
* jblack checks in
<daniels_mobile> Thanks for testing. I'll BBIAB.
<jblack> I dn't have anything to test? 
<infinity> jblack : Well, did you test the current live image?
<infinity> jblack : To confirm that it doesn't offer you the right res?
<jblack> I haven't done anything. I'm still waiting for instructions
<infinity> Oh, feh.
<infinity> jblack : We wanted you to test the current live image to confirm that it doesn't offer you the res you want/need (1920x1200, right?)
<jblack> Correct.
<infinity> jblack : Then, shortly, once we've built new livecd images, test again to make sure it does.
<jblack> What do you mean "again".
<infinity> As in, download the new image and re-test.
<infinity> To make sure we've fixed the bug.
<infinity> (Though we're pretty sure we have anyway)
<jblack> I know you guys want me to test two livecds, but I don't know what special place they're in and what you specifically want me to test (though I surmise "yeah, x runs" is sufficient
<infinity> http://cdimage.ubuntu.com/daily-live/current/
<jsgotangco> oh!
<infinity> The livecd from there right now is the one that should give you an incorrect resolution (or just not work at all, depending on how stubborn your laptop is)
<infinity> jblack : And the livecd from that same source in an hour or two should be the "fixed" on.  mdz will let you know when that is.
<jblack> Downloading [   ]  breezy-live-i386.iso            08-Sep-2005 05:33  650M  Live CD for PC (Intel x86) computers (standard download).
<jblack> eta is 36 minutes
<infinity> Danke.
<jblack> make that 40.
<jdub> mdz: ppc install is up?
<infinity> jdub : Yes, but not the final test images (still waiting on the new xorg to build for that)
<infinity> jdub : If your resolution isn't some oddball one, test the current image, nothing will change for you with the new one.
<jblack> _just in case_ I don't come back, somebody please tell steva where I went.
<infinity> jblack : Heh.
<mdz> infinity: looks like it's installed on i386 and amd64; what's powerpc's excuse?
<mdz> jblack: I gave you the download URL
<infinity> mdz : adare is still building.
<mdz> jblack: an hour ago
<infinity> mdz : Watching it like a hawk, will upload as soon as it's done.
<jblack> Hmm. My screen didn't mark it that you spoke to me. did you put jblack: in front of it? 
<jdub> infinity: grab the image currently in current? :)
<infinity> Aye.
<jdub> tops
* jdub twangs the string between his tin cans
<mdz> Sep 07 22:22:57 <mdz>   jblack: I need you to test the current live CD and confirm the bug, and then test a new live CD with a fix in about an hour
<mdz> Sep 07 22:23:13 <mdz>   jblack: http://cdimage.ubuntu.com/daily-live/current/
<ajmitch> latest daily is the same as the one you want tested, then?
* ajmitch is trying to rsync now
<mdz> ajmitch: only if you have a funky LCD
<mdz> otherwise, we need you to test the next one
<jblack> And there it is
<jblack> Sorry. Missed it.
<ajmitch> ok, mine's normal, I'll test the next one then
<jdub> mdz: ooh, ia64 status query coming in on u-d ;)
<infinity> mdz : powerpc uploaded.
<infinity> If you don't feel like a manual corn.daily, it'll go in at :33, I guess.
<infinity> cron, too.
<infinity> Mmm, daily corn.
<mdz> infinity: cron.daily running
<mdz> jdub: there is a ppc install up, but it isn't a candidate for final
<mdz> it works though
* jdub does a massive s/final/preview/ on the channel
* jdub stops downloading the ppc install cd to one of the gnome servers, logs out to do it on his laptop
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with breezy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://www.ubuntulinux.org/wiki/DeveloperResources | Colony 4 is released: http://cdimage.ubuntu.com/releases/breezy/colony-4/ | https://wiki.ubuntu.com//HelpingWithBugs | MOM/NDA producing bad diffs | Preview freeze in effect; no uploads to main without prior approval | Please test http:
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with breezy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://www.ubuntulinux.org/wiki/DeveloperResources | https://wiki.ubuntu.com//HelpingWithBugs | MOM/NDA producing bad diffs | Preview freeze in effect; no uploads to main without prior approval | Please test http:
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with breezy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://www.ubuntulinux.org/wiki/DeveloperResources | https://wiki.ubuntu.com//HelpingWithBugs | MOM/NDA producing bad diffs | Preview freeze in effect; no uploads to main without prior approval | Please test http://cdimage.ubuntu.com/daily{,-live}/
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with breezy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://www.ubuntulinux.org/wiki/DeveloperResources | https://wiki.ubuntu.com//HelpingWithBugs | MOM/NDA producing bad diffs | Preview freeze in effect; no uploads to main without prior approval | Please test http://cdimage.ubuntu.com/daily{,-live}/current/
<daniels> bloody hell.
<daniels> now, I'm not a telecommunications engimaneer.
<daniels> but I can tell you that if you have two pairs of phone line coming into your house, you're not going to be able to put three lines on it.  thankyou, telstra.
<jsgotangco> =)
<daniels> infinity: probably too late, but there's a recent-ish livecd kicking around on brainfreeze, either ~daniels/canonical/d-i, or ~daniels/canonical/livecd.  amd64.
<jdub> daniels: isdn
<jdub> quite easy, really :-)
<infinity> daniels : Who said anything about 3 lines?... I though they were doing two voice + 1 DSL?... Or was the DSL supposed to be on a dry pair, not on one of the voice lines?
<infinity> daniels : Or was it going FROM that to 3 voice + DSL?
<pitti> hi
<ajmitch> hi pitti 
<pitti> Hi Kamion 
<pitti> Hi ajmitch 
<ajmitch> & Kamion 
<mdz> morning folks
<infinity> Ooo, the cavalry has arrived.
<mdz> Kamion: candidate build is in progress after a xorg bugfix
<mdz> ppc usplash works for me
<mdz> successful amd64/powerpc install/live on the last set of CDs
<mdz> could use some i386 success reports from the channel
<daniels> jdub: well, we have one phone line coming in right now, plus dsl.  they were trying to get a second line in, but didn't realise that this may possibly require a third pair.  so I had no landline or DSL for most of the day.
<infinity> i386 will be happening on my laptop when I'm sure I can stop caring about last-minute builds and start rebooting. :)
<daniels> infinity: the DSL is supposed to be on a dry pair
<mdz> infinity: all the builds are in as far as I can tell?
<infinity> daniels : Ahh, kay.  Not used to that anymore, since all my DSL in Australia has been Data-over-voice... Though all my DSL lines in Canada were dry pairs.
<infinity> mdz : Yup.  And livefs builds are going/good?
<mdz> daniels: do you know what this report of a missing module section in xorg.conf on -devel is about?
<mdz> infinity: going
<Lathiat> daniels: ...you have dsl on a second pair?
<infinity> Oh, look, ia64 caught up.
<mdz> install CD build in progress, livefs builds in progress, live CD build queued
<Lathiat> daniels: never seen that before
<Lathiat> that just doesnt happen here.
<mdz> Kamion: we need to do something about jigdo before final
<mdz> this is just silly
<daniels> Lathiat: we have weirdo dsl.  nextep provisioned it themselves, bypassing telstra.
<daniels> mdz: there's code to explicitly handle that case in current xorg; it's a hangover from a single bad version earlier on in breezy.
<daniels> mdz: so if it's still happening now, today, I'll be surprised.
<pitti> mdz: oh, how long until the candidate build? I just download the current daily, but if it arrives fast, I rather wait for some minutes
<mdz> daniels: report was 05 sep
<Lathiat> daniels: oh right
<mdz> pitti: about one hour
<Lathiat> daniels: that happens here but they still use the voice pair
<pitti> mdz: ok, then I only test the live CDs in that time; no need to waste 45 minutes for an install then
<Lathiat> daniels: they just share it with telstra
<mdz> pitti: better to wait; there are new live CDs coming too
<mdz> and they have X changes
<pitti> ok
<daniels> mdz: i think that was roughly when I added the brute-force-you-will-get-your-goddamn-modules bit to .config, so we should be okay.
<mdz> Kamion: either jigdo needs to get faster, or we need to do it after publishing so that we don't have to wait for it
<pitti> mdz: is the live build already running? we need to downsize amd64
<mdz> jblack: any luck with that live CD?
<TheGodFather> mdz: i had say that live works fine :)
<mdz> pitti: no, it isn't yet
<jblack> downloaded image and starting to burn now
<pitti> mdz: ok, then let's quickly throw out 16 MB
<daniels> bbiab
<mdz> pitti: but it is too late to process new metapackages
<pitti> hm
<mdz> that takes an hour
<pitti> well, most people won't have a problem with 666 MB
<TheGodFather> mdz: other than the net setup that's pretty peculiar in my house
<TheGodFather> SCORE!
<mdz> TheGodFather: what's peculiar about it?
<infinity> pitti : Probably not worth worrying about for preview, almost eveyrone testing it will be using 700 MB blanks anyway.
<pitti> infinity: ack
<TheGodFather> essid (wifi)
<infinity> (Can you even BUY 650 MB blanks anymore?)
<TheGodFather> it's not broadcasted
<TheGodFather> so there is no way for the livecd to know it in advance
<TheGodFather> but the card was detected properly
<TheGodFather> cards actually---
<pitti> infinity: I don't see them in the shops here
<mdz> jdub: who moderated this impi post to ubuntu-announce?
<jblack> finalizing... about to reboot. anythhing needed other than a "yes, x starts" ? 
<jblack> mdz: ^
<jblack> infinity: ^
<mdz> daniels: how about the keyboard vs. kbd issue also on -devel in the past 24 hours?
<infinity> jblack : Erm, it gave you the right resolution?
<jblack> I haven't restarted yet. 
<mdz> jblack: the expected behaviour is "X starts with the wrong mode"
<jblack> Ok. 
<jblack> brb
<infinity> jblack : Oh, you're doing install, not live?
<pitti> mdz: for the record, I did a hoary->breezy upgrade and then I had "kbd" in xorg.conf
<jblack> infinity: live
<jblack> brb
<mdz> pitti: did it work?
<infinity> Oh, finalizing the CD image.  I'm retarded.  I thought you meant finalizing the install. :)
<infinity> jblack : Carry on. :)
<pitti> mdz: well, the gnome part didn't (#14895), but the X side seemed to be fine
<pitti> mdz: I will triage the bug a bit, but it rather seems to be a gnome bzg
<pitti> bug, even
<jblack> Ok. I'm in the first livecd
<jblack> I have 1920x1200 on the main monitor
<jblack> on the main lcd, that is
<mdz> that's disappointing
<infinity> That does seem odd...
<jblack> The attached monitor is in mirror mode at 1600x1024
<mdz> daniels: ^^^
<infinity> The livecd set it up that way by default?
<mdz> daniels: I expected this to be a good test case, since we have 1920x1440 and 1920x1200
<jblack> All I hit was enter three times and start up a shell to run xwininfo a few times and ssh into mercury to talk.
<dholbach> good morning
<pitti> Hi dholbach 
<dholbach> morning martin
<infinity> jblack : Weird.
<jblack> by the way, if anyone cares, there was an error during boot about debian-installer. I didn't see the error long enough to write it down.
<mdz> Riddell: kubuntu preview status?
<mdz> jblack: that's known
<jblack> I'm still in the livecd if you want me to look at things.
<mdz> jblack: /var/log/casper/post.log would be interesting
<jblack> should be at http://mercury.linuxguru.net/~jblack/post.log
<infinity> mdz : Hrm, maybe a laptop that only reports one available mode was a bad test. :)
<mdz> yeah, on further consideration the impact of this bug was probably smaller than we thought
<jblack> This screen used to do other resolutions back in windows.
<infinity> mdz : Note that DCRESOLUTIONS doesn't actually include his res in the list, but it gets used anyway, cause his display told us it was the only one it had.
<infinity> jblack : The windows drivers blindly ignore what the display claims to be able to do, and just gives you all the options BELOW the max option.
<infinity> jblack : And prays your display can stretch to accomodate.
<jblack> I say used to because something ate the hal dll and rather than reinstall windows resized the ext3 filesystem.
<mdz> infinity: is there still a point in having him test the new one?
<infinity> jblack : Not sure whose behaviour is really more correct, but we now should offer a very comprehensive list regardless (but default to your native)
<infinity> mdz : Getting a log from the new one would verify the bug is fixed, but in his case, both will (should) obviously work fine.
<jblack> If you don't need anything else from this one I'll switch back over so that I can get that rsync --partial started...
<infinity> mdz : The only reason it works on the livecd is because we never ask the debconf question.  Clever.
<jblack> where's reboot on this thing? 
<infinity> mdz : In any scenario where the question actually got asked, jblack would have been screwed (cause his resolution isn't in the select list)
<jblack> found it
<infinity> mdz : At least, that's how I'm reading this log.  We seed debconf with the list, then just set it to what we got from the earlier probe and ignore the list.
<infinity> mdz : If the probe had failed for any reason, he would have been presented with a list that didn't have his resolution in it, I assume.
<infinity> Either way, can't go back in time and unfix the bug, so let's just pretend it was urgent enough to postpone testing for a couple of hours and carry on, shall we? :/
<jblack> Also, reboot doesn't.
<Kamion> mdz: ok, just woken up and am catching up (the IRC client connection was automatic ...)
<mdz> jblack: works for me; can you be a touch more specific?
<infinity> jblack : DO you have an update-notifier or update-manager process spinning in the background, by any chance?
<infinity> jblack : Or anything at all in "ps ax" that looks like it's suspiciously stopping your session from closing?
<jblack> Ok. The lcd turns off, the monitor stays on and says something like ...[reboot]  on the bottom. I hold the power button for four seconds to turn the machine off, tap the power button to turn it back on.
<jblack> infinity: I'm back in my normal systme setup.
<infinity> Oh, it didn't apm/acpi reboot.
<infinity> That could be something specific to your laptop.
<jblack> Its undoubtedly an acpi problem. ubuntu on this machine was a nightmare on this machine for the last year.
<infinity> I'll have to test here and make sure the reboot gets tripped okay on my machine.
<jblack> I was getting over 100 megabytes a day of log errors at one point. 
<infinity> What kind of laptop is that?
<jblack> I eventually solved that with nolapic in grub's config. 
<jblack> Whether its still necessary, I don't know.
<infinity> And did you just accidentally volunteer to have us commandeer it for the entirety of UBZ?
<jblack> Its a Sony Vaio VGN-A190.
<jblack> I um... um.. I was looking for an excuse to buy a new baby laptop to replace the dying one in my bedroom, I guess? 
<jblack> For all I know you guys fixed it three months ago, though.
<jblack> btw, suspend to disk works, suspend to memory doesn't.
<infinity> mjg59 : Do we have a facility to fiddle things like turning local apic off and on, depending on system board DMI dumps on anything equally nasty/clever?
<jblack> suspend to disk _mostly_ works, actually. The docking station doesn't get powered back up if I suspennd to disk, take the machine out of the docking station, wake up, and put it back 
<infinity> jblack : yeah, I would expect that, after the bit about not being able to reboot, and requiring nolapic.
<infinity> (Expect that suspend to ram wouldn't work, that is)
<jblack> on the baby laptop upstairs, suspend to anything results in the machine coming back up, but the backlight stays off. 
<infinity> Suddenly, I feel pretty good about how well my hardware is supported.
<jblack> that one is a sony as well.
<jblack> anyways, I'm *not* complaining.;
<jblack> You guys do a great job. I'm happy with what I've got, and I'm not asking for help
<jblack> Do you guys want me to bring the docking station as well to ubz? 
* jblack get started on the rsync
<infinity> If it's not too much trouble, and someone has a chance to look at it, it may be educational.
<jblack> no problem at all. I'm driving, so I can load up
<jblack> I can even bring you a machine that xen can't handle if you wish. :) 
<infinity> Oh, rock on, then.  Bring whatever gear you can fit in the car, and if we have a chance to play with it, we will. :)
<jblack> that one is one of those 1st gen acpi machines. 
<jblack> Ok. I'll bring the minivaio (the baby one), which is on its very last legs, the ex-wife's compaq laptop (broken keyboard and cdrom), comet (the vgn-a190 you had me test) and ...what at one point was called rms. :) 
<jblack> the minivaio used to be the ex's too. She was hard on laptops.
<jblack> Oh, and I can bring another vaio as well. a....grv550. That's the daughters.
<jblack> let me get that rsync started.
<siretart> hm. has anyone been using ddd recently?
<siretart> moving window around makes it segfaulting for me (current breezy). will investigate further..
<jblack> starting:
<jblack> jblack@comet:~/Desktop$ rsync -B 65536 -v --partial rsync://cdimage.ubuntu.com/cdimage/daily-live/current/breezy-live-i386.iso  ./breezy-live-i386.iso
<jblack> 33%...
<jblack> 2/3...
<jblack> Hmmm. 
<jblack> The new livecd is exactly the same size as the old livecd? 
<jblack> jblack@comet:~/Desktop$ -rw-rw-r--    1 jblack jblack  681308160 2005-09-08 02:44 breezy-live-i386.iso
<jblack> -rw-rw-r--  1 jblack jblack 681308160 2005-09-08 03:41 breezy-live-i386.iso
<Kamion> has anyone tested an install on a wireless-connected machine? there've been some bugs about wireless configuration not being carried over to the second stage, and I'd like to make sure they're isolated rather than systemic
<Lathiat> Kamion: worked with colony 4
<Kamion> ok, that's probably good enough
<Lathiat> Kamion: stage 2 ? reboo t?
<Kamion> thanks
<Kamion> Lathiat: yes
<Lathiat> well i had wireless when i rebooted so
<Lathiat> i assume it worked
<Lathiat> interface was up, dhcpd
<Lathiat> i didnt specify a wep key or anything tho
<jblack> infinity: I get a md5sum of 250c5cd3443959f0deea7a43e7818893 on the new image, which has the same filesize as the old image.
<Lathiat> so its mostly default apart from knowing it asked for eth1 and dhcp
<Mithrandir> doko: do you have any idea about http://bugzilla.ubuntu.com/show_bug.cgi?id=14539 ?
<infinity> jblack : Not sure if there IS a new image yet.  You'd have to ask mdz.
<jblack> mdz: ^ 
<mdz> not yet
<mdz> ETA 10m
<jblack> Ok. no problem.
<mdz> new install CDs are up though
<mdz> NEW INSTALL CDS READY FOR TESTING
<Kamion> at least new xorg explains why my rsync is taking ages
<mdz> 20050908.4
<jblack> infinity: Will that shopping list I gave you above help any? 
<infinity> mdz : Did you change the labels this time?
<infinity> mdz : The jidgo template claims it's: 'Ubuntu 5.10 "Breezy Badger" - Alpha i386' (breezy-install-i386.iso)
<mdz> Kamion: I changed CONF.sh as instructed...
<mdz>     export OFFICIAL="Preview"
<mdz> infinity: 20050908.4?
<fabbione> mdz: permission to upload xdm (universe) to fix 14412
<infinity> mdz : Oh, wait, I think my jigdo is cacheing.
<mdz> fabbione: universe is not frozen
<infinity> 'Ubuntu 5.10 "Breezy Badger" - Preview i386' (breezy-install-i386.iso)
<infinity> Better.
<daniels> nice
<infinity> mdz : False alarm.
<mdz> phew
<doko> Mithrandir: no idea, works for me on amd64
<mdz> if I had to wait another 70 minutes for a label change I would have killed
<daniels> mdz: i've followed up with more information requested for keyboard vs kbd
<Mithrandir> doko: yeah, works for me as well.
<mdz> or rather done it by hand
* Kamion belatedly comments out all cdimage cron jobs
<daniels> we finally have two phone lines plus the dsl
<daniels> my laptop celebrated this great news by getting down to 3% battery
<Lathiat> daniels: mmm
<daniels> mdz: the main thing is that 14751's fixed, a) because I think that was the worst manifestation, b) because the submitter is a complete prick and I would love for him to go away
<Lathiat> most interesting you were using a separate pair
<daniels> Lathiat: nextep, dude.  it's crazy commercial dsl.
<Lathiat> daniels: yeh but we have commercial companies with their own dslaams and they share the copper
<Lathiat> how they do that sanely is beyond me but they do
<Kamion> mdz: yeah, I've incorporated that into arch, thanks, looks fine
<daniels> Lathiat: yeah, go figure.  all I know is that NEC have their own kit in the exchange.
<Lathiat> daniels: right, same as the other ISPs here but yeh, interesting
<daniels> alright, battery's dead.  i'm out for the next 2-3 hours.
* infinity has to run into town for an hour or so, before he comes back and spends his evening doing CD testing.
<mdz> jblack: 20050908.5 is mirroring now
<jblack> ok
<jblack> looks like its there.
<mdz> NOTICE: the current daily and daily-live CDs are preview candidates.  Please test them and report success or failure to the channel!
<dholbach> morning seb128 
<seb128> hey dholbach
<jblack> 33%
<jblack> 75%
<pitti> yay
* pitti cranks up the wireless
<Mithrandir> is the live cd VT switching bug tracked down yet?
<Burgundavia> jdub, we really need to do something about the Preferences menu in Breezy+1
<jblack> rebooting
<ubuntu> Ok. I'm in the cd.
<ubuntu> mdz: ready
<ubuntu> infinity: ready
* pitti really wants a split X server to reduce download time and volume
<jblack_> heh. I can't see nicknames in irssi on the livecd. :) 
<jblack_> That's better.
<daniels> Mithrandir: should be okay
<daniels> pitti: tell me about it
<jblack_> daniels: Would you be interested in monitors audibly clicking when doing a shutdown now -r ? 
<daniels> jblack_: at which point?  a click on a mode switch is pretty normal.
<Kamion> Mithrandir: I think we nailed most of that yesterday, over a few iterations
<pitti> daniels: ah, it's just a crackful dream I had the other day :-)
<daniels> jblack_: if they blow up, I'm interested ... but *totally* not responsible.
<daniels> pitti: heh
<jblack_> daniels: I dualhead.  When I leave X, the lcd drops to console. The monitor clicks every 2 seconds or so (sounds like the click monitors often do during change of resolution). 
<jblack_> That doesn't happen if I ctrl-alt-backspace.
<daniels> neat.  running usplash, perchance?
<jblack_> not intentionally?
<daniels> hrm
<daniels> *shrug*
<daniels> just one of those things
<jblack_> reading apt-cache show, I don't think so.
<daniels> anyway, time to go cook dinner.  i'm not going to irc from the stove, like last night.
<bob2> soup?
<daniels> bob2: nah, just random stir fry over at dad's place
<daniels> bob2: thursday -> family dinner
<bob2> ah
<jblack_> mdz: There? 
<jblack_> infinity: Hello? 
<daniels> bob2: between last night's effort (I didn't eat any, just froze it all), and some I had frozen before, I have enough soup to last me until UserLinux releases
<daniels> (ha ha)
<Kamion> whoa, slightly dodgy progress bar in base-config
<Kamion> oh well
<mdz> jblack_: yes?
<bob2> hahah
<jblack_> I'm in the second livecd
<mdz> Kamion: dodgy how?  I didn't notice anything untoward, but I didn't watch it the entire time either
<jblack_> 1920x1200 of course. What would you like? 
<Kamion> mdz: it goes up to 11% and then jumps back to 4%, near the start
<Kamion> it's only noticeable if you're paying fairly close attention
<Kamion> so much not a big deal for preview though
<mdz> jblack_: any additional testing you want to do is helpful, but the detection of the panel size is what we wanted to test. thanks.
<jblack_> Oke-doke
<sivang> morning all
<pitti> Hi sivang 
<sivang> pitti: how's bugsquashing going?
<mdz> sivang: it's CD testing time
<pitti> sivang: now it's CD testing time; do you have some time to thest them?
<Burgundavia> Kamion, I noticed something similar with my colony 3 install, jumped from 64% backt o 56%
<Kamion> Burgundavia: that's much weirder, but colony 3's old enough that I'm not too bothered unless you can reproduce it with newer
<Kamion> 64% is in the middle of the desktop installation and it really shouldn't jump around randomly there
<Burgundavia> Kamion, I didn't bother filing a bug because I couldn't reproduce it
<sivang> mdz, pitti : ofcourse I do, I have a seperate /home and /root , so I can probably install over this office workstation of mine, however is there anyway to save the alredy installed packages?
<mdz> Kamion: I didn't think debconf progress bars were capable of going backward
<mdz> sivang: just install to a separate partition
<Kamion> mdz: they certainly are, you can update them with SET (absolute) as well as STEP (relative)
<mdz> Kamion: and base-config does that?
<Kamion> mdz: and base-config always uses PROGRESS SET 'cos the maths are much simpler that way
<mdke> I'm still getting xkb errors on my hoary->breezy machine, i have touched nothing in the configuration since I installed hoary. Is this known?
<sivang> mdz: ok, I'll go fetch me a daily
<Kamion> mdz: it means there's a risk of going backward in the event of a programming error, but the counter-risk would be having the progress bar reach 100% far too early and then just sit there ... I prefer this set of risks
<sivang> mdz: what about hoary->breezy upgrade tests? are those worthwhile? (should I note anything while at it etc..)
<Kamion> and also using STEP would mean I'd have to make the progress bar use only integers throughout, which is impossible because I don't know exactly how long apt's progress bar should be
<Kamion> anyway, not important enough to worry about
<mdke> is anyone who can answer my xorg question around?
<Kamion> mdz: (actually, you might well be able to pass a negative number to PROGRESS STEP, too. I've never tried.)
<sivang> hmm, just making sure my testing is useful, shoudl I try with a daily or with colony-4 ?
<Kamion> sivang: current daily please
<mdz> Kamion: usplash failure on powerpc 
<mdz> live
<Kamion> boo
<Kamion> what happened?
<sivang> Kamion: k, thanks
<mdz> black screen, no artwork no progress
<jdub> mdz: my fault on the impi moderation - thought that was just the start of the mail
<mdz> morning sabdfl
<ogra> morning mdz 
<Kamion> mdz: did it work on install, or have you tried yet?
<mdz> Kamion: install is burning now
* jdub is 87% on the ppc install
<jdub> download, that is
<Kamion> I think I preferred it without the bterm bug fixed, looking at those error messages on live ;-)
<Kamion> ah well
<sabdfl> hi guys
<Kamion> morning
<dholbach> sabdfl: hi mark
<pitti_live> hi
<pitti_live> mdz, Kamion: powerpc live: I get a completely black screen during boot, when usplash is supposed to show up
<pitti_live> vt switching on shutdown works, but after ejecting the CD nothing happens, I'm not asked to press enter for shutdown, and pressing enter does nothing
<pitti_live> Kamion: The "Bummer, cannot run d-i" is a known issue?
<Kamion> pitti_live: yeah
<Kamion> it's probably always been there, we just never noticed until we fixed the VT switching
<pitti_live> it does not actually seem to do any harm
<Kamion> so it looks a bit untidy but it's just the final death throes of the old /
<pitti_live> I'm more worried about usplash not working
<pitti_live> anyway, I test amd64 shutdown now and brb
<Kamion> it would be interesting to know what kind of framebuffers you guys have
<Kamion> pseudo/truecolour, colour depth
<Kamion> mine's pseudo/8
<mdz> Kamion: how do I find out?  fbset -i?
<mdz> is there a way to check from d-i? I have an install in progress now
<pitti> mdz: amd64 live works flawlessly (apart from the ridiculously looking English and German mix)
<mdz> pitti: here as well
<mdz> only without the german
<dholbach> hehe
<lllmanulll> mdz, About CD integrity testing, I asked in a mail to write on the CD download page that CDs should be burned 1/3 slower than the maximum allowed ; I think this solution doesn't involve any code modification and would already prevent a lot of CD burning errors ; what do you think ?
<pitti> most menu strings are translated, but there is English in between
<mdz> lllmanulll: I read your email; I think a safe guideline is to go no faster than 4x
<dholbach> brb - have to re-adjust cables
<mdz> lllmanulll: on which page do you think the advice would be most visible?
<pitti> Kamion: did you hear any other usplash failures on ppc?
<lllmanulll> mdz, On the page where one can download the CD images ?
<lllmanulll> Make it bold face, or something like that ?
<Mithrandir> mdz/Kamion: ok to upload http://err.no/patches/glib1.2_1.2.10_1.2.10ubuntu1_asm_const_ftbfs.diff after preview? Fixes Ubuntu #13704
<pitti> do patches still need manual approval after preview?
<mdz> Kamion: /proc/fb says "ATI Radeon If"
<mdz> Mithrandir: ok to upload now; it'll be queued for after preview
<Mithrandir> mdz: thanks
<mdz> pitti: no
<sivang> hey sabdfl 
<Mithrandir> pitti: hm, point.  I'm not sure, but I'd like to have people at least eyeball stuff I upload in case I overlook something and introduce quiet breakages.
<mdz> Kamion: usplash works on your powerpc in the current candidate?
<Mithrandir> mdz: so I can just do the uploads I queued yesterday now?
<mdz> Mithrandir: which packages?
<mdz> preferably not anything in desktop
<mdz> in case we need to do uploads targeting preview
<Mithrandir> mdz: blender, siege, unifont.
<Mithrandir> the last one might be in desktop, I'm not sure
<Mithrandir> hm, no, it's not
<seb128> brb with liveCD
<dholbach> i386 live: the colors of the usplash status messages appear a bit dark overe here, the "ok" is barely readable
* pitti tests amd64 and powerpc install now
<dholbach> i386 live: clicking on the help icon -> going over to "desktop" gives me information about gnome 2.10 and gnome 2.6 even - will the doc team revamp this?
<Kamion> mdz: I'm still trying to get a reliable enough burn to tell, one moment
<sivang> err, 8m ETA for install cd, I wish it finished up already
<jsgotangco> dholbach, that's upstream!
<ogra> dholbach, ask gnome :)
<dholbach> jsgotangco, ogra: that's what i feared :-p
<jsgotangco> dholbach, there is work being done for 2.12 though
<mdke> dholbach, nothing we can do: if they don't perhaps we should remove it
<dholbach> mdke: yes... it's a bit ... well ... confusing to the user :)
<jsgotangco> dholbach, im one  of the people contributing to 2.12 wiki atm but its very very slooowww
<ogra> mdke, or get 10 additional guys and rewrite it ;)
<mdz> Kamion: similar usplash behavior on powerpc install here
<mdz> Kamion: worse, in fact, because it seems to clobber the console font
<dholbach> apart from mentioned issues - live i386 is fine for me
<Kamion> well, I get a black screen on a laptop where you have to use vga=771
<Kamion> so it's not just powerpc FWIW
<mdz> the dialogs are drawn with garbage rather than line drawing characters
<mdz> Kamion: works fine for me on amd64 and i386
<\sh> http://cdimage.ubuntu.com/daily/20050908.4/ <- latest daily?
<mdz> \sh: /current is a symlink which points to the latest
<dholbach> brb
<\sh> mdz: k
<\sh> downloading
<mdz> Kamion: vt switching seems solid, at least
<mdz> Kamion: we did fix it several times over ;-)
<sivang> mdz: whats the bug number for the vt switching? (/me is curious to know what happened there)
<mdz> 14851 or something like that
<Kamion> mdz: fbset -i, the Type and Visual lines and the last number in the geometry line
<mdz> it's all over the irc log
<Kamion> it's not all in the bug
<mdz> Kamion: hmm, we don't install fbset?
<mdz> which package is it in?
<mdz> in universe, even
<mdz> it'll have to wait until the install is finished
<seb_li386> i386 liveCD works quite fine
<mdz> seb_li386: excellent
<seb_li386> mdz, I've a network issue though. I've an eth0 and a eth1n eth0 unplugged, eth1 which should gets its IP from DHCP
<seb_li386> mdz, on boot eth0 is up and eth1 is not, I've to run sudo dhclient to get it and an IP
<seb_li386> is that a known issue?
<mdz> seb_li386: that is NOTABUG
<mdz> oh, didn't see your first message
* sivang is going to burn
<mdz> seb_li386: does mii-diag report the link status correctly? has this ever done any different, e.g. in hoary?
<mdz> Riddell: ping
<seb_li386> mdz, 
<seb_li386> $ mii-diag
<seb_li386> Using the default interface 'eth0'.
<seb_li386> SIOCGMIIPHY on eth0 failed: Operation not supported
<sivang> seb_li386: it gives the same for me on my desktop here, which is installed and using network fine
<mdz> seb_li386: I see an icon on the panel for evolution on i386 but not on amd64
<seb_li386> I'll try with hoary in a sec. I changed my eth cards since hoary and I've not tried with this config
<mdz> seb_li386: mii-diag requires root
<sivang> mdz: this is on my hoary, using root
<seb_li386> mdz, I get the same by running sudo mii-diag
<sivang> Using the default interface 'eth0'.
<sivang> Basic registers of MII PHY #1:  3100 7809 02a8 0330 05e1 0000 0000 0000.
<sivang>  Basic mode control register 0x3100: Auto-negotiation enabled.
<sivang>  Basic mode status register 0x7809 ... 7809.
<sivang>    Link status: not established.
<sivang>    End of basic transceiver information.
<mdz> seb_li386: ok, then your hardware/driver doesn't support testing link state
<mdz> seb_li386: and so we can't determine if it's plugged in
<seb_li386> hum, k
<seb_li386> so NOTABUG?
<mdz> seb_li386: CANTFIX
<seb_li386> dmesg has "[4294702.958000]  eth0: no link during initialization." though
<mdz> seb_li386: what about the panel icon issue?
<seb_li386> I don't have it on the i386 liveCD
<seb_li386> looking at it
<mdz> hmm
<Kamion> I don't have it on live/i386 either
<Kamion> was about to mention that
<dholbach> me neither
<mdz> any of you using laptops?
<Kamion> yes
<mdz> interesting
<jsgotangco> aye
<mdz> is it supposed to be there or not?
<seb_li386> /usr/share/gconf/schemas/panel-default-setup.entries:        <string>/usr/share/applications/evolution.desktop</string>
<mdz> jsgotangco: and you see the icon, or not?
<seb_li386> I hate upstreams
<seb_li386> they keep versionning it
<seb_li386> it's evolution-2.4.desktop now
<jsgotangco> what icon? (im just burning the live atm
<seb_li386> we should use evolution-mail.desktop rather, it's shipped with the package and don't move
<mdz> jsgotangco: oh, I thought you were responding to my question
<dholbach> the hoary -> breezy upgrade i did on another box was particularly fine, just gnome-phone-manager (universe, was fixed today) wasn't installable
<mdz> amd64 and powerpc installs both successful 
<mdz> though powerpc was ugly as hell
* sivang back in a 30m, launch calling.
<mdz> Kamion: I'm thinking we should roll back usplash on powerpc unless  you already know what the  problem is
<Kamion> my fucking CD drive is not helping
<mdz> I will get you that fb info though
<ogra> seb_li386, does gconfd still need a SIGHUP after you changed a setting with gconftool-2 ? 
<Kamion> how about we leave usplash as it is but make base-installer not install it? that way at least live CDs work on some hardware
<Kamion> and we don't get the install CD damage
<seb_li386> ogra, yep, dh_gconf does it though
<mdz> Kamion: the user experience is pretty bad on the live CD
<Kamion> the live CD is not massively helped by not having usplash
<Kamion> ?
<mdz> it just goes blank, no feedback at all
<mdz> we could disable it in casper
<Kamion> that would save a live fs build
<mdz> right
<ogra> mdz, the script in 7150 will need to SIGHUP gconfd in the end to make the change valid (in case gconfd already runs while you change the setting)
<Kamion> I'm going to have to go out and get a CD cleaner and some new discs
<mdz> ogra: gconfd isn't running
<ogra> ok
<ogra> didnt know when you run it
<mdz> Kamion: sent you mail
<mdz> Kamion: with the fb
<mdz> info and an assertion error from usplash
<mdz> ogra: I don't think it's started until login
<ogra> yes, it gets started by gnome-session afaik... seb_li386 might speak up if its different :)
<mdz> my i386 install definitely gives me the evolution icon
<jsgotangco> hmmm
<jsgotangco> i have it as well
<jsgotangco> (just finished)
<seb_li386> mdz, grep evolution /usr/share/gconf/schemas/panel-default-setup.entries ?
<mdz> seb_li386: just rebooted, will check
<\sh> Mithrandir: if glib is compiled, I can give gabber a new shot
<mdz> \sh: it won't be compiled until after preview; it's in main
<\sh> mdz: ah ok
<mdz> seb_li386: <string>/usr/share/applications/evolution.desktop</string>
<seb_li386> mdz, do you have this file?
<seb_li386> dpkg -S it?
<Mithrandir> \sh: should be by now
<Kamion> mdz: please change ->width to ->height on that line in bogl-pcfb.c and bogl-tcfb.c, rebuild, install, rebuild mkinitramfs, reboot
<Kamion> mdz:   assert (xx + pixmap->width <= bogl_xres);
<Kamion>   assert (yy + pixmap->width <= bogl_yres);
<mdz> seb_li386: no
<Kamion> obviously bogus :)
<Kamion> (not new code though)
<seb_li386> mdz, so the bug is that you get the icon, you should not if you don't have the desktop file
<pitti> mdz: amd64 install (network, with language-support download) flawless
<pitti> mdz: powerpc install a complete failure
* Kamion goes to get cleaner/discs - I'm hamstrung without being able to test myself
<mdz> pitti: details?
<dholbach> brb
* \sh prepares his network install
<pitti> mdz: #14736, os-prober crashes kernel when probing MacOS X partition
<seb_li386> pitti, computer:/// is bogus on the i386 liveCD here
<mdz> pitti: ouch
<pitti> mdz: after some kill -9 in vt2, yaboot failed to write a boot sector
<seb_li386> pitti, I've 2 CD drives, it lists both and the CD has a 3rd icon 
<pitti> mdz: manually rebooted, old yaboot installation still worked, got dropped into an empty console (usplash failure)
<mdz> pitti: related or unrelated?
<pitti> mdz: and base-config does not run
<pitti> mdz: I think the yaboot failure is a consequence of my killall os-prober
<pitti> I made a screenshot, just need to download
<pitti> Kamion: on powerpc: "usphash: bogl-pcfb.c:195: bogl_pcfb_put: Assertion yy + pixmap->width <= bogl_yres failed
<pitti> Kamion: does that say anything to you
<pitti> mdz: IMHO we should leave usplash disabled on powerpc for now, such last-minute features seem to lead to nothing but trouble
<ogra> pitti, yes, he said something similar before you entered the channel
<pitti> ah, ok
<ogra> pitti, :
<ogra> <Kamion> mdz: please change ->width to ->height on that line in bogl-pcfb.c and bogl-tcfb.c, rebuild, install, rebuild mkinitramfs, reboot
<ogra> <Kamion> mdz:   assert (xx + pixmap->width <= bogl_xres);
<ogra> <Kamion>   assert (yy + pixmap->width <= bogl_yres);
<ogra> pitti, try that :)
<pitti> ogra: oh, yes, that sounds sane :-)
<pitti> seb_li386: sorry, ENOTIME
<seb_li386> pitti, grumpf, k. I'll try to figure myself if that's a gnome-vfs issue so
<seb_li386> but computer:/// is messed
<mdz> Kamion: that fixed it
<pitti> seb_li386: I actually thought this was already fixed in the last version :-/
<seb_li386> pitti, are drives and volumes supposed to have separate icons?
<pitti> Kamion: what should actually be executed after the first boot? base-config does not quite DTRT
<seb_li386> pitti, I've no 2 drives icons and 2 CD icon, and no eject work
<pitti> seb_li386: normall ynot
<seb_li386> pitti, it used to change the drive icon to a volume one
<Riddell> mdz: hi
<seb_li386> pitti, k, will try to figure what's wrong with that
<pitti> mdz: http://people.ubuntu.com/~pitti/shots/ppc-install.jpg <- that's what I get after first ppc boot when switching VT and thus get my screen back; looks familiar?
<mdz> pitti: yes
<mdz> pitti: see breezy-changes ;-)
<pitti> hm, I don't really want to trash my MacOS partition now, since I want to keep it for confirming the kernel crash bug fix
<mdz> pitti: we can't leave usplash disabled on powerpc because it is already enabled; we can only disable it ;-)
<mdz> pitti: the reason it was enabled was as a workaround for the vt switching bug
<mdz> though that is also fixed another way now
<pitti> mdz: ok, so we can keep the current i386/amd64 images and only get new ppc ones?
<mdz> pitti: not unless we do it by hand, no
<dholbach> kubuntu i386 live is fine
<mdz> infinity: around?
<mdz> dholbach: kubuntu is several generations behind presently, and Riddell is nowhere to be found
<pitti> ok, I have to leave for ~2 hours
<Riddell> mdz: here I am
<dholbach> mdz: he just answered you 
<mdz> Riddell: oh, hi
<pitti> when I'm back, I can test new images, I will circumvent the os-prober test
<mdz> Riddell: need an immediate status update on kubuntu preview
<mdz> Riddell:  the last time we spoke, you had no successful CD operations yet
<infinity> mdz : Just stepped in.
<Riddell> mdz: 20050908 made last night works great on i386 but doesn't contain the language pack updates pitti put in, the normal daily build doesn't seem to have run
<mdz> infinity: can I get express treatment for usplash -10 on powerpc?
<infinity> mdz : Yup.
<Riddell> mdz: the problems I had went away as mysteriously as they came
<seb_li386> pitti, is eject supposed to be fixed?
<mdz> Riddell: are the seeds and metapackages in order?
<Riddell> mdz: yes
<infinity> mdz : Uploaded.
<mdz> Riddell: so you need a new CD build?
<mdz> infinity: thanks
<Riddell> mdz: for the new language packs yes
<mdz> Riddell: what about the livefs?
<Diziet> mdz: Thanks for the browser bugs, btw :-).
<Riddell> mdz: livefs?
<mdz> Diziet: HTH
<mdz> Riddell: the filesystem used on the live CD
<mdz> I have no idea if it's up to date or works at all
<Riddell> mdz: the live CD works fine
<mdz> on i386, ok
<mdz> but it won't have the langpacks either and needs to be revved
<Riddell> yep
<daniels> mdke: pong
<daniels> mdke: is it just the gnome 'hey, GNOME and X keyboard settings are different, wtf?' dialog?
<mdz> pitti: what's the last powerpc install which worked for you?
<pitti> mdz: uh, maybe two weeks ago, I didn't reinstall my laptop so often
<mdz> it worked fine here, which leads me to guess that some of your problems are fallout from os-prober
<pitti> mdz: yes, I think so; I'll try the next image and just disable the hfs mounting in the os-proper backend
<pitti> cu
<mvo> fabbione: do you happen to know why we seem to have no "sk98lin" network driver on 2.6.12-8-amd64?
<spacey> does someone know why /etc/ld.so.conf is gone? 
<fabbione> mvo: there is no sk98lin anywhere.. we ship the free version called skge
<spacey> and is there a replacement?
<fabbione> the sk98lin kernel driver is utterly broken and the one from upstream is a royal mess
<mvo> fabbione: hm, it works on my (on-board) yukon ethernet port but skge does not (it seems to be unable to detect a link or auto-negociate)
<fabbione> mvo: other people have the opposite problem. there is no winner
<fabbione> skge conflicts with sk98lin to a certain extents of hotplug
<fabbione> meaning that they share part of the same pciids space
<\sh> mvo: http://bugzilla.ubuntu.com/show_bug.cgi?id=6142
<Riddell> mdz: are new kubuntu ISOs being built?
<fabbione> making unpredictable what will work where and with what driver
<\sh> mvo: same here with the r200 and I'm tweaking my boot iso every time ,-)
<mvo> \sh: thanks, I have seen this bugreport
* Kamion gets back and tries to figure out how to drive the DVD cleaning kit
<mvo> fabbione: ok, thanks. 
<Kamion> mdz: thanks for the usplash upload
<\sh> mvo: we have to wait until a good replacement is in the kernel ;)
<mdz> Riddell: we can only do one build at a time currently
<mdz> Kamion: can we disable the source CDs?
* sivang -> back
<mdz> Kamion: I need to roll new install CDs for usplash and it takes 70 minutes with the current method
<mvo> \sh: r200? you probably do not mean the graphic chip from ati, right :) ?
<mdz> it shouldn't take more  than 20; it's all jigdo and source CDs
<mvo> mdz: should I wait for that? I'm about to start a i386 install test now (cd just burned)
<mdz> Riddell: I can roll new install CDs, but live needs to wait for the livefs build to finish on powerpc
<\sh> mvo: no...portege r200 from toshiba
<mdz> Riddell: kubuntu install build is running (no source, no jigdo)
<\sh> I think I have to buy some food stuff 
<mdz> Riddell: what other architectures can you test, or find testers for?
<seb_lamd64> I got a debconf question with the list of resolution on boot of the amd64 liveCD
<seb_lamd64> didn't get it with the i386 CD on the same box
<Kamion> mdz: CDIMAGE_NOSOURCE=1 in the environment, being aware that HP have explicitly asked for source CDs of our releases in the past
<Kamion> seb_lamd64: yes, xresprobe can't autodetect on amd64 yet
<Riddell> mdz: I should be able to find a powerpc tester
<mdz> Kamion: dude, it's cost me too much sleep already
<Kamion> mdz: I'll refer them to you :-P
<mdz> HP can get the source like everyone else
<seb_lamd64> Kamion, thanks
<mdz> it's only preview
<siretart> in breezy, where shoud app-defaults go, /etc/X11/app-defaults or /usr/lib/X11/app-defaults?
<jsgotangco> hmm i must have a bad burn on amd64
<daniels> the former
<seb_lamd64> I've message about S72menu-exist before the splash screen, is that known?
<WaterSevenUb> kamion, thanks for correcting the archive-copier.po :) We were sleepy in the evening already :)
<\sh> xterm has old link to /usr/lib/X11/app-defaults...fixed it here locally
<Kamion> seb_lamd64: yeah, it's the death throes of the old root filesystem, which are visible now that we've fixed the vt switching
<Kamion> ugly but harmless
<seb_lamd64> k
<seb_lamd64> amd64 liveCD works fine here too out of these small notes
<Kamion> WaterSevenUb: no problem
<seb_lamd64> daniels, when switching between apps with alt-tab the windows are black painted ... any idea of what could do that?
<\sh> mdz: ok with u to upload xterm-103 after preview time to fix the location of /etc/X11/app-defaults
* sivang is going to install..
<mdz> \sh: fine to upload to the queue now
<\sh> mdz: thx
<siretart> daniels: is it possible that xmkmf makes makefile that make compiled programs look for app-defaults in /usr/lib/app-defaults instead of /etc/X11/app-defaults
<Riddell> hmm, oversized kubuntu live CDs
<daniels> seb_lamd64: iz gtk bug
<seb_lamd64> daniels, cairo?
<daniels> seb_lamd64: unless.  do me a favour.  fire up xev, and partially obscure it (so, say, half of it is behind a terminal).
<daniels> seb_lamd64: tab over to xev, and back to the terminal.
<daniels> seb_lamd64: you should get VisibilityNotifies about it being fully visible, then partially obscured
<daniels> if you ever get a FullyObscured VisibilityNotify, X is broken
<daniels> seb_lamd64: this is the colourmap-is-null one that I patched straight after you uploaded 2.8; the patch hasn't gone missing, hsa it?
<seb_lamd64> VisibilityNotify event, serial 28, synthetic NO, window 0x2a00001,
<seb_lamd64>     state VisibilityPartiallyObscured
<daniels> siretart: i dunno, possibly
<seb_lamd64> VisibilityNotify event, serial 28, synthetic NO, window 0x2a00001,
<seb_lamd64>     state VisibilityUnobscured
<daniels> seb_lamd64: okay, 'tis a gtk bug :)
<seb_lamd64> daniels, patch came from upstream, right?
<daniels> yeah
<daniels> from otaylor
<seb_lamd64> daniels, I'm pretty sure it has been used for new versions
<seb_lamd64> we have 2.8.3 atm
<seb_lamd64> but it doesn't do that on the same box with my standard install
<daniels> seb_lamd64: another easy way to tell is, well, use xev as a litmus test
<siretart> daniels: I will check this. if it is, shall I file another bug about this?
<daniels> seb_lamd64: see if it only does it with gtk apps, or if it does it with xev also
<daniels> siretart: sure
<Mithrandir> live amd64 works for me
<siretart> ok (off fur lunch now)
<seb_lamd64> dand, xev is painted black as weel
<seb_lamd64> ups
<seb_lamd64> daniels, 
<daniels> seb_lamd64: on alt-tab?
<daniels> gar, I can't reproduce it
<seb_lamd64> daniels, it's painted when I press tab, and keep this way while alt is pressed
<daniels> seb_lamd64: painted black?
<seb_lamd64> yeah
<daniels> hm
<seb_lamd64> it goes away when I relax alt
<daniels> when I hold down alt, and hit tab, I get the outline of the frames showing
<daniels> but I can still see my active window
<Kamion> I really, really hate typing 'sudo reboot' on the wrong machine by mistake
<seb_lamd64> which is the correct behaviour
<daniels> Kamion: yes
<daniels> seb_lamd64: so, let me get this right
<daniels> seb_lamd64: you hold down alt
<daniels> seb_lamd64: hit tab
<daniels> seb_lamd64: and the window you're switching to ... its area is drawn completely black, over the current window?
<daniels> seb_lamd64: and then you release alt and it paints itself
<seb_lamd64> correct
<daniels> i've seen that before, but only once, and it heisenbugged itself
<daniels> also on amd64
<daniels> i'm pretty sure it's a metacity bug
<seb_lamd64> it does that with i386 and amd64 liveCD on this box
<daniels> x has nothing to do with it at that point -- all painting over the active window is done by metacity
<seb_lamd64> and no with i386 install
<seb_lamd64> install beeing my working box, no a fresh one
<daniels> if you could get me a diff between the Xorg.0.logs on live and install, that would be great, but I'm pretty sure it's a metacity thing
<daniels> if you want to make really sure, try starting kwin or fluxbox or something
<seb_lamd64> k
<dholbach> brb
<sivang> I tried to resize the partition on which I Want to install, but I got "due to unknown reason cannot resize partitoin"
<hunger> daniels: I keep running into problems with the xdm deb. Its postinst fails with status 1 whenever I upgrade something. Is there a way to work around that? I guess I broke some symlinks trying to fix stuff during the transition.
<sivang> the partition is ext3 plain one, with bootable device flag 
<daniels> hunger: i dunno man, I didn't do xdm
<daniels> hunger: apparently it was broken until today though
<hunger> daniels: Oh, I thought you were the big X hacker.
<sivang> Kamion: any idea?
<daniels> hunger: yeah, but fabbione did a lot of the apps
<hunger> daniels: Great, I'll upgrade as soon as I get back into the hotel tonight.
<Kamion> sivang: no, check the log files
<Kamion> sivang: perhaps it was not cleanly unmounted
<Mithrandir> hmm, shouldn't the update-notifier be disabled on the live CD?
<Mithrandir> it offers to upgrade usplash here, which seems kinda silly
<hunger> daniels: It is always great to hear that it wasn't me who messed up stuff for a change:-)
<sivang> Kamion: ah, so should I umount it manually before trying to install using the install cd ?
<Kamion> sivang: manually or automatically, don't care :)
<seb_lamd64> daniels, Xorg.0.log.diff on my chinstrap dir
<Mithrandir> daniels / seb_lamd64 : the black box problem goes away be switching to openbox, fwiw.
<Mithrandir> s/be/by/
<Kamion> sivang: but I think parted will often refuse to resize a filesystem that wasn't cleanly unmounted
<sivang> Kamion: if there's a dirty flag set for this fs, how can I manually unset it?
<Kamion> sivang: fsck
<Kamion> ah, good, my powerbook's CD drive is much healthier now
<daniels> Mithrandir: \o/ metacity problem
<sivang> Kamion: k, I'll fsck it now that I manually unmounted it. I really want to see the ext3 resize in action, plus I have all the mirror data on that partition :)
<seb_lamd64> daniels, or xorg bug exposed by it :p
<daniels> seb_lamd64: what's - and what's +?
<sivang> /dev/hda4: clean, 11576/3571712 files, 1680702/7138884 blocks (check in 4 mounts)
<seb_lamd64> daniels, out of joke, probably a wm bug, but any help to debug it is welcome, I've no clue on this code
<sivang> goody, not back to installation.
<daniels> seb_lamd64: actually, I have an idea
<seb_lamd64> daniels, - is the working install, + the bugged liveCD
<daniels> shazam! fuck I'm smart
<seb_lamd64> you found what causes the bog?
<daniels> yeah
<seb_lamd64> cool
<seb_lamd64> you rock :)
<seb_lamd64> what is it?
<daniels> missing Modules section in xorg.conf -> no extmod
<daniels> at a *guess*, I'm going to say missing SHM support
<mdz> Riddell: kubuntu install isos are up
<seb_lamd64> daniels, why extmod is not used? xorg bog?
<Kamion> damn, same os-prober problem here
<mdz> Kamion: I'm happy with the current builds, modulo the powerpc/usplash issue
<mdz> Kamion: a powerpc livefs build is in progress and should finish soon
<mdz> when it does, I'll kick off live and install builds and go to sleep
<Kamion> well, kernel problem while running os-prober anyway
<Kamion> mdz: ok, cool
<Kamion> I don't know what to do about this os-prober thing. Release-note it? The workaround is not entirely trivial.
<daniels> seb_lamd64: for some reason, xserver-xorg/config/modules is still empty.  could you please chuck up /var/log/casper/post.log?
<Kamion> I could temporarily change os-prober to avoid hfsplus partitions
<mdz> Kamion: do we know if the os-prober issue affects all macos partitions, or only some?
<mdz> yes, was going to suggest that next
<Kamion> mdz: can't prove a negative ... but it's both pitti's and my OS X partitions
<seb_lamd64> daniels, on chinstrap too
<mdz> Kamion: well, a counterexample would be enough
<Kamion> and somebody else's
<Kamion> I haven't heard of a counterexample, but I don't really have enough data
<mdz> I could install macos here
<Kamion> it's hard enough to get people to report successes let alone to get information about what other OSes they have installed ;)
<daniels> seb_lamd64: thanks
<mdz> Kamion: I have no problem with disabling it; it isn't as if we can resize macos anyway, so dual booting it is something which requires advance planning and some expertise
<Kamion> mdz: that might be a plan, although it will take an hour or two
<seb_lamd64> daniels, np, thank you for working on it :)
<Kamion> mdz: er, I thought parted could shrink hfs fine
<mdz> it takes about an hour, an hour of saying "20 minutes remaining"
<mdz> Kamion: it can
<mdz> ?
<Kamion> not that I've ever tried it, but I've seen it in changelogs
<sivang> Kamion: still no go, no apparent logging information. any other way to obtain logs of the resize checkup other then ALT+F{1,2,3} ?
<Kamion> sivang: alt-f4 for a start
<mdz> powerpc livefs just succeeded
<Kamion> sivang: but please, if you can find somebody else to help, please do, I'm very busy just now
<daniels> seb_lamd64: no worries.  my best guess is either of the damage or shape extensions being missing, but it's sort of irrelevant which.
<mdz> Kamion: any reasonable way to avoid rebuilding and retesting i386 and amd64?
<sivang> Kamion: ok, I'm sorry, I will go on without resizing then, won't bug anymore
<seb_lamd64> daniels, I can try to turn them
<daniels> seb_lamd64: what's the value of xserver-xorg/config/modules?
<seb_lamd64> daniels, on my standard install, and notice which one breaks it?
<Kamion> mdz: not particularly conveniently
<seb_lamd64> daniels, how do I get that?
<daniels> seb_lamd64: ah, it's okay, doesn't particularly matter at this point
<daniels> seb_lamd64: /var/cache/debconf/config.dat :)
<mdz> ok
<mdz> Kamion: builds running
<mdz> I'm turning in
<mdz> SMS me if any new blockers are discovered
<Kamion> ok
<seb_lamd64> Name: xserver-xorg/config/modules
<seb_lamd64> Template: xserver-xorg/config/modules
<seb_lamd64> Value:
<seb_lamd64> Owners: xserver-xorg
<seb_lamd64> Flags: seen
<Kamion> mdz: can we release before you wake up, if not? :-)
<mvo> i386 install is fine here
<Kamion> or I guess you have all the announcement-fu
<daniels> seb_lamd64: sheeeeet.
<daniels> seb_lamd64: okay
<daniels> seb_lamd64: this is where it gets hillarious
<daniels> seb_lamd64: can you please hack /var/lib/dpkg/info/xserver-xorg.config to run with sh -x, and dump the output of sudo dpkg-reconfigure -pcritical xserver-xorg on chinstrap?
<jsgotangco> grrr i seem to have a corrupted rsync image
<daniels> (btw, it is shape support rather than damage that causes it.)
<seb_lamd64> daniels, xorg-reconfigure.log
<seb_lamd64> daniels, and now I have "Value: GLcore,i2c,bitmap,ddc,dri,extmod,freetype,glx,int10,type1,vbe" :/
<daniels> seb_lamd64: let me guess, xorg.conf now has a reasonably well-populated Modules section too?
<seb_lamd64> daniels, correct
<daniels> well, shit.
<daniels> gar, it should always be answering it with the default that I can see.
<seb_lamd64> daniels, and a new xorg started with startx -- :1 works fine now
<daniels> seb_lamd64: sigh
<seb_lamd64> daniels, is there any way to get a log of the first boot/config?
<daniels> my rsync's still going, I'll get down and dirty with the cloop when it's fone
<dholbach> brb
<daniels> seb_lamd64: start it with expert, in one of the steps where it's mounted /target but not yet run dpkg-reconfigure xserver-xorg, drop to the shell, edit /target/var/lib/dpkg/info/xserver-xorg.config (or maybe just /var/lib/dpkg/info/xserver-xorg.config, whatever works), and add sh -x to it
<daniels> and post.log should then have the full trace from the config script too
<Kamion> powerpc install into second stage, looking fine
<seb_lamd64> daniels, lemme try
<daniels> sebcheers
<daniels> heh
<seb_lamd64> daniels, grumpf, the liveCD has no expert mode?
<sivang_i386_inst> besides some weirdness in my LCD configuration, and some gibbrish characters when setting up gnome-games (watched using alt+f4) this is pretty awesome install process
<daniels> seb_lamd64: live-expert
<seb_lamd64> daniels, grra, thanks, brb :)
<sivang_i386_inst> the USPlash not that bad either, although I'd like to see it use a higher screen resolution
<daniels> sivang_i386_inst: can't
<daniels> 640x480 is the only sensible resolution we can ever hope to configure
<daniels> even then, it doesn't always work
<sivang_i386_inst> daniels: I see, it also had on error there - "failed setting up console font"
<sivang_i386_inst> daniels: is there neglectable?
<daniels> probably, yeah
<sivang_i386_inst> daniels: and still, my console fonts are really weird looking comapred to hoary's...
<sivang_i386_inst> daniels: and I had to punch my LG's "auto adjust" so it will stretch and center the display picture.
<daniels> yeah, that's because we're using a vga framebuffer
<daniels> lots of fun
<sivang_i386_inst> daniels: I see. so, how can I make it not use the framebuffer ? :) (I like it how it was in hoary hehe)
<sivang_i386_inst> Hmm, I can't see the evolution icon either next to the Yelp one on the top panel..
<daniels> sivang_i386_inst: ... don't use usplash.
<Kamion> sivang_i386_inst: the evolution icon's broken, was discussed earlier
<sivang_i386_inst> Kamion: k,thanks
<dholbach> bbl
<mjg59> infinity: I think it probably /can/ be done
<sivang> daniels: so, due to using the frambuffer for usplash, I get weird gnome-terminal fonts? (I think I understood wrongly)
<daniels> sivang: oh, gnome-terminal fonts are something else altogether
<daniels> that's probably freetype changing again
<sivang> daniels: oh :)
<mdke> i can't boot into my windows partition after dist-upgrading yesterday. The entry has disappeared from grub and I can't succeed in booting in manually
<mdke> anyone else seen that?
<sivang> all in all, very nice install as always, and usplash is refreshing :)
<bob2> mdke: you mean grub ignore is, or you don't know how to add it?
<mdke> bob2, i tried adding it and it didn't boot, just returned me to the grub menu
<ogra> mdz, still here ? 
<sivang> mdke: it happens every time a new kernel is added for me 
<sivang> mdke: he's off to sleep, I think.
<sivang> ops, that was for ogra 
<daniels> ogra: he's asleep, yeah
<mdke> sivang, ok can you 14947 then pls?
<mdke> also, any idea how to put it back?
<Kamion> sounds like you didn't put the Windows configuration in the right part of menu.lst
<Kamion> the file has clear documentation about which parts are autogenerated and will be rewritten on upgrade
<ogra> does anybody know since when the liveCD user has apassword set ? i thought there wasnt one ?
<mdke> Kamion, i didn't put anything in there, it was added automatically when I installed Ubuntu, and has been there since, until it was removed randomly yesterday
<ogra> (for the ubuntu user that is)
<mdke> Kamion, it's a testing machine so i don't play with configuration
<mdke> Kamion, when i tried to add it manually, i just did it from the grub command line
* mvo boots into live-cd, brb
<daniels> seb_lamd64: hey dude
<daniels> seb_lamd64: how was your adventure in live cd land?
<seb_lamd64> daniels, I've the log
<daniels> seb_lamd64: excellent! thanks a lot
<sivang> what more testing needs to be done? (/me is hungry for more QAing..)
<seb_lamd64> daniels, post-verbose.log on chinstrap
<daniels> okay, what the fuck?
<daniels> + db_set xserver-xorg/config/modules GLcore,i2c,bitmap,ddc,dri,extmod,freetype,glx,int10,type1,vbe
<daniels> [...] 
<daniels> + db_input low xserver-xorg/config/modules
<daniels> [...] 
<daniels> + RET='question will be asked'
<daniels> [...] 
<daniels> + db_get xserver-xorg/config/modules
<Kamion> is that a multiselect?
<daniels> [...] 
<Kamion> you probably need ", " instead of ","
<daniels> + db_get xserver-xorg/config/modules
<daniels> [...] 
<daniels> + RET=
<daniels> Kamion: nnnnnghargnh
<Kamion> cdebconf is a bit less picky there
<daniels> seb_lamd64: okay
<Kamion> but debconf splits on /,\s+/ not /,\s*/
<daniels> seb_lamd64: if you feel like doing another live run ... grep for the line that says GLcore,i2c
<daniels> seb_lamd64: and change foo,bar,baz to foo, bar, baz
<Kamion> put quotes around it too if they aren't there already
<daniels> there are quotes around it, yeah
<daniels> it came from debian.  so the quoting was perfect.  it's just everything else that was broken. :P
<Kamion> ok
<Kamion> what are the consequences of this bug, again?
<Kamion> current Debian xserver-xorg seems to use awk with RS=", "
<Kamion> I don't see the same hardcoded list there; I guess it's old
<daniels> Kamion: it's in another section
<mvo> daniels: the amd64 live cd didn't auto-detect my panel resolution. known issue?
<daniels> Kamion: the impact is that we don't get any modules loaded
<Kamion> hmm, that's bad, right?
<daniels> Kamion: -> no xvideo, metacity doing ugly black shading of windows, no gl
<daniels> accelerated or no
<seb_lamd64> daniels, will give it a try
<daniels> yeah, that's not great
<daniels> mvo: external panel, not laptop panel, right?
<mvo> daniels: external, yes
<daniels> mvo: yeah, been there ever since warty ;)
<daniels> Kamion: if seb tries this ant it comes up roses, I can do an upload immediately
<Kamion> ok, thanks
<mvo> daniels: uhhh ... right (/me dosn't have his amd64 for that long)
<daniels> and, everyone, I really like your testing, but stop finding bugs :P
<HiddenWolf> daniels, why, the more the merrier? ;)
<Kamion> daniels: the ", " thing confused me really severely about two months ago, if that's any consolation - that's how come I noticed it immediately above
<Kamion> it bit localechooser rather hard
<daniels> Kamion: hey man, don't worry about it.  multiseat taught me about writing portable shell, this is teaching me about hillarious debconf semantics. ;)
<daniels> HiddenWolf: heh
<mvo> other than that, amd64 looks pretty good (modulo the isse that seb reported already)
<daniels> yeah
<Kamion> I'll do a live run on powerpc with that change in a bit, too
<BenC> anyone able to reassign bugs?
<BenC> I have two bugs assigned to me that need to be reassigned correctly
<Kamion> ogra: could you give BenC editbugs please?
<ogra> Kamion, BenC, done :)
<Kamion> BenC: you should be able to do it yourself now
<BenC> thanks
<Kamion> ogra: ta
<ogra> Kamion, do you happen to know why the liveCd has a password for the default user now ?
<BenC> hmm, assigned-to field is still not editable for me
<Kamion> ogra: no - perhaps passwd -l broke?
<Kamion> BenC: there should be a reassign radio button further down
<BenC> yep, damn bugzilla, doing things all weird
<ogra> Kamion, can casper set environment vars before the user gets logged in ? 
<mvo> hm, looks like starting the screensaver is not a good idea on the live-cd :P
<ogra> mvo, just solved
<ogra> ;)
<ogra> mvo, but you could be my guineapig if you run the liveCd currently
<Kamion> ogra: what are you trying to do?
<mvo> ogra: nice picture btw =)
<mvo> ogra: I was just rebooting, should I boot back into it?
<ogra> Kamion, solving the xscreensaver lock issue
<Kamion> ogra: you could hack /etc/environment; bear in mind that every hack performed by casper has to be unhacked by ubuntu-express
<ogra> mvo, could you kill xscreensaver after login and export RUNNING_UNDER_GDM="True", then start xscreensaver again and try to lock ?
<mvo> ogra: ok, will do (once it's up again)
<ogra> Kamion, see that ^^^ it prevents locking at all, i just have to get this var set before the user gets logged in
<Kamion> ogra: it would be much better for xscreensaver to detect that the user's password is locked
<Kamion> I don't see why that should be infeasible; it surely has the privileges to tell
<Lathiat> Kamion: technically, that behavior would be correct
<ogra> Kamion, yes... but as a quick fix this will work...
<Lathiat> Kamion: (not letting you unlock if is locked)
<mpt> mvo: Has "Click on the update icon the link to see the available updates" already been reported?
<ogra> Kamion, i.e. for preview since its a one liner :)
<Kamion> ogra: did mdz say this is preview-critical?
<ogra> Kamion, nope... but a easy fix and i guess the current CD arent final, are they ? 
<Lathiat> it should be
<Kamion> no, unfortunately they aren't
<mvo> mpt: I thought that was fixed in the current image? let me check
<Kamion> I want to keep the delta to preview as small as possible, that's all
<ogra> Kamion, o adding this one line to casper should be sufficient for now... i'm working on a zero PW chack already, but this will take longer
<BenC> who officially handles udev bugs?
<BenC> doesn't seem to be just one person assigned udev stuff
<ogra> BenC, pitti ? 
<BenC> is that scott?
<Kamion> a motley selection of pitti, Keybuk, jbailey, and whoever fails to step back first
<mvo> mpt: it's not fixed apparently :/ would "Click on the update icon or the link.." be appropriate?
<BenC> ah, martin-pitt
<mpt> mvo: That would be acceptable, though I'd still wonder why I was being given a choice :-)
<HiddenWolf> Guys, I've got trouble with my cdroms again.
<HiddenWolf> Don't automount.
<mvo> BenC: do you plan a kernel upload after preview? the hook file would need a (small) update to support not showing the reboot notification if a reboot already happend
<Kamion> that hfs crash really needs to be fixed before final, so I hope so
<BenC> mvo: yeah
<Mithrandir> doko_: what do you think about http://err.no/patches/bcel_5.1-4ubuntu2_5.1-4ubuntu3_ftbfs_ant_compiler.diff ?
<mvo> mpt: you don't like choices ;) ? I'm fine with just writing "the link" or "the button"
<mvo> BenC: the hook file will need the additonal key ""DontShowAfterReboot=true"
<pitti> Hi
<daniels> hi pitti
<pitti> new CD images to test?
<sivang> pitti: wb
<sivang> pitti: I'm in to more tests as well
<pitti> Kamion: thanks Colin for the hfs workaround - so I don't even need to hack in the scripts during install :-)
<Kamion> daniels: that X fix seems to have worked
<fabbione> hey BenC 
<seb_lamd64> daniels, that fixes it
<daniels> Kamion: okay, cool
<daniels> sweet
<seb_lamd64> thanks for debugging it
<daniels> Kamion: speak NOW if you don't want me to upload
<daniels> seb_lamd64: thank you, dude
<Kamion> go ahead
<daniels> Kamion: done
<daniels> seb_lamd64: i hope you want beer bought for you at ubz
<seb_lamd64> was not GTK bog :p
<daniels> seb_lamd64: (of course, this means that all bugs from here in are gtk bugs ...)
<seb_lamd64> sure :)
<daniels> since all the xorg bugs have clearly been fixed
<seb_lamd64> ha ha :)
<pitti> mvo: btw, I installed with network and download of the l-support pack, worked fine
* daniels blinks.
<seb_lamd64> pitti, you are next on my list :)
<mpt> mvo: That's not the sort of choice that lets someone increase their long-term productivity, so the only effect will be to slow them down
<daniels> i'm so used to mentally reversing your 'ah ah' in my head, I read that as 'ah ah'.
<mvo> pitti: yeah! thanks
<mpt> mvo: It's rather strange to use hyperlinks in non-Web GUIs anyway, so nuking the link and just saying "click the icon" would be an improvement I think
<seb_lamd64> pitti, is the liveCD supposed to be mounted?
<pitti> Kamion: during install I noticed quite a few missing translations - did the msgids really change that much or is there a bug somewhere?
<pitti> seb_lamd64: well, you can't do without, right?
<Kamion> pitti: there's a bug somewhere in debconf->cdebconf passthrough - I'll track it down after preview
<seb_lamd64> pitti, hal-device-manager doesn't list it as mounted
<pitti> Kamion: yes, should be no preview blocker, I just noticed it
<pitti> seb_lamd64: but "mount" does?
<seb_lamd64> pitti, neither do mount
<seb_lamd64> pitti, nop
<mvo> mpt: can't you usability folks have a common opinion :) ? I got a bug a couple of days ago that it's too hard for people to understand what a "update icon" is and that I should add a clickable bit in the notification
<seb_lamd64> pitti, but computer:/// and the desktop list "cdrom"
<pitti> seb_lamd64: hm, then hal can't either - I look at it in my next live test
<seb_lamd64> pitti, I don't get how/why it happens
<mvo> mpt: but yeah, I agree that it's lame to have a choice in this question
<pitti> seb_lamd64: I suspect that gvfs displays the loopback image as cdrom
<mpt> mvo: I agree entirely that it's too hard for people to understand what an update icon is
<seb_lamd64> pitti, what loopback?
<pitti> seb_lamd64: the live root fs?
<mpt> mvo: The long-term solution is not to use an icon, but realistically, that won't get done for Breezy, will it :-)
<pitti> seb_lamd64: I will look at it
<seb_lamd64> pitti, right
<seb_lamd64> pitti, thanks, let me know if you figure something
<Kamion> ogra: testing a casper hack now
<mpt> mvo: In the short term, saying "please click the icon" with a balloon pointing straight to it should be *obvious*, even if annoying or whatever.
<mvo> mpt: no, I'll get eaten alive if I do anthing but (small) fixes at this stage
<pitti> ah, I need to change my IP to circumvent my quota, brb
<daniels> heh
<daniels> and I thought Australian ISPs sucked
<ogra> Kamion, great :)
<HrdwrBoB> haha
<Lathiat> haha
<daniels> (well, they do, but still.)
<Lathiat> well
<HrdwrBoB> that's ok I route traffic through my work because we peer with them
<Lathiat> i cant change my IP to avoid quota
<Lathiat> wish i could
<daniels> HrdwrBoB: oh, dude.  nice.
<HrdwrBoB> so I get free traffic
<HrdwrBoB> :D
<Lathiat> HrdwrBoB: eh heh
<Lathiat> i do that when i get shaped
<Lathiat> well through a small non profit ISP i look after
<Riddell> mdz: can we get new kubuntu live CD builds
<daniels> we just have unlimited 1.5/256 at the moment.  iinet are planning to do dsl2 on our exchange, so we should have unlimited 12/lots soonish, but I'm really hanging out for agile's adsl2+, so we get 24/arseloads.
<daniels> Riddell: he's asleep at the moment
<Lathiat> daniels: unlimited? hahahha
<Lathiat> daniels: have you seen iinets plans? :)
<Riddell> daniels: quite right too
<Riddell> kamion: can we get new kubuntu live CD builds
<daniels> Lathiat: i thought they offered an unlimited.  but I sense we're spiralling rapidly offtopic.
<Kamion> ogra: are you sure that RUNNING_UNDER_GDM=True won't affect anything else?
<Lathiat> daniels: no, the *most* you can get is 40GB
<ogra> Kamion, yup
<daniels> oh, cock
<Lathiat> well, you could pay $190/month
<Lathiat> and get 120GB
<Kamion> Riddell: is there any point considering that we'll have to rebuild them for new xorg anyway?
<Kamion> Riddell: and new casper, for that matter
<Riddell> Kamion: when are they coming in?
<ogra> Kamion, its a explicit xscreensaver env var
<Lathiat> don't forget you'll have to bundle your phone service with them
<daniels> Kamion: is there any point filing a wishlist on debconf asking it to scream frigging loudly if it decides to throw away your selections because you're doing something wrong?
<daniels> Lathiat: don't use the landline, so I don't care
<Kamion> ogra: it's not named like an xscreensaver environment variable :-P
<Lathiat> daniels: yeh but the rental is like $12 month more than most people pay to telstra
<Kamion> does nobody know about namespaces any more?
* mvo is going back to non-live 
<Kamion> THIS_IS_MY_ENVIRONMENT_VARIABLE_HONEST_ALL_YOU_OTHER_PEOPLE_CAN_GO_JUMP=True
<daniels> Kamion: i'm pretty sure libx11 had LIBRARYPATH at some point
<daniels> maybe still does
<Kamion> daniels: probably ought to at least show up in DEBCONF_DEBUG=developer logs
<Kamion> Riddell: they're on their way, next couple of hours
<ogra> Kamion, if you feel better with it, i can add two lines to xscreensaver and add RUNNING_UBUNTU_LIVE as lock prevention
<ogra> ;)
<ogra> its trivial
<Kamion> that doesn't make me feel better, no
<daniels> Kamion: that would rock, yeah
<Lathiat> ogra: does this fix include asking the screensaver to lock itself?
<Riddell> Kamion: right
<ogra> i suspected this :)
<ogra> Lathiat, yes
<Lathiat> ogra: ok cool
<ogra> Lathiat, it works n th lowest level...
<Kamion> ogra: RUNNING_UNDER_GDM=True in /etc/environment seems to work, anyway; I'll upload that shortly
<ogra> Kamion, thaks :)
<Kamion> Riddell: when do your last usable live CDs date from?
<Kamion> ogra: it really ought to be XSCREENSAVER_*, though, if you're adding future variables
<Riddell> Kamion: 2005-09-07 
<ogra> Kamion, this var is set normally if you run xscreensaver from GDM to have it switch to a screensaver if nobody logs in...
<Lathiat> pitti: was the decision not to restart dbus on any package installations kept?
<Lathiat> pitti: (just wondering if we should keep this behavior in the avahi package)
<ogra> Lathiat, its an upstream decision
<Lathiat> ogra: sure, i more meant the decision on what to do in our packages
<Lathiat> i'm aware of the issues/reasons surrounding it
<pitti> Lathiat: yes
<Kamion> ogra: since it's set by gdm, are you aware of any other code that looks at that environment variable and behaves differently when it's set?
<ogra> Kamion, nope ...
<Kamion> that's the obvious question
<daniels> Lathiat: you should absolutely have code to deal with it
<daniels> Lathiat: but it won't be happening by default
<Lathiat> daniels: was that the dbus thing?
<Lathiat> daniels: basically i dont restart, because that tended to be the consensus, unfortunately as its a system bus service the restart is needed to make avahi-daemon actually able to connect, i should send a patch to get dbus to reload its config files.
<daniels> Lathiat: yeah, the dbus restarting thing
<ogra> Kamion, sabayon uses it too to prevent locking in the xnest session, i dont think it will do any hram to anything else
<ogra> harm even
<Lathiat> avahi seems to have single handedly turned up about 10 bugs/annoyances in dbus so far
<tseng> Lathiat: haha
<Lathiat> really, it has
<tseng> Lathiat: and snorp is finding more in dbus-sharp trying to bind avahi
<Lathiat> tseng: yeh some of them are those
<Lathiat> (was talking to him earlier about that)
<Lathiat> not supporting arrays of arrays, didn't haven wrap a 16bit integer (in dbus-sharp)
<Lathiat> we had some bugs in the python bindings, the problems with private connections, the fact the system bus address isnt exported, the fact restarting sucks / you can't reload config files, the header files arent ansi C compliant, etc, etc :)
<Kamion> Riddell: I'm doing a quick build now for you
<Kamion> won't be final though
* ogra envys Riddell for having liveCDs
<seb_lamd64> pitti, 
<seb_lamd64> vol(0x54f720)[dev: /dev/cdroms/cdrom0, mount: file:///cdrom, device type: 4, handles_trash: 0, icon: gnome-dev-cdrom, name: cdrom, user_visible: 1, drive: (nil)] 
<ogra> edubuntu is just to big :(
<seb_lamd64> that's from the gnome-vfs volume stuff
<Riddell> ogra: twice as much to test
<Riddell> ogra: but feel free to test kubuntu CDs on your amd64
<ogra> Riddell, but unbelivable promotion advantages
<Kamion> ok, I like new xorg, it actually builds in reasonable time
<daniels> Kamion: no it fucking well doesn't
<daniels> it still takes like 40 minutes on my laptop
<pitti> seb_lamd64: and yet this is a lie, i. e. the cdrom is not actually mounted?
<seb_lamd64> pitti, nop
<Kamion> daniels: I can stay awake for 40 minutes
<daniels> (daniels, meet years of accumulated bitterness.  years of accumulated bitterness, meet daniels.)
<seb_lamd64> pitti, but I don't get where it founds /dev/cdroms/cdrom0
<pitti> daniels: how long does the split server need?
<daniels> Kamion: i much preferred the fifteen seconds or so.
<Kamion> heh
<pitti> seb_lamd64: that indeed looks like devfs...
<seb_lamd64> pitti, /dev doesn't even has a /dev/cdroms/cdrom0
<Kamion> seb_lamd64: if that's a live CD that's where it is in d-i
<pitti> seb_lamd64: did you ever see that problem in an installation?
<Kamion> casper copies in /dev/cdroms/ at shutdown
<seb_lamd64> pitti, nop
<daniels> pitti: it'll land as soon as dapper opens if I don't get it into Debian first.  gravity wants to work on 7.0 now, so hopefully that'll work out pretty well.
<Kamion> but that may not be enough
<seb_lamd64> Kamion, yep, that happens with amd64 and x86 liveCDs from today
<Kamion> seb_lamd64: what's the effect?
<seb_lamd64> Kamion, computer:/// and the desktop have a "cdrom" icon
<pitti> seb_lamd64: it's not actually wrong, cdrom seems to be the cloop live image, and CD-RW (or whatever) the actual drive
<Kamion> that's not a showstopper on the live CD, I don't think
<seb_lamd64> nop a stopper, no
<pitti> seb_lamd64: ... whcih you can't mount anyway since there already is a CD in it
<seb_lamd64> just quite ugly
<pitti> Kamion: nope, it's just a cosmetical thing; we eventually shuold make it nicer, but not for preview
<hunger> Would it be possible to add zeroconf to /etc/services? Should be 5353/udp IIRC.
<Lathiat> hunger: thats not 'zeroconf' its 'multicast dns'
<seb_lamd64> pitti, but where does it find it? It's not listed by mtab neither hal
<hunger> Lathiat: Could that get added then?
<Lathiat> hunger: not the person to ask, just pointing that pout :)
<pitti> seb_lamd64: as soon as we get a new CD set with the new xorg and casper, I try the live CD again
<seb_lamd64> pitti, k
<sivang> when are we expecting to have now images for testing?
<Kamion> I am not answering questions of that form. :-)
<tepsipakki> nautilus keeps crashning (same for trashapplet) if $HOME is behind a symlink
<tepsipakki> -n
<tepsipakki> uptodate breezy
<seb_lamd64> what an idea to not use a real folder for that
<tepsipakki> eh?
<sivang> Kamion: oops, s/now/new/ :)
<daniels> err
<Kamion> still not :)
<tepsipakki> seb_lamd64: it is a real folder..
<Kamion> os-prober's in, xorg/amd64,i386 is in, xorg/powerpc's in accepted, waiting for casper
<daniels> Kamion: so, with all this bugfixing I've been doing in xorg, for releases, it's reminded me of something
<daniels> Kamion: y'know how multiseat duplicates all of xserver-xorg's maintainer scripts and shit?
<tepsipakki> seb_lamd64: $HOME is /u/lai/lk/uid, but /u -> /home/u because it is a local folder, not behind NFS
<Kamion> daniels: uh-huh
<daniels> Kamion: we should probably think about disabling it unless explicitly requested for final
<Kamion> can it be updated reasonably?
<Kamion> but yeah
<daniels> 'possibly, but I totally can't be arsed'
<Kamion> I've put it on my to-do list, I'll see if I can do it
<pitti> carlos: here?
<Kamion> lamont-away,infinity: can you hurry casper_1.14 through? it's just an arch: all build
<carlos> pitti, hi
<carlos> pitti, yes
<Kamion> oh, never mind, it's in accepted now
<daniels> Kamion: if we're not actually going to be supporting multiseat (read: giving someone some time to do XorgAutoconfiguration), it's probably best to just take it out behind the shed
<Kamion> I think some of our approach has to be dictated by whether the people who wanted multiseat in the first place are still interested (to the extent that they'd complain if we dropped it from breezy)
<daniels> Kamion: the answer as I know it (in that I was directed to not spend work time on fixing it) is 'no'
<seb128> CD sessions froze, if somebody wrote something for me write it again :)
<Lathiat> seb128: no one said anything with your name :)
<Lathiat> (nobody loves you)
<seb128> k
<daniels> seb128: just more gtk bugs
<pitti> seb128: oh, I just pasted you the patch for a huge gtk bug, but now it's lost
<pitti> :-)
<pitti> daniels: heh
<seb128> :p
<tepsipakki> the nautilus-crasher is in gnome-vfs, and it occurs if the first part of $HOME is a symlink (in this case, /u ->). If I make /u a real directory and then add a symlink to the real $HOME under it, everything works
<tepsipakki> and that's why I haven't hit this before
<seb128> tepsipakki: could you describe what is the first part of a dir?
<tepsipakki> umm
<seb128> you don't use /home/<user> as home?
<tepsipakki> no, this is a campus-wide system
<seb128> and...?
<seb128> could you describe the setup
<tepsipakki> my home is /u/lai/lk/tjaalton.. the "first part" here is /u =)
<seb128> and what make it crashing?
<seb128> do you have a backtrace?
<tepsipakki> normally we have links under a directory named /u, but in this case /u itself is a symlink (under /home/u, laptop ie. local home)
<tepsipakki> well, yes but no debugging symbols
<tepsipakki> http://users.tkk.fi/~tjaalton/crash.txt
<Kamion> live fs and install CDs building
<seb128> tepsipakki: apt-get install libgnomevfs2-0-dbg
<tepsipakki> seb128: yes, will try
<tepsipakki> seb128: http://users.tkk.fi/~tjaalton/crash-dbg-nautilus.txt
<tepsipakki> seb128: http://users.tkk.fi/~tjaalton/crash-dbg-trashapplet.txt
<tepsipakki> they look similar ;)
<ogra> seb128, the issue with 7150 is that disabling the button doesnt solve the problem :)
<seb128> tepsipakki: http://bugzilla.gnome.org/show_bug.cgi?id=308639 upstream
<seb128> ogra: I figured that, I don't really get Matt's question though
<ogra> seb128, i suspect he expected the key to do what its name says ;)
<ogra> seb128, disable_lock_screen should be reamed to disable_lock_button ;)
<tepsipakki> seb128: well, this is on login
<seb128> /apps/panel
<seb128> the namespace count
<seb128> tepsipakki: the backtrace is the same
<ogra> yup... but still the name of the key is confusing
<tepsipakki> seb128: ok, luckily this is easily avoided
<seb128> you don't have real bugs to start discussing about key name not beeing optimal?
<mjg59> jbailey: 1126184936.3740.139.camel@petra on lkml looks interesting
<seb128> tepsipakki: maybe you could comment on the upstream bug saying what you do to get the bug
<tepsipakki> seb128: yes
<ogra> seb128, haha.... 
<Mithrandir> daniels: 9925 works just fine for me; close it?
* sivang downloads live for testing
<mjg59> crimsun: Ping?
<elmo> Kamion: I take it I shouldn't do the NEW l-p or BYHAND d-i?
<Kamion> elmo: not yet, please
<elmo> cool, just checking
<Kamion> hm, I thought we had those NEW l-p ages ago, but evidently mdz just NEWed the source or something
<Kamion> oh well, it'll have to miss preview
<lamont> Mithrandir: my bad on that hwclock.sh bug - I fixed it about the same time as I uploaded to ubuntu
<Mithrandir> lamont: but you forgot to mention it in the changelog. :-P
<daniels> Mithrandir: just did, thanks
<lamont> Mithrandir: yeah
<lamont> Mithrandir: likewise, I think that the latest debian upload of util-linux is a non-diff for ubuntu
<lamont> IIRC
<Mithrandir> lamont: that'd be nice.
<jbailey> mjg59: It seems too new for google to have indexed.  Who's it from?  I'll look it up in today's lkml.org
* lamont double checks
<lamont> Mithrandir: the bug in question (deb323872 - I think) was fixed in 2.12p-7
<Mithrandir> lamont: the ==-bug?  Yeah, it was.
<lamont> yeah
<lamont> iz the only change in -7
<mjg59> jbailey: Karel Zak
<lamont> then there's -8, which deals with a dangling symlink, which should not be the case on grandma'
<lamont> s computers
<Mithrandir> lamont: still the LSB diff, though, and some other smallish cleanups by mdz (usplash friendlyness and such)
<herzi> which package do is use to file bugs for linux-image-*? they're not mentioned in bugzilla
<mjg59> herzi: linux
<herzi> thx
<lamont> Mithrandir: ah, ok.  I'll pull the ubuntu changes back into debian then..
<mvo> ping jamesh 
<lamont> Mithrandir: note that the LSB stuff is down to a 18 line diff or so
<jbailey> mjg59: Ooo, the failed resume support there?
<jbailey> That's nice.
<Mithrandir> lamont: nice.
<lamont> Mithrandir: since the debian version includes lines of the form: log_begin_msg () { echo -n "$@"; }
<jbailey> My patch to do that is in file, but didn't make it into Debianyet.
<lamont> prolly closer to a 25 line diff, but it's one block of text
<herzi> BenC: can you take a quick look at http://bugzilla.ubuntu.com/show_bug.cgi?id=14964 and tell me whether this can be achieved within breezy?
<Mithrandir> lamont: can't you just wrap that in an if [ ! -f ... ]  ?
<lamont> no.  they might have lsb-base installed on the system.
<lamont> or do we have a file that we know only exists on ubuntu machines?
<hunger> Is the network-manager in universe up to date? I can't install it due to libcairo1 dependency.
<Kamion> I'm increasingly of the opinion that it's OK to just start using lsb-base functions on Debian too
<Kamion> if there's a difference in required output format, it should be handled in the lsb-base functions in Debian
<lamont> Kamion: does it not violate policy?
<lamont> ah, woot!
<Kamion> lamont: see above
<Kamion> lamont: I'm not saying it *is* handled properly there (it wasn't, last I checked), but that seems to be the obviously correct approach ...
<lamont> Kamion: I'd be inclined to say let's fix lsb-base, and then we can go there... not the other way around...
* hunger has not yet seen a guide when to use which function in inti scripts.
<Kamion> lamont: a number of people have already started to use lsb-base, so hopefully that'll provide momentum
<lamont> nice
<Mithrandir> hunger: nm is br0ken because it doesn't recognize the dbus version, so the cairo rebuild failed
<Diziet> One of the firefox bugs I'm triaging is more or less equivalent to a wiki page mentioned in the obsolete https://wiki.ubuntu.com/BreezyBadger under `Un-prioritized stuff' but not in https://wiki.ubuntu.com/BreezyGoals.
<Diziet> (Triageing ?)
<Diziet> It claims to be `major' which is an exaggeration anyway, but should I put a reference to it anywhere, or shall I just let it wallow in amongst the `normal' bugs ?
<lu|dinner> (triaging)
<Kamion> ("triaging", I think, because a following "i" still produces the same "g" sound as a following "e".)
<hunger> Mithrandir: Thanks!
* Kamion looks through BreezyBadger
<Diziet> It's 7023 which I think is equivalent to MimeManagement.
<Mithrandir> hunger: I guess prodding a MOTU to update the snapshot might be the best thing to do.
<Kamion> MimeManagement already has a link to 7023.
<Kamion> and I see 7023 has a link to MimeManagement, too
<Diziet> Indeed.  But do they want a link anywhere else ?
<Diziet> Also it has `Target Milestone: Ubuntu 5.10'
<Kamion> so I think it's probably OK to just reprioritise it as appropriate, and bring it up at the next conference if you think it's a substantial piece of work that you want a chunk of time allocated to
<Diziet> Well, actually, I don't think it's that important.  But I don't want to overrule some earlier decision by someone ...
<Kamion> let me just find out who set that milestone
<mvo> ping niran 
<Diziet> It looks to me like it was the submitter./
<Kamion> Diziet: Jeff Waugh set the milestone when he made comment #2
<Diziet> s,/,,
<Kamion> (unfortunately, the only way I know of to find this out is to hunt through mail archives, which is why I keep a full archive of ubuntu-bugs ...)
<Diziet> Oh, I should look in `view bug activity'.
<Kamion> ah
<Kamion> !
<Kamion> well, that comment was made around the Hoary release, and I think it's clearly blown past the stage in this release cycle where one might add that feature
<Diziet> Indeed so.
<Kamion> We should get an "Ubuntu 6.04" milestone added
<Diziet> Should I set it to no milestone, normal and email Jeff ?
<Kamion> Yes, that sounds reasonable for now
<Amaranth> i hate wireless networks
<dholbach> re
<Kamion> mjg59: did you see this morning's usplash upload as well as my mail about last night's?
<Kamion> (I should get those changes back into BOGL)
<mjg59> Kamion: Yup
<mjg59> Kamion: So it all works now?
<daniels> Kamion: g'luck with preview, thanks for dealing with the updates etc.  i'll be back in the 'morn.
<Kamion> mjg59: seems to, yes
<mjg59> Kamion: Rock
<Kamion> beautiful usplash on beautiful huge powerpc framebuffer
<elmo> kamion: fyi succesful i386 live test on kinnison's toshiba portege a100
<mjg59> Kamion: Ideally, we might want to provide higher coloured images plus a usplash package that uses linear framebuffers on x86
<Kamion> ("beautiful" may be an exaggeration. -ed)
<mjg59> That way people who use vga=foo could get a nicer picture
<mjg59> But probably post-breezy
<Kamion> mjg59: yes, having 256 colours would be good on this framebuffer
<Kamion> mjg59: the Kubuntu branding requirement is probably pre-breezy, so maybe a 256-colour version could go in at the same time ...?
<Kamion> although god knows how to get the right artwork installed that early
<elmo> what's the password for ubuntu on live CD?
<Kamion> elmo: none
<Kamion> (locked)
<elmo> kamion: ah
<Mithrandir> Kamion: there's a md5 hash in /etc/shadow.
<Kamion> elmo: bitten by #7150?
<elmo> daniel locked it while testing the hot keys and now can't get in :)
<Kamion> elmo: switch to tty1 and 'sudo passwd ubuntu'
<elmo> kamion: do we no longer auto-login a console session?
<Kamion> elmo: we certainly do
<Kamion> six of them
<Mithrandir> four of them
<Mithrandir> is it six now?
<Kamion> yes, we just sed /etc/inittab
<Mithrandir> elmo: but it's very secure. :-P
<Kamion> s/getty/login/ or something equally bright
<elmo> hmm, ok, could be PEBKAC ;)
<Kamion> Mithrandir: I think the password is temporarily set to 'ubuntu' and then locked after that
<Kamion> preview-candidate install CDs up, please test
<elmo> mjg59: is the nx6125 thermal trip work around going to get into before final?
<Kamion> live building
<Kamion> well, not quite up yet, still mirroring - 20050908.6
* mvo rsync preview
<Kamion> really up now
<mjg59> elmo: Nngh.
<mjg59> elmo: With luck
<mjg59> elmo: I've tracked it down some more. The behaviour is utterly mad.
<mjg59> Basically, the thermal trips are wrong if the timer is overridden from irq 0 to irq 2
<mjg59> Which is a bit of a WTF type situation
<Lathiat> is there any reason we dont install libesd-alsa0 by default? this woudl free up /dev/dsp for the various applications that use it (games, flash, vmware, etc)
* pitti burns ppc install
<elmo> hmm, ok current live doesn't like nx6125's, it goes screwey as soon as you hit X
<mjg59> elmo: Yeah, X is still going to explode
<mjg59> We're working on that
<pitti> Lathiat: erm, we do
<Lathiat> we do?
<Kamion> desktop: * libesd-alsa0
<elmo> mjg59: ok
<Lathiat> err
<Lathiat> so we do
<Lathiat> when did that change?
<Lathiat> it definately was steal using /dev/dsp last week
<pitti> Lathiat: maybe two or three months ago
<Lathiat> ... weird
<Kamion> 2005-05-19 11:36:11 GMT Martin Pitt <martin@piware.de>  patch-31
<Kamion>     Summary:
<Kamion>       switch from libesd0 to libesd-alsa0
<Lathiat> i still had /dev/dsp being used up until last week
<pitti> Lathiat: we use alsa dmix by default now
<Lathiat> pitti: ya, which is why its nice to keep /dev/dsp free because that doesnt allow you to use it more than once even with dmix
<pitti> right, that was the idea
<Lathiat> oh well, weird
<Lathiat> something must of happened
<BenC> anyone have any ntfs partitions on a breezy box with 2.6.12-8 kernel?
<Kamion> perhaps you never upgraded to the new ubuntu-desktop until recently (e.g. due to not dist-upgrading)
<pitti> BenC: we can't create them, right?
<Lathiat> i've been dist-upgrading the whole time
<Lathiat> BenC: yes
<Lathiat> pitti: not afaik
<pitti> Lathiat: and you have u-desktop installed=
<BenC> Lathiat: can you mount the ntfs partition?
<Lathiat> pitti: yep, its even using alsa now, but it wasnt last week
<BenC> I've got a bug report that shows an error mounting an ntfs partition (so grub ignored it, and they couldn't boot to windows anymore)
<Lathiat> BenC: interesting
<Lathiat> BenC: works fine here
<shackan> BenC, here too ( but with 2.6.12-7 )
<Kamion> Riddell: Kubuntu live filesystem build running
<BenC> probably this guys ntfs partition got borked then
<BenC> thanks
<elmo> live cd on a 15" PB is fine, but that's probably not surprising
* pitti taps foot while waiting for the .7 live CD
<Diziet> http://www.ubuntulinux.org/include/ubuntu1.png has Content-Type: text/plain.  Should I email webmaster like the website says ?
<lifeless> how do we turn metacity back to fast mode in breezy ?
<pitti> elmo: oh, good to hear; this morning it was completely borked
* lifeless has beenm looking at kinnison testing the cd
<Kamion> elmo: good stuff. your powerbook's newer than mine so it wasn't guaranteed that the framebuffer was the same
<elmo> Diziet: don't bother, hn073 already filed a bug
<elmo> hno73 too
<sivang> pitti: there's a new one to test?
<pitti> sivang: well, according to Kamion there should be a new one, which should be .7
<Kamion> just a sec, it's mirroring
<pitti> sivang: this is the one withe ppc fixes
<Kamion> amd64's still oversized, bah
* pitti does ppc install now
<Kamion> lifeless: install CD or live CD?
<sivang> pitti: ah, for ppc64/CHRP booting ?
<Kamion> sivang: no
<lifeless> Kamion: livecd
<Kamion> nothing along those lines has changed recently
<pitti> sivang: for the usplash break and hfs kernel hang
<sivang> Kamion: k, just wanted to know. 
<lifeless> Kamion: the black rectangles on minimise, for instance.
<Kamion> lifeless: grab the new live CD, please; that's one of the things we were just fixing
<lifeless> Kamion: uhn, that was burnt 10 minutes back, is that new enough ?
<Kamion> nope
<Diziet> `Mozilla has considerable problems with embedded internally-handled types like text/html and image/gif when they have unusual file extensions' - no shit.
<Kamion> try 30 seconds
<lifeless> Kamion: K
<pitti> yay, .7
<Kamion> lifeless: alternatively add a sensible Modules section to xorg.conf
<pitti> lifeless: we release fast, don't we? :-)
<seb128> pitti: can you note what permission .dmrc has on the new install? That's for #14910
<Mithrandir> hey, we have 30 minute days, you can't assume that something which is 1/3 of a day out of date is the latest&greatest.
<sivang> pitti: I see the -7 there, will download and test
<Keybuk> hmm, so how do people test these CDs?  spare machine you blow away each time?
<Kamion> Keybuk: spare partition
<elmo> should the CD upgrade work?
<mvo> Keybuk: basicly yes
<Kamion> EVERYONE: please test current install and live CD images as Breezy preview release candidates
<elmo> as in, pop a breezy CD in a hoary machine and hva eit do the right thing?
<mvo> elmo: modulo the ubuntu-desktop problem and that it does not rewrite the sources.list 
<sivang> Keybuk: I chose to keep data, and installed on my ubuntu mirror fs, works well
<elmo> ...
<pitti> elmo: we still have three X conffile questions, otherwise it worked reasonably well yesterday
<elmo> mvo: hmm, ok will breezy be better?
<Keybuk> ok
* Keybuk is about to pop out to find a cd writer
<mvo> elmo: better in the way that it rewrites the sources.list? or that it does not remove ubuntu-desktop :) ?
<\sh> Kamion: I will test ubuntu + kubuntu tonight...
<Kamion> sivang: it's pretty dodgy to put your new root filesystem on a filesystem that already has stuff on it; I'd caution against doing that in the future
<Kamion> \sh: that will be too late
<\sh> argl
<elmo> mvo: both :)
<Kamion> we are releasing the preview today
<\sh> I need to get a bloody usb cdrom
<sivang> Kamion: sure, but I didn't mind it get blown away - and didn't want to waste more time by moving it since resize didn't work
<Keybuk> Kamion: when is too late? :p  it'd gonna take me an hour to get a drive to burn a CD <g>
<\sh> i  can't help it...I have to go later into office and grab one there *grrr*
* sivang uses /current. hope the links are updated
<Kamion> Keybuk: you'll probably be in time
<Kamion> sivang: yes
<Keybuk> ok, I'll head off now then
<mvo> elmo: the ubuntu-desktop remove thing will be fixed after preview. the rewriting of the sources.list is tricky, there is a bug open, I probably need advice from mdz if that's something we want to do (and if, if we should do it for breezy)
* seb128 rsyncs
* \sh cries
<Kamion> \sh: that said, Kubuntu CD testing tonight definitely won't go to waste
<Kamion> even if it's after preview, Kubuntu CDs need more testing in general
<elmo> is the live image rsyncable?
<Kamion> elmo: yes
<pitti> yes
<\sh> Kamion: well...i will test them in anyway...but I want to have an original media and not a tweaked one...
<pitti> pretty well
<pitti> elmo: I get speedups of 10 and above
* sivang almost done rsyncing
<\sh> but I cried because I saw my tax papers...and what I earned before tax and what I had after tax...it's really sad
<sivang> (5 mins differnece, cool)
<elmo> hum, what options do I want?
<elmo> I'm doing .6 -> .7 and it seems to be doing it from scratch
<pitti> elmo: only at the beginning for me, then it becomes really fast
<elmo> pitti: ah, ok
<pitti> rsync -vP rsync://cdimage.ubuntu.com/cdimage/daily-live/current/breezy-live-amd64.iso breezy-live-amd64.iso
<pitti> nothing special
* sivang is copying image to burn server, and vncing to that windows machien to burn
<Kamion> the first 4MB or so always seem to re-download from scratch
<Kamion> I'm assuming it's an index or something
<pitti> elmo: speedup is 20.66 - that's not bad :-)
<Diziet> elmo: Do you have a reference for that Content-Type bug ?
<elmo> https://rt.admin.canonical.com/Ticket/Display.html?id=38
<elmo> Diziet: ?
<elmo> err, s/?/^--/
<Diziet> Thanks.
<Lathiat> hrm, the imaging shrinking in firefox has gotten horrendous
<Diziet> (That bug) plus (barmy Firefox) = 8911, which is on my list.
<Lathiat> it seems to be just flat dropping pixels or something
<elmo> ok, so doing the CD based upgrade:
<elmo> a) the debconf dictionary question popped up - wasn't that fixed already?
<sivang> :-( 1hr eta for live download...
<elmo> b) the graphic debconf front end needs some branding love, it's got a big-ass debian swirl on it
<elmo> c) glibc halted the upgrade with the non-debconfified "can I restart services question?"
<tim1> is there a specific reason f-spot has been updated to 0.1.1 recently although 0.1.2 was already available at that time?
<dholbach> tim1: i suggest you ask in #ubuntu-motu
<pitti> wow, usplash on ppc works finally
<pitti> Kamion rocks :-)
<dholbach> pitti: YAY! :)
<dholbach> usplash love! :)
<tim1> dholbach: oh, I didn't know that channel, thanks
<mpt> woo
<dholbach> i'd just like the text to be in a brighter colour
<dholbach> but that's just me :)
<pitti> dholbach: well, failures stand out better that way IMHO
<Kamion> pitti: cool :)
<Kamion> elmo: b) I de-branded that post-hoary (debconf 1.4.49ubuntu2)
<pitti> so the only thing is that I can't boot MacOS now due to the disabled hfs scanning, but I don't actually care about it anyway :-)
<elmo> Kamion: ah, of course, it's still hoary's debconf
* Kamion does a Dutch install
* sivang would like to also try the graphical installation, if that's already in :) (this is not buggery)
<elmo> ok, --partial clearly isn't working at all
<elmo> hateful rsync
<Mithrandir> elmo: partial just means it doesn't eat what you've transferred already.
<Kamion> sivang: no
<maswan> Mithrandir: partial just means that it will eat your whole almost-correct image and replace it with the first N megabytes. :/
<Mithrandir> maswan: that too
<Kamion> maswan: amen
<Kamion> bloody irritating, that
<Kamion> --partial-dir=DIR looks like it ought to help thre
<Kamion> there
<maswan> btw, would a cdimage.u.c mirror be good for you? and if so, what time of day should I mirror? so far, I have silly large ammount of free space. ;)
<Kamion> cdimage.u.c updates throughout the day really, but around 10am London time wouldn't be bad
<Kamion> you do realise it's HUGE
* maswan nods
<maswan> yes, I know the size of it
<maswan> would a mirror be a net gain or loss in bandwidth usage for you guys though?
<elmo> oh dear
<Diziet> Have I moaned about bugzilla today yet ?  It's utterly hateful.
<elmo> so rsync --partial works if you do it on the right machine
<Kamion> 10am is after the big Ubuntu daily and daily-live cron jobs
<elmo> works better
<Robot101> Diziet: Status: CLOSED Resolution: WONTFIX
<tseng> Diziet: if you think you've hit rock bottom with bugzilla, there is always malone..
<Kamion> maswan: I suspect net gain, we certainly have tens of downloads a day of the dailies
<maswan> Kamion: *nods*, I'll take a good look at it then.
<Kamion> and that's only the reliable ones
<mdke> BenC, are you around?
<Kamion> maswan: thanks
<Riddell> Kamion: the kubuntu live CD is oversized by about 3Megs, is the only option to remove stuff from the desktop seed?
<Diziet> How do I make a bug a duplicate of some other bug, and does that do anything useful ?
<sivang> ok, /me is going for an install cycle again
<sivang> bbl
<Kamion> Riddell: it's possible to remove stuff from the live seed too, but I see you've already done most of that
<Kamion> Riddell: trying to get it within size now will take too long; let's just live with the live CD being oversized for preview
<Kamion> we'll see how the next Kubuntu live CD looks, anyway
<Riddell> Kamion: right
<Diziet> Oh, I can't mark it as a duplicate when it's closed.
<\sh> yay...dancing the xorg dance again ;)
<Kamion> the Greek fonts we have installed are pretty awful - hopeless kerning
<Kamion> I think characters are coming from a mix of fonts or something
<Kamion> Riddell: Kubuntu install CD preview candidate up
<slomo> hm, does someone know how i can disable password (and other form data) saving in epiphany?
<Riddell> Kamion: great.  how final is the current live CD?
<Kamion> Riddell: I'm just building a preview candidate of that now
<ogra> jbailey, where is man initramfs.conf ?
<dholbach> Kamion: will the partition dialog be translated in the release?
<pitti> Kamion: ppc/install is golden; also, nice to have linux-wlan-ng on the CD to get online without trouble :-)
<seb128> pitti: have you noted the .dmrc rights?
<pitti> -rw-------  1 martin martin 26 2005-07-18 08:06 .dmrc
<pitti> what's wrong with that?
<seb128> pitti: https://bugzilla.ubuntu.com/show_bug.cgi?id=14910
<seb128> pitti: not wrong, but this bug is weird ...
<Amaranth> btw, has anyone found any bugs with smeg?
<Lathiat> Amaranth: dude! 
<Amaranth> the only one brought to me was a bug in pyxdg 0.14 and gnome-menus 2.10.x
<ogra> Amaranth !
<pitti> seb128: hm, having .dmrc owned by sb else than the owner would indeed be wrong, but fussing about the perms is rather a gdm bug
<pitti> anyway, testing ppc live now
<Kamion> dholbach: which dialog exactly?
<seb128> Amaranth: there is 2 bugzilla bugs on smeg ... should I set you as default assignement for smeg package?
<Lathiat> Amaranth: found any kind of reliable net access? :)
<ogra> Amaranth, i have several reports with vanishing education menus, the education menu just disappears unintentional for time to time...
<dholbach> Kamion: "resize the disk", ... - it has 4 options on it - 3 were not translated into german
<dholbach> Kamion: the help text was though
<Amaranth> Lathiat: only two days a week on windows machines at school
<Amaranth> brb
<ogra> Amaranth, any idea what could cause this ? as menu expert ...
<Lathiat> Amaranth: ah
<Kamion> dholbach: some of those are Ubuntu-specific, I haven't received translations for them yet - feel free
<ficusplanet> Speaking of SMEG, you guys know what it is, right? http://en.wikipedia.org/wiki/Smegma
<Kamion> (nor have I particularly solicited translations, in fairness)
* Lathiat laughs at ficusplanet 
<Lathiat> ficusplanet: see also wikipedia.org/en/Smeg
<Lathiat> err
<Lathiat> en.wikipedia.org/wiki/Smeg
<jbailey> ogra: Missing atm.  It'll be added right after preview.
<dholbach> Kamion: will have a look at them
<Kamion> dholbach: thanks
<ogra> jbailey, how do i set rsize and wsize for the nfs mount ? 
<ogra> jbailey, for the ltsp clinet that is...
<Kamion> Riddell: Kubuntu live CD up for you now too
<tseng> ogra: in fstab
<tseng> ogra: er :)
<ogra> tseng, for a boot mount in an initramfs ? 
<tseng> ogra: MAGIC VOODOO
<ogra> haha
<ogra> :)
<Lathiat> hey Travis_Watkins_ 
<Travis_Watkins_> heh
<jbailey> ogra: How do you usually set those?  Are they passed to nfsmount?
<Lathiat> windows machine crash on you? ;p
<Amaranth> network died
<Amaranth> stupid wireless crap
<ogra> jbailey, normally i set them as mount options in fstab...
<Lathiat> ah
<ogra> jbailey, or at the mount command...
<jbailey> ogra: There doesn't appear to be any way to set those right now.
<ogra> ok
<Amaranth> ogra: ok, got any more details?
<jbailey> ogra: So how would you like it to look? =)
<Amaranth> otherwise i'm going to say people are deleting their menus :)
<ogra> jbailey, i'm just trying to triage #12942
<ogra> Amaranth, nope, i've seen it too
<Kamion> infinity: any idea why the Kubuntu live filesystems are getting language-pack-gnome-en installed in them?
<seb128> Amaranth: ping
<ogra> Amaranth, it just vanishes, no extra actions required, no special time after which it happens and it doesnt happen every session
<Amaranth> ogra: hrm, got a ~/.config/menus/applications.menu from when this problem is showing?
<Kamion> the seeds are correct
<Amaranth> seb128: pong
<ogra> Amaranth, and its happening on fresh installs
<Amaranth> *boggle*
<seb128> Amaranth: could you reply to the question I asked like 10 min ago? :)
<Amaranth> ok, so it's not smeg related ;)
* Amaranth looks
<Amaranth> oh, yeah
<seb128> Amaranth: dunno if you ignore me on purpose :p
<ogra> Amaranth, nope, but i suspect gnome-menu or something related to it...
<ogra> worst case gamin :(
<Lathiat> Amaranth secretly hates you
<Amaranth> seb128: got flooded with question here and irl
<Amaranth> in html class, i know more than the teacher so everyone asks me things
<jbailey> ogra: Ah, cool.  Aside from adding those options, is there anything else you might need?  Or is a generic "mount options" in initramfs.conf good enough?
<seb128> Amaranth: k. So do you want to bugzilla.ubuntu bugs for smeg?
* Lathiat grins at Amaranth 
<Lathiat> i get that
<ogra> jbailey, usplash ;)
<Amaranth> seb128: yeah
<ogra> jbailey, that'd be all :)
<Amaranth> seb128: since that'll send me an email, which is better than the forums now
<jbailey> ogra: Sorry, what about usplash?
<ogra> jbailey, running on the thin client on boot ;)
<Kamion> lamont: please change "ubuntu-live" to "kubuntu-live" in the kubuntu case in livecd.sh
<ogra> jbailey, just joking, i think its to much effort now :)
<jbailey> 'kay.  You'll inherit that as part of the run-usplash-earlier bit.
<jbailey> ogra: BTW, did you see my hack yesterday to replace usplash graphics?
<ogra> jbailey, err, i really wasnt serious... i dont expect usplash for thin clients :)
<ogra> yup i saw that
<ogra> i'll do a pic as soon as i have some spare time
<jbailey> ogra: It is in the plans, though.  mjg59 wants usplash to start earlier.
<lamont> Kamion: ah, exists now... ok
<ogra> jbailey, for breezy already ?
<seb128> Amaranth: thanks
<jbailey> I don't have the palette numbers handy, butit's like 0 background, 2 is foreground text, and 13 is the failed colour or something like that.
<Kamion> lamont: not sure whether we're going to redo preview candidates for this, but I'd like to have the option ...
<ogra> jbailey, thanks
<Amaranth> can someone work some bugzilla foo and get me a url that shows all the smeg bugs?
<lamont> Kamion: I assume you want that pushed all the way to the build trees, yes?
<pitti> Kamion: powerpc/live works fine
<Kamion> lamont: yes please
<Kamion> pitti: great, thanks
<Kamion> I have golden i386/install and i386/live, testing amd64/* now
<Lathiat> Amaranth: see under 'advanced search'
<Lathiat> Amaranth: component->smeg
<Amaranth> that only gets me one bug
<Amaranth> seb128 said there were two
<Amaranth> does http://bugzilla.ubuntu.com/buglist.cgi?component=smeg look right?
<Lathiat> yeh
<Lathiat> ig uess theres only 1?
<seb128> Amaranth:  https://bugzilla.ubuntu.com/show_bug.cgi?id=13797 and https://bugzilla.ubuntu.com/show_bug.cgi?id=14614
<pitti> Kamion: amd64/install success
<seb128> Amaranth: what email do you use? 
<Amaranth> seb128: alleykat@gmail.com
<seb128> Amaranth: so I can assign smeg bugs to you and reassign them to the right place
<Lathiat> right, the first bug is assigned to gnome-menus
<Amaranth> seb128: sure
<Amaranth> err, for 13797 i thought i switched to GNOME's icon selection dialog so i dunno what i can do there
<Lathiat> Amaranth: hrm i just get a standard file selector here
<seb128> Amaranth: that's a common widget?
* Amaranth really wishes his HD hadn't crashed
<Amaranth> hrm
<seb128> Amaranth: the fileselector dialog could be with preview mode
<Amaranth> i know i have a preview in there
<Lathiat> Amaranth: heh did you try sticking it in the freezer?
<Amaranth> Lathiat: that'll fix overheating and frying it?
<Lathiat> Amaranth: err
<Lathiat> Amaranth: wtf did you do?
<Amaranth> had two very hot HDs one on top of another and forgot to move them when i finally got both hooked up
<Amaranth> one fsck later and it was dead
<Lathiat> hmm
<Lathiat> how dead
<Lathiat> did it detect?
<Amaranth> yes but it lost all the partition information
<Amaranth> so i wiped it and reinstalled
<Lathiat> oh wow
<Lathiat> that sucks
<Amaranth> and on the 3rd or so boot my /home partition lost it's superblock
<Amaranth> so i'm assuming it's toast
<Lathiat> nice
<Amaranth> 120GB Maxtor, about a year old
<sivang> man
<doko> mvo: ping
<Lathiat> wow gdesklets has a nice memory leak
<sivang> I lost my grub configuration, and installer never even offered me to install grub
<Lathiat> it was up to 54%
<sivang> defaulted straight to lilo
<Lathiat> sivang: using xfs?
<mvo> doko: pong
<sivang> Lathiat: no, plain ext3 under LVM
<sivang> Kamion: I used the "use free space for LVM" option
<mvo> doko: sup?
<Amaranth> once i get my student loan i should be able to get a new HD and dsl again, otherwise right now all i can do is collect bug reports
<Amaranth> wait, i might be able to boot up a hoary live cd on one of the library computers
<Lathiat> Amaranth: you cant warranty your existing hard drive?
<sivang> Kamion: the preset LVM config uses while fs for / , doesn't offer you to have a seperate home etc..
<Amaranth> Lathiat: that doesn't get my breezy install back
<Amaranth> Lathiat: or access to the internet to work on things
<doko> mvo: how do I upgrade a hoary system to breezy using the update manager?
<Lathiat> Amaranth: but saves you buying a new one, good start
<mvo> doko: not at all, it's not supposed to do dist-upgrades
<Amaranth> brb, switching to the library
<mvo> doko: there has been work in this direction but it didn't made it for breezy (unfortunately)
* sivang tried to reinstall grub through chrooting to the hoary partition
<Kamion> sivang: that's fabbione's baby, I haven't looked at it much
<Lathiat> sivang: outside of the chroot
<Lathiat> sivang: /path/to/hoary/grub-install -R /path/to/breezy
<Kamion> sivang: grub doesn't work with LVM AFAIK
<Kamion> (/boot on LVM at any rate), or if it does we don't have the autoconfiguration magic for it
<Kamion> amd64/live good
<sivang> Kamion: I see, then we should probably disable it or something, becasue someone might get tempted to use the "use free space for LVM" option and end up in the same state..:)
<Kamion> Lathiat: whoa, don't do that, grub-install calls other binaries like grub, I'm not sure what happens if they mismatch
<Lathiat> Kamion: oh? hrm, worked for me last time i needed to :)
<Kamion> sivang: talk to fabbione, and I believe it's meant to have a separate /boot outside the LVM ideally
<Lathiat> well i used /path/to/breezy/sbin/grub-install -R /path/to/breezy
<sivang> Kamion: ok, cool. I will sure metnion this to him if not open a bug report about it
<Kamion> sivang: but there is nothing actually wrong with the fallback to lilo, I don't consider it unreleasable just for that
<Lathiat> cus using grub-install inside the chroot didnt work
<Kamion> Lathiat: guess you were lucky
<sivang> Kamion: yes, but I think that me choosing "install lilo on /dev/hda5" which is NOT my boot partitoin messing my boot config, is not what you expect it to do...
<Kamion> sivang: I'm pretty sure the lilo-installer default is to install in the MBR, not in a partition
<sivang> Kamion: sure thing, but I was offered to install it on /dev/hda5 , and did that (at least so it seemed from the interaction with d-i).
<Kamion>  If unsure, install LILO into the Master Boot Record.
<Kamion> ^-- lilo-installer/bootdev
<Mirv> is rosetta's export-function's failure a known problem? worked the day before yesterday, but not anymore..
<dholbach> Kamion: could you please enlighten me regarding the ubuntu-specific partition-installer translation bits? where can i find them?
<ogra> dholbach, in the templates file in the udeb
<sivang> Kamion: so what you are saying is that even if I choose to have it installed under /dev/hda5 , it still leaves touches my grub config on the MBR
<sivang> ?
<seb_lamd64> liveCD amd64 works fine
<dholbach> ogra: which udeb?
<ogra> dholbach, dunno how the prtitioner one is called... partman ?
<dholbach> ogra: i see... that's as much as i figured ;)
<Keybuk> right, now to install this
<mvo> hm, install-i386 installs a i386 kernel on my k7 test-machine
<sivang> Lathiat: hrm, seems my grub foo is aging.. how do I restor it ? :)
<ogra> mvo, thats normal
<sivang> Lathiat: (it misses /dev/null from within the chroot)
<dholbach> mvo: wasnt that always the default behaviour?
<Lathiat> sivang: like i said earlier (altho kamion seems to think its a bad idea)
<Kamion> dholbach: http://people.ubuntu.com/~cjwatson/installer-po/ in theory except that it seems to be missing partman-auto for some reason
<Kamion> dholbach: anyway it's partman-auto not partman
<ogra> ah
<mvo> ogra, dholbach: ok, thanks
<dholbach> Kamion: super... will send you the update
<Kamion> dholbach: thanks
<sivang> Lathiat: well, I mounted /proc and /dev inside the chroot, and now it works well, but it seems to not find and list all of the targets it used to have
<bddebian> Howdy
<sivang> hey bddebian :)
<bddebian> Heya sivang
<sivang> anyway, /me is going to reboot to test if grub restore succeded.
<dholbach> i386 install: "computer view" shows diskette - though i don't have a drive in the box :)
<dholbach> but that's because of the fstab entry
<dholbach> removing it, makes it disappear instantly
<seb_lx86> liveCD x86 rocking too
<pitti_live> Kamion: ok, amd64/live success, too
<pitti_live> mdz: for the record, amd64+powerpc live+install 4/4 success
<BenC> need ppc64 tested (live only)?
* sivang is back
<Kamion> BenC: certainly wouldn't hurt, I don't think anyone else has
<seb_lx86> mdz, and here liveCD on x86 and amd64 rocking too
<BenC> what's the image URL?
<Kamion> BenC: http://cdimage.ubuntu.com/daily/current/breezy-live-powerpc.iso
<Kamion> sorry, s/daily/daily-live/
<Kamion> BenC: http://cdimage.ubuntu.com/daily-live/current/breezy-live-powerpc.iso
<pitti_live> seb_lx86: indeed: /proc/mounts says "/dev/cdroms/cdrom0 /cdrom iso9660 ro 0 0"
* sivang is going for reinstall this time without LVM.
<lamont> and, while nearly everyone cares not at all, ia64 remains broken, all isos. :-(
<seb_lx86> mvo, this "OK" button not closing the language-selector dialog suck :/
<BenC> take about 30 minutes to download, so I'll let you know in about na hour
* lamont must make time to fix that kernel bug
<pitti_live> seb_lx86: so this is not actually a bug in gvfs, it precisely shows what is mounted
<sivang> lamont: folks over here say it's a deprecated arch :)
<pitti_live> seb_lx86: it's just very unlucky for the live cd
<seb_lx86> pitti_live, why doesn't mount list it?
<lamont> sivang: depends on who you talk to - that arch is paying my bills right now
<pitti_live> seb_lx86: this is mounted before chrooting, so /etc/mtab is not yet writtten
<Kamion> seb_lx86: mount uses /etc/mtab by default
<seb_lx86> k
<sivang> lamont: ah :-) 
<seb_lx86> pitti_live, and hal doesn't notice it neither, so we don't get the correct name
* lamont is hoping to get the kernel working in time for breezy, but dunno
<lamont> there are, admittedly, a few things ahead of that on the prioritized list...
<pitti_live> seb_lx86: hal is not designed to show all mounted thingies, just drives and their volumes
<seb_lx86> pitti_live, hum, maybe gnomevfs should do the same?
<pitti_live> seb_lx86: mounted image files don't belong to any bus and don't appear in sysfs, so hal does not recognize it
<pitti_live> seb_lx86: not sure, I think it is a good thing for gvfs to display mounted images
<Kamion> lamont: ahead of the *kernel*? :)
<seb_lx86> k, so let's say it's NOTABUG
<pitti_live> seb_lx86: jdub wants pmount support for fs images, then this becomes really handy
<seb_lx86> still a bit ugly, but whatever
<pitti_live> seb_lx86: we could discuss special-casing this in gvfs, but I don't think that it is worth the trouble
<seb_lx86> me neither
<sivang> oh bed not time to test now...:-(
<sivang> s/bed/bad/
<sivang> Kamion: until when it is still relevant to do tests?
<Kamion> sivang: dunno yet
<sivang> (have something in the office now..)
<Kamion> depends when mdz gets up ;)
<sivang> Kamion: I see, well, I will be able to test that "RC" again late today (around 10UTC) this time on a dell 8200...
* sivang --> out , cheers all
<bddebian> Later sivang
<Amaranth> yay, stupid bookstore finally got my math book in
<bddebian> yeah
<dholbach> apart from the diskette item and the gnome docs i386 install fine
<dholbach> ... is ...
<lamont> Kamion: management assigned tasks...  They're um, kinda ahead of ubuntu in general, despite evidence to the contrary...
<Kamion> lamont: ah, heh
<lamont> Kamion: rather, the kernel debugging is more time than I can get away with committing atm.
<lamont> but I hope to have things caught up this week/early next to the point that I can burn a day or 3
* lamont grumbles each time his rsync of breezy-install-i386 drops down from 500kB/s+ to 200kB/s
<mvo> Kamion: i386 install is working fine here
<dholbach> ebrb
<Keybuk> ok, my desktop should work better-than-ever now
<Keybuk> I've put it back together with the _right_ sized screws
<Kamion> Keybuk: clearly now you need to benchmark it with glxscrews!
<Keybuk> heh, you know I'm going to be filing a "DRI doesn't work on my super-l33t gfx card" bug anyway ... and I'm going to deliberately include glxgears info to amuse daniels
<bddebian> hehe
<hunger> Keybuk: the new glxgears suck... I have to use strings on it each time I use it to figure out what that stupid option to get the fps is called again.
<mjg59> hunger: Why do you want to know the fps?
<hunger> glxgears is the one and only GL test for me;-)
<Lathiat> hunger: heh what is the option
<mjg59> Hmm?
<hunger> mjg59: Because I do not see a difference between 40 fps (no accel) and 1500 fps.
<mjg59> if glxinfo says you have direct rendering, and if glxgears runs without errors, then you have accelerated 3D
<Lathiat> -info ?
<hunger> Lathiat: -iknowthisisnotabenchmarkireallydo or something simillar... string glxgears | grep ^-
* Lathiat has had cases oh
<Lathiat> i see
<Lathiat> haha
<Lathiat> -iacknowledgethatthistoolisnotabenchmark
<Lathiat> i wonder if thats a daniels patch :)
<mjg59> Lathiat: Yeah
<hunger> mjg59: Right... but if glxgears runs fast then I have DRI running... and it does look way nicer than the output of glxinfo.
<ogra> pretty sure :)
<Kamion> ogra: are you going to attempt to release Edubuntu with the Ubuntu/Kubuntu previews?
<Kamion> i.e. do I need to kick off an updated CD build now?
<ogra> Kamion, i'm not ready with the udeb yet
<Kamion> ok, has the delay been signed off?
<ogra> Kamion, and i'm waitin for a ltsp fix... mdz surely was to busy :
<Kamion> (metaphorically speaking)
<hunger> mjg59: Besides: glxgears is the only GL app I ever run... so benchmarking using it is fine for me;-)
<ogra> Kamion, who would sign that off ?
<Kamion> ogra: mdz or JaneW, presumably
<ogra> Kamion, with JaneW its clear that we delay one or two days...
<Kamion> all right
<Kamion> Riddell: new kubuntu daily-live up, with the right set of language packs this time
<Keybuk> mjg59: glxinfo says I have direct rending, and glxgears runs without errors
<Keybuk> oh, and I get 350fps
<Keybuk> maybe this card finally got an accelerated bit and I never noticed <g>
<Keybuk> Kamion: how does one rsync these images?
<wasabi_> 350fps is pretty slow for glxgears isn't it?
<HiddenWolf> wasabi_, yes it is
<wasabi_> Mine hits 8000+ fps I think.
<Kamion> Keybuk: rsync from cdimage.ubuntu.com::cdimage/daily/current/ etc.
<Keybuk> Kamion: right, google beat you :p
<Keybuk> well rsync://.... but yeah
<Keybuk> (I think that means the same thing)
<Kamion> yeah, it does
<Kamion> careful not to overload the server, there's an rsync limit in place there
<Keybuk> I'm not Tollef
<Keybuk> I can't take down random hosts just by downloading things :p
<ogra> lol
<pitti> fabbione: here?
<HiddenWolf> Does ian jackson irc?
<pitti> HiddenWolf: Diziet 
<HiddenWolf> Diziet: I've upped some info you requested to bug 14729, I have the same problem, altho with lan rather than wlan. let me know if I can help, ok?
<HiddenWolf> pitti, thanks, and ubuntu not mounting my cd's was due to having disabled the checkbox on 'mount removable devices' so i'll save you that one.
<pitti> HiddenWolf: hah, cool :-)
<HiddenWolf> pitti, I had a period when I had a lot of $otherOS gamecds in my dvddrives, must've deselected it to unclutter the desktop. ;)
<bddebian> damn I need my uploads rights if for no other reason that to fix my own stupidity... :-(
<bddebian> Whoops, sorry, wrong channel
<HiddenWolf> bddebian, if you're stupid, that'd be genetic, and unfixable, right? ;)
<bddebian> HiddenWolf: Well it kind of is ;-)
<HiddenWolf> bddebian, use "dumb behavior" instead. ;)
* Diziet fixes a segfault in mozilla.  Woohoo.
<Diziet> Well, firefox.
<bddebian> HiddenWolf: 
<Lathiat> nice
<Lathiat> which one?
<bddebian> uhh
<Kamion> mdz: I have to go out for a bit; I'll be back within the hour. My tests are at 5.5/6 (powerpc/install is still running).
<pitti> Diziet: please wait before you upload
<Diziet> 10257.  Textarea segfault.
<HiddenWolf> bb?
<Diziet> Sure, I wasn't going to just upload it.
<HiddenWolf> bddebian, ?
<Lathiat> Diziet: oh nice
<pitti> Diziet: fixing> yay :-)
<pitti> Diziet: if you upload a new version anyway, could you please add an empty package "mozilla-firefox" that just depends on "firefox"?
<bddebian> HiddenWolf: I forgot.. :-) 
<pitti> Diziet: we have so many complaints about m-f not being upgraded to ffox 
<Diziet> pitti: OK.
<pitti> Diziet: #14917, btw
<pitti> desrt: bah, I have to apply your battery voltage normalization patch manually...
<Diziet> pitti: Ah, thanks.
<Diziet> keybuk: Is there a bugzilla bug for us not yet using the new multi-patch-capable source format ?
<Keybuk> there's no -b equivalent for it yet
<Diziet> Yes, yes :-).  I just want to make another bug depend on it.
<Keybuk> there isn't a bug for that, no
<Diziet> OK, well I won't insist on filing one.
<pitti> a pity, because unpacking already seems to work fine :-/
<pitti> I tried it with a hand-crafted .dsc
<hughsie> desrt: I still didn;t get your HAL patch - did you get any reponse (i.e. did your mail client truck up, or mine?)
<drobbins> hiya
<drobbins> sabdfl is mark shuttleworth, right?
<Keybuk> right
<drobbins> ok :)
<Keybuk> or his evil twin brother
<lifeless> or sister
<jbailey> Didn't he cut his hair?
<elmo> no, he's still a long haired hippie
* mvo is away for a bit to play hockey
<dholbach> mvo: have fun
<dholbach> :)
<dholbach> he calls it playing hockey... i saw his hockey racket - all the other guys must be in hospital or something...
<pitti> dholbach: .. or good armory
<dholbach> i doubt it ... they must have little splinters everywhere and are heavily beaten up... stuff you wouldn't expect from mvo
<dholbach> ;-p
<Lathiat> hehe
<pitti> CAN WE UPLOAD YET?
<pitti> :-)
* pitti is eager to break the world with a new crackish hal
<mdz> *pawn* morning
<pitti> Hi mdz 
<mdz> er *yawn*
<pitti> hehe - we figured :-)
<mdz> Kamion: what's the story?
<pitti> it looks fairly well
<pitti> <Kamion> mdz: I have to go out for a bit; I'll be back within the hour. My tests are at 5.5/6 (powerpc/install is still running).
<mdz> ok, I'll do a test cycle here
<pitti> mdz: I tested amd64 and powerpc (live and install), Kamion, too, we also have successful i386 reports
<pitti> no reported failures so far
<elmo> we tested all 3 arches here
<pitti> mdz: powerpc really rocks now
<elmo> amd64 failed, but that's the specific laptop
<pitti> mdz: on powerpc there is no "press enter" message after CD ejection, and pressing enter does nothing
<pitti> mdz: but after half a minute or so the computer reboots anyway, and rebooting maually is fine, too
<mdz> pitti: hmm, that worked for me
<pitti> that is the only thing I noticed
<pitti> certainly not a showstopper
<pitti> and some broken translations in the installer, but Kamion knows the reason and will fix it for final
<seb128> mdz: liveCD on amd64 and x86 work great here
<mdz> seb128: thanks
<mdz> pitti: what else was changed since I went to sleep?
<mdz> Riddell: how does kubuntu look?
<Diziet> Ghods, doing anything with mozilla takes an age because it's so huuuge.
<Riddell> mdz: currently installing on both ibook and 386, 
<Keybuk> breezy-install still has Debian stuff in pics/
<Keybuk> is that deliberate?
<pitti> mdz: a workaround for the hfs kernel bug, usplash fix, daniels uploaded one or two new xorgs to fix some option setting
<mdz> pitti: ha ha ha
<pitti> mdz: however, I might not remember exactly any more, I'm terribly tired
<pitti> mdz: ?
<mdz> oh  no you were serious about xorg?
<mdz> wtf?
<pitti> yes
<pitti> mdz: -60 at least, not sure whether you still saw infinity's resolution fix in -59
<mdz> I saw -59
<pitti> xorg (6.8.2-60) breezy; urgency=low
<pitti>   * Set module list to be separated by commas and spaces, not just commas, in
<pitti>     xserver-xorg.config.in.  Thanks to Colin Watson and Sbastien Bacher.
<mdz> and I see -60
<mdz> what was the bug exactly?
<pitti> however, no idea what that was good for - seb128?
<Keybuk> holy multitude of partitioning options, partman!
* Keybuk wonders what the lightning bolt, white face and dark face all mean
<Treenaks> Keybuk: and the skull/crossbones
<Keybuk> I didn't get a skull/crossbones
<Treenaks> Keybuk: it's there if you already have swap, for example
<Treenaks> maybe it's what you call the dark face
<seb128> mdz, pitti: bug was xorg.conf without any "Module" listed, which made window black painted on switch with alt-tab
<mdz> seb128: ok, daniel had thought that was an older bug which was fixed
<Keybuk> no, that's just a  (as apposed to the  above it)
<seb128> mdz: yeah, he started by blaming GTK :)
<pitti> seb128: sacrilege!!
<ivoks> ;...(
<seb128> pitti: :)
<Keybuk> I had a dream last night, daniels had died of a drug overdose and couldn't make it to the conference
<HiddenWolf> Keybuk, *shock* 
<sbartleylinux>  Looking for information on creating an Ubuntu based light distribution using xorg, xfce, firefox, thunderbird and our own application sets.  Any recommendations on where to start looking?
<HiddenWolf> sbartleylinux, check out ubuntulite.org
<sbartleylinux> thx
<Keybuk> hmm, who does "grub"
* Keybuk has a suggestion ... can we add "Breezy Badger" to the kernel descriptions?
* bddebian hopes Keybuk never dreams about him
<jbailey> Keybuk: Do you want it to magically autodetect which ones came from breezy, hoary and warty?
* netjoined: irc.freenode.net -> kornbluth.freenode.net
<mdz> argh, anacron is running on the powerpc live CD for me
<mdz> did anyone else notice it was incredibly slow?
<Kamion> mdz: as well as what pitti mentioned, a casper workaround for the xscreensaver lock thing
<Kamion> live CDs are always incredibly slow for me :P
<mdz> I don't see how it started; there are no init links for it
<Kamion> I didn't notice slow vs. slower
<mdz> but it's running cron.daily
<mdz> it's always slowest for me on powerpc, but this is a drastic difference with updatedb running :-P
<Kamion> mdz: aside from what you just mentioned, as far as I'm concerned it's now ready
<mdz> casper deletes /etc/rc?.d/S??anacron
<mdz> has for ages
<mdz> anyone know how else it could have been run?
<Keybuk> jbailey: it could read /etc/lsb-release no?  ... is just amusing having to guess by kernel release
<Kamion> mdz: had to respin kubuntu live because the live rootfs was being built with ubuntu-live instead of kubuntu-live; that's fixed now
<mdz> this happened to me earlier (slower than normal) but I didn't investigate
<Keybuk> mdz: /etc/cron.daily
<mdz> it didn't happen on anything but powerpc
<Keybuk> anacron is just a one-shot app, rather than a daemon
<mdz> Keybuk: anacron is what runs cron.daily
<ogra> Kamion, i just was told there is no delay for edubuntu apparently
<jbailey> Keybuk: Sure, but then your 2.6.8 from Warty will say 'breezy badger'.  Is that fine>
<Kamion> Keybuk: update-grub rewrites menu.lst every time, so no, it couldn't just check /etc/lsb-release, because that would mean the warty kernel would show up as breezy
<mdz> Keybuk: it's a daemon
<Keybuk> jbailey: well, it'd be booting into breezy no?
<Keybuk> mdz: so isn't
<jbailey> Keybuk: Nothing that we'd support as 'breezy' if you filed a bug. ;)
<Keybuk> isn'tisn'tisn'tisn'tisn't :p
<mdz> hell
<ogra> Kamion, so please kick off the builds if the time is up :(
<Keybuk> the init script runs anacron if it's been a while since it was last run
<Keybuk> and cron.daily makes sure it's run every day
<mdz> cron.daily still shouldn't be running at 11:18 EDT
<Kamion> ogra: sheesh; ok, running
<mdz> anyway, casper just needs to cripple cron too
<Kamion> this is why I asked earlier so that we wouldn't have to rush now
<Kamion> mdz: preview blocker or not?
<ogra> Kamion, there is no ruch at all... 
<ogra> rush even
* Kamion wants to know whether he stands a chance of nipping off to the pub for an hour this evening ;)
<mdz> Kamion: not
<Keybuk> hmm, xorg didn't detect useful resolutions for me :-/
<Kamion> (mind you I may not anyway, child being here and all that)
<mdz> Keybuk: this is the first time you've tested X?  grr....
<Keybuk> mdz: on the desktop yeah, it's worked on the laptop ok
<Keybuk> are we supposed to always see the "pick your resolutions" screen during install?
<HiddenWolf> Keybuk, shouldn't be.
<Kamion> Keybuk: depends on whether xresprobe can detect it
<Kamion> if not, you'll see that
<Keybuk> ok, I'll file a bug
<Kamion> what arch?
<Keybuk> I did suspect it wouldn't like this card
<Keybuk> i386, ATI *mumble*
<Kamion> ok
<mdz> Kamion: whose child is it?
<mdz> Keybuk: you should only see that if we were unable to do the smart thing
<Keybuk> *nods*
<mdz> i386 + ati in general is well supported for autodetection
<Kamion> mdz: my wife's
<mdz> unless you have a KVM or a crap monitor
<Keybuk> this is a "cheapest card I could buy at PC World"
<Keybuk> so it's probably far too advanced for daniels <g>
<mdz> Kamion: oh :-)
<Kamion> he lives here 50% of the time or so
<Keybuk> "xresprobe ati" just says "id:\nres:\nfreq:\ndisptype:\n"
<mdz> Kamion: where can I merge your casper change from?
<mdz> Keybuk: xresprobe probably isn't even run; we should be able to probe DDC on a desktop
<Kamion> mdz: nowhere, because I couldn't figure out where to branch from (you didn't seem to have committed 1.13 anywhere I could see)
<mdz> Kamion: ah, my mirror is behind
<mdz> Kamion: could you send a patch?
<Keybuk> mdz: any quick&easy way to debug that?
<Kamion> mdz: ok, I'll do that once my development system is finished doing a test install
<mdz> Keybuk: DEBUG_XORG_DEBCONF=yes dpkg-reconfigure -phigh xserver-xorg
<mdz> Keybuk: or if you booted the live cd
<mdz>  Keybuk /var/log/casper/post.log 
<mdz> amd64 in stage 2, powerpc in stage 1 here
<mdz> amd64 live and powerpc live successful
<Keybuk> mdz: which bit of the output am I looking for?  can't see anything about resolutions in it
<mdz> I wonder if using -novtswitch in xresprobe would prevent the screen blanking
<mdz> Keybuk: attach it to the bug report
<mdz> has anyone looked into why the hotplug init script is missing its "ok"?
<Keybuk> it's never had one, has it?
<Keybuk> it always used to output a series of following lines which we turne doff
<mdz> seb128: still seeing the evolution icon on i386, how strange
<mdz> seb128: maybe it has to do with the fact that it's a lapttop, so gnome-panel-data gets reconfigured?
<mdz> Keybuk: it used to
<pitti> mdz: anacron> never noticed it, I usually accounted my weak CPU and small memory for the slowliness...
<Kamion> mdz: OK, I'm 6/6 at last
<Keybuk> on hoary is just does
<Keybuk> * Starting hotplug subsystem:
<Keybuk>   pci.agent             [ok] 
<Keybuk>   net.agent             [ok] 
<Keybuk> etc.
<mdz> Kamion: 4/6 here
<pitti> mdz: 2 failed or untested?
<mdz> Keybuk: that changed since hoary
<mdz> several times
<Kamion> usplash fine on powerpc both install and live
<mdz> pitti: 2 pending
<mdz> Kamion: likewise
<pitti> *phew*
<Riddell> mdz: kubuntu {i386,powerpc}{live,install} all tested and looking good
<Keybuk> #14974 for the X resolution bug
<Kamion> Riddell: yay
<mdz> Mithrandir: can you assist Riddell with kubuntu/amd64?
<pitti> I can check the live CD
<mdz> ok
<mdz> install needs testing, too, though
<Kamion> I can start downloading kubuntu/amd64/install but it'll be at least two hours before I have a result
<Kamion> I have not been keeping up with kubuntu CDs due to disk space juggling reasons
<mdz> I think I have a recent rsync; I'll see if I can do it
<mdz> has to wai tuntil my i386 install is finished in order to use the drive though
<Kamion> I wonder if rsyncing against an Ubuntu CD would be worthwhile
<pitti> 446.16K/s    ETA 23:45
<mdz> probably
<pitti> Kamion: hm, good idea
<Riddell> the live CDs have a disconcerting message on boot saying "Bummer, could not run /sbin/debian-installer"
<pitti> same for ubuntu
<pitti> but just cosmetics
<Kamion> Riddell: known, fallout from the VT switch bugfixes (it's always been there, we just only started noticing it recently)
<Riddell> ok
<Kamion> but yeah, it's ugly
<Kamion> I'm thinking maybe we can put symlinks to /bin/sleep or something in place of that and the other command it complains about, just to shut init up until it's killed
<pitti> Diziet: do we have a new firefox maintainer then? :-)
* Lathiat laughs
<Kamion> mdz: so should I stick these in releases.ubuntu.com/.pool/ so that mirrors have a chance to pick them up?
* Keybuk wonders whether breezy will detect his printer
<Keybuk> nope, still needs a cupsys restart *sigh*
<mdz> Kamion: yes, please
<mdz> Kamion: do we have any push capability?
<Kamion> elmo: ?
<Kamion> maswan: are you around?
<Riddell> pbbuttonsd went crazy on one of the ibooks I tried, any recommended way to get info for a bug report on that?
<Lathiat> Keybuk: yeh ive noticed that with my usb printer
<Lathiat> Keybuk: seems silly.
<elmo> Kamion: ?
<Keybuk> Lathiat: *nods* it only detects usb printers at start, and doesn't listen out for new ones
<pitti> Riddell: yes, I think so, wait...
<Kamion> elmo: are there any releases.ubuntu.com mirrors we can trigger?
<Lathiat> so we write a hal callout to restart cupsys on usb printer detection?
* Lathiat grins
<elmo> Kamion: triggering syowa triggers us + se
<elmo> and se are part of relases.u.c proper
<Kamion> good stuff
<pitti> Riddell: #13909
<Kamion> maswan: never mind :-)
<Kamion> mdz: please don't sync-mirrors for a bit until I have this put together
<Keybuk> Lathiat: HALifying cupsys would be hella-sweet
<mdz> elmo: so in the release announcement, I  should be able to list '', us. and se.?
<pitti> Keybuk: guess what? a while ago I sent seb128 a patched package that at least dbus'ifies it :-)
<dholbach> good bye
<pitti> bye dholbach 
<seb128> pitti: I pointed the patch to start :p
<elmo> mdz: yeah
<pitti> seb128: right, sorry
<Keybuk> this CD Writing thing is fun
<Keybuk> I might actually back up lots of things to CD and store them and stuff
<pitti> I keep wondering why some CDs are burned in 10 minutes and some in 20...
<Keybuk> mine seem to be taking about 3 minutes
<mdz> powerpc install  successful
<pitti> \o/
<mdz> pitti: some of my DVD+RWs are slower than others
<mdz> at a guess it seems to be ones I have used to burn larger images and then later smaller ones
<Kamion> Daily for breezy amd64 on 20050908.7 is oversized! Continue? [yN] 
<pitti> mdz: that might be the reason, I use the same CD-RWs for over a year now (the "Ubuntu test R/Ws")
<Kamion> (yay cdimage)
<Keybuk> really silly bug
<Keybuk> why doesn't "Blank CD-R Disc" turn into "Ubuntu 5.10 Live" when you finish writing it? :;
<phlaegel> seb128: I think I've found a fairly strange nautilus bug. Do you want to hear about it or should I take it upstream?
<seb128> phlaegel: feel free to describe it
<mdz> seb128: the menu masking stuff for non-admin users landed, right?
<mdz> i386 install success
<mdz> 6/6
<HiddenWolf> mdz, you're making speed, are you? ;)
<phlaegel> seb128: here goes: some open folders will disappear after being open for an hour or so. If the parent folder is also open, the subfolder won't be shown in it at all until a refresh.
<mdz> HiddenWolf: I do them in parallel
<seb128> mdz: gnome-menus is patched for it but we have not update desktop files according to that
<mdz> seb128: so the functionality is not there
<elmo> has anyone seen the evolution icon in the panel being broken by upgrades?
<elmo> it still points at evo-2.2 after hoary -> breezy
<seb128> mdz: it's here but we don't use it, no. Was a bit short with the freeze and there was some other stuff to push too
<ivoks> elmo: yes
<elmo> ivoks: know if there's bug about it?
<ivoks> elmo: no :( but i can confirm it
<Keybuk> Kamion: .18: Can't open S72menu-exit
<seb128> elmo: I hate this bug, basically novell guys change the versionning on every update and the panel config is an user setting so it can get updated on upgrade
<Kamion> Keybuk: same as Riddell's /sbin/debian-installer mention above; will probably be fixed in the same way
<bddebian> elmo!!
<elmo> seb128: it's evil but couldn't we have a evo-2.2 -> evo-2.4 symlink? :)
<ivoks> :))
<sabdfl> seb128: what happened with Terminal?
<Keybuk> live seems faster than I remember
<Keybuk> like a _lot_ faster
<Kamion> mdz: ok, stuff's on its way out to releases.u.c mirrors now in .pool
<seb128> sabdfl: the icon change?
<seb128> sabdfl: just looking at it. I've made the change and apparently dholbach based his 2.12 upload on the previous version and dropped it 
<pitti> kubuntu amd64/live burning
<maswan> lets see if you guys or the gnome 2.12 livecds will win the bandwidth usage contest. ;)
<lu|away> haha
<lu|away> that's a real OS, that's not fair
<seb128> s/icon/menu category/
<desrt> hughsie; it's stuck in the list.  david needs to release it
<desrt> hughsie; it's on the ubuntu bugzilla though
<maswan> lu|away: but it's only a pre-release? :)
<desrt> pitti; i was going to do it myself but then i got lazy :)
<pitti> desrt: no worries, see the bug followup; I already did it, pending upload
<desrt> oh
<desrt> rocking
<mdz> Kamion: writing the announcement
<crimsun> mjg59: pong
<desrt> hughsie; the patch on the ubuntu bugzilla is actually against HEAD
<Kamion> elmo: should torrents work automatically now, then? should I poke you anyway to check?
<desrt> hughsie; so even though it didn't work for martin it should work for you :)
<Keybuk> *giggle*
<Keybuk> I just stuck a warty CD in, and it asked me whether it wanted me to upgrade from it
<Lathiat> heh
<bddebian> Keybuk: heh
<sabdfl> Keybuk: you need "I BREAK SOFTWARE!" on your business card
<hughsie> desrt: sorry, just got back from dinner
<hughsie> desrt: i would join, and resend it
<hughsie> i've lost stuff on hal-devel before
<desrt> hughsie; pfah.
<desrt> where is david?
<desrt> he's been AWOL since last weekend
<hughsie> desrt: don;t know. he;s not been on irc for *ages*
<desrt> i want him to comment on my application to be added to the 'hal' group on fd.o :p
* pitti tests kubuntu amd64 live now
<Riddell> pitti: good luck
<Kamion> since we have matching source CDs and now have the scriptage to publish them sanely, I'm putting those on releases.ubuntu.com too (but not anywhere they'll visibly get in the way, don't worry)
<Kamion> just 'cos otherwise I have to keep backups of them in my home directory and stuff and risk losing them
<hughsie> desrt: i don;t see why not. +1 from me
<pitti> Riddell: f***, it did not even boot... I try another CD...
<desrt> hughsie; well, currently the official reason "why not" is because david is AWOL :)
<hughsie> desrt: :-)
<desrt> hughsie; but since, ultimately, he's the one reviewing patches, there's no problem with waiting until he gets back :)
<hughsie> desrt: yes, agreed
<Kamion> speedup 3.56 from rsyncing Kubuntu amd64/install against Ubuntu amd64/install
<Lathiat> Kamion: nice
<Kamion> /dev/sda3            562456664 372170536 161714960  70% /
<Kamion> I must get round to cleaning up little
<Kamion> although it's particularly loaded at the moment because the purge scripts base their decisions on how old images are rather than on how many builds there've been, and we've built something like fifteen rounds of Ubuntu CDs today (counting both install and live)
<Kamion> yeah, >70GB in daily and daily-live alone
<Surak> hello, I just managed to build the module for conexant modems with ubuntu. They have a closed-source part, which is distributed with the modem in form of 2.4 linux driver. I would like some advice about how to package this for ubuntu.
<CarlFK> Surak - try in #ubuntu-motu
<pitti> ok, kubuntu live test, take 2...
<pitti> hrm, no luck
<pitti> Kamion, Riddell: the Kubuntu amd64 live plainly refuses to boot on my box
<pitti> I know I'm not supposed to do KDE development, but hey, a short peek at the competition can't hurt
<Kamion> pitti: it's an oversized image; perhaps you have a 650MB CD, or a drive that can't do 700MB?
<pitti> Kamion: certainly not, 700 MB works well here
<pitti> I burned 720 MB images here...
<Kamion> that's the only reason I can think of ...
<pitti> hm
<pitti> I dd the image and check md5
<seb128> pitti: I hate you now :p
<Kamion> Kubuntu amd64/install boots fine anyway, let's see how it goes
<pitti> seb128, please, please, I promise, I will never do it again!!
<Riddell> pitti: thanks anyway
<Riddell> seb128: you're lucky it didn't boot for him, else he's see the wonder of KDE and never want to leave
<seb128> pitti: ok ok, but be careful, I'm watching you :p
<seb128> haha 
<pitti> breezy-live-amd64.iso           08-Sep-2005 17:43  624M
<pitti> Kamion: it's not even close to oversize...
<Kamion> pitti: oh, sorry, I was thinking of the i386/powerpc ones
<Kamion> you're quite right
<pitti> anyway, checking md5....
<jbailey> slomo: Around?
<slomo> jbailey: yes
<jbailey> slomo: What do you mean the kernel detects the harddrisk some seconds earlier?
<Keybuk> wow, warty feels so retro
<pitti> "warty"?
<slomo> jbailey: something like "hda: ST3160023A, ATA DISK drive"  (but this is on my desktop now)
<jbailey> slomo: Can you add the word 'break' to the kernel command line, please?
<slomo> jbailey: sure... what does it do?
<mdz> breaks your computer
<jbailey> It should drop you to a shell prompt/  If your harddrive is being detected then it's getting further than it was before.
<jbailey> mdz: Shhhh..  You're telling secrets!
<mdz> jbailey: do you have success reports for booting from USB hard disks now?
<mdz> that ought to just work now
<mdz> would be nice for the release notes
<pitti> darn, dd'ing /dev/cdrom does not quite produce exactly the same image
<slomo> jbailey: then we had some kind of misunderstanding... that was there since the beginning... ok, reboot with break now :)
<Keybuk> pitti: I'm trying a warty->breezy upgrade, to see what happens
<mdz> Keybuk: do you not have enough work to do? :-P
<slomo> jbailey: and break doesn't change anything
<Lathiat> hr
<Lathiat> m
<Lathiat> the arrows on the update notifier are buggering around again
<jbailey> mdz: No, sorry.  I'll poke the submitted of the bug I have against initrd-tools so that we can get it for release.
<pitti> Riddell: I'll burn the cd in my laptop now, last chance...
<pitti> darn, I burned like 20 CDs today without problem...
<jbailey> slomo: Hmm.  And you're sure you're using the stock kernels?  It shouldn't be able to detect your harddrive at this point.
<Keybuk> mdz: it was a very short-lived experiment <g>
<seb128> pitti: that's a sign you should stick with GNOME :)
<jbailey> What is our upgrade promise?  Are people expected to go through the releases in sequence if they're upgrading?
<slomo> jbailey: sure... i never compiled my own kernel on the ibook
* Keybuk wanted to know: "Can you upgrade a warty machine to breezy?"  The answer: No.
<pitti> seb128: yeah, my computer does not seem to be KDE compatible
<pitti> seb128: I don't even know how kubuntu looks like...
<ogra> pitti, you could test edubuntu to check if a smaller potion of KDE works :)
<pitti> ENOBANDWIDTH
<pitti> I already used up mine and my flatmate's weekly quota
<Keybuk> jbailey: it's certainly not possible to do anything but at the moment
<Keybuk> the modularised Xorg packages can only be upgraded from the monolithic Xorg packages by the looks of it
<Keybuk> they only declare relationships on xorg-* and not xfree86-* as well
<Keybuk> e.g. xinit should replace xfree86-common _as_well_as_ xorg-common
<jbailey> Keybuk: Right, and it might be nice to clearly say that.
<jbailey> Keybuk: As well as figure eventually what that means for people jumping from long-lived-release to long-lived-release.
<Keybuk> mdz: should we add that to the rlease notes?
<mdz> Keybuk: "that"?
<Keybuk> mdz: you can't upgrade a warty machine to breezy preview
<Keybuk> you must first upgrade to hoary
<seb128> pitti: probably crappy, it's KDE :p
<mdz> Keybuk: I don't think it's necessary
<mdz> you can't upgrade from woody either
<Keybuk> or sarge
<Keybuk> annoyingly
<mdz> in fact, since we haven't worked out the upgrade issues yet, I don't think we should put upgrade instructions in the announcement
<mdz> sabdfl: any objection to removing that bit?
<pitti> Keybuk: maybe we can fix breezy final to be upgradable from warty?
<mdz> pitti: I think that time could be better spent fixing upgrades from hoary and sarge, and other bugs
<Keybuk> fixing upgrades from sarge would implicitly fix from warty
<Keybuk> as it's the same problem
<pitti> well, yes
<jbailey> Sure, but we need to know what the upgrade-from targets are for testing anyway.
<mdz> Keybuk: only one problem?  your test must have been thorough :-P
<pitti> the other day sb told me we would support upgrades from any to any currently supported release
<Keybuk> mdz: well, two dozen instances of the same problem
<Keybuk> force-overwriting the appropriate packages seemed to get me a breezy machine
<mdz> pitti: sb = mark?
<pitti> no, but some canonical employee 
* pitti tries to remember
<mdz> pitti: it wasn't me
<pitti> well, anyway
<pitti> if we don't, so much the better - or easier - for us
* jbailey wonders how 'sb' maps to 'some canonical employee'
<mdz> I don't think it makes sense
<Keybuk> we probably /should/ support upgrades between supported releases, to be fair
<Keybuk> jbailey: some body, I guess
<ogra> jbailey, somebody
<jbailey> Ah. =)
<shackan> ah, someday I hope to have rhythbox not crashing for at least six hours in a row...
<jbailey> I don't think it's harmful to say dist-upgrde through each release for the short-lived ones, and support long-lived to long-lived on top of it.
<Kamion> mdz: so, can I publish these images properly now?
<mdz> Kamion: yes
<tseng> jbailey: is there a specific plan for long-lived releases?
<pitti> ok you bloody KDE live CD: this is your third and last chance to boot on my box before I give up
<tseng> jbailey: or it will just be a regular release with more security time
<jbailey> tseng: I am not the keeper of the crystal ball on that one. ;)
<Kamion> mdz: hooray
<Riddell> Kamion: did you try amd64 kubuntu install?
<Kamion> Riddell: it's at 63% second stage
<Kamion> mdz: oh, and am I publishing kubuntu at the same time or later?
<mdz> Kamion: depends on whether it's ready to be blessed
<Kamion> I'll know that before Ubuntu publishing finishes ...
<Kamion> well, assuming we take amd64/live on faith
<Riddell> pitti: any luck?
<shackan> hi pitti, why back so early ? :)
<pitti> Kamion, Riddell: nope - three different CDs, two different burners, correct downloaded images - this thing just doesn't boot
<shackan> maybe you inserted the cd upside-down..
<seb128> :)
<pitti> it must have an internal Gnome developer boot protection
* pitti whines about the 650 MB of wasted bandwith
<seb128>  /msg pitti nice GNOME promoting job, I own you a beer :)
<seb128> (ups :p)
<shackan> pitti, I've got more than that to whine about
<pitti>  /msg seb128 and nobody noticed my syslinux upload that did this :-)
<Kamion> Kubuntu amd64/install success
<Riddell> Kamion: yay, thanks
<Riddell> anyone else able to test amd64 live kubuntu?
<Kamion> I'll try it, but subject to usual download time comments
<pitti> would be nice to verify/falsify my failure
<jbailey> Riddell: Sure, Angie's off her machine.
<jbailey> I don't think I sync kubuntu as part of my nightly rsync, though.
<ogra> anybody able to test edubuntu ?
<ogra> on ppc/amd64 ?
<Kamion> unfortunately I doubt it will sync against Ubuntu in the same way the install CD does
<Riddell> ogra: I'm 29% downloaded, 40 minutes to go
<ogra> Riddell, wow, thanks :)
<jbailey> Riddell: I don't.  kubuntu daily/current live from last night okay?
<ogra> Riddell, http://edubuntu.org/EdubuntuTesting follow these notes :)
<Riddell> ogra: that's i386, if you want me to test powerpc I can stop i386 download and start powerpc
<seb128> I can try it, but will take 3 hours to download
<ogra> Riddell, yes, that'd be better
<seb128> mvo: around?
<ogra> Riddell, x86 i just finishing the burn here
<ogra> s/i/is
<Riddell> jbailey: http://cdimage.ubuntu.com/kubuntu/daily-live/20050908.2/
<Riddell> or daily-live/current
<sabdfl> mdz: no problem on removing upgrade instructions
<jbailey> Mm, weird, I can't highlight text in nano.
<Riddell> why does cdimage.ubuntu.com not reject http connections from my IP address, it's most impolite
<Riddell> jbailey: shift-click?
<mdz> sabdfl: latest draft is https://wiki.ubuntu.com/DraftBreezyPreviewAnnouncement
<Riddell> I think nano is one of those spooky ncurses mouse programmes
<mdz> sabdfl: spell checked, just needs link checking and then ready to go
<mdz> Kamion: ETA for live links?
<sabdfl> mdz: can i tighten up the text flow a little?
<mdz> sabdfl: formatting or content?
<sabdfl> formatting
<mdz> sabdfl: certainly
<Kamion> Can't count up to 5!
<Kamion> best error message EVAH
<mdz> Kamion: nice1
<Kamion> mdz: couple of minutes
<mvo> seb128: yes, just came back
<seb128> mvo: what causes this 3s/1s delay for gksu?
<sabdfl> mdz: silbs and i have been reviewing desktop item menu placement
<jbailey> Riddell: Thanks.  I guess someone X enabled nano.
<seb128> mvo: is it waiting for something? Or that's a on purpose waiting?
<sabdfl> we need to introduce changes immediately post preview, to give the doc team time to catch up
<sabdfl> like the terminal
<mvo> seb128: kov is starting sudo to test if it requires to input a password
<sabdfl> it reverted
<mdz> sabdfl: we noticed a weirdness about the evolution icon on the panel
<bddebian> An X enabled nano?? Kick-ass
<seb128> mvo: and it takes 3s to sudo to say that?
<Keybuk> hmm
<mvo> seb128: it times out after ~3s, but with the cvs patch it's killed before (with kill)
<Keybuk> did anyone else notice that a lot of other people seem to be releasing betas/previews today too? :p
<sabdfl> yes, silbs caught that one
<Keybuk> SuSE beat us to 2.12 :p
<pitti> darn
<bddebian> Yeah but who uses SuSE? ;-)
<Kamion> ssh: connect to host frei.ubuntu.com port 22: No route to host
<Kamion> elmo: ^-- ?
<mdz> sabdfl: the deadline agreed with the doc team for UI changes was August 25th, FWIW
<sabdfl> in general, any old menu item that pointed to a version-specific place would be caught out if it had transferred to the panel
<Keybuk> so did Foresight (who are they?!)
<mdz> sabdfl: and the docs are supposed to be in string freeze now so that they can be translated
<seb128> mvo: what timeout? it that an ugly hack like "try a random password and wait to know what it gives"?
<tseng> Keybuk: they are based on rPath
<Burgundavia> sabdfl, our string freeze is today
<tseng> Keybuk: which is the autopackage distro
<tseng> Keybuk: cracksmoking abounds
<mdz> Keybuk: flattery is the sincerest form of admiration
<Keybuk> mdz: indeed
<Kamion> UK releases.u.c has the live links; the others are catching up
<Kamion> can somebody please test the torrents? I'm off to get some dinner
<mdz> er
<mdz> imitation
<mdz> is the sincerest form of flattery
<mdz> rather
<Kamion> this is Ubuntu only btw, not Kubuntu yet
<mvo> seb128: more like a empty password, but otherwise, yes. the problem is that sudo is _very_ unfriendly for frontends. it does not provide any usefull information (well, there is -l but that isn't enabled by default)
<mdz> Keybuk: where is this suse thing?  I see nothing on www.suse.com
<tseng> mdz: opensuse
<mdz> not that I can read it
<tseng> mdz: (.org)
<mvo> seb128: there are some other problems like "-p" does not work for e.g. kerberos or opie 
<mdz> dude, they are totally mimicking our releases
<tseng> of course they are
<silbs> mdz, sabdfl: the release announcement ignores large parts of the world (i.e., non-UK, US, Europe).Maybe include something like "download from the site closest to you"
<tseng> we are stealing their community
<mdz> silbs: I thought you went home!
<Kamion> silbs: ideally we'd update /download/ a bit and point to that, I just haven't had a chance yet
<Kamion> perhaps somebody else could update that
<tseng> mdz: the mono faceoff will be fierce!
<silbs> mdz:I did. But I didn't want to miss the excitement.
<sabdfl> mdz: formatting done
<mjg59> crimsun: Hi - was it you who ended up with the X41?
<Keybuk> mdz: planet suse
<sabdfl> silbs, mdz, should we have a "Rest of World" link that goes to http://releases.ubuntu.com/5.10/ ?
<mvo> seb128: do you have any idea about #14430? 
<mdz> seb128: didn't we decide to put add/remove programs at the bottom of Applications?
<Nafallo> wow!
<mdz> sabdfl: change "United Kingdom" to "Rest of World"?
<Nafallo> se.releases.u.c already have it ;-)
<sabdfl> mdz: UK guys will likely then goe with Europe
<sabdfl> so, i'll have an additional one
<mdz> sabdfl: the rest of the world should use the one closest to them
<sabdfl> silbs, mdz: I would like to move the "Getting" section to the top
<mdz> rather than UK always
<sabdfl> mdz: they will, anyway
<mdz> then why add a new section?
<Lathiat> mdz: see the gnome-menus changelog
<Lathiat> mdz: it was reverted
<Lathiat> mdz: as in some locales, it makes the menu stupidly wide
<Lathiat> mvo: my libnotify arrows are being silly again on both my machines
<seb128> mdz: mvo did and we rolled back, it was ugly and there was some technical issue to put a separator before it (not a big deal, but require some gnome-panel patching)
<mvo> Lathiat: can you send me a screenshot? 
<Lathiat> http://bur.st/~lathiat/libnotify.png
<mdz> sabdfl: finished editing?
<seb128> mvo: nop, not really 
<mvo> Lathiat: that's a interessting one, I haven't seen that one before
<sabdfl> mdz: yes
<Lathiat> mvo: ive seen that sort of thing the whole time..
<mdz> sabdfl: "extra work"?
<sabdfl> silbs, mdz, please ack you are ok with the shift
<mdz> sounds like a chore :-)
<sabdfl> "extra work"?
<mdz>   * X.org 6.8.2 with extra work for wider hardware support
<mdz> that isn't what I wrote
<sabdfl> ah, yes
<tseng> Lathiat: that drives me nuts
<Lathiat> tseng: mmhmm
<ivoks> Lathiat: that notify is here to like that :)
<Lathiat> mvo: sounds like you have a problem ;)
<sabdfl> mdz: fixed
<Lathiat> what the hell does it do
<Lathiat> to end up with that
<Lathiat> its like it draws its on border
<Lathiat> on top of gtk 
<Lathiat> *own
<silbs> sabdfl: "server,with" -> "server, with" (typo, space)
<silbs> sabdfl: "On The Desktop" -> "On the Desktop"
<mvo> Lathiat: can you join #notification-debug please? I don't want to distrub this channel too much :)
<Lathiat> mvo: ok
<silbs> sabdfl: I would reorder the features under installation. OEM and others are more impressive than a progress bar.
<mdz> sabdfl: should we point to the forums as well as the mailing list?
<hotte-> ^^
<ogra> Riddell, btw, i would suggest doing the workstation install, since i doubt you have amd64 thing clients around ;)
<mdz> silbs: I've already copy/pasted, spell checked and link checked
<mdz> silbs: but if you want to make more edits, go ahead, just somebody let me know when everyone is happy
<mdz> keyboard break
<silbs> sabdfl, mdz: that's all I see
<mdz> silbs: did you fix those?
<silbs> mdz: no, I thought someone else was editing. Happy to do so though - should I?
<ajmitch> no mention of malone for universe bugs, or you don't want to confuse users? :)
<bddebian> heh
<sabdfl> mdz: yes, please add forum link
<bddebian> Heya ajmitch
<ajmitch> hi
<BenC> anyone with the laptop folks here?
<mdz> Kamion: er, where are the torrents?
<mdz> silbs: please
<mdz> I need to be off of the keyboard for a while
<sabdfl> BenC: could you get our kernels integrated with KLive, please, post preview?
<Kamion> mdz: they're on the datacentre mirrors but not on the .se ones
<Kamion> dunno why
<Kamion> maswan: ?
<Kamion> maswan: I guess you're still syncing ...
<BenC> sabdfl: maybe if I knew what KLive was :)
<maswan> Kamion: .pool/ubuntu-5.10-preview-src-4.iso
<silbs> mdz: done. And I added a forums link (please double check). Don't know what the XXX is on the first line.
<Burgundavia> BenC, 
<Burgundavia> http://klive.cpushare.com/
<maswan> seems to average somewhere around 1MByte/s, +-500k/s
* Kamion pickily puts a trailing slash on the forums link
* sabdfl thanks the stars for guys like Kamion
<Kamion> heh
<sabdfl> seriously
<ogra> :)
<ogra> sabdfl++
<BenC> arch_commit: unable to acquire revision lock (internal error in archive-pfs.c(pfs_lock_revision))
<BenC> anyone know how to fix that?
<BenC> I killed mid commit because it was commiting files I didn't want to, and now I've got that
<Kamion> BenC: baz lock-revision -b <revision>
<Kamion> ?
<BenC> that's a baz commit error
<fabbione> BenC: it looks like wrong permissions on the archive
<fabbione> same as i was getting when you had the wrong umask
<Kamion> I usually find baz lock-revision -b ...whatever... clears that up
<BenC> wouldn't be from me
<fabbione> BenC: did you interrupt a commit?
<ogra> fabbione, yes
<BenC> yes
<BenC> lock-revision didn't help
<fabbione> BenC: ah ok.. that explains :).. use the command Kamion told you
<BenC> lock-revision: unkown lock state for kernel-team@ubuntu.com--2005/kernel-team@ubuntu.com--2005/kernel-debian--preX,13--2.6.12--patch-13
<BenC>    (lock was in transition -- consider retrying)
<fabbione> ok.. let me login and fix it for you
<fabbione> BenC: on which branch were you commiting?
<BenC> the commit can be tossed
<BenC> kernel-debian--preX,13--2.6.12
<Kamion> should just be mv ++revision-lock-held--* patch-12/++revision-lock
<Kamion> or patch-11/ if you're tossing patch-12
<Kamion> oh, no, you're tossing patch-13
<BenC> I think I fixed it
<BenC> nope
<Kamion> you need a +contents subdirectory of ++revision-lock
<fabbione> wait
<fabbione> i am working on it
<silbs> Kamion: do you want a trailing slash on the mailing list link too? :)
<fabbione> we can't work all together
<BenC> no, I was working on my end
<BenC> thought the ,,commit* stuff was causing something, but it isn't
<Kamion> silbs: I didn't consider that to be a directory, but I'm not sure how it looks on the backend
<Kamion> it doesn't redirect me to a URL with a slash anyway ...
<fabbione> BenC: ok try to commit now
<maswan> Kamion: better now?
<maswan> sent 5007 bytes  received 2334599320 bytes  1180583.73 bytes/sec
<maswan> took a while
<BenC> fabbione: thanks, working now
<Kamion> maswan: all your mirrors look happy; just poking frei.ubuntu.com now
<mdz> sabdfl,silbs: announcement ready to go?
<Kamion> (which was unrouteable earlier)
<mdz> Kamion: mirrors ok?
<fabbione> BenC: no problem..
<fabbione> maswan: hey dude
<Kamion> mdz: as of about fifteen seconds ago, yes
<Kamion> mdz: still need a torrent check
* pitti feels the suspension
<mdz> Kamion: I get 0bytes/sec on all torrents
<Kamion> elmo: can you check the torrent seeding please?
<mdz> elmo: does bt need the usual swift kick in the tail?
<Kamion> Znarl: or if you're around and know how
<Burgundavia> pitti, that would be supense. Suspension is a bridge
<pitti> Burgundavia: oh, thanks :-)
<Keybuk> Burgundavia: he could be wearing suspenders
<Burgundavia> Keybuk, or driving over a bumpy road?
<Kamion> elmo: also, could you please configure durville and frei's apaches to honour my .htaccess files?
<maswan> fabbione: hi there
<fabbione> maswan: buttercup has been dead for a long time...
<fabbione> maswan: i start to think it's hw issue
<fabbione> maswan: becuse i am running the same kernel here without problems
<maswan> fabbione: ok, I could try installing solaris on it and see if I can get a crash doing something?
<fabbione> maswan: can you just preserve the disks in case?
<fabbione> or allow me to backup some stuff first?
<CarlFK> Kamion - breezy install to hdb, grub on hda mbr, boot, grub error 21.  Smart Boot Managaer will boot breezy from hdb, so I suspect that grub doesn't know where to find boot/.  A) what package do I report against, B) got a quick fix?
<maswan> fabbione: yeah, sure
<maswan> fabbione: I'll do both. :)
<fabbione> maswan: nah.. i mean.. if you can install slowlaris on another disk (without touching the disks with linux) i am ok.. even without backup
<fabbione> maswan: if you need to reuse the disks.. than i would be glad to take a backup
<Kamion> CarlFK: I've been working for 13 hours, I'm not sure I can even read your question accurately at this point
<maswan> fabbione: we have no shortage of 9:ish gig drives, so..
<Kamion> send mail or file a bug against debian-installer or something
<fabbione> maswan: ok :) perfect :)
<CarlFK> Kamion - grub-installer ?
<Kamion> fair enough
<Kamion> I can always reassign once I understand what's up
<Kamion> sorry, thanks for testing, I'm just tired :)
<CarlFK> no prob
<CarlFK> http://bugzilla.ubuntu.com/show_bug.cgi?id=14989
<maswan> Kamion: the tracker does not seem to be running, as far as I can tell. for the torrents.
<CarlFK> done.
<Kamion> maswan: gah
* Kamion goes to SMS elmo
<maswan> at least, the announce url gives me a connection refused
<bddebian> SMS elmo?
<Kamion> bddebian: SMS. mobile phone. text message.
<bddebian> Kamion: Ahh
<maswan> If he's not available, you could regenerate the torrents and use the cdimage.d.o tracker I run. But that would probably not be optimal in at least a couple of different ways. :)
<crimsun> mjg59: yes
<sabdfl> mdz: go from my side, yes
<Kamion> maswan: yes and yes :)
<mdz> sabdfl: just waiting on torrents
<Kamion> james says "on bike. back soon"
<Keybuk> one hopes he pulled over to reply
* Keybuk has images of elmo biking one-handed in front of a bus
* Lathiat laughs
<CarlFK> i got some pics here of what happened when I tired to eat a hot-dog while riding...
<CarlFK> everything was fine till i tried to shift gears
<Kamion> Keybuk: let's not, eh
<Kamion> CarlFK: :-)
<Kamion> sounds painful
<CarlFK> at least the hotdog fell on some grass, so it was still eatable
<Keybuk> and where did you fall?
<CarlFK> no broken bones, and the fluid dripping from my face was sweat.  
<CarlFK> I hit the pavement
* Keybuk is good friends with all the local pavements
<CarlFK> lol
<Keybuk> side-effect of strapping wheels to your feet as a hobby
<bddebian> Anyone know off-hand what provides X11/bitmaps/gray ?
<BenC> that sucks, live-ppc cd doesn't boot on the G5
<BenC> bddebian: is that a file?
<Keybuk> bddebian: http://archive.ubuntu.com/ubuntu/dists/breezy/Contents-i386.gz
<elmo> kamion: I didn't
<BenC> or "dpkg -S X11/bitmaps/gray" if the file is installed
<elmo> that was my first SMS on a bike, and boy was it exciting
<elmo> kamion: anyhoo, torrent's back
<Kamion> elmo: great, thanks
<Kamion> BenC: you did boot with live-powerpc64, right?
<bddebian> BenC: I tried the dpkg -S route :-)
<BenC> Kamion: nope, didn't know there was one
<BenC> there's no way to have a single cd for 32/64?
<BenC> yaboot can't select a kernel based on the cpu type?
<Kamion> BenC: it's a single CD, but you need to select 32/64 at the yaboot prompt; the default is 32
<Kamion> BenC: there's a SuSE patch apparently, but not by default no
<bddebian> BenC: Oh and it in included in drscheme: #include <X11/bitmaps/gray>
<Kamion> I need to look at said patch
<BenC> hopefully it's similar to the silo usage
<BenC> image[sun4c] =/boot/vmlinuz-32 or image[sun4u] =/boot/vmlinuz-64
<Kamion> yeah, it's image[64bit]  I think
<Kamion> bah, all my systems are NATted such that I cannot test torrents
<mdz> my torrent downloads are still stalled
<mdz> just starting to come up at 1k/sec
<Kamion> rah
<Nafallo> yay! ;-)
<BenC> cool, live-powerpc64 is booting now
<mdz> is anyone getting realistic rates from torrent?
<maswan> Ok, I seem to be seeding a bit now
<mdz> maybe it's just me
<maswan> this will probably not give a very realistic rate though
* pitti only has NAT and torrents don't work with that
<maswan> we'll see in a while,but..
<Keybuk> I don't have NAT, but then I've also not managed to get torrents to ever work
<mdz> pitti: I have NAT, and set up a trivial forwarding rule
<bddebian> Keybuk: Sorry to bother you but how does that tell me what package?
<Burgundavia> mdz, pulling down 20~40k/sec
<Kamion> pitti: ah, --ip is the key
<pitti> mdz: but you certainly have to do that on the router that does NAT, right?
<mdz> pitti: yes
<mvo> Ijust started the torrent download and have 2k/s right now
<pitti> mdz: or do you mean some crackful ssh tunnel or so?
<Burgundavia> mdz, scrub that, dropping
<Kamion> pitti: http://crashrecovery.org/bittorrent/HOWTO.bttr.html
<pitti> mdz: ah, that router is at my provider
<mvo> (over nat and stuff)
<maswan> mvo: it seems that my slow seed is the only one running now. :/
<mdz> pitti: so you don't have nat, you are a victim of nat ;-)
<HiddenWolf> has preview been released?
<Kamion> the DNS hack there seems unnecessary
<mdz> HiddenWolf: it'll go to ubuntu-announce and the topic
<mvo> it's getting sharpy up now :) 20k now
<mdz> you have my word
<pitti> bah, jigdo works sooo well without any hacking...
<HiddenWolf> mdz, I can seed 1mbit for a few days...
<Kamion> oh, hmm, maybe it is necessary after all, hard to say
<Riddell> Kamion: it's not looking good for the kubuntu live amd64 CD, two reports of it not booting now
<mdz> still stalled here
<maswan> mvo: ehm. you on the amd64 install?
<Keybuk> bddebian:
<mvo> maswan: yes
<maswan> mvo: my home machine got a full block and started to upload. :)
<Keybuk> syndicate scott% zgrep "X11/bitmaps/gray" Contents-i386.gz
<Keybuk> usr/include/X11/bitmaps/gray                                x11/xbitmaps
<Keybuk> -- 
<Keybuk> so it's in "xbitmaps", which is in the x11 section
<maswan> mvo: the one I'm testing the rate in. :)
<mvo> maswan: and getting down again ... 5k
<pitti> Riddell: bad...
<mvo> maswan: hm, should I take a different one then :) ?
<bddebian> Keybuk: Ohh, I misunderstood the Location part.  Thank you.
<maswan> mvo: *shrug*, it will all even out in a while anyway
<mdz> elmo: torrent is not happy
<BenC> latest live cd runs on my G5, for whoever cares
* ogra still looks for a ppc edubuntu tester
<pitti> Riddell: it does not even spend any noticeable time on the CD
<pitti> BenC: cool
<Kamion> BenC: hooray
<Kamion> thanks
<jbailey> ogra: What needs to be setup aside from just the ppc box?
<pitti> ogra: is edubuntu closer to kubuntu or ubuntu?
<ogra> pitti, ubuntu
<Kamion> torrent stalls at 1.5MB precisely here
<pitti> ogra: I can't stay awake much longer anyway, I almost fall asleep
<Keybuk> getting about 50KB/s down at the moment
<Burgundavia> Kamion, same with me
<pitti> ogra: do you want to release edubuntu together with ubuntu? otherwise I can test it tomorrow
<ogra> jbailey, i'd be fine if someone just confirms a working install and that all server processes are running
<elmo> mdz: ... ? what do you want me to do?  the software's running
<elmo> in the same configuration that it's been running for the last two releases
<Keybuk> Kamion: here too
<mdz> elmo: ...but it isn't worknig properly
<mdz> working
<BenC> I love that all my mac keyboard special keys work on ubuntu
<ogra> pitti, nope, not at all, but mdz wants to... i'd rather fix the two remaining bits...
<maswan> I'll add another seed, soon.
<maswan> mdz: could it be that the seeding client on elmo's machine is busy checksumming the isos?
<mdz> maswan: elmo would know if that's the problem
<ogra> jbailey, http://edubuntu.org/EdubuntuTesting for the two manual interventions needed...
<jbailey> ogra: Sure, I can dust off the pegasos box fox that.  I have 10 minutes left in another rsync, and probably another 20 to sync the edubuntu disk.
<elmo> maswan: not AFAICS, no
<Keybuk> it uninstalled for me
<Keybuk> than restalled at 2.1MB
<ogra> jbailey, that'd be cool
<maswan> elmo: annoying, because I can only see my almost infinitely slow ftp.acc seed
<Kamion> wasn't there a web page somewhere that showed torrent status?
<mdz> Kamion: torrent:6969
<Riddell> ogra: I'm still downloading edubuntu ppc
<Kamion> mdz: "Server Error"
<ogra> mdz, i386 edubuntu is ok so far (i.e. no regressions)
<Riddell> 20 mings to download
<Riddell> mins
<mdz> Kamion: yeah, exactly
<ogra> Riddell, err, didnt you say amd64 ? 
<Riddell> ogra: I said powerpc
<ogra> dmaned
<ogra> damned even
<Riddell> ogra: you have an amd64 don't you?
<ogra> Riddell, yes, but i cant install on it and it only ready DVD for boot... my DVD writer is broken :(
<ogra> mvo, do you hav an amd64 to test ? 
<jbailey> ogra: Is there a useful amd64 test that I should do instead that doesn't involve wiping out my wife's computer? =)
<HiddenWolf> I'd volunteer, but I need to go :(
<mdz> Riddell: what are the symptoms of the failure?
<pawdro> hello, is gnome available to download for ubuntu?
<mvo> ogra: sort of, yes. no free partition, but I can make space
<Riddell> pitti: I'm downlodaing edubuntu poewrpc if you don't want to use up your bandwidth
<HiddenWolf> pawdro, it's installed by default, but please ask #ubuntu
<ogra> jbailey, i have no edubuntu live ...
<pawdro> I meant 2.12
<Burgundavia> Kamion, did you just stall at 2.5 as well?
<Riddell> mdz: acording to jbailey and pitti it just doesn't read the CD at all
<HiddenWolf> pawdro, it's in breezy
<Kamion> Burgundavia: yes
<mdz> Riddell: not even isolinux?
<HiddenWolf> pawdro, #ubuntu
<Kamion> oh, no, it's continuing
<pawdro> ok
<pitti> mdz: it just doesn't boot
<jbailey> mdz: It just spins at my bios' booting cd... prompt and then falls back to the harddrive to boot.
<pitti> same for me
<mdz> weird
<pitti> as if there were no CD at all
<jbailey> mdz: the amd64 ubuntu install cd goes to the expected isolinux prompt
<mdz> does it mount OK?
<mdz> and md5sum?
<jbailey> yes
<mvo> I stalled at 2.4, no it goes fast again
<jbailey> to mounting.
<jbailey> Haven't md5sum'd it.
<pitti> mdz: I tried to burn with three different CDs and two burners
<Burgundavia> Kamion, we seem to pulling of maswan, who is getting 0.5 meg chunks
<maswan> Burgundavia: the 0.5 meg chunks come to me from the seed in 2k/s
<pitti> mdz: md5sum of downloaded file was correct, dd'ing the image does not quite produce the same iso, though (probably some padding)
<mdz> pitti: I mean the internal md5sum on the CD itself
<Burgundavia> maswan, ouch, this is going to take a while
<mdz> pitti: md5sum -c
<pitti> mdz: I checked the download against the MD5sums file on the web, if you mean that
<jbailey> Do we just do md5sum -c foo.iso?
<mdz> pitti: no,I mean the md5sum.txt file on the CD
<Kamion> the log of that amd64 live build doesn't show any signs of problems
<mdz> the integrity check
<jbailey> Running it.
<jbailey> It looks like all OKs and echo $? gives me 0
<Kamion> mdz: md5sum.txt doesn't include isolinux/
<jbailey> Should the isolinux.bin be the same as on the ubuntu live cd?
<Kamion> jbailey: yes
<pitti> check still running, no problems so far
<bddebian> Gotta run, thanks for the Contents-i386 tip Keybuk
<jbailey> 45265d7515a84c5cc3000a3937a83316  isolinux.bin
<jbailey> 8bcdce8b2e28c6ed178e7445e5991011  isolinux.bin
<pitti> 45265d7515a84c5cc3000a3937a83316  isolinux.bin
<Kamion> hmm, actually it might be modified by mkisofs
<pitti> jbailey: at least we have the same file which makes random burn errors unlikely
<Kamion> other kubuntu live-amd64 images have the same isolinux.bin md5sum
<Lathiat> i have noticied that cdrecord vs nautilus tends to end up with different things
<Kamion> live-i386 is the same between ubuntu and kubuntu
<pitti> md5sum check complete without any error
<pitti> anyway, it's getting late again, and I need some sleep - happy release!
<Keybuk> hmm, it would be nice if, for the real release, we could find a version of the firefox totem widget that didn't crash all the time :-/
<maswan> some peopel getting better rates now?
<maswan> (on the torrents)
<Burgundavia> maswan, oh ya
<Kamion> ok, we use the -boot-info-table argument, so mkisofs modifies isolinux.bin with information about the CD layout
<elmo> Kamion: eh, do we need to put src seeds up for torrent?
<mdz> elmo: hey, it's picked up now; did you change anything?
<Kamion> elmo: probably not
<jbailey> Kamion: Why would just that one be different, though?
<Kamion> jbailey: good question
* dieman grumbles aobut ia32-libs-gtk not being updated yet.
<mdz> 4/6 torrents are going well, 2 still stalled
<Kamion> elmo: are they overloading things? I'll kill them off if so
<maswan> mdz: now all stalled?
<elmo> mdz: I've restarted it several times, they'll take a bit to come up
<mdz> maswan: argh, yes, all faling now
<maswan> mdz: and now up to speed again?
<mdz> maswan: yes, same 4
* maswan nods
<mdz> maswan: are you seeding only 4 of the isos?
<maswan> mdz: no, but for some reason the last 2 won't send data...
<maswan> ah, there one more
<maswan> heh. I'm close to that one
<maswan> dl speed: 6199.3 KB/s
<maswan> (my testing client at home)
<elmo> Kamion: I don't know if they're overloading it, but there's lot of whining about them in the blog
#ubuntu-devel 2005-09-14
<mdz> ok, I'm going to just rsync everything down and be a seed myself
<maswan> mdz: well, you can wat and we'll see if it managed to pick up on install-ppc too?
<maswan> ok, I seem to be seeding everything now.
<Nafallo> maswan: have you got seeds directly from the servers or something? :-)
<maswan> Nafallo: I downloaded the isos from a certain mirror and then started running a seeding client.
<Nafallo> maswan: at home or at univ? :-)
<maswan> Nafallo: univ
<Nafallo> or both? ;-)
<Nafallo> ah, nice
<maswan> my test client was at home
<Nafallo> I will pick torrent later then :-)
<Nafallo> maswan: we have the se.releases... in the topic on #ubuntu.se ;-)
<maswan> elmo: anyway, even if you don't get your seeding working right now, the 6 isos are seeded and it shouldn't be a blocker as long as the tracker stays up.
<mdz> this will take about an hour
<elmo> maswan: yeah, I'm assuming it's good ATM
<elmo> unless someone tells me otherwise
<elmo> there really isn't much more I can do anyway
<mdz> maswan: your seed seems to be working well for all 6 now
<mdz> so we can go ahead with the announcement, thanks
<maswan> mdz: yeah, your client might have been slow in re-requesting new peers from the tracker, or something
<maswan> or something else broke. now it works anyway. :)
<torkel> maswan: are you running any seeding client at HPC2N?
<maswan> torkel: nope, just using the non-production filesystem on farbror.
* dieman fired up an rsync
<dieman> damn thing wasn't setup right
<torkel> maswan: oh, come on... we need to keep up with ACC wasting bandwidth :-)
<mdz> announcement is away
<dieman> mirror.cs will have the cdimage when its done
<dieman> only coming in at 500kB/s tho
<maswan> torkel: feel free? :)
<Nafallo> torkel: rock! :-)
<dieman> but thats just rsync from archive.ubuntu.com
<Kamion> elmo: source torrents gone
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with breezy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://www.ubuntulinux.org/wiki/DeveloperResources | https://wiki.ubuntu.com//HelpingWithBugs | MOM/NDA producing bad diffs | Breezy preview is out: http://lists.ubuntu.com/archives/ubuntu-announce/2005-September/000031.html
* maswan is going to be somewhat busy now and then sleeping, but I'll see nick hilights as soon as I get to them
<torkel> maswan: not now. I'm heading to bed
<Nafallo> dieman: you could use se.archive.ubuntu.com ;-). I would think those have more bandwidth :-P
<maswan> ehm. s/archive/releases/, right?
<Lathiat> nooo se.archive is so starved for bandwidth
<dieman> there we go
<Riddell> Kamion, mdz: anything to be done about amd64 kubuntu live?
<Lathiat> it wasn't pushing 1.4gbit/s out last relase, oh no :)
<Nafallo> ah, right :-)
<Nafallo> releases
<Nafallo> Lathiat: hehe
<dieman> yeah, i only get 2.25 MB/sec from se
<maswan> well, right now we don't have any offloading hosts, so it is just the ftp cluster and a torrent seeding machine.
<dieman> i get 8MB/s from us
<Kamion> Riddell: frankly right now I'm in the mood to pretend I never heard any failure reports :P
<maswan> so we'll probably top out at 700Mbit/s or so.
<dieman> scrach that, peaks to 30, and then slows way the heck down
<dieman> yeah, back to 8MB
<Kamion> elmo: I don't know if you need to manually kill ubuntu-5.10-preview-src-* from the tracker
<elmo> Kamion: dude, so not touching this fragile POS
<Kamion> will it get there on its own?
<elmo> Kamion: how do you mean?
<maswan> it's working right now
<Kamion> elmo: does the tracker get restarted when files disappear due to a trigger from little?
<elmo> Kamion: in theory yes
<elmo> have you already triggered little?
<elmo> from little
<mdz> thanks to everyone who helped with the push for preview
<Kamion> in theory and practice, theory and practice are the same thing? :)
<Kamion> elmo: yes
<elmo> kamion: doh
<elmo> kamion: ok, so good news and bad news
<mdz> Riddell: can look at it now that preview is wrapped
<elmo> bad news is, trigger is broken. good news is, trigger is broken. 
<sabdfl> well done everybody
<Kamion> hee
<elmo> kamion: ATM, the tracker/seeds are working - I kind of want to leave them that way for now
<mdz> Riddell: burning one now
<elmo> kamion: and restarting them wipes them out for a good 10 minutes, and it's at best 50/50 on whether you end up with a working tracker
<elmo> mdz: let me know when I should unfreeze breezy uploads
<mjg59> crimsun: Cool - could you add details to the wiki at some stage?
<elmo> s/when/if/, I guess
<mdz> elmo: was thinking maybe we should leave them frozen for a day or so that upgrades are stable, but if upgrades are already tricky, we might as well let the fixes in
<mdz> mvo: what's the upgrade situation like, wrt to metapackages etc?
<mvo> mdz: readahead/readahead-list needs to be fixed, then it should work well
<elmo> mvo: another problem with CD based upgrade is, any file overwrite errors kill it dead
<sabdfl> elmo: can i see the bandwidth chart?
<elmo> and leave the system in a very confusing-to-the-user state
<mdz> Riddell: it's booting just fine for me here
<elmo> sabdfl: sec
<mvo> elmo: hm, what packages give us file override errors? 
<Riddell> mdz: spooky
<Kamion> 4 bytes/sec up. man, I'm such a good seeder
<elmo> mvo: oo2
<mvo> mdz: one think we may want to consider before final is if the cd based dist-upgrade should rewrite the sources.list to the new distro as well
<mvo> elmo: and the problem is that apt/synaptic stops at the override error?
<elmo> mvo: they don't stop, they just disappear
<maswan> http://www.acc.umu.se/technical/statistics/ftp/monitordata/index.html.en
<maswan> se.releases bandwidth graph
<mvo> elmo: they *disappear*? the errors?
<Lathiat> it already peaked up? ;p
<elmo> mvo: all the windows associated with the upgrade process disappeared, AFAICR
<mdz> Riddell: boots all the way into KDE with no problems
<mdz> Riddell: usplash, sound, everything
<maswan> Lathiat: yeah, I'm a bit surprised, but hey.. :)
<elmo> mvo: unfortunately, silbs was trying to do something semi-urgent at the time, so I didn't can't rember the exact sequence of events :(
<mdz> mvo: I think cd-based upgrade between releases needs more spec work
<mvo> elmo: so IOWs it crashs?
<elmo> mvo: yes
<mvo> mdz: ok, I agree. that's something for UBZ
<Kamion> mdz: SHIP IT
<elmo> mdz: dude, CD based upgrade happens when you put a CD in the drive already?
<elmo> even if we don't advertise it, people are going to use it
<mvo> elmo: I'll do a test cd-upgade from hoary->breezy now to see if I can reproduce the crash
<Riddell> mdz: does that mean we can release kubuntu breezy preview?
<mvo> elmo: the upgrade itself should work fine, the problem is that it needs hand-holding after the package upgrade (i.e. updating the sources.list with the synaptic repository editor for example)
<elmo> mvo: yeah
<Kamion> elmo: one minor snag is, we're going to have to get Kubuntu torrents in there somehow
<mdz> Riddell: as far as I'm concerned, kubuntu live amd64 is blessable
<elmo> Kamion: meh, ok, well let me know when - I'll play manual trigger
<mdz> Riddell: 26951ba02ef1f1696233efd3b07cfac7  breezy-live-amd64.iso
<mdz> Riddell: that's what I tested
<Kamion> Riddell: say the word
<Riddell> Kamion: go
<Burgundavia> ogra, http://www.advogato.org/person/bwh/diary.html?start=27
<mvo> elmo: silbs did a cd-based upgrade from hoary to breezy and it crashed in the middle of it, right? (/me tries to reproduce now)
<Kamion> publishing
<ogra> Burgundavia, thanks
<elmo> mvo: yes, but only when she hit a file overwrite in oo2
<elmo> make sure your hoary has that installed
<elmo> or you have some other file overwrite to hit :)
<silbs> mvo: yes. I had a hoary version of oo2 installed (in addition to oo1).  It was dealing with that that caused confusion.
<elmo> damn, I keep forgetting silbs lurks in here
<silbs> just passing by on my way to bed, heard sirens and came to see.
<Keybuk> by watching nautilus updating its thumbnails, I just learned an interesting thing about BMP files -- they're stored backwards
<mvo> elmo, silbs: thanks! (/me has some pretty broken deps to test the error reporting/handling in synaptic, but it may be a bug in the hoary version or something)
<mdz> elmo: yeah, better stop making fun of her
<Kamion> from now on all my world-killing weapons will be kept a TOTAL SECRET
<silbs> elmo, mdz: I'm leaving now. You can talk about me again.
<silbs> congrats all, well done.
<elmo> silbs: we'll be sure to do that, in a couple of hours, to make sure your laptop's noises are suitably irritating
<fabbione> night guys
<fabbione> thanks for the ride :)
<mdz> night fabbione
<mvo> night fabbione 
* fabbione did enjoy the fun
<ogra> night fabio
<mvo> elmo: is there already a bug open for that file-override errors in oo2? if not, I'll open one once I have triggered it :)
<mdz> sabdfl,Kamion: who can update the website?
<elmo> mvo: not yet no
<Kamion> mdz: www.u.c?
<mvo> elmo: ok, thanks
<Kamion> I think I can, or at least I used to be able to
<dieman> hrm, so has anyone figured out this libpangohack.so issue with openoffice and mixing 32 and 64 bit binaries?
<Kamion> yes, I can - I'll tweak /download/
<dieman> it tries to call 64 bit stuff to print, and it breaks badly
<mdz> Kamion: yes
<dieman> because of the preload
<mdz> Kamion: thanks
<elmo> Kamion: btw, little's down to 30% free, fyi.  if you don't care, let me know what I should reset the yellow-line alarm %-free to
<dieman> fuck this
<dieman> im goig to patch pango in ia32-libs-gtk
<dieman> all this hassle for a one-liner?
<Kamion> elmo: 20%
<Kamion> elmo: it should get healthier when we're not building 10 extra manual sets of images a day, though
<Kamion> anyone want to inspect http://www.ubuntu.com/download/ ? my additions are deliberately fairly brief
<Kamion> might want to be a bit more adverty though
<jbailey> Kamion: Doesn't seem to contain the word 'preview'.  What are we looking for?
<jbailey> Ah, the page to commit.
<jbailey> =)
<Kamion> jbailey: reload
<jbailey> Kamion: It looks like hte preview is codenamed "Breezy Badger".  Just tryig to think of how to word it differently.
<Kamion> jbailey: try now?
<jbailey> Looks better.  Maybe make it "The Breezy Badger" to be consistant with the preview line?
<Kamion> a news item wouldn't hurt either, but I have no idea how to do those
<Kamion> jbailey: ok
<BenC> hmm, doing "Restart" on breezy live-cd on my G5 just ends up dropping to a shell prompt
<BenC> goes all the way to "Restarting System" and then doesn't
<Kamion> does a normal 'reboot' or 'shutdown -r now' work?
<sabdfl> Kamion: page looks good, thanks
<Riddell> ogra: booting by typing workstation at yaboot didn't work
<ogra> oh
<dieman> Kamion: while you're there, could you fix ftp.cs.umn.edu ->mirror.cs.umn.edu?
<ogra> Kamion, didnt you make the changes to yaboot ?
<dieman> Kamion: i've emailed mirrors@ twice i think now.
<ogra> Riddell, could you just do a normal install then ? 
<Kamion> sabdfl: cool
<Riddell> ogra: doing that, seems to be working so far (1/3rd through installing the base system)
<ogra> ok
<Kamion> dieman: ok, one sec
<dieman> thanks
<dieman> i want to kill the old mirror, and thats part of the reason i keep it around
<dieman> i'll email -users sometime tonight about it changing too
<Kamion> 404 Not Found
<Kamion> The requested URL '/pub/ubuntu-releases/' was not found on this server.
<dieman> ints ubuntu-rleeases
<dieman> in the root
<Kamion> ah, 'twas same on ftp.
<dieman> mirror.cs.umn.edu/ubuntu-releases
<Kamion> or not
<dieman> no, its a change
<Kamion> dieman: ok, cool, sorted
<dieman> ok
<dieman> thanks
<Kamion> dieman: I see you have the preview already too, I'll put your mirror up at the top as well if that's ok
<dieman> machine isn't as fast as the other us/se mirrors but its not bad
<dieman> sure
<dieman> it can do 100mbps
<dieman> i need to get it a gigE card
<Kamion> ogra: no, not yet
<ogra> Kamion, none yet ? 
<Kamion> $ grep edubuntu ubuntu/status
<Kamion>   powerpc edubuntu bootloader config fixups (workstation)
<Kamion> (my to-do list)
<ogra> ok
<dieman> it might still be rsyncing the
<Kamion> sorry, I did mention it at the time and you didn't seem to be saying it was massively urgent so I put other things ahead of it
<Kamion> dieman: looks complete at a quick glance
<Kamion> dieman: could you configure it to honour the .htaccess files there?
<Kamion> that way it'll get the pretty header and footer
<dieman> ok
<dieman> i'll move it to apache sometime, i guess
<dieman> i dont know if thttpd will do it
<Kamion> ah, didn't realise that was thttpd
<Lathiat> did dbuds behavior change to allow anyone on the system bus
<Kamion> not important enough to change your server arrangements just for that :)
<Lathiat> *dbus
<dieman> apache might just be fine on there, but i know thttpd is stupidly fast.
<Kamion> certainly for static files it'll be a win over apache
<Riddell> Kamion: what's the status of releasing kubuntu ISOs?
* Kamion does a full check of the mirror list
<Kamion> Riddell: sorry, got distracted by other things - they're syncing to mirrors now
<elmo> Kamion: I have a script for that ;)
<Kamion> elmo: ... which mustn't have been run since hoary :P
<Kamion> I'm nearly done anyway
<Kamion> moving stuff from "Other mirrors" further up
<elmo> Kamion: right
<elmo> given releases hasn't changed since then ;P
<Kamion> yeah, but the list of mirrors that managed to grab it has
* Lathiat d09w099    
<Lathiat> .
<Kamion> anyway, much better now, only three mirrors in the dead list at the bottom
<Kamion> and the Norwegian mirror has the preview
<Nafallo> hmm, I thought that was done with pulling :-P
<Nafallo> or pushing rather...
<Kamion> not all
<tseng> jdub: ping
<crimsun> mjg59: sure, will do
<jdub> tseng: pong
<tseng> jdub: so my blog was down for a few days
<tseng> jdub: its back, p.u.c doesnt seem to care
* Lathiat discovers a solution for most restarts of dbus
<tseng> jdub: (not picking up new posts)
<Kamion> elmo: Kubuntu images are on our mirrors now though not the Swedish ones yet
<elmo> nobody    1540  0.7  0.0   3680  1912 ?        SNs  00:12   0:03  \_ rsync --daemon
<Kamion> so should be torrentable
<elmo> they're syncing
<elmo> oh, ok
<Kamion> yeah, I'm not worried, the Swedish bit should've been in parens or something
<elmo> torrent kicked
<Kamion> cheers
<Kamion> I really should've poolonly'd kubuntu a while ago, oh well
<Riddell> Kamion: what's the url?
<jdub> tseng: i don't have access to the planet install to fiddle :-|
<Kamion> Riddell: http://releases.ubuntu.com/kubuntu/5.10/
<tseng> jdub: ok rock on. other planets picked it right up
<tseng> jdub: obviously no emergency, though
<Kamion> Riddell: will only work some of the time, it's round-robin DNS and 2/6 have the files
<Kamion> Riddell: make obvious changes to the URLs in the Ubuntu announcement to get explicit US and Sweden links, if you like
<Kamion> http://us.releases.ubuntu.com/releases/kubuntu/5.10/ has got just install-amd64 so far
<Kamion> http://se.releases.ubuntu.com/kubuntu/5.10/ is working on it
<jdub> Lathiat: you became a member last week or so, right?
<Lathiat> jdub: yup
<Lathiat> last CC meeting, approved as MOTU last TB meeting
<jdub> with the "best wiki home page ever" as i recall
<Lathiat> yeh
<mvo> elmo: filed #14997 about the ooo2 upgrade issue, no crash here, I'll try harder now (to make it crash)
* Lathiat patches dhcdbd not to have a dbus configuration allowing any one to do anythign on the system bus
<Lathiat> silly redhat
<desrt> mxpxpod; bug submitted
<mxpxpod> desrt: awesome
<mxpxpod> desrt: does it do it on i386?
<desrt> x86 is fine
<mxpxpod> lovely
<jdub> Lathiat: do you have a hackergotchi?
<mxpxpod> desrt: now, if we can just get it fixed somehow
<Lathiat> jdub: umm, i have a southpark face
<Lathiat> (no)
<desrt> mxpxpod; i assigned the bug to martin pitt.  he owns an ibook
<desrt> :)
<mxpxpod> sweet
<desrt> it'll probably be fixed in a day or two knowing how things go :P
<mxpxpod> probably
<mxpxpod> desrt: have you tried usplash?
<mxpxpod> on ppc
<jbailey> I should reboot and see what it looks like now.
<desrt> no
<desrt> is it special?
<mxpxpod> jbailey: I'm not sure that it works
<jbailey> mxpxpod: Oh?
<jbailey> mxpxpod: What happens for you?
<mxpxpod> jbailey: you can try it, but last time for me it just did the same thing as always
<mxpxpod> this service starting...     [ok] 
<jbailey> As always?  The code to make it work on ppc only went in last night. =)
<mxpxpod> jbailey: yeah, I downloaded it this morning and tried it out
<dieman> heh
<dieman> someone just rsynced off of me
<dieman> i think
<dieman> nifty
<Riddell> ogra: edubuntu powerpc installs and boots just the same as ubuntu (but the kdeedu installed)
<dieman> was doing 8mbps or so
<dieman> nothing like the se mirror :)
<jbailey> Riddell: Doing kedubuntu as well?
<Nafallo> dieman: ;-)
<ogra> Riddell, yes, with the added artwork thats a workstation install...
<mxpxpod> also, another oddity is that when I boot into linux, it says at the start: init: line 91 chmod doesn't exist on /
<jdub> elmo: planet update please, when you have a moment :-)
<Riddell> jbailey: breezy + 1 :)
<ogra> Riddell, thanks for testing :)
<jbailey> mxpxpod: Update your busybox-initramfs and regenerate the initramfs to solve that.
<jdub> elmo: oh, wait a sec, mirror hasn't finished
<Nafallo> jdub: did you ever add my blog btw? :-)
<mxpxpod> jbailey: huh?
<mxpxpod> jbailey: how do I regenerate my initramfs?
<jdub> Nafallo: yep!
<jbailey> mxpxpod: That chmod error should have been fixed about a week ago.
<Nafallo> jdub: yay! I was holding off for an ack-mail ;-)
<jbailey> mxpxpod: mkinitramfs -o /boot/initrd.img-$(uname -r)
<Nafallo> jdub: I should start blogging again soon then, and thanx and goodmorning :-)
<Lathiat> jdub: thanks
<jdub> hrm, having trouble mirroring
<jbailey> mxpxpod: If you weren't regenerating your initramfs, then I'm surprised you saw any graphics screen at all on ppc...
<mxpxpod> jbailey: didn't know that I had to update it
<jbailey> mxpxpod: After the freeze is done, the new usplash package and such will try to update it automatically.
<mxpxpod> wow, it takes a while to mkinitramfs
<mxpxpod> ok, let's reboot and see what's up
<Riddell> Kamion: are there any .torrent files for the Kubuntu CDs?
<mxpxpod> jbailey: holy crap,that's sweet
<Kamion> Riddell: sure, they should be on mirrors or syncing to them
<TheMuso> Has anybody had trouble rsyncing the preview iso images? I get the message: skipping non-regular file "ubuntu-5.10-preview-install-i386.iso" when I try to fetch the image.
<jbailey> mx|gone: =)
<Kamion> TheMuso: ubuntu-5.10-preview-install-i386.iso is a symlink to ../.pool/somethingorother.iso - make your rsync follow symlinks?
<mx|gone> jbailey: gotta get going... talk to you later
<Kamion> -L
<jbailey> mx|gone: Post preview it will update automatically.  Glad it works for you.
<jbailey> mx|gone: Be well. =)
<TheMuso> ah thanks.
<mx|gone> jbailey: also, the chmod thing is fixed now
<mx|gone> ok, now I'm really gone
<mx|gone> jbailey: now, if we can just get pbbuttonsd to quit eating all the cpu on boot
<mx|gone> :)
<jbailey> mx|gone: Yes.  It only happens randomly for me here.
<Riddell> Kamion: hmm, none of the mirrors have picked up any of the .torrent files
<Nafallo> Riddell: http://se.releases.ubuntu.com/5.10/ yes, they have.
<Riddell> Nafallo: I mean for kubuntu
<Kamion> Riddell: it's not a problem, the other files you're seeing are all symlinks which confuses the ordering
<Nafallo> Riddell: ah, that's not done syncing for se. :-)
<Kamion> Riddell: and actually I just reloaded http://releases.ubuntu.com/kubuntu/5.10/ four times and saw torrents every time
<Riddell> ok, I'll just be patient :)
<Kamion> Riddell: the UK mirrors have them, the SE ones not yet
<dieman> yay. 15mbps
<Nafallo> Kamion: do you know if se. uses push to get the updates? :-)
<Kamion> Nafallo: yes
<Nafallo> thought so :-)
* ajmitch looks for somewhere fast to rsync from
<Kamion> Nafallo: 19:52 < elmo> Kamion: triggering syowa triggers us + se
<Nafallo> yay! that's cool :-)
<Nafallo> and then se triggers some other mirrors?
<jdub> boh, can't get to preview through cdimage.ubuntu.com
<Nafallo> jdub: to lazy to type releases? ;-)
<jdub> sweden is giving me the flick doing that
<Nafallo> hehe
<jordi> mdz: you popped the trunk
<mdz> jordi: yes
<mdz> jordi: your turn
<mdz> jordi: language pack exports from rosetta!
* jordi delegates turn on carlos.
<jordi> mdz: that should be done or about to be done 
<mdz> jordi: I have heard this story before
<desrt> is there a backlog of ubuntu packages somewhere?
<desrt> like, an archive of all the previous versions
<mdz> desrt: morgue.ubuntu.com
<jordi> mdz: don't say you didn't get your apt patch
<desrt> awesome!
<jordi> even if you broke it a lot
<mdz> jordi: I uploaded it
<mdz> jordi: UNANNOUNCED
<jordi> mdz: heh, funny, you got even more heat for the c++ stuff, didn't you? :)
<mdz> jordi: I hate c++
<mdz> jordi: want to maintain apt?
<jordi> mdz: at most, I'd like to fix all those i18n bugs.
<jordi> BUT IT REMAINS YOURS
<Riddell> bah, none of the kubuntu torrents are working
<bur[n] er> who wants that kubuntu stuff anyway? ;)
<Keybuk> anyone else seen the mtr bug where it gets rather confused when you have more than one mtr banging away at the same host? :p
<ogra> mdz, ping
<BenC> anyone using mol?
<ogra> BenC, there are some users on the ubuntu-users ML 
<desrt> cdrtools is in serious need of an autoconf makeover
<desrt> s/autoconf/automake/
<Lathiat> BenC: what to use the wireless? ;p
<desrt> this schily makefile system is _the suck_
<mdz> ogra: yes?
<bddebian> mol?
<ogra> mdz, so what do i do with edubuntu now ? 
* bddebian quivers
<Riddell> elmo: if you could seed the kubuntu torrents that would be great
<mdz> ogra: what works and what doesn't?  what  blockers does it have?
<elmo> Riddell: they are seede
<elmo> d
<ogra> mdz, the ppc yaboot changes arent in, i have found no amd64 tester yet (mvo wants to test tomorrow, he was to tired)
<mdz> ogra: what has been tested, and what remains untested?
<ogra> mdz, i386 is ok with two manual steps
<mdz> ogra: 1. fix any blocker bugs, 2. test every iso, 3. release
<ogra> mdz, ltsp-build-client needed a udeb 
<BenC> I think I found what I need for mol to work
<BenC> I was booting osx tiger with it, and mol needs a patch
<jsgotangco> ogra, you mean by amd64, on the server? i can grab an iso now
<ogra> mdz, the source is up for review through Kamion... on rookery
<ogra> jsgotangco, that'd be cool... 
<ogra> mdz, additionally the patch update i sent you for ltsp would be needed for a complete automatic install...
<ogra> mdz, the missing pieces are listed on http://edubuntu.org/EdubuntuTesting
<mdz> ogra: check the restart patch into baz, upload ltsp and tell me where to merge it from
<ogra> mdz, did you chack my ltsp archive ? i'm not sure if i did it right
<ogra> check even
<mdz> ogra: for the mirror stuff, you ought to be using the apt cache.  all of the debs are already copied to the hard drive, so there is no reason to tell the user to reinsert the CD
<ogra> mdz, i do it before reboot with the udeb, "Build LTSP chroot" is also a point in the installer menu...
<mdz> ogra: your email has a patc hattached to it
<mdz> ogra: not an archive or a url for an archive
<ogra> mdz, about a week before...
<tseng> mdz: would it be possible to have katie mails redirected temporarily while my server is dead?
<tseng> mdz: it would be good to know where uploads are going
<mdz> ogra: I don't have it
<ogra> mdz, ... when you asked me for an arch repo
<mdz> ogra: if you are blocked on me looking at something, you need to give me the information now, not send me looking for it.  i don't have time
<jcole> how do i make apt install suggests/recommended packages automatically?
<mdz> tseng: what?
<ogra> mdz, from my mail from aug 30: http://people.ubuntu.com/~ogra/archive/ogra@ubuntu.com--ltsp
<tseng> mdz: my mail server is dead, as a side effect i dont get mails from katie. is there a way to send them somewhere else for now?
<mdz> ogra: baz merge ...?
<mdz> tseng: just for you? no, I doubt it
<mdz> tseng: they'll be queued and sent whenyou r server comes back up
<tseng> mdz: ok, thanks. hopefully tommorow then.
<mdz> tseng: you can read breezy-changes meanwhile
<tseng> mdz: that works when things are accepted :)
<jcole> i'll just write a script to parse the apt-get install simulate output...brb
<mdz> ogra: I assume you mean ltsp--ogra--0
<ogra> err, yes
<mdz> ogra: that branch has a lot of other changes in it
<mdz> I can't merge it as-is
<mdz> forget it; I will commit the patch separately to my archive
<ogra> hmm, but you wont have the themeable ldm from august then :/
<mjg59> Damnit.
<mjg59> The release is the week after Linuxexpo
<jsgotangco> yay
<mjg59> How was this DISASTER allowed to happen?
<bddebian> heh
<elmo> I blame www.dccalliance.biz
<Nafallo> lol
<mjg59> elmo: Seen http://lists.userlinux.com/pipermail/discuss/2005-September/007379.html ?
<elmo> mjg59: oh yes
<elmo> does anyone know how to stream from xmms to a shoutcast (or similar) server with ogg rather than mp3?
<Lathiat> elmo: hrm
<Lathiat> elmo: icecast i think does the ogg stuff
<Lathiat> elmo: no idea about xmms
<mjg59> Hm. Anyone know why the archive files from pipermail don't seem to be mboxes?
<daniels> they're special
<BenC> yay, mol booting macosx tiger
<BenC> need to point mol maintainer to the patches
<mjg59> Ah. I can download the entire archive.
<mjg59> That'll do.
<mp1> whoa, just reported bug 15000
<infinity> And thanks to our community commitment to never have more than 15,000 bugs, we can now all stop working and shut down the archive.
<infinity> \o/
<bddebian> infinity: :-)
<mpt> But you see, infinity, that's why Malone exists
<mpt> So we can start again from #1
<infinity> Clever.
<bddebian> Not quite, we have several on Malone already too :-)
<infinity> When Malone hits 15,000, do we switch to debbugs?
<mpt> Yes, about 2000
<Nafallo> lol
<mpt> So Malone will last us for a few more months yet
<bddebian> hehe
* bddebian wonders if mpt should get a prize.. :-)
<mpt> I reported Malone #1000, that was prize enough
<slomo> daniels: regarding #14993... will you pull the via driver vom HEAD for breezy?
<bddebian> heh
<ajmitch> I guess quite a few of those 2000 bugs are from mpt anyway
<bddebian> ajmitch: lol
<mpt> Eventually I'll catch up to the 140 or so I reported about Mozilla
<ajmitch> mpt: you're at 82, according to your karma page
<ajmitch> so it won't take long
<mpt> Yeah, but about 138 of those are about Launchpad itself
<mpt> so they don't really count
<mpt> er, about 78 of those, I mean
<daniels> slomo: probably not, to be honest; not at this late stage
<infinity> Yeah, I get 138 and 78 mixed up all the time, too.
<daniels> slomo: it's a big change to backport, and the via driver is notoriously regression-happy
<slomo> daniels: hm :(
<slomo> daniels: that bugreport was by a friend of mine... that's why i ask ;)
<slomo> daniels: i'll probably create some packages for him with the new driver then...
<daniels> okay
<daniels> i just can't guarantee that we won't be in regression city between preview and final if I backport it
<slomo> yeah... i understand... would it help if i write upstream and ask if they can guarantee that there were no regressions?
<mjg59> NO, NO, NO REGRESSIONS HERE
<mjg59> Oh. You mean those regressions?
<slomo> ok, let's build xorg ;)
<khermans> how can I submit out sourceforge deb binary into the offical repos?
<khermans> or how does this process work?
<mdz> jbailey: have you changed your email preferences in bugzilla or something?  it says it is excluding you from mailings
<jsgotangco> mdz, docs are frozen now
<jsgotangco> we'll put up the pot files for translation
<fabbione> morning guys
<jsgotangco> morning fabbione
<bddebian> Hello fabbione 
<themikester60> does anyone have any news about the breezy preview?
<daniels> what, other than 'it's out'?
<infinity> themikester60 : /topic
<themikester60> its not really support if i just ask for news
<infinity> Further down the topic.
<themikester60> ah right, i eat my words then sorry
<daniels> themikester60: i think he was more talking about the bit where it says 'breezy preview is out', with a link to the ubuntu-announce list ...
<fabbione> daniels: ping?
<fabbione> mdz: permission to upload fix for #14726, the submitter is right and it's one line change in an init script.
<daniels> fabbione: mmm?
<fabbione> daniels: did you have any time to look at xfs anymore?
<fabbione> otherwise i can poke it today
<daniels> not yet, sorry
<fabbione> ok i am on it
<fabbione> if that's ok with you
<daniels> i had a quick look, but I've been more distracted with fixing the maintainer scripts for preview and also libxt
<daniels> yeah, that's great, thanks a lot
<fabbione> no problem
<jammcq> mdz: hey, I build a breezy box tonight, plugged a thin client in, turned it on, and the sucker booted :)
<fabbione> i have just been slightly busy with some -security stuff
<fabbione> jammcq: yo :)
<jsgotangco> yeah it works
<jammcq> hey fabbione, how's it going?
<jsgotangco> its actually fast
<fabbione> jammcq: just woke up.. i barely feel alive
<fabbione> you?
<jammcq> heh, i'm just getting ready for bed
<daniels> fabbione: (also I've been pretty sick for a while, so not been at full effectiveness)
<mdz> jammcq: groovy
<fabbione> daniels: yeah.. i have been sick too for almost a week...
<fabbione> today i almost feel 100%
<mdz> jammcq: in the excitement I forgot to tell you when preview was out; I guess you got the word though
<jammcq> mdz: yeah, the docs don't say that you have to start dhcpd, portmap and nfs-kernel-server tho
<fabbione> more energy and more power to do stuff
<mdz> fabbione has been at death's door
<mdz> jammcq: that's a bug I just fixed today
<jammcq> mdz: ah, cool
* fabbione does the italian dance to kill unluck and scratches his nuts
<jsgotangco> mdz, so edubuntu doesn't need any configuration anymore?
<mdz> jammcq: dhcp and nfs-kernel-server, anyway.  you shouldn't have to touch portmap in any case
<jammcq> and I saw that problem, where the first time I boot the client, it fails at the nfs mount.  But then I rebooted the client, and it worked fine
<mdz> jsgotangco: you need to run ltsp-build-client manually for now, but ogra is working on that
<jsgotangco> ahh
<mdz> jammcq: yeah, that's a tricky one, that is
<jsgotangco> i did his instructions last night and it worked nicely except i had to reboot the client
<mdz> jammcq: nobody sees that problem in ltsp-land, eh?
<jammcq> nope
<jammcq> but overall, this is VERY impressive
<mdz> it's pretty basic, but has a lot of potential
<jammcq> yessir
<mdz> montreal will be fun
<jammcq> i'm anxious to see where we all go with it
<mdz> we'll be able to get on with the more interesting stuff
<jsgotangco> ive been testing some of the educ apps in edubuntu most of them already work
<mdz> jsgotangco: I should hope so; it's quite late in the game ;-)
<jsgotangco> its very much usable
<jammcq> i'm gonna boot my main desktop via breezy, see how well it detects my 23" monitor.  brb
* daniels shudders.
<fabbione> mdz: sorry.. did you read my upload permission request? ntp lands in main...
<mdz> fabbione: no, I didn't
<fabbione> mdz: permission to upload fix for #14726, the submitter is right and it's one line change in an init script.
<fabbione> (just copy/paste)
<mdz> fabbione: yes, fine
<fabbione> ok thanks
<mdz> I scrolled up :-)
<mdz> fabbione: uploads are still queued for now
<fabbione> yeah i read that yesterday night
<daniels> mdz: ping
<mdz> daniels: I've been talking in the channel for the past 15 minutes...
<daniels> mdz: in any case
<daniels> mdz: permission to introduce a new binary package or three
<mdz> daniels: specifically?
<daniels> mdz: libfontcache is currently only being shipped libfontcache.so.x.x and libfontcache.so.x with libxfont
<daniels> turns out xfs needs it to work properly, so I'd like to give it its own packages
<fabbione> daniels:hold on.. i can probably workaround that 
<mdz> I don't follow...what's being shipped in which package(s) currently, and what of that do you want to move to new packages?
<daniels> mdz: libxfont1 ships libxfont.so.1 and libfontcache.so.1
<mdz> or is it something we aren't shipping at all currnently?
<daniels> mdz: there is no libfontcache.so
<mdz> fabbione: ?
<fabbione> mdz: that makes xfs build, but not link properly (there are no errors in the build log tho)
<fabbione> so xfs fails to start
<fabbione> mdz: i can workaround linking directly. probably
<mdz> xfs is uiverse
<mdz> universe
<fabbione> mdz: yes and you still larted me for saying that a few days back :)
<fabbione> mdz: so i am fixing an xfs bug that's the result of the first one
<mdz> fabbione: this is a regression?
<fabbione> mdz: compared to hoary, yes
<fabbione> it doesn't start
<mdz> argh
<mdz> fabbione: what's your proposed workaround?
<fabbione> mdz: let me see first what is required to fix it properly and if we can workaround it
<fabbione> mdz: in theory just ld xfs /usr/lib/libxfontcache.so.0 should do
<fabbione> that will avoid to add another set of pkgs...
<fabbione> but it's HACKISH
<fabbione> ok just gimme a few minutes to test.. ok?
<mdz> why not just add a .so symlink to libxfont1?
<mdz> we can split it up after breezy if that's the right long-term solution
<daniels> i could add it to libxfont-dev if you liked
<daniels> (the .so)
<elmo> WTF.  WE'VE (preview-)RELEASED PEOPLE.  USE UP SOME BANDWIDTH ALREADY.
<daniels> elmo: hey, I'm working on today's upload of xorg.  give it some time.
<infinity> elmo : Aww, are you feeling underappreciated?
<jdub> elmo: hasn't hit any of the news sites yet
<fabbione> daniels: no.. it's not that..
* jdub starts using his forward button in mutt
<fabbione> daniels: xfs is linked with libfontcache..
<fabbione> daniels: i think it's a bug in libfontcache
<daniels> fabbione: ...
<da_bon_bon> hi all.. does breezy usplash need framebuffer console ?
<daniels> fabbione: so the ld xfs /usr/lib/libfontcache.so.0 thing won't work
<mdz> da_bon_bon: yep
<daniels> da_bon_bon: well, yes
<fabbione> ldd /usr/bin/xfs |grep cache
<fabbione>         libfontcache.so.0 => /usr/lib/libfontcache.so.0 (0xb7cf4000)
<fabbione> this is from the pkg in archive
<fabbione> so it is linked with libfontcache
<mdz> elmo: dude, we had three mirrors from the start, including us where people were actually awake at the time
<da_bon_bon> mdz, daniels: sorry to be asking here .. but is i810 framebuffer console enabled ? i think there is a special driver for i810 fb else it wont work
<daniels> da_bon_bon: it just uses vga, which works everywhere
<mdz> da_bon_bon: it uses vga16fb, which works on i810
<fabbione> brb
<jammcq> ok, my Hp thin client booted, but the 23" flat panel wasn't very pretty
<da_bon_bon> mdz: ok.. but vga16fb gives very less colors..
<jammcq> not surprised tho
<mdz> da_bon_bon: so it goes
<da_bon_bon> daniels: vgafb wont work on i810
<daniels> da_bon_bon: it works fine on my i855
<mdz> da_bon_bon: yes, it does.
<daniels> da_bon_bon: it works fine on many other i8xx devices out there
<mdz> jammcq: does it not support DDC or something?
<daniels> da_bon_bon: if you want a better resolution and accelerated drawing, and better colours, sure you need the i8xx fb
<jammcq> hmm, dunno.  it's a fairly new monitor
<daniels> da_bon_bon: but the i8xx fb driver doesn't work on any laptops.  so it's kind of useless.
<mdz> jammcq: what's the size of the panel (pixels)?
<jammcq> does a very nice 1920x1200 resolution, but in Breezy/ltsp it came up as 1280x1024
<daniels> jammcq: 'wasn't very pretty'?
<daniels> oh, right
<mdz> daniels: shouldn't that work?
<daniels> this is probably that hillarious thing where ddcprobe thinks it's an analogue monitor, so refuses to use the top res
<jammcq> in my LTSP, I have a custom modeline I use for it
<jammcq> I copied those entries over to breezy, but it didn't pick it up
<daniels> mdz: in theory, yes.  in practice, I need to rewrite yet more chunks of ddcprobe.
<mdz> jammcq: we don't have a mechanism for custom modelines yet
<jammcq> mdz: ah, ok
<daniels> jammcq: did it write out HorizSync and VertRefresh entries?  if so, nuke them (this is the expected -- shitty, but expected -- behaviour on amd64)
<mdz> jammcq: I sent you a mail a while back with a list of which lts.conf parameters we'd implemented and asked which ones were most important...;-)
<jammcq> daniels: umm, dunno.  I've since rebooted the client from my old ltsp server
<jammcq> mdz: umm, yeah, I prolly have that email still :)
<da_bon_bon> mdz: on i810 ?? what should i pass ? vga= ? in 791 it gives undefined mode number.
<fabbione> re
<jammcq> the boot time of the clients is still a bit strange.  my 1ghz Via booted in about 1 minutes. which isn't too bad.  My 733mhz transmeta took about 5 minutes to boot
<da_bon_bon> daniels: it is not useless for all i810 users .. but as ubuntu must cater to laptop community, i am not arguing :)
<jammcq> both of those workstations take about 30 seconds on LTSP-4.1
<jammcq> it spent about 90 seconds in the 'Starting Hotplug'
<mdz> jammcq: it loads all drivers which are available for the hardware, even if we don't actually have a chance of using it yet (e.g., USB, audio, etc.)
<mdz> some of them take a few seconds to load
<mdz> 90 seconds for hotplug is excessive, though
<jammcq> but the 1ghz box is like 5 times faster.  seemed odd
<mdz> there's a flag in /etc/default/hotplug or such that you can set to make it more verbose
<jammcq> ah, that would be good, so we can track what it is doing
<jammcq> i'll try that tomorrow
<mdz> on an installed system, you can boot in recovery mode and it should be verbose; no convenient way to do that on a thin client though
<jammcq> what determines 'recovery mode' ?
<jammcq> a kernel cmdline paramter?
<mdz> recovery mode = single-user mode
<mdz> that's what the default grub menu calls it
<jammcq> ah, 'single' on the kernel cmdline
<jammcq> that's easy to add to the pxelinux.cfg/default file
<mdz> jammcq: http://bugzilla.ubuntu.com/show_bug.cgi?id=14979
<mdz> jammcq: my definition of 'convenient' is more like something I could easily explain over the phone to someone who didn't already know where to go ;-)
<jammcq> heh
<mdz> daniels: dude, you have people complaining both about refresh rates being too high AND too low
<daniels> mdz: tell me about it
<daniels> mdz: THIS REFRESH IS JUST RIGHT!! WTF I DEMAND A REFUND
<daniels> mdz: that's what I'm waiting for
<daniels> mdz: though I'm cheerfully ignoring the '85Hz at a minimum but always 100Hz if possible' insanity
<desrt> people complain about refresh rates too high?
<HrdwrBoB> how could you POSSIBLY have a refresh rate too high
<desrt> (other than, the obvious problem that your monitor doesn't dig)
<daniels> because it's not the highest possible resolution omg
<desrt> ah
<HrdwrBoB> unless your monitor is a hojillion years old and squeals like a stuck pig if it's higher, in which cash you deserve it to explode
<desrt> crts are best run at one or two steps down from max
<desrt> lcd should very obviously be at absolute max
<mdz> daniels: for breezy+1, what would it take to push this all out to the desktop and just let the user pick what they want?
<HrdwrBoB> oh, I'd rather have 1280x1024 at 60hz interlaced than 1024x768@85hz
<mdz> that little xrandr thing in gnome is a good start on it
<desrt> mdz; ya... that's always a thought
<daniels> mdz: they can do it today if they want
<desrt> give them whatever the hell you feel like and if they don't like it they have a nice friendly app to do it themselves
<daniels> mdz: doing this *properly* with multiple monitors (which I'm currently blueskying about in #freedesktop with a couple of others) is much, much harder
<mdz> daniels: they can do it only at the session level, and they can't really change the refresh rate
<daniels> mdz: in general, I was extremely skeptical of the ability of the current configuration infrastructure to hold together to hoary
<daniels> mdz: xorgautoconfiguration would be an *excellent* start
<mdz> forgetting about multiple monitors for now, it would be nice if we could just configure the X server to allow all available modes and let the user pick
<daniels> for the general case, we do that
<daniels> the only freak cases are shitty laptop chipsets and amd64 desktops
<daniels> although, to be fair, there is one case we don't handle
<daniels> which is the highest resolution when we've determined n-1 would be best
<daniels> right now X's metric for resolutions is highest -> best
<fabbione> daniels: libfontcache is miscompiled :) it's missing the -DFONTCACHE.. exactly like xfs was
<daniels> so if we put them all in, you'd always get the absolute highest thingo
<daniels> resolution
<daniels> fabbione: okay
<fabbione> daniels: so the missing -DFONTCACHE in xfs seems to me like a consequence to libfontcache being miscompiled
<fabbione> daniels: anyway.. looking more deep into it
<mdz> hmm, I guess my refresh rate widget is not so useful because I lack DDC
<mdz> daniels: we don't have a way to set the default for the server, only for a particular user's session
<mdz> so e.g. the login screen still always gets the default mode, no?
<infinity> Yeah, I whined abou tthis to daniels earlier.
<daniels> fabbione: new package on the way
<daniels> mdz: right
<mdz> infinity: that's a GNOME issue
<fabbione> daniels: wait.. let me finish to check please
<daniels> mdz: xorg configuration is currently hillarious
<infinity> mdz : Oh, I know, it wasn't "in his capacity as X guy", just whining in general. :)
<mdz> daniels: it would be fly if we could add colour depth to that dialog
<daniels> we don't have any runtime configuration infrastructure at all (xrandr is ... it's a start, but not a patch on what we need)
<daniels> mdz: HA HA HA HA
<daniels> mdz: yeah
<daniels> mdz: run-time depth switching doesn't happen
<mdz> obviously we can't switch depth o the fly
<daniels> okay
<mdz> X being the lovable old curmudgeon that it is
<mdz> but to let the user change it would be huge
<daniels> mmm
<mdz> even if they have to reboot
<mdz> ideally we'd like to decouple the "these are the capabilities of your hardware etc." stuff (xorg.conf) from the "my display preferences" stuff
<fabbione> daniels: ok.. i can cofirm that adding -DFONTCACHE to CFLAGS option to libxfont fixes the problem.
<daniels> right
<daniels> that would indeed kick arse
<mdz> and set the latter somewhere other than a crazy config file
<fabbione> daniels: it would be still good to get the fixes in the right order.. like libxfont to set that properly
<fabbione> daniels: xfs doesn't need to be rebuilded
<mdz> if the tool were extended to have some way to set up a default config for gdm...
<mdz> then it wouldn't be too crazy to expect it to be able to pass -depth or whatever too
<daniels> i think we'd perpetually be maintaining that as our hack on top of the gnome applet
<daniels> because then you're tying your gnome session to gdm
<daniels> fabbione: i've already committed the fix to cvs :P
<fabbione> daniels: ok...
<mdz> I don't see why it couldn't go upstream
<mdz> the 
<fabbione> daniels: please take to check if xfs still requires -DFONTCACHE
<fabbione> daniels: and so on...
<daniels> mdz: because it's suddenly wildly incorrect if you don't use gdm
<daniels> fabbione: xfs still requires -DFONTCACHE
<mdz> it could have two tabs, for setting your user settings and the system-wide settings
<mdz> daniels: people who install non-default X display managers can cope
<daniels> mdz: this is not a problem for ubuntu
<daniels> mdz: it's more of a problem for gnome
<fabbione> daniels: ok.. than just upload libxfont with -DFONTCACHE (recheck the B-D because i didn't)
<mdz> there are already other bits of gnome config which assume you're using gdm
<daniels> i've committed the right fix upstream (the AC_DEFINE was wrong), so I'll just push that up
<daniels> mdz: which bits?
<daniels> fabbione: um, I checked the Build-Deps when I uploaded it
<mdz> daniels: administration->login screen setup, e.g.
<daniels> mdz: right, but that's explicitly gdm setup
<daniels> mdz: it's not X setup in general
<mdz> I don't think it's a biggie
<daniels> mdz: i don't think it's not useful -- not in the least -- but I'm not sure it'll work as is
<mdz> if they care, they can hide the widgets if not running under gdm
<daniels> how do we detect that we're managed, aside from RUNNING_UNDER_GDM=True in /etc/environment? :P
<mdz> something like that
<daniels> ow, my head
<mdz> gnome stuff knows that it's runniing under gdm already
<mdz> e.g. the new login, reboot/shutdown, etc.
<mdz> and if they're not, they hide
<mdz> under gdm, logout gives you options; under ltsp, it just logs you out
<fabbione> lamont-away: ping?
<daniels> mdz: hm, okay
<Mithrandir> Riddell: what do you need help for wrt kubuntu/amd64?
<mdz> Mithrandir: he needed help testing the ISOs which have since been released
<Mithrandir> http://cdimage.ubuntu.com/kubuntu/daily/20050908.2/ ?
<fabbione> infinity: i am on #14844 if you are busy...
<doko> are there reasons (besides UVF), that we do not upgrade valgrind to 3.0? in that case I would like to package valgrind3 with a different source package name to have a version for amd64
<Mithrandir> doko: it has been discussed to just sync it, iirc
<Mithrandir> doko: did you see my question about http://err.no/patches/bcel_5.1-4ubuntu2_5.1-4ubuntu3_ftbfs_ant_compiler.diff yesterday?
<doko> Mithrandir: sorry, no, I didn't (had two nicks in use yesterday). will look at it today
<fabbione> mdz: permission to upload iproute (#14844) the patch makes sense and it's trivial to understand
<fabbione> (2 oneliners in 2 files)
<doko> Mithrandir: what was the outcome of the discussion?
<Mithrandir> doko: thanks.
<Mithrandir> doko: I can't remember.
<Mithrandir> doko: iirc, either mdz or Kamion was involved in the discussion.
<mdz> fabbione: yep
<mdz> Mithrandir: that url is not familiar
<fabbione> mdz: thanks
<Mithrandir> mdz: what's the right one, then?
<doko> Mithrandir: the bcel fix looks fine
<mdz> Mithrandir: I'm saying that I don't think I was involved in a discussion about that patch
<doko> mdz: no, the valgrind thing
<Mithrandir> mdz: I didn't imply you were; that was about valgrind.
<Mithrandir> mdz: sorry for the confusion
<Mithrandir> doko: I've also looked a bit at the ecj-bootstrap FTBFS and it seems like gcj has problems with too many input files or something like that?
<mdz> I don't recall a conversation about a new valgrind source either
<Mithrandir> sorry, it was jdub
<Mithrandir> mdz: as well as 18:20 < jdub> mdz: ross burton has asked for a sync of valgrind to more sanely d
<Mithrandir> ebug gnome things that are affecting us, Riddell is checking if the reverse-depe
<Mithrandir> nds works with it, and Mithrandir suggests the amd64 camp will have a debugging
<Mithrandir> orgy if it goes in - your thoughts?
<Mithrandir> thursday a week ago.; TZ is CEST
<mdz> what are the reverse deps?
<Mithrandir> kcachegrind or something like that, iirc
<mdz> new valgrind is ok with me if it doesn't break any packages which depend on it
<Mithrandir> ok, I'll test that, then
<pitti> Good morning
<ajmitch> morning pitti 
<fabbione> hi pitti
<Burgundavia> pitti, is moz going to support the 1.0.x branch of FF or are you going to have put 1.5 in breezy/hoary/warty?
<pitti> Burgundavia: I really hope they support 1.0.x further 
<Burgundavia> pitti, ouch, I don't envy your job
<pitti> I hope that enough vendors have that problem so that moz upstream will see the necessity
<pitti> Hi Kamion 
<doko> Mithrandir: the ecj-bootstrap thing is a regression, I don't know, when it did stop working, I couldn't find anything yet yesterday looking at it.
<Mithrandir> doko: I don't know the gcj source, but all the smoking guns point in that direction.  It should be possible to add a workaround to ecj-bootstrap, but that's really the wrong place to fix it.
<pitti> new hal coming - daniels, infinity, jdub something new for you to play with :-)
<Burgundavia> pitti, 0.5.4?
<pitti> Burgundavia: no, new patches to 0.5.3
<Burgundavia> ah
<pitti> Burgundavia: upstream version freeze :-/
* Burgundavia wants g-p-m 0.2.2
<doko> Mithrandir: yes, and it builds ok on amd64 ...
<doko> ohh, wait that was too quick :-/
<infinity> pitti " Fun.
<infinity> s/"/:/
<Mithrandir> doko: uhm, no?  It fails in the first round of compiles, but gcj doesn't return non-zero when a file fails to compile, so make just continues.
<doko> mdz: is the preview freeze for the pending uploads over?
<infinity> doko : Preview is released, so you do the math. :)
<ondrej> mornin', just quick question.  Is "breezy" in Breezy Badger meant as "windy" or as "jolly"...
<ondrej> ?
<ondrej> or "jovial"?
<infinity> mdz : Can I get a UVF exception for PHP 5.0.5 (bugfix-only release, I can let it cook in sid for a week first, if you prefer)
<Mithrandir> infinity: "bugfix-only" means they've only removed three features, changed behaviour of half a dozen and added a few new libraries to the testsuite?
<infinity> Mithrandir : No, it actually seems to be bugfix-only, this time.
<Mithrandir> infinity: amazing.  Have they taken a rock to the head or something?
<infinity> Mithrandir : I think they're busy doing the real breakage on the PHP 5.1 branch (which is in beta right now), so they're distracted from messing up 5.0.x
<Mithrandir> ah, makes sense
<wickedpuppy> hi guys does anyone knows how is /lib/modules/<kernel> is generated ? by what program ?
<infinity> wickedpuppy : With the exception of the "volatile" modules (which are linked by lrm-manager on boot), everything else is built as part of the stock kernel builds.
<wickedpuppy> but what if the kernel is downloaded and built with genkernel ?? then genkernel builds those modules as well ?
<infinity> If you configure it to build modules, yes.
<infinity> wickedpuppy : These questoins would probably be better in #ubuntu
<wickedpuppy> ah i know ... but i thought you guys are doing dev
<wickedpuppy> thanks
<wickedpuppy> :P
<robitaille> what's the ETA for the official announcement of the next release name?  I just noticed that someone started using it in the bugzilla :)
<pitti> daniels: seeing the new xorg release, may I bitch you about adding the CAN numbers again?
* infinity decides it's the weened, and time to rest up for the hundreds of bug reports he expects to see on Monday.
<infinity> s/weened/weekend/
<dholbach> good morning
<pitti> Hi dholbach, hi seb128  - good morning to the Gnominators
<pitti> Hey enrico 
<dholbach> merci beaucoup pitti - how is it going?
<pitti> fine, got a good night's sleep, as opposed to the previous night
<enrico> hi pitti!
<fabbione> bella enrico
* enrico hugs fabbione
<fabbione> infinity: ping?
<mdke> who has a preview install?
<mdke> can they please see if ubuntu-docs is installed?
<robitaille> mdke,  it seems to be available, but it didn't install by default on my laptop
<mdke> hmm
<HrdwrBoB> I do, but I upgraded
<infinity> fabbione : pong.
<fabbione> infinity: mind if i look around some of the FTBFS bugs?
<fabbione> most of them are assigned to you
<infinity> fabbione : The more, the merrier.
<fabbione> infinity: hehe ok
<infinity> fabbione : I know, Mithrandir's already got free reign on them.
<fabbione> infinity: ok i will coordinate with him
<infinity> fabbione : You may want to co-ordinate with him to make sure you don't duplicate effort, but I'm officially weekending right now, so you won't step on my toes.
<fabbione> infinity: have fun and enjoy
<fabbione> Mithrandir: i am looking at 13684
<Kamion> mdke: ubuntu-docs isn't in any seed
<Mithrandir> fabbione: have fun
<mdke> Kamion, do you know the reason?
<fabbione> Mithrandir: ehehe it looks pretty simple problem.. freetds is buggy :)
<Kamion> mdke: no
<mdke> ok
<mdke> Kamion, can someone fix it?
<Kamion> oh, we used to have ubuntu-quickguide in desktop, and then that got renamed
<Kamion> or removed or superseded or whatever
<Kamion> mdke: fixed
<mdke> awesome thanks
<Mithrandir> fabbione: it's not a simple problem.  It's an API change.
<carlos> seb128, it's a pity I cannot complain about firefox to you... now that the panel does not crash....
* carlos hides
<seb128> :)
<fabbione> Mithrandir: yes i know.. i was just kidding because the freetds maintainer is vorlon :)
<lifeless> moin
<mvo> carlos: for ff just complain to dholbach :p
<dholbach> mvo: wait until i see you next
<carlos> mvo, I know, but that's not so fun ;-)
<dholbach> thank you carlos
<seb128> carlos: come on, dholbach is a fun guy too
<carlos> seb128, I didn't say that he's not fun :-)
<seb128> and he's really looking forward debugging ff
<dholbach> seb128: you're playing with the fire
<carlos> seb128, but I don't want to scare him so early
<pitti> dholbach: beware, mvo has a club^Whockey bat :-)
<mvo> dholbach: the the fire-fox ;)
<mvo> pitti: and experience in melee fighthing^W^Wplaying
* mvo weeps a bit at his buglist
<dholbach> just to be 100% sure - main is open again, right?
<pitti> dholbach: yeah, upload new craaaack
<dholbach> ROCK
<fabbione> Mithrandir: i think the easiest solution for breezy is to drop the freetds support...
<fabbione> Mithrandir: the API change is immense
<Mithrandir> fabbione: yeah, that's a viable course, I think
<mvo> ping ogra 
<infinity> Mithrandir, fabbione : Wait, leave the freetds-related bug to me.  I co-maintain freetds, I should be able to have a look at it.
<WaterSevenUb> Hey guys. "Hibernate the computer" and "Suspend to the computer" are not translatable in gnome-session. 05_translations.diff however contains patches for some languages. Can someone help me out implementing the patch for my language? The patch is very easy but I have some doubts.
<Mithrandir> infinity: it's the libgda2 bug.
<infinity> Mithrandir : Yeah, I see that.
<fabbione> infinity: ok.. it's a bit API change in freetds.. freetds is ok.. libgda2 freetds plugin needs almost a full rewrite
<fabbione> infinity: and you are supposed to be weekending by now
<infinity> fabbione : It's probably not as bad as it looks at first glance.  I'll poke at it, and if I give up, I can dro ptds support (but I'd prefer not to)
<fabbione> ok
<infinity> Yes, I'm weekending.  Watch me weekend.  Woo, woo.
<fabbione> fabbione@cerberus:/usr/src$ rm libgda2* freetds* -rf
<fabbione> fabbione@cerberus:/usr/src$ 
<fabbione> problem solved
<infinity> :)
<mvo> seb128: do you have a idea about #14998? it looks like the gtk icon-theme changed bug, but I wonder how it can happen during the upgrade
<WaterSevenUb> pitti,mvo,seb128?:) 
<pitti> yes?
<seb128> ?
<seb128> use rosetta
<seb128> mvo: why should it no happen during the update? it's trigerred by the icon changes, so by the packages upgrade
<mvo> seb128: I was under the impression it was a new bug in gtk2.7, no?
<WaterSevenUb> seb128, the strings I mentioned are not in the PO file so they can't be translated through rosetta. Under debian/patches in 05_translations.diff however some guys solved the problem, when building, their .PO files include these strings. I want to do the same.
<seb128> mvo: not sure
<seb128> WaterSevenUb: how so? they should be listed by the pot file, lemme have a look on it
<mvo> seb128: that leaves the problem ... how to fix the crash?
<seb128> mvo: you can't ... does it happen a lot?
<mvo> seb128: it seems to be happening on each hoary->breezy upgrade with synaptic *cough*
<seb128> mvo: if the issue if hoary's gtk beeing bugged that would require patching it and doing an hoary-update upload
<seb128> mvo: arg
<mvo> seb128: yeah. pretty anoying :(
<seb128> mvo: why didn't we get any bug about that before?
<mvo> seb128: I have no idea, but doko and silbs reported the crash and I can reproduce it here too
<seb128> mvo: the fix is probably quite small; maybe you can look if it applys on 2.6.n from hoary
<infinity> Even if it does apply, good luck getting all hoary users to update with hoary-updates before they upgrade to breezy. :/
<mvo> infinity: oh yes :/
<sivang> moring all
* infinity thinks it may be time to abstract the higher-level tools one level above where they are right now.
<sivang> cd testing still ongoing?
<infinity> So, for "nontechnical desktop users", we can force "upgrade this package first, before you even attempt any other system upgrades"
<pitti> sivang: preview is released
<hunger> infinity: Yes! There is no problem that can't be solved by adding another layer of abstraction:-)
<Kamion> all problems can be solved by adding an additional level of abstraction
<Kamion> snap
<infinity> (Somewhat akin to Windows Update updating itself before doing anything else)
<sivang> pitti: ah cool, so we can go on with the remaining uploads from before preview freeze ?
<Kamion> sivang: yes, we're back to feature freeze status
<Kamion> sivang: although uploads are still being held for approval for the moment, just in order to give people a chance to have a stable preview archive for a bit
* hunger thinks breezy is getting too boring... stuff keeps getting better, where is the adventure there?
<Kamion> boring == good
<Kamion> (spot the release manager mentality)
<infinity> Kamion : yeah, it's not an idea I feel very good about, but it sure beats telling users they're on their own with broken dist-upgrades, cause they didn't read the release notes first, etc.
<WaterSevenUb> seb128, be right back.
<Kamion> infinity: yeah, I agree with you
<infinity> If we can figure out a way to enforce "release-note-isms" (ie: upgrade this first, do that dance, then do a dist-upgrade), that would rock.
<Kamion> ogra: speaking of freezes, am I to put Edubuntu CDs on releases.ubuntu.com before we unfreeze?
<seb128> carlos: rosetta only has hoary .pot files?
<sivang> Kamion: Where do we hold our release notes? I think we oughta mention that LVM issue that I experienced last night, I'd hate to see unsuspecting desktop users bump into this..:)
<fabbione> wow.. down to 252 Maj bugs from 270 of 4 hours ago
<fabbione> not too bad
<fabbione> sivang: what LVM problem did you see?
<fabbione> sivang: did you open a bug for it?
<infinity> fabbione : No fair, you're cherry-picking all the INVALID imported bugs, aren't you? :)
<fabbione> infinity: i didn't say why the count is going down..
<Kamion> sivang: don't know, doc team should be taking care of that
<sivang> fabbione: not yet, I will go open a bug about it now, unless you want to hear me first and tell me probably that this is not a bug :)
<fabbione> i just said it is going down
<Mithrandir> Kamion: 2419 seems to be fixed?
<sivang> Kamion: k
<mvo> infinity: I guess we would need some dist-upgrade hints file. but there are more practial problems. e.g. for this gtk+ bug it would require to first upgdate libgtk, then restart synaptic/pm-of-choice so that it actually uses the new libgtk and then continue. certainly doable but...
<fabbione> infinity: neither i did say that i did it or who has to be credited ;)
<carlos> seb128, no, it also has breezy
<carlos> seb128, why?
<seb128> carlos: I don't find them
<fabbione> sivang: well open the bug.. and i will look at it
<carlos> seb128, ?
<sivang> fabbione: ok, guess better that way then on IRC.
<seb128> carlos: https://launchpad.net/products/gnome-session has only hoary on the left pane
<seb128> "Template "gnome-session-2.0" in Ubuntu Hoary Hedgehog package "gnome-session""
* sivang pokes bugsie
<seb128> https://launchpad.net/products/gnome-session/+translations
<seb128> "Template "gnome-session-2.0" in Ubuntu Hoary Hedgehog package "gnome-session""
<seb128> 
<seb128> carlos: where are they hidden? :)
<Kamion> Mithrandir: good point, thanks, closed
<carlos> seb128, we promote Hoary vs. breezy
<carlos> seb128, https://launchpad.net/distros/ubuntu/breezy/+sources/gnome-session/+pots/gnome-session-2.0
<carlos> seb128, the main problem is that we don't have yet the publishing information inside launchpad
<fabbione> infinity: but if you prefer i can leave you all these little boring bugs.. :P
<carlos> seb128, the usual path is look for a package at https://launchpad.net/distros/ubuntu/breezy/+sources
<seb128> carlos: where does I find gnome-session-2.0 2.12.0 pot file?
<carlos> seb128, anyway, you also have https://launchpad.net/distros/ubuntu/breezy/+translations
<infinity> mvo : Yeah, that's the sort of thing I was referring to.  So we'd update only gtk/synaptic (and deps), then respawn synaptic.  Or something equally hideous.
<carlos> seb128, upstream one? we don't have it on Rosetta
<infinity> mvo : Not doable now anyway, as the code would never get into hoary, and we woudn't have time to do it for breezy either, but maybe someone could think of some clever hint hooks for breezy+1
<seb128> carlos: no, 5.10 ones
<carlos> seb128, breezy
<carlos> seb128, https://launchpad.net/distros/ubuntu/breezy/+sources/gnome-session/+pots/gnome-session-2.0/+export
<infinity> fabbione : Heh.  I don't care who does the cherry-picking.  Triaging needs to be done, regardless.  Go nuts. :)
<carlos> seb128, select the potemplate
<mvo> infinity: yes, hints would be really good. another ubz topic
<carlos> and you will get it by email
<dholbach> does a CC on bugzilla need to have a bugzilla account?
<seb128> carlos: k, that's a pain to find
<fabbione> infinity: so stop complaining on what i am cherry picking :P
<carlos> seb128, ?
<carlos> seb128, it's a normal 'download' action
<carlos> seb128, anyway, why do you want the .pot file?
<seb128> carlos: https://launchpad.net/products/gnome-session should have both distro on the left pane
<carlos> seb128, usually you get your language's .po file...
<seb128> carlos: I don't care of the pot
<carlos> seb128, dude, same issue raised by jordi yesterday. Ask sabdfl about that...
<seb128> <WaterSevenUb> seb128, the strings I mentioned are not in the PO file so they can't be translated through rosetta. Under debian/patches in 05_translations.diff however some guys solved the problem, when building, their .PO files include these strings. I want to do the same.
<seb128> carlos: that's the issue
<carlos> seb128, that's something you need to talk with Martin then
<seb128> carlos: and I want to check if current po files have the Hibernate string by example
<carlos> seb128, hte .pot file should be updated every time a build is raised
<seb128> carlos: yeah, that's why I search the pot
<seb128> to know if it's correct or not
<carlos> seb128, if rosetta is missing strings means that the .pot is not being regenerated
<seb128> I'm not blaming rosetta, I'm searching for the pot to know it it's correct or not :)
<seb128> graa
<seb128> you can't search for a string from the UI?
<carlos> not yet
<carlos> seb128, we have a spec for that but it's not implemented
<seb128> k
<seb128> and there is no "next" on the bottom of the page
<seb128> man, I'm going to fill some bugs :)
<mvo> silbs: could you please do a "reload" in synaptic and tell me if the "couldn't stat waring" goes away then?
<carlos> seb128, the 'next' thing is a lost subject, we talked about that already and decided to leave it as it's atm.
<seb128> carlos: that sucks :(
<seb128> I translate, go to the bottom
<seb128> then I need to go up again just to go to the next page
<carlos> seb128, people loses translations if they click over it instead of the submit button and the submit button does the same if you don't add translations so...
<carlos> seb128, dude, if you translate.... you need to click over the button....
<carlos> or you lose your translations
<seb128> I don't translate
<carlos> seb128 I translate, go to the bottom
<carlos> seb128 then I need to go up again just to go to the next page
<carlos> seb128, you do
<carlos> :-)
<seb128> I'm looking on all the pages to find Hibernate because there is no search
<jordi> hear, hear :)
<seb128> graa, and it's damn slow to go to the next page
<carlos> seb128, the submit button should work for you, without changes, the button does the same
<seb128> that's not obvious
<jsgotangco> carlos, jordi hi, we're about to test our pot file for the documents we made do we give them to you or upload them to rosetta?
<seb128> and since I don't want to change anything
<seb128> I don't submit anything
<seb128> k, I found the string
<jordi> jsgotangco: add them to wiki.ubuntu.com/RosettaImportQueue
<seb128> WaterSevenUb: rosetta has the strings
<mdke> jsgotangco, it's under control
<carlos> seb128, we choose the less data lose solution... anyway, complain with a bug report, the button label should be changed if it's not good enough
<mvo> seb128: I looked at the gtk+ 2.6 source and I'm pretty sure that's the bug
<mdke> jsgotangco, i spoke to jordi yesterday to arrange it
<seb128> mvo: k
<Mithrandir> seb128: mind if I fix the missing dependency bug in pygtk?
<seb128> carlos: k
<Mithrandir> seb128: http://bugzilla.ubuntu.com/show_bug.cgi?id=13992
<carlos> seb128, also, you need to navigate that way because the lack of the search form
<carlos> seb128, when we add it you will not do that so often
<jsgotangco> ok
<seb128> Mithrandir: not at all
<seb128> carlos: right
<Mithrandir> seb128: great, uploaded. :-P
<seb128> carlos: other point, is there a way to change the "10 strings by page"?
<seb128> Mithrandir: thanks
<carlos> seb128, yes, but not from the web UI
<carlos> seb128, it's an 'advanced' feature
<jdub> yay, i had my first gam_server cpu/memory blowout!
<Mithrandir> seb128: have you seen the window change applet become massively unhappy and eating all the cpu it can find (on only one core, but still)
<seb128> Mithrandir: nop
<Mithrandir> seb128: it's very reproducible here, but I wondered if it was known before I start spending time tracking it down.
<Mithrandir> seb128: ok, I'll see if I can get you a useful backtrace, then
<seb128> no it's not
<seb128> but because it's because of your wm :)
<Kamion> yay, lots more shiny mirrors picking up the preview
* Kamion updates /download/
<Kamion> although mostly European for the moment; the Australian, African, and Canadian mirrors are part-way through
<Mithrandir> elmo: please sync sgml2x
<Kamion> JaneW: 09:41 < Kamion> ogra: speaking of freezes, am I to put Edubuntu CDs on releases.ubuntu.com before we unfreeze?
<pitti> Kamion: hm, are uploads still hand-approved? it almost seems to
<Kamion> pitti: yes
<mdke> silbs, thanks for your documentation bugs
<Kamion> won't stay that way, it's just to get a bit of stability around the preview
<pitti> ah, because of edubuntu, I see
<Kamion> pitti: not really
<Kamion> well, I suppose we might want to do an emergency rebuild of Edubuntu, but I'm going to hurt people if that's the case
<ogra> Kamion, we are allowed to finish first
<Kamion> ogra: as in the ltsp-client-builder stuff?
<Kamion> or just what you had yesterday?
<ogra> Kamion, jup and and edubuntu-artwork :)
<Kamion> ogra: did mdz say the archive was staying frozen until you were done, then?
<pitti> darn, I was already uploading happily - sorry
<pitti> Hi mdz
<Kamion> pitti: it's all held in a queue, don't worry
<Kamion> morning/evening mdz
<mvo> pitti: no problem, it's won't processed
<pitti> Kamion: I know, but it will make things complicated if we need to fix something already uploaded for Edubuntu
<Kamion> yes
<mvo> is there any reason for us to keep the old readahead around and not make readahead-list the new (and only) readahead package?
<WaterSevenUb> seb128, You are right, sorry. When I do apt-get source gnome-session why the .PO files don't trace Rosetta?
* Mithrandir grumbles
<Mithrandir> sound-juicer segfaults
<seb128> WaterSevenUb: "trace"?
<seb128> WaterSevenUb: rosetta import the .po files from the packages and we are going to make language-packs from rosetta
<seb128> but that doesn't work yet
<seb128> carlos: when will rosetta gives language-packs?
<Mithrandir> why is gdb such a POS when it comes to debugging threads?
<WaterSevenUb> seb128, equal..... I am confused by the fact that the original english strings are not the same in the source and in rosetta.
<carlos> seb128, I'm doing final changes to be able to create them
<carlos> seb128, on Monday I think kiko will give to martin a new language pack from Rosetta to test it
<carlos> pitti, btw, should we talk today, I ping you yesterday but seems like you were a bit busy
<seb128> WaterSevenUb: original == upstream? The ubuntu patches have some new strings
<JaneW> Kamion: hi
<JaneW> Kamion: I need ogra to decide that but edubuntu is conspicuous in it's absence from the preview announcments...
<ogra> mvo, pong
<WaterSevenUb> seb128, k, I appreciate your help.
<Kamion> ogra: I've updated debian-cd to fix Edubuntu bootloader configuration on powerpc; your next CD build will have that
<WaterSevenUb> seb128, thx.
<ogra> Kamion, WOW...
<seb128> np
<ogra> Kamion, else we would have dropped ppc...
<Kamion> JaneW: I've cleared it up with ogra, thanks
<Kamion> ogra: can't have that ;)
<ogra> i thought so, thanks a lot :)
<JaneW> Kamion: many thanks :)
<Kamion> pitti: I can always (I think) reject something if absolutely necessary
<Kamion> ogra: do you need ltsp 0.54?
<Kamion> (see breezy-changes, it's in the queue)
<ogra> Kamion, yup
<ogra> it has the necessary changes
<Kamion> mdz: your changelog entry does not tally with the actual diff
<Kamion> mdz: "Restart nfs-kernel-server and dhcp3-server on installation" vs. restarting nfs-kernel-server on removal
<ogra> Kamion, thats my patch
<Kamion> well, I'll approve it and you lot can see whether it works
<Kamion> ogra: why does the changelog disagree with the change?
<ogra> Kamion, it restarts nfs on both and dhcp on install
<sivang> seb128: did you finish with gimp ? can we upload my last bit of lpi (gnome-applets) ?
<Kamion> ogra: that's not what the diff says
<ogra> hmm
<Kamion> +           invoke-rc.d nfs-kernel-server reload
<Kamion> that's all the diff adds
<Kamion> (on postrm remove)
<seb128> sivang: no and no
<ogra> Kamion, there must be a change in postinst too (the more important one...)
<Kamion> I've approved 0.54, you can check for yourself in fifteen minutes when it hits the archive
<ogra> Kamion, any idea why edubuntu-meta's update script still tells me edubuntu-artwork is unavailable ? 
<Kamion> because you didn't wait as long as I told you to wait
<Kamion> 10:11 <Kamion> update -meta again the next time the archive updates (about 30 minutes)
<Kamion> it is now 10:27
<ogra> oops, ok
<ogra> i need a coffee to wake up i think
<Kamion> cron.daily happens at :03 and :33, takes some minutes
<Kamion> we can run it manually in emergencies but I prefer not to :)
<sivang> fabbione: check bug #15017
<Mithrandir> hmm
<Mithrandir> if you set your clock 30 minutes back, the download stats in firefox stops working
<fabbione> Kamion: permission to upload gail to fix 14598. missing one B-D. no other changes
<Kamion> fabbione: seems unlikely Edubuntu will want to upload that, so sure
<HiddenWolf> who owns dh@mailempfang.de ?
<Kamion> HiddenWolf: dholbach
<jsgotangco> that's dholbach 
<fabbione> Kamion: thanks
<HiddenWolf> dholbach, if you upload something that fixes a bug, close it. ;)
<HiddenWolf> Kamion, thanks
<dholbach> HiddenWolf: what are you referring to?
<HiddenWolf> 14823
<dholbach> HiddenWolf: xchat? serpentine? i will wait until they built on all architectures :)
<dholbach> HiddenWolf: but if i forget to close bugs in the future, be sure to remind me ;-p
<HiddenWolf> dholbach, heh, I'm not browsing all bugs just yet. :)
<seb128> dholbach: you should rather close on upload
* dholbach gives HiddenWolf the "Bug Squashers" badge - You've responsibility now. :)
<HiddenWolf> dholbach, *g* Wrong move that, I don't understand the technicalities of 70% of them. ;)
<dholbach> seb128: i don't promise users "it all works", until it really all works :)
<ogra> HiddenWolf, oh, you are our new bugmaster ? 
<seb128> dholbach: if you are sure you'll manage not forget any bug this way, good luck :p
<HiddenWolf> ogra, preferably not, I'm starting my second bachelor year monday. :)
<dholbach> seb128: i'll see how it works :)
<seb128> dholbach: and the bug is actually closed by the upload, if that FTFBS it's an another issue
<sivang> Kamion: so no uploads from now on, or will it be ok again in a couple of days?
<Kamion> sivang: will be OK in a bit
<fabbione> Kamion: i hate you... Mid-air collision detected!
<Kamion> that partman-auto-lvm bug?
<fabbione> yes
<fabbione> ok hold on..
* Kamion sticks his tongue out at fabbione and waggles it
<fabbione> Kamion: i will recommit my comments and answer to your question
<sivang> fabbione: can I help on that one ? :)
<sivang> fabbione: (interested to learn the technicalities invloved.....)
<mjr> a,24
<fabbione> sivang: we might get that thing fixed for breezy+1
<fabbione> but not for breezy
<fabbione> partman-auto-lvm is special
<fabbione> sivang, Kamion: you both got spam^Wmail from bugzilla...
<sivang> fabbione: yay :)
<fabbione> sivang: cool, eh?
<fabbione> isn't it?
<sivang> fabbione: yes, indeed 
<sivang> fabbione: I'd thank my love for LVMs for helping me find this bug, either way we should mention something on the release notes, right?
<dholbach> bdftopcf  will have to be promoted to main,  unifont  and  xfonts-terminus  build-depend on it
<fabbione> sivang: i need to think about it first
<ogra> Kamion, added the missing bit to ltsp and uploaded, can you please wave through if it shows up ?
<fabbione> Kamion: what reference do you have for lilo supporing booting from LVM?
<fabbione> because there is only one entry in CHANGES
<Kamion> grep -i lvm *
<Kamion> ?
<Kamion> loads of stuff in geometry.c
<Kamion> plus I'm fairly sure I did it with a test Ubuntu install ages ago
<fabbione> Kamion: it doesn't support LVM2
<Kamion>    * Added edubuntu-artwork to desktop-amd64, desktop-ia64, desktop-
<Kamion>      sparc, desktop-hppa
<Kamion> ogra: what about powerpc?
<Kamion> fabbione: ah
<fabbione> #define MAJOR_LVM       58 /* Logical Volume Manager block device */
<fabbione> this is coming from 2.4 kernels
<ogra> Kamion, eek...
<fabbione> LVM1...
<fabbione> and LVM2 uses 254
<fabbione> at least that's what i can see here
<ogra> Kamion, the archive seems under heavy load, now i cant even run the update script... only corrupt Packages.bz2 files, sigh
<fabbione> Kamion: there are also some other checks that lilo does and might easily fail
<HiddenWolf> daniels, bug 11161 is still listed as need info, do you need any more?
<fabbione> Kamion: see geo_get( in gemoetry.c
<fabbione> Kamion: so if we want to assume that lilo can boot from lvm, we can reassign the bug to lilo :)
<HiddenWolf> daniels, and i think 8438 can be closed...
<jdub> seb128: can we get gnome-bluetooth 0.6 into breezy, and make sure nautilus-sendto is built against it? the tarball is on f.g.o, not edd's site
<pitti> fabbione: kernel update is out, thank you for preparing it!
<ogra> daniels, around ? 
<fabbione> pitti: no problem.. thanks to you
<seb128> jdub: no
<Kamion> fabbione: or lilo-installer to make it fail on 2.6 or something, don't care either way
* Kamion wows at #15020
<seb128> jdub: it's an universe package and we nautilus-sendto is a main package
<jdub> seb128: only libgnomebt (and source, obviously) will have to go into main
<seb128> jdub: that would require moving gnome-bluetooth, but when I asked to people on charge of that like 2 weeks ago they said it's not ready for that
<jdub> seb128: we don't have to worry about the other functionality
<seb128> jdub: gnome-bluetooth too
<jdub> we can leave it in universe :)
<seb128> so we can't Build-Depends on it
<Lathiat> but nautilus-sendto is in main
<jdub> seb128: we'd build-depend on libgnomebt-dev
<fabbione> ROFTL at 15020
<seb128> jdub: doesn't matter, the source is still gnome-bluetooth
<Kamion> - -- Oliver Grawert <ogra@ubuntu.com>  Fri,  9 Sep 2005 03:58:21 +0200
<Kamion> + -- Oliver Grawert <ogra@localhost>  Fri,  9 Sep 2005 03:52:16 +0200
<Kamion> weird
<Kamion> (edubuntu-meta 0.23's diff to the changelog entry from 0.22)
<pitti> Riddell: is CAN-2005-2097 (the xpdf disc consumption issue) fixed in breezy's kdegraphics?
<seb128> jdub: that would require to move the source package
<Mithrandir> grrrr.
<Mithrandir> dvd-rw doesn't work :/
<ajmitch> iirc gnome-bluetooth is still a bit immature
<jdub> seb128: yes, the source would move into main, i don't think that's a huge problem (particularly given bluetooth goal)
<ogra> Kamion, err...
<jdub> ajmitch: gnome-bluetooth itself, yes
<Kamion> ogra: (do you use debdiff before uploading?)
<seb128> jdub: people working on it have raised objections when I asked a few weeks ago
<seb128> jdub: you will have to make a wiki page and speak with mdz/pitti about it
<jdub> seb128: g-b or the library (which is all n-st needs)?
<seb128> I've no bluetooth stuff here, I'm not going to argue for it without playing with it
<tseng> jdub: every source package.
<ogra> Kamion, nope, but i unset DEBEMAIL to make sure i dont upload broken stuff before looking at the changelog
* jdub knows the problems with g-b
<seb128> jdub: g-b
<seb128> that's a source package
<jdub> tseng: different question :)
* tseng unconfuses
<tseng> ok.
<jdub> seb128: the problems are with g-b itself, not the library (which is also in the package)
<Riddell> pitti: KDE up to 3.4.1, so yes as breezy has 3.4.2
<seb128> jdub: we can't move the lib without moving the source package too, and if we move the source package we have to assure security, quality, etc
<Kamion> ogra: running debdiff is always a good idea
<ogra> oki
<seb128> jdub: if you feel that's not an issue just make a wiki page for it and ping mdz/pitti 
<Kamion> just to make sure you're uploading what you think you're uploading
<pitti> Riddell: ok, thanks
<mjr> (so, how about compiling a universe nautilus-sendto-bluetooth that replaces nautilus-sendto)
<sivang> fabbione: so, it seems lilo should have faild when it just continued?
<seb128> mjr: I would rather get g-b moved if it's ready
<seb128> duplication of same sources to build with different options is not nice
<fabbione> sivang: it seems so.. yes
<mjr> seb128, yah, I'm just assuming it isn't, since there seems to be such opinions around
<seb128> jdub: I'll start by updating g-b to 0.6, let me know if you poke mdz about moving it to main please
<mjr> haven't tried, I probably should though
<sabdfl> seb128: please could you get Terminal and Filebrowser changes in asap, see what the fallout is? thanks
<sabdfl> seb128: also, please could you rename Smeg menu editor to "Desktop Menu Editor"
<sabdfl> and cc mdz, doct team on notice of that
<seb128> sabdfl: sure, I'll do that right now
<sabdfl> thank you
<fabbione> hey sabdfl 
<sabdfl> sorry for the late changes, hopefully we have enough time for translations
<sabdfl> hey fabbione
<seb128> sabdfl: the nautilus entry change has been made 2 days ago
<sabdfl> nautilus entry change?
<seb128> sabdfl: the gt one too, but dholbach accidently reverted it, I'm changing it again
<sabdfl> gotcha
<seb128> sabdfl: filebrowser
<seb128> it's already moved to accessories
<sabdfl> mdke: ping
<dholbach> seb128, sabdfl: sorry for that - just didn't notice it
<sabdfl> dholbach: np
<Kamion> seb128: bug #15011 is for the menu editor change BTW
<seb128> Kamion: thanks
<sivang> ah, good to be back
<sivang> fabbione: and can you tell now if it just ignored my instruction to install on /dev/hda5 and not on the MBR? (it sure seemed so)
<fabbione> sivang: that's something i have no idea about
<fabbione> that's lilo-installer in anycase
<sivang> fabbione: I see ok, well, I'd be interested in helping out on this multiple bugs sprung bug....:-) (I'll go read poke partman-lvm-auto)
<sivang> morning mdz 
<seb128_> sabdfl, Kamion: "Menu Editor" or "Desktop Menu Editor"?
<Keybuk> mdz: yikes, you're up early!
<Keybuk> seb128: "Applications Menu Editor", surely? :p
<Keybuk> we don't have a Desktop menu
<jdub> seb128: just "menu editor"
<seb128_> Keybuk: sabdfl asked for "Desktop Menu Editor" and the bug state "Menu Editor"
<seb128_> jdub: what I thought, but making sure :)
<Kamion> Keybuk: autoreconnecting client I think
<jdub> Keybuk: we do have a desktop menu, but it's not editable ;)
<sivang> lol
<seb128_> jdub: GNOME has one, we do have a System menu
<jdub> yep
<jdub> that's why it makes even less sense
<jdub> seb128_: we have a "desktop" menu, gnome has a "desktop" menu and a "Desktop" menu
<jdub> neither are editable
<jdub> :-)
<seb128_> right :p
<mdke> sabdfl, hi?
<ogra> Kamion, udeb updated, do you want me to upload it to rookery again or do you want to review it in the queue ? 
<Kamion> ogra: upload it to rookery and I'll give it a final check over
<ogra> Kamion, ok
<jdub> seb128: don't make any changes based on my answer, however - you need to talk to sabdfl directly
<seb128> jdub: waiting on his reply to upload, don't worry :)
<ogra> Kamion, i left out the mirror/suite for now, its unlikely that we run this udeb from anywhere else than the install CD ...
<pitti> Hi Keybuk 
<pitti> Keybuk: just replied to your hct mail - ENOCASEYLOGIN
<ogra> Kamion, uploaded for review :)
<Keybuk> yes, I just replied to it
<Kamion> erk, cdebconf's debconf-copydb is trashing translated fields in the target templatedb
<Kamion> no wonder we're having localisation problems
<Kamion> ogra: I wonder why you're bothering with an .orig.tar.gz
<Kamion> ogra: if I were you I'd just call it version 0.1.0 and make it native
<ogra> Kamion, i'm just used to it :)
<Kamion> ogra: hm - bump Priority: to standard please
<Kamion> so that it's used by default if it's on the image
<ogra> Kamion, target is to merge it into ltsp later anyway...
<ogra> ok
<ajmitch> fyi, the MOTU crew are organising a bug day on the 17th, in #ubuntu-bugs
<ajmitch> just a heads up (I'll send a mail out soon)
<ogra> :)
<Kamion> ogra: oh, ltsp-build-client could take a while, couldn't it? how about a progress bar?
<Kamion> (even if that progress bar does have to sit at 0%, it's better than a blank screen)
<ogra> Kamion, i tried, i didnt manage to get it right and the time is short...
<ogra> hmm
<ogra> Kamion, what about doing it right post preview ? 
<Kamion> ogra: add an ltsp-client-builder/progress template, Type: text, _Description: Building LTSP chroot...
<ogra> rather than having a 0% bar
<Kamion> ogra: in debian/postinst, before apt-install ltsp-server, do 'db_progress START 0 2 ltsp-client-builder/progress'
<Kamion> ogra: after the apt-install, do 'db_progress STEP 1'
<Kamion> ogra: after ltsp-build-client, do 'db_progress STEP 1' and 'db_progress STOP'
<Kamion> ogra: that's not ideal, but really a blank screen for that long will make people think the installer's crashed
<fabbione> sivang: partman-auto-lvm needs a good rewrite and better integration with other d-i modules, like partman-auto and lvm
<Kamion> ogra: also, "a LTSP" -> "an LTSP" in ltsp-client-builder.templates
<ogra> ah, i missed the second one ...
<ogra> changes uploaded
<Kamion> ogra: "Type: text", not "Type: text, "
<pitti> elmo: can you please sync postgresql-8.0? it fixes paths of some include files which render some packages FTBFS; no other changes that affect Ubuntu (just mips and m68k fixes)
<\sh> btw...how expensive is beer in Canada?
<ogra> \sh, ;)
<Kamion> ogra: change that and I think it's fine to upload to the archive
* maswan readjusts ftp.acc.umu.se/se.releases.ubuntu.com to stress the whole ftp cluster instead of only two out of four frontends. :)
<ogra> Kamion, ok, thanks...
<\sh> I have to know it ;) because then I do a lot more night work ;) too many people to drink with ;)
<ogra> Kamion, done :)
<maswan> they do 18MByte/s each btw
<ogra> Kamion, any additional action required for edubuntu-meta ? (why do i always type meat first?)
<Kamion> ogra: no, that's fine; please add ltsp-client-builder to the edubuntu installer seed, though
<ogra> oh, yes
<Kamion> ogra: hmm, I guess workstation installs want to preseed ltsp-client-builder/run=false?
<ogra> yup
<ogra> oh, and i need one change to the language stuff in preeseed, how does it behave if a package isnt there ? does it just ignore that ? gcompris-sounds-$LL moved to the archive, i'd like to add it with the other language pack stuff
<ogra> but the number of langs is limited... so many of them would fail
<Kamion> ogra: could you make that post-preview, please? it's a bit complicated
<ogra> Kamion, ok
<Kamion> thanks - requires weird cdimage changes and stuff
<ogra> ok, seed change committed, as soon as it shows up, and if edubuntu-meta 0.34 and the udeb in the archive we can have a testbuild :)
<ogra> oh, ltsp-client-builder hangs in NEW :/
<ogra> indeed
<pitti> lifeless: here?
<lifeless> nope
<lifeless> hes not here
<lifeless> hes inane
<Kamion> ogra: preseed change done
<lifeless> erm.
<lifeless> and insane
<Kamion> ogra: I'm shepherding ltsp-client-builder through NEW, I just got interrupted by a phone call that's all
<ogra> Kamion, thanks, i'll ping if everything has built
<Kamion> it'll hit NEW again for the binaries
<ogra> oh
<Kamion> but that's ok
<ogra> i always thought if you un-NEW the source its enough...
<jbailey> mdz: Yes - I use queries and sort by last-changed-date so that I can easily see which bugs have changed.  It's a bit annoying that bugzilla announces that.
<Kamion> ogra: no, separate override tables
<ogra> ah
<Kamion> NEW just means that an object isn't in the overrides
<lifeless> pitti: pong
<Diziet> `Bugzilla has suffered an internal error.'  Joy
<ogra> Diziet, file a bug :p
<pitti> lifeless: do you still have troubles with your CF card in breezy? (#12526)
<lifeless> pitti: dont know yet, haven't tried breezy. will the livecd tell me ?
<pitti> lifeless: yes, that should work fine
<pitti> lifeless: the handling of removable devices is exactly the same in live and install
<lifeless> ok, let me see if I have a cf on me
<HiddenWolf> pitti, are floppies supposed to automount?
<lifeless> nope
<pitti> HiddenWolf: well, I'm not sure, they might be polled by hal
<lifeless> I'll test when I get home, unless someone here has a cf card
<jbailey> HiddenWolf: On ia32?  I don't think there's an event for floppies in the hardware.
<pitti> HiddenWolf: however, I don't have a floppy in either my desktop nor my server nor my laptop
<pitti> jbailey: hal might poll
<HiddenWolf> pitti, 14778
<jbailey> pitti: *puke*
<HiddenWolf> I've got one, for bios upgrades. :)
<pitti> HiddenWolf: anyway, clicking on the drive mount applet is certainly fine
<jbailey> Hmm.  My alpha has a floppy drive in it. =)
<pitti> for such an ancient method of storing data...
<HiddenWolf> I'm trying to find bugs where I can provide useful information so some of these need info/unconfirmed bugs get fixed.
<ogra> EEK
<ogra> http://lists.ubuntu.com/archives/ubuntu-devel/2005-September/010621.html
<pitti> HiddenWolf: I think #14778 is something different
<HiddenWolf> pitti, yup, but I can't confirm it. My floppy worked fine.
<pitti> HiddenWolf: blkid works fine, I'm still waiting for the lshal output
<pitti> HiddenWolf: however, I will ask him for pmount -v
<HiddenWolf> pitti, I don't suppose my hal and pmount would be useful then?
<pitti> HiddenWolf: if it works for you, then rather not... I followed up
<HiddenWolf> pitti, ok
<pitti> HiddenWolf: if you start hald in debugging mode, does it repeatedly call the floppy probe?
<Lathiat> daniels: is there any chance of that nv overlay bug being fixed? (is it fixed upstream?)
<HiddenWolf> wtf: opening system > administration > printers > "error loading files into library" "home/hidde/.gnome2_private" is a directory. file:///home/hidde/.gnome2_private"
<HiddenWolf> pitti, I've never started hald in debugging mode, afaik.
<pitti> HiddenWolf: wiki.ubuntu.com/DebuggingRemovableDevices, part 2
<HiddenWolf> pitti, with a floppy inserted I suppose?
<HiddenWolf> pitti, doesn't poll at all.
<pitti> HiddenWolf: ok, thanks for checking. it would probably be too ugly anyway
<HiddenWolf> pitti, np
<HiddenWolf> Who is the cups guy?
* pitti whistles
<pitti> I did some fixes in the past
<pitti> HiddenWolf: but your issue looks like "ITZ GTK BUG"
<HiddenWolf> any clue why I get that error message I wrote above?
* pitti blames seb128 
<HiddenWolf> It's new, was messing a lot with a printer that won't do duplex yesterday.
<chmj> dir
<pitti> file
<chmj> oops 
<infinity> 'dir'?
<infinity> Tsk.
<pitti> socket!
<seb128> pitti: I love you too :p
<pitti> seb128: SCNR :-)
<infinity> deltree /y c:\windows
<infinity> Oh man, why do we ship the "dir" binary in Ubuntu?... I'm ashamed.
<chmj> infinity: why ? 
<infinity> (Yes, I know it's just a hardlink to ls, that's not excuse)
<pitti> HiddenWolf: this is gnome-cups-admin, I assume you get the same when calling it from the command line?
<HiddenWolf> pitti, wrong instruction in that wiki page: /etc/init.d/dbus-1 is just dbus in breezy. I'll fix it.
<chmj> I use -> alias dir'ls -al -color' 
<infinity> chmj : Encourages people to not learn UNIX commands? :)
<pitti> HiddenWolf: well, it was dbus-1 for hoary
<HiddenWolf> pitti, haven't tried, i'm far from an expert.
<pitti> HiddenWolf: lemme fix it
<HiddenWolf> pitti, seb128, that error doesn't reproduce now I open g-c-m a second time...
<pitti> HiddenWolf: btw, restarting dbus breaks your desktop session
<pitti> HiddenWolf: reload
<HiddenWolf> pitti, I'll log out.
<HiddenWolf> brb
<ajmitch> pitti: yep, and dbus does allow reloading of the config via dbus-send
<sabdfl> jdub, seb128, mdz: i have one further change to propose
<sabdfl> already discussed with the doc team, they can handle it
<sabdfl> its a double change
<sabdfl> Add/Remove Programs needs to be at the bottom of the Applications menu
<ajmitch> pitti: I got avahi installed & working without dbus restart thanks to Lathiat 
<sabdfl> also, it needs a new name, that won't ExplodeOnTranslationToFrench
<sabdfl> seb128: what is "Add Applications" in French?
<ogra> sabdfl, or german...
<HiddenWolf> pitti, seb128, one time weirdness only, it seems.
<sabdfl> ogra: DasIstVerboten!
<ogra> sabdfl, "Programme hinzuggen/entfernen" is very long
<ogra> *hinzufgen
<sabdfl> drop the entfernen
<sabdfl> seb128: ^?
<Mithrandir> seb128: gdmflexiserver -n looks a bit weird in a multihead setup
* maswan grumbles a bit about se.archive being slow for an upgrade. ;)
<pitti> sabdfl: but users will also want to remove software...
<sabdfl> pitti: less so, and that behaviour is obvious once you've used the tool
<pitti> ogra: btw, you use dhcp3-server? did you recently had any problems with it? it somehow stopped working for me since maybe two weeks ago
<pitti> sabdfl: true
<lamont-away> fabbione: pong
<ogra> pitti, for ltsp it works fine
<sabdfl> Applications -> Add Applications is hugely discoverable
<pitti> ogra: ok, I check it on my end nevertheless
<fabbione> lamont-away: yo.. meh i already did.. it was about that heap corruption in iproute
<maswan> oh. mozilla release too.
<sabdfl> elmo: ping
<lamont-away> fabbione: ah - I have a patch prepared, was waiting for preview to hit - or did you already upload?
<Mithrandir> seb128: http://err.no/tmp/flexiserver-wide.png
<fabbione> lamont-away: i used your patch and uploaded
<lamont-away> fabbione: cool
<jdub> sabdfl: i'd prefer it there (and designed it to be so), but giving it the right name and allowing for translations is a difficult issue
<fabbione> lamont-away: i was going trough all the maj or > today
<fabbione> lamont-away: but the patch is definetely sane..
<lamont-away> fabbione: ok... and you used round 2 of my patch from that bug, yes?
<fabbione> lamont-away: yup.. of course.. i did also check for other calloc calls outside tc/
<ogra> pitti, note that i only use it in ltsp with a *very* simple setup, not for anything else here... 
<pitti> ogra: for me too, I just assign an IP and nameserver to my laptop
<pitti> my house server still runs woody
<seb128> sabdfl: sorry, was focussing on the other chan
<seb128> sabdfl: we did this change and rolled back
<seb128> sabdfl: Add/Remove Applications is too long and ugly ... you want only "Add Applications"?
<pitti> "Software installation"?
<sabdfl> what's the translation for "Add Applications" in French?
<pitti> hm, too generic
<sabdfl> pitti: i want to follow the "Applications" cue from the top
<ogra> pitti, thats synaptic ...
<seb128> sabdfl: Ajouter des applications
<sabdfl> ok, that'll do
<sabdfl> DOIT
<ogra> :)
<seb128> sabdfl: which is fine. Add/Remove Applications would be "Ajouter/Supprimer des applications" which start beeing long and ugly :p
<sabdfl> ok
<seb128> mvo: could you change the menu entry title according to that?
<jdub> all of this will go away when we don't have silly menus anymore :-)
<sabdfl> mvo: it needs to be at the bottom of the Applications menu
<sabdfl> doc team is briefed
<mvo> seb128: yes
<seb128> mvo: I'll update gnome-menus
<sabdfl> jdub: which package contains the About Ubuntu page? The firefox home page?
<mvo> sabdfl: ok
<mvo> seb128: thanks
<jdub> sabdfl: ubuntu-artwork, but the doc guys have theirs in about-ubuntu
<jdub> sabdfl: firefox was being updated to point to / depend on it
<sabdfl> jdub: can you resolve that, please, and get the page updated?
<sabdfl>  - new Ubuntu CSS
<sabdfl>  - not version specific
<jdub> i believe the doc team about-ubuntu stuff is version specific
<Lathiat> pitti: i emailed you about not needing to restart dbus
<pitti> Lathiat: I saw it, thanks
<Lathiat> pitti: so, is there any reason we can't do this in our various packages?
<Lathiat> i plan to add this to avahis postinst
<pitti> Lathiat: of course we should do it where necessary
<pef> hello !
<pitti> Lathiat: however, e. g. notification-daemon does not even need that
<Lathiat> pitti: I think it should be done in anything that installs a system.d config file
<Lathiat> for whatever reason
<Lathiat> notification-daemon does do that
<Lathiat> not sure why
<Lathiat> since it uses the session bus exclusively
<pitti> Lathiat: so we only need to do it in hal, I suppose
<seb128> Mithrandir: http://bugzilla.gnome.org/show_bug.cgi?id=303801
<Lathiat> pitti: and bluez-utils
<Lathiat> theresa lso a bunch of universe packages that could do with it
<Lathiat> i propse to replace their restarts with this command
<Lathiat> would that be a problem
<ajmitch> Lathiat: want to get a list of dbus users so we can fix them?
<pitti> Lathiat: hal doesn't restart itself or dbus any more
<Lathiat> ajmitch: i have a partial list
<ajmitch> great
<Lathiat> pitti: ok, but reloading the config can't hurt
<ajmitch> might as well get them fixed up asap so we can test them
<Lathiat> yeh
<Lathiat> dhcdbd sucks
<ajmitch> heh
<Lathiat> it installs an allow * for everything
<Lathiat> i made a new woen for it
<Lathiat> i wshould send it upstream
<Lathiat> silly redhat
<jdub> seb128: did the system > about ubuntu file location change?
<Mithrandir> daniels: any thoughts on  http://bugzilla.gnome.org/show_bug.cgi?id=303801
<Mithrandir> daniels: I think the suggestion that Xnest do something sensible seems good
<Mithrandir> seb128: thanks
<seb128> np
<Mithrandir> Riddell: how are font fallbacks handled in KDE?
<Mithrandir> Riddell: http://bugzilla.ubuntu.com/show_bug.cgi?id=14690
<seb128> jdub: what package used to ship it?
<seb128> jdub: I guess it has been accidently dropped
<jdub> seb128: whoa, now it's doing yelp ghelp:about-ubuntu
<HiddenWolf> pitti, seb128, at the moment when there is a cd/usbdrive in the pc when you boot, the first thing gnome does is pop up a wndow displaying it's contents. Isn't this wrong? It's hal coming up, not the cd being inserted. The user knows it's there already, no need to pop it in their faces.
<ogra> Kamion, could you have another look at ltsp-client-builder ? there seems to be no build attempt yet
<Riddell> Mithrandir: it's handled by Qt, and should do intelligent things when it can't find the character in the current font
<seb128> jdub: since hoary
<jdub> seb128: one of the panel patches was dropped?
<Mithrandir> Riddell: apparently, it doesn't.
<seb128> jdub: I doubt it, lemme have a look
<pitti> HiddenWolf: hm, that isn't meant to happen, right
<Kamion> ogra: it's built, binaries in NEW, I'll process them
<ogra> ah
<elmo> sabdfl: ?
<sabdfl> Kamion: please could you add ubuntu-doc as a dependency of ubuntu-desktop
<HiddenWolf> pitti, file one on hal then?
<sabdfl> elmo: is there a problem with the mail server?
<ogra> Kamion, then i'm ready to go with a cdimage testbuild :)
<pitti> HiddenWolf: gnome-volume-manager, please
<jdub> sabdfl, Kamion: ubuntu-docs
<HiddenWolf> pitti, right, sorry
<Kamion> sabdfl: I already seeded it earlier today, it'll be added automatically the next time we update ubuntu-meta
<pitti> HiddenWolf: no worries, I can always reassign it
<sabdfl> Kamion: k thanks
<HiddenWolf> pitti, learning here. ;) I mean to help, not to cause work.
<elmo> sabdfl: not that I can see?  several people logged on and I can connect
<Kamion> ogra: please remove ${misc:Depends}, it isn't really appropriate for udebs
<ogra> oki
<pitti> HiddenWolf: oh, good bug reports are always helpful :-)
<seb128> jdub: the menu entry is placed if DATADIR"/gnome/help/about-ubuntu/C/about-ubuntu.xml" exists
<sabdfl> elmo: imaps is not working from here
<jdub> seb128: yeah, which no longer exists
<seb128> jdub: somebody changed this file (location)
<elmo> sabdfl: are you still using the port 8001 hack?
<jdub> seb128: /usr/share/doc/ubuntu-docs/HTML/en/about-ubuntu/C/index.html
<seb128> jdub: which one should be used?
<HiddenWolf> pitti, that's why I browse bugzilla to learn and improve/help by providing info. ;)
<jdub> at least for now
<elmo> sabdfl: if so, please undo that, and try again
<seb128> jdub: that sucks
<seb128> jdub: that's a regression
<fabbione> sabdfl: works fine from here
<pitti> HiddenWolf: right, many bug reports are poor and cannot be reproduced, or lack necessary info
<sabdfl> e
<seb128> jdub: there is no way to translate it like that ...
<jdub> seb128: those might change again - perhaps wait for the next ubuntu-docs release
<jdub> seb128: i know, that's one of the sucky things about going with html
<seb128> jdub: we had translations for hoary
<seb128> jdub: we do we have this regression?
<sabdfl> elmo: no joy, on 993 or 8001
<HiddenWolf> pitti, Give me a list of those, and I'll happily work down them Bugzilla search isn't that useful, and plain unfriendly.
<seb128> s/we/why/
<ogra> Kamion, do you need a new upload now for that ?
<pitti> HiddenWolf: search for bugs tagged "NEEDINFO"
<jdub> seb128: because the doc team want to ship html, not docbook
<seb128> that's not going to work
<HiddenWolf> pitti, won't work.
<Kamion> ogra: I think it will probably be OK anyway, but yes please, just in case
<pitti> HiddenWolf: oh, NEEDINFO and open
<ogra> done
<seb128> pitti: I've the issue with CD automounted on login and opening a nautilus window if you want to debug it with me
<HiddenWolf> pitti, still getting unconfirmed bugs too, then.
<HiddenWolf> seb128, want me to file a bug still?
<Mithrandir> Riddell: can you reproduce the problem?
<HiddenWolf> pitti, seb128: Bug 15028
<Kamion> Mithrandir: problem with that debconf-copydb change you made a few weeks back
<pitti> HiddenWolf: thanks
<pitti> seb128: that bug is for me
<Kamion> Mithrandir: cdebconf doesn't understand non-UTF-8-encoded translations in the templatedb, so when you save the (debconf-generated) templatedb, it wipes out all the translations
<HiddenWolf> pitti, greedy one! ;)
<Kamion> Mithrandir: (not sure why all rather than just nearly all, since there *are* one or two UTF-8-encoded translations in there - but never mind)
<pitti> HiddenWolf: g-v-m is my toy, and only mine! :)
<HiddenWolf> pitti, haha
<HiddenWolf> pitti, seriously, searching for "NEEDINFO" open nets me 200 bugs, most assigned, unconfirmed, barely any on NEED
<jbailey> Kamion: How much love do you think cdebconf would take to actually make it usable?
<jbailey> I guess split between coding / politics. =)
<Kamion> Mithrandir: I've changed debconf-copydb again to only save the templatedb if something changed, which should make the problem crop up a bit less often at least, and I think for now we just have to ensure that the target templatedb always has the copied template
<Kamion> jbailey: not particularly politics, just lots of work. not willing to commit to a particular number
<Mithrandir> Kamion: hmm..  I thought it didn't really copy the translations at all?
<Riddell> Mithrandir: yes
<jbailey> Kamion: Do you have a not-less-than guess?
<Kamion> Mithrandir: it certainly ought to at least try, since it's just loading and saving the templatedb and cdebconf handles translations in its own templatedb just fine
<pitti> HiddenWolf: WFM - https://bugzilla.ubuntu.com/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=NEEDINFO&emailtype1=exact&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdty
<pitti> pe=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=
<pitti> oops
<pitti> sorry
<Kamion> jbailey: wouldn't like to do it inside three months
<Mithrandir> Kamion: ok, it's probably just getting annoyed at non-UTF8, then.
<jbailey> Kamion: 'kay.
<Mithrandir> Kamion: iirc, cdebconf is fairly utf8-centric
<Kamion> Mithrandir: it definitely skips non-UTF-8 templates entirely
<HiddenWolf> pitti, thanks, I just found edit search. :)
<pitti> HiddenWolf: I just selected "NEEDINFO" in the "status" filter
<Kamion> Mithrandir: I'm thinking of making it at least store non-UTF-8 templates so that it can load/save them cleanly, even if it does nothing with them itself
<Mithrandir> Kamion: I guess converting all templates to utf8 is a bit too much work?
<Kamion> Mithrandir: don't really want to have to have all the iconv tables available
<Mithrandir> Kamion: dh_installdebconf could make sure DEBIAN/templates is in utf8.
<Kamion> Mithrandir: we can start moving to that now I think (it's a po-debconf thing and there was a woody->sarge transition issue involved), but even so ...
<Mithrandir> Kamion: I think making cdebconf barf at non-utf8 templates would make sense, but it should probably be discussed upstream
<Kamion> no, the problem here is that it mangles all translations in the *debconf* templates.dat in the base system
<Kamion> so we'd have to convert all packages there before it would start working, and this is causing a breezy-critical issue
<Mithrandir> yup.
<Kamion> (loss of translations in timezone/apt configuration)
<Kamion> so, pain :)
<Mithrandir> Kamion: which is why I didn't suggest to do it _now_.
<Kamion> :)
<Kamion> fair enough
<Mithrandir> you want me to hack in support for loading and storing non-utf8 templates?
<Mithrandir> and just treating them as blobs?
<Kamion> if you could, that'd be fantastic
<Mithrandir> sure
<Mithrandir> better than trying to debug Qt font fallback problems in Polish. :-P
<Kamion> I think my r30448 should be enough to let me work around the issue for noe
<Kamion> now
<mvo> sabdfl: gnome-app-install changed and uploaded
<Kamion> except that if somebody typos a preseed variable name, it might all come crashing down
<Kamion> jbailey: the other problem with the cdebconf transition is that it's kind of all or nothing
<Kamion> jbailey: we have to be very, very confident before switching
<Mithrandir> Kamion: I think cdebconf should grow a test suite
<Kamion> definitely
<Kamion> it's got one you can drive by hand, but not a proper automated one
<jbailey> Kamion: Right - I was more trying to decide if the target was something I should either hack on or shut up about. =)
<Kamion> Mithrandir: of course, we should be getting proper udebs of tzsetup and apt-setup and stuff in dapper, so we can lose this particular hack
<ogra> oh, secret name leaking ? 
<ogra> :)
<Kamion> I don't even know if that name's final yet; it's just a handy working name
<Mithrandir> Kamion: sure, but we use it for live as well
<Kamion> yeah
<Mithrandir> Kamion: and I don't think we want a xorg to begin creating udebs..
<Mithrandir> not even "config-live-xsession"-style udebs
<pitti> ogra: I hope it will change, "depper" sounds soo ugly at least in my ears.. - like the German "Depp"
<ogra> yep
<pitti> ogra: but I heard it from different sides already...
<ogra> me too
<Kamion> it's *a* not *e*
<Mithrandir> pitti: dapper, not depper
<mpt> Mithrandir: https://bugzilla.mozilla.org/show_bug.cgi?id=94091
<pitti> right, same thing though
<ogra> but there is no difference in prononcation between the two in german
<Kamion> Mithrandir: adding a debian-installer/keymap template to xserver-xorg.templates would be sufficient to work around this bug there
<pitti> ogra: let's see what the second name is :-)
<ogra> yup
<ogra> donkey would be cool.... but its bad marketing wise :)
<desrt> so.. if i get 2 emails about UBZ sponsorship i should ignore the first one? :)
<Kamion> Mithrandir: and arguably correct anyway
<pitti> ogra: it's not a hog...
<pitti> well, badger isn't either
<ogra> desrt, nope, you have to show up twice then ;)
<desrt> ogra; one of them was a rejection :P
<ogra> oh ...
<desrt> (exactly one of them)
<Mithrandir> mpt: not the same, but similar.  I had my time set back, which meant the progress meters just stopped.
<\sh> desrt: ask claire ;)
<Mithrandir> Kamion: I'd argue; .debs shouldn't use the debian-installer/* namespace
<ogra> desrt, i'd mail back and ask which one i should take serious
<Kamion> Mithrandir: base-config does
<Mithrandir> Kamion: but it's a clean workaround.
<Diziet> Cripes, the Flash player licence is evil.
<ajmitch> desrt: hopefully that means you're going
<Mithrandir> Kamion: base-config is thpetul
<Kamion> Mithrandir: and remember xserver-xorg is already looking at debian-installer/keymap
<jbailey> Diziet: Catching up on your /.? =)
<Kamion> Mithrandir: it's perfectly legitimate for it to have the template for it as well, I think
<desrt> ajmitch; i think i was going to go either way
<Diziet> No, trying to fix mozilla bugs.  Why, are they discussing it on /. ?
<jbailey> Someone claimed that the flash license prohibited you from installing it on a laptop.
<Kamion> Mithrandir: and true, base-config is rather special in this regard ...
<Diziet> I'm one of those weirdos who actually reads things before signing (or, in this case, clicking ok).
<jbailey> Made front page for some reason.
<ajmitch> jbailey: because it specifically mentioned desktop? 
<jbailey> ajmitch: I don't remember.  I see the headlines on my google home page and didn't read further than the first line.
<teprrr> hmm, how soon breezy will be out? just thinking will libgl/dri/gl stuff be usable by then?
<Kamion> teprrr: http://wiki.ubuntu.com/BreezyReleaseSchedule
<Mithrandir> Kamion: and, isn't b-c going away at some point anyway? :-)
<Mithrandir> Kamion: looking at != having the template itself, imo
<Kamion> Mithrandir: theoretically yeah ...
<Mithrandir> Kamion: anyway, I think we're mostly in agreement and there are more pressing issues, so
<Kamion> that's some way in the future though, even in the best of all possible worlds :)
<infinity> teprrr : It'll be fine.
<pef> does gnome2.12 will be integrated into breezy before the release ?
<Kamion> pef: it already has been.
<teprrr> infinity, hmm..
<Diziet> 14:00:50.722839 IP (tos 0x0, ttl  64, id 62596, offset 0, flags [DF] , proto: TCP (6), length: 60) 172.18.45.41.59448 > 192.168.0.201.443: S, cksum 0x2efc (correct), 2089739431:2089739431(0) win 5840 <mss 1460,sackOK,timestamp 8723421 0,nop,wscale 2> ???
<pef> Kamion: wow, you are fast !
<Kamion> pef: see the ubuntu-announce mailing list
<pef> ok
<HiddenWolf> pef, 2.11.9X has been in for a while, it was just a minor update to get 2.12 in. ;)
<ivoks> hi
<Diziet> Why is Firefox (or the plugin installer) trying to connect somewhere random in RFC1918 space ?
<Diziet> I blame NAT.
<HiddenWolf> seb128_, I've got a problem with device icons on the desktop showing in the wrong place. Half off the screen, for instance. Known?
<seb128_> HiddenWolf: yep, known
* HiddenWolf interested
<HiddenWolf> browing gnome
<seb128_> HiddenWolf: is that with nautilus 2.12? they fixed some placement issues
<HiddenWolf> Yes it is.
<HiddenWolf> seb128_, http://bugzilla.gnome.org/show_bug.cgi?id=45953
<HiddenWolf> partial patch, but not "lazy-icon aware" so not commited, it seems.
<HiddenWolf> seb128_, actually, patch that should work in a 23-aug-05 mail, but nothing followed up.
<seb128_> the bug you pointed is not the bug you described
<HiddenWolf> seb128_,isn't it?
<seb128_> no
<seb128_> the bug you pointed is device icons going on top of other icons
<HiddenWolf> Hm. right you are.
<HiddenWolf> Can't find the wrong placement then.
<seb128_> HiddenWolf: http://bugzilla.gnome.org/show_bug.cgi?id=159621 by example, but this one is fixed now
<HiddenWolf> seb128_, want a screenshot?
<seb128_> HiddenWolf: no, I know the issue
<seb128_> that's the same as on this bug
<seb128_> but for the desktop
<HiddenWolf> seb128_, and it's the desktop, not nautilus. ;)
<seb128_> the desktop is nautilus
<HiddenWolf> right.
<HiddenWolf> so nautilus can look decent? ;)
<seb128_> jamesh: ping?
<Diziet> In fact, the reason why plugin downloading isn't working is because mozilla.org is giving out duff redirects.  Haven't they noticed ???
<HiddenWolf> Diziet, moz.org has bigger problems. ;)
<Diziet> Oh, Am I missing some news ?
<ogra> Kamion, did you unqueue 0.1.0-2 ? 
<Kamion> ogra: oh, drat, no, sorry - done now
<ogra> thanks :)
<pitti> bah, get-source takes ages...
<pitti> Good morning lamont
<Mithrandir> Kamion: humm, it appears cdebconf explicitly doesn't allow you to set foo-$LANGCODE.nonutf-8 fields.
<Mithrandir> Kamion: so the loading probably fails, and when it's then written out again all the non-utf8 fields are dropped.
<Kamion> right ...
<dholbach> we're on LWN: http://lwn.net/Articles/150971/ - just a brief mention, but even so :)
<Kamion> I think they're ignored on load
<Mithrandir> Kamion: well, load does a t->lset
<teprrr> preview without working  opengl support, huh?
<teprrr> or has it been fixed?
<Kamion> Mithrandir: yeah, and lset skips non-UTF-8 fields
<teprrr> hmm, doesn't seem to work
<lamont> morning pitti
<lamont> pitti: you going to Oldenburg?
<pitti> lamont: no, I have a long-standing family event at that time; joeyh and I agreed to an IRC meeting instead
<lamont> ah, ok.  /me is going
<lamont> need to book travel today
<jbailey> lamont: To Oldenburg?
<lamont> ya
<jbailey> lamont: For d-i, obscure hardware, or the Java DevJam?
<lamont> http://wiki.debian.net/?OldenburgSecuritySummit
<Mithrandir> Kamion: humm, humm, so it should probably allow people to lset non-utf8 fields, then?  Or just add a "force" parameter to lset?
<bddebian> Howdy
<jbailey> Insane.  Ther'es *more* going on there?
<jbailey> It was crazy last year as it was.
<jbailey> I had a great time, though.
<Kamion> Mithrandir: I was thinking the former
<Mithrandir> Kamion: I'm trying to think of what, if anything, will break.
<Mithrandir> Kamion: if the templates are ever printed, they might fuck the display totally
<Kamion> cdebconf would definitely have to ensure never to *use* non-UTF-8 templates
* lamont wonders how long a train from hamburg to oldenburg take
<lamont> s
<ogra> lamont thats not this far... 
<ogra> lamont, if it doesnt stop in any 4 house village, it should be around an hour
<lamont> heh
<lamont> jbailey: they're also working on non-i386 ports :-)
<jbailey> lamont: YEah, that's how the whole thing started.  Obscure hardware hacking session.
<jbailey> lamont: At this rate it's growing so much, joey will never be allowed to graduate.
<lamont> hehe
<lamont> ogra: cost estimate (WAG acceptable)
<lamont> ?
<ogra> hmm, 50 or less i think
<ogra> for one direction
<ogra> (cologne - frankfurt costs 58 it will be a bit less)
<mdke> sabdfl, i can't apply that patch >_<
<mdke> sabdfl, problem seems to be that the version number you worked from is not the latest one in my svn tree
<mdke> sabdfl, just send me the whole file and I'll insert it?
<sabdfl> mdke: sent
<mdke> sabdfl, ty
<mdke> sabdfl, uploaded
<sabdfl> mdke: thanks muchly
<spacey> canonical has an office somewhere?
<mdke> spacey, yes
<ogra> spacey, yes, one at freenode and a real one :)
<spacey> hehe ;)
<jdub> spacey: most of our offices are at our homes, but there is one in london, too. :-)
<jdub> ogra: how many steps away from your office are you?
<ogra> 0 ?
<jdub> haha, not now ;)
<spacey> canonical does internship kind of things? 
<ogra> still only between 0 and 20 normally depends if i move out to the garden :)
<anyw> hi
<anyw> Is there anyone who has participed at the google summer of code here ?
<anyw> breezy bounties
<spacey> sabdfl, ? :D
<mvo> spacey: it's easy to participate, help with bugs, become a motu etc
<HiddenWolf> mvo, make me a motu! ;)
<spacey> mvo, i would have to be able to convince my school that they give me study points for it
<mvo> HiddenWolf: you aren't one already?
<HiddenWolf> mvo, no. My coding skills are currently limited to "hello world" in 3 languages. 
<HiddenWolf> mvo, looking to change that tho.
<mvo> spacey: it sounds like it's worth a try, working on open-source is certainly a good way to get experience in international coding projects
<pitti> HiddenWolf: is python amongst the 3? :-)
<mvo> HiddenWolf: well, if python is among them, that's a start :)
<HiddenWolf> pitti, mvo: you're in luck. :)
<pitti> HiddenWolf: we have a small python project called "launchpad". Just fix all of its bugs and we give you 1.000 study points
* pitti hides
<spacey> mvo, thats why i ask :) but it think i need some agreement with for example canonical towards school
<pitti> erm sorry - s/Hiddenwolf/spacey/
<spacey> pitti, problem is i don't know python. not that i mind learning it.
<pitti> spacey: just kidding :-) 
<spacey> :p
<anyw> Has anyone won an award?
<mvo> spacey: I think that can be arranged, how big does your project has to be?
<spacey> 1000 study points would be quite convienant? :p lots more then i can get with my whole study ;p
<HiddenWolf> pitti, now name me a real small cute python project, and I'd be interested.
<spacey> mvo almost 2 months
<mvo> spacey: what language/topic? can you work on existing projects or will it need to be a new one?
<HiddenWolf> pitti, and don't bribe me with pionts. I'd have a hard time to convince the Rotterdam School of Management that Linux even exists. ;)
<ogra> damned, Kamion, ping
<ajmitch> HiddenWolf: so help out the MOTUs, get fame & glory instead ;)
<pitti> HiddenWolf: bribe them with a box of 100 Ubuntu CDs then 
<ajmitch> you don't need points when you have the prestige of being a MOTU
<HiddenWolf> pitti, I'd gladly put CD boxes outside of all major auditoriums, but I doubt it'd be appreciated. :)
<HiddenWolf> ajmitch, motu doesn't pay rent, does it? ;)
<anyw> please, I just want to know if anyone has won an award?
<maswan> btw, working on offloading se.releases, it is getting silly slow now.
<mvo> HiddenWolf: think of it as a long-term investment ;)
<ajmitch> HiddenWolf: forget about such mundane things :)
<mvo> anyw: what kind of award?
<pitti> anyw: award about what?
<HiddenWolf> ajmitch, I hate going hungry, sorry. :)
<maswan> just takes a bit of time, since I need to update from se.archive. :)
<ajmitch> HiddenWolf: so do I..
<spacey> mvo, i have to talk with school about that, i guess it could be an existing one. For myself I would want to get to know ubuntu in and out in those two months, and get experience giving support and master packaging.
<Kamion> ogra: ?
<pitti> anyw: you mean got a bounty? yes, kronoss has, but he is not online ATM
<HiddenWolf> mvo, I do. Just need to get some place to start. I don't work well on long-term goals. :)
<ogra> Kamion, i just saw that i forgot schooltool, its in anastacia since a week waiting for main approval...
<ogra> Kamion, could you process it ? its approved and everything since a while
<dholbach> ha, new gnome-phone-manager - bluetooth fun :)
<ajmitch> dholbach: oh great, I'll have to try it :)
<Kamion> ogra: https://wiki.ubuntu.com/UbuntuMainInclusionQueue lists several Edubuntu items; is schooltool the only preview-critical one?
<anyw> pitti, ok, how long he has worked for it ? on which project ?
<pitti> anyw: #ubuntu, please
<mitsuhiko> hi gys: http://releases.ubuntu.com/5.10/ <== all i get is 403 :(
<ogra> Kamion, its not preview *critical* but its approved and everything i got in now i dont have to beg for later...
<ogra> Kamion, i'd like to have it in...
<ogra> Kamion, all the other stuff in the queue are "needs work" items or listed falsely (i.e. mediawiki should be rejected)
<Kamion> ok, give me a few minutes until cron.daily finishes
<ogra> Kamion, ta i'll fix the seeds
<spacey> mvo i just mailed my school if they would allow such a thing. guess i have to wait for response.
<Kamion> elmo: uh ... how did schooltool manage to end up without any source overrides?
<Kamion> cjwatson@jackass:~$ sudo -u katie katie/teri -s breezy -c main -t schooltool
<Kamion> E: schooltool doesn't exist in overrides for breezy.
<Kamion> ogra: btw the longer this takes this afternoon, the less likely it is to get released today - I did a marathon yesterday, I don't want to do another one today
<ogra> Kamion, only this piece... then we can directly start the cdbuild
<Kamion> don't you need to modify edubuntu-meta again to get schooltool in?
<Kamion> and by the way you don't need to comment stuff out of the server seed pending main inclusion - the update script will automatically exclude things not in main, now that it's been fixed not to look at universe
<Mithrandir> Kamion: do you think anybody would be massively unhappy if I just ran indent over cdebconf?
<pitti> ogra: do you need any main approvals?
<ogra> pitti, nope
<ogra> pitti, thanks
<ogra> Kamion, yes, i need to modify edubuntu-meta again :/
<Kamion> Mithrandir: if you could pick a coding style that produces minimal diffs ...
<Mithrandir> Kamion: well, pick one, pick any.  It's a massive gob of coding styles already.
<Mithrandir> Kamion: I was talking about in svn, really.
<Kamion> yeah, I know
<Kamion> and there are active committers (*cough*attilio*cough*) who wouldn't recognise a consistent coding style if it hit them in the face, and who are actively committing stuff that's all over the place
<Kamion> Mithrandir: mail -boot to make sure nobody has any outstanding major patches they want to merge first?
<Mithrandir> Kamion: yeah, I should catch up my massive chunk of unread mails there too, I guess.
<Mithrandir> Kamion: anyway, it's weekend for me now; I'll see what I can do over the weekend
<Kamion> ok, cool
<Diziet> I guess we're not likely to be out of freeze today ?
<Kamion> Diziet: not in the sense that uploads will be processed automatically; but feel free to upload things if you don't mind them sitting in a queue for a bit
<Kamion> ogra: if this isn't preview-critical, I'd rather we proceeded with CD builds without it
<Diziet> Oh, good.
<Kamion> ogra: otherwise I foresee a substantial part of my evening being eaten up by this
<Diziet> I'll send the new mozilla this afternoon, then.
<ogra> Kamion, ok... should i change the seeds back ? 
<Nafallo> maswan: ping
<Kamion> ogra: for now, yes please
<Diziet> I want to get something out there with the textarea crash fixed before I start digging for more nontrivial bugs.
<Kamion> I've done the main promotion, so you can reapply that right after release
<ogra> Kamion, ok
<ogra> Kamion, so if the seedchange is up you could pull the trigger :)
<Kamion> ogra: when you commit it ...
<ogra> sorry, my net hung a bit
<ogra> its committed now
<maswan> Nafallo: pong
<Kamion> ogra: OK, CD builds running
<Nafallo> maswan: is there something wrong with se.releases...
<Nafallo> ?
<maswan> Nafallo: you mean, there used to be something wrong?
<Nafallo> maswan: people complain to me that it's down ;-)
<Nafallo> maswan: it's awfully slow here :-). have you fixed it already?
<maswan> Nafallo: one of the frontends rebooted, took the filesystem down a while with it. now the fs is up again, even if the one node might not have booted properly yet, most of it works.
<Nafallo> maswan: oki, thanx :-)
<maswan> Nafallo: We're working on getting a fixed gigE driver, we're currently running it on one to see if that one won't reboot as often.
<Nafallo> maswan: yay! :-)
<ogra> Kamion, thanks! :)
<dholbach> Mithrandir: 14951 was assigned to you - unifont build-depends on  bdttopcf  which now is in a separate package (in universe) - i write the main inclusion report for it, ok?
<Kamion> dholbach: that used to be in xutils (in hoary main) so I'll just promote it under obviousness rules
<dholbach> Kamion: oh thank you - that's less painful for me :)
<pitti> dholbach, Kamion: quick security and package check is fine
<dholbach> pitti: thank you
<elmo> kamion: because source is assumed from binary if it doesn't exist
<seb128> Lathiat: ping?
<Lathiat> seb128: pong
<Kamion> elmo: oh, so moving binary then source caused problems?
<seb128> Lathiat: what is debian/patches/01_gnome-ui-appbar-fix.patch from gnome-bluetooth for?
<Lathiat> seb128: if i recall, the appbar type didnt exist or someting
<elmo> can do, teri's override handling is pretty retarded
<Lathiat> seb128: and as such it didnt work/run at all
<elmo> ^-- kamion: 
<jdub> http://www.tectonic.co.za/viewr.php?id=595
<jdub> ^ :-) :-)
<Lathiat> seb128: iirc python no longer wrapped it or something.. or i couldnt find it at the time
<Lathiat> seb128: i totally forgot i ever made that
<Kamion> elmo: ok, fixed (echo schooltool universe/misc | natalie -t dsc -c universe --add; teri -c main -t schooltool - seemed to work)
<seb128> Lathiat: k, thanks .. upstream made some changes but not the same as you, so I was wondering
<slomo> elmo: did ipod-sharp and libipoddevice arrive in NEW yesterday? i don't know because the maintainer address isn't mine (and isn't even whitelisted for katie) but the one from the debian mono group
<Lathiat> seb128: ok, feel free to nuke it
<seb128> Lathiat: we can probably go with upstream fix so
<Lathiat> seb128: as long as it works
<seb128> Lathiat: thanks
<Lathiat> where was that patch?
<Lathiat> in debian or ubuntu?
<seb128> yeah, was just not sure if you made that for cosmetic reason 
<seb128> Lathiat: Ubuntu
<Kamion> jdub: rock
<Lathiat> seb128: does the new bluetooth manager do anything yet?
<Lathiat> seb128: if you need some testing i have a bluetooth laptop & phone, feel free to throw my way
<Kamion> Mithrandir: (oh yeah, bdftopcf promoted)
<dholbach> Lathiat: uploaded a new gnome-phone-manager some minutes ago :)
<Lathiat> dholbach: cool
<dholbach> and it didnt build GNA
<seb128> Lathiat: dunno, I don't have bluetooth stuff .. jdub asked for an update to gnome-bluetooth 0.6, doing it now
<torkel> jdub: we want/need HP _servers_ with Ubuntu, it's to hard to building laptop clusters :-)
<jdub> torkel: soon, soon ;)
<jdub> seb128: i'll happily test (we'll need a nautilus-sendto respin too)
<ogra> torkel, whats wrong with laptop clusters :)
* Lathiat finds a photo
<ogra> torkel, they even briong their own ups per node ;)
<seb128> jdub: are you going to make a wiki page for g-b to main?
<mdke> elmo, have you got a spare minute to make rob^ an svn commit account?
<seb128> jdub: or the lib binary package
<jdub> seb128: hrm, after testing, yeah
<seb128> jdub: cool, thanks
<torkel> ogra: you can't access the bios remotely :-)
<ogra> torkel, hmm, true :)
<torkel> ogra: and you don't need the monitor :-)
<mdke> elmo, correction, give him his old password (he lost it)
<ogra> torkel, as well as the keyboard or touchpad :)
<Lathiat> http://bur.st/~lathiat/dsc02668.jpg <- lots of laptops being used as servers, theyre even HP :)
<torkel> jdub: you never get back to us about kerbers/afs/...?
<Lathiat> dont mind the windows one thats prominent, the rest ran debian or ubuntu :)
<ogra> torkel, we have ocfs2 support in the kernel now ;)
<jdub> torkel: hmm - sent request for info some time before my last trip
<torkel> ogra: ocfs2 is not a // filesystem :-P
<torkel> jdub: you did?
<torkel> ogra: we want lustre...
<maswan> torkel: or something else that is fast and doesn't dpeend on a SAN.
<maswan> well, fast and stable, I guess. :)
<jdub> torkel: i think june; don't have mail archives here, will fetch on monday
<torkel> jdub: I think maswan sent you some info
<jdub> earlier than that i htink
<torkel> anyway... it is weekend now
<jdub> torkel: clusterfs were not very responsive, btw
<jdub> torkel: think we'll hve more leverage now though
<jdub> maswan: do you like gfs?
<maswan> yeah, I think I answered your questions. let me know if there is something unanswered I missed
<maswan> jdub: gfs is aimed towards failover/redundancy when you have a san. not very close to our situation.
<jdub> yeah
* maswan hacks madly to get a redirect host working and logging and giving bandwidth graphs. :)
<Nafallo> maswan: rock on! :-)
* mvo is away for a bit
<Riddell> pitti: do you know why hal depends on python-launchpad-integration?
<ogra> Riddell, hal-device-manager should...
<Nafallo> Riddell, ogra: don't you guys read breezy-changes? ;-)
<pitti> Riddell, ogra: latest hal doesn't any more
<pitti> it's just still stuck in the queue
<pitti> blame mvo :-)
<ogra> Nafallo, i'm concentrated on edubuntu today :)
<Nafallo> ogra: :-)
<Riddell> pitti: ah hah
<ogra> Kamion, cdimages done, report is empty :) now cross your fingers that the installer changes work :)
<ogra> rsyncing ...
<seb128> jdub: hum. evolution changed its menu entry? I'm not sure, but it used to open on the groupware no?
<jdub> seb128: the panel one? hrm, not too sure it matters
<jdub> seb128: unless i'm misunderstanding you
<seb128> jdub: the panel one ... we made an evolution-mail.desktop for a reason
<seb128> jdub: but currently the upstream entry opens evolution with the previous mode .. not sure if that was the case before
<jdub> pretty sure it was
<jdub> we made the evolution-mail one for the 'internet' menu
<seb128> yeah
<jdub> so it was more obvious that it did email
<seb128> but why do we keep the other one?
<jdub> because it makes sense in that menu too ;)
<seb128> shouldn't this one be a -c calendar or something?
<jdub> hrm, no, it's good that it loads whatever the user was previously using
<ogra> Kamion, ltsp-update-sshkeys is missing from the preseed file :/
* Mithrandir ruffles Simira 
<Nafallo> seb128: have time to help me figure out what goes wrong with the mail-hotkey? :-)
<Simira> ruffruff
<seb128> Nafallo: not really
<maswan> http://farbror.acc.umu.se/stats/monitordata/index.shtml
<Nafallo> seb128: oki, ping me when you do :-)
<seb128> Nafallo: I've a lot of bugs on my list, and this one requires some code debug probably ...
<maswan> the test0 host is starting to pick up (getting redirects for i386-install only for now)
<Nafallo> seb128: yepp, I'll try to remember to use the panelicon then :-)
<seb128> Nafallo: thanks
<Kamion> ogra: oh, damnit, sorry
<Kamion> ogra: where should that go? in base-config/late_command?
<ogra> Kamion, i'll test the current one
<ogra> yup
<ogra> Kamion, if the current one is ok and the command is in the next, i think we're fine...
<Kamion> ogra: which architecture would you prefer me to test first? it will take a little while to rsync
<ogra> i can only test i386 here, pick what you like :)
<Kamion> I'll take powerpc then
<ogra> Kamion, but clear wording from mdz was i386 is the only essential bit... 
<Kamion> fine
<ogra> the others are nice to haves :)
<ogra> our announcement refers to that ...
<Kamion> ogra: late_command updated, rebuilding
<ogra> (and i dont want to eat more of your time than necessary, you already saved my ass )
<mdz> ogra: what I said was that powerpc wasn't critical for preview
<mdz> it's almost nonexistent in educational deployments from what I have heard
<ogra> mdz, yes, sorry, wrong wording
<mdz> amd64 is important
<Kamion> argh
* Kamion cancels rsync, restarts
<Kamion> although I do want to test powerpc due to the bootloader changes I did today which should make it work
<jbailey> mdz: I'm surprised.  Apple used to cut some great deals for schools.
<ogra> mdz, there are some imacs i heard... a WS install should be there at least
<mdz> jbailey: on 68k hardware...;-)
* jbailey backs away slowly.
<pitti> Morning mdz
<ogra> mdz, amd64 thin clients ? 
<seb128> <teuf> dpkg: error processing /var/cache/apt/archives/linux-kernel-headers_2.6.11.2-0ubuntu11_i386.deb (--unpack):
<jbailey> I said nothing, you heard nothing, drop the thought from your mind....
<seb128> <teuf>  trying to overwrite `/usr/include/asm/bootsetup.h', which is also in package amd64-libs-dev
<seb128> is that a known issue?
<mdz> ogra: amd64 servers
<seb128> upgrade from a hoary (maybe with some changes) to current
<seb128> hi mdz
<pitti> seb128: it's universe anyway
<ogra> mdz, yes, but the client environment will be built for the same arch by default?
<Kamion> well, the yaboot.conf on current powerpc images looks OK at least
<mdz> morning all
<ogra> morning mdz 
<ogra> heh
<seb128> mdz: is that ok to update gnumeric? They have rolled 1.5.90 and 1.6.0 is planned for next week? Bug fixes versions and we already have 1.5.n, so better to go with 1.6.0
<dholbach> morning mdz
<bddebian> Heya mdz
<jsgotangco> he dholbach
<mdz> seb128: to 1.5.90 or 1.6.0?
<mdz> ogra: i386 thin clients with an amd64 server is a very important configuration that everyone tells us they want
<mdz> ogra: therefore edubuntu needs to work on amd64
<seb128> mdz: 1.5.3 to 1.5.90 now, and 1.5.90 to 1.6.0 next week
<seb128> mdz: 1.5.90 is the candidate for 1.6.0
<ogra> mdz, yes, but you'll have to set up the chroot manually then 
<ogra> mdz, so its not the super duper fully automatic install anymore...
<mdz> ogra: ...
<ogra> writing CD ...
<mdz> ogra: can you see the difference between "a manual step is required to set up the chroot" and "amd64 doesn't work"L
<mdz> ?
<ogra> mdz, sure...
<mdz> ok
<mdz> it needs to install
<mdz> and we should provide documentation for the extra step required to set up for i386 thin clients
<ogra> yup
<ogra> we have a draft of the cookbook already, i'll add a section for that
* ogra sighs about the slowness of his CD writer
<jsgotangco> i thought you always burn slower
<ogra> i burn at 8x, but the writer operates at 4x obviously...
<ogra> it shows 4.2 currently
* lamont wonders what the process is for doing bug-fix uploads now that preview is out...
<bddebian> elmo rocks
<xTina> *sigh* I seem to be unable to completely turn off partman and all partitioning-related stuff in a breezy installation through a udeb exclude file in combination with a custom udeb that "provides" made-filesystems, mounted-partitions, partitioned-harddrives and created-fstab :(
<eruin> did the fglrx fixes make it intime for preview?
<eruin> ah, pendingupload
<eruin> nm
<slomo> hi... is there any good reason why lftp and gftp are compiled without ssl support? see https://bugzilla.ubuntu.com/show_bug.cgi?id=12671 for example...
<Nafallo> slomo: licenseissues AFAIK
<Kamion> slomo: probably licensing, last I heard lftp was GPL with no licensing exception and didn't support gnutls, and openssl's licence is GPL-incompatible
<Kamion> as in, explicitly so
<slomo> huh... ok... didn't know that :/ so maybe something to bug upstream about?
<Kamion> I suspect they've heard
<Kamion> http://www.mail-archive.com/lftp@uniyar.ac.ru/msg02022.html
<slomo> ok, thanks :)
<Kamion> dunno about gftp
<maswan> "3.2.0 is out and GNU TLS support is there" <- from that same thread
<Nafallo> Kamion: same last time I bugged the debian maintainer about it ;-)
<mdz> lamont: the process is "be careful and ask mdz if you are uncertain"
<slomo> Kamion:  yes we have lftp 3.2.1... which could be compiled against gnutls... is this something we could get in breezy? lftp is main
<Kamion> ogra: hmm, I get a bogus netcfg/get_ipaddress template displayed
<Kamion> slomo: don't know
<slomo> Kamion: who is to be asked for that? i can prepare a debdiff and everything ;)
<Kamion> slomo: file a bug or something?
<lamont> mdz: OK.  I just noticed that fabbione's upload for iproute, as well as a potential sync of blender are pending...
<lamont> actually, fabbione's upload sent mail to -changes, but the bits aren't on archive.u.c yet
<slomo> Kamion: there already is a bug... #12671
<ogra> Kamion, hmm, strange i just had this step here, was working right
<Kamion> ogra: can we take out those netcfg preseeds you had me add? I don't have time to figure out why I'm getting the debian-installer/dummy template displayed for them right now, and those preseeds are non-critical
<mdz> lamont: uploads were approval-only during the critical time around preview
<ogra> Kamion, hmm, but they work on i386... hard to decide...
<Kamion> there is a substantial amount of lightning around here and my lights are flickering; if I go offline, I've probably lost either power or ADSL
<lamont> ISTR he did it after preview (but before I woke up after-preview and was going to do it..)
<lamont> anyway, must go pester people - back in a bit
<Kamion> ogra: also the default answer to the gateway question is bogus because of a known netcfg bug when you preseed *.1
<Kamion> for the IP address
<mdz> lamont: "around" preview included a bit after.  it's flowing again now
<ogra> Kamion, can you take it out on amd64 only ? 
<Kamion> ogra: not easily
<ogra> hm
<Kamion> ogra: and you will hit said netcfg bug on i386 too
<Kamion> the default gateway is set to "192.168.0."
<ogra> the gw, yes...
<Kamion> I'm strongly inclined to be conservative and remove them, and figure out the problem after preview
<ogra> Kamion, installing will be more complicated, but ok...
<Kamion> the results I am seeing here are not particularly user-friendly
<Kamion> and surely 192.168.0.1 will not be compatible with many deployers' existing network layouts anyway
<ogra> Kamion, standalone.... 
<Kamion> this is the server install
<ogra> Kamion, thats why i made this change in the beginning...
<Kamion> so instead of going to the network admin and saying "what address should I enter?", they will see an address pre-filled and say "oh, I guess that's OK" and hit Enter; then they will have to figure out how to undo the damage later
<Kamion> surely?
<ogra> Kamion, take it out for now, i'll add a section to the installation notes with te default values
<lamont> mdz: thanks
<Kamion> ogra: done, rebuilding
<ogra> Kamion, thanks... 
<pitti> dholbach: hey, you packaged libpgtcl? rock
<ogra> meh
<MasterC> where do I get develpment support?
<MasterC> +o
<dholbach> pitti: ?
<dholbach> pitti: you must have misread :)
<ogra> Kamion, the udeb seems not to work :(
<pitti> dholbach: oh, indeed -- sorry
<Kamion> ogra: can you check whether /cdrom is actually mounted in the chroot?
<ogra> it is, checked already
<Kamion> hm, it's claiming ltsp-client-builder/run doesn't exist
<ogra> strange, its in the templates
<Kamion> ogra: oh, I see
<ogra> whats wrong ? 
<ogra> i dont see it
<Kamion> ogra: you have to be careful about trailing whitespace at the ends of lines
<ogra> oh no !
<Kamion> ogra: you have a line between ltsp-client-builder/run and debian-installer/ltsp-client-builder/title that consists of just a single space
<Kamion> I think that causes cdebconf to treat the two as one template
<Diziet> Almost as bad as email headers.
<ogra> hmm, for me there is no space...
<Kamion> ogra: I'll upload the fix if you like
<ogra> yup
<Kamion> since my editor is clean about that sort of thing
<ogra> i cant even se a space here, its a single line, vim beeps even if i try to move anywhere...
<Kamion> ogra: try 'a' on that line
<Kamion> you'll see the cursor move right one space
<ogra> yup
<Kamion> now Escape, and try 'a' on the other blank line
<ogra> i see
<ogra> odd
<ivoks> hi
<Kamion> ogra: uploaded
<ogra> thanks
<Kamion> ok, hacked around it for now
<Kamion> we should get a PROGRESS INFO in there at some point, otherwise it looks a bit bare, but it'll do for the moment
<Kamion> and ultimately there's really no reason we couldn't use debootstrap progress reporting
<ogra> yup
<ogra> thats what i wanted to do initially...
<Kamion> yeah, takes time to get that right though
<ogra> yup
<Kamion> you'd probably want to depend on base-installer (which you're doing already) and use its templates for that
<ogra> i'll look into it... after my nerves are usable again :)
<Kamion> whoa, I was sitting on tty3 watching /var/log/messages, and the main d-i screen just flicked over onto it
<ogra> oh, that shouldt happen, right ? 
<Kamion> something must have managed to signal init from inside two chroots or something
<Kamion> or fiddled with udev
<ogra> as i said, they chroots are stacked :) 
<ogra> the even
<\sh> argl.
<Kamion> stacking chroots makes little difference to anything
<Kamion> you know, I can't help feeling that with so little visible progress, telling users to run a command after the install would actually be friendlier
<Kamion> oh, and it breaks because X has to ask a question and you aren't doing the required passthrough magic to make that work
<Kamion> so it's now stalled
<ogra> :(
<Kamion> that will happen on all amd64 and some i386
<ogra> x shouldnt ask questions
<Kamion> it does if it can't figure out the resolution itself, which happens on all amd64 and some i386
<Kamion> you may never have seen it, but it's been that way since warty
<ogra> it doesnt even need to be configured :/
<Kamion> er, you're installing it
<ogra> thats done by the client bootup script on the fly
<Kamion> huh?
<Kamion> test -z "$EARLY_PACKAGES" && EARLY_PACKAGES="x-window-system-core ltsp-client discover1 laptop-detect mdetect xresprobe"
<ogra> yup
<Kamion> they are installed by ltsp-build-client
<Kamion> that's a very strange set of things to install anyway!
<ogra> for the bootup process of the client....
<Kamion> discover1 laptop-detect mdetect xresprobe should be installed before x-window-system-core, not alongside it
<ogra> Kamion, its mdz's set and it works fine
<Kamion> ogra: no, it really doesn't
<Kamion> mdz: ?
<mdz> hmm?
<ogra> mdz, ltsp-build-client
<mdz> hmm?
<seb128> mdz: so about gnumeric? of for updates?
<Kamion> mdz: installing x-window-system-core along with all the other stuff that needs to be installed during xserver-xorg's preconfiguration isn't going to work
<mdz> seb128: gnumeric should be ok; no reverse deps, right_
<Kamion> mdz: and installing xserver-xorg in the first stage isn't safe without a lot more code
<mdz> Kamion: it does
<xTina> Kamion: I think I just ran into a weird problem. Could you think of any reason why a breezy installation would run base-config/late_command twice?!?
<pirroH> hello, someone uses apt-listbugs && ubuntu graphical updater?
<Kamion> xTina: not now, sorry
* xTina almost killed a whole NFS server, luckily the test machine wasn't the one with write access
<ogra> Kamion, it works if you run it manually on the console, it also works if i do it in the installer manually from tty2
<seb128> mdz: no, there is libgsf/goffice to update as well, but they are gnumeric part moved to libs and not used by other stuff for the moment (same situation as previous update) and nothing else affected 
<Kamion> ogra: we cannot fix this today
<mdz> seb128: those are deps, not reverse deps, right_
<ogra> Kamion, damned...
<seb128> mdz: correct
<seb128> mdz: no rdepends
<mdz> Kamion: what's the issue
<Kamion> mdz: xserver-xorg.config tries to use discover for autodetection, so it needs to be installed first for it to work optimally
<Kamion> mdz: I'm wondering why ltsp-build-client needs to install x-window-system-core at all
<mdz> seb128: ok, please watch it carefully and make sure it isn't uninstallable for a significant amount of time
<Kamion> mdz: we could avoid a lot of problems if it did not do so
<mdz> Kamion: the X server configuration in the chroot is incidental; it isn't used for anything
<mdz> Kamion: in fact I think it's rm -f'd later, or if not, it should be
<seb128> mdz: sure, thanks
<mdz> Kamion: all that matters is that it is noninteractive
<mdz> Kamion: the real config is generated at client boot
<Kamion> mdz: as it stands, installing x-window-system-core means that we have to go through all the passthrough rigmarole in order to make this work on amd64
<\sh> anyone familiar with python-launchpad-integration?
<Kamion> mdz: because xserver-xorg always asks a question there
<mdz> Kamion: it installs with the noninteractive frontend
<mdz> DEBIAN_FRONTEND=noninteractive
<mdz> export DEBIAN_FRONTEND
<Kamion> mdz: well it's sitting here hung in xserver-common.config
<mdz> Kamion: then something else is wrong; what's it doing?
<ogra> mdz, chroot /target /usr/sbin/ltsp-build-client --mirror file:///cdrom >> /var/log/messages
<Kamion> it's hung in read(), I can't tell otherwise
<mdz> Kamion: read on which fd?
<ogra> mdz, before this command the udeb installs ltsp-server
<Kamion> process tree is apt-get -y install x-window-system-core ltsp-client discover1 mdetect xresprobe -> dpkg-preconfigure --apt -> xserver-common.config
<Kamion> mdz: 0
<mdz> Kamion: I agree about the lack of progress
<mdz> it should either dump its messages to the console, or be run by hand
<ogra> mdz, we can add it until final...
<mdz> ogra: add what before final?
<ogra> the missing progress stuff in the udeb
<mdz> no, we won't
<mdz> Kamion: does it work if you give it /dev/null as stdin?
<ogra> Kamion, so is there a way to show the console output then ? 
<Kamion> ogra: nothing else in d-i does that, I'm not convinced it will work with the terminal in the state it's in once bterm and cdebconf-newt are running on it
<mdz> ogra: I said yesterday that using the cdrom is wrong, and it should be using the debs copied by archive-copier; did you fix that?
<Kamion> mdz: I'm going to have to reboot to tell
<mdz> Kamion: it certainly doesn't read from stdin when I run it
<ogra> mdz, how ? should i generate Packages and Release files ? thats not right imho
<Kamion> mdz: I'll get a DEBCONF_DEBUG=developer log
<mdz> ogra: ejecting the CD and then telling the user to put it back in is unacceptable
<ogra> mdz, yes, thus the udeb solution
<Kamion> mdz: that was the point of doing this first-stage thing
<Kamion> before the CD is ejected
<mdz> ergh
<mdz> that's suboptimal, but better than what I thought you were doing
<Kamion> I think it's the correct approach, long-term anyway
<mdz> oh, so this is running under cdebconf-with-debconf-confmodule, not plain debconf
<mdz> as in casper
<ogra> i think mdz's approach is better, but i have no idea how to solve it without generating the needed archive files
<ogra> it'll be much faster to install from HD
<mdz> ogra: the same way that "apt-get install ssh" works
<mdz> without asking for the CD
<Kamion> oh, crap, I bet it needs 'unset DEBIAN_HAS_FRONTEND' and stuff
<mdz> Kamion: yes
<mdz> it'll be trying to start a new frontend in the chroot
<ogra> mdz, but it requires a mirror (and being online), doesnt it ? 
<mdz> ogra: install ubuntu and then sudo apt-get install ssh
* Kamion hacks that in
<ogra> mdz, i know what happens... 
<mdz> ogra: it installs from the cache.  you have never done this_
<Kamion> mdz: other way round, the problem is that it's *failing* to start the noninteractive frontend in the chroot
<mdz> ogra: apparently not, if you think it requires being online
<Kamion> and is trying to talk to the main frontend, ignoring DEBIAN_FRONTEND=noninteractive
<ogra> mdz, ltsp-build-client runs an apt-get update, doesnt it ? 
<mdz> ogra: yes
<mdz> so does d-i
<ogra> hmm, so i should supress it if in installer mode and copy over the d-i generates sources.list
<Kamion> no?
<ogra> what else ? 
<Kamion> I'm trying the various env -u bits now
<Kamion> same as base-config/casper do
<mdz> ogra: forgot to baz add ltsp-server-standalone.postinst
<mdz> I
<mdz> didn't notice you were creating a new file
<mdz> ogra: please please please make branches instead of sending patches
<ogra> its in now, i hope it doesnt cause confusion in yur tree
<\sh> nice...gajim has launchpad integration ,-)
<ogra> mdz, i'll do... let me survive this CD first ...
<Kamion> ok, that's working
<mdz> ogra: I already fixed it in my tree.  I'm talking about in the future.
<ogra> mdz, promised
<ogra> Kamion, hero !
<Kamion> ogra: may I upload this?
<Kamion> -chroot /target /usr/sbin/ltsp-build-client --mirror file:///cdrom >> /var/log/messages
<Kamion> +env -u DEBIAN_HAS_FRONTEND -u DEBIAN_FRONTEND \
<Kamion> +       -u DEBCONF_REDIR -u DEBCONF_OLD_FD_BASE \
<Kamion> +       chroot /target /usr/sbin/ltsp-build-client --mirror file:///cdrom \
<Kamion> +       >> /var/log/messages 2>&1
<ogra> Kamion, what a question, if it works :)
<mdz>  /var/log/messages is the wrong place for that output
<Kamion> mdz: it's where other similar output in the installer goes.
<Kamion> so for consistency's sake, I beg to differ
<mdz> oh, that's outside of the chroot
<Kamion> yes
<mdz> never mind
<Kamion> ideally it'd all go to syslog eventually so that we only have one file to inspect when stuff goes wrong, but anyway
<Kamion> ok, uploaded, install is at apt configuration
<Kamion> second-stage question from dhcp-server
<ogra> yup
<Kamion> and two largely pointless notes
<xTina> Hm. Base-config seems to be run twice. Weird.
<bddebian> elmo: ping
<linuxsbartley> Breezy loaded.  Boot gets most of the way in and hangs at: Starting periodic command scheduler.....mon...rface daemon...
<linuxsbartley> press enter and I get login
<linuxsbartley> oops.  meant press alt-f1 and get login
<linuxsbartley> alt-f8 shows this message as last entry.
<linuxsbartley> only error showing is the t_kernel_font one.
<Kamion> xTina: note that late_command is just evaled directly, not (yet) in a subshell or anything
<Kamion> xTina: so if you fiddle with the environment, or cd without cding back at the end, or whatever, you'll confuse base-config
<Kamion> that was just fixed in Debian today
<mdz> Kamion: do server installs install usplash now?
<Kamion> mdz: yes, mistakenly
<Kamion> mdz: I'll do something about that next week
<mdz> Kamion: that's linuxsbartley's problem, I expect
<mae> I know this is kind of O/T but do you guys know if that new ipod nano uses flash memory or the micro drives?
<xTina> Kamion: Was that different in hoary?
<Kamion> xTina: don't believe so, no
<xTina> Kamion: Hm. Weird. I believe that if I'm cd'ing I always remember the owd and go back. But I'll check again, just to make sure.
<Kamion> mdz: I'm running out of time I can dedicate to shepherding Edubuntu builds this evening, because Kirsten is ill and I need to do things around the house for her; can you take over any CD builds that are needed?
<Kamion> mdz: SMS me when it's ready to publish and I can do that
<Kamion> ltsp-client-builder 0.1.0-4 should be OK I think
<Kamion> modulo poor progress reporting
<seb128> dholbach: ping?
<Kamion> OK, successful Edubuntu/amd64 install, but I haven't yet tested its LTSP functioning
<dholbach> seb128: pong
<Kamion> and for that matter I only have one amd64 box
<seb128> dholbach: do you use ldap? :)
<dholbach> seb128: i tried to use it, but failed miserably
<dholbach> and not just once :)
<seb128> dholbach: k, so this gdm bug is not for you neither :p
<dholbach> sorry
<Kamion> ogra: you need to update the homepage in edubuntu-artwork to talk about 5.10 and Breezy, not 5.04 and Hoary
<dholbach> seb128: maybe some of the sun upstream guys know
<Kamion> ogra: (both title and header)
<ogra> Kamion, yup
<seb128> dholbach: I've forwarded it :)
<ogra> Kamion, i didnt expect to have the artwork in already...
<seb128> dholbach: no pb, don't worry
<mdz> Kamion: yep
<mdz> ogra: say when
<ogra> mdz, ok...
<ogra> as soon as the new udeb is there
<mdz> mjg59_: as a safeguard, we ought to have something at the end of the boot process which kills usplash
<mdz> mjg59_: in the event that the user decides to remove gdm or such (or gets usplash installed unexpectedly, as in current server installs)
<mjg59_> mdz: Ok, that's easy enough
<Diziet> My new firefox packages have a package mozilla-firefox which exists to cause the installation of firefox during upgrades.  Does anything need to be done to get that .deb included in the main distribution ?
<Diziet> (not having to upload giant binaries)++
<dholbach> good bye
<mdz> jbailey: did "Starting Ubuntu..." go missing in the initrd->initramfs transition?
<mdz> jbailey: we ought to say something there, since there is a noticeable delay before usplash starts
<mdz> it can be quite long on systems with SCSI especially
<sladen> it was originally just an 'echo' statement in the first line of the initrd that said ''starting initrd-tools 1.2.3''
<jbailey> mdz: Yes, it's not in there because it wasn't trivially brandable.  Is lsb_release -i branded for kubuntu/edubuntu?
<mdz> sladen: until Warty, when it said "Starting Ubuntu..."
* sladen knows :)
<mdz> jbailey: something neutral is fine
<carstenh> .oO(Starting...)
<jbailey> "
<mdz> starting up, loading, please wait, etc.
<mdz> I'll
<sladen> jbailey: could you fish it out from lsb_release when he initramfs is rebuilt---it's being rebuilt for usplash to be installed anyway
<ogra> mdz, the udeb is in the archive, you can pull the trigger
<mdz> do the same with casper
<jbailey> sladen: That's what I wsa thinking.  But if it's not branded there, then there's no point.
* sladen thinks mdz's   Loading, please wait...   would be fine for the moment
<jbailey> Also, I think the idea is to get usplash starting very soon there, so it might not matter much at that point.
<Keybuk> I'd suggest "Starting, please wait ..." as people might be confused by "Loading"
<Keybuk> it's a bit of an 80s term
<mdz> ogra: building
<ogra> mdz, thanks :)
<Keybuk> LOAD ""
<mdz> jbailey: it'll matter for breezy
<jbailey> mdz: I mean, there's not much point in branding it, if usplash will start soon after.  The usplash graphic should be enough to customise.
<mdz> jbailey: agreed
<mdz> "Loading, please wait..." seems reasonable.
<doko> mdz, elmo: please promote libmythes0 to main, needed for the next OOo2 build
<mdz> doko: please only ask one of us, so that we don't both try to do it
<mdz> doko: done
<tvo> anyone knows how to set up a sid pbuilder chroot in breezy?
<doko> mdz: ok, if you have time, the gcc-3.4/gcc-4.0 documentation can be promoted as well, including gnat-4.0, gnat-3.4, libgnat-4.0, libgnat-3.4. can we still target plone in main for breezy?
<ogra> tvo, wiki.ubuntu.com/PbuilderHowto
<tvo> ogra: I followed that and setup a hoary and breezy succesfully, but the sid one fails..
<mdz> doko: wait for anastacia to get manageable again (elmo is working on it) before seeding plone, so that we can easily see what it pulls in and verify the  reports
<mdz> doko: if the documentation is already seeded, it will be promoted by the normal process
<mdz> if it isn't seeded, seed it
<doko> it already is.
<mdz> hmm, my anastacia cron job is broken
<mdz> elmo: IOError: [Errno 2]  No such file or directory: '/srv/ftp.no-name-yet.com/sync/germinate/output//all_edubuntu_breezy_i386'
<elmo> sorry, I ran cron.sync by hand
<elmo> I guess it raced with your cron job 
<mdz> ah, ok
<mdz> I thought it might have been broken since moving to the new box or something
<mdz> doko: http://people.ubuntu.com/~mdz/anastacia.txt
<spayne> will Mono be updated to 1.1.9
<mdz> jbailey: casper uploaded with "Loading, please wait..."
<slomo> spayne: not for breezy
<spayne> oh bollox
<jbailey> mdz: Cool.  Do you want this change uploaded now by itself, or with other changes when the lockdown is over?
<mdz> jbailey: it's already over
<jbailey> 'k
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with breezy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://www.ubuntulinux.org/wiki/DeveloperResources | https://wiki.ubuntu.com//HelpingWithBugs | MOM/NDA producing bad diffs | Breezy preview is out: http://lists.ubuntu.com/archives/ubuntu-announce/2005-September/000031.html | Uploads are flowing again, subject to FeatureFreeze criteria
<mdz> Keybuk: is that MOM item in the topic still accurate?
<Keybuk> mdz: yes, sadly
<Keybuk> once we're down to less than 1-in-10 being fucked, then I'll remove it
<Keybuk> that'll probably happen once dapper starts up
<Keybuk> though that's going to be slightly painful :-/
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with breezy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://www.ubuntulinux.org/wiki/DeveloperResources | https://wiki.ubuntu.com//HelpingWithBugs | MOM/NDA producing bad diffs | Breezy preview is out: http://lists.ubuntu.com/archives/ubuntu-announce/2005-September/000031.html | Uploads to main are flowing again, subject to FeatureFreeze cr
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with breezy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://www.ubuntulinux.org/wiki/DeveloperResources | https://wiki.ubuntu.com//HelpingWithBugs | MOM/NDA producing bad diffs | Breezy preview is out: http://lists.ubuntu.com/archives/ubuntu-announce/2005-September/000031.html | Uploads to main are flowing again, subject to FeatureFreeze
<mdz> Keybuk: a pity, because it's too long
* ..[topic/#ubuntu-devel:Keybuk] : Ubuntu Development (not support, even with breezy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://www.ubuntulinux.org/wiki/DeveloperResources | https://wiki.ubuntu.com//HelpingWithBugs | MOM/NDA producing bad diffs | Breezy preview is out: http://xrl.us/hh4u | Uploads to main are flowing again, subject to FeatureFreeze
<slomo> elmo: thanks :)
<bddebian> slomo: ?
<bddebian> slomo: Ahh.. :-)
<bddebian> Yeah thanks elmo, you kick arse! 
<mdz> Diziet: let's talk about your pending dpkg changes the next time we're both around
<mdz> Diziet: or send me email
<Kamion> Diziet: To get mozilla-firefox in main, it's enough to add it to the supported seed; see http://wiki.ubuntu.com/SeedManagement
<Lathiat> Kamion: is this to make it a virtual package to install firefox?
<Kamion> Lathiat: "virtual package" has a specific technical meaning which is different, but I know what you mean, and yes
<Kamion> ogra: have you started syncing the new CD build?
<Lathiat> Kamion: so while were here, can you explain the different?
<Lathiat> *difference
<ogra> Kamion, already installing
<Kamion> Lathiat: a virtual package is one mentioned in a real package's Provides field
<Kamion> (a real package is a .deb)
<Lathiat> ah right
<Lathiat> whats the name for packages that just install toher thigns etc?
<Kamion> Lathiat: there are two more fine-grained distinctions: "mixed virtual", i.e. one that's both mentioned in Provides and is a real package, and "pure virtual", one which is only mentioned in Provides
<Kamion> Lathiat: dummy package or transitional package (in the mozilla-firefox case above, where you're transitioning from one name to another name and the packaging system needs a bit of help)
<Kamion> Lathiat: or metapackage, if it's something like x-window-system-core or ubuntu-desktop
<Lathiat> Kamion: ah ok thanks
<ogra> Kamion, i'm in base-config :-D
<ivoks> i have one question for wich i need advisory
<ivoks> in universe is package ssh-krb5, wich provides ssh-client and ssh-server with kerberos
<ivoks> since some packages in main depend on ssh-client or ssh-server, could we repackage ssh-krb5 so it provides those packages, and replaces ssh-client and ssh-server from main?
<Kamion> nooooooooo
<ivoks> ok
* Kamion <- openssh maintainer :-)
<ivoks> hehe
<Kamion> please leave that particular situation alone, it's very messy and complicated
<ivoks> then you could take ssh-krb5 :)
<ivoks> ok
<Kamion> I don't use kerberos so I'm not a good maintainer for it
<ivoks> all right
<Kamion> but the ssh-krb5 maintainer in Debian specifically asked me not to incorporate the kerberos patch into openssh for now, saying it wasn't ready
<Kamion> ogra: you forgot to define the log() function, so the workstation install fails
<ogra> oh no
<Kamion> uploading fix
<Kamion> sorry, I should've spotted that one while reviewing
<ogra> i shouldnt have forgot it ...
<Kamion> 0.1.0-5 fixes
<ogra> *forgotten
<ogra> otherwise this looks good
<ogra> Kamion, cant we just redirect stdout to the frontend to shouw the lines and drop the progress bar ? so you see at least its working...
<Kamion> ogra: try it yourself with a test image, but I really have my doubts whether that will work
<ogra> Kamion, i'll do
<Kamion> if it works, sure; it's horrible, but ...
<ogra> why is it horrible ? i mean to have it look the same, just without progressbar
<Kamion> you will have to redirect to /dev/tty1 or /dev/vc/1 or whatever, not just let it pass through to stdout
<Kamion> oh, er, you mean just pass each one through as a PROGRESS INFO or something?
<ogra> yes...
<Kamion> er, ok, if you think you can write that code quickly and make it robust
<Kamion> many of the lines will be blank, of course
<ogra> Kamion, pattern matching... it only needs to match certain expressions (Configuring, Installing etc)
<ogra> this would bring more output to the user and i dont thin its to hard to write...
<Kamion> it's horrible because we have infrastructure for doing this properly
<Kamion> but in any case, whatever you want, as I say you'll have to do it entirely yourself
<ogra> yup
<Kamion> and remember internationalisation
<Kamion> so pattern matching will not be appropriate
<Kamion> free hint, the way to display arbitrary text in a progress bar is to use ${LINE} (or similar) in the template you display with PROGRESS INFO and use SUBST to replace it with the current line
<ogra> oki
<Kamion> ivoks: (though actually, as I've just been reminded, it may be OK to get some Kerberos support into mainline openssh soon. not for breezy, but perhaps breezy+1)
<ogra> brb
<Mez> whiprush, ping
<ivoks> Kamion: ok, but what to tell this guy that wants -krb5, and doesn't want to loose half on other apps? :)
<ogra_ltsp> mdz, ping
<ivoks> bye all
<pef> bye !
<ogra_ltsp> mdz, /etc/X11/Xsession is not executable :(
<eruin> why aren't there templates for, say, synaptic in rosetta?
<mdke> eruin, #launchpad is the channel
<eruin> woops, sry
<mdke> np
<mirak_> hi
<ogra_ltsp> mdz, can you revert that to x-session-manager ?
<mirak_> when I download kernel source 2.6.12, how can I make the source evolve to 2.6.12-8 level ? so it's like the headers ?
<lu|away> j^: trying to debug a n-m problem- any idea how I can tell what dns servers bind is checking against?
<eruin> mirak_, check your pm ;-)
<mirak_> you can talk here
<ogra_ltsp> Kamion, if you didnt trigger the cdbuild fro the log() change yet, dont do it, ltsp doent work currently
<mirak_> how to apply the patches to the kernel ?
<mdke> mirak_, not really, it is a question for #ubuntu
<mirak_> mdke: but I think the answer belongs here ^^
<mirak_> or would come from here
<mirak_> i asked on #ubuntu first
<mirak_> but there is only incompetent people
<mirak_> like me ;)
<eruin> anyone know tollef fog heens nick or where to catch him on irc?
<slomo> eruin: Mithrandir 
<eruin> cheers
<torkel> jdub: probably. With HP in the loop, clusterfs is probably more intrested in supporting Ubuntu
<torkel> jdub: we have also been poking them few times :-)
<mdz> ogra: it certainly is executable here
<mdz> ogra: if it isn't, it's a bug
<ogra> it isnt in my new install
<ogra> dmaned
<ogra> damned even
<mdz> ogra: confirmed in my new install too
<mdz> ogra: needs to be fixed in xinit
* ogra apt-get sources
<mdz> ogra: needs special treatment for upgrades as well, since it's a conffile
<ogra> *  Install xinitrc from old xbase-clients also (closes: Ubuntu#13331).
<ogra> that might be it
<mdz> I don't think so
<mdz> I think that it was probably forgotten when the package was split
<mdz> xinitrc and Xsession are different
<ogra> phew, xserverrc isnt executable either
<mirak_> what compiler is used to compile breezy ?
<mirak_> breezy kernels
<Nafallo> 3.4
<mirak_> k
<Mez> mdz: little bit of news for you... novell want to "officially" support iFolder on ubuntu
<jdub> GOOD MORNING FREEDOM LOVERS! (SPECIAL SFD EDITION!)
<tseng> jdub: hi
<Nafallo> jdub: morning :-)
<tseng> jdub: im not feling the love
<tseng> Mez: um
<tseng> Mez: hth would that work?
* jdub fels tseng 
<Mez> tseng: how do you mean?
<tseng> ouch!
<tseng> Mez: well we cant distribute it, as we've learned
<tseng> Mez: and we cant sanely package it
<Mez> we cant distribute, but it'll be from thair apt repos
<tseng> er, I guess
<tseng> works for me, then
<Mez> and we can sanely package it, they took my bug reports and fixed most of it
<Mez> it's semi-sane now
<tseng> ah great
<Mez> and they've asked me to maintain
<tseng> good work then.
<jdub> slomo, tseng: yay banshee!
<tseng> jdub: yay!
* tseng syncs his ipod
<slomo> jdub: :)
<slomo> jdub: works for you?
<jdub> slomo: installing now
<slomo> jdub: ubuntu2?
<jdub> slomo: has it built yet?
<jdub> ooh, yes :)
<Mez> tseng: forwarded you email regarding crappy stuff they fixed
<slomo> jdub: sure... is already in the archives... but it just adds a depend on libsqlite3-0 which was missing before
<ogra> mdz, hmm, daniels just installs it in the xinit.install file... if its upgrade critical, shouldnt it be in postinst with a check ?
<mdz> ogra: config files are installed with mode 644 by default
<mdz> ogra: Xsession is special because it is a script
<mdz> ogra: you need to override the permissions in the .deb for new installs, and add an upgrade test with chmod in postinst to fix it for upgrades
<ogra> ah, ok... 
<mdz> Mez: interesting; is there a press release or other url about it?
<tseng> Mez: my mail server is dead :(
<mdz> ogra: if you need help with it, ask jbailey or wait for daniels
<tseng> Mez: but ill get it eventually. thanks.
<ogra> mdz, ok
* lamont kicks all the bogus dep-waits
<Mez> mdz: not at the moment, it's all in private emails between me and the lead... though they're actually developing on breezy, which is good :D
<mdz> Mez: very cool
<tseng> Mez: thats awesome
<Mez> mdz/tseng: http://forge.novell.com/pipermail/ifolder-dev/2005-September/001021.html
<Mez> they mention developing on breezy there
<tseng> Mez: its cool to see that we are now a top mono distro
<Mez> tseng: and it's all your fault
<tseng> Mez: novell makes a tough contest.
<Mez> how do you mean?
<tseng> the upstream and the packager share an office :P
<Mez> ??
<tseng> elite, kernel panic on my laptop testing box
<tseng> Mez: ok.. novell distributes suse, they employee most mono devs..
<tseng> Mez: connection? yes.
<Mez> ah
<Mez> ok
<Mez> :P
<Mez> now I get you
<tseng> cheers
<torkel> Mez: are there .debs of ifolder available anywhere?
<Mez> torkel, not atm
<Mez> but, spayne has made nice howtos on how to build it
<torkel> k
<Mez> torkel, lemme find the link
<Mez> torkel, Client: http://www.evolutioncolt.com/~spayne/blog/?p=164
<Mez> Server: http://www.evolutioncolt.com/~spayne/blog/?p=165
<spayne> http://www.evolutioncolt.com/~spayne/blog/?p=164
<spayne> oh well :-)
<torkel> Mez: thanks
<Mez> spayne, too slow
<Riddell> Mithrandir: looks like the Qt Eastern European issue is down to Qt being not as intelligent as I had 
<Riddell> assumed
<HiddenWolf> mdz, can we put a limit on the size of the apt cache, is there a timeout after which stuff automatically gets cleaned?
<Kamion> somebody said something to me after I last spoke, but I didn't see it due to a power cut
<ogra> Kamion, was me i guess
<Kamion> (I only saw the red indicator on the disconnected ssh session on my laptop)
<Kamion> anyway, post-power-cuts I'm off to bed, so others will have to take care of any CD builds you need
<ogra> Kamion, i wanted to stop you starting the cdbuild for the log() patch since i have another bug
<ogra> Kamion, thats ok, i'll only need one last one, i guess mdz can do this...
<ogra> Kamion, thank you very bery much for all the help, i wouldnt gotten here without you
<ogra> *have gotten
<Kamion> mdz: in case you want to release the Edubuntu preview without me, you want 'for-project edubuntu publish-release daily 20050909.4 install yes preview' (or whatever the datestamp will be), check over cdimage/www/simple/edubuntu/, 'sync-mirrors' when happy
<Kamion> ogra: that's ok
<Kamion> mdz: I've set up the bits of the directory structure that still need to be done by hand (fortunately, not a lot)
#ubuntu-devel 2005-09-15
* mode/#ubuntu-devel [+o Keybuk]  by ChanServ
* mode/#ubuntu-devel [+b *!n=chmj@*]  by Keybuk
* chmj was kicked off #ubuntu-devel by Keybuk (Keybuk)
<tseng> wow
<Keybuk> he's going to be doing that all weekend ...
<Keybuk> we tried to stop his client earlier, but it looks like it's still keeping-on-coming-back :-/
<ogra> i hope he has a flatrate
<mdz> HiddenWolf: we implemented that months ago
<HiddenWolf> mdz, how do you turn it on?
<HiddenWolf> I had a 560mb  /var/cache/apt/archives
<HiddenWolf> And mine was the smallest of the people that I asked to check.
<mdz> it is on by default in breezy
<Keybuk> HiddenWolf: what app are you using to install and upgrade software?
<HiddenWolf> Keybuk, plain apt.
<mdz> files are expired after 2 days by default
<HiddenWolf> mdz, no option in synaptic to set anything, and I did not download 560mb of hoary changes over the last 48 hours.
<HiddenWolf> mdz, s/hoary/breezy
* mode/#ubuntu-devel [-o Keybuk]  by Keybuk
<HiddenWolf> mdz, that was _before_ I did tonight's gnome/xorg download, 100+ packages for 40mb total.
<mdz> mvo did change that code recently; it's possible that it stopped working
<Keybuk> syndicate scott% du -sh /var/cache/apt/archives
<Keybuk> 474M    /var/cache/apt/archives
<mdz> er
<mdz>     MaxAge=0
<mdz>     MinAge=2
<mdz>     MaxSize=0
<mdz> those defaults are not what they used to be
<HiddenWolf> mdz, closing my bug before checking it actually worksforyou? ;)
* HiddenWolf chuckles
<mdz> HiddenWolf: yes. your bug said "hey it would be nice if this were implemented" and it clearly already was
<Keybuk> it's been a long release for him
* HiddenWolf was about to rename it to "implemented but doesn't work"
<mdz> if it had said "cache pruning doesn't seem to be working anymore" that would have been worth a closer look
<HiddenWolf> mdz, besides, it'd be good to put the options in synaptic, and allow a user to set size/age limit.
<mdz> that's a feature
<mdz> whereas the cache not being pruned by default is a bug
<HiddenWolf> mdz, true
<HiddenWolf> Well, I'm not sober, and it's past midnight. I'll leave you to it.
<HiddenWolf> Night.
<ogra> HiddenWolf, err, you can set this options
<ogra> HiddenWolf, in update-manager
<HiddenWolf> ogra, just "clear after download" "clear now" or "cache everything" in synaptic.
<HiddenWolf> ogra, if that's the case, then there's a difference between the two that I'd consider a bug.
<ogra> i have "set maximum size for the package cache" and "delete old packages after:"
<ogra> and its been there since quite a while....
<HiddenWolf> ogra, not in my synaptic.
<HiddenWolf> which was just dist-upgraded 10 minutes ago.
<ogra> HiddenWolf, i didnt talk about synaptic
<HiddenWolf> ogra, then synaptic and u-m disagree. I never see update-manager tho. command line works for me.
<ogra> HiddenWolf, you asked for an option... its obviously there
<ogra> mdz, xinit is updated in the archive, a new cdbuild would be nice
<mdz> ogra: binaries are in?
<ogra> according to http://archive.ubuntu.com/ubuntu/pool/main/x/xinit/, yes
<mdz> running
<ogra> thanks
<ogra> i hope thats the last one...
<HiddenWolf> ogra, make me happy, put the option in synaptic. ;)
<HiddenWolf> and good night. :)
<ogra> HiddenWolf, i'm not the synaptic maintainer :)
<Mitario> hello everyone
<bddebian> Hello Mitario 
<elmo> Kamion: is your seed regeneration stuff working?
<bddebian> THANK YOU ELMO!
<Riddell> bddebian: what did elmo do?
<Riddell> libdebtags1, nice
<bddebian> Riddell: Got me your debtags, libdebtags, and tagcoll and got me my upload rights :-)
<crimsun> hmm, load of gstreamer engine fixes in amarok 1.3.1
<Riddell> crimsun: what was wrong with it?
<crimsun> Riddell: various people reported "buzzing" with gstreamer engine in 1.2.[34] 
<tseng> Reinstallation of libxml-libxml-perl is not possible, it cannot be downloaded.
<elmo> tseng: that'll sort itself out in next cron.daily
<tseng> elmo: great.
<slomo> elmo: when does cron.daily run? ;)
<Mez> slomo every 20 mins
<elmo> 30
<Mez> ah
<Mez> nearly ;)
<slomo> daily? every 30 minutes? ah... well ok ;)
* slomo waits
<Mez> not bad for something I read about 3 months ago
<ogra> brb
<sabdfl> night all. THAT's the Badger
<ogra_ltsp> mdz, edubuntu default install on i386 is good
<mdz> ogra_ltsp: fantastic
<ogra_ltsp> mdz, going to test the workstation 
<ogra_ltsp> brb
<daniels> Mithrandir: i'm against adding new functionality and extensions to xnest
<daniels> Mithrandir: i'd much rather gdm pass the geometry
<ajmitch> daniels: any known problems with setting 855resolution to run earlier in bootup?
<daniels> ajmitch: nope
<ajmitch> found a bug in malone about people wanting it to start before gdm
<ajmitch> ok, will upload
<daniels> thanks
<daniels> make sure you migrate it
<ogra_edu> mdz, workstation is fine too
<daniels> because update-rc.d won't migrate them for you, it will say 'oh, you already have links for this, good work then'
<ajmitch> I see
<Mez> wtf? regular ogra?
<ajmitch> why not?
<ajmitch> he can clone himself if he wants :)
<ogra> mdz, bsed on Kamions info from the amd64 install, i think we can assume that it only suffered the same bugs i had on x86, so i would say lets publish this...
<slomo> can someone remove gmime2.1 from incoming? the connection stalled :/
<tseng> slomo: elmo was just here
<ogra> mdz, but i'm way to tired to rewrite the announcement now, ok to send it out tomorrow ? 
<tseng> slomo: but it should upload again ok
<elmo> done
<slomo> elmo: thanks :) can i really just reupload like tseng said?
<elmo> no
<elmo> well, actually, yes
<tseng> depends how much went up, but stuff that isnt properly formed is deleted anyway
<elmo> you can't overwrite a file, but if you upload again, the bad upload would get REJECTed and moved out of the way
<tseng> right?
<elmo> tseng: only if a .changes makes it
<elmo> stuff without a .changes is ignored
<elmo> (yes, that means you, whoever uploaded photoshop)
<bmonty> elmo: can you do a sync of ace?
<slomo> lol
<tseng> good one
<elmo> bmonty: are you a MOTU?
<ajmitch> elmo: are you able to sync from debian's NEW queue, or shall I wait for it to be processed there?
<bmonty> nope
<elmo> bmonty: please get a MOTU to ack or proxy your request 
<elmo> ajmitch: I can't sync from NEW, it's not public
<ajmitch> alright
<bmonty> elmo: will do
<ajmitch> elmo: ack on ace sync
<azeem> hrm
<elmo> bmonty: I need your name + email
<bddebian> Heya azeem 
<azeem> ajmitch: can you tell elmo to sync/import libghemical (needed for ghemical, a user bugged me)?
<azeem> hey Barry
<Lathiat> azeem: i test all that
<Lathiat> azeem: and it builsd however ghemical is fairly useless
<azeem> Lathiat: why is that?
<Lathiat> azeem: i think a new ghemical version is needed or lighemical
<Lathiat> azeem: the window you draw in doesnt come up
<Lathiat> and theres no way to bet it up
<Lathiat> *get i up
<bddebian> Lathiat: Even in the newer version?
<Lathiat> bddebian: define newer version
<bddebian> Lathiat azeem: i think a new ghemical version is needed or lighemical
<Lathiat> i had libghemical 1.9, ghemical 1.5
<Lathiat> built with mopac support
<Lathiat> (and ive used ghemical before so im pretty sure it wasnt rigth)
<azeem> yeah, I got a report about that for Debian as well
<azeem> Lathiat: thanks
<Lathiat> azeem: so we could do with 1.9 or something?
<Lathiat> azeem: (are you the debian maintainer?)
<azeem> probably and yes
<Lathiat> azeem: is a new ghemical likely to come soon?
<azeem> Lathiat: upstream?
<Lathiat> azeem: somethign in debian that makes it work :) whatever that is
<azeem> Lathiat: well, I wanted to look at it soonish, if you say 1.9 works, I can do that tomorrow
<Lathiat> azeem: i havent tried 1.9
<Lathiat> azeem: (only libghemical was 1.9, i stoel taht from debian, the ghemical i stole was 1.5)
<azeem> I didn't get it to build some time ago, so I went for 1.5 in the meantime
<Lathiat> ok
<elmo> mdke: ?
<Lathiat> mjg59: any news on #14659.. its rather nasty ? 
<Lathiat> mjg59: oops, i meant #14658
<crimsun> elmo: please sync vlc from Sid; it's fine to blow away the Ubuntu changes (I'll merge them back in by hand)
<elmo> crimsun: um, if you know you're going to do an ubuntu upload immediately after I sync, there's no point in me syncing
<crimsun> so it's better to just upload directly?
<Lathiat> crimsun: just make sure you pass -v to debuild
<Lathiat> to get all the changelog in .changes
<crimsun> sure, I can do that.
<elmo> crimsun: if you know you're going to be modifying it from Debian, yes
<crimsun> all right, thanks.
<elmo> bmonty: ok to override ubuntu changes?
<elmo> [Updating]  ace (5.4.2.1.0-1ubuntu2 [Ubuntu]  < 5.4.7-3 [Debian] )
<bmonty> elmo: I don't see any way to avoid it....the package won't build without syncing in the debian patches for gcc 4.0
<elmo> bmonty: err, but are the ubuntu changes merged into the debian or otherwise no longer relevant?
<Lathiat> we have 1 build-dep change. if thats nto fixed upstream we can easily put it back
* Lathiat looks
<elmo> guys
<elmo> I'm not being funny, but you should be checking this stuff BEFORE you ask for syncs
<Lathiat> elmo: i'll sort it uot and we'll get back to you :)
<Lathiat> bmonty: ->#ubuntu-motu
<elmo> thanks
<Lathiat> elmo: ok, please sync
<elmo> done
<Lathiat> elmo: thanks :)
<Mez> hmm
<Mez> if firefox has changed name from mozilla-firefox -> firefox
<Mez> should stuff like mozilla-firefox-locale-fr-fr change to firefox-locale-fr-fr
<bddebian> Probably.  Consistency is a GOOD thing ;-)
<Mez> hmm
<Mez> none of the locale have been renamed yet
<Mez> and i think it's too close to release to do it
<Lathiat> Mez: talk to diziet perhaps i saw he was doing some related stuff earlier
<Mez> Lathiat, ciool
<Mez> you got an email address for him/
<Mez> ogra: ping
<elmo> christ
<elmo> there has to be a saner way to handling the seeds than this duplication
<bddebian> elmo: Did you happen to morgue any of the ones I mentioned a while back, do you know?
<elmo> bddebian: I've no idea sorry - it should be easy for you to check?
<bddebian> elmo: What's the best way to check.  I don't see any binaries or source packages.  Is that enough?
<elmo> yes?
<bddebian> OK, sorry, just wan't sure.
<jblack> infinity: ping
<jblack> mdz: ping
<mdz> jblack: yes?
<elmo> mdz: how are merges of ubuntu changes to {edu,k}buntu handled?  manually?
<elmo> (seed-wise)
<mdz> elmo: yes
<jblack> so, kind of a cute story. Remember how infinity said he was going to hijack my laptop? 
<jblack> I went and got another one so that I could work while he had it. This one has a 1280x768 display.
<elmo> mdz: :|
<jblack> the first cd you had me burn doesn't use the full cd. 
<jblack> doens't use the full screen, that is.
<bddebian> elmo: Hmm, yaprimaxgui appears to still be there
<elmo> yaprimaxgui |    3.1.2-1 | hoary/universe | source, amd64, i386, ia64, powerpc
<elmo> it's in hoary
<elmo> not breezy
<bddebian> Shows in apt-cache policy and apt-cache source for me??
<jblack> mdz: I don't have the second cd any more, so I'm burning a copy to make sure the fix fixed the problem you guys were looking at.
<mdz> ok
<bddebian> s/source/showsrc/
<elmo> bddebian: dude, it's not in breezy
<elmo> whatever your apt is telling you
<bddebian> OK, sorry
<mdz> bddebian: use apt-cache madison; that shows you where stuff is coming from
<jblack> btw, reboot on the livecd doesn't work on this new one either.
<bddebian> mdz: Thank you
<bddebian> Heh, local archive, what a dolt
* bddebian feels stupid again
<bddebian> Can I mention xezmlm without getting in trouble?
<daniels> jblack: the new live cd should give you the full display
<jblack> I'll rsync a third image down and check that if the 2nd one doesn't.
<jblack> the second cd I was told to download didn't fix the screen. 
<jblack> Burning today's livecd
<bddebian> lamont-away: If you happen to come around can you free up debtags.  I sent up a new, fixed libdebtags1 that should meet the Dep-wait.  Thx
<jblack> daniels: negative
<jblack> mdz: negative. 
<jblack> native resolution is 1280x768. The casper log for a just-burned-now livecd shows it finds 1280x768, but ends up using 1024x768 
<daniels> jblack: full post.log and xorg.0.log would rock
<jblack> I guess um.. well, would pastebin.org work? 
<daniels> sure
<jblack> Ok. still booting. 
<daniels> thanks
<jblack> daniels:  first one pasted. 
<jblack> You can find it linked under pastebin.com under recent posts.
<jblack> That's post.log
<jblack> Ok. jblack1 and jblack2 
<jblack> daniels: Let me know when you get them.
<daniels> got 'em
<jblack> Ok. standing by
<daniels> okay, looks like your video BIOS sucks
<daniels> you'll need a tool like 855resolution to patch it
<jblack> Heh. 
<jblack> I think you misunderstand. I'm not complaining about a problem. mdz asked me to test my laptop last night because it has a unusual screensize. 
<jblack> which led to me mentioning acpi problems, which got infinity that I had lost the right to my laptop in ubz. 
<jblack> so today I got a brand new one (its tiny and runs like 6 hours), also with a widescreen. 
<daniels> heh
<daniels> yeah, I was just checking that it wrote the configuration file out right
<daniels> thanks for the testing :)
<jblack> Welcome. 
<jblack> btw, it doesn't look bad at 1024x768 instead of 1280x768
<jblack> daniels: need anything else? 
<jblack> mdz: anything else? 
<daniels> nope, that's fine, thanks
<daniels> ow, dude
<daniels> ajmitch: dbtcp -- just say no.
<bddebian> heh
<Mithrandir> daniels: are you opposed to adding functionality to xnest even if it comes in the form of a patch?
<daniels> Mithrandir: not hugely
<pef> hi
<Mez> hmm
<Mez> how to make a file show only lines that arent duplicate
<Mez> i.e.  using sort, to concetenarte
<ajmitch> uniq?
<Mez> aha :D
<Mez> does sort not cncetenate lines?
<Mez> hmm
<Mez> uniq isnt Exactly what I'm looking for
(pkern/#ubuntu-devel) At least it could replace the bloddy RhythmBox which crashes just when an iPod is plugged in (on Hoary at least)
<pkern> Hihi and Banshee segfaults just when I hit Preferences. What a pity.
<tseng> that will be fixed
<tseng> very soon
<bddebian> I think slomo is working on banshee
<bddebian> Oh and apparently tseng too
<tseng> bddebian: and we're talking to him, thanks :P
<slomo> btw, preferences don't crash for me ;) but that will be fixed upstream soon
<tseng> i think its already fixed
<tseng> abock will give me the tarbal when he wakes up
<pkern> tseng & slomo: Thanks. (o:
<bddebian> Heya slomo 
<slomo> tseng: and you said there will be no new release soon? ;P
<tseng> slomo: i said 0.9.8 in a week
<tseng> slomo: we get 0.9.7.1 under the table today
<slomo> tseng: fine :)
<azeem> Lathiat: I built ghemical-1.90 for breezy at people.debian.org/~mbanck/ubuntu-breezy
<azeem> seems to work OK, uploading them to unstable now after a bit of cleanup
<ivoks> ajmitch: ping
<ajmitch> ivoks: pong
<ivoks> ajmitch: it's ok, i resolved my problem :) sorry for bother...
<ajmitch> ok :)
<pvanhoof> Hey guys .. /dev/input/mice isn't created by the current Breezy setup
<pvanhoof> yet xorg.conf uses it
<pvanhoof> however
<Kamion> ogra: ok, it's up
<pvanhoof>  /dev/.static/input/mice actually is created
<ogra> yay, thanks :)
<pvanhoof> and works
<Kamion> ogra: http://releases.ubuntu.com/edubuntu/5.10/ etc., see other announcements
<pvanhoof> is this a known bug? Or should I report it?
<Keybuk> pvanhoof: it's a known bug (#12915) though any information you can give to help debug it would be greatly appreciated
<pvanhoof> Keybuk, ok
<Keybuk> we have no idea why it doesn't appear for some people sometimes
<ogra> Kamion, i wonder why we didnt just change the ip to 192.168.0.10 ... i must have been barred somehow yesterday
<pvanhoof> ok, if somebody wants to login to my laptop .. he may
<pvanhoof> Keybuk, one thing I know is that I have a synaptics touchpad thing and a USB mouse
<HiddenWolf> hunger, like I said, bug daniels.
<pvanhoof> Keybuk, and the usb mouse wasn't connected during boot
<Kamion> ogra: what IP?
<pvanhoof> Keybuk, perhaps that combination did something ...
<Kamion> ogra: anyway the UK, US, and Swedish mirrors all have it
<pvanhoof> Keybuk, and I can "disable"  the touchpad using a "FN" key on my laptop (it was disabled upon boot)
<ogra> Kamion, the preseeded one... since you said the gatway error only occurs if gw ip = iface ip
<Keybuk> pvanhoof: I have the same combination here
<Keybuk> we think the problem is udev events getting lost early in the boot process
<ogra> Kamion, thanks... fixing the announcement now
<Kamion> ogra: because it was a late and clearly-untested change anyway and the best thing to do was to revert it
<pvanhoof> when it's disabled .. the synaptics kernel module used to throw kernel warnings upon boot. Ps. My laptop is a acer travelmate 8000
<Keybuk> because if you run "udevstart" once the system has settled down, the device appears
<Kamion> insufficiently-tested, at least
<ogra> Kamion, yes, but lets just use 192.168.0.10 if the gateway gets set up right then ...
<Kamion> ogra: no, let's revert late untested changes
<Kamion> standard release management practice
<pvanhoof> root@lort:~ # ls -alh /dev/input/mice
<pvanhoof> ls: /dev/input/mice: No such file or directory
<pvanhoof> root@lort:~ # udevstart
<pvanhoof> root@lort:~ # ls -alh /dev/input/mice
<pvanhoof> crw-rw----  1 root root 13, 63 Sep 10 14:51 /dev/input/mice
<pvanhoof> root@lort:~ #
<pvanhoof> indeed
<ogra> Kamion, i mean for the next builds... i cant release without a preseeded ip, thats to ugly ...
<Kamion> ogra: sure, now - we did the right thing for preview, though.
<ogra> yup
<Kamion> why .10 though? just .2 I think
<Kamion> IPs aren't particularly decimal despite their usual representation :)
<pvanhoof> Keybuk, my first test was :  rm /dev/input/mice , unplug the usb mouse and hardware disable the touchpad
<pvanhoof> and then a udevstart
<pvanhoof> and /dev/input/mice got created
<pvanhoof> so that ain't the problenm
<ogra> Kamion, my personal preference is to put routers below .10 and servers between .10 and .20, i'm open for everything :)
<Keybuk> no, /dev/input/mice isn't actually connected to any hardware
<Keybuk> it's a multiplexer for all connected mice devices the kernel provides with the mousedev module
<Kamion> ogra: I want to investigate the problem where I saw the debian-installer/dummy template text instead of the netcfg/get_ipaddress template text first, though
<Keybuk> rmmod mousedev && modprobe mousedev makes it appear again too
<Keybuk> though mousedev is loaded for people on boot
<ogra> Kamion, yup...
<Keybuk> so that should cause the device to be created
<pvanhoof> is there something that happens after udevstart that could be important?
<pvanhoof> (during normal boot)
<pvanhoof> like .. loading a specific kernel module
<Keybuk> we thought of that, in fact for a while we thought the problem was that the kernel support for AF_UNIX sockets was in a module
<Keybuk> and certainly loading that earlier removed some of the symptoms sometimes
<Keybuk> but we now don't think that's the problem, and is just suppressing it slightly
<Keybuk> also force-starting udevd before running udevstart fixes it
<pvanhoof> well, a quickfix could be to start udevstart in the gdm script :-\
<Keybuk> that'd be the third time it would be run in the boot process
<pvanhoof> Keybuk, another hint .. it's a race
<pvanhoof> becuase
<Keybuk> oh, it's definitely a race
<pvanhoof> sometimes my boot does work
<pvanhoof> and other times it doesn't
<pvanhoof> so it could be a problem with parallel starting scripts?
<pvanhoof> (which ubuntu does, right?)
<Keybuk> we don't parallel much, only the network stuff
<pvanhoof> indeed, can't be the problem then
<pvanhoof> since when did it start to happen? 
<Keybuk> up for some debugging fun?  edit /etc/init.d/udev and change the _SECOND_ time (~line 217) udevstart is run with "UDEV_LOG=debug udevstart"
<Keybuk> and then when you get a missing /dev/input/mice -- attach /var/log/syslog to the bug
<pvanhoof> ok
<Keybuk> it started about the time we did 2.6.12 / initramfs / etc.
<Keybuk> oh, and edit /etc/udev/udev.conf and change the udev_log= line there to debug too
<pvanhoof>     log_begin_msg "Creating initial device nodes..."
<pvanhoof>     UDEV_LOG=debug udevstart
<pvanhoof>     make_extra_nodes
<pvanhoof> like that?
<Keybuk> yup
<Kamion> elmo: could you kick the torrent tracker for Edubuntu, please?
<pvanhoof> does udev restart trigger the logging?
<pvanhoof> becuase I find few interesting things in syslog
<Keybuk> you'll need to restart the machine to get an interesting log
<Keybuk> you can't really restart udev on a running machine
<pvanhoof> aha ok, nex reboot then :)
<pvanhoof> Writing down #12915
<pvanhoof> :)
<sivang> HiddenWolf: there is a seemelss out of the box support for Apple's 20+ inch displays, which failed with RH, mandrake etc..
<HiddenWolf> sivang/
<HiddenWolf> ?
<Keybuk> pvanhoof: thanks
<HiddenWolf> sivang, I haven't touched an apple in years. What where you referring to?
<pvanhoof> the gnokii package can't remove it's group
<pvanhoof> this made my last apt-get upgrade fail
<pvanhoof> I had to manually remove the group from /etc/group and retry
<Keybuk> what I'm hoping to see is where udevstart actually gets run in your boot process, whether it sees that the mousedev device is detected, whether it tries to add it, and whether it gets to udevd
<Keybuk> in fact, we know already that it's _not_ getting to udevd; so knowing whether the former stuff is happening would be very useful
<pvanhoof> ok
<pvanhoof> Keybuk, if you guys push a new kernel package :), I might reboot faster and append my syslog earlyer :)
<pvanhoof> *hint*
<Keybuk> nothing to do with me :p
<Keybuk> I doubt we'd change kernel API this close to release though
* Keybuk points at BenC
<pvanhoof> it would be *very* useful if the default compiler could compile kernel modules
<zul> Keybuk: just for the fun of it we might :)
<pvanhoof> right now I have to do crazy stuff to get the vmware support modules working
<pvanhoof> but that is probably also a problem in the vmware software .. not really an ubuntu problem perhaps
<torkel> pvanhoof: shouldn't it be enough to set CC=gcc-3.4 when building the vmvare modules?
<hunger_> Keybuk: I did have the missing /dev/input/mice, too. It does work for me again for a while now.
<pvanhoof> torkel, nope (I think even for correctly setup kernel module build environments CC=something also doesn't work. It's another env var I think)
<Keybuk> hunger_: what kind of system did you have the problem on?
<zul> pvanhoof: at the time gcc 4.0 miscompiled the kernel so we used gcc 3.4 to build the kernel fyi
<pvanhoof> zul, ok
<hunger_> Keybuk: Thinkpad T43p.
<torkel> pvanhoof: it was enough for me last time I rebuilt the modules
<hunger_> Keybuk: I upgraded to a 2.6.13 kernel which might have helped with /dev/input/mice (/dev/input/mouse0 was created by the way).
<bddebian> elmo: Can you also please sync vipec 3.2.0-4 from Debian unstable?  Or better yet, would it be better for me to just upload using -v<version> instead of pinging you for every little sync?
<pvanhoof> hunger, /dev/.static/input/mice exists on my system. As a temporary fix you could use that (or symlink it to /dev/input/mice)
<pvanhoof> hunger, else will only one of your mice work
<pvanhoof> s/mice/mouses 
<hunger_> pvanhoof: I just logged in as root in the console and reran udevstart:-)
<pvanhoof> ah yes, that also works. However .. 
<pvanhoof> the gdm failure screen makes my keyboard hang
<hunger_> pvanhoof: That did create the missing entry.
<hunger_> pvanhoof: Use kdm:-)
<pvanhoof> so I have to login on another system .. stop gdm, do the trick and restart gdm
<hunger_> pvanhoof: and X will not start here without /dev/input/mice, so neither gdm nor kdm will work and dump me to the console.
<pvanhoof> bleh .. actually .. X should work even without a mouse
<hunger_> pvanhoof: Nope. Not is it is a CorePointer.
<pvanhoof> so what about blind people .. perhaps they don't use X much, but I can see a use for a mouse for blind people
<pvanhoof> yet X might be usable (with only a keyboard and braille device)
<hunger_> pvanhoof: I guess they define something else as corepointer.
<hunger_> pvanhoof: They have sliders on their keyboard that simulate a mouse.
<j^> Section "ServerFlags"
<j^>  Option "AllowMouseOpenFail"    "true"
<j^> in /etc/X11/xorg.conf should let you start x without a mouse
<Keybuk> yeah, but then it won't notice when you plug it in later
<Keybuk> #include <rant about X developers focussing on bling instead of actually fixing it>
<hunger_> Keybuk: adding bling *IS* fixing X for most people or so it seems to me.
<pvanhoof> patch X in ubuntu and ignore their reasoning?
<hunger_> j^: Actually I prefer no X to X without a mouse.
<Keybuk> unfortunately our X maintainer is one of the bling crowd
<hunger_> Keybuk: Who? daniels?
<Keybuk> yup
<hunger_> Keybuk: I had not noticed that yet...
<Mez> grr whats happened with fglrx
<Mez> it sucks ass now
<Mez> I cant use it
<hunger_> Mez: When was fglrx good?
<Mez> hunger_when it let me play games
<Mez> Xlib:  extension "XFree86-DRI" missing on display ":0.0".
<hunger_> Mez: lrm contains an old version, too... try upgrading.
<hunger_> Mez: Not that that is easy with daniels having moved everything around;-|
<Mez> lrm?
<hunger_> linux-restricted-modules
<Mez> erm
<Mez> yeah
<Mez> I'm using the latest version
<Mez> I think
<hunger_> Mez: Have fun figuring out where to put stuff... the ATI script did install things in all the wrong places for me.
<Mez> ...?
<Mez> it worked fine yesterday
<Mez> I did an update (after being away 2 weeks)
<Mez> and it broked
<hunger_> Mez: It did? Cool, maybe I should install the ATI stuff again.
<Mez> ...?
<Mez> ATI stuff
<hunger_> fglrx and libGL and such.
<Mez> :(
<hunger_> Mez: I tested it and then moved on... didn't like it, broke too many things I like.
<Mez> yeah
<Mez> this broke me gaming
<Mez> I like my games
<hunger_> Mez: fglrx crashed my system, I like my system;-)
<j^> hunger for installations with one app starting in fullscreen mode i prefer X without a mouse attached to the pc to no X
<eruin> j^; your last nm package has added itself twice to bootup ;-)
<hunger_> j^: that is a special situation;-)
<Mez> :(
<hunger_> j^: Any idea on when your NM debs will make it into universe?
<jammcq_office> whiprush: ping
<j^> hunger_ thats not up to me, so i have no idea
<hunger_> j^: Too bad... I'd love to give it a try on my private laptop once more... even though I still do not like the idea too much.
<\sh> infinity: ping
<j^> hunger_ you can add http://bootlab.org/~j/NetworkManager-breezy/ and try
<ogra> hunger_, tseng uploaded them a week ago
<hunger_> ogra: So when will they show up?
<ogra> hunger_, aks tseng .... i dont know where his upload went ...
<hunger_> j^: Seems like NM does not work with my wireless connection.
<hunger_> j^: Stops the connection at install time and then claims there is no wireless network around.
<j^> hunger_ you might wait some seconds
<j^> does iwlist eth? scanning work?
<hunger_> j^: But the icon shows up... which is more than what I can say about the NM in the archives.
<hunger_> j^: The device is called ath0 and scanning works.
<hunger_> j^: But madwifi is rumored to not work too well with NM.
<lu|sleep> it works decently here with latest breezy kernel and j^ n-m
<hunger_> j^: And of course I do not know the passphrase for this network... only the key.
<lu|sleep> you have to disable the 'always search' wireless network discoverty
<ogra> n-m never worked for me with pcmcia orinoco here
<hunger_> lu|sleep: I did.
<lu|sleep> since the atheros driver can't do discovery and be up at the same time
<ogra> (scanning works though)
<j^> ogra thats because the orinoco driver only got search support in 2.6.13, if you use orinoco.sf.net it works
<hunger_> lu|sleep: I set it to search when disconected.
<lu|sleep> j^: how can I find out what dns servers bind is looking at? for some reason n-m ignores my local (192.168.1.1) dhcp server, AFAICT
* hunger_ thinks lu is a chatty sleeper;-)
<j^> lu|sleep /var/lib/NetworkManager/NetworkManager-named.conf
<lu|sleep> hunger_: hrm, well, works fine for me with an atheros with that setting. YMMV, I guess
<tseng> ogra: i uploaded it, it went nowhere, nafallo uploaded it, same thing
<hunger_> lu|sleep: I guess I need to change the WEP key... I do not remember the passphrase anymore.
<lu|sleep> j^: thanks
<tseng> ogra: we wont get any mails because j^ is not whitelisted
<lu|sleep> ah, I don't use WEP
<ogra> tseng, time to poke elmo then
<lu|sleep> that might be part of the problem
<infinity> \sh : pong... Ish.
<tseng> elmo: poke?
<hunger_> j^: Can I give a key to NM instead of the passphrase?
<tseng> hunger_: "hex key"
<tseng> hunger_: yes
<\sh> infinity: I have a small problem because of libgdkglext-x11...and I think you had a similar error message the last time
<\sh> infinity: /usr/lib/gcc/i486-linux-gnu/4.0.2/../../../../lib/libgdkglext-x11-1.0.so: undefined reference to `pango_x_font_cache_load'
<infinity> \sh : ...?
<Mez> daniels: ping
<infinity> \sh : Build log?
<\sh> infinity: its in a config.log of gtkglextmm
<\sh> infinity: i'm trying to fix this package..but it looks like that gtkglext is the problem...and libgdkglext-x11 is in gtkglext
<infinity> \sh : Well, you're not linking the library you need, obviously.  But you may want to find out WHY that is.
<\sh> infinity: hmmmm....
<bddebian> infinity: Can you release kboinscpy-cvs from Dep-wait?
<infinity> \sh : Does the package use pkg-config to put together its linker lines?
<hunger_> tseng: I need to prefix hex key? I need to put the key in ""?
<hunger_> tseng: Stupid me... found it.
<infinity> bddebian : Package doesn't exist.  Can you spell it better? :)
<hunger_> The applet looks really ugly in KDE... but it seems to work fine.
<\sh> infinity: yes...even in the configure section...
* \sh is pkg-config n00b
<\sh> infinity: i will talk to pitti next time...i think he had the same error message but i will try to fix this issue
<\sh> libgtkmm2.0
<\sh> is the devil i think lets see
<infinity> \sh : If you're still confused to all hell after the weekend, ping me, but right now, I'm trying very hard not to do anything even remotely like work, unless I can do it in under 60 seconds.
<\sh> infinity: no problem...thx anyways :)
<Mez> infinity: no chance of mono bootstrap then
<ivoks> :>
<infinity> bddebian : Ahh, kboincspy-cvs, not kboinscpy-cvs.  You made me search for it and everything.  You owe me. :)
<infinity> bddebian : Cleared.
<bddebian> Gah, sorry
<bddebian> infinity: Also, debtags is dep-waiting libdebtags1 and libdebtags1 shows up as building in the buidlogs but I don't see it in the archive, any clues?
<bddebian> Might be waiting for elmo, I think it's new in the archive
<infinity> Looks installed to me.
<infinity> Where does it say it's building?
<ivoks> infinity: searchandrescue is dep-wait (xlibmesa-glu-dev ??), could you please kick it? :)
<infinity> Oh, nevermind, I looked at libdebtags, not libdebtags1.
<infinity> Yeah, libdebtags1 is in binary NEW, because it's.  Well.  New.
<pkern> "If your ISP does sender callback checks, it will block our mail." <-- Bah, the reason provided isn't very valid. Sender callback is not connecting to the sending machine but checking for a valid email.
<bddebian> infinity: OK, thx
<bmonty> anyone here know where I can get a copy of the CA certificate that ubuntu/canonical uses on their websites?
<bddebian> elmo: I have to run for a while but another sync request.  xastir from Debian unstable 1.6.0-1.  Builds clean and fixes several FTBFS failures for us.  Thanks as always.
<bddebian> Who's the ruby expert?
<bddebian> elmo: You around sir?
<elmo> bddebian: no, sorry - mail me.
<elmo> kamion: done
<elmo> (gone)
<bddebian> elmo: OK, thx
<ondrej> hi all...  looks like, that new Launchpad Integration menu items are untranslated (and are not available in Rosetta)...
<ondrej> since menu items are likely to be same, it makes sense to make translation just once and update them together in all LI packages.
<spacey> where are the launchpad integration menu items?
<spacey> did the patch to not display admin stuff to non-sudo users in the gnome menu get in?
<ondrej> spacey: Help->Get Help Online... and Help->Translate This Application...  (at least in firefox and evo)
<jbailey> ondrej: They're translated into French on my system.
<jbailey> Dunno about availability in Rosetta, though.
<wasabi_> usplash for ppc coming soon?
<jbailey> wasabi_: It's in, regenerate your initramfs with it installed.
<wasabi_> k. doing so.
<jbailey> That'll get taken care of for you automatically for release.
<ondrej> jbailey: not in czech :-(, it could be related to fact, that LI items are updated from debian/patches?
<wasabi_> Darn MOL doesn't support Tiger yet.
<wasabi_> jbailey, those evms things up?
<jbailey> ondrej: It seems unlikely that they'd be separate from the regular .po mechanism, but I'm only guessing.
* wasabi_ rebuilds desktop initramfs too
<jbailey> wasabi_: No, I'm doing more evms hacking today and tomorrow.
<wasabi_> Oh.
<wasabi_> ok.
<jbailey> wasabi_: Are you interested in being a guinea pig? =)
<wasabi_> Yes. Very.
<jbailey> wasabi_: Also, can you tell me, do evms volumes always start with /dev/evms/ ?
<wasabi_> Yes.
<wasabi_> sometimes they are in subdirs of /dev/evms/ however.
<jbailey> That's fine.  I will just hook it so that evms-activate is only called when the root starts with /dev/evms
<ondrej> well, I will raise it again on some other day/time then Saturday 22:00... (ie. will ask seb128 about it :-)
<jbailey> ondrej: Please file a bug in bugzilla.
<jbailey> ondrej: It's easier for it to get tracked then, and the launchpad-integration stuff is important.
<ondrej> jbailey: what package?
<ondrej> (since it seems to be smart to update them all at once...)
<wasabi_> cool uspaslh on ppc
<wasabi_> high res too
<wasabi_> well, it's smaller
<jbailey> ondrej: Mmm.  launchpad-integration, I suspect.
<jbailey> wasabi_: It's 640x480.
<jbailey> Same image across all arch's.
<wasabi_> it centered it in the screen vs stretch
<wasabi_> so it looks ok
<ondrej> jbailey: yeah, you're right...  I'll do it right away.
<jbailey> wasabi_: Yeah, it's an awesome hack. =)
<wasabi_> Where is the usplash image stored?
<jbailey> embedded in the usplash binary.
<wasabi_> Hmmm.
<wasabi_> Anyway to rectify that?
<wasabi_> So it's easily updatable.
<jbailey> I've sent a patch to Matthew to make it loadable./
<wasabi_> k
<tseng> its a png in the source
<wasabi_> It should totally support animation.
<wasabi_> I want a dancing circle of ubuntu developers.
<jbailey> wasabi_: err...
<jbailey> wasabi_: Have you ever *seen* us dance?
<Mithrandir> jbailey: it wasn't so bad in Oxford
<tseng> has anyone heard of a /usr/bin/no?
<tseng> and can tell me where it comes from
<Mithrandir> tseng: dpkg -S ?
<tseng> Mithrandir: but i dont have it.
<jbailey> Debian's Contest-i386.gz doesn't mention it.
<\sh> i know only /bin/no
<tseng> its a ftbfs on a missing build-dep in my pbuilder
<tseng> \sh: maybe that
<wasabi_> jbailey, it's 640x480, but does it support higher, for instance on ppc?
<tseng> < tseng> no --ecma ./en -o gtk-sharp-docs
<tseng> < tseng> make[1] : no: Command not found
<wasabi_> ie is it smart or hard coded?
<jbailey> wasabi_: There doesn't appear to be an easy way of detecting the resolution.
<jbailey> zgrep "bin/no " Contents-i386.gz
<jbailey> gives  nothing.
<wasabi_> jbailey, well, I sort of mean, if I drop a 1024x768 png in the loadable place, will it change res to that, or does it just have no idea at all?
<\sh> tseng...hmmm
<jbailey> Mithrandir: Maybe it was just the group of us at the Stonewall in Sydney. =)
<tseng> something is broken, I think, will go upstream
<jbailey> wasabi_: It's just offsets, so it'll start placing it wherever you ask it to.
<\sh> graphviz: usr/bin/nop
<jbailey> wasabi_: I could probably hack something in to look at the resolution at try to DTRT.
<\sh> its the only thing i found which sounds like this ;)
<wasabi_> Hmm. I'd also like to turn off the text output.
<jbailey> wasabi_: I suspect more colour deptch is probably wanted first, though. =)
<jbailey> Turn it off?
<jbailey> So that you jus thave the progress bar?
<wasabi_> Yeah.
<Mithrandir> jbailey: I wasn't there, iirc
<jbailey> wasabi_: I don't know how the progress bar updates.  Otherwise you could hack something in /lib/lsb/init-functions
<jbailey> But it relies on gettnig some sort of updates on a regular basis to keep the splash from dieing.
<wasabi_> hmm
<wasabi_> weird.
<wasabi_> sounds complicated. ;)
<jbailey> Nah, its just that if usplash doesn't get an update for N seconds, it goes away to let you see what's broken. =)
<jbailey> I think N is currently 10.
<\sh> jdub or anyone who is planet responsible: fixed my rss feed :(
<sladen> jbailey: perhaps make it switch away after X seconds and die after Y seconds;  giving it the option to switch back.
<karlheg> mjg59, Can we chat a moment re usplash and initramfs support for it?
<jbailey> sladen: What problem does that solve?
<karlheg> mjg59, I am looking at your hook and script, and see a possible improvement.
<sladen> jbailey: if it switches away, it'll switch back if things continue to happen again
<jbailey> Oh, I see.
<jbailey> Have it automatically switch back.  That makes sense.
<jbailey> I thought you meant to have the user do that.
<karlheg> mjg59, I'll patch it and email that.
<jbailey> sladen: Maybe file an enh bug in bugzilla for it>
<karlheg> Q: Is there a 'paste' site for this channel where I can show the patch to others here?  You seem to be discussing usplash atm, right?
<jbailey> pastebin.com I think is pretty common
<karlheg> The question is why run all the hard to keep updated 'insmod' rather than a 'modprobe', and why not use 'force_load' from the hook, and let 'load_modules' do the modprobe for you, and 'udevstart' create the fb0 device automatically?
<karlheg> Ah; so the 'fbcon' and 'vga16fb' modules should only be loaded if 'vesafb' is not present... I see it now.
<karlheg> Ok, so since 'modprobe' is present in the initramfs, then why not use it rather than 'insmod'?
<karlheg> ... letting 'modprobe' handle the depends?  The 'depmod' is already run by the time that the init-premount scripts are run.
<sladen> jbailey: depends whether it is a bug
<jbailey> sladen: Severity: enhancement
<jbailey> karlheg: modprobe is in there, it's built into busybox
<karlheg> jbailey, No, you are using the "real" one, not the busybox one.
<karlheg> bb 'insmod' perhaps?
<jbailey> Ah, maybe.
<sedak> about the usplash thing ...
<jbailey> I do know that it's in there somehow, though.
<sedak> i've compile my own kernel
<sedak> and i had to add insmod ... fb.ko to make it work
<sedak> maybe it would be a good idea to add to load ?
<jbailey> sedak: possibly, or at least document it.
<jbailey> sedak: I usually try to discourage people from compling their own kernels when possible.
<sedak> ok
<sedak> it is just something i do since i'm young ...
<jbailey> =)
<sladen> jbailey: is busybox now in initramfs' by default or just if requested?
<sedak> i've been addicted
<karlheg> I've fixed it, if mjg59 accepts the patch, by using 'modprobe' rather than hand-maintained 'insmod' lines in the script that loads them.
<jbailey> sladen: Always.
<jbailey> karlheg: Does it work?
<jbailey> karlheg: ISTR there was some problems with it before.
<karlheg> I will test it soonish.
<sedak> well, anyway, if you use modprobe, there is no need to add a insmod fb.ko
<karlheg> http://pastebin.com/360043
<karlheg> Who should I email it to?  Or should I post it to bugzilla?  I suppose the latter.
<Kamion> elmo: thanks
<Kamion> tseng: stuff looking for 'no' is almost always a configure script that went "checking for foobar: no" (i.e. couldn't find foobar) and then mistakenly stuck 'no' into a Makefile where it would get run as a command
<Kamion> tseng: so therefore typically a missing build-dep
<jbailey> karlheg: Does it work?
<tseng> Kamion: yep, we've figured it out :)
<tseng> Kamion: thanks.
<tseng> Kamion: more of a broken build-dep, bad symlinks
<Kamion> karlheg: have module dependencies been guaranteeably updated by that point?
<Kamion> remember that happens during boot after usplash starts ...
<jbailey> Hmm, actually that's a good point.
<jbailey> Kamion: They are now, but they won't be when usplash moves to run earlier.
<Kamion> right ...
<Kamion> anyway, I'm meant to be going to a party; later
<jbailey> I think paprt of what mdz wanted was for usplash to be running while depmod -a did its stuff.
<jbailey> Kamion: enjoy. =)
<glm> Hi out there, I'm looking for a screen(1) user which will download http://pubwww.fhzh.ch/~mgloor/data/screenie-1.26.0.tar.gz from http://pubwww.fhzh.ch/~mgloor/screenie.html to report if it's working with Ubuntu or not. Thanks.
<sladen> jbailey: is depmod not cached?
<karlheg> Kamion, Yes, by 'load_modules'.
<karlheg> jbailey, What if the depmod -a was run sooner?
<karlheg> ... hmmm.  What about a static modules.dep with information for ONLY the fbcon and vga16fb in it... generated by the usplash hook?
<karlheg> Let me explore that.
<karlheg> (brb)
<karlheg> Q: are the modules.dep lines each complete in themselves, or is a transitive closure required?
<jbailey> sladen: No, it's run at boottime to allow late assembly of the modules.
<jbailey> karlheg: depmod -a is slow, that's the whole point of running usplash before it.
<jbailey> That way the user has something to look at.
<jbailey> I dont know the formal structure of the modules.dep file.
<karlheg> jbailey, Right, but if the 'usplash' hook created a "modules.dep" that contained only enough information for 'modprobe' to work for it's required modules, maybe that will suffice?
<jbailey> If it knows all that inforamtion, tough, why not just use insmod?
<karlheg> The thing is that a series of hand-written 'insmod' statements is fragile in the face of kernel rebuilds with different module vs static driver sets compared with the stock kernel, and in the face of kernel changes that affect the module deps.
<karlheg> I think I can hack it.  Patch pending.
<jbailey> Right.  Probably the right thing to do is to generate the insmods at build time and load those into the initramfs.
<karlheg> man modules.dep
<karlheg> ... says that the dependencies listed are "complete", and gives an example.
<sladen> jbailey: that would be better;  you could notice what platform you're on too
<karlheg> Thus, the 'usplash' mkinitramfs hook need only 'grep' out the relevant lines from the system "modules.dep" file.
<hunger_> Why is depmod -a run all the time? Does it change between reboots?
<karlheg> It can then install, or better, catenate to if exists, a temporary static "modules.dep" file...
<karlheg> Hmmm.  Perhaps that depmod ought be run at mkinitramfs time then.  Simple.
<karlheg> Ah.  catenate_cpiogz.
<karlheg> It MUST be run at run-time.
<karlheg> But a temporary static one for 'usplash' should do the trick for early start up; the later depmod can overwrite it.
<karlheg> I'll do that.
<sladen> karlheg: I don't really see the benifit of modprobe for two modules in the first 2 seconds of boot
<jbailey> hunger_: it might.  There's no promises.
<jbailey> hunger_: the initramfs doesn't know where it came from.  One of its features is that it could be assembled by the bootloaders.
<karlheg> sladen, Think of the case where a custom kernel is installed with different set of modular vs built-in drivers as compared with the stock kernel.
<jbailey> karlheg: Keep in mind.  You don't *know* for certain that usplash is the only one that needs it.  Try to think of solutions that can cohabitate with other things.
<hunger_> jbailey: Which bootloader can do something that complex?
<karlheg> ... or if a Linux kernel upgrade brings in a kernel with different set of modules required for the fbcon and vga16fb.
<jbailey> karlheg: Like if something else also wants modprobe, it could overwrite your modules.dep before you get there.
<sladen> karlheg: then they obvious know what they're doing ("...")
<jbailey> hunger_: It's about a 10 line hack to grub.  I think grub2 has it already.
<jbailey> hunger_: One of hpa's bootloaders also apparently has it.
<hunger_> jbailey: Oh, great...
<karlheg> The 'manual_load_modules' function does the right thing, by using 'modprobe' to get the list.  The script in the initramfs should also use 'modprobe' for the same reason, and can if a temporary static "modules.dep" is used.  I am very sure it will work, and will create the patches.
<karlheg> I wonder if 'modprobe' can be given a specific "modules.dep" file?
<karlheg> Ah, it's simple.  I see.  The series of 'insmod' commands can be dumped to a file with "modprobe --show-depends".
<karlheg> That can be sourced by the 'usplash' initramfs script.
<karlheg> Then, it's just like a 'modprobe', but requires no "modules.dep".
<karlheg> Very simple.
<karlheg> The 'usplash' mkinitramfs hook can do all of that easily.
<hunger_> karlheg: Will that work with bootloaders that meddle with the initrd?
<jbailey> karlheg: Right, that's why I meant earlier by generate them.
<karlheg> jbailey, Ah.
<hunger_> jbailey: Does that work with grubX meddling with the initramfs?
<karlheg> hunger_, Probably; if it can run anything at all in there, then it can run this.
<jbailey> hunger_: Yup, because the dependancies are caused by the modules.  You're just running insmod at that point.
<jbailey> hunger_: Unless you actually change out modules from underneath something, there should be no conflict.
<hunger_> karlheg: You run the modprobe --show-depends on ramfs buildtime, don't you?
<jbailey> hunger_: Yes.  Where do you see the problem?
<hunger_> jbailey: Under that assumption, why do you need to regenerate modules.dep?
<karlheg> hunger_, Each package that needs to can drop it's own script into the mkinitramfs hooks chain.  Each can thus add its own set of modules.  Given only that, a prebuilt "modules.dep" is possible.
<hunger_> jbailey: Why don't you copy the system's modules.dep when creating the initramfs and then stick with that? It should work for as long as nobody meddles with the modules;-)
<karlheg> The problem is that the initramfs can consist of catenated gzipped cpio archives, and mkinitramfs supports that.  That is also what the bootloader likely does.
<karlheg> So one overlays the next, and a "modules.dep" must be generated late.
<hunger_> karlheg: So why is it save to modprobe --show-depends then?
<karlheg> Hmmm.... so as long as no modules not in the system already are added to the initramfs, that should work.
<karlheg> Because it's done at mkinitramfs time and we assume that the modules are from the system only...
<karlheg> This seems to imply that the copy of "modules.dep" should suffice, doesn't it?
<hunger_> karlheg: I do not see why one should work while the other doesn't. AFAICT both have the same assumptions.
<karlheg> Iff the modules themselves are not overlayed with ones that have different deps, and no out-of-system-set modules are added by anything that require deps be present, it should work fine.
<hunger_> karlheg: But then it is late here and I should have gone to bed hours ago;-)
<karlheg> We need to document that.
<karlheg> ... assumption.
<jbailey> karlheg: Right, we assume there's only one instance of any given module in the world and don't allow for namespace collisions.
<jbailey> karlheg: If people are overwriting system kernel modules, they'd better know what they're doing.
<jbailey> Out of system modules need to be able to be added, though.  It might be important for non-Free modules that can't ship with the kernel.
<thesaltydog> is ipw2100 driver not yet in breezy?
<karlheg> jbailey, Leaving only the case where something adds an out-of-system-set module to a cpiogz overlay.
<jbailey> karlheg: 
<jbailey> right
<jbailey> So depmod -a still needs to be run.  But the --show-depends trick is enough for usplash.
<jbailey> And almost nothing else should ever have to worry about being run that early.
<sladen> presumbly you have to point 'modprobe' at the specific module-set/kernel-version in question before generating the depends
<karlheg> sladen, No need to now.  'modprobe --set-version=${VERSION} --show-depends' prints a series of 'insmod' statements.
<sladen> grooviness
<karlheg> A short shell snippet is thus generated that can be sourced from the (eg) 'usplash' mkinitramfs script.
<thesaltydog> anybody knows when the ipw2100 driver will be in Breezy? I lost it during upgrade from Hoary so no more wireless...
<karlheg> I will make those changes, and update the patch I submitted earlier.
<karlheg> thesaltydog, I wonder if you need the 'linux-restricted-modules' package for that?
<karlheg> thesaltydog, I need to have that installed to get my madwifi (atheros) working.
<thesaltydog> I have linux-restricted-modules installed..
<thesaltydog> it doesn't work with 2.6.12, but it still works with 2.6.10-5..
<karlheg> jbailey, I will document this all in the 'mkinitramfs.8'.
#ubuntu-devel 2005-09-16
<jbailey> karlheg: Thanks.
<thesaltydog> ipw2100 is no more working on Breezy. Kernel 2.6.12 doesn't detect anymore my eth0 wireless card..
<karlheg> thesaltydog, Is the driver present?
<karlheg> thesaltydog, Is it loaded?  Any errors in dmesg?
<thesaltydog> no errors in dmesg. the driver is loaded, simply eth0 is not working. It is working in 2.6.10
<thesaltydog> With 2.6.12 if I run ifup eth0 it gives me an error in sit0 (I don0't remember)
<karlheg> jbailey, I wonder if the 'mkinitramfs' should set a 'umask' at the top?
<karlheg> thesaltydog, We need to see the specific error message.  Please try again and get that information.  Anything in dmesg wrt sit0?  What is sit0?  IPV6, right?
<karlheg> (six in tunnel?)
<thesaltydog> I need to boot back and forth, as I have now booted with 2.6.10 to let wireless work.
<thesaltydog> On july I read that colony 2 CD won't have the ipw2100 driver in 2.6.12
<karlheg> thesaltydog, Since the module is present and loads with no error, I must assume that it is capable of working, and is thus not so much a -devel problem but a #ubuntu one.  If you post the exact error string, we will try and help you.
<karlheg> thesaltydog, Dunno.  That was several months ago.
<jbailey> karlheg: Probably.
<karlheg> If you ask on #ubuntu, you may find someone out there who has already solved it.  Also, grep the ubuntu-users email list archives.
<thesaltydog> I quote here part of the message of july 1st:
<thesaltydog> On 7/1/05, Colin Watson <cjwatson@ubuntu.com> wrote:
<thesaltydog> >   * There are no restricted drivers or firmware (fglrx, nvidia, madwifi,
<thesaltydog> >     ipw2100/ipw2200, etc.) for Linux 2.6.12 in Ubuntu yet. We apologise
<thesaltydog> >     for the inconvenience. If you own hardware that requires such
<thesaltydog> >     drivers or firmware, you might be best advised to wait for the next
<thesaltydog> >     milestone release.
<karlheg> That next milestone has long since been released, IIUC.
<thesaltydog> So my qyestion was: is it still missing?
<karlheg> IIRC, I've seen talk of a Colony 5?
<thesaltydog> I'm going to reboot, then let you know.
<karlheg> thesaltydog, Ok.
<karlheg> jbailey, Is the initramfs-tools-0.25 not in bzr yet???
<mae> so is breezy near ready to be canned up?
<jbailey> karlheg: I thought it was, lemme look.
<jbailey> karlheg: Oh, my bzr-push is broken, I'll fix it in a little bit, sorry.
<jbailey> I have a friend coming over in a few minutes and we're heading out.
<thesaltydog> karlheg, I'm back
<thesaltydog> I had a look at dmesg output
<karlheg> jbailey, I'll try my patch against 0.25 if necessary, but bzr would certainly expedite things.
<karlheg> Will you be back later?
<karlheg> thesaltydog, And?
<thesaltydog> [4294715.746000]  ipw2100: Detected Intel PRO/Wireless 2100 Network Connection
<thesaltydog> [4294716.746000]  ipw2100: eth1: Firmware 'ipw2100-1.3.fw' not available or load failed.
<thesaltydog> [4294716.746000]  ipw2100: eth1: ipw2100_get_firmware failed: -2
<thesaltydog> [4294716.746000]  ipw2100: eth1: Failed to power on the adapter.
<thesaltydog> [4294716.746000]  ipw2100: eth1: Failed to start the firmware.
<thesaltydog> [4294716.746000]  ipw2100Error calling register_netdev.
<thesaltydog> [4294716.746000]  ipw2100: probe of 0000:02:02.0 failed with error -5
<karlheg> thesaltydog, Well, it's not eth0, it's eth1, and it's failing.
<karlheg> thesaltydog, Do you have a wired ethernet card in that computer?  It's probably eth0.
<karlheg> thesaltydog, It looks like the firmware file is missing.
<thesaltydog> the firmware is not missing.
<thesaltydog> with 2.6.10 eth0 is the wireless and eth1 is the ethernet
<thesaltydog> why on 2.6.12 should be viceversa?
<crimsun> it has always been that way on my laptop
<crimsun> eth0 is bcom gigE, eth1 is ipw2200
<shackan> interface names are dynamically generated, you should not count on them being consistent across different versions, usually eth0 is the device which is detected first so maybe the new kernel detects hardware in a different order, just guessing
<karlheg> Perhaps.  There are ways to make the if name deterministic.  Try 'ifrename' or module options.
<thesaltydog> or maybe, due to the error, the wireless card is not detected
<karlheg> Right.  That's my bet.
<karlheg> Under 2.6.10, does it say the similar?
<karlheg> Probably not...
<thesaltydog> on 2.6.10 everything is working fine.
<karlheg> You're sure the firmware file is there?  Does the module support a verbose debug option to insmod?
<thesaltydog> So you suggest to replace eth1 with eth0 and viceversa in /etc/network/interfaces ?
<carstenh> .oO(Ifrename allow the user to decide what name a network interface will have.)
<thesaltydog> the firmware is here: /lib/hotplug/firmware/ipw2100-1.3.fw-2.6.12-8-686
<karlheg> thesaltydog, No, that will make it not work for the other kernel.  I would make the WIFI be 'wlan0' and the ethernet be 'eth0'.  Do that with module options in /etc/modprobe.d/ipw2200 or with 'ifrename'.
<karlheg> The module option will probably be easiest.
<karlheg> IIRC, it supports that; RTFS.
<karlheg> There is ifrename support in the hotplug scripts, but not for 'ifplugd' if you use that, unless that's been fixed.
<thesaltydog> ok I'll try and report back. Thanks
<karlheg> thesaltydog, You need to solve the firmware load problem first.
<karlheg> unless 'ifconfig eth1' is showing up?
<thesaltydog> I have to switch back to the other kernel..
<kent> Is it only me, or is dcgui-qt package in Breezy empty? dpkg -L dcgui-qt shows nothing :(
<netdur> breezy being forzen! means no new packages gonna be added before 5/10?
<tseng> not to main
<tseng> only fixes from here.
<netdur> so no mono 1.1.9!?
<netdur> I was kidding... thanks for great job
<tseng> we are pushing mono 1.1.8.3
<tseng> should be the last one.
<tseng> .9 breaks a bunch of stuff
<tseng> and has more major changes than we'd like
<tseng> and nothing amazing ive seen for users, besides "hey cool, big version #"
<netdur> tseng, I was kidding you... cause I know you are mono guy!!!
<tseng> haha.
<tseng> you got me
<tseng> im super easy to troll
<tseng> no effort required.
<xTina> Hm. Anyone (not) having UI performance issues with realplayer (current version from real.com or hoary-extras) on breezy while playing an audio stream?
<tseng> you want #ubuntu for support
<tseng> we dont even package realplayer
<tseng> or deal in hoary-extras.
<tseng> sorry
<xTina> I know. But #ubuntu has nothing else to do than talk about hot white or black chix.
<xTina> And I'm sort of desperate trying to finally get our lab up and running.
<tseng> realplayer is about the last thing we could possibly help you with
<kent> xTina, and if you desperatly want things to be working, you should not be running breezy in your lab.. 
<tseng> you could check out the hoary-extras forums
<tseng> kent: eh, we're in preview freeze
<xTina> kent: Well, why should I put tons of work in making hoary run, when I have bugs in there that are fixed in breezy and need to move 150 machines to breezy in < 2 days after release anyway?
<xTina> Don't get me wrong, I don't want realplayer support, I was just suspecting that people here might mostly run breezy on their machines and might be using realplayer for one reason or the other on those machines, so having an answer like "yes, it's working here" or "no, seen the same issues" would be helpful in determining if it's something that might be related to breezy and thus have the chance of being fixed til release if tracked down in t
<ivoks> congrats on a HP deal
<tepsipakki> ivoks: what deal?
<robitaille> tepsipakki,  http://www.tectonic.co.za/viewr.php?id=595
<tepsipakki> robitaille: great, thanks! ;)
<ivoks> ah
<tepsipakki> does this "local level" mean only South-Africa?
<ivoks> there goes mysql :/
<jdub> tepsipakki: europe, middle east and africa
<tepsipakki> sounds great
<jdub> tepsipakki: but concentrateed on africa, it seems :)
<tepsipakki> it will spread ;)
<jdub> so call hp in europe and demand ubuntu :-)
<ivoks> :)
<karlheg> http://bugzilla.ubuntu.com/show_bug.cgi?id=15129
<hunger_> It would be really nice if the init.d scripts would return "fail" if they did not start stuff... sl-modem-daemon does not and I noticed this in other scripts before as well.
* hunger_ thinks about writing a test script for that once he gets his article out of the door.
<spacey> muine freezes when I press play :S
<david_> i have a xorg xkb error at gnome start  i use latest breezy.. preview version-- (daniels fixing page dont helped me) what can i do ? 
<sivang> morning all
<sivang> jdub: yo! 'sup dude?
<[Chameleon] > sivang: morning
<[Chameleon] > sivang: what time is in in Germany? 9?
<hunger_> [Chameleon]  11
<[Chameleon] > yeah, I just asked my PDA.
<[Chameleon] > it's only 2am here near Seattle
<[Chameleon] > :)
* [Chameleon]  has a question...
<[Chameleon] > Should the change made by the script in this bug be instant or require a restart of X or a reboot or something?
<[Chameleon] > https://bugzilla.ubuntu.com/show_bug.cgi?id=2251
<[Chameleon] > basically this:
<[Chameleon] > $ sudo /usr/share/cups/enable_browsing 1
<sivang> [Chameleon] : it doesn't require restart.
<sivang> [Chameleon] : actually, it does :) but the cups-manager now handles it. The bug we have with it is that it doesn't ask to be sudo'd when executed, which it needs to be able to executed that script
<[Chameleon] > because, it's not enabling the "Global Settings \ Detect LAN Printers" menu in gnome-cups-manager
<[Chameleon] > sivang: oh, so the menu not being enabled is because the script doesn't ask to be sudo'd?
<[Chameleon] > I ran it manually with sudo and restarted gnome-cups-manager, but I still don't get the menu.
<sivang> [Chameleon] : well, the cups-manager has be executed sudo'd in order to be able to access /usr/share/cups/..
<[Chameleon] > OIC
<sivang> [Chameleon] : sudo gnome-cups-manager
<[Chameleon] > $ sudo gnome-cups-manager
<[Chameleon] > Password:
<[Chameleon] > ** (gnome-cups-manager:5562): WARNING **: IPP request failed with status 1030
<[Chameleon] > it's repeating the error message
<[Chameleon] > every 5 seconds
<sivang> [Chameleon] : you're cups server is un accessible
<sivang> [Chameleon] : so it seems, but am not sure. anyways it works great for me with sudo g-c-m
<[Chameleon] > yeah, it was the server
<[Chameleon] > my server seems to be flaky lately
<[Chameleon] > the cups service needs to be restarted frequently
<[Chameleon] > I should probably remove the FC3 on it and put Ubuntu there, too.
<[Chameleon] > :)
<sivang> [Chameleon] : hehe, sure :)
<[Chameleon] > sivang: thank you for your help.
<[Chameleon] > I was going to write this up since it seemed to be a bug, but apparently it's already a known issue.
<sivang> [Chameleon] : I'd appriciate if you opene a bug about the fact it must be executed sudo manually
<sivang> [Chameleon] : this does seems a bug to me :)
<[Chameleon] > sivang: you got it. :)
<sivang> [Chameleon] : if you can , assign it to me
<[Chameleon] > k
<jdub> 28100 jdub      15   0  226m 225m  892 S  0.0 36.2   0:09.72 gam_server
<jdub> :-)
<lifeless> erm
<lifeless> thats not so good
<nowlin> is it possible to get novells ifolder into ubuntu http://www.ifolder.com/index.php/Main_Page
<whiprush> nowlin: there are people on the ifolder team now using ubuntu, it's only a matter of time before they offer .debs.
<[Chameleon] > sivang: the bug was automatically assigned to Martin Pitt, but I CC'd you.
<nowlin> whiprush: okthx
<\sh> whiprush: mez wanted to package ifolder stuff as i understand him
<whiprush> cool
<nowlin> \sh: any idea when this will happen
<\sh> nowlin: no...ask mez when hes around
<\sh> but i think it will come after the breezy relese
<\sh> Mez: ping whiprush and nowlin wants to know when ifolder is reaching the archives ;)
<Mez> \sh: it wont be
<ajmitch> licensing, right?
<Mez> yeah
<\sh> Mez: didn't u want to package it ;)
<Mez> licencing issues
<ogra> Mez, didnt you say you wanted to do it ? 
<torkel> depends on what archive :-)
<\sh> nothing for multiverse?
<Mez> hmm
<Mez> dont think it can go in multiverse, but It'll be distributed on Novell's own apt repos once Calvin and I talk things through
<ajmitch> Mez: is the license that bad?
<ogra> Mez, if it cnat go into multiverse ? how can Calvin distribute it then ? 
<Mez> ajmitch - I've not reviewed it myself, but from what calvbin's said - yes
<Mez> Calvin = from Novell
<ogra> and ? 
<Mez> Novell are allowed to distribute it as they packaged it
<ogra> the only multiverse prerequisite for software is, that its redistributable
<ogra> if they license it as redistributable, it can be in multiverse...
<lifeless> aand if they dont, its so not open source
<ajmitch> lifeless: I think parts of it are
* Mez goes and gets the downloads
<vrln> is it true that xorg 7.0 isn't going to make breezy? If I recall correctly the feature-list is already frozen
<whiprush> hmm, didn't know there was a license problem
<Mez> whiprush: It'd be there already if there wasnt
<\sh> where can i find the license file..its not in cvs
<Mez> \sh I know
<Mez> I'm trying to find it mysel
<Mez> tseng: ping
<[Chameleon] > vrln: probably. Breezy is pretty much in the final testing phase. It's to be released next month.
<torkel> the client should be distributable. It is under GPL
<whiprush> http://forge.novell.com/modules/xfmod/cvs/cvsbrowse.php/ifolder/ifolder/COPYING?rev=1.1.1.1&content-type=text/vnd.viewcvs-markup
<whiprush> simias has a gpl license also.
<whiprush> maybe he was referring to their zeroconf/bonjour stuff?
<Mez> hmm
<Mez> no, the libflaim is the problem apparently
<whiprush> bummer
<Mez> though the client doesnt seem to use it / include it
* Mez checks out simias
<Mez> it's simias that's the problem
<Mez> brb
<Mez> breakfast
<HiddenWolf> doko, ping
<[Chameleon] > Anybody else getting this stupid page every time they start firefox?  http://www1.umn.edu/twincities/index.php
<[Chameleon] > just started happening to me a couple days ago.
<mdke> does anyone take care of console-data?
<mdke> it hasn't been upgrading properly for the last 2 months
<Kamion> mdke: mm?
<Kamion> how so?
<mdke> Kamion, #13134
<Simira> Kamion : I'm installing preview, and parted doesn't seem to discover my partitions ;( Should I add it to #9881, or file a new bug?
<Kamion> mdke: hmm, never seen that on fresh installs - but I've assigned it to myself and I'll have a look sometime this week
<mdke> Kamion, thanks, I see it on all 3 of my computers
<Kamion> mdke: I'd like a log of a failed install with DEBCONF_DEBUG=developer set in the environment
<mdke> Kamion, if you post on the bug and explain exactly what I can do, I'll post the result
<Kamion> Simira: do you have the same kind of strange partition layout, with overlapping partitions? If so, append your information to #9881, otherwise please file a new bug
<Simira> Kamion : ok. No strange partition layout, just a win ntfs partition and a previous breezy install.
<Kamion> mdke: done
<Mez> whiprush: ping
<tseng> Mez: hi
<Mez> hey tseng: looking at http://www.ifolder.com/index.php/Download it needs a few mono packages... I dont knlw the package name equivalents for ubuntu, any chance you can see if the mono stuff'll need to be packaged aswell?
<tseng> Mez: ok.
<tseng> Mez: yes, we have those.
<Mez> ah good
<Mez> now to try and get round the flaim licencing sisue
<tseng> Mez: you probably want our policy to start
<tseng> Mez: it has alot of tips to keep you out of trouble later.
<tseng> Mez: http://pkg-mono.alioth.debian.org/cli-policy/
<Mez> tseng: you've already linked me that enough :D
<Mez> hehe
<tseng> it has updates!
<Mez> I already have it in my bookmarks
<tseng> ok :)
<Kamion> mdke: there's not a lot in that log ...
<Kamion> mdke: and certainly no debug information
<Kamion> mdke: in fact, from that log, it looks like the install succeeded
<mdke> Kamion, what can I do?
<mdke> ah sugar
<mdke> Kamion, the attachment doesn't seem to have uploaded properly
<mdke> lemme redo
<mdke> Kamion, is it ok if I paste rather than attach the log?
<mdke> well I have anyhow
<mdke> ;)
<Kamion> mdke: yes
<Kamion> mdke: ok, that's surreal
<Kamion> mdke: "GET console-data/keymap/qwerty/layout" works but then METAGET on the same question fails ...
<Kamion> mdke: could you mail /var/cache/debconf/config.dat and /var/cache/debconf/templates.dat to cjwatson@ubuntu.com, please? They shouldn't contain confidential information in general (that should live in passwords.dat) but feel free to encrypt the mail if you like
<mdke> np
<Kamion> thanks
<mdke> Kamion, ok it's gone
<pitti> $ wish
<pitti> Application initialization failed: this isn't a Tk applicationunknown color name "Black"
<pitti> hm, any idea?
<sivang> pitti: you're laying with tcl/tk ? :)
<sivang> s/laying/playing/
<pitti> sivang: I just tried to get pgaccess running
<pitti> sivang: just found a thread in Ubuntuforums, but it didn't help
<sivang> pitti: ah :)
<pitti> but there's an open bug about it anyway
<sivang> pitti: what happend to nicksrv?
<sivang> pitti: I can't msg it anymore
<ajmitch> pitti: does pgadmin3 still ftbfs?
<ajmitch> pitti: also, your libgphoto2-2 upload caused f-spot to ftbfs
* ajmitch hasn't filed bug yet, very naughty of ajmitch 
<sivang> pitti: btw, I talked with mdz about the USB printer bug - he said he replugs he printer all the time, but I was able to reproduce it with some HP LaserJey printers of small scale..need to debug g-c-m code with it. (printer is not near me)
<pitti> ajmitch: I repaired pgadmin3 IIRC
<pitti> oops, still FTBFS as it seems
<pitti> ajmitch: will care for that tomorrow
<ajmitch> thanks
<ajmitch> libgphoto2-dev didn't want to install, causing f-spot to break
<bddebian> Howdy
<sivang> yo bddebian 
<sivang> pitti: can you log on to your ICQ account?
<Mez> kamion: what was your "technical" name for the process of throwing things at the buildd's till they stick
<bob2> "doing a test build on your own machine"
<ajmitch> bob2: nah, this was at UDU, when we didn't have access to amd64
<ajmitch> uploading from a remote box
<bob2> heh
<tseng> oh man, that was elite hacking
<Mez> bob2, no - I remember \sh doing at some point and kamion mentioning it with a random name
<tseng> mono 1.1.6-0ubuntu9
<sivang> tseng: please elaborate :)
<Mez> I dont think I have the logs anymore
<tseng> sivang: we build a dozen times to get it to go
<ajmitch> tseng: we got it done, eventually
<sivang> hehe
<tseng> sivang: with a few trips to cry on lamont's shoulder
<sivang> hehe
<tseng> because the amd64 buildd fell over
<Mez> lol
<ajmitch> I think we had to bug him a few times
<sivang> ajmitch: anyway, what do you think about the lvm-auto bug?
<ajmitch> sivang: depends if it gets solved before breezy
<ajmitch> a note in the release notes may be a good idea
<sivang> ajmitch: it won't , I already talked with kamion and fabbione , seems partman-lvm-auto needs a good rewrite :)
<ajmitch> annoying
<ajmitch> hopefully grub2 will see the light of day, with lvm2 support
<sivang> ajmitch: does it have a planned release date?
<ajmitch> nope
<sivang> ajmitch: what's the differnece between lvm -> lvm2 ?
<ajmitch> different on-disk metadata, different utils & limits
<bddebian> Hi sivang 
<sivang> bddebian: hey again
<xerox> Hi.
<bddebian> Heya \sh
<bddebian> sivang: Still there?  Sorry I was afk for bit
<xTina> Ok, this may be a stupid question, but who is responsible for setting DEBIAN_FRONTEND? /usr/sbin/update-inetd uses this environment variable to determine wether to use /dev/tty or /dev/null. cvs' postinst runs update-inted. It is apparently not set anywhere. Who should've set it?
<Mithrandir> xTina: debconf sets it.
<xTina> Mithrandir: When? Where?
<ogra>  /etc/debconf.conf ?
<Mithrandir> xTina: in the frontend.
<Mithrandir> xTina: what are you trying to find out?
<xTina> Mithrandir: I'm installing a bunch of packages on a system that has the frontend set to Noninteractive. cvs is one of them and its postinst complains about not being able to reopen stdin (/dev/tty). This error message comes from /usr/sbin/update-inetd, and it happens because the check for DEBIAN_FRONTEND eq "noninteractive" gives the wrong result, so it thinks it can use /dev/tty when it should have used /dev/null.
<xTina> Mithrandir: let me check if it's just not set or if it's set to Noniteractive instead of noninteractive real quick.
<Mithrandir> xtina: you've set the debconf frontend to noninteractive?
<xTina> Mithrandir: yes
<xTina> Mithrandir: And when I export DEBIAN_FRONTEND="noninteractive" right before running apt-get install, it's fine.
<Mithrandir> hmm, sounds like debconf is doing something silly
<infinity> Err, wait, wait.
<infinity> update-inetd doesn't USE debconf.  You need to have DEBIAN_FRONTEND in your environment if you expect it to work unilaterally.
<infinity> (You'll run into the same problem with glibc and timezone settings)
<infinity> (And countless other maintainer scripts that test for that variable, but don't use debconf)
<Mithrandir> infinity: cvs uses (or used to use, at least) debconf
<infinity> . /usr/share/debconf/confmodule
<infinity> So it does.
<infinity> I'll shut up, then.
<bddebian> Did I miss pitti?
<xTina> infinity: But where in there is that variable being set?
<infinity> (My point still stands anyway.  That variable should be set for noninteractive installs anyway, you shouldn't rely on debconf for it everywhere)
<infinity> (see glibc)
<xTina> infinity: I already looked there, and I just saw it testing for it, not setting it.
<xerox> Hi.  Did the last xorg update break emacs for anyone else here?
<xTina> infinity: Or more like: testing for HAS_FRONTEND
<infinity> xTina : "dpkg-reconfigure debconf" to set it from debconf.
<xTina> infinity: The env variable? Or the frontend?
<infinity> xTina : HAS_FRONTEND is a debconf variable as well, which will automatically exist only in a "running under debconf" situation, if you have a frontend.
<carstenh> bddebian: 16:01:29 -!- pitti [n=pitti@195.227.105.180]  has quit [Read error: 110 (Connection timed out)]  16:36:14 < bddebian> Did I miss pitti?
<infinity> xTina : The variable will be set by debconf, if a maintainer scripts runs under debconf.  If not, you need to set it yourself during installation (ie: export it before apt-get)
<xerox> Running X11 emacs does result in this message "Undefined color: "WINDOW_FOREGROUND"", and emacs doesn't start.  It works -nw, though.
<infinity> xTina : The safe way is to do both (pre-seed debconf with what you want it to do, and export DEBIAN_FRONTEND for stuff like glibc that doesn't use debconf)
<bddebian> carstenh: Thx.
<xTina> infinity: Ok, I will do that. But cvs runs under debconf, doesn't it?
<infinity> xTina : Yes, in which case it should be okay if you've first reconfigured debconf to use frontend=noninteractive,priority=critical
<infinity> (The latter isn't necessary anymore, I don't think, but I'm paranoid)
<infinity> (Oh, wait.  It's necessary if you don't want root's mailspool to fill up with junk, that's right)
<xTina> infinity: That's what I've done (to be exact, the values are preseeded), but the variable still does not seem to be set.
<infinity> xTina : Output of "debconf-show debconf"?
<xTina> * debconf/frontend: Noninteractive 
<xTina> * debconf/priority: critical
<Mithrandir> xerox: install xrgb and it should be fine
<\sh> shermann@toshiba-laptop:~$ emacs
<\sh> Undefined color: "WINDOW_FOREGROUND"
<ogra> Mithrandir, shouldnt xrgb be a dep of xemacs ?
<\sh> and xrgb is installed
<Mithrandir> ogra: the whole world would have to depend on xrgb then.
<Mithrandir> ogra: it should probably be depended upon by xlibs or something
<ogra> Mithrandir, since at least half of the whole world uses colors for RGB.txt, i'd not be opposed to that
<ogra> yes, xlibs would be better
<xerox> Mithrandir: in fact it is installed.
<\sh> and somehow app-defaults for emacs are missing as well
<ogra> hmm, probably at the wrong location again ? 
<\sh>  etc/X11/rgb.txt
<xerox> \sh: #emacs people told me it could have been a problem with app-defaults, but I didn't find anything about Emacs there!
<\sh> xerox: thats what i said, its not installed..and damnit i don't have connection to my home laptop
<\sh> and fetching emacs source and compiling on this portege is more then nasty
<xerox> Let me see if I can find one.
<\sh> this evening i will check it
<sivang> guys, how can I have USPlash installed , I did dist-upgrade on my laptop and still I can't see it on boot
<infinity> xTina : Alright, brain switched back on, re-read the debconf docs.
<ogra> sivang, there are instructions on ubuntu-devl
<ogra> devel even
<infinity> xTina : debconf does NOT export DEBIAN_FRONTEND (yay, confusion), it only reads it to set the frontend.
<sivang> ogra: k, thanks, I'll look
<infinity> xTina : In other words, noninteractive installs should be exporting that before they get going.
<\sh> sivang: dpkg-reconfigure linux-image-`uname -r`
<sivang> \sh: thanks
<xTina> infinity: Ok, thanks a lot for clearing up that confusion :)
* xTina puts that on the list of things to go into the "howto install and maintain ubuntu on 150 machines" doc ;)
<sladen> xTina: do it!
<sladen> xTina: it's something that's worth writing up just for the press-converage
<Mez> infinity, just so youn know bittorrent (your package) has unmet deps
<infinity> Mez : it's not my package...
<\sh> bittorrent-gui?
<infinity> Mez : But I'll happily fix it. :)
* infinity grabs the source.
<Mez> infinity - I think you were just the last person to upload
<\sh> well i fixed it a couple of weeks ago...
<Mez> \sh: the unmet dep?
<\sh> Mez: i fixed wxgtk2.6 issues
<\sh> for the gui part which is in universe
<infinity> gui depends on <\sh> for the gui part which is in universe
<infinity> Err.
<infinity> Cut 'n paste hilarity.
<\sh> hehe
<infinity> bittorrent-gui: Depends: libwxgtk2.4-1-python but it is not installable
<infinity> (Cause it doesn't exist)
<ajmitch> needs python-wxgtk2.4
<LinuxJones> xTina, you using SystemImager for those 150 machines ?
<ajmitch> the package name changed a couple of times
<\sh> this is not funny
<infinity> ajmitch : Yeah, I know.  Was just pointing out the error. :)
<xerox> \sh: that's strange, no one of the people I asked has an "Emacs" file.
<xTina> LinuxJones: No, images are evil (and fai is too, for that matter :P )
<infinity> \sh : You want to upload a fix, or should I?
<LinuxJones> xTina, :)
<ajmitch> infinity: sorry, 3am here :)
<xTina> LinuxJones: d-i preseeding + ssh forced commands + python + nfs
<\sh> infinity: i can do it only this evening
<infinity> \sh : Actually, I'll leave it to you, checking the changelog, you seem to have it well in hand.
<\sh> around 19 utc
<\sh> infinity: yes...I'll fix it later this evening
<infinity> \sh : Cool, I'm still on my weekend for another 10 hours (8 or so of those, I hope to sleep through), so go nuts.
<ogra> infinity, \sh is on visit her at my house... he cant work with 768K DSL ;)
<\sh> infinity: hehe u shouldn't work so much
* \sh drinks a beer...
<infinity> Hrm.  Beer sounds good.
<Mez> yes it does
<Mez> and I own \sh some
<Mez> grr
<LinuxJones> xTina, SystemImager is excellent for pushing updates (or downgrades) across your network. It would save you alot of time :)
<tseng> ogra: oh, is there a wiki page for php5 migration?
<ogra> tseng, nope..
<tseng> ogra: i just noticed cacti wants php4 installed
<ogra> is there something to migrate ? i thought php5 is downwards compatible in most areas
<tseng> the Depends:
<tseng> are you just rebuilding?
<ogra> yes
<tseng> ill look at the source
<ogra> rebuilding and testing... if i see no breakage its fine...
<tseng> great, i can do that
<xTina> LinuxJones: I've worked with SystemImage for a while at $BIG_CORP and I hated it ;)
<sivang> ogra: you put php5 into edubuntu ?
<infinity> There's no real pressing reason to change all the deps.
<ogra> sivang, we have php5 in ubuntu... so yes
<tseng> infinity: besides that it wants to jack my install by removing php5 and installing 4
<infinity> Though changing the "php4" deps to "php5 | php4" makes it easier for people who DO want php5 installed.
<mxpxpod> does anyone else (after the recent updates) have terminal and search & indexing in the accessories categories?
<xerox> \sh: xrdb -q | grep WINDOW_FOREGROUND  has the same output of  grep -rni WINDOW_FOREGROUND /etc/gnome/config/  more or less, if it helps.
<tseng> infinity: i thought 5 was going to be breezy supported fare and 4 was out the window
<infinity> tseng : 5 is supported, 4 is universe.  Not sure about "out the window", but definitely "out of my hair, support-wise"
<\sh> xerox: lemme check this evening..or latest tomorrow morning....
<\sh> in the moment i'm really in relaxing mode 
<tseng> infinity: ill try the 
<infinity> tseng : So, yeah.  For main, I've removed/migrated all php4-related deps.  For universe, it would be nice, but I'm not sure if we'll actually get to them all.
<tseng> grr uk keyboard
<tseng> ill try the | bit
<xerox> \sh: I'm not, but thanks anyway.
<tseng> or just make it 5
<sivang> ogra: ah nice :) I wasn't aware.
<infinity> Oh, and if you guys run into php5 extensions we need packaged to rid us of php4 deps in universe, tell me.
<infinity> I can whip up extension packages in my spare time for anything you think is missing.
<LinuxJones> xTina, really ?
<tseng> infinity: is php5-mysql supported now?
* tseng looks
<ogra> tseng, yep
<infinity> tseng : Everything build from the php5 source is in supported.
<tseng> woo!
<tseng> finally.
<mxpxpod> also, "text editor" doesn't seem to be in Accessories or in my "Open With" dialog
<infinity> tseng : So, the only php5 etension currently in universe is php5-imap.
<ajmitch> hm, my email to u-devel needs moderation :)
<sivang> infinity: take the new oci8 extension as well :)
* ajmitch checks subscription address
<jdub> ajmitch: i'm adding your ubuntu.com to the accepts list
<xTina> LinuxJones: Yep. Though it probably has evolved a bit in the past 2 years.
<infinity> sivang : Uhh, we don't package any oci8 extensions, cause the library is non-free (well, non-distributable, afaik)
<jdub> ajmitch: do you want me to switch all of yours to ubuntu.com?
<\sh> infinity: grab a beer and relax dude...
<ajmitch> jdub: yeah, would be good
<ajmitch> thanks
<LinuxJones> xTina, well it's a better long-term solution than say kickstart :)
<xTina> LinuxJones: The system here is completely image-free (except for an install image with an initrd, kernel & grub that just gets distributed along with the Windows guys who use Ghost anyway).
<sivang> infinity: ah I see 
<xTina> LinuxJones: KS is nice. Of course it won't provide you with patches and updates, but that's what our Python stuff does :)
<jdub> ajmitch: all four of your different addresses :)
<sivang> infinity: I was sure they were releasing them FOSS..what about ibm_db2.so ?
<LinuxJones> xTina, I'll be looking forward to reading your howto :D
<jdub> ajmitch: debian, gmail, gnu, ihug - right?
<infinity> sivang : Same story, unless sometihng's changed recently.  I'll admit, I haven't kept up on Oracle and DB2 licensing recently.
<sivang> infinity: ok, I might do a couple of checkups see if it changed and let you know
<infinity> sivang : If you do some research and find that those libs are a) released under free licenses, b) packaged somewhere, and c) can be linked with PHP without violeting their licenes, I'd be happy to know about it.
<xTina> LinuxJones: :)
<infinity> s/violeting/violating/
<sivang> infinity: sure
<LinuxJones> xTina, you have anything up online now ?
<sivang> jdub: can we set up an ftp server or something for the IBM guy to send us the DB2 validation scripts?
<sivang> jdub: is that or waiting for the cd to be in through snail mail..
<jdub> sivang: speak to elmo or Znarl about it
<xTina> LinuxJones: Just the old RedHat-based documentation (and not even that right now, cause the HP-UX machine that serves the web pages gave up last night and I'm not touching that *g*). I've changed a lot in the past weeks.
<infinity> sivang : Item C is important.  See, for instance, the hell I went through with MySQL to get their client library relicensed so we could link to it (they released it under the GPL, which conflicted horribly with both PHP and half the things PHP links to, and I had a 6 month back-and-forth with them to get the license relaxed to allow linking for distribution)
<LinuxJones> xTina, cool
<sivang> infinity: Yes, I wonder how it gets in PHP so easily although it anything but BSDish in nature
<xTina> Anyway, I'm off to the labs now, need to turn on a few more machines, test cd burning and sound, and make xfce look pretty ... which is all sort of hard to do from remote :)
<sivang> elmo, Znarl : can we set up an ftp server with roughly ~700MB free space. I have an IBMer that needs to send me some db2 validaiton scripts :-)
<jdub> ajmitch: done :)
<sivang> jdub: can I also get an ubuntu.com mail alias ? :)
<sivang> would look nice on my future changlogs ;-)
<ogra> sivang, just fix up your flaunchpad account...
<ogra> heh
<ogra> launchpad...
<ogra> sivang, if you got ubuntite status in launchpad, you automatically got a @ubuntu.com address now
* jdub adds a s/ubuntite/ubuntero/ filter to his irc client
<ogra> heh
* ajmitch_ wonders what he missed, dsl died again :)
<jdub> ajmitch: me fixing your multitude of email addresses subscribed to ubuntu lists ;)
<sivang> ogra: I have an account, what do I need to do to it?
<ajmitch_> jdub: I shouldn't have too many :)
<ogra> sivang, upload your gpg key and sign the CoC
<jdub> ajmitch_: four!
<ajmitch_> really?
<ajmitch_> interesting
* ajmitch_ should cut down a bit
<sivang> ogra: ah well, then I Need to talk to Mako, he approved me as an ubuntite ages ago and as a member, re: gpg, I am gonna have to resign it with folks, as you might remember :)
<jdub> well, now you have one ;)
<ogra> sivang, ah, yes...
<ogra> but mako approval wont work around the launchpad tchnology i fear
<sivang> elmo, Znarl : just email me with the account details, and I will provide it to him, and continue from there without bugging anymore :)
<sivang> ogra: you mean launchpad must have the GPG key in in order to let me use the email address?
<ogra> sivang, exactly
* sivang is proud to say that Ubuntu won over FC3,MDK10,RH in working *out of the box* with 20inch Apple cinema display, the freind installee was really impressed. 
* ajmitch wants one
<sivang> ajmitch: not mine, some PhD freind of mine who has fettish for apple's hardware :)
<tseng> i have one :)
<tseng> its the coolest
<sivang> tseng: Brandon!
<tseng> hi~
<ajmitch> I've just got dual-head CRT setup
<ajmitch> the 21" monitor is getting a bit old & flickery in one corner
<sivang> tseng: amazingly crips and soft on the eyes
* jdub gets his LCD tomorrow!
<tseng> it works great with my nvidia desktop
<sivang> jdub: apple's ?
<tseng> its pretty suck with my laptop docking station
<tseng> i have to hack xorg.conf to switch between lcd + tft
<jdub> a dell 24", same panel as apple's but about 2/3 the price (and 20% off when i bought it)
<tseng> but thats not the monitors fault
<sivang> jdub: hmm, quality same as Apple's? (crispness, durability etc) 
<tseng> sivang: yeah it really is the same screen
<jdub> same panel
<sivang> jdub: (am also looking for a similar one but not 1200$)
<tseng> different mount and stuff
<tseng> different controls
<tseng> lcd is the same
<sivang> jdub: you have a link so I can tomboy it ?
<jdub> has 4 usb ports instead of 2 usb / 2 firewire
<jdub> sivang: can't deep link into dell's shop
<jdub> and you're in .il, not .au :)
<sivang> jdub: well, I have someone to send me stuff over the states , or you can bring it to UBZ  if candian custom won't object :)
* jdub considers hauling a very large lcd around for half of the BBB Tour... hrm, no. :-)
<sivang> </humor?>
<sivang> hehe
<sivang> anyway, that guy, I even installed him Breezy preview, and everything was so smooth.. that delta the usb printer bug (cups needs restarting)
<pkern> jbailey: I just upgraded to breezy and am also suffering of #14485, ppc kernel failing to mount root fs
<pkern> jbailey: And there was no problem with hoary. |:
<ogra> sivang, you come to UBZ ? 
<sivang> ogra: I do! :-) So, I'll have my GPG key signed again and this time I will store the passphrase in a safe deposite.
<ogra> YAY
<tseng> heh
<\sh> sivang: put urself on the attendees page ;)
<ogra> sivang, get a tatoo with it on a secret place ;)
<sivang> ogra: heheh
<sivang> ogra: yay, finally meet again -  I still can't really grasp it :) 
<ogra> :-D
<\sh> jdub: btw....nice pictures from your wedding
<sivang> \sh: where's the link ?
<ogra> sivang, planet
<sivang> ogra: ah right :) (Doh1)
<\sh> sivang: wiki.ubuntu.com/UbuntuBelowZero
<\sh> sivang: the wedding pictures of jdub are on the planet..right
<sivang> \sh: thanks, looking forward to meet you as well, Stephan
<\sh> sivang: me too :)
<\sh> I'm very curious to see faces in front of all the nicks here :)
* bddebian hides
<\sh> bddebian: u and i we have to meet dude...
<\sh> and I think ogra will love to meet u as well
<ogra> :)
<sivang> bddebian: you also coming to UBZ ?
<sivang> so how does it go, are we going to be able to suggest BOFs before the conf, or are we just going to do spec work while there?
<\sh> if so..I have to prepare at least 2 bofs :( more work 
<bddebian> I may try
<ogra> may ? 
<ogra> try ?
<ogra> booo
<\sh> u have to barry
<Lathiat> \sh: yeh conferences are good to that
<Lathiat> *for that
<\sh> Lathiat: I've prepare nafallos duty as well
<bddebian> Well I want too but it's tough with the wife and thee kids :-)
<pkern> How could I get a verbose boot of the kernel?
<Lathiat> pkern: take quiet off
<Lathiat> pkern: hit e in grub and goto the line wit the options and take it out
<pkern> Lathiat: It's yaboot |:
<Lathiat> errr
<Lathiat> i have no idea
<Lathiat> figure out how to change its config not to include quiet
<Lathiat> :)
<pkern> Lathiat: But thanks anyway.
<pkern> Time to try it.
<pkern> Bah, sucky new kernel )o:
<jc-denton> how can i mount the initrd image of the breezy kernel? mount -o loop -t cramfs .. did not work
<jc-denton> cramfs: wrong magic?
<pkern> jc-denton: I just tried it... You can't |:
<pkern> jc-denton: gunzip -c initrd.img > initrd.img.ungzipped
<pkern> jc-denton: cpio -i initrd.img.ungzipped
<jc-denton> i did that too
<jc-denton> but how do i create the image from it again
<jc-denton> if i changed the stuff i wanted
<pkern> jc-denton: With cpio -o, but I never used that.
<jc-denton> and this will work?
<pkern> Don't know... I'm stuck with the new kernel, too. ):
<jc-denton> hrmm
<pkern> jc-denton: Do you use xfs by chance?
<jc-denton> pkern: nope?
<jc-denton> man i hate cpio
<jc-denton> /bin/ls | cpio -o doesnt seem to work
<pkern> jc-denton: It was worth a try. ):
<pkern> Eh?
<pkern> hm
<thesaltydog> On my new breezy upgrade my wireless card is eth0, but the kernel tries to load the card firmware in eth1...
<jc-denton> can't i use that like tar?
<pkern> jc-denton: That works here. `ls foo bar | cpio -o > foobar`
<pkern> slomo: I really think it's xfs ):
<slomo> pkern: ah you are the second one? ;)
<pkern> slomo: I'm the one who just commented ;)
<pkern> slomo: I don't get why it thinks of unknown-block(0,0) when a valid device is specified in root=, so either it can't convert that or... it doesn't cope with xfs?
<jc-denton> pkern: it needs to be ls -R i think
<slomo> pkern: but the funny thing is... when i use 2.6.12-3-powerpc with old initrd it works... with initramfs i get this error
<jc-denton> but the format of ls -R is not correct
<jc-denton> i guess that cpio expects for every file a line
<pkern> jc-denton: Yep.
<pkern> jc-denton: Try `find`
<jc-denton> ah yes find
<jc-denton> thx for that tipp
<pkern> slomo: So the other point could be that it doesn't find the initrd?
<slomo> pkern: but it says exactly that one line above... it is found ;) but lets wait for BenC or jbailey to comment on that...
<jc-denton> i forgot about find lol
<pkern> slomo: Ah... http://gaugusch.at/kernel.shtml
<slomo> pkern: ppc has no acpi
<slomo> pkern: ah i see
<pkern> slomo: "This is because initramfs get confused by the additonal data after the initrd. "
<jc-denton> argh crap
* jc-denton expanded the initrd img, compressed it again with all firewire modules added and tried to boot from a firewire disk
<slomo> pkern: please put it in the bugreport :)
<jc-denton> i'm not sure if this is the channel to ask about such stuff but on #ubuntu nobody had a clue about the initrd image
<hughsie> ogra: ping?
<desrt> hughsie; i received a perplexing email from you yesterday
<hughsie> desrt: perplexing? did you email intend to attach a patch?
<desrt> it's starting to seem like i did not :)
<hughsie> desrt: or is it me?
<desrt> let me check my sent mail folder
<hughsie> desrt: okay
<desrt> hahah no
<desrt> i'm just an idiot
<desrt> :D
<desrt> http://bugzilla.ubuntu.com/attachment.cgi?id=3559
<desrt> it's this one, remember?
* desrt resends email
<hughsie> desrt: ohh, i found it, but davidz not going to be bothered :-)
<desrt> ya.  i don't blame him :)
<hughsie> desrt: have you got hal-commit privs?
<hughsie> desrt: also, what do you make of my processor.state.* patch?
<desrt> have not looked at all
<desrt> ok
<desrt> resent
<desrt> hopefully that one clears the list sooner
<hughsie> desrt: it adds processor.state.{nice|idle|system|user} to the hal tree
<desrt> hmm
<desrt> as % numbers?
<hughsie> desrt; yes
<desrt> interesting
<hughsie> desrt: you subscribe to hal right?
<desrt> no
<hughsie> desrt: that why you got stuck in the list
<desrt> david just added me to the happy list :)
<hughsie> desrt: ohh, okay
<jc-denton> are there some docs about how ubuntu kernels are built
<hughsie> desrt: shall i send it to you?
<desrt> i'm viewing the archive
<desrt> er
<desrt> when did you send it?
<hughsie> yestreday
<desrt> man
<Nafallo> what exactly is " Lid Close" supposed to do in ubuntu?
<desrt> i don't wanna get on the hal list
<desrt> but it's starting to look like i might have to :/
<desrt> Nafallo; sleep the machine
<hughsie> desrt: it's low traffic
<Nafallo> desrt: ah, then I should enable that before trying to do it then ;-). thanks :-)
<desrt> hughsie; compared to... say... lkml :P
<desrt> btw
<desrt> there are some machines out there (ow!) that report battery 'discharging' if it's ever not charging
<hughsie> desrt: i know :-(
<desrt> we might have to address it in hal
<hughsie> desrt: acpi is *so* fucked
<desrt> if the kernel guys can't sort it out
<desrt> basically, keep track of ac adaptors in the system and how many of them are 'plugged in'
<slomo> pkern: ping?
<pkern> slomo: pong
<desrt> and if any adaptor is plugged in, never show a battery 'discharging'
<hughsie> desrt: i'm sure we should, but it adds to the overhead.
<slomo> pkern: will you add this url to the bugreport? maybe it helps...
<desrt> hughsie; you can do it in a no-overhead way if you use a global
<hughsie> desrt: might be worth adding a "quirks" global enum like the usb kernel guys do for broken hardware
<hughsie> desrt: beat me to it
<desrt> hughsie; i think maybe i'll whack up a patch for it
<pkern> slomo: It's in fact only one sentence which helps I think. 
<desrt> hughsie; pitti is gonna want to kill me by the end of this release cycle :)
<hughsie> desrt: what about a generic quirk thing?
<hughsie> desrt: but i wonder how many ppl just didn;t have battery status with the old applet
<desrt> hughsie; i think, all of the quirks we've encounted thus far, can be fixed in generic ways by applying additional sanity
<pkern> slomo: I'll have to reboot again and check two lines before that.
<slomo> pkern: ok
<desrt> hughsie; far better, i think, to always be sane than to be slightly more careful according to a blacklist
<hughsie> desrt: knock up a patch (and subscribe to hal-devel :-) and we'll discuss there
<pkern> brb
<hughsie> desrt: okay, sounds good
<hughsie> desrt; is there *ever* more than one ac_adapter in the system?
<desrt> plus... i wouldn't want the job of maintaining *that* list :P
<desrt> hughsie; wellllll
<hunger_> hughsie: With servers: Sure.
<desrt> hughsie; my patch is going to be naive about that and i bet it'll still work 100% of the time
<Kamion> xTina: "noninteractive" must be in all lower-case; if you're preseeding debconf/frontend=Noninteractive, then fix that
<desrt> hughsie; if any single adaptor transitions from off to on, set flag to 1
<hughsie> desrt: i have a compaq server with two psu's, but reports nothing with acpi
<hunger_> hughsie: Dunno whether those need a battery applet though.
<desrt> if any transitions from on to off, set flag to 0
<hughsie> hunger_: you like g-p-m?
<Nafallo> wow
<hughsie> :-)
<hunger_> hughsie: g-p-m?
<Nafallo> I just hibernated :-P
<desrt> Nafallo; congratulations.  do you feel well-rested now?
<desrt> :)
<hughsie> hunger_: http://gnome-power.sourceforge.net/
<Nafallo> desrt: mostly amazed. I didn't even disconnected from xchat and gajim ;-)
<hunger_> hughsie: I use as little gnome as possible...
<hughsie> hunger_: :-p
<desrt> gajim is seeing a lot of popularity among ubuntu circles lately :)
<desrt> hunger_; don't worry.  g-p-m mostly sucks anyway
<desrt> :)
<hunger_> desrt: I am not surprised... it has "gnome" in the name after all.
<desrt> hughsie; btw.  i have commit access to hal now. :)
* hughsie is ignoring both of you.
<desrt> hunger_; oooo.  thems fighting words
<hughsie> desrt; ohh okay!
<hunger_> desrt: Yeah, I should make fun of gnome in #kubuntu-devel only;-)
<desrt> hughsie; seriously, though... i beg of you
<desrt> hughsie; make g-p-m a service that gets started by the initscripts
<desrt> hughsie; and is configurable over dbus with the gnome interface
<hughsie> desrt: you mean a system service
<desrt> yes
<hughsie> been there, seen that
<desrt> having power management that only works while logged in ....
<hughsie> if hal does all the heavy lifting, the session daemon is just as small
<hughsie> desrt: that is a good point
<desrt> heh
<desrt> remember GnomePower? :)
<desrt> or whatever it was called
<hughsie> but, hopefully we can init a special case whithin gpm (the logon screen) without a gui
<hughsie> *powermanager
<desrt> hmm.  interesting
<desrt> what happens in the case that multiple users are logged in?
<hughsie> that was davidz's idea for killing the system daemon
<hunger_> is power-manager the obsolete thing or the newest craze?
<desrt> do the two user daemons interfere?
<hughsie> desrt: you can configure who can do what with the dbus policy
<hunger_> is gnome-power in ubuntu?
<hughsie> desrt: no, they both work independantly
<desrt> hunger_; g-p-m is the latest craze
<hughsie> hunger_: yes, i think. try the package gnome-power-manager
<desrt> hunger_; PowerManager or whatever it was called is over-engineered vapour
<hunger_> desrt: gnome-power-manager deb claims to be a frontend to gnome-powermanger
<desrt> hughsie would know :)
<desrt> oh man
<hughsie> hunger_: thats a really *old* version then
<desrt> it is a good day
<desrt> because today
<desrt> there is leftover pizza in the fridge
* desrt zips off for a moment
<hunger_> with power-manager being the backend for gnome-power-manager.
<hughsie> desrt: but is it moldy?
<hunger_> hughsie: It is what is in breezy at the moment.
<hughsie> hunger_: powermanager was the bodge solution until hal supported events
<hughsie> hunger): then it's old :-)
<hughsie> hunger_; http://gnome-power.sourceforge.net/faq.php#power_manager
<hunger_> hughsie: That is why I asked:-)
<hunger_> hughsie: So this is not in ubuntu?
<desrt> hughsie; pfah.  as if left-over pizza would last longer than 24 hours around here :)
<desrt> hughsie; from last night
<hunger_> hughsie: Then I am too lazy to test;-)
<desrt> homemade 3 cheese/chicken
<desrt> hughsie; move to gnome.org plz
<desrt> and start hanging out in -hackers :)
<hughsie> desrt: okay :-)
<Lathiat> infinity: can you give-back cheesetracker
<desrt> hughsie; do you have CVS?
<hughsie> desrt: what , for g-p-m?
<desrt> cvs.gnome.org
<hughsie> desrt: export CVSROOT=":pserver:anonymous@anoncvs.gnome.org:/cvs/gnome"
<hughsie> cvs -z3 checkout gnome-power-manager
<desrt> oh!  awesome
<desrt> i didn't realise
<desrt> i thought you used sf cvs
<hughsie> http://gnome-power.sourceforge.net/compile.php
<hughsie> i did, but switched to gnome about a month ago by request of a few head gnomies
<desrt> ah
<hughsie> sf still hosts the website
<desrt> i'm a month late, then :)
<hughsie> that's going -> gnome.org too, but i stil need to find the right person to talk to
<lu|away> wrt?
<desrt> hughsie; sysadmin@
<lu|away> gnome.org/projects/power-manager/? 
<desrt> or gnome-sysadmin@ even
<hughsie> desrt: okay, i'll give it a go.  gnome.org/projects/gnome-power-manager i figured
<desrt> hughsie; do not expect a prompt reply :)
<hughsie> desrt: to be honest i quite like the sf one as i can see the hits
<lu|away> actually for that try gnome-web@, I think
* lu|away checks
<desrt> lu|away; but sysadmin needs to give you an account on window
<hughsie> desrt: i have commit privs on gnome-power
<lu|away> desrt: no
<desrt> s/gnome-power/*/
<hughsie> all
<lu|away> desrt: you just need cvs privs
<desrt> lu|away; oh.  the projects/ stuff auto-syncs from cvs?
<lu|away> yes
<desrt> l33t.
<lu|away> hughsie: http://cvs.gnome.org/viewcvs/gnomeweb-wml/www.gnome.org/projects/README?rev=1.2&view=markup might be helpful
<hughsie> dinner calls guys. back in about 30 mins
<hughsie> lu|away, thanks, i;'lll read that later
<lu|away> hughsie: if it isn't useful, please email gnome-web-list@gnome.org
<lu|away> and we'll get it fixed up
<lu|away> :)
<desrt> luis; gnome-sysadmin@ is still the right place to ask for ftp master upload capability, right?
<lu|away> desrt: believe so, yes
* desrt resumes waiting, then :)
<jdub> desrt: accounts@gnome.org would be easier/faster
* desrt will resend
<bddebian> infinity: ping?
<infinity> bddebian : pong.  I'm asleep.  Maybe.  But if it's quick, I'm still awake.
<bddebian> infinity: Well I was going to ask you to clear the dep-wait on gnustep-gui because I uploaded a fixed gnustep-base but I don't think it's hit the archive yet.
<xine> any body home...?
<bddebian> xine: Nope
<bddebian> :-)
<infinity> gnustep-gui doesn't have a dep-wait.
<tseng>  /nick mplayer
<infinity> Unless it was a (correct) dep-wait on gnustep-base, which is auto-cleared when the package is installed.
<infinity> It's only incorrect dep-waits (ie: on packages that don't exist) that need manual intervention.
<bddebian> Hmm it must have cleard itself, sorry
<segfault> shouldn't the breezy livecd include ALL language-packs?
<Kamion> they won't fit
<Kamion> it would certainly be nice to include more, but last I checked we were at the limit
<bddebian> What else is there beside English? ;-P
<bddebian> j/k
<segfault> it's not so useful, then
<segfault> if we would like to show the user how the system is, before installing it.
<segfault> he'll ask: why is the menu all in english?
<Kamion> yes, it's a shame that other software has grown to the point where we can't fit it in
<Kamion> we're well aware of the problem
<segfault> :(
<Kamion> you can install a language pack on the fly once you have the live CD running
<Kamion> (and log out and log back in to get the menu updated)
<segfault> yeah, i did that manually
<segfault> apt-get install lang.. && killall gnome-panel
<segfault> haven't tried the language selector though
<Kamion> I suppose it might be possible to make casper do that if you have Internet access, but it would require an extra question and we're generally trying to reduce questions rather than add them
<Kamion> dunno ...
<segfault> how bad is removing /usr/share/doc/* from livecd? :)
<pkern> slomo: I think most of the assumptions were wrong. ):
<slomo> pkern: wonderfull :( what did you test?
<pkern> slomo: I even converted the initrd to cramfs.
<Kamion> removing documentation hardly seems like a good way to showcase a system
<pkern> slomo: It loads the initrd just fine and then bails out not being able to load the root filesystem.
<slomo> pkern: tried with another filesystem? ext3 instead of xfs for example? ;)
<pkern> slomo: That's not the problem I think. IMO /init should be called on the initrd, but it isn't.
<pkern> slomo: The initrd contains all needed modules.
<pkern> slomo: But instead of taking the ramdisk it continues to look for another root fs |:
<pkern> slomo: (The one given by root=)
<slomo> pkern: but root=/dev/hda3 in my case didn't work either
<pkern> slomo: At least the initrd provided does not contain any device nodes because the udev on it has to be started first.
<pkern> slomo: So I guess that the initrd is in fact the root system where init should be started from.
<slomo> pkern: how did you get at all this informations? did you get a shell somehow?
<pkern> slomo: I finally accessed the initrd image with cpio.
<pkern> slomo: Because I was sick of all those trys |: I wanted to just convert it to cramfs, which worked with the old kernel.
<segfault> so, the way is start creating custom localizated liveCDs
<pkern> slomo: But the old kernel (2.6.10-X) uses "linuxrc"
<slomo> pkern: under a working system? yes i looked it too but that didn't help ;) this stuff is not loaded
<Kamion> segfault: that seems a reasonably appropriate thing to do, yes
<pkern> slomo: First by booting off the installation system but I fingered out that the old kernel still works.
<segfault> kamion: is there already any documentation on how create one?
<slomo> pkern: hmm... well... lets wait for BenC or jbailey on that... :)
<pkern> jc-denton: (cd ${TMPDIR} && find . | cpio --quiet --dereference -o -H newc | gzip -9 >${outfile})
<pkern> jc-denton: (From the initramfs website)
<Kamion> segfault: https://wiki.ubuntu.com/LiveCDCustomizationHowTo
<raphaelpereira> hello
<raphaelpereira> some time ago I posted a bug here and on bugzilla, about hibernation on Duron
<raphaelpereira> I haven't received any news from it.
<pkern> slomo: brb
<slomo> pkern: ok
<segfault> kamion: nice, i will start a project to release a customization of it in pt_BR.
<bddebian> \sh: Well I did get in trouble :-)
<Kamion> identifying ways to reduce the size of the core part of the live CD without losing important functionality would also be useful
<raphaelpereira> my hibernation is working so well that i really want others to take advantage of it
<Kamion> of course the argument will always be over what's important functionality
<\sh> bddebian: uhm..why?
<bddebian> \sh: I got an e-mail from doko saying a sync was already requested :-(
<\sh> bddebian: hmmm....bad luck I think
<segfault> will look into that too
<bddebian> It's frustrating because I'm trying to clean up all these lists and trying to take some of the load off of elmo having to sync everything.. :-(
<\sh> bddebian: don't worry about it
<pkern> slomo: Haha.
<slomo> pkern: ?
<pkern> slomo: One step further, but /init seems the wrong approach.
<pkern> slomo: I got it to boot from the initrd, but init terminated and thus the kernel panic'ed.
<slomo> pkern: why did init terminate? and what did you do?
<pkern> slomo: I'll look into this script now, if I was right or wrong to call it.
<raphaelpereira> I would like to know the status of hibernation scripts for next release
<pkern> slomo: root=/dev/ram0 init=/init rw ramdisk_size=<the provided-value> into append of yaboot.conf
<pkern> slomo: But it is obviously still wrong.
<raphaelpereira> hibernation wasn't working on my Duron and I found a workaround... now it works flawless
<slomo> pkern: isn't it /bin/init?
<pkern> slomo: If anything then it's /sbin/init ;)
<slomo> pkern: yes... typo :)
<Kamion> raphaelpereira: it seems that nobody interested is currently around (well, it *is* Sunday evening, here at least ...) - try posting to ubuntu-devel@ instead?
<hughsie> lu|away, desrt: can i use php on the gnome.org servers?
<pkern> Could the kernel run a shell script as init or would it fail? I thought that it is not possible to do that.
<raphaelpereira> Kamion, ubuntu-devel@ubuntu.com?
<slomo> pkern: i don't think it can run shell scripts...
<pkern> slomo: I thought that same but probably I see enough evidence here. |:
<jc-denton> pkern: wow cool
<jc-denton> k will try again
<pkern> I want that this bloody kernel runs until tomorrow. ):
<slomo> pkern: did you try /sbin/init? or doesn't this exist in the initrd?
<lu|away> hughsie: no
<pkern> slomo: The kernel checks more than /sbin/init, but that's not the problem.
<lu|away> hughsie: the last breakin at g.o was via php
<slomo> pkern: ok
<hughsie> lu|away: bugger.
<pkern> slomo: I am not allowed to mess with "root=", but the kernel does not drop to the initrd but to root=.
<pkern> slomo: I'll beat the devil out of this script ):
<Kamion> raphaelpereira: @lists.ubuntu.com
<lu|away> hughsie: yeah
<slomo> pkern: thanks for looking into this :) i'm too busy for such stuff currently
<pkern> slomo: I hack it to work but I'm not getting to a clean solution ;)
<slomo> pkern: as long as you get a solution... tell about that in the bugreport then :) but do it with a initramfs please ;)
<jc-denton> ah
<jc-denton> hrmm
<jc-denton> i think the problem is that my initrd.img is on a different hd then root
<pkern> If this works... then... |:
<slomo> pkern: but the real question is why it works for other ibook g4 ;)
<pkern> Ok it doesn't... Hm.
<pkern> slomo: Does it?
<slomo> pkern: yes
<pkern> slomo: How could you tell? ;)
<slomo> pkern: i asked the laptop testing team ;)
<pkern> k
<slomo> #ubuntu-laptop
<slomo> two people with an ibook g4 were there
<raphaelpereira> Kamion, thanks
<pkern> Both having Breezy and exactly this kernel?
<slomo> pkern: yes
<jc-denton> hrmm
<jc-denton> i tried to setup ubuntu on an external fwhd
<jc-denton> then i noticed that grub has trouble booting from it
<jc-denton> so i moved the kernel with the initrd.img to the ide hd
<jc-denton> but humm
<jc-denton> still does not work
<mirak> hi
<jc-denton> not sure if it loaded my ramdisk
<mirak> why there is not gproftpd in any package ?
<pkern> jc-denton: Turn the quiet boot off, then you see if it loads your ramdisk
<jc-denton> what is quiet?
<jc-denton> no i think i'll try to split up the parition on my internal hd
<pkern> jc-denton: A kernel parameter. Is you don't see a verbose boot it is set.
<jc-denton> yes but which one
<jc-denton> im booting knoppix right now
<pkern> jc-denton: "quiet" ;)
<pkern> Why do I think that I should just install linux-source |:
<jc-denton> i only have ro
<jc-denton> but i think i would have to be really quick to see it
<pkern> slomo: I can't believe that one still needs a two liner kernel patch or so for this... I see posts about that of 2004, but if it's really not in mainline already...
<slomo> pkern: what patch?
<pkern> slomo: Sadly it's *exactly* that problem (http://www.ussg.iu.edu/hypermail/linux/kernel/0404.1/0245.html)
<slomo> pkern: put it in the bugreport :)
<pkern> slomo: "If there is an /init, run it."
<pkern> slomo: JBailey is involved in the development of initramfs... he should know it?
<slomo> pkern: jbailey is the initramfs guy... and BenC afaik the ppc kernel guy ;)
<pkern> slomo: Ouch. |:
<slomo> pkern: ?
<slomo> pkern: did you try that patch?
<pkern> slomo: No, I didn't. But I put the URL into the bug report.
<slomo> pkern: thanks :) let's see what happens
<pkern> Time to finally start up breezy with the 2.4.10 kernel.
<Lathiat> 2.4.10?!
<pkern> And perhaps in any time in the future I'll understand why the gnome-terminal has disappeared from the menus...
<jc-denton> uh there is a 2.4er kernel for it?
<pkern> Lathiat, 2.6 ;)
<pkern> Lathiat, sorry.
<jc-denton> lol
<jc-denton> im curious if the gnome terminal is finally usable
<fabbione> Kamion, mdz: ping?
<Lathiat> jc-denton: always has been
<pkern> Oh yeah... all fscked up... Because I had my Gnome 2.10 in my home dir...
<jc-denton> but it does not ask on install?
<Lathiat> pkern: terminal has moved to accessories
<pkern> Lathiat: Thanks but why? And all the other things like "Root Terminal" are also disappeared...
<Lathiat> pkern: mark asked it to be moved
<Lathiat> as for root terminal
<Lathiat> no idea about that
<pkern> It was nice that I nuked my home directory accidentally while installing breezy on my desktop because all went smoothly then. But upgrading to Gnome 2.12 messes with the icons just again.
<doko> bddebian: no trouble, it's just unnecessary, same for gnustep-gui, which did enter unstable today
<jdub> root terminal should never really have been there, it was pretty evil
<pkern> jdub: Why? ;)
<bddebian> doko: -2 for gnustep-gui?
<fabbione> jdub: mind to approve a mpeg2dec upload? it's one line change to fix FTBFS on sparc and contained in a #ifdef SPARC #endif block 
<jdub> because a) if you know you need a root terminal, you don't need an icon (or know how to create one), b) encouraging use of root without sudo is a bad idea, and c) it ran *gnome-terminal* as root, not the shell
<jdub> fabbione: will have to wait for mdz or kamion
<fabbione> jdub: is that a yes. because i read <jdub> SURE GO AHEAD!
<fabbione> ;)
<jdub> heh
<doko> bddebian: yes
<jdub> if it's minor and makes sense, you may as well shoot first and ask questions later
<fabbione> it doesn't touch any common code
<fabbione> and it fixed FTBFS
<bddebian> doko: Grr, it's soo hard to keep up. :-)
* fabbione fires...
<pkern> ...and fabbione forgets.
<pkern> ;)
<slomo> pkern: ask fabbione if the patch is included in the kernel
<fabbione> well let's put it in this way
<fabbione> in the worst case a nuclear war head will knock on my door...
<pkern> slomo: I'll rebuild the kernel image now because I'm tired of it now. ;)
<pkern> fabbione: Because you are a terrorist and because of Bush's new policies?
* pkern hides
<tseng> uh
<slomo> fabbione: is this patch included? http://www.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.6/2.6.5-rc3-aa1/initramfs-search-for-init
<tseng> keep that out of here, please.
<fabbione> *cough*....
<fabbione> slomo: did you check the kernel already?
<slomo> fabbione: nope... i thought you maybe have this in memory :) i'll check it later then ;)
<fabbione> slomo: ok.. i understand you guys think i am some kind of insane nerd with robotic brain on some kind of AI crack...
<bddebian> heh
<fabbione> but despite what you think.. i have a life and a wife..
<fabbione> i truely can't remember the few millions line of code of the kernel :)
<bddebian> Oh if you have a wife, you have no life. ;-P
<crimsun> way to shatter my image of you, fabbione. :-P
<fabbione> but thanks for believing i can do that
<slomo> fabbione: no... i meant it that way, sorry :( i just thought that you could remember adding it or something... :(
<fabbione> slomo: i know jbailey did push me a patch to make initramfs work
<fabbione> but i don't check stuff coming from trusted people
<fabbione> i just apply them
<fabbione> if they break i know who to blame and crossburn
<fabbione> ;)
<slomo> hehe... i'm downloading the source atm :)
<xTina> Just making sure I don't have wrong assumptions about Gnome in the final breezy release: The evolution icon in the menu bar is gone for good, isn't it?
<xTina> (I will need to print our user manual a few days before the final breezy release, so I will have to make screenshots before it's actually released)
<pkern> slomo: It is.
<slomo> pkern: ok...
<Kamion> fabbione: retroactively, that's fine
<Kamion> xTina: no, that was a mistake as far as I know
<gouchi> Hi 
<gouchi> is it ok for a bugreport to submit ?
<pkern> o_O
<gouchi> http://paste.ubuntulinux.nl/2093
<gouchi> dunno how to use ksymoops
<gouchi> how to use ksymoops ?
<fabbione> Kamion: ok, thanks. i am working on 5/6 pkgs that are FTBFS on sparc. If i can limit the change to a #ifdef sparc (or similar) without changing common code, can i just upload?
<fabbione> they are the last 5/6 to make all of main :)
<bddebian> Ack, if I didn't do -v<version> and uploaded will it get silently rejected or will it wait for intervention?
<gouchi> crimson : bugreport about Intel HD audio crash is here http://bugzilla.ubuntu.com/show_bug.cgi?id=15031
<crimsun> ack
<crimsun> wish his nick complete had worked :/
<bddebian> crimsun: Do you know the answer to my question above?
<mdz> fabbione: pong
<bddebian> mdz: If I didn't do -v<version> and uploaded a newer merged version (from MOM) will it get silently rejected or will it wait for intervention?
<mdz> bddebian: neither
<bddebian> neither?
<mdz> neither.
<bddebian> What will it do?
<mdz> it will be accepted unless there is something else wrong with it
<mdz> but the .changes sent to the breezy-changes list will be incomplete
<bddebian> Well I uploaded quite a while ago and haven't gotten any response from katie
<mdz> use your ubuntu.com email address for uploads to ensure that you receive mail from katie
<bddebian> My ubuntu.com e-mail isn't working. :-(
<bddebian> Uhm, duh again.  I uploaded with my key but left the merge changelog entry.
<bddebian> I really must have been slipped some drugs last night, I swear.
<mdz> I don't know what you mean
<bddebian> My name isn't in the changelog so I won't get the katie e-mail.
<Kamion> fabbione: yes, although obviously if it really is a common fix don't needlessly #ifdef sparc it
<martinald> hi
<martinald> is bug #11237 fixed yet?
<mdz> martinald: I asked you not to do that
<martinald> well i thought it might of been checked in for preview release but not updated in bugzilla
<mdke> Kamion, anything else you need for that console-data thing?
<mdke> (if you are still around)
<martinald> mdz, is it likely this will be uploaded in time for the final release?
<mdz> martinald: if you have a question about a bug, please file it as a comment on the bug in Bugzilla, rather than asking here.  That will reach the person who is working on that particular bug
<martinald> ok
<martinald> will do
#ubuntu-devel 2005-09-17
<Kamion> mdke: it is my weekend; I'll reply to you when I've analysed the information you sent
<Kamion> mdke: (in other words, I don't know yet)
<mdke> Kamion, np, i just saw you were active so asked on the off chance
<mdke> good night
<Kamion> mdke: just stopping by in between playing wesnoth and going to bed. :)
<bob2> hm
<bob2> mono-asemblies-arch isn't needed anymore?
<slomo> bob2: nope... it's in mono-classlib-1.0 now
<bob2> libdbus-cil Depeds on dbus-glib-1-dev?
<bob2> that seems odd
<slomo> the package is called libdbus-glib-1-dev now... and it is odd ;) tseng?
<bob2> and gnumeric is uninstallable
<slomo> bob2: hum... there is no libdbus-cil... it's libdbus-1-cil and this depends on libdbus-glib-1-1
<bob2> maybe aptitude is being shit
<slomo> hm... you're on breezy?
<bob2> just looking at upgrading from hoary
<slomo> oh ok... libdbus-cil was only in hoary and depended on dbus-glib-1-dev...
<slomo> and gnumeric should be installable on breezy ;) what error do you get?
<bob2>   gnumeric: Depends: libgoffice-1 (< 0.0.4) but 0.0.4-1 is to be installed
<elmo> goffice was only just synced
<elmo> I'm sure seb will fix it later today
<bob2> ah, thanks
<slomo_> elmo: did you already read my mail about ffmpeg?
<elmo> slomo: I've got some concerns about demoting it to multiverse when debian have it in main
<elmo> but I realise I've been dragging my feet
<elmo> I'll try and reply to you tomorrow, sorry
<slomo_> elmo: our current version could stay in universe... as it's in debian... but i wanted to upload marillat's version to fix some bugs in the debian package and marillat's has to be in multiverse... but thanks for looking at it tomorrow :)
<jay> Does anybody know if this whole HP all-in-one subsystem is supposed to be run even if there is not one installed?
<infinity> jay : Yes.
<jay> infinity: any idea why?  it seems to use a lot of memory while covering a very small use case %
<infinity> jay : Because it is?... It would probably be better to start it from hotplug, but we don't have the time to do that and make sure it works in all cases.
<infinity> jay : On the other hand, hplip covers a reasonably large range of printers and all-in-one devices, so we'd like it installed by default.
<infinity> jay : And no, I don't own one, yes, it runs on my laptop at boot, no, I don't mind much.
<fabbione> morning guys
<xTina> waaah!
<xTina> 6 am!
* xTina screams in horror and is off to bed
<daniels> ... well, good morning to everyone *else*.
<Burgundavia> morning daniels 
<fabbione> hey kid
<daniels> sup
<fabbione> just woke up
<fabbione> hmmmm
<fabbione> 15008 is going to give headacke
* fabbione has the feeling that sudo isn't to blame at all
<daniels> no, it's the fact that entirely-numeric hostnames a) are complete crack, b) violate RFCs left right and centre IIRC
<fabbione> nope
<fabbione> you are allowed to have numeric only hostname
<fabbione> but yes.. they are pure crack
<elmo> there definitely was a RFC which at least said SHOULD not start with a number, but I don't know if got superceded
<fabbione> elmo: i will need to dig them anyway
<fabbione> because if all numeric is allowed, that's a glibc bug in the resolver
<fabbione> if it isn't it's a bug in the installer that allows that
<elmo> well, sudo shouldn't really die on regardless of what the resolver returns
<elmo> it only needs the hostname for !ALL
<elmo> and fragile sudo when, by default it's the only path to root, is baaad
<fabbione> if the user sets manually such a hostname, an hologram should appear in the room and beat him to a slow painful death
<fabbione> elmo: yes i agree on that too, but we also need to prevent a non RFC compliant situation too
<infinity> The RFC about not having a domain name starting with a number was superceded.
<infinity> Hence why 3com.com (and my domain, 0c3.net) are now legal.
<infinity> But I'm still unsure about a host part that's entirely numerals.
<fabbione> i still need more coffee before i can be alive enough to poke into RFC
<daniels> alternately, you could not wake up at 6am
<daniels> (why elmo's awake yet/still awake, I have no idea)
<fabbione> daniels: i just can't sleep longer...  i got so used to wake up at this time that my acpi goes crazy
<fabbione> i blame mjg59 
<mdz> fabbione: back from the grave?
<fabbione> mdz: i was back already last thursday
<fabbione> i just didn't spend too much time on IRC
<mdz> fabbione: you said you were not entirely feeling better yet
<mdz> how are you now?
<fabbione> mdz: that's right, thursdy i was still a bit shaky..
<fabbione> much better..
<fabbione> thanks
<fabbione> but it will take sometime to recover 100%
<fabbione> it seems like that my body crashed because i tend to have blood sugar drops too fast
<fabbione> so now i had to change my diet completely
<fabbione> and it's a slow recovery
<fabbione> the high fever was a consequence of the crash
<fabbione> (at least according to the doc)
<mdz> it's good that you rested
<fabbione> anyway.. the only annoying part is that i need to eat very often and extremely balanced
<fabbione> but the firsts results are already showing up
<fabbione> mdz: yes.. i got scared
<fabbione> AHHHHHHHH cool!!!! finally the ocfs2 fix for the tcp pressure is in
<fabbione> and no abi changes :!
<desrt> so
<desrt> i hear that 2.6.13 is gonna be shipped with breezy
<fabbione> desrt ????
<infinity> fabbione : As I read RFC952, and the clarifications in 1123 and 3696, all-numeric parts are allowed for any portion of a hostname, except the TLD.
<fabbione> infinity: ok.. so it is a valid hostname
<infinity> fabbione : Unfortunately, yes. :)
<fabbione> mdz: i am also working in fixing the last 2/3 sparc FTBFS.. since the changes are not relevant to other arches, am i good to go without pestering you and kamion any further?
<infinity> (The restrictoin against all-numeric TLDs is what stops you from confusing a hostname with an IP)
<fabbione> infinity: that's good.. it makes thing simpler
<mdz> fabbione: yes
<fabbione> mdz: ok thanks
<fabbione> if we can get the fixes to klibc, we will even be able to install!
<infinity> Hrm, actually glibc is probably doing the right thing.
<infinity> If he has no domain assinged, then his hostname is also his TLD.
<fabbione> infinity: eh????
<infinity> Well, is it resolving "1234" with no domain search, or "1234.something.com"?
<fabbione> infinity: the user has a domain search
<fabbione> look in the bug
<infinity> Oh, then glibc is wrong. :)
<fabbione> so indipendently or not, the hostname is also in /etc/hosts that by default is preferred to dns lookups
<fabbione> infinity: yes, that's what i am afraid of
<fabbione> and probably the latest sudo workarounds a glibc bug
<fabbione> but we have jbailey!
<infinity> The /etc/hosts case is a weird corner case, though.
<fabbione> infinity: it's not a corner case... there many things that can happen before hitting a dns lookups
<infinity> If his /etc/hosts contained "127.0.0.1 1234.domain.com 1234", it would probably work.
<infinity> (untested)
<fabbione> infinity: there can be nis/samba/whatever lookup
<fabbione> infinity: i am going to test these cases as soon as i can get my workstation free...
<fabbione> i can't efford to get it down right now
<dilinger> jbailey: ping
<fabbione> hey dilinger 
<dilinger> hey
<fabbione> infinity: i am looking at #15187
<pitti> Hi
<desrt> w3rd.
<desrt> pitti; you poke the cdrtools bug yet?
<Burgundavia> pitti, did the work by carstenh on the firewall come to frutition?
<pitti> Burgundavia: it's not finished yet; the concept is good, but the backend needs much loce
<pitti> love, even
<pitti> desrt: not yet, weekend was busy
<Burgundavia> pitti, ok, just wondering
<pitti> Hey JaneW 
<ajmitch> evening all
<fabbione> hey pitti
<pitti> Hi ajmitch 
<pitti> Moin fabbione 
<fabbione> hi Jan
<ajmitch> so if I do manage to come to UBZ, what days should I care about? just the ubuntu days?
<jsgotangco> wow ajmitch is going to UBZ
<ajmitch> jsgotangco: if I pay my own way
<ajmitch> jsgotangco: found cheaper flights
<jsgotangco> ajmitch, that's a lot of money!
<ajmitch> I might make a short holiday of it afterwards
* ajmitch has no wife & family to spend money on :)
<jsgotangco> yeah
<pitti> mjg59: ping
<ajmitch> I think I need to get out of this town every few months to stay sane
<Burgundavia> ajmitch, how big is where you live?
<ajmitch> Burgundavia: about 120K people
<Burgundavia> ajmitch, that is not that small
<jsgotangco> there is a smaller place?
<ajmitch> yes
<ajmitch> I come from a town of 4000
<jsgotangco> wow i live in an overcrowded country indeed
<ajmitch> there's maybe a million or so people in the south island
<Burgundavia> jdub, shall I create a MenuReThink spec?
<jdub> Burgundavia: sure!
<jdub> Burgundavia: perhaps 'MenusRevisited'
<Burgundavia> sure
<JaneW> hi pitti
<Burgundavia> jdub, https://wiki.ubuntu.com/MenusRevisited
<jdub> Burgundavia: "radically altered" -> "had a top-down review"... surely the aim is not to radically alter things willy-nilly :)
<Burgundavia> jdub, yes
<pitti> desrt: btw, what do you mean by cdrtools breakage?
<desrt> pitti; i have a bug open assigned to you
<desrt> mkisofs produces bogus output on ppc
<ajmitch> jdub: you're an enthusiastic fellow, got ideas for writing up a bug day announcement?
<desrt> http://bugzilla.ubuntu.com/show_bug.cgi?id=14990
<pitti> desrt: ah, this one; ok
<desrt> pitti; it's absolute retardedness
<pitti> desrt: really odd, too
<desrt> pitti; jrg shilling stole mjg59's gpl
<desrt> pitti; basically... cdrtools uses this really messed up makefile system called shilly
<desrt> pitti; and it complains about a 'bug' in gmake
<desrt> and accuses gmake of being unmaintained
<desrt> and recommends the use of smake
<desrt> so i'm wondering if somehow that's causing the makefile oddness
<ajmitch> hi AndyFitz 
<AndyFitz> g'day ajmitch
<pitti> jordi: Hi! Do you know about http://savannah.gnu.org/patch/index.php?func=detailitem&item_id=4407 ?
<dholbach> good morning
<mvo> good morning dholbach 
<ajmitch> hi dholbach, mvo 
<dholbach> mvo: hey michael, how is it going?
<dholbach> morning seb128! :)
* mvo waves to ajmitch 
<seb128> hey dholbach
* mode/#ubuntu-devel [+o fabbione]  by ChanServ
* mode/#ubuntu-devel [-b *!n=chmj@*]  by fabbione
* mode/#ubuntu-devel [-o fabbione]  by fabbione
<Burgundavia> seb128, g-a-i is missing a seperator above it on the menu
<Burgundavia> seb128, and good morning
<seb128> hi
<seb128> I don't care, we are UI frozen and that would require some good panel patches but I've other stuff to di
<seb128> s/di/do/
<Burgundavia> seb128, ok, jdub just pointed me at you when I told him
<fabbione> dholbach: ping?
<dholbach> fabbione: pong
<fabbione> dholbach: what's your BZ email address?
<dholbach> fabbione: dh@mailempfang.de
<seb128> dholbach: run away, NOW :)
<dholbach> seb128: fabbione likes me :)
<seb128> he he
* ajmitch wonders when dholbach will start maintaining FF :)
<dholbach> ajmitch, seb128, mvo, pitti: would you please drop it
<dholbach> ajmitch, seb128, mvo, pitti: thank you
<ajmitch> hehe :)
<seb128> I was thinking about that when I've patched firefox yesterday
<seb128> "where the heck is Daniel, he should be doing it" :)
<jdub> oh, is dholbach taking over ff? rock!
<dholbach> *cry desperately*
<seb128> hey jdub
<ajmitch> better him than me :)
<pitti> stop bitching about the poor guy - he is supposed to help seb with breaking the panel...
<fabbione> dholbach: you wut 15183
<fabbione> ops
<Burgundavia> seb128, shall I send you patch for applications.menu?
<fabbione> s/wut/win
<dholbach> fabbione: thanks, i'll have a look
<seb128> Burgundavia: a patch for what? the menu is fine this way
<fabbione> dholbach: i already did some debugging
<fabbione> dholbach: so it should be farly easy
<Burgundavia> seb128, to add a seperator between add programs and the system tools, like run applications used to have
<dholbach> fabbione: thank you... that's very nice :)
<seb128> Burgundavia: that's not that easy, you need to patch gnome-panel source code
<Burgundavia> seb128, ick
<Burgundavia> seb128, why?
<seb128> because there is no separator element for the .menus
<jdub> seb128: (the previous time we had g-a-i there, it was fixed to have a separator - it was rad)
<daniels> pitti: seb doesn't need any help breaking the panel, he's great at doing at that on his own
<seb128> jdub: not true, we reverted the changes because neither mvo or me wanted to start hacking the panel for that (and it was quite ugly)
<jdub> oh
* mvo nods
* jdub was sure he had a separator at one stage
<jdub> perhaps i was toking too hard
<Burgundavia> jdub, we did, for run applications
<seb128> nop
<seb128> that was upstream code
<jdub> Burgundavia: different issue
<seb128> we didn't do anything
<pitti> Hi Mithrandir 
<Burgundavia> seb128, if it involves icky codes changes, forget about it. Too bad that kind of stuff is not simply built into the .menu spec
<dholbach> Mithrandir: morning tollef :)
<herzi> hey all
<HiddenWolf> seb128, are you aware of any problems with nautilus-cd-burner blanking discs? It seems to lock the disc down so it can't blank it for me.
<seb128> HiddenWolf: your description is weird, but taking a guess I would blame pitti's plugdev change
<HiddenWolf> seb128, I want to burn something to a full -rw, so nautilus offers to blank, then pops up an error that it can't write to disk.
<seb128> https://bugzilla.ubuntu.com/show_bug.cgi?id=15098
<HiddenWolf> killing nautilus and using cdrecord does the trick.
<seb128> can you try with the previous udev package?
<pitti> HiddenWolf: right, will fix ASAP
<HiddenWolf> pitti, good man. :)
<fabbione> dholbach: you have davis :)
<Mithrandir> good morning dholbach 
<dholbach> http://www.heise.de/newsticker/meldung/63799 - unfortunately it's in german, but they say that HP loves us :)
<Treenaks> do we love them back?
<bob2> an rdns-less scott
<\sh> dholbach: i think there has to be also an english announcement, because it was in south africa
<\sh> http://www.tectonic.co.za/view.php?id=595
<\sh> this si the english article
<pitti> HiddenWolf: udev fixed
<HiddenWolf> pitti, great
<HiddenWolf> dholbach, search for Ubuntu HP
<HiddenWolf> dholbach, you'll find articles left and right
<HiddenWolf> including tomshardware, heise, south african newspapers
<Treenaks> HiddenWolf: tomshardware was oldn ews
<Treenaks> HiddenWolf: from may
<seb128> pitti: thanks for the quick fix on this udev bug
<pitti> np, sorry for the breakage
<HiddenWolf> Treenaks, still news. :)
<mvo> seb128: gnumeric is uninstallable right now?
<seb128> mvo: how so?
<dholbach> seb128: libgoffice* removes it
<jdub> anyone have recommendations for a thin, 14"-15" notebook for pipka?
<seb128> mvo: short story: I've asked for libgsf/goffice syncs saturday and elmo did that this night, I've to catch with gnumeric now
<dholbach> seb128: maybe it needs a recompile or something? or maybe it was libgsf? *has a look*
<seb128> dholbach: I'm on it
<dholbach> seb128: super
<bob2> jdub: t42!
<jdub> bob2: how thin are they?
<dholbach> seb128: mvo pushed me towards *bluetooth - i have a look at those again
<mvo> seb128: thanks (I'm going over the desktop files of g-a-i right now)
<mvo> to make sure that the stuff is installable
<seb128> mvo: np
<daniels> jdub: the T series isn't that much thicker than X
<daniels> maybe 1.5x
<jdub> hmm
<jdub> IBM might be a bit 'spensive
<daniels> but don't take my word for it, check the epscs
<daniels> and the specs
<daniels> i have to put raster on /ignore, he's making me typo too much
<daniels> osmosis
<infinity> Yeah, the T-series are pretty dang thin.
<infinity> Just much larger desk area, cause the screens are big.
<bob2> powerbooks certainly look thin
* daniels hugs his X40.
<daniels> bob2: they aren't thin at all
<bob2> and you get 15% off if you're a student
<daniels> bob2: the 12" PB is about twice as thick as my X40
* bob2 hugs his x40 too
<daniels> bob2: and weighs way way more
<daniels> (2.2kg as opposed to 1.2/1.47kg)
<sivang> Morning all!
<sivang> T's looks cool, and yes, they don't seem thicker then X's
* HrdwrBoB hugs hus X40 as well, while we're at it
<daniels> jdub: you should hug your X40 to ... oh, wait.  nevermind.
* Mithrandir ruffles his x40
<HrdwrBoB> jdub: I picked up my X40 off ebay for $700 sans battery and hdd which cost $320
<daniels> Mithrandir: and bob2 loves your x40 as well
<Mithrandir> daniels: yeah, I know.
<Mithrandir> daniels: especially the corner the farthest away from the hard drive.
<bob2> dang, ifrename doesn't let you rename eth0:1 interfaces
<Mithrandir> don't use ethX:Y interfaces, then?
<Mithrandir> they're so mid-1990s
<sivang> speaking of which, I reckon we do support T43 out-of-the-box ?
<bob2> Mithrandir: shorewall appears to puke if I just stick my DSL modem and local network on the same interface
<Treenaks> sivang: see the LaptopTestingTeam page
<bob2> and it's 1849, so no new NIC tonight
<Treenaks> sivang: I saw one on there
<sivang> Treenaks: k, thanks
<daniels> bob2: so don't use shorewall
<bob2> daniels: but I'm no iptables hacker, it's too hard for me!
<HrdwrBoB> iptables is easy
<daniels> bob2: maybe you need to become a Linux Kernel Developer, then
<bob2> boomtish
<daniels> bob2: step one: borrow rusty's books.  step two: return them three and a half year slater.
<bob2> HrdwrBoB: yeah, yeah, but trolling daniels is not
<sivang> daniels: I have RML's book, mind booming :)
<infinity> sivang : I'm working on a T43 right now.  Everything works fine, except the video is woefully unaccelerated, because we don't support PCI express video yet.
<daniels> sivang: i'm sorry to hear that
<sivang> daniels: why ?
<infinity> (Oh, and it crashes at least once a day, but other than that... <sigh>)
<daniels> oh, sorry
<daniels> i thought you sai dd rms for a second
<daniels> rml's cool though, and by all accounts, his book is good also
<sivang> infinity: Hmm well, guess it'd make a good support testing machine :-o ? :_)
<sivang> daniels: funny as it should, however you need to give some of the section 2nd and 3rd read
<Mithrandir> infinity: hmm, sure we don't support PCIe?  My nvidia works fine..
<infinity> Mithrandir : It's set up as pure PCI, and slow as a dog.  Unless you're using binary drivers.
<jdub> yeah, don't want X series -> 12" not useful for pipka
<infinity> Mithrandir : Unless the nv driver recently got PCIe support, then it's just radeon that's behind the curve.
* infinity looks at daniels.
<daniels> Mithrandir: actually, we do support PCIE, it's just that it's too late in Breezy to backport all the open source PCIE 3D acceleration for ATI
<daniels> infinity: stfu
<infinity> jdub : I heart my 1400x1050 display on my T series.
<jdub> infinity: that'll be pretty tempting
<Treenaks> infinity: ctrl+shift+2665
<daniels> i heart my stable laptop
<sivang> infinity: it's using nvidia based circuits?
<infinity> sivang : No, the T43 is ATI-baed, mine's an X300.
<infinity> s/baed/based/
<HiddenWolf> infinity, x300 is ati
<infinity> HiddenWolf : Yes, and?
<sivang> infinity: I see, because when I looked at IBM's site, they have "Intel Accelerated Graphics" nor ATI/nVidia and I was wondering if the ditched them altogether.
<infinity> HiddenWolf : Did I ever claim it wasn't?
<mjr> daniels, hm, now that you mentioned it, will there be any (even remotely working) r300 code in breezy's X?
<Mithrandir> infinity: I'm using binary drivers, yes, but iirc that's because that was the easiest way to get xinerama working. :-P
<infinity> daniels : Feh, it's never too late to backport a mess of drivers to support newer hardware.  Clearly, I need to start a petition.
<jdub> it's a pity that it's so hard to rip the hdd out of the toilet seat ibooks
<infinity> With a chainsaw, nothing is impossible.
<jdub> tempting
<jdub> i think i'm going to rehouse the machine
<sivang> infinity: lol
<sivang> Mithrandir: and you have all hw-accel with the binary drivers?
<mjr> infinity, right you are; "Well, can you knit a sweater with a chainsaw?" "The _real_ question is *brmmm* do you want to make me one, now?"
* jdub cheers for elite stage two progress bar
<Mithrandir> infinity: have _a bit_ of style, use a dremel
<Mithrandir> sivang: iirc, yes.
<Mithrandir> sivang: I'm not at home now, so I can't check right now.
<daniels> mjgr	no
<sivang> Mithrandir: well, seems that's my next dream laptop
<doko> watch the trolls (german), "HP im Ubuntu Fieber" -> http://www.heise.de/newsticker/meldung/63799
<Mithrandir> sivang: it's a desktop, not a laptop.
<sivang> Mithrandir: oops, I had in mind the T43 ;)
<Mithrandir> sivang: I have an X40, not a T series.  \infty has a T series
<mjr> daniels, bummer
<daniels> mjr: tell me about it
<sivang> infinity: let me know if you get hrdwr-accel working with bin drivers
<daniels> mjr: but it's about 200,000 lines of stuff to backport.  i know how much it sucks -- my desktop is a pcie ati chip.
<infinity> sivang : No luck there, fglrx doesn't appear to work on my laptop, so I'm stuck with the Xorg radeon driver.... Which would be good, but it's desperately in need of some CVS updates first.
<daniels> (and Mesa DRI, and kernel DRM, and ...)
<mjr> yeah, I get it
<daniels> oh yeah, and airlied fixed PCIE after anholt committed Exa
<daniels> so we'd need to backport all of exa
<mjr> :)
<daniels> which, I mean, exa is really good, right ...
<Mithrandir> daniels: you mean you don't want to support a CVS snapshot of xorg for 18 months?
<mjr> on my home box, I'd be content with the AGP stuff. Though at work, I'll need to support PCIE boxes quite soon...
<daniels> Mithrandir: *SHOCK*
<Mithrandir> daniels: sissy!
<daniels> mjr: eh, if youi *need* to support it, just grab CVS
<Mithrandir> :-)
<mjr> daniels, yes, I know how, was just wondering how much of the pain will I have to endure personally ;)
<daniels> mjr: i did packages for the server a couple of weeks back anyway, so maybe I'll update them and throw them on p.u.c when I have some spare time
<mjr> yah, thanks
<jdub> daniels: is xephyr rough to build?
<jdub> might be fun to have it in universe
<daniels> jdub: ross is packaging it, along with kdrive and shit
<bob2> hah
<sivang> daniels: I might be in for some of that backporting stuff if you and infinity would show me around ;-) (and I'll have my T43 there)
<sabdfl> moin moin
<pitti> Hi sabdfl 
<sabdfl> a small announcement:
<sabdfl> YOU GUYS ROCK
<Mithrandir> sabdfl in da house.
<dholbach> :)
<dholbach> hi mark
<jordi> heh
<Mithrandir> sabdfl: what have done now?
<pitti> sabdfl: thanks :-)
<Lathiat> moin sabdfl :)
<sabdfl> fabbione, benc: my desktop keeps hanging, how can i give you debug feedback?
<jordi> pitti: yes, didn't you get a mail from me?
<sabdfl> it locks hard
<fabbione> sabdfl: morning.. sure
<fabbione> sabdfl: what kernel?
<pitti> jordi: hm, can't remember
<sabdfl> breezy standard
<fabbione> sabdfl: did you upgrade recently?
<jordi> pitti: hm. what's your email address?
<sabdfl> fabbione: current as of saturday
<pitti> jordi: martin.pitt@ubuntu.com
<Lathiat> fabbione: mjg59 mentioned an issue with sata stuff where accessing the cdrom at the same time as the hdd results in a hard locK (and we guess tahts whats locking my laptop) any idea about that / when we'll get the fix in ?
<jordi> pitti: heh. I mailed pitti@
<fabbione> sabdfl: meh.. what kind of load do you have on the machine?
<jordi> pitti: bounced.
<jordi> pitti: in short, I asked for a CVE number
<sabdfl> fabbione: little, it's locked up during screensavers mostly. not even gl screensavers
<fabbione> Lathiat: no, i have no idea, because i am not tracking the kernel anymore
<Lathiat> fabbione: oh ok
<Lathiat> fabbione: i'll go make it someone elses problem then ;)
<sabdfl> hmm... Lathiat might have the same problem as me, it's SATA
<fabbione> sabdfl: it's always reproducible? on what kind hw is it?
<pitti> jordi: can't find one
<sabdfl> Lathiat: need to talk to BenC
<Lathiat> sabdfl: ah 
<daniels> sivang: seriously non-trivial
<jordi> pitti: this was saturday, they may have not processed it.
<sabdfl> fabbione: reproducible in the sense that the desktop has locked most mornings overnight
<seb128_> jordi: about what?
<Lathiat> sabdfl: yeh apparently thats the problem and that it would be fixed but i odn tknow any more
<fabbione> sabdfl: let me take a look on what's boiling in baz...
<fabbione> sabdfl: perhaps there is a fix already committed
<jordi> seb128_: mailutils
<jordi> pitti: saw the LWN article re: security? sad...
<jordi> ubuntu is rocking so much in that regard
<pitti> jordi: I am not subscribed, which article?
<seb128_> jordi: you can reassign the epiphany-browser one to mozilla
<Lathiat> sabdfl! you cursed me, it just locked then.
<jordi> pitti: LWN compared the response times to vunerabilities for a few distros
<ajmitch> Lathiat: ouch, I haven't seen it on mine
<pitti> jordi: ah, that one, I read it on sounder
<jordi> Debian's numbers were horrible.
<seb128_> pitti: the one pointed by mdz when you replied you have not subscribsion
<jordi> seb128_: sure
<jordi> pitti: got my mail?
<ajmitch> Lathiat: except I haven't been using the cd much
<Lathiat> sabdfl: try keeping a cd in the drive
<pitti> jordi: second please, in the middle of USN release
<jordi> oh, heh.
<jordi> sorry.
<ajmitch> hey jordi 
<sabdfl> Lathiat: i do have one in the drive. audio cd, and it's been locking. could be the same?
<Lathiat> sabdfl: umm, try taking it out then? :)
<sabdfl> Lathiat: it's a home box, will try it tonight
<Lathiat> okie
<Lathiat> i have no idea how specific this problem is so not sure if tis the same one
<Lathiat> find out i guess
<pitti> jordi: mail looks fine, you should get a reply soon
<fabbione> sabdfl: sorry.. i need a few more minutes.. baz is taking ages to update
<doko> pitti: please review pootle / translate-toolkit for inclusion in main
<pitti> doko: yep, already saw the mail
<doko> pitti: note, that translate-toolkit is in unstable only, and needs to be synced, so better take the package from unstable
<sabdfl> doko: happy for it to be in universe, but main implies support, and i'd rather just support rosetta
<HiddenWolf> Guys, i'm trying to use linda, and it's looking for it's files in /usr/lib/site-python/ and not /usr/lib/python2.4/site-python/
<doko> sabdfl: therefore the renaming to translate-toolkit and the removal of the pootle files. but currently we need it convert the OOo2 language data to po files. However, we can do after the build as well
<fabbione> sabdfl: you are experiencing this problem http://bugzilla.ubuntu.com/show_bug.cgi?id=13370 <-
<fabbione> sabdfl: and it claims to be fixed in baz..
<sabdfl> doko, fabbione: thanks
<fabbione> sabdfl: would like a test kernel?
<fabbione> sabdfl: because that would sort of rock :)
<sabdfl> doko: if we need it for our own processes then main is fine
<sabdfl> fabbione: sure
<fabbione> sabdfl: ok.. i will build it for you, but you will have to upgrade it manually later, when final will be out...
<fabbione> or at least i think you will have to
<fabbione> Lathiat: what kernel flavour would like? so you can test it too?
<Lathiat> fabbione: 386 is fine
<fabbione> sabdfl: for you?
<fabbione> 386, 686?
<fabbione> Lathiat: 686 is ok too?
<Lathiat> fabbione: yeh sure
<infinity> fabbione : Cook up a 686 for me too, yo. :)
<fabbione> infinity: sure :)
* fabbione gets ready to make nagios yell and scream
<daniels> fabbione: pleeeeeeease can we have .13 for breezy? or backported drm? :)
<fabbione> daniels: *cough*beer*cough*
<daniels> i'm getting ready to make my desktop run a non-stock kernel for the first time in its life
<daniels> fabbione: eh, i'll buy you a molson in canadia
<Treenaks> daniels: does that solve the ATI DRI/DRM version mess?
<infinity> fabbione : Any particular reason why we aren't trying to push in .13?
<fabbione> daniels: dude.. i am still waiting beer from UDU :P
<daniels> Treenaks: no, but it gives you open-source DRI for every ATI card that exists right now
<fabbione> infinity: UVF?
<daniels> fabbione: eh, bring me to a conference where I'm not dying
<Treenaks> daniels: whoa!
<infinity> fabbione : Makes more sense to keep rolling upgrades going than to carry around a bunch of patches that make the kernel "almost .13, but not quite".
<Lathiat> daniels: oh nice
<Treenaks> daniels: even the PCIE ones?
<daniels> Treenaks: yes.
<infinity> fabbione : The kernel has a standing UVF exception, does it not?
<Lathiat> Treenaks: woo
<Mithrandir> fabbione: we're not in kernelfreeze, are we?
<fabbione> infinity: nope.. we did freeze the main upstream version with all the other stuff
<fabbione> Mithrandir: almost.. yes..
<fabbione> Mithrandir: we are in strict bug fixing only
<fabbione> and in 2 weeks only security 
<infinity> fabbione : Meh.  Also, meh.  Moving our patches forward ot .13 sounds easier than backporting DRM. :)
<infinity> (I guess we get neither, though)
<fabbione> infinity: i am sure you can manage :)
<fabbione> infinity: and thanks for offering volunteer :P
<fabbione> infinity: portforwarding patches takes around 2 days 
<fabbione> just to kill/rediff
<fabbione> + another 2 days to get * to build
<infinity> fabbione : I'd volunteer to forward-port our patches to .13, but you just told me it's a no-go, so why volunteer to do work that won't be accepted?.. Y'know?
<fabbione> infinity: you can make it ready for breezy+1 and breezy backports
<fabbione> infinity: seriously.. .12 is pretty stable and a pretty decent kernel
<sabdfl> fabbione: 686
<sabdfl> if possible
<fabbione> sabdfl: perfect..
<infinity> If I'm going to run a backport kernel, I may as well just run a non-stock kernel altogether (which I'll probably end up doing)
<fabbione> sure..
<fabbione> few minutes and it will be ready
<infinity> And yeah, I know .12 is the bomb... For everyone who isn't me. :)
<fabbione> infinity: ain't my fault if you buy crappy hw
<infinity> Obviously, I'm being selfish in my wish for working ATI/PCIe acceleration.
<infinity> s/crappy/new/
<fabbione> s/new/crappy
<fabbione> infinity: the DRM patch is way too intrusive to push at this point in time
<fabbione> infinity: i did try to apply what daniels pushed me a while ago...
<fabbione> it was a full reject
<infinity> Oh well.  If this SATA patch fixes my constant crashing issues, I'll cope with slow X.
<infinity> The speed thing isn't nearly as irritating as having the box lockup every few hours "just cause".
<fabbione> wow.. i managed to use 200MB of swap on concordia
<Mithrandir> fabbione: she's too slow, then.
<fabbione> Mithrandir: yes.. i like davis much much more
<fabbione> that's why i am going to buy a powerbook
<bob2> davis has less cylons, tho
<fabbione> bob2: elmo and I unleashed davis power with a 64bit kernel
<Mithrandir> fabbione: I should try building the kernel on rho or pi one day; they're nice-ish boxes.
<bob2> bwahaha
<fabbione> bob2: more RAM.. SMP. no random segfaults
<fabbione> bob2: davis is way faster than concordia
<Mithrandir> just four gigs of memory, but dual 265 and 275s.
<Diziet> I need to get `mozilla-firefox' (a dummy transition package) into main.
<bob2> Mithrandir: your use of "just" offends me and my 512MB laptop
<daniels> only 512MB? wtf
<bob2> fabbione: heh, did you ever figure out what the segfaults were from?
<bob2> daniels: no scotch wraps for you
<daniels> bob2: verdammt
<fabbione> bob2: yes.. running a 32bit unsupported kernel on a 64bit cpu
<bob2> hah
<Mithrandir> bob2: apart from my router, I don't use any boxes with less than 1.5GB of memory.
<fabbione> bob2: make -j 300 is just perfect :)
<fabbione> Mithrandir: we don't all have free hw :P
<daniels> fabbione: says you
<bob2> fabbione: hahaha
<fabbione> daniels: i had freehw when i was working in Ericsson
<ajmitch> Mithrandir: I'd be lucky to have a total of 1.5GB over all my boxes here
<Mithrandir> fabbione: I spent about 2500 on hardware a few weeks ago.  That's my new and sweet home system. :)
<daniels> fabbione: you still scam free hardware of dodgy Danish ISPs
<daniels> i need to blow some cash on a stack more RAM for brainfreeze
<fabbione> daniels: didn't get any yet :/
<fabbione> Mithrandir: ehehe
<daniels> a reasonably nice AMD64, but let down by one slow IDE disk (LVMed with SATA, need to get 3 250GB SATA drives) and only having 1GB of RAM
<daniels> but it's nice matched-pair low-latency stuff, at least
<bob2> you guys all have too much hardware
<fabbione> daniels: i just upgraded the trider-g7 with 4x400GB
<fabbione> almost 2TB of data around me
<daniels> bob2: dude, I only have 200GB here
<daniels> bob2: do you know how much that sucks?
<daniels>  25
<dholbach> does anybody know anything about stuff like  "../libtool: line 1223: 26661 Segmentation fault"  on the ppc buildd?
<bob2> go libtool, it's your birthday
<fabbione> dholbach: hmm sounds like a random segfault...
<Mithrandir> bob2: libtool is a shell script.  It shouldn't segfault. :-P
<dholbach> i hope a "give back" makes me happy :)
<fabbione> Mithrandir: but bash can :)
<bob2> Mithrandir: a shell script which has been Touched by scott
<bob2> who knows what powers it has now
<dholbach> Mithrandir: that's not the first time i see that message on ppc :)
<Mithrandir> dholbach: Iz gtk bug
<pitti> dholbach: that's very common again these days, one or more g-b should help
<dholbach> Mithrandir: hahaha, of course - how could i possibly forget :)
* infinity wonders if there's some way he can blame bash.
<ogra> Kamion, ping
<infinity> dholbach : List of packages that need a give-back, by any chance?
<dholbach> infinity: doko will be delighted :)
<dholbach> infinity: will look at the buildlogs, just a sec
<fabbione> sabdfl, infinity, Lathiat: http://people.ubuntu.com/~fabbione/linux-image-2.6.12-8-686_2.6.12-8.13_i386.deb
<fabbione> it's totally untested.. it builds...
<sabdfl> fabbione: oops. seems like my home machine has locked, will try the package when I get home
<daniels> if I were to compile a list of really terrible failure modes for installing kernels, I'd probably put 'trashing /lib/modules' somewhere near the top
<fabbione> sabdfl: ok thanks
<dholbach> infinity: at least: totem, gnome-bluetooth, udev
<\sh> infinity: ace should be removed from frozenapps libs list...
<dholbach> infinity: (on powerpc)
<seb128> dholbach: what about totem? libtool issue too?
<dholbach> seb128: yep
<seb128> k
<Mithrandir> elmo: please sync blender
<Mithrandir> elmo: please sync sgml2x
<infinity> \sh : Can't unfreeze it until it's built everywhere.
<\sh> infinity: aye...so bmonty has to fix it...i don't touch it 
<infinity> \sh : Looks like it's missing a -fPIC
<daniels> oh wait, I see, it's just trashed my initrd.
<pitti> brb
<seb128> ogra: putting exagerated values don't fix bugs
<seb128> s/values/bugzilla settings/
<ogra> seb128, nope, but notifys them as important
<seb128> nop
<seb128> use the right settings if you want to do this
<seb128> anyway that's not a gamin issue for pretty sure
<infinity> fabbione : I'll let you know in a couple of days if this patch is helping (I think my record uptime for this machine is just over a day, so 2 or 3 should be enough to know if it's helped)
<ogra> seb128, so which would have been the right setting ? i cant releases edubuntu with a randomly dissapearing menu...
<\sh> seb128: u mean this directory scanning?
<seb128> no reason it works fine on a folder and not on an another one. That's probably an app not putting the same monitors
<fabbione> infinity: ok thanks
<seb128> \sh: http://bugzilla.ubuntu.com/show_bug.cgi?id=15239
<seb128> ogra: the settings are no edubuntu specific, this is not a big issue for Ubuntu
<ogra> seb128, its affecting *all* kde apps in the gnome menu apparently... i dont think its a singel app
<\sh> seb128: yes...it happens with ubuntu and with kde apps who are installing .desktop files in kde
<\sh> seb128: after loggin in, it's all there..and after a randomly time it
<\sh> 's disappearin
<seb128> ogra: who spoke about a single app?
<seb128> \sh: somebody who has the issue will have to debug it
<\sh> seb128: how
<ogra> <seb128> no reason it works fine on a folder and not on an another one. That's probably an app not putting the same monitors
<desrt> pitti; ping
<ogra> seb128, you
<seb128> ogra: read it again, the app beeing gnome-menus or gnome-panel
<koke> hey, I'm testing colony-4 in a dell inspiron 1200 and installer is frozen :(
<seb128> ogra: apps just put a .desktop files, they don't monitor anything
<koke> in partman step I guess
<ogra> seb128, yup
<seb128> ogra: so don't say it's not a single app, it is
<seb128> either gnomevfs, or gnome-menus or gnome-panel
<ogra> ok
<Kamion> ogra: yes?
<seb128> \sh: good question, the gamin website an a "how to debug page", that's a good start
<ogra> Kamion, would it be possible to set ClientAliveInterval in sshd by default...
<\sh> seb128: ok....will have a look
<seb128> thanks
<ogra> Kamion, i have many reports about timeout issues with sshd/ltsp.... the session persists for 30 seconds after a client logs out
<Kamion> ogra: no, I'd rather not make that sort of behaviour change from upstream
<seb128> \sh: at least try to get a way to get the menu entries changing .. because "log and wait 5 hours" is not going to work to debug
<Kamion> ogra: so have ltsp run sshd -o 'ClientAliveInterval whatever'
<ogra> Kamion, ah, yes.... thanks... i'll talk to mdz about that ...
<\sh> seb128: if i touch a desktop file under kde/ it's coming back (only this app with the touched desktop file) but I will provide some logs
<seb128> \sh: but any way to get this masked from the menu?
<Mithrandir> elmo: please sync gnome-vfs (universe)
<\sh> seb128: u mean that the kde menus/kde apps or whatever is in subdirs to disappear? no..it just happens
<seb128> yeah
<\sh> and strangewise sometimes it's coming back
<seb128> because "it just happens", sometimes
<seb128> is not something you want to debug :)
<seb128> if you can't trigger the bug to work on it ...
<ogra> my edu menu just appeared again after it was gone for the whole morning ...
<\sh> seb128: lets check...I will debug this first and see how i can trigger it
<ogra> its totally unintentional
<doko> Kamion: ok to sync openjade from unstable to fix FTBFS?
<Kamion> doko: yes
<reinouts> Kamion: ping
<Kamion> reinouts: yes
<Kamion> ?
<pitti> infinity: bah, looking at today's buildd list, powerpc failures seem to be much worse than on other days - particularly bad day for royal?
<reinouts> Kamion: I was told to talk to you about debian-installer translations
<Diziet> OK, I give up.  Anyone here know anything about how Java is supposed to work in our Firefox ?
<reinouts> Kamion: the Dutch GNOME live cd is based on breezy but shows some mixed language messages during boot
<reinouts> do you know where I can contribute the missing translations?
<pitti> Diziet: the Sun plugin doesn't work?
<ogra> Diziet, worksforme with the blackdown packages from multiverse
<Diziet> ogra: Is that (multiverse's) the correct answer ?  Because atm firefox seems to invite the user to faff about with its plugin finder, which fails, and that seems to lead to the `do it manually' route.
<ogra> Diziet, it does that since we got it... disabling the plugin finder would be the right way i guess
<ogra> many users might be hit by that confusion
<Diziet> Hmm.  I don't think I know how to do that but I may be able to find out :-).
<Diziet> The plugin finder has to keep working for Flash support.
<ogra> why ? we offer flash in multiverse too... probably replacing the plugin finder with a option to start synaptic and a hint what/how to install would be right
<infinity> pitti : I'm not really sure, TBH.
<ogra> but thats very intrusive indeed... and i doubt its abreezy feature
<infinity> pitti : I'll have to look more deeply tomorrow.
<Diziet> Oh.  Um, hmm.  I think there are some deeper policy questions here.
<Diziet> Like how much we want to automatically advertise multiverse.
<ogra> yup, that too
<slomo> seb128: i have a bug with patch for you in gst-plugins ;) http://bugzilla.gnome.org/show_bug.cgi?id=315144
<seb128> slomo: thanks
<Kamion> reinouts: depends which ones are missing
<Diziet> kamion: Can you sort out my mozilla-firefox package ?  It needs to be in main.
<mvo> Kamion: can you think of any reason to keep "readahead" in universe now that we have readahead-list (in main)? it breaks upgrading right now (see #14842)
<infinity> Diziet : Then it needs to be seeded.
<Diziet> inf: Yes.
<reinouts> Kamion: for instance 'Loading additional components" and "Preparing for live session"
<jbailey> dilinger: pong
<mjg59> Keybuk: hotkey-setup is currently being synced from Debian - I'd prefer to upload there first if possible, rather than getting confused about which version I'm looking at
<slomo> seems like the ppc buildds are broken... so much stuff fails there without a good reason...
<Keybuk> mjg59: yah, I kinda bodged the version number on that one
<Kamion> Diziet: you might as well get practice editing seeds; see http://wiki.ubuntu.com/SeedManagement, and add it to the "Transitional packages" / "Upgrades from Hoary" section
<mjg59> Keybuk: Just a touch :)
<mjg59> Keybuk: What changes did you make?
<Kamion> mvo: probably not, although removals are generally an elmo thing
<Keybuk> mjg59: default) in a case only matches "default"
<Keybuk> mjg59: you mean *)
<Kamion> reinouts: "Loading additional components" is a string from Debian, but is currently fuzzy:
<Kamion> #, fuzzy
<Kamion> msgid "Loading additional components"
<Kamion> msgstr "Installatiemodules van Internet ophalen"
<Kamion> reinouts: please contact Bart Cornelis <cobaco@linux.be> about that one
<mjg59> Keybuk: Ah
<mjg59> Yes
<Kamion> reinouts: send a translation of "Preparing for live session" (and indeed the rest of the casper source package) to me
<reinouts> Kamion: where can I retrieve the nl.po from?
<Kamion> reinouts: anna
<tepsipakki> any talks about when the next version on U. is released with 5/3yrs of support (after 6.04, that is)
<reinouts> anna?
<Kamion> reinouts: source package
<Kamion> reinouts: er, hang on, sorry
<Kamion> reinouts: the nl.po for which string?
<Treenaks> tepsipakki: probably before those years expire, I guess
<reinouts> sorry I'm not very familiar with debian
<reinouts> Kamion: the nl.po for the installer messages I just gave
<Treenaks> reinouts: the installer is all kinds of different parts, you need to figure out which part this is, and get the .po from there (I guess?)
<tepsipakki> treenask: hopefully, yes ;)
<Kamion> reinouts: the first one you mentioned is in the anna source package; the second is in the casper source package
<Kamion> reinouts: 'apt-get source casper'
<reinouts> great :-s
<Kamion> reinouts: but as I say, for the first one please contact Bart Cornelis about getting that unfuzzied
<reinouts> Kamion: ok
<pitti> infinity: http://people.ubuntu.com/~ogra/buildlogs/ shows a whole lot of ppc ftbfs, can you please g-b them?
<reinouts> Treenaks: do you know what /etc/apt/sources.list should contain for 'apt-get source casper' to work?
<slomo> pitti: for me it looks like something broken there... they fail for no good reason ;)
<pitti> slomo: ppc buildd has always segfaulted randomly, but today it's particularly bad
<seb128> slomo: does it have any noticable effect on an Ubuntu app?
<slomo> pitti: ok...
<seb128> slomo: the gst-plugins0.8 patch
<slomo> seb128: yes... tseng can't rip his cds with banshee ;)
<slomo> seb128: (me neither ;) )
<seb128> ah, banshee
<seb128> will try it
<seb128> I'll uploaded a patched package though
<infinity> pitti : Feh, I think it must be something with royal.  Don't see those failures on adare and ross (do you?)..
<pitti> infinity: I didn't check that closely
<infinity> pitti : I'll shut down the buildd on royal and give-back everything it's registered as building in a bit.
<seb128> slomo: are you sure it doesn't break anything? Upstream have not used the patch (yet)
<infinity> Then figure out WTF later.
<pitti> infinity: that would be nice, thanks
<pitti> infinity: maybe bad memory?
<infinity> Who knows.
<infinity> Don't have the time to look at it right now, but I'll play later and alert elmo.
<slomo> seb128: no idea... what applications use the cdparanoia plugin? soundjuicer? but novell has applied this patch for suse so it should be ok imho... but i'll test later and tell you then :)
<seb128> slomo: let's wait for bugs due to the upload :p
<seb128> slomo: yep, sj by example
<slomo> seb128: hehe... you can point them all to me then ;P
<seb128> cf upstream bug
<seb128> "Please confirm that this doesn't break gnome-cd, sound-juicer or totem. "
<seb128> according to the novell guy it's fine
<slomo> seb128: yes... and abock can be trusted normally ;) i know him a bit from packaging banshee :) but i'll test it anyway later
<seb128> k
* seb128 tries banshee
<seb128> the UI looks like rhythmbox
<jdub> banshee looks like it will shape up nicely after a bit of work
<seb128> expected than the columns suck
<seb128> jdub: what's better than rb?
<jdub> amarok
<seb128> jdub: no, what banshee has over rb
<seb128> what part is better than rb ones :)
<jdub> (despite the usual widget overload)
<jdub> oh
<jdub> the license ;)
<jdub> it seems more responsive
<slomo> is more stable for me
<jdub> has a nice loading status bar
<slomo> at least when importing music it doesn't crash ;)
<seb128> what is the issue with rb license? it's GPL, no?
<jdub> makes startup rescanning more clear
<jdub> seb128: GPL + mp3 == DOOOOOM
<jdub> (section 7)
<seb128> oh, but rb is only a frontend
<seb128> it has no mp3 playing part
<seb128> is that an issue?
<seb128> I mean gst is doing the work
<Treenaks> slomo: does it handle 14000 oggs nicely? :)
<jdub> rb -> gstreamer -> mp3 == same process
<slomo> Treenaks: for me it does :)
<jdub> slomo: (heh, very precise answer!)
<reinouts> Treenaks: do you know what /etc/apt/sources.list should contain for 'apt-get source casper' to work?
<\sh> reinouts: deb-src http://archive.ubuntu.com/ubuntu breezy main restricted universe multiverse
<\sh> reinouts: it covers all source package sources of ubuntu
<seb128> jdub: anyway all that seems to be details to me (the status bar and the rescanning), not a reason to redo rb ... that's seems to be only "let's do it with C#" novell policy
<jdub> seb128: well, no, this was very much about the license
<reinouts> \sh, tnx
<seb128> jdub: rb has music sharing with zeroconf, etc now
<slomo> seb128: banshee will get it in some weeks too ;)
<jdub> seb128: and rhythmbox never had a sole copyright holder, so it's too hard to manage relicensing
<seb128> slomo: what a waste
<seb128> jdub: you "just" have to mail contributors
<slomo> seb128: they're already working on daap support... but as a general library for CLI
<jdub> seb128: and get their permission
<seb128> jdub: yeah, but imho that would not have been an issue
<seb128> slomo: still a waste imho, we have 2 apps doing the same thing now
<seb128> anyway, seems novell guys are going to rewritting anything they can using C# just to use it :)
<slomo> seb128: maybe... let's see which one will be the better in maybe a year ;) but i think a general daap library is useful... and that also provided us with avahi bindings for CLI ;)
<hunger> seb128: .. and drag yet another runtime environemnt onto the system...
<slomo> seb128: as long as they don't rewrite whole gnome in c# it's fine for me ;)
<hunger> seb128: As if KDE Gnome and java were not enough already.
<seb128> slomo: that's not a matter to which one will be better, but if they worked together instead of duplicating ...
* sivang just installed a Dual Xeon Ubuntu testing server
<\sh> ok..bittorent uploaded to fix bittorrent-gui
<slomo> \sh: good work :) i already wanted to poke you for that ;)
<\sh> slomo: well...it took some time for pbuilder creation here on this portege
<hunger> What is NetworkManager-named.conf doing in / ?
<hunger> j^: Any idea?
<hunger> j^: /NetworkManager-named.conf is not part of the deb... maybe I broke something again.
* sivang wonders if ubuntu-desktop is sufficient to get a running XOrg + GNOME running..
<Treenaks> sivang: more than enough
<sivang> Treenaks: what about a trim sized installation, with only a lightweight window manager?
<Treenaks> sivang: xfce you mean?
<Treenaks> sivang: instead of gnome?
<sivang> Treenaks: suppose so, yes
<pitti> infinity: I give-back the security build for ppc myself
<seb128> pitti: you have buildd powers now? 
<pitti> seb128: not really, I can only give-back (but I'm only supposed to do that for security uploads)
<seb128> k, it's noted :p
<sivang> seb128: what about my gnome-applets lpi love? moved to breezy +1 ? ;-)
<seb128> I've not got any mail with a patch nor bugzilla 
<sivang> seb128: I sent you a link in IRC a week ago, and you said you'd care for it after preview freeze..in any case, it's here : http://muse.19inch.net/~sivan/lpint/gnome-applets/ let me know if it's upload worthy
<seb128> sivang: yeah, but I've a lot to do, so a msg on IRC get quickly out of the scope
<seb128> thanks anyway
<pkern> jbailey: ping
<sivang> seb128: np, just let me know if it's in so I'll be responsive to bugs :)
<jbailey> pkern: Pong
<pkern> jbailey: It just doesn't drop to init, right. It loads the ramdisk (when the additional ramdisk_size parameter is specified), but then it still checks for another root fs. ):
<pkern> jbailey: I just don't get this problem. Even if I call init manually by setting root=/dev/ram0 init=/init it tells me "attempt to kill init" and bails out.
<Treenaks> Where are translations launchpad-integration stored? not in rosetta :(
<seb128> Treenaks: source package
<jbailey> pkern: And you're also on an ibook, yes?
<pkern> jbailey: Yep.
<Treenaks> seb128: hm, ok.. that means lots of translators will miss it
<Treenaks> seb128: starting translations
<pkern> jbailey: iBook G4 1,2GHz (so new style iBooks), and xfs as root filesystem
<pkern> jbailey: 2.6.10 of warty works nicely but the upgrade to 2.6.12 broke it.
<slomo> jbailey: i have a ibook g4 1ghz with xfs as root fs ;)
<seb128> Treenaks: yeah, kick rosetta guys
<pkern> jbailey: It didn't even work with a cramfs image instead. I just repacked it for cramfs, it loaded successfully but didn't use the ramdisk to do early userspace work.
<jbailey> Either of you two willing to wipe out your partition and try an install on ext3?
<jbailey> I'm curious if yaboot is doing something to the image when it's loading it off of a new xfs or something.
<jdub> interesting, distrowatch give props to mandriva for boot times
<jbailey> I'm still hping benc can prove what it's doing, though.
<jdub> daniels: heard of any visual corruption on ati 128 + powerpc?
<slomo> pkern: can you try on ext3?
<pkern> slomo: Bah, loading of all those debs just again. Perhaps if it's possible to install it with the hoary install cd. But not in the next days, though.
<daniels> jdub: not really
<slomo> pkern: me neither in the next days :(
<pkern> slomo: Considering that Gnome 2.12 didn't work nicely with my previous home directory it's ok.
<pkern> slomo: But school has started today. (=
<slomo> pkern: hehe... but hey, it's just school ;) i have to learn for 3 exams the next days... :(
<pkern> slomo: But it's the last year... (o:
<seb128> pkern: what was wrong with GNOME 2.12?
<pkern> seb128: Most icons disappeared.
<seb128> change your icon theme
<seb128> you were probably using clearlooks
<seb128> and upstream droped the icon theme when they moved it to GNOME
<pkern> seb128: Ok, thanks.
<seb128> np
<pkern> seb128: Couldn't it default to an icon theme when the chosen one is not available?
<seb128> it does, it default to GNOME
<seb128> but seems that when there is no action it doesn't try to update the icon theme
<seb128> that would require some debug
<jbailey> slomo, pkern: No worries - let's see what Ben comes up with.
* jbailey wanders off for food.
* pkern is hopefully
<Mithrandir> hmm, what's a useful resolution for bugs that don't affect us yet? :-P
<mvo> Kamion: permission to upload http://people.ubuntu.com/~mvo/python-apt_0.6.13.1ubuntu1.debdiff? it's needed to make the locking on the various python-apt based apps consistent
<seb128> mvo: we need approval for uploads?
<Kamion> not if they're within feature freeze restrictions
<seb128> right, thanks
<Kamion> adding locking support sounds more like a bug fix than a feature to me :-)
<Kamion> (so go ahead)
<mvo> seb128: this change is not stricly a bugfix, but it's needed to fix other bugs :)
<mvo> Kamion: right, thanks 
<Kamion> elmo: please sync man-db 2.4.3-2
<Riddell> chmj: I'm going to remove bluez-utils depends on bluez-pin if that's OK
<Riddell> chmj: and shouldn't bluez-pin depend on bluez-utils?
<Nafallo> Riddell: spammer! ;-)
<Riddell> hay, I can't help it if KDE is so multi-lingual
<Diziet> Urgh.  What could be worse than dpatch ?  cdbs.  They're using it for grep.
<xerxas> hi
<xerxas> is there anyone concerned by the ubuntu-desktop package ?
<xerxas> it depends on python-musicbrainz which depends on python2.4-musicbrainz 
<xerxas> which I think don't provide any desktop stuff 
<xerxas> xerxas but a python module not used by any software 
<Riddell> elmo: could you sync ttf-dejavu from debian?
<bob2> yes, ubuntu installs lots of random python modules by default
<tseng> pitti: is there an rss feed for USN?
<Kamion> xerxas: that was an explicit request from Mark, if I remember correctly
<Kamion> sabdfl: ^--
<xerxas> bob2, it's ok to have pyhon modules if they're used 
<bob2> you should have seen the original list then
<xerxas> Kamion,  and so ? 
<xerxas> we can't remove it ? 
<xerxas> it usefull ? 
<bddebian> Hello
<jdub> xerxas: ubuntu is the ultimate python platform - we put in a lot of useful (and a few less useful) python modules so that lots of python software will work out of the box
<Kamion> xerxas: when the boss explicitly asks for something, one doesn't remove it without asking him first. :-)
<xerxas> jdub,  picard isn't working with these packages 
<xerxas> I didn't find any apt software which uses these packages 
<xerxas> and I needed to recompile new version to make picard (the NG tagger) work 
<Kamion> it's not for other packaged software, it's for use by users
<xerxas> Maybe I should try to make new packaages 
<Kamion> if it were for other packaged software, it wouldn't need to be explicitly mentioned in desktop ...
<xerxas> Kamion, it's not usable by users, or am I wrong ? 
<Kamion> xerxas: are you saying that python-musicbrainz is broken in itself?
<Nafallo> xerxas: well, we _are_ in upstream version freeze and will release in a month...
<Nafallo> xerxas: try an older version of picard?
<xerxas> Nafallo, you made picard work with current packages ? 
<Nafallo> xerxas: I don't use picard. that was a suggestion.
<chmj> Riddell: thats ok 
<xerxas> Nafallo, ok ok 
<chmj> Riddell: bluez-pin doesn't depend on bluez-utils, its the other way around 
<xerxas> tahnks 
<xerxas> thanks 
<tseng> jdub: dude.
<tseng> jdub: i reckon the USN rss feed from p.u.c/news is too large to be very useful
<tseng> jdub: is that your baby?
<jdub> sort of
<jdub> it's meant to be news
<jdub> but thanks to plone, it's mega-USN instead ;)
<tseng> what i mean is ubuntu.com/usn/search_rss?blahblah
<tseng> i guess i can narrow it down
<tseng> to 10 or so
<tseng> is there a magic keyword for that?
<jdub> oh, that's a planet thing
<jdub> hrm, there should only be 10 max in the news output
<tseng> not on the usn feed
<tseng> its like every one ever
<jdub> right, direct from plone maybe
<jdub> in which case, i have *no* idea ;)
<tseng> http://www.ubuntu.com/usn/search_rss?review_state=published&sort_on=effective&sort_order=reverse&limit=10
<tseng> limit is not the magic word :)
<tseng> too bad ajmitch turned in for the day, he smokes from the plone bong
<bddebian> heh
<Nafallo> is there a reason we don't have sbackup in ubuntu?
<Nafallo> IIRC that was one of the Google SoCs for us?
<ogra> Nafallo, it was dropped afaik... 
<Nafallo> ogra: packages.debian.org/sbackup, doesn't look dropped
<mjg59> Unfrgiven: Have you filed a bug about your sleep issue?
<ogra> Nafallo, but that doesnt look like a ubuntu SoC :)
<Nafallo> mjg59: you want any bugs for TargaVisionary811 ?
<ogra> Nafallo, since its in debian, but not ubuntu...
<Nafallo> ogra: I'll try to find the SoC-page then :-P
<ogra> Nafallo, but if it works it'd be cool to have it synced .... at least in universe
<mjg59> Nafallo: If stuff doesn't work, then please file bugs (after checking it's no a duplicate)
<Nafallo> mjg59: oki, will do then.
<Nafallo> ogra: I'm about to build it ;-)
<ogra> great :)
<Nafallo> ogra: https://wiki.ubuntu.com/SimpleBackupSolution
<ogra> Nafallo, i know the SoC page.. i was very much after having it in main and was quite disappointed the SoC student stepped back...
<wickedpuppy> hi anyone knows how to sign packages  with dpkg-buildpackages ?? i got  no secret key error
<wickedpuppy> i mean how to import key
<bddebian> wickedpuppy: Do you have a key? :-)
<jbailey> mjg59: ping re: the usplash pluggable image stuff?
<bob2> wickedpuppy: presumably you're not actually going to get Riddell's secret key
<bob2> wickedpuppy: run it with -uc -us
<mjg59> jbailey: Mm? I replied to you in the other window
<seb128> daniels: around?
<jbailey> mjg59: Eh?  Which one?
<daniels> seb128: yeah?
<mjg59> jbailey: You /msged me 15 minutes ago
<mjg59> And then I never heard anything back :)
<wickedpuppy> thanks guys ... btw the file i need is .dsc file ?
<bob2> wickedpuppy: what are you trying to do with it?
<bddebian> Heya jb
<bddebian> Err jbailey
<wickedpuppy> build it
<bob2> wickedpuppy: then you presumably want the .debs
<jbailey> Right, haven't seen a reply.
<jbailey> Are you being beaten with the freenode not-identified stick?
<mjg59> jbailey: Oh, probably. Christ.
<mjg59> Indeed I am. 
<ogra> brb
<wickedpuppy> ah but my boss ask me to get the source :P
<mjg59> Oh dear. IRC has got less useful.
<wickedpuppy> clearly i also wants the source
<jbailey> I need to lookup the instructions on how to disable that for my userid again.
<bob2> s/IRC/Feenode/
<bob2> wickedpuppy: this is not development, #ubuntu
<Treenaks> bob2: Feenode, you _have_ to pay now?
<pkern> jbailey: /msg nickserv set unfiltered on
<jbailey> pkern: Thanks.  Is that permanent?
<pkern> jbailey: IIRC yes.
<jbailey> Cool.
<Kamion> Treenaks: that nickname is almost as old as the network name
<Treenaks> Kamion: yeah, since the OpenProjects crap/OFTC split days right?
<pkern> Treenaks: Sure, please place your donation in the box over there.
<Treenaks> pkern: you sound an awful lot like lilo
<pkern> Haha.
<pkern> (:
<sabdfl> xerxas: we try to have all useful, and a few more obscure, python modules instantly available
<sabdfl> if there's a better module that does the same thing, then we should discuss replacing the current one with that new one
<Treenaks> hm, mdke's announcement broke the launchpad?
<bob2> they're looking at it
<sabdfl> otherwise, i don't mind the extra space in order to live up to the statement that install ubuntu; python will get you what you want
<sabdfl> xerxas: since the module is not a dependency of anything else, we would probably be open to an upload of a newer version if it's known to fix issues and considered good by its upstream
<sabdfl> xerxas: ack
<Nafallo> sabdfl: I think there was a new upstream of the version we got, and the package didn't work with the "old" version.
<slomo> Nafallo: the other way around... the old version we have doesn't work with some software afaik
<slomo> Nafallo: picard for example
<Nafallo> slomo: with some _new_ software ;-)
<xerxas> sabdfl,  ack 
<xerxas> :)
<Nafallo> slomo: I adviced him to try an older version :-)
<Nafallo> xerxas: did the older version work?
<xerxas> there is some API change in the tunepimp
<xerxas> Nafallo, didn't tried yet 
<slomo> Nafallo: ok... so i will get back fixing haskell stuff =)
<xerxas> will try this evening 
<xerxas> gotta go
<Nafallo> oki
<bddebian> infinity: ping?
<infinity> bddebian : Pong.
<maswan> up to a bit over 100Mbit/s of 5.10 preview i386 install iso today too
<bddebian> infinity: Please forgive me if this is another dumb question but I uploaded a new version of addresses-for-gnustep, it built on all archs and shows Installed by xxx, but it isn't in the archive.  Where do I look?
<Riddell> mdz: can I upload kdeaddons and kdeartwork 3.4.2?
<infinity> bddebian : Uhm, http://archive.ubuntu.com/ubuntu/pool/universe/a/addresses-for-gnustep/
<infinity> bddebian : That matches the same version as wanna-build claims is installed.
<bddebian> Weird, it doesn't show with apt-get install or apt-cache policy, but does in apt-cache madison.. Hmm
<bddebian> Riddell: I'm still waiting for libdebtags1 but you should have most of your 1.4 stuff now. :-)
<pkern> How often is dinstall run for Ubuntu?
<daniels> pkern: every half hour
<pkern> daniels: Thanks.
<bddebian> infinity: OK, thx, sorry to bother you.
<bddebian> elmo: You around?
<pkern> daniels: Together with a mirror pulse?
<Riddell> bddebian: do you know what the status of libdebtags1 is?
<bddebian> Riddell: Sitting in NEW.  Waiting for elmo to OK, I think.
<infinity> bddebian : Nope, it's installed.
<bddebian> infinity: libdebtags1 is?
<infinity> Yes.
<Riddell> bddebian: I just uploaded a debtags snapshot which compiles with the libapt-front version
<bddebian> Hmm, since when?
<infinity> <shrug>... Didn't check the timestamp on the state change, but it's installed.
<dholbach> Riddell: i saw a package that was had a wrong/missing builddep libapt-*front*-dev
<dholbach> Riddell: dunno which it was
<bddebian> Riddell: Looks like I have to fix debtags though
<dholbach> but it failed today
<daniels> pkern: don't know about the pulses
<pkern> daniels: Ok, thanks. (o:
<Riddell> bddebian: why do you have to fix it?
<bddebian> Riddell: The sync ftbfs'd
<Riddell> bddebian: it's missing libapt-front, which is in NEW
<mjg59> Keybuk: What codec does alsamixer claim you have?
<Riddell> dholbach: any idea where you saw it?
<bddebian> dholbach: Oh, that's debtags :-)
<slomo> elmo: please remove haskell-cabal from the archives... it is now provided by ghc6 and doesn't work anyway
<bddebian> universe/admin/debtags_1.4+svn20050912-0ubuntu1: Dep-Wait by buildd+terranova [optional:out-of-date] 
<bddebian>   Dependencies: libapt-front-dev
<bddebian> Where did the svn20050912 version of debtags come from?
<slomo> elmo: and it breaks some stuff because of not working :(
<Riddell> bddebian: I just uploaded it
<Keybuk> mjg59: how do I ask it?
<mjg59> Keybuk: Run it
<mjg59> It'll print it in the information at the top
<Keybuk> mjg59: Card: ALI 5451, Chip: Analog Devices AD1981B
<mjg59> Ok, rock
<mjg59> That makes life nice and easy
<Keybuk> oh?
<mjg59> Same codec as the Intel ones
<Keybuk> right
<mjg59> So I just need to add a load of entries to set the quirks up properly
<Diziet> keybuk: This dpkg conffiles patch.  Should we (well, I) upload it into breezy now ?
<linuxsbartley> Trying to setup a 5.10beta server installation w/ xdm and xfce.  5.04 worked fine.  5.10beta hangs if I install xdm.  When I start the xdm session, I get a black screen with nothing.  Never get a gui login.
<linuxsbartley> 5.04 I get gui login and when logged in, get an xfce desktop as intended.
<pkern> linuxsbartley: Does X work on the box?
<linuxsbartley> I have to uninstall xdm from the 5.10 to get xfce to work again.
<pkern> linuxsbartley: If not please try dpkg-reconfigure xserver-xorg
<linuxsbartley> pkern, tried that.  no good.
<linuxsbartley> Uninstalled xdm and then X started working again.
<pkern> linuxsbartley: Do you get X but no xfce when you authed against xdm? 
<linuxsbartley> nope
<linuxsbartley> just a black screen
<linuxsbartley> never get auth screen
<linuxsbartley> w/out xdm installed, can do startxfce4 and it comes up fine.  As soon as I install and start xdm, it breaks x
<eruin> heh, xorg-62 five minutes ago, now -63 ;)
<linuxsbartley> eruin, will try it again then.
<linuxsbartley> my install was from yesterday.
<daniels> eh, -62 came sages ago
<bddebian> Riddell: Just out of curiousity, what does the svn stuff buy us?
<daniels> s/sages/ages/
* pitti looks at http://people.ubuntu.com/~ogra/buildlogs/ and curses the powerpc buildds
<linuxsbartley> After server install, I installed the following: xorg-common, xserver-common, xserver-xorg-core, xserver-xorg, xutils, x-window-system-core, xfce4, synaptic & xdm.  Does this look ok?
<eruin> daniels, weird. is #14383 ready too since you're in a frenzy?
<daniels> no way in hell
<eruin> haha :)
<daniels> the only reason I'm uploading at 12am is because the embargo for the CAN ended at 1400 UTC, which is 0000 localtime
<daniels> and it's a fairly critical fix, so I decided to stay around and up and push it as quickly as I could
<daniels> but thanks for reminding me ;)
<eruin> somehow I just can't help but to love daniels
<mdke>  [15:09:22]  < Treenaks> hm, mdke's announcement broke the launchpad?
<mdke> eh?
<mdke> what happened?
<pitti> seb128: erm, the mail you replied to with your "use bz, dude" stanza explicitly referred to bz :-)
<pitti> seb128: (of course I know that the mail was not really helpful)
<seb128> pitti: the guy understand what I said, he put a comment on the pointed bug and got his reply here
<pitti> seb128: hehe, good :-)
<seb128> ;)
<Riddell> bddebian: the svn stuff means it compiles with libapt-front 0.3
<bddebian> pitti: I was told you are fixing pgadmin3.  Is that true?
<Riddell> and that's the version of libapt-front we have so we kinday need the svn upload
<bddebian> Riddell: Oh.. Heh :-)
<pitti> bddebian: I already fixed it locally, it just needs a give-back on the buildds
<pitti> bddebian: oh, thanks for the reminder
<pitti> lamont-away, infinity: can you please give-back pgadmin3?
<bddebian> pitti: NP, thank YOU.  You gonna look at pgaccess to or no?
<pitti> bddebian: that's harder - nobody packaged libpgtcl for breezy
<pitti> bddebian: when you intstall the hoary version, pgaccess installs and runs just fine
<bddebian> pitti: Didn't pgadmin3 depend on libpgtcl too?
<pitti> bddebian: no, pgadmin failed because of wxgtk 2.5 -> 2.6 transition
<bddebian> Ohh
<pitti> bddebian: btw, the DD of pgadmin3 contacted me today, I explained him the changes, he will fix Debian soon, too
<bddebian> pitti: Great.  Sorry to keep bugging you but one more quick question.  postgresql-plruby.  Should it be redone for just postgre 8 or 7.5.8? And or just ruby1.8?  Or do you care? ;-) 
<pitti> bddebian: for Debian, it should be done for both 7.4 and 8.0 ideally; however, if you don't want to change the package too heavily, then 8.0 is certainly fine
<pitti> bddebian: hmm, I remember having answered an email about this recently...
<lamont-away> pitti: done
<pitti> lamont-away: thanks
<bddebian> pitti: From me?
<pitti> bddebian: I don't remember any more
<bddebian> Hmm
<bddebian> Maybe I should just stop bugging the shit out of everyone.. ;-)
<pitti> bddebian: oh, that's fine, at least for me
<pitti> bddebian: if you want to fix plruby, you might want to take a look at plr (I did the multi-version build for that)
<bddebian> pitti: OK, awesome, thanks
<linuxsbartley> ok.  5.04 xdm worked.  Tried install of 5.10beta again w/ xdm and xfce.   Rebooted system.  Tries to launch xdm gui auth screen then goes away and drops me to Alt-F8 w/ last line "Starting X display manager: xdm"
<linuxsbartley> Xorg.0.log shows many font renderer warnings and an error regarding font path unix/:7100 not init'd so it removed from list.
<sivang> does anybody know if people tagged as "supporter" in the ubuntu forums have any affiliation with canonical ?
<Kamion> sivang: it seems unlikely to me
<tseng> sivang: it sounds more like they donate to the forum
<tseng> sivang: freenode has a similar distinction
<tseng> sivang: (pdpc.supporter hostmasks)
<sivang> tseng: ah right
<Kamion> mvo: the whole point of /etc/default/gdm was to avoid using /etc/environment, since there was a huge argument about using that file
<Mithrandir> because /etc/environment should really have been named /etc/pam_environment or something like that.
<seb128> Kamion: even upstream use /etc/environment
<seb128> Kamion: we already had this discussion, nobody raised an objection for /etc/environment out of "it maybe change one day"
<seb128> and it works better for the moment and that's what people expect
<lamont-away> Kamion: yaboot is ftbfs... - I think I'll go ahead and fix it..
<lamont> (undeclared build-depends: gcc-3.3
<Kamion> seb128: sigh
<Kamion> I hope you got the syntax for /etc/environment right this time, anyway
<_elmo> Mithrandir: /go ste
<_elmo> meh
<Kamion> nope, you didn't
<seb128> Kamion: we got it wrong before? 
<Kamion> ++  . /etc/environment
<Kamion> /etc/environment is not a shell script
<seb128> Kamion: mvo did the changes ... mvo? :)
<Kamion> seb128: that's certainly a mistake I've seen in suggested patches for this before
<seb128> ah, maybe, I've not really followed all the comments on the Debian bug
<Mithrandir> seb128: use pam_getenv if you want to do that
<Kamion> yeah, pam_getenv would be fine
<jbailey> Sam hartmans wrote it exactly for that.
<jbailey> Well, to solve the standoff between neuro and I. =)
<seb128> mvo: these comments are for you :)
<Kamion> pam_getenv has a -l option too which would be appropriate here
<Diziet> gs is is full of strcpy(foo,foo);
<Kamion> hmm, pam_getenv seems buggy though
<lamont> Kamion: elmo: yaboot has an undeclared build-dep gcc-3.3.... are we leaving 3.3 in main for breezy, or does yaboot need to shift to 3.4?
<Kamion> lamont: leaving in main
<lamont> ok.
<Kamion> I don't want to mess with the compiler used for yaboot at the moment
<lamont> -3ubuntu4 should upload sometime later today then, after jbailey finishes testing it for me...
<lamont> Kamion: my thinking as well.
<mvo> Kamion: thanks, that was my fault, looking at it now
<Kamion> pam_getenv> will fix
* bddebian wonders if he dare ask elmo for another sync
<Kamion> jbailey: I think he wrote it but never actually tried running it, or something; it doesn't even parse the proper syntax
<Kamion> (it's parsing pam_env.conf style syntax)
<jbailey> Kamion: Joy.
<jbailey> Well, given that neuro refused to consider using it, despite having suggested it.
<dholbach> HAPPY BIRTHDAY TO YOU!
<dholbach> HAPPY BIRTHDAY TO YOU!
<dholbach> HAPPY BIRTHDAY DEAR SB
<dholbach> HAPPY BIRTHDAY TO YOU! :)
<bddebian> heh
* dholbach hugs seb128  :)
<HiddenWolf> Congratulations!
<\sh> what? seb128 has birthday? 
<sabdfl> seb128: congratulations!
<\sh> happy birthday seb128 :) all the best :)
<mvo> seb128: HAPPY BIRTHDAY
* mvo gives a virtual present to seb128 
<sivang> HAPPY BIRTHDAY seb128 !!!!!
* jbailey sings: You're older than you've ever been, and now you're even older..
* dholbach gives everybody a beer.
* jbailey hides
<jbailey> =)
<\sh> champagne for seb128 :)
<jbailey> seb128: Bonne aniversaire. =)
<seb128> thanks everybody :)
<sivang> jbailey: so good at stating the obvious which will be right for me as well, in 2 months :)
<jbailey> sivang: It's a song by They Might Be Giants.
<seb128> jbailey: "bon anniversaire" :)
<sivang> jbailey: ah :)
<jbailey> seb128: Right, the n is pronounced because of the liason.  Thanks. =)
<seb128> THANK YOU dholbach, THANK YOU GUYS :)
<seb128> jbailey: correct 
<\sh> seb128: if I may ask: how old are u now? :)
<lamont> hrm... can I upgrade warty-> breezy, or do I have to stop off at hoary first???
<jbailey> lamont: Acc. to Keybuk you have to pass through Hoary.
<seb128> \sh: one year less than next year :p
<\sh> seb128: ok ,-)
<lamont> k
<seb128> lamont: xfree to new xorg has issues it seems
<sivang> seb128: what's your sign?
<mdke> virgo
<mdke> best sign
<mdke> Kamion, around by any chance?
<sivang> mdke: how do you know ? :)
<mdke> mine was yesterday
<infinity> lamont : Snapshot the system and try warty->breezy for kicks.  I'm curious.
<seb128> sivang: those are fixed, easy to know, just look on the calendar 
<sivang> seb128: a right :) 
<Kamion> mdke: yes
<mdke> Kamion, just wondered if you had any idea on #14947, because I am about to do a system restore on that system out of desperation
<Kamion> mdke: I'm sorry, I'm just about the worst person to attempt to handle Windows bugs
<mdke> Kamion, if it's a windows bug then it should be closed. But it's been marked as a grub bug
<Kamion> IIRC Windows CDs have some kind of fixboot option
<Kamion> I mean bugs relating to Windows
<mdke> ok I'm going to restore to factory settings. I'll see if I can reproduce it and otherwise close, but it would be worrying if that will happen to a lot of users when upgrading to Breezy
<mdke> Kamion, could it be that there was a problem on the windows partition that didn't bother windows, but which might bother Grub?
<hughsie> desrt: ping
<desrt> hughsie; poke
<hughsie> desrt: heh, hi.
<desrt> more hal goodness on the list, i think
<hughsie> desrt: mind if i rework that patch you sent to hal-devel a little?
<desrt> what did you have in mind?
<hughsie> desrt: i'll email you - just stylistic changes, and the way you've done the while loop.
<Kamion> mdke: I don't see why the entries should have been removed from your menu.lst file in the first place (update-grub normally doesn't touch them)
* desrt imagined he might meet some resistance there :)
<desrt> k.  send away.
<Kamion> mdke: as for GRUB, I honestly have no idea
<mdke> Kamion, me neither :(
<Kamion> mdke: you need a GRUB expert
<Kamion> I only play one on TV occasionally
<mdke> Kamion, reassign the bug to one?
<Kamion> that would need an *identified* GRUB expert
* mdke nods
<Kamion> fixing the ntfs module certainly wouldn't hurt, but I know even less about that :)
<hughsie> desrt: sent
<desrt> k.
<hughsie> desrt: what do you tink about my /proc/stat patch?
<Kamion> mdke: did you ever edit menu.lst by hand at all?
<desrt> i still haven't found it :)
<desrt> i sort of have a lot on my plate right now
<mdke> Kamion, not before I saw that bug, no. Only afterwards, when trying to readd the entry
<hughsie> desrt: no problem
<Kamion> 'cos unless somebody's broken it, grub-installer writes Windows entries outside the region that update-grub automatically modifies
<hughsie> desrt: (or anyone who knows HAL): http://pastebin.com/361671
<mdke> Kamion, the system was installed from colony 2, and the bug appeared after I did a very big dist-upgrade after several weeks without internet access. So maybe there was an update to another package which played with menu.lst?
<desrt> hughsie; fwiw, i think it'll be a while before gnome-applets use hal for this sort of thing :)
<desrt> hughsie; like... not during 2.14
<hughsie> desrt: yup, but g-p-m can use it now :-)
<hughsie> desrt: n/p - they will come....
<Kamion> mdke: that would be a very serious bug, but I've never heard of anything like that
* desrt already catching a bit of flak for using it for battery
<Kamion> mdke: to my knowledge the only thing that plays with menu.lst is update-grub
<mdke> Kamion, ok I'll system restore and then install from colony 2 again and dist-upgrade
<hughsie> desrt: but how did things work before?
<hughsie> desrt; the battery applet acpi code was *so* crude
<Kamion> mdke: if you can manage to keep enough information for somebody to debug the ntfs problem if required, that'd be good
<desrt> hughsie; i disagree
<mdke> Kamion, hmm, i wouldn't know what to keep
<desrt> hughsie; the battery applet acpi code was a finely polished gem
<desrt> hughsie; it had years of bug reports smoothing down the rough edges
<desrt> hughsie; right now, the hal stuff is what i'd consider 'crude'
<desrt> hughsie; but it's rapidly improving
<Kamion> mdke: the first few megabytes of the partition ought to be enough
<hughsie> desrt: ohh - I got ya. But stuff like mAh was never implimented
<hughsie> desrt: i didn;t believe acpi specific code benonged in an applet anyway...
<desrt> hughsie; but would have been during this release cycle, since we got bugged about it
<desrt> hughsie; neither do i :)
<desrt> hughsie; but it was there and it was working
<Diziet> mdz: You're right about those grep patches.  I misread the date.
<desrt> hughsie; porting to HAL has caused a seemingly endless string of regressions
<mdke> Kamion, is there any way that bug can be assigned to someone who can ask for the details needed before I do the system restore?
<hughsie> desrt: sometimes you have to break a few eggs to make an ommlette
<desrt> hughsie; all i can do is be grateful that we have lots of people running breezy prereleases
<desrt> hughsie; absolutely
<hughsie> desrt: yes, finding the bugs
<desrt> hughsie; and it had to happen sooner or later
<desrt> so why not now? :)
<desrt> for this release cycle the code was mature enough that it at least was useable
<hughsie> desrt: yes, agreed. it's where it belongs, in hal.
<desrt> and it's had the addition benefit that hald has gotten an awful lot of extra feedback
<hughsie> desrt: and updating hal is a no brainer for most distros.
<desrt> hughsie; heh.  i dunno.  look at what martin's doing
<hughsie> desrt: okay, point :-) heh.
<hughsie> bet you are popular :-)
<desrt> i have =yet another= hald patch sitting on ubuntu bugzilla now awaiting testing before i send it up to the list
<desrt> hah
<desrt> popular might not be the right word :)
<hughsie> another? whats the link?
<desrt> http://bugzilla.ubuntu.com/show_bug.cgi?id=14050
<desrt> it's a crude hack.  i'm not even sure if upstream will want it
<desrt> it's also a 5AM hack :)
<sivang> man these NFS mounts take ages to complete..
<hughsie> desrt: just looking now
* mvo is away for a bit now to play hockey
<hughsie> desrt: bodgetastic.
<desrt> hughsie; :)
<desrt> pretty much
<desrt> fortunately, the bodge will hold until the kernel gets fixed
<sivang> Kamion: how do you test partman-auto-lvm when you do changes in it?
<desrt> because i doubt the kernel will get fixed in time for breezy
<hughsie> desrt: i don't see why this couldn;t be in hal -- looks okay to me.
<desrt> hughsie; the proper fix belongs in the kernel, really
<hughsie> i think it more likely a bios issue than kernel
<desrt> hughsie; but after it gets a bit of testing i'll send it to the list
<hughsie> desrt: by inspection, the patch looks correct
<desrt> nod
<desrt> acpi isn't too bad
<desrt> i usually nail the patches even without testing :p
<hughsie> hal_device_property_set_bool (d, "battery.rechargeable.is_discharging", 0);
<hughsie> should be
<hughsie> hal_device_property_set_bool (d, "battery.rechargeable.is_discharging", FALSE);
<hughsie> nitpick
<desrt> true.
<hughsie> and davidz likes the comments on a seporate line
<desrt> k.  i'll keep those in mind
* desrt has to write 2 versions of each patch anyway :)
<desrt> ahh
<desrt> psych or polysci
<desrt> or both....
<desrt> hmmmmmmm
* desrt needs to pick up an elective or two
<hughsie> desrt: eigh?
<desrt> eigh?
<hughsie> desrts: what's psych or polysci
<desrt> psychology and political science
<desrt> generic 1st year courses on the subjects
<hughsie> ahh, my girlfiend is a psych undergrad
<desrt> maybe i'll take both
<desrt> 8 courses + 2 jobs could be fun :)
<hughsie> desrt: stick to hal patches :-)
<desrt> pfah
<desrt> there are more important things in life than free software :)
<desrt> like uh... graduating
<hughsie> desrt: girls :-)
<desrt> hughsie; maybe if i get more time :)
<hughsie> desrt: know the feeling - just thinking whether to do a PhD or not..
<desrt> hughsie; only wimps say no
<desrt> hughsie; only wimps say yes, though
<desrt> hughsie; so basically, you're already a wimp and nothing you can do will change that
<hughsie> desrt: not sure about the wimp status. I play rugby..
<desrt> rugby is for wimps :)
<hughsie> desrt: come here and say that
<desrt> hughsie; are you going to UBZ?
<hughsie> UBZ?
<desrt> ubuntu below zero... the conference
<hughsie> where?
<desrt> montreal
<desrt> (bonjour)
<hughsie> bit of a mission. i'm in uk
<bddebian> lamont: In case no one as told you lately, your webpages are a Godsend. :-)
<desrt> blah
<desrt> people are coming from farther :)
<hughsie> desrt: heh, okay. i g2g, dinner;s ready
<Kamion> mdke: it's already cc'ed to kernel-bugs@lists.ubuntu.com
<desrt> cheers
<lamont> bddebian: I wonder which pages those are...
<sivang> desrt: you coming from .au ? :)
<Kamion> sivang: if you look at the changelog it will be clear that almost all the real work on partman-auto-lvm has been done by fabbione, and I have not done anything that requires much testing
<desrt> sivang; pfa.  no :p
<sivang> Kamion: ok, sorry I will ping him up about it, thanks anyways.
<sivang> desrt: there where? 
<bddebian> lamont: All of the above? :)  BuildLogs, lists, etc
<desrt> sivang; .ca
<lamont> ah, o
<lamont> k
* desrt goes to shower
<sivang> desrt: laterz
<bddebian> lamont: BTW, do you have or would it be easy to create a list by arch of the latest versions that fail to build for that arch?
* Kamion fixes pam_getenv
<Lathiat> Kamion: is it broken such that it doesnt actually get the variables its supposed to?
<lamont> bddebian: buildLogs/Lists/breezy.all.$ARCH has that info, basically.
<Kamion> Lathiat: it was broken such that it could not ever have possibly worked
<Kamion> so yes
<Lathiat> Kamion: right, i was wondering, i was tryign to use it and wondered if i was being stupid
<bddebian> lamont: Ah, OK, thx
<Kamion> Lathiat: (a) it was parsing /etc/environment using the syntax for a totally different file; (b) even if that accidentally succeeded, it would crash because a variable was declared in the wrong scope
<bddebian> Anyone know if libjack0.100.0 is just not there/right/etc?
<Lathiat> Kamion: heh
<Kamion> well, not crash, but print a warning followed by a blank line
<mdz> doko: it doesn't look like you've seeded zope yet
<mdz> doko: anastacia is relatively clean for the moment
<doko> mdz: ok, I'll seed it
<seb128> mdz: hi
<mdz> seb128: hi
<Kamion> Lathiat: (actually, I was wrong about (b); but who cares, it was hosed)
<seb128> mdz: evolution-plugins should be installed with the desktop, is there any place to discuss that or pinging you on IRC is fine?
<mdz> seb128: is it a universe package currently?
<Lathiat> Kamion: :)
<seb128> mdz: right, but it's evolution which has been splitted to a new binary to make plugins optional, not any new code
<seb128> mdz: we had these files under the evolution package for hoary ... should we make a wiki page in this case too?
<mdz> seb128: if the code was already in main, no report is needed
<mdz> just seed it
<seb128> ok, will do, thanks
<seb128> mdz: should I change the ubuntu-desktop package too to list it?
<Kamion> seb128: that's semi-automatic
<seb128> I just update the desktop seed so?
<mdz> seb128: yes
<mdz> seb128: update the desktop seed, then apt-get source ubuntu-desktop,, run ./update, read changelog and upload
<Kamion> if you want ubuntu-desktop updated quickly, update the desktop seed, wait until it propagates to http://people.ubuntu.com/~cjwatson/seeds/breezy/desktop (<= 17 minutes), run ./update in ubuntu-meta
<seb128> cool, thanks
<seb128> thanks mdz, Kamion
<mdz> right, you need to wait for the seed to be published before running update
<Kamion> where do SuSE keep their source packages?
<mdz> we should fix that one day
<mdz> Kamion: .../SRPMS/
<mdz> presumably?
<Kamion> ah, they're there for 9.3 but not 10.0
<Kamion> yaboot doesn't seem to be there though
<bddebian> yaboot is a PITA :-)
<Kamion> oh god, they have per-arch source directories
<elmo> haha
<\sh> Kamion: what? since when ;)
<Kamion> \sh: what else would you call ftp://ftp.suse.com/pub/suse/i386/9.3/suse/src/ ?
<bddebian> elmo: Can I ask a quick question?  (Don't worry not a sync request) ;-)
<\sh> Kamion: the directory for the i386 distri of suse version 9.3
<\sh> Kamion: but not the SRPMS directory
<Kamion> \sh: that directory is full of source RPMs
<jbailey> Kamion: Is it a massive symlink farm like the good ol' pre-pool days of Debian?
<\sh> Kamion: yes...it's the source archive of suse for the packages...but I was thinking u refered to /usr/src/redhat/SRPMS/i386/
<\sh> because SRPMS are just like ours and laying in /usr/src/redhat/SRPMS
<Kamion> \sh: no, that's why I said "SuSE" not "Red Hat"
<\sh> Kamion: even on suse the official RPM building root dir is /usr/src/redhat
<Kamion> I don't care about what happens when you're *running* SuSE; I just want their source code
<sabdfl> Kamion: thanks for the new data, worked a treat
<Kamion> sabdfl: cool stuff
<bddebian> Worked a treat??
<doko> Setting up xserver-xorg (6.8.2-63) ...
<doko> /usr/share/debconf/confmodule: line 33: 3: Bad file descriptor
<doko> [hangs ...] 
<doko> daniels: ^^^
<mdz> doko: something funny in your environment?
<mdz> I don't see how xorg could cause that
<mdz> that's the first thing in the script
<Kamion> my guess would be that DEBIAN_HAS_FRONTEND is set
<Kamion> which it really shouldn't be unless you're debconf
<Kamion> as in, set externally to package installation
<Kamion> hm, or perhaps DEBCONF_REDIR
<elmo> bddebian: sure
<bddebian> elmo: NM, you answered in the e-mail.  Thank you.
<dholbach> see you all tomorrow, bye
<doko> mdz, Kamion: fun was yesterday. I see this on amd64 only, currently updating another amd64 machine
<doko> mdz: please promote translate-toolkit to main, reviewed by pitti
<doko> mdz: plone & zope seeded
<mdz> doko: translate-toolkit is not germinated
<mdz> doko: see http://people.ubuntu.com/~mdz/anastacia.txt
<doko> sorry, when is next germinate run?
<mdz> doko: I just ran one 5 minutes ago
<doko> ahh, ok, I need to upload ooo2 first, that has t-t as a b-d
<Diziet> mdz: Hello.
<Riddell> mdz: can I upload kdeaddons and kdeartwork 3.4.2?
<Diziet> mdz: ping
<mdz> Diziet: yes?
<mdz> Diziet: if you just say what you need, I can answer you when I see it, instead of waiting another RTT
<mdz> Riddell: does anything in Ubuntu depend on them?
<mdz> or are they purely desktop packages?
<elmo> Diziet: are you aware 'mozilla-firefox' isn't installable?
<elmo> ogra: ?
<Diziet> mdz: Ah, OK.  I wanted to talk to you about grep.
<Riddell> mdz: only kubuntu-desktop depends on them
<Riddell> or packages from them
<Diziet> I'm less sure now that you've pointed out that it only went in yesterday.
<Diziet> One possibility would be to diff the current Debian package against the Fedora one.
<Diziet> How large a risk of damage is acceptable at this stage ?
<Diziet> This bug seems to have been quite longstanding.
<Diziet> And the fixes have been around for a while too.
<Diziet> elmo: No, I wasn't aware of that.  I installed it here I think.
<Diziet> elmo: BICBW.
<mdz> Diziet: grep is such a critical component, and we are so close to the final release, that our risk tolerance is very low
<elmo> Diziet: firefox Conflicts mozilla-firefox, mozilla-firefox Depends firefox
<elmo> ...
<Diziet> mdz: In that case we should punt this.
<mdz> Riddell: ok
<Diziet> To breezy+1.
<mdz> Diziet: let's give it a week in Debian and revisit to see if it caught fire there
<Diziet> mdz: OK, we could do that.  I'm still a bit nervous.
<Diziet> If it had had the month I thought then definitely.
<Diziet> I'll do that diff tomorrow and see what it turns up.
<Diziet> elmo: OIC, it's not installable together with firefox.  That's OK.
<elmo> Diziet: no it's not?
<Diziet> The purpose is to trick the package manager into selecting firefox.
<Kamion> Diziet: it's not installable *at all*, because it Depends: firefox
<Diziet> But you don't want it installed.
<Kamion> Does this trick you postulate actually work in practice?
<Kamion> because it's not what anyone else does with dummy packages so I doubt that path is tested
<Kamion> seeing as e.g. Debian testing won't let such a package in
<Diziet> I tested it but obviously it wasn't a pure test because I had to kludge lots of stuff to make it visible at all.
<Kamion> we require zero uninstallables in main when we release ...
<Diziet> OK, I'll change firefox then.
<Diziet> Sorry about that.
<Kamion> thanks
<Diziet> No problem.  Thanks for the grumble.
<Kamion> I realise it requires nasty conflicts <<
<Kamion> actually, does it? would just replaces << work?
<Diziet> Yers.  Now is perhaps not the time to be fighting that one.
<Kamion> but again, now is perhaps not the time to be trying that out
<Diziet> No, the reason it's not installable is because  m-f Depends f  f Conflicts m-f  .
<Kamion> yeah, I know
<Diziet> So just replaces wouldn't work.
<Kamion> I'll draw you pictures of what I mean if I see you at post-pizza tonight :-)
<Diziet> :-).
* Kamion runs off to karate
<Diziet> Chop well.
<Nafallo> ehm
<Nafallo> pizza?
* Nafallo goes to the kitchen
<Riddell> doko: I can't get the openoffice/kaddressbook integration to do much, the only source openoffice seems to list is evolution
<Riddell> doko: would it be possible to use KDE file open dialogues by default?  they seem to work fine now
<doko> Riddell: it's only possible to enable the default dialogs for kde _and_ gnome, not for just one.
<doko> However I didn't check much the gtk dialogs
<bddebian> Goddamn I hate it when I can build a package from Debian fine, I sync it and it explodes.. Grr...
<HiddenWolf> bddebian, as #debian is fond of saying, debian _is not_ ubuntu
<bddebian> HiddenWolf: Bah :-)
<HiddenWolf> bddebian, sorry, but that was asking for it. ;)
<doko> mdz: heading to bed now, please promote translate-toolkit once it shows up in anastacia output
<crispin> Hmm, I had to hex edit the http method to get rid of the If-Range support as my ISP has a broken proxy :-(
<sladen> crispin: transparent proxy too?
<crispin> yeah
<Lathiat> sladen, crispin: ah those are great, mine causes random apt requests to get reset, usually the first time i talk to a particular server in a while
<crispin> Lathiat, sladen, yeah they suck :-( I'm going to cook up a patch to allow turning off If-Range's to get round my problem
<Lathiat> whats this for?
<crispin> Lathiat: my ISP's proxy just returns bogus responses to If-Range requests, causing apt to fail to update 99% of the time
<Lathiat> ah
<Evaso> hi guys fpc will be available in ubuntu?
<Evaso> i know that debian source package was fixed and now support also amd64
<Evaso> why fpc binary packages aren't available but only the sources pakcages?
<Evaso> http://packages.ubuntu.com/breezy/source/fpc
<Lathiat> Evaso: because its compilation requires bootstrapping, and no on ehas organised to have that done, and this is an issue you want to talk in  #ubuntu-motu about since its a unvierse package
<Evaso> thanks
<ajmitch> morning mdz
<mdz> morning
<mdz> power is finally restored
<mdz> it was out for nearly 2 hours
<ajmitch> mdz: I got a request from hypatia to update python-nevow in main (UVF issue)
<ajmitch> apparantly 0.3 is quite irritating to use with twisted
<ogra> mdz, :(
<mdz> ajmitch: can you be a bit more specific?
<ajmitch> < hypatia> the justificiation would be something like "nevow 0.3 uses the Twisted 1.3 style component architecture, and while technically compatible wit
<ajmitch> h Twisted 2.0.1, requires application developers to do a lot of compatibility wrapping"
<ajmitch> python-nevow packages don't appear to have reverse depends in main
<mdz> yes, was just checking that
<Nafallo> mjg59: can I tell usplash to go and die from an initscript?
<mdz> ajmitch: ok with me, as long as you take responsibility for fixing any issues with it (merging, watching to make sure it builds, responding to any reports of regressions)
<jbailey> Nafallo: chvt to terminal 1 ought to be enough.
<ajmitch> mdz: alright, thanks
<mdz> ajmitch: email the request to elmo, CC me
<Nafallo> jbailey: the script in question is cryptsetup, usplash should vanish when cryptsetup asks for a password ;-).
<Lathiat> mdz: "nearly 2 hours"?  heh when the pwer goes out here 2 hours is usually a minimum :)
<mdz> I rarely lose power here
<jbailey> Nafallo: Ah, that I don't know.  =)
<Nafallo> jbailey: so chvt is probably not an option :-/
<mdz> I think that was the only time this year
* Lathiat has had 3 times this year
<mdz> for more than a few seconds, anyway
<Lathiat> maybe 4
<ajmitch> right, it's not a straight sync as the default python version needs set to 2.4 again
<mdz> elmo: the cron.sync locking still doesn't seem to work for me ("Try praying...")
<elmo> mdz: yeah, I've noticed - it's harmless enough
<elmo> oh, well I suppose less so if you're running it often
#ubuntu-devel 2005-09-18
<mdz> doko: http://people.ubuntu.com/~mdz/anastacia.txt updated with zope
<mdz> doko: the xpdf deps need to go
<mdz> Riddell: there are two deps of libkiten1  in http://people.ubuntu.com/~mdz/anastacia.txt which have no main inclusion reports
<mdz> Riddell: until they are reviewed and promoted, it is uninstallable
<ogra> mdz, they shouldnt even be in there anymore
<mdz> oh, I confused kiten with krita I think
<ogra> mdz, they come from kdeedu...
<mdz> ogra: well, they are there
<mdz> apt-cache show libkiten1
<ogra> hrm... i'll look ... i changed the edubuntu seeds yesterday to let them disappear there
<mdz> they are not seed entries
<mdz> they are dependencies
<ogra> yup, i removed the binary deps that pulled them in
<Riddell> ogra: did you update the meta-package?
<ogra> Riddell, its not in the meta package...
<ogra> its only in supported... elmo wanted me to clear the non used kdeedu apps from anastacia... since all were approved i put them into supported, but missed that one pulls libkiten in...
<ogra> mdz, so how do i make kiten and friends go away ? i dont need them, they are in none of my seeds for edubuntu 
<mdz> ogra: read the germinate output and see what pulls it in
<ogra> ok
<ogra> oh, how silly... i dont have kiten in supported, but kdeedu... hmpf...
<HrdwrBoB> easier to fix than my problem, I have two physical kittens in my way
<mdz> Kamion: groff is the only thing which uses libxp in main
<sivang> night all!
<jdub> 'night israel!
<jdub> 'morning sydney!
<Nafallo> morning jdub :-)
<ajmitch> morning jdub 
* jdub is hoping that the dell delivery guy turns up VERY EARLY this morning
<tseng> jdub: these panels are amazing
<jdub> shush!
<tseng> jdub: you will have to start jdub|tv up for us
<tseng> to see you dance
<jdub> that's cruel and unusual treatment!
<jbailey> jdub: Somehow I can imagine you yelling "GOOD MORNING VIETNAM!"
<jdub> i would record for you
<jdub> but my voice is all croaky and gross
<jdub> pipka gave me a cold!
<jdub> ogra: ha ha conservative
<ogra> :)
<Kamion> mdz: I blame imake or something; it's not used explicitly as far as I can see
<stub> I just upgraded to breezy, and had no Gnome sound. Turned out I had polypaudio installed rather than esound. Was this my fault from sometime in the past or is this an upgrade bug that needs reporting?
<jdub> stub: that was a release-notes-only-able upgrade fix
<stub> There are release notes? ;)
<mdz> stub: with every milestone CD, yes
<jbailey> stub: https://wiki.ubuntu.com//BreezyReleaseNotes =)
<stub> Ahh... I just upgraded with synaptic, and google hasn't found the breezy release notes yet ;)
<jdub> stub: it was a hoary preview -> final thing
<sladen> yes, experienced 15283 when I was at my parents in Nottingham last week.
<ogra> sladen, be happy you didnt experience 15284 *g*
<Kamion> mdz: ok, I have a patch here which avoids the libXp linkage
<mdz> Kamion: woo
<Kamion> mdz: will I be able to sync past groff 1.18.1.1-9? the multibyte fixes are tasty and I've had no bug reports
<mdz> how long has it stewed in sid?
<Kamion> two weeks
<Kamion> or just under, anyway
<mdz> it makes me a bit nervous because it's such a build-depish thing
<mdz> but if you're confident
<mdz> and don't mind rolling it back if it blows up on us
<Kamion> I'll check it over again to make sure the changes are as CJK-specific as I remember
<Kamion> but certainly, all the code involved is mine anyway so for a change I understand the multibyte patches
<sladen> ogra: hehe, some people are fairly detailed in their bug-reporting...
<ajmitch> slightly too detailed
<mdke>  [00:54:26]  < Kamion> mdz: will I be able to sync past groff 1.18.1.1-9? the multibyte fixes are tasty and I've had no bug
<mdke> argh
<mdke> sorry all
<mdke> leaned on the mousepad
<Ubuntu> it's very weird that I caught a msg fail to load general console font and t_kernel font ...[fail] , I looked through but couldn't find the reason to make a patch to fix, any1has anyidea?
<mdke> on booting?
<Ubuntu> yes
<mdke> i get that too
<mdke> i think it is usplash related
<Ubuntu> I thought so
<Ubuntu> u got any idea?
<mdke> except for that, no. Will you file a bug?
<mdz> mdke: it's already there
<mdz> at least twice
<mdz> so please don't
<mdke> fair enough
<mdz> http://bugzilla.ubuntu.com/show_bug.cgi?id=14691
<mdke> by filing a bug, i meant, check bugzilla and then file if it's not there
<mdke> :)
<Ubuntu> got ya
<Ubuntu> besides, I also found a problems, not sure I can call it a bug or not
<Ubuntu> the fglrx-driver does not automatically put module 'fglrx' into /etc/module
<mdz> that isn't a bug
<Ubuntu> okay
<Ubuntu> thx much mdz
<desrt> mhmm
<mxpxpod> is anyone else having problems with beagle starting?
<sabdfl> hi folks. i see we don't have a protocol handler for irc:// in firefox. should we not have Gaim or Xchat setup to handle those URL's?
<mdz> sabdfl: you scared them all away
<mxpxpod> ooh, I love netsplits
<sabdfl> slackers
<mdz> xchat seems like a reasonable handler for that
<bddebian> pfft
<desrt> sabdfl; bugzilla :p
<mdz> though I don't think it does anything sane if it's already running
<ajmitch> hi sabdfl 
<sabdfl> hi guys
<bddebian> Hello sabdfl 
<sabdfl> i ask because we have the irc URL for #ubuntu on the +gethelp pages in LP, but you only get an error if you click on them
<desrt> sabdfl; what's the tone of the launchpad week at UBZ gonna be like?
<ajmitch> is there a date by which we have to notify that we're coming to UBZ?
<sabdfl> desrt: focused. we mainly work with specs not code, and we'll be trying to narrow down the scope of LP 2.x
* ajmitch is quite tempted to go to UBZ
<desrt> but all about the webservice side of things, right?
<slomo> elmo: ping?
<sabdfl> desrt: yes
* desrt isn't too sad about missing it, then
<daniels> mjg59: can you please drop me an Xorg.0.log from your X300 that dies?  just want to pick out the model so I can special-case it for the time being
<bddebian> Riddell: ping
<jgorski> are fairly uninvolved ubuntu fans such as myself invited to UBZ?... i might be in the neighborhood at that time.
<Lathiat> jgorski: anyone is welcome to attend
<Lathiat> jgorski: it is however a developer oriented conference
<daniels> it's more of a developer summit than a conference
<ajmitch> Lathiat: I reckon you should just start swimming there
<Lathiat> daniels: details, details
<Lathiat> ajmitch: hrm, well if i start now..
<Lathiat> maybe i can stuff myself in daniels' carry on luggage
<jgorski> Lathiat: well. i'm looking to be more involved in any case... so, I'm glad it fairly open.
<spstarr> uhm why do we have silly dependencies for kubuntu-desktop in -devel
<spstarr> mdadm is needed for what reason? RAID is a desktop thing these days?
* bddebian bets daniels would love to see him there..
* spstarr files some bugs
<bob2> yeah, surely no one ever considered that ;)
<spstarr> bob2?
<Lathiat> spstarr: an extra 100K of used space killed your cat?
<spstarr> i just dont want daemons running that aren't useful in ram
<spstarr> not disk space, its about ram
<bob2> they don't use ram
<spstarr> mdadm does
<jdub> if you don't have any raid devices, mdadm doesn't run
<Lathiat> mdadm isnt an in memory thing it manages stuff in the kernel, and yes lots of people use raid etc on the desktop
<spstarr> we can't make it a conditional dependency?
<jdub> if you have raid devices, mdadm will run to monitor them
<jdub> so it doesn't hurt at all :-)
<bob2> spstarr: a) it doesn't run if you don't have raid devices, b) if it does run and doesn't get used, it will live in swap, not ram
<Lathiat> spstarr: what is a 'conditional dependancy'
<jdub> Lathiat: like pcmcia-cs, only installed if required
<Lathiat> jdub: ah
<spstarr> yeah
<spstarr> a few packages should be conditional 
<jdub> mdadm isn't
<jdub> because it does the right thing
<spstarr> that way, by default you install, but you allow people to remove them without removing 780MB of stuff
<bob2> removing mdadm removes nothing aside from ubuntu-desktop
<Lathiat> spstarr: err, removing mdadm wont remove a stack of stuff
<spstarr> oh yes it does
<Lathiat> ooh
<Lathiat> i lied
<Lathiat> it removes your kernel
* Lathiat smirks
<jdub> there are very few things that need to be conditional
<Lathiat> spstarr: its not hurting you, get over it. :)
<spstarr> my kernel is non packaged so it won't bug me
<jdub> Lathiat: for initramfs love
* Lathiat nods at jdub
<spstarr> but it removes kubuntu-desktop which removes all of Xorg and other stuff
<Lathiat> spstarr: removing kubuntu-desktop wont remove anything
<daniels> err, removing kubuntu-desktop does not remove Xorg
<Lathiat> its a meta package that purely depends on other things to install them
<spstarr> oh, i guess why it asked me to rip out 780MB?
<jdub> spstarr: the bottom line is - if you need it, it runs. if you don't, it doesn't.
<daniels> probably because of initramfs and the kernel
<Lathiat> are you trying to use some kind of smart package management thats removing everything it depended on or something?
<spstarr> now i have to put it back and its going to reinstall 789MB 
<Lathiat> spstarr: apt-get remove kubuntu-desktop
<spstarr> Lathiat, aptitude
<Lathiat> spstarr: it wont do jack
* Lathiat has no idea about aptitude
<spstarr> aptitude seems to think otherwise oddly
<Lathiat> any which way
<Lathiat> removing it is going to gain you 100K of disk space
<Lathiat> i dont see how thats helpful
<spstarr> but its fixing its self now, i'd still like to see some packages conditional for the next release coming 
<Lathiat> spstarr: like what
<spstarr> its not many
<Lathiat> give a specific example
<spstarr> evms/lvm
<daniels> we've had this discussion before, and the consensus was that if you cared deeply about 200kB or whatever it is, then desktop metapackages are not for you
<jdub> spstarr: again, if you don't need them, they don't run
<spstarr> hmm
<jdub> they're nicely short-circuited in their init scripts
* Lathiat idly wonders if anyone actually uses evms
<jdub> we were very picky about this when we decided to ship great hardware support stuff by default
<jdub> Lathiat: yeah! it is rad.
<Lathiat> jdub: yeah?
<bob2> people use it on laptops, even
<Lathiat> but its gui is 1.2! ;p
<jdub> i haven't fully transitioned, but will when i get my new controller/disks
<Lathiat> (gtk)
<spstarr> otherwise, breezy is just a breeze for release
<jdub> i use the curses one :)
<Lathiat> so what do i do to pull that up?
<spstarr> i need to get my friend to test a bug i submitted for him for his qlogic scsi card blowing up with wrong kernel driver
<Lathiat> evmsn apparently
<jdub> yeah
<spstarr> hopefully he can get the 4th drop 
<Lathiat> jdub: so what does this let me do
<HrdwrBoB> spstarr: hopefully he has another card
<jdub> you can set up named storage sets
<jdub> which can encompass raid, lvm, etc.
<spstarr> HrdwrBoB, breezy loaded/loads the wrong driver 
<jdub> really impressive
<Lathiat> hrm
<Lathiat> i'll have to play with it
<spstarr> HrdwrBoB, ive been told its fixed in 4, so he needs to pull the ISO and let me know :)
<HrdwrBoB> oh, so it didn't 'blow up'
<spstarr> breezy found my qlogic 64bit scsi card no problem 
<spstarr> HrdwrBoB, dont know he hasn't tried it yet
<spstarr> the bug is NEEDMOREINFO state
<Lathiat> has anyone looked into the bunch of people reporting poor hard disk performance in breezy?
<spstarr> daniels: do we have a timetable for when Xorg 7.0RC0 packages will be added to the next drop?
<Lathiat> i figure somethigns loading a generic ide module or something
<bob2> haha
<bob2> daniels: where's my x.org modular cvs packages??///
* Lathiat grins
<spstarr> bob2: I'd love those too
<bob2> haha
<daniels> bob2: stfu
<spstarr> Xorg-HEAD is amazing right now
<daniels> spstarr: 'sometime after breezy releases'
<Lathiat> i want 3d support on my ati!
<Lathiat> :)
<spstarr> Lathiat: r300?
<Lathiat> spstarr: ya
<Lathiat> well, 3x0
<spstarr> its awsome
<Lathiat> 350 i think
<spstarr> i get 30-40 fps for ppracer (tuxracer)
<Lathiat> nice
<spstarr> it varies on the course
<Lathiat> i just want to play bzflag 
<Lathiat> and supertuxkart
<Lathiat> im sure it can manage those :)
<spstarr> supertuxcart eh
* spstarr gets
<Lathiat> yeh i've yet to try it
<Lathiat> since neither my nvidia nor ati want to play ball atm
<spstarr> actually, whats the next release name coming? :)
<spstarr> or thats still secret
<jdub> Lathiat: early initramfs-tools packages included generic ide modules in /etc/mkinitramfs/modules
<jsgotangco> i tried the binary drivers and they work well with me
<spstarr> Lathiat, I have to mit im damin amazed upgrading from debian unstable to breezy was almost painless
<spstarr> er admit
<jsgotangco> although there is no way atm to switch displays with it
<jdub> [4721900.431000]  hda: dma_timer_expiry: dma status == 0x21
<jdub> [4721910.431000]  hda: DMA timeout error
<jdub> [4721910.431000]  hda: dma timeout error: status=0xd0 { Busy }
<jdub> [4721910.431000] 
<jdub> [4721910.431000]  ide: failed opcode was: unknown
<jdub> [4721910.431000]  hda: DMA disabled
<jdub> [4721910.481000]  ide0: reset: success
<jdub> 
<jdub> interesting
<Lathiat> spstarr: you did that? wow im impressed it work, maybe thats why your tryign to remove 800M of stuff ;p
<spstarr> Lathiat, well i had to downgrade GNU libc and such
<spstarr> but, thats it
<elmo> jdub: is that a powerbook?
<jdub> elmo: X300
<elmo> oh, interesting
<spstarr> i had to run a weird dpkg command to do it
<spstarr> something i never saw before
<jdub> intersting like "ouch"
<spstarr> my .bash_history is gone so i cant tell you what ;/
* spstarr looks at #ubuntu channel log
<Lathiat> gah this hard freeze on sata thingies is getting annoying
<Lathiat> fabbione: what happened to that test kernel
<ajmitch> Lathiat: I haven't seen it, I'll try & reproduce it tho
<Lathiat> ajmitch: theres an open bug, apparently fixed, just no new kernel yet
<sladen> I've had freezes here;  they seem to be more related to the PATA CDROM than the SATA laptop drive
<spstarr> apt-get -o"Dir::Cache::archives=`pwd`" -o"Debug::NoLocking=true" -o"Dir::State::status=/dev/null" -d install ubuntu-base
<spstarr> thanks to Seveas 
<spstarr> :)
<spstarr> i should add this all to the wiki
<spstarr> how to upgrade from debian unstable to ubuntu breezy +
<ajmitch> spstarr: it's dangerous :)
<ajmitch> because it'll require a numver of downgrades in some situations
<spstarr> wasn't for me at all other than udev causing the system to hang on boot
<spstarr> ajmitch, i only downgraded gnu libc 
<spstarr> the rest took itself out
<spstarr> heh so i had downloaded 1.1G when it finished updating me
<Lathiat> doesnt mean there arent other problems that cna cause conflicts later
<spstarr> i removed the non -ubuntu* packages (the ones that conflicted me)
<bddebian> elmo: Did you get my e-mail reply about oregano and vipec?
<spstarr> so i have a 99% ubuntu breezy with some debian unstable floating around which will eventually get replaced as dependencies need
<ajmitch> and you'll have config files that may or may not match the package versions you have installed
<spstarr> 780 packages have #ubuntu# marked 
<spstarr> ajmitch, it replaced most of them since i removed all system daemons except udev
<spstarr> which appears broke for me (hangs forever so im using debian unstable version)
<spstarr> 0.68
<spstarr> ajmitch: i wouldn't expect much breakage since breezy has much of debian unstable 
<spstarr> let's just say it's been a pleasent migration :)
<Lathiat> spstarr: i would, it has alot of it but theres alot of differences, and intermixing package versions like that can have all sorts of unexpected results, a prime example being your broken udev as no one else has that problem
<spstarr> well i am using mainline kernels off the shelf
<Lathiat> so its not totally without pain, be warned :)
<spstarr> well, 3 weeks so far, it's been just great
<spstarr> as a former linuxfromscratch nut, i can picture almost all of the dependencies  in my head 
<crimsun> you're using mainline kernels?
<spstarr> oh yes
<crimsun> I wouldn't be surprised if things mysteriously didn't work
<spstarr> im glad ubuntu hasn't complained (other than udev)
<spstarr> yeah
<spstarr> i just have to switch back to Xorg-HEAD, 6.8.2 is killing my video card, the laptop fan is always on since redrawing text has to page the whole window up each time
<spstarr> (in a konsole)
<spstarr> hopefully the xkb stuff is unborked (pressing keys randomly resized the video for some reason)
<daniels> works for me (modular tree, at least)
<spstarr> building it all again now
<spstarr> (in usr/local/X11R6)
<spstarr> im wondering if i need to do some --prefix magic to tell it to look in usr/local for xkb config stuff instead of 6.8.2's version
<daniels> you probably want the xkeyboard-config stuff
<daniels> wa-hey!
<spstarr> oh another module.
* daniels finally finds the root of all the f**king keyboard vs kbd drama, fixes.
<spstarr>  cvs -d :pserver:anoncvs@cvs.freedesktop.org:/cvs/xorg -f co app data doc driver font lib proto util xserver
<spstarr> if that's not in there, i will add to wiki
<Lathiat> daniels: sweet?
<spstarr> xkeyboard-config oh, thats an ubuntu package.. yea i got that, me watches build
<fabbione> morning guys
<fabbione> Lathiat: ping?
<bddebian> Heya fabbione 
<fabbione> hi bddebian 
<Lathiat> fabbione: pong
<fabbione> Lathiat: did you get to test the new kernel?
<Lathiat> fabbione: ah i didnt get the url for it
<fabbione> Lathiat: tsk :P
<Lathiat> fabbione: i asked earlier
<fabbione> http://people.ubuntu.com/~fabbione/linux-image-2.6.12-8-686_2.6.12-8.13_i386.deb <-
<fabbione> i know know that it builds
<Lathiat> wgrabbing now
<Lathiat> fabbione: ok installing now.. just have to wait a few days and see what happens 
<Lathiat> its frozen 3 times today so if it hasnt within a couple days it should be ok
<fabbione> Lathiat: yup.. i am aware of that. thanks a lot
<Lathiat> did mark have any luck?
<infinity>  14:03:27 up 16:42,  6 users,  load average: 0.00, 0.14, 0.27
<infinity> So far, so good.
<infinity> But I'm not going to assume anything until it's been up another day or two.
<fabbione> Lathiat: no idea.. 
<Lathiat> cus his was a desktop issue now? until now i thought it seemed ot be only reported on dell laptops, but i have no idea of the underlying proble
<Lathiat> m
<infinity> Not a Dell here, my daily freezes have been on an IBM laptop.
<Lathiat> ah ok
<Lathiat> so its general then
<infinity> But if it really is an SATA issue, then it could happen anywhere.
<Lathiat> btw i thought we had the patch for SMART w/ SATA ?
<fabbione> Lathiat: no.. we have "go to sleep SATA"
<Lathiat> ah ok i knew about that one, just thought we had the smart one too
<Lathiat> wonder if mjg59 had any luck with the dualpoint issue
<infinity> mdz :ping.
<mdz> infinity: pong
<infinity> mdz : Can I get a UVF exception to toss php5 5.0.5 i. It's a bugfix only release, includes the XML_RPC security fix, and a few nasty fixes I would have pulled from CVS anyway.
<infinity> s/i./in./
<fabbione> infinity: if you want i can pre-test it
<fabbione> my new server is running breezy and php5
<fabbione> and i host a couple of php only sites
<infinity> fabbione : Sure, it's been cooking in sid for a day or two with no bug reports yet.  I'll whip up the Ubuntu sync.  What arch is your server?
<fabbione> i386
<infinity> Alright.  I'll build binaries in a sec.
<fabbione> infinity: is there any diff between breezy <-> sid packaging?
<fabbione> if not i can just pull from sid
<infinity> fabbione : Just disabling some stuff we don't have in main, otherwise it should be fine.
<fabbione> infinity: ok. than i prefer to have the standard pkgs
<fabbione> i am trying to avoid to clutter the machine too much :)
<fabbione> since it's expected to run for at least the next 5/6 years
<mdz> infinity: sounds reasonable; please arrange for test builds of the reverse build deps
<infinity> Already tested, php5-dev appears to agree with it's reverse-build-deps just fine.
<elmo> eh
<elmo> was ipw an out of tree driver we merged in?
<bob2> yes
<fabbione> hey elmo
<elmo> christing banans
<elmo> hey fabbione
<fabbione> elmo: what's the problem with ipw2x00?
<elmo> no problem, I just didn't realise it was something we merged in out of tree
<elmo> I assumed it was upstream
<fabbione> elmo: it's going upstream.. but it's taking a bit of time because of the ieee$whatevernum layer
<fabbione> elmo: i need your comment on #15237
<elmo> fabbione: yeah, linus just merged it
<fabbione> elmo: eheh
<elmo> fabbione: hum, my comment beyond "we need to strip that file"?
<fabbione> meh...
<fabbione> that can be sort of an issue so close to release :/
<fabbione> elmo: thanks...
<elmo> well.
<elmo> we can rebuild main at least, to make sure nothing breaks, FWIW
<elmo> tho you just messed the latest b-at run of DOOM
<fabbione> elmo: i dunno all the tetex internals.. i  am more worried about runtime breakage
<elmo> tetex-extra is for freeekay stuff
<fabbione> did i break what?
<fabbione> when?
<fabbione> how?
<fabbione> elmo: how can i push to you a stripped version for b-at ?
<elmo> well
<elmo> we'll definitely be doing more main runs , like weekly, so can it wait for the next one?
<elmo> if not I suppose I could pause this one, and restart it later today
<fabbione> elmo: i am ok to wait.. given that i need to prepare the pkg first
<fabbione> elmo: how can i push the pkg to you without uploading to the archive?
<elmo> you don't
<elmo> we have to strip this dude
<elmo> if stuff breaks, we'll fix the stuff
<elmo> so upload to the archive, and I'll sync from there
<elmo> (that's how b-at works, it syncs from b)
<elmo> anyway, I need to crash.  g'night
<infinity> elmo : Oh, wait!
<fabbione> elmo: ok.. good night
<infinity> elmo : Can you sync php4 for me before you nap? :)
<elmo> infinity: pls fix king's space again, bonus points for permanently, kthxbye
<elmo> nap, pfft
<infinity> Consider it done.
<infinity> s/nap/slumber/
<elmo> done
<elmo> gone
<infinity> Danke.
<fabbione> ok... 
<fabbione> we can drop tetex*
<fabbione> grep "You are not allowed to change this file" * -ril | wc -l
<fabbione> 33
<[Chameleon] > my Breezy install doesn't have an /etc/modules.conf ... Is this normal?
<Lathiat> [Chameleon] : yes
<[Chameleon] > OK, do I do my configurations in some file under /etc/modules.d ?
<[Chameleon] > it's not obvious which I am to modify
<[Chameleon] > er, /etc/modprobe.d
<[Chameleon] > :)
<[Chameleon] > oh crud
<[Chameleon] > n/m
<Lathiat> [Chameleon] : what are you trying to d?
<[Chameleon] > I see that it is modules I am needing to modify
<[Chameleon] > GXine says: "If you are using the ide-cd module ensure
<[Chameleon] > that you have the following entry in /etc/modules.conf:
<[Chameleon] > options ide-cd dma=1"
<fabbione> [Chameleon] , Lathiat: please move to #ubuntu
<fabbione> it's offtopic here.. thanks
<[Chameleon] > fabbione: sorry... I did try several times in #ubuntu, but nobody would help.
* [Chameleon]  is on track now. Thanks.
<infinity> fabbione : Still want test binaries, or sould I just do a source upload?
<fabbione> infinity: if you want me to test, i can.. up to you
<doko> mdz: dropping xpdf-utils seems to be possible, although I'm not yet sure, if we need pdftohtml. but: pdftohtml is derived from xpdf-2.02, which should not enter main
<doko> mdz: do you remember the reason why to drop xpdf-utils together with xpdf?
<fabbione> we might have to drop tetex* from main
<infinity> fabbione : I've tested enough here to satisfy myself, and my bandwidth sucks, so I'll just do the source upload. :)
<fabbione> infinity: works for me
<fabbione> mdz: can we get a picture of what would happen if we move tetex* out of main?
<fabbione> s/main/archive.....
<fabbione> or move it multiverse..
<mdz> doko: the reason was that poppler provided the same functionality
<mdz> doko: pitti added a program or two to it, iirc
<mdz> fabbione: rdepends in germinate-output
<fabbione> MEH
<fabbione> i guess that's not an option
<fabbione> not without killing docs on 3/4 of the archive
<jdub> Just one question....The boot splash was the absolute best I've ever
<jdub> seen anywhere, any distro.
<jdub> Is this a part of Breezy now, or a future addition?
<jdub> ^ ha ha
<doko> mdz: hmm, didn't know that poppler uses the xpdf sources ...
<jdub> doko: it's a fork
<infinity> gh.
<infinity> Argh, too.
<infinity>  libghc6-cabal-dev is hosing buildd chroots.  Yay.
<fabbione> infinity: how so?
<infinity> See, for example: 
<infinity> http://hwdb.ubuntu.com/buildlogs/?show=http://people.ubuntu.com/~lamont/buildLogs/t/tea/9.0-1/tea_9.0-1_20050913-0526-powerpc-failed.gz
<infinity> It's sticking around half-installed, and killing all builds after the one that tried to install it.  YAY.
<fabbione> meh
<infinity> Oh, this is so broken in so many ways.
<infinity> The postinst does a chmod +x on something in /usr/share/doc, then runs it.
<infinity> <shudder>
<pitti> Morning
<ajmitch> hi pitti
<infinity> Christ on crutches, there are a whole mess of ghc libs that are broken in cute and interesting ways.
<infinity> ajmitch : Feel like being a productive MOTU today and fixing a mess of bugs?
<ajmitch> infinity: sure, I might as well be productive for a change
<infinity> :)
<infinity> ajmitch : apt-get install libghc6-cabal-dev libghc6-hsql-dev ... Those are both broken.
<infinity> In different ways.
<ajmitch> such as?
<infinity> postinsts failing in both cases, leaving the packages half-installed and hosing chroots.
<ajmitch> how badly will I screw up my box like the buildd if I install?
<infinity> Easy neough to purge the packages after the fact.
<infinity> (Well, -hsql- may require some manual fiddling to purge..)
* fabbione goes to buy a new power supply for his workstation
<fabbione> bbl
<ajmitch> rules & postinst look strange, for sure
<infinity> The postinst is utter crack, but that's not the point.  The point is how it dies.  Debian bug #300461, if you're curious, but there's been no response to it.
<ajmitch> I'll take a look at it
<infinity> Danke.
<pitti> elmo: please sync tdiary
<ajmitch> looks like there's new code in haskell-cabal's darcs repo, so at least it's not forgotten
<ajmitch> infinity: good news is that that package was never meant to work with ghc 6.4 :)
<infinity> And the bad news?
<ajmitch> the debian maintainer never bothered to upload any of his newer versions
<ajmitch> simple to fix
<infinity> If it's simple, pretty please fix it. :)
<ajmitch> will upload asap
<infinity> If you get a fixed package uploaded, I'll fasttrack it through the buildds ASAP, so I can then go around cleaning everything up. :/
<infinity> ajmitch : Can you check on libghc6-* (whatveer apt-cache search shows you) as well, just for sanity's sake?
<infinity> ajmitch ; The fact that my first random try (-hsql-dev) was also broken kinda freaks me out.
<ajmitch> sure
<ajmitch> cabal is a build system for this stuff, so it might be breaking the others
<infinity> No, hsql appears to be broken due to the postgresql transition.
<infinity> But the general feeling I get is that it's all rather old, crusty, and unmaintained in breezy (likely due to the fact that we bootstrapped ghc6 only recently...)
<torkel> 1G
<ajmitch> this package is certainly annoying
<ajmitch> works fine if I build in-tree
<ajmitch> produces a broken register.sh if I use pbuilder
<infinity> Missing a build-dep?
<infinity> Or just does something Very Wrong somewhere?
<ajmitch> something Very Wrong, I suspect
<ajmitch> no surprises there
<crispin> daniels: btw, have you seen bug 15167 ?
<daniels> crispin: hmm, turns out I forgot to dput it
<daniels> actually, no
<daniels> gar
<daniels> weird
<daniels> will look at it later
<Mithrandir> elmo: could you please melanie the readahead source package?
<KwongPham> I need some confirmation about 
<KwongPham> 'fglrx_xgamma' command
<KwongPham> when I run it
<KwongPham> it said it miss libxgamme libary file
<Treenaks> KwongPham: file a bug please
<hunger> Any chance of getting a updated ATI driver in breezy?
<infinity> hunger : Yes, it's happening.,
<hunger> Maybe that problem will go away then, too;-)
<hunger> infinity: Great! And sl-modem-deaemon was updated, too!
<hunger> infinity: linux-restricted-modules are getting really useable again. Thanks for fixing that.
<infinity> Not much I did to make them useable.
<infinity> I think my name is in the changelog all of once.
<hunger> infinity: Well, you gave me the good news, you get the fame;-)
<hunger> infinity: Now if only I could use the lrm...
<hunger> infinity: Got to build all that stuff myself since the breezy kernel is not stable for my system.
<infinity> ajmitch : Any progress?
<infinity> hunger : What happens on your system?
<hunger> infinity: It is just plain unstable... longest uptime with a ubuntu kernel is about 3h.
<infinity> hunger : Does it lock up hard, does it panic, oops repeatedly..?
<hunger> infinity: Hard lockup. 2.6.13 is rock solid. I guess it is due to PCIe support.
<infinity> hunger : SATA?
<hunger> infinity: Laptop with SATA, PCIe and all the other new stuff.
<infinity> hunger : Same her, an IBM T43 in my case.
<infinity> hunger : s/her/here/
<infinity> hunger : i686?
<hunger> infinity: T43p here;-)
<infinity> hunger : Can you test this kernel for us?
<infinity> http://people.ubuntu.com/~fabbione/linux-image-2.6.12-8-686_2.6.12-8.13_i386.deb
<infinity> (I've been running on my machine for about a day with no lockups yet)
<hunger> infinity: sure... on friday or so.
<infinity> Kay, the more people who say it's all good, the better.
<hunger> infinity: I probably won't have network access with the laptop till then.
<infinity> If my machine stays up for another day or two, I'm calling it "good", though.
<hunger> infinity: It will be better than the "normal" ubuntu kernel in any case;-)
<hunger> infinity: 2.6.13 is a nice kernel, dunno whether I'll head back for some modules I build myself already anyway.
<infinity> We'd still appreciate the testing, though, even if you dont plan on running the stock kernel.
<infinity> Pretty please. :)
<jsgotangco> hrmmm
<jsgotangco> i can prolly test that deb now
<jsgotangco> and make it run for a few days
<hunger> infinity: Sure, I will test it once I can get my laptop online again.
<fabbione> guys feel free to test it
<fabbione> but remember that's not final.. do there might be more changes before release
<fabbione> so remember to upgrade it
<hunger> infinity: It sucks that I have no internet here... well except for my tiny little tunnel through the firewall of this bank;-)
<jsgotangco> hmm is it usable in hoary? or do i have to install it in breezy
* hunger loves competent firewall admins.
<infinity> breezy would be preferable.  Brrezy kernels on hoary break things in subtle ways.
<fabbione> infinity: they break. full stop
<fabbione> there are too many pkgs you need from breezy
<fabbione> i need to figure a way to make the kernel for release+1 completely uninstallable on release
<infinity> Versioned dep on lsb-release, but.. Uhh.. Please don't. :)
<infinity> That's just vile.
<fabbione> infinity: no, that's too easy to workaround
<fabbione> i need something really hardcore
<hunger> fabbione: apt-get -y distupgrade in pre-inst? ;-)
<fabbione> hunger: no. that won't work because the pkg db is locked during an installation and it can't be made available to another session at the same time
<fabbione> i was more thinking of an hash on some files...
<fabbione> checked at boot time..
<hunger> fabbine: Forcing an upgrade is *REALLY* evil, too;-)
<fabbione> and that will kprint the hell of warnings everywhere.
<hunger> fabbione: Which files are guaranteed to stay stable during a releasecycle?
<fabbione> till you will be so tired of them that you must reboot with the proper kernel :)
<fabbione> hunger: a bunch
<fabbione> on fresh install i could just use sources.list
<fabbione> so as soon as you add one extra repo, i will refuse to boot :P
<hunger> fabbione: Require a TPM and use the trusted grub;-)
<hunger> fabbione: Imagine all the PR: "Ubuntu looks down software even before MS managed to do it!" ;-)
<fabbione> that won't work either.. grub loads dynamically a set of files
<Treenaks> hm, my laptop has a TPM chip...
<fabbione> Treenaks: quite a lot do...
<Treenaks> fabbione: linuxbios + TPM :)
<sivang> morning all
<hunger> fabbione: Not the trusted one... loads only stuff that matches MD5 sums that are locked to a TPM.
<sivang> (or g'afternoon)
<Treenaks> hey sivan
<sivang> yo Treenaks 
<sivang> fabbione: hello
<fabbione> hi sivang
<hunger> Treenaks: Linuxbios is not TPM compatible AFAIK.
<Mithrandir> fabbione: uhm, what are you trying to accomplish?
<fabbione> Mithrandir: make impossible to backport kernel for release foo into release bar
<Treenaks> hunger: ... yet ?
<hunger> Mithandir: Stop people from using kernels know to be incompatible with their release.
<Mithrandir> fabbione: as long as people have the source, you've lost.
<fabbione> Mithrandir: clearly.. kernel developers should be able to do so
<fabbione> Mithrandir: never talked about source :P
<fabbione> sabdfl: hey.. did you get to test the kernel by any chance?
<hunger> Mithrandir: I think fabbione wnats to stoip ubuntu people using ubunut kernel debs only.
<fabbione> hunger: uh?
<hunger> aehm... stop them using incompatible kernel debs of course:-)
<fabbione> hunger: no, i don't want people to run breezy kernel in warty (for example)
<fabbione> becuase it breaks
<sabdfl> fabbione: +1 so far, am trying to arrange some stress testing today
<Mithrandir> fabbione: fix the incompatibilities, then.
<sabdfl> continuous LP "make check" runs should do it ;-)
<fabbione> and people are not always aware of all the subtle breakage that can happen with kernel/userland mistmatch
<hunger> fabbione: Yeap: Ypou want to stop people from using kernel debs that are known to break their release.
<fabbione> Mithrandir: you can't
<fabbione> sabdfl: cool! thanks for testing
<fabbione> hunger: exactly.
<fabbione> hunger: it's not meant to be in bad way
<fabbione> it's meant to protect user to do stupid things
<hunger> fabbione: Which was what I was trying to say to Mithrandir (and obviously failed to convey).
<fabbione> sabdfl: ehehhe.. 
<fabbione> i need to checkout LP once for fun
<Mithrandir> fabbione: express it in the package dependency system
<hunger> LP?
<Mithrandir> hunger: no, I think you/he is trying to solve the problem in the wrong way.
<fabbione> Mithrandir: it can be easily overriden
<Mithrandir> fabbione: yes, and so?
<fabbione> Mithrandir: that won't solve the problem
<Mithrandir> fabbione: dude, people can fuck their system if they try hard to .  You can't stop them.
<fabbione> Mithrandir: that's true.. 
<Mithrandir> make it obvious that it's what they're doing, but if they proceed, well, then they do it at their own risk.
<hunger> fabbione: I think Mithrandir has a point: You can't stop people from being stupid. You just should try to protect them by default.
<[Chameleon] > fabbione: can you simple parse the /etc/lsb-release file and check version in a pre-install script?
<hunger> fabbione: If someone forces a kernel to get installed then he must expect problems... and he will probably mess with your hashes or whatever you come up with, too.
<[Chameleon] > s/simple/simply
<Mithrandir> making it ~impossible to do stupid things makes it similarly hard to do clever things
<fabbione> [Chameleon] : there are tons of way to do that. i need find a reliable one that can't be easily overriden, until you really know what you are doing
<fabbione> i do expect people to be able to bypass it
<fabbione> but not the average foo user
<[Chameleon] > fabbione: you can just prompt. "Are you sure?" then again "Are you REALLY sure?! This is unsupported!"
<[Chameleon] >                   ^ and WILL break things!
<fabbione> [Chameleon] : the prompt/warning is not the issue.. but how to gather the info required...
<[Chameleon] > normal users will heed warnings
<[Chameleon] > parse the release file. that's simple enough
<[Chameleon] > IMHO
<fabbione> [Chameleon] : yes.. but that's easy enough to be overridden :)
<fabbione> that's the whole point
<Mithrandir> fabbione: why is that a problem, really?
<fabbione> Mithrandir: because a lot of users have been playing backports, broken their systems and come back with the most desperate bugs that nobody was able to understand
<fabbione> till we figured their were running whatever unknown backport repository
<fabbione> = a lot of time spent for really hard to support configs
<hunger> fabbione: I think it would be better if you could collect data about the release for the bugreport so that you know you can close it because the users were stupid.
<bob2> refuse to fix weird bugs unless you see a sources.list ad dpkg -l output
<fabbione> hunger: eh.. if it only was that simple...
<fabbione> they still reopen bugs and complain and blablabla
<hunger> fabbione: Sure... but what makes you think making it harder for them to install a broken kernel will stop stupid people from being a pain?
<fabbione> hunger: it's a balance 
<fabbione> i make it harder for him to break his system
<Mithrandir> I guess the backporters are just going to rip out that protection anyhow
<fabbione> i warn him a few extra times
<fabbione> at that point i feel much less guilty to wave him kthxbye
<hunger> fabbione: You come up with something clever... next day there will be a wiki page about how to get around the fabbione-bossyness and the day after you get your bugreports.
<hunger> fabbione: There will be some namecalling about you taking the freedom to ruin your system, too.
<fabbione> hunger: that's the same kind of namecalling when we smash systems by mistake
<fabbione> so they have no point in the latter
<[Chameleon] > back, was taking care of laundry
<fabbione> yes.. there might be a wiki page...
<[Chameleon] > um, I think that if you throw up warnings for ppl trying to override, you've done due dilligence
<fabbione> [Chameleon] : right..
<sivang> pitti: [Chameleon]  pointed out out to me the other day, about the non showing "enable IPP browsing in g-c-m" , I discovered it was eventually due to not running as root or sudo'd , why is g-c-m not asking to gain sudo rights anymore?
<sivang> pitti: so the scripts are now there, but unless you sudo g-c-m you cannot use it
<pitti> sivang: g-c-m was never supposed to run as root
<pitti> sivang: as long as the user is in group lpadmin, he can talk to cups
<[Chameleon] > should users be in that group by default?
<bob2> they are
<pitti> [Chameleon] : the first user is
<[Chameleon] > I didn't have to modify my groups in Hoary to modify the Detect LAN Printers option
<[Chameleon] > hmm
<[Chameleon] > my user is marked as having the priveledge to setup printers.
<[Chameleon] > yet running the System > Admin > Printing app does not prompt for a password and does not display the menu for LAN Detection
<[Chameleon] > (unless run from terminal with sudo)
<[Chameleon] > just tried on my wife's Ubuntu machine. It does not prompt (as you said), but the Detect LAN Printers menu is available.
<[Chameleon] > Hoary
<Mithrandir> mvo: what's the state of the patch in the last message in 8265?
<sivang> pitti: sure, but then it can't access /usr/share/cups I think
<sivang> pitti: so we might want to make this location chgrp'd for lpadmin ?
<pitti> sivang: hm? /usr/share/cups is world readable
<sivang> pitti: weird, I get permission denied
<sivang> pitti: I'll recheck
<[Chameleon] > paul@Chameleon:/usr/share$ ls -l | grep -i cups
<[Chameleon] > drwxr-xr-x     9 root root  4096 2005-09-05 02:41 cups
<sivang> pitti: do you get the LAN detection menu ?
<pitti> sivang: hum, no
<pitti> sivang: somehow this has broken
<sivang> pitti: ok, I will try to find it and fix it then
<mvo> Mithrandir: pretty good, I can upload it today 
<Mithrandir> mvo: thanks
<pitti> sivang: ah, I know the reason
<sivang> pitti: ok, what is it ? :)
<pitti> sivang: -rw-------  1 cupsys lpadmin 22911 2005-06-23 13:49 /etc/cups/cupsd.conf
<sivang> bah
<pitti> sivang: this file needs to be 640, not 600
<sivang> pitti: so lpadmin could write to it as well..?
<pitti> sivang: no, not write, but read
<pitti> 640, not 660
* mvo reboots to test a change, brb
<sivang> pitti: oh, since you write changes to the included snippet.
<pitti> sivang: no, that requires root privs (g-c-m asks for gksudo, remember?(
<sivang> pitti: since I upgraded to breezy it never asked me..
<[Chameleon] > ditto
<[Chameleon] > didn't need priveledges in Hoary
<sivang> pitti: ah no, you're right. we didn't get the menu item so there was no need :)
<[Chameleon] > changing that file is not enough
<[Chameleon] > it seems
<[Chameleon] > I changed the permissions, which did cause the menu item to show up
<[Chameleon] > It is currently enabled due to my setting it under sudo previously
<[Chameleon] > however, when I then try to modify that setting, I am prompted by gksudo, which I proceed through, then a dialog box warning of security implications is shown...
<pitti> [Chameleon] : that's fine
<[Chameleon] > Neither OK or Cancel result in the option being altered
<[Chameleon] > that's what is not fine
<sivang> hmm
<pitti> uh, not? please file a bug about that then
<[Chameleon] > OK
<sivang> [Chameleon] : assign it to me , if you may :)
<pitti> I'm currently busy, will deal with that later
<[Chameleon] > sivang: I don't have the ability to assign bugs it seems.
<sivang> [Chameleon] : ah ok
<[Chameleon] > when I tried before, it said I could not
<[Chameleon] > but, I will CC you
<[Chameleon] > :)
<sivang> [Chameleon] : thanks
<[Chameleon] > np
<pitti> [Chameleon] : don't worry, I will see the bug no matter who it is assigned to
<[Chameleon] > thank you both
<\sh> morning
<sivang> [Chameleon] : thank you for spotting this up
<[Chameleon] > np
<sivang> pitti: can you assign it to me when you see it?
<[Chameleon] > we can thank my wife! she's the printer!
<[Chameleon] > I hate paper.
<[Chameleon] > hehe
<pitti> sivang: for my sake, but I think I have a fairly good idea where to look for the bug
<Treenaks> [Chameleon] : you married a printer?!
<[Chameleon] > LOL, might as well have...
<[Chameleon] > our office is covered in paper!
<\sh> seb128_: ping can I send a SIGUSR2 to the gamin server and to the gnome-panel as gamin client to get a good debug output? 
<sivang> pitti: ok then, np
<seb128_> \sh: should do the trick yep
<\sh> seb128_: I see it now
<\sh> seb128_: when we're talking about /usr/share/applications does it mean "check recursively" for the gamin_server?
<doko> infinity, lamont: what's the current state of OOo2? if it's currently not building, please retry it, some error during the setup of the b-d's
<pef> hi
<[Chameleon] > hello
<\sh> moins mvo 
<mvo> \sh: hi
<sivang> hey mvo 
<mvo> sivang: hi
<seb128_> \sh: probably not
<\sh> seb128_: ok...I see that it tries to examine the /etc/xdg/menus/applications.menu but I don't see gamin pulling any kde-applications.menu...that could mean, that gnome-panel doesn't request those files?
<seb128_> no
<seb128_> the .menu defines the categories, the structure of the menu etc
<seb128_> gnome-panel use the GNOME layout, not the KDE
<\sh> seb128_: ok..so everything which is defined in these xdg menu files and has a match in the .desktop files in /usr/share/applications/ should be pulled in...even those kde/*.desktop ones 
<seb128_> the code has some special case for KDELegacy
<seb128_> gnome-menus has a debian/patches/03_kde-legacydirs.diff
<seb128_> -  <KDELegacyDirs/>
<seb128_> but I don't think that's the issue
<seb128_> some users have the issue with pan too
<mvo> mjg59: is there a way to detect that usplash is runing?
<seb128_> which is installed to /usr/share/gnome/apps/Internet/
<mvo> mjg59: in a init script that is
<\sh> seb128_: in the /etc/xdg/menus/applications.menu there are the LegacyDirs defined
<\sh> seb128_: <LegacyDir>/usr/share/gnome/apps</LegacyDir>
<seb128_> I know
<seb128_> and KDE has a special one coded from the sources too
<mjg59> mvo: No. Why?
<mjg59> Well, other than pidof usplash
<mvo> mjg59: for #14691
<\sh> seb128_: so where do I have to look ;) or do u have a suspicion?
<mvo> mjg59: I would like to skip setting the console-font for vc0 if usplash is runing
<seb128_> \sh: no suspision, no
<mjg59> mvo: Uhm. So is the call only relevant if it's a VGA terminal, or is it just the difference between graphical and text mode?
<mvo> mjg59: it looks like it's the difference between graphical or text-mode 
<\sh> seb128_: i will restart the session now..to see what it does in the beginning
<seb128> k
<\sh> brb
<mjg59> mvo: pidof is about the best I can offer you, I'm afraid
<mvo> mjg59: ok, fair enough
<mjg59> More sensible would be to check whether the screen is in graphical mode and not error in that case, I'd guess - that way it doesn't end up being usplash specific
<mvo> mjg59: right, I'll have a closer look
<\sh> seb128: I have it
<\sh> seb128: when I restarted the complete sessions I can see that gnome-panel is trying to fetch all dirs (even the subdirs like kde or Development) 
<\sh> seb128: now I'm waiting for the disappearing
<seb128> k
<mvo> mjg59: does usplash do any video mode switching on it's own?
<mjg59> It uses bogl
<mjg59> Which does, by the looks of it
<mvo> mjg59: looking at the code it's doing a lot of interessting things. haven't seen so many outbs in a while :)
<mjg59> vga16 is like that, sadly
<mvo> mjg59: so it looks like it's setting up it's very own video mode and bypassing the framebuffer more or less? 
<\sh> seb128: disappeared ;)
<\sh> seb128: u need the debug file to see it happening?
<mjg59> mvo: You have to for vga16
<mjg59> The only thing the driver gives you is access to the framebuffer
<seb128> \sh: probably yep
<\sh> seb128: done it's attached to #14967
<jordi> doko: dude?
<jordi> doko: you ping me and never replied
<seb128> jordi: are you registred? maybe he didn't get your pong
<jordi> doh
<jordi> fucking stupid thing
<jordi> doko: ah well. I had an ispellcat nearly ready for upload.
<jordi> I just had to fix an issue with the has autogeneration.
<hunger> Can I change the resolution used by usplash somehow?
<mvo> hunger: no
<hunger> mvo: Are you sure? I read something like "use center 640x480 pixels independent of fb size" or something similar.
<hunger> mvo: In the changelog that is... don't have my laptop handy, can't check right now though.
<pitti> infinity: any chance to disable royal? I still need to g-b packages...
<mvo> hunger: it uses vga16, I don't think you will be able to change the resolution. the change you mentioned seem to be cfb (powerpc) specific
<mvo> hunger: or is your laptop a ppc?
<hunger> mvo: Oh, that explains it then:-)
<hunger> mvo: Nope. I had assumed usplash to use the fbdev, not vga16.
<mvo> hunger: ok :) 
<\sh> infinity: can u give me a short update on ghc6 upload? :) 
<Diziet> What's our usual approach to new bugfix upstreams of say firefox ?
<doko> jordi: sorry, anyway. Thought you wouldn't mind that much about the NMU.
<jordi> doko: nope.
<seb128> \sh: 
<seb128> inotify: resource /usr/share/applications/kde went away. Adding it to missing list
<seb128> inotify: Emitting Deleted on /usr/share/applications/kde
<seb128> inotify: got an event for unknown wd 55
<seb128> \sh: seems to be an inotify bug
<\sh> seb128: hmm
<bob2> firefox's concept of "bugfix releases" is pretty broad
<Kamion> hunger: that change was generic, but vga16 framebuffers are always 640x480 so it's a no-op there. If usplash ever starts using other framebuffer types on i386/amd64, it will apply to them
<bob2> including "breaking extension API"
<Kamion> Diziet: roughly "treat with extreme caution, especially if it's firefox, but sometimes we have to give up because its security fixes are impossible to backport"
<\sh> seb128: ok..now you have your bad boy ;)
<pitti> Diziet: for breezy we should generally allow them, to make further backporting easier
<Kamion> we've been burnt before by taking a firefox bugfix release at the last minute
<Kamion> mozilla-firefox | 0.99+1.0PR.1+revertedto0.9.3-0ubuntu3 |         warty | source, amd64, i386, powerpc
<\sh> seb128: but what if gnome-panel as gamin client is adding those dirs again? it should, right?
<Kamion> but as pitti says we may not get a choice
<pitti> it was a similar hell to make warty halfway work again with the 0.9.3->1.0.6 upgrade
<jordi> pitti: what can we do about the Kurdish guys not having a locale?
<pitti> jordi: add it to libc?
<seb128> \sh: no it should not, inotify/gamin said the directory went away, no point to monitor a non-folder
<jordi> pitti: who writes it? :)
<jordi> pitti: got my email/know anything about CAN assignment?
<pitti> jordi: I got your mail, looked fine. You didn't get an answer yet?
<\sh> seb128: as this is not the truth...inotify is in the kernel, right?
<mjg59> Yes
<jordi> pitti: no
<sivang> mjg59: it's a kernel interface right?
<seb128> \sh: right, but maybe that's a bug with the gamin code for inotify
<jordi> pitti: I guess I should upload now.
<pitti> jordi: I think you should get an answer by this evening, but if you already want to upload, just go ahead
<mjg59> sivang: Yes
<pitti> jordi: you can always add the CAN to the changelog later
<Diziet> kamion: Hmm.  I've just had an email from them about their `upcoming 1.0.7 security release'./
<jordi> pitti: I will then.
<seb128> \sh: could you package gamin 0.1.6 and figure if you get the issue with it?
<\sh> Mithrandir / maswan: can u please install on ravel breezy chroot: debmake glade-2 bison
<pitti> Diziet: any concrete date?
<\sh> seb128: I can try :) 
<seb128> \sh: I planned to not upgrade because 0.1.5 works quite fine and new version has a bunch of changes/rewrittable but that's worth knowing if it fixes it
<Diziet> pitti: They're freezing today.
<pitti> Diziet: ok, so it has a chance to go into Breezy?
<Diziet> They're asking me `do I mind if they don't include this fix' (the textarea segfault) which obviously I don't mind but I think they're probably making a mistake.
<Diziet> Well, yes, but I'm not sure how late we'd want to take one.
<pitti> Diziet: the 1.0.6->1.0.7 upgrade should be much less painful than warty's beta version juggling
<seb128> Diziet: you are maintaining firefox package atm?
<pitti> Diziet: if they release by next week, that should be fine
<Diziet> I haven't found out their schedule yet, but I would have hoped they would.
<\sh> seb128: working on it...
<seb128> \sh: thanks
<seb128> \sh: according to the code the debug is when inotify send a delete signal for the folder... I'm wondering why that happens
<seb128> \sh: have you an idea on what trigger the bug? dist-upgrade? package install or removal?
<Kamion> elmo: please sync groff 1.18.1.1-10 from incoming; mdz OKed it last night
<\sh> seb128: nothing...I just restarted the session...and did nothing at all...running gnome-terminal, firefox and evolution
<\sh> seb128: did gam_inotify.c: In function 'mask_to_gam_event':
<\sh> gam_inotify.c:259: error: 'IN_MOVE_SELF' undeclared (first use in this function)
<\sh> gam_inotify.c:259: error: (Each undeclared identifier is reported only once
<Kamion> 2005-09-13 11:36:18 GMT Colin Watson <colin.watson@canonical.com>       patch-153
<\sh> say anything to you?
<Kamion>     Summary:
<Kamion> ogra: ^--
<Kamion>       Edubuntu: re-enable IP address preseeding (requires cdebconf 0.84ubuntu6); switch to 192.168.0.2 to work around netcfg bug
<ogra> yay
<ogra> Kamion, thanls a lot :)
<ogra> thanks even
<Kamion> no problem
<ogra> Kamion, i have some reports that the server bootoption doesnt work for the CD ... did you disable it ? 
<Diziet> pitti, Kamion: thanks.  We'll see what they say.
<Kamion> ogra: you told me to rename it to edubuntu
<ogra> i'm not particulary after having a server option on the Cd if it generates work, but i'll have to fix the introduction text...
<seb128> \sh: nop
<Kamion> ogra: if you want me to re-add a server option, I'll do that
<Kamion> ogra: (server meaning "base system only")
<ogra> Kamion, if its easy done, yes, if it takes time, no, then i'll just submit a fixed intro text
<ogra> yup...
<Kamion> it's straightforward, I'll do it now
<ogra> ok, thanks
<\sh>  IN_MOVE_SELF the same as IN_DELETE_SELF
<\sh> hmmm
<seb128> Diziet: could you push this change with the next upload: https://bugzilla.ubuntu.com/show_bug.cgi?id=8680 ? xfce guys would be happy to have a desktop running without gnome libs used
<Diziet> seb: Looking at it now.
<mvo> Kamion: do you have a idea how we could fail more gracefully in #13713? some sort of timeout maybe?
<seb128> Diziet: the changed the dh_install to exclude imgicon, modified the .install ... and there is probably a Replaces to put too. That should get ride of the firefox depends on GNOME
<seb128> Diziet: thanks
<\sh> seb128: i have to patch this 
<\sh> seb128: it pulls in linux/inotify.h but #define IN_MOVE_SELF           0x00000800      /* Self was moved */
<\sh> is not defined in there
<Diziet> seb: That doesn't look too hard.  Sure, I'll put it in my upload this afternoon.
<seb128> Diziet: thank you
<Diziet> I'll let you know if I come across a snag that means I have to bail on it.
<seb128> k
<Kamion> ogra: done
<Kamion> mvo: perhaps you could just fail rather than prompting if stdin is not a tty, and I could redirect aptitude's stdin from /dev/null in base-config?
<ogra> Kamion, thanks
<\sh> ok..restarting session
<\sh> brb
<mvo> Kamion: I could change that in aptitude (it has it's own MediaChange code). would that mean that cd-only server installs always fail? because there is no network fallback for the needed packages?
<Kamion> mvo: no, CD-only server installs still copy a few .debs to the hard disk so that it all works
<Kamion> mvo: it only breaks if (a) there's a bug or (b) if you deliberately skip the code that makes it work, as some people seem to feel the need to do :-)
<\sh> seb128: strange...sending SIGUSR2 to the new gamin doesn't give me any debug output file anymore
<mvo> Kamion: ok, that sounds reasonable, thanks. I'll add a comment to the bug and implmenent the needed change in aptitude
<Kamion> mvo: Great, thanks. There's nothing else in apt/aptitude that will fall over if I redirect stdin from /dev/null, is there?
<Kamion> actually I guess I could just try that out now
<mvo> Kamion: I don't think there will, but it's certainly better if you try it :)
<seb128> \sh: there is no upstream bug about that :/
<seb128> \sh: how quick do you have the issue? does it happen with the "pan" entry too?
<\sh> seb128: it takes sometime...for the last debug session it was 30 mins
<seb128> \sh: I maybe known why I've not the issue, I still use 2.6.12-3-k7
<seb128> s/known/know/
<seb128> lemme try with an update linux package
<seb128> if that's it, that due to inotify code
<\sh> seb128: ok...I don't get a debug output at all...so I'm just waiting for something to happen ;)
<seb128> that's fine too
<seb128> \sh: we just need to know if that happens with it too
<Kronoss> hi
<\sh> seb128: yeah
<pablof> what filesystem i use mounting initrd ?
<\sh> seb128: inotify: resource /usr/share/gnome/apps/Applications went away. Adding it to missing list
<\sh> inotify: Emitting Deleted on /usr/share/gnome/apps/Applications
<\sh> inotify-missing: add - /usr/share/gnome/apps/Applications
<\sh> inotify: got IGNORED event for unknown wd 23
<seb128> \sh: how did you got the debug mode?
<\sh> seb128: it took some time that gamin was creating it
<seb128> \sh: that's not the same message than before ... does it bug or not?
<\sh> seb128: not now
<\sh> seb128: I'm waiting for the kde stuff
<seb128> do you have pan installed?
<\sh> seb128: no...but I can...moment
<seb128> yes please
<seb128> so you can note if it has the same issue than KDE entries
<\sh> seb128: but with 0.1.6 i have panel crashes again :
<\sh> (
<seb128> not cool
<\sh> that's right
<hunger> fabbione: Where was that kernel of yours again?
<hunger> fabbione: The one we should test with SATA?
<spacey> mvo, you there?
<fabbione> hunger: http://people.ubuntu.com/~fabbione/
<hunger> fabbione: Thanks!
<fabbione> hunger: linux-image-2.6.12-8-686_2.6.12-8.13_i386.deb
<mvo> spacey: yes
<spacey> mvo, remember what we talked about friday?
<mvo> spacey: about the i18n patches?
<spacey> no
<ivoks> fabbione: sata problems?
<mvo> spacey: then no, please help me :)
<spacey> about working on ubuntu for my school/study
<mvo> spacey: right, rings a bell now
<spacey> i got reply from my school, and its probably OK. But need to state my activities clearly, and need someone for guidance/supervising. and the difficulty should be high enough
<spacey> you know who i should contact about this?
<mvo> spacey: I think JaneW might be a good person to talk to
<mvo> JaneW: around?
* mvo curses heartlily at apts MediaChange code
<spacey> oh and i have to learn something new.
<mvo> spacey: but I think that shouldn't be a prolbem. at least the "learn something new and it must be difficult" bits ;)
<mvo> spacey: the good thing is that you can more-or-less choose what to work on (or at least in what area). do you already thought about what interessts you most?
<JaneW> yes
<JaneW> mvo: with a month to the release will anyone be prepared to act as a mentor?
<JaneW> mvo: even the Google SoC was tough at times and that's already wrapped
<mvo> JaneW: *nod*, we probably can't do that before the release. spacey, when does your work has to start?
<spacey> it would start in november till end of januari
<ajmitch> so around the time of UBZ, I guess
<mvo> spacey, JaneW: that should match pretty well with our development cycle
<spacey> have to look up the exact dates, but it ends end of jan. and it its like 9 weeks
<spacey> starts in november i'm sure
<JaneW> mvo, spacey : that;s good news :)
<JaneW> spacey: you should probably try for a bounty...?
<JaneW> spacey: assuming you have some skills already...
<spacey> JaneW, i'll look at that as well, but besides that i would like to master packaging stuff, generel development. school demands that i need to learn something new in any way
<spacey> JaneW, my coding skills are quiet limited unfortunately
<\sh> seb128: until now, no disappearing ... but I can see some issues, that inotify wants to delete the dirs..but readds them again
<mvo> spacey: may I ask what school/subject you do? 
<hunger> fabbione: Running your kernel now. Let's see how stable it is:-)
<spacey> Informatica (dutch name), IT stuff, i can code somewhat but not my strong point, but i know the basics
<fabbione> hunger: thanks for testing
<seb128> \sh: k, so inotify has some issue and gamin handle that it seems?
<\sh> seb128: looks like...0.1.6 that is now
<spacey> mvo, as a side job i deploy linux stuff, and in general i'm at least advanced user/admin, but want to pick up the development stuff, would be great if i can do that for school/ubuntu
<\sh> seb128: and for 0.1.6 u have to patch something in server/gam_inotify.c
<seb128> \sh: but you get panel crashes?
<\sh> seb128: when I installed pan
<seb128> do you have the backtrace?
<\sh> seb128: from panel? no :( 
<\sh> seb128: I try to reproduce it now
<spacey> JaneW, bounties mostly seem for breezy/advanced coding stuff atm
<seb128> \sh: I've a 5M debug file with no "went away" message running for like an hour
<\sh> seb128: hmmm....
<\sh> seb128: what is it...really strange
<\sh> seb128: aha..
<\sh> seb128: I removed pan and all the good stuff is disappearing ;)
<\sh> weired
<seb128> you get the bug?
<\sh> seb128: yes
<seb128> I'm installing linux-image-2.6.12-8-k7 atm
<seb128> I bet it's a inotify bog
<\sh> seb128: should I send u the file or attach it to the bugzilla entry?
<seb128> bugzilla rather
<\sh> k
<spacey> mvo, should be something to do right? :o
<pitti> ogra: is universe frozen in any way? i. e. would it hurt if I uploaded the package from my SoC student to universe?
<mvo> spacey: there is plenty to do, you may look at the specs on the wiki or start by stoping over at ubuntu-motu and help with e.g. transitions to get a feeling for the various things to do :)
<ogra> pitti, if it doesnt brak anything else, its fine to upload
<ogra> break even
<pitti> ogra: no, it's just a new application
<ogra> pitti, go ahead then :)
<\sh> seb128: done
<spacey> mvo, specs for breezy+1 or what do you mean? i will try to make a list of things i can do, could you review it if i finished to see if i missed some possibilities?
<mvo> spacey: yes, I can do a review. how many hours/week will you have?
<spacey> well normally a project would last for 9 weeks (officially 40 hours a week).
<mvo> ok
<spacey> but i guess it will be spread out a little more
<Kamion> mvo: redirecting from /dev/null seems to be working OK, although I've yet to try an install that asks a debconf question
<Kamion> if it works, I'll upload that
<ajmitch> spacey: I guess you'd need to focus on some specific task, right?
<spacey> ajmitch, well i don't think thats neccesary but at least some main tasks i guess
<mvo> Kamion: thanks! apt is not dealing with with possibility of a cdrom method failing ATM, but I'm on it
<infinity> Meh.
<infinity> pitti : Is royal still acting up?
<mdke>  [14:07:31]  < Bob_Sheep> aww
<mdke> gah
<mdke> i hate these touchpads
<HrdwrBoB> all touchpads
<HrdwrBoB> they suck
<Lathiat> theyre better than nipples
<mdke> i have hiccups and whenever I hiccup I risk pasting random stuff into the chan :(
* Lathiat laughs at mdke 
* mdke holds his breath
<Lathiat> take middle click off heh
<linuxsbartley> I am trying to do a server install of 5.10 and then use xdm & xfce.  On 5.04 this was as simple as installing server, followed by x-window-system-core, xterm.  Then using Universe, installing xdm and xfce4 then rebooting.  The system would come back up w/ xdm & xfce.  On 5.10, I followed the exact same process.  The system tries to go to the xdm gui but fails and drops me to Alt-F8 w/ a message of "Starting X display manager.
<linuxsbartley> I have done a dpkg -l on both installs and compared.
<linuxsbartley> Nothing sticks out as "missing" from the 5.10 installation.
<linuxsbartley> My logic tells me then that there is something wrong with the 5.10 xdm or some other package.
<infinity> Does X work if you manually start it?
<linuxsbartley> w/out xdm installed, I can get X to work.
<linuxsbartley> i.e. I can manually start xfce
<linuxsbartley> As soon as xdm is installed, xfce fails to start as well.
<ogra> linuxsbartley, is the xinit package up to date ? there was a bug with Xsession not being executalble recently
<ogra> afaik xdm aprses that...
<ogra> parses too :)
<linuxsbartley> hm.  Well, it was as of yesterday afternoon if the updated version was in the repository.
<linuxsbartley> 1.0+0.99.1-2
<ogra> yes, thats the fixed version
<linuxsbartley> k. 
<linuxsbartley> I have tried adding some echo "Reached Xaccess" >> /tmp/xdm.log  type commands to each of the xdm called scripts.  Nothing is output.  I have also started xdm manually with the -error switch to specify the error log file being /var/log/xdm.log.  When I do this, I do get some logged errors.
<linuxsbartley> The first error is "Couldn't connect to PRNGD socket "/tmp/entropy": No such file or directory.
<linuxsbartley> Then several messages about Skipping ".....": No symbols found
<linuxsbartley> Several Warning: font renderer already registered
<Zomb> hi
<linuxsbartley> and finally, /usr/lib/X11/xdm/libXdmGreet.so: cannot open shared object file: No such file or directory while loading /usr/lib/X11/xdm/libXdmGreet.so
<sivang> hey Zomb 
<ogra> linuxsbartley, locate libXdmGreet.so ??
<linuxsbartley> ogra, does not exist
<HiddenWolf> pitti, ?
<Zomb> can someon give a hint how the Hoary live cd is created? I guess: Two PVs, the main file system located on one of them, the system installed there. Then the VG is stopped, then the snapshot is created using the space of the second PV. Then the VG is stopped, the first PV is compressed with cloop, the second (beeing a sparse file) is compressed and stored separately.
<Zomb> correct?
<pitti> HiddenWolf: yes?
<HiddenWolf> pitti, I still have cd's being auto-mounted at boot. That isn't preferred behavior, right?
<pitti> HiddenWolf: that's actually supposed to be like this
<pitti> HiddenWolf: however, you can configure it in system -> prefs -> removable devices
<seb128> pitti: hum, that's supposed to be like this?
<HiddenWolf> pitti, it was my understanding what when you pop a cd in, it gets automounted, popped in your face, but when it is already in the drive at boot, it just gets mounted, and no nautilus popup.
<pitti> seb128, HiddenWolf: yes, g-v-m attempts to mount all removable devices at startup
<seb128> pitti: it should not open a nautilus window on them at login
<pitti> HiddenWolf: ah, you mena the nautilus popup? yep, that's a bug
<pitti> right
<pitti> that's still on my list
<seb128> k
<pitti> got drawn away by security updates
<seb128> if that's a bug for you all is fine :)
<HiddenWolf> Oh, I thought you fixed it already, sorry. :)
<seb128> I just parsed what you said as "NOTABUG" which supprised me
<sivang> seb128: is g-v-m hard to debug?
<pitti> sivang: no, it's fairly easy
<seb128> ask pitti but I guess it's not
<doko> lamont: does yaboot need the gcc-3.3 b-d, or does it work with gcc-3.4 as well?
<sivang> pitti: you like strace at it or something?
<pitti> sivang: no, gdb is much more fun - or just RTFS
<seb128> there is a wiki page
<bob2> oops, didn't mean to upgrade libc6
<sivang> seb128: https://wiki.ubuntu.com/DebuggingRemovableDevices ?
<pitti> sivang: yes, that's for answering bug reports
<Kamion> Zomb: no, I don't think we use LVM in the process at all
<seb128> pitti: what is weird for #13176 ?
<Zomb> Kamion: what then?
<TheMuso> q
<pitti> seb128: see comment #14 - there " autoipod_command = nautilus %h"
<Kamion> Zomb: I believe we create the tree with debootstrap/apt-get/etc., dd /dev/zero to a big file, mkfs, losetup, mount, rsync the tree into that mounted filesystem, partimage based on the previous image if we can, then create_compressed_fs
<pitti> seb128: however, I have no idea where this setting comes from
<pitti> seb128: the system gconf schema does not have it, and ~/.gconf neither
<Kamion> doko: I don't want to change yaboot's compiler at this point in the release cycle; it's kinda delicate
<Zomb> Kamion: maybe, but AFAIKS the devmapper is used on the live CD and you can modify files on it while the cloop-Image is read-only
<Kamion> Zomb: you asked how the live CD was created, not how it runs
<seb128> pitti: you asked for .gconf/desktop/gnome/gnome-volume-manager instead of .gconf/desktop/gnome/volume-manager no?
<seb128> pitti: volume_manager rather
<pitti> seb128: oh, wrong path then?
<Zomb> Kamion: ok, alternative question: how is the cloop-Image integrated into the live filesystem
<netstar> Where can I speak to people who know about the ppc release?
<seb128> pitti: /desktop/gnome/volume_manager
<HiddenWolf> netstar, just ask the question, or mail the mailing list.
<seb128> pitti: and you ask for "ls .gconf/desktop/gnome/gnome-volume-manager
<pitti> seb128: bah, /me stupid
<seb128> "
<Kamion> Zomb: see casper/pre.d/10filesystem in the casper source package
<pitti> seb128: thanks :-)
<seb128> pitti: np
<Zomb> yeah, I will just study your initrd image
<netstar> Does the ppc release support the new Imac G5's?
<Kamion> we use dmsetup
<Kamion> netstar: I don't know of a reason why it shouldn't, but Apple keep adding hardware to new models that Linux doesn't quite support yet so you'd have to try it and see
<Kamion> netstar: try the live cd (boot with the 'live-powerpc64' option)
<bddebian> Hello
<Kamion> if that works it should be fine
<netstar> Does the cd include enough software to compile my own kernel (ppc) ?
<Mithrandir> Kamion: you don't mind me confirming d-i bugs?
<linuxsbartley> ogra, any further ideas?  Or, do you know who would be able to help?
<mvo> Kamion: with the patch for apt for #13713 the </dev/null fix should work (mdz will probably want to look at the diff first, but it should be sane)
<Kamion> Mithrandir: no
<Kamion> Mithrandir: go ahead
<Mithrandir> Kamion: oki, thanks.
<netstar> Kamion, does the standard install cd include enough software to compile a kernel succesfully?  Or must more be downloaded?
<Kamion> mvo: the </dev/null fix can happen first anyway, since the install already breaks at a CD prompt :-)
<mvo> Kamion: right :) [fixing this fallback should fix debian #44135 as well and that a bug from 1999] 
<Kamion> netstar: the install CD includes basic development tools (though they aren't all installed by default); those should be enough to compile a standard kernel although not enough to compile the Ubuntu kernel package
<Kamion> I mean, not enough to build the full package; you should be able to build the actual kernel bit fine
<Kamion> mvo: cool
<netstar> okay, I'll probably be back later on to annoy you with more questions.
<mvo> HiddenWolf: do you mind if I close #15059 ?
<netstar> thanks
<Mithrandir> Kamion: hmm, bugs such as 2539 should be closed now that we use the non-antique kbd-chooser?
<HiddenWolf> mvo, Not really
<mvo> HiddenWolf: if you find more out about it, we can reopen always it :)
<sivang> fabbione: how do you test partman-auto-lvm changes ? 
<Kamion> Mithrandir: er, if it works ... I have no idea whether it does or not. FWIW the keyboard names are mostly in console-data not kbd-chooser
<Kamion> and I don't remember seeing that particular one changing
<jkossen> hmm typo on http://www.ubuntulinux.org/ubuntu/releases/document_view: Upgrades will be supported from enteprise release to enterprise release. (s/enteprise/enterprise)
<Mithrandir> Kamion: hmm, perhaps I'm utterly mistaken then.
<Mithrandir> Kamion: I'll see if I can reproduce
<Kamion> Mithrandir: it's powerpc-specific
<Kamion> jkossen: thanks, fixed
<HiddenWolf> mvo, exactly
<jkossen> Kamion: nice :)
<Mithrandir> Kamion: I know, which means I have to see if I can get my peg to install ubuntu
<Kamion> Mithrandir: er ... not sure if that'll help; looking at kbd-chooser/usb-kbd.c, it's probably Mac-specific
<Mithrandir> Kamion: I've seen it on the peg before
<Kamion> oh, ok
<Mithrandir> but that could have changed,
<Kamion> well, I'll have a look next time I do a test install on my powerbook
<elmo> fabbione: ?
<fabbione> elmo: ?
<elmo> fabbione: am I good to do b-at?
<fabbione> elmo: i didn't upload tetex yet. the problem is sort of bigger than i expected and my workstation died.. i will let you know later on.. but if you want to run, go ahead
<fabbione> i must finish to rebuild my ws first
<elmo> ok
<spacey> mvo, i guess you can't read dutch? :o)
<bddebian> elmo!
<fabbione> elmo: as i understand it... as it is we can just remove tetex from the archive and see what breaks...
<elmo> fabbione: this b-at is a full (i.e. +universe) run, so I'd like to get it started; there'll be a main only b-at run again soon tho
<elmo> fabbione: ?!
<fabbione> elmo: just start.. don't wait for me
<fabbione> elmo: i found over 35 files inside tetex that are bad
<elmo> christ
<fabbione> they all report stuff like:
<fabbione> licence foobar from tetex/latex.whever
<fabbione> and 2 lines after:
<fabbione> "You are NOT ALLOWED to modify this file"
<fabbione> or
<sivang> what's b-at ?
<fabbione> "You are NOT ALLOWED to make money on top of this file"
<fabbione> elmo: most of the stuff is in tetex-extra, but some of it is in tetex-basa
<fabbione> base even
<fabbione> so run for now, becuase if we need to kick tetex a bit out, we will need to work all together on it :)
<elmo> bddebian: ?
<fabbione> i won't be enough
<elmo> sivang: breezy-autotest - test rebuilds of the archive
<fabbione> anyway. i must get my ws fixed first
<fabbione> just ping if you need something
<bddebian> elmo: You are my hero. :-)  Did you get my huge e-mail last night?
<elmo> bddebian: yeah, I'm still catching up on mail tho
<bddebian> elmo: NP
<elmo> Mithrandir: ?
<elmo> Mithrandir: you broke *-desktop; either they need regenerated or readahead needs to provide readahead-list
<bddebian> Riddell: ping?
<Riddell> bddebian: hi
<bddebian> Riddell: Heya.  I'm a little lost (not surprising).  Isn't debtags supposed to provide libdebtags1-dev and libdebtags1-pic?
<mbreit> elmo: could you sync ardour from debian unstable please? thanks!
<Riddell> bddebian: libdebtags1 should do that
<bddebian> Riddell: Sorry, that is what I meant. but the source doesn't show that and we dont have libdebtags1-pic?
<elmo> why do you need a -pic?
<bddebian> packagesearch 2.0 from Debian
<elmo> they're got a very limited use case
<Riddell> there's no -pic, but libdebtags1-dev is there
<Riddell> it's a static library
<bddebian> I guess I could just do packagesearch 1.3 as MoM asks but it seems stupid when 2.0 is there.
<Riddell> elmo: could you sync ttf-dejavu (or is there some reason it hasn't been synced?)
<elmo> Riddell: we stopped auto-syncing stuff months ago?
<Riddell> elmo: it must be newer than I thought then.  could you do it manually?
<Riddell> bddebian: packagesearch only build-dep on libdebtags1-dev
<Riddell> and qt4 excitingly
<bddebian> Riddell: 2.0?
<Riddell> yes
<Riddell> 2.0.1
<bddebian> Ahh, it when to 2.0.1 two days ago.. :-)
<bddebian> Err went even
<Riddell> fast paced this stuff
<bddebian> No shix
* bddebian will try 2.0.1 and bug elmo some more.. :-)
<mdz> morning
<bddebian> Hello mdz
<pitti> Hi mdz 
<pitti> elmo: can you please sync tdiary? it fixes a security issue and also removes files with problematic licenses
<bddebian> mbreit: Are you working on ardour for unmetdeps or the Malone bug?
<bddebian> Or both? :-)
<bddebian> Heh, packagesearch 2.0.1 FTBFSs..
<Riddell> bddebian: what's up with it?
<lamont> doko: for breezy, it requires gcc-3.3 (too late to change)
<hunger> hey! Apt's print-uris rocks!
<Diziet> Wergh.  The entry for `terminal' has disappeared from my testbed's applications menu !
* hunger just used that to create a batch file for windows to download stuff;-)
<mbreit> bddebian: both
<bddebian> mbreit: Great :-)
<bddebian> Riddell: packagesearchimpl.cpp:937: error: invalid use of undefined type 'struct Tagcoll::HandleMaker<std::string>'
<Diziet> Does anyone have any idea what might cause that ?  I can live without it but if I think it should be investigated.
<bddebian> Welcome sabdfl
<sabdfl> hey guys
<bddebian> Hey, what if I'm a girl? ;-)
<pitti> Hi sabdfl 
<Lathiat> sabdfl: did you try that new kernel?
<seb128> hi sabdfl
<sabdfl> Lathiat: so far so good, yes
<sabdfl> working for you?
<sabdfl> hey seb128. feeling successfully older and wiser?
<Lathiat> yeh good so far, see in a couple days i guess
<seb128> sabdfl: kind of :)
<hunger> fabbione: Your new kernel seems stable so far.
<pitti> I just peeked in #u-meeting, will we have a meeting today?
<seb128> Diziet: it's under the Accessories category?
<hunger> fabbine: I'm keeping the HD busy, no problem yet.
<fabbione> hunger: it's not my kernel. i only builded a snapshot of BenC work
<hunger> fabbione: Feel free to s/your/whoever/. Fact is: It is way more stable for me than the "normal" breezy kernel.
<hunger> fabbione: Whoever made it: He did good work. Thanks BenC.
<Diziet> Oh, it used to be in System Tools.  It's not an Accessory.
<seb128> Diziet: sabdfl requested to get it moved to Accesories (same for the file-browser icon)
<Diziet> I see.
<Diziet> I still think it's wrong, but there you go.
<ivoks> terminal
<ivoks> ?
<jsgotangco> heh
<Diziet> Yes, terminal.
<ivoks> imho, it shouldn't be in system tools in first place... since it isn't system tool
<ivoks> it's more accessorie
<jsgotangco> just like how windows treats dos as an accessory?
<ivoks> :)
<ivoks> terminal and ms-dos prompt are one, and DOS is something other
<Diziet> Isn't it ?  It seems like one to me.  While it's traditional of pointyclicky UIs to make the CLI hard to find, it's less usual of them to trivialise it.
<ivoks> i don't care where it is... it's allways on my win+x :)
<Diziet> I think of `accessory' as something like a calculator.  A small and pretty simple thing that even a naive user might easily use often.
<ivoks> someone who knows UI better should decide aoubt that, and i'm sure sabdfl didn't go to access without consultation
<Diziet> Anyone here got an amd64 install ?  Does the current firefox work at all ?
<mvo> Diziet: you mean the ubuntu12 version?
<Diziet> Yes.
<mbreit> Diziet: works fine here
<pitti> Diziet: works fine here
<ivoks> so... amd64 builder is on strike? :)
<pitti> mbreit: :-)
<mvo> Diziet: seems to work ok here
<Diziet> OK.  Hmm, thanks.
<sabdfl> Diziet, ivoks, more controversial is the removal of Root Terminal. you guys have any opinion on that?
* pitti never used the root terminal entry so far
<ivoks> never used that one..
<pitti> gksudo in the menus and sudo in the shell works so well
<jsgotangco> sudo works most of the time
<pitti> and we should discourage permanent root terminals anyway
<pitti> so, sabdfl++
<ivoks> yeah... sabdfl++ :)
<ogra> ++
<Diziet> sabdfl: Um, what was the reason for it ?
<Diziet> I assumed that it was something to do with not confusing the easily-confused.
<Diziet> But if it's for `security reasons' then I think it's pretty bogus, really.
<pitti> Diziet: no, not for security reasons; just to educate people to not type commands as root when not necessary
<pitti> Diziet: if you have a root shell, then people could get used to "let's just take this terminal for everything"
<Diziet> I see.  That sounds like `educating' people into `security'-consciousness.
<pitti> Diziet: something along that line, yes
<pitti> Diziet: do you disagree with that?
<Diziet> I'm afraid so, yes.
<pitti> Diziet: hm, so you think we should keep the root terminal?
<pitti> what is the use case for that?
<Diziet> (a) Saves typing if you know what you're doing (rather than terminal followed by sudo bash).  (b) Sysadmin unfamiliar with our system setup choices may not know that we prefer sudo and may (for example) try su etc.  `root terminal' in the menu advertises to them what they need nice and easily.
<pitti> Diziet: well, our installer points out that there is no root, and sysadmins shuold generally know about the implications anyway
<pitti> we should care more for inexperienced users IMHO
<jsgotangco> pitti ++
<ivoks> if they do custom install, they can create root password, iirc
<ogra> and (a) is solved by sudo -s more easily
<pitti> Diziet: but in the end, I don't mind either way
<mpt> If there is a use case for it, perhaps add a menu item to do the proper incantation (sudo -i $SHELL, or whatever it is) to one of the menus in the terminal itself, rather than encouraging people to open a terminal and then think "oh crap, this isn't the one I wanted"
<jsgotangco> the root account can be easily activated by experienced users
<ivoks> maybe under system -> administration?
<spacey> there is a root terminal in the menu...
<spacey> right?
<jsgotangco> spacey: deprecated
<ogra> spacey, thats what we're talking about
<spacey> oh ok:p i also use `sudo -s`
<Diziet> mpt: One of the menus in the terminal itself ?  Who's going to look there ?
<mpt> Someone pointed out on ubuntu-doc that people often get the incantation wrong, they don't know about the -s
<Diziet> My (b) use case involved a sysadmin who doesn't know how we set things up.  Note that such a person might not have been the person who installed it.
<Diziet> You've come and tried to fix other people's computers before now, right ?  It would be nice if the system made that relatively convenient.
<pitti> right
<pitti> but we shouldn't encourage it
<Diziet> Shouldn't encourage what ?  Having a root terminal open ?
<pitti> yes
<ivoks> maybe pop-up with warning?
<Diziet> I disagree.  There's nothing wrong with having a root terminal open.
<pitti> programs with elevated privileges under X are a PITA in the first place
<ogra> ivoks, eek
<mpt> Diziet: Would patching su to print an explanation work better?
<pitti> so we should minimize them
<spacey> Diziet, if he doesn't know how to set up stuff.. should he be root? ;p
<ivoks> ogra: :)
<Diziet> mpt: That's a kludge, for us failing to provide the UI cue in the right place.
<Diziet> Not that it wouldn't help.
<pitti> Diziet: as soon as you have a program running as root under X, all other user processes have, too - bad for trojans and such
<Diziet> spacey: Eh ?  You've never fixed someone else's computer running some strange distro you've not seen before ?
<pitti> Diziet: in the end, I think we should fix su anyway, we planned to do this for a long time
<pitti> Diziet: so, if su sees that root is disabled, it should point to sudo
<pitti> (but that is orthogonal to the topic)
<Diziet> pitti: If we're trying to defend against other programs in the session stuffing stuff into that window I think we're being overparanoid.  There are much worse things to worry about - the fact that the user is using a browser in the same account as sysadmin at all.
<ivoks> don't forget, there is still problem with gksu, not reading sudoers like it should :/
<ivoks> gksudo, not gksu
<spacey> Diziet, sorry, all people i know are running ubuntu (or winxp). but sudo is not such a unknown command..
<Diziet> spacey: Yes, but it would be nice just to make things smooth and easy.  That's what we're trying to do, right ?
<pitti> Diziet: I see your point, it's a tradeoff
<Diziet> What's the downside ?
<pitti> between cautious education and easy maintenance
<Diziet> Someone makes a virus that takes over the user's firefox and uses the running root terminal to help do something nasty ?
<pitti> erm, educating cautiousness, I mean
<mvo> ivoks: gksu can't read sudoers, at least not with the current design
<Diziet> I think this `educating' people not to have a root terminal open is nonsense.
<pitti> mvo: but mvo can determine whether root has a password
<ivoks> mvo: ok, that's good to know...
<spacey> Diziet, well this one person in thousand might as well read a few lines of documentation and know sudo. pretty convienant to use, but i understand your point ofcourse
<hunger> Diziet: If you are afraid of that: Run firefox as a different user.
<ivoks> mvo: since sudo someapp works ok, and gksudo someapp doesn't (if someapp is NOPASSWD in sudoers)
<mvo> pitti: gksu can? how?
<Diziet> hunger: Well, of course.  But that's too inconvenient for the average user (we have decided).
<pitti> mvo: su can
<seb128> Diziet: about the Accessories category upstream take it too for lusers tools, some GNOME guys condider it's for stuff who have a real life equivalent (dictionnary, calculator, notepad, ...)
<pitti> mvo: not gksu, of course; but we are talking about people who enter "su" into terminals and fail
<mvo> ivoks: yes, the problem is that gksudo just calls sudo, it has no other rights than the user 
<hunger> Diziet: Using a root terminal is too, so do not worry too much about that.
<mvo> ivoks: sudo is not very friendly when it comes to being embedded
<ivoks> mvo: i see, thanks for clarification
<mvo> pitti: yes, that's something we can fix
<Diziet> seb: I think that most users - particularly people who aren't familiar with the system - will consider a CLI as a system tool because it's a thing that `system people' use to do `system things'.
<mvo> ivoks: I haven't looked into the NOPASSWD issue, I was under the impression that recent version of gksudo have fixed that, but apparently they don't 
<Diziet> ie things they don't understand.
<Diziet> For the same reason experts look for expert tools like CLI in scary sounding places like `system tools'.
<Diziet> `Accessories' should be full of harmless but useful trivia.
<ivoks> mvo: if gksudo asks pass before it sends it to sudo, then problem is obvius, and i think that's the case...
<seb128> Diziet: I quite agree with that
<Diziet> Did we have some UI expert tell us otherwise, in fact ?
<pitti> Diziet: I think keeping the root terminal in the system tools menu (and having the normal Terminal in accessories, like now) is a good compromise
<Diziet> Splitting them up is a bad idea.
<pitti> Diziet: you just suggested doing so
<pitti> Diziet: keep system admin tools in one scary menu, and generally useful things in another
<seb128> pitti, mvo, Mithrandir: you guys have an amd64 right? Sombody wants to take over http://bugzilla.ubuntu.com/show_bug.cgi?id=14903 ? That's firefox crashing with the totem video plugin (seems to be reproducible when doing "previous page" from a video)
<ivoks> mvo: yes... easy to demonstrate :)
<ivoks> mvo: for app that's NOPASSWD, you can enter worng password in gksudo
<ivoks> mvo: it would still open that app
<Diziet> My argument above was about both root and non-root terminals.
<Diziet> CLI = Command Line Interpreter.
<pitti> Diziet: right, but a normal terminal is much more useful than a root terminal
<pitti> Diziet: for example, users will need it to type things we ask them to (for debugging)
<pitti> and many will eventually want to explore some CLI bits
<Diziet> Yes.  And we're `system people' who ask them to do `system things' like debugging, for which they will need `system tools'.
<pitti> I just want to scare them off a root terminal
* seb128 uses right click with nautilus and panel launchers :)
<mvo> ivoks: hm, I just tested it for the current gksudo in breezy and it seems to work as excepted (not asking for a passwd)
<floo> hi guys :) i used usplash but usplash is not on my fullscreen (1024x768) its work @ fb16? can usplash  work in 1024? sorry for my english :)
<pitti> mpt: what does our UI expert say to the terminal/root terminal story? :-)
<jsgotangco> scary
<mvo> floo: usplash will do only 640x480
<floo> damn
<ivoks> mvo: did you use any other app with gksudo before?
<hunger> floo: I was told it can't.
<pitti> floo: usplash is designed for one fixed resolution
<floo> =/
<floo> bootsplash didn't work because its not under udev :/
<ivoks> mvo: try that on fresh login
<mvo> ivoks: I don't think so, I did sudo -k before and tried it on a new vt as well
<floo> +work
<netstar> Does anyone know where I can get a copy of the ppc-64 kernel config file used for the kernel in the lastest preview breezy release?
<sabdfl> Diziet: it's to simplify things. there is now one obvious way to get to a terminal. and the docs can focus on one way to escalate privileges: sudo
<mvo> ivoks: tried that too, now difference
<sabdfl> for clever people, it's not hard to setup their own panel icon that does exactly what they want
<pitti> mdz: no meeting today?
<ivoks> mvo: no or now? :)
<Diziet> sabdfl: But there are numerous system tools in the `System' menu which also escalate privileges.
<sabdfl> and "Accessories" is a good place, because a Terminal is not something to be scared of, or embarrassed about, it's just a tool
<mvo> ivoks: no :) works as excepted, no password prompt and runs as root
<sabdfl> like a calculator
<mdz> pitti: this week is CC, no?
<ivoks> mvo: ok, promise me to try that after restart, ok? :)
<\sh> mdz: it was
<sabdfl> mdz: i believe so
<sabdfl> was?
<\sh> 12UTC
<mvo> mdz: it was today
<\sh> today
<seb128> sabdfl: GNOME guys tend to describe Accesories as stuff which have a real life equivalent: dictionnary, calculator, notepad, ...
<ivoks> mvo: thing is that some PIDs are still in the air after you logout
<jsgotangco> gyahhh
<ogra> all over :)
<jsgotangco> oh well
<ivoks> mvo: and there is /tmp with your data
<floo> usplash is on my laptop TFT very small :( its ugly... :(
<ivoks> mvo: that happend to me to, after fresh login, it worked, but after restart - no
<Diziet> sabdfl: I think that for most users a terminal is something they should have a healthy respect for.  And the whole point of the pointyclicky UI is to avoid them having to use it - based on the very premise that it's hard to use.
<\sh> but my 2 1/2 hours sleep was good :)
<Diziet> Now, it's true that there are things people need a terminal for but part of the point of the GUI is to minimise those.
<floo> hi \sh :)
<\sh> seb128: did u see this problem now with 2.6.12-8?
<seb128> \sh: I don't get this away messages
<Diziet> If you disagree with this then you don't need Gnome.
<seb128> inotify: resource /var/lib/dpkg/status went away. Adding it to missing list
<seb128> inotify: resource /etc/xdg/menus/debian-menu.menu went away. Adding it to missing list
<seb128> is all what I get basically
<seb128> and that's due to apt-get updates
<\sh> seb128: strange...
<seb128> ie: file moved/renamed
<seb128> yeah
<mvo> ivoks: I don't think so, the tickets are per-tty IIRC. but I'll check after my next reboot too
<seb128> you are on x86?
<\sh> seb128: yepp
<Diziet> `System tools' is the nearest we have to an `expert' menu.
<ivoks> mvo: thanks
<\sh> floo: hi
<mpt> pitti: I agree with sabdfl on this
<Diziet> Also, `root terminal' ought to exist and has to be next to `terminal' and ought to be in `system tools', so `terminal' has to be there too.
<Diziet> `Terminal' and `root terminal' should not be separated.
<ivoks> mvo: (aren't per-tty since now it doesn't me for password from any tty)
<sabdfl> Diziet: i disagree, i'm afraid
<sabdfl> a GUI is wonderful, but so is a console
<ivoks> mvo: 'ask' should somewhere in that line :)
<ivoks> mvo: and 'be' in other :)))
<sabdfl> rather than seeing it as a battle between them, we should understand that both will continue to evolve
<sabdfl> i know a couple of Mac users who are now happy terminal users under mac OS X
<sabdfl> Diziet: if you don't separate them it causes no end of confusion
<sabdfl> we're going to stick with the current arrangement for Breezy, and review for +1
<mvo> ivoks: care to join #gksu? I don't want to "spam" this channel too much
<Diziet> sabdfl: I see.  Well, it's your decision but I still disagree.
<\sh> seb128: I'm running the plain i386 kernel
<sabdfl> Diziet: ok, please join in the followup discussion post-breezy
<seb128> mpt: what do you think about launchpad entries on the right click menu of the panel?
<sabdfl> seb128: which panel?
<seb128> sabdfl: the GNOME one
<seb128> the bar you have on the top and bottom of the screen
<seb128> right click on a free space
<sabdfl> ah
<sabdfl> cool
<mpt> seb128:sabdfl: I've already been asked this question :-) I agreed, because there's really no better place to put them
<Diziet> sabdfl: Willdo.
<sivang> seb128: true
<sivang> seb128: I asked him :)
<sivang> mpt: ;-)
<seb128> mpt: k, I don't like to make menu longer
<sabdfl> seb128: we need icons for those menu entries
<seb128> sivang: right but you never communicate on what you do
<seb128> sabdfl: do we have any artist for that? I'm not good at making icons :)
<sivang> seb128: no I did :...-( I even talked with you about it on the sam eday
<sabdfl> mpt: could you put seb128 onto the icons we use for translations and for tickets? i think we need ticket icons
<seb128> sivang: you said you'll ask
<sabdfl> let's use the ones we currently have in LP
<sivang> seb128: and then I replied back that mpt was content with that change..
<sivang> mpt: do you remember?
<dieman> Kamion: btw, i put apache on mirror.cs.umn.edu now
<dieman> Kamion: did some googling about thttpd/apache/etc
<dieman> Kamion: looks like apache is a win due to persistent connections.
<mpt> seb128: There is the problem that people might not understand the panel as being a distinct program by itself, though
<dieman> didn't know thttpd can't do those :)
<seb128> mpt: not a lot we can do about that
<sivang> mpt: they will find this out when they click the context lp item, no?
<sivang> sabdfl: is there going to be an open ticket function in each app as well?
<mpt> sabdfl: I think gnome vastly overuses icons in menu items, but sure, I'll send them to seb128
<sabdfl> sivang: not inside the app. the menu takes you to a "support overview", and from there you can open a ticket
<sivang> sabdfl: I see, that will be under the "Get help" option right?
<sabdfl> yup
<sivang> cool
<sivang> seb128: I even talked with you about gnome-applets that was deferred since you were too busy at that time..
<seb128> sivang: I know that
<seb128> sivang: but you tend to ping when you are done with your changes or the discussions instead of bringing discussions here when people concerned are here
<seb128> sivang: no big deal, don't worry
<pkern> (Bloody IRC client crashing away after sending a message)
<mxpxpod> can someone with the most recent libevolution-cil try to start beagle? I'm getting a DllNotFound exception
<sivang> seb128: ok, sorry for the troulbe, anyways. I will discuss this on u-d ml next time, it's probably better then IRC anyways..
<seb128> sivang: don't worry, there is no trouble. But having everybody part of the discussion is better than having you pinging mpt and then pinging me, then I've to ping mpt or you to know what point you discussed, etc
* pitti has to run out for a bit, cu later
<mpt> seb128: Sorry for getting in the way
<ivoks> bye
<seb128> mpt: no, that's fine, thanks for give your advice on such questions
<Reveng-ER> christel@freenode/staff/christel is a corrupt staff member. people on the staff social channel beg for modes and she is setting them just to read "christel we love you". do you all support such networks with corrupt staff members who set modes for personal pleasure?
<\sh> Reveng-ER: wrong channel..has nothing to do with ubuntu
<Mithrandir> elmo: readahead provides readahead-list?
* floo brb reboot
<\sh> elmo: please sync gtk-gnutella 0.95.4-1 from debian unstable (universe that is) thx :)
<seb128> mpt, sivang: we have a complain about gnome-panel upstream because right click menu on the clock applet is too long with lpi items
<Nafallo> mjg59: ping
<mjg59> Hello
<sivang> seb128: oh, why do upstream want it?
<seb128> want what?
<bddebian> Hello mjg59
<Nafallo> mjg59: hi :-). can usplash handle interactive things like password-prompting?
<sivang> seb128: sorry, you mean, GNOME upstream? they also use the patches?
<mjg59> Nafallo: Not currently
<mjg59> But it would be easy enough to implement
<mjg59> If you need input, best thing to do is to explicitly kill usplash
<seb128> no, gnome-panel upstream uses Ubuntu and right clicked on the clock
<mjg59> (usplash_write "QUIT")
<Nafallo> mjg59: I got a user running cryptsetup see, and I just uploaded a version that kills usplash if /sbin/usplash_write is executable :-).
<sivang> seb128: ah, I saw , vuntz right?
<seb128> correct
<Nafallo> any way to start usplash after the script is done?
<mjg59> Nafallo: It might be nice to check if it's running first and then restart it if so, but not too important
<Nafallo> mjg59: naah. I'll just kill it for him then. the goal should be to enter the password inside usplash anyway :-)
<Nafallo> mjg59: but not for breezy, I guess?
<vuntz> hi
<Kamion> dieman: mm, that's a matter of some debate - I don't think it's that cut-and-dried
<sivang> mpt: seems that vuntz also thinks that patching the applets is ugly, what do you say? (for instance, clock applet)
<vuntz> sivang: I think that dropping the patches for applets would be better, indeed
<vuntz> sivang: but the users won't find any link to translate some applets, though
<Kamion> dieman: it's true that a web server with keep-alive support will be able to give better performance on repeated requests, all other things being equal, by avoiding the extra connection setup and tear-down costs
<sivang> vuntz: yes, that was guided me on my way to patch them...:-)
<sivang> s/guided/guiding/
<vuntz> brb
<Kamion> dieman: but you have to offset that against thttpd being a select()-model web server which means that it will be able to cope with large numbers of concurrent connections considerably better than Apache
<mjg59> Nafallo: Yeah
<Kamion> dieman: there do exist keep-alive patches for thttpd; it's been a long time, but maybe I should get back into web server hacking and have a go at those
<Kamion> Diziet: I'm told that the root terminal menu entry ran the terminal emulator as root as well as the shell; if we restore it, we should remember to fix that
<Diziet> k: That's silly of it, indeed.  Note that it's still there, just disabled by default.  You can turn it on again with pointyclicky, I think.
<Kamion> right, I haven't looked at the current state much yet ...
<vuntz> sivang: maybe you could add lpi in the "add to panel" dialog?
* mvo is away for a bit
<sivang> vuntz: don't think it's a preoblem, but let us ask mpt first - he's the usabilty expert
<sivang> mpt: actually not sure if it's suitable even there...where do you think it can be added? this is a list of aplets to add..
<sivang> mpt: eithery way, let's wait for mpt.
<sivang> errr
<sivang> vuntz: those were for you ^^^
<magnon> yet another ubuntu success story
<magnon> or "how to exchange a faulty router within 3.5 minutes"
<mpt> sivang: What I suggested in the mockup was that there be general items that took you to the pages for Ubuntu-as-a-whole
<mpt> That, combined with a search function in Rosetta, would let you find badly-translated strings and correct them
<mpt> or get help with Ubuntu in general
<sivang> mpt: ok, so you would you second vuntz suggestion?
<dieman> Kamion: heh, the machine is holding up fine with apapche
<dieman> apache
<dieman> i think i would only care if i had gigE on that box
<mpt> sivang: Add it where? Buttons for such unimportant functions would be crack
<sivang> mpt: In order to easily transalte the applets, and also not clutter the context menus we can drop individual applets supprt, leave it for the menu, and mention this somehwere in the docs possibly
<mpt> and the dialog doesn't have menus
<vuntz> what about using the items in the panel context menu for the applets and the panel?
<vuntz> I'm not sure users will think that applets are not the same app as the panel
<Nafallo> mpt: yay for search-function! :-)
<Kamion> dieman: I used to be able to effectively disable Apache servers from an untrusted client with a trivial shell script and trivial bandwidth, even after they said they'd fixed that :-(
<Kamion> (and not an exploit or anything, just connecting to them lots)
<Kamion> but it's been a few years
<sivang> mpt, vuntz : maybe we can start a thread about it , I need to run, but will be back in about 2 hours (train to catch)
<sivang> mpt: or just let me know what you think is best, and I will make sure it's reflected in the pacakges
<seb128> you guys can use bugzilla for that too
<mpt> sivang: I'd rather just have a single item for the whole panel
<mpt> vuntz is right, expecting people to distinguish between different parts of the panel is unreasonable
<mpt> Some people have trouble even distinguishing between hardware and software...
<sivang> mpt: no problem. so be it :)
<sivang> mpt: so only the panel get's lpi love, and applet's context menu is free fo them , yes?
<mpt> correct
<sivang> mpt: cool hen, seb128: I will make a new pakcage and ping you for review/upload?
<mpt> https://wiki.ubuntu.com/LaunchpadIntegration?action=AttachFile&do=get&target=system-help-menu.jpg was my original suggestion
<seb128> sivang: that works, thanks
<sivang> seb128: cool =) next time I don't move a mussle without writing to #u-d ;-)
<doko> seb128: are defaults for printer drivers handled by gnome-cups-manager?
<xxenon> I got no accents in breezy with a fr_CH keyboard...(driver kbd). Worked in hoary (driver keyboard)
<mdz> Mithrandir,ogra,Riddell: please merge edubuntu and kubuntu seeds with ubuntu and upload new metapackages, to complete the readahead transition
<fabbione> elmo: tetex panic seems to be finished...
<fabbione> elmo: apparently we need to do nothing.
* fabbione accepts bets for how long his workstation will stay alive without freezing
<eruin> 7join #ubuntu-art
<bddebian> whoops :-)
<lamont> hrm... montreal is YUL, yes?
<eruin> ;)
<mdz> fabbione: gfs certainly spews a lot of warnings on amd64
<Diziet> mdz: Shall I upload that dpkg with the conffiles fix tomorrow ?
<fabbione> mdz: what kind of warnings?
<fabbione> mdz: what config?
<mdz> fabbione: fs/gfs_locking/lock_dlm/thread.c:133: warning: long unsigned int format, uint64_t arg (arg 3)
<mdz> default ubuntu config
<fabbione> at build time..
<fabbione> yeah i told upstream..
<mdz> Diziet: send me a debdiff, and if you don't hear from me by tomorrow, go ahead
<fabbione> they say not to worry
<Diziet> mdz: Willdo.
<Diziet> You won't want to read the actual code though; it's a 610-line diff.
<Diziet> (Debian #108587, for reference.)
<sabdfl> elmo: what's a zombie process?
<mdz> sabdfl: a process which has exited, but whose parent hasn't acknowledged it (yet)
<ogra> sabdfl, a leftover from a dead process in the processlist afaik
<mdz> tseng: mono-assemblies-base wants to move to universe, ack?
<pitti> Hi again
<sabdfl> mdz: ok, so i can not stress about that? noticed it on the stress test box
<bddebian> Heya pitti
<bddebian> Anyone know what xcontrib is/was?
<mdz> sabdfl: if they're accumulating or something, that can indicate a bug, but seeing them from time to time is nothing to be concerned about
<sabdfl> ok. there's just one, i'll give it a little time to get noticed
<Diziet> mdz: YHM
<mdz> Diziet: I check regularly throughout the day, thanks
<Diziet> Noted.
<tseng> mdz: afaik we arent building that anymore
<tseng> mdz: eh, its a transition package.
<mdz> tseng: did that just happen recently, past few days?
<tseng> mdz: more like a month or two
<tseng> mdz: its a dummy package.
<mdz> tseng: is it there for upgrades from Hoary?
<tseng> yes.
<mdz> ok, I'll seed it for you then
<tseng> thank you.
<lamont> scrollkeeper-update -p /var/lib/scrollkeeper -o /build/buildd/gucharmap-1.4.4/debian/tmp//usr/share/omf/gucharmap
<lamont>  /var/lib/scrollkeeper/scrollkeeper_docs: Permission denied
<lamont> is that a scrollkeeper bug, or a buildd-config bug?
<Diziet> Goodnight people.
<mdz> Diziet: night
<pitti> night Diziet 
<ogra> night Diziet 
<ogra> Diziet, and thanks for fixing 2679
<ogra> :)
<Mithrandir> mdz: refreshing the deps means it removes a load of stuff from -sparc and -hppa.
<ogra> Mithrandir, did you have a timeout during the ./update run ? 
<mdz> Mithrandir: usually that means it failed to download the Packages files from ports
<lamont> Mithrandir: mdz: doing another refresh in a few days should add them back without significantly impacting the first-class arch...
<mdz> no idea why it happens; it's intermittent
<ogra> Mithrandir, it happens quite often with ports
<Mithrandir> ah, ok.
<lamont> doh.  yeah.  what mdz said
<mdz> Mithrandir: dumping the source tree and running it again often fixes it
<Mithrandir> shouldn't it fail, rather?
<mdz> yes
<mdz> Mithrandir: which seeds were affected?
<mdz> if it's minimal, that's debootstrap's bug
<Mithrandir> yes, it's minimal
<mdz> if not, possibly my bug
<mdz> yeah
<mdz> debootstrap doesn't fail properly
<mdz> it didn't need to download the Packages file for --print-debs before, so this wasn't a problem
<mdz> but it ought to be fixed now
<Mithrandir> looks better now, so I'll upload this.
<Mithrandir> ok, done
<ogra> MS tried to employ esr o_O 
<bddebian> Heh, that would be funny
<ogra> http://esr.ibiblio.org/index.php?p=208
<ogra> thats no joke
<\sh> lolo
<\sh> this is a good one ;)
<ogra> yup :)
<\sh> actually they were successful with drobbins ;)
* ogra looks up polkadots
<Lathiat> hahaha
<\sh> Lathiat: actually...they're not paying bad ;)
<\sh> hmmm
<\sh> I'm waering a MS shirt right now...shame
<\sh> s/ae/ea/
<mvo> \sh: they do (at least that's what I heard), but they issue stock to compensate that
<\sh> mvo: lets say, daniel can take care about his wife and his children without a look on the cent ;)
<mvo> \sh: hm, ok :)
<bddebian> ogra: Yeah but ESR is as much of a nutjob as Gates ;-P
<mdz> fabbione: is there some clarity on the tetex issues?
<\sh> mvo: but trying to hire eric is really a joke ;)
<mvo> \sh: yes, in every respect ;)
<fabbione> mdz: yes, it's coming along
<fabbione> mdz: it looks like it will explode in a big bubble of soap
<\sh> hmmm...
<pitti> Hi otavio 
<\sh> where do i find now xfonts-cjk?
<\sh> xfonts-intl-japanese ?
<bddebian> \sh: Doesn't show on packages.u.c
<fabbione> mdz: sorry.. did you write anything else about GFS more than the warning.. i did answer and lost my box all of a sudden..
<mvo> seb128: about #13249, how does this notification look like? 
<\sh> bddebian: xfonts-xjk is not there anymore...so it should be xfonts-intl-japanese
<bddebian> xjk or cjk, you're confusing me.. :-)
<\sh> cjk
<\sh> sry
<bddebian> ;-)
<mdz> fabbione: no, I was just noticing it during a build
<fabbione> mdz: ok.
<fabbione> BenC: when is the next kernel upload planned?
<ogra> mdz, about dhcp3-server, i guess its ok if i set the two default postinst warnings from high to medium ? 
<teprrr> hmm, looks like gl works fine but not in q2.. anyone does know anything about this? _glapi_Dispatch fails when it tries to load r200_dri.. xorg problem/proble in quake2's code?
<seb128> mvo: pong
<seb128> mvo: what notificiation?
<seb128> mvo: the startup notification? it's the clock cursor
<mvo> seb128: thanks, trying to reproduce it now. I assuem I have to start it from the panel?
<ivoks> are translations on rosetta being forwared to upstream?
<seb128> mvo: yep
<mvo> seb128: hm, sorry. worksfortm
<seb128> mvo: I've tried with the gdmsetup entry
<seb128> first time it asks for the gksudo password
<seb128> second time the windows list applet has "starting..." for 15s
<seb128> and the apps has the busy pointer
<mvo> seb128: funny, it is reproducable with the gdmsetup, but not with synaptic :)
<seb128> weird
<seb128> the bug was on g-s-t
<seb128> and a friend pinged me about this with gdmsetup
<seb128> and it happens only with gksudo
<mvo> seb128: I can reproduce it on both g-s-t and gdm, but why not for synaptic. odd
<seb128> so I thought it was for all the apps using it
<mvo> seb128: do you think #15252 justifies a new upload?
<seb128> maybe that's because synaptic rocks :)
* mvo hugs seb128 
<seb128> mvo: I would say use it to collect translations and do an upload some days before 5.10
<mvo> seb128: ok
<seb128> mvo: but it should be listed by rosetta
<mvo> seb128: all "my" apps (u-m,g-a-i,synaptic) work, I'll ignore the bug and pretend it's other peoples problem :P
<seb128> ah ah
<mvo> seb128: yes, some apps are not listed, I need to ping carlos about it
<seb128> mvo: 
<seb128> $ grep Notif synaptic.desktop
<seb128> $
<seb128> $ grep Notif gdmsetup.desktop
<seb128> StartupNotify=true
<seb128> 
<seb128> maybe that's why?
<mvo> *cough*
* mvo hides
<seb128> :)
<mvo> yes, of course
<mvo> Diziet: do you plan another firefox upload soon? I got a i18n update for it
<lamont> hrm... should I get asked what dictionary I want on a hoary-> breezy upgrade?
<lamont> Name: dictionaries-common/default-wordlist
<seb128> lamont: that is known (been mentionned by several people on the list)
* fabbione heads to bed
<fabbione> good night guys
<lamont> seb128: cool
<ogra> seb128, how should i understand comment 2 in 15239 ?
<ogra> whic settings do you mean ? 
<seb128> ogra: bugzilla settings (priority, ...)
<seb128> ogra: a stopper for edubuntu or kubuntu is not one for Ubuntu
<ogra> err, yes, we talked about it already, sorry... i'm just digging through my important bugs list :)
<seb128> ogra: \sh did some good work on it, seems to be an inotify bug, so not a gamin/GNOME one
<ogra> seb128, bu it think its critical for ubuntu as well, i see it on ubuntu and edubuntu
<ogra> seb128, yes, i noticed that... i already ordered 2 goldstarts at JaneW or you both ;)
<seb128> ogra: that means we have to delay 5.10 if it's not fixed ... we probably don't
<seb128> we have only 2 bugs
<seb128> from your and \sh
<ogra> seb128, it happens with every KDE app in the gnome menu
<seb128> that's not that an issue for users
<mdz> mvo: do we need to make a corresponding change to the kernel for the notification fix, or has that already been done?
<seb128> ogra: Ubuntu don't ship with KDE apps
<seb128> not "out of the box"
<seb128> and it doesn't happen for me
<\sh> ogra & seb128: one moment :)
<seb128> so not for everybody
<ogra> seb128, and i have had lots of reports on IRC
<mvo> mdz: a single line needs to be added to the hook notitifcaton file of the kernel
<\sh> it happens to any menu items which are subdirs of /usr/share/applications/
<mvo> mdz: BenC knows about it
<ogra> seb128, i get this report for nearly all new installs of edubuntu... 
<seb128> sure, that's a stopper for edubuntu since you guys ship KDE stuff by default
<ogra> seb128, and since we suport KDE apps, they should also work in GNOME, even if we dont ship them
<seb128> would be nice
<seb128> but I don't get the issue as said
<seb128> so you will have to debug it
<ogra> yup, its on my list...
<mvo> mdz: if you have a moment, it would be nice if you could have a look at #13713 
<\sh> seb128: what can trigger this behaviour? an client or inotify itself cause it's stoopid? ;)
<\sh> s/an/a/
<mdz> mvo: oh, I thought you had uploaded that already
<seb128> \sh: dunno, I've the new linux for like 8 hours and no such issue
<seb128> and no "moved away" log message
<\sh> seb128: plain i386? 
<seb128> k7 linux version
<mdz> mvo: oh, this is a revision to the earlier patch
<seb128> but i386 install
<mvo> mdz: the media-change fix yes, if we want to have a simpler workaround we need some more support in apt because it does not support not-available cdroms
<\sh> hmm...
<doko> lamont, infinity: are the OOo2 b-d installation problems on the buildds buildd problems, or can I blame seb128 due to some new gnome stuff?
<mvo> mdz: it's a new patch, it's needed if we want to just fail if a media-change would be needed
<lamont> doko: blame seb128...  that'll give us time to figure out if you should or not.. :-)
<\sh> seb128: and as add: with "pan" i don't have this issue
<seb128> doko: there is no new GNOME stuff for a week and I've been tracking the builds
<seb128> so blame lamont :)
<mdz> mvo: looks ok
<mdz> mvo: I think there is a debian bug open about this as well
<\sh> seb128: and pan.desktop is in /usr/share/gnome/apps/Internet
<torkel> doko: thanks for fixing gcc-3.4/libstdc++. We are now one big step closer to be able to deploy ubuntu on all our clusters
<seb128> \sh: weird, I got a bug from a guy who has the issue with pan
<mvo> mdz: yes, I put it in the changelog already :)
<mvo> mdz: thanks!
<\sh> hmm...I reinstall 0.1.5
<\sh> grmpf...how can I downgrade *lol*
<seb128> \sh: http://bugzilla.ubuntu.com/show_bug.cgi?id=14967 speaks about pan
* doko watches seb128 and lamont's fight ... hey, that was easy ;-)
<seb128> "I have installed the pan news reader. Sometimes (it seems rather random at first
<seb128> sight), pan does not appear in Gnome's application menu, sometimes it does"
<\sh> seb128: I read the bugreport...but I installed pan after I updated to 0.1.6...so I have to downgrade now...and I don't want to screw my whole installation..
<Nafallo> \sh: don't you have a canonical laptop to screw? ;-)
<\sh> and when I want to remove libgamin0 and gamin now...it will remove my whole system
<seb128> \sh: how screw?
<seb128> \sh: apt-get install package=version
<\sh> seb128: thx ;)
<seb128> np
<lamont> Setting up libgphoto2-2 (2.1.6-1ubuntu3) ...
<lamont>  /var/lib/dpkg/info/libgphoto2-2.postinst: line 23: /etc/hotplug/usb/libgphoto2.usermap: No such file or directory
<lamont> dpkg: error processing libgphoto2-2 (--configure):
<lamont>  subprocess post-installation script returned error exit status 1
<lamont> seb128: ^^^
<seb128> lamont: blame pitti I guess
<\sh> Nafallo: this is not what I want to do...u don't know how hard it is to have ubuntu on it again ;)
<seb128> lamont: he did the upload
<lamont> heh
<Nafallo> \sh: I don't know that indeed :-P
<seb128> pitti: booooog
<lamont> we'll let doko blame pitti - same TZ and all that.
<seb128> both .de
<pitti> lamont: don't worry, I'm listening
<lamont> heh
<lamont> fix that.  kthxbye
<seb128> :)
<doko> ok, I'll wait with the phone call, until he's asleep 
<Nafallo> lol
<seb128> pitti: doko wants to hurt you
<bddebian> Yikes
<pitti> doko: I use to switch off my mobile at night anyway :-)
<pitti> doko: but you can cry really loud in an email 
* pitti readjusts procmail rules
<doko> did I? ;-)
<pitti> doko: no, but maybe you will :-)
<doko> there's a bug report about wav files embedded in .doc files. maybe I'll investigate ;)
<pitti> :0B\n* .*kthxbye\n/dev/null
<\sh> grmpf...
<\sh> patching fixing patching fixing pointer to (unsigned int) casts *gnarf*
<mdz> mjg59: shall we disable the hdparm -B business (regarding #6108)?
<netstar> what;s the equivalent to /etc/rc.d/rc.local/
<pitti> lamont, seb128: fixed libgphoto uploaded
<seb128> pitti: rock
<pitti> lamont: I was told that f-spot needs a g-b with the new libgphoto
<lllmanulll> seb128, Hey :)
<seb128> g-b?
<seb128> lu lllmanulll
<pitti> seb128: give-back
<pitti> seb128: that what you always call "kick"
<elmo> ogra: what's the status of kdeedu?
<elmo> ogra: the kiten stuff is still showing up as wanting to be imported
<ogra> huh ?
<ogra> Binary only demotions to universe 
<ogra> o kdeedu kiten libkiten-dev libkiten1                                {kdeedu}
<ogra> elmo, whas wrong ?
<elmo> ok - so you're happy for those to go?
<ogra> yup
<ogra> i only need parts of kdeedu, not the metapackage...
* mvo goes to bed now
<Nafallo> elmo: could you sync sbackup from unstable and new it?
<doko> elmo: is poppler-utils stuck in new? the buildds tell, it's built
<doko> pitti: anything found for idle?
<netstar> where can I get mkinitrd from?
<lamont> drivers/usb/input/hid-input.c: event field not found
<lamont> I
<lamont> 'm guessing that has something to do with the keyboard not working...
* lamont -> home.  back in a bit
<netstar> why mkinitramfs over mkinitrd?
<thierry> I just aded a patch to ubuntu bug 14744. Simple and should apply on breezy so anyone to apply it?
<netstar> do all ubuntu kernels require an initrd?
<doko> lamont, infinity: please requeue OOo2, libgphoto-2 is built and in the archive
<dieman> OOo2 uses libgphoto-2? yikes.
<doko> no, just the bloody gnome dependency chain
<ogra> mdz, ping
<mdz> ogra: pong
<ogra> mdz, i'd like to set all debconf questions in dhcp3-server to mediaum, would that be ok ? if we generate the /etc/ltsp/dhcp.conf according to the ip that should work out of the box
<mdz> ogra: yes
<mdz> ogra: don't forget to make it not a conffile
<ogra> fine, thanks... didnt want to make this change without approval
<ogra> mdz, you mean the dhcp.conf ? 
<slomo> elmo: ping?
<netstar> hi
<netstar> Where can I obtain a copy of the kernel configuration file used to make the ppc64 kernel in breezy?
<pitti> netstar: in the installed system: /boot/config.*
<netstar> yu
<netstar> ty
<netstar> initrd is always necessary for ubuntu?
<netstar> oh well, here goes nothing...again
<Surak> Hello
<Surak> Is there a reason for the cd drives having dma disabled with breezy live?
<Lathiat> dma on cds breaks on alot of hardware
<Surak> Lathiat: does this still happens? 
<Lathiat> yes
<lamont> doko: oo.o2 given-back
<Surak> Lathiat: it used to happen on older hardware - in fact, so old that gnome 2.x would be unusable with that :-) I'm curious about what kind of newer hardware still suffers from dma problems.
<tseng> doko: mdz btw i have been using rrdtool 1.2.x for awhile now in production
<Surak> I mean, older drives, which usually are at older computers. Does knoppix uses dma, isn't it?
#ubuntu-devel 2006-09-11
<AlinuxOS> doko, http://www.teutonici.com/Alinux/OOo_2.0.4-ka-GE.gsi   Voila!
<AlinuxOS> it's pure gsi ;)
<jdong> pure, uncut, powdered gsi :)
<AlinuxSOS> doko, if some problems just ping me.
<jdub> eek! console-setup questions!
<_lemsx1_> umm.. anybody uses OpenOffice from Edgy? it seems that when you try to save the program crashes
<_lemsx1_> same when opening documents using File>Open
<ajmitch> dbus lib issue, I think there'a a bug filed about it
<_lemsx1_> ajmitch: that saves me from reporting this. thanks!
<ajmitch> bug 58508
<Ubugtu> Malone bug 58508 in openoffice.org "cant save under edgy" [Untriaged,Confirmed]  http://launchpad.net/bugs/58508
<ajmitch> looks like that one
<_lemsx1_> ok. reading...
<_lemsx1_> the fun thing is that you can quit OOo
<_lemsx1_> it keeps coming back!
<Nafallo> hmm, not even triaged...
<Kaleo> Kamion: I would like to point you to bug 58500
<Ubugtu> Malone bug 58500 in ubiquity "The resize operation is impossible" [Medium,Confirmed]  http://launchpad.net/bugs/58500
<Fujitsu> Anyone around to bump that OOo up to High/Critical? It got me on Friday...
<wasabi> So uh. LaunchPad thinks my key has expired. Which, is true. It has an old key. I've increased the date.
<wasabi> How do I make LP refresh it?
<wasabi> Old key info, that is. Same key.
<Fujitsu> Just reupload it to the server.
<Fujitsu> (keyserver.ubuntu.com)
<wasabi> Ahh that's a keyserver.
<wasabi> Was trying to use hte web interface
<Burgundavia> zul_: are the xen changes you just uploaded significant?
<xav> I just made a minimal edgy install, I love it. it boots and shutdowns much faster, and everything looks cleaner
<xav> now I can make ubuntu windows-like by rebooting every 5 min, I'll do it just for fun
<jdub> http://lists.linux.org.au/archives/lca-announce/2006-September/msg00000.html
<ajmitch> jdub: is that a gentle hint for us?
<jdub> ajmitch: s/gentle hint/vicious kick in the behind/
<Fujitsu> It can be a rough hint if you want :P
<Fujitsu> Yeah, what jdub said.
<jdub> though i believe current ubuntu innovations have already been covered in proposals
<jdub> to date
<jdub> (scott on upstart)
<Keybuk> jdub: do you think my proposal needs more words/rewording?
<jdub> Keybuk: haven't read it
<bluefoxicy> so hmm.
<bluefoxicy> has anyone considered integration of FUSE into HAL to get things like ntfs-3g and sshfs easy to set up
<bluefoxicy> (no I have no idea how the heck this is supposed to work, there are security considerations though I think the proper way to handle it is to make sure only what the user can get to some other way can be mounted via fuse-- which is normal, as long as the fuse file system module is run as the user)
<jdong> bluefoxicy: I think that's on the big Linux utopian todo list... next to good tasting diet soda, open source ATI and nvidia drivers....
<jdong> swap management up to par with freebsd...
<mjg59> Goddamned ioapic suspend/resume code
<zul_> Burgundavia: yes, they are
<Burgundavia> zul_: how? (wnat to add something about them to UWN)
<bluefoxicy> jdong:  the swap management thing sounds easy.
<zul_> Burgundavia: added a bunch of 3rd party drivers, new snapshot, some bug fixes
<jdong> bluefoxicy: heh, it's not as bad as I make it sound... linux already pretty good at it
<Burgundavia> zul_: the third party drivers appear to be mostly networking ones
<zul_> ie: ndiswrapper, bcm43xx, etc
<jdong> bluefoxicy: just my experience on ram-limited old hardware is that freebsd still does it better
<zul_> Burgundavia: true..
<Burgundavia> zul_: ok, just wondering
<bluefoxicy> jdong:  Get Nitan to get his patches into mainline when they wrok
<jdong> :)
<zul_> Burgundavia: no problems, they werent there before though :)
<Burgundavia> zul_: no, I wanted to clarify. Adding somethign to UWN now
<bluefoxicy> jdong:  that'll make ram-limited twice as efficient and ample ram basically no faster/slower at all :)
<zul_> ok..ill probably blog something about it later as well
<bluefoxicy> jdong:  https://wiki.ubuntu.com/CompressedMemory
<jdong> yeah, the whole compressed memory thing sounds very nice
<mjg59> Hngh stabby stabby
<jdong> hope to see it in action soon
<mjg59> This code is approximately unreadable
<Burgundavia> zul_: cool
<Burgundavia> zul_: ping me with the blog url
<Seveas> mjg59, try running rot13 on it
<bluefoxicy> jdong:  the nice thing is it runs UNDER the swap cache
<bluefoxicy> jdong:  swap cache caches recent swap-in/swap-out and thus prevents write-back of non-dirty pages to swap when being swapped back out (they're on disk already, if they're not dirty there's no reason to write) and prevents read-back of recently swapped pages (because they're kept in memory until we really need them gone)
<bluefoxicy> jdong:  with compression this translates to avoiding compressing/decompressing pages instead of avoiding swapping pages; so compressed memory can't really make the problem of swapping any worse, which is a nice magic touch.
* bluefoxicy coughs a bit and gets back to something else
<bddebian> Howdy
<zul_> Burgundavia: no problem
<administrator> does anyone know the commandline to regenerate the debian menu system like debian packages do after they are installed?
<administrator> is*
<administrator> hmm maybe not
<administrator> it seems no one know not even the people who created debian
<administrator> knows8
<administrator> *
<administrator> well if anyone here knows
<administrator>  just ping me
<sbalneav> administrator: This isn't the channel for support, or debian support, but the command you're looking for is update-menus
<administrator> sbalneav: tried it it does not work
<administrator> sbalneav: also i doubt anyone in #ubuntu whould know i have asked before
<sbalneav> Are you doing this is debian, or ubuntu, first of all?
<administrator> ubuntu
<administrator> and not on gnome either
<Burgundavia> ajmitch: where woudl I find the final report for your SoC stuff?
<mjg59> Menus in gnome are not generated using the Debian menu system
<mjg59> And this is still the wrong place to ask
<sbalneav> AFAIK, menu entries are handled differently on Ubuntu, using the newer menu editor
<administrator> mjg59: 20:29 < administrator> and not on gnome either
<crimsun> that's the correct command. If it "doesn't work", perhaps you need to log out and back in or otherwise tell whatever app providing the menus to reread its conffile(s) [sighup?] 
<ajmitch> Burgundavia: I'll get back to you on that, I'm at work at the moment
<Burgundavia> ajmitch: sure, thanks
<zul_> meh...wife calling ttyl
<SEJeff> Can I close a bug in lp if I am not the maintainer? Some glaring ones that I just commented on like this which I am trying to triage: https://launchpad.net/distros/ubuntu/+source/compiz/+bug/31925
<Ubugtu> Malone bug 31925 in compiz "Please package new upstream version" [Wishlist,Unconfirmed]  
<Hobbsee> SEJeff: if it's fixed, yes
<SEJeff> Thanks, they told me how in #launchpad
<fabbione> morning
<Kagou> hi
<mempf> hi
<dholbach> good morning
<pygi> hey dholbach 
<dholbach> hey pygi
<pitti> Good morning
<Hobbsee> hey dholbach, pygi, pitti!
<pitti> Hobbsee: Good morning Mrs. KDE!
<Hobbsee> pitti: mrs?  who'd i marry? :P
<pitti> Hobbsee: KDE of course :)
<Hobbsee> pitti: ah right
<pitti> 'until the CVS server breakage parts you'
<Hobbsee> lol
<Kamion> jdub: it shouldn't ask questions, so please file a bug with all your details (/etc/X11/xorg.conf, 'echo GET debian-installer/keymap | debconf-communicate', /etc/default/console-setup)
<Mithrandir> mvo: mind taking a look at https://launchpad.net/bugs/49977 ?  It looks more like an apt bug than anything else.
<Ubugtu> Malone bug 49977 in linux-restricted-modules-2.6.15 "After kernel upgrade to 2.6.15-25 X server cannot find nvidia module " [Untriaged,Confirmed]  
* Starting logfile irclogs/ubuntu-devel.log
<mvo> Mithrandir: looking at it now and trying to reproduce it on my dapper box
<vehbi> why mp3,divx  and rar are not supported by default?
<Fujitsu> vehbi, please see https://wiki.ubuntu.com/RestrictedFormats.
<Fujitsu> (and try #ubuntu, here isn't the right place to asK)
<vehbi> I know it , I am asking this question because some distrubitions support this out of box, and people think that they are better
<Fujitsu> vehbi, those formats are patented, so have questionable legal connotations.
<xav> some distrib doesn't even provide it with official repo
<Mithrandir> vehbi: we can't, for legal reasons.  This has been debated to death on the mailing lists and I think there's a discussion on that page too.
<vehbi> how can other distrubitons can add them?
<Mithrandir> vehbi: they're probably willing to take the legal risk.  We aren't.
<Kamion> we believe that those "some distributions" are taking a legal risk, and we'd rather Mark's money went towards employing developers than fighting lawsuits
<Kamion> more to the point, so would Mark, in this case ...
<Kamion> (we discussed this stuff extensively back in the beginning)
<vehbi> ohh, I got it but as I said people think -who knows linux a bit or nothing-other distrubtions are good:(
<Kamion> I'm afraid our orbital mind control lasers are not yet operational
<Mithrandir> vehbi: well, there's nothing we can do about that, really.
<vehbi> Can you make a package that installs all this stuff easily for home users?
<vehbi> one big package
<Mithrandir> no
<vehbi> ok:)
<Mithrandir> sorry.  We'd like to make MP3s and DVDs and flash and all that work out of the box, but there are legal reasons why we can't.
<Mithrandir> it's not that we're evil or anything like that.  We just can't.
<Fujitsu> EasyUbuntu is for this sort of thing.
<Treenaks> Mithrandir: flash as in Macromedia Flash or as in memory cards? :)
<Mithrandir> Treenaks: the former.
<vehbi> Fujitsu:yes thats what I try to say
<Fujitsu> Treenaks, Adobe Flash nowadays :P
<Treenaks> Fujitsu: same thing, same thing  ;)
<Kamion> vehbi: https://launchpad.net/distros/ubuntu/+spec/easy-codec-installation outlines ways to improve the user experience for multimedia codecs; https://launchpad.net/distros/ubuntu/+spec/common-customizations goes through the rest of EasyUbuntu et al and tries to figure out what we can incorporate. Unfortunately neither made the Edgy feature freeze, but they'll stay on the list for the future.
<jdub> Kamion: heard of the desktop installer hanging after clicking next on the keyboard page?
<jdub> bork, it's not doing it now
<jdub> the installer formatted the windows partition as ext3 earlier
<mvo> Mithrandir: I commented on the bug (I don't think its a apt bug, more a problem with the users install)
<jdub> i'm going through it again because it had some python spew last time, and i want to make sure i did / didn't tell it to ext3ise windows
<Mithrandir> mvo: well, one could argue that apt should try to install as few extra packages as possible.
<mvo> Mithrandir: right, that would be a valid claim. feel free to retitle/reassign it to apt with a wishlist think to imporive the resolver
<mvo> Mithrandir: OTOH if just no linux-restricted-modules package is installed 
<Kamion> jdub: I'd much rather you filed bugs about this sort of thing
<Kamion> I don't mind getting duplicates
<mvo> Mithrandir: and the user wants nvidia-glx, apt has the choice between install l-s-r-2.6.15-23 or l-s-r-2.6.15-26. in both cases just one additional package
<jdub> Kamion: determining if it's a bug or not first :-)
<Kamion> jdub: and shit, you went through it again? did you save the logs from the first time?
<jdub> Kamion: pretty soon after the installer horked, the machine froze
<Kamion> jdub: at what stage did it freeze?
<jdub> the installer tb window was up, i left it for a while, and it was frozen (blank screen, too) after that
<jdub> so no evidence of connection
<Kamion> I mean how far had it got
<Kamion> the traceback window can appear at any time, so that says nothing
<Mithrandir> mvo: well, if the -23 kernel isn't installed, it shouldn't try to install that one.
<jdub> oh
<jdub> back to the larger window after the small install progress window had finished
<Mithrandir> mvo: unsure what would be a good heuristic to break cases where it can install either of two packages -- almost sounds like it should handle kernel packages specially
<mvo> Mithrandir: right, but if -23 is installed than this heuristic won't work
<Kamion> jdub: it doesn't go back to the larger window normally
<Kamion> you mean to the "installation complete" dialog?
<mvo> Mithrandir: *nod*
<jdub> Kamion: yeah
<Kamion> jdub: in that case, it had almost certainly saved the logs to the installed system already
<Kamion> jdub: but by reinstalling before talking to me, you've probably erased the evidence :(
<slomo_> doko: ping?
<pitti> slomo_: hi
<slomo_> hi pitti :)
<pitti> slomo_: please tell me how apport 0.20 works with mono
<Kamion> jdub: also, we recently swapped out the keyboard backend, so hangs are quite possible, but I'd need the logs
<slomo_> pitti: ok :)
<Mithrandir> pitti: do you have an eta for when we're able to get at the debugging symbols?
<pitti> Mithrandir: I hope this or next week, depends on infinity's work load
<doko> slomo_: I'm away, please send email
<slomo_> doko: ok
<Kamion> mbiebl: ok, fixed your console-setup issue in 1.7ubuntu8
<Kamion> mbiebl: the stty error is something else; I don't know what
<Fujitsu> Hm.
<Fujitsu> With the latest upstart/usplash update, I've got my tty1 back..
<Fujitsu> But mknod spews a `File exists' error for tty[1-8]  on tty1.
<Kamion> yeah, likewise, I think it's harmless but
<Kamion> oh, it'll be in usplash
<Kamion> I was about to upload that anyway for powerpc - I can easily fix that
<Fujitsu> Why would usplash be doing that?
<Kamion> it needs to create the ttys so it can switch to them
<Kamion> usplash (0.4-11) edgy; urgency=low
<Kamion>   * Take over responsibility for ensuring that the tty device nodes
<Kamion>     exist in time for usplash
<Kamion>  -- Matthew Garrett <mjg59@srcf.ucam.org>  Mon,  7 Aug 2006 21:02:09 +0100
<Kamion> in fact it was done earlier, usplash 0.1-17
<Kamion>   * initramfs/scripts/init-top/usplash:
<Kamion>     - mknod tty0-tty8, tty8 is the terminal that usplash -c switches to
<Fujitsu> Ah.
<Fujitsu> How will you fix that?
<Fujitsu> Redirect their output?
<Fujitsu> Or eliminate them?
<Kamion> -                mknod /dev/tty$i c 4 $i
<Kamion> +                [ -e /dev/tty$i ]  || mknod /dev/tty$i c 4 $i
<xav> sounds good :)
<Kamion> possibly [ -c ]  actually
<Kamion> if it's not a character device, you at least want the error
<Fujitsu> I'd say so.
<Fujitsu> :)
* Fujitsu likes the look of the first changelog entry of apport 0.20.
<Kamion> init-top/framebuffer creates those devices too; maybe that should be eliminated per Matthew's changelog entry
<Kamion> but shrug, not urgent
<xav> is that where the "extended states" come from : "added support for aptitude like auto-install tracking" ?
<Mithrandir> mvo: are you aware that update-manager fails to start ATM?
<Mithrandir> mvo: ImportError: No module named dbus_bindings
<xav> where does apt development happen?
<Mithrandir> actually, that's a bug in dbus.py
<pitti> Riddell: can you please test the current edgy daily langpacks? we plan another update today
<Riddell> pitti: from where?
<pygi> xav, come to #synaptic, ask there =)
<pitti> Riddell: deb http://people.ubuntu.com/~pitti/langpacks/daily/edgy/ ./  (usual location)
<mvo> xav: yes
<xav> pygi: but I also would like to know how debian and ubuntu deal with upstream, if any
<pygi> xav, mvo is upstream and he's here :) come to #synaptic pls :)
<pitti> Riddell: oh, please postpone that, we need to wait for today's dailies (in the afternoon)
<Mithrandir> slomo_: dude, your dbus-python upload broke stuff; it doesn't clean up byte-compiled files properly.
<slomo_> Mithrandir: yep, already noticed it although it worked fine here :/ seems to be a bug in pycentral, i'll look into it soon
<slomo_> Mithrandir: bug #59775
<Ubugtu> Malone bug 59775 in dbus-python "dbus-python is broken" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59775
<Mithrandir> slomo_: thanks.
<jdub> HOLY CRAP
<jdub> the new console font makes me feel like i'm using AIX
<Spads> where is gsmitty?
<Fujitsu> Which font, jdub?
<Treenaks> Spads: gsmitty?! for _gnome_?
<Treenaks> Fujitsu: terminus
<Spads> Treenaks: you know you want it.
<Kamion> it's designed to reduce eye fatigue
<Kamion> (terminus)
<Kamion> I might change the default though, depending on script coverage
<Kamion> yeah, there doesn't seem to be anything that Terminus supports that Fixed doesn't
<Kamion> or VGA16
<Kamion> but jdub whining doesn't really count :P
<lifeless> was that a whine ?
<Treenaks> I think it was a compliment :P
<Mithrandir> lifeless: comparing Ubuntu to AIX?  Yes.
<Mithrandir> Kamion: I got console-setup questions too now
<Kamion> Mithrandir: can you get me details?
<Mithrandir> Kamion: sure, what do you want?
<Kamion> Mithrandir: /etc/X11/xorg.conf, debian-installer/keymap, /etc/default/console-setup
<Kamion> and if you can, a DEBCONF_DEBUG=developer trace
<Mithrandir> in a bug or just here?
<Kamion> a bug would be good
<jdub> hooray for new laptop netcat!
<jdub> Kamion: i quite like it, but it does remind me of AIX. all it needs is green.
<Spads> and then synaptic needs a smitty theme
<Kamion> jdub: heh. can probably be arranged ;-)
<Mithrandir> Kamion: https://launchpad.net/distros/ubuntu/+source/console-setup/+bug/59883 now
<Ubugtu> Malone bug 59883 in console-setup "Asks questions on installation" [Untriaged,Unconfirmed]  
<Treenaks> Spads: just adapt yast2 ;)
<Kamion> Mithrandir: thanks
<jdub> Kamion: my housemate was wondering if i should suggest it.
<Kamion> Mithrandir: do you remember which questions it asked?
<Mithrandir> Kamion: origin and then exact model
<Kamion> Mithrandir: ah, right
<Mithrandir> Kamion: for some reason, console-setup is marked as unpacked about half a zillion times in dpkg.log.. Unsure if that has anything to do with it.
<Mithrandir> Kamion: also, I got the xkb-data/xkeyboard-config upgrade at the same time
<Mithrandir> hmm, no, xkb-data has the same "status unpacked" half a zillion times
<Kamion> "origin" actually means layout - crappy text
<Kamion> Mithrandir: model is normally before layout ...
<Kamion> unless you mean layout then variant?
<Mithrandir> Country, then variant, I think it's called, yes.
<Kamion> ok, xorg.conf is probably the one I really need, then
<Mithrandir> variant being the one where it asked about norwegian, norwegian without dead keys, norwegian (sami), etc
<Kamion> right
<Mithrandir> maybe it got confused about my XKbOptions compose:caps
<Kamion> what's your XkbLayout?
<Mithrandir>         Option          "XkbLayout"     "no"
<Kamion> oh, you're right, XkbOptions compose:caps will confuse it
<Kamion> though I'm surprised it asked for layout/variant at all then
<Kamion> you should have got console-setup/dont_ask_layout
<Mithrandir> doing a dpkg -P and then reinstalling does not cause it to reask the questions.
<Kamion> well, FSVO "should"
<Kamion> oh, no, compose:caps *is* handled
<Kamion>             compose:caps)
<Kamion>                 default_compose='Caps Lock';;
<Kamion> I just can't read
<Kamion> Mithrandir: silly question, but what's debconf/priority set to?
<Kamion> Mithrandir: and did you have /etc/default/console-setup before this installation of console-setup?
<Mithrandir> Kamion: high.
<Kamion> if you have /etc/default/console-setup but the questions aren't marked as seen (which seems unusual), then it will ask
<Mithrandir> Kamion: no, I don't think I had /etc/default/console-setup beforehand.
<Kamion> as far as I can see, that's the only way this could have happened
<Mithrandir> Kamion: maybe. :-/
<pitti> Kamion: maybe it relates to this matter, on this morning's dist-upgrade I had postfix' general configuration debconf question
<pitti> Kamion: such as postfix would have forgotten that it already displayed this question
<pitti> I suspected a postfix bug, but it might be related to this console-setup bug somehow
<fabbione> hmmmm
<fabbione> this new console-* thingy doesn't have the concept of "No keyboard connected"
<dholbach> Kamion: seems like upstream is going to release gparted 0.3.1 soon - just wanted to let you know in case you still considered it
<Mithrandir> Riddell: you might want to poke whoever has done http://wiki.kubuntu.org/EdgyEft/Knot2/Kubuntu in the past to do a Knot3 now; we're getting close.
<Riddell> Mithrandir: what's our target edgy 3 release day?
<Mithrandir> Riddell: Thursday.
<Riddell> ok
<Riddell> nixternal: ^^
<slomo_> Mithrandir: i'm completely unable to reproduce the dbus-python bug here :( i'll upload a dbus-python which checks for this files in postinst when upgrading from a lower version and then removes them for now... fine with you?
<Mithrandir> slomo_: sure, that's fine.
* Fade updates his xemacs bug
<Mithrandir> (I'm drafting a mail to ubuntu-devel now asking if anybody has any big changes they want in before main freezes tomorrow)
<Fade> Mithrandir: I got emacs rebuilt with the requisite deb_build options.
<Kamion> pitti: seems unlikely; that's orders of magnitude more likely to be a postfix bug
<pitti> Kamion: ok
<Fade> s/emacs/xemacs
<Kamion> fabbione: please file a bug or I will forget
<fabbione> Kamion: what's this new source?
<fabbione> Kamion: (name)
<Mithrandir> Fade: console-setup
<fabbione> thanks
<Mithrandir> uh
<Mithrandir> s/Fade/fabio/
<fabbione> yeah gotchat
<Fade> I was very confused there momentarily.
<Mithrandir> Kamion: should we move the "Tell Jeff about upcoming milestone" a bit earlier on the milestonerythm page?  It makes more sense for us to warn QA and Jeff that we'll need resources soon rather than "We need them now, immediately", doesn't it?
<Kamion> Mithrandir: yes
<iwj> pitti: BTW, I'm about to upload m-f-l-all with Breaks in it.
<pitti> iwj: ah, great
<pitti> iwj: instead of the Conflicts: ?
<pitti> iwj: (I'm not sure whether Breaks: is supposed to handle this rather special case, but you certainly know better than me)
<ogra> pitti, i assume you didnt get a chance to look over the SCP MIR ?
<pitti> sorry, not at Friday; I plan to do another review session today
<HiddenWolf> pitti: is apport supposed to actually work already?
<pitti> HiddenWolf: sure, is it not for you?
<HiddenWolf> pitti: I got an error when it wanted to send a crash.
<pitti> HiddenWolf: can you please file a bug with the details?
<ogra> pitti, i assume you didnt get a chance to look over the SCP MIR ?
<pitti> <pitti> sorry, not at Friday; I plan to do another review session today
<pitti> ogra: ^
<HiddenWolf> pitti: I will, if I can reproduce it.
<ogra> pitti, thanks :)
<ogra> sorry, very flaky WLAN over here 
<tseng> pitti: can yo uplease just note on the wv mir that youve approved it verbally?
<tseng> pitti: so Colin doesnt give me dirty looks for using it :)
<Tonio_> pitti: hi ;)
* tseng hugs pitti 
<Tonio_> pitti: I was looking at bluez config, and it looks like hidd is disabled by default
<pitti> tseng: yes, I will
<pitti> hi Tonio_ 
<Tonio_> pitti: why not activating this, since one always have have to connect the peripherical once at least ?
<iwj> pitti: Yes, this is just what Breaks is for.  I'm not sure why you think it's a weird special case.  It seems perfectly normal to me.
<pitti> Tonio_: no idea TBH, I never looked into BT affairs until now
<Tonio_> pitti: activating it just avoids  performing the sudo hidd --connect at every boot
<Tonio_> pitti: you just do it once and for all
<pitti> iwj: it's 'either it depends on ffox >= 1.99 and <= 2.0.99 or it depends on language-support-de'
<Tonio_> pitti: is there someone I should ping concerning this ? cause hidd hardware is really hard to manage for Joe currently :)
<pitti> Tonio_: that seems to make sense; is there an existing init script for that?
<pitti> Tonio_: yes, the bug tracking system
<Tonio_> pitti: well the config file is /etc/default/bluetooth
<Tonio_> just one line to change and it become far more usable :)
<Tonio_> okay I'll bug about this
<Tonio_> pitti: thanks
<iwj> pitti: Ah, I see what you mean now.
<pitti> Tonio_: that seems easy to achieve; please subscribe 'pitti' and 'mdz' (mdz has to approve this change, since it is a feature, I guess)
<Tonio_> pitti: sure
<iwj> pitti: But yes, Breaks is an improvement even if it can't exactly express the complete situation.
<pitti> Tonio_: so it just seems off by default to work for older kernels
<Tonio_> pitti: ah ! Well I'm reporting with all informations and probably mdz will decide ;)
<pitti> Tonio_: I'll check this out and write a comment, that's why I'd like to be CC'ed
<Tonio_> pitti: hehe
<Tonio_> pitti: bug 59894
<Ubugtu> Malone bug 59894 in bluez-utils "HIDD periphericals are disabled by default" [Wishlist,Unconfirmed]  http://launchpad.net/bugs/59894
<ogra> Mithrandir, i'll be travelling on thursday ...
<ogra> so its unlikely i can test CDs
<Mithrandir> ogra: can't you get somebody else to test them for you?  Or just make sure they're perfect on Wednesday.
<ogra> having thme perfect on wednesday wont guarantee that ltsp-build-client works fine ... there are some packages that are edubuntu-specific, if they break it wont work ...
<ogra> (i often had that in the past)
<ogra> but i'll try my best 
<Mithrandir> ogra: thanks; this schedule was drawn three weeks ago so it would have been helpful if you had complained then rather than now
<ogra> it would be very odd to not have edubuntu knot3 since thats the one that contains *all* ltsp changes for the first time 
<ogra> i can probably find someone for i386 testing ...
<ogra> but the ltsp stuff needs a lot testing and i dont know if i can find someone with the right HW
<ogra> well, i posted the dates of my travel since 4 weeks in the dev meeting ...
<ogra> i wasnt looking at the knot schedule, sorry for that
<pitti> iwj: btw, you know about m-f-l-a's magic of generating debian/control?
<iwj> pitti: Yes, thanks.  I got bitten by that last time :-).
<iwj> This time, I ran update-debian-files after editing just the template.
<pitti> right
<tepsipakki> hmm, there's a new xmms uploaded in late June, but it still isn't built :)
<pitti> tepsipakki: hrm, we totally need email notifications about FTBFSes...
<tepsipakki> :)
<Mithrandir> pitti: we have the code for doing them now, AIUI
<pitti> oh, wow
<Fujitsu> pitti, that'd be good...
<tepsipakki> a friend of mine told about xmms hanging on dapper/sarge (mp3 streams), on etch it works so wondered why edgy still had the same version as dapper
<Remenic> seb128: who's responsible for the xorg driver packages (notably ati driver) in ubuntu?
<pitti> Remenic: rodarvus ATM
* rodarvus raises his hand
<pitti> rodarvus: hello Rodrigo, how are you?
<rodarvus> hi pitti :)
<rodarvus> I'm better, thanks
<rodarvus> thankfully we were able to prepare the last rites and attend the funeral of my father in time
* pitti hugs rodarvus and wishes him all the best
* pitti waves to pygi 
* rodarvus hugs pitti 
* pitti waves to pygi 
<rodarvus> thanks dude, appreciated
<pygi> hey pitti, how are you?
<pitti> pygi: I'm fine, thanks! got apport rocking a bit more, and now back to security :)
<pygi> pitti, nice. congrats ^_^
<pygi> pitti, I made libburn rocking even more :)
<pitti> pygi!
<pitti> pygi: did you notice that Debian just forked cdrtools? (mainly due to license issues)
<pitti> pygi: let's hope that will be only temporary then, thanks to your work
<pygi> pitti, I know everything about cdrkit, yes ^_^
<popey> pitti: i doubt it's temporary
<pitti> popey: I perfectly see the need for it for etch
<pitti> popey: but eventually something like libburn seems like a better approach to me?
* popey shrugs
<popey> anything that doesn't have the "baggage" that cdrtools has
<pitti> popey: 'baggage'?
<HrdwrBoB> having been writing by a sociopathic crazed person
<HrdwrBoB> er... I mean, nothing
<popey> heh
<popey> the flame wars that go along with it whenever the kernel changes something to do with scsi or ide
<Remenic> rodarvus: hey, you're aware of some rendering issues with ubuntu with the ati drivers, right?
<pitti> pygi: how difficult would it be to write some python wrapper around libburn that emulates an useful subset of cdrecord's command line? and what about mkisofs?
<rodarvus> Remenic, yes. I got an UVF exception approval I had requested last week
<pygi> pitti, I know that you'll have a python bindings for both libburn and libisofs, and that we have cdrskin (written in C tho) which emulates useful subset of cdrecord command line 
<Remenic> rodarvus: Benjamin Otte (aka Company) has written a patch that fixes this, but it hasn't been applied upstream, and probably won't be for a while. So I'm really hoping that you could apply this patch for ubuntu
<rodarvus> in a few hours, a new version of the open source ati driver will be uploaded
<Remenic> UVF exception?
<rodarvus> Remenic, I appreciate if you could point me to the bug report describing his patch
<pygi> pitti, we are also planning to write genisofs, the emulation app which will emulate mkisofs command line (it'll also be written in C)
<Remenic> rodarvus: here it is https://bugs.freedesktop.org/show_bug.cgi?id=8134
<Ubugtu> Freedesktop bug 8134 in Driver/Radeon "Render Composite with POT sources broken" [Normal,Resolved: duplicate]  
<pitti> pygi: that ... simply rocks :)
<Remenic> rodarvus: ok it's basically a workaround, but it's better than nothing
<pygi> pitti, if you really need command line cdrecord emulation which is written in python, it would be trivial once the bindings are out, but I don't see why when you already have cdrskin
<rodarvus> Remenic, thanks, I'll take a look at it later today
<Remenic> rodarvus: thank you! I'll poke you again tomorrow ;)
<pitti> pygi: cdrskin seems to be exactly that, doesn't it?
<rodarvus> no promises it will be applied yet, though :)
<pygi> pitti, backward compatibility is important :)
<pygi> pitti, indeed :)
<Remenic> rodarvus: that's ok :)
<pygi> pitti, and you wouldn't believe how close are we to making -tao work...
<pitti> hi BenC_ 
<BenC_> hey pitti
<Kamion> pygi: if you could make HFS+/ISO9660 hybrid filesystems work as well as HFS/ISO9660, I would love you
<Kamion> pygi: as would a lot of Intel Mac users
<pygi> Kamion, you mean this? :)
<pygi> http://libburn.pykix.org/ticket/68
<Kamion> pygi: that's HFS (needed for powerpc Mac booting)
<Kamion> pygi: HFS+ is a different filesystem
<Kamion> so yes, http://libburn.pykix.org/ticket/68 will be needed too, but wasn't what I was asking about. :-)
<pygi> Kamion, ok, then file a ticket about both of your requests pls? :)
<Kamion> both of them?
<pygi> oh, one. sorry =)
<pygi> HFS+ only :)
<Riddell> Kamion: where is this new grub setup button on ubiquity-gtk?
<Kamion> Riddell: on the summary page
<Kamion> was the easiest place to put it where I could get debconf out of the way while the page was being displayed
<pygi> Kamion, I'll try to make sure you get it for libisofs 0.3.0 ^_^
<pygi> feature freeze for 0.2.1 is in 4 days :P
<Kamion> pygi: http://libburn.pykix.org/ticket/71
<Kamion> thanks!
<pygi> thanks for the ticket
<pygi> Kamion, I assume this is correct spec for HFS?
<pygi> http://developer.apple.com/technotes/fl/fl_36.html
<pygi> (regular HFS)
<pygi> brb, lunch, would be glad if you could confirm the above Kamion so I don't end up implementing wrong stuff :)
<seb128> Remenic: rodarvus but I see you figured it out :)
<Kamion> pygi: I'm not sure - I thought mkisofs just overlaid the filesystems, rather than using the Apple extensions, but I'm not certain
<Kamion> pygi: http://developer.apple.com/documentation/mac/Files/Files-99.html is the full HFS specification
<Remenic> seb128: hehe yeah, but thanks :)
<Kamion> pygi: I'd compare both of the above with mkisofs and see which is the best match :)
<Remenic> seb128: if rodarvus can apply that patch, then I'm going to apply a new progressbar style
<pygi> Kamion, ok, thanks :)
<seb128> Remenic: is that the same issue than bug #34435 ?
<Ubugtu> Malone bug 34435 in gtk-engines "Cairo and ATI RENDER extension cause scrambled buttons in UbuntuLooks" [Unknown,Unconfirmed]  http://launchpad.net/bugs/34435
<Remenic> seb128: I Think so, yes
<seb128> ok
<Remenic> seb128: one that has been haunting ubuntulooks for a long time now
<seb128> right
<seb128> how does it make difference for progressbar then? ;)
<pitti> Remenic: ooooh, don't tell me there's finally a patch for that?
<Remenic> pitti: yup!
<Remenic> pitti: a workaround, but still ;)
<seb128> I mean the bug would be really nice to fix
<Remenic> better than nothing
<sladen> Ubugtu: is that the Xorg 7.1 ABI change---or something else?
<pitti> Remenic: anyway, if the standard theme would be unf**ed on my laptop, I'd love the world even a bit more ;)
<seb128> but theme already are scewed, so one extra screwed part will not make that of a difference
<Remenic> pitti: exactly :)
<Remenic> seb128: well, this part would hurt even more I think... because a crappy looking button doesn't hurt much, but a progressbar that won't show the progress anymore becomes pretty useless :)
<Riddell> Kamion: updating kubuntu-meta all the recommends packages end up removed, is there something I need to update to have them not removed?
<seb128> Do people having that issue keep using the theme?
<seb128> I would switch to an another theme if that was on my desktop
<pitti> I switched long ago for that reason
<HiddenWolf> sladen: you're talking to the bot?
<Riddell> pitti: any chance of a main inclusion review for python-qt4 before knot 3?
<pitti> yes, I think so; I'll do reviews after my lunch
<Riddell> mvo: actually my question should probably be for you
<pygi> Kamion, you mean someone is actually able to read mkisofs code? :)
<Kamion> pygi: heh
<Kamion> Riddell: you're only looking at the changelog, right?
<Kamion> Riddell: there's an arguable bug in germinate-update-metapackages where changes to entirely new files (*-recommends-* in this case) don't get changelogged
<Kamion> Riddell: I bet you'll find that the files are there
<Kamion> Riddell: if so, just add a note to the changelog saying that all the above have become Recommends
<Riddell> Kamion: yep, -recommends- file are there so I'll upload, thanks
<Spads> zul: this ping is merely a thank you for 3.0.2+hg111412-2 and 3.0.2+hg111412-3
<Spads> zul: building now...
<zul> no problem, you'll have to grab the .config from xen-source-2.6.16
<Spads> oh?
<zul> yeah the kernel is doing different things now
<Spads> ahhhh
<zul> i guess i can make a backport for you
<Spads> okay, I'll look into it
<zul> actually if its amd64 i cant :(
<Spads> heh
<Spads> it's okay, I just need to finally make my own chroot for Xen builds.  The need for the newer gcc led me to Improper Practices on a shared chroot :)
<zul> heh..
<Kamion> smurf: ok, keymapper uploaded to Debian
<Kamion> smurf: I need to figure out how to make it fast enough to generate a full decision tree for console-setup rather than a drastically reduced one ...
<Kamion> but not right now
<smurf> Kamion: what are you doing to reduce it?
<ogra> ogra@edubuntu:~/packages/edubuntu-artwork-0.1.0$ LC_ALL=C dpkg -S /usr/lib/usplash/usplash-artwork.so
<ogra> dpkg: /usr/lib/usplash/usplash-artwork.so not found.
<ogra> where is that supposed to come from now ? 
<ogra> i think it used to be in the usplash package before
<StevenK> I saw a usplash package in the NEW queue
<StevenK> usplash- something that is
<ivoks> right -theme
<ivoks> usplash-ubuntu-theme, IIRC
<StevenK> Sounds like it
<ogra> argh
<ivoks> usplash-theme-ubuntu is right name
<ogra> that means i have to ship it in edubuntu just to make a update-alternative call to change it ? 
<ogra> thats silly
<ogra> no, there is no such package
<ogra> in fact there is not even anything that ships the /usr/lib/usplash dir anymore
<ogra> ah, in NEW ...
<ogra> but still ...
<ogra> thats a huge waste ... 2M of pics edubuntu will never use just to set a symling
<ogra> *symlink
<Kamion> smurf: hardcoding a list of keymaps to look at
<Kamion> smurf: basically just the set that console-data provides at the moment
<Kamion> ogra: huh?
<Kamion> ogra: ship the /usr/lib/usplash directory in your own package if you want to use update-alternatives
<Kamion> if you're providing your own usplash theme then of course you do not have to depend on usplash-theme-ubuntu
<ogra> well, i still need the original file, dont i ?
<Kamion> why?
<Kamion> (hint: no)
<smurf> Kamion: what's the runtime (reduced vs. full) right now?
<ogra> becuse update.alternatives complains ? 
<_ion> I just installed edubuntu-artwork-usplash, lrwxrwxrwx 1 root root 35 2006-09-11 16:27 /etc/alternatives/usplash-artwork.so -> /usr/lib/usplash/edubuntu-splash.so
<ogra> hmm
<Kamion> ogra: it's complaining that the *directory* is missing, I'll bet
<ogra> right ...
<Kamion> ogra: just ship the directory in your package
<ogra> silly me
<ogra> sorry ... i'm confused :)
<Kamion> smurf: not much vs. lots and lots
<ogra> _ion, thats still the old one :)
<Kamion> smurf: don't have current figures, but I think it's under a minute versus hours
<smurf> Yeah, the idea "some characters look substantially the same" causes some (i.e. lots of) recursion when the thing realizes it has painted itself into a corner, but doesn't know how deep the corner is
<Kamion> ah. doesn't it do an initial simplify pass to avoid traversing one tree multiple times?
<Kamion> one bit of the tree, rather
<smurf> Kamion: the best bet to reduce that would be to run the full table once, then assign lower weights to the characters/keys that end up tried first
<smurf> Kamion: it does, but only for the "this keyboard is a superset of another" case
<Kamion> I think that's deeper into keymapper than I've so far ventured :(
<smurf> Kamion: Another way would be to fiddle with the weights assigned to the "which character to try next" decisions so that it doesn't run into the dead end in the first place
<smurf> pending some analysis of the trace output -- you'd need to identify the dead end first ;-)
<pitti> BenC: btw, thanks for fixing the pcspkr in the latest kernel - nice to have beeps again :)
<Hobbsee> hey pitti 
<BenC> pitti: hehe, they do come in handy :)
<pitti> BenC: (I just closed bug 54657 again)
<Ubugtu> Malone bug 54657 in linux-source-2.6.17 "PC speaker does not work any more" [Untriaged,Fix released]  http://launchpad.net/bugs/54657
<Kamion> smurf: if you want to try it, I basically built console-setup, ran ckbcomp-mini for all possible layout/variant combinations, dumped all that into a temporary directory, and fed it to gen_keymap
<Kamion> smurf: the reason I added gen_keymap --interactive was that I got bored of having to rerun it from scratch all the time ... it doesn't quite work properly though, I think because it doesn't prune the deselected keymaps from points further up the tree
<smurf> Kamion: "all possible layout/variant combination" are to be found where?
<Kamion> smurf: Keyboard/KeyboardNames.pl
<Kamion> smurf: or I think I might have just done it by cutting off the first and second fields from pc105.ekmap
<Kamion> (produced by the console-setup build)
<Kamion> you get stuff like this:
<Kamion> hu:standard::#include hu:102_qwertz_comma_dead
<Kamion> hr:alternatequotes::#include ba:alternatequotes
<Kamion> tr::#include tr:sundeadkeys
<Kamion> ckbcomp-mini knows how to unpack it
<bddebian> Howdy folks
<smurf> Kamion: OK -- I'll have a look in a few (I'm being threatened with a short vacation ;-)
<Kamion> smurf: yeah, no rush at all, what we have now is basically working I think
<Kamion> just thought it was worth mentioning
<smurf> Kamion: sure
<pitti> Riddell: pyqt4 approved
<Riddell> pitti: you rock
<pitti> sorry for the delay
<bddebian> You should be.. ;-P
<Riddell> bddebian: wheesht
<bddebian> j/k
<Chipzz> heh
<Chipzz> why does libgtk2.0-0 depend on libcupsys2?
<Chipzz> seb128?
<bddebian> Riddell: wheesht?
<jdong|laptop> because shlibdeps said so?
<pitti> Chipzz: new printing backend of gtk 2.10, I'd presume
<seb128> Chipzz: because GTK printing API
<pygi> seb128, poke? I saw you was responsible for first libburn package in debian :)
<Riddell> Kamion: could you move python-qt4 and its binary packages into main
<seb128> pygi: I was?
<seb128> was I?
<Chipzz> seb128: neither the .la file nor the .pc file mention it, and ldd on the .so doesn't show it either?
<pygi> seb128, acording to this, you was: http://ftp.debian.org/debian/pool/main/libb/libburn/libburn_0.2-2.diff.gz
<Mithrandir> Chipzz: it's probably dlopened, then
<pitti> Chipzz: then it probably deserves a -Wl,--as-needed
<seb128> Chipzz: 
<seb128> $ ldd /usr/lib/gtk-2.0/2.10.0/printbackends/libprintbackend-cups.so | grep cups
<seb128>         libcups.so.2 => /usr/lib/libcups.so.2 (0x00002b99a5534000)
<seb128> $ dpkg -S /usr/lib/libcups.so.2
<seb128> libcupsys2: /usr/lib/libcups.so.2
<Chipzz> ok, how did I miss that... nevermind
<pygi> seb128, you interested in poking at it again? :)
<seb128> pygi: I'm waiting for the page to load, looks like my internet has some issues atm
<pygi> oki
<seb128> not really, I'm sort of busy enough already
<seb128> though I'm fine updating the package when there is some new tarballs upstream
<seb128> but I'm too busy to code on it or debug issues it might have
<pygi> seb128, no tarballs, I want svn checkout
<pitti> seb128: you sponsored the upload, nothing more
<pygi> ah, that :P
<seb128> pitti: ah, that would make sense ;)
<seb128> I'm still fine to sponsor updates for it then :p
<Q-FUNK> would anyone happen to know which package contains the default Ubuntu usplash theme to go with usplash 0.4?
<seb128> or to update to SVN 
<pitti> ogra: SCP looks fine to me (haven't tested it, of course, I trust you with that)
<pygi> seb128, would be fine if you could update to svn, and we could sync it to ubuntu :)
<ogra> yes, it runs :)
<ogra> YAY
<ogra> pitti, thanks so much
<pitti> ogra: what does it do with dbus?
* ogra hugs pitti
<ogra> pitti, there is aq hook script that runs on ltsp sessions so all IPC is done via dbus ...
<pitti> ogra: I'd like to take a look at the dbus interface, since it is a privilege transition
<sladen> Q-FUNK: {k,ed}ubuntu-artwork-usplash
<ogra> i.e. the teacher can execute apps in the users session
<pygi> seb128, ah, ignore, some more packages would have to be updated then
<Q-FUNK> sladen: I meant for the gnome-based variant
<jdong|laptop> ogra: regarding dbus/hal and vmware breakage on edgy, it seems like it's our fault
<pygi> we'll just get in "ubuntu only"
<jdong|laptop> ogra: i.e. we should've bumped up the sonumber after changing HAL's ABI
<ogra> jdong|laptop, ??
<pygi> sivang, poke?
<ogra> i havent touched either of them :)
<jdong|laptop> oh, sorry
<pitti> ogra: the hal conf file seems to indicate that only root can send these commands, right?
<jdong|laptop> it seems like you're always talking dbus :)
* jdong|laptop finds someone else to poke
<ogra> pitti, yes, only the admin user can use SCP for now
<pitti> ogra: that's good
<pitti> ogra: that with some gksudo magic should do fine
<pygi> sivang, poke?
<ogra> SCP sends the exec command on the system bus ... in the LTSP users session sits a listener that waits for the username, and if the username is in the selection it executes the command
<Fade> scp from the openssh suite?
<pitti> ogra: and sorry for the delay, I was just too busy; I hope it didn't disrupt it too much
<Fade> oh, sorry.
<pygi> Fade, no :) 
<ogra> pitti, totally not
<Fade> I was about to inject a 'huh?!' ;)
<ogra> as long as its in all is fine :)
<sladen> Q-FUNK: the testcard is in usplash itself, the overide will be in 'ubuntu-artwork-usplash' if/when it's uploaded
<ogra> Fade, SCP != scp :)
<pygi> Fade, student control panel ^_^
<jdong|laptop> I think that's a Student control panel :)
<ogra> Fade, SCP == Student Control Panel 
<fschoep> Mithrandir: ping
<jdong|laptop> LOL
<ogra> heh
<pygi> o joy, three answers :P
<Q-FUNK> sladen: right.  which is currently not in the repo.
<ogra> pygi, nobody can say our community isnt responsive ;)
<Mithrandir> fschoep: hi
<pygi> ogra, indeed, hehe :) one could even claim we are OVER responsive ^_^
<fschoep> Mithrandir: I had a request for Knot 3
<Mithrandir> fschoep: let me her
<ogra> seb128, my evo doesnt jump to the next message in the messagelist after i deleted one anymore ...
<Mithrandir> hear, even
<fschoep> Mithrandir: I want to update three packages slightly
<Hobbsee> Mithrandir: how long do we have before freeze?
<ogra> seb128, i always need to click on one to use my keyboard again
<Mithrandir> Hobbsee: until after I finish reading email and IRC backlog tomorrow morning.
<fschoep> Mithrandir: edgy-gdm-themes, edgy-session-splashes and edgy-wallpapers
<Fade> Mithrandir: I updated my bug report.
<dholbach> troy_s: heya - did you manage to subscribe ubuntu-art to the art packages?
<seb128_> re
<Mithrandir> fschoep: well, we're not frozen yet, so if those aren't big disruptive changes, just do it.
<fschoep> dholbach: Hi
<Hobbsee> Mithrandir: right.  when is tommorrow morning - how many hours?
<dholbach> hi fschoep
<fschoep> Mithrandir: OK, thanks
<ogra> seb128_, gah i talked to your ghost :)
<ogra> seb128_, my evo doesnt jump to the next message in the messagelist after i deleted one anymore ...
<fschoep> dholbach: Can I borrow you for a few seconds later today with updated artwork sources?
<seb128_> ogra: dholbach knows about it
<ogra> seb128_, i always need to click on one to use my keyboard again
<seb128_> he complained about the same
<ogra> ah, k 
<ogra> then im fine
<dholbach> fschoep: sure
<seb128_> works fine for me ;)
<Mithrandir> Hobbsee: I'm guessing somewhere in the range of 16-18 hours from now.
<fschoep> dholbach: If you can explain to me which runes you enter and what links you click on Launchpad I'd be happy to update stuff myself in the future.
<dholbach> ogra: i suffer from the same bug, slomo too
<Hobbsee> Mithrandir: right, good.  so as long as i get off my lazy rear end, and do some main work between now and then, i'll be fine.  i've been playing in universe again, as i dont have to get sponsors for that.
<dholbach> fschoep: update what? the packages? bugs? bzr branches?
<seb128_> pygi: have you tried libburn SVN? does it work?
<fschoep> dholbach: update the packages
<ogra> seb128_, dholbach, i also see a problem if evo ran but my network connection died over night ... evo dies then with a "too many open files" message
<pygi> seb128, I'm the upstream, thank you :)
<seb128_> ogra: that is weird
<Mithrandir> Hobbsee: yeah, I'm trying the novel idea of warning people beforehand this time.  Wondering how it works out.
<ogra> imaps ...
<fschoep> dholbach: BTW, I'm also gathering data for the optipng / pngcrush discussion which I'll probably have completed tonight
<seb128_> pygi: I see, you are upstream so it has to work ;)
<ogra> well, i guess it opens a file/socket whatever for every mailcheck or something like that
<dholbach> fschoep: nice
<Hobbsee> Mithrandir: hehe!   surely it's against the secret, private canonical rules.
<seb128_> pygi: I'll do a SVN snapshot then
<dholbach> fschoep: I'm going to write a wiki page about that (updating stuff)
<pygi> seb128, right, it has to work :)
<fschoep> dholbach: that would be so awesome, I really hate to call you for help
<dholbach> fschoep: so if people use the art packages as an example to branch from, they'll have an easy life
<Mithrandir> Hobbsee: well, we're trying not to keep all those discussions in secret -- it just means more work for us in the end.
<pygi> seb128, ok, so you package libburn, libisofs, and cdrskin
<dholbach> fschoep: don't hate it, do it :-)
<fschoep> dholbach: cool, thanks :)
<pygi> seb128, libburn and libisofs = 2.0SVN, Cdrskin = 1.5SVN (http://libburn-svn.pykix.org)
<pygi> seb128, thank you ^_^
<Hobbsee> Mithrandir: true that
<_ion> Hi q-funk. I think we've met at #altparty.
<Q-FUNK> _ion: possible. I've been tere a few times.
<pygi> seb128, you'll need quite a lot modifications to packages ^_^
<lamont> Kamion / pitti: postfix debconf hasn't changed in ages, afaik
<seb128_> pygi: np
<pitti> lamont: hmm, curious
<ivoks> seb128_: if you are busy, I could work on that (pygi's packages)
<seb128_> ivoks: if you want to do it you are welcome, thank you
<ivoks> seb128_: ok
<pitti> ivoks: that reminds me of the 'Warning: condition is always true' gcc warning :)
<ivoks> pitti: :)
<Q-FUNK> sladen: the (g)ubuntu splash theme simply isn't released yet, I guess.  thanks for the help anyway :)
<ivoks> pitti: i've been quite busy these days with faculty, so I was not much of a help... (this stage will continue whole month :/)
<pitti> ivoks: don't worry, uni should have precedence :)
<ivoks> pitti: it does :)
<carlos> pitti: do you remember that you fixed attr's .pot file to include a valid .po header?
<carlos> at least I think you did it for dapper
<pitti> carlos: vaguely
<carlos> pitti: anyway, Edgy's attr's .pot file lacks a header, are you still in charge of that?
<carlos> or should I ping someone else?
<pitti> carlos: it probably got lost when we synced with Debian
<pitti> carlos: I can fix it again
<carlos> pitti: ok, I'm going to file a bug report with you as the assignee
<carlos> pitti: thanks
<pitti> carlos: hm, I never touched attr as it seems
<pitti> carlos: and dapper has an unmodified Debian version
<pitti> carlos: I'll fix it anyway
<Kamion> Riddell: done
<carlos> pitti: ok, hmm, maybe it was acl and I got confused...
<carlos> pitti: thanks
<pitti> carlos: apparently that was another package -- yes, acl could be it
<pitti> carlos: nevermind filing a bug, I'm fixing it right now
<carlos> Kamion: btw, I forgot to confirm you that latest debian installer .po and .pot files were uploaded into Rosetta
<Kamion> carlos: thanks
<Riddell> thanks Kamion 
<carlos> pitti: in fact, attr doesn't have translations in Dapper, so you are right, you didn't touch it ;-)
<Kamion> ogra: student-control-panel promoted
<Kamion> tseng: wv promoted
<carlos> pitti: ok
* ogra hugs Kamion 
<pitti> carlos: fixed attr package uploaded
<carlos> pitti: thanks
<pitti> freeflying: ping
<pitti> freeflying: do you have any idea about bug 47597?
<Ubugtu> Malone bug 47597 in language-support-zh "doesn't display chinese properly" [Medium,Unconfirmed]  http://launchpad.net/bugs/47597
* ogra twiddles thimbs waiting for the seeds to sync ...
<ogra> *thumbs too
<ogra> Kamion, could you demote blender so motu has a chance to get an UVF exception through for it ? 
* jdong_ waves to BenC 
<ogra> (was dropped from edubuntu-desktop a while ago)
<Kamion> ogra: done
<ogra> thanks :)
<ogra> lfittl, ^^^^
<elmo> I don't suppose I could convince anyone to cowboy swap xvncviewer for xvnc4viewer in main?
<elmo> even in dapper, the gnome TSC programs works (as well as it does) with both
<lfittl> ogra: ah perfect, finally :)
<ogra> :)
<zul> hey simon
<sfllaw> zul: Hey.
<sfllaw> How was your weekend?
<zul> good...went to a baby show
<mvo_> Riddell: the kubuntu-meta package needs a small patch to fully support the recommends stuff, I can do it and send it to you if you it is still a issue (sorry for my late reply)
<Riddell> mvo_: please
<mvo_> Riddell: give me 5min
<ivoks> i know i'm asking too much...
<ivoks> but, could it be possible to implement graylisting for @ubuntu.com? :)
<pygi> Mithrandir, poke?
<pitti> Riddell, seb128: fresh new edgy langpacks, can you please test them?
<Riddell> pitti: URL/
<Riddell> ?
<pitti> deb http://people.ubuntu.com/~pitti/langpacks/daily/edgy/ ./
<ivoks> pitti: bug 55828
<Ubugtu> Malone bug 55828 in cupsys "PJL output from 1.2.2 client over IPP" [Unknown,Unconfirmed]  http://launchpad.net/bugs/55828
<ivoks> pitti: could it be possible to implement that patch? I know 1.2.3 is out, but due it's bugs, I would rather wait for 1.2.4 :)
<wasabi__> So why the tmpfs for restricted modules?
<wasabi__> I don't get the reason.
<pitti> ivoks: ah, that means it's fixed in edgy, but needs a dapper backport?
<ivoks> pitti: right
<ivoks> pitti: but don't backport 1.2.3 yet
<pitti> I know, there are some regressions
<ivoks> pitti: it has nasy 100% CPU consume bug, which isn't fixed yet
<ivoks> ok
<pitti> ivoks: there is a patch upstream, btw
<ivoks> is it?
<pitti> but I didn't see the issue yet, thus I didn't patch
<ivoks> i didn't check ML for couple of days
<pitti> ivoks: http://www.cups.org/str.php?L1968
<pitti> ivoks: if you get the issue, can you please test and reply upstream?
<ivoks> i can test that right now
<pitti> ivoks: I updated bug 55828 accordingly, now needs mdz's blessing
<Ubugtu> Malone bug 55828 in cupsys "PJL output from 1.2.2 client over IPP" [Unknown,Unconfirmed]  http://launchpad.net/bugs/55828
<ivoks> ok
<pitti> ivoks: (asked mdz in the bug for approval)
<ogra> mvo_, does that apply to edubuntu-meta as well ? 
<pitti> seb128, Riddell: langpacks seem to work well for me
<pitti> mvo_: is there a way to tell apt-get to not install recommends when I try apt-get install ubuntu-desktop?
<mvo_> ogra: yes, if you want to use recommends, then yes. I can send you a debdiff (or just upload it)
<mvo_> pitti: yes, but only hackish
<ogra> mvo_, as you like ...
* pitti tried --no-install-recommends, but that didn't work
<mvo_> pitti: yeah I know. only hackish
<mvo_> pitti: do you want to the hackish one?
<pitti> sure
<pitti> I'd like to have -desktop installed again, but without the auxiliary stuff I don't want
<mvo_> pitti: apt-get install ubuntu-desktop -o APT::Install-Recommends-Section="none"
<pitti> that's not quite as hackish as I feared :)
<pitti> mvo_: however, it makes no difference; it still wants to install bug-buddy and mono sttuff
<ogra> is mono already recommends ? 
<Riddell> pitti: langpacks work, but still the stock strings lacking in KDE which I need to look at (probably my fault)
<seb128> pitti: language pack update looks good to me too
<ogra> pitti, it shouldnt install gnome-screensaver thats for sure a recommends
<pitti> Riddell, seb128: thanks; thus good to upload?
<seb128> as far as I'm concerned it's good to upload yep ;)
<pitti> ogra: well, I have that installed :)
<ogra> heh
<ogra> as anyone :)
<Riddell> pitti: yep
<mvo_> pitti: I will have a look (once I finished kubuntu-meta)
<pitti> mvo_: oh, f-spot and bug-buddy are still depends, thus not your fault
<mvo_> pitti: aha, ok. I guess changing the seeds is ok for this
<mvo_> Riddell: do you want a debdiff or should I upload the changes?
<Riddell> mvo_: debdiff would be nice, I have an update pending anyway
<mvo_> ok
<mvo_> Riddell: http://paste.ubuntu-nl.org/23136 <- should be what you need 
<Riddell> mvo_: worth pinging ogra and xubuntu with that too?
* ogra already reads the patch
<mvo_> Riddell: absolutely!
<mvo_> ogra: I have a update for you too :) shall I send it or upload it? (upload without any other modifications)
<ogra> upload is fine ... as you like 
<ogra> if it causes extra work for you, just send it to me
<mvo_> ogra: no, that is fine. I uploaded it now, please let me know if it works (should pick up recommends automatically when you do your next seed change and use " * (pkgname)" instead of  the regular " * pkgname"
* mvo_ will do the same modification for xuubntu
<ogra> yup, i already merged the seed changes ...
<mvo_> ogra: ah, nice! my upload was without runing ./update because I was not sure about this
<mvo_> note that germinate does not yet get the changelog right, it may write funny stuff like "removed foo; added foo" 
<ogra> i'll do the update ... need to add SCP to desktop anyway ...
<ogra> well, it looks right in ubuntu-meta 
<mvo_> ogra: because I ran a "querry-replace" over it *cough* 
<ogra> heh
* mvo_ whistles inoccently
<Kamion> mvo_: I fixed that
<Kamion> it'll say "added foo to desktop-recommends-i386" or whatever now
<mvo_> Kamion: oh, great! 
* mvo_ hugs Kamion
<Kamion> however it still won't list the additions to the new file the first time you add recommends
<Kamion> you can probably work around that by touching all the *-recommends-*
<Kamion> first
<pitti> how can it be that both i386 buildds are idling around when there are a bazillion langpacks waiting to be built?
<pitti> well, now they at least build something
<Kamion> pitti: I've accepted usplash-theme-ubuntu straight into main, FYI; I assumed it was at least conceptually a split-out from usplash
<pitti> sounds sensible, thanks
<tseng> Kamion: thanks alot
<tseng> Kamion: will upload beagle when i get home
* mvo_ is out for ~30min
<ogra> Kamion, edubuntu can default to dhcp network setup again btw ... 
<ogra> we should change that before release ...
<Kamion> ogra: please file a bug on /products/ubuntu-cdimage telling me what to do
<ogra> ok
<mdz> pitti: does apport display a progress indicator now?
<ogra> bug buddy does ...
<mdz> pitti: and what do you plan to do about interaction with the gnome segv handler?
<pitti> mdz: progress> how should apport do this?
<pitti> mdz: bug-buddy> I asked seb128, and he prefers to keep bug-buddy installed by default
<mdz> pitti: isn't the slow part basically dpkg -S?
<pitti> mdz: yes, about half of that time is used by dpkg -S
<pitti> mdz: but apport is called by the kernel, not from the user's session, thus it would be quite hackish to display a progress bar
<mdz> pitti: is there nothing running in the session that it could send a message to?
<mdz> pitti: maybe not a progress bar, but just a notification
<mdz> "A program has crashed, information is being collected" or such
<pitti> mdz: we could try a update-notifier hack
<pitti> mdz: basically we don't even need to change apport for that
<Treenaks> and: is the 'OOPS' when you kill apport intentional?
<pitti> mdz: the 0-byte report is created, then apport collects, finally the file is completed
<pitti> mdz: but apport now runs with nice 5, thus should be much less disturbing
<pitti> Treenaks: ?
<mdz> pitti: given that it takes some time to create the report, I think we should display something immediately
<Treenaks> pitti: I've had a few kernel OOPSes when killing apport
<Treenaks> pitti: (as apport was hogging memory/cpu, and I didn't have a clue about what it was..)
<pitti> Treenaks: that's news to me, can you please file a kernel bug?
<mdz> pitti: in my experience it seems I/O bound, so scheduling priority doesn't make much of a difference
<pitti> mdz: in my experiments it behaves much better
<mdz> but I haven't seen it run in a while
<pitti> mdz: previously it made the desktop session sluggish, music playback stuttering, etc.
<pitti> now it's smooth as silk
<pitti> mdz: I'll discuss that with mvo, if you want that feature
<agutierr> hello all: someone knows if its possible to reuse a partition table using preseeds? Thanks :-)
<seb128> mdz: I've added a gconf-key (/apps/bug-buddy/run_on_crash) for bug-buddy, if it's set to false the gnome_segv handler is not set
<mdz> seb128: so we can set that to false by default?
<seb128> we can yep
<seb128> I advice not doing so
<seb128> since we don't get automatic debug bt yet
<pitti> seb128: do we with b-b?
<seb128> and we don't have the workface to handle the hundreds of crashers week that we would get
<seb128> pitti: no, that's my point, we would not won anything and increase the workload a lot
<seb128> s/won/win
<pitti> ah, I see
<seb128> my opinion will probably change the day we get debug backtraces for everything
<seb128> there we will win a lot over bug-buddy
<Treenaks> pitti: https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/59935
<Ubugtu> Malone bug 59935 in linux-source-2.6.17 "OOPS when killing apport" [Untriaged,Unconfirmed]  
<seb128> pitti: did you fix the coredump limit issue BTW?
<seb128> like evolution bt would work now?
<pitti> seb128: oh, not yet; can you please file a bug so that I don't forget?
<pitti> Treenaks: I believe today's version (0.20) should fix/workaround this
<pitti> 'k, I gotta run now
<pitti> cu tomorrow!
<Treenaks> Bye
<seb128> pitti: linux bog?
<kristog> uh cool i get MD5Sum mismatch if i use the universe repo of it.archive.ubuntu.com.
<o_cee> anyone got any idea about Bug #59691, "vmware-player fails to start"? got a similar crash here when i try to start, the only thing it writes to the console is: "/usr/lib/vmware-player/bin/vmplayer: /usr/lib/vmware-player/lib/libpng12.so.0/libpng12.so.0: no version information available (required by /usr/lib/libcairo.so.2)"
<Ubugtu> Malone bug 59691 in vmware-player "vmware-player fails to start" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59691
<seb128> o_cee: mvo_ might have an idea
<o_cee> seb128: ok, we'll wait for him then :)
<Burgwork> seb128, desrt was mumbling someting about a dbus issue
<mvo_> o_cee: this only happens on edgy, right?
<seb128> Burgwork: something specific?
<o_cee> mvo_: don't have any machine with dapper, but i'm on edgy yes
<Burgwork> seb128, something about being linked to 2 and 3 at the same time?
<mvo_> o_cee: ok, thanks
<o_cee> mvo_: no problem. let me know if you need more info or whatever, got a generated crash report as well
<jdong_> o_cee: does the LD_PRELOAD workaround work for you?
<o_cee> jdong: point me in the right direction please? haven't seen that 
<jdong_> o_cee: LD_PRELOAD=/usr/lib/libdbus-1.so.3 vmplayer
<o_cee> sec
<seb128> Burgwork: not sure of what he was speaking but thank you for mentionning it
<seb128> Burgwork: ah, was about vmplayer?
<o_cee> jdong: seems like it yes, it started at least
<jdong_> o_cee: cool; there's a dupe bug report with more info
<jdong_> bug 59232
<Ubugtu> Malone bug 59232 in hal "libhal1 0.5.7.1-0ubuntu8 with new dbus breaks vmware" [Untriaged,Confirmed]  http://launchpad.net/bugs/59232
<o_cee> jdong: cool, thanks. probably the same as the other bug i mentioned
<jdong_> yep
<jdong_> the png warning is not the real warning
<Burgwork> seb128, yep. He was looking into the oo.o crashing issue and said "this solves the vmplayer issue as well". He said nothing further and I didn;t question
<jdong_> just a throw-off
<jdong_> Burgwork: the OOo crash is related to the vmplayer issue?
<Burgwork> jdong, no idea, again, this is 2nd hand. Check the logs for saturday or sunday
* jdong_ ld_preloads oowriter
<jdong_> gasp!
<jdong_> it works!
* jdong_ hugs Burgwork
<zyga> hey
<Burgwork> mark si the on the front page of cnn http://edition.cnn.com/
<tseng> whoa
<tseng> where..
<Burgwork> left, little box
<Burgwork> also first story on their tech section
<zul> http://edition.cnn.com/2006/TECH/09/11/space.tourist.microsoft.reut/index.html
<zul> still old picture though
<Burgwork> space is cool
<Burgwork> linux is not
<zyga> Burgwork: that's right, linux is hot and it's way to cold in space :D
<Burgwork> heh
<Keybuk> In space, nobody can hear you run closed-source products.
<zyga> Keybuk: yes they can, vista startup sound is getting mandatory, at least co-workers in the space shuttle or the ISS would know ;D
<Burgwork> zyga, does that mean, when the shuttle launches, the noise will be overpowered by a massive windows login tune?
<zyga> Burgwork: now it makes sense why the launch platform is so far away from casual viewers
<Burgwork> right
<zyga> microsoft would have to pay for running the sound on national tv
* bluefoxicy sighs as he idly hammers the package servers
<bluefoxicy> you know what would be nice
<bluefoxicy> all this talk about zeroconf and avahi, how about mdnsing a package server
<bluefoxicy> once you enable avahi, you find that -updates and -security for any distribution you're running has multiple mirrors on your network
<bluefoxicy> and when you update, they all communicate, determine who has the package, mirrors it across eachother; if it's not there it's downloaded from the main server and streamed to whoever else wants a copy at the time
<bluefoxicy> network of 5 billion PCs?  No need to clog the point of presence link
<jdong_> Keybuk: any chance for updated readahead-lists in time for knot3?
<CarlFK> bluefoxicy: we need apt-torrent :)
<bluefoxicy> (I would not mind such a server being set up as a proxy either, mind)
<bluefoxicy> CarlFK: Nah, I mean organizational.
<bluefoxicy> At a school district they decided to install winxp sp2
<zyga> bluefoxicy: hmm?
<zyga> bluefoxicy: apt-mdns?
<zyga> bluefoxicy: is there such a thing already?
<bluefoxicy> so somene decided, hey, send all 1000000 PCs to windowsupdate
<bluefoxicy> zyga:  no clue!  :)
<zyga> bluefoxicy: that would be kind of cool :)
<bluefoxicy> anyway, what happened was, for 3 days there was no internet.  The pipes were totally clogged.
<jdong> bluefoxicy: hasn't anyone thought of putting up a caching proxy? :)
<zyga> I don't know much about bonjour/avahi but I guess it's perfectly possible
<zyga> the workstation would have to publish an ubuntu mirror service and apt could somehow sniff that
<bluefoxicy> And I am thinking, with apt, you could have deb http://10.1.1.11/ubuntu edgy-security main restricted
<CarlFK> http://packages.ubuntu.com/dapper/admin/apt-proxy
<bluefoxicy> and then when you contact the web server it'll proxy through it yeah, and cache it
<bluefoxicy> except at home you may have 3 computers in bedrooms and 2 laptops, and you won't set up an apt-proxy yourself
<CarlFK> "apt-proxy automatically builds a Debian HTTP mirror based on requests which pass through the proxy.  It's great for multiple Debian machines on the same network with a slower internet link."
<bluefoxicy> which is where an apt-mdns would come in
<bluefoxicy> CarlFK: mmhmm.
<bluefoxicy> CarlFK:  the automation would be good for home users though, who don't normally do anything but click "update"
* bluefoxicy checks out apt-proxy anyway, since it'll do what he wants most likely.
<jdong> apt-proxy is great...
<jdong> if you have more than one edgy box on a lan, it's a requirement :)
<jdong> only thing, needs that dedicated apt-proxy server
<jdong> and sources.list editing
<bluefoxicy> (I want something that can be around by default and working automatically for everyone using Ubuntu, though)
<jdong> not to mention it's damn inconvenient if you have a laptop that can roam onto a apt-proxy-less network
<jdong> so yeah, bluefoxicy, make apt-avahi happen :)
<jdong> aptvahi
<jdong> there you go
<bluefoxicy> heh
<jdong> a name for it
<bluefoxicy> jdong:  Maybe after I get Steel finished.
<Keybuk> jdong: depends when the Knot 3 freeze begins
<Keybuk> I want to take some time to actually play a little with readahead again
<Keybuk> do some test runs and see what effect different tests have on it
<jdong> Keybuk: awesome
<Keybuk> (e.g. sorting it by block at boot, not at generation time
<jdong> Keybuk: yes!
<Keybuk> running it in the foreground, not the background
<Keybuk> etc.)
<bddebian> Man, I read readahead as something else.. Heh.. ;-)
<jdong> thank you!
<Keybuk> and I obviously want it to be tested on the live cd and real system, etc
<Keybuk> that's a few days work
<jdong> Keybuk: at the forums, there's mixed results from reprofiling their systems
<jdong> Keybuk: most people reported 5 or more seconds better bootup
<jdong> Keybuk: some reported no change
<jdong> Keybuk: I just posted a follow-up asking for daring people to test foregrounding readahead... will let you know how that turns out
<jdong> but from that, I think definitely reordering deserves a look :)
<Keybuk> jdong: did anyone report worse?
<jdong> Keybuk: nope. that's the good news :)
<Keybuk> that's good, at least
<jdong> Keybuk: but I'd expect maybe a "worse" report or two from foregrounding
<zyga> Keybuk: hey, does X die moment after login due to upstarf
<zyga> upstart?
<jdong> zyga: I read that as upsnarf :P.... good nickname for when it fails :)
<CarlFK> is there a right way to draw attention to a bug report?
<zyga> jdong: I was not trying to be mean 
<zyga> CarlFK: bounty
<Keybuk> zyga: no
<jdong> CarlFK: I usually whine about it :)
<Keybuk> zyga: at least, there's no reason it should
<jdong> zyga: gdm or kdm?
<zyga> Keybuk: X sigsegvs regularly about 5 seconds after logging in on ati driver
<zyga> gdm
<zyga> radeon X300
<Keybuk> oh, that'd be the driver at fault then, no? :p
<CarlFK> edgy alternate and server aren't installing, which seems pretty bad: Bug #59938
<Ubugtu> Malone bug 59938 in debian-installer "edgy alternate installer: No kernel modules were found" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59938
<zyga> Keybuk: well it didn't used to :-)
<Keybuk> upstart can't magically induce segfaults in proprietary drivers <g>
<jdong> Keybuk: that's an open source driver, thank you very much :)
<zyga> Keybuk: note: ati != fglrx
<zyga> :)
<jdong> and for the record, my fglrx is running gdm just fine :)
<Keybuk> nor open source ones
<zyga> bah, I know I want to buy intel next time
<Keybuk> upstart can be blamed for something not starting
<zyga> now after intel both ati and nvidia are just crap 
<Keybuk> it is not responsible for your fonts looking funny
<zyga> Keybuk: okay I got the message
<Keybuk> (yes, someone really thought upstart had caused that)
<zyga> Keybuk: heh
* Keybuk looks pointedly at ogra
<zyga> Keybuk: I just remember you saying that upstart pulled VT from X and that was kind of deadly
<zyga> Keybuk: BTW, why does VT gets killed twice during startup?
<jdong> zyga: you should be looking at blaming usplash for that :)
<Keybuk> zyga: no idea
<Keybuk> which vt?
<zyga> Keybuk: anything I can set to make upstart much verbose
<zyga> Keybuk: tty[1-6] 
<Keybuk> boot with --debug on the kernel command-line
<zyga> Keybuk: will do, it happens at work
<zyga> for some reason it didn't affect my laptop at home
<bluefoxicy> is it just me or does Planner have no native file extension
<Kamion> CarlFK: shrug, probably transient
<Kamion> that error message is symptomatic of mid-transition images
<CarlFK> Kamion: ok - I'll try again in 24 hours 
<Kamion> oh, it's because debian-installer failed to build
<Kamion> infinity: could you give-back debian-installer on all architectures, please? those build failures look transient
<frandavid100> hi
<frandavid100> I'd like to ask a question
<frandavid100> is there a chance to pack a given program to use tango icons even if that's not the default?
<frandavid100> I'm thinking gaim, or gimp
<glatzor> frandavid100: you should contact the artwork team
<frandavid100> how could I do that?
<zyga> frandavid100: #ubuntu-artwork is there but I don't know how occupied it is
<zyga> frandavid100: try the mailing list
<glatzor> frandavid100: or subscribe to the mailing list. you could push your wish if you already have got a patch or a plan
<frandavid100> thanks a lot guys
<glatzor> frandavid100: https://wiki.ubuntu.com/ContributeToUbuntu this site is a good starting point
<Mithrandir> pygi: hi
<pygi> hi Mithrandir 
<Mithrandir> pygi: you pinged me?
<pygi> Mithrandir, just wondering how your student(s) passed SoC
<Mithrandir> pygi: not very well, I'm afraid.
<pygi> Mithrandir, ahm? :-/
<Burgwork> Mithrandir, ajmitch keeps promising me updates for the UWN, but so far nothing
<Mithrandir> Burgwork: well, SoC is over now anyway so whatever is done now, though nice, can't affect those evaluations.
<pygi> Mithrandir, so he failed the final eval?
<Keybuk> my god, this md guy is so pessimistic
<kristog> Keybuk: why?
<Keybuk> it's a bit "it's all doomed, it can't possibly fixed, it'll never work"
<Burgwork> Keybuk, md?
<Keybuk> uh, md != marco in this case <g>
<Keybuk> mdadm
<Lure> Keybuk: neil brown?
<Keybuk> bug #54002
<Ubugtu> Malone bug 54002 in udev "LVM/MD root filesystem not found by uuid" [High,Confirmed]  http://launchpad.net/bugs/54002
* desrt feels sort of that way about edgy sometimes :)
<desrt> wow.  this bug has a lot of commentary
<seb128> Keybuk: is xdg-utils binary stucked to NEW?
<xav> will 2.6.18 go in when released?
<seb128> no
<seb128> 2.6.17 for edgy
<xav> I would still like to see this bug, kernel-package needs to be updated for working with 2.6.18-rc kernel, so probably 2.6.18 as well.
<xav> to see this bug fixed, even
<mdz> Kamion: around?
<fschoep> Does anyone know whether or not the Firefox Human theme is going to be included and set to be default for Knot 3?
#ubuntu-devel 2006-09-12
<wasabi__> shell script pros: Looking for a trick to make a script process lines from a command as they come in. easy enough with a while read line pipe or otherwise. I want a timeout though. If the while loop doesn't exit within 30 seconds, I want it to break out.
<wasabi__> Various ideas have popped up: fork sleep 30 && kill $$. That sucks. ;)
<xav> wasabi__: man read maybe
<xav> wasabi__: help read rather, but finally I don't think it'll help you, sorry
<Jones_> The one thing that doesn't work on my system is video. Something wrong relating to libxv1 I believe. flash plugin works with youtube etc. But videos don't work. mplayer/vlc/totem all included. If I do, mplayer -fs -vo x11 -zoom; it plays. But I can't just click on a video and play it, totem just shows a black screen.(the audio works fine on all players)
<Jones_> Are there any bugs relating to this for edgy? I couldn't find any...I wanted to make sure before I file a bug report.
<Jones_> I'm not really sure what to say on the bug report, just that video doesn't work I guess? I don't know exactly what the problem is.
<xav> what does xvinfo say?
<Jones_> I did apt-get build-dep libxv1; apt-get source libxv1; and I recompiled it from orig, but still doesn't work.
<xav> what error do you get when usin mplayer?
<Jones_> xav: http://www.rafb.net/paste/results/Uknu2r25.html
<Jones_> http://www.rafb.net/paste/results/F7g6AU40.html (mplayer error)
<Jones_> I tried to play $HOME/Examples/Experience\ ubuntu.ogg
<Jones_> Doesn't work in Totem/vlc/mplayer.
<xav> did you try xv with another video?
<Jones_> yes, I tried an mpeg-1 video, and xvid(ogm) video.
<grexk> morning everyone
<treitter> how does the kernel versioning work?  (ie, in linux-image-2.6.15-26.46, what are the numbers "26" and "46" for, exactly?)
<xav> in which place is it morning?
<Fujitsu> xav, Australia.
<Jones_> I'm thinking it might be because I dist-upgraded from dapper to edgy a couple days ago. And I should have just done a clean edgy install. So maybe I'll format when knot3 comes on in a few days, and if the problem is still there I'll file a bug.
<grexk> xav, Philippines
<xav> ah yep
<xav> ok :)
<xav> Jones_: that would be odd
<jdong> treitter: 2.6.15 is the upstream kernel version number, 26 is the Ubuntu ABI, 46 is the number of revisions ubuntu has made since the 2.6.15 package
<treitter> jdong: great! Thanks
<jdong> treitter: 26 is changed every time a kernel change is made that would break binary compatability
<Jones_> xav: Well I can't figure it out. I don't know what is wrong with libxv1
<treitter> jdong: is this documented somewhere? I had no luck finding it on my own
<jdong> treitter: I'm not sure if it's documented somewhere; good question
<jdong> treitter: http://kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-dapper.git
<xav> Jones_: are you sure the problem is with libxv1 ?
<jdong> that's a live browser of what goes into Dapper's kernel
<jdong> treitter: in reality it's A LOT more than just a 2.6.15 kernel ;)
<Jones_> xav: no
<treitter> jdong: so I hear :)
<treitter> jdong: do the numbers start at 1?  (ie, was the first 2.6.15 kernel 2.6.15-1.1?)
<jdong> treitter: yep.
<treitter> jdong: cool, thanks
<treitter> jdong: is the git repo you pointed me to documentation, or an actual kernel?
<treitter> jdong: it'd have to be worth it to install git to check it out :)
<jdong> treitter: it's the git branch; I find the changelog really informative
<jdong> treitter: there is documentation on the wiki for checking out git branches of ubuntu kernels
<Jones_> xav: What else could it be do you think?
<xav> Jones_: the driver
<Jones_> I'll reboot into vesa and see how that does.
<xav> Jones_: I didn't think that worked, but I've no clue
<Jones_> xav: hmm, yea things work in vesa
<Jones_> They're kind of slow/choppy when I play video and resize things
<Jones_> I wonder what is wrong with x.org's ati driver
<xav> ah, didn't know xv was possible with vesa
<roico> is the common customization spec going to be implemented till edgy?
<Keybuk> roico: I suspect you mean "by edgy" :p
<roico> well yeah, english is not my native, sorry... =\
<Keybuk> oh, meh, whoever registered that can't spell customisations :p
<Keybuk> by the status, it would appear that it will be at least partially implemented for edgy
<roico> didn't we pass the feature freeze?
<Keybuk> yes, and it hasn't been marked as deferred
<roico> whats deferred?
<HrdwrBoB> put away until later
<Keybuk> though it wasn't mentioned in the FF meeting
<d1sc0rd> anybody using ndiswrapper on edgy in here
<Burgwork> Keybuk, licensing of tcl files. Know anything abou tthat?
<Keybuk> Burgwork: uhh?
<Keybuk> -v
<Burgwork> Keybuk, I have some code here that I need to attach the GPL to
<Keybuk> err?
<Keybuk> -v
<Keybuk> -v
<Keybuk> -v
<Keybuk> :p
<sivang> re
<Keybuk> I'd quite like to attach the GPL to the Windows source code ... doesn't mean I can <g>
<sivang> Keybuk: heh
<Burgwork> right, this is code  my company wrote
<Keybuk> ok, so they own it
<Burgwork> my new job as "Open Source Community Manager" at Userful means I get to cleanup the code to get it read to actually have code to build a community around
<sivang> Keybuk: http://www.reactos.org/xhtml/en/index.html
<Burgwork> sivang, indded
<Burgwork> so I have a bunch of .tcl files. Do I need to append the "this is under the GPL" to all of them?
<Keybuk> ok...
<Keybuk> have you read the GPL? :p
<Burgwork> yes, and this http://www.gnu.org/licenses/gpl-howto.html
<Jones_> Burgwork: join the debian-legal mailing list
<Burgwork> Jones_, I value my eyes and brain
<sivang> Burgwork: quite nice to see something like that going on.
<Keybuk> ok
<Burgwork> sivang, trying hard to make sure it is code thrown over the wall
<Keybuk> Burgwork: that kinda tells you the answer :p
<Burgwork> Keybuk, in this instance, each tcl file is considered source?
<Keybuk> I wouldsay so
<Burgwork> ok, thank you
<Burgwork> let me buy you a drink at the next develops summit
* Burgwork goes off, grumbling about tcl and openacs
<sivang> Burgwork: ;-)
<jdong_> ack, is dbus misbehaving with permissions for anyone else?
<bddebian> Heya
<Seveas> mjg59, ping
<mjg59> Seveas: Hi
<Seveas> mjg59, would it be possible to add one more field to struct usplash_theme? I'd want a char* name in there, which can be used by a frontend I want to develop for edgy+1 but like to test on edgy systems -- I'll provide patches for the 4 existing themes
<mjg59> Seveas: Wurgh.
<Seveas> mjg59, an often asked question is how to switch between themes, so I thought: who not make it easy and learn some gtk along the way ;)
<mjg59> Heh.
<mjg59> Ok
<mjg59> Put it in the themes first
<mjg59> Actually, no, that's difficult
<Seveas> yeah
<mjg59> Put it in the .h but don't use it in the client
<mjg59> That way it won't care about the format of the themes changing
<mjg59> Providing the char* is at the end
<bluefoxicy> Can someone tell me when makedepend and imake will be gone?
<bluefoxicy> they've been obsolete for the past couple months but removing them removes damn near everything on my system
<Fujitsu> They'll be gone when the packages which depend on them have been fixed.
<bluefoxicy> how vague
<mjg59> If there are dependencies on them, that implies that they're not obsolete
<bluefoxicy> anyway I have to test this new via driver and see if it kills my system, i'll reboot too.
<bluefoxicy> mjg59:  they don't seem to be in the repos, says synaptic
<wasabi> What bluefoxicy says is accurate. They're sitting on my system too.
<bluefoxicy> driver check.
<mjg59> Oh
<mjg59> Because you still have transitional packages installed
<mjg59> apt is poor at dealing with that situation
<Fujitsu> It does that.
<wasabi> Which are the transitional packages?
<bluefoxicy> Works.
<wasabi> oh crap. everything that touches my disk is now getting IO errors.
<wasabi> uh oh!
<rodarvus> wasabi, 'dpkg --list | grep transitional'
<wasabi> wasabi@kyoto:~$ ls
<wasabi> bash: /bin/ls: Input/output error
* Fujitsu runs away from wasabi, as his system starts to combust.
<wasabi> Yeah I probably won't be here long.
<wasabi> Heh gtk icons are disappearing all over
<wasabi> bbl. =(
<Fujitsu> :(
<Fujitsu> Good luck!
<wasabi> somehow it is now fixed. =/ that's scarey
<mjg59> https://launchpad.net/bugs/59997 - this has to win some sort of prize for the most amusingly misdirected bug
<Ubugtu> Malone bug 59997 in xen-3.0 "[edgy]  xen fails to run" [Untriaged,Unconfirmed]  
<mjg59> Oh, that's interesting
<mjg59> I just got mail telling me it had been filed against usplash
<ajmitch> mjg59: I reassigned already
<ajmitch> since he also filed bug 59998 which I closed as duplicate
<Ubugtu> Malone bug 59998 in xen-3.0 "[edgy]  xen fails to run" [Untriaged,Rejected]  http://launchpad.net/bugs/59998
<mjg59> ajmitch: I kiss you
<wasabi> oh crap. my system is doing this io error stuff over and over again
<wasabi> might be new kernel
<jamadagni> hello is mithrandir here?
<mjg59> jamadagni: It's 05:12 his time
<Hobbsee> mjg59: freeze cant be in place yet then :P
<Hobbsee> which is good.  i want to test this fix to see that it really works, before getting a sponsor.
<wasabi> Heh. Corruptex XFS. Big time.
<HrdwrBoB> wasabi: I did that
<wasabi> Oh?
<HrdwrBoB> 32->64 bit OS change, destroyed it
<wasabi> I thought XFS was arch neutral
<HrdwrBoB> allegedly
<wasabi> ahh fuck. I just repaired it in a 64bit livecd.
<HrdwrBoB> well, it is
<wasabi> I have probably just destroyed it
<HrdwrBoB> wasabi: haha
<HrdwrBoB> yes
<HrdwrBoB> I'm sorry, but.. yes
<HrdwrBoB> if you have a dirty log
<wasabi> god damnit.
<HrdwrBoB> and you use it in a 64bit sytem
<HrdwrBoB> it eats it
<wasabi> it just moved a shit ton of inodes to lost+found
<HrdwrBoB> yes, and even those are screwed
<wasabi> Well, I'll be mightily disappointed if so
<HrdwrBoB> well, that's exactly what happened to me
<HrdwrBoB> and the data was all gone
<HrdwrBoB> there's data THERE
<HrdwrBoB> but it's not the same data you had before
<wasabi> Probably going to mount empty, with nothing except a lost+found
<HrdwrBoB> yep
<HrdwrBoB> there's lots of stuff in lost and found
<HrdwrBoB> but files aren't the same data
<HrdwrBoB> this is fixed in the latest XFS releases
<bluefoxicy> right
<bluefoxicy> don't use glxinfo.
<HrdwrBoB> I lost 1.4tb of data
* bluefoxicy notes.
<wasabi> how can i run xfs_repair twice and have it fix things both times.
<wasabi> bah
<HrdwrBoB> wasabi: I know you want to make sure for yourself
<HrdwrBoB> but your data is toast
<HrdwrBoB> restore from backups (you have backups right?)
<wasabi> I keep my Big FIles on a seperate partition.
<wasabi> Which, hopefully, isn't fucked up.
<HrdwrBoB> unless you mounted it, it should be fine
<wasabi> There was some important stuff on /. We'll see.
<wasabi> My other partition is 800GB. No way to back it up.
<HrdwrBoB> yeah, that's my problem
<HrdwrBoB> this is why i now use LVM and make a snapshot daily
<wasabi> I'm getting close to giving up on XFS.
<johanbr> Lots of people seem to have trouble with XFS, like Martin Krafft: http://blog.madduck.net/geek/2006.08.09-through-with-xfs
<HrdwrBoB> prevents against accidental deletion and fs screwups
<wasabi> I like it a lot, but it's screwed up in various ways 3 times now.
<HrdwrBoB> XFS is a very large speed win for my large array with large files, so I stick with it, however for regular usage, it's not worth the hassle
<wasabi> Well, the LVM idea sounds good. Do a LVM snapshot + xfs_repair once a day... if xfs_repair finds ANYTHING, copy new files off and revert.
<HrdwrBoB> well, a snapshot isn't going to be clean unless you unmount, snapshot, remount
<wasabi> Yeah. That's fine, for my big data drive.
<wasabi> All movies.
<wasabi> Hmm. THere are files left.
<HrdwrBoB> try playing them, they will be jumpy and corrupted
<wasabi> So... any suggestions on a better / fs? Guess I could just go back to ext3 like everybody else.
<HrdwrBoB> I use XFS still on my large array
<HrdwrBoB> however I just use ext3 on most things
<HrdwrBoB> it Just Works
<wasabi> Well, since I'm reformatting, I mine as well install a 64 bit OS this time.
<Hobbsee> Kamion: ping?
<RnB-Tunes> http://www.RnB-Tunes.dl.am << new RnB, Hip Hop, Dancehall Tracks!!! free Download... CHECK IT!!!!
* mode/#ubuntu-devel [+o Hobbsee]  by ChanServ
* mode/#ubuntu-devel [+b *!*@p54982F75.dip0.t-ipconnect.de]  by Hobbsee
* RnB-Tunes was kicked off #ubuntu-devel by Hobbsee (Hobbsee)
* mode/#ubuntu-devel [-o Hobbsee]  by ChanServ
<mneptok> shake 'em on down!
<fabbione> morning guys
* mneptok farts
<mneptok> hey sexy.
<Hobbsee> hi fabbione 
<fabbione> hi Hobbsee 
<Kagou> good morning
<zyga> morning
<Mithrandir> Riddell: there seems to be some qt4 uninstallability issues in the kubuntu world today, but they don't seem to affect -desktop installability.  Just a heads-up.
<pitti> Good morning
<Burgundavia> morning pitti, marilize
<mneptok> Burgundavia: encountered your name earlier when looking through open GNOME Foundation tickets :)
* marilize hugs pitti and Burgundavia
<Burgundavia> mneptok: cool. If you process it quickly I will buy you alcohol in Boston
<HiddenWolf> pitti: wasn't bug-buddy supposed to be disabled by apport?
<mneptok> Burgundavia: i'm not on the Membership Committee
<mneptok> (sorry)
<pitti> HiddenWolf: no, until we have proper debug symbols, seb128 wants b-b to be enabled by default
<Burgundavia> mneptok: oh, too bad
* pitti hugs marilize and Burgundavia, good morning!
<Kagou> good morning
<Burgundavia> pitti: can apport back into bug-buddy by default? It seems insane to me to maintain a seperate UI
<HiddenWolf> pitti: ah. that bug that I asked about yesterday was bugbuddy then. :)
<pitti> Burgundavia: how do you mean?
<pitti> Burgundavia: in the long term we want apport only, but for that we need the possibility to produce good backtraces (to win something over b-b) and easy upstream bug forwarding
<Burgundavia> pitti: it me, carrying deltas from upstream is a little nuts, unless the work justifies it. Would it not be easier to modify bug-buddy and thus have less code of our own laying around?
<whiprush> as an aside, a ubuntu-dbg thing could be nice. I've had three things crash on me this week and I have no decent data to send back
<whiprush> er, maybe more an ubuntu-desktop-dbg
<Burgundavia> it seems that every distro builds it delta with upstream slowly, without a concerted effort to truly reduce it
* ..[topic/#ubuntu-devel:Mithrandir] : Ubuntu Development (not support, even with edgy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | 6.06.1 released | Main frozen for knot 3
* Burgundavia wanders off on his "each in their own silo" rant again
<Mithrandir> Burgundavia: (re /EdgyEft/Knot3): thanks; I didn't know it was a -marketing thing now; nobody told me. :-)
<Burgundavia> Mithrandir: no worries. Marketing didn't really exist last cycle and given that nixternal and myself did the Knot2 and we are active in both teams, it really didn't matter
<pitti> aah, hal 0.5.8
<Treenaks> pitti: what's so cool about it? :)
<pygi> morning all
<pitti> Treenaks: I didn't yet wade through the detailled changelog, since it's not for edgy anyway
<pitti> Treenaks: but it's nice that there finally is a new stable release
<freeflying|away> pitti: hi
<pitti> hi freeflying|away 
* mneptok is being kept awake by caffiene and X playing *really* loud
<Burgundavia> pitti: PolicyKit, crack or not?
<mneptok> "when he was waking up beside the bed he found clumps of hair. the last paulene wouldn't cooperate. she wasn't what you'd call living, really. but she was still awake. johnny hit and run paulene!"
<pitti> Burgundavia: optional in this release
<Treenaks> mneptok: do we want to know what kind of stories you're reading?
<dholbach> good morning
<Burgundavia> pitti:  and +1?
<Burgundavia> morning dholbach
<dholbach> hi Burgundavia
<mneptok> Treenaks: listening to seminal American punk band X
<pygi_> morning dholbach 
<pitti> Burgundavia: +1 to what?
<freeflying|away> pitti: I'm trying reproduce the bug you mentioned
<dholbach> hi pygi_
<Burgundavia> pitti: sorry, edgy+1, what are the plans?
<pitti> Burgundavia: oh, no concrete plans so far, but I guess we'll need PolicyKit anyway for gnome-system-tools
<pitti> Burgundavia: so, I'll take a look at it
<Burgundavia> right
<Burgundavia> pitti: ok, just wondering
<pitti> right now the g-s-t implementation is less than ideal
<Kamion> Hobbsee: yes?
<Hobbsee> Kamion: why are you requiring people from ubuntu-dev to approve sync requests, when the package was last synced from unstable anyway?
<Hobbsee> Kamion: ie, there are no ubuntu changes, due to the version number?
<Kamion> Hobbsee: syncs aren't always harmless - I'd like somebody to check for major compatibility problems, etc.
<Kamion> even if there are no Ubuntu changes to discard
<Hobbsee> oh, and i'm seeing why you're requiring lists of changes - i've seen some very crazy stuff try to be put through.
<Hobbsee> Kamion: right, okay
<Kamion> Hobbsee: sometimes I do the check myself and don't bother asking, if it's trivial and I'm not too overworked
* Hobbsee dies.
<Hobbsee> Kamion: yeah, fair enough
<Kamion> dies?
<Kamion> playing nethack? :)
<Hobbsee> who's Matthew Revell  on irc?
<Hobbsee> Hi Sarah,
<Hobbsee> Any chance I could interview you, for the Fridge, about your new Kubuntu role? 
<Hobbsee> i just read my email :P
<imbrandon> Hobbsee, he is mattrevelle ( in #ubuntu-fridge and of LR fame ;P )
<Hobbsee> imbrandon: ahh right...
<Hobbsee> imbrandon: i think i finished building on your machine for a little bit :P
<imbrandon> heh
<imbrandon> i've still got it chugging away ;)
<Hobbsee> imbrandon: if you dont want me to build on your machine, it would be nice if you'd warn me when, and for how long, you know :P
<Hobbsee> imbrandon: rather than just having a go at me in -motu
<imbrandon> hahaha okies ;)
<imbrandon> was no big deal, i was realy just teasin you, sorry if you dident take it that way ;)
<imbrandon> Hobbsee, ^^
<Hobbsee> ok
<infinity> Kamion: A give-back of d-i failed the same way, BTW.  Something sketchy in udeb publishing or something?
<Mithrandir> Kamion: console-setup still asks questions for me.
<Mithrandir> Kamion: do you want a DEBCONF_DEBUG=developer trace?
<Kamion> Mithrandir: yes please.
<Kamion> infinity: hmm, will investigate, thanks
<Mithrandir> Kamion, added info to https://launchpad.net/distros/ubuntu/+source/console-setup/+bug/59883
<Ubugtu> Malone bug 59883 in console-setup "Asks questions on installation" [Medium,Confirmed]  
<Kamion> Mithrandir: what I want to know is how come console-setup/layout isn't seen
<Kamion> Mithrandir: as in, isn't already marked as seen
<Kamion> since you obviously have /etc/default/console-setup there already
<Kamion> Mithrandir: ... oh. I see the problem. There are some places where we bypass the layout question but don't mark it as seen ...
<Kamion> ok, I'll sort this out later
<Mithrandir> ok
<Mithrandir> I'll keep the system "broken" for now so we can try reproducing with a later version
<Mithrandir> this is post-knot material anyway
<doko> good morning
<Kamion> infinity: could you check whether libconsole is already installed in those chroots, please?
<Kamion> infinity: (re debian-installer build)
<Kamion> infinity: and if not, why not? :) it's in base ...
<Mithrandir> Kamion: is this d-i build something we'd want for knot, by any chance?
<Kamion> Mithrandir: considering bug 59938, yes
<Ubugtu> Malone bug 59938 in debian-installer "edgy alternate installer: No kernel modules were found" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59938
<Kamion> the word "mandatory" comes to mind
<Mithrandir> Kamion: indeed.
<Mithrandir> just alternate, or do you need live too?
<Kamion> it builds fine in my debootstrap+build-essential chroot ...
<fabbione> Mithrandir: when is knot-3 planned?
<Kamion> Mithrandir: d-i doesn't block the live CDs, if that's what you mean
<Mithrandir> fabbione: Thursday
<fabbione> Mithrandir: ok thanks.
* fabbione goes to buy some empty CD's
<fabbione> actually
<fabbione> i also need to rsync edgy images
<xav> what was the md bug someone mentionned yesterday ?
<pitti> hey sabdfl 
<mneptok> sabdfl: http://www.cnn.com/TECH/
<pygi> pitti, you have a sec for me'
<pygi> ?
<pitti> pygi: hi; sure
<pygi> pitti, any chance libburn, libisofs, and cdrskin can be packaged & put into universe before the freeze if we release them on September, 26?
<pitti> pygi: yes, if packaging doesn't take too long
<pitti> pygi: universe freeze is Sept 28
<pygi> pitti, well, I know :P Release was supposed to be on October, 1 but I moved it 'cause of the freeze
<shenki> mneptok: "...local language versions would curry favor with the government."
<pygi> pitti, I'd really like that we get it in edgy
<mneptok> mmmm .... curry
<pitti> pygi: that would indeed be nice
<pygi> pitti, so we can promote it to main in edgy+1 or +2 at least ^_^
<carlos> Riddell: hi, around?
<Hobbsee> carlos: havent seen him around yet today
<carlos> Hobbsee: ok, thanks
<mneptok> uhhh
* mneptok blinks at a very odd support ticket
<fschoep> Mithrandir: ping
<Mithrandir> fschoep: pong
<fschoep> OK, good morning
<fschoep> Where's the Knot3 freeze at?
<Mithrandir> ?
<pitti> carlos: is there any chance of searching for a particular msgid in Rosetta?
<pitti> carlos: gnome-applets has 985 strings, and I just need to fix one particular string
<fschoep> Mithrandir: I thought you were coordinating the "freeze" of packages for Knot 3?
<Mithrandir> fschoep: yes, but a "where" question doesn't make any kind of sense.
<fschoep> Mithrandir: I meant to ask what the current status was - "where it's at"
<fschoep> Mithrandir: sorry for the confusion
<carlos> pitti: not yet, we are going to implement such feature
<carlos> pitti: danilos will work on it
<Mithrandir> fschoep: we're frozen and I at least am testing the live images.  You're welcome to help out.
<pitti> carlos: or any way to display more than 10 strings?
<Mithrandir> Riddell: you might want to start testing the kubuntu desktop images.
<Mithrandir> ogra: you might want to start testing too
<carlos> pitti: change batch=SIZE_YOU_WANT
<fschoep> Mithrandir: OK, I see - testing like in downloading and running the CD?
<carlos> pitti: but I should warn you that if you put there an high number, launchpad/rosetta will give you a timeout
<Mithrandir> fschoep: yes.
<fschoep> I can do that
<fschoep> The link is probably somewhere obvious, right?
<pitti> carlos: thanks, batch=100 seems to work fine
<Mithrandir> fschoep: cdimage.ubuntu.com/daily-live/current
<fschoep> I see, thanks - I'll give it a spin
<carlos> pitti: you are welcome
<carlos> pitti: another thing to do that is download a .po file and look for the string there
<pitti> carlos: I did, but how does that help me?
<pitti> carlos: you mean fixing the .po and uploading it?
<carlos> you can find the msgid that way and later, yes, you can upload it fixed
<carlos> is the easier workaround for that use case until the search feature is implemented
<ogra> Mithrandir, later this evening, i have to help with a move and need to prepare stuff for my travel ...
<Mithrandir> ogra: ok.
<ogra> but i have made up a testing plan for the community, hopefully someone uses it :)
<ogra> ciao ...
<Mithrandir> Gloubiboulga: you might want to get Xubuntu testing started.  Note that we need a new alternate cd first, so just live for now.
<Mithrandir> Kamion: how's the d-i bugfix coming along?
<Mithrandir> dholbach: gnome-settings-daemon fails to start on the live cd because of a timeout.  I've discussed this before with Seb and I think we need to increase the timeout.
<dholbach> Mithrandir: I need to take a look at it - I'm not aware of the problem yet.
<Kamion> Mithrandir: need that information from infinity, really :(
<Kamion> but looks like he's gone to bed
<dholbach> Mithrandir: which kind of timeout was that? or do you have any stray bits of info that help me looking for the failure?
<Kamion> oh, hmm, maybe it's a console-tools-udeb packaging bug
<Mithrandir> dholbach: I don't have the exact message here, but it's an error which happens when gnome-settings-daemon uses too long to start.
<Kamion> Mithrandir: ok, I understand the problem, working on it
<Mithrandir> dholbach: actually, the problem is probably that gnome uses dbus to activate g-s-d and dbus takes too long.
<Riddell> carlos: you pinged?
<carlos> Riddell: hi, yes
<carlos> Riddell: https://launchpad.net/bugs/60049
<Ubugtu> Malone bug 60049 in kde-i18n "Import of translations for KDE's desktop-* failed" [Untriaged,Unconfirmed]  
<carlos> Riddell: seems like upstream doesn't include the .po files with the .desktop translations because they release the .desktop files including such translations
<carlos> Riddell: so Rosetta has 0 translations for them while upstream has most of them full translated.
<Riddell> hmm, tricky part is how to include the desktop-*.po files in an upload
<carlos> Riddell: either as new packages or merging two tarballs....
<carlos> Riddell: would that be too difficult?
<carlos> noting the version as the snapshot date
<Riddell> carlos: not too difficult, I just have to think of the best way to do it
<carlos> Riddell: ok
<carlos> thanks
<Riddell> carlos: it'll be after knot 3 anyway
<carlos> knot 3 ?
<Riddell> carlos: testing CD we'll be releasing now
<carlos> ok
<carlos> Riddell: thanks
<Riddell> nowish
<Mithrandir> grr.
<Mithrandir> the launchpad-integration stuff is broken with a new-ish casper.
<Mithrandir> hmm, this is icky.  /proc/$pid/exe points to /casper/filesystem.squashfs/$whatever rather than $whatever.
<Riddell> Mithrandir: would you allow in some updates to ubiquity to get the kd frontend synced with the gtk frontend
<Mithrandir> Riddell: Can you run the diffs by Colin, as he knows the code better than I do?
<Mithrandir> Riddell: if he's happy with them, I'm ok with them too.
<Riddell> Kamion: please look at the branch at http://kubuntu.org/~jriddell/bzr/ubiquity/ubuntu/ and merge/upload if you think it's ok
<Kamion> ok, will do
* Mithrandir looks at pitti and points to the topic and u-d-a.
<dholbach> Mithrandir: I just booted into i386 live cd, no gnome-control-center breakage
<Mithrandir> dholbach: depends on the speed of your CD ROM.
<dholbach> hmhmmhhm
<Kamion> Riddell: I still think you should remove the distro logo entirely; ubiquity's policy is to not require branding
<Kamion> Riddell: anyway, I'm moving it to kde-distro-logo.png, since it's specific to the KDE frontend
<Kamion> the rest looks fine, thanks; merged
<Kamion> Mithrandir: there's also a change in my ubiquity branch to remove /etc/popularity-contest.conf and reconfigure popularity-contest after copying, so that everyone doesn't end up with the same popcon UUID; are you OK with that?
<Mithrandir> Kamion: sounds sane.
<Mithrandir> Kamion: (cleared for upload)
<Kamion> I haven't had time to test it yet, so if you want to review the code, feel free
<Mithrandir> the diff is in your branch?
<Kamion> but it's pretty simple and I stuck try/except around it to try to reduce the likelihood of breakage
<Kamion> Mithrandir: yes, r1539
<Mithrandir> I guess that means we'll need new livefs-es. :-/
<Mithrandir> Kamion: remind me of the URL again?  I seem to have cleaned my ~ a bit aggressively and it's not referred to in the source package
<Kamion> Mithrandir: sure is, in debian/copyright
<Kamion> Mithrandir: http://people.ubuntu.com/~cjwatson/bzr/ubiquity/ubuntu/
<Mithrandir> Format <RepositoryFormat6> for http://people.ubuntu.com/~cjwatson/bzr/casper/ubiquity/.bzr/ is deprecated - please use 'bzr upgrade' to get better performance
<Mithrandir> JFYI
<Mithrandir> uh
<Mithrandir> that was casper, so much for reading urls
<fabbione> ROFL
<Mithrandir> Kamion: and the reconfiguration bit doesn't fall over if popcon isn't installed?
<Kamion> Mithrandir: correct - chrex just returns false
<Mithrandir> Kamion: ok, I'm fine with you uploading that, then
<Kamion> Mithrandir: also fixing #60045
<Mithrandir> bug 60045
<Ubugtu> Malone bug 60045 in ubiquity "Installer crashed for Kubutu, daily 11.09.2006" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/60045
<Mithrandir> Kamion: sounds good
<shawarma> Is MoM still running?
<Kamion> Mithrandir: one mistake neither of us caught - /etc/popularity-contest.conf -> /target/etc/popularity-contest.conf :-)
<Mithrandir> true
<Kamion> Mithrandir: ok, all source should be uploaded now; we'll see if debian-installer builds this time round
* Mithrandir crosses fingers
<pitti> infinity: ping
<Lathiat> http://releases.ubuntu.com/ubuntu-server/ still says Release Candidate for dapper
<imbrandon> yup and it seems 6.10 and 6.10.1 are missing from the dir listing ;)
<jdub> how's nm on iw3945?
<Kamion> Lathiat: updated; how's that
<Kamion> ?
<Kamion> imbrandon: there is no 6.10.1 (yet)
<Kamion> nor is there a 6.10 yet of course but at least we know what that will be :)
<pitti> Mithrandir: ok to upload a new pkgbinarymangler with two small bug fixes? (not stripping backports and manpage updates)
<Mithrandir> pitti: any reason you can't hold it off until knot 3 is out?
<fabbione> who is the initramfs god as of today?
<Lathiat> Kamion: better cheers :)
<imbrandon> err 6.06.1 Kamion, typo ;)
<Lathiat> 'and newer'
<Kamion> Lathiat: yes, I don't want to have to remember it later
<Kamion> Lathiat: besides, 6.06.1 is newer than 6.06
<Lathiat> Kamion: that was my point :)
<Fujitsu> jdub, it's very similar to ipw2200, which works fine..
<mjg59> jdub: Fine
<pitti> Mithrandir: no particular one, just to not forget about it
<mneptok> jdub: Works For Me(tm)
<Mithrandir> pitti: we should have a delayed queue. :-P
<rodarvus> jdub, I use nm on ipw3945 on a daily basis
<rodarvus> works great, as mjg59 mentioned
<jdub> thanks dudes
<pitti> infinity: FYI, I locally modified pkgbinarymangler, pending upload until after knot freeze
<rodarvus> Kamion, do you think it will be possible to get xserver-xorg-video-amd, xserver-xorg-input-vmmouse and xserver-xorg-video-unichrome out of NEW in time for knot 3? (I'd like to ask people to test -unichrome soon)
<Kamion> rodarvus: oh, hmm
<Kamion> Mithrandir: ?
<rodarvus> they can be accepted into universe - would that affect knot 3?
<rodarvus> -amd and -vmmouse is more for completeness sake (since they became available recently)
<jdub> hrm!
<rodarvus> -unichrome is an alternate driver for via boards - which in theory works a lot better for various via boards
<jdub> so if i have auto eth1 auto eth0 in /e/n/i
<jdub> bootup takes ages
<jdub> but if i don't, nm won't own them
<Kamion> rodarvus: sure, I can dump them in universe
<rodarvus> Kamion, nice, thanks!
<jdong> jdub: really? nm owns my cards just fine without them
<jdub> what's an example stanza from your /e/n/i ?
<jdong> jdong@jdong-laptop:/tmp$ cat /etc/network/interfaces 
<jdong> auto lo
<jdong> iface lo inet loopback
<jdong> :)
<jdub> not lo...
<jdong> that's it
<jdong> that's the whole file
<jdub> oh right
<jdong> I have eth0 (wired) and eth1 (wireless)
<jdub> i can just remove them entirely
<jdub> righto
<jdong> yep
<jdub> good point - thanks!
<jdong> no prob
<Kamion> rodarvus: source accepted, will do binaries later if Keybuk doesn't beat me to it
<Kamion> Mithrandir: can I accept these language pack updates in NEW?
<jdong> oh, that is freaking sweet... vmware mouse driver :)
* jdong hugs rodarvus :)
<rodarvus> Kamion, thanks again!
<rodarvus> jdong, don't forget to tell us if the driver works fine ;)
<jdong> rodarvus: trust me -- I complain pretty loudly when something doesn't work ;)
<jdong> ask everyone here :P
<Hobbsee> heh
* Hobbsee stays quiet
* jdong puts vmware-server back on his edgy box
<Mithrandir> Kamion: yeah, sure
<Kamion> oh, damn, forgot to use the no-mails option
<Kamion> oh well, some more junk for everyone on -changes
<Mithrandir> Kamion: also, accepting the vmware stuff into universe is totally unproblematic
<Kamion> oh, I just thought of something
<Kamion> we'd better include the new Ubuntu usplash, hadn't we ...
<marseillai> hi
<Hobbsee> Kamion: nah....that'd be overrated.
<marseillai> is there a replacement to alsaconf ? i can't find it and i need it to configure my sound card to mke it use my new 5.1 system
<Kamion> edubuntu-artwork-usplash - edubuntu artwork for usplash
<Kamion> kubuntu-artwork-usplash - kubuntu artwork for usplash
<Kamion> usplash-theme-ubuntu - Usplash theme for Ubuntu
<Kamion> xubuntu-artwork-usplash - Xubuntu usplash image
* Kamion sighs at the inconsistency
<Hobbsee> pathetic.  change the ubuntu one?
<jdong> Hobbsee: lol, yep, ubuntu's fault :)
<Hobbsee> jdong: definetly, they're such rebels!
* Hobbsee pets kubuntu :P
<mneptok> it could be that there is a failure to follow the example ;)
* Kamion blames Seveas
<Kamion> (his package)
<Hobbsee> Kamion: so it's time to blame Seveas this week?  oh good!
<Seveas> blame the artwork people
<Seveas> they shoved the task to me around 4 hours before their deadline
<Seveas> when I was supposed to be out
<Kamion> Mithrandir: I'm going to need to upload ubuntu-meta, I'm afraid
<mneptok> can't i blame an international zionist conspiracy?
<mneptok> or maybe freemasonry?
<Kamion> Seveas: nod
<mneptok> i know! UFOs!
<Hobbsee> mneptok: that can be worth the next 3 weeks of blame.
* mneptok sends /. "Ubuntu Artwork Steganography Reveals ET Invasion Plot"
<fabbione> Kamion: if you upload ubuntu-meta, could you please make sure that we use sysvinit for sparc?
<fabbione> Kamion: upstart is somewhat broken
<jdub> ah, steganography - that explains why the new gdm theme has to be so ugly :-)
<pygi> jdub, lol
<Seveas> jdub, usplash theme is worse ;)
<Fujitsu> The new GDM theme isn't bad.
<Kamion> fabbione: uh, ubuntu-meta is an automatic update from the seeds. I'm not going to hack it by hand.
<Kamion> fabbione: if you want the seeds changed, you know where they are
<fabbione> Kamion: ok. i was hoping in a last minute hack :)
<fabbione> Kamion: no big deal
<fabbione> hopefully Keybuk can fix upstart
<Kamion> does that mean you are going to change the seeds, or you aren't?
<fabbione> no i am not.. go ahead
<Kamion> oh, actually, it's a no-go anyway
<Kamion> we don't have per-package priorities in the archive
<Kamion> so I can't make it use sysvinit on one architecture and upstart on another, sorry
<fabbione> ok
<fabbione> i guess Scott will need to fix upstart soon
<elmo> Kamion: erm, what?
<elmo> Kamion: do you mean per-architecture?
<Kamion> elmo: er, sorry, yes :-)
<elmo> ah, right
<Riddell> Mithrandir: we have three packages to upload for kubuntu then we're ready for knot 3.  artwork fixes in kdelibs and kubuntu-default-settings, and bug fixes in kdebase
<Kamion> Seveas: the usplash-theme-ubuntu progress bar seems wonky, BTW; it seems to be filling up in pixel rows left-to-right and then top-to-bottom
<Kamion> (that's the best description I can find)
<Kamion> this is on powerpc, so it could be specific to that architecture, but everything else on powerpc is now working
<Seveas> Kamion, works fine on x86
<Kamion> might well be brokenness in the bogl backend then
<Kamion> I'll try to investigate
<Seveas> the edubuntu one is wonky, I'm almost sure that there's a palette mismatch between background an progressbar 
<Seveas> (didn't look at the code yet, but have seen the symptoms too often :))
<Kamion> Seveas: there doesn't seem to be any correction for bytesperpixel in usplash_put or usplash_put_part in the svga driver. Isn't that a bug?
<Seveas> no
<Kamion> why not?
<Kamion> not all the SVGA modes usplash uses are one-byte-per-pixel
<Seveas> the palette is initialized earlier on 
<Kamion> but you're doing a memcpy ...
<Kamion>         memcpy(part + i * width, start + i * pixmap->width, width);
<Kamion> surely that needs to take into account that the data is longer if bytesperpixel != 1
<Kamion> compare __svgalib_driver16_getbox which does:
<Kamion>         __memcpy(bp, vp, w * 2);
<Seveas> hmmmm
* Seveas reads more svgalib docs
<Kamion> see also vga_putbox(3)
<Kamion>        Pixmaps are in row-major order. The source pixmap memory has the size w * h * BYTESPERPIXEL.
<mjg59> Kamion: None of the svga modes usplash uses will be /more/ than one byte-per-pixel
<Kamion> mjg59: that's not true
<Kamion> I checked
<mjg59> Uh.
<Kamion>         { 1152, 864, 39 },
<Mithrandir> Kamion: ubuntu-meta> ok, nothing big I hope?
<mjg59> It's got a hard-coded list of modes it'll set, all of which are 256 colours
<Kamion>         { 1600, 1200, 45 },
<Kamion> those two are 2 bytes per pixel
<mjg59> Oh, are they?
<mjg59> Sounds like my error
<mjg59> Sorry about that
<Mithrandir> Riddell: feel free; it just touches Kubuntu so I'm fine with you just doing it yourself.
<Riddell> Mithrandir: thanks
<pygi> sivang, poke? :)
<Kamion> er, unless I'm miscounting, one moment
<Hobbsee> Mithrandir: is that the rationale of "if we kill our own cd's, it's our fault?"
<mjg59> Kamion: Hm. 45 is a 256 colour format.
<Mithrandir> Hobbsee: "if you break the kubuntu cds, you get to keep both halves", yes.
<mjg59> So is 39
<mjg59> (see /usr/include/vga.h)
<Hobbsee> Mithrandir: hehe.  right
<Kamion> mjg59: oh, sorry, I just can't count evidently
<Kamion> yes, you're right. I could have sworn I'd double-checked that
<mjg59> Ok, that makes me feel better :)
<mjg59> That was a deliberate decision - vesa slows down once you get above 256 colours
<Kamion> yeah
<Kamion> I do think this is where the error is in the bogl backend, though
<mjg59> Right, the mode that OF gives you may well not be single byte per pixel
<Kamion> the pcfb and tcfb backends are both int-per-pixel, I think
<mjg59> Having thought about it, it may well be necessary to include the bogl backend in the x86 version anyway
<mjg59> Otherwise people using framebuffers lose
<Kamion> in fact I think all of them are int-per-pixel
<mjg59> Since we forcibly switch back to VGA text mode in the svgalib backend
<Kamion> Mithrandir: adding usplash-theme-ubuntu
<Mithrandir> Kamion: sounds trivial enough, so please do just go ahead
<jdub> mjg59: transitions in current startup are a bit rough
<Kamion> done
<Mithrandir> mjg59: do you have an usplash that works on amd64 (or a plan on how to fix it) yet?
<mjg59> Mithrandir: It works on amd64. It doesn't work on nvidia hardware on amd64.
<mjg59> It's actually an x86emu backend issue rather than an amd64 one
<mjg59> jdub: We need to forcibly set the screen back to text mode, otherwise X get horribly confused when you switch back to console VTs
<mjg59> Given current X, I'm afraid that's unavoidable
<mjg59> Mithrandir: I'm at something of a loss as to what the problem is. Any help there greatly appreciated.
<Mithrandir> mjg59: hmm.  Do you have a useful point to start debugging?
<mjg59> Mithrandir: Nope.
<mjg59> You can duplicate the failure using vbetool
<mjg59> The vbestate calls fail on nvidia kit
<Kamion> oh, no, bogl isn't int-per-pixel after all, I'm just on crack. I wonder what's really going on, then
<Mithrandir> mjg59: vbetool vbestate save made my second monitor unhappy, too. :-/
<mvo_> Mithrandir: would it be possible to do a update-manager upload? or is knot too deeply frozen already? it contains a bunch of fixes/smallish UI improvments
<Mithrandir> mvo_: I'd rather not if it's only small things.
<mvo_> Mithrandir: ok
<Kamion> mjg59: gotcha - it was just wrong width and height being set in the bogl_pixmap
<mjg59> Kamion: Ah
<mjg59> Excellent
<Kamion> Mithrandir: can I upload sftp://bazaar.launchpad.net/~ubuntu-core-dev/usplash/ubuntu/ ? fixes incorrect progress bar display on powerpc
<bluefoxicy> by the by
<bluefoxicy> should I not be using e-mail to put comments on bugs?
<mjg59> Why not?
<Kamion> no, it's fine, just attachments don't work that way
<bluefoxicy> it's not that
<bluefoxicy> my comments are like
<bluefoxicy> --- BEGIN PGP SIGNED MESSAGE ---
<bluefoxicy> a*##
<bluefoxicy> Hello.  Yes this works
<bluefoxicy> -- BEGIN 50 lines of SIGNATURE --
<mjg59> So don't send signed messages
<Mithrandir> Kamion: ok.
<Kamion> you don't need to sign random comments - only if you're sending control messages
<Kamion> AFAIK
<bluefoxicy> yeah, I figured that malone would strip the signature
<Kamion> and in any case, the fact that that isn't stripped for display on the web is a launchpad bug
<mjg59> Ideally it would strip them, but there's little point in validating it
<Mithrandir> Kamion: I'm off for a bit, so please just use your judgement (or call me if you're indecisive) for a bit.
<Kamion> https://launchpad.net/distros/ubuntu/+source/debian-installer/20060711ubuntu10 woo
<Kamion> Mithrandir: ok
<bluefoxicy> also
<Kamion> Mithrandir: oh, what's the CD build status? do you want me to do anything there?
<bluefoxicy> mm.
<bluefoxicy> I never filed bugs on packages demanding x86-64 libs on x86
<SEJeff> Keybuk is working on upstart, correct?
<bluefoxicy> QUESTION:  How hard is it going to be to make an argument to remove things like libc6-amd64 from i386 ubuntu?
<bluefoxicy> hm.  This is odd.
<bluefoxicy> they'll remove clean, how did they get installed in the first place then
<SEJeff> bluefoxicy: check your spec RapidReboot, I'm looking to work on implementing it with some guidance from the upstart team
<SEJeff> SEJeff == Jeff Schroeder
<fabbione> SEJeff: yes, right.. he is upstart *
<SEJeff> BenC: ping
<BenC> SEJeff: pong
<bluefoxicy> SEJeff:  nice.  Are you going to do any of the "Quick Reboot" shutdown menu hacks?
<bluefoxicy> I favor having the icons change when you press shift myself; windows 9x did a fast reboot if you held shift and hit shutdown (it exited win.exe and reloaded it), but it didn't change the text to say "Fast Restart" when shift was held
<SEJeff> BenC: Being the kernel guru you are, you would likely know about kexec. Is it in a state for *possibly* implementing RapidReboot for edgy+1. If so, I would like to work with Keybuk on it and integrating it into upstart
<bddebian> Howdy folks
<bluefoxicy> easily discoverable and non-invasive
<SEJeff> bluefoxicy: Icons changing is against the HIG though
<bluefoxicy> ah, true.
<bluefoxicy> Text under the icons?
<BenC> SEJeff: it is there and enabled
<SEJeff> bluefoxicy: there was a rant on planet gnome recently by behdad about evolution and the excess number of buttons. It was brought up that changing buttons contextually is anti-HIG
<bluefoxicy> SEJeff:  the alternative is to pack yet another button onto the interface.  I would argue that having 6 buttons, 2 of which do about the same thing, is probably worse but possibly HIG-conformant
<SEJeff> BenC: I've been following the dev meetings and edgy pretty closely. How would I go about proposing RapidReboot for acceptance in edgy+1? I would like to do it
<bluefoxicy> SEJeff:  (well, the other alternative is to not allow the user to manually initiate a fast reboot)
<SEJeff> bluefoxicy: I agree with you entirely. Maybe just have the quick reboot implemented from the notification icons
<BenC> SEJeff: launchpad's spec system is what you need to look into
<BenC> SEJeff: that's where all new features are proposed
<SEJeff> BenC: https://features.launchpad.net/distros/ubuntu/+spec/rapid-reboot it is already there
<bluefoxicy> Edgy+1 isn't open yet so I don't think the spec system lets [mortals]  propose a spec for Edgy+1
<SEJeff> bluefoxicy: I realize this, but I would like to start planning seeing as how I want to try and work on it
<bluefoxicy> Yes I know :)
<SEJeff> bluefoxicy: RapidReboot would also compliment the teardown spec already implemented
<bluefoxicy> (there's a similar set of hacks for the LiveCD I want to try... which I'll go spec out now)
<bluefoxicy> teardown?
<SEJeff> https://wiki.ubuntu.com/Teardown
* bluefoxicy swats the Internet for being slow.
<bluefoxicy> ah, nice.
<dholbach> hum, how can I extract the core file part out of a apport report and feed it into gdb?
<BenC> http://www.watchguard.com/products/x2500.asp
<BenC> that's my new Ubuntu Edgy Server box :)
<bluefoxicy> SEJeff:  good luck on that.  I have to go to class soon, and then move the Nano/Pico-Tier stuff into the main design for my allocator, since I set feature freeze for friday (I will creep new features in every 3 days for the next 5 years ...)
<dholbach> BenC: What do you need 275+/300+ Mbps for - I thought your internet connection was dying all the time ;-P
<SEJeff> have fun
<bluefoxicy> SEJeff:  do you know when discussion on Edgy+1 Toolchain is going to happen?  I really want to be there.
<SEJeff> no
<janimo> bluefoxicy: I think that happened already in paris
<bluefoxicy> janimo:  oh damn.
<BenC> dholbach: Gives me room to upgrade to multi-T3 :P
<janimo> bluefoxicy: unless you mean a specific discussion that was planned these days
<bluefoxicy> There's a couple can't-miss optimizations that need to be done and one we-really-shouldn't-but-if-you-want-to-go-for-it
<dholbach> BenC: riiiiight :)
<bluefoxicy> janimo: eh.  I thought the tech board meetings or dev team meetings focused on this stuff some time nearing the release of Edgy
<janimo> bluefoxicy: the spec for a cycle is planned at the start of the one before it since the transition happens in the weeks after release, before the conference. So it needs to be discussed earlier
<bluefoxicy> janimo:  ah.  That means what, in english?
<janimo> bluefoxicy: I read that myself after sending and asked the same question :)
<bluefoxicy> haha
<janimo> the toolchain specification ofr a release happens one cycle earlier, as the transition from one toolchain to another can be thought of as part of the previous cycle.
<bluefoxicy> yes but when is it frozen
* bluefoxicy is going to have to crash the next developer's meeting at this rate
<bluefoxicy> <-- not a dev
<janimo> as soon as edgy opens (well one or two weeks after) the new toolchain needs to be uploaded os it can be tested as much as possible
<janimo> so it is discused months ahead, along with the specs affecting the just released version
<bluefoxicy> so the edgy+1 toolchain has been in testing since June?  o_O
<janimo> bluefoxicy: not in testing (I don;t know for sure) but settled on AFAIK
<tseng> planned is al
<tseng> all
<janimo> but there are people who know for sure (doko, jbailey)
<bluefoxicy> I noticed a while back that --hash-style wasn't on the spec so stuck it in :o
<bluefoxicy> was that a bad idea?
<bluefoxicy> (it's in the newer binutils since around June-July)
<janimo> I don;t know so I'll shut up instead of possibly misguiding you
<bluefoxicy> tseng:  who do I have to blow to find out what the buildd looks like?  I've had 5 different people tell me 5 different things about -Wl,-O1
<Kamion> bluefoxicy: infinity is the authority
<bluefoxicy> either Keybuk or Kamion said that it's only applied to GNOME packages, someone else said it was applied globally in LD_FLAGS, no one seems to really have solid documentation
<bluefoxicy> Kamion:  ah, then I'll stop bugging every random person :)
<Kamion> bluefoxicy: the buildd is not doing *anything* special to toolchain options
<Kamion> bluefoxicy: the only thing that's happening is that some packages apply options in their own build scripts. You can look for those yourself.
<slomo> bluefoxicy: most gnome packages use it, right... but it's done per-package in debian/rules
<Kamion> feel free to confirm that with infinity if you like
<bluefoxicy> Kamion:  yeah, I saw it was in some gnome debian/rules
<Kamion> bluefoxicy: with regard to editing specifications, please refrain from editing specifications that are already approved except to add comments in a separate section at the bottom
<bluefoxicy> Kamion, slomo:  There's some things worth doing globally, like --hash-style=both (approximately 50% speedup for dynamic linking, apps load faster)
<Kamion> bluefoxicy: anything we want to do globally should be in the gcc specs file; it shouldn't be done at the buildd level
<Kamion> you need to talk to the toolchain maintainers about that
<bluefoxicy> nods.
<bluefoxicy> that would be doko/infinity/who else?
<Kamion> primarily doko
<bluefoxicy> (meanwhile I'll move the stuff I put on the spec down into the comments)
<bluefoxicy> ah.. his schedule was what?
<bluefoxicy> is he gonna be here when i get back from school in about 4 hours?
<Kamion> I have no idea. You know where your mail client is :)
<bluefoxicy> nobody I e-mail here ever mails me back :)
<bluefoxicy> well, mdz does
<jdong> bluefoxicy: they get lots of e-mails... it's indeed hard to get ahold of them :)
<bluefoxicy> jdong:  easier to pester them on IRC ;)
<jdong> bluefoxicy: exactly :)
<bluefoxicy> grah.  I can only see the immediate prior revision on the wiki!
<mdz> dholbach: is 52405 actually fixed?
<hunger> How do i
<hunger> How do I work around the upstart problem with cryptdisks again?
<hunger> The last upgrade has again broken my boot process:-(
<jdong> hunger: doesn't look like keybuk's around :-/
<dholbach> mdz: I just deinstalled menu and menu-xdg and restarted - it's fine for me -- do you still have the problem?
<_ion> hunger: Add the line "console owner" to /etc/event.d/rcS
<tkamppeter> pitti, I have problems with the build of GutenPrint 5.0.0 final
<xav> dholbach: how is that a fix ? it's a workaround, there are many described
<dholbach> xav: I had menu installed previously as a workaround, now I *de*installed it again, restarted my session
<dholbach> xav: and I tested a live cd today which didn't expose the problem either
<xav> dholbach: oh ok then but
<dholbach> but?
<xav> dholbach: it's the package who got fixed, or the real bug ?
<dholbach> To be honest, I'm not quite sure which fix finally solved the problem.
<janimo> tkamppeter: is there a preferred way of storing default printer? ~/.cups/lpoptions vs /etc/cups/printers.conf
<dholbach> xav: do you still have the problem?
<xav> dholbach: problem with the packages is that there were a broken symlink
<dholbach> that I know
<xav> dholbach: I've no clue, I'm on edgy but didn't reinstall gnome
<janimo> tkamppeter: I see gnome-cups-manager uses the first the RH config UI the second
<xav> dholbach: is it still there?
<dholbach> xav: I didn't reinstall it either?
<pitti> tkamppeter: hi! (I just replied to your mail)
<dholbach> xav: I don't face the problem on any of my machines
<mdz> dholbach: I am subscribed to the bugs and saw someone mark it Fix released and claim it fixed, but I think it very much still exists
<dholbach> mdz: oh?
<tkamppeter> /etc/cups/printers.conf can only mark locally defined printers as default, whereas /etc/cups/lpoptions can also mark broadcasted printers from other machines as default.
<mdz> dholbach: as always, it only happens if there's a broken symlink, but we either need to fix the broken symlink (as a workaround) or fix the bug
<tkamppeter> ~/.cups/lpoptions is like /etc/cups/lpoptions, but a for personal settings of the user.
<dholbach> ok, I'll try to reproduce it...
<xav> so the broken symlink is still there?
<pitti> tkamppeter: ok, so far that's clear
<tkamppeter> janimo, printerdrake uses both.
<janimo> tkamppeter: so the latter is preferred then? Since both are used by CUPS is one of them supposed to obsolete the other or both can be used?
<xav> how did an upgrade manage to fix it?
<pitti> tkamppeter: I believe we use ~/.lpoptions by default (gnome-cups-mgr does that)
<pitti> tkamppeter: back in 15 minutes, I'm grabbing a bite
<dholbach> mdz: so you still have the problem on an up-to-date edgy?
<janimo> tkamppeter: what cat printers.conf do that cannot be done in lpoptions then?
<janimo> s/cat/can/
<mdz> dholbach: I did the last time I looked, and I have no reason to believe it's been fixed. do you?
<ivoks> tkamppeter: need a help?
<tkamppeter> Note that ~/.lpoptions or ~/cups/.lpoptions is personal to the user. A printer setup tool which sets up system-wide print queues should also set up a system-wide default printer.
<ivoks> tkamppeter: ~/.cups/lpoptions :)
<xav> dholbach: sorry, I may be a little slow but I still don't understand. do you have this file : /etc/xdg/menus/debian-menu.menu and is it a broken symlink?
<janimo> tkamppeter: I understand the user vs systemwide difference. BUt I wonder what is the diff between /etc/cups/lpoptions and /etc/cups/printers wrt default system wide printer setting
<tkamppeter> Note also that a default printer set in /etc/cups/lpoptions in a CUPS 1.1.x environment is not propagated into the network. With a CUPS 1.2.x network it is possible that it gets propagated, but I am not absolutely sure.
<dholbach> mdz, xav: I just made /etc/xdg/menus/debian-menu.menu a broken symlink and after restarting the panel behaves fine
<tkamppeter> So the advantage of /etc/cups/printers is that the default printer setting gets for sure propagated into the network. At least to clients which do not have their own default printer setting.
<mdz> dholbach: er
<mdz> dholbach: I fixed it ;-)
<tkamppeter> printers.conf and lpoptions are different
<dholbach> mdz: YOU ROCK! How? :-)
<mdz> dholbach: /usr/share/doc/menu-xdg/changelog.gz
<mdz> dholbach: I implemented the workaround I was just talking about, but I forgot about it
<xav> lol
* dholbach hugs mdz
<tkamppeter> printers.conf is configured by the lpadmin command by an admin and is always system-wide. It has no personal counterpart.
<dholbach> :-)
<tkamppeter> It defines print queues and the queue's properties. One queue can be marked as the default.
<mdz> dholbach: I forgot to update the bug with that information; I've done so now
<tkamppeter> The actually available queues can come from printers.conf, from classes.conf (printer classes, queues clustered together), or can be picked up from external CUPS server's broadcasts
<dholbach> mdz: I don't have that version of the package installed
<janimo> tkamppeter: so the default server can be set in both places with slightly different goals?
<janimo> default printer I mean
<tkamppeter> In printers.conf OR classes.conf NO or ONE local queue can be set as default queue.
<dholbach> mdz: and I just installed a broken symlink for gnome-panel/gnome-menus/gamin/whatever to stumble over ... so I'm a bit unsure
<tkamppeter> lpoptions is configured by the lpoptions command, if root runs the lpoptions command, /etc/cups/lpoptions is modified, if a normal user runs the lopoptions command, the file ~/.cups/lpoptions is modified.
<tkamppeter> janimo, the default printer, not the default server.
<jamadagni> hello is mithrandir here/
<janimo> tkamppeter: Still, which has priority, lpoptions or printers.conf as both can be set systen wide and contain a default printer
<tkamppeter> To get the best transparence for an admin using a printer setup tool I recommend that the tool sets the default printer in BOTH printers.conf/classes.conf (sudo lpadmin -d <queue>) AND /etc/cups/lpoptions (sudo lpoptions -d <queue>). If you set the default CUPS printer with "sudo foomatic-configure", it is done so.
<janimo> tkamppeter: but why are ther two places for the same setting?
<tkamppeter> if printers.conf/classes.conf and lpoptions has different default printers, lpoptions has priority.
<janimo> tkamppeter: ah,ok. thanks
<ivoks> tkamppeter: hm?
<tkamppeter> If a user has a personal lpoptions, this overrides any system-wide default.
<ivoks> tkamppeter: i had default in lpoptions and in printers.conf
<pitti> tkamppeter: I'm back now, btw; how can I help you with gutenprint?
<ivoks> tkamppeter: but default was from printers.conf
<pitti> tkamppeter: btw, you didn't get my /msg?
<janimo> tkamppeter: I knew it overrides lpoption from system wide but was not sure of printers,coinf as it's a separate file format and option 
<tkamppeter> pitti, I have now the Debian package, where all dpatches are flattened out into the general diff.gz file. So all info about their changes is definitely lost and a private secret of Roger Leigh (and I thought we work with free software)
<pitti> tkamppeter: right, that's what I answered in my mail
<pitti> tkamppeter: the short form: we don't need to care
<tkamppeter> But anyway, I can still re-add the Ubuntu patches with dpatch.
<pitti> tkamppeter: that would be appreciated, it makes merges a lot easier
<tkamppeter> I would at first make sure that dpatch.mk is in debian/rules, re-adding it if needed.
<pitti> tkamppeter: do we actually have relevant changes that still apply to 5.0-2?
<pitti> tkamppeter: right
<pitti> tkamppeter: ideally we could send the remaining diff to Debian and sync in the future
<pitti> tkamppeter: until then dpatch should do fine
<tkamppeter> Then I have seen that the Debian package still has the "model" hard-coded into the PPD path.
<pitti> tkamppeter: btw, we don't patch files in debian/ (they are modified directly)
<tkamppeter> So the build system still needs to be patched that we can add out /usr/share/ppd (and all other future standard paths of LSB 3.2).
<tkamppeter> Note that the debian diff.gz file does not only contains hunks in debian/ but 30 or 40 files also outside the debian, it seems that it is parts of our 10-.... patch mixed with other patches.
<pitti> tkamppeter: yeah
<pitti> tkamppeter: I wonder why Debian didn't adopt the /usr/share/ppd policy yet
<pitti> tkamppeter: it was discussed months ago and we implemented it pretty quickly
<tkamppeter> So I have loaded the Debian source with dpkg-source -x and then I have manually edited only the configure.ac file accordint to our 10-... patch. I did not modify anything else.
<tkamppeter> Then I typed autoreconf and it complained about missing m4local directory, mkdir'ed that and again autoreconf. then this:
<pitti> tkamppeter: if Debian already modified configure.ac in the diff.gz and called autoreconf (with those changes being inline as well), then it might be better to just do the same in Ubuntu and documetn it in the changelog
<pitti> tkamppeter: otherwise we would have two big patches, which doesn't make sense
<Kamion> mdz: FYI, kwwii is now sorted for using usplash on his system
<tkamppeter> aclocal: configure.ac: 382: macro `AM_PATH_GTK' not found in library
<tkamppeter> aclocal: configure.ac: 739: macro `AM_PATH_GTK' not found in library
<tkamppeter> aclocal: configure.ac: 743: macro `AM_PATH_GTK' not found in library
<tkamppeter> aclocal: configure.ac: 743: macro `AM_PATH_GLIB' not found in library
<tkamppeter> autoreconf: aclocal failed with exit status: 1
<pitti> tkamppeter: maybe dholbach can help you with that
<tkamppeter> But for this autoreconf has to run anyway, and I do not get it working.
<pitti> tkamppeter: I'd assume you are missing some gtk-dev package
<janimo> Kamion: can you take python-cups out of NEW or is it Keybuk's day? 
<dholbach> tkamppeter: which package did you try to autoreconf? gnome-cups-manager?
<Kamion> janimo: it's Keybuk's day, but I haven't seen him ...
<Kamion> janimo: is it destined for main?
<pitti> dholbach: gutenprint
<dholbach> ok
* dholbach looks
<tkamppeter> The error messages seem to be caused by missing libgtk1.3-dev, but I cannot install it as apt-get tells me it conflicts with libgtk2-dev
<pitti> argh, 1.3?
<pitti> *shudder*
<janimo> Kamion: it may be, I'd like to get it tested by some more people first though
<mjg59> libgtk1.3 was the development tree for libgtk2
<tkamppeter> and libgtk2-dev is also needed for this autoreconf
<mjg59> If anything depend son it, it's broken
<dholbach> tkamppeter:    sudo apt-get build-dep gutenprint     should have all you need
* dholbach downloads and tries as well
<tkamppeter> I am fighting with gutenprint
<tkamppeter> dholbach, I have done this, and for autoreconf I had even to install more packages
<tkamppeter> So do I need another libgtk1-dev?
<ivoks> umm...
<Kamion> janimo: python-cups doesn't seem to follow the new python policy; it should be using one of python-central or python-support, surely
<ivoks> didn't we disable gtk1 in our packages?
<pitti> ivoks: we must have, since gtk1 is in universe
<pitti> tkamppeter: no, that would be wrong
<tkamppeter> ivoks, seems so, as apt-get does not find a package named libgtk1-dev
<ivoks> pitti: debian/rules, debian/control.in: Drop libgtk1.2-dev build dependency
<janimo> Kamion: when I uploaded it I asked doko and he said it was not mandatory. Since then pyton 2.5 got in so this may have changed
<tkamppeter> Universe is activated in my /etc/apt/sources.list
<janimo> I guess I'll use one of those two options in the next upload then
<ivoks> tkamppeter: no main package can depend on universe package
<Kamion> janimo: not mandatory to use python-{central,support}, or not mandatory to follow the new python policy?
<pitti> tkamppeter: you might try libgtk1.2-dev
<janimo> Kamion: to use the two
<pitti> oops, gtk1.2 is still in main
<pitti> we couldn't throw it out, as it seems
<pitti> so, I lied, sorry
<Kamion> janimo: I guess it is possible to comply with the new python policy and not use python-{central,support}, but you'd need to use a number of workarounds, which you don't seem to be doing
<tkamppeter> all gutenprint binary packages do not depend on GTK1, nor the build process, but as Gutenprint has legacy support for GTK1, autoreconf for gutenprint needs GTK1.
<janimo> Kamion: as for policy with only python-2.4 as the supported version it looked ok. It may not be ok now with pyversions -s saying both 2.4 and 2,5
<janimo> I need ottest
<Kamion> janimo: from our perspective as archive admins, following the new python policy is definitely mandatory
<Kamion> janimo: yes, please; I'll reject it for now
<Kamion> the point of the new policy is to gracefully handle the move to python2.5 and later
<ivoks> we changed rules to not build against gtk1
<tkamppeter> Installing libgtk1.2-dev ...
<ivoks> no...
<ivoks> :)
<Kamion> janimo: http://wiki.debian.org/DebianPython/NewPolicy describes how to do it
<dholbach> ivoks: you seem to need to have libgtk1.2-dev installed to autoreconf -i
<tkamppeter> At least I get to another error now ...
<ivoks> this is in debian testing?
<janimo> Kamion: thanks, I'll reread that.
<dholbach> ivoks: because of the error that tkamppeter just quoted: AM_PATH_GTK, AM_PATH_GLIB - check configure.ac -> AM_PATH_GTK(1.2.0, ...
<dholbach> tkamppeter: with libgtk1.2-dev installed   ./autogen.sh  at least runs through for me again
<ivoks> hm
* pitti hugs dholbach 
* dholbach hugs pitti back
<ivoks> you are trying to build debian package.. or?
<ivoks> plain source?
<tkamppeter> Here are my autoreconf errors:
<tkamppeter> http://www.freestandards.org/~till/tmp/ubuntu/edge/gutenprint/autoreconf1.log
<dholbach> ivoks: it seems that tkamppeter needs to run  autoreconf -i  for a patch of his to apply
<dholbach> (if I didn't get the situation wrong=
<ivoks> (couse i can build debian package without libgtk1.2-dev)
<ivoks> ok
<tkamppeter> dholbach, autogen.sh runs also for me, it even runs configure afterwards, but try make after that. This fails for me.
<dholbach> urg
<pitti> tkamppeter: any chance to fix the PPD path without messing with autobreak tools?
<dholbach> I wonder how upstream rolled their release tarball then
<pitti> tkamppeter: a two-line patch in one file seems easier to handle than touching all the auto stuff
<tkamppeter> pitti, that is probably the only solution. Perhaps I should try things which I often did in Mandriva packaging, like
<pitti> tkamppeter: alternatively, if you just fix a path in configure.ac, just do the same change in configure
<pitti> and don't bother with autoreconf
<tkamppeter> perl -p -i -e 's:/usr/share/cups/model:/usr/share/ppd:g' * */* */*/*
<tkamppeter> or similar
<pitti> tkamppeter: yeah, that's what I mean :)
<pitti> tkamppeter: find -name '*.c' -o -name '*.h' | xargs sed -i 's/oldpath/newpath/g' or so
<pitti> and then check the diff
<tkamppeter> Perhaps it is enough to apply the perl command only to the configure script
<ivoks> find has an -exec :)
<pitti> ivoks: too clumsy for my taste, and xargs is more efficient in the general case :)
<pitti> </nerdiness>
<ivoks> well, pitti fwiw, i wouldn't use sed, but vim -c :)))
<tkamppeter> Perhaps I run the perl or whatever out of debian/rules and so I can avoid a patch
<pitti> tkamppeter: oh, please don't
<pitti> tkamppeter: if you do that, then you cannot build the source package after buliding the binary package any more
<pitti> tkamppeter: rather do it statically, that's more robust
<tkamppeter> So I better run the perl in my shell to generate a patch?
<pitti> tkamppeter: but putting the command in the changelog would be helpful
<pitti> tkamppeter: yes, as long as it's not too big (I doubt that it is big), doing the modifications in a dpatch is better
<tkamppeter> Yes, this is a good idea.
<mdz> dholbach: maybe it's not so easy to reproduce
<pitti> tkamppeter: it would surprise me if the path was hardcoded in more than handful of places
<dholbach> mdz: I'll try on other boxes
<tkamppeter> In my Mandriva RPMs I tried to avoid patches as much as possible. They contain a lot of perl magic
<pitti> tkamppeter: btw, /msg still doesn't work for you?
<ivoks> well, so long guys, i have exam tomorrow :/
<pitti> ivoks: /me crossing fingers, good luck!
<ivoks> thanks
<dholbach> tkamppeter: ./autogen.sh && autoreconf && make   builds it (not sure what your changes are, though)
<tkamppeter> autoreconf after autogen.sh fails for me, a "make" after that re-runs configure and fails then.
<tkamppeter> pitti, what do you mean with /msg
<pitti> tkamppeter: private conversation
<pitti> tkamppeter: try '/msg pitti ping'
<tkamppeter> pitti, I have seen that you have opened a private coversation now.
<Kamion> Am I going mad? Are file-scoped static variables trashed before registered atexit() handlers are called?
<o_cee> hrm, Compiz settings manager, why doesn't it apply changes? strange..
<Kamion> mjg59: valgrind is telling me very weird things about usplash
<Kamion> mjg59: it's saying that saved_vt is uninitialised when usplash_restore_console is called
<mjg59> Kamion: I can well believe it
<mjg59> Erm.
<Kamion> but it's static and initialised
<mjg59> Yes
<mjg59> What if you make it non-static?
<Kamion> I'm wondering if there's something very weird about static objects and atexit()
<mjg59> Could be
<Kamion> except this isn't even called from atexit(), so it's not that
<Kamion> no, that doesn't help
<Kamion> the reason I'm looking at this is that I'm working on a change to properly test the framebuffer mode before applying it, as you're supposed to
<Kamion> this pretty much necessitates saving the whole fb_var somewhere
<Kamion> and the fb_var is getting corrupted somewhere in the middle of proceedings, so I'm trying to figure out why
<zyga> hey
<zyga> mvo: ping, how is progress?
<mjg59> Kamion: Bear in mind that not all framebuffers will support modesetting
<mjg59> Kamion: If they don't, that shouldn't be a failure - we should just return the size that we do get back
* zyga praises recent update that stopped X crashes :)
<Kamion> mjg59: hmm, ok; shouldn't their FB_ACTIVATE_TEST mode then tweak the mode you supply to the closest thing it can manage?
<mjg59> Kamion: I'm not sure
<Kamion> (perhaps the current mode)
<mjg59> Kamion: But at some stage we need to feed the resolution back to usplash, and it needs to be the resolution we ended up getting rather than the one it requested
<Kamion> mjg59: right. the change I'm working on is getting much closer to that
<Kamion> although it isn't all the way there yet
<Mithrandir> Kamion: I've been waiting for your d-i and ubiquity fixes to get into the archive, so I haven't built livefs-es or anything.  Is everything you want in in now?
<Kamion> doing FB_ACTIVATE_TEST intrinsically involves accepting possibly a slightly different mode than the one you asked for
<Kamion> Mithrandir: yes, should be
<o_cee> oh my. xgl with cgwd is just.. wonderfully beautiful..
<Kamion> Mithrandir: oh, usplash 0.4-24 isn't there yet
<Mithrandir> Kamion: I'll twiddle my thumbs until the new usplash's there, then.
<Kamion> should be there RSN
<mjg59> Kamion: Ok. Once you've committed, I'll test it against vesafb
<Kamion> Mithrandir: it's in this publisher run
<Kamion> mjg59: might be a while, as I have no ideas currently about what might be trashing my saved copy of fb_var
<mjg59> Kamion: Ok
<mvo> zyga: hello! how was your exam? the data-extraction did run, I'm integrating them now
<zyga> mvo: bad, I failed --- again :/
<zyga> mvo: cool, how many ERRORs did you get?
<mvo> zyga: oh :( sorry for that :(
<zyga> mvo: bah, I was not prepared as usual
* mvo hugs zyga
* zyga is all right
<mvo> zyga: the new data is more better, I will do a upload of it (i386 only for now)
<zyga> I'm angry with myself but that'll pass
<zyga> why i386 only?
<mvo> zyga: I meant only the i386 db
<zyga> yeah, but why?
<mvo> the -universe databases are ~4Mb each
<mvo> so for a full upload it would be a 12mb source package. its not that bad, but it is not really needed either IMO
<zyga> so we'll assume that any-arch == i386?
<zyga> ah, the data needs to be in the source package
<zyga> how about taking the raw scan.log
<zyga> bzipping it away and making the build process do the rest?
<zyga> will that be smaller?
<mvo> and build the database on compile time? yeah, that should work
<zyga> mvo: how big is scan log?
<mvo> yeah, that sounds like the right solution
<mvo> the logfile is immense, the scan.data is ~5,5mb
<zyga> right
<mvo> zyga: scan.log: 220MB(!)
<zyga> the log file is irrelevant for the source package :)
<mvo> I know :)
<zyga> but uploading scan.data.bz2 will make it a good source package and a small one as well :)
<zyga> mvo: I'll grep my scan log at home :)
<shaya> does any suffer from a bug w/ "Loading Hardware Drivers...." where it just hangs?
<shaya> edgy of course
<shaya> pitti: btw, did I answer your quesiton about my vino patch?
<mvo> seb128: HAPPY BIRTHDAY
<seb128> hi
<seb128> mvo: thank you
<dholbach> seb128: BONNE ANNIVERSAIRE!
<seb128> Mithrandir: is main frozen, frozen?
* dholbach hugs seb128
* dholbach hugs seb128
* dholbach hugs seb128
<seb128> dholbach: "BON", anniversaire est masculin ;)
* mvo hugs seb128 seb128 seb128
* seb128 hugs mvo dholbach
<dholbach> seb128: ah ah :-)
<thom> happy birthday seb!
<seb128> thom: thank you
<Mithrandir> seb128: veeeeery cold, yes.
<Mithrandir> seb128: I was going to start building livefs-es and cds now; is there anything particular you need?
<mvo> zyga: please merge from http://people.ubuntu.com/~mvo/bzr/command-not-found/mvo  (only changelog updates for now)
<zyga> mvo: merging
<mvo> zyga: and add everything to the changelog that I forgot :)
<seb128> Mithrandir: I've a libgnomeui patch ready to upload
<xav> hey, mine was 3 days ago :p maybe all french are born in september
<seb128> Mithrandir: it fix the GTK fileselector hanging apps like rhythmbox or evince
<pitti> shaya: I didn't yet look at it, sorry
<Mithrandir> seb128: hmm.  Trivial patch?
<seb128> Mithrandir: http://cvs.gnome.org/viewcvs/libgnomeui/file-chooser/gtkfilesystemgnomevfs.c?r1=1.82&r2=1.83&makepatch=1&diff_format=u
<seb128> Mithrandir: pretty simple yep
<seb128> Mithrandir: and already commited to upstream stable branch
<zyga> mvo: looks great, thanks :)
<zyga> mvo: merged and pushed
<Mithrandir> seb128: ok, upload it then.
<seb128> Mithrandir: thank you
<zyga> mvo: I guess it's time to blog about it because it's quite good now :)
<MrFaber> hi all
<pitti> zul: do you have any clue about the failed breezy kernel?
<MrFaber> What is the most common reason for sporadic kernel syncing errors? What is more likely, hardware or software bug? The mem is ok according to mem check. I am useing Dapper with latest amd64 server kernel.
<simira> mvo: had a look on u-m when I got home just now (I was out when you asked). Right now, it just asked for my password, and then failed to start...
<zul> pitti: not yet..
<zul> ill get it fixed tonight though
<pitti> Mithrandir: ok to upload libxfont security update to edgy? It just got un-embargoed
<pitti> Mithrandir: I tested the package for over a day now, no visible regressions and straightforward patches
<Mithrandir> pitti: yes
<pitti> thanks, I'll upload now
<mvo> zyga: totally
<mvo> zyga: please merge again, I made the generation current-arch + "all" (by default)  now so that it can be integrated into the build process. once that is finished, we can upload (but I need to go and do some washing first now :)
<zyga> mvo: okay
<zyga> mvo: update-manager looks nicer with 'Updates of Ubuntu' banner on top :)
<Kamion> I hope that's not hardcoded branding?
<zyga> mvo: thanks, I could not do it without you :)
<zyga> Kamion: I don't know but I doubt it, probably a channel
<Kamion> seems unfortunate for Kubuntu, Edubuntu, and Xubuntu
<Kamion> since the channel will be "Ubuntu" for all three, probably?
<zyga> all three?
<zyga> ah
<zyga> hmm, I don't know
<zyga> but it's unfortunate :/
<zyga> mvo?
* zyga goes homre
<punkmexic> hello
<sivang> re
<seanh> Hi ubuntu-devel, I have ubuntu setup in a cafe and want something to automatically clean up files that users leave around, without touching my desktop shortcuts or the users config files. Was thinking of an rsync script. Any advice?
<Burgwork> seanh, are users allowed to save files?
<seanh> Well.... users can save files to the homedir to work on them, yes, but they shouldn't assume the files will be there when they come back next time
<Burgwork> how do they login?
<seanh> There is one 'public' user account that is shared by all visitors
<seanh> that account is set to automatically login
<seanh> it uses the Desktop user profile
<Burgwork> here is what I would do: create a sabayon profile, link the user to it
<seanh> I'm using Sabayon and Pessulus to prevent users from changing some things
<Burgwork> upon logout, wipe out the user, including their home dir, recreate on login
<seanh> What do you mean wipe out the user? Simply delete their homedir, or do I have to remove the username from the system somehow?
<Burgwork> no, you can just wipe the idr
<ivoks> right
<ivoks> and with PAM recreate
<seanh> And sabayon will recreate the homedir on each login?
<ivoks> PAM will
<seanh> PAM?
<Burgwork> ivoks, hmm, PAM, not thought of that
<ivoks> seanh: Plugable Authentication Module
<ivoks> seanh: you use it every time you login
<ivoks> seanh: it has a modul which can create user's home dir upon user login
<Kamion> pam_mkhomedir
<ivoks> seanh: very handy in LDAP installations, but would also work great in your situation
<ivoks> Kamion: right
<Burgwork> ivoks, for edgy+1, we would create a profile, etc, for this, so people can just install it
<ivoks> Burgwork: that would be fairly easy
<ivoks> Burgwork: but that should be part of the bigger master plan; ubuntu-caffe :)
<Burgwork> indeed
<seanh> How do I run a script on logout anyway?
<Burgwork> currently all the "session-clearing" kiosk cds use livecd, which suck
<ivoks> seanh: i have an idea
<ivoks> ups... better not via skel :)
<seanh> Okay folks, I just had an update go bad and need to leave X right now, sorry. Thanks for the advice though, will look into it
<ivoks> Burgwork: if you are interested, we could work on that
<Burgwork> can you create closed source PAM modules?
<_ion> I hope not. :-)
<ivoks> it's GPL
<Kamion> PAM itself is dual-licensed BSD/GPL
<Burgwork> right, so you can
<ivoks> right
<Kamion> Burgwork: not necessarily
<Lathiat> does pam link with any GPL stuff on a linux system?
<Kamion> Burgwork: bear in mind that applications distributed on the system might be GPLed
<Burgwork> such as gdm?
<Kamion> for example su contains GPLed code
<Kamion> yes, gdm is GPLed
<Burgwork> ok, licensing official sucks
<Kamion> ... if you're trying to produce closed-source software, sure
<Kamion> ;-)
<Burgwork> hey, I don't produce it, I just sell it
<ivoks> then you are evil man :)
<Burgwork> I want to see if my company misstepped, as we have one of those closed-source PAM modules
<mdz> mjg59: are you available for TB?
<mjg59> mdz: Yes
<mdz> excellent, because I don't think anyone else is
<mjg59> Scott certainly isn't
<ivoks> ttg bye
<Kamion> Burgwork: it's probably a bit debatable. If you're distributing a system that contains gdm (or another GPLed program linked to PAM) plus your proprietary module as a work as a whole, then you're violating the gdm licence; but if you're just distributing the module on its own and letting users decide what to do with it, you're probably OK
<Kamion> IANAL, etc. Consult a lawyer if you're unsure.
<Burgwork> Kamion, we are certainly not doing the latter, so I will chat with the company president about it
<desrt> see also: proprietary gstreamer plugins
<Burgwork> desrt, indeed
<Burgwork> should I be worried when our chief developer has no idea about the license of a significant chunk of code the company has written?
<Lure> Burgwork: yes
* pygi nods
<Burgwork> I want to work for a sane company!
<Nafallo> Burgwork: glhf :-)
<Burgwork> Nafallo, glhf?
<Kamion> hmm, maybe it's just me, but you're brave saying all this in a public channel whose logs are on the web
<Burgwork> Kamion, I realize that
<Nafallo> yes. good luck, have fun. in the sense of finding one that is :-)
* Kamion cranks up a kernel build with CONFIG_DEBUG_MUTEXES and heads off for the evening
<neuralis> is anyone who can correct posts on the fridge present?
<simira> neuralis: try #ubuntu-fridge ?
<bluefoxicy> doko:  are you here
<bluefoxicy> nope he's not
<bluefoxicy> I'm gonna go vote, brb.
<SlicerDicer-> who or where would I talk to find out information about ubiguity?
<SlicerDicer-> I want to do some modifications
<Burgwork> SlicerDicer-, Kamion is the person you need to talk to
<SlicerDicer-> Burgwork: thanks
<Burgwork> SlicerDicer-, what are you planning?
<Burgwork> SlicerDicer-, we are past feature freeze for edgy, so stuff would be edgy+1 stuff
<SlicerDicer-> well I want to modify it to lay out the disks differnetly by default, user creation etc
<SlicerDicer-> custom livecd
<SlicerDicer-> I doubt what I would do would ever make it into a release but what I am going to use it for would be extremely useful for what I am wanting to do anyway
* pygi wants autotools expert once again :)
<pitti> Mithrandir: ok to upload a mailman security update to edgy?
<Mithrandir> pitti: that's not on the CDs is it?
<pitti> no, I don't believe so; I can check
* Nafallo was about to say server ;-)
<Nafallo> if you're building server that is...
<Mithrandir> Nafallo: we are
<pitti> Mithrandir: yeah, what Nafallo says; it's not on the desktop/alternate CDs
<administrator> Kamion: may i pm you?
<Mithrandir> pitti: ok, upload away.
<pitti> Mithrandir: it's a remote DoS, not *terribly* urgent, but trivial to exploit
<pitti> alright, thanks
<ogra> Mithrandir, can i have a general exception for edubuntu-artwork ?
<bluefoxicy> Anyone else handle toolchain besides doko?
<ogra> so i dont need to ask if i work until 5am :)
<Mithrandir> ogra: sure.  It's edubuntu and nothing else which breaks, which makes me slightly less worried. :-)
<ogra> right
<ogra> :)
<Nafallo> hehe
<Lathiat> pitti: ping?
<pitti> Lathiat: hello
<Lathiat> pitti: hrm nevermind figured out i needed to scroll down further to find universe in cve/unfixed :)
* pygi wants autotools expert, pls :)
<pitti> pygi: me too, sometimes :)
<pygi> pitti, it refuses to do what it's supposed to do :P
<pygi> I want scons back :)
<pitti> pygi: why don't you use scons?
<pygi> pitti, because this is a system library, and I don't want to impose need of python on such a library for building system
<pitti> pygi: don't you have python bindings anyway?
<pygi> pitti, well, will do, yes, but that'll be as separate build
<mdz> pitti,imbrandon: I saw that in bug 58164 there was a misunderstanding about the security process for universe.  what do you think we can do to improve awareness of the policy there?
<Ubugtu> Malone bug 58164 in dapper-backports "firestarter backport" [High,Rejected]  http://launchpad.net/bugs/58164
<pitti> mdz: FYI, I filed bug 60135 for keeping track of the nvidia/usplash bug and sub'ed you
<Ubugtu> Malone bug 60135 in usplash "does not work at all on amd64 with nvidia card" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/60135
<pitti> mdz: our policy with that has been fairly consistent, but not documented, I believe
<pitti> mdz: I'd add it to SecurityUpdateProcedures
<mdz> pitti: please do, thanks. is that linked from DeveloperResources?
<pitti> yes, it is
<pitti> if appropriate, I'll also add a note there
<imbrandon> mdz, i think alot of that has to do with they ( jdong in this case ) dont know where to poke -security updates 
<imbrandon> pitti, yea +1 , i think that would solve it
<pitti> imbrandon: well, 'poking' doesn't fit here
<pitti> I usually know which stuff is outstanding in universe
<pitti> but I can't possibly fix them all
<mdz> imbrandon: did you find SecurityUpdateProcedures when looking?  if so, updating that would likely solve it
<mdz> imbrandon: if not, tell us where you looked and maybe it needs more links
<imbrandon> i dident look as i knew the proceedure, that was filed by jdong and i commented on that it dident belong in -backports as backports isnt on by default
<imbrandon> and pointed jdong to pitti
<imbrandon> but a standard wiki would be nice to point and future occurances , as security fixes get requested in -backports quite a bit
<imbrandon> s/point/point to/
<ogra> pitti, g-v-m is never happy with me removing my usbdisk :/
<pitti> ogra: even if you unmount it before pulling out?
<ogra> seems it doesnt like ext3 formatted devices and even complains if i eject properly
<pitti> mdz, imbrandon: I added a stanza to https://wiki.ubuntu.com/SecurityUpdateProcedures (language fixes appreciated)
<ogra> at least i guess its caused by ext3
<pitti> ogra: I'll try to reproduce that with ext3
<ogra> ok
<ogra> i cant dig further now (knot3 test ahead) but tomorrow 
<pitti> ogra: I can reproduce it, thanks for pointing this out
<ogra> ok ...
<ogra> i'm off for knot testing ... bbl
<Nafallo> knot already? :-)
<mdz> pitti: I simplified it a bit, please review
<imbrandon> pitti, thanks
<pitti> mdz: sounds much smoother, thanks
<LaserJock> we should replace python2.4 deps, correct?
<pitti> 'Updates prepared directly by the security team should be peer-reviewed.' *cough*
<bddebian> SHould be python policy :)
<LaserJock> bddebian: mhm
<ajmitch> pitti: yes, I have a universe update to get to you soon :)
<ajmitch> and I still have to sort out libgphoto2 after knot3 
<pitti> yay, I don't need a visa for the US
<imbrandon> pitti, looks great thanks
<pitti> cool
<yveslu> hi, any plans to get fontconfig 2.4 into edgy? it should improve perf. and reduce memory usage
<sladen> yveslu: we're in FeatureFreeze, and long in UpstreamVersion Freeze
<pitti> hi zul
<yveslu> sladen: it's a pity... btw it has been packaged for debian experimental and these packages seem to run fine in sid. 2.4 is also abi and api compatible to 2.3
<Burgwork> yveslu, the issue more is getting enough testing this late in the freeze
<yveslu> ok... just wanted to ask and share my experience with sid. they will surely end up in edgy+1 though... :)
<yveslu> sladen: fyi http://fontconfig.org/wiki/2_2e4_20release_20notes
<ogra> hmm
* ogra wonders why his CDs have no installer kernel modules ...
* nixternal joins ogra in the same wonder ;)
<ogra> nixternal, so you see it on ubuntu as well ? 
<nixternal> on kubuntu i did with the latest
<nixternal> as well as ubuntu
* ogra just tried edubuntu
<Burgwork> ogra, I saw somebody mentioning that a day or so ago, with ubuntu alt
<nixternal> and edubuntu yes
<ogra> ok
<nixternal> and xubuntu on my lappy
<ogra> then i'm fine ... i thought i broke the seeds or something :)
<ogra> intrestingly it mentions 2.6.17-7-* in all seeds here
<nixternal> my lcd does not like the new ubuntu splash
<sladen> nixternal: nvidia drivers?  external flatscreen?
<nixternal> yes and yes
#ubuntu-devel 2006-09-13
<Kamion> ogra: debian-installer failed to build, but that should be fixed now. rebuild your CDs.
<nixternal> actually, NO to the NVidia drivers
<ogra> oki
* Kamion goes back to bed
<nixternal> thought they were in there
<ogra> Kamion, thanks, sleep well
<Nafallo> hehe, Kamion woke up only to tell ogra that :-)
<ogra> Nafallo, he knows i'm short on time ... i'll be travelling by the time knot3 comes out and have to do the testing before ... ;)
<Nafallo> aha :-)
<Burgwork> http://blogs.adobe.com/penguin.swf/ <-- ubuntu!
<jdong> Burgwork: yeah, I noticed... doesn't that make us feel good? :)
<zul> Burgwork: I have updated my blog fyi
<bddebian> Hwody
<bddebian> Err Howdy even
<jdub> mjg59: pcscd with a stupid plist (apple!) setting change in libccid works
<jdub> though now i need a functional smart card
<wasabi> I've been eatten alive by the XFS bug in 2.6.17 apparently. Fixed in 2.6.17.7.   The 2.6.17-7 kernel, is that this? Or is the - the ubuntu version?
<bluefoxicy> o.o
<bluefoxicy> doko?
<wasabi> ALso somebody needs to upload xfsprogs 2.8.10 because it's related in this bug.
* bluefoxicy opens beagle and uses it to find doko
<mjg59> wasabi: The Ubuntu kernel is 2.6.17.11
* bluefoxicy opens beagle and uses it to find doko^Wanyone in control of the toolchain
<wasabi> mjg59, Where is that number shown?
<bluefoxicy> hi Keybuk
<mjg59> wasabi: The Makefile. Also the changelog.
<wasabi> Heh.
<Keybuk> heyhi
<mjg59> Keybuk: Query about functional module dependencies
<mjg59> Keybuk: tifm_711x binds to the PCI ID. tifm_sd provides the SD reader functionality and is required for the PCI device to be functional. This is trivially expressed in modprobe.d, but what package is the right place to put that?
<Keybuk> shouldn't it either be a dep
<Keybuk> or itself declare those aliases?
<Keybuk> if not, module-init-tools can ship a modprobe.d file
<mjg59> Is there a reasonable way to express inter-module dependencies outside that?
<mjg59> tifm_sd relies on a ti flashmedia device
<mjg59> The only current driver we have is for a PCI device, but that's not inherently true
<Keybuk> in the modules itself?
<mjg59> tifm_sd depends on tifm_711x by virtue of it currently being the only module that provides the symbols it needs
<mjg59> But tifm_711x has no logical dependency on tifm_sd
<Keybuk> why doesn't it?
<mjg59> Why should it?
<mjg59> The part doesn't necessarily have an SD reader
<Keybuk> what's a 711x then?
<mjg59> So from a driver point of view, it's sensible
<mjg59> A chip that can read various different flash formats
<Keybuk> what's tifm_sd?
<mjg59> A driver for the SD portion of that class of chip
<mjg59> I've got a Sony which has the same chip, but only memory stick
<mjg59> It doesn't hurt to always load tifm_sd, but there's no reason for the driver to depend on it
<Keybuk> so surely if you have a 711x device, you always need sd loaded?
<mjg59> No
<Keybuk> meh, this smells of the "it's not a dependency, it's a recommends" type of bullshit :p
<mjg59> On the Sony, I'd want tifm_711x and tifm_ms (which isn't fully written yet, but still)
<Keybuk> ahh
<Keybuk> but you'd get sd anyway
<mjg59> Right
<mjg59> The driver author has no reason to introduce a dependency
<Keybuk> we can add it in userspace easily enough
<mjg59> Yeah
<Keybuk> install tifm_711x modprobe --ignore-install tifm_711x $CMDLINE_OPTS && { modprobe -Qb tifm_sd ; : ; }
<Keybuk> in a modprobe.d file
<mjg59> Yeah
<Keybuk> reminds me, TODO; bridge jcm to add "depends" syntax
<Keybuk> the location of UDSMV interests me
<Keybuk> I wonder which hotel the staff will be in, I don't recall one being anywhere near the Googleplex
<Keybuk> will we need to hire cars?
<mjg59> Yeah, I was curious about that
<zul> i thought the public transit would be pretty good in mountain view
<wasabi> UDSMV?
<mjg59> Ubuntu Dev Summit Mountain View
<wasabi> oh that's what keybuk mentioned
<mjg59> zul: It is, but the Googleplex is pretty much on the edge of nowhere
<zul> ah...gotcha
<wasabi> Heh. I need a common to reinstall every package on my system.
<wasabi> command.
<Burgundavia> mjg59: welcome to the US. They build for cars there
<Keybuk> wasabi: aptitude reinstall '~i'
<wasabi> Nice.
<wasabi> here I am trying to parse the output of dpkg -l
<Burgundavia> zul: seems like Xen is a major pain to keep updated
<zul> Burgundavia: yeah once it smooth out it will be ok
<SEJeff> Keybuk: ping
<Keybuk> SEJeff: hi
<SEJeff> Keybuk: Evening. I would like to implement the RapidReboot spec for edgy+1 and know that it will need to play nicely with upstart seeing as how thats what ubuntu is moving towards.
<Keybuk> RapidReboot spec?
<Keybuk> let me bring that one up
<SEJeff> Keybuk: https://wiki.ubuntu.com/RapidReboot
<Keybuk> yeah, was waiting for the wiki to kick into gear
<wasabi> Interesting.
<Keybuk> SEJeff: sweet.  Not sure that it'd need to play much with upstart, tbh
<SEJeff> Keybuk: It is basicly implementing kexec reboots for things like kernel upgrades, etc
<SEJeff> Keybuk: And it would go perfectly with the idea of the Teardown spec just implemented
<Keybuk> it seems kernel-level
<SEJeff> Keybuk: kernel-level is above me but advanced shell scripting / python is not.
<Keybuk> I mean that it seems that you'd be shutting down and starting the system AT the kernel level
<Keybuk> i.e. you replace a call to reboot() with a call to kexec()
<Keybuk> and what gets started as a result is a new kernel, that would start upstart again
<SEJeff> Keybuk: Sort of. It isn't done at the kernel level though. It is done through the init scripts. Hence the need for upstart integration
<wasabi> Might pass a "quick" option to upstart.
<wasabi> As the first option to "shutdown". ;)
<Keybuk> is there any change to the boot?
<wasabi> Or something. ;)
<Keybuk> or is it just to the final step in the shutdown?
<wasabi> Kexec is a patch to the Linux kernel that allows you to boot directly to a new kernel from the currently running one. In the boot sequence described above, kexec skips the entire bootloader stage (the first part) and directly jumps into the kernel that we want to boot to. There i
<wasabi> ^ sounds like it's done in the kernel to me.
<Keybuk> right
<SEJeff> Keybuk: the boot is identical but the reboot is different.
<Keybuk> ok
<Keybuk> how do you mean "the reboot is different"?  different how?
<SEJeff> wasabi: kexec is already integrated into the mainline AND ubuntu kernel
<SEJeff> Keybuk: Just a sec...
<wasabi> Nice. So, the work is done. Just need a user space utility to read grub's config. :)
<wasabi> ANd send the first initramfs/kernel into kexec.
<SEJeff> wasabi: actually, install kexec-tools from universe and everything you need is in place
<wasabi> Sure. YOu just need to make the last task in the runlevel change call it.
<SEJeff> /etc/init.d/reboot would need to be changed
<SEJeff> Correct
<Keybuk> right
<Keybuk> so the way that shutdown upstart works (downshut? :p) is:
<wasabi> Or however we figure out how to make upstart do that right.
<wasabi> Not sure what that is. It sends reboot() on it's own doesn't it?
<Keybuk> upstart emits a "shutdown" event (so apps can stop, etc.)
<jdub> "I can't understand someone like Osama bin Laden understanding the joy of Hanukkah." - GWB
<Keybuk> once that's been handled, upstart then emits a second event, that is specified by /sbin/shutdown
<Keybuk> power-off for -P
<Keybuk> system-halt for -H
<Keybuk> reboot for -r
<Keybuk> etc.
<wasabi> AHh.
<Keybuk> you can specify a custom event as well, and we can add options for others
<Keybuk> so we could have a fast-reboot for /sbin/shutdown -Q now or something
<Keybuk> then we just make sure any scripts with "on reboot" are also run for "on fast-reboot"
<Keybuk> except the one that calls /sbin/reboot -f, that would be replaced by one that calls kexec
<SEJeff> Right
<wasabi> jdub, obviously the whole "muslim" thing threw him off.
<Keybuk> the sysvinit analogy would be adding a runlevel 7 for a fast reboot
<SEJeff> ok
<wasabi> yay I fixed my fss enough to save some data
<SEJeff> I won't be able to set up an edgy box for a few weeks until I complete my move to Cali for a new Sys Admin job but want to work on what I can here and now
<Keybuk> how much does Windows restart on a shift-restart?
<Keybuk> it's just the shell, isn't it?  not the whole kernel?
<jdub> windows 9x?
<SEJeff> Keybuk: thats how I understand it
<wasabi> shift-restart?
<jdub> that was just 'win'
<jdub> not reboot+dos
<SEJeff> wasabi: it is a faster method of rebooting
<wasabi> Thought windows just did a plain ol' power off reboot, but with a fast boot up time.
<wasabi> (preload all previously used drivers into a big blob)
<jdub> shift-restart still exists in nt land?
<wasabi> Sure didn't think so.
<jdub> (the turn off dialogue doesn't change labels for restart as it does for sleep)
<SEJeff> wasabi: well that can't be correct because shift reboot doesn't do the bios post. That means it has to be a software only reboot
<wasabi> How does one do "shift reboot" on NT?
<wasabi> I see no such feature here. =/
<SEJeff> wasabi: http://www.lawrencegoetz.com/95tips.htm
<wasabi> The name of tha tURL does not suggest NT.
<SEJeff> wasabi: I can't speak for nt
<wasabi> Yeah. NT doesn't support that no more. That means XP.
<SEJeff> Keybuk: So I'm curious to the upstart design and how difficult you think it would be to do this
<Keybuk> SEJeff: very easy
<Keybuk> see above
<SEJeff> Keybuk: As in can you think of any gotchas or things I should look into
<Keybuk> nothing obvious
<Keybuk> we already have three different "when you're done shutting down" things
<Keybuk> I don't see how a fourth option hurts
<SEJeff> Keybuk: Great news to hear. You might see my post to ubuntu-devel sometime earlier today about this. Feel free to reiterate the same thing.
<Keybuk> I haven't caught up on u-d yet
<SEJeff> Keybuk: good luck with that one :)
<Keybuk> SEJeff: mostly I use the "Delete" key
<wasabi> Keybuk, all that upstart stuff makes me wonder how shutdown would be optimally implemented in that case.
<wasabi> You'd think you'd have everything set to "stop on shutdown"
<wasabi> Oh wait n/m. Nothing changes.
<wasabi> Hah. 
<wasabi> n/m. take back everything. forget I spoke.
<Keybuk> "stop on shutdown" would be things that are teardown-exempt
<Keybuk> "on reboot/halt/power-off" would be things like mounting the disks, etc.
<wasabi> Yeah. For a second I had forgotten that shutdown and poweroff were seperate things.
<Keybuk> this isn't entirely in stone yet, of course
<wasabi> Yeah
<jdub> Keybuk: so how many distro team people are refusing to enter the USA for UDSMV?
<Lathiat> UDSMV?
<jdub> ubuntu developer summit mountain view
<Lathiat> ah i see
<wasabi> When is that?
<jdub> nov
<wasabi> Oh crap.
* Fujitsu hopes a lot.
<wasabi> I had no idea it was that soon.
<mjg59> See Fridge
<wasabi> wiki???
<Lathiat> hrm i should hurry up and finish my lca proprosal
<jdub> yes you should
<Lathiat> interesting mvoe to have it in MV
<Lathiat> as you say i generally see that alot of developers have a hard time getting into the US and such
<AlinuxOS> hello mjg59 ;)
<wasabi> Hey, I have a lot of trouble getting OUT
<Keybuk> jdub: none that I'm aware of
<Keybuk> a couple of us had immigration issues, I've sorted mine out, I believe the person who forgot to return his slip last time is also sorting that out
<mjg59> Last time I had US immigration issues, I got a passport from another country...
<wasabi> Keybuk, have any times during the UDSMV week where upstart stuff is planned?
<wasabi> I might not be able to make it for the entire week.
<jdub> plans! hah!
<wasabi> =(
<wasabi> destination airports?
<mjg59> wasabi: SFO or San Jose
<wasabi> thx
<mjg59> San Jose is slightly nearer, but not very international
<wasabi> coming from the us. ;)
<mjg59> Yeah, San Jose is probably a better bet
<Keybuk> wasabi: we don't do any form of planning I'm afraid
<Lathiat> whats SFO?
<mjg59> I'm hoping to get there, but I won't know if it's possible for a month or so
<mjg59> Lathiat: San Francisco
<Keybuk> wasabi: usually the schedule is drawn up that morning, and altered throughout the day
<Lathiat> ah right
<Lathiat> whats the 'O' mean?
<wasabi> heh. nice.
<Keybuk> wasabi: generally you register when you turn up, and your interest in particular specs
<mjg59> Lathiat: Airport codes rarely have a great deal to do with the city name
<Lathiat> oh right
<Lathiat> airport code
<Keybuk> and then the scheduler ensures we talk about things of interest to you on the day that you are there
<Keybuk> uh, I mean by that "you register when you are going to turn up, in launchpad, in advance"
<mjg59> Keybuk: Is the scheduler automatic now, or is there still someone stuck doing that all evening?
<Keybuk> which always struck me as a public list of people whose house was going to be empty, but still
<Keybuk> mjg59: jamesh's schedule-o-matic
<wasabi> I doubt I'll be able to afford this either.
<wasabi> Might turn out to not be practical.
<Keybuk> wasabi: it'd be a shame, you'd be great to have there
<Keybuk> how far do you have to travel?
<wasabi> Not far at all. Tickets aren't a problem.
<wasabi> Hotel is. ;)
<wasabi> Also gf would insist she be brought along.
<wasabi> Heh.
<jamesh> the plan is to move the schedulomatic code into Launchpad, so that it is easier for multiple people to work on the schedule
<Keybuk> I can suggest sponsorship for you, but not the partner
<Keybuk> jamesh: btw, can we mark our attendance as private please? :p
<jamesh> stalking problems?
<Keybuk> (if I can't get my own partner sponsored ... etc.)
<wasabi> Heh. I don't know what the requirements of "sponsorship" are. =)
<Keybuk> jamesh: house insurance problems
<Keybuk> after the recent "google calendar" scandal, they've added a condition to the insurance
<Lathiat> er, haha
<wasabi> Ya know, if I could find a place to stay, a room to share, somebody to split room with... I might be able to leave her at home. ;)
<jamesh> Keybuk: file a bug
<wasabi> I will have to see. And buy some roses.
<jamesh> so they don't want you advertising to the world when your house will be empty?
<mjg59> wasabi: After what happened to Mez, that might be a bad idea
<wasabi> ?
<wasabi> Uh oh. Conference horror stories.
<mjg59> Oh, UBZ in Montreal
<Keybuk> jamesh: exactly
<Keybuk> jamesh: in fact, if I do so on a public web page, I am uninsured
<wasabi> What's this insurance stuff?
<jamesh> Keybuk: that'd be a pain if you were a speaker at a conference
<jamesh> "come to $CONFERENCE and you may or may not see a talk by Keybuk"
<Lathiat> indeed
<Lathiat> haha
<jdub> Keybuk: suck!
<Keybuk> jamesh: the wording implies publishing of one's schedule
<jdub> insurance companies are such parasites
<Keybuk> though I'm sure they'd wriggle out of it in any case
<Lathiat> so i wonder when the ubuntu+google rumor mill will start spinning again :)
<Keybuk> which rumour?
<Lathiat> rumors liek google working on a ubuntu based googleOS and other such things :)
<Keybuk> they are?
<Keybuk> they use it internally
<Keybuk> this is well known
<Lathiat> nah nah like for public release and such
<Keybuk> and there are many comments from senior people of both companies that confirm this
<Lathiat> google pcs, takign over the world
<mjg59> Keybuk: Nonono, that's not true
<mjg59> After all, asuffield says that Ubuntu has no large deployments
<wasabi> Yeah, not making it.
<wasabi> Can't do the hotel. That's really the deal breaker.
<Lathiat> mm i love this i just searched for flights from here to SFO its $1600 + taxes... of $550
<Lathiat> which they dont give you the value of until you click through to start actually booking the flight
<mjg59> wasabi: Well, you can always apply for sponsorship
<Keybuk> mjg59: asuffield can blow me
<mjg59> Keybuk: I'm sure you wouldn't actually want that
<wasabi> I don't have much to stand on. I don't spend lots of time commiting code that helps ubuntu these days.
<Keybuk> yes, actually, you're quite right
<Keybuk> asuffield can blow mark ray
<jdub> *** WARNING: THIS IS NOT A DEBIAN FANFIC CHANNEL ****
<Keybuk> jdub: isn't it called "shipping" these days?
<wasabi> the wiki is being annoyingly slow.
<wasabi> Keybuk, added my name to the sponsor list thingy. Best I can do now unless I win the lottery or something. :)
<Keybuk> wasabi: alrady done
<wasabi> I know. I did it... ?
<Keybuk> no, I did
<wasabi> I did first, then.
<wasabi> I hope we didn't just overwrite each other. ;)
<wasabi> Unless you have a new super-secret list.
<Keybuk> oh, there's an internal list yeah
<wasabi> thanks. sleepy time.
<fabbione> morning guys
<mneptok> hey fabbione 
<fabbione> hey kurt
<bluefoxicy> why does my home have 48 objects in it and take up of 5 seconds to load
<bluefoxicy> while a folder with 100 objects takes under a second
<bluefoxicy> even ls cries about it
<bluefoxicy> what do I need to do, defragment the damn thing?
<mneptok> maybe get rid of that MFM drive?
<fabbione> no wonder the initramfs in edgy is at least 3 MB bigger than dapper
<fabbione> we are pulling in libc and libpthread
<fabbione> and in dapper we are pulling also optimized libc.. that's kind of pointless without libc
<bluefoxicy> ouch.
<bluefoxicy> I need sleep
<pitti> Good morning
<Burgundavia_> whiprush: you around?
<dholbach> HAPPY HUG DAY!
<Burgundavia_> hey mvo, dholbach
* pitti hugs dholbach 
<dholbach> hey mvo, pitti, Burgundavia_
<mvo> hey burgundavia, dholbach!
<nixternal> hug day already?  wooopeeee
<dholbach> yeah!
<dholbach> let's all join #ubuntu-bugs and get the party going :-)
<nixternal> woohooo 2:15am ;)
<nixternal> give me 7 hours ;)
<zyga> morning
* mvo waves to zyga
<zyga> mvo: answering your yesterday's question: I did remove that apt bit because I didn't quite understand how it worked and I didn't (selfish me) need it for a pure one release mirror
<zyga> so yes - we have stuff since warty :)
<janimo> Riddell: thanks for the xubuntu artwork ;)
<mvo> zyga: heh, ok :) I will have a look at it today and include it again then
<zyga> okay :)
<zyga> I can do it in the evening though - you're quite busy
<janimo> doko, if a python binary has .install files under debian/ do I add the python dirs manually (/usr/lib/python2.{4,5}), or is there some way to have those inferred as well by pycentral?
<janimo> the source package is exo which builds not only the python bindings but the C library as well, so .install files are needed
<janimo> it's recent rebuild di not make is have 2.5 support as the .install file only lists /usr/lib/python2.4
<pitti> Mithrandir: do you use the test matrix or just IRC status messages for CD testing? I'm going to test the powerpc CDs
<Mithrandir> pitti: the matrix.
<doko_> janimo: it shouldn't matter, the install file should list /usr/lib/python*
<janimo> doko_: thanks
<pitti> 'dont-test-yet' - ok, so I'm going to test the desktop CD modes first
<pitti> Mithrandir: want me to update the desktop timestamp to 20060913?
<Mithrandir> pitti: yes, please.
<Mithrandir> pitti: if you'd update the install cd timestamp to 20060912.1 too, that'd be good
<infinity> Mithrandir: Mornin'.  Do you want me to freeze edgy officially and see if malcc's fixes work?
<janimo> doko_: I assume the dpkg-genchanges warning unknown information field `Xb-Python-Version' is expected?
<pitti> Mithrandir: from dont-test-yet? so we shall test them now?
<doko_> janimo: yes
* dholbach hugs infinity
<Mithrandir> pitti: yes
<pitti> hi infinity 
<Mithrandir> infinity: yes, please, since it seems I still can't do it myself.
<infinity> Mithrandir: Done.  Let's see how this works this time. :)
<Mithrandir> infinity: it'll be.. interesting.
<infinity> Mithrandir: Well, Ican't wait for the first freeze exception to see how it goes.
* mvo_ waves to infinity
<Kamion> morning
<infinity> Evenin'.
<Fujitsu> Evening, Kamion.
<realist> Is there an easily accessible list of orphaned packages up for adoption anywhere?
<fabbione> Mithrandir: permission to upload lvm2 to add -fno-stack-protector to CFLAGS. It fixes a bus error on sparc and some random segfault i noticed on i386 with certain disk labels
<fabbione> Mithrandir: it's not a blocker for knot but it would be nice to have
<Fujitsu> Isn't Soyuz meant to notify me when my sync requests are uploaded?
<Fujitsu> And they didn't appear on my packages page either :S
<Mithrandir> fabbione: if nothing else, it'd be a useful way to test the FROZEN bit now.  Please upload.
<fabbione> Mithrandir: thanks. will do in 2 minutes max
<Fujitsu> Am I right in saying that sync requests should be done in the name of the requestor, not the approver (ie. me rather than crimsun)?
<Fujitsu> Sorry, `syncs should be done', not `sync requests should be done'.
<pitti> Mithrandir: ugh, it seems Kamion's ppc usplash fixes did not make it to the desktop CD?
<fabbione> Mithrandir: uploaded
<fabbione> Mithrandir: i just got the mail from Ubuntu Installer that it has been Accepted
<infinity> fabbione: Grr.  Really?
<fabbione> infinity: only that one
<fabbione> not the one to the mailing list
<fabbione> but yeah.. "Really!"
<infinity> Oh, no.  It's in UNAPPROVED.  Yay.
<infinity> The mail is just incorrect.
* infinity approves it.
<Kamion> Fujitsu: I'm a bit haphazard about that
<Fujitsu> Kamion, what do you mean?
<Kamion> Fujitsu: normally what I try to do is make it be in the name of the first person in the chain who knew what a sync request was; so for example if some random user files a bug saying "I'd like to have a newer version of such-and-such", then that doesn't count, but the first person who knew what they were talking about gets their name in the changelog
<Fujitsu> Well I didn't :(
<Kamion> Fujitsu: however this requires a fair bit of memory from me of who's who, so I'm not entirely consistent
<Fujitsu> Yeah...
<Kamion> Fujitsu: I beg to differ - you very often do
<Fujitsu> It was Keybuk :)
<Fujitsu> I often do.
<Kamion> I've typed 'sync-source -b fujitsu' lots of times
<Fujitsu> But not with this last batch.
<fabbione> infinity: now i got 2 times the email about Accepted
<Fujitsu> fabbione, fantastic!
<Kamion> I don't think it will be entirely consistent until you're in ubuntu-dev
<fabbione> infinity: ah feh.. it sends one to me and one to the mailing list
<Fujitsu> Probably.
<fabbione> infinity: weird.. before it was only one
<Kamion> Keybuk and I have never talked about this practice; it's just what makes sense to me
<infinity> fabbione: Yeah, that buglet's not a big deal, just annoying.
<infinity> fabbione: At least it appears to be doing the right thing in the queues now...
<Kamion> pitti: the livefses seem very out of date
<fabbione> infinity: yeah.. emails.. who cares :)
<Kamion> cdimage/www/full/daily-live/current/edgy-desktop-amd64.manifest:usplash 0.4-14
<Kamion> cdimage/www/full/daily-live/current/edgy-desktop-i386.manifest:usplash 0.4-20
<Kamion> cdimage/www/full/daily-live/current/edgy-desktop-powerpc.manifest:usplash 0.4-20
<pitti> ugh
<pitti> Kamion: this will make 'check CD' totally unusable on ppc, too -- so should we roll new live fses?
<Kamion> definitely, none of the most recent batch of builds worked
<Kamion> Setting up human-theme (0.1-0ubuntu2) ...
<Kamion> update-alternatives: unable to make /usr/share/icons/default/index.theme.dpkg-tmp a symlink to /etc/alternatives/x-cursor-theme: No such file or directory
* pitti switches testing to the alternate CDs
<Kamion> dholbach: didn't you have a fix in progress for that?
<Zdra> hi, any chance to have the package spiftacity updated with metacity 2.16 and his compositor ?
<Kamion> oh, apparently that was a different bug
<Kamion> I'll fix it now
<Kamion> (human-theme that is)
<pitti> iwj: any idea why the firefox font on the current live CD looks totally ugly? (not hinted and subpixel'ed); the desktop in general is fine, so is the ffox menu bar, it only affects the document contents
<Fujitsu> Also, will builds that are of state `Dependency wait' automatically restart themselves when the dependency becomes available?
<slomo_> pitti: same here... looks much better (at least in epiphany) when selecting bitstream vera as fonts instead of sans-serif/monospace
<dholbach> Kamion: urg, I thought I had fixed that one - was that an upgrade problem?
<infinity> Kamion: The freeze appears to be correctly shunting things to -Q unapproved, so don't forget to drive drescher to accept stuff. :)
<Kamion> dholbach: no, fresh install. I've just committed a fix to bzr
<infinity> Kamion: And, on the flipside, it means I can upload non-approved stuff.  YAY.
<dholbach> Kamion: thank you very much
* dholbach looks
<Kamion> dholbach: the guideline is that every time you use update-alternatives, you must ship the target directory in the package
<infinity> Fujitsu: Yes, dep-wait handling is automatic.
<Fujitsu> OK, thanks :)
<pitti> slomo_: does the current edgy/alternate ppc work for you? 'check' complains about a wrong md5sum in the release file
<pitti> slomo_: I try another burn, though
<slomo_> pitti: i tried two days ago and the cd drive didn't even accept the alternate cd
<pitti> hm, I do an alternate install from time to time, but I seldomly use 'check'...
<dholbach> Kamion: that makes sense - thanks again.
<dholbach> rodarvus: thanks for joining the telepathy team :-)
<mneptok> "telepathy" is something insane people tell themselves they have to explain the voices in their heads
<Kamion> really committed to bzr now - I didn't mean to use get rather than checkout ...
* mvo reboots for new-kernel-love
<pitti> Kamion: against which package do I file a failing 'check' boot target?
<pitti> I ruled out bad media by checking the md5's manually
<pitti> Kamion: cdrom-checker?
<Kagou> pitti: for firefox ugly fonts, have you looked also at yelp ?
<pitti> Kagou: no, will do next time
<Kamion> pitti: alternate or desktop?
<pitti> Kamion: alternate
* infinity has to run out to the store for some steaks.
<Kamion> pitti: cdrom-checker, yes
<pitti> thank you
* infinity hands the keys for drescher to Kamion.
<Kamion> I've never heard of it failing on genuinely good media and drive though
<Kamion> it basically just does md5sum -c on each line
<infinity> Kamion: Is this you?
<infinity>    94377 | S- | human-theme          | 0.1-0ubuntu3         | six minutes
<infinity>          | * human-theme/0.1-0ubuntu3 Component: main Section: x11
<Kamion> infinity: yeah
<Kamion> I'll approv it
<Kamion> +e
<infinity> Too late.
<infinity> Now you can have the keys. :)
<Kamion> heh, ok
* infinity goes.
<pitti> Kamion: me neither, but see bug 60188, I think I correctly compared md5sums
<Ubugtu> Malone bug 60188 in cdrom-checker "check does not work on ppc/alternate 20060912.1" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/60188
<MrFaber> hi all
<Kagou> pitti: for firefox ugly fonts -> Bug #56682
<Ubugtu> Malone bug 56682 in Ubuntu "Raster fonts appear in Edgy" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/56682
<pitti> Kamion: the md5sum in md5sum.txt is definitively wrong
<Mithrandir> it's an ubuntu-cdimage bug, then.
<Kamion> definitely wrong? you said in the bug that it was definitely right
<thom> http://benjamin.smedbergs.us/blog/2006-09-12/deploying-the-airbag/
<Mithrandir> Kamion: he said it matched the .iso on his disc.
<Kamion> or did you?
<Mithrandir> (and that the .iso matched what's on cdimage.u.c)
<Kamion> I don't understand
<MrFaber> Is it possible that edgy changed the shell option of users? If I add an user in edgy or just upgrade vom dapper to edgy and have another user accounts than the standard one console shows for this one only a $ . After useing usermod -s /bin/bash USER everything works fine. It is a bug or a feature?
<pitti> Kamion: I mean the md5sum of the actual file on the CD is right
<pitti> Kamion: but the sum that c-c checks against in md5sum.txt is wrong
<Kamion> MrFaber: /bin/sh is dash now, but we should be giving new users bash by default, imho
<Kamion> $ isoinfo -R -i edgy-alternate-powerpc.iso -x /dists/edgy/main/binary-powerpc/Release | md5sum
<Kamion> 76da0c7fb89cfae9595a369f927bb1dd  -
<Kamion> $ isoinfo -R -i edgy-alternate-powerpc.iso -x /md5sum.txt | grep /dists/edgy/main/binary-powerpc/Release
<Kamion> 76da0c7fb89cfae9595a369f927bb1dd  ./dists/edgy/main/binary-powerpc/Release
<Kamion> no ubuntu-cdimage bug there
<MrFaber> Kamion, yes please since sh doesn't support tab completion of file names and so on
<MrFaber> Kamion, but standard user still uses bash
<Kamion> MrFaber: please file a bug on whatever you used to add the user
<pitti> Kamion: argh, I picked the wrong file, sorry; /me updates the bug
<MrFaber> Kamion, ok
<ogra> is base-install failing on initramfs-tools known ? 
<Kamion> pitti: it's still correct
<pitti> Kamion: so, md5sums are all correct
<Kamion> $ isoinfo -R -i edgy-alternate-powerpc.iso -x /dists/edgy/restricted/binary-powerpc/Release | md5sum
<Kamion> b60e1e09e13135b8537380ebb1882f60  -
<Kamion> $ isoinfo -R -i edgy-alternate-powerpc.iso -x /md5sum.txt | grep /dists/edgy/restricted/binary-powerpc/Release
<Kamion> b60e1e09e13135b8537380ebb1882f60  ./dists/edgy/restricted/binary-powerpc/Release
<pitti> Kamion: yeah, I updated the bug, md5sums all match, and still 'check' complains and claims it's wrong
* StevenK wonders what's going on with his krecipes sync request.
<Fujitsu> Wazzup with it, StevenK?
<StevenK> Fujitsu: It hasn't been touched for a while.
<Fujitsu> StevenK, how long's a while?
<Fujitsu> Mine sat for 8 days.
<Mithrandir> pitti: what does grep /dists/edgy/restricted/binary-powerpc/Release md5sum.txt | md5sum -c say?
<StevenK> Fujitsu: Damn it, I was hoping to get away with not checking.
<Kamion> pitti: updated bug
<Kamion> StevenK: it's still in the queue
<StevenK> Heh, 4 days. It seems I'm less patient than I thought.
<StevenK> Kamion: Yeah, sorry, I honestly thought it had been longer.
<Kamion> looks like we're a bit backed up unfortunately
<ogra> Kamion, base-install breaks for me when installing initramfs-tools is that a known one or should i run a new install to get a log ? it says initramfs-tools is already the newest version and is not allowed to remove it ?
<Mithrandir> (food)
<dholbach> Mithrandir: bon apptit
<pitti> Mithrandir: 'Ok'
<Kamion> ogra: not known, I'll try to duplicate in a moment; a bug on base-installer with the full syslog would be appreciated
<pitti> Mithrandir: same for 'main'
<ogra> ok, i'll run a new install then ... (need to upload some other fixes before)
<pygi> sivang, poke?
<dholbach> troy_s: did you have luck with subscribing ubuntu-art to bugs of packages?
<pitti> Kamion: (bug updated)
<giftnudel> are there known problems with the german mirror of archive.ubuntu.com?
<pitti> giftnudel: doesn't work for me either ATM
<giftnudel> it has been bad for nearly a week now
<Mithrandir> pitti: weird.  Can you get the syslog with DEBCONF_DEBUG=5 out somewhere?
<pitti> Mithrandir: where do I set that?
<Kamion> I'm not sure how much that will help ...
<pitti> as boot option?
<Kamion> kernel boot parameter
<pitti> will do after my current test install (only server, should be fast)
* pitti burns the amd64 alternate and checks there
<Mithrandir> that reminds me, I should rebuild the server ISOs
* Mithrandir idly wonders why oowriter complains about his OpenGL driver being shit
<broonie> Documents just aren't the same without the shading effects.
<pitti> broonie: we want cube rotation when scrolling pages, of course
<giftnudel> and the paper should behave like paper when dragged
<Kamion> mvo: help
<Fujitsu> Or... not.
<Kamion> mvo: your auto-remove stuff broke d-i - 'apt-get -y --no-remove install <package that is already installed>' exits non-zero
<Kamion> ogra: ^-- that's the initramfs-tools problem
<ogra> ah
<ogra> right 
<mvo> Kamion: does it print anything? or just exists zero?
<mvo> Kamion: aha, I see the problem
<mvo> Kamion: give me a bit
<Kamion> mvo: thanks; it's needed for knot-3 obviously
<Kamion> it says "E: We are not supposed to delete stuff, can't start AutoRemover"
<Kamion> that should be entirely silent and not error, IMHO
<ogra> right, thats the message 
* pitti just ran into that, too
<mvo> Kamion: I'm on it now, it was a oversight of a side-effect 
<Kamion> Mithrandir: can I upload console-setup to switch the dependencies back to xkb-data? I'd like to get rid of the transitional xkeyboard-config from minimal
<Mithrandir> Kamion: is there any harm in waiting until after knot 3?
<Kamion> I guess not
<Kamion> I'll just let it sit in unapproved then
<Kamion> just means people have an extra junk package lying around. :)
<Mithrandir> yeah, which is unfortunate, but that'll be fixed with the apt magic. :-)
<Kamion> mjg59: would you mind if I changed usplash.postinst to fetch the X modes from /etc/X11/xorg.conf rather than debconf? I'd be much more comfortable with that - we shouldn't be relying on values in the debconf db
<iwj> pitti: No, no idea, sorry.  I hadn't noticed.  I suppose it's possible that 2.0 beta 2 will fix it, but it sounds more like something's wrong with the font machinery.
<infinity> Kamion: Basing it on the config file is saner, yes.  Just do it. :)
<infinity> Kamion: Debconf is not a registry and such.
<Kamion> just need to suck the sed magic out of dexconf for parsing xorg.conf reliably
<thom> iwj: are we likely to see beta2?
<Kamion> er, out of xserver-xorg.postinst
<mvo> Kamion: fix is here, I'm doing a final test and will upload then. I assume it is urgent?
<zyga> mvo: g-a-i postinst crashed during knot-2 current upgrade, interested?
<mvo> zyga: yes, can you put it into a pastebin please?
<zyga> mvo: not untill evening, the python script could not import pygtk though
<Mithrandir> mvo: yes, it's urgent. :-)
<pitti> ok, 'check' on amd64 works fine
<iwj> thom: Yes, I'm merging it right now.  Urgh, etc.
<thom> heh. Urgh indeed
<Kagou> doko or iwj around ?
<simira> who broke x?
<infinity> Kamion,Mithrandir: We win.  Binaries are being built and accepted correctly too.  FROZEN works.
<Mithrandir> infinity: yay!
<Kagou> For Bug #56682 i'v proposed a solution, but i don't know if it's working, 'cause i have to simulate a clean/fresh installation with a modified version of fontconfig. So if doko  or iwj can have a look at resolving this bug :)
<Ubugtu> Malone bug 56682 in fontconfig "Raster fonts appear in Edgy" [Medium,Confirmed]  http://launchpad.net/bugs/56682
<iwj> Kagou: Here.  Just reading that now.
<iwj> Kagou: Are you `VETSEL Patrice' ?
<Kagou> iwj: yes
<iwj> Right ...
<pitti> hi iwj
<iwj> pitti: Hi.
<pitti> hm, does anyone know how to get a file from the d-i system to the hard disk or usb stick? all my mount attempts just fail with 'invalid argument' or 'no such device'
<pitti> iwj: yup, that's the same issue I pinged you about some hours ago
<iwj> pitti: I thought it might be.  Kagou seems to be saying it happens on a desktop install too.
<iwj> Kagou: Or was this on a livecd ?
<iwj> The code here in the fontconfig postinst is a bit odd.
<Kagou> iwj: i'v this bug on since knot1, and i'v done fresh install of knot1 . And fresh install of knot2too
<ogra> pitti, install the ssh client udeb and scp it :)
<iwj> Kagou: Hmm.
<Kagou> iwj: in my dapper system i'v "30-debconf-no-bitmaps.conf" not in edgy knot1 and knot2 after install
<pitti> ogra: already tried netcat, no ethernet modules at this stage
<ogra> hmm... thats bad
* pitti grabs his camera
<iwj> Where can I read about how the livecd is constructed ?
<Kamion> infinity: w00t
<Kagou> iwj: i must disconnect. i came back in 1/2 H 
<Nafallo> pitti: ehrm... footage of the file in a hexeditor and then playing with a scanner? :-)
<iwj> Kagou: OK.
<iwj> Kamion: Does the livecd builder to dpkg --extract and then run postinsts, or something ?
<iwj> s/ to/ do/
<Kamion> iwj: no, just 'apt-get -y install'
<Kamion> there's no magic that could be at all relevant here AFAICS
<iwj> Hmm.
<Kamion> I think looking at casper will be more fruitful
<Kamion> although it doesn't do any fontconfig tweaking any more ...
<Kamion> iwj: if there's anything in the fontconfig postinst (say) that's specific to the machine (like running laptop-detect), then casper will have to reconfigure it at live CD boot
<iwj> Do we know whether this font wrongness happens on D-I installs too ?
<iwj> I confess I haven't installed either knot from CD.
<Kamion> similarly a desktop CD install (ubiquity) will just copy the read-only filesystem so if there's hardware-specific work in the postinst then it will have to be reconfigured in a ubiquity hook
<Kamion> there's no use comparing the live CD to a ubiquity install really, it'd have to be a live CD install
<Kamion> er, it'd have to be a d-i install, I mean
<iwj> No, the postinst does a lot of silly faff but it's not hardware specific.
<Kamion> I seem to remember that fontconfig does LCD detection internally now
<iwj> The LCD detection is to do with subpixel rendering IIRC.
<iwj> Or autohinting.
<iwj> But anyway not whether bitmap fonts are enabled.
<doko> going offline again ...
<iwj> I'm looking inside the casper source package and it doesn't seem to have anything relevant.
<agutierr> hi all
<agutierr> someone can I help me with preseeds, debian-installer and partman? :-) Thanks.
<Kamion> agutierr: maybe
<agutierr> I am using a preseed to auto-install workstations
<agutierr> But I have a problem: 
<agutierr> I would like to reuse partitions, without mading a new partition talbe
<agutierr> table
<Kamion> is there going to be free space on the disk?
<Kamion> or are you talking entirely about writing over existing partitions?
<mvo> Mithrandir: its uploaded and waiting for approval (apt)
* Kamion looks
<pygi> seb128, we'll just wait for libburn to release as it should be soon, then I'll bug you ^_^
<pygi> sivang, ping?
<seb128> pygi: ok
<pygi> seb128, relase is sep. 26...can we do update in debian and sync to ubuntu before the universe freeze?
<seb128> pygi: ivoks said he would have a look on them, no?
<Kamion> mvo: ok - it looks a bit inefficient in that it'll still run through the cache looking for autoremovable packages, but it'll fix the error
<pygi> seb128, before yes, but he won't be able to update in debian :) So it's easier to update it there, and just sync here, no?
* Kamion accepts
<seb128> pygi: I'm too busy to start maintain that package to Debian, so no
<janimo> mvo: hi, is the recent recommends work in the metas described somewhere? I'd like to know what I need to modify in the xubuntu seeds, and why :)
<pygi> seb128, ahm, ok then, no problem
<mvo> Kamion: going over the cache is very fast, it shouldn't be a issue
<Kamion> ok
<kagou> iwj: back
<mvo> Kamion: I can do some measurements on older hardware to verify that though
<agutierr> Kamion: I would like to mount existing partitions
<agutierr> Kamion: and format, if necesary
<mvo> janimo: I uploaded a xuubuntu-meta that is prepared for the recommends already
<Mithrandir> seb128: on the live cd, why don't I get the edgy gdm theme?
<iwj> Kamion: Do you happen to know if the livecd apt-get install -y somehow suppresses apt's usual running of the .config ?
<mvo> janimo: all you need to do now is to modify the seeds and put a () around the packages that you want as recommends
<seb128> Mithrandir: is edgy-gdm-themes installed?
<Mithrandir> seb128: yes
<Mithrandir> hmm
<Mithrandir> however, it's ancient.
<janimo> mvo: I saw you changed the meta, thanks. I was wondering if some packages _have_ to beput in recommends to play nice with ubuntu-desktop or it
<Mithrandir> oh
<janimo> is entirely optional. And what besides base install size is the motivation behind this?
<seb128> Mithrandir: what theme do you get?
<mvo> janimo: the use of recommends is complettely optional. the only case I can think of would be xubuntu-system-tools vs gnome-system-tools
<Mithrandir> seb128: ignore me, the amd64 live fs failed to build
<seb128> ok ;)
<iwj> kagou: Hi again.  I'm pretty sure your suggested change is wrong, I'm afraid, but I'm still trying to understand why it's not working the way the author intended.
<janimo> mvo: right, and evince-gtk evince maybe
<mvo> janimo: those recommends will be installed by default now, so its not really about size, more about choice
<janimo> ok
<mvo> janimo: to let user remove non-core stuff (scim, accessability etc)
* Mithrandir sighs at forgetting to check.
<janimo> Kamion: will there be usplash-theme-{k,x,ed}ubuntu packages as well?
<kagou> iwj: in fact as 30-debconf-no-bitmaps.conf and 30-debconf-yes... are not at all created we can suspect that debian/fontconfig-config-postinst is wrong no ?!
<kagou> except if $enable_bitmaps is set to TRUE
<kagou> iwj: it's why i'v suggested modifications on fontconfig-config.config
<Mithrandir> doko: prod
<Mithrandir> Unpacking ia32-libs-openoffice.org (from .../ia32-libs-openoffice.org_15_amd64.deb) ...
<Mithrandir> dpkg: error processing /var/cache/apt/archives/ia32-libs-openoffice.org_15_amd64.deb (--unpack): trying to overwrite `/etc/java/security/security.d/1000-gnu.java.security.provider.Gnu', which is also in package java-gcj-compat
<iwj> We can definitely conclude that the debconf key is being set to true.  (Not TRUE.)
<iwj> The question is, why ?
<kagou> if /etc/fonts/fonts.conf exist i don't see why we have to set to true
<Mithrandir> doko: ^^ ; This is a blocker for knot 3.
<Nafallo> [12:08]  <doko> going offline again ...
<kagou> iwj: may be /etc/fonts/fonts.conf is installed before fontconfig-config.postinst is called. So enable bitmaps is set to true
<Mithrandir> Nafallo: sigh, ok, thanks.
<Mithrandir> dholbach: Setting up human-theme (0.1-0ubuntu2) ...
<Mithrandir> update-alternatives: unable to make /usr/share/icons/default/index.theme.dpkg-tmp a symlink to /etc/alternatives/x-cursor-theme: No such file or directory
<dholbach> Mithrandir: Kamion already fixed it
<Mithrandir> ok
* dholbach hugs Kamion
<Kamion> agutierr: I think you may have to write your own partman script to do that unfortunately; I don't think partman-auto can do it natively
<agutierr> Ok
<Kamion> iwj: I'm pretty certain it doesn't. Note however that debconf will be running in noninteractive mode (and thus db_input will return non-zero etc.).
<Kamion> iwj: (it's not apt that runs the .config - it's debconf, via the sourcing of /usr/share/debconf/confmodule from the .postinst)
<Kamion> janimo: usplash-theme-ubuntu is misnamed - should've been ubuntu-artwork-usplash. You already have a xubuntu-artwork-usplash.
<Kamion> iwj: what debconf key is this?
<Kamion> er s/key/question/
* Mithrandir retries the livefs builds.
<Mithrandir> Kamion: I guess we need new alternate CDs too?
<Kamion> Mithrandir: after apt has built, yes
<Mithrandir> oh, we need that too, yes.
<Mithrandir> is that needed for the live cd?
<Kamion> iwj: oh, I think I see what's happening
<Mithrandir> (shouldn't be?)
<Kamion> iwj: somebody has fundamentally misunderstood how debconf runs
<Kamion> Mithrandir: probably, yes - ubiquity will get upset otherwise
<Kamion> (maybe)
<Mithrandir> Kamion: oh well, I get to exercise the buildds a bit, then.
<Kamion> actually ubiquity uses --no-upgrade so it might not matter
<Kamion> iwj: so, the .config script actually gets run twice. (It MUST be idempotent.)
<Kamion> iwj: The first time is during preconfiguration, before anything has been unpacked; so /etc/fonts/fonts.conf won't be there
<agutierr> Kamion: do you know if ubuntu-installer with preseeds uses debian-installer ?
<Kamion> iwj: The second time is while the package is being configured; IIRC conffiles are moved into place before the postinst is run, so /etc/fonts/fonts.conf is there
<Kamion> agutierr: "uses" does not make sense, but the Ubuntu installer is a derivative of debian-installer
<Nafallo> maswan: ping
<agutierr> ok
<fabbione> Kamion: i think he means for the preseed strings where you use debian-installer
<Kamion> fabbione: I think he should be more specific then :-)
<Kamion> agutierr: ?
<fabbione> Kamion: that too :)
<carlos> pitti: hi, I'm going to move language pack generation earlier every day
<Kamion> iwj: I'm trying to work out what the best fix would be
<carlos> pitti: and move back edgy lang packs to be generated daily now that the process has been optimised
<pitti> carlos: cool
<Kamion> unfortunately (well, in this particular case), db_input does not mark a question as seen if it was never shown (i.e. you aren't running at priority low)
<carlos> pitti: I will give you concrete times after tomorrow's export
<Kamion> so you cannot use the seen flag as an indicator
<iwj> Kamion: Oh.
<zyga> carlos: nice :)
<iwj> I didn't realise that .config was run via the postinst like that.
<Mithrandir> infinity: can you byhand the publisher for me?  I need to roll a new ia32-libs-ooo and won't make :03
<carlos> zyga: are you still using those tarballs?
<maswan> Nafallo: pong
<iwj> The whole scheme is rather crazy.  All of this copying a single bit into a complex encoding involving the existence or not of several files and symlinks.
<zyga> carlos: not at the moment but I'll resume the old stuff after I'm finished with cnf
<zyga> probably for edgy+1
<zyga> (s/probably/for sure/)
<carlos> zyga: people.ubuntu.com/~carlos/language-packs is the new location
<zyga> I hope you don't store every single one :)
<Kamion> .config being run from .postinst is arguably a debconf bug, but (a) would require explicit support for preconfiguration in dpkg to fix and (b) is probably impossible to change now anyway.
<iwj> No, I think it's fine.  But it does explain the difficulty.
<carlos> zyga: I remove them from time to time
<pitti> carlos: hm, you use language-packs/dapper instead of dapper-updates
<Kamion> (It has to be run from the .postinst because if you aren't using apt then preconfiguration won't happen.)
<iwj> Yes.
<zyga> carlos: right, thanks
<iwj> Err, I see.
<carlos> pitti: hmm.... then I did a mistake yesterday... anyway, I will fix it now in my side, sorry
<Kamion> I think the basic problem is that its test for are-we-upgrading in the .config is wrong.
<iwj> That's not readily fixable, I think.
<Kamion> Find some other way to do that than testing for the conffile and it'll probably become idempotent.
<iwj> Yes.
<zyga> carlos: rosetta-edgy.tar.gz is -> current, right?
<iwj> Err, it unconditionally sets the debconf key./
<carlos> pitti: fixed
<iwj> Surely it would make more sense for it just to default the debconf key ?
<carlos> zyga: is latest snapshot, it's not the on in our official archives
<Kamion> iwj: I don't think it can. Boolean questions don't have a "not set yet" state, and as I said above it can't use the seen flag to help.
<Kamion> As in, I don't think it can without breaking other thing.
<Kamion> s
<rodarvus> dholbach, I forgot to upload my package of telepathy-inspector 0.3 to p.u.c yesterday, sorry
<rodarvus> its there now
<janimo> Mithrandir: exception req for xubuntu main: add newer version of xfwm4 mostly with bugfixes
<dholbach> rodarvus: no problem - we're storing all the packaging in bzr now
<Mithrandir> janimo: do you need it for knot?  If not, I'd recommend holding it off.
<janimo> Mithrandir: as usual not critical, just in case spinning CD for the other releases takes time.
<janimo> Mithrandir: ok I'll hold off then
<Mithrandir> janimo: your call though, it's xfce-only.
<dholbach> rodarvus: so if you get the time to do that, it should be easy for us to review/update it and upload it
<dholbach> rodarvus: thanks for your efforts!
<rodarvus> thank YOU
<Kamion> Unfortunately there's nothing that the postinst does that can easily be tested for in the config. What you really want to know is "has the postinst ever run".
<dholbach> rodarvus: http://wiki.ubuntu.com/Telepathy/InBzr
<rodarvus> telepathy-inspector is developed by a friend of mine, and he asked for help getting it into Ubuntu ;)
<seb128> trying the current i386 desktop CD, bbl
<dholbach> rodarvus: NICE
<dholbach> rodarvus: it looks pretty cool
<dholbach> rodarvus: and the packaging looked good to me too
<dholbach> rodarvus: I just noted there was 0.3.0 upstream already
<Kamion> iwj: There's one hack that would work. It would probably get things wrong if anyone ever blew away their debconf db, but at worst it would have the wrong default for the question on the next upgrade (and perhaps not even that)
<janimo> dholbach: haven;'t looked yet, is telepathy relying on gnome libs or just has parts which work with gnome?
<rodarvus> dholbach, it uses scons, which is rather different from anything autotools related
<pygi> rodarvus, but scons rules, compared to autotools :)
<rodarvus> version 0.2.5.1 had a few bugs (and one bug on the packaging)
<rodarvus> which were fixed on 0.3
<Kamion> iwj: at the end of the postinst, 'db_fset fontconfig/enable_bitmaps processed true'
<janimo> pygi: s/scons/anything/
<Kamion> (processed is an arbitrary identifier)
<pygi> jamesh, hehe :)
<dholbach> janimo: the framework uses glib, dbus, gstreamer stuff and its own libs - some frontends might make small use of gnome stuff (python, etc)
<pygi> janimo, hehe*
<pygi> dholbach, there is that C#/Mono telepathy client which even works :)
<dholbach> rodarvus: ah nice, so it might be worth to get 0.3.0 in
<iwj> Kamion: Hmmm.
<dholbach> pygi: which one is that?
<zyga> mvo: what is curentArchOnly for, in practice?
<rodarvus> pygi, scons is nice - I just wish it had more plugins available by default (so you don't have to do it all by yourself)
<Kamion> iwj: then in the config, replace 'if [ ! -f "/etc/fonts/fonts.conf" ] ' with 'if ! db_fget fontconfig/enable_bitmaps processed || [ "$RET" != true ] '
<zyga> mvo: since we have arch=all now
<rodarvus> dholbach, its done already :)
<dholbach> we should move telepathy discussion probably to #ubuntu-desktop
<pygi> dholbach, I forgot, but I can look for it :P
<dholbach> rodarvus: rock and roll :-)
<pygi> rodarvus, true :-/
<rodarvus> I'll create a product on LP for it too
<Kamion> iwj: I believe I'm just about the only person who ever uses flags that way, but it is supported :-)
* dholbach hugs rodarvus
* rodarvus hugs dholbach back
<mvo> zyga: just sugar, if we ever want to pre-caclculate it
<Kamion> you might want to add a check for reconfiguration or something too, but the above should fix the live CD case with minimal fallout
<Kamion> and in fact the general first-install case
<pygi> janimo, you coming to Hungary, right? 
<zyga> mvo: it adds an dependency on dpkg 
<iwj> Kamion: Is this documented somwhere ?
<iwj> I mean, this use of a `processed' flag ?
<mvo> zyga: how do you mean?
<zyga> mvo: you need dpkg and python2.4 to run that
<zyga> but I'm just picky
<janimo> pygi: I promised, so I think I am 
<Kamion> iwj: flags in general are documented in /usr/share/doc/debian-policy/debconf_specification.txt.gz
<Kamion> iwj: the use of a made-up processed flag is an invention
<pygi> janimo, nice, see you there perhaps ^_^
<janimo> pygi: :)
<iwj> Aha.
<pygi> janimo, I am supposed to talk, don't know yet if I'll be able to attend :P
<Kamion> It's just a way to transmit state around
<Kamion> (As if fontconfig-config.* needs any more such ways ...)
<iwj> Quite.
<iwj> I think I'll do as you suggest but it seems to be just adding wrongness to an already very wrong thing.
<Kamion> I agree
<kagou> iwj: can you understand the if "/etc/fonts/fonts.conf" file exist -> # We are upgrading. No file for bitmaps means: -> enable_bitmaps="true" ?
<Kamion> kagou: See near the end of the postinst where it doesn't create a symlink if enable_bitmaps is true because that's the fontconfig default
<Kamion> it's convoluted, but at least consistently so
<pygi> janimo, o yes, wanted to discuss something with you = xubuntu related, so when you get time ;)
<janimo> pygi: -> /msg now
<Kamion> iwj: the alternative would be to always create the symlink (uncomment the above bit in the .postinst) and use the existence of either symlink as a "we're upgrading" indicator
<Kamion> iwj: you'd have to think very hard about upgrades, either way
<janimo> Kamion: does usplash select the appropriate png depending on detected resoluion? So artworks should have all 4 or so variants?
<kagou> Kamion: what is the default for edgy : to enable or not bitmaps ?!
<Kamion> janimo: yeah, it iterates through the linked list of themes in the theme library and picks the first one that will fit in the specified resolution
<Kamion> kagou: I neither know nor care; I'm just saying how to fix the code
<Kamion> iwj: (There's an argument that depending on filesystem state is better than depending on debconf database state, so maybe the latter approach would be better.)
<kagou> Kamion: you think that if we create 30-debconf-yes-bitmaps, fonts will be well rendered ? I think no. 
<kagou> may be i'm wrong i will test this...
<Kamion> kagou: I don't know. Don't talk to me about how fonts will actually look. I'm just being a "how to use debconf correctly" person.
<kagou> oh :)
<Kamion> And it's obvious that the current code is incorrect (because the config script isn't idempotent across the two runs in a fresh installation with preconfiguration), regardless of what it's intending to do
<Kamion> If we fix it to actually work right, then it'll be a lot easier to make the default swing either way
<zyga> mvo: hmm, should I mirror and re-scan with ia64 and hppa?
* StevenK wonders how large the mirror push for Ubuntu is per day
<zyga> StevenK: not so large
<zyga> StevenK: now it's pretty stable :)
<rodarvus> dholbach, did you create a Telepathy project to include all telepathy-related products?
<dholbach> rodarvus: yes - http://wiki.ubuntu.com/Telepathy
<mvo> zyga: oh jesus ... hppa/ia64 
<Treenaks> dholbach: I knew you were going to say that :P
<mvo> zyga: don't forget sparc ;)
* Mithrandir twiddles thumbs while ia32-libs-ooo uploads
<dholbach> rodarvus: I'd love to see all the goodness in to play with it and make upstream's life easier :-)
<StevenK> zyga: I'm just wondering if it's less than 30Gb a month, and how large the archive is.
<StevenK> (For i386, amd64, sparc and all)
<StevenK> I should really be doing an assignment, but whatever. :-P
<rodarvus> dholbach, no, I mean a 'Project' on LaunchPad
<dholbach> ahhhhh!
<rodarvus> so I can inform it when creating the telepathy-inspector product
<dholbach> no, I didn't know where to do that
<dholbach> but it'd make sense
<rodarvus> indeed
<Kamion> mjg59: I think I'm going to change the installer always to install usplash as part of desktop, rather than hacking it in first. That way it can rely on the result of xserver-xorg.config
<mvirkkil> pain and suffering with edgy :(
<dholbach> rodarvus: https://launchpad.net/projects/+new -> Sorry, you don't have permission to access this page.
<Nafallo> hmm
<Nafallo> something throws Generic_Recipe_Edgy_agreement.html into my ~ all the time. anyone else got that? :-P
<mvirkkil> I installed edgy on an oldish computer, it's not booting all the way to gdm, though gdm comes up when started manually.
<mvirkkil> After logging in I get a notice about some HAL failure.
<mvirkkil> And nautilus and a lot of other programs don't work.
<mvirkkil> I'm suspecting some dbus issue, but that's just a guess.
<pitti> mvirkkil: please file a bug against hal and do the steps on the second half of https://wiki.ubuntu.com/DebuggingRemovableDevices
<pitti> mvirkkil: it most likely is a dbus failure if it worked for you before and you didn't change hardware
<mvirkkil> pitti: well, one piece of hardware which wasn't supported in dapper, and should be in edgy (but in reality isn't, I'm buggind u-kernel about it).
<mvirkkil> pitti: I'll try booting without it, to see if it makes a difference. Otherwise I'll file a bug. Thanks :)
<infinity> Mithrandir: Gah, missed your request to drive the publisher by hand, sorry.  Was having a late dinner.
<pitti> mvirkkil: nevertheless, filing a bug would be appreciated if it is due to that hardware
<pitti> mvirkkil: even if it isn't supported, it doesn't mean that it should make the system unusable
<Mithrandir> infinity: no problem.
<Mithrandir> infinity: it takes almost a full cycle to upload anyway.  Hooray for huge .tar.gz-s
<infinity> Yeah.
<Kamion> Mithrandir: should I accept xfwm4?
<mvirkkil> pitti: and in this case it should be supported :) The kernel got a patch just for this piece (new zydas1211b chip)
<Mithrandir> Kamion: I let that call be janimo's, so if he uploaded it, yes.
<Kamion> ok, accepted
<mvirkkil> pitti: removing the hw didn't make any difference :(
<mvirkkil> pitti: booting without it, that is..
<mvirkkil> oh well, I'll start looking in to what's up.
<pitti> mvirkkil: thanks
<mvirkkil> pitti: hmm.. Hal isn't running after bootup
<Kamion> I do wish dpkg had a package relationship field that said "please configure me after package A if A is to be installed, but don't worry about it if it isn't"
<pitti> mvirkkil: well, that's what the message said :)
<StevenK> Kamion: What, Half-Depends? :-P
<infinity> Kamion: A soft-depends?
<Kamion> maybe Recommends or Suggests should do that
<Kamion> yeah
<pitti> mvirkkil: please do the debugging steps, it might point out the source of the problem
<Kamion> because I want usplash to be configured after xserver-xorg if possible, but I don't want to make usplash require X
<infinity> Kamion: Don't Recommends and Suggests already try to order packages in a dependency chain (barring loops)?
<pitti> Kamion: Ladies-First: :)
* Hobbsee wonders what the ugly ALPS hack for xserver-xorg-input-synaptics is  - the latest update is making my touchpad on crack.
<Kamion> pitti: heh
<Kamion> infinity: if they do, that would be ideal, but I didn't know about it
<infinity> Kamion: If my guess is correct, having usplash suggest xserver-xorg should be good enough.
<Mithrandir> Kamion: sounds like a sensible (and easy enough to add) thing for dpkg to do.
<Kamion> iwj: any wisdom on this?
<infinity> Kamion: The reason I'm guessing this isn't so much because it makes sense (though it does), but because I'd expect as much code re-use as possible in those areas.
<infinity> Actually, wait.  dpkg doesn't do loop unrolling and reordering at all, does it?  Doesn't apt do that?
<Kamion> At configure time, apt passes a big load of packages to dpkg --configure and says "do it", as far as I know
<infinity> I seem to recall a few days ago doing "dpkg -i foo.deb foolib.deb" and having to do two passes, since the first complainted about foo and then worked with foolib.
<Kamion> infinity: was Pre-Depends involved?
<infinity> Heck if I can recall. :)
<Kamion> if not, I'd say that's a dpkg bug. According to the comment above deferred_configure, it's meant to keep going round the packages in a loop until it's done as much as it can
<mvirkkil> pitti: hald stops running after printing (a boatload of) messages.
<pitti> mvirkkil: can you please attach that log to the bug report?
<Kamion> I don't see anything that handles Recommends or Suggests the way you mention, anyway
<janimo> Kamion, what is the development section of the seeds? It is included in ship, but ship alreday has the components in devel. Is it used elsewhere too?
<Kamion> janimo: it's intended to become a task for use by tasksel. It shouldn't be included in ship
<Hobbsee> mjg59: have you heard of any other regressions with the alps hack in xserver-xorg-input-synaptics?  I'm getting bug 47971, as are some other edgy people, it seems.
<Ubugtu> Malone bug 47971 in xserver-xorg-input-synaptics "synaptics touch pad(laptop) clicks when i dont want it to" [Critical,Confirmed]  http://launchpad.net/bugs/47971
<Kamion> janimo: err, you mean the "development" seed, right?
<janimo> Kamion: yes
<Kamion> the one starting with python-adns?
<janimo> yes
<Kamion> that's definitely not included in your ship
<janimo> not in ship, but in the STRUCTURE file after ship:
<janimo> oh, sorry supportted
<Kamion> ship: boot minimal standard desktop
<janimo> yeah, they both begin with an s
<Kamion> supported: in STRUCTURE should always list all the other seeds
<janimo> aha. ok that makes sense then.
<Kamion> because everything you seed is by definition supported
<janimo> ok, sorry for the noise
<Kamion> fabbione: could you add lvm2 to the list of problems at the end of https://wiki.ubuntu.com/GccSsp ?
<infinity> Kamion: Oh, hrm.  Seems a sane wishlist, then.  And what I'd expectas resonable behaviour.
<infinity> Kamion: Actually, maybe that behaviour's backward.  Perhaps Enhances would be a better way to express that you should configure Y before X.  Or something.
<StevenK> infinity: Hey yeah, that actually makes sense.
<Kamion> In the absence of that, I wonder how to deal with getting xserver-xorg configured before usplash. Maybe I should hack this into tasksel somehow.
<Kamion> infinity: logically I'd expect Recommends to have similar ordering to Depends
<janimo> is the alternate CD installer accessible? Does it make sense to have a11y in ship (as opposed to ship-live) in xubuntu?
<Kamion> janimo: not yet
<infinity> Kamion: Yeah, I'd expect Recommends to be similar to Depends, I'dexpect Suggests to be backwards, perhaps.  I'm a bit fuzzy on that.
<mvo> infinity: will you have time later to talk about the auto-dist-upgrade testing and where we could set it up?
<infinity> mvo: Did we ever get past elmo's "I don't want that crap on the buildds" and perhaps get some extra DC hardware for it?
<infinity> mvo: If not, we eitherneed to talk to elmo, or you and I can set it up outside the DC (I'm happy to host the PowerPC one, for instance)
<mvo> infinity: ok. my memory is that he disliked the specific approach how it was implemented when I/we proposed it, but I may be wrong :) [I reworked it since then] 
<iwj> Kamion: I think I'll write down all of the states that this madness might encounter and see if they're distinguishable.
<iwj> I'll try to think of a plan and talk to you after lunch.
<infinity> mvo: Well, yes.  We should perhaps re-discuss this, then. :)
<mvirkkil> pitti: https://launchpad.net/distros/ubuntu/+source/hal/+bug/60219
<Ubugtu> Malone bug 60219 in hal "Hald exits after starting" [Untriaged,Unconfirmed]  
<mvirkkil> oh :)
<pitti> mvirkkil: thanks
<pitti> mvirkkil: your first contact to ubugtu? :)
<Kamion> iwj: Thanks. I have an alternative plan anyway so it's not at all urgent.
<mvirkkil> I'll be glad to provide any other information you might need
<mvirkkil> pitti: no, just forgot it existed.
<pitti> 14:35:49.721 [E]  hald_dbus.c:3258: dbus_bus_get(): Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
<mvirkkil> pitti: I was just as surprised last time.
<pitti> hmm
<mvirkkil> so it seems it's a dbus problem
<pitti> mvirkkil: ps aux|grep dbus-daemon?
<Mithrandir> doko: hope you're ok with my ia32-libs-ooo upload; I just nuked /etc/java/security from the package.
<mvirkkil>  /usr/bin/dbus-daemon --fork --print-pid 8 --print-address 6 --session
<pitti> mvirkkil: ok, so no system daemon
<pitti> mvirkkil: let's continue this in /msg
<mvirkkil> pitti: note though that now I've started gdm manually and logged in etc.
<pitti> mvirkkil: did you get my private message?
<theine> Is tepepathy in Edgy actually usable right now (i.e. with Google Talk)?
<iwj> Kamion: Right.
<doko> Mithrandir: ahh, ok. missed that. Did you freshen the packages as well (don't see the install mail yet)
<Mithrandir> doko: no, I didn't see a point in doing that.
<pitti> seb128: mvirkkil's problem is that /etc/rc2.d is almost empty
<pitti> seb128: you had the same problem, right?
<pitti> seb128: is there a bug about it, so that I can make bug 60219 a dup?
<Ubugtu> Malone bug 60219 in dbus "system dbus not started at boot" [Untriaged,Needs info]  http://launchpad.net/bugs/60219
<seb128> I had only README left from all the /etc/rc[0-6] .d
<seb128> pitti: the bug I had had been fixed quickly
<mvirkkil> seb128: well, I've got almost nothing. 
<pitti> seb128: was that a transient upstart bug?
<seb128> pitti: I just got that "failed to initialize HAL!" message right now
<seb128> pitti: no, it was a transition gnome-system-tools services-admin bog
<mvirkkil> seb128: it's  because hal failes to start because dbus isn't alive
<pitti> seb128: I guess the dbus rc2.d symlink is missing for you as well?
<seb128> pitti: and I didn't got it this morning, so it's probably due to a recent update
<seb128> lrwxrwxrwx 1 root root 14 2006-09-09 00:04 /etc/rc2.d/S20dbus -> ../init.d/dbus
<jono> if I want to book a meeting in #ubuntu-meeting - do I just choose a time that doesnt conflict with another meeting and mail the fridge team about adding it to the calendar?
<mjg59> Kamion: Sure
<seb128> jono: seems good
<tseng> jono: sounds pretty reasonalbe
<jsgotangco> pretty much i guess
<Hobbsee> jono: yep
<pitti> mvirkkil: ok, so since this seems to have been fixed in a later gnome-system-tools, can we close that bug?
* Hobbsee wonders what meeting
<jono> ok cool :)
<pitti> seb128: thank you
<jono> gonna book a LoCo meeting :)
<jono> thanks folks
<seb128> pitti: np
<Hobbsee> jono: fun :)
<jono> Hobbsee, we should talk today about Kubuntu :)
<seb128> pitti: bug #60219 doesn't look like that g-s-t issue
<Ubugtu> Malone bug 60219 in dbus "system dbus not started at boot" [Untriaged,Needs info]  http://launchpad.net/bugs/60219
* jsgotangco hopes its not a time that would require us in the other side of the world to wake up at 3am ;)
<pitti> seb128: well, something erased mvirkkil's /etc/rc2.d/
<Hobbsee> jono: perhaps.  i've actually got an assignment that i'm supposed to be doing at the moment, but clearly am not.
<seb128> mvirkkil: did you use services-admin?
<realist> Hobbsee: could you direct me where to look for package upload sponsors?
<mvirkkil> seb128: I don't think so :O)
<Hobbsee> realist: universe or main?
<seb128> mvirkkil: did you played with the NTP option from times-admin?
<realist> Also, is there a list of orphaned packages for adoption?
<Hobbsee> realist: poke someone in #ubuntu-motu to upload it for universe, or subscribe-ubuntu-universe-sponsors
<realist> Hobbsee: universe at this stage
<jono> Hobbsee, later this week ?
<Hobbsee> realist: you can modify almost anything you like - there arent set "maintainers"
<Hobbsee> jono: should be fine
<jono> :)
<mvirkkil> seb128: Well, I installed ntp support by going through the clock applet
<realist> Hobbsee: is that intentional ?
<seb128> mvirkkil: did you get that issue just after that? for how long do you have the issue?
<Hobbsee> realist: yes
<realist> I don't want to end up reproducing other people's work
<realist> Or touching other people's code base...
<mvirkkil> seb128: I did a fresh install yesterday of knot2 and I've been upgrading and dist-upgrading ever since (slow net connection)
<seb128> hum
<fabbione> Kamion: sure
<mvirkkil> seb128: so this is a pretty clean install.. 
<seb128> mvirkkil: ah, knot2 might have had the boggus version
<mvirkkil> seb128: so, what can I do to repair the situation?
<seb128> reinstall :/
<pitti> mvirkkil: cp -a /etc/rc3.d/* /etc/rc2.d
<seb128> hum
<seb128> rc3.d is ok?
<pitti> (provided that the other runlevels are still intact)
<mvirkkil> no
<pitti> oh
<seb128> that bug cleaned rc[0-6] .d on my box
<mvirkkil> none of the runlevels have anything useful.
<pitti> mvirkkil: then you are pretty screwed, I'm afraid
<mvirkkil> A re-install will take me two days.
<Kamion> aptitude reinstall '~i' (?)
<Kamion> dunno if that will work
<Kamion> or dpkg-reconfigure every package that has update-rc.d in its postinst
<Kamion> you'd get quite a lot of questions, but you wouldn't have to re-download anything
<mvirkkil> How about someone tar their /etc/rc?.d/ and send that to me?
<Kamion> you're much safer doing the above
<seb128> would require somebody having your exact config
<pitti> mvirkkil: that would cover different packages, etc.
<Kamion> oh, 'dpkg-reconfigure --default-priority' to get fewer questions
<seb128> dpkg-reconfigure on the packages using update-rc.d should be fine
<mvirkkil> how can I find out which packages those are?
<seb128> I did something like that and got my box booting again correct
<seb128> grep update-rc.d /var/lib/dpkg/info/*.postinst
<Kamion> cd /var/lib/dpkg/info; grep -l update-rc.d *.postinst
<mvirkkil> ok, I'll do that. Thanks for yourhelp :)
<seb128> np, sorry for the breakage
<pitti> mvirkkil: for i in `grep -l update-rc.d /var/lib/dpkg/info/*.postinst`; do i=`basename $i`; sudo dpkg-reconfigure ${i%.postinst}; done
<pitti> mvirkkil: ok, you should have enough shell runes now :)
<Mithrandir> Kamion: argh, I forgot to ask you to accept the new ia32-libs-ooo; mind doing that?
<Kamion> Mithrandir: will do
<mvirkkil> 56 packages...
<Kamion> pitti: (dpkg-reconfigure can be given a list of packages)
<pitti> right, there's certainly room for optimization
<Kamion> probably doesn't matter for 56 packages
<Kamion> smurf: is there a way to blacklist certain keysyms from certain keymaps in keymapper?
<realist> Hobbsee: I don't quite understand how there can be any quality control, if anyone can change any package in the universe repository?
<Hobbsee> realist:  see #ubuntu-motu
<Kamion> smurf: the X keymap for gb includes latin, which lists a lot of symbols on AltGr which aren't typically engraved on UK keyboards
<Kamion> smurf: so if you just go through the keymap detector without knowing about this, you get US, because it asks if you have an "" key and of course you say no
<Kamion> but actually AltGr-a gives 
<Mithrandir> Kamion: ISTR hacking keymapper to not look at level 3 or 4 maps.
<Kamion> Mithrandir: and uploading the result? :)
<Kamion> thing is, we'd need that to be done only for certain keymaps ...
<zul> hi, can someone new the xen-image kernel generic stuff for me?
<Mithrandir> Kamion: no, since it's part of the "parse X11 keymaps" bit of keymapper rather than the console-* bit of keymapper.
<Kamion> zul: done
<zul> Kamion: thanks..
<Kamion> zul: shouldn't -amd64-generic be renamed to -generic, to match the mainline kernel?
<zul> Kamion: it probably should...ill do it for the next upload
<Kamion> thanks
<doko> seb128: ping
<Mithrandir> hmm, ubuntu-server's ports seems to fail to build
<fabbione> Mithrandir: hppa is non-existant in edgy
<fabbione> Mithrandir: what's the problem with ia64?
<Riddell> Kamion: could you check, merge and upload my ubiquity branch, it's got a fix to enable the Install button on the last page
<Mithrandir> fabbione: unsure.  It seems to die with tar: ./usr/lib/debootstrap/scripts/edgy: Not found in archive
<Kamion> Riddell: knot-3 urgent I guess
<Mithrandir> fabbione: I'll investigate later, now I want to get alternate cds built.
<Riddell> Kamion: yes, won't install without it
<Mithrandir> Riddell: "ouch".
<fabbione> Mithrandir: ok
<Mithrandir> Kamion: is there anything you know of holding the alternate cds back?
<mvirkkil> Yay, seems to be working now (after an additional dpkg-reconfigure dbus). Thanks guys. Now if I could just get my wlan dongle working (the reason I installed edgy in the first place)
<pitti> mvirkkil: \o/
<jdong> is OOo to be rebuilt soon?
<jdong> or are we shipping knot3 with unusable OOo?
<simira> ~
<Mithrandir> jdong: OOo seems to work fine for me in knot 3
<jdong> Mithrandir: you can save new documents without crashing?
<Riddell> Mithrandir, Kamion: I noticed that openssh-client isn't installed by default, seems the recommends from ubuntu-standard don't get in
<jdong> Mithrandir: bug 58508... it's due to the dbus 0.92 change
<Ubugtu> Malone bug 58508 in openoffice.org "cant save under edgy" [High,Confirmed]  http://launchpad.net/bugs/58508
<Kamion> hmm, remind me to make "Device for boot loader installation:" translatable at some point
<Mithrandir> jdong: not new ones.  Old ones seem to work.  *shrug*; too late.
<ogra> Mithrandir, how are you able to install knot3 ? is the apt fix on the CDs ?
<jdong> Mithrandir: I know; too late :-/
<Mithrandir> ogra: I'm about to build alternate cds now.
<Riddell> Kamion: will do.  did you notice that the dialogue said "blah" in it when you did the last merge? :)
<ogra> ah, cool !
<Kamion> Riddell: I think it flicked past my consciousness but I was past caring
<Kamion> it had probably been a long day or something :)
<Nafallo> Mithrandir: don't forget to write it down in the release mail as a critical bug though :-P
<Mithrandir> Nafallo: point.
<Mithrandir> ogra: I'll tell you when you have ISOs
<Kamion> Mithrandir: let me look into Riddell's openssh-client issue first please?
<Mithrandir> Kamion: 'k
<Nafallo> s/ :-P//
<simira> hi sladen 
<Kamion> oh, argh
<ogra> Mithrandir, thanks :)
<Kamion> ok, probably easy to fix, just need to upgrade germinate on lithium I think
* sladen gives Kamion a lollipop
<Mithrandir> Kamion: so I should just kill the current cd build?
<Kamion> yeah
<simira> woooah
<simira> the rainforest just stepped into my workplace...
<Kamion> the overrides in the archive are broken, though
<simira> *installing edgy current*
<ogra> you have rainforest in norway ? 
<simira> ogra: ubuntu ships it
<simira> anywhere
<ogra> ah
<Kamion> we need to upgrade germinate on drescher somehow, but that's complicated with dapper-updates closed for business at the moment
<Kamion> it'll have to wait
* ogra hast seen new ubuntu artwork since quite some time :)
<Kamion> Mithrandir: ok, you can probably build now
<simira> ogra: this was more a sound-experience
<ogra> ah
<Mithrandir> Kamion: ok, building.
* robertj egads! I'm seeing 5 meg/sec uploads to XDrive...I hope someone gets a FUSE module out soon :)
<Riddell> Kamion: actually none of the recommends are installed from any seed
<Mithrandir> robertj: just write one?
<robertj> Mithrandir: hehe, I've got my hands busy with other pet projects ;)
<Kamion> Riddell: yes, same reason, fixed by upgrading germinate on lithium
<robertj> I'm very impressed that they aren't entirely crapped out though
<ogra> Kamion, ouch, does that mean that my next CD build can be oversized again ? 
<Kamion> ogra: yes
<ogra> (i dont have much time left anymore today)
<ogra> gah
<Kamion> the same bug rendered the CDs rather small
<ogra> sh*t
<Kamion> ogra: I hope you didn't go "woohoo" and stuff more things into it
<Kamion> if you did, you'd better take them out again
<ogra> well, not yet ... there are still 20M free
<robertj> Mithrandir: although it might not be as easy as say GmailFS because it uses a java applet to do checksumming & such before sending
<ogra> but i was planning to
<Kamion> Mithrandir: could you do Edubuntu alternate early so that ogra can have something to work on?
<ogra> that'd be nice, yes :)
<Mithrandir> Kamion: yes, I'll do it when ubuntu finishes (since it's already building)
<Mithrandir> robertj: there's no info on their pages about what APIs they have, but I suspect they have something nicer than a web UI as they have something that integrates into windows explorer.
<simira> Kamion: I am stuck in the installer. When I choose "Manually edit partition table" and click "next", it just seems to be loading, but nothing happens
<simira> Kamion: current Edgy
<tseng> Mithrandir: ping
<Mithrandir> tseng: hi dude
<tseng> Mithrandir: looking at ajmitch's bug about mono on a livecd not finding a config file
<tseng>  open("/casper/filesystem.squashfs/usr/etc/mono/config",
<tseng>           O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
<tseng> do you have an idea why something would get that path?
<tseng> is presumably the "wrong" path
<Mithrandir> tseng: see https://launchpad.net/distros/ubuntu/+source/launchpad-integration/+bug/60071
<Ubugtu> Malone bug 60071 in launchpad-integration "Gets confused when using --translate --pid $pid on the live cd" [Untriaged,Unconfirmed]  
<infinity> Kamion: php5 heading to incoming is meant for post-knot (ie: don't ask if it needs approving, just leave it be)
<Mithrandir> looks like the same bug
<Kamion> simira: need /var/log/syslog and /var/log/partman in a bug report against partman-base, please
<Mithrandir> tseng: it looks like an unionfs bug, really.
<simira> Kamion: it's skipping keyboard layout as well. Something's real buggy here
<tseng> Mithrandir: really, you think the app should be changed?
<Kamion> simira: could be entirely disconnected
<Kamion> simira: since we replaced the keyboard handling recently
<Mithrandir> tseng: unsure.  I thought it was just the /proc/$pid/exe symlink which was wrong, but now I'm wondering if realpath does something weird, or something.
<Kamion> I'd like a separate bug on console-setup about the keyboard handling, with /var/log/syslog attached
<Mithrandir> tseng: I don't have a live cd booted here just now, but I'll investigate it
<simira> Kamion: I'll do
<mvirkkil> Would anyone be interested in helping me get to the bottom of the issues mentioned at https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/60222 ? I tried #ubuntu-kernel but no-one seems to be awake.
<Ubugtu> Malone bug 60222 in linux-source-2.6.17 "zd1211rw tries to load firmware from wrong file" [Untriaged,Unconfirmed]  
<tseng> seb128: you get that?
<Mithrandir> ogra: new cds
<ogra> thanks !
<ogra> AAAAAARRRGGGGHHHHH !!!!!!!
<ogra> edgy-install-i386.iso            13-Sep-2006 14:20  761M 
<jdong> lol
<ogra> thats not even remotely solvable
<tseng> thanks alot Mithrandir 
<jdong> a bit oversized, ogra?
<ogra> so i suspect no knot3 for edubuntu 
* ogra curses loudly
<Mithrandir> ouch.
<ogra> but i wonder why ...
<ogra> it cant be that much i didnt add any stuff over dapper 
<Kamion> simira: thanks
<Mithrandir> I wonder why i386 + ppc seem to be oversized for Ubuntu, though.
<ogra> apart from small things like pessulus or student-control-panel and some kb for ltspfs it shouldnt differ from dapper
<ogra> i even dropped the linux-headers so i should have more space than ubuntu 
<Mithrandir> Kamion: any thoughts on what we can get rid of to save 5MB on i386 and 3MB on ppc?
<Kamion> I can save a bit by kicking out the old console-keymaps udebs
<tkamppeter> pitti, have you already looked at my Gutenprint package? It's my first Debian package.
<pitti> tkamppeter: oh, not yet, will do in 10 minutes, ok:?
<tkamppeter> ok
<pitti> tkamppeter: wow, that merge was terribly difficult for starting to learn about Debian source packages :)
<Mithrandir> Kamion: that needs a -meta upload, doesn't it?
<Mithrandir> or can you just twiddle the archive?
<Kamion> Mithrandir: Mark said we could drop the book and replace it with a link to the online content. Has that been done?
<bluefoxicy> did I miss doko
<Kamion> Mithrandir: no, installer seed, so it's just a seed change
<Mithrandir> Kamion: I don't think it has happened, no.
<dholbach> Kamion: no it wasn't - it'd need changes to example-content and to gnome-panel
<dholbach> rodarvus: we have 'telepathy' project now
<Kamion> dholbach: how long would that take?
<dholbach> Kamion: I'm not sure where to find the online content
<Kamion> eventually we'll be able to drop console-data and save some space, but that's not ready yet
<Kamion> jono: could you point dholbach at the right place? see above
<rodarvus> dholbach, I noticed, telepathy-inspector is there already :)
<dholbach> Kamion: example-content: easy - seb128 did the gnome-panel change, so I need to look at it first
<dholbach> rodarvus: oh right, yes
<Kamion> > I'm easy on both counts. I do think though that we should have SOME
<Kamion> > multimedia content, even if it's tighter than the old 10.6MB file. If
<Kamion> > the book is to be removed then please ensure we have prominent linkage
<Kamion> > to it on the landing page of System->Help->Online documentation. Thanks!
<Kamion> As it's large, I think it makes more sense to host it primarily online and
<Kamion> link to it, rather than bundling it on the CD for Edgy.
<Kamion> ^-- ubuntu-devel discussion, > is Mark, main paste is mdz
<jono> Kamion, I will check into where the book is now, I am not sure
<pitti> carlos: do you know why apport is not translatable in Rosetta? (https://launchpad.net/distros/ubuntu/edgy/+source/apport/+translations)
<dholbach> Kamion: I can prepare the changes and wait for jono to do it
<pitti> carlos: it has a proper .pot file which is auto-updated on build
<jono> dholbach, do you just need to know where the online content is?
* bluefoxicy goes to a job fair
<Kamion> ogra: is denemo really worth including on your CD?
<carlos> pitti: I'm still working on the new .pot files for Edgy
<carlos> I guess that's one of the missing ones
<bluefoxicy> One day I need to get paid.
<pitti> carlos: ok, so not a problem on my end?
<realist> pitti: what is the best way to submit security patches for review?
<ogra> Kamion, its a note setting app 
<carlos> pitti: let me check to be completely sure
<ogra> Kamion, and its quite small
<dholbach> jono: yes, for now it is: file:///usr/share/example-content/book-toc.html
<Kamion> yes, I know what it is, I used to maintain it in Debian
<pitti> realist: a ML, please see https://wiki.ubuntu.com/SecurityUpdateProcedures
<Kamion> it's a megabyte, and while it's nice, it doesn't seem required?
<jono> dholbach, right, and in Edgy are we just pointing to it online?
<ogra> Kamion, right, its broken as well atm ... i'l drop it
<realist> pitti: same procedure for debdiffs?
<dholbach> jono: no, not yet - we're about to do that change now :-)
<ogra> but that still doesnt explain where 80M came from 
<pitti> realist: yes, debdiffs are the prefered form of review
<Kamion> ogra: the only way to determine that is by looking through the list
<ogra> i'm looking through the log atm
<jono> dholbach, right, so we need someone online to point to where the book content will live :)
<jono> s/someone/somewhere
<carlos> pitti: confirmed and approved
* pitti hugs carlos, thank you!
<dholbach> 11,8M -> 8,6M
<realist> pitti: do we submit the tested debdiff to malone?
<ogra>  /srv/cdimage.no-name-yet.com/scratch/edubuntu/daily/tasks-previous/edgy/lamp-server
<ogra> whats that ? 
<ogra> err, and why does server-ship get added as well ? 
<pitti> realist: either that or directly to the ML (the latter is easier for review)
<dholbach> jono: exactly
<jono> dholbach, ok, so are you guys putting it online, or should someone else?
<dholbach> Kamion: what do you think: is people.ubuntu.com/~dholbach/book good enough for now?
<Kamion> ogra: huh, let me check that
<ogra> Kamion, that would explain 80MB else i'd hav no idea how it should grow by such a huge amount
<Kamion> dholbach: when it exists, sure :-)
<Kamion> ogra: yes, that's definitely a bug, I'll fix that - thanks
<dholbach> Kamion: ok, cool - I'll get working on it
<ogra> Kamion, thanks as well ... i nearly fell off my chair, that saves my day :)
<ogra> hmm, why doesnt my metapackage talk about recommends ... i thought mvo's upload should have fixed that ...
<ogra> mvo_, ?
<Kamion> ogra: hmm, are you sure? lamp-server being germinated doesn't mean it's on the CD
<ogra> hmm
<mvo_> ogra: did you changed your seeds already? used () around the stuff that should become recommends? if so, I can have a look to see what goes wrong
<ogra> mvo_, the recommends are in the package, but my update script keeps quiet about them 
<Kamion> ogra: is this your first upload of edubuntu-meta with recommends?
<ogra> yes, i changed to brackets long ago
<ogra> Kamion, nope
<ogra> the third or something like that
<mvo_> ogra: so its only  missing in the changelogs? 
<ogra> yes
<ogra> i thought your upload was supposed to fix that
<Kamion> there was nothing to fix
<Kamion> it was only ever a problem on the first upload
<ogra> hmm, k 
<Kamion> ogra: oh, what version of germinate do you have installed?
<ogra> they are in, so its fine for now ...
<mvo_> ogra: my initial version was very bad at getting the changelogs, kamion fixed it in germinate 
<ogra> Kamion, 0.22
<Kamion> that should work
<Kamion> oh, no, it shouldn't
<ogra> yes, you told me that a week ago or so
<Kamion> there was something to fix in fact :)
<ogra> oh
<Kamion> ogra: upgrade to 0.23
<ogra> ah :)
<ogra> will do
<Kamion>   * Fix recommends-related changelog entries from update-metapackage.
<ogra> but i suspect that still wont fix my 80MB issue
<Kamion> if it still doesn't work, let me know
<Mithrandir> Riddell: new kubuntu alternate images for you, FYI.
<Kamion> lamp-server is *not* being included on the edubuntu CDs; that was a false alarm
<Kamion> note how e.g. php5 isn't there
<ogra> hmm, then i suspect server-ship is neither
<Kamion> it is not
<ogra> but there are at least 50M more than should be on the CD ...
<Riddell> thanks Mithrandir 
<Kamion> for instance, zope3-sandbox isn't there
<ogra> i'd have expected an oversizedness of 10 or 15MB 
<Kamion> ok, please stop it
<Kamion> we *know* it's oversized, both of us are looking into it
<ogra> yes
<ogra> but i dont see anything suspicious
<Kamion> if you spend less time explaining how bad it is, you'll have more time to investigate. :)
<ogra> :)
<dholbach> Kamion: gnome-panel is test-building
<Kamion> I wonder why libglib1.2 is back on the Edubuntu CD
<Kamion> gs-esp has a new dependency on libglib1.2
<ogra> ouch
<Kamion> not ouch, libglib1.2 is small
<ogra> didnt we want to drop it from main ages ago ? 
<ogra> or was that only gtk1.2
<infinity> That was gtk1.2
<ogra> to be honest i dont see *anything* that would cause such a huge oversizedness ...
<pitti> ogra: we *want* to drop both, unfortunately we can't
<tkamppeter> The newest SVN state of ESP GhostScript auto-detects which GTK is there and uses GTK2 if possible.
<infinity> pitti: Has either of us (okay, that's a trick question, I know I haven't) looked at ReducingDuplication for edgy yet?
<dholbach> Kamion: ok to upload gnome-panel and example-content?
<dholbach> Mithrandir too: ^
<tkamppeter> For what does GhostScript need libglib1.2?
<Kamion> no idea, I just saw the dependency
<pitti> tkamppeter: biff
<Mithrandir> dholbach: yes.
<Kamion> if you can look at fixing its dependency on libglib1.2, that would be good, although it isn't urgent
<pitti> infinity: I didn't
<Kamion> tkamppeter: ^--
<dholbach> Mithrandir: gracias
<pitti> infinity: the only thing I looked at is gnutls12 -> 13
<Mithrandir> infinity: you didn't read my mind and stopped the publisher so we can sneak dholbach's stuff in, did you?
<infinity> pitti: We should probably run our extremely unscientific scripts again soon.
<pitti> infinity: on !{sparc,hppa} the transition is almost complete (only gutenprint missing, which is just getting merged by tkamppeter)
<infinity> Mithrandir: Oddly, no.
<infinity> pitti: I'd like todo a wholesale transition to db4.4 as well.
<pitti> infinity: on ia64 and hppa half of the world still depends on 12, no idea about that
<pitti> infinity: (when I said 'sparc' I meant 'ia64' of course)
* pitti hugs fabbione 
<fabbione> pitti: there is no hppa in edgy.. 
<Kamion> damn, I forgot to approve ubiquity
<infinity> pitti: Remind me to look into the sparc gnutls thing.  hppa is broken because it's not built edgy in any way (and might not do so)
<fabbione> pitti: so just forget about that
<Kamion> done now
<pitti> fabbione: oh, I see
<infinity> pitti: s/sparc/ia64/ then. :0
<pitti> infinity: so anastacia should not look at hppa any more either
* fabbione injects some true 64 bit in pitti and infinity's veins
<infinity> pitti: Yeah, we need to make all the tools ignore hppa soon, I think.
<pitti> fabbione: amd64 works just fine :)
<fabbione> pitti: amd64 is hibrid
<dholbach> Mithrandir, Kamion: done
<jdong> why are some of the restricted modules missing from the livecd?
<jdong> fglrx is nowhere to be found
<infinity> jdong: casper disabled building the fglrx and nvidia modules.
<SEJeff> jdong: Doesn't that have something to do with gpl violations like what Kororaa got into
<jdong> infinity: is it due to licensing?
<jdong> SEJeff: yes, but when the system is installed, fglrx magically pops back in.... which is just as illegal by the kororaa phenomenon...
<infinity> jdong: No, to cut down on memory usage.
<jdong> infinity: ah, ok
<jdong> infinity: is there any way to temporarily get it back?
<infinity> jdong: There's no licensing issue, but linking those modules in a ramdisk eats precious memory.
<jdong> infinity: I suppose apt-get install --reinstall l-r-m?
<infinity> jdong: edit /etc/default/linux-restricted-modules
<jdong> once I set up networking...
<jdong> oh
<jdong> duh
<jdong> :)
<jdong> thx
<ogra> Kamion, if i compare http://people.ubuntu.com/~ogra/removals.txt with http://people.ubuntu.com/~ogra/additions.txt there should roughly be a +/-0 
<infinity> jdong: (and then re-run the init script)
<jdong> yep, got it :)
<Kamion> ogra: what's that a diff between? I'm looking at quite a different diff
<ogra> the ubuntu and edubuntu .list files
<tkamppeter> pitti: biff
<Kamion> I'm diffing edubuntu dapper->edgy, which I think is probably more useful
<ogra> removals.txt is what is removed in edubuntu vs ubuntu 
<ogra> additions.txt is the other way around
<fabbione> hey Keybuk 
<Keybuk> heyhey
<fabbione> Keybuk: i was just waiting for you
<fabbione> :)
<Keybuk> fabbione: did you have any luck with the --debug thing?
<tkamppeter> I have made the last Mandriva package of ESP GS with the current SVN state and by checking the binaries with ldd I see that glib2 and gtk2 is used. So probably we need to update ESP GhostScript from upstream.
<fabbione> Keybuk: i added the output to the bug and prepared access for you
<fabbione> Keybuk: i was waiting to give you info on how to access the *
<Kamion> ogra: I've committed a seed change to drop linux-generic from your i386 CD, which should save you some space
<ogra> ok
<Kamion> well, am committing
<ogra> Kamion, but dapper->edgy should roughly only be ltspfs/fuse and student-control-panel and deps ... plus some bytes in ltsp
<fabbione> Keybuk: i am taking 5 minutes off and then i will give you details on how to access..
<ogra> that cant be such a huge difference
<Kamion> tkamppeter: we're well past the point where we are comfortable updating from upstream by default; we'll need to consider such an update rather carefully. If the problems we have can be fixed without doing that, that might be preferable
<Keybuk> fabbione: many thanks
<Kamion> but it depends what else is fixed by the new upstream, and what risks it entails
<Kamion> ogra: I'm not much bothered what it *should* be; I'm looking at what it is
<ogra> well, i now what i added
<ogra> *know
<Kamion> ogra: about 30/40MB of the diff is the addition of ttf-arphic-ukai, ttf-arphic-uming, ttf-baekmuk, and ttf-dustin
<Kamion> well, -dustin is small
<ogra> argh ...
<Kamion> but the others are big
<ogra> how did they end up in there agaon ...
<Kamion> apparently you don't know what you added :P
<ogra> ah, i see, my seed merge for recommends added them
<ogra> they were comented since breezy :)
<kagou> iwj: do you have you found a solution for Bug #56682 ?
<Ubugtu> Malone bug 56682 in fontconfig "Raster fonts appear in Edgy" [Medium,Confirmed]  http://launchpad.net/bugs/56682
<Keybuk> fabbione: from the output, it looks like you have a duplicate of jbailey's bug
<Keybuk> it wouldn't surprise me if init is spinning at 100% CPU at that point with waitid() returning the same (dead) pid each time
<Kamion> ogra: together with the removal of linux-generic from ship, that should get rid of basically all your oversizedness
<ogra> yeah
<ogra> updating the seeds now
<tkamppeter> if getting rif of glib1.2/gtk1.2 is essentially important, we should perhaps extract a patch from the ESP GS SVN. If the unwished libs are small, we simply leave it this way in Edgy and let it simply come by itself on the way to 7.04.
<Keybuk> fabbione: it makes some amount of curious sense that sparc and ppc64 would exhibit the same problem -- I believe the kernel code is similar?
<fabbione> Keybuk: re.. 
<fabbione> dunno if the code is similar..
<iwj> kagou: No.  Well, we have a workaround.  I was just about to look at it again in fact as my ff build seems not to be dying at the first hurdle now.
<fabbione> but one thing is sure... the same behaviour is seen in both .15 and .17
<Keybuk> fabbione: that would be consistent with jbailey's problem too
<Keybuk> the same behaviour was seen with the dapper and edgy kernels
<Kamion> tkamppeter: it's relatively unimportant in itself, so if there's nothing else that points to updating gs-esp as a good thing, we can leave it
<Kamion> Keybuk: they're kind of similar architectures at the CPU level
<Keybuk> Kamion: indeed
<Kamion> ogra: finally committed my seed change, so you'll need to update again; sorry, it took longer than I expected for bzr to get its act together for some reason
<ogra> dont worry
<ogra> thanks for the help :)
<Kamion> np
<pitti> tkamppeter: answered
* fabbione takes off
<doko> Mithrandir: would you mind an python2.5 upload at this time (not on the CD's)?
<kagou> iwj: do you know if edgy is installed with the wanted of enabled bitmaps or do you want to install edgy with no bitmaps by default ?
<infinity> doko: It'll just end up in queue/unapproved anyway.  We're actually frozen properly this time.
<infinity> doko: So upload away, just don't be shocked if no one bothers to approve it right away.
<doko> infinity: so it shouldn't hurt?
<doko> ok
<pitti> oh, that means I can also upload the fixed pkgbinarymangler already
* pitti grabs something to eat
<infinity> pitti: Oh, what did I break? :)
<infinity> pitti: Oh, the backports bug.  Right.
<pitti> infinity: yes, that and some manpage fixes
<pitti> nothing earthshaking, I'd just like to get it off my hard disk and forget about it
<infinity> pitti: You realise this will need to be fixed for dapper, right?
<pitti> infinity: yes, it has a dapper task
<pitti> infinity: but dapper-updates is frozen, too
<infinity> Yeah, I know.
<infinity> You can upload to it, though.  We just aren't approving currently. :)
<iwj> kagou: I think the intent is to install it with them disabled by default.
<infinity> pitti: How are you detecting the target pocket?  Just `dpkg-parsechangelog | grep ^Distribution`?
<pitti> infinity: yes
<pitti> infinity: I was going to ask you for the CurrentlyBuilding format
<pitti> infinity: but then I saw that backports have an automatic changelog entry
<infinity> pitti: CurrentlyBuilding doesn't have a distribution in it, but it certainly could.
<infinity> pitti: Not much point in duplicating that info, however.
<pitti> infinity: as long as we have the changelog entry, this seems more robust to me
<infinity> As "robust" as anything in that package is. :)
<infinity> I fear I made it scarier with my last upload, but it *does* seem to work, so I'll not jinx it.
<pitti> mdz: infinity and I had a short discussion about adding a checkbox to the apport-gtk dialog and a gksudo wrapper to disable apport; do you consider that an edgy+1 feature or an usability bug fix?
<ogra> Riddell, would it hurt to drop the menu-xdg dep from kdelibs ? 
<iwj> kagou, Kamion: After a bit of archeaology, it is now clear more or less why that weird code is there in the fontconfig-config.config but in fact we can just get rid of it.  It serves no useful purpose for us.
<iwj> So I will remove it.
<iwj> As in, we can get rid of all of the efforts to look at symlinks and mess with the debconf db.
<Kamion> Keybuk: did I remember to warn you about gtk2-engines? the binaries in NEW are bogus, I think - at least it should be checked whether they're supposed to be there before accepting
<Kamion> iwj: ah, ok, excellent
<Keybuk> Kamion: no, but I think I already saw them last night and postponed dealing with them
<Kamion> ok, good
<infinity> Kamion: They're not bogus, but the queue tool's handling of them is bogus.
<Kamion> infinity: it doesn't display them properly because they existed in dapper, yes - but those binaries were supposed to be gone ...
<kagou> great iwj. do that mean that by default 30-debconf-no-bitmaps will be installed ?
<Kamion> oh, are they transitional maybe?
<infinity> Kamion: I was leaving it there as an example of bug #59291
<Ubugtu> Malone bug 59291 in soyuz "queue tool seems confused about NEWness" [High,Confirmed]  http://launchpad.net/bugs/59291
<Kamion> ah, they are
<infinity> Kamion: They're new transitional arch:all binaries, it's the arch:all business that's causing the bug.
<Kamion> hmm, I don't want to leave an upload there indefinitely until the soyuz people fix a bug
<infinity> I wasn't planning on it being indefinite. :)
<Kamion> I'm a bit uncomfortable with gtk2-engines being out of sync for knot-3
<infinity> I'll put it on my "poke cprov and malcc" TODO for tomorrow.
<infinity> Unless you want to accept them now.
<Kamion> but I guess if it isn't actually causing breakage ...
<infinity> I can reproduce the bug at will.
<Kamion> seb128,dholbach: is gtk2-engines 2.8.0 important to have?
<kagou> iwj: i don't know if it's possible, but update fontconfig package for knot3 will be great
<seb128> Kamion: no
<seb128> why?
<ogra> Keybuk, ?? "...Evolution still doesn't :-/..." ???
<ogra> i use it daily
<Kamion> seb128: it's stuck in NEW due to the above, that's all
<Kamion> if it's not urgent I'll leave it there
<seb128> ah ok
<Keybuk> ogra: doesn't obey Mail-Followup-To
<seb128> right, no hurry
<ogra> Keybuk, ctrl-l ?
<Keybuk> ogra: that is not Mail-Followup-To ... that is Reply-To-List which uses the List-* headers
<ogra> ah, k
<ogra> sorry
<ogra> i'm to confused today 
<Treenaks> mail-followup-to specifies if you want a Cc on the mail-to-a-mailinglist, afaik
<Keybuk> right, poster preference
<infinity> Kamion: Okay, malcc's going to attack it and either find a fix, or extract enough data from the queue item that we can take away his example.
<Riddell> ogra: why do you want to drop menu-xdg?
<Riddell> ogra: although it's probably fine to drop
<iwj> kagou: If I give you a .deb under the table, can you test it for me ?
<iwj> Whether to include this change in knot-3 is up to Tollef.
<Mithrandir> iwj: which bug?
<iwj> Ah, hello :-).
<iwj> bug 56682
<Ubugtu> Malone bug 56682 in fontconfig "Raster fonts appear in Edgy" [Medium,Confirmed]  http://launchpad.net/bugs/56682
<iwj> I can explain more if you like.
<Mithrandir> iwj: while I see that it is/can be annoying, I don't think it's worth holding up knot 3 for.
<iwj> Fair enough.
<Mithrandir> iwj: if you think otherwise, feel free to convince me. :-)
<iwj> I'll upload after the release announcement then.
<Mithrandir> you can upload it now, it'll just get stuck in the unapproved queue
<iwj> I don't have an opinion really.  I'm not one to hanker after prettiness :-).
<iwj> Oh, good.
<iwj> There was a note in your knot-3 message saying not to.
<Mithrandir> yes, since FROZEN was broken for knot 2 and we didn't know if it was fixed or not.
<Mithrandir> (actually, it wasn't fixed until today, UTC)
<iwj> Ah, but it is fixed now.  Excellent.
<Mithrandir> yup
<iwj> kagou: I'd still like to get this off my radar, so if you'd like to test it so I can upload then that would be very helpful.
<Riddell> hmm, usplash broken on kubuntu alternate CD and booting without usplash X doesn't seem to start
<ogra> Riddell, it breaks gnomes menu if the menu package isnt installed (which i surely dont want)
<kagou> iwj: i'm, of course, ready to test it
<Kamion> infinity: great, thanks
<Kamion> Riddell: broken how?
<Mithrandir> Riddell: removing splash from the command line doesn't fix it either?
<iwj> kagou: http://www.chiark.greenend.org.uk/~ian/d/fontconfig/
<iwj> It may not fix a system that was already broken, though.
<iwj> Because the broken system has the wrong values in debconf.
<iwj> So to test it you should clear out the relevant debconf data and purge the fontconfig packages, and then install these.
<Kamion> as long as (a) dpkg-reconfigure fixes it and (b) dapper->edgy upgrades DTRT then that's probably ok
<iwj> dpkg-reconfigure will fix it and I'm confident about the dapper upgrades.
<iwj> kagou: You can confirm for me whether installing that and then saying dpkg-reconfigure fixes it :-).
<crispin> pitti: are you around ?
<pitti> crispin: yes
<tkamppeter> pitti: biff
<tkamppeter> pitti: New gutenprint uploaded
<crispin> pitti: ahh, excellent, I was wondering how to best go about debugging bug #55809 ? I can repro all the time on my laptop and would dearly love to fix it (and am willing to put in the time this weekend to do so)
<Ubugtu> Malone bug 55809 in hal "HAL changes wireless interface (net.80211) to wired (net.80203) in info.category after suspend" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/55809
<infinity> mvo: Can I have you in ##soyuz1.0 for a few minutes?
<HiddenWolf> dholbach: can you check if https://launchpad.net/distros/ubuntu/+source/gstreamer0.10-pitfdll/+bug/59948 contains what you need? 
<Ubugtu> Malone bug 59948 in gstreamer0.10-pitfdll "Crash in totem-thumbnailer" [Low,Needs info]  
<Riddell> Kamion: blank screen, nothing happens
<Riddell> Mithrandir: removing splash from command line boots up into command line, need to start X manuall
<janimo> tkamppeter: what was the fix for foomatic-db and duplicate printer description files for two epson stylus models? It should go in ubuntu as a patch if the whole package is not synced with upstream
<pitti> crispin: hm, the log does not show anything useful at first sight
<Mithrandir> Riddell: uh, so kdm doesn't start for some reason?
<pitti> crispin: I guess this requires a proper gdb session on hald
<Riddell> Mithrandir: seems to be the case
<crispin> pitti: so build up a debug hald, find where it detects the network driver, then put a break point in and suspend and resume and see what goes on ?
<simira> Kamion: I finally managed to report a bug. I guess a partman-log of > 2MB points to something being wrong...
<Riddell> Mithrandir: it is in /etc/rc2.d/ and it does start from the live CD I installed today
<pitti> crispin: yes, that's the broad description
<pitti> crispin: you should stop the system hald (kill or /etc/dbus/event.d/20hal stop) before
<crispin> pitti: nod
<smurf> Kamion: altgr keys are penalized so it should only ask for one of those if it can't find anything better
<pitti> crispin: then DEB_BUILD_OPTIONS=nostrip,noopt debian/rules build in the source package
<crispin> pitti: I'll give that a go sometime over the weekend
<pitti> crispin: I put a run-hald.sh script into debian/ for convenience
<pitti> crispin: it runs the locally built hald with all necessary paths adapted for the stuff in the source package (rather than installed system files)
<crispin> ahh nice
<pitti> crispin: TIA for debugging
<iwj> dpkg-deb: building package `firefox' in `../firefox_1.99+2.0b2+dfsg-1ubuntu1_i386.deb'.
<iwj> Scary.
<crispin> pitti: I'll go for a gdb or printf session and try tracking things down then :-)
<smurf> Kamion: one quick and dirty solution would be to add "" to the aliases for "a"; but whether it would find a better alternate is anybody's guess
<Kamion> smurf: something's wrong with the algorithm then -  is the obvious distinguisher between gb and us and it's not trying that
<smurf>  is where on a gb keyboard?
<Kamion> smurf: shift-3
<Kamion> and nowhere on us
<_ion> Where is # then?
<Kamion> _ion: where us has \
<_ion> Where is \ then? ;-)
<kagou> iwj: testing your packages... they create 30-debconf-yes-bitmaps.conf. And i said that's not good.
<Kamion> _ion: left of z
<Keybuk> _ion: on the # key :p
<iwj> kagou: Yes, they would do, if you just install them on an affected install.
<_ion> kamion: Ok. :-)
<Keybuk> Kamion: uhh, # is left of ENTER on a sensible UK keyboard
<iwj> Can you try dpkg-reconfigure fontconfig-config ?
<Keybuk> oh, sorry, you were talking about \
<Kamion> Keybuk: yes, that's what I said :)
<iwj> config config font config reconf conf conf figure
* Keybuk reboots iwj
<iwj> I didn't have any boots beforehand.
<jdong|laptop> Keybuk: how come filelist-order in readahead-list is not installed onto the system?
<kagou> iwj: how can i test them like a fresh install ?!
<Keybuk> jdong|laptop: because it was silly
<jdong|laptop> Keybuk: you almost waste 25 minutes of my time rewriting that program :P
<jdong|laptop> Keybuk: does it not work?
<iwj> kagou: That's tough.  dpkg-reconfigure throws away what I think is the infection and is the first step, so can you try that ?
<Keybuk> jdong|laptop: oh, I suspect it works
<iwj> kagou: If that fails then it's buggy.
<Keybuk> jdong|laptop: it was just easier to make readahead-watch do that
<jdong|laptop> Keybuk: well, if you put a filelist-order call in S01readahead, that solves the reordering problem
<jdong|laptop> and you're right, it does happen in nanoseconds :)
<iwj> kagou: If that works then there's a more extensive test which involves clearing the relevant debconf entries, purging the packages, and then dpkg -i'ing them.
<smurf> Kamion:  is probably in the alias list as too-easy-to-confuse with lLiI
<smurf> one moment
<Keybuk> jdong|laptop: tbh, why not just put the ioctl code in readahead-list itself?
<Keybuk> that way you save a fork/exec
<Kamion> smurf: seriously? the only people with  on their keyboards know what it is :)
<Keybuk> and don't need a writable filesystem :p
<jdong|laptop> Keybuk: that works too. :)
<Kamion> I don't think it looks all that much like L
<Kamion> (any more)
<_ion> Doing that in readahead-list would be nice.
<Kamion> anyway, no, it's not - just ""
<smurf> Kamion: so it is ... I'll have to check the code more closely then
<smurf> Kamion: I'm on vacation for the next eight days, but I'll take the laptop and will check
<Kamion> smurf: thanks
<kagou> iwj: i'm sorry, i don't understand. "sudo dpkg-reconfigure fontconfig-config" ask severals questions. Saying yes or no at "do you want bitmaps" is ok.
<kagou> is that what you want ?
<iwj> dpkg-reconfigure --default-priority should avoid the questions.
<Kamion> smurf: failing that I can probably hack something up :)
<iwj> And take the default.
<kagou> ok so iwj in this case it's ok for me
<kagou> i mean, it's work fine
<Kamion> smurf: I think adding /a would probably cause problems for the Norwegians or Danish or whoever it is that has 
* kagou is searching for a goog english method :)
<kagou> s/goog/good
<Nafallo> danish
<iwj> kagou: Thanks.  If you want a more thorough test it's quite tough.
<Kamion> simira: I can reproduce the keyboard problem, anyway
<simira> Kamion: it's the partition problem that keeps me from installing, atm. I am downloading the alternate one now.
<smurf> Kamion: They do have  or , but one of those will probably be the next candidate :-/
<Kamion> simira: yeah, I'm just going one step at a time in case there are knock-on problems
<Kamion> smurf: right, and both of those look like o by the exact same argument ...
<simira> Kamion: but it's somewhat annoying, and the correct norwegian layout isn't available in the layout-list, it seems
<iwj> I wasn't expecting this ff build to work !
<simira> Kamion: no complaints, I know you're doing your best and then some
<kagou> iwj: it's ok for me. do you think that you can include your version on knot3 ?
<iwj> kagou: I asked Mithrandir and he'd rather not, so sorry.
<Kamion> simira: current images have a broken version of ubiquity
<Kamion> simira: because they're out of date
<simira> Kamion: the alternate one also? So I need't bother to test it?
<siretart> is universe frozen as well?
<Kamion> should be fixed next time Tollef does a build - I think all the underlying issues are fixed
<simira> *sigh*
<simira> and he just left... well, off to dapper, then...
<Kamion> simira: I think very current alternate will work
<Kamion> simira: also
<simira> Kamion: ok, I'll test current, then
<simira> current alternate, even
<Kamion> simira: try 'sudo apt-get update; sudo apt-get install ubiquity' on a live CD
<Kamion> no shame in upgrading it on the fly :-)
<kagou> iwj: thanks for your work. i mark the bug as "in progress"
<Keybuk> fabbione: ok, disk1 works now
* kagou hugs iwj 
<Kamion> simira: having done that, it does offer me *a* Norwegian layout. Can you tell me what's incorrect about it?
<simira> Kamion: everything. It still seems to run with a US layout, to me... I'll try again
<iwj> kagou: Right.  Well, I'll upload now and it'll hopefully be deployed in due course.
<Kamion> simira: on the live CD, it's working for me after upgrading ubiquity
<Kamion> I get   etc. anyway
<simira> Kamion: lucky you. May I have yours, then?
<Kamion> and I can get into manual partitioning
* ogra wonders why his edubuntu-meta upload didnt show up on -changes ... 
<simira> Kamion: I get  -s' instead of , actually
<roico> is the common customizations spec going to be implemented by edgy?
<Kamion> ogra: because all uploads require manual approval and you didn't ping me about it :)
<simira> Kamion: uhm... now my letters are _completely_ mesed up. I am not sure what layout it is, but it's neither US or NO, or qwerty at all
<ogra> ah, ok
<ogra> Kamion, ping :)
<Kamion> accepted
<ogra> heh
<Kamion> simira: what did you select?
<Kamion> I need to know *exactly* what you did, from the start
<simira> Kamion: the only Norwegian alternative, Norwegian -> Dvorak
<Kamion> simira: oh, in the alternate CD?
<Kamion> that would have been a good thing to tell me first :)
<simira> Kamion: no, current live, still
<Kamion> uh
<simira> I found them!
<Kamion> what are you doing that presents Dvorak?
<Kamion> what exactly are you running?
<siretart> Kamion: so even universe uploads need approval?
<Kamion> siretart: yeah, but I wave those through when I notice them
<siretart> ah. I see
<simira> Kamion: changing keyboard layout on the menu System -> Preferences -> Keyboard, it presents Norwegian -> Dvorak(messy), Eliminate dead keys (works), Samii and Samii eliminate dead keys
<Kamion> I just approved the outstanding ones
<Kamion> simira: oh, that menu has nothing to do with me
<Kamion> simira: try just picking "Norwegian", not any of the sub-entries
<tkamppeter> pitti: biff
<Kamion> it's not obvious that you can do that
<roico> is the common customizations spec going to be implemented by edgy?
<Kamion> roico: probably not anything much more than has already been done, as we're past feature freeze now
<Kamion> than whatever has already been done; I haven't been following the details of that spec
<pitti> tkamppeter: oh, I didn't suggest to close the bugs right now, but just to collect some which will be definitively fixed (there are some which are already marked so)
<pitti> tkamppeter: but don't worry about it too much, closing them after upload after checking with the reporter is fine
<Kamion> simira: I still need that /var/log/partman, if you can; feel free to gzip it first
<simira> Kamion: should be added to the bug
<jdub> go edgy
<jdub> it's your birthday
<jdub> go edgy
<jdub> it's your birthday
<ogra> jdub, still more than a month ...
<jdub> LIES
<Kamion> oh, malone's attachment UI changed and there now isn't a comment for each attachment
<ogra> :)
<jdong|laptop> :)
<simira> Kamion: yes, it fooled me too, for a minute
<hunger> Keybuk: What was the trick again to make cryptdisks work with upstart again?
<tkamppeter> janimo, was it the Epson Stylus C65/C68? I have fixed this upstream.
<jdub> hunger: -> #nsa
<ogra> haha
<jdong|laptop> lol
<jdong|laptop> hunger: I don't think it's sudo apt-get install sysvinit.... ;)
<Kamion> hunger: last time you asked somebody said 'console owner'
<Keybuk> hunger: fix the cryptdisks script to do </dev/console not </dev/tty :p
<simira> Kamion: I still don't get into manual partitioning on the current live, though
<hunger> jdong|laptop: Actually that is what I am doing right now.
<tkamppeter> I have also fixed bug #16703 upstream in foomatic-db.
<Ubugtu> Malone bug 16703 in foomatic-db "hpijs is recommended for hp laserjet 1100A but ljet4 prints better" [Medium,Confirmed]  http://launchpad.net/bugs/16703
<jdong|laptop> hunger: shhhh! Keybuk is gonna go ballistic on me... ;)
<hunger> Keybuk: I do not get any output whatsoever... do I need to add console owner somewhere?
<Kamion> simira: yeah, known bug, I'm just looking for the number ...
<Keybuk> hunger: if you like output
<Keybuk> jdong|laptop: for?
<jdong|laptop> suggesting sysvinit :)
<hunger> Keybuk: Well, I need to see cryptsetup ask for its password;-)
<Keybuk> hunger: so fix the cryptsetup script
<Keybuk> it'd be a useful patch if you also added usplash support
<Keybuk> that has an INPUT command now
<hunger> Keybuk: I have a somewhat different cryptsetup script:-)
<Keybuk> you could fix that too :p
<hunger> Keybuk: See bug #563 about my init script:-) Did not get round to update it for this release round (did not make it into breezy or dapper, so my motivation is somewhat low;-)
<Ubugtu> Malone bug 563 in cryptsetup "improved start/stop script" [Wishlist,Needs info]  http://launchpad.net/bugs/563
<dholbach> Keybuk: there's a new release of libjingle and new packaging for it - I'll have a look at it before pestering you with it again - i just really really hope we can get it in
<Keybuk> dholbach: I saw
<ogra> libjingle ? 
<Keybuk> ogra: Google Talk
<ogra> does it play advertisements  ?=
<ogra> ah
<hunger> Keybuk: When will you have upstart mount the disks? At that point it would probably make sense to integrate cryptdisks into upstart instead of trying to improve the init-script.
<Keybuk> hunger: edgy+1
<hunger> Keybuk: Oh, OK, I'll just stick with sysvinit till then.
<Seveas> hunger, edgy is "sysvinit as /sbin/int", edgy+1 is "replace all intiscripts kthxbye" and edgy+2 will be "DIE SYSVINIT DIE!!"
<desrt> is the startup screen in edgy supposed to be completely screwed up?
<mdz> pitti: I think it's appropriate to allow the user to disable it
<Seveas> desrt, no
<mdz> pitti: if it's simple and quick, it can go into edgy with a FF exception
<desrt> http://desrt.mcmaster.ca/random/bad_startup.jpeg
<desrt> ^ this is what the bootup screen looks like for me
<desrt> the old test pattern was fine
<jdong|laptop> desrt: your server is down
<desrt> erm.  wfm?
<janimo> tkamppeter: yes the C65/C86 issue. I asked what the fix was in case a new version of the package does not make it to edgy, we should pick that oartilcuar fix at least
<desrt> jdong|laptop; your problem, fairly sure
<Seveas> desrt, widescreen?
<desrt> Seveas; yup.  macbook 13.3
<Keybuk> Mithrandir: ping?
<Seveas> ah, mac
<desrt> Seveas; the test pattern worked fine
<Seveas> maybe the bogl backend is borking
<Seveas> desrt, did you upgrade usplash today?
<desrt> well... the image looks to be correct but started at the wrong location
<desrt> Seveas; last night, i think
<jdong|laptop> desrt: heh, dns doesn't resolve... might be my problem :-/
<desrt> hang on for a version tag
<desrt> jdong|laptop; definitely your problem
<desrt> the dns is hosted by mcmaster university... quite redundantly
<Kamion> Seveas: macbook => i386 => svga surely
<Kamion> Seveas: the powerpc Macs aren't called "macbook"
<Seveas> Kamion, *headdesk* -- I keep forgetting that
<jdong|laptop> desrt: yeah, my problem... MITNet can access it just fine
<desrt> "Fix incorrect width/height used by usplash_put_part in BOGL backend."
<bddebian> Howdy folks
<desrt> i bet that's what caused the bug
<Kamion> desrt: nothing to do with you
<Seveas> no
<Kamion> desrt: you're not using the bogl backend
<desrt> oh.
<desrt> in any case i'm running 0.4-24
<Kamion> desrt: and that only affected the progress bar anyway, not the whole picture
<Kamion> you're in totally the wrong video mode by the looks of things
<Seveas> Kamion, the whole picture is put on screen by usplash_put
<Kamion> Seveas: yes, I know
<Kamion> desrt: you can probably work around the problem by changing the resolution in /etc/usplash.conf
<desrt> Kamion; well.  i'm willing to help if you have questions
<pitti> mdz: the backend is already there (/etc/default/apport), it just doesn't have a GUI
<desrt> Kamion; dpkg-reconfigure my image?
<Kamion> desrt: just edit it
<desrt> how does usplash read the file before the root filesystem is mounted?
<Kamion> I bet it's 640x480 at the moment; change it to whatever your X resolution is
<Kamion> desrt: after you edit the file, run update-initramfs -u
<Kamion> that copies it into the initramfs
<desrt> Kamion; what's what i meant by dpkg-reconfigure :p
<tseng> desrt: usplash stuff is in initramfs
<Kamion> desrt: dpkg-reconfigure won't do what you want in this case.
<desrt> Kamion; it rebuilds initramfs
<Kamion> the postinst won't rewrite an existing configuration file.
<Kamion> talking about it is totally misleading
<mdz> pitti: ok then
<desrt> oh.  that's pretty weird/lame
<Kamion> it's pretty damn correct :)
<Kamion> pissing about with existing configuration isn't good
<mdz> well, sometimes it is
<Kamion> yeah, but probably not in this case
<desrt> k.  it's going
<desrt> please stand by
<desrt> that sort of fixed the problem
<jdong|laptop> Seveas: regarding your blog post, I certainly hope I won't be using a distro codenamed "fuzzy ferret" :)
<Seveas> ;)
<Nafallo> lol
<desrt> Kamion; http://desrt.mcmaster.ca/random/bad_boot_2.jpeg
<desrt> fills the screen now, but the aspect ratio is awful
<desrt> skinny-tall-buntu: linux for people who aren't fat
<Kamion> that I don't know about, and it could just be an "adjust your monitor" thing
<Kamion> modern monitors often being per-mode adjustable
<desrt> uh
<Seveas> Kamion, no, it's the "your theme has only 4:3 and 16:9 images and your monior is neither" thing that causes this
<desrt> it's a laptop LCD screen :p
<desrt> i guess it picked 16:9
<desrt> then scaled it
<desrt> better to pick 16:9 then crop it, imo
<Seveas> it does neither
<Seveas> the scaling is done by your monitor
<pygi> sivang, ?!
<desrt> Seveas; it's running in the native resolution of my monitor
<desrt> 1280x800
<Seveas> no
<Seveas> it's running in the svga mode closest to it
<desrt> oh.  this is bad.
<Seveas> and svga as used by usplash only does 4:3
<Nafallo> 16:10 then :-)
<desrt> Seveas; if that were the case then it would be stretched out widthwise
<Seveas> but there are images that are 16:9 but scaled to 4:3 in the standard themes
<desrt> not heightwise
<Seveas> and usplash will use those for 1280x800
<desrt> oh.  ok.  i get it.
<desrt> so you have intentionally tall images
<desrt> if a 'widescreen' reso is detected
<desrt> because you know that the laptop will stretch them back out again
<Seveas> indeed
<desrt> but my laptop doesn't stretch far enough
<desrt> that's clever -- but very evil :)
<Seveas> indeed again
<sladen> Seveas: most of the manufactuers include extra widescreen VESA modes (if it's a laptop)
<desrt> sladen; 915resolution says otherwise :)
<Seveas> theoretically it could support 16:10 and 14:9 too, but that really needs someting generic in usplash 
<Seveas> which will NOT be edgy material 
<desrt> Seveas; just so we're clear -- you have to fix this bug :p
<Seveas> yes
<desrt> it's damn ugly :)
<Seveas> it's not that bad
<sladen> desrt: 915resolution has nothing to do with VESA modes
<desrt> sladen; i see.
<desrt> Seveas; i guess one workaround would be for me to tell usplash that i have 1024x768
<desrt> then i'll get a wide image instead of a tall one
<Seveas> indeed
<desrt> which will probably look a bit better :p
<sladen> desrt: if your X is running at 1280x800 or some such, then usplash should be able to pick 1024x768 and hope that it's being scaled to 1280x800 and adjust (squeeze) the video inversely
<desrt> sladen; right.  i want to shortcircuit that intelligence and have it use 1024x768 directly (thus avoiding the squeeze)
<desrt> ya.  looks a bit better wide instead of tall :)
<sladen> desrt: do you /have/ an 1280x800 (or whatever) VESA mode?
<desrt> sladen; i'd imagine not?
<sladen> desrt: then you're not going to get it without scaling...
<desrt> sladen; but a 3rd scaling factor could be added
<sladen> desrt: could be.  they'd all just get scaled together
<desrt> or better yet, the installer could do custom scaling at ramfs-image-build-time
<jdong|laptop> infinity: I'm getting lots of reports in backports land about md5sum mismatches
<Nafallo> jdong: from more mirrors than se.a.u.c? :-)
<jdong|laptop> lol, no this time from archive, us.archive, ca.archive
<jdong|laptop> which makes me more worried
<jdong|laptop> most recent report is 14 minutes ago
<jdong|laptop> most aged report is around 10 hours ago
<Seveas> desrt, interesting idea
<jdong|laptop> and I don't currently have a dapper box handy
<Nafallo> I had edgy main from se.archive.u.c around 10:45 UTC :-)
<desrt> Seveas; i'm just chock full of interesting ideas that i want other people to do the work for :)
<jamadagni> hello is mithrandir herer?
<Seveas> hehe
<Nafallo> I wget'd, bunzip2'd and mv'd the file into place :-P
<jbailey> fabbione: Around?
<Kamion> is anyone here a French translator? I'd appreciate it if somebody could fix bug 60064 in Rosetta
<Ubugtu> Malone bug 60064 in ubiquity "Translation problem in french" [Low,Confirmed]  http://launchpad.net/bugs/60064
<jbailey> fabbione: I was just looking at the glibc on sparc packaging problem you found.  Mostly I'm amazed that this bug hasn't tripped someone up before.
<jbailey> fabbione: If you want amusement, read debian/rules.d/debhelper.mk, line 161.  The bit that starts with: #Ugly kludge: =)
<Seveas> Kamion, asking in #ubuntu-fr may help
<Kamion> Seveas: thanks, I've tried
<Kamion> Seveas: looks like a straight user channel though
<Seveas> vuntz is membr of -l10n-fr
<bddebian> Kamion: Are LP sync requests still OK or are we supposed to use the new sync script?
<bddebian> jbailey: Doesn't that describe most of glibc? ;-P
<jbailey> bddebian: Well, this is the packaging in particular.  Glibc itself is remarkably elegant in a number of ways.  The build system is "remarkable" in other ways... ;)
<bddebian> Heh
<Kamion> bddebian: any sync script you may have seen is probably just a convenient way to file bugs in LP
<bddebian> Kamion: OK, fair enough, thx.  We can still request for Universe right?
<Kamion> bddebian: filing bugs in LP is fine; just give all the information requested by Scott on ubuntu-devel-announce
<Kamion> bddebian: yes
<zyga> re
<bddebian> Kamion: I don't get u-devel-announce.  Do you happen to have a link?
<tseng> bddebian: search gmane
<tseng> bddebian: its low traffic
<tseng> it was sent in August
<bddebian> gmane?
<jdong> no... BenC... don't go... I was gonna bug you about my USB chipset!
<dsas> bddebian: gmane.org lists available in nntp/rss/html
<bddebian> Hmm, I see the merge policy one
<tkamppeter> janimo, here is the C65/C68 fix in foomatic-db:
<tkamppeter> http://bzr.linuxprinting.org/devel/foomatic-db?cmd=revision;revid=pqm%40freestandards.org-20060906191142-7a8aa326766b71c7
<janimo> tkamppeter: thanks
<tkamppeter> and here the fix for the recommended driver of the LJ1100:
<tkamppeter> http://bzr.linuxprinting.org/devel/foomatic-db?cmd=revision;revid=pqm%40freestandards.org-20060913115808-f5bd6515e31cc7d7
<Riddell> Kamion: could you set off a new kubuntu livefs build
<janimo> tkamppeter: is the second url (LJ1100) addressed to me as well? I don;t remember anything about that :)
<mxpxpod> desrt: ping
<tkamppeter> The second is bug #16703, should you be the one in charge of making a new foomatic-db package, then you should fix both.
<Ubugtu> Malone bug 16703 in foomatic-db "hpijs is recommended for hp laserjet 1100A but ljet4 prints better" [Medium,Confirmed]  http://launchpad.net/bugs/16703
<tkamppeter> bug #1
<Ubugtu> Malone bug 1 in ubuntu-meta "Microsoft has a majority market share" [Critical,Confirmed]  http://launchpad.net/bugs/1
<tkamppeter> That was only a test, it seems that every time when someone writes "bug #XXX" then ubugtu posts the link and the subject/
<dholbach> tkamppeter: it works for upstream bugs too
<dholbach> gnome bug 325375
<Ubugtu> Gnome bug 325375 in Mailer "critical warning crasher : bonobo_ui_component_set_prop: assertion" [Critical,Resolved: fixed]  http://bugzilla.gnome.org/show_bug.cgi?id=325375
<tkamppeter> mandriva bug 25186
<Ubugtu> Malone bug 25186 in norwegian "norwegian: new changes from Debian require merging" [Medium,Fix released]  http://launchpad.net/bugs/25186
<tkamppeter> ubugtu has a bug!
<dholbach> lalalala, Seveas is the master of Ubugtu
<mxpxpod> bah, do we really need to keep track of mandriva? ;)
<dholbach> mxpxpod: when we link bugs to their bug tracker, etc - sure :)
<mxpxpod> oh, right...
<mxpxpod> is there any way to find out if a package is scheduled for a re-build?
<licio> why ubuntu doesn't have mailx package?
<dsas> licio: It does, http://packages.ubuntu.com/dapper/mail/mailx
<licio> dsas, I know, but mailx should be required by ubuntu-desktop
<Seveas> tkamppeter, what's the mandriva BTS?
<dsas> licio: Probably something to do with it requiring postfix and ubuntu having a "no ports by default policy", though that's a bit of a guess.
<Kamion> licio: no, we removed that because we aren't shipping an MTA by default so mailx is pointless
<desrt> mxpxpod; pong
<desrt> or should i say... mxpxpong ha ha ha
<licio> Kamion, uhm.. thanks :)
<tkamppeter> Seveas, it is bugzilla, site is http://qa.mandriva.com/
<Seveas> @bugtracker add mandriva bugzilla http://qa.mandriva.com/ Mandriva
<Seveas> mandriva bug 25186
<Ubugtu> Mandriva bug 25186 in cups "Printer Brother HL-5140 does not work anymore with this version of cups" [Normal,Needinfo]  http://qa.mandriva.com/show_bug.cgi?id=25186
<tkamppeter> Thank you. Does it also work with the custom-made bug tracker of CUPS: http://www.cups.org/str.php?
<mdz> Seveas: yay
<mdz> tkamppeter: is mandriva's bug tracker registered in launchpad as well?
<tkamppeter> I think, not, but I do not really know.
<Seveas> mdz, I was going to say "just tell me which bugtackers should be added" but the launchpad comment made me think of something more evil.
* Seveas goes to hack on ubugtu
<mdz> tkamppeter: https://launchpad.net/malone/bugtrackers
<janimo> xfce bug 1737
<Ubugtu> Malone bug 1737 in malone "Can't dissociate a bug tracker from a project" [Medium,In progress]  http://launchpad.net/bugs/1737
<tkamppeter> mdx, know, it is not there.
<mdz> tkamppeter: please add it; then you can link from malone bugs to mandriva bugs and have status tracked
<Seveas> tkamppeter, the cups bugtracker is weird but should be usable
<janimo> @bugtracker add  xfce bugzilla http://bugzilla.xfce.org/ 
<janimo> xfce bug 1737
<Ubugtu> xfce bug 1737 in general "Keyboard Shortcuts - Window key maps to different "Keys"" [Normal,Resolved: fixed]  http://bugzilla.xfce.org/show_bug.cgi?id=1737
<Seveas> @bugtracker add xfce bugzilla http://bugzilla.xfce.org/ XFCE
<janimo> \o/
<Seveas> last argument is a description
<janimo> seems it is optional :)
<Seveas> it is
<janimo> so is it now permanently added to ubugtu?
<Seveas> yes
<Seveas> @quit
<Seveas> (hand-hacking config)
<janimo> I wonder what bug number in Microsofts bugtracker 'Squash Ubuntu' is
<Keybuk> I doubt they even think we've taken a single user off them
<zul> janimo: its number 2
<pitti> bah, why must copying with nautilus be so sloooooowww
<ogra> Kamion, 698M ... you rule :)
<coyctecm> will edgy ship with xorg 7.1 ?
<ogra> it already does
<Kamion> ogra: rock
<coyctecm> oh? I installed it one test box at work, and I was looking that xorg was version 7.0.x
<Kamion> $ head -n2 /var/log/Xorg.0.log | tail -n1
<Kamion> X Window System Version 7.1.1
<fabbione> Keybuk: how are we doing?
<Kamion> coyctecm: you were probably looking at the xorg package, which isn't really relevant (counterintuitively)
<Kamion> it's just a few script
<Kamion> s
<coyctecm> Kamion: yes, I thinks so too :) My mistake :)
<Keybuk> fabbione: fixed it
<Keybuk> it was, as I thought, a kernel "issue"
<Keybuk> compat_sys_waitid behaves differently to sys_waitid
<fabbione> Keybuk: if you can write me a detailed description of the kernel problem, i can talk to David S Miller and see to get it fixed
<Keybuk> fabbione: it's not sparc-specific
<Keybuk> put simply; do_wait() (called by sys_waitid) takes care to zero the struct siginfo if WNOHANG is to be returned and there's no child waiting
<Keybuk> this means that waitid() returns 0 and you check whether info.pid != 0
<Keybuk> compat_sys_waitid() returns early without copying if WNOHANG ... so whatever values were passed into that struct are returned, which may be the last waitid or random data
<fabbione> Keybuk: ok.. well it might be worth to talk to david and see.. perhaps he can push a fix upstream
<Keybuk> the man page for waitid does say, hidden in the notes, that you must zero the struct yourself if you call with WNOHANG
<Keybuk> so it was definitely an upstart "bug"
<fabbione> ah ok
<Keybuk> but I'd also say that it's a kernel bug too for having a silly inconsistency
<Keybuk> I've tested and committed the fix (installed on that machine)
<fabbione> perfect
<Keybuk> and have asked Mithrandir for a freeze exception
<fabbione> can i powerit off?
<fabbione> it's not a blocker for knot-3
<fabbione> sparc can wait the next..
<fabbione> i am not too fuzzy about that
<ogra_> is there a next ? 
<Keybuk> sure
<ogra_> i thought next is beta 
<fabbione> ogra: i am happy to test the fix with tomorrow's netinstall
<Keybuk> we don't install by 64-bit-kernel-on-32-bit-userland by default, no?
<fabbione> i don't need a cd for that
<ogra_> ah
<Keybuk> other than sparc
<fabbione> i think we do it only for sparc and hppa
<fabbione> and ppc64
<ogra_> there are users that use a hack to install amd64 64bit ernels in 32bit userland
<fabbione> ogra: hacks are not supported.. 
<ogra_> i know
<Keybuk> is ppc64 a supported arch?
<fabbione> these are supported configs that we ship
<fabbione> yes ppc64 is
<Keybuk> I thought we just did powerpc and let them change the kernel if they wanted?
<fabbione> we ship kernel and 32 bit userland
<fabbione> nope
<fabbione> it's automatically detected by yaboot
<ogra_> but thats something very typical for ltsp users that want the 64bit kernel and flash support ...
<Keybuk> oh
<fabbione> and it boots/installs the right kernel
<Keybuk> then it's probably more critical then :p
<Keybuk> this breaks ppc64 too
<fabbione> Keybuk: can i shut down the machine in the meantime?
<fabbione> or do you still need it?
<Keybuk> fabbione: nope, no longer any need for it
<Keybuk> thanks
<Keybuk> (so you can shut it down)
<fabbione> Keybuk: ok perfect
<fabbione> Keybuk: i won't kill your account so we can use it again if needed
<Riddell> anyone around able to make kubuntu livefs?  mdz? infinity?
<Kamion> Riddell: I can
<Kamion> Riddell: I've just started off a build
<Riddell> thanks Kamion 
<Kamion> Riddell: also just pushed a ubiquity change to add scrolling to the mount points table that should be duplicated in the KDE frontend
<Riddell> Kamion: ok
<fabbione> good night guys
<pitti> bye fabbione 
<zul> night fabbione 
<bluefoxicy> Hey
<bluefoxicy> Is Ubuntu 10.04 going to release with MP3 support?
<ogra> 10.04 ?
<pitti> bluefoxicy: ogg vorbis will have conquered the world by then :)
<ogra> might be
<ogra> who knows ... 
<bluefoxicy> pitti:  I wish :)
<pitti> bluefoxicy: will the patent end in 2010?
<bluefoxicy> yes, the MP3 patents expire in 2010
<pitti> funny that the technology expires much faster than the patent, at least in terms of quality
<bluefoxicy> We are having a dispute over MP3/vorbis in another channel and someone brought up that certain linux distros don't ship with MP3
<bluefoxicy> so I'm now curious as to if there's other policy in place to prevent it
<bluefoxicy> is anyone else on toolchain besides doko?
<pitti> bluefoxicy: not actively; infinity sometimes
<pitti> (but it's not a normal Australian guy's time to be awake)
<bluefoxicy> hrm
<bluefoxicy> I am looking to find out what is going to be used for Edgy+1 because I want --hash-style=both by default for the new GNU hash functionality
<Yagisan> pitti, so true that
<pitti> Yagisan: :)
<pitti> Yagisan: *normal* :)
<Yagisan> pitti, ;) no one ever says I'm normal
<lamont> licio: mailx requires an MTA, and is not something that grandma would have on her computer -- those of us who actually want local mail user/transport agents tend to also know how to install them.
<lamont> that's why we dropped the MTA from ubuntu-standard, and postfix now gets to actually listen on port 25 when you install it, since it's not part of the base install any more.
<LaserJock> lamont: I liked it when MTA was dropped, I finally got to figure out what an MTA was ;-)
<sfllaw> Shootings in downtown Montreal.
<o_cee> what kernel will be the final version for edgy, .18?
<smurf> fabbione: ping
<LaserJock> sfllaw: ?
<sfllaw> http://www.cbc.ca/story/canada/national/2006/09/13/shots-dawson.html
<LaserJock> oh man
<jdong> o_cee: 17. what you see now
<o_cee> jdong: m'kay. so no ivtv in the kernel then
<jdong> o_cee: why do you say that? can't it be backported to 2.6.17?
<o_cee> jdong: don't think it's ready yet
<jdong> ah, I see
<jdong> that's a shame :-/
<o_cee> yeah, would make things alot easier 
<zul> sfllaw: not as bad as the time we had shootings inside the rieau center
<sfllaw> zul: Terrible.
<zul> sfllaw: yep
<carlos> pitti: better here...
<pitti> carlos: well, sort of
<carlos> pitti: what's the difference between libfreetype and libfreetype1 source packages?
<carlos> pitti: in edgy and translation contexts
<pitti> carlos: not sure, I thought freetype1 was an older version
<carlos> pitti: we got translations for libfreetype from dapper, and now, in Edgy, I got a new .pot file for libfreetype1
<carlos> pitti: should I import that one from libfreetype1?
<pitti> I think not
<pitti> lemme check something
<carlos> ok
<pitti> carlos: only graphviz still needs freetype1, the rest uses freetype
<pitti> so freetype1 is an excellent candidate for duplicate elimination
<carlos> ok, then I will not import it
<carlos> because I guess it will be moved to universe...
<pitti> carlos: better not
<carlos> pitti: ok, thanks
<ogra> Keybuk, Kamion poke ... could someone unleash edubuntu-artwork -35 ?
<Keybuk> "unleash" ?
<bddebian> "Unleash the hounds"
<Keybuk> I only have one "hound", and he's not very lethal ... unless you're allergic to doggy-licks
<bddebian> heh
<ogra> well, it seems it sits somewhere in the queue 
<Keybuk> I'm doing NEW at the moment, if it's in there, it'll get out soon enough
<LaserJock> \o/
<ogra> right... it was supposed to be in the last CD build, but indeed i forgot to ask to let it through
<Keybuk> actually, that's a good point
<Keybuk> maybe I should hold off NEWing anything for main?
<Keybuk> not sure whether or not that counts as freeze breaking or not
<Nafallo> Keybuk: should be :-)
<Nafallo> or rather, it should need Mithrandir's approval :-)
<Keybuk> indeed
<bddebian> Thanks Keybuk
<ogra> Keybuk, e-a has a general freeze exception, i got it yesterday from mith...
<Keybuk> ogra: show me
<Keybuk> with gpg signature
<ogra> but that doesnt really matter anyway, since i wont be able to do any further CD tests ...
<ogra> so i need to live with the broken one
<ogra> well, Nafallo saw it :)
<Keybuk> I'm so not believing you after the ltsp stunt :p
<Nafallo> Keybuk: I saw it :-)
<ogra> what was with the ltsp stunt ... the fix was in the same day you complained about it ...
<ogra> and would havebeen in one day ater if you hadnt complained
<Nafallo> Keybuk: but that was for if he decided to work until 5 that night, so I'm not sure if it's still active ;-)
<Seveas> urgh
<Seveas> if a program crashes once, I get a zillion apport dialogs :/
<Keybuk> ogra: claiming pitti had approved an MIR when he'd just said he'd reviewed it :p
<Nafallo> Seveas: there is a bug for that somewhere :-)
<ogra> Keybuk, he said he's confident that we fix it soon and thus i should ask you to let it through to unbreak the CDs
<Keybuk> hmm?
<Seveas> Nafallo, good 
<tseng> whoa Seveas is on fire
<ogra> usplash gets the config completely wrong ...
<ogra> it created a usplash.conf for 640x480 on my knot3 testsystem ... where the installed and upgraded edgy here gets 1024x786 (which is right)
<Kamion> ogra: right, I know about that and have a plan for fixing it
<ogra> apparently it doesnt scale the pic right ... so its ~1/3 moved to the left and ~1/3 moved to the bottom
<Kamion> at present, yes, it'll default to 640x480 on fresh installs, which is unfortunate
<ogra> Kamion, ah, cool
<ogra> fine with me ... it just looks a bit odd since the background isnt sitting at the right position
<Kamion> bluefoxicy: not an official statement, but I doubt there's any other policy preventing it; in particular there's the free Fluendo implementation that could be used once the patent expires
<ogra> the progressbar sits at the right place
<bluefoxicy> Kamion:  re mp3?
<Kamion> bluefoxicy: yes
<Kamion> ogra: that sounds like a theme bug
<Kamion> 21:50 < ogra> Mithrandir, can i have a general exception for edubuntu-artwork ?
<Kamion> 21:51 < Mithrandir> ogra: sure.  It's edubuntu and nothing else which breaks, which makes me slightly less worried. :-)
<Kamion> with regard to e-a
<Kamion> (last night)
<ogra> Kamion, apart from that, i386 edubuntu is fine for knot 3 ... since thats the only arch i can test right now, i'm not sure what to do about the other arches
<Kamion> I'll check/approve it now
<ogra> right
<ogra> that was the conversation
<Seveas> tseng, ?
<tseng> Seveas: reading your blog
<Seveas> tseng, heh
<Seveas> ogra: ubiquity doesn't write an usplash config and the default themes don't support 640x480
<Seveas> it's a bug in usplash that it will try to use them
<ogra> yep
<Seveas> fixing now
<Kamion> huh? I fixed that already, just not uploaded
<Seveas> ah
<Kamion> if it's the usplash bug I think you mean
<Kamion> that it tries to use the theme anyway and lets bogl/svgalib fail?
<Seveas> bzr is still pulling - so can't look
<Kamion> the ubiquity bug is fixed in bzr, but there's a more fundamental and difficult installation ordering bug in d-i
<Kamion> need to fiddle with tasksel a certain amount to make that work smoothly
<Kamion> fortunately said fiddling is useful to have anyway - it'll make stuff like media changes during the tasksel preinst work properly in Debian
<Seveas> hmm, my workdir is fubar
<Seveas> Kamion, :
<Seveas>   * Exit immediately if no theme is found that fits in the specified
<Seveas>     resolution.
<Seveas> why not fallback to testcard theme?
* ogra created https://wiki.edubuntu.org/EdubuntuKnot3LTSPTesting with a list of known issues for edubuntu knot3
<Kamion> Seveas: I guess we could do that too, if it fits, but I can't help feeling that at that point text output might be better (once we fix everything to be able to *get* text output)
<Seveas> ack
<Seveas> testcard theme is 640x400, so should fit virtually anything worth supporting
<Kamion> yeah, it just seems to kind of scream "hi, we broke, d'oh"
<Kamion> in a way that text output doesn't so much
<Kamion> I mean, yeah, it's visibly not pretty, but at least it can be made useful
<sfllaw> http://www.flickr.com/photos/vogoa/242601540/
<zul> sfllaw: ouch...thats kind of bloody
<Keybuk> UDSMV is too wordy, I propose FIUH
<Keybuk> or UFH would suffice
<Seveas> FIUH? 
<Keybuk> Flowers in Ubuntu's Hair :p
<Keybuk> a URL to a famous pic of dholbach may be appropriate
<ivoks> :)
<Seveas> HAHAHA
<Seveas> I know that pic dhippyolbach
<LaserJock> hahaha
<seb128> Keybuk: my desktop looked like edgy was hanging on boot (black screen with only a cursor in the top left corner), happens without the splash and the quiet boot options too. I figured after some reboot that it was doing a fsck (probably after n mount). Is that upstart to blame to not mention what is going on?
<Keybuk> the spec that says "ve vill not have ze boot messages" is to blame
<seb128> have the box stucked on a black screen for 10 mins is a bug though
<Keybuk> 10 mins?
<Keybuk> probably fsck mount count or something?
<seb128> yeah, the partition is not small
<Keybuk> you'd get the same effect with usplash
<Keybuk> it'd just sit there at a static graphic
<seb128> "figured after some reboot that it was doing a fsck (probably after n mount)"
<mjg59> Keybuk: No, usplash would drop out to the fsck text
<seb128> usplash dropped after some secs
<mjg59> 15 second timeout
<seb128> and I got the black screen with the cursor
<ivoks> seb128: but you could login, even if fscking
<seb128> no
<seb128> I got a black screen with a cursor to the top left corner
<AlinuxOS> Hello, I need to test new OpenOffice 2.0.4 tranlations + 2.16 GNOME translations for Georgian language... but I still use Dapper, is dist-upgrade quite painless for this moment ?
<seb128> no prompt
<seb128> no gdm starting
<ivoks> no? i was able to login (at alt+f2)
<ivoks> of course not gdm
<ivoks> it's read only
<Keybuk> mjg59: not it wouldn't
<Keybuk> mjg59: the fsck text would have been lost under usplash while tty8 was the active, and svgalib was owning it
<Keybuk> and usplash would have left them at an empty tty1
<seb128> ivoks: that's not a solution, do you really expect users to do that?
<ivoks> seb128: of course not, i didn't say it isn't a bug :)
<mjg59> Keybuk: In dapper
<Keybuk> mjg59: in edgy, right now
<Keybuk> I tested it not 8 hours ag
<Keybuk> +o
<mjg59> Keybuk: Uh. I'm pointing out that it's a regression, not disputing that it's the current situation.
<seb128> my issue is that with splash I had no indication of what was going on too
<Keybuk> ah
<Keybuk> sorry
<seb128> "without splash"
<Keybuk> mjg59: it seems there's no way for have usplash on an active tty, and not lose /dev/console output
<Burgwork> Kamion, are you still around?
<Keybuk> I had a bit of a fiddle
<SlicerDicer> lol Burgwork I was just about to ask
<SlicerDicer> haha
<Keybuk> the best solution I came up with was to use logd to output it to tty1 by force
<seb128> Keybuk: so if I file a bug on upstart you will close it because that's a design decision? ;)
<Kamion> Burgwork: technically yes, but I'm just off to bed, so not any more - sorry
<Burgwork> Kamion, I will catch you tomorrow. I wanted to speak to you about your SoC student
<Kamion> SlicerDicer: feel free to send mail if you can't get hold of me otherwise
<SlicerDicer> Kamion: thank you I will bother you tomorrow if I can otherwise I will mail you
<Keybuk> seb128: right
<Keybuk> you should have turned up at the boot-message-logging BOF in Paris to object <g>
<seb128> nah :p
<seb128> k, I'll bug upstart anyway ;)
<seb128> if it blocks the box for longer than some seconds it should give some hint of what is going on
<Keybuk> that will not change before edgy+1
<Keybuk> so I'll reject it anyway
<seb128> grumpf
<seb128> that is broken
<seb128> what do you think a guy having his computer blocking on a black screen for 10 min will do?
<Keybuk> arguably it's a bug in sysvinit
<Keybuk> as the checkfs scripts should ensure that what they are doing is notified to /dev/console and usplash
<seb128> I started by trying to boot without usplash and without quiet then
<seb128> then I tried to boot previous kernel
<seb128> then I booted dapper
<seb128> k
<jdong> Keybuk: I find it hard to blame sysvinit for something that worked with sysvinit but no longer works with upstart :-/
<seb128> I'm fine with opening a bug on sysvinit
<seb128> but that's a bug somewhere
<jdong> get it fixed somewhere... especialyl since we still have a periodic fsck set
<Keybuk> seb128: would you reject a bug that asked for the old GNOME logout dialog?
<seb128> yep
<jdong> it'll only take 35 bootups before we get our first rush of bug reports regarding a blank screen and hung bootup
<Keybuk> why?  because it was specced to be changed
<Keybuk> this is the same
<Keybuk> it was discussed, specced, reviewed and approved
<mdz> tkamppeter: http://www.ubuntu.com/ubuntu/components
<seb128> Keybuk: I would not reject a valid objection on the new one though
<Keybuk> the change is completely irrelevant to upstart, it's just a setting for the rc scripts
<mdz> tkamppeter: and the table on https://wiki.ubuntu.com/UbuntuDemystification
<seb128> Keybuk: I'm fine filling it somewhere else as said
<seb128> but that's a bug *somewhere*
<Keybuk> I have no problem with deciding to drop the spec entirely
<Keybuk> and revert both console and usplash to dapper behaviour
<seb128> I expect most user will think the distro is broken if it's staying there for 10min and doesn't boot
<seb128> without any indication of what is happening
<Keybuk> I don't disagree
<jdong> Keybuk: so is it not possible for upstart to "revert" to console output only if usplash times out?
<Keybuk> jdong: no, you can't change the file descriptors of a running process
<jdong> I see
<jdong> but what if it was logged to a logfile, then upstart spawns a "tail -f" on a tty when usplash fails?
* jdong just putting up a suggestion -- he has no idea what he's talking about :)
<Keybuk> <Keybuk> the best solution I came up with was to use logd to output it to tty1 by force
<Keybuk> . o O { ah, I believe we have reached the middle of this conversation }
<jdong> :)
<jdong> excuuuuse me for not reading the scrollback :P
<Keybuk> the cleanest solution is probably just to make checkfs and checkroot do things properly
<Keybuk> and make sure the message is printed
<seb128> Keybuk: basically that's https://launchpad.net/distros/ubuntu/+source/sysvinit/+bug/58609 then, right?
<Ubugtu> Malone bug 58609 in sysvinit "upstart doesn't display checkrootfs.sh messages" [Untriaged,Confirmed]  
<Keybuk> yes
<seb128> ok, thank you
<seb128> maybe you can milestone it for edgy? ;)
<Keybuk> I'm unsure who by and how the milestone field is supposed to be used?
<seb128> I use it to note the bugs I planned to try getting fixed for a distro for some time
<seb128> and nobody complained ;)
<seb128> "I plan to fix for next distro" rather
<seb128> would be a question for mdz maybe
<mdz> Keybuk: the first rule of the milestone field is, we don't talk about the milestone field
<Keybuk> mdz: that's what I thought
<Keybuk> I've been ignoring it
<mdz> it's meant to be used for, well, milestone
<mdz> s
<mdz> which I've said we don't really have a use case for
<Keybuk> my experience so far has that people just use it for an "OMG! SO CRITICAL IT HURTS!WJKREJQUU!*("$(*!_("*$(_!*"$(_I129- _!(*U"*(U*IP" type thing
<mdz> and then there's to be a different mechanism for targeting bugs to releases
<mdz> which, it's my understanding, isn't implemented yet
<mdz> Keybuk: it's supposed to be restricted to the same people who can set importance
<seb128> I milestone "edgy" something when I think it should be worked for edgy
<seb128> it works fine usually
<seb128> desktop guys look at that list
<seb128> and try to fix issues listed there in priority
<mdz> seb128: yes, but Mark has said that it isn't meant for that, and there is work in progress to have a mechanism to mark bugs for edgy
<mdz> milestone is meant to be for knot 1, knot 2, etc.
<seb128> ok
<Keybuk> what does Mark thing it's meant for?
<Keybuk> ah
<seb128> I do with what we have :p
<mdz> I know
<mdz> this is why we don't talk about it
<seb128> I see ;)
<mdz> so if you are happy then please continue quietly ;-)
<seb128> will do :)
<Keybuk> we need to take a decison about boot messages at some point
<Nafallo> ,
<Nafallo> hehe even
<Keybuk> I was going to propose it for the TB meeting
<Keybuk> but then I realised it was this week, when I was off watching Jean-Luc Prospero
* infinity fails to see why we'd need a different mechanism to define knot-1/knot-2/knot-3 and dapper/edgy/edgy+1
<infinity> They all seem to be easily definable as milestones/snapshots/releases/points-in-time, whatveer.
* Nafallo totally agrees with infinity 
<Nafallo> I was just thinking the same myself
<sistpoty> infinity: do you have some time to help with bootstrapping fpc?
* bluefoxicy puts on his wishlist a OLPC machine
<bluefoxicy> Actually I'll discuss this one with Casey
<bluefoxicy> he's pretty bright, he might have some ideas
<mdz> Keybuk: what about them?
<mdz> Keybuk: on or off?
<infinity> sistpoty: I will in a couple of hours.  I'm just doing the "wake up, pack up stuff, wander over to another house" dance.
<Keybuk> mdz: on, or off; yes
<mdz> Keybuk: sounds like an ubuntu-devel thing rather than tech board
<Keybuk> you're probably right
<mdz> or a strawman launchpad vote!
<infinity> sistpoty: If you're around in ~2 hours, bug me about it.
<Keybuk> I'll draft a mail
<Seveas> Keybuk, how about 'on only for fsck'
<bluefoxicy> (I'm pondering the potential to use OLPC-type hardware in developed countries to enhance primary school education; as a side bonus, you could potentially persuade developed countries' school systems to pay extra as a 'donation' so that the profits can go to free machines for the undeveloped schools in third world countries)
<Keybuk> Seveas: that's only implementable for edgy+1
<sistpoty> infinity: ok, I'll stay up till then ;)
<bluefoxicy> later
<sistpoty> and thx. btw. ;)
<Seveas> Keybuk, due to FF or technical reasons?
<Keybuk> technical reasons
<Seveas> usplash already can do "don't do text things unless needed"
<Keybuk> obviously "make the checkfs/checkroot scripts write over /dev/console and send usplash commands" should be possible
<mdz> speaking of fsck, did anyone else find that email odd, about flaky power causing fsck to report unexpected inconsistencies?
<Keybuk> define "needed" ?
<mdz> I've rudely killed ext3 boxen an awful lot without seeing that
<Seveas> a trivially implemented URGENTTEXT 
<Seveas> and chkfs/chkroot using it
<Keybuk> Seveas: right, I was thinking along those lines ... have check* send something to usplash and the console saying "I'M DOING A FSCK!"
<infinity> mdz: It's happened to me a few times, but I can't rule out sketchy hardware as s possibility, so never bothered to distill images and hurl them at Ted.
<mjg59> Keybuk: We still run into problems if the fsck hits anything unexpected and needs user input
<Keybuk> mjg59: < /dev/console
<mdz> Keybuk: it might be possible to run fsck in a "tell me if you're going to take a while" mode
<mjg59> Keybuk: For edgy?
<Keybuk> we could wimp out and do exec </dev/console >/dev/console 2>&1 at the top of check* too
<Keybuk> though we'd have to kill usplash or something
<mdz> Keybuk: what's on stdin for boot scripts now?
<Keybuk> which is tricky :p
<Keybuk> mdz: /dev/null
<Seveas> s/the top/if it really goes to check things/
<mdz> Keybuk: I like that in a sadistic sort of way, to foil packages which do stupid things during boot
<Keybuk> mdz: right
<mdz> like that package which was in the laptop task in...woody? potato?
<Keybuk> it saves the boot hanging on some silly package trying to ask questions in the boot process
<Keybuk> or blocking on tty
<Keybuk> etc.
<mdz> the only other use case I'm aware of is interrupting dhclient
<Seveas> cryptsetup
<mdz> which shouldn't block anymore in a default config, right?
<mdz> Seveas: hmm, good point
<Keybuk> right, that is supposed to get called from a udev rule
<mdz> I think cryptsetup is pretty hosed in the new world order anyway though
<Seveas> indeed
<Seveas> although now that usplash supports INPUT, cryptsetup may recover pretty nice
<infinity> apache with passphrases on SSL certs (something I always recommend against, mind you) is hosed in the new world order too.
<infinity> That's something I'm happy about, mind you.
<infinity> One more reason to point and laugh at people who think they're doing something reasonable.
<Nafallo> that seems like more paranoia than me current firewall :-P
<Keybuk> cryptsetup is equally hosed as checkfs and checkroot
<Nafallo> s/me/my/
<Keybuk> those are the three things that I'm aware of that can halt the boot process, ask for input, and probably should continue to do so
<Nafallo> I'm the only one who misses all that text? :-)
<Seveas> hehe
<infinity> I miss it desperately when booting without splash.  The complete lack of visual feedback on a black screen for a minute or twois very disconcerting.
<slomo_> Nafallo: nope ;)
<Seveas> boot without 'quiet'
<infinity> Seveas: That will get me kernel messages, won't get me anything from init anymore.
<Nafallo> Seveas: will that get my usplash to display text again? :-)
<Seveas> Nafallo, yes
<Nafallo> what infinity said though :-P
<Keybuk> infinity: that's actually a bug of the "keybuk can't spell quiet" variety
<Seveas> infinity, hmm, then I misunderstood Keybuk 
<infinity> Keybuk: Oh, hah.
<Seveas> I thought upstart looked at 'quiet'
<Seveas> ah
<Keybuk> however the Ice Queen has frozen ubuntu yet again ;p
* Seveas pipes keybuk through aspell
<Keybuk> Seveas: "quite" is an entirely valid word
<Seveas> true
<Nafallo> lol
<Seveas> trigraphs to the rescue
<Nafallo> that's totally worthy of an upload after knot-3 I hope? :-)
<Keybuk> yes
<infinity> Still, not sure I want to get 12 screens of kernel vomit just to get my 30 lines of init script output back.
<Keybuk> the ice queen didn't event want me to upload a fix for ppc or sparc :p
<Keybuk> let alone something that trivial
* infinity shrugs indifferently at this new world order.
<Keybuk> infinity: quiet, verbose ... pick one :p
<infinity> Makes sense for desktops, I'm still unconvinced for systems without a splash.
<Nafallo> Keybuk: maybe you could implement a third word? :-)
<Keybuk> infinity: *shrug* like I said earlier, most grown up UNIXes don't bother with the 30 lines of init script output either
<Keybuk> the most annoying thing about those 30 lines is that an error message in the first 6 is lost
<Nafallo> something like "messages" :-)
<infinity> Keybuk: There you go, you just defined 3 states, problem solved.  :)  quiet: no output, verbose: Oh god, too much, neither: give me init and no kernel. :)
<Keybuk> infinity: that involves a kernel patch, no? :p
<infinity> Keybuk: Yes.  We're hardly against that. :)
<Keybuk> the boot-message-logging spec actually defines several levels
<Keybuk> the problem is that it's unimplementable for edgy
<Seveas> crackful
<Keybuk> for edgy, we can implement two levels.  "on" and "off"
<Keybuk> actually, that isn't entirely true
<Keybuk> we can implement three if we change the kernel
<Keybuk> though colin wants a verbose option to mean "ignore the earlier quiet option"
<Keybuk> tbh though, I don't see the win of three levels
<Nafallo> Keybuk: so "messages" then :-)
<Seveas> we could name the 3rd level infinity 
<Keybuk> Debian always traditionally spat the kernel output over the init script messages
<Keybuk> and never had a problem with that
<Keybuk> a minimal/silent grown-up boot is the logical opposite to that
<Nafallo> well, people with Debian knows that, we have already diverged from that :-)
<Keybuk> mdz: what happened to getting rid of the grub messages?
<mdz> Keybuk: it's done, but we don't do grub-install on upgrade
<infinity> Keybuk: I never used to mind the kernel and init both spewing together, but modern kernels have become MUCH more verbose.
<mdz> Keybuk: zul did it
<mdz> I think we should change the message though
<Keybuk> "the message" ?
<mdz> it prints "Booting the operating system now"
<mdz> so that something is on the screen while the kernel loads
<mdz> I think it should just say "Starting up" or so
<mdz> too much technical jargon
<Nafallo> maybe we should ask mpt what he would like? :-)
<Keybuk> infinity: I don't think that's true ... I think that modern kernels just load modules at different times
<mdz> I will ask his opinion
#ubuntu-devel 2006-09-14
<Keybuk> whoah, funky console font
<tseng> are cd dailies good?
<tseng> i need a cd image now, so i could test something for knot3 if thats of any use
<Nafallo> tseng: they are hopefully on the way to knot-3 so... ;-)
<yogurtthewise> hi there
* Keybuk has a sick idea
<Seveas> when don't you?
<Keybuk> have a "spinner" job that runs on the console doing / - \ | and is killed when the first getty runs
<Keybuk> :p
<Seveas> I love it
<Seveas> it shows activity
<yogurtthewise> I just managed to create a package for moc 2.4 for ubuntu, compiles perfectly and package builds with no prob. what should I do to see it included?
<yogurtthewise> there's an unofficial deb pkg I started from, it's very easy, but it diverges from debian repos, so dunno if it can actually be accepted by ubuntu
<yogurtthewise> but there are lots of important improvements over the available 2.3
<Nafallo> yogurtthewise: ask on #ubuntu-motu please :-)
<yogurtthewise> oh, ok, ta
<Keybuk> mdz: if he could just print "Starting up ... " and no \n, that would work rather well
<mdz> Keybuk: go for it
<mdz> Keybuk: debian/patches/quiet.diff
<Keybuk> post-knot3 :)
<Keybuk> right, bed
<Keybuk> some evil early meeting tomorrow
<imbrandon> mdz, ping
<imbrandon> still awake ?
<mdz> imbrandon: yes, it's afternoon in california
<Nafallo> :-)
<imbrandon> mdz, ahh dident know you were in cali ;)
<imbrandon> mdz, can you poke a look at bug 60319 , i know its not your day to do archive stuff but before i subscribed the archive you are the current mainatiner for that package
<Ubugtu> Malone bug 60319 in mythtv "please mythtv sync 0.20 from debian-multimedia" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/60319
<imbrandon> just wanted to get you to eyeball it if you had time, i pbuilt it and ran it, seems ok
<mdz> imbrandon: the package lies; I haven't maintained it for years now
<imbrandon> it will close about 5 misfiled sync requests and a few bugs
<imbrandon> ahh okies hehehe, i was just going by the LP maintainer ;)
<mdz> imbrandon: bringing in the latest from debian-multimedia is the right thing to do
<imbrandon> i'll just subscribe archive then , it should be cool as i did all the normal checks
<imbrandon> ;)
<imbrandon> wow i just realized the title words were scrambled heh
<Seveas> imbranyodan 
<imbrandon> Seveaayeas
<hikenboot> anyone with any experience with the ubuntu-desktop package and rewriting its metadatabase to include a dummy package instead of openoffice?
<Burgwork> hikenboot, that is maintained in bzr, you can pull it down yourself and play with it
<hikenboot> sorry for being dumb..but bzr?
<Burgwork> distributed revision control
<Burgwork> http://bazaar-vcs.org/
<hikenboot> thanks...
<Nafallo> gaah. I was just about to past the url :-P
<hikenboot> ah ok that is to ubuntu as mercurial is to xen
<Kamion> ubuntu-meta is not maintained in bzr; the seeds are, but if you just want to change the dependencies around a bit, it's much less of a waste of your time to just do 'apt-get source ubuntu-meta' and fiddle
<hikenboot> ah ok thanks kamion
* Nafallo makes future plans on becoming more active in the linux world again :-)
<pygi> Nafallo, ;)
<Kamion> Burgwork: the list of what packages are really maintained in bzr is here: https://wiki.ubuntu.com/BzrMaintainedPackages
<Kamion> ... and back to bed
<Nafallo> Kamion: :-)
<hikenboot> thanks guys I will investigate to see where this all takes me!
<Nafallo> damn Kamion, I must say you're not a heavy sleeper when IRC can wake you ;-)
<Burgwork> Kamion, right, my bad. Now sleep
<jamadagni> hello
<jamadagni> can anyone tell me why gstreamer0.10-plugins-ugly-multiverse is in universe and not multiverse?
<Nafallo> jamadagni: it's in multiverse
<jamadagni> @Nafallo. I've got multiverse disabled from my repo list, but i still see it in adept
<Nafallo> jamadagni: do apt-cache madison gstreamer0.10-plugins-ugly-multiverse to see for yourself. if you can see it, it might be cause you have it installed? :-)
<Nafallo> I'm not using Kubuntu myself.
<jamadagni> ftp://in.archive.ubuntu.com/ubuntu/pool/universe/g/gst-plugins-ugly-multiverse0.10
<jamadagni> but also; ftp://in.archive.ubuntu.com/ubuntu/pool/universe/g/gst-plugins-ugly-multiverse0.10
<jamadagni> crazy
<Nafallo> that's not even current edgy
<Nafallo> and that's the same URL twice
<Nafallo> gstreamer0.10-plugins-ugly-multiverse |   0.10.4-1 | http://ftp.acc.umu.se edgy/multiverse Packages
<Nafallo> gstreamer0.10-plugins-ugly-multiverse |   0.10.4-1 | http://archive.ubuntu.com edgy/multiverse Packages
<Nafallo> gst-plugins-ugly-multiverse0.10 |   0.10.4-1 | http://ftp.acc.umu.se edgy/multiverse Sources
<Nafallo> gst-plugins-ugly-multiverse0.10 |   0.10.4-1 | http://archive.ubuntu.com edgy/multiverse Sources
<jamadagni> ftp://in.archive.ubuntu.com/ubuntu/pool/multiverse/g/gst-plugins-ugly-multiverse0.10
<Nafallo> hmm, so misplaced binaries.
<jamadagni> misplaced sources as well
<Nafallo> no
<Nafallo> the source is in multiverse for dapper aswell
<Nafallo> according to the urls you just sent...
<Nafallo> or rather... the source for -3 is lacking...
<jamadagni> the pool is common for all distros, no?
<Nafallo> but see archive.ubuntu.com. it's the in-mirror that's wrong :_)
<Nafallo> :-)
<jamadagni> i mean, for all versions
<Nafallo> yess
<Nafallo> yes
<Nafallo> ooh. a.u.c has them in both places... interesting ;-)
<Nafallo> infinity: ^ :-)
<jamadagni> what?
<jamadagni> ftp://archive.ubuntu.com/ubuntu/pool/universe/g/gst-plugins-ugly-multiverse0.10
<infinity> If it's in two components, that would mean it had an override change recently (and is making a smooth transition from A to B)
<Nafallo> infinity: where recently is in dapper? :-)
<infinity> Oh.  I see.  It was in universe in dapper, andin multiverse in edgy.
<jamadagni> confirmed at ftp://se.archive.ubuntu.com/ubuntu/pool/universe/g/gst-plugins-ugly-multiverse0.10
<jamadagni> if it was in universe in dapper then why is it labeled multiverse?
<jamadagni> i mean, in the package name itself?
<jamadagni> is infinity one of the ubuntu devels?
<Nafallo> infinity: where are the sourcecode for the latest dapper version? -3? :-)
<Nafallo> jamadagni: he is one of the archive gods :-)
<jamadagni> meaning?
<infinity> Nafallo: That's a far more interesting question.
<jamadagni> he maintains the archives or is just highly knowledgeable about them?
<infinity> jamadagni: yes.
<Nafallo> jamadagni: both of that I would say :-)
<infinity> Nafallo: Err, wait.  -2 should be the latest dapper version.
<jamadagni> perhaps -3 was a backport or something
<infinity> Nafallo: -3 is an obsolete edgy version.
<Nafallo> infinity: ehm, okey. so that's a bug that the binaries is in the archive then :-).
<infinity> Nafallo: The fact that the binaries appear to have not been correctly reaped looks to be a soyuz bug.
<jamadagni> i reported https://launchpad.net/distros/ubuntu/+source/gst-plugins-ugly-multiverse0.10/+bug/60327
<Ubugtu> Malone bug 60327 in gst-plugins-ugly-multiverse0.10 "gst-plugins-ugly-multiverse is present in universe as well as multiverse" [Untriaged,Unconfirmed]  
<Nafallo> indeed
<jamadagni> just now
<infinity> https://launchpad.net/distros/ubuntu/+source/gst-plugins-ugly-multiverse0.10/0.10.3-3 <-- That screams "oh god, the DB is broken" to me.
<Nafallo> infinity: https://launchpad.net/distros/ubuntu/edgy/+source/gst-plugins-ugly-multiverse0.10 <-- isn't that worse then? -2 is still there :-P
<infinity> Nafallo: What's wrong with that?
<Nafallo> infinity: ...but that is probably because hppa was build on -2 :-)
<infinity> Nafallo: Yes.  Exactly.
<Nafallo> why are the old source in the archive still? :-)
<infinity> Nafallo: Until/unless we drop hppa completely for edgy (which we should do), you'll see stuff like that.
<Nafallo> ah, oki. so known bug + fix then ;-)
<infinity> Not a bug at all.
<infinity> That's behaving as designed.
* milli looks over at lamont
<Nafallo> oki, feature then :-)
<infinity> Well, unless you consider "hppa won't make the edgy release, and should be removed until we bootstrap edgy+1" a bug, which I suppose you could.
<Nafallo> yea, that was it :-)
<jamadagni> i386, powerpc and amd64 are the only three supported ubuntu archs, right?
<jdub> GOOD MORNING FREEDOM LOVERS!
<zul> hey jdub 
<Nafallo> jamadagni: sparc aswell
<Nafallo> jdub: morning :-).
* milli is away: Attending to something else, for a variety of possible reasons
<jamadagni> nafallo yes
<infinity> jamadagni: Sparc for -server
<Fujitsu> Good morning, jdub.
<infinity> jamadagni: The other three for desktop and server.
<Nafallo> woha! just did a apt-cache search xen :-P
<Nafallo> lots of images with diffrent kernels :-)
<Seveas> GOOD MORNING PANTS!
<Seveas> (iow: hi jdub)
<Fujitsu> Hahah.
<Nafallo> infinity: is there a reason soyuz allows binaries without source in the archive? :-)
<infinity> Nafallo: It doesn't.  The thing you just found is a bug.
<Nafallo> infinity: want me to report it against something or do you handle it? :-)
<infinity> Nafallo: I'm already on it.
<Fujitsu> infinity, you mean it's not meant to. It obviously does :P
<Nafallo> nice thanks :-)
<infinity> Fujitsu: Well, no.  In this case, it looks like a hideous DB inconsistency caused the sources to be removed because we thought the binaries were removed (actually, the whole sourcepackage release seems to have gone missing), but the binaries stayed on-disk.
<infinity> Fujitsu: I'm not prepared to commit to this being a code bug yet, it could have been someone's manual futzing in the DB gone horribly wrong.
<Fujitsu> Why would anybody have been manually screwing around with the DB?
<infinity> (Either way, it's a bug in the archive, obviously)
<Fujitsu> A pretty silly thing to do...
<infinity> Fujitsu: Happens all the time, really.
<infinity> Fujitsu: Usually to clean up after bugs. :)
<Fujitsu> Heheh.
<infinity> (Design me a perfect system, and I'll be happy to use it)
<jamadagni> ok guys bye bye. looks like i started a good discussion
<Nafallo> infinity: I thought you where a perfect system? :-)
<Nafallo> jamadagni: indeed, thanks :-)
<Nafallo> jamadagni: and see you :-)
<infinity> Nafallo: Sure, but I'm not that tightly integrated into soyuz. :P
<infinity> (Nor did I write it)
<Nafallo> :-)
<jamadagni> ok before i go:...
<jamadagni> has https://launchpad.net/distros/ubuntu/+source/usplash/+bug/39173 been fixed for edgy?
<Ubugtu> Malone bug 39173 in usplash "usplash messages look a little bland and a little intimidating" [Wishlist,Confirmed]  
<jamadagni> bugs 60084 and 60090 as well
<Ubugtu> Malone bug 60084 in kdepim "KMail should have a menu item in Kubuntu default install" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/60084
<Ubugtu> Malone bug 60090 in kdebase "Konqueror Archive Web Page tool no longer automatically converts spaces to underscores" [Unknown,Confirmed]  http://launchpad.net/bugs/60090
<infinity> jamadagni: The plan for edgy is to have no text messages on the splash at all.
<jamadagni> fine, but at least will the graphic look nice?
<infinity> jamadagni: Also, please don't ask for progress of dozens of bugs here.  Just subscribe to the bugs.
<jamadagni> ok sorry
<jamadagni> i've already subscribed
<jamadagni> bye then
<infinity> I appreciate you bringing archive breakage questions here, though, cause those are sometimes urgent. :)
<infinity> (Though this one's not so urgent)
<infinity> But every archive oddity has the potential to make me run around for hours like a headless chicken.
<jamadagni> ok thanks infinity bye
* Fujitsu chops of infinity's head
<Nafallo> lol
<infinity> Oh dear lord, the embarassment.  It's been so long since I've used CVS, I need to RTFM to figure out how to do a checkout.
* infinity hangs his head in shame.
<Fujitsu> infinity, be happy. CVS is a good thing to forget about.
<infinity> (Okay, I still use it reasonably frequently on existing checkouts on my hard drive, but that's just "up" and "commit" over and over, I've not checked anything out for well over a year, I'm sure)
<infinity> Amazing how quickly knowledge goes stale and gets punted off my stack.
<Nafallo> infinity: you're not alone! :-)
* Nafallo only uses bzr everywhere now days ;-)
<Seveas> <infinity> But every archive oddity has the potential to make me run around for hours like a headless chicken. <-- that just screams for a webcam
<Seveas> Nafallo, likewise 
<Nafallo> Seveas: my thought exactly, if he ever gets one, noone will tell him about those strange things though :-P.
<infinity> Nafallo: I use a mix of svn, baz (yes, still, ugh), bzr, and apparently occasionally cvs.
<infinity> If I could rid my life of cvs and baz, and be left with just svn and bzr, I'd be pretty happy.
<Nafallo> infinity: hmm, tailor them? :-)
<bddebian> Howdy folks
<sistpoty> infinity: got some time now?
<infinity> sistpoty: Yup.
<sistpoty> infinity: great :)
<sistpoty> infinity: bootstrapping fpc should be pretty straightforward, see bug #2253
<Ubugtu> Malone bug 2253 in fpc "fpc needs bootstrapping on buildds" [Medium,Confirmed]  http://launchpad.net/bugs/2253
<jamadagni> hello i'm back
<jamadagni> i have a question about overrides which i'm sure only the devels can answer so i'm asking here
<sistpoty> infinity: it just need fp-compiler, fp-units-rtl and fp-utils available (all built by fpc itself)
<jamadagni> i'm looking at ftp://in.archive.ubuntu.com/ubuntu/indices
<jamadagni> the files override.dapper*
<jamadagni> most of them i can conjecture what they are for
<jamadagni> but override.dapper.extra.* i don't know what they are for
<jamadagni> please tell me
<infinity> sistpoty: Wow, I promised to help in July?  I suck.
<infinity> sistpoty: I'll do it today.
<sistpoty> infinity: no, I suck... I pinged you only once before ;)
<jamadagni> i mean, everything else is related to a pool category or backport or update or security
<sistpoty> infinity: thx :)
<jamadagni> that's all understandable
<jamadagni> but what is this extra?
<jamadagni> which component does it go under?
<jamadagni> sorry
<jamadagni> obviously there are "extra" packages under all four components
<jamadagni> but what can we expect to be there, i mean, what kind of pakages?
<infinity> jamadagni: Regular overrides only handle section and priority.  extraoverrides are for "other stuff" we want to override in Packages.gz, like Origin, Bugs, Tasks, etc.
<jamadagni> man:dpkg-scanpackages tells me that override files provide information related to the arrangement of files for release
<jamadagni> extra overrides doesn't come under that, right?
<infinity> dpkg-scanpackages is a bit outdated in that respect. :)
<jamadagni> oh then what else are overrides for?
<jamadagni> origins, bugs and tasks obviously
<infinity> It still assumes an old-style archive layout, where packages live in the mirror under section and priority.
<jamadagni> oh of course that is not the case now, right?
<infinity> But overrides are used now for overriding various headers in the Packages file (as seen in "apt-cache show <package>")
<jamadagni> ok i tried apt-cache show knemo and i get the headers for that package
<jamadagni> what would the override change?
<infinity> jamadagni: In that case, probably theonly things overridden are "Origin" and "Bugs"
<infinity> jamadagni: A more interesting one would be something that's in a task, like metacity.
<jamadagni> i don't comprehend - tal
<infinity> jamadagni: That will have a Task header added, with "ubuntu-desktop, edubuntu-desktop"
<jamadagni> sorry - i don't comprehend task
<infinity> jamadagni: And, of course, if the binary package's priority/section don't match with what we (the archive admins) want, that will be overridden too.
<jamadagni> google does not help here
<infinity> jamadagni: Tasks are usedby the installer and tasksel to select groups of packages.
<jamadagni> oh like metapacakges
<infinity> In our case, we have a 1:1 mapping between some tasks and metapackages, yes.
<infinity> But tasks don't have to have a corresponding metapackage (and we have some that don't)
<jamadagni> so tasks are developer-side only?
<infinity> For instance:
<infinity> (base)adconrad@cthulhu:~$ apt-cache show mysql-server-5.0 | grep ^Task
<infinity> Task: lamp-server
<jamadagni> ok task = purpose of a package
<infinity> So, the installer can cleverly use that task to install a LAMP server.
<infinity> Not a purpose, no.  It's a package grouping.
<jamadagni> right
<jamadagni> so when i say "give me a lamp-server", it installs all the packages marked with task=lamp-server and presto
<jamadagni> i have a lamp-server
<jamadagni> right?
<infinity> (base)adconrad@cthulhu:~$ grep-dctrl -FTask -sPackage lamp-server /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_edgy_main_binary-i386_Packages 
<infinity> [...] 
<infinity> Package: apache2
<infinity> Package: apache2-common
<infinity> (Lots of output)
<infinity> Hrm, and I'll note that task is actually broken.  Cute.
* infinity fixes.
<Nafallo> :-)
<Nafallo> infinity finds bugs everywhere today ;-)
<infinity> It's my lot in life.
<jamadagni> pest-eradication!
<jamadagni> glad that i could do my indirect bit to help :)
<jamadagni> hey, before i say byebye again, just one q -
* infinity uses his 4th revision control system of the day and feels himself going slowly insane...
<jamadagni> how do you do that "* infinity fixes* sort of message on irc here?
<infinity> jamadagni: "/me does stuff"
* jamadagni is going off for prayers, then
* jamadagni thanks all great friends here, especially most informative and knowledgeable infinity
* jamadagni says chee you, bai bai
* milli is back (gone 00:53:40)
<infinity> milli: Please don't use verbose away/back messages in this channel.
<milli> sorry
<milli> didn't know they were verbose
<infinity> milli: Anything is verbose. :)
<infinity> milli: With as many people as we have in here, if everyone printed something on away/back, we'd be flooded with it.
* milli makes the annoyance go away
<jdong> ooh, did I hear correctly that ooo 2.0.4 is to be native for amd64 users?
<LaserJock> looks like it
<infinity> jdong: That's the plan, if it works okay.
<jdong> cool
<rodarvus> mdz, ping
<bluefoxicy> infinity
<mdz> rodarvus: yes?
<bluefoxicy> you're in charge of the buildd's right?
<infinity> bluefoxicy: Yes.
<rodarvus> airlied just made a comment on bug #34435, I would appreciate your comment on it
<Ubugtu> Malone bug 34435 in gtk-engines "Cairo and ATI RENDER extension cause scrambled buttons in UbuntuLooks" [Unknown,Unconfirmed]  http://launchpad.net/bugs/34435
<bluefoxicy> OK, I've been told a number of things, most recently that there's absolutely no gcc wrappers and no global CFLAGS/LDFLAGS/etc on the buildd, this is correct?
<infinity> bluefoxicy: For edgy, that's correct, yes.
<bluefoxicy> alright
<rodarvus> he recommends us to just skip the patch (which he commited to git) and use 6.5.8.1 instead
<bluefoxicy> Other stuff I wanted to talk about is setting a couple options default for Edgy+1, is there a meeting I should show up at or should I talk to doko or you?
<rodarvus> (but imho it would be safer to apply the patch for now, ask users to test it, and then, without rush, consider updating the ati driver to the above mentioned version)
<infinity> bluefoxicy: We decided in Paris that compiler defaults belongin the compiler spec file (we had some VERY long arguments about it, surrounding the stack-protector change), so yeah, discussing itin #ubuntu-toolchain would be best, and you'll want doko present.
<bluefoxicy> infinity:  nods.  When is doko normally around?  He's hard to come by :)
<infinity> bluefoxicy: Ifit's contentious, you'll want to set up a meeting and invite a few other key people who like to argue about such things (me and mdz, perhaps)
<infinity> bluefoxicy: He tends to be around during standardish European work hours.
<bluefoxicy> infinity: what would be contentious?
<bluefoxicy> things with stability/performance trade-offs?
<infinity> bluefoxicy: Anything that (like -fstack-protector) has a high chance of breaking more than a few packages, or something that will cause performance hits, etc.
<rodarvus> doko is on OOoCon today (and I guess for a few days still)
<bluefoxicy> ah  Hmm european work hours  I'mat gmt-5 ... it's 1am
<infinity> bluefoxicy: If it's security-related (as many of the things you tend to look at are), you may also want to bring pitti along for the ride.
<rodarvus> it will quite probably be hard to find him
<bluefoxicy> infinity:  it's performance stuff, some of meeks' work went into next mainline glibc/ld and I want it enabled by default due to the officially acclaimed 50% application load speed-up
<bluefoxicy> and a couple nit-picky things that I bring up every several months anyway
<infinity> bluefoxicy: pitti is also in Europe-land.  mdz is all over the map, depending on which hotel he's in this week, and I never sleep.
<bluefoxicy> haha
<mdz> rodarvus: I'm subscribed to that bug and have been commenting already
<Nafallo> lol
<Nafallo> all to true :-)
<rodarvus> mdz, yes, I know
<mdz> rodarvus: if you're asking about dapper, we're not even going to discuss it until the fix has been working well in edgy for an extended period
<bluefoxicy> infinity:  I'll keep an eye open in #-toolchain then
<mdz> he's provided a patch which should be able to go into edgy immediately
<rodarvus> sure, seems reasonable
* bluefoxicy gets back to trying to finish the Web site for his allocator... deadline is this friday.
<desrt> bluefoxicy_alloc (sizeof (int));
<bluefoxicy> desrt:  no, replacement for crappy Ptmalloc in glibc
<desrt> ptmalloc is glibc's current allocator?
<bluefoxicy> desrt:  i'm _really_ going to try to finish this by december but we all know how that goes *glares at the other 15 sourceforge projects that don't have any code*
<bluefoxicy> desrt:  yes
<desrt> bluefoxicy; you should see if glib would accept your code
<bluefoxicy> Last I looked it was, in fact Wolfram Gloger's home page says it is.... http://www.malloc.de/en/
<desrt> bluefoxicy; that would probably provide MONTHS of amusement
<bluefoxicy> "On Linux systems, ptmalloc has been put to work for years as part of the GNU C library."
<bluefoxicy> heh
<bluefoxicy> desrt:  that's probably a really bad idea ;)
<desrt> bluefoxicy; i'm sure people are calling free() instead of g_free() and g_free() instead of free() everywhere
<desrt> bluefoxicy; and we'd find out really really quickly :)
<bluefoxicy> desrt:  yeah with my tiered micro-heap design you'd find out really, REALLY quickly
<bluefoxicy> the structure isn't even remotely the same
<desrt> :)
<bluefoxicy> hell, the structure isn't remotely the same between allocations of 128 bytes and allocations of 129 bytes
<bluefoxicy> allocations of 3967 bytes and 4091 bytes act the same, but allocations of 3968 bytes or 4096 bytes act like allocations of 128KiB
<bluefoxicy> desrt:  is g_free() and g_malloc() any more than a wrapper around malloc() anyway?
<desrt> bluefoxicy; in theory yes
<desrt> bluefoxicy; in implementation, no
<desrt> bluefoxicy; which is exactly why people are getting away with things that they ought not to be
<bluefoxicy> desrt: http://steel-malloc.sf.net/ *shameless plug* :>
<desrt> that's an awful name :)
<desrt> but i wish you luck :)
<bluefoxicy> hah
<bluefoxicy> desrt:  on my wishlist is getting Wolfram Gloger's mtrace tool working on Ubuntu, so I can get good numbers for memory waste; last I tried it claimed that after 5 minutes and 2 messages read, Thunderbird had managed to average having twice as much memory allocated to it than it requested via malloc() :P
<bluefoxicy> anyway, back to what I was doing
<desrt> have fun :)
<Seveas> desrt, nice vim syntax file 
<desrt> Seveas; enjoy :)
* infinity kicks wiki.ubuntu.com
<infinity> I hope that doesn
<infinity> 't make it even slower...
<Hobbsee> infinity: it will.  try to figure out some way to exploit murphy's law over it.
<jdub> Hobbsee: congrats on your new role :)
<Hobbsee> jdub: um, thanks?  
<infinity> New role?
<infinity> Was I stripped of my "most bizarre Australian" title when they discovered I wasn't born here?
<Hobbsee> infinity: kubuntu community coordinator, i assume, but i'm not sure how jdub found that out, as i didnt tell pia that yesterday.
<jdub> UWN
<Hobbsee> and i've had it for a while :P
<zul> Hobbsee: heh...we know everything
<Hobbsee> zul: no you dont :P
<Hobbsee> zul: tell me when my work will next be held up, so i can be prepared with something a little stronger than my voice.
<zul> Hobbsee: uh.......january....8th....2013..no...2014
<Hobbsee> heh
<Hobbsee> right
<CarlFK> daily alternate w/ preseed file just started asking "Detect keyboard layout?" and it does it before the preseed file is even loaded. anyone know if this is expected, or should I bug report it?
<jamadagni> i'm back
<jamadagni> can i ask for help on local repos here or is that ot
<TheMuso> jamadagni: You might find you will get more help in #ubuntu-motu.
<jamadagni> @TheMuso i'll try there
<jamadagni> thanks
<jamadagni> noone there
<jamadagni> please let me ask it here once
<jamadagni> please see http://paste.ubuntu-nl.org/23399
<jamadagni> i created a local repo using dpkg-scanpackages
<jamadagni> the location of the packages.gz file is /home/samjnaa/is
<jamadagni> the location of the packages is /home/samjnaa/ab/_official
<jamadagni> what to do?
<infinity> What was your dpkg-scanpages command line?
<infinity> packages, even.
<infinity> Anyhow, you probably just want to add a path prefix of "../.." and you'll beset.
<infinity> s/beset/be set/
<jamadagni> sudo dpkg-scanpackages /home/samjnaa/ab/_official override.dapper | gzip -9c > Packages.gz
<jamadagni> the override-dapper is a cat of many overrides from the indices
<infinity> sudo dpkg-scanpackages /home/samjnaa/ab/_official override.dapper ../.. | gzip -9c > Packages.gz
<jamadagni> oh ya
<jamadagni> i saw the error just now
<jamadagni> i could hug you infinity
<jamadagni> :D
<infinity> I'll hug myself instead, should save you the effort.
<bddebian> heh
<infinity> And the airfare...
<Hobbsee> infinity: jamadagni may have very long arms
<jamadagni> well i have long fingers :)
<jamadagni> i'm getting too many Package kcoloredit has `Section: universe/graphics', but file is in `kde-3.5.2--koffice-1.5.0' !!
<jamadagni> kind of messages because my repo strucrture is different
<jamadagni> from what is in the override
<jamadagni> seriously do i need to override file or can i use /dev/null as inoput
<jamadagni> or is there any other way i can suppress those errors
<jamadagni> ok i think i got it bye
<imbrandon> crimsun, ping
<imbrandon> bddebian, ping also
<bddebian> imbrandon: Yessir?
<imbrandon> can i get you to eyeball ( even though tech not required ) http://revu.tauware.de/details.py?upid=3108 , i dunt wanna mess up my first lib package ;)
<bddebian> Egads, you want ME to look at a library package? :-)
<imbrandon> hehe i figure the more eyeballs the better ;)
<imbrandon> its the first time i did a lib package from scratch soo heh
<ajmitch> imbrandon: running revu-report on it now
<imbrandon> cool thanks ajmitch
<imbrandon> revu-report? sounds like something i need in my toolbox heh
<ajmitch> imbrandon: it's a tool on tiber
<imbrandon> ahh cool
<ajmitch> builds & checks some things
<imbrandon> nice
<ajmitch> so why'd you choose libmtp1?
<imbrandon> becouse it was libmtpBROKEN before heh
<ajmitch> and why are you missing any sign of shlibs stuff?
<imbrandon> probably becouse i havent done a lib package heh thus the input ;)
<ajmitch> uh oh
<imbrandon> the ubuntu guide dosent cover libs much
<imbrandon> s/much/any
<imbrandon> so i pretty much dh_make'd it and went from there
<bddebian> imbrandon: Nope.  I have a guide though if I can find the damn URL again
<imbrandon> nice , yea that would be cool
<bddebian> http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
<bddebian> Hmm no linda and only 1 lintian warning though..
<bddebian> Hmm, probably because the .debs are pretty much empty :-)
<Kagou> good morning
<infinity> Huzzah, I fixed my space bar!
<infinity> Take that, IBM.
<infinity> This, of course, will be the high point of my day.
* Hobbsee immediately borks infinity's space bar again.
<infinity> Hobbsee: I don't think I like you anymore.
<Hobbsee> infinity: heh
<Hobbsee> infinity: is that a good thing then?
<infinity> Fixing my space bar, or not liking you?
<Hobbsee> infinity: the latter
<infinity> I suppose not being liked by me is probably a good thing.
<StevenK> Bwahaha
<infinity> Though, being liked by me is better than being liked by StevenK. :P
<Hobbsee> infinity: yes, i've met StevenK.  quite scary, really.
<StevenK> infinity: Keep grinning, I'm reloading. :-P
<infinity> Hobbsee: After seeing pictures, I turned down an opportunity to meet him. :)
<Hobbsee> infinity: hehe, smart.  i needed him to sign my key though.  both of them.
<StevenK> infinity: Hmph
<Hobbsee> infinity: you just dont dare to visit sydney.
<StevenK> He has done
<Hobbsee> silly melbournians :P
* Hobbsee pouts
<Hobbsee> i didnt get a visit :P
<infinity> Hobbsee: I've not been to Sydney since I became aware of you, honest.  Or somehting.
<infinity> Hobbsee: Not since Ubuntu Down Under, actually.  I'm about due for another visit.  LCA, I suppose.
<Hobbsee> infinity: true that.  i guess i'll have to let you off the hook then.
<fabbione> morning
<Hobbsee> hey fabbione!
* StevenK is still wondering about LCA
<Hobbsee> StevenK: what are you thinking about it?
<StevenK> Hobbsee: Whether I go or not
<Hobbsee> StevenK: well, yeah...
<StevenK> Hobbsee: The other point is who from $WORK is going and how that fits in
<Hobbsee> StevenK: point.
<fabbione> hi Hobbsee 
<infinity> StevenK: I doubt I'll be attending the actual conference much (if at all), it's just an opportunity to find a bunch of friends and co-conspirators in one town together, soI'll head in for a day or two to catch up over beers and the like.
<Hobbsee> infinity: that's a good idea.
<ajmitch> sounds like fun
* ajmitch has to work out if he can afford it
<pitti> Good morning
<imbrandon> moins pitti
<dholbach> good morning
<fabbione> hey dholbach 
<dholbach> hey fabbione
<lifeless> doko: around ?
<Burgundavia> Mithrandir: ping (re: knot 3)
<doko> lifeless: pong
<Mithrandir> Burgundavia: hiya
<Burgundavia> Mithrandir: you on track for a release today?
<lifeless> https://demo.launchpad.net/products/automake
<lifeless> doko: ^ thats the upstream product finding logic in operation on the lp demo sit
<lifeless> e
<Mithrandir> Burgundavia: mostly so, yes.
<Mithrandir> Burgundavia: making what I hope are the final builds now.
<Burgundavia> ok, no worries
<lifeless> doko: compare with https://launchpad.net/products/automake
<doko> lifeless: where do I see the relation to the version in edgy?
<lifeless> doko: thats coming
<lifeless> doko: one step at a time man!
<doko> lifeless: ok, but that was my original spec (comparing versions in ubuntu with upstream and debian)
<lifeless> yes, I realise
<lifeless> it needs a packaging record added
<lifeless> doko: i.e. : https://demo.launchpad.net/products/automake/1.9
<lifeless> doko: I've added the packaging record for the 1.9 series
<lifeless> doko: that can be done right now in the production launchpad
<lifeless> for each series, its just 'click on 'link to ubuntu package' (to register for edgy), or 'link to any package' (to register for dapper etc)
<Kamion> CarlFK: keyboard> it's simultaneously expected and a bug. :-)
<CarlFK> hi Kamion
<CarlFK> Kamion: I am doing an alternate install on vmplayer - the vm screen (What I see in the window) is ... flipping out...  any idea what I am talking about?
<Kamion> CarlFK: none
<CarlFK> hmm.  ever done any ubuntu install to vmware?  
<Kamion> all the time
<Kamion> using workstation more than player though
<CarlFK> Kamion:  near the beginning, when it does the video detection and says something about "frame buffer" you see the screen paint a few times.  right?
<Kamion> I can't say I've noticed - I sort of take it for granted that it's going to paint the screen more than is perhaps necessary
<CarlFK> Kamion: it is installing packages, but doing that screen paint thing
<CarlFK> for about an hour
<Kamion> what stage exactly? anna, base-installer, pkgsel ...?
<CarlFK> hmm, just did a screen shot - seems to be stuck in partman
<Burgundavia> CarlFK: could you get me a screenshot of the new uplash?
<CarlFK> I am using a preseed file I made from  debconf-get-selections --installer > file debconf-get-selections >> file
<alejandro> hi
<CarlFK> Burgundavia: sure.  oh yeah - that has issues too :)  (the text didn't display in the little window)
<alejandro> CarlFK: can you get working preseed in Ubuntu? 
<Burgundavia> CarlFK: a screenshot is great, as long as it can show the new upsplash theme
<Kamion> CarlFK: the output of debconf-get-selections --installer will always need tweaking per the documentation
<Kamion> I'll update installation-guide soon with recent changes in dgy
<Kamion> edgy
<Kamion> CarlFK: if it's stuck in partman, please send me /var/log/syslog and /var/log/partman
<CarlFK> alejandro: yes, I just need to tweeking it a bit
<Kamion> it's unlikely to be particularly vmware-speciffic
<CarlFK> :)
<Burgundavia> Kamion: is that debugging information useful if it hangs trying to get to the manual partion as well, outside of vmware?
<alejandro> CarlFK: ok, here it doesnt work, it gives a /dev/ram0 or /dev/rd0 error when ubuntu boots.
<Kamion> Burgundavia: yes
<Kamion> alejandro: are you changing the boot arguments?
<Kamion> I assume so; are you sure you started with the standard ones?
<CarlFK> Kamion: here is the screen shot - im having trouble getting to the F2-vt  http://dev.personnelware.com/carl/temp/Sep14/a/screen1.png
<Kamion> in particular, you didn't leave out the initrd by mistake, did you? :)
<alejandro> yes, the standard ones and I tried both using ram0 and rd0 with ramfs.
<Kamion> ramfs?!
<alejandro> Kamion: append vga=normal initrd=initrd-ubuntu ramdisk_size=14332 root=/dev/rd/0 devfs=mount,dall rw
<Kamion> alejandro: is that dapper or edgy?
<CarlFK> alejandro: here are my boot params: https://launchpad.net/bugs/60338 - make sure you have ramdisk_size=16098  (it changes now and then)
<Ubugtu> Malone bug 60338 in base-installer "alternate just started asking "Detect keyboard layout?"" [Untriaged,Unconfirmed]  
<Kamion> alejandro: standard for both dapper and edgy is root=/dev/ram, not root=/dev/rd/0
<Kamion> and lose the devfs=mount,dall
<alejandro> Ok, I tried a lot of options. (that is the latest one) :-)
<Kamion> I'd also try giving it a full path to the initrd
<Kamion> sounds like you're flailing around, I'm afraid :)
<Kamion> go back to the start and make the standard images work
<Kamion> then tweak one step at a time from that
<CarlFK> Kamion: I think the looping is caused by out of memory (VM has 96mb) - free shows 5mb free
<CarlFK> and trying to install scp resulted in "Killed"
<Burgundavia> mdz: is that email about Hoary EOL going out soon? (wow, is it really 2 years since Mataro...?)
<Keybuk> yes
<Keybuk> and yet, we can still taste the bags of death
<pitti> iwj: the problems is the gtkmozembed breakage
<Burgundavia> Red Red Love, baby
<iwj> pitti: Ah.  Is that worse in dapper ?  I thought breezy had it too.
<pitti> iwj: dapper is not our problem, dapper has 1.5 :)
<iwj> I mean, is it worse in our 1.5, which currently means in dapper.
<CarlFK> Kamion: I take that back.  the looping caused syslog to be 47mb
<pitti> iwj: ah, you mean the time when we have to upgrade dapper to 2.0?
<pitti> well, that's a future problem
<iwj> No.
<Kamion> CarlFK: right, that's what I would have said if you hadn't disappeared :)
<Kamion> CarlFK: 96MB is more than enough for an alternate install
<iwj> I mean: you say this gtkmozembed breakage is a problem with breezy 1.0 -> 1.5 but isn't the gtkmozembed breakage just the same in our 1.0 (ie current breezy) and our 1.5 (ie current dapper) ?
<pitti> iwj: I asked myself the same question; but ISTR that all firefox rdepends broke after installing 1.5 in breezy
<iwj> OIC, like that.  I thought you meant the pygtk crasher.
<Burgundavia> iwj: 1.5 is not abi compatibile with 1.0 and thus you need to recompile every gecko using app
<mdz> Burgundavia: I'm not aware of an email having been written yet
<iwj> Burgundavia: Right.
<mdz> Burgundavia: but one should be
<pitti> Burgundavia: no, that didn't help, I tried that
<iwj> pitti: That's strange.
<iwj> So why isn
<iwj> 't dapper broken ?
<pitti> iwj: I don't know, maybe because it has a newer yelp & co
<pitti> I really didn't look into it
<pitti> I gave up on that when this backporting mailing list and group were bor
<pitti> n
<iwj> Mmm.
<seb128> pitti: breezy GNOME apps should work fine with firefox 1.5
<seb128> after a rebuild I mean
<pitti> well, I guess I'll try it again
<pitti> iwj: do you still have the breezy 1.5 package you prepared some time ago?
<iwj> Not sure.  Let me look.
<Kamion> isn't pygtkmozembed still broken in dapper?
<Kamion> in a "really hard to fix, upstream need to meditate on it" kind of way
<pitti> Kamion: AFAIR the problem was with the C gtkmozembed, too, i. e. yelp and friends didn't work any more even after rebuild
<iwj> pitti: Yes, at least if we have firefox_1.5.dfsg+1.5.0.4.orig.tar.gz somewhere.
<pitti> iwj: hm, we should go straight to 1.5.0.6 anyway, I guess
<Mithrandir> Kamion: not bind-mounting all the squashfs-es into /casper, which means ubiquity has to work out which ones to mount by itself.
<Mithrandir> or something along those lines.
<Kamion> it's going to have to anyway, for stacked filesystems
<Kamion> and I already wrote that code a week or two ago
<Mithrandir> I think I'll start by chucking the bug in BenC's direction and see if he can come up with a fix/workaround first.
<iwj> pitti: http://www.chiark.greenend.org.uk/~ian/d/firefox/ is what I have.  The diff.gz is quite likely to apply without too many problems to 1.5.0.6.
<Kamion> it's preseedable and everything
<pitti> iwj: ah, thanks
<Kamion> Mithrandir: I think you should find that if you stop bind-mounting the filesystems then ubiquity will just cope
<Kamion> Mithrandir: IIRC the last time I checked the filesystems were (presumably accidentally) not properly bind-mounted anyway ...
<Mithrandir> Kamion: they _should_ be properly bind-mounted now.  I'll just bind-mount them if the user requests it with a command line option, then
<Kamion> yeah, that should be fine post-knot-3
<CarlFK> Kamion: the screen repaint (or whatever) is clearing VT shell - how can I kill the installer?
<Kamion> as I say, we pretty much need to move to that with stacked filesystems anyway; /rofs as "just base and desktop" doesn't make much sense in the DVD world
<Kamion> CarlFK: does ctrl-alt-shift-f2 get you to tty2?
<iwj> pitti: I can probably try to help as well if you get stuck, now that I know and can workaround what was making breezy not install for me.
<Mithrandir> Kamion: you won't have /rofs, you won't have anything but / which is unionfs then and you'll have to mount and copy yourself, in the right order.  But you probably need that anyway, so it should be fine
<pitti> iwj: I would appreciate if we could both work on it, especially since we need to update mozilla and tbird, too
<CarlFK> Kamion: well, Alt-f2 does, but as I am typing the screen keeps getting wiped out every few seconds
<Keybuk> so I still get the usplash test card ...
<Keybuk> what package includes the theme?
<iwj> pitti: It would be nice for me not to do only firefox this week :-) but how about I try the breezy firefox backport on Monday ?
<CarlFK> Kamion: Alt-f4 gets me to what I call the 'tail -f syslog' screen, Alt-f2 goes back to... working in the dark
<infinity> Keybuk: usplash-theme-ubuntu
<pitti> iwj: that sounds great
<pitti> iwj: I'll go to look at tbird first, if that's fine with you
<Kamion> CarlFK: 'killall debian-installer' might do it ...
<Keybuk> infinity: that's installed
<Kamion> CarlFK: but I think it's probably nothing to do with vmware screen repaint
<infinity> Keybuk: Of course, I have no idea if it works, since I disabled usplash the last time it upset me.
<Kamion> CarlFK: I think the installer is getting killed and then respawning on the current tty
<iwj> pitti: OK
<Kamion> CarlFK: so you need to edit it out of /etc/inittab (blind) and kill -HUP init or whatever it is
<CarlFK> Kamion: rignt - the screen repaint is just making it hard to work
<Kamion> CarlFK: it would be easier to give me a recipe for how I can reproduce this problem
<Kamion> and let me deal with it :-)
<Kamion> Keybuk: the alternative got stuck for me
<Kamion> Keybuk: update-alternatives --auto usplash-artwork.so fixed it
<CarlFK> Kamion: recipe comming up
<Kamion> I hadn't got round to tracking down who had been subtly misusing update-alternatives in one of the eighteen possible ways that can be done
<Kamion> CarlFK: ta
<Keybuk> Kamion: yes, it did for me too
<Keybuk> Kamion: everyone, simultaneously, usually
<Kamion> aye, and generally it's almost unfixable without making the problem worse
<Kamion> I really wish there were an official "here is how you use update-alternatives correctly from maintainer scripts" document
<Kamion> some years back, I went through all the maintainer scripts on my system and found no fewer than eight different convention
<Keybuk> A. Don't
<Keybuk> ? :p
<Kamion> s
<Kamion> I collected this together and filed it as a policy bug, saying "please tell us all which one to use"
<Keybuk> ok, so update the alternative AND update the initram
<Keybuk> fs
<Kamion> I'm not sure that's ever had a satisfactory response, possibly because nobody actually knows
<Keybuk> Kamion: btw, why is the console black and white
<Keybuk> is that you or garrett?
<infinity> Mine's not black and white.  I'd like to know why I got this godawful new console font by default, though.
<infinity> Spindly-looking piece of...
<Keybuk> infinity: I've had that font come and go
<Keybuk> right now, for instance, I don't have it
<Keybuk> but last time I booted, I did
<infinity> ...
<infinity> Special.
<Kamion> Keybuk: wasn't the console always black and white? :) or do you mean the svga thing?
<Kamion> Keybuk: I haven't touched the svga backend
<Keybuk> Kamion: I mean that all colour has gone from it
<Kamion> infinity: that's console-setup; I may change the default for Latin away from terminus
<infinity> I've been getting the new spindly font since I rebooted a few days back.
<Keybuk> if I type ls, it's in various shades of grey
<Kamion> some people like it, some don't
<Kamion> dpkg-reconfigure console-setup if you don't
<infinity> Kamion: Yeah, I'll change it back to something sane.  This one doesn't agree with me at all.
<Keybuk> Kamion: why do I only get it sometimes?
<Kamion> Keybuk: probably because setupcon isn't always managing to work at boot?
<pitti> infinity: how do you guys get the new console font? Mine didn't change for literally years
<Kamion> Keybuk: I bet if you run setupcon for a console post-boot, it'll chang
<Kamion> e
<Kamion> pitti: it's new with console-setup
<Keybuk> Kamion: yes, it does
<Kamion> which is, well, new. :)
<Keybuk> Kamion: want a bug?
<Kamion> Keybuk: if you could hack your init scripts to strace -f setupcon, that would be useful
<Kamion> I can't do a lot with a bare "doesn't work" bug, but I might be able to dig it out of a trace when it doesn't work
<Kamion> and I do want a bug in the latter case
<Burgundavia> Mithrandir: I am going to bed, up again in 5 or 6 hours to finish up the page. If you send out the announcement before then, link to the wiki page and I deal with it
<infinity> Ahh, good ol' "VGA", how I missed you.
<Mithrandir> Burgundavia: 'k, thanks.
<Keybuk> infinity: you're very odd ... you know that, right?
<Kamion> VGA and Fixed actually have better language coverage than Terminus, ironically
<pitti> Kamion: is there deliberately no amd64 in http://cdimage.ubuntu.com/daily-live/20060914/ ?
<thom> Keybuk: if you're only just realising that you're _very_ slow :-)
<Kamion> I get the impression that Anton just loves Terminus and set it as the default for the languages that could handle it (basically Latin and Cyrillic scripts)
<janimo> pitti: ok with me fixing a bug in foomatic-db which till pointed to in CVS? The one I found that crashed the fedora printing tool
<Kamion> pitti: that indicates a build failure, see the logs on http://people.ubuntu.com/~cjwatson/cd-build-logs/
<infinity> Keybuk: I'm aware that VGA isn't a very readable font, but I've been reading it since I first got an IBM PC in the mid-80's, so my brain parses it at lightning speed.
<janimo> pitti: is's search and replace 68/65 in a printer description xml file
<pitti> janimo: of course, go ahead :)
<Kamion> Terminus is explicitly intended to reduce eyestrain
<pitti> janimo: ah, I remember that
<pitti> janimo: however, please coordinate with Till, we might want a complete upstream update anyway
<janimo> pitti: till also pointed to another bug during that discussion re LJ1100 or similar bug which he said we should get in and if I touch the package I may upload that as well
<janimo> however I know nothing of that bug
<Kamion> oh, I see
<Kamion> pitti: will fix
<Kamion> after meeting
<janimo> pitti: a complete upstream would be better of course, I know nothing about their release sched and how if affects out FF though
<pitti> Kamion: ah, thanks
<Keybuk> Kamion: then why is it so light?
<Keybuk> terminus is definitely not as easy to read as VGA
<infinity> Keybuk: You may just be suffering from the same thing I am.
<infinity> Keybuk: Terminus *is* easier on the eyes, but it's also a pain to parse for someone who's been reading VGA for the last 20 years.
<Keybuk> I'm just referring to the fact that VGA appears white
<Keybuk> and that Terminus appears a kind of dark grey
<Keybuk> nowhere near as contrasty
<infinity> Eyes playing tricks on you because it's thinner?
<infinity> The boldness of VGA may make it seem whiter because you've got more bright pixels yelling at you.
<janimo> Kamion: fixed up python-cups according to to the policy and also uploaded system-config-printer to NEW
<Mithrandir> Riddell: new kubuntu images for you, btw, both desktop and alternate.
<Kamion> Keybuk: *shrug* dunno, I'm just quoting the stated purpose in the readme
<Kamion> ask Anton :)
<CarlFK> what text editor exists in the installer?  (so I can edit inittab)
<Riddell> Mithrandir: great, just what I need before breakfast
<Keybuk> you probably don't want to edit inittab
<Keybuk> given it's largely ignored
<Kamion> CarlFK: nano
<Keybuk> and probably doesn't even exist on fresh installs
<Kamion> Keybuk: in the *installer*
<Kamion> it still exists
<Kamion> ignore Keybuk :)
<Keybuk> Kamion: alternate?
<Kamion> we're not using upstart in the installer ;)
<Kamion> Keybuk: yes
<Keybuk> ah, I assumed LiveCD
<Keybuk> at which point, of course, you have an entire distro
<Keybuk> ignore me :p
<Kamion> CarlFK generally uses the alternate CD for preseeding work
<Kamion> know thy users ;)
<tkamppeter> janimo, pitti, a complete upstream update of foomatic-db to today's snapshot does not only fix the two Ubuntu bugs which you mentioned here, but it also adds entries for 20 Toshiba PostScript printers, around 5 new HP inkjets (supported by HPLIP 1.6.7), 5 Samsung GDI lasers (work with ESP GhostScript's "gdi" driver or with the new Splix driver, and AFAIR there was also a Ubuntu bug report of missing Samsung printer entries).
<pitti> tkamppeter: sounds like a good excuse for an UVF exception
<Kamion> Mithrandir: I've repaired amd64 live CD builds; you may want to rebuild any you care about
<pitti> tkamppeter: can you please mail mdz with a complete changelog for approval?
<tkamppeter> So we fix 3 Ubuntu bug reports and add many new printers.
<Mithrandir> Kamion: as of when?
<Keybuk> Kamion: bug #60347  (with strace)
<Ubugtu> Malone bug 60347 in joybot "Joybot has no way of specifying whether an attack is energy or physical" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/60347
<Keybuk> no, not that bug
<janimo> tkamppeter, pitti, good idea, as I just noticed the package has no patch system to easily add small upstream fixes only
<Keybuk> bug #60357
<Ubugtu> Malone bug 60357 in console-setup "Does not set the nasty new font" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/60357
<Keybuk> :p
<tkamppeter> pitti, here is the complete ChangeLog, look at everything newer than the date in the original tarball name of the current foomatic-db. http://www.linuxprinting.org/foomatic-db/ChangeLog
<Kamion> Mithrandir: about two minutes ago
<Kamion> Mithrandir: it wasn't handling the amd64-generic -> generic kernel rename
<pitti> tkamppeter: mdz needs to approve, not I; can you please mail him with the URL? (mdz@ubuntu.com)
<Mithrandir> Kamion: oh, just the live _cd_, not livefs?
<Kamion> Keybuk: strace *-f*
<Kamion> Mithrandir: yeah
<janimo> tkamppeter: are there releases of foomatic-db upstream? I see debian is a few snapshots ahead of us
<Mithrandir> Kamion: ok, thanks, running now.
<Kamion> Keybuk: I need at least the consolechars subprocess
<Kamion> Keybuk: actually -s 1024 wouldn't hurt either
<janimo> but I dont' know if they are taken at arbitrary point in time or according to upstream releases
<Mithrandir> Riddell: you might want to hold off your desktop cd downloads for a little bit, then
<Keybuk> Kamion: oops, sorry
<tkamppeter> There are not really releases of the Foomatic database. From the database every night a snapshot is taken.
<mdz> tkamppeter: have you already talked with doko about updating hplip?
<mdz> tkamppeter: I also suggested that he talk with you about the status of printing in oo.o and make sure that it is in good shape
<MrFaber> hi all
<MrFaber> Does anyone know the reason why dynamic scaling doesn't react on kernel load? It only reacts on app load. Both ondemand and powernowd seems to don't recognize kernel load. If you use loop encryption or emulators with modules the cpu runs always with the lowes frequenzy until some app uses much.
<Keybuk> Kamion: appears to be usplash related
<Keybuk> ie. setupcon doesn't work if usplash is running
<Keybuk> and the second one (run by usplash) doesn't work because X is running
<jamadagni> hello my friends
<tkamppeter> pitti, mdz, exception request for foomatic-db sent -> biff
<tkamppeter> doko, are you here?
<doko> pitti, tkamppeter: what do you think about an hplip update?
<doko> tkamppeter: a few more minutes, then going offline for an hour
<tkamppeter> doko, I think it is very important, was there not already the apptopriate UVF ER?
<doko> tkamppeter: I don't think so.
<doko> (the exception)
<tkamppeter> HPLIP needs to be updated as a lot is done to improve fax, also the newest models added by the UVF ER for foomatic-db are supported then
<tkamppeter> In the UVF ER for HPLIP we also need to request the update of foomatic-db-hpijs so that CUPS auto-generates the appropriate new PPDs.
<tkamppeter> doko, what is your mail address?
<doko> same as the nick
<tkamppeter> doko, pitti, mdz: bug 51573
<Ubugtu> Malone bug 51573 in dapper-backports "Please update HPLIP to 1.6.7" [Untriaged,Needs info]  http://launchpad.net/bugs/51573
<pitti> re
<CarlFK> Kamion: this tell you anything usefull? http://dev.personnelware.com/carl/temp/Sep14/a/screen2.png
<Kamion> Keybuk: do you have an updated strace? I may be able to fix consolechars
<Kamion> CarlFK: no, it's just out of memory and doing random crap
<Kamion> (most likely)
<CarlFK> Kamion: I think this may be causing it: anna-install openssh-client-udeb  
<CarlFK> whatever it is ..
<CarlFK> that is from my "early_command.sh" which keeps getting downloaded and run
<Kamion> that should be harmless
<Kamion> have you sent me the recipe?
<tkamppeter> mdz, doko, pitti: Now the UVF ER for HPLIP 1.6.7 + foomatic-db-hpijs (current snapshot) is out --> biff
<CarlFK> still trying to figure out what parts are needed 
<Keybuk> Kamion: yes, just fiddling atm, sorry
<pitti> tkamppeter: thanks
<jamadagni> i need to ask a q here about local/remote repos
<jamadagni> didn't get from ubuntu-motu
<pitti> jamadagni: better just ask instead of asking to ask
<jamadagni> pitti sorry
<jamadagni> just didn't want to go ot without permission
<pitti> jamadagni: don't worry, if it's off topic, someone will lart you with or without permission :)
<jamadagni> "lart"?
<pitti> jamadagni: (just kidding, just go ahead)
<jamadagni>  i have a local repo with tidy and libtidy. these are also present on the remote repos. same version in both places.
<jamadagni> the local repo is configured before the remote repo in sources.list
<Keybuk> Kamion: ok, strace attached
<jamadagni> but apt-get goes and gets the remote file when i do apt-get install tidy
<jamadagni> i remove the remote repo from the list then i try to install, then it takes the local file
<jamadagni> why?
<Kamion> make sure the local repository is first in the list; apt breaks ties by sources.list order
<pitti> jamadagni: that's an mvo question, but I assumed that earlier repos were considered first, too
<CarlFK> Kamion: https://launchpad.net/distros/ubuntu/+bug/60362
<Ubugtu> Malone bug 60362 in Ubuntu "preseed partman loop " [Untriaged,Unconfirmed]  
<Kamion> oh, you already said that
<jamadagni> mvo?
<Kamion> CarlFK: ok, I'll get to that this morning
<CarlFK> let me know if you need more pxe setup info 
<pitti> jamadagni: you are sure that you apt-get update'd and everything?
<jamadagni> ya
<mvo> jamadagni: is your local repo signed? or a file:// uri?
<pitti> jamadagni: apt-cache policy tidy looks good?
<pitti> (I have the same configuration in my chroots - local file:// mirror, then http://archive, and it Just Works (tm) )
<Kamion> CarlFK: could you attach the preseed file please? (feel free to strip passwords or whatever)
<jamadagni> i get installed none; candidate 20051018-1 and version table
<CarlFK> just attached
<jamadagni> i removed tidy after testing lastt time
<jamadagni> mvo: local repo is *not* signed
<jamadagni> it's a file:///home/username uri
<Kamion> meh, I'm not sure I want to support preseeding by starting from debconf-get-selections --installer
<Kamion> there's such an enormous amount of crap in there
<jamadagni> i suspected as much that apt-get might prefer a signed over unsigned repo
<jamadagni> is that why
<Kamion> I should make debconf-get-selections sort by question name, for a marginal increase in clarity
<mvo> jamadagni: what is the output of apt-cache policy tidy? that should give a clue
<Kamion> oh, that turns out to be hard, sigh
<CarlFK> Kamion: is there a kernel param I can pass to satisfy the keyboard questions?
<Kamion> CarlFK: I don't know yet
<Kamion> console-setup is new and I haven't looked at its preseedability yet
* pitti clears and updates Testing/Current
<CarlFK> ok.  It is only 3 keystorks... but I think I have done it about 20 times in the last few hours :)
<Kamion> d-i     partman-auto/disk       string  /dev/discs/disc0/disc
<Kamion> hmm, that shouldn't be using /dev/discs any more
<Kamion> was that something you did manually?
<CarlFK> nope - didn't touch foo.cfg
<Kamion> CarlFK: and definitely current edgy?
<jamadagni> mvo: while i wait for paste.ubuntu.nl to load, i repeat that the local repo is not signed
<Kamion> because /dev/discs isn't there any more
<jamadagni> mvo: could that be the reason?
<Kamion> CarlFK: I mean, did you generate the preseed file from a current edgy install? not knot 2, absolutely current
<CarlFK> Kamion: ouch.  i 'thinik' so, but now I am starting to wonder 
<Kamion> that would be my guess as to the problem
<mvo> jamadagni: it could, but if the local version is newer than the archive version thatn it should still use the local one. if they are the same version, than apt will fetch the signed one (always)
<Kamion> I'll feed the preseed file to my system anyway and see what happens; undoubtedly we can do something better than looping
<Kamion> although your preseed file probably isn't helping by preseeding absolutely everything under the sun
<CarlFK> Kamion: that was just an attempt to figure out the keyboard parameters :)
<Kamion> the installation guide does say:
<Kamion> However, a file generated in this manner will have some items that should
<Kamion> not be preseeded, and the example file is a better starting place for most
<Kamion> users.
<Kamion> CarlFK: consider console-setup preseeding broken until I've had a chance to look into it
<jamadagni> mvo: if so, should it be added to the apt-get documentation?
<mvo> jamadagni: that sounds reasonable
<jamadagni> mvo: cause i tried searching man:apt-get for the word "sign" but nicht results
<CarlFK> Kamion: ok. I'll go to bed now :)
<mvo> jamadagni: try man apt-secure
<Kamion> CarlFK: I do plan to sort it out this week
<jamadagni> mvo: ok i'll try signing my repo.
<jamadagni> mvo: is it enough to create a dummy release file and sign it using gpg and create a public.key fgile?
<mvo> jamadagni: make sure to add your key to apts keyring with apt-key add 
<jamadagni> mvo: oh so it's not enough if my own gpg trusts it
<mvo> jamadagni: oh, use apt-key list to see what apt trusts
<jono> am I going nuts, or is it normal for my windows not to wobble or spin around by default in edgy?
<jamadagni> mvo: my key is placed last
<jamadagni> mvo: after i did apt-key add
<mvo> jamadagni: that is expected
<jamadagni> mvo: i did another apt-get update after adding the key and *still* apt-get goes to the remote repo
<jamadagni> i mean apt-get install
<Keybuk> jono: normal
<Keybuk> you can install compiz if you want them to
<jono> Keybuk,  it is planned to have my windows wobble by default if 3D accelleration is available? I have been reading the thread about compiz on ubuntu-devel but don't know enough about the area really
* zyg1 waves to mvo
<Keybuk> jono: I don't know ... I hope not :p
<jono> Keybuk, bah, your no fun :P
<jamadagni> mvo: have i tired you?
<jamadagni> mvo: i do ask a lot of q-s
<tseng> is there no longer a desktop smp kernel?
<tseng> the default -386 only sees one cpu
<jamadagni> tseng, why don't you install 686-smp
<tseng> maybe -686 has the detection algo?
<mvo> jamadagni: I do other stuff beside irc, that is why I may have some lack when answering
<jamadagni> there are no 386 smp systems in the world, rae there?
<jamadagni> mvo: i was not ocmplaining
<jamadagni> mvo: i was just hoping i didn't bug you too much, sincerely
<tseng> i believe there are some 586's
<tseng> but i dont see a 686-smp in edgy
<jamadagni> tseng-  ok maybe but you get only a 386 and 686 kernel with ubuntu
<ajmitch> tseng: names have changed
<tseng> jamadagni: this is tangential, btw
<jamadagni> http://packages.ubuntu.com/edgy/base/linux-686-smp
<jamadagni> tseng - of course (tangential = ~ot, right?)
<ajmitch> tseng: go for -generic
<tseng> ajmitch: right on
<CarlFK> what would a pPro use?  (i have a quad pPro-200 I may use for it's raid)
<Kamion> -generic
<tseng> thanks ajmitch
<fabbione> Keybuk: ping?
<carlos> pitti, seb128, dholbach: Hi, would be possible to fix gnome-desktop's documentation to generate the .pot file on build time? I only get .po files for it
<Keybuk> fabbione: heyhey
<seb128> carlos: do we do something with the documentation?
<fabbione> Keybuk: ok. i am in initramfs now wirh root on raid and root=someUUID
<fabbione> Keybuk i can see that mdadm did start the raid correctly
<carlos> seb128: there are many packages already fixed
<seb128> carlos: I'm not really happy to have things listed to rosetta for which ones we don't use what people do
<carlos> seb128: when upstream uses .po files to translate it, we import them
<seb128> carlos: yeah, and I think that's just misleading
<fabbione> Keybuk how can i kick udev the canonical way to crete the uuid symlink?
<fabbione> Keybuk because that clearly seems not to be there
<seb128> carlos: because people spend time to translate that on rosetta and we don't use their translation
<carlos> seb128: well, I guess it's just a matter of improve our system to ship them
<seb128> right
<seb128> but I think we should list them until we ship them
<seb128> shouldn't list
<Keybuk> fabbione: echo -n add > /sys/.../uevent
<seb128> because people are wasting efforts on that
<Kamion> Keybuk: hmm, consolechars seems to be managing to set the font - I'm wondering if usplash is setting it back when it restores the console
<fabbione> Keybuk is that a path to what?
<Keybuk> fabbione: whenever you want to kick udev about
<fabbione> Keybuk ok.. let me try
<Keybuk> the block device, in this case
<Kamion> [pid  4833]  write(2, "Loading 256-chars 8x16 font from file `/usr/share/consolefonts/Lat15-Terminus16.psf.gz\'.\n", 89) = 89
<Kamion> [pid  4833]  ioctl(3, KDFONTOP, 0xbfb4db2c) = 0
<carlos> seb128: well, we should fix it anyway, that's something to fix, I agree, and as in the mean time, the priority should 'hide' them over the ones we already use
<Kamion> Keybuk: when this happens to you, are the fonts on all the ttys the same, or is it just tty1 that's using the VGA font?
<fabbione> Keybuk: ok one step forward.. i was able to add md0 that was also root by coincidence, but not md1
<fabbione> Keybuk: anyway we already have some data
<Keybuk> Kamion: all
<fabbione> let me login from the other box
<Kamion> Keybuk: and it was definitely like that (with all ttys having failed to change font) after the strace you supplied?
<Keybuk> Kamion: yes
<Kamion> freaky
<pitti> hey lloydinho 
<lloydinho> hi pitti! 
<Mithrandir> hmm, example-content seems to be missing from the livefs?
<Tonio_> hi
<fabbione> Keybuk: ok.. figured all out.. it's enough to kick udev before mounting root (of course)
<Kamion> Mithrandir: it's a recommends - I have a bad feeling ...
<fabbione> Keybuk: nevermind the md1 thingy.. it was my bad setup. it's all good.
<Kamion> I bet the livefs build process isn't following recommends by default
<Kamion> infinity: ping
<Mithrandir> Kamion: so the livefs is built without recommends.  :-(
<fabbione> Keybuk: now.. how do we want to kick udev in the right way and from what package?
<Kamion> and it can't follow recommends globally, it'll get too big
<Mithrandir> Kamion: he's not around now.
<Keybuk> fabbione: the interesting point here is why do we need to kick udev
<Keybuk> but let's not worry about that for now
<Kamion> aaaaaaaaand the Task headers in the archive aren't including recommends properly rigt now
<Kamion> right
<Keybuk> does the kick need to happen after mdrun?
<Kamion> so, uh
<fabbione> Keybuk: i hounestly have no idea.. echo -n add /... did work and created the proper by-uuid symlink
<Keybuk> fabbione: was it a /sys/block thing you did?
<fabbione> Keybuk: yes.. after mdrun
<Keybuk> try adding udevtrigger -b && udevsettle to the mdrun script afterwards
<fabbione> and the path for me was /sys/block/md*/uevent basically
<Keybuk> (kick all block devices and wait for udev to process them)
<madduck> argh. mdrun.
<fabbione> oh
<fabbione> feh ok i can do it...
* fabbione sighs at another reboot
<Mithrandir> Kamion: so, what's a useful workaround for that?
<Kamion> Mithrandir: right now, I can't think of anything not involving infinity
<Kamion> mvo: any ideas?
<Mithrandir> Kamion: make the recommends hard depends, build livefs-es, make them recommends again?
<Mithrandir> (no, not nice)
<janimo> pitti: when you're in review mode again please remember gxine ;)
* fabbione goes for another reboot
<Kamion> Mithrandir: we could fix the Task fields on drescher, get sysadmin to frob the livefs script to use tasks rather than metapackages, build livefses, let infinity clean up later
<Mithrandir> Kamion: hmm, is frobbing the livefs script trivial?
<Mithrandir> it uses apt-get, not aptitude, doesn't it?
<slomo> janimo: you want gxine for xubuntu as movie player? do you already have something as music player? :)
<fabbione> Keybuk: that did work just fine.. 
<fabbione> Keybuk: do you need more data/info?
<Keybuk> fabbione: ok, it's a good patch for now ... we'll investigate _why_ we need that another time
<Kamion> Mithrandir: switching it to aptitude install ~t wouldn't actually be hard, I don't think
<Keybuk> feel free to upload fixed mdrun after knot 3 freeze
<janimo> slomo: no music player for now
<Mithrandir> Kamion: I'm just worried about what else'll break if we do that, but yeah, it's probably the best way to do it.
<janimo> and yes I want gxine to replace xfmedia
<fabbione> Keybuk: ok. works for me. i have the setup, it's just annoying to access it.
<fabbione> brb
<janimo> not just me, most people agreed on this
<slomo> janimo: i guess that's a fairly good choice ;) do you already have any candidates that could be used as music player?
<Kamion> Mithrandir: I'm thinking hard about the dapper germinate backport now
<janimo> slomo: no candidate which does not dep on some form of mp3 lib
<janimo> do you have decent proposals?
<Mithrandir> Kamion: stop the publisher?
<Kamion> Mithrandir: not needed?
<Mithrandir> (since I suspect you'll need to republish to regenerate the Packages file)
<slomo> janimo: hum... anything that uses gstreamer (quodlibet or bmpx should've no gnome dependencies), anything that uses xine (i only know about amarok and you definitely don't want kde dependencies but there are probably more than this)
<pitti> argh, it seems this bug returns in every release - snd-powermac is not in /etc/modules
<Kamion> pitti: deliberate this time
<pitti> Kamion: what is the correct source package for filing something about /etc/modules?
<Kamion> pitti: snd-powermac crashes some G5s apparently
<pitti> oh
<Kamion> pitti: hw-detect, but I'm sorry, I don't think I'm going to revert this on
<Kamion> e
<Kamion> unless I can find some better way to detect the machines that it crashes
<pitti> oh, too bad; that's something for the release notes then?
<Kamion> probably, yeah
<Kamion> 2.6.18 will fix it properly
<Kamion> (AIUI)
<pitti> ok, thanks, then I won't bother filing a bug
<Kamion> feel free to file a bug by way of documentation
<Kamion> I have plenty ;)
<janimo> slomo: sine we alreday have xine we won't put gstreamer as well. And there seem to be no simple xine based players
<pitti> Kamion: ok :)
<slomo> janimo: ok, no idea then :(
<pitti> seb128: not sure whether it's fschoep's bug our gtk's: the current desktop background's note about 'artwork preview' is partially hidden by the bottom panel
<seb128> pitti: the background fits the screen, the panel is on top of it, and panel didn't change ... I would say that's artwork bog :)
<fabbione> Mithrandir: permission to upload mdadm. one line change to fix / on raid. it's NOT a knot-3 blocker. it would be nice to have but it's not a mandatory thingy
<seb128> pitti: the text should be placed uper
<madduck> fabbione: what's the one line change?
<pitti> seb128: the background stretches over the whole screen, it does not end at the upper panel edge
<seb128> pitti: correct
<pitti> seb128: if I move the panel elsewhere, I see the full text
<seb128> pitti: you can have a transparent panel you know? ;)
<pitti> seb128: ok, so backgrounds have to be designed with that in mind?
<seb128> pitti: correct
<fabbione> madduck: +udevtrigger -b && udevsettle at the bottom of initramfs local-top script
<pitti> seb128: yes, I just want to understand it fully
<pitti> seb128: thanks for the confirmation
<seb128> pitti: background takes the full screen
<Mithrandir> fabbione: you can upload, but I won't have it accepted until after knot is out; we need to stabilise now.
<fabbione> madduck: it's required to fix root on raid when we moung by-uuid
<Mithrandir> fabbione: sorry. :-/
<seb128> pitti: panel is just an object you move on screen like a window
<seb128> pitti: np
<pitti> seb128: ok, I'll file an u-artwork bug then
<fabbione> Mithrandir: sure.. no problem... as i said it's not a blocker.. if it can make it good.. otherwise it's still good
<seb128> ok
<dholbach> pitti: edgy-wallpapers
<pitti> dholbach: ah, thanks
<Kamion> Mithrandir: I've uploaded the germinate backport and RTed it
<Mithrandir> Kamion: thanks.
<Kamion> then it needs two cron.daily runs
<Mithrandir> they'll grab it out of the unapproved queue or something?
<Kamion> Mithrandir: I stuck in on chinstrap for them. It's installed on drescher now
<Kamion> s/in/it/
<madduck> fabbione: ah, so it's ubuntu-only. thanks.
<stub> Launchpad is going down in 15 minutes for hardware maintenance on our database server. Estimated down time is 15 minutes.
<Kamion> stub: argh; is it critical now?
<stub> Dud ram. We have no way of knowing when it screw up badly enough to crash or corrupt.
<Kamion> oof
<Kamion> stub: can you make sure cron.daily has finished on drescher before shutting down, at least?
<Kamion> I'd like not to incur more one-hour penalties than we have to
<stub> Already done that - I disabled it before this hours run
<Mithrandir> Kamion: can you byhand the publisher for the next two runs then so we have the runs back-to-back
<Kamion> oh, I was hoping we might have got an extra run out of it
<Kamion> Mithrandir: certainly
<Kamion> stub: please let me know when it's back up and I'll drive the publisher
<stub> Kamion: ok
<pitti> Kamion: just to confirm that this is right: In an OEM install, I get a 'which software should be installed? [ ]  Ubuntu desktop' question, I don't get it on a standard alternate install
<Kamion> pitti: whoops! fixed, thanks
<Kamion> was a cdimage bug
<pitti> Kamion: this question might be quite nice in an expert install :)
<pitti> Kamion: i. e. does the standard install now have it as well, or the oem install doesn't have it any more?
<Kamion> pitti: I agree, haven't quite figured out how to get expert to un-preseed it there
<Kamion> pitti: the oem install no longer has it
<pitti> ah, ok
<Kamion> pitti: please file a bug about it not appearing in expert mode, on /products/ubuntu-cdimage
<pitti> I didn't test expert yet, but sure, I'll file a bug since you are sure about it
<Kamion> yeah, it's preseeded and therefore marked as seen
<pitti> whoops, LP is down for maintenance
<Kamion> sorry, I assumed you'd seen it from your comment
<pitti> Kamion: it was off by default, btw (I assume that the preseeding enables it instead of just marking as 'seen')
<Kamion> s/instead of/as well as/
<Kamion> yeah, not quite sure what to do about the default - reconciling handling of CDs and netboot is difficult
<pitti> ah
<Kamion> tasksel's pretty flexible though, so I probably just need to sit down and have a long talk with it
<Kamion> mvo: so your plan is to have apt install recommends by default for metapackages but not for everything else, right?
<mvo> Kamion: yes
<mvo> Kamion: at least for edgy, we can switch on recommends-by-default for edgy+1 (but then we should do it very early)
<Kamion> mvo: we're going to need a partial backport of that for the livefs build script
<Kamion> mvo: can you discuss that with infinity when he's around?
<Kamion> Mithrandir: ok, publisher running
<elmo> what's the kernel pseudo package in LP for bugs?
<mvo> Keybuk: I would like to request a new apt/python-apt for dapper-backports. is it easier if I do that upload myself? or do you have some soyuz magic that makes it easy/straightforward?
* pitti installs ppc/oem and finds yaboot broken; hmm
<Keybuk> mvo: we have some amount of magic
<Keybuk> though backports is completely hosed
<Keybuk> I really wouldn't try and backport apt at this point :p
<pitti> \o/ usplash on ppc - /me hugs Kamion
<mvo> Keybuk: hm .. just hosed for soyuz magic? or hosed in general? do you have any (rough)  idea if/when things get better there?
<Keybuk> hosed in soyuz
<Keybuk> you'd only get one version, on one architecture
<mvo> Keybuk: I was wondering if I could use it to get a apt-that^Wwith-breaks for the dist-upgrader, but things look not very bright there it seems :/
<pitti> hm, today's ppc live CD shows usplash, then a black screen with two (normal) kernel messages, and now it just sits around without any progress
<pitti> Keybuk: can I enable boot logging as a boot option?
<Keybuk> pitti: not yet
<pitti> hmm; any idea how I can find out what's going on?
<Keybuk> probably just fsck
<pitti> Keybuk: how? it's the live CD
<pitti> erm, I meant s/logging/message displaing/
<Keybuk> you can't
<pitti> ok
<pitti> slomo: AYT?
<MrFaber> Does anyone know the reason why dynamic scaling doesn't react on kernel load? It only reacts on app load. Both ondemand and powernowd seems to don't recognize kernel load. If you use loop encryption or emulators with modules the cpu runs always with the lowest frequency until some apps instead of modules uses much.
<pitti> Kamion: FYI, the live CD enables snd-powermac
<Kamion> pitti: yeah, casper appears to
<Kamion> pitti: maybe it's best to leave that on, so that users have an option either way
<pitti> Kamion: shall I file a bug about removing it as well there?
<Kamion> dunno
<Kamion> *shrug* I don't want to knee-jerk, should check over the details with Ben
<pitti> Kamion: ok; maybe we can put some grep /proc/cpuinfo into the casper script
<Kamion> it's not that simple, I don't think
<Kamion> usually when people say "G5" they actually mean "certain chipsets that happened to generally ship with G5s"
<Kamion> it's almost certainly not the processor
<pitti> ah, it depends on the sound chip, not on the processor perculiarities?
<Kamion> I believe so, yes
<pitti> ah
<Kamion> unfortunately (last time I investigated this) they didn't seem to be all that well-distinguished in /proc/devices
<Kamion> er, /proc/device-tree
<Kamion> BenC: are you aware of a snd-powermac crash on some G5 systems?
<BenC> Kamion: no, is it snd-powermac, or snd-aoa?
<Kamion> snd-powermac - see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380082
<Ubugtu> Debian bug 380082 in hw-detect "shouldn't always use snd-powermac" [Unknown,Closed]  
<Riddell> Kamion: I'm afraid it looks like kubuntu needs another ubiquity fix
<Kamion> I think further details are on debian-boot
<Kamion> Riddell: urgh. details?
<Riddell> Kamion: http://muse.19inch.net/~jr/tmp/kde-ui.py enables Install button on automatic partitioning
<Riddell> Kamion: the previous fix only enabled them on manual partitioning
<BenC> Kamion: Well, for edgy, we don't have snd-powermac anymore, it's snd-aoa, so edgy is ok
<Kamion> +       print "MMMMMMMMMMM disabling"
<Kamion> quality ;)
<BenC> Kamion: I've not heard of G5 crashing with snd-powermac
<Riddell> Kamion: doh, you can remove those lines
<Kamion> BenC: oh, really?
<Kamion> I didn't realise we'd backported that
<Kamion> pitti: are you sure sound doesn't work anyway, then? :)
<Kamion> I thought snd-aoa was supposed to be properly modaliased
<Riddell> Kamion: also it looks like the 20060914.1 daily-live kubuntu cd images don't have the Recommends packages on them
<BenC> yeah, I specifically wanted to get snd-aoa in there because of the hotplug capability of it
<Kamion> I have all of snd-powermac, snd_aoa_i2sbus, and snd_aoa_soundbus loaded here
<Kamion> Riddell: see the extensive discussion between me and Mithrandir above about that problem
<pitti> Kamion, BenC: no idea, I just know that the live CD loads snd-powermac (which *does* exist) and the alternate doesn't, thus I have no sound there
<Kamion> we've been working on fixing it for the last couple of hours
<Riddell> Kamion: ok
<pitti> Kamion: yeah, I specifically tested sound in alternate install, I need a modprobe snd-powermac to get it working
<pitti> I didn't try snd-aoa, though, I'll do that in my next test install
<z\> hello
<mvo> Kamion: I looked at the popcon stuff and the HOSTID is indeed crucial. what do you think about me upload a new popularity-contest package that just reconfigure itself wen upgraded from a earlier version (what mdz suggested in the meeting)?
<mvo> we would love some of the current data though for a short period of time
<Kamion> we'd still have to know how to throw away the older data
<Kamion> is it possible to find out which hostids are most commonly submitted, and just reconfigure if the hostid is one of those?
<Kamion> maybe check whether it matches e.g. the dapper desktop CDs
<mvo> its seems to be not easy to figure that out, it looks like it just overwrites a file (file==HOSTID) on each submit 
<mvo> and no history is kept
<Kamion> apache logs?
<mvo> thworing a away the old data would be a delete on the hashes dir on the server
<mvo> good point!
<Kamion> Keybuk: usplash is trying to open /dev/console just before quitting and failing because its filesystem namespace is that of the initramfs, which went away
<Kamion> Keybuk: what's the right way to deal with that?
<Kamion> Keybuk: hold an fd to /dev/console open while usplash is running? copy /dev/console to /dev/.initramfs/console? something else?
<Kamion> I'll try the former and see what happens
<Mithrandir> Kamion: both publisher runs done now?
<Kamion> Mithrandir: nearly, but need one more for ubiquity binaries for Riddell
<Mithrandir> Kamion: 'k, but I won't hold {ed,}ubuntu for that. :-)
<Kamion> nod - I'll let you know
<Kamion> Keybuk: oh, and same for /dev/tty* - no wonder it needs help from the init script to switch back to tty1
<Keybuk> Kamion: ah, that makes sense
<Keybuk> yes, hold it open
<Keybuk> heh, this explains various bugs ;)
<simira> mvo: u-m seems good to me now
<jdong|laptop> whoa, look at all those new kernel commits in the git tree :)
<Nafallo> Morning! ARE WE THERE YET? :-)
<mvo> thanks simira :)
<pitti> Kamion: yay for the expert installer asking me for an AltGr replacement key!
<Mithrandir> pitti: "you asked for it".
<pitti> Mithrandir: that was meant as a praise, not as a complaint
<Mithrandir> pitti: yeah, I understood that.
* Mithrandir starts building livefs-es and new ISOs.
<pitti> Mithrandir: new alternates, too?
* pitti didn't yet start testing the live ones, just thoroughly tested the alternate so far
<Mithrandir> pitti: do you get example-content installed correctly from alternate?
<pitti> Mithrandir: I couldn't check in my latest install (oem) due to bug 60409
<Ubugtu> Malone bug 60409 in oem-config "eternal hang after selecting keyboard" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/60409
<Kamion> pitti: some bits of console-setup certainly qualify as expert. :)
<pitti> Mithrandir: I'll look for that in the next install (this expert one)
<pitti> Kamion: heh, I just noticed it asking me about fonts, font sizes, encodings, etc. :)
<mvo> Mithrandir: whats in the test-matrix that needs more testing? I can surely help
<mvo> my head hurts anyway and my nose is runing like crazy. prefect testing conditions
<pitti> BenC: btw, snd-aoa is not automatically loaded on my iBook G4, and manually loading it doesn't make my card work; I really need to modprobe snd-powermac
<Mithrandir> pitti: thanks.
<Mithrandir> mvo: http://wiki.ubuntu.com/Testing/Current
<BenC> pitti: modprobe i2c-powermac
<pitti> BenC: btw, I *did* get some aoa-related modules autoloaded (_busconfig or so?), but not snd-aoa itself; probably because it doesn't drive my audio chipset
<pitti> BenC: I'll try the modprobe after this currently progressing installer run
<BenC> pitti: no, it does, but it needs the i2c controller to detect everything and load the rest of the modules
<pitti> ah, maybe
<Kamion> BenC: can that be automatically loaded or do I have to hardcode it?
<Mithrandir> BenC: do you have any idea about the cause of bug #60071?
<Ubugtu> Malone bug 60071 in launchpad-integration "Gets confused when using --translate --pid $pid on the live cd" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/60071
<BenC> Kamion: for edgy hardcode, but edgy+1 and beyond will have all the neat ppc/sparc openprom autoloading magic
<mvo> Mithrandir: thanks, I do edgy/atlernate/i386 now
<Mithrandir> mvo: thanks.
<Kamion> BenC: so just look for any device-tree node with name=="i2c", or something more specific?
<maswan> Mithrandir: are we going to need an extra mirror run soon? :)
<BenC> Mithrandir: not sure about that one, sounds like a limitation of squashfs or something
<Mithrandir> BenC: note that / is an unionfs mount of everything in /casper/*
<Mithrandir> maswan: we'll see.. things didn't go according to plans this morning so it might be tomorrow
<maswan> Mithrandir: 'k
<BenC> Kamion: device-tree device modules will get automatically loaded
<BenC> Mithrandir: ah, there's the reason then
<BenC> hmm, well, unionfs or bind?
<Kamion> pitti: find /proc/device-tree -name i2c\*
<Mithrandir> BenC: / is an unionfs mount, /casper/* is really bind-mounted from /casper/* in the initramfs.
<BenC> Kamion: you mean for edgy? I think the find and/or "grep -qi mac /proc/device-tree/compatible" would make it specific enough
<Kamion> BenC: pitti has /proc/device-tree/pci@f2000000/mac-io@17/i2c@18000 with name=="i2c" - is that meant to be autoloaded as i2c-powermac now, or do you mean that'll happen for edgy+1?
<Mithrandir> BenC: so, is there any way to tell the kernel that it shouldn't look in /casper for stuff?
<Mithrandir> Kamion: the fix doesn't seem to have made any difference.
<Mithrandir> Kamion: recommends still aren't installed
<Kamion> Mithrandir: haven't changed the livefs build script yet
<Kamion> I'm sorry, I got horribly distracted by an arsey letting agent
<BenC> Kamion: edgy+1 i will be autoloaded
<Mithrandir> Kamion: ok, could you do that now, then?
<Kamion> yeah, just trying to test it
<BenC> Mithrandir: I don't think so
<Mithrandir> BenC: so the fix is just to not bind-mount the separate squashfs-es, then.
<BenC> Mithrandir: very likely, yes
<Mithrandir> Kamion: isn't the easiest way to test it to just change it and do a livefs build? :-)
<mvo_> hmm, after doing a server install (in german) I end up with a english keylayout
<Kagou> i'v installed daily desktop twice. found 3/4 problems
<tepsipakki> backspace doesn't work here on console
<Kagou> 1/ iso burn failed at the end twice (cdr and cdrw) but cd seems ok and installation have not failed
<Kagou> 2/ ubiquity have problem displaying partition from gparted. (have to click on a partition to make it appeared)
<Kagou> 3/ i'v selectioned french at the boot, but when ubiquity ask for keyboard and time, before, french and Paris was already selectioned. Just have to click next
<Kamion> Mithrandir: I guess ...
<Kagou> 4/ bug displaying fonts in firefox/yelp.. but iwj already have the patch for fontconfig in is hands
<Mithrandir> Kagou: it's not helpful to tell us about your bugs here.  Make sure they're filed in malone and if you think they're knot blockers, tell me.
<Kagou> 5/ usplash are not efficient but for this i need to talk to the mainteneur
<Kagou> ok Mithrandir 
<Kamion> Mithrandir: could you review chinstrap:~cjwatson/livecd.sh.diff please?
<Kamion> 3 is not a bug
<Kagou> Kamion: 3 is a regression ?!
<Kamion> no it's not
<Keybuk> Kamion: bug #48038 ?
<Ubugtu> Malone bug 48038 in shadow "Always asks for root password" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/48038
<Kamion> ubiquity has never automatically advanced over questions (except due to bugs)
<Keybuk> is marked fix committed in your branch ... some months ago
<Kamion> Kagou: your 3 above has nothing to do with that bug
<Kamion> oh, sorry, Kagou != Keybuk
<Mithrandir> Kamion: it looks good to me.
<Kamion> Mithrandir: I'm just trying to at least do a debootstrap + simulate-install here
<Keybuk> Kamion: heh, I'm having a little bug day of my own ... doing my usual trawl through any package I've ever uploaded
<Mithrandir> Kamion: ok.  Tell me when you have it ready?
<bddebian> Heya folks
<Kaleo> Hi
<seb128> Mithrandir, Kamion: is the desktop having no timezone configured a bug?
<bddebian> Hello Kal
<bddebian> Err Kaleo
<seb128> Mithrandir, Kamion: time-admin doesn't like it, which is a g-s-t issue but I'm wondering if that's a desktopCD bug too
<Kamion> seb128: I'm going to have to get back to you later; can you file a ubiquity bug and I'll look at it later?
<seb128> Kamion: sure, no problem, doing that
<Kamion> Mithrandir: I've sent RT about livecd.sh; can you chase it up with sysadmin if required? I have to run out to the bank about urgent house-buying stuff
<zul> Kamion: good luck
<pitti> hi jvw 
<jvw> pitti: good evening!
<pitti> Mithrandir: example-content works fine here
<pitti> BenC: I have an installed system ATM; 'FATAL: Module i2c_powermac not found.'
<BenC> pitti: AH!...I forgot, I built it in since it's almost 100% going to be loaded anyway
<pitti> BenC: :)
<BenC> pitti: is there any output from snd-aoa in dmesg?
<pitti> BenC: however, that means it's something else...
<BenC> yeah, I may need to sync snd-aoa with upstream again
<pitti> BenC: nothing that matches 'snd' or 'aoa' in dmsg
<pitti> BenC: maybe this is interesting: 'PowerMac i2c bus pmu {1,2} registered'
<BenC> pitti: find /proc/device-tree | grep layout-id
<BenC> cat the file you find
<pitti> BenC: and similar for mac-io and uni-n
<BenC> well, it's definitely seeing the i2c then
<pitti> BenC: find -> no hit
<pitti> find | grep layout -> ram-layout-architecture
<BenC> hmm, ok
<pitti> which is certainly unrelated
<pitti> BenC: shall I modprobe snd-i2c?
<BenC> yeah, I think you need the latest snd-aoa stuff that doesn't use the layout-id
<BenC> nah, it's probably just an issue of not supporting your setup
<pitti> ok
<pitti> BenC: well, I wouldn't worry about it too much for knot-3, few people have ppc
<pitti> and with the desktop CD -powermac is loaded automatically still
<pitti> BenC: thanks
<BenC> np
<Riddell> Kamion: looks like new ubiquity is in, could you spin new kubuntu livefs
<Mithrandir> Kamion: yes, I'll do that.
<pitti> argh@wiki internal server error
<Mithrandir> seb128: I suspect it might be desktop-cd-no-recommend related.  Or, what do you mean by "no timezone"?  /etc/localtime not being there?
<Mithrandir> pitti: ok, cool, that means we don't have to rebuild alternate.
<pitti> Mithrandir: I'm glad about that, testing all possiblities takes half of the day
<pitti> Mithrandir: I'm currently testing ppc/rescue, then I'm through
<Mithrandir> pitti: I know. :-/  We need a proper test rig.
<pitti> Mithrandir: IMHO we can ignore the broken OEM mode for knot-3, vendors won't install an alpha release anyway
<pitti> Mithrandir: so it won't make sense to test desktop 14.1, if a new image is in preparation?
<Mithrandir> pitti: correct.
<Mithrandir> pitti: I'll note the broken oem thing in the release notes.
<pitti> whoops
* pitti files two more bugs
<mvo_> I got no usplash when installing on xfs (and so got lilo instead of grub). is that known?
* mvo_ was unable to find something about it in malone
<pitti> mvo_: I don't get usplash with alternate installs either
<pitti> mvo_: with the desktop CD it works (all on ppc)
<mvo_> I got it on the normal alternate install here
<roico> is there any chance to see the common customizations spec when edgy final comes out?... is there any progress with it?
<Mithrandir> Kamion: I suspect this will blow up: Need to get 1083MB of archives. After unpacking 3459MB will be used.
<Mithrandir> Kamion: something pulls in xubuntu-desktop, for instance.  Gnr.
<mvo_> Mithrandir: is this normal apt? do you know about -o Debug::pkgDepCache::AutoInstall=true ? 
<mvo_> Mithrandir: I found it very useful to find problem about what brings in what
<seb128> Mithrandir: no /etc/timezone and tzselect saying that the timezone is "Unknown"
<Mithrandir> mvo_: it's aptitude.
<seb128> Mithrandir: tzconfig rather
<mvo_> Mithrandir: it should support this as well 
<Mithrandir> mvo_: problem seems to be that we're not running with -R
<mvo_> aha, 'k
<mvo_> that certainly explains it :)
<Mithrandir> mvo_: so we're getting insane amounts of stuff installed.  Like xubuntu-desktop when bootstrapping ubuntu.
<pitti> mvo: do you have a bug for 'no usplash with alternate'? I'd like to say 'me too' for ppc and link it to T/Current
<mvo> pitti: not yet, but I can add one
<pitti> ok, ppc/altearnate tested through; really not in the best condition, but workable at least
<mvo> pitti: bug 60425
<Ubugtu> Malone bug 60425 in debian-installer "no usplash with i386-alternate CD and XFS" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/60425
<pitti> mvo: thanks, I added a comment
<mvo> pitti: thanks!
<pitti> mvo: usplash on live works for you as well?
<mvo> pitti: I haven't tested live yet, but a different alternate install gave me usplash
<pitti> oh?
<pitti> mvo: strange that it depends on the file system type
<mvo> pitti: XFS uses lilo, I suspect that something with the boot options is the reason
<pitti> ah
<pitti> mvo: well, I just get a black screen
<mvo> oh
<mvo> heh :)
<mvo> I just get the normal boot messages
<Riddell> Mithrandir: can you make me a new kubuntu live fs?
<Mithrandir> Riddell: yes, once I have live-fses which won't be DVD-sized.  We're monkeying around with the livefs build script now.
<roico> is there any chance to see the common customizations spec when edgy final comes out?... is there any progress with it?
<Riddell> Mithrandir: ah, didn't relise that
<Mithrandir> Riddell: (see above for "building ubuntu livefs includes xubuntu-desktop" hilarity.)
<bddebian> doko: You about by any chance?
<fabbione> Mithrandir: are we still deeply frozen?
<bddebian> Or anyone that deals with glibc?
<Mithrandir> fabbione: yes.
<fabbione> Mithrandir: any objections if i upload glibc to fix build on sparc? the change is sparc specific and it can be approved after knot-3
<fabbione> Mithrandir: it's not a blocker of anykind
<Mithrandir> fabbione: as long as nobody approves it, feel free.
<fabbione> Mithrandir: i won't ask for approval before knot-3. so i am doing it :)
<khermans> shouldn't the gdm package depend on xserver-xorg ?
<khermans> i will file a bug if you guys think so
<Mithrandir> no, you can run gdm without a local server.
<Mithrandir> think terminal server, for instance.
<khermans> oh ok
<khermans> by default, it tried to run X
<khermans> ok, thx for the info
<Tonio_> mvo: ping ?
<mvo> Tonio_: weak pong
<Nafallo> hehe
<Nafallo> mvo: 1000ms+ ? :-)
<Tonio_> mvo: I just noticed a little issue with launchpad-integration, see bug 60426
<Ubugtu> Malone bug 60426 in launchpad-integration "uses gnome prefs if kde and gnome are installed." [Untriaged,Unconfirmed]  http://launchpad.net/bugs/60426
<Tonio_> mvo: here is a debdiff that patches urls.py and closes the issue : http://paste.ubuntu-nl.org/23444
<Tonio_> mvo: any problem if I upload this ?
<Tonio_> mvo: changes should be commited to bzr I assume...
<seb128> Tonio_: main is frozen for knot-3, don't upload
<Tonio_> seb128: I know :) that was for "after the freeze" :)
<Tonio_> seb128: although that's minor issue, so there is no emergency
<seb128> Tonio_: I'm not sure the patch is correct, don't we have a better way to detect the desktop used that looking for gnome-session running?
<mvo> Tonio_: if you attach the patch to the bugreport I can merge it into bzr then. and then what seb128 said, it feels wrong to grep ps -A :)
<seb128> Tonio_: what about xfce?
<Tonio_> seb128: does it use gnome-open too ?
<seb128> Tonio_: I'm not sure, but I would like you to make sure before making a change ... and I fin the ps way hackish :)
<Tonio_> seb128: well concerning kde I can use KDE_FULL_VERSION env variable, but I didn't found a gnome equivalent......
<Tonio_> seb128: if you have a tip, would be nice :)
<seb128> Tonio_: no, I don't
<seb128> will think about it
<Tonio_> seb128: that the problem...... I kno ps stuff is not very clean, but it works....
<Tonio_> seb128: it would nice if both kde and gnome would set the same variable so that we could look at the one in use...
<seb128> Tonio_: we try to not hurry ugly code just because it works usually :p
<Tonio_> seb128: hehe, I agree :)
<seb128> when we have time to think about a better solution
<Riddell> Portland is the longer-term answer to this
<seb128> I've a "DESKTOP_SESSION="gnome"" on my edgy desktop
<mvo> xdg-utils, yeah
<Tonio_> seb128: "default" here......
<seb128> Tonio_: what desktop are you running?
<Nafallo> default here aswell, using gnome
<Tonio_> seb128: kde
<seb128> ok, so that one is not good enough
<Tonio_> Riddell: shouldn't we patch to get "kde" instead of "default" ?
<seb128> maybe raise the issue on the desktop or devel list?
<Nafallo> GDMSESSION="default" :-)
<seb128> Nafallo: not everybody is using gdm anyway
<seb128> Nafallo: relying on GDM variable is not perfect
<Nafallo> that's a point...
<Nafallo> GNOME_DESKTOP_SESSION_ID="Default"
<Tonio_> Riddell: can't we patch kdm to get DESKTOP_SESSION set to "kde" instead of "default" when kde is running ?
<Riddell> I suspect KDM will have a good reason to set it to that
<Riddell> I'd rather just investiagte Portland
<Tonio_> Riddell: sure
<Nafallo> and DESKTOP_SESSION is default for gnome as well, so probably a reason somewhere :-)
<seb128> Tonio_: from a mail on the gnome desktop list:
<seb128> "On Novell Linux Desktop, we have a number of applications which try to
<seb128> detect which desktop environment is running and perform the correct
<seb128> action.  I have no idea how much customization went into the detection
<seb128> scripts, but I know at least some did.  Here's what we look for:
<seb128>         $DESKTOP_SESSION == gnome
<seb128>         ${WINDOWMANAGER##*/} == *gnome*
<seb128>         $GNOME_DESKTOP_SESSION_ID == gnome"
<Nafallo> seb128: I have default on all of those ;-)
<giftnudel> maybe some variable should be set, this should not be too difficult to implement?
<Nafallo> !WINDOWMANAGER
<seb128> Nafallo: if GNOME_DESKTOP_SESSION_ID is set that's likely by GNOME though :p
<Tonio_> seb128: yes, DESKTOP_SESSION looks ideal for this... just that kdm doesn't set it as we need :)
<seb128> Tonio_: fix kdm then ;)
<giftnudel> Tonio_: file a bug
<seb128> Tonio_: for now look if GNOME_DESKTOP_SESSION_ID is set
<Nafallo> seb128: but the above code checked if it was set to "gnome" :-)
<Tonio_> giftnudel: well I'll had the information on bug 60426 since they are linked
<Ubugtu> Malone bug 60426 in launchpad-integration "uses gnome prefs if kde and gnome are installed." [Untriaged,Unconfirmed]  http://launchpad.net/bugs/60426
<seb128> Nafallo: that's a mail giving the idea, not a code
<Nafallo> ehm, right.
<seb128> Nafallo: you should be able to adapt on top of it instead of discussing details like that ...
<seb128> anyway, let's say if GNOME_DESKTOP_SESSION_ID is set we use GNOME
<seb128> KDE people know what they want to look for
<Nafallo> should be. I don't run XFCE ;-)
<seb128> Tonio_: can you update the patch according to that?
<Nafallo> but maybe it doesn't use gnome-session.
<Tonio_> seb128: sure
<seb128> thank you
<Tonio_> seb128: the point is isn't that better trying to fix kdm first to check for the same variable ?
<Tonio_> seb128: probably better than checking 2 different ones no ?
<seb128> DESKTOP_SESSION seems to be set to "default" if you use the default session with gdm too
<seb128> easier for now to do the lpi change
<seb128> and doesn't prevent to work on a cleaner xdg solution to detect the desktop
<Tonio_> seb128: ah okay
<trappist> is mailto:ubuntu-users@lists.ubuntu.com what we really want apt-cache to show for where to send bug reports?
<giftnudel> should probably be a spec for edgy+1
<trappist> (it's the Bugs line of every package I've tried it on)
<trappist> giftnudel: if that was for me, it sounds like a good idea
<giftnudel> trappist: sorry, it wasn't but there should be put some effort in that too
<dsas> trappist: I think someone else has raised that issue before (possibly Burgwork), not sure what progress was made.
<Kamion> BenC: DOH I'd better reject that hw-detect upload then
<BenC> Kamion: yeah, sorry about that
* Kamion shoves the publisher back to full-auto, having forgotten to do that earlier
<Keybuk> bug #44314
<Ubugtu> Malone bug 44314 in base-files ""telinit 2" doesn't stop X" [Wishlist,Rejected]  http://launchpad.net/bugs/44314
<Keybuk> dilema ... do I flame the guy mercilessly for bullshit in his last post
<Keybuk> or do I politely correct him
<mvo> CoC!
<mvo> :p
<Kamion> pitti: usplash defaults to 640x480 at present and there's no theme that fits that
<Kamion> (apart from the testcard)
<Kamion> so TBH it doesn't matter lots if usplash isn't installed properly :-)
<Keybuk> mvo: I'm somewhat tempted to suggest that he forfeited the right to protection under that when he started talking out of his arse
<bddebian> heh
<mvo> haha
<pitti> Kamion: ah, curious why it works when booting the live system then
<Nafallo> lol
<dholbach> hahahaha, who wrote those silly things about me on the fridge?
<thom> Keybuk: it's not _really_ his fault that debian and ubuntu have historically chosen to ignore run levels, but his response is a bit... daft
<Keybuk> thom: "runlevels exist in System III"!!!")"$()"$" :p
* Keybuk curiously looks at the letter between "sys" and "init"
<Kamion> pitti: usplash might be configured differently there, not sure
<thom> Keybuk: *g* indeed
<Kamion> pitti: the problem on the alternate install CD is very d-i-specific
<madduck> mdz: i'll try to get to your document today or tomorrow. sorry for the delay.
<jdong> pitti: do you think it's possible that we do security updates for flashplayer?
<jdong> pitti: http://www.adobe.com/support/security/bulletins/apsb06-11.html
<Tonio_> mvo, seb128: just attach fixed diff to bug 60426
<Ubugtu> Malone bug 60426 in launchpad-integration "uses gnome prefs if kde and gnome are installed." [Untriaged,Unconfirmed]  http://launchpad.net/bugs/60426
<pitti> jdong: didn't crimsun alrady prepare them?
<jdong> (I know it's multiverse and all :-/)
<jdong> pitti: I'm not sure
<pitti> jdong: as long as someone provides updated tested packages, uploading them is not a problem
<jdong> pitti: ah, it's been uploaded into edgy, apparently
<jdong> pitti: after it gets uploaded into edgy, what's the process for getting them into dapper?
<mdz> madduck: thanks
<pitti> jdong: mainly, building the package on dapper, testing it properly, and checking for regressions
<pitti> jdong: if that's fine, someone needs to prepare a new source package according to https://wiki.ubuntu.com/SecurityUpdateProcedures
<pitti> jdong: (appropriate version and changelog entry)
<pitti> hi mdz
<mdz> pitti: hi
<Mithrandir> hiya Matt
<seb128> hey mdz
<mvo> hey matt
<Zdra_> seb128 (or another GNOME ubuntu packager): can you take a look at this bug, please: http://bugzilla.gnome.org/show_bug.cgi?id=355117
<Ubugtu> Gnome bug 355117 in General "Use  instead of * for masking passwords" [Minor,Reopened]  
<mdz> good morning everyone
<Zdra_> in short: is the "" ubuntu specific ?
<Zdra_> for masking passwords
<seb128> Zdra_: it is
<bddebian> Hello mdz
<zul> afternoon mdz
<Zdra_> seb128: ok so it should be reverted in upstream and maybe applied in ubuntu package ?
<seb128> Zdra_: we are not going to patch every .glade for that, no
<seb128> Zdra_: feel free to make it reverted upstream though
<Zdra_> ok, thanks :)
<seb128> np
* zyg1 finally goes home
<BenC> anyone using dapper+nvidia?
<mdz> BenC: I'm using dapper+nvidia-the-chipset, but nv-the-driver
<BenC> mdz: Ok, I have a bug with dapper security, I think lrm needs recompiling...it's using the single symbol that changed because of the last upload
<mdz> BenC: why didn't the ABI checker detect that?
<BenC> it did, but I checked all (except lrm) modules to see if anything was using it...it's boot_cpu_data, which from what I found was only use by internal kernel stuff
<BenC> so I force ignored it to avoid a big ABI bump for just i386+1-symbol
<BenC> I'm not sure if I should reupload dapper kernel with ABI bump + l-m + lrm, or just rebuild lrm and do an ABI bump for next security update
<pitti> BenC: ugh
<BenC> fglrx, and other lrm modules aren't affected, neither is vmware-player-modules it seems
<BenC> mdz: which way do you think is best, full ABI bump, or just rebuild lrm?
<pitti> BenC: if we skipped the ABI bump for the kernel, why not just rebuild l-r-m without an ABI bump as well? doesn't that work?
<mdz> BenC: please do the abi bump
<BenC> pitti: yeah, that's the easiest plan
<BenC> that's what I want to do, but I want to make sure that's ok with everyone else too
<mdz> actually best would probably be to do both
<mdz> I guess rebuild now and bump later
<BenC> pitti: do we have any security updates for dapper?
<mdz> and please don't ever disable that check again
<BenC> I can do the lrm upload now
<mdz> in stable
<jdong|laptop> BenC: does that account for the complaints about system being broken by the kernel update?
<BenC> and we can do a security update within the next week or two
<BenC> mdz: ok
<BenC> jdong: for people using nvidia and not getting X, yes
<BenC> any others I'm not aware of
<jdong|laptop> BenC: alright, there's some vague complaints of breakage over at system76, I'll try to look into it
<BenC> jdong: There's also a VIA quirk patch reversal
<pitti> BenC: alright, I'll monitor the builds and push out lrm ASAP
<jdong|laptop> urgh
* jdong|laptop pulls out moderator hammer and crushes some flamewars
<pitti> BenC: yes, today I did a security review and committed new stuff into the svn
<jdong|laptop> BenC: you're killing me here :P
<Mithrandir> Keybuk: can you please accept bluez-utils_3.1-1ubuntu9 ?
<Mithrandir> Kamion: or you ^^
<BenC> jdong: next kernel will have the VIA patch taken out, and an ABI bump
<jdong|laptop> BenC: 0000:05:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8055 PCI-E Gigabit Ethernet Controller (rev 11)
<Mithrandir> preferably so it's part of this publisher run.
<jdong|laptop> BenC: was anything done with regards to that chipset of NICs?
<pitti> BenC: current lp_archive for security is just running; do you think you can upload lrm within the next 55 minutes?
<jdong|laptop> BenC: system76 reporting that it no longer works or shows up in hal after the updates
<BenC> pitti: yep
<pitti> BenC: ok, then we can have it on the mirrors in 2 hours
<mdz> BenC: which version introduced this regression?
<BenC> mdz: last one
<jdong|laptop> mdz: 2.6.15-26.47
<BenC> 26.47
<Kamion> Mithrandir: doing
<Mithrandir> Kamion: thanks
<Kamion> Mithrandir: done
<BenC> lrm is on it's way up
<BenC> I'm going to do a dapper+security+abi bump upload by this evening
<BenC> that VIA quirk thing needs to be fixed as well
<pitti> BenC: do you just want to revert that, or apply today's security fixes as well?
* Mithrandir goes out to find ingredients for making waffles.
<pitti> BenC: if the latter, we should coordinate with hoary/breezy as well
<BenC> pitti: it's up to you
<BenC> I can do either
<zul> hi..
<jdong|laptop> BenC: the sky2/sk98lin changes apparently breaks system76 ubuntu boxes, too
<pitti> zul: would you have time today for preparing another update?
<zul> i can do an upload tonight when i get home from work
<pitti> zul: if we can defer the abi update until tomorrow to give zul some breathing room, I'd prefer the latter
<pitti> BenC: ^
<pitti> BenC: since we'll have the lrm update soon, it doesn't seem that urgent any more?
<BenC> jdong: I'm surprised sky2 was working for anyone at all :/
<BenC> pitti: Ok, I'll get the security updates in, and we can upload tomorrow
<BenC> pitti: correct
<BenC> jdong: Do you have access to these systems?
<BenC> jdong: can you find out if they have sk98lin loaded, and if not do "modprobe sk98lin"?
<jdong|laptop> BenC: no, I don't have access to the systems; It's just that the guy in charge of system76 is telling me that the update broke networking
<jdong|laptop> which leads me to believe it worked before the update (i.e. a regression)
<BenC> jdong: can you get me in touch with him?
<jdong|laptop> BenC: he's on the forums in this thread: http://ubuntuforums.org/showthread.php?p=1498684
<BenC> that sky2 problem has been around since before dapper released, and I've never heard of sky2 actually working for someone
<jdong|laptop> he's been actively posting within the past few minutes :-/
<BenC> the sk98lin change was a direct forward port from breezy, and so far, no one with a sky2 has a) Bothered to test the sk98lin change, or b) bothered to report back abou tit
<BenC> I had test packages with it, and posted it to the largest bug report I have against the kernel (dozens of subscribers I bet), and after all the complaining NO ONE TESTED IT
<jdong|laptop> calm down... it's ok.... we still love you :)
<BenC> jdong: that post is about nvidia, and says "sound and networking are ok" :)
<jdong|laptop> BenC: look at post number 3
<BenC> nm, I see at the top
* BenC has never used the forums before
* jdong|laptop has noticed ;-)
<bddebian> heh
<jdong|laptop> fortunately this one hasn't turned into a major uproar {yet}
* jdong|laptop knocks on wood
<BenC> you had to say it didn't you :P
<jdong|laptop> BenC: apparently it breaks fglrx, too. yay!
<jdong|laptop> :)
<BenC> that's odd, because I have a dapper + fglrx system
<jdong|laptop> weird... I'm just reporting what people are saying :)
<jdong|laptop> BenC: did you catch the latest reply in that thread, regarding the sound issue?
<BenC> jdong: That may be the VIA issue I talked about
<BenC> for most people it caused a lock up when gnome started (presumably playing the login sound)
<jdong|laptop> hmm
* jdong|laptop notices BenC's new forum account, and hands him a shiny developer tag :)
<sladen> what do people normally get?  A "grain of salt" tag :)
<jdong|laptop> sladen: naw, we go by coffee beans
<jdong|laptop> after the CoC demons started rioting about the classic star-level thing :)
<jdong|laptop> we got tired of the whining, so I proposed coffee beans as a joke, and it stuck :)
<pitti> BenC: ok, so we don't need to to obey to fixed cron.dailies, as soon as the upload is ready, please fire away
<mdz> BenC: you said the upload was done, pitti doesn't see it
<pitti> BenC: nothing in REPORT for three hours
<BenC> lftp was still open...it doesn't process till the connection is closed, if I recall correctly
<BenC> was uploaded to dapper-security
<elmo> BenC: yeah, it doesn't
<pitti> BenC: there now
<pitti> mdz: ^
<BenC> ACCEPTED
<pitti> BenC: yeah, in accepted/ for two minutes now
* pitti cheers the buildds to go faster
<bddebian> Does that work? :_)
<jdong|laptop> BenC: should breezy people be seeing disappearing eth0's?
<Frederick> hi folks doesnt the image magick libs distributed in ubuntu have debug info?
<pascal80> pitti: what do you think about dynamically generated PPDs for Edgy as suggested here: https://lists.ubuntu.com/archives/ubuntu-devel/2006-August/020320.html
<pitti> pascal80: later, please
<pascal80> pitti: ok
<zyga> re
<bddebian> Frederick: Not likely unless there is a -dbg package
<Frederick> bddebian, so basically I cant debug my appl =/
<bddebian> Frederick: Sure you can, check out the DebuggingApps wiki page
* bddebian doesn't have the name/url handy sorry
<Frederick> bddebian, kdevelop doesn't seems to be happy samething applies to ddd
<bddebian> Frederick: Happy with what?
<Frederick> bddebian, for example I cant set break points nor watch variables
<bddebian> Frederick: All of Debian/Ubuntu packages have stripped binaries so all the symbol/debug information is "missing"
<Frederick> bddebian, oki but there is a -dev package for it and I believe it should have a -dbg package don't it?
<bddebian> Frederick: Not all packages have -dbg binaries no
* bddebian hopes someone corrects him if he is speaking out of his arse again
<bddebian> https://wiki.ubuntu.com/DebuggingProgramCrash
<Frederick> bddebian, thanks a lot
<bddebian> NP
<Frederick> I got an error =/
<Frederick> E: Could not open file /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_dapper_multiverse_source_Sources - open (2 No such file or directory)
<bddebian> Frederick: Do you have an entry for deb-src for multiverse in your sources.list?
<jdong|laptop> 403 forbidden on the 26.47 kernel updates
<jdong|laptop> is that our way of blocking users from getting the borked updates?
<Frederick> bddebian,  yep http://rafb.net/paste/results/I68SbL12.html
<pitti> jdong, Frederick: will be fixed soon, yes, we want to block a faulty update
<Frederick> pitti, ?
<jdong|laptop> pitti: cool, glad to hear we're blocking it. Has packages.gz been updated to reflect that?
<jdong|laptop> pitti: there's users at the forums getting 403's from trying to do an update, wondering if that's because their packages.gz is not up-to-date
<Frederick> pitti, what do you mean?
<pitti> Frederick: we currently building an updated linux-restricted-modules, since the previous kernel update broke nvidia driver
<pitti> Frederick: and we don't want people to download the faulty version for the time being
<pitti> Frederick: thus we blocked the package lists
<pitti> Frederick: they will work again soon
<Frederick> I have no problems with that :P my problem is with imagemagick =/
<jdong|laptop> Frederick: I think pitti means they blocked the package lists....
<jdong|laptop> Frederick: and that's causing your apt errors
<Frederick> jdong, oh
<Frederick> but I think the lib doesn't have dbg info avaliable for ubuntu =/
<jdong|laptop> pitti: are rollback procedures to be posted on ubuntu.com like last time, for the users already bitten by this bug?
<pitti> jdong|laptop: actually we didn't block the package lists
<jdong|laptop> pitti: we're trying to figure out the best way to address this at the forums, since a number of users are already affected
<pitti> jdong|laptop: some minutes, please, while we finish this at maximum speed
<jdong|laptop> k, sure
<Frederick> jdong|laptop, so I should also wait some minutes and try again later?
<jdong|laptop> Frederick: try an apt-get update... it should resolve itself
<pitti> jdong|laptop: we prefer apt-get failure over installing a broken kernel
<pitti> since users can recover from the former, but it's tricky with broken X in the latter case
<mdz> jdong|laptop: we're focused on getting a corrected package up right now
<jdong|laptop> pitti: yeah, I totally agree with that
<jdong|laptop> pitti: it's just that if you block linux-headers, it makes it hard for people to recompile a custom nvidia against the new kernel ;)
<jdong|laptop> mdz: I understand that. just trying to keep forum users at bay for now :)
<mdz> jdong|laptop: thanks
<pascal80> pitti: can I ask now?
<pascal80> pitti: what do you think about dynamically generated PPDs for Edgy as suggested here: https://lists.ubuntu.com/archives/ubuntu-devel/2006-August/020320.html
<Mithrandir> pascal80: we've already implemented it?
<jdong|laptop> pascal80: dude you waited a total of like 10 minutes :D
<Mithrandir> "are we there yet?"  "no, we were there two weeks ago"
<pascal80> Mithrandir: I don't think, I just would like to hear pitti's opinion
<jdong|laptop> Mithrandir: hey! this week I am resisting the urge to ask about knot3 :P
* pitti thinks it's a great idea and also saves space on the CDs
<Mithrandir> jdong|laptop: I could give you a long story about everything conspiring against us, but you could piece most of it together by reading backlog here
<jdong|laptop> Mithrandir: yes, I noticed. So are the Knot3 dual-layer DVD's ready yet? ;)
<Mithrandir> we're not making DVDs for knots, just for beta and release.
<Mithrandir> they're not intrinsically harder either ; it's just that it's more testing and therefore more work.
<jdong|laptop> just teasing :)
<jdong|laptop> Mithrandir: at least it'd accomodate that extra xubuntu-desktop or two :)
<Mithrandir> jdong|laptop: true dat.  We'll stuff it full of langpacks instead, though
<jdong|laptop> mdz: sorry to bug you on this one, but do you have a recommended solution for users affected by the nvidia breakage, other than sit around for a few hours and yell at the forum staff?
<jdong|laptop> i.e. using apt-get to roll back to the previous kernel, switching back to nv, etc
<pitti> jdong|laptop: it's a matter of minutes now
<jdong|laptop> pitti: k, then we'll take the heat :)
<pitti> jdong|laptop: the solution for people who already have a broken system is:
<pitti> jdong|laptop: logging in to a text console, sudo apt-get update, sudo apt-get dist-upgrade
<pitti> and then sudo reboot
<jdong|laptop> pitti: k, thanks
<pitti> jdong|laptop: thanks a million for being the mediator to the forums
<jdong|laptop> pitti: no problem
<pounk> hello, when I try to install the linux-header, I have an error 403... the http://security.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.15/linux-headers-2.6.15-26-386_2.6.15-26.47_i386.deb dont work
<Frederick> are the packages still blocked?
<pounk> try to go the the url.. is a 403 error
<bddebian> pounk: Known problem that they are working diligently on
* ..[topic/#ubuntu-devel:pitti] : Ubuntu Development (not support, even with edgy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | 6.06.1 released | Main frozen for knot 3 | current kernel security update is blocked, update being worked on, will be fixed any minute
<pitti> pounk: ^
<pounk> ok, is because the package have a problem or is a permission error on the server?
<Frederick> I think I wil lgo for MSVS =/
<BenC> pounk: "blocked" would imply that it was in purpose :)
<zul> pitti: might want to do that on #ubuntu as well
<pitti> pounk: the former
<pounk> ok
<pitti> zul: I shouted there, but I can't change the subject in #ubuntu
<zul> ok
<pounk> also with the kernel, the vmware package don't work
<pounk> this*
<jdong|laptop> pounk: http://ubuntuforums.org/showthread.php?t=257459
<cr3> there seems to be an update of linux-image-2.6.15-26-386, but the package name and version look exactly the same. why is that?
<cr3> shouldn't the next update be linux-image-2.6.15-27-386?
<Burgwork> pitti, you need the #ubuntu topic changed?
<pitti> Burgwork: would be nice, same last component of this channel's
<jdong|laptop> cr3: my understanding is that 27 is coming soon... right now it's just usn 346-2 to solve the restricted module problem
<pitti> Burgwork: although it's now almost done
<jdong|laptop> hopefully 27 will revert some of the other regressions introduced
<cr3> jdong|laptop: "usn 346-2"?
<jdong|laptop> http://www.ubuntu.com/usn/usn-346-2
<pitti> usn-346-2 will only fix the nvidia stuff
<jdong|laptop> right
<pitti> I didn't yet send out the email
<cr3> jdong|laptop: interesting, I don't see what part of that security notice would make the Marvell ethernet controller stop working.
<jdong|laptop> cr3: there were other bugfix updates in USN-346-1 that were not mentioned in the notification
<Burgwork> pitti, done
<pitti> thanks
<jdong|laptop> cr3: namely, a sky2 driver forward-port from breezy
<BenC> cr3: Please subscribe to https://launchpad.net/bugs/60271
<Ubugtu> Malone bug 60271 in linux-source-2.6.17 "wired network does not work since 2.6.17-7" [Untriaged,Needs info]  
<BenC> same bug, applies to dapper too
<Kamion> cr3: the "27" bit indicates module ABI - it's not the package version
<cr3> BenC: hi! saw your posting on ubuntuforums
<Kamion> cr3: each successive upload may but does not necessarily increment the module ABI
<jdong|laptop> cr3: are you mr. system76?
<cr3> jdong|laptop: nope, but I'm in contact with him :)
<jdong|laptop> ah, ok
<cr3> jdong|laptop: they are a very cool company selling laptops with Ubuntu preinstalled
<BenC> cr3: just got the output, let me read through it real quick
<jdong|laptop> cr3: absolutely, they're awesome :)
<jdong|laptop> cr3: just hope they're not too swamped by what's been going on :)
<sladen> mjg59: http://www.linuxfirmwarekit.org/
<cr3> jdong|laptop: the problem has incured some support indeed, I sure wish I could tell him something to help
<jdong|laptop> BenC: is there a launchpad bug for the possible sound/via issue?
<AlinuxOS> cr3, in Italy there is Essedi Shop, that sells computers with Kubuntu preinstalled.
<AlinuxOS> just a info :) essedi.it
<cr3> AlinuxOS: we would love to have them listed in our Ubuntu Marketplace, are you sometimes in contact with Essedi?
<AlinuxOS> cr3, no I'm not...some friends of mine bought Linux suitable hardware.(They have Linux Assemblator Software) and they install Kubuntu :)
<BenC> cr3: replied to the output from system76
<bluefoxicy> wow
<AlinuxOS> cr3, I can contact them if you want.
<bluefoxicy> Nitan is asking Ubuntu for money
<AlinuxOS> It depends if you need this.
<bluefoxicy> https://wiki.ubuntu.com/CompressedMemory
<crimsun> jdong|laptop: precise details being...?
<jdong|laptop> crimsun: either hard lockup on gnome login sound, or soundcard disappearing after kernel update
<jdong|laptop> system76 is experiencing the latter
* ..[topic/#ubuntu-devel:pitti] : Ubuntu Development (not support, even with edgy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | 6.06.1 released | Main frozen for knot 3
<bluefoxicy> hi pitti
<pitti> Burgwork: can you please update #ubuntu, too? kernel can be downloaded again and new l-r-m is up
<jdong|laptop> crimsun: maybe BenC can provide you with better info than me; I'm just going by what people at the forums have been reporting
<AlinuxOS> cr3, you can notice SMART CONFIGURATOR: http://essedi.it/smartconfigurator.htm?SID=
<AlinuxOS> pitti, hello ;)
<pitti> hi bluefoxicy, hey AlinuxOS 
<crimsun> jdong|laptop: I don't know who this 'system76' is.
<jdong|laptop> crimsun: they're a hardware company selling only ubuntu systems
<bluefoxicy> hm
<AlinuxOS> pitti, Edgy will Rock I see :) there is Georgian listed in debian-installer menu :)
<jdong|laptop> they were the first ones to report having problems with the kernel update
<BenC> jdong: that's the VIA problem, fixed in git repo already
<bluefoxicy> He should probably go through the bounty system, shouldn't he?
<cr3> BenC: last reply I see from you on ubuntuforums is asking for lspci output
<crimsun> right, the revert
<jdong|laptop> BenC: k, regarding dapper though?
<BenC> cr3: it's via email to the system76 guy
<BenC> jdong: Yes
<AlinuxOS> pitti, but there is horrible,ugly fonts(again and again) so I'm working to replace them. I'm talking about gnu unifont.
<cr3> BenC: can you forward the email to me as well, he's expecting a call from me this afternoon
<crimsun> jdong|laptop: http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-dapper.git;a=commitdiff;h=23a7178767252cc5b6337b74c2359950aa099d08
<BenC> cr3: email
<BenC> ?
<cr3> BenC: /msg'ed it to you
<jdong|laptop> crimsun: yeah, that's what broke it, right? where's what fixes it? when will that be available via apt?
<jdong|laptop> crimsun: linking a baffled forum user to a git commit won't do the trick
<crimsun> huh? I thought reverting it _fixed_ the symptoms.
<jdong|laptop> crimsun: hmm, the recent kernel update _caused_ these problems, apparently :)
<mdz> jdong|laptop: it's up now, linux-restricted-modules 2.6.15.11-4
<BenC> cr3: sent
<jdong|laptop> mdz: yep, saw that. thanks. that resolves the nvidia issues :)
<BenC> yeah for long distance phone conferences
<mdz> jdong|laptop: the via issue is bug 52649
<Ubugtu> Malone bug 52649 in linux-source-2.6.15 "VIA IRQ quirk changes in 2.6.15-26.44 have broken various VIA devices" [High,Fix committed]  http://launchpad.net/bugs/52649
<BenC> s/yeah/yay/
<jdong|laptop> mdz: I've put up a global announcement on the forums already...
<mdz> jdong|laptop: thank you
<jdong|laptop> mdz: yep, np. thanks for the via link, too
<Burgwork> pitti, so issue is fixed?
<ajmitch> morning
<pitti> Burgwork: yes, it's out, tested, and announced
<crimsun> jdong|laptop: unless git timestamps are playing tricks on me, that _is_ the commit.
<cr3> BenC: wow! that is some workaround, I'm impressed how you could come up with something like that
<Burgwork> pitti, done
<jdong|laptop> crimsun: I think they are.... BenC just said in the launchpad ticket that it's gonna be in the _next_ upload
<jdong|laptop> the fix
<pitti> Burgwork: merci
<BenC> cr3: it's pretty common, most ppl just don't know about it :)
<Burgwork> de nada
<jdong|laptop> Burgwork: your french needs some work ;)
<pitti> sounded like Spanish :)
<jdong|laptop> yeah, sure did
<Burgwork> jdong, yes, my french does need work
<cr3> BenC: is this something totally specific to the sk98lin or other drivers as well?
<BenC> cr3: You can add pci id's to any pci driver using that method
<jdong|laptop> hey, kudos to everyone on how fast the nvidia problem got fixed. impressive :)
<cr3> BenC: /sys/bus/pci/drives/sk98lin seems to be a file on system76's system
<cr3> BenC: scratch that, something weird is going on
<BenC> yeah, that would have been weird :)
<cr3> BenC: I told him to change the ">" with "| sudo tee" and sudo apparently segfaulted. weird
<cr3> BenC: weird, input/output error when trying to cat the file
<Treenaks> cr3: sudo cat | tee
<Treenaks> cr3: not cat | sudo tee
<mdz> BenC: there is a report in the forums about a problem with fglrx; it could easily be a misunderstanding but it needs to be investigated anyway just in case: http://www.ubuntuforums.org/showthread.php?t=257353&page=2
<BenC> mdz: probably same issue as nvidia
<cr3> Treenaks: the original command was echo 'foo' > /file/owned/by/root which I suggested changing to echo 'foo' | sudo tee /file/owned/by/root
<jdong|laptop> mdz, BenC: another fglrx one : http://ubuntuforums.org/showthread.php?t=257405&highlight=fglrx
<BenC> cr3: I/O error n read is expected
<BenC> cr3: sudo -l root
<BenC> then do the command
* _ion has used do_something_as_user | sudo tee file routinely for ages, and hasn't had any problems so far.
<BenC> cr3: oops, wrong command, "sudo /bin/bash"
<_ion> benc: Rather sudo -i or sudo -s
<BenC> one of them there to get you a root shell
<cr3> BenC: he tried your echo and gets "no such file or directory", he tried ls and find, the file is there.
<mdz> BenC: it should be straightforward to confirm that
<BenC> mdz: yeah
<BenC> if it's "missing symbol boot_cpu_data"
<BenC> then that's it
<mdz> the one I saw didn't provide any details
<shaya> is there a better way to extract meta data of installed packages then constantly calling dpkg --status $package and greping for the meta data?
<mdz> shaya: dpkg-query
<BenC> cr3: that's an odd error
<cr3> BenC: he is using a root shell, trying to cat the file is still returning input/output error. weird
<shaya> mdz: doesn't seem to be different for my purposes.  I'm trying to extract version, dependency, conflict, provide relationships
<shaya> for a research project I'm doing based on edgy
<mdz> shaya: man dpkg-query, search for showformat
<BenC> root@grayson:/sys/bus/pci/drivers/ohci1394# echo 11ba:4471 > new_id 
<BenC> root@grayson:/sys/bus/pci/drivers/ohci1394# 
<BenC> cr3: the command works for me
<BenC> cr3: I just did it on a random pci driver with a random id, but it took it
<mdz> BenC: 
<mdz> [ 1787.044040]  fglrx: disagrees about version of symbol boot_cpu_data
<mdz> [ 1787.044075]  fglrx: Unknown symbol boot_cpu_data
<shaya> I see
<BenC> mdz: fixed with lrm rebuild then
<cr3> ~# cat /sys/bus/pci/drivers/PIIX_IDE/new_id
<cr3> cat: /sys/bus/pci/drivers/PIIX_IDE/new_id: Permission denied
<jdong_> BenC: so does murphy's law state that every module you didn't check would depend on boot_cpu_data? ;-)
* jdong_ ducks
<cr3> BenC: I'm getting a permission denied as well, you're running a freaky shell
<BenC> cr3: I did "sudo /bin/bash; echo xxxx.xxxx > new_id"
<mdz> BenC: yes, but means that the problem was more widespread than we thought
<mdz> jdong|laptop: confirmed that both nvidia and fglrx are affected
<mdz> jdong|laptop: so those users are experiencing the same bug
<mdz> the rest of l-r-m is OK
<BenC> mdz: true
<cr3> BenC: I'm also getting permission denied and I'm using sudo bash
<BenC> privmsg me a transcript of you running that command
<Mithrandir> Keybuk: please accept bluez-utils_3.1-1ubuntu10_source.changes once it's up.
<zul> mdz: are you going to be around later?
<mdz> zul: I expect to be
<zul> mdz: ok great..
<zul> ttyl
<Keybuk> Mithrandir: isn't the publisher disabled?
<Keybuk> yes, it is
<Keybuk> so it won't "get" up
<BenC> pitti: We still doing the dapper-security (and hoary/breezy) uploads tomorrow?
<mbiebl> lamont: Is there a reason, why /etc/init.d/postfix calls lsb_release?
<mbiebl> This slows down my boot process quite a bit (~5sec)
<mbiebl> Seems lsb_release calls apt-cache, which needs a lot of I/O
<slomo> pitti: now i'm there
<SlicerDicer-> Kamion: are you about?
<pitti> BenC: whenever they are ready
<Kamion> AlinuxOS: please extend GNU unifont rather than replacing it; I really don't want to switch to something different at present
<BenC> pitti: Ok, I'm working on dapper right now
<pitti> slomo: hm, I forgot what I wanted to ask you :/
<pitti> slomo: ah, right, something about CD testing, but it's sorted out already
<slomo> pitti: ok :) what's the state of the cds now btw?
<Kamion> AlinuxOS: (replacing characters is fine of course, I just don't want to be told to switch to a different font which will then be suboptimal for some other language)
<Keybuk> Kamion: is the publisher meant to be disabled?
<pitti> slomo: https://wiki.ubuntu.com/Testing/Current
<Kamion> Keybuk: it's not?
<Kamion> $ sudo -u lp_publish crontab -l
<Kamion> MAILTO=lp_archive
<Kamion> 3 * * * * /srv/launchpad.net/codelines/current/cronscripts/publishing/cron.daily
<pitti> we disabled it for the emergency l-r-m update, but I guess it can be re-enabled now
<Kamion> oh, nothing to do with me then :)
<Kamion> SlicerDicer-: briefly
<SlicerDicer-> Kamion: I will just shoot you a email no worries
<Keybuk> Kamion: uh, someone so reactivated it in the last ten minutes then
<Keybuk> in fact, I bet someone just went "oh fuck" and silently reactivated
<Kamion> SlicerDicer-: ok
* Keybuk waves to whoever that is
<Keybuk> lp_publish@drescher:~$ crontab -l
<Keybuk> MAILTO=lp_archive
<Keybuk> #3 * * * * /srv/launchpad.net/codelines/current/cronscripts/publishing/cron.daily
<Keybuk> *minutes later*
<Keybuk> lp_publish@drescher:~$ crontab -l
<Keybuk> MAILTO=lp_archive
<Keybuk> 3 * * * * /srv/launchpad.net/codelines/current/cronscripts/publishing/cron.daily
<Keybuk> <g>
<jdong> on a sidenote, I can't believe the forums have stayed up given the increased traffic with today's fun :)
* jdong knocks on wood.... :)
<Keybuk> today's fun?
<pitti> Keybuk: breaking X again, what else :-P
<jdong> Keybuk: kernel update, x breakage, what else is new around here? ;P
<beuno> nvidia only this time  :D
<Keybuk> oh, ABI change with the kernel weekly exploit dose?
<jdong> beuno: naw, nvidia too.. sky2 networking, via sound
<pitti> Keybuk: http://www.ubuntu.com/usn/usn-346-2
<jdong> beuno: I meant fglrx
<Keybuk> SERVES THEM RIGHT FOR NOT OPE...oh, wait, I have an nvidia too...
<jdong> LOL
<_ion> :-D
<beuno> heh
<AlinuxOS> Hello, http://alinuxos.no-ip.org/debian-installer.png I can't find this English string in debian-installer.po file, can someone help me ?
<jdong> Keybuk: and I'm sure that's the reason all of this happened :)
<jdong> Keybuk: after all, it's not like the source code to nvidia.ko is what we compile or anything
<Keybuk> jdong: we don't have most of the source to nvidia.ko
<Keybuk> it's a .o file
<cr3> can anyone actually read or write new_id files under /sys/bus/pci/drivers? I really have no clue how BenC manages to pull it off
<jdong> Keybuk: we have enough of it to make it binary-compatible with the frickin kernel update :P
<Keybuk> cr3: explain
<cr3> Keybuk: as root, I get "Permission denied"
<beuno> jdong: do you have any idea how many ppl were affected thistime?
<Keybuk> cr3: maybe the driver doesn't support it
<_ion> --w------- 1 root root 4096 2006-09-15 00:02 /sys/bus/pci/drivers/PIIX_IDE/new_id
<BenC> cr3: You can NOT read the files, they can only be written to
<Keybuk> echo -n 0000:00:00:00 > new_id  usually works for me
<BenC> Keybuk: it's not the driver, it's the PCI subsystem, it lets them all support it
<cr3> is the "-n" absolutely necessary? everytime system76 tried the echo, it seemd to freeze his terminal :(
<jdong> beuno: at least around 200 people on the forums have commented on the problem
<Keybuk> cr3: I usually do the -n when echo'ing anything to the kernel
<BenC> cr3: if it froze his terminal, then it worked
<Keybuk> lol
<BenC> well, it worked in that it took the command
<Keybuk> "if kernel crashes, then it worked"
<BenC> check dmesg
<BenC> well it didn't freeze the kernel, just the command blocked :P
<Keybuk> "driver, meet this hardware, hardware meet this driver, now FIGHT!"
<beuno> jdong: so it's pretty big...
<Keybuk> why does the command block like that?
<cr3> BenC: ok, thanks, I was worried there for a moment.
<jdong> beuno: despite how miraculously fast the ubuntu team reacted, unfortunately a number of users were affected, yes. 
<BenC> it blocks because it starts a driver bind/probe
<cr3> BenC: are changes to /sys/.../new_id permanent or is there some file I should modify for changes to be permanent?
<beuno> jdong: any idea what happend with the idea to add an extra step before these things get into the repos?
<BenC> cr3: it does not last across reboots, no
<jdong> beuno: people don't really test and report back?
<AlinuxOS> Kamion, maybe you know why I can't find this string:  http://alinuxos.no-ip.org/debian-installer.png
<jdong> beuno: BenC had a rant about that earlier :)
<BenC> cr3: that command would have to be added to an init script, or done after each boot
<jdong> beuno: and I can tell you the same thing from backports.... people don't tell you it breaks UNTIL you move it into the stable repos :P
<beuno> jdong: great, add me to it  ;)
<cr3> BenC: at the end of rc.local should be fine? I'm just afraid of what will happen to the following rc scripts because of that crashing behavior
<Kamion> AlinuxOS: that's an Ubuntu-specific string; you'll find it in debian-installer in Rosetta
<Kamion> should be in the kbd-chooser section
<beuno> jdong: so what's the plan?  I thought that would contain these problems a bit more, but if it's not the solution...
<jdong> beuno: I don't know what's the plan. I'd like to know too.... I don't make such calls around here ;-)
<AlinuxOS> Kamion, Edgy-s debian-installer is not translatable in this moment...what can I do ?
<jdong> beuno: you're gonna have to poke different people in this room for that info
<Kamion> AlinuxOS: well, for starters that string won't be relevant in edgy :-)
<Keybuk> BenC: isn't the driver bind/probe supposed to unblock eventually though?
* beuno is afraid to poke anyone at this stage
<Kamion> AlinuxOS: we'll get it sorted out soon, but the code needs to be in place first
<BenC> cr3: I'm a little worried that it gives an error, I'd like to see the dmesg output from the addition of the command
<AlinuxOS> Kamion, won't be relevant ? :)You mean that this string will change or something similar ?
<Kamion> AlinuxOS: that's a string in kbd-chooser, which is being replaced by console-setup; the strings in console-setup are different
<BenC> Keybuk: it does, he said it hangs for  a bit then errors
<Kamion> so there is essentially no point in translating that string
<beuno> well, I'm off, will check later to see who else needs to get walked through the breakages
<beuno> good luck  ;D
<Kamion> interesting, that string indeed doesn't seem to be in the .pot file
<Keybuk> BenC: ahh, I usually just see that hang forever
<AlinuxOS> Kamion, it would be great if rosetta-s guys order modules by importance. So in this way translators can understand which module is more-less important.
<Kamion> AlinuxOS: oh, you didn't tell me that was edgy :-)
<Kamion> AlinuxOS: that *is* the console-setup string
<AlinuxOS> ah
<Kamion> AlinuxOS: I'll get it added to the master d-i .pot file tomorrow
<AlinuxOS> Kamion, thank you.
<Kamion> AlinuxOS: they already do have some degree of ordering by importance, as I understand things
<Kamion> and there is a rough importance ordering in debian-installer.pot
<AlinuxOS> Kamion, great.
<jdong> mdz: one of the most common questions we get at the forums after an incident like this is "what is gonna be done to prevent this in the future"
<jdong> mdz: do you/Canonical have anything official you'd like us to tell forum users?
<AlinuxOS> Kamion, debian installer uses gnu unifont right ?
<Kamion> AlinuxOS: yes
<AlinuxOS> Kamion, so I must change georgian font section, actual fonts are not proprortional at all and very ugly...unbelivably ugly :)
<lamont> mbiebl: to figure out where it is.
<mdz> jdong: I can't give you an official response at this time; we're still dealing with the immediate problem
<lamont> mbiebl: otoh, the init script doesn't actually use the result.
<jdong> mdz: ok, that's fine
<cr3> BenC: nothing appears in dmesg, sk98lin module is still there, ifconfig eth0 up returns "no such device"
<AlinuxOS> Kamion, are there some other modules straightly linked with debian-installer (for translation of course)?
<mbiebl> lamont: I wasn't sure if postfix needs this environment variable.
<mbiebl> If not, I would simply remove this check.
<lamont> mbiebl: it's code that is in both postinst and in init.d.  at one point it was used in init.d
<mdz> jdong: anyone who upgraded between approximately 1400 and 2000 UTC should be sure to upgrade again before their next reboot
<mdz> if they use the proprietary drivers
<sladen> okay,whichjokerstolenmyspacebarinX?
<pitti> sladen: 'Empty spaces -- what are we living for?'
<pitti> o/`
<sladen> ./mepondersonasolution
<pitti> copy&paste existing spaces from text files *duck*
<AlinuxOS> pitti, The show must go on! :)
<LaserJock> pitti: ouch
<pitti> AlinuxOS: my space bar may be flaking, but my vi goes on
<AlinuxOS> loooool pitti 
<pitti> sladen: since an upgrade, or what changed?
<jdong|laptop> mdz: I'll add that to the forum announcement. thanks!
<pitti> s/goes on/still stays on/ of course /me sends excuses to Freddie
<cr3> BenC: you mentionned liking to see the dmesg output from the addition of the command so I privmsg'ed it to you
<sladen> pitti:well,quite:)
<AlinuxOS> Kamion, console-setup or console-setup-fonts-udeb ?
<Kamion> AlinuxOS: console-setup source package, but please don't translate it yet - we'll disable translations of that when it gets sucked into debian-installer
<Kamion> AlinuxOS: what do you mean by "some other modules straightly linked with debian-installer"?
<AlinuxOS> :) example: console-setup
<Kamion> there are a whole bunch, too many to list
<AlinuxOS> ah
<AlinuxOS> Kamion, so we need that bunch into rosetta, listed before.
<Kamion> AlinuxOS: with the exception of console-setup, they already are
<Kamion> AlinuxOS: see https://launchpad.net/distros/ubuntu/edgy/+source/debian-installer/+translations
<Kamion> they're all incorporated in one giant template
<AlinuxOS> Some people (like me), translators don't know which module is more-less important. So when you have mature consol-setup and debian-installer it will be super to have everything listed in rosetta in first page.
<Kamion> AlinuxOS: translators should just go to debian-installer
<Kamion> one module
<Kamion> it has everything in an appropriate order for translation
<AlinuxOS> Kamion, super.
<AlinuxOS> Kamion, thank you very much for info! ;)
<Kamion> np
<jdong|laptop> LOL, you guys will get a laugh out of this one
<jdong|laptop> "My MCSE (microsoft certified service engineer) teacher was telling me today in class that open source means that the programmer got stuck and didn't finish the program, which is why open office is so bad. is this true?"
<SEJeff> jdong|laptop: And thats why Ubuntu won't play mp3s after I install it, right? </sarcasm>
<jdong|laptop> :)
<AlinuxOS> openoffice is so bad ???hm I don't think so.
<SlicerDicer-> jdong: I would use the phase "excuse me can you repeat that in english please, I have not been to studies on stupid yet"
<SEJeff> jdong|laptop: And someone should ask that guy why M$ used so much "open source" bsd code in their early tcp/ip stack :)
<SEJeff> his reaction to his own stupidity: Priceless...
<jdong|laptop> SEJeff: so MS can finish it? *ducks*
<SlicerDicer-> ohh no SEJeff I am sure he would figure a way to say ohh that never happend just to raise his stupidness level.
<SlicerDicer-> lol jdong|laptop 
<SEJeff> jdong|laptop: I have a buddy that actually believes what you just said. SlicerDicer-: And thats why people like us are here to prove him wrong
<jdong|laptop> SEJeff: I've worked at an all-Microsoft camp. you won't believe some of the firefox myths I've had to put up with
<SlicerDicer-> SEJeff: don't you mean "had" ;-)
<Burgwork> guys, this is -devel, please keep the chatter to a minimum
<Burgwork> guys, this is -devel, please keep the chatter to a minimum
<SlicerDicer-> sorry Burgwork 
<Frederick> does anyone ever managed to get debbug info for image magick in ubuntu?
#ubuntu-devel 2006-09-15
<sistpoty> Kamion | mdz: what's the current procedure to get an universe package into dapper-updates?
<mdz> sistpoty: it's being written, due out tomorrow
<mdz> will be on -devel-announce when it's done
<sistpoty> mdz: ok, thanks
<ogra> hmm, no knot3 ?
<tseng> ogra: i can upload right?
<tseng> ogra: and it will just be held
<ogra> right
<tseng> ok
<zul> mdz: ping
<mdz> zul: pong
<mdz> I was just trying out your Xen howto
<zul> and?
<zul> still needs some work i think
<mdz> and I've made some edits you may want to review
<zul> sure no problems...the kernels in the /boot directory are named that way because of kernel-package
<mdz> zul: is there a generic Xen howto you can link to which picks up where yours leaves off?
<zul> yes debian-administration site
<zul> http://www.debian-administration.org/articles/396
<zul> as well im working on the restricted modues, meta-xen, and a domU kernel as well
<mdz> zul: that would be a good link to add to the end of your wiki page
<zul> ok
<zul> mdz: there is a git repository as well hosted by olpc i could send you the url if you wish
<bddebian> Howdy folks
<zul> as well Mithrandir has been contributing some patches 
<zul> http://dev.laptop.org/git.do?p=projects/ubuntu-xen;a=summary fyi
<BenC> zul: I contributed a "what the hell were you thinking taking on xen packaging" a few times, don't I get some credit? :)
<zul> BenC: yeah you did, and now i lost hair because of it :)
<LaserJock> heh, I wonder how BenC can keep all that hair sometimes
<BenC> I hear working on archive maint is cake work, so do that for awhile ;)
<zul> no thats ok, im crazy enough
<BenC> Kamion: ping
<terlmann> i have a major ubuntu ptoblem! i tried to run msudo nautilus as user terlmann but the thing ran as "hal" and now my screen is whacked out,the bottom menu are 3 inches from the bottom of the screen,and the mouse pointer has to locate 1 inch BELOW the dialog i wanna click... has anyone got a solution?
<terlmann> HELP !!
<jdong> terlmann: this is not a support forum; this channel is for developers of ubuntu. Please try #ubuntu or another support method instead
<terlmann> but i need developer strength formula,real programmer support!
<bluefoxicy> <+FirefoxKal> Bluefox: the poor asian language support in linux is bad :\
<bluefoxicy> o.O
<bluefoxicy> he's using knot2 now
<bluefoxicy> I thought there was good hongkongese support
<slomo_> doko: ecj-bootstrap-gcj doesn't want to run postinst in the buildd chroots :/ http://librarian.launchpad.net/4209912/buildlog_ubuntu-edgy-i386.ikvm_0.26.0.1-2ubuntu2_FAILEDTOBUILD.txt.gz
<bluefoxicy> doko:  you around?
<Frederick> folks why doesnt ubuntu features the dgb info for image magick?
<bddebian> Frederick: As I told you earlier today, all Ubuntu and Debian packages strip their binaries to conserve space on the archives :-)
<bluefoxicy> aww man, sourceforge is up but the project web server is down, what the ass
<sistpoty> bluefoxicy: if you want to get to a download page, you can do so with sourceforge.net/projects/<project>
<bluefoxicy> sistpoty:  I want to finish my web page before the deadline.
<bluefoxicy> I don't want to have to adjust the time on my project
<sistpoty> he, well can't help you there then ;)
<bluefoxicy> sistpoty:  can you help me by somehow getting OLPC to give me an OLPC?  ;)
<bluefoxicy> (they're not for sale normally-- though I think they're not yet finished)
<sistpoty> bluefoxicy: magic is beyond my abilities ;)
<bluefoxicy> heh.  I wish i had money when they were running the pledge
<bluefoxicy> they were selling them, you could plegde $300 for a unit, and the other $200 bought 2 more for poor people
<bluefoxicy> which is a good deal
<bluefoxicy> there's an Ubuntu OLPC spec somewhere too, which I'd like to be able to test out; plus it'd be a cheap and easy to carry around internet/IRC connection, since it's got full wifi :D (hey I can't be all charity)
<neuralis> bluefoxicy: we were certainly *not* selling them.
<bluefoxicy> neuralis:  lemme see if I can dig it up.
<neuralis> bluefoxicy: the pledging was an unofficial pledgebank petition.
<jdub> neuralis: oh, ivan - never made the connection between you and your nick :)
<bluefoxicy> neuralis:  AH!  I didn't know it was unofficial, damn slashdot.
<Frederick> bddebian, but then I cant debug my files and there should be a package wich holds debug info =/
<bddebian> Frederick: Sure you can, you just need to build unstripped packages :-)
<bluefoxicy> neuralis:  I've actually considered the prospect of enhancing primary education in developed countries with the same technologies; we're certainly not going to hand out $1200 laptops to American children for first grade math
<neuralis> jdub: no worries, it just means my nick joins the ranks of kam ion, key buk, infi nity, mith randir, etc. spaces inserted to protect the innocent from their irc client beeping ;)
<bluefoxicy> But it looks like that angle isn't going to be aimed at either.
<Frederick> bddebian, apt is suspended =/
<neuralis> bluefoxicy: it is. we're not at all restricted to the third world, nor were we ever supposed to be. we're just starting there.
<bddebian> Frederick: Still?
<jdub> neuralis: ha ha ha
<Frederick> yep
<Frederick> why don't they simply block the package?
<bluefoxicy> neuralis:  ah cool.  Any plans to up the ante in the first world?
<neuralis> bluefoxicy: google 'romney olpc'
<sistpoty> bddebian: no linda issue on gaim-libnotify for me... :/
<sistpoty> oops wrong channel
<bddebian> sistpoty: Yeah, don't talk to me in here.. ;-P
<sistpoty> hehe
<bluefoxicy> $150-$300 per unit in the first world would supply a sizeable profit.. 37.9 million primary schoolers... divide by 5... about 7 million.. $350 million profits at $150 ... America would fetch enough to pay for 3,500000 units in the third world, per year
<bluefoxicy> (I am an EVIL economist)
<bluefoxicy> neuralis:  will do
<YokoZar> Is it a good idea to put lone virtual packages in the build depends, eg libcupsys-dev?
<bluefoxicy> Mitt Romney?
<sistpoty> YokoZar: unless lp can cope with it now: no, you should resolve it to a real package
<YokoZar> lp?
<sistpoty> YokoZar: launchpad (soyuz to be more specific)
<YokoZar> I was more worried about apt-get build-dep myself
<sistpoty> no idea about that really... but if you're talking about a package in the archive, it first needs to get through soyuz ;)
<infinity> YokoZar: You should always specify a preferred alternate.
<Burgundavia> mdz: do you mind if I mention https://wiki.ubuntu.com/Bug57153IncidentReport in UWN 14 (due out on Sat.)
<Burgundavia> mdz: if you want me to leave it out until next week, I will
<infinity> YokoZar: So, "Build-Depends: libcupsys2-dev | libcupsys-dev"
<YokoZar> infinity: yeah, thanks
<Frederick> is apt still blocked?
<sistpoty> quick question: should the libtool information (*.la) be shipped in a -dev package?
<sistpoty> (for reference: comments on http://revu.tauware.de/details.py?upid=3126)
<bddebian> sistpoty: Guess they are all asleep? :-)
<sistpoty> or busy ;)
<sistpoty> but I think your assumption is more likely 
<bddebian> Never count on anything from my dumb ass :-)
<sistpoty> :P
<SEJeff> I'm going to guess that the earlier incident prevented knot 3 from being released
<Frederick> SEJeff is apt back?
<LaserJock> there was an incident?
* LaserJock needs to pay attention more apparently
<SEJeff> https://wiki.ubuntu.com/Bug57153IncidentReport
<imbrandon> afaik that was august
<imbrandon> 21 22
<imbrandon> nothing much to do with knot 3
<SEJeff> imbrandon: Read the completion date
<SEJeff> Completion date: Friday, 15 September 2006
<LaserJock> I don't see the correlation, but ...
<LaserJock> I don't think it has anything to do with knot 3, but I could be utterly wrong :-)
<imbrandon> i still dont see how that has to do with knot 3 , and afaik its not delayed just not released
<SEJeff> BenC was working all morning on a new l-r-m and bumped up the kernel abi
<imbrandon> btw moins LaserJock ;)
<SEJeff> that was the fix that bug
<LaserJock> imbrandon: hola
<imbrandon> SEJeff, well i dont think that had alot to do with it either but i could be wrong, best case if your dieing to know is wait a few hours ( morning EU time ) and ask
<imbrandon> just my 0.2c
<SEJeff> imbrandon: I've got specto watching http://cdimage.ubuntu.com/releases/edgy/, it will tell me when. Thanks
<fabbione> morning guys
<Burgundavia> morning fabbione
<bddebian> Hello fabbione, Burgundavia
<jsgotangco> hello
<bddebian> Hi again jsgotangco :-)
* Starting logfile irclogs/ubuntu-devel.log
<desrt> ajmitch; ping
<lynn> hi - a quick question - during the install I filled in the blanks and after the reboot my user and pass aren't recognized........is the default for these?..........I installed ubuntu alternative 
<imbrandon> it should be what it asked you durring the install
<imbrandon> there is no way to recover or reset it that i know of
<imbrandon> check you caps lock etc
<imbrandon> and for future ref try #ubuntu this is the dev channel ;)
<lynn> tried all that .............:(
<ajmitch> desrt: yes?
<desrt> ajmitch; can you upload your updated libcm?
<ajmitch> sure, I'll dig it out sometime tonight
<desrt> ajmitch; update spiftacity too while you're at it, since it'll be able to build again with the new libcm :)
<desrt> you'll make a lot of people happy
<ajmitch> yeah, I was doing that at one point
<ajmitch> breaking metacity to produce a spiftacity package is a little more work, I had it done for 2.15.x
<ajmitch> & then dholbach & seb kept on updating metacity on me :)
<ajmitch> excellent, local conflicts in libcm checkout
* ajmitch fixes
<Burgundavia> mdz: https://wiki.ubuntu.com/EdgyEft/Knot3 any thoughts?
<desrt> Burgundavia; needs more beavers
<Burgundavia> desrt: umm.... ???
<desrt> Burgundavia; the arabic screenshot looks bad as it is
<desrt> Burgundavia; i'd either get rid of it or move it to the front
<desrt> Burgundavia; i don't realise that arabic is RTL and i look at the menubars of oo.o and gimp and say "oh.  blank spaces.  maybe they haven't finished the translating yet."
<desrt> Burgundavia; if it was on top you could see the text
<Fujitsu> desrt, that's what I initially thought.
<Fujitsu> Then I realised it was probably RTL.
<desrt> Burgundavia; also.  gimp is active in the russian screenshot but none of the others
<Burgundavia> oh, right
<Fujitsu> desrt, true.
<Fujitsu> Also: This screenshot shows this new feature/
<Burgundavia> given my gimp-foo sucks
<desrt> also - fix your links.. i wanna read about upstart :)
<Burgundavia> right
<desrt> also -- if knot3 is gonna release soon you should probably make sure a new openoffice upload has been completed :)
<desrt> but that's not really your job
<Burgundavia> no, it is not, thankfully
<desrt> well, bug someone :)
<Burgundavia> doko: ping
<Burgundavia> desrt: I just did
<desrt> 100% of the time crash-on-save in the office suite is a pretty big eyesore in a prerelease :)
<Burgundavia> desrt: actually, it is only crash when save-as, not save
<desrt> Burgundavia; well.. save new document -> save as
<Burgundavia> yes, like I said, any sort of save as
<Burgundavia> purely saving an existing document works
<desrt> i suspect it's actually any time the file chooser shows
<desrt> so it might happen on open too
<Burgundavia> OO.o so needs to die
<desrt> it's a shame that abiword sucks
<desrt> because i really really like abiword
<Burgundavia> so does FF, Gaim and GIMP
<infinity> Kamion: I suspect the update-alternatives breakage in usplash is because the .so shipped by usplash is no longer a registered alternative.  That seems to be a mistake.
<desrt> ooo -> abi
<desrt> ff -> ephy
<desrt> gaim -> gossip
<desrt> gimp -> ?!?!?
<infinity> Kamion: Oh, cause it doesn't ship one anymore...
<Burgundavia> fspot
<desrt> i'm afraid we'll have to disagree :)
<Burgundavia> desrt: you are right
<Burgundavia> the open dialog causes it crash as well
<infinity> Kamion: Doubly a mistake, I guess.
<infinity> Seveas: ?
<desrt> ok.  it is time for bed.
<desrt> Burgundavia; congrats on the so-far-so-good release notes.  have fun finishing them up.
<desrt> cheers.
<Burgundavia> I don't know why Mozilla doesn't consider Ephy to be the Camino of Linux
<infinity> Because it's crap?
<Fujitsu> +1 infinity.
<Burgundavia> infinity: Mozilla is crap as a platform? Mozilla is crap as a product? yes, I would agree
<infinity> No, epiphany is crap as a browser. :)
<Burgundavia> now there we have to disagree
<infinity> I use it daily along with firefox, and it irritates the piss out of me.
<Burgundavia> FF does that for me
<infinity> Makes sense. :)
<Burgundavia> well your sanity has clearly boiled away in the sun down under
<Fujitsu> Uh... Silly North Americans, with little/no sanity :P
* Fujitsu realises he's North American too....
<Burgundavia> Fujitsu: Pot, kettle...
<Fujitsu> Burgundavia: ?
<Burgundavia> anybody else notice how the new battery notifications cover up your desktop switcher?
<Burgundavia> Fujitsu: the pot calling the kettle black
<Fujitsu> Burgundavia, yes, I noticed that well over a month ago :P
<Fujitsu> Burgundavia, probably.
<Burgundavia> hmm, no Keybuk
<buzzen> update-grub now converts kopt=root=/dev/md0 into kopt=root=UUID=(uuid of filesystem). this does not seem to work on my raid device. how can I disable this ?
<buzzen> feels like a bug to me
<buzzen> (or untested with raid)
<fabbione> buzzen: known and fixed bug
<fabbione> the new mdadm that handles that is waiting knot-3 CD to be out to be unleashed in the archive
<fabbione> a fix exists and it's there..
<buzzen> ok thanks
* madduck wonders what mdadm has to do with filesystem labels.
<fabbione> buzzen: i assume that it won't be long (max 24 hours) before it will be there
<buzzen> if I remove the evms package, does it also disable all evms activation (also in initrd for example)
<buzzen> ?
<madduck> buzzen: yes
<fabbione> madduck: the problem is udev/md interaction. md doesn't kick udev hard enough to create /dev/disks/by-uuid/symlinks...
<fabbione> madduck: so the fixed package does just that
<buzzen> ok thanks.. ive had enough of evms... it also seems to take over mdadm configured arrays without permission at times
<fabbione> that's why UUID is not there with the old one
<madduck> fabbione: 2.5 works, btw.
<fabbione> 2.5 what?
<madduck> mdadm :)
<fabbione> well i could ask for a UVF exception...
<madduck> you don't want to do that at this stage, i think.
<buzzen> so new mdadm will also be in edgy soon 2.4.1 is rather old
<buzzen> ?
<madduck> too many changes between 2.4.1-6 and 2.5.3.gitXXX-4
<buzzen> 2.6.17 kernel + mdadm is more powerful than evms in some ways now.
<buzzen> with online reshaping..
<buzzen> i noticed that is disabled in ubuntu kernels..
<Mithrandir> sladen: that xorg space bar bug of yours is impressive.
<fabbione> buzzen: we are too close to release to import new versions from upstream. This one is known to work just fine.
<buzzen> referring to the 2.5.3 version? any 2.5.x is good enough
<buzzen> so thats ok
<buzzen> one thing thats bugging me. either im doing something wrong or. I created another raid device. and after a reboot, the new device (i called /dev/md1) has become /dev/md0 and my old one md1
<buzzen> i thought using a mdadm.conf locked it down
<buzzen> is the mdadm.conf being used by update-initramfs ?
<fabbione> buzzen: no that's related only to the order in which devices are discovered. there is no locking in that regard. 
<fabbione> it's a FIFO
<fabbione> the first raid that's discovered becomes md0
<fabbione> and so on
<buzzen> oh.
<fabbione> if your second raid is discovered first, it will be md0
<buzzen> I dont like the order though :-)
<jdub> fabbione: is the initramfs/uuid/md stuff sorted now?
<fabbione> jdub: i have the package in the unaccepted due to knot-3
<fabbione> but the fix is there and ready to be unleashed
<jdub> fabbione: rock!
<jdub> fabbione: i'll reboot my server as soon as the update goes thru :-)
<buzzen> fabbione: I guess I will have to live with it :-) So I shouldnt refer to them as /dev/md0 but using the UUID in the fstab for example ?
<fabbione> jdub: i did test it yesterday before publishing the fix
<fabbione> buzzen: that would be the best once the fix is in the archive yes..
<buzzen> fabbione: incase a change in teh kernel alters the order etc.
<fabbione> exactly
<fabbione> more than in the kernel, i would say in your device chain
<fabbione> but you get the idea
<buzzen> would be handy to lock them down by uuid though.like you can with network devices and mac addresses
<fabbione> i need to go offline for 20 minutes 
<fabbione> later
<fabbione> you can
<buzzen> how ?
<fabbione> it needs the fix that's waiting in the archive
<buzzen> aah ok :)
<fabbione> mount by UUID
<fabbione> that's the same thing that break root on raid at the moment
<fabbione> i really need to take off for 20
<fabbione> later
<buzzen> cheers.
<madduck> fabbione: i am curious as to why thoe problems exist on Ubuntu. do you deal with RAID on configurations that change?
<madduck> because otherwise, the order in which RAID arrays are assembled/detected is deterministic
<fabbione> madduck: no the order is not deterministic. 
<fabbione> the bug people are talking about is the mount of raid via UUID when it's mounted as /
<buzzen> fabbione: i remember reading about md driver getting support for saving raid resync progress so it can continue after a reboot. Don't suppose you know when this was added to the kernel ?
<fabbione> buzzen: i know it's there.. when it was introduced.. no idea
<fabbione> probably sometimes after .12
<buzzen> do you know if it works for old 0.90 superblocks or just the new formnat ?
<buzzen> i nice big changelog for the md driver would be nice. guess that doesnt exist in one place..
<fabbione> the format of the sb didn't change
<madduck> fabbione: hm. right, ubuntu uses mdrun, which makes it non-deterministic
<buzzen> fabbione: you have 0.90 sb and 1.0 sb which is more flexible/newer
<buzzen> it has less restrictions..
<buzzen> (supports more disks and more space for "expansion" etc)
<buzzen> but im not sure if there is "space" in the 0.90sb to sotre this resync "progress". certainly it doesnt seem to be on my system.. i didn't try with 1.0sb
<fabbione> buzzen: according to git the first patch to support partial resync did hit kernel last year in June
<fabbione> and still according to other git entries, the sb format is updated by the running kernel when possible
<fabbione> and when required
<fabbione> so basically an old version-0.90 is upgraded to 0.91 or 1 when needed
<buzzen> ive not heard that before. but some of the superblocks are stored in different places ?
<buzzen> how could it handle that..
<pitti> Good morning
<Burgundavia> Mithrandir: ping
<Burgundavia> pitti: morning
<fabbione> buzzen: i am only reading git commit logs
<fabbione> buzzen: not the code
<buzzen> fabbione: yup. thanks :)
<fabbione> and reading an old sb and write to the new format is not rocket-science...
<buzzen> fabbione: the kernel md driver and mdadm is not documented as well as it could be..
<buzzen> fabbione: i wondered perhaps if there was data on that portion of the disk for example. but ok.. i dont know the details really
<fabbione> buzzen: patches are welcome
<pitti> hey Burgundavia 
<fabbione> no, there is no data after the sb
<fabbione> the sb is located at the end of the device
<fabbione> and it allocates a big chunk of disk to store data
<buzzen> fabbione: sb 1.1 is located at the beginning.
<buzzen> or 1.2 i forget
<fabbione> and there is space for extensions
<buzzen> either  at  the end (for 1.0), at the start (for 1.1) or 4K from the start (for
<buzzen>                      1.2).
<fabbione> buzzen: nope.. the md superblock has always been in the same place since god created light
<buzzen> fabbione: then mdadm man is lying ?
<fabbione>  * If x is the real device size in bytes, we return an apparent size of:
<fabbione>  *
<fabbione>  *      y = (x & ~(MD_RESERVED_BYTES - 1)) - MD_RESERVED_BYTES
<fabbione>  *
<fabbione>  * and place the 4kB superblock at offset y.
<fabbione>  */
<fabbione> this is kernel code
<buzzen> see. you cant even trust the documentation then! :D
<fabbione> patches are welcome
<buzzen> :)
<buzzen> ill put thgat on my todo list
<Mithrandir> Burgundavia: hi
<Burgundavia> Mithrandir: http://www.ubuntu.com/testing/knot3 is up, but should I leave the "not yet released" on the page?
<Burgundavia> issue is, I am about to go to sleep and so you would need to find somebody else to edit it if you release Knot 3 in the next 8 hours
<Mithrandir> Burgundavia: yes, please leave the not yet released.
<Burgundavia> ok, will do
<Mithrandir> thanks
<Burgundavia> you will need to find Matthew Nuzum or Heno to get it removed at the right time
<Mithrandir> Burgundavia: yeah, shouldn't be a problem.
<pitti> hey seb128
<seb128> hi pitti
<seb128> how is knot-3 going? Current iso are good to play with?
<Mithrandir> doko_: around?
<Mithrandir> doko_: emacs has some functions where it passes a char * and a couple of extra parameters (which aren't in the parameter list of the called function), then try to access those extra parameters in the called function.  This used to work (in dapper), but doesn't in edgy; is there a command line switch to revert to the old behaviour?
<fabbione> Mithrandir: probably is the stack-protector that's causing the segfault?
<Mithrandir> hmm, possibly.
<fabbione> try to build without
<fabbione> but the code in emacs needs fixing.. no matter
<Mithrandir> sure, it needs fixing, but I won't do that now.
<fabbione> oh i don't care either.. i don't use emacs
<Mithrandir> I use it bloody all the time, but I prefer it not to crash when I close an unsaved buffer. :-P
<Mithrandir> hooray, livefs-es seem to build properly this time.  Let's just hope they're reasonably-sized.
<Mithrandir> mvo: what do you think of having apt-get grow a way of installing tasks?
<mvo> Mithrandir: nice idea, I'm not sure how easy/hard this would be
<Mithrandir> mvo: we had to cowboy livecd.sh to use aptitude rather than apt-get yesterday, but I'd actually be more comfortable with apt-get since it doesn't have this idea of "a partial solution is better than no solution" and similar, which is annoying when you want things to fail if they can't be accomplished.
<Mithrandir> such as when you're building livefs-es.
<mvo> Mithrandir: what was the problem with apt-get yesterday?
<Kamion> BenC: yes?
<Mithrandir> mvo: we had to switch to aptitude because of the recommends problem.  That is, we probably wouldn't have to, but we ended up doing it.
<Kamion> SEJeff: the stuff Ben was working on was unrelated to the incident report you referred to
<Kamion> SEJeff: and said incident report was unrelated to Knot 3. The reason Knot 3 is delayed was because of a live filesystem build problem discovered yesterday morning that took a while to rectify.
<Mithrandir> fabbione: yup, it's the stack protector.
<fabbione> Mithrandir: score
<Kamion> infinity: alternative> yeah, could well be ...
<mvo> Mithrandir: is the new apt recommends code buggy? is there a way for me to help debugging the problem?
<Mithrandir> mvo: no, it's fine now after the last upload you did.
<infinity> Kamion: Well, removing the last alternative (as would happen on a usplash upgrade) leaves a danling link, which forces manual mode.
<Mithrandir> (afaik)
<Kamion> infinity: right
<Kamion> mvo: we didn't realise that (a) a suitable new apt was already there and (b) the LP patch to add the metapackages section had been applied
<Kamion> otherwise I'd just have changed the overrides
<mvo> Kamion: aha, ok. sorry for this communication problem then :/
<Kamion> nah, our fault
<infinity> mvo: Anyhow, that particular series of events did bring Colin to wonder if *-live might be better off as a task instead of a metapackage, since it's only really used by the livecd build process.
<infinity> mvo: And updating ubuntu-meta just to mangle the livecds is a pain.
<Mithrandir> Kamion: did you get the ubiquity patch from Riddell uploaded last night?
<Kamion> Mithrandir: yeah
<infinity> mvo: But we'd prefer not to use aptitude, since it does sketchy things when it can't do what you ask it to, hence Tollef's request for apt to be able to install a task.
<Mithrandir> Kamion: thanks; I'll build kubuntu livefs-es too then
<Kamion> Mithrandir: ubiquity 1.1.18
<infinity> mvo: Alternately, I suppose, a new switch (aptitude --no-half-ass) to prevent it from trying half-assed solutions instead of just failing might be nice. :)
<mvo> infinity, Mithrandir: ok, I have a look at the code in apt now
<pitti> Mithrandir: are you satisfied with the alternate CDs, knot3-wise?
<infinity> mvo: I don't care which interface we use (apt or aptitude) as long as it can both install tasks, and fail completely and painfully when it can't do precisely what you asked it to.
<Mithrandir> infinity: it's probably harder to get that into aptitude due to the scoring engine.
<Mithrandir> pitti: I'm been dug in with desktop CD bugs, but I think I am happy with alternate, yes.  If the wiki would like to answer me this century, I could give you a definitive answer.
<pitti> Mithrandir: so, today will be live CD testing, as soon as they finally appear?
<seb128> is current desktop CD worth testing? or a new one will be rolled and better to wait for that one?
<zyga> morning everyone
<Mithrandir> pitti: from the reports on the wiki, it looks like alternate is ok.  I need a couple of amd64 tests, but apart from that I'm happy.
<Fujitsu> Morning, zyga.
<Mithrandir> pitti: yes, live cds are building now.
<pitti> seb128: ^
<pitti> cool
<Mithrandir> seb128: wait ten minutes or so
<seb128> ok
<Mithrandir> *sigh*
<Mithrandir> we're oversized.
<imbrandon> re
<Mithrandir> Kamion: we should be able to roll back to using apt-get, shouldn't we?
<Kamion> Mithrandir: yeah, if I make the metapackage section changes
<infinity> Kamion: Well, you have until the next publisher run (we can do a by-hand run around :30 or :35..)
<Mithrandir> hmm, -desktop for knot 2 didn't have evms, mdadm, etc.
<Mithrandir> nor did it have any of the python-* and random other bits.
<infinity> Err, when did mdadm get back in standard?
<Mithrandir> infinity: it's not?
<Mithrandir> it's in ship
<infinity> Answer: It didn't, but the Packages file thinks it did.
<infinity> Which means germinate thinks it is.
<infinity> Which means something's gone wrong.
<infinity> (base)adconrad@cthulhu:~/build/seeds/edgy/ubuntu$ apt-cache show mdadm | grep ^Task
<Mithrandir> indeed.
<infinity> Task: ubuntu-standard, kubuntu-standard, edubuntu-standard, xubuntu-standard
<infinity> Either germinate's on crack (checking now), or the germinate->archive updating mechanism exploded at some point.
<Kamion> infinity: I blame hppa
<infinity> Kamion: Drop hppa from everything, then.  Yesterday.
<infinity> Kagou: It's pretty obvious at this point that it won't release with edgy.
<infinity> s/Kagou/Kamion/
<Kamion> it's in a launchpad script :(
<Mithrandir> I'm not sure why hppa is to blame, but if you say so, I guess you're right.
<infinity> OTOH, germinate seems perfectly happy.
<infinity> So, yeah, it's LP that's confused.
<Kamion> Mithrandir: the ubuntu-standard metapackage on hppa still Depends: mdadm
<infinity> Kamion: Are Task overrides not arch-specific?
<Kamion> don't think so
<Mithrandir> Kamion: ah, and that confuses lp.  I see.
<infinity> That would be the issue then, yeah.
<infinity> Well, that'll go away for now if we switch back to apt.
<Kamion> they should be
<Kamion> ok, I'll chase that up with team soyuz
<infinity> Kamion: Can you get the overrides fixed ASAPish, and we can trigger a fresh publisher run?
<Kamion> ok, give me a few
<Kamion> just all the binaries from {,k,ed,x}ubuntu-meta, right?
<infinity> Kamion: Should do.
<Kamion> $ change-override.py -x metapackages ubuntu-{minimal,standard,desktop,live} {k,ed,x}ubuntu-{desktop,live} edubuntu-server
<Kamion> done
<Mithrandir> infinity: ok, and you'll do the necessary livecd.sh fixes?  You might need to clean up any stray locks or processes on the buildds. (sorry)
<infinity> Mithrandir: You're still building images currently?
<infinity> Oh, we're in queue/lock hell, right.
<Mithrandir> infinity: I just canceled them
<infinity> I can make that go away.
<Mithrandir> even as fun as it is to build livefs-es, I don't see the point in building ones which I know will be useless.
<Kamion> infinity: shall I kick off the publisher?
<infinity> Kamion: Whenever you'd like to, sure.
<infinity> I'm cleaning up buildds and such.
<pitti> ah, new images on cdimage
<pitti> Mithrandir: but it looks you are going to roll another one?
<infinity> We are.
<infinity> Those were oversized.
<pitti> ok, so I'll continue my thunderbird update fun for now before starting testing them
<Mithrandir> pitti: yes.
<Kamion> publisher running
<dholbach> hello!
* pitti hugs dholbach
<dholbach> hi pitti
* jdub hugs dholbach and pitti -> UBUNTU CIRCLE HUG!!!111
<pitti> hey hey jdub!
<Hobbsee> hey dholbach, pitti 
<Hobbsee> hey jdub 
<jdub> morning!
<pitti> moin Hobbsee 
<Fujitsu> Ji jdub.
<Fujitsu> Hi Hobbsee!
* dholbach hugs jdub back :)
<Hobbsee> hey Fujitsu 
<infinity> Argh.
<dholbach> hiya infinity
<Fujitsu> Yeah, hi infinity!
<infinity> Hey.
<jdub> Fujitsu: so, are you actually affiliated with Fujitsu?
<Fujitsu> jdub, er... no. Blame YukiCuss for my name >_>
<imbrandon> lol @ jdub
<GNOMEProject> this is kinda like jenny government
<Lathiat> haha
<wag> There we go.
<jdub> ha ha
<jdub> initial nicks are elite though
<jdub> but Fujitsu is a sweet nick
<dubg> I doubt it.
* imbrandon like his simple I'm Brandon
<jdub> imbrandon: see, that has always made me angry
<jdub> imbrandon: i guess i should admit it to you now
<imbrandon> jdub, heh why is that ?
<i> <- freenode doesn't allow apostrophes
<imbrandon> ahh yea no '
<pitti> jdub: ` should be ok, though
<jdub> nor domain names
<jdub> i notice you're imbrandon.com
<imbrandon> yup 
<imbrandon> for the last few years atleaste, before it was Eagle ( a.k.a WalkingEagle - too full of sh*t to fly , my full blood american indian wife would call me )
<imbrandon> ;)
<jdub> ha ha
<Fujitsu> I was originally wgrant... How imaginative :P
<jdub> it is kind of odd being in a relationship marked by cultural or ethnic differences
<jdub> for instance, pia and i
<jdub> i'm from sydney
<jdub> she's from yass
<Fujitsu> Then YukiCuss decided that he wouldn't have such a boring username on his server, so looked for one for me. He had a Fujitsu 10.4GB HDD next to him...
<jdub> it's very complicated
<Fujitsu> Hahah.
<Fujitsu> Yass...
<Fujitsu> That Triple J thing was good...
<imbrandon> yea heh jdub i feel ya there but it nice at times too , to see the "another side" of culture(s)
<imbrandon> (even though we're divorced now *grumble* but that a whole nother story)
<imbrandon> anyhow i'm wayyyy OT
<jdub> yes, drinking illegally brewed alcohol and shooting street signs has been thoroughly educational
<imbrandon> hahahahahahaha
<Hobbsee> lol
<Fujitsu> Lovely Yassians.
<jdub> imbrandon: (yass is just a country town - i'm totally taking the piss for the ubuntu-au people's benefit)
<imbrandon> ahh ;)
<jdub> Fujitsu: itym 'yassoise'
<Hobbsee> jdub: better from yass than from goodnight.
<Fujitsu> Hahahh.
<imbrandon> would be like the souther hick towns of america i am assuming from your comments ;)
<jdub> yeha, the jjj interview was good
<imbrandon> southern*
<Fujitsu> I didn't record the first minute :(
<jbailey> fabbione: Looking at the patch, are you sure that LIBDIR doesn't *also* need to be defined for some reason?
<jdub> imbrandon: it's actually an entirely reasonable place; just gets a lot of crap.
<imbrandon> ;)
* jdub tries to think of a US analogue
<Fujitsu> jbailey, that's on topic. That can't be allowed.
<jdub> well, it's not like noofies in canada
<fabbione> jbailey: this way works fine and tested. all packages get builded correctly
<jdub> because they're quite obviously a different species
<jbailey> Fujitsu: You'll notice it's midway through a conversation, and only because we left somewhere else where it would've been too close to being on topic. =)
<jbailey> fabbione: a'ight.
<\sh> guys, anyone running XOrg from edgy on t43 with [Radeon Mobility M300]  in xinerama mode? I see here a complete borked mouse cursor
<fabbione> jbailey:  i didn't want to spend more time in there.. i needed something working
<jbailey> fabbione: It's a localised sparc change.  If you want it this week, I recommend you upload it.  Otherwise it'll need to wait for next week when I'm near my gpg key.
<fabbione> it's already uploaded
<jbailey> Even better. =)
<jbailey> I haven't looked recently, but I think there's still a bug from Jim Meyering that I want to deal with, and some complaints about nscd not starting because of a missing /var/run directory.
<jbailey> So those are next week fun, too.
<jbailey> Whee!
<fabbione> there is also something else i want to look at
<fabbione> i think who did change libc-other.postinstall should be cross burned alive
<fabbione> the call to ldconfig vanished
<jbailey> Enjoy taking me up then.
<fabbione> so basically you install the optmized libs
<fabbione> and you don't use them by default
<fabbione> i fixed a similar bug in 2.3.6 but i am sure you did push it to debian
<jbailey> Doesn't the #DEBHELPER# token cause it to get added in again?
<fabbione> it's empty
<fabbione> fi
<fabbione> #DEBHELPER#
<fabbione> exit 0
<fabbione> fi
<fabbione> exit 0
<fabbione> so either you didn't call debhelper
<fabbione> or when it's called it's too early or something
<jbailey> Hm
<jbailey> fabbione: You don't happen to be bored and want to look into that, do you? =)
<infinity> Mithrandir: Kamion's publisher run is done, and the buildds are idle again, you should be good to go to spin livefses.
<fabbione> jbailey: once i get to finish with silo i will look at it
<\sh> I'm happy to see Mr. Linuxpriting in #ubuntu-devel :)
<\sh> printing even
<fabbione> jbailey: it might be for next week tho
<fabbione> this only affects a very specific corner case
<jbailey> fabbione: Sure.  Into next week, I can look at it too.
<fabbione> when you install the optmized lib alone
<fabbione> on normal installs or upgrade is fine
<fabbione> (due to the other 34098398439843 libs calling ldconfig)
<Mithrandir> infinity: thanks
<mvo> janimo: good news, a full xubuntu-desktop install upgrades cleanly from dapper->edgy 
<janimo> mvo: thanks, nice :)
<mvo> pitti: is there a way to enforce that new restricted-modules packages are available at the same time as updated kernels (for security upgrades)? or should this be handled in the tools (update-manager/unattended-upgrades)? we currently can end up with a system without X :(
<pitti> \sh: indeed, let's all hug tkamppeter  :)
<mvo> if for some reason the kernel/restricted-modules are not available in the same publisher run
<pitti> mvo: if we need a new l-r-m, there should be an ABI bump
<pitti> mvo: i. e. we only need to make sure to publish a new metapackage when kernel and lrm are in place
<pitti> mvo: yesterday's update was an unhappy exception, won't happen again
<pitti> mvo: but in general (like with mozilla-thunderbird and enigmal) we can't ensure that
<mvo> pitti: ok, well. if yesterday was a exception, then all is good. one of my machines ended up without X because it auto-upgraded itself at the wrong time.
<Riddell> Mithrandir: is the kubuntu livefs built?
<Mithrandir> Riddell: no, since we ended up grabbing too much due to a lp bug.
<Mithrandir> Riddell: I'll build them once I have the ubuntu ones ready (which is about now)
<Riddell> this knot release is cursed :)
<Mithrandir> Riddell: let's hope (k)not. :-P
<Mithrandir> Riddell: anyway, livefs-es building now.
<Riddell> thanks
<janimo> Mithrandir: after the others are done please build xubuntu as well, thanks
<Mithrandir> hooray, smaller images again.
<Mithrandir> please test ubuntu desktop 20060915.1
<seb128> ok
<Mithrandir> I'll go clean out the test grid
<Mithrandir> janimo: will do
* pitti rsyncs
<pitti> Mithrandir: but you'll leave alternate results, I presume?
* seb128 too
<pitti> imbrandon, Riddell: are you generally satisfied with the quality of ipodslave? what's your QA assessment?
<imbrandon> seems to work great here, i've been using it with my ipod regularly on edgy ( and SuSE shhh just for testing )
<imbrandon> seems solid
<Riddell> pitti: yes, and it's more sane than someone mounting an ipod and just seeing the raw ipod files
<Riddell> it's also the default in suse and elsewhere
<imbrandon> yea just about everywhere but debian/ubuntu
<pitti> Riddell: ok, that sounds good
<Mithrandir> pitti: naturally.
<pitti> imbrandon, Riddell: ok, approved
<imbrandon> pitti, thanks
<sivang> re
<Trewas> I was trying to file a bug for network-manager but launchpad.net is saying "NetworkManager does not use Malone as its bug tracker. To report a bug about NetworkManager, please use its official bug tracker.", maybe I am blind but I don't see any indication where that is or how that should be done... or does it simply mean that I should bug upstream directly?
<Kamion> Trewas: if your bug was found while using the Ubuntu package of network-manager, use https://launchpad.net/distros/ubuntu/+source/network-manager/+bugs
<giftnudel> Trewas: you need to first go to distro - ubuntu and look then for the package, not directly in launchpad.net
<Mithrandir> Riddell: kubuntu livefs-es done; doing .isos now.
<Trewas> Kamion, giftnudel: ok, thanks
<Mithrandir> Riddell: your livecds are served
<Riddell> great
<AlinuxOS> Riddell, hello, maybe you know about it, is Georgian supported in Edgy Eft Kubuntu edition ?
<Kamion> publisher's back on full auto
<Riddell> AlinuxOS: supported in which way?  we have language-pack-kde-ka packs, the ttf-bpg-georgian-fonts font isn't installed by default but it's brought in at install time if there's an internet connection with the language-support-ka package
<AlinuxOS> Riddell, the problem is that some users asked me that if they install theese packages, UI still remains english.
<Riddell> "Error: 'ka' is not a supported language or locale"  hmm
<Kamion> what's that from?
<Riddell> Kamion: installing language-support-ka
<pitti> Riddell: sounds like my bug then
<Kamion> hmm
<pitti> Riddell: do you have language-pack-{gnome-,}ka installed?
<Riddell> pitti: no, I have language-pack-kde-ka-base installed
<Riddell> pitti: ah, but that doesn't depend on language-pack-ka-base
<Kamion> you need language-pack-ka-base for the locale
<pitti> right
<pitti> Riddell: this will provide /var/lib/locales/supported.d/ka
<pitti> AlinuxOS: ^
<Kamion> why don't the support packages depend on language-pack-*-base?
<Kamion> I see they only Recommends: language-pack-*, so I assume there was a reason ...
<pitti> Kamion: the reason is that people usually want only one desktop translation, but more than one input support
<pitti> Kamion: i. e. I might want to write Russian and English text, but I still only want a German desktop
<AlinuxOS> Oh, so it's a Pitti's bug...Oi oi oi :D
<AlinuxOS> pitti, good morning.
<pitti> AlinuxOS: right now it's more like a design decision
<AlinuxOS> Riddell, Kamion GOOD morning.
<AlinuxOS> pitti, you've right
<AlinuxOS> what about Edgy Eft's daily packs?
<AlinuxOS> I've installed Edgy...to continue working on 2.16 and debian-installer translation.
<Mithrandir> mjg59: is there any way for something using usplash to tell usplash that displaying text is a bloody good idea?
<Mithrandir> mjg59: the no-text usplash makes checking the live cds kinda useless.
<mjg59> Mithrandir: seveas was talking about that
<mjg59> Mithrandir: Right now, no, but it's trivial to add
<mjg59> Just add an extra parameter to the text argument
<Mithrandir> mjg59: or add a TEXT ON / TEXT OFF command?
<mjg59> Or that
<mjg59> But I think explicitly setting the priority might be saner
<Mithrandir> I'm fine with either; let's visit that post-knot-3
<mjg59> Sure
<Seveas> wax on, wax off
<Kamion> pitti: ah
<AlinuxOS> mjg59, hello bro, is there some improvements for ttf-bpg-georgian-fonts ?I've upgraded to Edgy Eft now(for translation reasons).
<Fade> well... this kind of sucks.
<Fade> Hans Reiser's ex wife is missing and police have served a search warrant for their house.
<Fade> http://cbs5.com/topstories/local_story_256204954.html
<Fade> what a mess. :/
<HiddenWolf> Fade: #ubuntu-offtopic please
<mjg59> AlinuxOS: It depends on fontconfig. I'll deal with it once I have some time.
<infinity> Seveas: Was not shipping a default splash with usplash a conscious decision, or an "oops" when doing the package split?
<mjg59> infinity: The testcard theme is built in
<Seveas> infinity, conscious -- the default splash was removed by mjg59 even before the split
<infinity> Seveas: It seems to have messed up update-alternatives a bit to lose the default out from under it, and it's also a bit sketchy since usplash doesn't depend on anything that provides a splash (which means you can have it installed with no artwork, which kinda explodes)
<infinity> mjg59: Oh, read above, then. :)
<mjg59> Having no artwork shouldn't explode
<seb128> Mithrandir: is keyboard not matching the locale a known issue?
<mjg59> If the dlopen fails, it should just fall back to testcard
<mjg59> The update-alternatives thing is probably more fun
<infinity> mjg59: Removing the default leads to a dangling symlink which makes update-alternatives drop to manual mode.
<Mithrandir> seb128: as in, keyboard defaulting to US American rather than whatever is closest for your language?  Yes, or at least, I've seen it too
<Kamion> mjg59: the problem is that once the alternative is bust, installing usplash-theme-ubuntu doesn't set the alternative to the artwork you just installed
<infinity> mjg59: And when I was in that state, I just got a black startup, no testcard.
<mjg59> But I'm sort of lacking in time to figure out Debian weirdness...
<AlinuxOS> mjg59, I hope you fix it before Edgy Eft final realise...because version 0.2 of ttf-bpg-georgian-fonts is without fontconfig...and BPG_Chveulebrivi contains more design errors.(It's not proportional, and its simply ugly)
<Kamion> until you do 'update-alternatives --auto usplash-artwork.so'
<mjg59> AlinuxOS: Yes, I know
<Kamion> seb128: lots of keyboard configuration is a bit sketchy. File bugs on console-setup please
<infinity> mjg59: Of course, I have other issues I'll bug you about when I'm not pretending to have a weekend.  Stuff like "when usplash is working 'correctly', I get no working consoles" and such.
<seb128> Kamion: ok, will do, thank you
<mjg59> infinity: Hrngh.
<mjg59> infinity: What hardware, etc?
<mjg59> But yeah, feel free to leave until next week
<seb128> Kamion: I didn't open a bug on ubiquity for the timezone not being set since it happens on the liveCD itself, ubiquity looks wrong for that no?
<infinity> mjg59: Radeon X300, Thinkpad T43.
<infinity> mjg59: I just get black consoles.
<mjg59> infinity: Passing vga= ?
<infinity> mjg59: Yeah.
<infinity> mjg59: Known?
<mjg59> Don't do that
<Kamion> seb128: that would be casper, but I believe there's already a bug about that; we've never set the timezone on the live CD
<mjg59> I need to have it fall back to framebuffer mode if you're running a framebuffer
<infinity> mjg59: Not doing that upsets me more, so I guess I'll just boot without splash.
<seb128> Kamion: ok, thank you
<mjg59> But yeah, that's a known regression
<seb128> I'll get time-admin fixed to handle that correctly ;)
<mjg59> It's easily fixed with a bit of buildsystem love
* infinity nods.
<Kamion> seb128: there's a bug filed ...
<mjg59> Just need to open /dev/fb0, and if that succeeds use the BOGL functions rather than the svgalib ones
<infinity> mjg59: On the plus side, my machine's decided that both suspend and hibernate are wonderful things again.  So, congrats on that, even if you had nothing to do with it.
<Kamion> bug 58629, if you don't have it already
<Ubugtu> Malone bug 58629 in gnome-system-tools "time-admin crashes when selecting time-zone" [High,Confirmed]  http://launchpad.net/bugs/58629
<seb128> Kamion: I know, I was looking at why time-admin crash, and it crashes because there is no /etc/timezone
<Kamion> nod
<seb128> but I was not sure if having no /etc/timezone was also a CD bug
<Mithrandir> while I could reconfigure libc6, I think just creating the symlink as part of the cd build process might make sense.
<mjg59> infinity: The alternative is to figure out your vesa mode and then do vbetool vbemode set whatever
<mjg59> infinity: That should get you your framebuffers back
<mjg59> Hm. Actually, I could just hack that into usplash.
<mjg59> Then it'd only be radeonfb people who were upset...
<Seveas> radeonfb == fglrx?
<infinity> mjg59: I like the autodetect-framebuffer-then-use-bogl trick, personally.
<mjg59> Seveas: Nope
<mjg59> infinity: Yeah, it's the right solution
<infinity> mjg59: We still need bogl for the PPC stuff anyway, so it sounds keen.
<infinity> Seveas: No, it's a hideous fb driver for radeon cards that is faster than vesa but buggier than a tropical rainforest.
<mjg59> infinity: bogl is already used on ppc
<infinity> mjg59: Yeah, I know.  I just meant "it's not going away anytme soon because of PPC, so we may as well use it cleverly elsewhere too"
<mjg59> Oh, yeah
<infinity> I assume we'll use the bogl backend on hppa too, when I get around to getting a head on my hppa box.
* mjg59 sends more acpi patches to ben
<Hobbsee> mjg59: are you aware that your latest commit to xserver-xorg-input-synaptics is causing a fair few people grief?
<mjg59> infinity: Indeed
<mjg59> Hobbsee: Given that my latest commit was aaaaaaaaaaages ago, no
<Hobbsee> mjg59: the one about a week ago.
<mjg59> Hobbsee: No
<mjg59> Hobbsee: Nothing to do with me
<Hobbsee> mjg59: interesting.  -- Matthew Garrett <mjg59@srcf.ucam.org> Mon, 7 Aug 2006 22:55:42 +0100
<mjg59> Hobbsee: Aug != September
<Hobbsee> er, sorry.  s/week/month/
<Hobbsee> mjg59: hush.   i cant even tell what day of the week it is, adn i've only recently started to notice it :P
<mjg59> Hobbsee: "grief" is a poorly defined term
<mjg59> The absence of that patch makes it useless for anyone with ALPS hardware
<Hobbsee> mjg59: yeah, i had a more consise description yesterday.  bug 47971
<Ubugtu> Malone bug 47971 in xserver-xorg-input-synaptics "synaptics touch pad(laptop) clicks when i dont want it to" [Critical,Confirmed]  http://launchpad.net/bugs/47971
<Hobbsee> right
<mjg59> To the best of my knowledge, that patch should not affect anything with a real synaptics pad
<rodarvus> actually, synaptics seems to work quite bad on Edgy since the beginning
<rodarvus> I don't think its mjg59 at fault here
<mjg59> I haven't seen the bug here
<mjg59> If anyone can actually reproduce it and debug it, that would be nice
<Hobbsee> right, okay then.
<rodarvus> mjg59, synaptics is extremely sensitive in most (all?) laptops I tried here
<Hobbsee> mjg59: how does one go about debugging the mouse going crazy?
<rodarvus> up to a point of being unusable
<rodarvus> (I just disable it as I don't like synaptics anyway)
* Hobbsee ended up downgrading a version, which has fixed the problem.
<mjg59> Hobbsee: Look at the diff between the versions. Figure out what paths the code may follow.
<mjg59> As I said, I can't reproduce it - it seems happy on both synaptics and ALPS machines here
* pygi grabs Hobbsee 
<rodarvus> but again, its not mjg59 at fault (nor his patch)
<pygi> Hobbsee, you have  a sec? :)
<Hobbsee> pygi: sure
<rodarvus> it was like this when I uploaded a version of synaptics straight from upstream, without any ALPS support
<Hobbsee> mjg59: okay, cool.  i figured you'd be a first point of contact, as changelogs.u.c said you'd touched it last
<rodarvus> and to be sincere, I'm almost sure dapper had the same behavior
* Hobbsee had the opposite problem for part of dapper, to be honest.  fortunately, modifying xorg.conf fixed that.
<mjg59> Hobbsee: I'm willing to believe that there's a bug in the patch, especially if downgrading to the previous version fixes it
<Hobbsee> mjg59: right, yep
<mjg59> But as I said, I can't reproduce it, so it's hard for me to debug it
<Hobbsee> yeah, of course
<Hobbsee> that's reasonable
<infinity> Hobbsee: Give me your laptop to take to the devel summit.  I'll make someone debug it. :)
<Hobbsee> infinity: heh.  my laptop!
* Hobbsee hugs her laptop
<infinity> (Of course, that'd be a bit late for edgy..)
<Kamion> mjg59: is that radeonfb patch in the usplash bug list sane to apply, btw?
<mjg59> Kamion: Uh. Which one?
<infinity> Kamion: The one that patches the initramfs hook?
<Kamion> the one that goes "did you boot with video=radeon*? ok, load radeonfb"
<Kamion> yeah
<mjg59> Kamion: Not to usplash, no. framebuffer loading is done by initramfs-tools now
<infinity> Kamion: That would be a bit obsolete now for x86, but I guess it could DTRT on PPC...
<Kamion> bug 33819
<Ubugtu> Malone bug 33819 in usplash "add a way to use radeonfb instead of vesafb or vga16fb" [Wishlist,Unconfirmed]  http://launchpad.net/bugs/33819
<mjg59> Kamion: Other than that, yes, it's sane
<mjg59> Should probably be generalised in some way
<infinity> It *should* be generalised in the kernel.
<infinity> I'm offended that the framebuffer drivers don't all get along.
<Kamion> well, it's actually done by both, but yeah
<mjg59> infinity: The kernel doesn't do module loading
<mjg59> Kamion: Urgh, is it?
<mjg59> Kamion: Please feel free to rip it out of usplash, then :)
<Kamion> I assumed you'd deliberately left it in usplash to facilitate porting to Debian or something
<infinity> mjg59: Yes, but the 15 different ways to specify that you have a framebuffer and how you want it is kinda lame.
<mjg59> No, probably just incompetence
<infinity> mjg59: video=driver=modenumber would be much saner.
<mjg59> infinity: video=driver=resolution would be even better
<infinity> mjg59: Or whatever, yes.  I think atyfb supports that.
<Kamion> fair enough. consider it outripped
<mjg59> The problem is that the vesa stuff is handled by the bootloader, not the kernel
<mjg59> Well, possibly video.s, but still
<infinity> mjg59: Actually, it seems to parse "magicnumber" or "WxHxDxR"
<mjg59> infinity: for vesafb, I don't think it does
<infinity> mjg59: No, I was specifically referring to atyfb there.
<mjg59> Ah, right
<infinity> mjg59: Refer back to my "no two drivers do it the same" thing. :)
<mjg59> But you want a generalised solution :)
<Kamion> oh actually no, it's the /dev/tty* setup that's done by both
<mjg59> Which is difficult for vesafb and intelfb
<Kamion> why is /dev/tty* done by the framebuffer hook?
<infinity> Overzealous cutting and pasting?
<mjg59> Can't remember
<mjg59> Hm.
<mjg59> To be honest, I think we should enable suspend by default on edgy
<mjg59> It solves a couple of UI issues, and I think it'll work for enough people
<infinity> Hey, if it works for me, it must work for everyone.
<thom> heh
<Mithrandir> pitti: does the desktop ppc cd reboot for you if you press a key?
<pitti> Mithrandir: still at installation, will try once it finished
<Mithrandir> pitti: after the check is completed, naturally
<Mithrandir> when you get the black screen
<pitti> Mithrandir: ah, in 'check' mode?
<Mithrandir> yeah
<pitti> well, I *think* I tried pressing keys, but I'll check again to be 100% sure
<Mithrandir> thanks
<Mithrandir> it _should_ reboot, but I could have done something wrong
<pitti> it's setting the clock now, can't take long any more
<doko_> tkamppeter: do you know if somebody is upgrading to the new hplip version?
<Mithrandir> I got an emergency call from the blood donation place here and they needed people to come and give blood today, so I need to pop out for a bit.
<Mithrandir> if somebody could please test alternate amd64 and i386 desktop, that'd be lovely.
<Mithrandir> I'll be back in an hour or so
<roico> hi... does any1 know if the common customizations spec is going to be implemented by edgy?.. is there any work being done on it?...
<roico> hi... does any1 know if the common customizations spec is going to be implemented by edgy?.. is there any work being done on it?...
<dholbach> roico: the status and whiteboard of the space in the tracker should reflect that.
<roico> hmm. sorry for my bad english, but whats "tracker"?
<dholbach> roico: https://features.launchpad.net/distros/ubuntu/+spec/common-customizations
<roico> ok lol... it says: "no indication is given as to whether or not this work will be completed for the targeted release"... =\
<roico> and there is no whiteboard...
<Kamion> roico: so it probably won't be done for edgy
<Kamion> I seem to remember telling you this last time you asked, also
<Kamion> if you have further questions, you should probably ask the assignee
<_ion> < neuralis> jdub: no worries, it just means my nick joins the ranks of kam ion, key buk, infi nity, mith randir, etc. spaces inserted to protect the innocent from their irc client beeping ;)
<_ion> I admit: i'm guilty.
<pitti> heno, dholbach: for the record, I have at-spi running since yesterday without any problem
<heno> pitti: that's great! sort of ;-/
<dholbach> pitti: I can't get it to crash neither :-/
<pitti> dholbach, heno: is it reported to crash randomly, or on special events?
<heno> Anyone else here on #u-dev care to test AT-SPI? 
<heno> pitti: thanks to testing!
<Kamion> mvo: are you aware that "translations_mutliverse_20060915.tar.gz" is misspelled?
<dholbach> pitti: "apport shows a crash report" - my hypothesis is: it crashes on logout and apport shows on next login
<mvo> Kamion: *gar* no, please reject
* mvo goes and fixes his script
<pitti> dholbach: 'k, will try that once this tbird build condescends to finish
<Kamion> mvo: done
<dholbach> pitti: I'm not sure that's really case, but it would explain a bit
<heno> pitti: for me it seems to crash on startup and then at 4-5 random times during my day
<pitti> heno: however, I didn't enable any additional modules like magnifier and such; shall I?
<heno> usually when I start an application, try to print or something
<pitti> heno: well, if you can reproduce the crash, maybe you can debug it?
<heno> pitti: perhaps the screen reader (and turn the volume down for your sanity)
* pitti enables
<heno> pitti: I cannot reproduce it at will, nor seem to get a proper backtrace
<pitti> Mithrandir: ok, so after check I can type characters and 'enter' causes a line break, but it does not reboot
<pitti> heno: do you have debug symbols?
<heno> pitti: no, dholbach was talking about making a debug package
<heno> so I can try with that
* pitti tries restartgnome, maybe this already activates the screen reader
<pitti> hm, apparently not
<heno> pitti: did you restart since activating AT-SPI? (it needs a restart to actually activate)
<pitti> heno: yes, I activated at-spi itself already yesterday
<heno> I guess you see it in top
<heno> ok
<pitti> /usr/lib/at-spi/at-spi-registryd --oaf-activate-iid=OAFIID:Accessibility_Registry:1.0 --oaf-ior-fd=27
<AlinuxOS> pitti, re-hello is there something like deb http://people.ubuntu.com/~pitti/langpacks/daily/edgy-updates ./  ?
<dholbach> heno: it seems that it crashes on logout
<pitti> AlinuxOS: almost - s/-updates//
<heno> dholbach: you got a crash?
<dholbach> heno: seb128 just got one on logout (which one usually (without apport) does not notice) on #ubuntu-desktop
<pitti> AlinuxOS: it's dapper-updates, but just 'edgy'
<pitti> heno, dholbach: please NB that it is a SIGABRT, not a SEGV or so
<pitti> seb128: ^
<seb128> right
<pitti> so a grep -r abort might help
<seb128> grep on what?
<pitti> maybe it just does something unusual when it's SIGTERMed at logout
<pitti> seb128: 'abort.*\(' perhaps
<pitti> seb128: well, the trace should tell you where it abort()ed
<seb128> Program received signal SIGABRT, Aborted.
<seb128> [Switching to Thread 47096792983968 (LWP 31575)] 
<seb128> 0x00002ad59339347b in *__GI_raise () from /lib/libc.so.6
<seb128> (gdb) bt
<seb128> #0  0x00002ad59
<seb128> 
<seb128> that I know :p
<AlinuxOS> pitti, loool I've changed dapper to edgy..and it dosen't work :) There is Edgy support yet...right ?
<pitti> seb128: hm, the bt in #u-desktop doesn't look terribly useful
<seb128> pitti: let me read the backlog, dunno if you speak about apport or the crash itself 
<pitti> seb128: the crash itself
<seb128> pitti: <seb128> dholbach: the bt has no function from it, doing debug builds now
<pitti> ah
<seb128> still building :)
<pitti> seb128: this smells like something throws an unhandled exception the glib way
<seb128> right
<Kamion> mjg59: should /lib/libusplash.so.0 be given a SONAME? (lintian complains that it doesn't have one)
<tkamppeter> doko_, I have only made an UVF ER for HPLIP 1.6.7 (sent to pitti and mdz) but I did not get any answer yet.
<mjg59> Kamion: Oh, erm, yes.
<mjg59> Kamion: Right now we're making no ABI (or even API) guarantees - should I bump the SONAME every time, or just leave it at .0 and handle transitions by hand?
<mjg59> There's only one other package that uses it
<doko_> tkamppeter: where are the packages?
<seb128> dholbach, pitti: new backtrace:
<seb128> Program received signal SIGSEGV, Segmentation fault.
<seb128> [Switching to Thread 47008438825168 (LWP 28822)] 
<seb128> 0x00002ac0fe705102 in get_c_method (obj=0x556920, class_id=1, servant=0x7fffacf64020, method_offset=16, method_flags=0)
<seb128>     at poa.c:2562
<seb128> 2562            if (!obj ||
<seb128> (gdb) bt
<seb128> #0  0x00002ac0fe705102 in get_c_method (obj=0x556920, class_id=1, servant=0x7fffacf64020, method_offset=16, 
<seb128>     method_flags=0) at poa.c:2562
<seb128> #1  0x00002ac0fe7052ab in ORBit_c_stub_invoke (obj=0x556920, methods=0x2ac0fe5b1248, method_index=1, ret=0x0, args=0x0, 
<seb128>     ctx=0x0, ev=0x7fffacf640c0, class_id=1, method_offset=16, 
<seb128>     skel_impl=0x2ac0fe4a3210 <_ORBIT_skel_small_Bonobo_Unknown_unref>) at poa.c:2615
<seb128> #2  0x00002ac0fe4a4a48 in Bonobo_Unknown_unref () from /usr/lib/libbonobo-activation.so.4
<seb128> dwarf2_read_address: Corrupted DWARF expression.
<seb128> not really useful :/
<Kamion> mjg59: leave it at 0, I guess, although I can never remember what the rules are for SONAME 0
<seb128> what is that "Corrupted DWARF expression"?
* pitti has no idea
<dholbach> I read it somewhere else already and it was not the problem that time, but I have no idea either
<Kamion> mjg59: don't all of usplash-theme-ubuntu (ngh misnaming), kubuntu-artwork-usplash, xubuntu-artwork-usplash use it?
<pitti> seb128: that looks bogus anyway; if (!ptr) shouldn't crash
<tkamppeter> doko_, before anyone starts to package we should at first determine whether we have agreement to put them into Edgy, otherwise we could package directly HPLIP 1.6.9 after the Edgy deadline.
<pitti> seb128: however, the part after the || might be the interesting one
<seb128> right
<pitti> seb128: since obj != NULL, thus the || is evaluated
<tkamppeter> Debian packages are there, see bug 51573.
<Ubugtu> Malone bug 51573 in Baltix "Please update HPLIP to 1.6.7" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/51573
<seb128> pitti, dholbach: the abort one: http://paste.ubuntu-nl.org/23513
<doko_> tkamppeter: no, that's not the way it works. we'll have to make the package, and then see, if it works. before, there's no fact you can base a decision on.
<dholbach> seb128: I'm quite clueless on it
<seb128> dholbach: me too
<dholbach> I wonder what 'dead object' it refers too
<AlinuxOS> pitti, loool I've changed dapper to edgy..and it dosen't work :) There is Edgy support yet...right ?
<dholbach> i'm likely to believe upstream when they say "at-spi-registryd crashing is not the root cause" - but debugging orbit is no fun
<pitti> AlinuxOS: yes, there are edgy langpacks
<pitti> AlinuxOS: do you have language-pack-ka and language-pack-gnome-ka installed?
<seb128> dholbach: right
<dholbach> i'm out for lunch
<dholbach> i'll have another look later on
<Kamion> oh dear god
<dholbach> thanks a lot seb128 and pitti
<Kamion> I hope nobody's using hunglish on Ubuntu
<seb128> dholbach: np
<AlinuxOS> pitti, yes.
<AlinuxOS> #deb http://people.ubuntu.com/~pitti/langpacks/daily/edgy-updates ./ is it right repository ?
<AlinuxOS> I've changed dapper to edgy.
<pitti> heno: hm, screen reader is marked as 'not available' in gnopernicus
<pitti> heno: and now I have a big white rectangle in the upper left screen corner which doesn't do anything and does not go away; but no crash
<pitti> heno: (the rectangle might be a non-working magnifier)
<heno> pitti: yes, welcome to the world of Linux magnification :) 
<heno> That needs some serious love
<pitti> heno: (yup, killall magnifier killed it)
<heno> pitti: try running Orca instead of gnopernicus
<_ion> alinuxos: See http://people.ubuntu.com/~pitti/langpacks/daily/
<Mithrandir> pitti: *grumble*; ok.
<pitti> heno: oh, screen reader works now
<pitti> heno: my computer talks to me :)
<heno> ubuntu-desktop no longer depends on gnopernicus. Why does everyone still have it installed on Edgy?
<heno> pitti: :)
<seb128> because package are not automatically removed?
<heno> does something else pull it in?
<heno> seb128: right, ok
<pitti> heno: it's a fairly hacked up system without u-desktop; I'll reinstall it soon
* heno though they would be
<heno> I see
<pitti> ok, I'm going to do an amd64/alternate test install, since Mithrandir still needs that AFAIK
* heno goes to lunch
<Mithrandir> pitti: thanks.
<Mithrandir> Riddell: how is your kubuntu testing coming along?
<Mithrandir> janimo: you're getting desktop ISOs now, fyi.  Sorry it's taken a bit.
<Mithrandir> hmm, somebody have an idea what I should do about edubuntu?  I can't usefully test them here and ogra's not around.
<pygi> Mithrandir, what testing do you need?
<Mithrandir> pygi: https://wiki.ubuntu.com/Testing/Current is the procedure
<pitti> dholbach: so, the bt looks a bit like an unexpected closing of something at-spi communicates with and exchanges corba data
<pitti> dholbach: maybe if that program is killed first, at-spi falls over; if at-spi is killed first, it works
<pitti> unserialization bugs make little sense otherwise in that form
<pitti> dholbach: oh, hm, it's a serialization crash, not unserialization
<Riddell> Mithrandir: all six kubuntu CDs are good to go
<Mithrandir> Riddell: yay, goodie.
<Hobbsee> yay :)
<pitti> Mithrandir: can you please add your test results as well so that we see what's still missing?
<Riddell> Mithrandir: usplash is broken in various places and the accessibility settings don't seem to work but I'm happy for a Knot
<Mithrandir> pitti: I did that two minutes ago.
<pitti> oh, /me reloads
<Mithrandir> seb128: did you ever complete your desktop install?
<Mithrandir> Riddell: yeah, I need to start writing the release notes now.  Input, as always, welcome.
<Riddell> Mithrandir: https://wiki.kubuntu.org/EdgyEft/Knot3/Kubuntu for us
<Kamion> pitti: did you ever request a sync / do a merge of the new latex-ucs?
<pitti> Kamion: AFAIK I requested a sync
<Riddell> Mithrandir: but a big caveat to be patient on bootup because usplash might not work and upstart doesn't give any output would be essential :)
<seb128> Mithrandir: yep, just did an i386 install with custom partitionning, I was about to update the wiki, worked fine
<Kamion> pitti: ok, thanks
<pitti> Kamion: bug 59865
<Ubugtu> Malone bug 59865 in latex-ucs "[after knot3 freeze]  Please sync latex-ucs (main) from unstable (main)" [Untriaged,Confirmed]  http://launchpad.net/bugs/59865
<Mithrandir> seb128: ok, thanks.
<Kamion> righto, good
<Kamion> trying to blitz through stuff depending on console-data
<Kamion> system-config-kickstart's dependency is a bit hard to kill though
<seb128> Mithrandir: liveCD had non-azerty keymap while I picked french, mono is broken by that unionfs path issue and time-admin crash due to no /etc/timezone, out of that it worked fine
<Kamion> seb128: first problem known, I'm working on it
<Mithrandir> seb128: all should be fixed for beta, none are blockers for knot 3
<seb128> Kamion: ok, cool
<pitti> ok, CD burned, going offline for amd64/alternate test install
<seb128> Mithrandir: right
<Mithrandir> (and I want to call this a weekend soon)
<Mithrandir> janimo: your ISOs are served.
<janimo> Mithrandir: thanks
<Mithrandir> seb128: we're at GNOME 2.16 proper now, right?
<seb128> Mithrandir: correct
<Mithrandir> Riddell: do you have a single Kubuntu-specific knot-2-to-knot-3 change you want me to highlight in the announcement?
* Kamion reboots to see whether his system works without console-common or console-data
<Riddell> Mithrandir: Konversation 1.0 would be nice to point out, since they were good enough to schedule their release cycle around us
<seb128> CD testing, brb
<janimo> Mithrandir: for xubuntu the only change I can think of is the upgrade of the core Xfce apps to 4.4 RC1
<Mithrandir> janimo: ok, I'll include that
<Mithrandir> http://err.no/tmp/knot-3.txt ; corrections, etc welcome.
<Kamion> ... apparently so
<Mithrandir> janimo: we expect 4.4 release to happen for edgy, right?
<janimo> Mithrandir: yes. But we expected that for dapper as well so I am not 100% sure :)
<janimo> their original target was Dec 2005 :)
<Mithrandir> janimo: heh, ok
<Kamion> Mithrandir: worth mentioning the replacement of the console layer maybe?
<Mithrandir> Kamion: true, added.
<Mithrandir> janimo: for beta, you might want to have a page similar to  http://www.ubuntu.com/testing/knot3 or https://wiki.kubuntu.org/EdgyEft/Knot3/Kubuntu to link to.
<janimo> Mithrandir: ok
<Mithrandir> janimo: just a suggestion, it's obviously up to you.  :-)
<janimo> Mithrandir: I'll pass it on to some documentation/graphics people :)
<janimo> there was such a presentation for dapper IIRC so they may write one up nw as well
<janimo> iwj: how easy is setting the default firefox theme ( I just saw in the announcement that it's tangerine now)
<janimo> if it is reasonably easy to override it I'd like to set it to tango for xubuntu as that's what the rest of the desktop uses
<AlinuxOS> doko, ping
<AlinuxOS> doko, I've upgraded to Edgy, installed your repo, everything is ok... but I can't find openoffice.org-experimental package. Even openoffice.org-l10n-ka is not available.
<giftnudel> Mithrandir:  "The primary changes from Knot2 have finalising ...." <-  there is probably a "been" missing
<Mithrandir> giftnudel: point, fixed.
<giftnudel> rest sounds good to me
<Mithrandir> goodie.
<Mithrandir> I'll just wait for pitti to return and confirm amd64/alternate is good before publishing, then
<sladen> seb128: any idea how I tell gnome-something to stop wanking with the X keyboard settings?
<seb128> sladen: don't start gnome-settings-daemon
<seb128> sladen: maybe unset the gconf keys for /desktop/gnome/peripherals/keyboard/kbd/*
<seb128> /desktop/gnome/peripherals/keyboard/kbd/layouts and /desktop/gnome/peripherals/keyboard/kbd/options and maybe /desktop/gnome/peripherals/keyboard/kbd/model
<seb128> sladen: but if your issue happens on gdm that's not due to GNOME
<sladen> seb128: /doesn't/ happen on just X+xterm.  /doesn't/ happen on gdm.  /does/ happen with GNOME has started.  killing g-s-d does not revert it
<seb128> sladen: sure, killing g-s-d doesn't happen any different setting
<sladen> seb128: I'll try that
<seb128> s/happen/apply
<seb128> sladen: basically g-s-d does setxkbmap
<seb128> with the gconf options I pointed
<iwj> janimo: It's quite straightforward.  The theme package drops a *.js file in /etc/firefox/pref.
<iwj> janimo: If you want to change it for xubuntu only that's slightly more tricky.
<iwj> Because xubuntu installs the firefox-themes-ubuntu package, right ?
<Kamion> seb128: is bug 60516 yours or mine?
<Ubugtu> Malone bug 60516 in ubiquity "Time zone & locale should also affect Gnome time applet 12/24 preference" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/60516
<seb128> Kamion: the 12/24 informations comes from the locale, I would say it's a locales bug
<janimo> iwj: yes, I want it to change in a default install not by the user after install
<janimo> iwj:  currenly the firefox theme package is not part of xubuntu
<iwj> janimo: Right.  Perhaps we'll have to move the default theme setting from firefox-themes-ubuntu to some other package.
<iwj> janimo: But it's the one with the tango firefox theme so if you want that in ff you'll have to install it.
<janimo> iwj: will this involve the alternatives system?
<iwj> That doesn't seem like the right anser.
<iwj> s/ans/&w
<janimo> iwj: sure I wiull install it, it's just today that I noticed it is in main and in ubuntu
<iwj> I'm afraid I'm totally unfamiliar with the set of artwork etc. packages.
<janimo> iwj: I am glad, I don;t like alternatives in packaging :)
<iwj> But what we need is for the default theme setting for each distro to be in a package specific to that distro.
<janimo> iwj: what happens when both ubuntu-desktop and xubuntu-desktop are installed?
<iwj> So the theme setting for firefox should move out of firefox-themes-ubuntu into some other package which is only in ubuntu and not {x,k,ed}ubuntu.
<iwj> Well, you'd end up with one at random.  I don't know what order ff reads the files in /etc/firefox/pref.
<janimo> iwj: if firefox can start with whatever it finds first ok
<janimo> iwj: that's ok as long as ff does not expect a specific file name then
<iwj> Maybe it reads them in a predictable order (eg, based on filename) in which case you could control which one wins.
<iwj> Indeed, you can have as many files in there as you like.
<bddebian> Heya folks
<janimo> iwj: looks like this package installs a symlink called theme.js to theme-actual.js
<janimo> does ff look for theme.js?
<iwj> janimo: ff reads all files ending in .js.
<iwj> The reason for the symlink is so that the file is disabled when the package is deinstalled but not purged.
<janimo> ah, so since it sources all files even multiple settings of selectedSkin() are ok.
<pitti> ok, test installs worked as expected
<Mithrandir> pitti: yay, that means we can release.
* Mithrandir runs publish-release
<iwj> janimo: Yes, but if you put more than one file in there we don't know which one will get used.
<iwj> I haven't looked through the code to see what it does ...
<Nafallo> yay!'
<iwj> I wouldn't be surprised if it just processes them in readdir order.
<tseng> Mithrandir++
<janimo> iwj: so looks like I could just install thias package and drop in the same dir a file which has a higher priority (aftre figuring out the rules)
<janimo> that file can reside in xubnutu-default-settings so ne new packages need to be crated or ubuntu ones altered
<janimo> but this means that whenever xubuntu-settings is installed the tango theme takes precedence
<janimo> I hope the order is not affected by underlying filesystem or other things beyond our control
<Mithrandir> janimo: are you happy with your ISOs?  (as in, should I release them?)
<janimo> Mithrandir: just tested one in qemu, looks ok
<janimo> not much changed since sep11 when I installed the daily on my box
<janimo> so yes, please release
<Mithrandir> janimo: ok, willdo
<iwj> janimo: underlying filesystem> That's what I meant by readdir order.
<iwj> janimo: it would be better to avoid relying on this, also for the other reason you mention.  So instead the theme setting should be moved out of firefox-themes-ubuntu to another package but you should probably consult the artwork list to ask which package.
<janimo> iwj: ok, will do
* janimo guesses ubuntu-artwork but will ask
<iwj> janimo: Yes, that would be my guess but I think someone who actually knows should tell us :-).
<janimo> iwj: I talked to dholbach in ubuntu-desktop
<iwj> janimo: Aha.
<janimo> he agreed it can be moved to human-theme
<iwj> Right, sounds fine to me.
<dholbach> yeah, just go ahead - that's fine
<janimo> if the file name is to be kept across packages we'd need conflict/replaces
<janimo> could we not avoid that by calling them differently now
<dholbach> and probably depends
<janimo> like ubuntu-theme
<dholbach> so the prefs file is not installed without the .jar file
<janimo> since ff sources any .js it does not have to be afixed name
<janimo> dholbach: depends are fine
<dholbach>  cool
<iwj> You should move the theme.js-actual file to the new package with a Replaces.  The symlink should stay in the firefox-themes-ubuntu package.
<janimo> I just dont; like conflict/replaces :)
<iwj> That way the theme.js-actual file will be ignored when the theme isn't installed.
<janimo> dholbach: depends would mean human-them indirectly deps on firefox is that ok? (for epyphany lovers :) ?
<dholbach> oh man, really?
<Mithrandir> maswan: if you're around, could you do an extra mirroring run for knot 3?
<janimo> the theme package deps on ff
<dholbach> that makes no sense
<dholbach> we should drop that depends
* ..[topic/#ubuntu-devel:Mithrandir] : Ubuntu Development (not support, even with edgy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | 6.06.1 released
<dholbach> ROCK ON!
* ..[topic/#ubuntu-devel:Mithrandir] : Ubuntu Development (not support, even with edgy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | 6.06.1 released | Knot 3 released
* dholbach hugs Mithrandir!
<Mithrandir> :-)
<Mithrandir> yay us
<dholbach> janimo: we should drop that depends in f-t-u
<janimo> we could just recommend and check for the existence of /etc/firefox/prefs in the install scripts
<Mithrandir> once we have a couple of mirrors with the stuff, I'll send out the release announcement
<janimo> dholbach: I agree but this is no longer my decision to make
<dholbach> janimo: or recommends firefox
<rodarvus> hooray!
<janimo> I just want tango theme for xubuntu, not mucking too much with the insides of ubuntu-deskotp
<janimo> stepping on toes and all that
<Mithrandir> edgy is frozen until somebody who has a small duckie thaws it, though. :-P
<dholbach> janimo: just move it from depends to recommends - I'll write a mail to iwj, fschoep, you and me
<janimo> dholbach: so the current theme package should recommend firefox, and get the .js removed
<dholbach> yeah
<dholbach> that makes sense
<janimo> then human theme get that removed file and add a replaces
<janimo> ok
<dholbach> and a depends on the f-t-u
<janimo> right
* dholbach mails
<rodarvus> Mithrandir, http://cdimage.ubuntu.com/releases/edgy/knot-3/ is still empty, though?
<Keybuk> Mithrandir: should I release everything from unapproved ?
<dholbach> janimo: hum - what about people install f-t-u and expecting firefox to pick the theme up?
<Keybuk> Mithrandir: thawed (via malcc)
<imbrandon> Mithrandir, so no uploads to main quite yet ?
<imbrandon> err Keybuk ;)
<janimo> dholbach: they install those as a convenience (jsut as if they had downloaded them off the net)
<janimo> the decision of which is the default is a separate step
<dholbach> ok
<janimo> especially since that package has 3 themes
<maswan> Mithrandir: running
<janimo> dholbach: anyway we want to make sure this work in default x/ubuntu desktop installs, not when the user does manual installs/removals
<janimo> in the latter case the user knows better 
<dholbach> janimo: mailed
<janimo> dholbach: is f-t-u packaging maintained in bzr as well? it has a .bzr dir
<dholbach> might be that fschoep has it in bzr too
<janimo> he does accoring to a chlog entry
<dholbach> cool
<janimo> but I was not sure if it's a regular apt-get source or bzr upadte type package
<janimo> and still am not sure :)
<janimo> hmm this has a very unusual packaging system
<Mithrandir> Keybuk: yes, please.  And thanks.
<Mithrandir> rodarvus: it takes a little bit of time to sync 3x4x700MB, even over a fast connection. :-)
<rodarvus> :)
<imbrandon> Mithrandir, main un-thawed ? 
<Mithrandir> imbrandon: 17:19 < Keybuk> Mithrandir: thawed (via malcc)
<Mithrandir> imbrandon: so yes.
<imbrandon> kk
<imbrandon> makin sure ;)
<jono> mako, ping
<jono> bugger he isnt here
<dholbach> jono: according to his blog entry he's in Berlin at Wizards of OS
<jono> ahhh of course
<phanatic> jono: hi, is there any deadline for sponsorship requests for uds?
<jdub> jono: http://reverendted.wordpress.com/2006/09/15/opensuse-about-to-overtake-ubuntu-on-distrowatch-7-day-hpd-chart/
<jdub> ^ ha ha
<Keybuk> it's done it once before
<jdub> for some reason, i enjoy watching the novellians stewing over ubuntu.
<jono> phanatic, not at the moment
<jono> jdub, hehe
<phanatic> jono: so it's also unknown when they are gonna be announced?
<jono> phanatic, yeah, I am working on this now :)
<Frederick> Folks I apologize to ask it here but the chances someone used imagemagick here is much greater than in #ubuntu or #kubuntu foks anyone else here having problems to debug aplications wich use magick core and magick wand? I cant debug them on gdb nor ddd Ive tried https://wiki.ubuntu.com/Backtrace with no luck. It lacks the dbg package =/
<Keybuk> jdub: nothing wrong with novellians ;)
<Keybuk> Frederick: actually, the chances are somewhat less
<phanatic> jono: thanks :) i was just asking because of visa issues...
<jono> phanatic, sure, I will try and get an answer out over the next few days :)
<Frederick> Keybuk, why? :-/ Developers usually play around more with libs than ordinary users :P
<phanatic> jono: great :)
<Keybuk> Frederick: I don't think that's true at all.  users play around with things more than developers, who are too busy fixing things to play
<Frederick> oki...
<bddebian> Oh man Frederick is back again?? :-)
<Frederick> bddebian, yep helo and thanks for the help yesterday
<Kamion> infinity: could you investigate why all the console-data 2:1.0-2ubuntu3 binary uploads failed, please? it looks like either a soyuz bug or a buildd bug
<Kamion> oh, hmm, actually - may be a debian/rules bug
<Kamion> hand-rolled dpkg-distaddfile stuff for udebs, probably doesn't account for epochs
<HiddenWolf> How long has the knot been out? :)
<HiddenWolf> Ah. I'm a full hour late.
<bluefoxicy> HiddenWolf:  shush.  Just go play with it ;)
<HiddenWolf> bluefoxicy: I'm running it, I just wanted to be the first seeder to make my ISP suffer a bit. 
<HiddenWolf> bluefoxicy: Uploaded 55GB for knot 2, planning to top that. ;)
<bluefoxicy> ah, giving everyone a chance to try the knot
<bluefoxicy> dad wants me to clean my room today :/
<tkamppeter> I am trying to build a package of HPLIP 1.6.7 and get
<tkamppeter> error: linux/compiler.h: No such file or directory
<pitti> tkamppeter: so, it seems to be time to upload gutenprint \o/
<tkamppeter> How do I obtain this file (probably /usr/include/linux/compiler.h)?
<tkamppeter> Which BuildDependency is missing?
<tkamppeter> pitti? How does the upload work? Will you upload it? Or do I have to do so? And to where?
<zul> tkamppeter: its a bogus error you can just remove the line
<pitti> tkamppeter: you can't, I'll do it
<tkamppeter> zul, which line?
<zul> pitti: uploaded linux-source-2.6.10
<zul> pitti: er...2.6.12
<pitti> zul: to jackass, or to your computer?
<janimo> zul: are you planning libvirt and other userspace xen stuff or just kernel for edgy?
<imbrandon> Kamion, ping
<tkamppeter> For me it is somewhat strange, Mandriva has /usr/include/linux/compiler.h in glibc-devel, Ubuntu does not have the file at all.
<zul> pitti: jackass
<seb128> tkamppeter: linux-headers-2.6.17-7: /usr/src/linux-headers-2.6.17-7/include/linux/compiler.h
<zul> janimo: yeah i was looking into it this morning already have it downloaded
<pitti> zul: nice that it works again; oh, right, I got failed build logs for sparc and hppa
<zul> pitti: aie..
<pitti> tkamppeter: usually you should avoid depending on linux-headers; that smells fishy
<pitti> tkamppeter: gutenprint uploaded; happy bug closing!
<janimo> zul: nice. I saw those mentioned in the FC6 test3 announcement
<zul> janimo: ditto
<pitti> zul: thanks
<zul> pitti: can you forward me the sparc logs?
<pitti> zul: these arches fail for ages now; if you are interested, I send you the logs
<jordi> mvo: ping
<pitti> zul: sent
<zul> thanks...im just curisous
<imbrandon> eer i guess Kamion or Keybuk ping heh
<zul> pitti: sparc failed for breezy
<Keybuk> imbrandon: ?
<imbrandon> Keybuk, can you manualy promote libnjb please , pitti said poke you when i uploaded amarok that needed it , its been approved at https://wiki.ubuntu.com/MainInclusionReportLibnjb
<seb128> BenC, crimsun: could you have a look on https://launchpad.net/distros/ubuntu/+source/rhythmbox/+bug/60563 please (rhythmbox freeze after linux update on dapper) and let me know what could be useful for you to determine what change could have done that?
<Ubugtu> Malone bug 60563 in rhythmbox "freezes on startup, worked before update on 14/09/2006" [Untriaged,Needs info]  
<zul> janimo: im going to take a run at them this weekend, basically its on my todo list
<tkamppeter> seb128, this package I have installed, but HPLIP does not find compiler.h
<imbrandon> Keybuk, i just uploaded amarok_1.4.3-oubuntu4 that build-deps on it
<imbrandon> s/o/0/
<tkamppeter> pitti, thanks for the upload.
<pitti> tkamppeter: no problem, thanks for the merge
<pitti> tkamppeter: so, we'll also get a new hplip and also a new foomatic?
<janimo> Keybuk: when you have time can you look at python-cups and system-config-printer in NEW?
<tkamppeter> foomatic-db and foomatic-db-hpijs I will do next week.
<pitti> tkamppeter: next week I'll try and fix the last two known cups permission bugs
<pitti> tkamppeter: after we fixed them (log files and lpd backend) it should be pretty much transparent again
<tkamppeter> pitti, when you do that, do not forget to apply the patches which fix bug 59542.
<Ubugtu> Malone bug 59542 in cupsys "cupsd monopolizes CPU" [Unknown,Unknown]  http://launchpad.net/bugs/59542
<pitti> tkamppeter: no, I'll also pick up some fixes from Debian's svn head
<pitti> tkamppeter: (changed the bug to jump on me when I do bugfixing)
<buzzen> is anyone here who deals with raid / initramfs ?
<Keybuk> janimo: dude, they've been in there for a couple of days!  nag when they're been in new for a couple of _weeks_!
<BenC> seb128: Replied to bug report
<seb128> BenC: thank you
<janimo> Keybuk: ok. I thought that archive Fridays were exception or something :)
<Keybuk> Friday is Kamion's day
<janimo> besides for these I'd rather not wait weeks as they should go to main and on the xubun CD if all goes well
<janimo> ah right.
<jordi> Riddell: onboard has been imported in rosetta now
<tkamppeter> pitti, zul, how to proceed with HPLIP now?
<jdub> mjg59: i copied 13-855-resolution-set.sh to 13-915-resolution-set.sh and changed the binary names it references
<pitti> tkamppeter: merge from Debian?
<jdub> mjg59: and btw:
<jdub> $ find /etc/acpi/ | grep 855
<jdub> /etc/acpi/resume.d/13-855-resolution-set.sh
<jdub> /etc/acpi/resume.d/49-855-resolution-set.sh
<jdub> what's with both?
<pitti> tkamppeter: first you should check whether merges.ubuntu.com did something sensible
<tkamppeter> Yes, it is a merge from Debian, and I have checked merges.ubuntu.com. I have taken out patch 50 and 60, as there is no support page in the Toolbox any more, but this does not matter to our problem.
<mjg59> jdub: Nngh. 915resolution is supposed to have that script in it.
<tkamppeter> The BuildDependencies from Ubuntu were stricter, so I have taken these.
<mjg59> jdub: They're both there because it's not entirely clear when it needs to be done
<jdub> mjg59: ah.
<jdub> heh
<mjg59> jdub: So we do it both before and after POSTing, in case the POSTing requires the mode to be there
<tkamppeter> s/60/55/
<buzzen> how are you supposed to upgrade mdadm for example, when it's install script wants to do a /etc/init.d/mdadm stop - and when you boot from a raid array (which you cant just "stop)
<buzzen> ?
<buzzen> that seems broken
<jdub> mjg59: figure i better copy that one for 915 too, then
<tkamppeter> Patch 40 and 60 disappeared in the merge as they were accepted upstream according to the ChangeLog.
<mjg59> Sigh.
<mjg59> How can I figure out who did the merge?
<bddebian> mjg59: If it was a merge it should have the persons name in the changelog
<mjg59> No, it's just been synced
<mjg59> With all Ubuntu changes dropped
<bddebian> What package?
<mjg59> 915resolution
<pitti> mjg59: you can look for closed ubuntu-archive bugs against that package
<bddebian> aye, or look at who "modified" the upload
<ogra> knot3 released ? there is nothing on ubuntu-devel-announce
<Kamion> ogra: yeah, I think Tollef's just waiting for mirrors
<ogra> ah, k
<ogra> what did you do with edubuntu ? 
<Kamion> released it
<ogra> cool :)
<Kamion> we figured it probably wasn't *that* brittle considering how little was changed
<Kamion> if it breaks, well ... sorry :)
<ogra> i just found out that 80% of the known bugs are caused by a bashism ... :/
<ogra> i could have easily avoided it ...
<Kamion> mjg59: https://launchpad.net/distros/ubuntu/+source/915resolution -> "Steffen Joeris"
<ogra> but well, i'll upgrade the package and users can grab the upgrade ...
<mjg59> Kamion: That's the Debian maintainer
<Kamion> so it is
<Kamion> the most recent sync was an autosync
<mjg59> There were Ubuntu-specific changes in the old version
<Kamion> or maybe not
<Kamion> I'm so confused
<mjg59> Looks like there's only been one sync from Debian
* Kamion greps his bug folder
<LaserJock> mdz: got a minute?
<tkamppeter> pitti, any idea for HPLIP?
<Keybuk> rodarvus: a word ...
<elmo> is using /usr/lib/firmware/$(uname -r) an ubuntu specific thing?
<Kamion> should be /lib/firmware/ surely?
<Keybuk> elmo: we don't use /usr/lib/firmware/$(uname -r) ? :p
<Kamion> it's not Ubuntu-*specific* but I don't think it'll work everywhere
<elmo> err, yeah, s#/usr##
<elmo> Kamion: hmm, ok, just not sure where this vanilla kernel I built is looking for it's firmware, /lib/firmware/$(uname -r) isn't working
<elmo> and Debian seems to use unversioned /lib/firmware
<Keybuk> right
<Keybuk> /lib/firmware is "universal"
<Keybuk> and is the place documentation should tell users to put firmware
<Keybuk> /lib/firmware/$(uname -r) is a "popular" place for distributors to put per-kernel-image firmware
<Keybuk> we use both, with preference in that order
<elmo> ah, I see, thanks
<mjg59> jdub: Thanks for that, fixed
<tkamppeter> pitti, have a look at http://www.freestandards.org/~till/tmp/ubuntu/usbext.h, it is the io/hpiod/usbext.h file of HPLIP 1.6.7
<jdub> mjg59: you rock :)
<pitti> tkamppeter: idea about what? the kernel #include?
<zul> pitti: compiler.h is just an empty file in dapper and it doesnt exist in edgy so removing it from the header file should be fine
<pitti> tkamppeter: ^ so, small patch to remove the #include should work then :)
<tkamppeter> Thanks, zul, I will try it.
<Keybuk> /usr/lib/hotplug/firmware/$(uname -r) is a historical, and very silly, firmware location
<zul> tkamppeter: nop
<Keybuk> I stopped supporting that for edgy, iirc
* Kamion adds pid file locking to ubiquity. Why did I leave that so long?
<mdz> LaserJock: yes?
<dholbach> have a nice weekend
<simira> dholbach: you too. Hug your dog from me also :)
<dholbach> simira: I'll do that!
<rodarvus> Keybuk, yes?
<LaserJock> mdz: pm, if you didn't see it already
<mjg59> Kamion: I can't find any mention of 915resolution on ubuntu-bugs
* ogra had several kernel hardlocks with 2.6.17-7 today :(
<Keybuk> rodarvus: s'ok, contacted upstream directly
<tkamppeter> pitti, zul: Build of HPLIP has worked with this patch.
<Kamion> mjg59: me neither; I blame Mr. Scott James "Auto-Sync" Remnant
<Keybuk> blame me for?
<mjg59> Keybuk: 915resolution got synced, dropping Ubuntu changes
<Keybuk> mjg59: interesting
<Kamion> and the creator of the sync was "Ubuntu Archive Auto-Sync"
<Keybuk> that wouldn't have been caused by an auto-sync though
<Keybuk> it had XubuntuY in its version
<Keybuk> 2006-07-06 04:07:34 BST  	Published  	edgy   	Release  	universe  	x11  	0.5.2-4
<Keybuk> 2006-06-08 15:44:14 BST 	Removed 	edgy 	Release 	universe 	x11 	0.5-1ubuntu6
<Keybuk> somebody removed it from edgy
<mjg59> Any way of tracking who?
<Keybuk> oh, hmm, that may be LP's new way of saying superseded
<Keybuk> grr
<Kamion> isn't that "superseded *and* we've actually purged it from disk?"
<Kamion> er s/\?"/"?/ logical quoting damnit
<elmo> hmm, does request_firmware() work for compiled in drivers?
<Keybuk> elmo: should do
<Keybuk> Kamion: ya know, I've no idea why this got sync'd
<Keybuk> the auto-sync always refuses to do XubuntuY
<Keybuk> if I forced them, they'd show up as "keybuk"
<Kamion> somebody didn't use -b auto -f?
<Kamion> er -b katie -f
<Kamion> whatever the launchpad user id is
<Keybuk> wouldn't have been me
<Kamion> whoever it was it's probably lost in expired .bash_history
<Kamion> mjg59: upshot is, we have no clue. sorry.
<Keybuk> yeah, and long lost from wtmp
<Keybuk> it won't have been a sync-request either
<Keybuk> the fact that the remove and publish are _so_far_ apart is very suspicious
<Keybuk> that really really really suggests to me that it was removed from edgy
<Keybuk> and the sync copied it as a new source
<Keybuk> it's not in removals.txt though
<Keybuk> oh, interesting
<Keybuk> it utterly FTFBS in edgy
<Keybuk> maybe someone removed the source by accident
<Keybuk> when they were trying to remove a bad binary
* Keybuk looks at infinity 
<Kamion> archive-cruft-check or something?
<Kamion> because that's the only thing that doesn't log
<Keybuk> yeah, could be that
<Kamion> and that would have removed a *ton* of stuff, probably
<Keybuk> 15:44 BST ... far too early for me to have been up :p
<Kamion> and in fact it would never have removed source
<Kamion> so it wasn't that
<Kamion> remove-package.py plus vi removals.txt? ;-)
<Keybuk> 06-08 was very very early in edgy?
<Kamion> that was definitely when you were driving all syncs
<Keybuk> no, I wasn't driving syncs until quite a bit after that
<mjg59> Keybuk: Seems to build fine here
<Kamion> I didn't start touching them until after Paris
<Keybuk> 08 was the day we managed to get edgy open!
<mjg59> It'd be nice to know what happened so I can check that nothing else has been hit, but...
<Kamion> don't remember doing removals that early in the cycle
<Keybuk> no, that was still toolchain churn
<Keybuk> I literally mean that was the day we added edgy to launchpad
<Kamion> it only FTBFS on non-x86 arches
<Kamion> which is fair enough, really
<mjg59> It should only be built for i386 and amd64
<Keybuk> Kamion: there's no non-x86 build record at all
<Keybuk> I reckon that this somehow ended up in the build queue when edgy was opened
<Kamion> Keybuk: sure there is, see https://launchpad.net/distros/ubuntu/+source/915resolution/0.5.2-4
<Keybuk> before there was a stable toolchain
<Kamion> https://launchpad.net/+builds/+build/222706
<Keybuk> Kamion: no, I mean the one that was removed
<Keybuk> https://launchpad.net/distros/ubuntu/+source/915resolution/0.5-1ubuntu6
<Keybuk> there's no build record for x86
<Kamion> oh, I see
<Kamion> we probably automatically retried everything that FTBFS in edgy as soon as edgy opened
<Keybuk> so yeah, I reckon this ended up in the build queue when edgy was opened by accident or by soyuz bug, it didn't get built on three and never even got a build record on the rest
<Kamion> no, it's deliberate
<Keybuk> and somebody tried to remove it and hide the evidence
<Keybuk> no, we didn't
<Kamion> as soon as there's a new distrorelease there, it retries everything from the last one
<Keybuk> we waited until we built the toolchain :)
<Keybuk> this is before we had a toolchain judging by -changes
<Kamion> *we* didn't, but soyuz didn't know that ...
<Keybuk> ahh
<Kamion> nobody told it to stop building stuff :)
<Keybuk> so yeah, looks like someone accidentally removed a source when they were trying to just remove the binaries, or something
<Kamion> we just stopped all source from going through
<Kamion> mm, seems probable
<Keybuk> this is all guessing, of course
<mjg59> It'd be nice if there was an audit trail for this stuff
<Keybuk> and then a month later, when I was doing auto-syncs, the new version came in
<Keybuk> mjg59: there is, kinda
<mjg59> Keybuk: Well, not in this case :)
<Keybuk> the trouble is the answer to "who did that" is always lp_archive
<Kamion> we only know this much because there is an audit trail - it's just incomplete
<Kamion> relevantly - what Keybuk said
<mjg59> Right
<Kamion> it's pretty bogus that we have to sudo to lp_archive to do anything, really
<Kamion> but it'll all be fixed once it's all done through the launchpad web UI, I guess
<mjg59> Wouldn't the sudo stuff be logged?
<Keybuk> there's nothing in removals.txt from 31st May to 21st Jun
<Kamion> mjg59: we generally sudo -i
<Keybuk> which about fits with the "opening edgy" delay
<Kamion> so not usefully
<Keybuk> mjg59: we don't have logs of that far back :-/
<mjg59> Kamion: Right, but you'd... ah, never mind
<Keybuk> anyway, given the timings, I would say it was the combination of human and computer error during the edgy opening
<mjg59> Yeah
<mjg59> It's unfortunate that it took jdub bitching about something I was sure I'd fixed to notice it, though...
<jdub> :(
<jdub> <- not a bitch
<zul> lol
<bddebian> heh
<rizo> is knot3 different from yesterday's daily iso?
<elmo> Keybuk: (btw, fyi, request_firmware doesn't work when you're totally modularless - apparently it might if you introduce initramfs, but otherwise the drivers run reuqest_firmware too early)
<Kamion> rizo: it'll be the same as the current daily images
<Keybuk> elmo: well, duh :p
<tkamppeter> pitti, I am currently uploading the new HPLIP packages to http://www.freestandards.org/~till/tmp/ubuntu/edgy/hplip/
<tkamppeter> and the binaries to http://www.freestandards.org/~till/tmp/ubuntu/edgy/hplip/binary/
* elmo thwaps keybuk
<tkamppeter> pitti, but I have still a problem: On my system is the old hpijs-ppds and hpijs installed, when I do "sudo dpkg -i hpijs*.deb" to update both to the new package, I get an error because the new hpijs-ppds conflicts with the old one.
<tkamppeter> Usually a new package should simply replace the old one.
<Kamion> if you move files from one package to another, you must include a suitable Replaces header
<Kamion> generally it's versioned, Replaces: package-the-files-came-from (<< first-version-of-that-package-that-doesn't-contain-the-files)
<tkamppeter> pitti (or someone else), can you look into the control file, whether there is something wrong? I have uploaded it to http://www.freestandards.org/~till/tmp/ubuntu/edgy/hplip/control
<Kamion> tkamppeter: what exactly is the error message emitted by dpkg?
<tkamppeter> till@laptoptill:~/ubuntu/hplip$ sudo dpkg -i hpijs*.deb
<tkamppeter> Password:
<tkamppeter> dpkg: regarding hpijs_2.6.7+1.6.7-2ubuntu1_i386.deb containing hpijs:
<tkamppeter>  hpijs conflicts with hpijs-ppds (<< 2.6.7)
<tkamppeter>   hpijs-ppds (version 2.1.10+0.9.11-2ubuntu7) is installed.
<tkamppeter> dpkg: error processing hpijs_2.6.7+1.6.7-2ubuntu1_i386.deb (--install):
<tkamppeter>  conflicting packages - not installing hpijs
<tkamppeter> dpkg: regarding hpijs-ppds_2.6.7+1.6.7-2ubuntu1_all.deb containing hpijs-ppds:
<tkamppeter>  hpijs conflicts with hpijs-ppds (>= 2.1.10.1)
<tkamppeter>   hpijs-ppds (version 2.6.7+1.6.7-2ubuntu1) is to be installed.
<tkamppeter> dpkg: error processing hpijs-ppds_2.6.7+1.6.7-2ubuntu1_all.deb (--install):
<tkamppeter>  conflicting packages - not installing hpijs-ppds
<tkamppeter> Errors were encountered while processing:
<tkamppeter>  hpijs_2.6.7+1.6.7-2ubuntu1_i386.deb
<tkamppeter>  hpijs-ppds_2.6.7+1.6.7-2ubuntu1_all.deb
<tkamppeter> till@laptoptill:~/ubuntu/hplip$
<Kamion> oh dear god, what are those Conflicts about
<tkamppeter> There should be a way to update both at a time.
<Kamion> tkamppeter: you can probably resolve that by using dpkg's --auto-deconfigure option
<Kamion> apt should manage to resolve it too
<Keybuk> elmo: module-less kernels cause sterility
<tkamppeter> Kamion, --auto-deconfigure gives the same errors.
<tkamppeter> Kamion, who can I install packages in local files with apt?
<Kamion> no, wait
<Kamion> don't flail around just yet :)
<Kamion> iwj could confirm, but I think it might be best to change hpijs's Conflicts to Breaks.
<tkamppeter> "apt-get install" does not find packages in the local working directory.
<Kamion> no, it won't.
<Kamion> if dpkg -i --auto-deconfigure can't manage it, then the problem should be fixed, not worked around by using apt
<tkamppeter> What is the difference between Conflicts and Breaks? Why does it work on Debian?
<Kamion> at present, the relationships declared by those packages are such that hpijs must be removed during upgrades to a new upstream version.
<Kamion> or possibly hpijs-ppds - one of the two
<Kamion> this "works" with apt (and therefore you probably haven't noticed the problems on Debian) because it will just remove one of them temporarily
<Kamion> however, this causes a lot of problems, such as inadvertent removal of metapackages and future upgrade problems
<Kamion> Conflicts means that the two packages cannot exist on the system *at all* (even just unpacked) at the same time
<Kamion> Breaks means that the two packages can't both be simultaneously in the "configured" state
<Kamion> therefore, Breaks would allow --auto-deconfigure to work in this case; dpkg would be able to temporarily deconfigure one of the packages, install the other, and then install the new version of the deconfigured package
<Kamion> (and configure it)
<Kamion> Breaks is a recent innovation (it was designed nearly a decade ago, but only recently implemented by iwj), so you probably won't find it in Debian
<Kamion> tkamppeter: but, as I say, consult with iwj; he's currently in charge of Breaks deployment
<tkamppeter> Kamion, yes, that's it! I have put "Breaks:" now and I can update with "--auto-deconfigure". Thank you very much.
<Kamion> good
<tkamppeter> Kamion, pitti, zul: Uploading all packages to the place I already mentioned, overwriting my previous packages.
<tkamppeter> Kamion, pitti, zul: The source packages and the control file are ready on http://www.freestandards.org/~till/tmp/ubuntu/edgy/hplip/
<tkamppeter> So ready for everyone to test and for final upload afterwards.
<tkamppeter> And for quick testing on 32-bit PCs, here are the binaries: http://www.freestandards.org/~till/tmp/ubuntu/edgy/hplip/binary/
<iwj> Kamion: The effect of Breaks nowadays is to defer upgrade of the breaking package until the broken one is upgraded so that it won't be broken.
<iwj> OIC.
* iwj reads more scrool.
<Kamion> the relevant relationship field was:
<Kamion> Package: hpijs
<Kamion> Conflicts: hplip-ppds (<< ${Source-Version}), hpijs-ppds (<< ${hpijs:Upstream-Version}), hpijs-ppds (>= ${hpijs:Upstream-Version}.1)
<iwj> tkamppeter: Yes, that should be Breaks.
<iwj> It's also quite crazy.
<iwj> I mean, WTF ?
<Kamion> I don't understand why it isn't just a Depends, but I never did understand the maze of twisty printing packages
<Kamion> presumably it's in some sense optional, but ...
<Kamion> iwj: thus the problem was that one of them *has* to be deconfigured when upgrading to a new upstream version, even with Breaks
<Kamion> since installed-hpijs Breaks: new-hpijs-ppds and new-hpijs Breaks: installed-hpijs-ppds
<iwj> Yes.  It's very strange that this isn't a Depends.
<tkamppeter> So then all is OK now, If no one sees any problem when running the new HPLIP we can upload my version to to Edgy.
<iwj> But certainly Conflicts is wrong.
<iwj> Did you change it to Breaks ?
<Kamion> mvo: do you have any idea what happened to your GST_NO_INSTALL_NTP patch? it appears to have disappeared from gnome-system-tools
<tkamppeter> Yes, my uploaded packages have it changed to Breaks.
<Kamion> mvo: there's some argument that the exact form of that patch should be changed anyway (see bug 52718) but it needs to be reinstated first :)
<Ubugtu> Malone bug 52718 in ubiquity "Unable to activate NTP support in the installer because it's not installed (?!)" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/52718
<mvo> Kamion: no, I guess it was a merge mistake of some sort, let me have a look
<iwj> tkamppeter: Excellent.
<mvo> Kamion: let me check the changelogs
<Kamion> I've reassigned 52718 to gnome-system-tools, if you want to subscribe to it
<mvo> Kamion: done, thanks
<iwj> I'm really going to quit for the weekend now and have some dinner.  Have a good time, everyone.
<zul> later iwj
<jdong> bye, iwj... thanks for new firefox packages :)
<KhanReaper> Hi, I saw something in a debian/rules file, and it confused me. Can someone tell me why clean calls "-$(MAKE) clean," specifically why $(MAKE) is prefixed with a "-"?
<mvo> Kamion: eh, am I missing something? in dapper we apparently have 2.14.0-0ubuntu11 and that one seems to include the GST_NO_INSTALL_NTP patch
<mvo> Kamion: or is the bugreport about edgy? 
<Kamion> mvo: the bug report is probably about dapper, where he's saying that the problem is that the rest of the NTP UI is still visible even though the "Install NTP support" button is disabled
<Kamion> mvo: I'm talking about edgy, though
<ogra> urgh
* ogra just discovered that the VideoRam parameter isnt preseedable in our new xorg packages anymore
<Kamion> KhanReaper: "-" in a Makefile means "ignore errors from this command". It's often used in clean rules because you don't care if the Makefile happens to have been removed already or something like that.
<ogra> was that dropped intentional ?
<ogra> rodarvus, ?? ^^^
<rodarvus> ogra, no, nothing intentional happened there
<rodarvus> ogra, is this causing you (or someone else) any problem?
<ogra> yep
<mvo> Kamion: aha, ok
<ogra> we're just trying to boot a ltsp 170 terminal from disklessworkstations.com ... it needs a forced videoram oarameter of 16384 
<ogra> *parameter
<ogra> but due to the missing preseedability i cant set it
<rodarvus> ogra, I would say its probably something inherited from debian when upgrading xorg from 7.0 to 7.0.22
<ogra> yep
<ogra> i know we had that parameter in the postinst, its not there anymore in the current package
<jdong> tseng: now that mono-xsp works, is our monodevelop being built with asp.net designer support?
<tseng> jdong: not that I know of
<jdong> tseng: any reason why we don't?
<tseng> xsp is priority 423456 for any one currently on the mono team
<tseng> if you care for it debdiffs are much appreciated
<jdong> tseng: I noticed a new mono-xsp upload to match 1.1.17, though
<tseng> yes to make it installable
<jdong> tseng: all it takes to build monodevelop against it is --enable-asp.net-designer or something like that in ./configure
<tseng> we try not to completely neglect it
<tseng> as in, leave it uninstallable
<tseng> we cant confirm bugs, or things like, hey, this xsp-monodevelop thing is legit
<tseng> I doubt just passing the configure flag is sufficient
<tseng> I don't want installing monodevelop to pull down xsp2 to everyone
<tseng> it needs split packaging, auditing on every release that it doesnt  have new, renamed, removed filed
<jdong> I see
<jdong> that's true, forgot about split-out packages
<tseng> keeping in mind that none of us want to touch xsp with a 10-foot pole
<jdong> hehe, monodevelop 0.12 doesn't compile from source :)
<tseng> we have a cvs snapshot
<jdong> tseng: slomo just uploaded a 0.12 this morning
<tseng> cool
<jdong> and apparently it doesn't build :)
<jdong> hehe
<tseng> Addin.cs(280,23): error CS0102: The type `VersionControlPlugin.BaseView' already contains a definition for `StockIconId'
<tseng> you are a C# guy, bet thats an easy fix
<neuralis> jdub: around?
<mjg59> Seveas: usplash appears horribly broken at 640x480
<Seveas> mjg59, -25 fixes that
<Seveas> none of the default themes have a 640x480 version
<jordi> muh
<jordi> pitti's gone
<mjg59> Seveas: Ahhhh
<mjg59> Seveas: They really should, since that's what's going to be used for first boot
<Seveas> mjg59, I'll tell the artwork people
<mjg59> Uh. Or does usplash default to 1024x768 if there's no arguments?
<Seveas> no, 640x480
<mjg59> Ok, cool
<Seveas> but it didn't check whether the theme was suitable for it
<Seveas> so it tried to use the 800x600 one for 640x480
<mjg59> The livecd is going to start usplash before there's any X config done
<mjg59> Seveas: Hm. No, if I run usplash on its own, I get a high-res image
<mjg59> If I do usplash -x 640 -y 480, I get a "No theme found" error
<Seveas> right, sorry, with no -x and -y, it'll pick the first theme and use its resolution
<mjg59> Seveas: Right. It needs to default to 640x480.
<Seveas> but livecds should have an /etc/usplash.conf, n'est-ce pas?
<mjg59> Seveas: How?
<sladen> mjg59: I think it'd quite safe to assume 800x600x8.  Microsoft have mandated it for logo requirements since 1999
<Seveas> I don't know the details of th buildprocess, but aren't the postinst scripts run?
<mjg59> sladen: We still run on older hardware
<Seveas> usplash' postinst will write it
<mjg59> Seveas: Yeah, but I thought they defaulted to blank
<mjg59> Oh, no, ok
<mjg59> You're right
<Seveas> I *thought* 640x480, but will check to make sure
<mjg59> Yeah, they're the default values
<sladen> mjg59: we don't.  Our kernel won't boot with less than 64MB of RAM...
<mjg59> sladen: There are laptops that are expandable past that but which have worse screens
<Seveas> mjg59, I just doublechecked, it defaults to 640x480
<mjg59> Seveas: Yeah
<mjg59> Sorry, my error
<ogra> crimsun, ping ? 
<mdz> mjg59: hmm, in fact we should add an explicit removal of usplash.conf to the live CD build process, otherwise it'll reflect the X configuration on the DC server
<mdz> or else regenerate it from casper
<mjg59> mdz: I think kamion's already dealt with that
<mdz> mjg59: which way?
<jdong> Kamion: can you push libtorrent7* through dapper-backports NEW?
<jdong> or is soyuz still being mean to me :)
<mjg59> mdz: Regenerating it after install
<Kamion> mdz: I made ubiquity do rm -f /target/etc/usplash.conf; chroot /target dpkg-reconfigure usplash
<Kamion> (effectively)
<Kamion> haven't uploaded that yet though, it's still in bzr
<Kamion> jdong: soyuz still doesn't like backports, afaik
<Kamion> sladen: perhaps it's changed recently, but I tested the dapper installer all the way through with 32MB
<jdong> heh, wonderfull.... any idea when that'll be resolved?
<jdong> I'm sitting here waiting, and it doesn't look like there's been any work towards it
<Kamion> jdong: dunno, but it's critical/in-progress
<jdong> Kamion: yeah, and it has sat there silently in that stage for weeks now
<Kamion> it's just awaiting a merge I think
<Kamion> LP merge timescales are often quite long unfortunately
<Kamion> since they involve review
<jdong> :-/
<Kamion> mdz: any chance you could chase up the flow of bug 58144 into production?
<Ubugtu> Malone bug 58144 in soyuz "Backport is rejected if an older backport is already there" [Critical,In progress]  http://launchpad.net/bugs/58144
<Kamion> mdz: I haven't had a chance to get a consensus on the "central issue" referred to by cprov, but that is not necessary to get the immediate fix into production
<kagou> iwj, still have problem with fontconfig-config. "dpkg-reconfigure --default-priority" make a 30-debconf-yes-bitmaps"
<kenne> anyone know when the libjingle and farsight libraries will be in edgy
<mdz> Kamion,mjg59: regenerating it after install is good but orthogonal; I"m talking about th econfiguration used during the livecd boot
<mjg59> mdz: The default file contains 640x480
<mdz> mjg59: oh, i thought it magicked it based on the xorg config
<mjg59> Yes, but in the livecd case there won't have been an xorg config for it to have magiced it from
<mjg59> So it'll fall back to the defaults
<mdz> Kamion: re: backports, will do
<Kamion> mdz: thanks
<mdz> mjg59: oh?  I would expect usplash and xorg to be installed in the same batch
<Kamion> usplash doesn't depend on xserver-xorg
<mdz> Kamion: yeah, but they're both part of desktop
<Kamion> so it's not guaranteed to be installed first
<Kamion> er, second
<mdz> xorg may or may not be configured first
<Kamion> it usually won't
<mjg59> mdz: usplash will be started some time before xorg is configured, surely?
<Kamion> usplash's dependencies are simpler so apt/dpkg tend to get to them first
<mdz> mjg59: it gets configured twice, once on the buildds and then reconfigured at boot
<mjg59> mdz: Right, but it's run out of the initramfs
<Kamion> mdz: at boot, usplash is started before xorg is reconfigured
<mdz> correct
<mdz> thus, it's using the config supplied by the buildd
<Kamion> right ...
<mjg59> Right. Which will be 640x480.
<mdz> which happens to be 640x480, but we should probably make it explicit
<elmo> mjg59: what makes you think that, JOOI?
<elmo> these things have KVMs attached
<mjg59> elmo: Hm.
<mdz> elmo: because usplash tends to be configured before xorg is, and xorg defaults to 640x480 I think
<Kamion> right, just what I was typing
<mdz> luck really
<Kamion> although actually not quite
<Kamion> if xorg hasn't been configured yet, then usplash explicitly says "ok, I'll use 640x480 then"
<mjg59> The ordering should possibly be enforced, but other than that things seem to work as designed
<Kamion> but same difference
<elmo> ok, if that's the reason.  but if you were expecting it because they're buildds in a DC, I just wanted to point out that they do actually all have a "monitor" and don't run in 640x480
<Kamion> mjg59: we don't want to enforce that ordering
<Kamion> at least not under normal circumstances
<Kamion> mjg59: because in d-i, we want to arrange for precisely the reverse ordering - xserver-xorg then usplash
<mjg59> Kamion: Yeah
<Kamion> I'm working on that
<Kamion> I'm going to do that by adding xserver-xorg to the list of packages installed up-front in tasksel's desktop.preinst
<Kamion> getting decent progress output out of that requires a bit of fiddling, so it's not a one-line fix, but I understand the problem
<Kamion> anyway, yeah, possibly casper should blat in a 640x480 configuration
<Kamion> I'd rather that sort of thing be done in casper than in the live CD build, personally
<mdz> I sent an email about this
<Kamion> actually, further to that, maybe it shouldn't force 640x480 either
<Kamion> on my powerbook's panel, for instance, it should just use the native resolution
<Kamion> i.e. don't change modes at all
<mjg59> Kamion: Right, the alternative is to fail to pass any parameters
<mjg59> If usplash.conf doesn't exist
<Kamion> yeah. what does the SVGA backend do with that?
<mjg59> Uses 640x480
<mjg59> Which currently breaks due to the lack of 640x480 artwork, but still
<Kamion> ok, ideal, since BOGL uses whatever the current mode is
<Kamion> yeah, that's clearly an artwork bug
<mjg59> The usplash init script just needs modifying to deal with that case
<mjg59> Or set them both to 0
<Kamion> I'll do that now
<Kamion> just rming it seems simpler
<mjg59> Yeah, the init script doesn't currently deal with that case
<mdz> mjg59: which defaults were changed in acpi-support and what were they changed to?
<Kamion> mjg59: what's the reason for the sleep 1 at the end of the usplash initramfs script?
<mjg59> Kamion: Erm.
<mjg59> Kamion: No idea at all. Feel free to kill it.
<mjg59> mdz: Sleep and DPMS
<mjg59> DPMS was disabled for hibernation, sleep was enabled globally.
<ogra> roddarvus, ping 
<ogra> hrm ... gone ...
<mjg59> uswsusp works surprisingly nicely
<mjg59> I think we can default to it in edgy+1
<mjg59> Graphical suspend/resume feedback, and faster than the standard kernel stuff
<Kamion> I'll commit the usplash initramfs fixes, just need to cope with one-second ping times to my ISP. gn.
* mjg59 repeatedly hibernates and resumes in order to see the pretty
<Kamion> mjg59: did you upload 0.4-26? it's not UNRELEASED, but I don't see it in -changes
<mdz> mjg59: baby jesus prefers more informative changelog entries ;-)
<mjg59> Kamion: Pretty sure I did...
<mjg59> mdz: Sure
<mjg59> Kamion: But possible that I didn't
<madduck> buzzen: this is a bug Ubuntu should fix before the release. please file a bug in launchpad and ask them to disable the stop call in preinst.
<mjg59> Let me check
<madduck> buzzen: they can check how i did it in mdadm 2.5 in debian
<Kamion> I don't see it on drescher anywhere
<Kamion> mjg59: if you didn't, can I sneak my change into it? :)
* Kamion -> away for half an hour or so
<Lure> mjg59: how do you enable hibernate with s2disk? just install uswsusp package?
<mjg59> Kamion: Looks like I didn't, so feel free
<mjg59> Lure: Correct
<mjg59> You'll need to wait for 0.2.1, which won't get build until the new usplash gets uploaded
<Lure> mjg59: ok, will do 
#ubuntu-devel 2006-09-16
<jdub> neuralis: pong
<HiddenWolf> mjg59: ping
<mjg59> HiddenWolf: Hi
<HiddenWolf> mjg59: I'm unsure if my bug is valid, seems my usplash.conf was set to 1680x1680, upgrade issue. Wondering if I should close it.
<mjg59> HiddenWolf: Which bug was that?
<HiddenWolf> https://launchpad.net/distros/ubuntu/+source/usplash/+bug/59651
<Ubugtu> Malone bug 59651 in usplash "usplash does not come up after dapper-edgy upgrade" [Untriaged,Unconfirmed]  
<mjg59> HiddenWolf: Hm. The fact that you had that in usplash.conf is still a bug
<mjg59> What resolution is your screen?
<HiddenWolf> mjg59: 1920x1200 under X.
<mjg59> HiddenWolf: And what do you have in usplash.conf now?
<HiddenWolf> mjg59: manually edited to 1280x900. Will reboot in a sec to see, Seveas says it should fix things.
<mjg59> HiddenWolf: It ought to be set to your X config
<HiddenWolf> Name: xserver-xorg/config/display/modes
<HiddenWolf> Template: xserver-xorg/config/display/modes
<HiddenWolf> Value: 1680x1680, 1600x1200, 1280x1024, 1152x864, 1024x768, 800x600, 720x400, 640x480
<HiddenWolf> I guess that's it
<HiddenWolf> I've edited xorg.conf to only include 1920x1200 24bit.
<Seveas> (HiddenWolf, I never said it would fix it, but it just might)
<HiddenWolf> Seveas: call me an optimist.
<HiddenWolf> I'll reboot, check, be right back
<HiddenWolf> Right, that was not it.
<HiddenWolf> I'd rather not have it end up being another vague bug for eternity. :)
<buzzen> madduck: found a bug already on launchpad. added my comments. Would be nicer to ahve a newer mdadm for edgy too
<Kamion> mjg59: we should be using /etc/X11/xorg.conf, not xserver-xorg/config/display/modes; I have a partial patch for that but had to shelve it due to being stymied by a kernel bug
<Kamion> parsing xorg.conf from the postinst is pretty nasty but possible
<mjg59> Kamion: Ok
<Kamion> but relying on the debconf database there is wrong, IMHO
<LaserJock> Kamion: do you think you'd have time to take a look at edubuntu-menus in NEW?
<ogra> damn, the xorg via drive is broken in edgy :/
<ogra> *driver
<ogra> this thin client works with a dapper ltsp chroot ... but braks with edgy 
<ogra> *breaks
<buzzen> madduck: another serious problem I have is if I have /dev/md0 as root (raid 1 - /dev/hda1 /dev/hdb1) and i remove a /dev/hda1 and reboot. then plug the disk back in and reboot, i get errors within "initramfs" mdaadm: failed to add /dev/hdb1 to /dev/md0: Invalid argument. 
<ogra> hmm, looks like its the same issue as bug 57329
<Ubugtu> Malone bug 57329 in xorg-server "upgrade to latest xorg has stopped my CLE266 from working" [Medium,Fix released]  http://launchpad.net/bugs/57329
<buzzen> madduck: this problem is caused from mdadm via mdrun 
<Kamion> LaserJock: deleting the shipped groups on prerm upgrade seems wrong
<Kamion> that'll cause problelms
<Kamion> problems
<LaserJock> Kamion: hmm, so would it be better to leave them? I wondered that myself
<Kamion> LaserJock: on upgrade, I think you should leave them, although you'll have to work out what to do if you ever remove/rename groups
<Kamion> LaserJock: speaking of which, I'm concerned that the group names are rather generic
<Kamion> "basic" for instance"
<LaserJock> mhm
<Kamion> could those be namespaced maybe? edubuntu-basic?
<LaserJock> could we use some sort of prefix?
<LaserJock> yeah
<ogra> sounds cool
<LaserJock> because I would like to seperate them out because they have a specific purpose
<Kamion> another thing I'm a little concerned about is chgrp/chmoding files that are shipped in the .deb
<LaserJock> k
<Kamion> dpkg-statoverride might be better for that, although it's really meant for administrator use so maybe not
<Kamion> why mode 640?
<LaserJock> because the menu works via group ownership of the .menu files
<Kamion> oh, it tests readability?
<LaserJock> yeah, so you only see .menu files that are readable by you
<Kamion> oh, hmm, from the looks of things it can't be anything else
<LaserJock> the first implementation I worked on was much more complicated
<Kamion> well, you should probably ship them mode 640 and override the lintian warnings
<LaserJock> ok
<Kamion> dpkg-statoverride would at least mean that logins during an upgrade wouldn't get groups they weren't supposed to
<Kamion> at present you have a window between unpack and configure where everything will be set back to world-readable
<Kamion> or, if you ship them mode 640 in the .deb, where nobody will be able to read any of the groups
<Kamion> since dpkg honours statoverrides internally, you can use that to override the menu file group without that window
<Kamion> I'd like the group names and the prerm upgrade issue to be sorted out before I accept the package, since those have upgrade implications
<Kamion> the rest can be handled more at your leisure, I think
<Kamion> sorry for taking a while to look at this
<LaserJock> yes, that makes sens
<LaserJock> thanks for the review :-)
<Kamion> oh, also:
<Kamion> lp_archive@drescher:/tmp/cjwatson/queue/edubuntu-menus-0.1$ head -n2 debian/postinst | tail -n-1
<Kamion> # postinst script for willowng
<Kamion> lp_archive@drescher:/tmp/cjwatson/queue/edubuntu-menus-0.1$ head -n2 debian/prerm | tail -n-1
<Kamion> # postrm script for willowng
<LaserJock> ah darn ;-)
<LaserJock> Kamion: ok, so do I need to bump the version or anything on the next upload? or does the reject clean the slate?
<Kamion> LaserJock: the latter, although a version bump may be helpful for your own records
<LaserJock> yeah, thanks so much
<Kamion> if you do bump the version, please use dpkg-buildpackage's -v option to include all the changelog entries in the .changes file
<LaserJock> ok, good idea
<ogra> mdz, i stole the initramfs-tools code from debians 0.73 ... but i apparently missed the second (copy_exec) part of it i'll look into it tonight from the hotel or tmorrw (they are wrapping up here)
* jdong draws Circles on the floor and sprinkles salt....
* jdong puts 5 Candles in circle and draws lines....
<buzzen> i saw this on blue peter
<jdong> hmm, guess it doesn't work for me :-(
<jdong> BenC: ping
<buzzen> don't forget to use the fairy liquid bottle
<BenC> jdong: pong
<buzzen> yeh, what's that pong!
<jdong> BenC: hibernate has regressed on my laptop in edgy since the 2nd kernel
<jdong> by that I mean 2.6.17-7
<BenC> jdong: Please try the next kernel that I am upload this weekend, which should fix it
<jdong> BenC: cool
<BenC> *uploading
<jdong> [17179755.084000]  suspend_device(): usb_generic_suspend+0x0/0x130 [usbcore] () returns -16
<jdong> [17179755.084000]  Could not suspend device 5-8: error -16
<jdong> [17179755.084000]  Some devices failed to suspend
* jdong marvels at his new summoning technique.....
* jdong puts it as an xchat script
<jdong> http://www.linux-watch.com/news/NS8278035161.html
<jdong> HA!
<jdong> IT IS THE HANS REISER
<jdong> and you guys thought I was nuts!
<lifeless> of course it is
<lifeless> the very first news report mentioned his job
<jdong> lifeless: not the first one I found
<jdong> from news.cbs5.com....
<jdong> that one just said "software programmer"
<lifeless> yeah that one, they updated it
<jdong> oh, :)
<lifeless> shortly after, added a big rebuttable from him
<lifeless> about some guy drugging and doing BDSM to his wife
<lifeless> anyhow, #offtopic
<jdong> man, what would it be like married to hans reiser.....
<jdong> hmm
<buzzen> fabbione: i've installed the new mdadm etc but the system still will not boot with UUID in grub. if i change it to /dev/md0 the system will boot
<lifeless> jdong: fwiw: http://cbs5.com/topstories/local_story_256204954.html
<jdong> lifeless: thx, that article definitely got longer :P
<bddebian> Howdy folks
<micahcowan> Is there a reason why the automerge argument to apt-get isn't documented, either in --help or in the manpage? https://launchpad.net/distros/ubuntu/+source/bash/+bug/60666 is a request to add the option to autocomplete, but I don't want to confirm it if there's a /reason/ it's not documented...
<Ubugtu> Malone bug 60666 in bash "New option in bash could use updated completion" [Untriaged,Unconfirmed]  
<fabbione> buzzen: did you update your initramfs?
<bod> elmo: about?
<bod> my rsync login to syncproxy seems to be broken
* imbrandon yawns 
<imbrandon> moins all
<Burgundavia> bugger, no keybuk
<Burgundavia> mdz: are you still awake?
<gardengnome> hi there :) i hope this is the right channel. i'd like to build a mythtv distro based on ubuntu. it would be cool if i could create my own seeds to make sure i only get the packages i need. i've alreasy found germinate and i'm wondering if it will also download all needed packages or if i'll have to have a local ubuntu mirror in order to create a CD image.
<Mithrandir> gardengnome: you need to have a local mirror.
<Mithrandir> (and you want it too, you're going to rebuild images quite a few times)
<gardengnome> ok, looks like debmirror will get to use some bandwidth then. :) i'm also wondering how i'd make the Cd image itself. i've found references to a version of debian-cd patched by the ubuntu team. should i use that or is there some nifty tool i haven't found yet?
<Mithrandir> we're using debian-cd
<gardengnome> thanks a lot! this is going to be fun :)
<Mithrandir> while some of the CD people might be around during weekends, weekdays are usually better.
<Mithrandir> jfyi. :-)
<gardengnome> Mithrandir: thanks. but i don't want to annoy you guys too much so i'll try to find out as much as possible on my own
<Mithrandir> gardengnome: as long as the person asking questions have tried to research on his own first and asks sensible questions, they're not annoying.
<UbuntuFan> Will Ubuntu take over Microsoft Windows
<UbuntuFan> ?
<UbuntuFan> hi
<imbrandon> UbuntuFan, this is the development channel, not for that type of disscussion, i'm sure someone would be more than happy to talk with you about it in #ubuntu
<imbrandon> or even #ubuntu-offtopic
<UbuntuFan> Rock on =)
<UbuntuFan> I hate a development question
<UbuntuFan> have*
<UbuntuFan> may I.
<UbuntuFan> Q-FUNK, Sup brutha?
<UbuntuFan> it's Mark. Am rounding up the Art team to bring out the bling bling!
<Q-FUNK> oh :)
<UbuntuFan> How are you man?
<Q-FUNK> hm... not much.  still walking circles around 3 different countries' immigrations just to get around starting a company.
<Q-FUNK> citizenship (or lack of) prevents everything.
<UbuntuFan> oh ok. Good luck mate.
<UbuntuFan> Very true...let me know if I can donate and help!!
<UbuntuFan> thats what I'm about, giving back.
<UbuntuFan> =)
<Q-FUNK> plenty of brilliant business ideas, some of which have been in the planning stage for several months. all blocked becuase EU countries discourage outsiders.
<UbuntuFan> EU grrrr...
<UbuntuFan> I feel for you man.
<Q-FUNK> ...althoguh it has to be said that their definition of outsider is... silly.  I've been here for nearly 9 yeas, dammit
<UbuntuFan> Anything I can do to help
<UbuntuFan> let me knwo
<UbuntuFan> know even.
<Q-FUNK> anyhow... I was just wonderng, who is responsible for packaging the firefox language packs?  the firefox 2.0b2 upgrade breaks because language packs don't match.
<UbuntuFan> imbrandon is ....
<UbuntuFan> hes here i think
<Q-FUNK> erm.  probably not much.  it's all political and all in finland's hands.  I jsut need one country somewhere to acknoeledge how long I've been here and grant me citizenship.
<UbuntuFan> giftnudel, welcome it's mark here just slipped in from outta space..to see that sad look upon ure face.
<imbrandon> UbuntuFan, no i'm not responisable for firefox, and can you please take non development disscussion to #ubuntu-offtopic 
<imbrandon> Q-FUNK, whats the problem?
<Q-FUNK> imbrandon: parsing errors in chrome://browser/content/browser.xul for non-C locales
<Q-FUNK> afaik caused by slight changes in the UI between beta1 and beta2
<UbuntuFan> imbrandon, I am sorry. but you gotta admit that was pretty funny.
<Q-FUNK> imbrandon: or well, is this generally a good channel to report bugs in edgy, since we are so close to releease?
<imbrandon> Q-FUNK, normaly this is ok or #ubuntu+1 or LP but right this very second i'm trying to take care of another issue, give me just a few minutes
<Q-FUNK> sure.  np :)
<buzzen> fabbione: yes
<buzzen> fabbione: ok... i thought i had. but maybe not ? :/
<buzzen> fabbione: just redid it and now its working :-) shouldnt the mdadm install script run it though ?
<fabbione> buzzen: it should.. i will check why it didn't
<buzzen> this sort of solves this bug then https://launchpad.net/distros/ubuntu/+source/mdadm/+bug/60623 since thats based on wrong ordering of mdx devices. although mdrun still has some problems.
<Ubugtu> Malone bug 60623 in mdadm "Upgrading mdadm package is impossible - can't upgrade while raid arrays active" [Untriaged,Confirmed]  
<buzzen> see this bug: https://launchpad.net/bugs/38438
<Ubugtu> Malone bug 38438 in mdadm "boot confused after stopping array" [Medium,Confirmed]  
<buzzen> oops. wrong one.
<buzzen> i mean this one: https://launchpad.net/bugs/60646
<Ubugtu> Malone bug 60646 in initramfs-tools "Unable to boot with degraded array" [Untriaged,Unconfirmed]  
<buzzen> fabbione: it's also not possible to upgrade to madm normally: https://launchpad.net/distros/ubuntu/+source/mdadm/+bug/60623
<Ubugtu> Malone bug 60623 in mdadm "Upgrading mdadm package is impossible - can't upgrade while raid arrays active" [Untriaged,Confirmed]  
<fabbione> buzzen: yes i am reading.. give me a break.. it's the same bug you pasted 10 lines above
<buzzen> fabbione: yes sorry that was an accident. 
<buzzen> fabbione: I pasted the wrong bug and didn't realise it was also a related one.
<fabbione> i will look into that on monday
<buzzen> sure
<buzzen> thanks
<fabbione> it needs a bit too much work for me to trash my weekend
<buzzen> there is a fix in debian according to madduck 
<fabbione> yes i read in the bug
<fabbione> but jumping to 2.5 is not an option
<buzzen> aah ok.. i wrote it. (i just got up)
<fabbione> we need to backport the fix
<buzzen> shame :/
<buzzen> 2.5 would be nice
<fabbione> buzzen: we are at about 1 month from release. i don't want extra bug coming in with 2.5
<fabbione> it will be in edgy+1
<fabbione> buzzen: also.. the bug is not in mdadm userland itself.. it's a bit more complicated compared to what you write in the bugs
<fabbione> the kernel should be sending a udev event on raid creation and apparently it doesn't
<fabbione> that result in udev requiring a manual kick
<fabbione> and that can only happen from mdadm in userland
<buzzen> ok
<fabbione> does anybody remember what's the canonical way to enable compiz?`
<fabbione> iirc there was something in the menus, but i can't find it
<Treenaks> fabbione: compiz --strict-binding --indirect-rendering --replace & gnome-window-decorator --replace&
<Treenaks> works for me
<fabbione> Treenaks: let's give it a shot
<fabbione> apparently it doesn't like nvidia
<Treenaks> it doesn't.. yet
<Treenaks> nvidia doesn't have some GL extension yet
<fabbione> hmmm
<giftnudel> GL_texture_from_pixmap I guess ;)
<fabbione> compiz is a wrapper
<Treenaks> giftnudel: something like that :)
<fabbione> yeah that one
<giftnudel> fabbione: this is a driver problem, rumors say it will be fixed in the next driver release
<fabbione> ahhh
<fabbione> no
<fabbione> it's the wrapper that is wrong
<fabbione> or better
<Hobbsee> hey all
<fabbione> nvidia-glx does something wrong with divert
<Treenaks> it LD_PRELOADs crap
<Treenaks> EEK
* Treenaks scared now
<fabbione> and it points to the wrong lib
<giftnudel> still, the extensions is probably still missing
<fabbione> no actually no
<fabbione> the wrapper is correct
<fabbione> so what driver do you use for that to work?
<fabbione> nv ?
<Treenaks> afaik only ati and intel work atm
<Treenaks> and maybe bits of via
<Treenaks> (as nv doesn't do dri..)
<fabbione> humpf
<fabbione> ok this just can't work
<giftnudel> fabbione: do you have a laptop with an intel chipset?
<giftnudel> it works quite well on those
<fabbione> giftnudel: no i don't
<Kamion> Mithrandir: I'm surprised Xubuntu worked well enough for knot-3 - its seeds were still pointing at the old kernel version
<Kamion> I've merged the seeds now ...
<Kamion> raphink: Why does ichthux-artwork-usplash conflict with kubuntu-artwork-usplash? Why not just give the usplash a different file name and register the alternative as usual?
<raphink> Kamion: yes, I agree
<raphink> Kamion: I yet have to find out how to give it another name
<raphink> this is something I planned to look at this week-end since it was already reported to me
<raphink> :)=
<raphink> thanks for pointint it though :)
<raphink> s/pointint/poinging
<raphink> pointing
<raphink> raah 
<raphink> ;)
<Kamion> is that hard? just install it as ichthux-splash.so rather than kubuntu-splash.so and edit the maintainer scripts
<raphink> Kamion: yes I guess it's just changing the name in the makefile
<raphink> I have to test
<Kamion> I'd rather not accept it until that's done since mistakes in alternatives often have complicated upgrade implications
<Kamion> sorry for the delay in reviewing
<raphink> alright Kamion :)
<raphink> no problem
<raphink> are you ok with ichthux-meta ?
<Kamion> the conflict with kubuntu-default-settings is also a bit nasty
<raphink> well no there's no choice for this one
<Kamion> if that can be avoided, it would be good, although I don't think so many alternatives are involved there
<Kamion> oh, how come?
<raphink> becaue of the way kubuntu patches KDE
<raphink> unless we patch kdelibs to add /usr/share/ichthux-default-settings in addition to /usr/share/kubuntu-default-settings
<raphink> but that would mean patching  a main package for ichthux so I don't think this is a great idea
<Kamion> ichthux-meta should be updated to the current way *-meta is done
<raphink> Kamion: ok I'll have a look at the new way :)
<Kamion> with an update that just uses germinate-update-metapackage, and an update.cfg pointing to your seeds
<raphink> alright :)
<Kamion> it would also be a good idea to update the seed dist to edgy :-)
<Fujitsu> Thankyou Kamion :)
<raphink> I had just used the Dapper way so far
<raphink> hehe
<Kamion> unless it's not used I guess
<raphink> Kamion: for ichthux-default-settings, I see two options as I said:
<raphink> 1) conflict with kubuntu-default-settings
<raphink> 2) patch kdebase
<raphink> or maybe there could be a third
<raphink> 3) make it possible for derivatives to add their path as a setting in kde
<Kamion> are you doing all the *-meta bits in your seeds now, or are you still manually patching stuff?
<Kamion> raphink: ok, never mind for now then
<Kamion> it looks like you were manually patching dependencies at one point, which is a bit suboptimal
<raphink> Kamion: in Ichthux 6.09 I had some manual patches because there were packages not in Ubuntu
<raphink> but for Edgy we want to put all the packages in Ubuntu and thus only use edgy seeds
<Kamion> you could probably solve that by grabbing all the Packages and Sources files and catting them together for germinate
<Kamion> even without them all in Ubuntu
<raphink> hmmm 
<raphink> well I wanted to use the existing code in ubuntu-meta and not patch it too much
<Kamion> nod
<raphink> so it was rather hard to add support for multiple repositories as it was
<raphink> to me at least ;)
<Kamion> anyway, not much to be actually unhappy with in ichthux-meta, just comments about how to improve it
<Kamion> I'd prefer to wait until ichthux-default-settings is ready though
<raphink> thank you Kamion I appreciate it
<raphink> alright I'll be working on this asap then :)
<Kamion> Fujitsu: np, I don't have enough time this weekend to clear out the whole queue but I thought I'd do a bit of it while I was doing a sync for myself anyway
<raphink> as for superkaramba-theme-losungen there's an issue with it Kamion
<Fujitsu> Yeah, thanks :)
<raphink> so please ignore it if you come over it
<raphink> :s
<raphink> we discovered this issue a few hours ago
<Kamion> raphink: do you want it rejected?
<raphink> Kamion: for now, yes :(
<raphink> I'd love to have it but the texts it uses are not free
<raphink> :(
<raphink> we're trying to see if we can port it to use libsword instead
<raphink> but it might not be easy
<raphink> so for now, just reject it
<Kamion> ok, rejected, thanks for the note
<Kamion> do try to have debian/copyright match the actual licence ;-)
<raphink> Kamion: since we plan to release ichthux 6.10 within Edgy 6.10 (i.e. same release schedule from now on) do you think I could add our specs to ubuntu's somehow?
<Kamion> raphink: you'd probably have to ask #launchpad about technical details; that said, I think it might be easier from a scheduling point of view if they were separate
<Kamion> so that you can target specs to milestones freely without having to get Ubuntu drivers to do it
<raphink> oh yes I see
<raphink> ok
<raphink> good point :)
<zyga> hey guys :)
<Fujitsu> Hi zyga.
<Fujitsu> Kamion, sorry about that dodgy geda-gschem shouldn't-have-been-a-sync... I must have missed that went I went through all the *geda*... :(
<Hobbsee> Fujitsu: you test built the geda-gschem package?
<Fujitsu> Hobbsee, yes.
<Hobbsee> Fujitsu: ahh...it's deps are waiting to be built
<Fujitsu> Hobbsee, yes.
<Hobbsee> that's a pity
<Hobbsee> it looks sane
<Fujitsu> I hope it is..
<Mithrandir> Kamion: oh well, I just did as janimo asked me to do..
<giftnudel> on the http://ubuntu.com/testing/knot3 page, there is still the message about knot3 not being released (which according to the topic seems wrong)
<Fujitsu> And there are no announcements on lists yet...
<giftnudel> oh, funny, I thought this was done yesterday
<Fujitsu> Thankyou Hobbsee :)
<Hobbsee> Fujitsu: :)
<giftnudel> pitti: you changed bug 32343 to fix committed in dapper, does that mean the packages are already in dapper and need time to sync to the mirrors?
<Ubugtu> Malone bug 32343 in gutenprint "printer Epson Stylus DX4850 does not work properly" [High,Fix released]  http://launchpad.net/bugs/32343
<Hobbsee> giftnudel: it's likely fixed in edgy
<Hobbsee> giftnudel: but check launchpad
<giftnudel> well, this is a serious bug for users of that printer, it should be fixed in dapper too
<Hobbsee> which then has the potential to break other things.  see !releases
<giftnudel> Hobbsee: well, I just don't like the "it's fixed in edgy, please upgrade" mentality, since dapper is supported, but I still get your point ;)
<Hobbsee> giftnudel: supported, ie, security fixes, yes.  new features which bring in new bugs?  no.  that's what the development release is for
<Fujitsu> Hobbsee, look at the bug report. Pitti created a task specifically for Dapper, and marked it as committed...
<Hobbsee> ah okay.  i didnt check that sorry
<Fujitsu> Yeah, it's a little odd..
<jsgotangco> Happy SFD!
<Fujitsu> Just, jsgotangco :)
<giftnudel> my new printer works with this update completely with open drivers, so this is really a good SFD day!
<tseng> Mithrandir: do you have a list of known issues for knot3 yet? its acting completely flakey on 64-bit
<Mithrandir> tseng: what part of it is?
<tseng> Mithrandir: i originally installed a 32-bit dapper cd
<tseng> Mithrandir: gnome, ubiquity
<Hobbsee> Fujitsu: can you add the debian --> ubuntu debdiff of kvdr please?  (and in all future merges) - it's useful to have both.
<Mithrandir> tseng: hmm.
<Fujitsu> Hobbsee, OK, shall do.
<Mithrandir> tseng: I don't know of any "known issues page", but maybe there's something under EdgyEft/Knot3/?
<tseng> Mithrandir: also if i plug/unplug power the entire thing hangs
<tseng> i looked at the wiki page
<Fujitsu> Hobbsee, done.
<tseng> ill try a dapper cd and see what happens
<Hobbsee> Fujitsu: thanks
<pitti> Hobbsee: committed != released
<Hobbsee> pitti: true. my error for not checking the bug report first.  
<Hobbsee> fabbione: do you own ubuntulog?
<bluefoxicy> Another day, another fucking annoyance.  I have to get my room sprayed, get a shower, get coated in this weird goo, then leave it on for hours while I feel all icky.
<bluefoxicy> Plus I had to clean my room yesterday
<neuralis> mdz: ping
<tseng> bluefoxicy: hey dude, off topic.
<jsgotangco> watch language too
<robertj> has anyone here created an Ubuntu image for s3 ECC?
<sladen> s3 eec?
<robertj> sladen: amazon's clustering system
<robertj> sladen: they have default images for core 3 & 4, but that be it
<robertj> (it's the same cluster that hosts s3)
<robertj> (btw, s3fs is shaping up to be great stuff)
<tseng> mjg59: is there a reason for 915resolution not to be on the livecd?
<zyga> re
* zyga got wpa_supplicant working :)
<BenC> pitti: ping
<pitti> BenC: pong (but about to leave)
<BenC> pitti: dapper upload is done
<pitti> BenC: ah, great
<BenC> kernels should be built, and I just uploaded lrm and linux-meta
<zul> and the breezy/hoary kernels are done as well yesterday
<pitti> BenC: breezy and hoary are built
<pitti> BenC: I assume lrm can only start building once I publish the kernel to the archive
* BenC is doing a nice dapper-proposed-updates upload too
<pitti> BenC: I'll release it properly on Monday
<BenC> pitti: probably
<pitti> BenC, zul: thanks for the fast update
<zul> no probs just doing my thing
<zul> thank my wife as well for being tolerant ;)
* pitti hands zul's wife some pralines
<zul> wohoo
<alex-weej> can anyone explain why i am getting bombarded with ancient email on ubuntu-devel@lists?
<alex-weej> stuff as far back as 02 July 2006 is being delivered to me NOW
<Treenaks> alex-weej: someone did some moderator work
<Treenaks> alex-weej: which hadn't been done for some time
<alex-weej> Treenaks: fair play
<desrt> wow.  awesome.  updated initramfs-tools, udev, usplash -> fun to watch my initramfs be regenerated 3 times
<crimsun> better to err on the side of inefficiency than to have your initramfs not be properly regenerated, eh?
<desrt> better to have apt exit hooks
<crimsun> (similar issue applies for various ttf packages0
<desrt> similar issues for any package that needs to update scrollkeeper/gtkiconcache/etc/etc
<_ion> dpkg 2 will have that AFAIK. :-)
<desrt> anyone know where i could get a linux-source-2.6.17-6.18 tarball?
<desrt> sleep on my laptop has regressed -- just noticed
<desrt> and it's gone from the archive already :(
<zul> launchpad
<desrt> how does that work?
<zul> you download the source from launchpad and build it from there
<zul> what regression btw?
<crimsun> except if the release has been removed, you get a 404 when you attempt to navigate to said release
<desrt> ya... so it's been removed.
<desrt> which is why i ask :)
<crimsun> I think what you might have to do is pull git tag a64b7fbd1d977443d45ad8726f00fdfcbfb77ba9
<desrt> where should i clone from?
<crimsun> ubuntu-2.6.git (kernel.org)
<desrt> yup.  definitely a kernel problem.  even happens in singleusermode
<Arador> while you're at it you could do a bisection search in that git tree to find out what change broke your box, and report it ;)
<desrt> Arador; uhm.. that's sort of the plan
<Arador> oh
<Will> http://www.ubuntu.com/testing/knot3
<Will> This pages shows knot3 as not ready
<desrt> crap.
<desrt> the git archive is mucked up
<desrt> someone has 'www.kernel.or' in there somewhere as a source
<shining> is anyone aware of any troubles with last mdadm update ?
<shining> I get something like "md : md* is in use" in dmesg, for my 3 raid devices, md0, md1 and md2. if nobody knows about mdadm, I'll just report a bug
<sbalneav> Hello all.
<sbalneav> Who's an autoconf maven here?  ogra and I are merging some upstream ltsp stuff, working on the "muekow takes over the world" weekend, and I need some help with bin_SCRIPTS
<crimsun> ogra: pong
<sbalneav> crimsun: he's afk at the moment.
<ogra> crimsun, did you see that i reopened the via driver bug yesterday ? 
<sbalneav> lol
<sbalneav> ok, he's not.
<crimsun> ogra: no (not familiar w/ bug)
<ogra> you uploaded the fix :)
<ogra> looking up the bug #
<crimsun> ogra: are we talking via (graphics) or via (sound)?
<ogra> graphics
<ogra> you disabled a patch in the 1.0.2 package 
<ogra> it seems to have regressed again in 1.1.1
<ogra> hrm, why did malone not send any mail about it ...
<desrt> crimsun; ok.  i have the git.
<ogra> crimsun, bug 57329
<Ubugtu> Malone bug 57329 in xorg-server "upgrade to latest xorg has stopped my CLE266 from working" [Medium,Confirmed]  http://launchpad.net/bugs/57329
<crimsun> ogra: err, no wonder I have no idea what you're talking about. I didn't have anything to do with xorg-server.
<desrt> oh man.  300000 lines of changes
<desrt> i love that
<ogra> crimsun, hmm, right, i didnt look at the changelog, only at the malone entry :)
<ogra> sorry then 
<crimsun> np
<ogra> i'll talk to rodarvus
* desrt thinks crimsun has the wrong tag
<crimsun> desrt: that's the changelog tag, so it very well could be slighter older than the actual 6.18 release. What are you running into?
<desrt> 2.6.15 era changes
<crimsun> err, I meant compilation issues
<desrt> no compile issues
<desrt> the old kernel would wake up from sleep.  the new one will not.
<desrt> that's all
<crimsun> you mentioned 6.18, so I pointed you toward it. Did I miss something?
<desrt> i think i'm just very confused on how y'all use git :)
<desrt> these old changes i'm seeing are probably merges from dapper or something...
<desrt> i want to bisect between the versions that were released as the last -6 and the first -7
#ubuntu-devel 2006-09-17
<gardengnome> ok, i have found the "ubuntu-cdimage" project in launchpad but i can't download the sources there. vanilla debian-cd looks like it won't support ubuntu without giving me headaches. does anyone know where i could get the ubuntu specific tool?
<gardengnome> oh, i found it. nvm :)
<jdong|GRR> uhh, knot3 amd64 ubiquity doesn't work
<jdong|GRR> poke screensaver throws a python exception
<jdong|GRR> is that a known issue?
<jdub> uh, ouch
<jdub> mdadm expects to be able to stop raid arrays during upgrade
<jdub> fabbione: ping (unlikely -> mdadm expects to be able to stop raid arrays during upgrade)
* jdub clags upgrade spew into bug
<jdong> jdub: you might need to try /summoning/ fabbione.....
* jdong hands stick, candles, and salt to jdub
<Fujitsu> jdub, that's know, I saw a comment about that last night.
<Fujitsu> *known
<jdub> #60623
<Fujitsu> Yes, that one.
* Amaranth wonders why he is getting emails from June from ubuntu-devel
<_ion> amaranth: I think a moderator found some false positives from a spam folder, and passed them to the list.
<Amaranth> so far they look like duplicates
<Amaranth> although perhaps people sent their message again when it didn't show up the first time
<Fujitsu> Amaranth, Burgandavia cleaned out the spam filter yesterday.
<bddebian> Heya folks
<BenC> is there something special I've got to do to upload to dapper-proposed-updates?
<zul_> isnt there something in the wiki?
<jdong> BenC: hehe, paranoia setting in?
<BenC> jdong: I've uploaded it twice and gotten no reply from the archive about it
<BenC> zul_: I checked, didn't see anything
<jdong> hmm :-/
<zul_> https://wiki.ubuntu.com/StableReleaseUpdates
<BenC> zul_: that's for dapper proper
<BenC> I don't see anything in there about proposed-updates
<jdong> BenC: under 2. Prepare
<jdong> "The upload target must be release-proposed"
<BenC> ah
<BenC> jdong, zul: thanks
<jdub> $ sudo dmidecode | grep Speed Max Speed: 1800 MHz Current Speed: 1200 MHz
<jdub> boh
<jdub> $ sudo dmidecode | grep Speed
<jdub>         Max Speed: 1800 MHz
<jdub>         Current Speed: 1200 MHz
<jdub> $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
<jdub> 1200000 800000
<jdub> 
* jdub ponders... bios is dumb?
<jdub> must be
<jdong> weird :)
<jdub> maybe the bios *wants* me to overclock it!
<Amaranth> jdub: Do it. ;)
<Burgundavia> jdub: given my bios doesn't even know what my cpu is and I have seen some very odd bios breakage out there, I would not be surprised
<AlinuxOS> Burgundavia, hello, I would like to ask you if you are ubuntu mailing lists manager ? I would like to set-up one for Georgian translators.
<Burgundavia> AlinuxOS: no, i am not
<Burgundavia> I merely have the (mis)fortune to moderate a few
<AlinuxOS> Burgundavia, thanks.
<sladen> jdub: the dmi tables are probably static and contain whatever the PFY typoed on the day of release.  
<Lathiat> err upgrading mdadm tries to stop the raid arrays..  thats not going to work on most systems
<jdub> Lathiat: lp#60623
<Lathiat> heh
<Lathiat> righto
<Lathiat> sheesh does kubuntu edgy boot quick, i assume from the upstart stuff
<jdong> Lathiat: profiling a bootup will get you another few seconds back... edgy's readahead-list is way off
<Lathiat> how do you do that?
<ajmitch> Lathiat: apparantly by adding profile to the kernel commandline in grub
<Lathiat> hrm ok i'll give that a shot
<Lathiat> yeh that made a big diff
<AlinuxOS> jdub, ping
<glick> hello
<glick> excuse me im reading the ubuntu packaging guide
<glick> and i have a question about this pbuilder application
<Burgundavia> glick: that is a question for #ubuntu-motu
<glick> ok
<adamant1988> hello all..
<adamant1988> uhm.. I guess if you're the developers I need to talk to.. the naim package is BAD
<adamant1988> I went to install it and it decided that I need to remove 93 packages in order to install =\
<Fujitsu> Works for me, adamant1988.
<Fujitsu> What are some of the packages it wants to remove?
<crimsun> (this is better addressed, as maintenance question, in -motu)
<imbrandon> thats most of the time the result of a shady sources.list file
<adamant1988> Fujitsu: a lot of KDE packages.. I have the whole list
<adamant1988> I'll paste bin it
<Fujitsu> OK, please move to -motu.
<imbrandon> e.g. #ubuntu-motu
<fabbione> jdub: yes i know. there is a bug filed already.
<fabbione> jdub: it's monday stuff tho..
<desrt> Burgundavia; poke
<Burgundavia> desrt: poke back
<desrt> Burgundavia; your knot3 page says "has not been released yet"
<desrt> (it has)
<Burgundavia> it shouldn't, I thought I removed that
<Fujitsu> Burgundavia, it's still there... And Knot 3 isn't listed on /testing.
<Burgundavia> I will fix
<thansen|laptop_> gaim-devs: ping :)
<Burgundavia> thansen|laptop_: are you looking for the people who upload gaim?
<thansen|laptop_> whoever packages it
<Burgundavia> thansen|laptop_: that would be seb128
<thansen|laptop_> Burgundavia: do you know if the beta3 is what for sure will be used in edgy?
<Burgundavia> thansen|laptop_: are you an upstream gaim dev?
<thansen|laptop_> no, but I have a patch for the groupwise protocol...which currently doesn't work
<Burgundavia> thansen|laptop_: file a bug, mention you have a patch
<thansen|laptop_> I talked to the novell guy who maintains it and he said he would upstream it sometime in the next couple weeks, but I want to make sure it gets into edgy
<thansen|laptop_> where are bugs filed for ubuntu?  sorry, kinda new to the ubuntu community
<Burgundavia> edgy is not due for a while, and given we have a beta, I would expect us to get the final
<Burgundavia> wiki.ubuntu.com/ReportingBugs
<thansen|laptop_> it's been beta now for a year :)
<thansen|laptop_> maybe it's inclusion in edgy will prod them along a bit though ;)
<Burgundavia> thansen|laptop_: I wish it would
<Burgundavia> given it has been in beta for more than 6 months
* Burgundavia waiting for telepathy to take the need for gaim away
<thansen|laptop_> link?
<Burgundavia> http://telepathy.freedesktop.org/wiki/
<thansen|laptop_> malone is telling me to use the official gaim bug tracker
<Burgundavia> right, you need gaim the ubuntu package, not the upstream product
<Burgundavia> welcome to LP :(
<thansen|laptop_> where can I find that?
<Burgundavia> under the ubuntu product, search for gaikm
<fabbione> Hobbsee: hey.. yes i "own" ubuntulog somehow
<Hobbsee> hey fabbione 
<Hobbsee> fabbione: right, can we get ubuntulog into #ubuntu+1 too please, and log that?
<fabbione> Hobbsee: can you please file a bug in LP and make sure you assign it to me?
<Hobbsee> fabbione: under what?  ubuntulog or something?
<fabbione> it's kind of sunday :)
<fabbione> ubuntu
<fabbione> general
<Hobbsee> right
<Hobbsee> fabbione: yes, and?   :P
<fabbione> and i am spending time with my wife and my kid :) no hacking today
<Hobbsee> fabbione: yeah, fair enough :)
<Lathiat> Hrm, can you no longer mark a bug as having two tasks one for breezy and one for dapper?
<Hobbsee> Lathiat: i thought you could.  say the bug affects another distro, and do it that way
<Lathiat> yeh but then it says 'already reported'
<Hobbsee> oh darn
<Hobbsee> i thought you could
<Hobbsee> that's how i used to do it
<Hobbsee> Lathiat: or the request a backport button?
<Hobbsee> make sure that doestn subscribe the backporters team by accident though
<Lathiat> hrm
<Lathiat> that looks like it would do what we want but
<Lathiat> it does seem to be specifically for 'backports'
<StevenK> Lathiat: There's a "Also affects: distrobution" link
<StevenK> Lathiat: The last part of the URL is +distrotask
<Lathiat> yeh that doesnt work
<Lathiat> you say Ubuntu, lynx
<Lathiat> and it says its already reported
<Hobbsee> StevenK: that's what i said
<Lathiat> doesnt seem to include a version component
<Lathiat> ok the backport fix thign seems to do the right thing
<Lathiat> just slightly confusing terminology
<o_cee> is it just my firefox that's broken in edgy at the moment?
<glick> hey is the debian maintainers guide still applicable to ubuntu?
<Burgundavia> glick: yes, mostly
<jdub> fabbione: :-)
<zyga> hello
<Kamion> o_cee: the language packs are outdated; 'LANG=en_US.UTF-8 firefox' should be a workaround
<Kamion> it's rather crashy though
<o_cee> Kamion: ah okay, thanks!
<Kamion> haven't tried with a clean profile yet to see if that works better
<zyga> pitti: hi
<pitti> hi zyga 
<zyga> pitti: there is a problem with langpack that includes polish firefox addon
<zyga> pitti: if you can confirm that LANG=pl_PL.UTF-8 firefox breaks things :)
<zyga> (some parse error in chrome.xul)
<pitti> zyga: bug 60631
<Ubugtu> Malone bug 60631 in mozilla-firefox-locale-all "[edgy] Crash opening firefox" [Critical,In progress]  http://launchpad.net/bugs/60631
<zyga> oh :)
<pitti> zyga: fallout from a Friday afternoon firefox upload :/
<pitti> zyga: I don't have much time right now, I'll fix this tomorrow morning
<zyga> right, have a nice weekend :)
<mjg59> Why has ubuntu-devel just thrown 60 old mails at me?
<Fujitsu> mjg59, Burgundavia cleaned the spam filter yesterday.
<Burgundavia> mjg59: shouldn't have been 60, but i passed a bunch through, some because of mailmans shite interface
<jdub> Burgundavia: apt-get install listadmin
<Burgundavia> jdub: listadmin?
<jdub> apt-cache show listadmin
<Burgundavia> oh, love
<Burgundavia> thanks
* _ion just realized the edgy kernel isn't using libata-pata anymore.
<mjg59> It was never supposed to be
<_ion> So there were problems?
<mjg59> There are still certain limitations
<_ion> Ok.
<Kamion> wow, listadmin is fantastic
<jdub> yeah
<jdub> the only thing it doesn't do is "add to okay posters list"
<pitti> jdub: thanks for that hint, this will help a lot :)
<lynxorgd> http://www.cyber-wars.com/?ref=100628
<lynxorgd> http://www.cyber-wars.com/?ref=100628
<lynxorgd> http://www.cyber-wars.com/?ref=100628
<lynxorgd> http://www.cyber-wars.com/?ref=100628
<lynxorgd> http://www.cyber-wars.com/?ref=100628
<lynxorgd> v
<lynxorgd> http://www.cyber-wars.com/?ref=100628
<lynxorgd> http://www.cyber-wars.com/?ref=100628
<lynxorgd> v
<lynxorgd> vhttp://www.cyber-wars.com/?ref=100628
<GyrosGeier> hi
<Hobbsee> heya
<GyrosGeier> is there anything the installer does to integrate bootsplash support that doesn't get done when installing the -desktop package by hand?
<GyrosGeier> because I installed Xubuntu, and now I get an Ubuntu bootsplash for startup and a Xubuntu bootsplash for shutdown
<StevenK> GyrosGeier: The boot splash is run from the initramfs, and the shutdown is from userspace
<Tonio_> hi everyone
<StevenK> GyrosGeier: Regenerate your initramfs and see if that fixes it?
<Tonio_> GyrosGeier: also check your alternatives settings
<GyrosGeier> excellent
<GyrosGeier> also, the bootsplash goes away after unpacking the restricted drivers
<GyrosGeier> and the system falls back to text mode
<GyrosGeier> is this maybe related to having 64MiB of RAM only?
<GyrosGeier> and third, is there any bug reporting tool? reportbug finds out "this is not Debian, so I need to send to ubuntu-devel", but fails as I don
<GyrosGeier> and third, is there any bug reporting tool? reportbug finds out "this is not Debian, so I need to send to ubuntu-devel", but fails as I don't have an MTA on this network
<Hobbsee> !bug
<Hobbsee> GyrosGeier: [23:03]  <ubotu> If you find a bug in Ubuntu, please report it at http://bugs.ubuntu.com
<bddebian> Howdy folks
<Hobbsee> hey bddebian 
<bddebian> Hi Hobbsee
<GyrosGeier> so nothing "assisted" that asks you whether you want to include debconf settings?
<Mithrandir> GyrosGeier: not yet, no.  We're still waiting for the XMLRPC interface for malone.
<Mithrandir> once we have that, reportbug or similar will be updated to just file bugs using that.
<GyrosGeier> ah
<fabbione> hey GyrosGeier !
<GyrosGeier> because I have an X server autodetection glitch
<GyrosGeier> so I have a lot of debconf info
<GyrosGeier> hi fabbione 
<fabbione> GyrosGeier: best thing is to open a bug above and add all the info you have.
<GyrosGeier> okay
<fabbione> GyrosGeier: there should also be something on the wiki
<fabbione> hol don
<GyrosGeier> I will probably be LARTed for installing onto a P166MMX anyway, but...
<fabbione> ahha nah
<fabbione> GyrosGeier: i still have your ex a1200 running here :)
<GyrosGeier> cool
* StevenK waits for other Debian guys to come across to the Dark Side
<GyrosGeier> so given this is #ubuntu-devel, will there be an Ubuntu release for m68k? :-)
<StevenK> Bwahaha
<fabbione> GyrosGeier: ehhehe
<_ion> Amiga, yay.
<fabbione> GyrosGeier: i am kind of thinking about it.. but i don't think i have enough time for it
<GyrosGeier> StevenK, well, if you've read my blog entry, you know my opinion
<GyrosGeier> StevenK, Ubuntu is cool for the desktop and maybe servers (never tried it there), but its focus is too narrow for it to be interesting to me
<fabbione> no.. the page on the wiki is gone
<fabbione> https://help.ubuntu.com/community/DebuggingXAutoconfiguration
<fabbione> there
<GyrosGeier> I happily hand out CDs to users, but my embedded devices run Debian.
<GyrosGeier> fabbione, thanks
<fabbione> GyrosGeier: i don't know how update it is
<fabbione> but it should help
<fabbione> at least to add all the info required
<GyrosGeier> well, the box in question has all the hardware evil you can find
<GyrosGeier> nVidia Riva128 OEM card with obscure Manufacturer ID
<GyrosGeier> plus a Voodoo1
<fabbione> GyrosGeier: i sort of expected that from you :)
* fabbione still can't take away the paintaing from the a1200 :P
<GyrosGeier> the X server autoconfig creates a config file that tells it to use the "apm" driver on the voodoo
<fabbione> that's a discover-data bug
<fabbione> is that the only glitch?
<GyrosGeier> fabbione, I thought you did away with the casing and glued to mainboard to the outside of some server box?
<GyrosGeier> fabbione, mostly
<fabbione> GyrosGeier: no, i glued the entire a1200 to a mini-desktop.
<GyrosGeier> fabbione, the screen is corrupted after DPMS
<fabbione> GyrosGeier: in that case just open a bug on discover-data with the pci id, description of the board and what X driver it should be used
<fabbione> GyrosGeier: that's enough to fix it
<GyrosGeier> fabbione, okay, can do that
<fabbione> yup thanks
* fabbione goes back to watch a movie
<GyrosGeier> fabbione, although there is also a driver for rendering to two triangles that fill the entire screen on Voodoo1
<GyrosGeier> so technically, you could use both cards. :-)
<fabbione> hmmm
<fabbione> yeah but we don't support dual-head or dual-gfx configs out of the box yet
<fabbione> it's difficult to detect which one is primary
<GyrosGeier> fabbione, yep, that may be the problem
<fabbione> yes that might be one of the 2
<GyrosGeier> fabbione, only the Riva claims to be a graphics card
<fabbione> the driver should have been the right one, no matter
<fabbione> it basically depends on the order in which discover finds them on the bus
<fabbione> the first one wins
<GyrosGeier> fabbione, the Voodoo just says "custom" in its PCI data
<fabbione> just add that's a Voodoo1 based card and a manufacturer if you have it
<GyrosGeier> fabbione, well, the IDs are 0:9:0 for the Riva, and 0:b:0 for the Voodoo, and the Voodoo's ID ends up in the config file
<fabbione> that's plenty of info for a text description that nobody really will ever read
<fabbione> yeah probably
<fabbione> anyway.. movie time :)
<GyrosGeier> \o/ movie
<GyrosGeier> hmm
<GyrosGeier> is it a good idea to dist-upgrade from a Debian system, or should I install from scratch?
<pygi> GyrosGeier, uhm, ubuntu? scratch :)
<GyrosGeier> because the CD-ROM drive in this box is dog slow and occasionally fails
<GyrosGeier> so network installation wins
<tseng> jdub: do you know why 915resolution isnt on the livecd?
<tseng> Mithrandir: did the soversion on libobrender go *down*?
<tseng> Mithrandir: obconf complains about not finding .so.1, openbox now ships .so.0.4.0
<Mithrandir> tseng: yeah, it did, for some reason..
<tseng> Mithrandir: weird
<Mithrandir> I need to poke upstream about it
<bluefoxicy> what the hell, lilo died?
<_ion> Yes.
<bluefoxicy> vo.ov sad.
<sivang> bluefoxicy: just notiuced. sad as hell
<pygi> wohooo, two more tickets :)))
<HiddenWolf> pygi: tickets to woodstock, or bugs? :P
<pygi> HiddenWolf, bugs ^_^ And then I can release the libburn ^_^
<HiddenWolf> ah. :)
<pygi> HiddenWolf, just you ah :P
<HiddenWolf> pygi: ah is the undervalued little brother to awe. :)
<pygi> HiddenWolf, heh :)
<pygi> HiddenWolf, you shall not make fun out of libburn ^_^
<HiddenWolf> pygi: will it bite me in the ass otherwise? ;)
<pygi> HiddenWolf, just you laugh, you'll see...
<HiddenWolf> pygi I'll see, and I'll cheer. :)
<davmor2> Hi I am using an up-to-date version of amd 64 bit edgy.  from both the live cd (knot 3) and my installed version I get a soft lockup on shut down which freezes the computer and prevents it shutting down.
<crimsun> any alt+sysrq+foo output?
<crimsun> you want to discuss this in -kernel, probably
<davmor2> crimsun: thanks will do.
#ubuntu-devel 2007-09-10
<unggnu> hi all
<unggnu> Today was a new acpi-support version release for Gutsy but the sonybright.sh issue https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/136380 hasn't been fixed. Is something wrong with the patch?
<ubotu> Launchpad bug 136380 in acpi-support "[Gutsy]  sonybright.sh doesn't use the correct value range" [Undecided,New] 
<mjg59> No, it was simply uploaded for other issues
<unggnu> I am afraid that this bug make it into final. Ok, it is no debian package patch but at least it should be clear what is wrong.
<unggnu> Is there any how to what is the best way to post patches?
<unggnu> If I post a bug in Launchpad it tries to find similar bugs which is great but it often shown duplicates. Isn't it better to show the main bug an not the duplicate? It should use the duplicate to find a similar one but then only show the main bug imho.
<pochu> unggnu: sounds like a good suggestion, could you file a bug at https://bugs.launchpad.net/malone/+filebug ?
<unggnu> pochu: For Launchpad?
<pochu> yeah, the dups thing
<unggnu> Ok, thanks.
<unggnu> pochu: There was already a bug report for this issue. https://bugs.launchpad.net/malone/+bug/130526
<ubotu> Launchpad bug 130526 in malone "Improve list of duplicates when reporting a bug (order by number of dupes, mark dupes)" [Undecided,New] 
<unggnu> ciao
<pygi> ls
<ion_> https://launchpad.net/apt-mark-sync in case anyone is interested.
<pygi> ion_, what is debfoster? :P
<pygi> and people are sleeping :D
<ion_> pygi: apt-cache show debfoster
<pygi> ion_, at this time of day? xD
<pygi> right
<pygi> good night =)
<ion_> Night
<saispo> anyone have an idea why with my macbook and the latest madwifi drivers under feisty i see my AP but when i enter the key, no dhcp response...
<saispo> ?
<jdong> 21:13 -!- geser [i=mb@2002:5361:2a04:0:0:0:0:1]  has joined #ubuntu-devel
<jdong> cool is that IPv6?
<geser> yes, ipv6-over-ipv4
<jdong> cool
<geser> it really is :)
<ion_> Speaking of IPv6, i hacked IPv6 reverses to all machines in my LAN. They advertise their addresses using Avahi, and the DNS box queries the addresses and updates the DNS records on demand.
<ion_> Thus, this box is seen by the outside world as luotain.lan.heh.fi
<stuart_> hi everyone, does this udev rule look correct? ACTION=="add", BUS=="usb", SYSFS{model}=="MHT2020AT*", RUN+="/usr/local/bin/fht_backup", SYMLINK+="usb_backup_disk"
<josh_whitney> hi, someone on my localnet got this ip address banned from #ubuntu.  how do I resolve it?
<Hobbsee> go to #ubuntu-ops
<pitti> Good morning!
<pygi> morning pitti
<StevenK> Morning pitti!
<StevenK> pitti: How was your holiday?
<pitti> hey StevenK, hi pygi
<pitti> StevenK: we truly enjoyed it, Paris is great
<StevenK> pitti: Now that you're back at work, can you do a bunch of NBS stuff? :-)
<StevenK> pitti: I *think* -10 of the kernel can be NBS'd out, along with a whole bunch of everything else - my suggestion is kill everything that is zero sized and then regenerate the list.
<pitti> StevenK: right, I'll do that
<StevenK> pitti: NBS'ing out everything zero-sized will also make another five or six also hit zero-size after the list is regenerated.
<pitti> hey thekorn
<thekorn> hey pitti
<thekorn> how was your vacation?
<pitti> thekorn: thanks for the apport porting to the new p-lp-bugs; however, the retracers now throw some exceptions, can I bother you with some questions today?
<pitti> thekorn: we loved it, Paris is great
<thekorn> pitti: yes, sure
<pitti> StevenK: slaughtery committed
<StevenK> pitti: Yay! You need to wait for the publisher to run/finish before re-generating?
<pitti> StevenK: yep
<superm1> pitti, do you know how mvo builds the big .tar.gz that contains all the .desktop and and icons files that go into app-install-data?  It appears his update script for it grabs them from a big .tar.gz sitting in his people.ubuntu.com directory
<pitti> superm1: unfortunately I don't know this; this is a special upload magic method
<superm1> okay i'll just shoot him a mail then, thx :)
<ScottK> StevenK: Maybe while he's in a slaughtering mood, he'll process some removal bugs ...
<StevenK> ScottK: Heh, maybe.
<LaserJock> pitti (aka The Grim Reaper) ;-)
<pitti> ScottK: if you need something urgently, I can do it now; otherwise, Friday is my archive day
<ScottK> pitti: No, no rush.  Friday will be fine.
<ScottK> Just having fun with the slaughtering motif.
<ScottK> Good night all.  I'm off to sleep.
<pitti> g'night Scott
<superm1> night ScottK
<StevenK> I guess that means the new PAM works.
<pitti> StevenK: so far it does fine :)
* StevenK idly wonders who he can beg to accept the new virtualbox-ose upload.
<kagou> good morning
<dholbach> good morning
<pygi> morning dholbach
<dholbach> hey pygi
<Mithrandir> dholbach: why did you make bluez-utils build-dep on gstreamer-tools rather than libgstreamer-plugins-base0.10-dev?
<Mithrandir> (and libgstreamer0.10-dev)
<dholbach> Mithrandir: gstreamer-tools is required for dh_gstscancodecs
<Mithrandir> ah, ok
<dholbach> Mithrandir: I guess I forgot to add the other build-dep
<dholbach> and didn't run the build in pbuilder, so I did not notice that the build-dep was missing
<StevenK> pitti: You should be able to regenerate the NBS list now, right?
<pitti> StevenK: right, doing now
<StevenK> Hum.
<StevenK> Maintainer: Peter Zhu <peter.j.zhu@intel.com>, Ubuntu MOTU Developers <ubuntu-mo
<StevenK> tu@lists.ubuntu.com>
<StevenK> I don't even think that's legal.
<pitti> StevenK: http://people.ubuntu.com/~ubuntu-archive/NBS/ is updated
<StevenK> pitti: Yay, thank you.
<pitti> StevenK: maintainer> right, there should only be one; but I guess few programs actually rely on that
<pitti> StevenK: I kill the two without remaining rdeps
<StevenK> pitti: Way cool.
<doko> pitti: maybe you can double-check the fstack-protector/nostdlib thing, planned to upload 4.1 with this one as well
<pitti> doko: yep, I can, once it's built and in the archive
<MacSlow> Greetings everybody!
<StevenK> infinity: Ping, libnss-db some more.
* StevenK works on getting missioncontrol{0,-dev} killed.
<Mithrandir> pitti: are you fixing the ftbfs in libcgi?
<pitti> Mithrandir: I got a lot of FTBFS from the maintainer: rebuilds, I probably won't fix them all
<Mithrandir> ok
<pitti> Mithrandir: if this one is particularly important, I can look into it, of course
<Mithrandir> nah, I'm just looking at my lp-buildd-admins mbox
<pitti> but since most of these packages haven't been touched for ages, I won't waste much time on them in general
<Mithrandir> hm, I wonder if there's a good mechanism I can add to packages maintained in revision control to tell people to submit patches properly rather than just uploading new versions of them.
<Mithrandir> (apart from X-VCS)
<StevenK> X-Commit-Do-Not-Upload: True ? :-P
<Fujitsu> We need the bit of NoMoreSourcePackages where Soyuz rejects non-VCSed uploads for VCSed source packages.
<Mithrandir> Fujitsu: something like that, yes.
<Mithrandir> I'm wondering if I can get it done in the package, though
<DktrKranz> dholbach, do you have time to review a segfault fix for bluez-libs in bug 126068 ?
<ubotu> Launchpad bug 126068 in bluez-libs "Pybluez segfaults if bluez not running" [Undecided,Confirmed]  https://launchpad.net/bugs/126068
<pitti> thekorn: ah, p-lp-bugs 0.2.10 might actually resolve one of the crashes
<thekorn> pitti: ah, ok, do you have any tracebacks or error messages I can check?
<pitti> thekorn: I'll look into it in a bit, once the updated deb is in the archive, I'll restart the retracers and watch the logs
<thekorn> ok, ping me if you need some help with py-lp-bugs
<calc> pitti: hi
* calc decided not to sleep tonight
<pitti> hey calc
<pitti> calc: why not?
<calc> my wife can't sleep and she won't shut up
<calc> so i am working instead of sleeping :\
<calc> i need another bed for situations like this ;)
<ion_> ...So your wife decided youll not sleep tonight?
<calc> pitti: oh did you get my message about suitesparse?
<calc> ion_: more or less, not her fault she has insomnia, we are taking her to the doctor tomorrow to have it checked
<pitti> calc: I did; I didn't check for an MIR yet, though
<calc> pitti: it was in main until Sept 5
<doko> calc: why upload rc1, if rc2 is released?
<calc> pitti: i can do a MIR if needed
<calc> doko: why upload at all when 2.3.0 will be out ~ thursday...
<calc> doko: i had rc1 done already and tested i didn't have rc2 tested
<calc> and yes 2.3.0 should be out around wed/thu this week aiui
<doko> ahh, ok. please don't upload the -l10n package immediately, but loosen the deps instead, and include the updated translations from launchpad
<doko> calc: hmm, debian changelog not in the changes file
* calc needs to make a script that kicks him when he doesn't use -v
* calc wishes dpkg-buildpackage was smart enough to do it on its own as well :\
<calc> either part the including the entries or kicking me when i don't use -v, either would suffice ;)
<pitti> calc: it does print out a warning about it already
<AlinuxOS> hello pitti, nice to re-see you ;)
<pitti> bonjour AlinuxOS!
<AlinuxOS> pitti, one fast question, is there daily lang-packages for gutsy ?
<pitti> AlinuxOS: it was disabled for a while due to some bad circumstances, but I just uploaded fresh ones and re-enabled the cronjobs
<AlinuxOS> asac, good morning, how is going https://bugs.launchpad.net/ubuntu/+source/mozilla-firefox-locale-all/+bug/88677 fixing?Sorry for refreshing you via IRC :)
<ubotu> Launchpad bug 88677 in mozilla-firefox-locale-all "Georgian Language support." [Undecided,Confirmed] 
<AlinuxOS> pitti, ah, so it's usable now right ?
<pitti> AlinuxOS: they are not built yet, but will be soon
<AlinuxOS> pitti, ah ok ;)
<AlinuxOS> nice too hear. thank you.
<calc> pitti: oh, hmm i missed that somehow, i'll look to see if i can find the warning
<AlinuxOS> pitti, I suppose this is a rep right?  deb http://ppa.dogfood.launchpad.net/ubuntu-langpack/ubuntu gutsy main
<pitti> AlinuxOS: nope, gutsy updates are uploaded straight into gutsy proper
<calc> pitti: i don't see the warning though i may be blind
<calc> pitti: at least not in my build log
<AlinuxOS> pitti, I was talking about daily langpack updates.
<pitti> AlinuxOS: so was I
<AlinuxOS> pitti, ;) ok thanks
<pitti> WARNING generated by debuild:
<pitti> Ubuntu merge policy: when merging Ubuntu packages with Debian, -v must be used
<pitti> calc: ^
<pitti> calc: I get this (from debuild)
<\sh> uh...what happened to the mouse under gnome?
<calc> pitti: cool i wonder why mine doesn't say that
<calc> pitti: i built with debuild -sa -S -us -uc
<calc> pitti: would that cause the problem of not seeing the message maybe?
<pitti> calc: no, that shuold work
<pitti> calc: however, it's only shown if $DEBEMAIL =~ /ubuntu/
<calc> pitti: hmm does that show up in the debuild *.build log?
<dholbach> DktrKranz: ok
<calc> pitti: oh doh
<calc> i should set my DEBEMAIL var then so it reminds me
<calc> i build in a chroot and don't have that set at all
<dholbach> DktrKranz: I'll triage the sponsoring queue in a bit
<DktrKranz> dholbach: thanks
<angel25_> i installed ubuntu server 7.04 on Intel Core 1.83 with 2 GB RAM (1 stick) and everyting working good , when i increase my memory to 4 GB the system got stuck and move very slowly, on the start i get an error under : loading hardware drivers - e1000: eth0: e1000_request irq unable to allocate msi interrupt error -22 someone please can help me ?
<DktrKranz> pitti: hi martin, welcome back! have you some time have a look at plr SRUs proposals in bug 130059 ?
<ubotu> Launchpad bug 130059 in plr "[SRU]  R_HOME environmental variable not set" [Undecided,Confirmed]  https://launchpad.net/bugs/130059
<calc> pitti: hmm i still don't get the warning even with it set, eg
<calc> dpkg-genchanges: including full source code in upload
<calc> ver: 1:2.3.0~rc1-1ubuntu1 since:  debemail:ccheney@ubuntu.com
<calc> dpkg-buildpackage (debuild emulation): source only upload (original source is included)
<calc> very odd :-\
<calc> debuild is out to get me, heh
<soren> calc: Does your DEBEMAIL have "ubuntu" in it somewhere?
<calc> soren: notice debuild output says debemail = ccheney@ubuntu.com
<pitti> calc: erk, there's still some debugging output there, I should remove that
<calc> heh
<pitti> calc: debuild itself generates the warning, btw
<soren> calc: Oh, right :)
<pitti> calc: and the changelog entry has to =~ /merge.*Debian/i
<pitti> calc: I know, it's a weird heuristics, that's why it doesn't live in dpkg itself
<calc> oh gr i used different wording in my changelog
<calc>   * Resynchronise with Debian. Remaining changes
<pitti> calc: ah
<calc> so it doesn't like my changelog entry i guess
<pitti> calc: I'll change the regex for that
<pitti> calc: along with removing that debugging stuff
<calc> thanks
<pitti> DktrKranz: reviewed, I updated the bug
<DktrKranz> pitti: thanks.
<mdz> jdstrand: yes.  the control actually works properly at the moment, but the brightness indicator on-screen is borked
* pitti celebrates his 1000th apport commit
* soren hugs pitt
* soren hugs pitti, too
<mhb> hi pitti
<soren> \o/
<pitti> hey mhb
<mhb> pitti: zasf had some bug fixes for r-m, before you upload them, I would like to have a look if those bugs don't appear in KDE frontend, too
<mhb> by "upload" I meant merge with the main branch, not uploading itself
<pitti> mhb: alright, thanks for the notice
* dholbach hugs pitti
<asac> siretart: ping
<Lure> pitti: have 5 minutes to discuss libgphoto2?
<pitti> Lure: doing some other things, but just ask
<Lure> pitti: I did merge to try libgphoto2 2.4.0 (new upstream release), but have found one issue with  debian/libgphoto2-2.postinst
<pitti> Lure: did you get UVFE for that?
<Lure> pitti: it looks like one condition (version check) is in reverse and I am concerned if it is ok at all in current package
<Lure> pitti: not yet, as I would like to have wider testing through ppa and then ask you what do you feel about it
<pitti> Lure: looking
<Lure> pitti: good thing that api stays (just new functions added)
<StevenK> Hrm. Who's archive day is it today?
<Lure> pitti:
<Lure> if which udevinfo >/dev/null && udevinfo -V | awk '{if ($3 >= 98) e
<Lure> xit 1}'; then
<Lure> This exit 1 seems to be wrong, based on what is executed afterwards
<pitti> Lure: I think it's correct
<Lure> pitti: on current gutsy, "else" part print usage of print-camera-list into udev rule file
<pitti> Lure: the problem is that udev-rules-0.98 has a weird semantics
<Lure> pitti: but exit 1, makes condition false
<pitti> Lure: oh, I guess they removed the pre-0.98 syntax in 2.4?
<Lure> pitti: looks like, but I still think condition is wrong in current package
<Lure> pitti: I can fix 2.4 properly (remove 0.98 case)
<pitti> Lure: for a new gutsy merge the entire if should just be removed, and replaced with a single p-c-l call
<Lure> pitti: exactly
<pitti> Lure: this was mainly introduced to keep the feisty package backportable to edgy
<Lure> pitti: ok, that was the reason
<geser> morning
<pitti> hey geser
<Lure> pitti: will complete the merge then and will upload to my PPA and ask for review/UVF later (when confirmed with some users it still works fine with most apps)
<pitti> Lure: great, thanks; I did the last merge IIRC, so I'd be interested in reviewing it
<Lure> pitti: that is why I waited for you to come back from vacation to check it at all makes sense to ask for UVF ;-)
<geser> does somebody know why the gnuradio source is in universe but all the binaries in multiverse?
<pitti> geser: probably just an oversight when NEWing it
<pitti> geser: hm, do you see a reason why it should be in multiverse?
<StevenK> pitti: libmissioncontrol{0,-dev} is ready to NBS out at your leisure.
<pitti> geser: I moved it to universe for now (debian/copyright is GPL and it's in Debian main)
<geser> pitti: thanks, I don't know a reason why it should be in multiverse.
<pitti> StevenK: done, thanks!
<StevenK> pitti: Thanks!
<geser> pitti: do you also handle UVFe for packages in main?
<pitti> geser: yes, I can do that
<geser> I've started to look on boost (bug #134684)
<ubotu> Launchpad bug 134684 in boost "Upgrade to Version 1.34.1" [Wishlist,New]  https://launchpad.net/bugs/134684
<geser> the linked list of fixed problems looks interesting
<geser> I've uploaded a merged boost to my PPA and started to check if packages build-depending on it still build
<geser> I didn't get far as my PPA is nearly full
<geser> I checked the 3 packages from main depending on boost and some from universe
<geser> 57 packages from universe are still to be checked :(
<pitti> geser: hm, which applications would actually benefit from that?
<geser> in main kdepim, kdeedu and libwibble build-depend on it
<pitti> geser: I mean benefit from the bug fixes to fix visible bugs
<geser> I don't know if there are any filed bugs
<geser> pitti: so no upgrade of boost for gutsy? and the bug asking for it can be closed?
<pitti> geser: currently looking
<pitti> geser: it's only a microversion upgrade
<pitti> geser: however, I'd like to see the upstream changelog, and a quick review of the diff
<geser> yes, a bugfix release from 1.34.0 to 1.34.1
<pitti> geser: browsing the diff should give an idea about API breakage and whether things look bugfix-ish, or like major new features
<geser> the problem is that the packages names contain the version and all depending packages need rebuilding
<geser> pitti: ok, will prepare the diff
<pitti> geser: merci
<dholbach> iwj: is bug 134358 ok to upload?
<ubotu> Launchpad bug 134358 in hexter "Please merge hexter (0.6.1-2) from Debian unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/134358
<pitti> geser: can you confirm that bug 131591 is fixed? it's for me
<ubotu> Launchpad bug 131591 in poppler "pdftops from poppler-utils 0.5.9-0ubuntu1 produces broken postscript" [High,In progress]  https://launchpad.net/bugs/131591
<geser> pitti: yes, it's fixed
<pitti> geser: thanks, closed
<dholbach> iwj: also... does the patch in bug 131858 make sense? shall I assign it to you or do you think there's somebody else who can review it?
<ubotu> Launchpad bug 131858 in grub "Update-grub does not add savedefault anymore" [Undecided,New]  https://launchpad.net/bugs/131858
<geser> pitti: re boost: there is no changelog, only the ticket list which got fixed in 1.34.1 (which is also linked from the homepage): http://svn.boost.org/trac/boost/query?status=closed&milestone=Boost+1.34.1
<pitti> geser: ok, so we need to take a look at the diff
<geser> pitti: a diffstat and a diff between 1.34.0 and 1.34.1 is at http://members.ping.de/~mb/boost/
<pitti> geser: filterdiff -x "*.html" boost.diff |grep -v ^diff is much better to read :-) reviewing now
<pitti> geser: why was the python2.5-dev b-dep changed to python2.4-dev? that looks wrong
<geser> pitti: it's a change made by Debian
<pitti> geser: bug updated
<geser> I diff the old Ubuntu packages with the new one
<geser> pitti: all the python-*-dev build-depends look a little bit duplicate for me
<pitti> geser: right, python-dev already pulls in 2.5-dev, but 2.4-dev seems to be wrong, unless we reintroduce the elementtree dep with sth. like "Depends: python2.5 | python-elementtree"
<geser> looking at the Debian bug it was done as python2.4 is still default in Debian, so it should be safe to change it back
<geser> pitti: build logs for boost, kdepim, kdeedu and libwibble at https://launchpad.net/~geser/+archive/+builds?build_text=&build_state=all
<pitti> geser: ah, cool; if everything builds, I'm fine with it
<geser> the miro FTBFS dies at linking with boost as it tries the old lib name
<siretart> asac: pong
<asac> siretart: hi ... about wpasupplicant .)
<asac> siretart: some operations take ages some times ... e.g. terminate
<asac> siretart: any idea what wpasupplicant might be doing?
<siretart> huh? I never noticed that
<siretart> asac: is it perhaps in state 'D' while hanging?
<siretart> that would indicate it was waiting for a system call to finish
<asac> siretart: how can i see that state?
<asac> siretart: my guts feeling suggests that its some system call ... however i am not sure how to best track that
<asac> siretart: you can easily see that when you use the latest opennet branch ... i increased timeout for some operations in nm ... but still sometimes it just fails.
<asac> siretart: would be really great if you could help a bit ;)
<asac> siretart: if you don't want to compile nm ... just wait a few hours, I will upload that branch now anyways.
<siretart> asac: you can see the process state with tools like 'top' or 'ps'
<asac> ah ... let me see
<siretart> asac: other 'normal' states are 'S' for sleeping, or 'R' for running. 'D' is 'I'm hanging during some system call'
<siretart> asac: is there a bug number for this issue?
<siretart> I'm happy to take a look at it, but first I need to be able to reproduce that
<asac> siretart: no ... i asked you because i am not sure if that is a known issue ;)
<asac> siretart: sure ... should be rather simple
<asac> siretart: i will ping you once new nm is rolled
<asac> siretart: you can see it now in nm as well ... there are often "couldn't connect to supplicant errors" when you switch networks for instance
<siretart> if it is indeed a system call which blocks it, there isn't much we can do on the supplicant side. it's a(nother) driver problem then
<mjg59> asac: ipw3945 loves me again
<mjg59> Thanks!
<asac> mjg59: yeah ;) ... i am happy that it appears to have cured most :)
<asac> mjg59: thanks for the feedback
* siretart hugs asac
<siretart> :)
* siretart lunch, cu later!
<asac> siretart: the intersting thing is that i see the same timeout issues even though i am using a different driver
<mvo> asac: network-manager is fine for me now after updating to the latest version. when the interface is manually managed it does not longer thinks its not configured, but correctly keeps its hands away
<asac> mvo: strange ;)
<asac> mvo: there wasn't really a change related to something like that ;)
<asac> but happy that it works now :)
<mvo> asac: I only infrequently upgrade my notebook, its quite possilbe that the change is already ~4 weeks old :)
<asac> ah ok
<asac> let me know when it reappears
<asac> mvo: its pretty important that users are not offlin if they use /e/n/i ;)
<mvo> sure
<mvo> I keep a eye open
<pitti> mvo: do you already know about the ImportError crash on livecd start from update-app-install?
<mvo> pitti: is this still a issue with 0.4.8-0ubuntu2 ? this version was meant to fix it
<pitti> mvo: I just tested the current i386 live
<mvo> pitti: could you please check the version of gnome-app-install on it? I sync a new image now, but it will take a bit until I have it
<pitti> mvo: which package is that?
<pitti> 0.4.8-0ubuntu1
<mvo> ok
<mvo> -ubuntu2 should fix it
<pitti> mvo: ah, ok, so I'll check tomorrow's; thanks!
<mvo> cheers
<mvo> -ubuntu2 was uploaded a couple of days ago, before the weekend - I wonder why its not there yet
<cjwatson> today's live CD build broke, which was my fault
<cjwatson> should be fixed shortly
<cjwatson> mvo: see above :)
<cjwatson> I'll poke through a new live CD build now
<mvo> :)
<mvo> ok
<mvo> np
<carlos> cjwatson, mdz: hi, around?
<mdz> carlos: on the phone. what's up?
<carlos> cjwatson, mdz: I wonder whether we could add a policy to force a package rebuild when we move it from universe to main if it has translations
<carlos> otherwise, the application cannot be translated in Launchpad neither appears in language packs
<cjwatson> it would be rather inconvenient to force it
<carlos> until a new version is rebuilt
<mdz> carlos: I think that rather we should ensure (when we do a global rebuild test) that no cases like this exist, and force rebuilds where necessary at that time
<cjwatson> is there a huge problem with just waiting until it's uploaded again in the normal course of development?
<cjwatson> (or reporting on it, as mdz suggests)
<mdz> at string freeze, say, we could do any needed rebuilds then
<carlos> cjwatson: well, the only problem is that users asks us to fix it, and we redirect them again to package maintainers
<cjwatson> carlos: the workflow for packages being moved from universe to main is not geared to let us easily do this sort of thing immediately
<carlos> other than that... nothing
<carlos> ok
<cjwatson> if we had the facility for central binary-only rebuilds, it would be trivial, but as it is it requires a source upload
<cjwatson> carlos: is it possible for you to produce a list of packages in main for which you do not have translation tarballs?
<carlos> cjwatson: we have a spec to produce such report, although is not yet implemented
<cjwatson> that would seem like the most straightforward answer
<carlos> anyway, that would include also packages that cannot be translated as false positives (still need to think on a way to remove them from the report)
<pitti> Mithrandir: to get a workaround for bug #131976, I'd like to create a casper hook which disables the AppArmor profile for cups on the live cd; would I ship that in the cupsys package, or in casper proper?
<ubotu> Launchpad bug 131976 in cupsys "fails to start: cannot apply additional memory protection after relocation" [High,Triaged]  https://launchpad.net/bugs/131976
<Mithrandir> pitti: traditionally, I've shipped all those hacks in casper itself.
<pitti> Mithrandir: right, by the looks of it it has all sorts of package specific hacks, but I wanted to get a second opinion
<dholbach> BenC: do you think I should assign review bugs for the kernel team to canonical-kernel-team instead of ubuntu-kernel-team?
<cjwatson> pitti: if you want a third opinion, I agree with Mithrandir - ship it in casper
<pitti> cjwatson: thanks; I'll do that
<cjwatson> pitti: I see cryptsetup is on the approved-for-main list now. Should we promote that and all the d-i bits for it too? I know we're past feature freeze ...
<pitti> cjwatson: promotion is fine for me if it works properly now
<pitti> cjwatson: I'd rather apply the FF to the package itself
<pitti> cjwatson: the d-i bits might fall under FF once they get installed by default, I figure?
<cjwatson> they won't be used by default, merely provided as options
<pitti> cjwatson: is that the module which allows you to create LUKS encrypted partitions in partman?
<cjwatson> right
<pitti> default> right, that's why I'm not too concerned about it
<pitti> in the unlikely case that it breaks the default install, the breakage should be at a level we immediately notice on install tests
<cjwatson> indeed so, and we won't be including it in ubiquity anyway
<cjwatson> ok, I have to go to buy milk now but will look at that when I get back
<pitti> (which is a pity... :-) )
<cjwatson> the ubiquity code would *definitely* fall under feature freeze. :-)
<stdin> doko: you about?
<doko> stdin: ?
<stdin> doko: Lure mentioned you were working on kde-systemsettings, it seems it now need python2.5-dev to work now
<doko> did I mention to work on this?
<Lure> doko: recent cleanup of python-qt that you did
<ion_> benc: Btw, have you had the chance to apply the patch to nvidia_supported in l-r-m? The newest l-r-m package still contains no modaliases for nvidia_new.
<stdin> doko: well, yeah, seems kde-systemsettings tries to access /usr/lib/libpython2.5.so
<doko> Lure, stdin: bug number?
<doko> shouldn't it do that?
<geser> doko: your vectormath package looks odd, libvectormath1 seems to be missing (the -dev package depends on it) and the -dev package includes only headers. Is this intended?
<Lure> doko: it is provided by python2.5-dev and not regular package
<doko> geser: yes, working on that ...
<stdin> here we go https://bugs.launchpad.net/ubuntu/+source/kde-systemsettings/+bug/138189
<ubotu> Launchpad bug 138189 in kde-systemsettings "[gutsy]  libpython2.5.so is missing" [Undecided,New] 
<doko> geser, do you have ubuntu running on the ps3?
<Jucato> thanks stdin :)
<ion_> benc: Btw2, in case you ever need a small program that indicates whether given hardware (by modaliases or a module name) is connected to the system, <https://launchpad.net/hardware-connected>. It should be useful when making the nvidia stuff automatically make symlinks to different versions of the nvidia drivers based on connected hardware.
<geser> doko: I don't even own a ps3
<hunger> siretart: Are you serious with cryptsetup breaking whith /usr being in a separate encrypted filesystem not being a serious problem?
<geser> pitti: can you please give-back libglade-java on sparc and libgnome-java on ia64. Thanks.
<pitti> geser: done
<pitti> hunger: do you think it is? what's the use case?
<pitti> hunger: after all, wouldn't it make much more sense, if you have a separate /usr, to have it be the only partition which is *not* encrypted?
<hunger> pitti: It has to be: /usr has to be encrypted, otherwise somebody can sneak SW onto your system.
<hunger> pitti: at least if you are considering encryption as a protection against manipulation of your system.
<pitti> hunger: but in that case, leaving / unencrypted won't help you
<hunger> pitti: Nope, you need to encrypt everything
<pitti> right
<siretart> hunger: iwj did the change, please discuss that with him
<pitti> but that was said to work?
<siretart> hunger: he was asking for comments for that change, and nobody was able to give reasonable arguments. I think you might be able to convince him.
<hunger> siretart: OK, The changelog entry was sailing under your name:-)
<Hobbsee> pitti!
* Hobbsee hugs pitti
* pitti jumps for joy and throws Merengues at Hobbsee 
<Hobbsee> hehe :)
<pitti> Hobbsee: how are you, oh my mistress of Kubuntu?
<Hobbsee> pitti: could be better.  i *seriously* dislike the physics subject i'm doing now.
<soren> Hobbsee: Are they claiming your LPSoD doesn't work and/or exist?
<cjwatson> hunger: in general, encryption is not the piece of cryptography that I'd look to to provide integrity
<Hobbsee> soren: havent tried, actually
* Hobbsee didnt even have to use the LPSoD on the phone company she just called, either.
<hunger> cjwatson: What else to use?
<cjwatson> hunger: hashes on a separate secured medium?
<hunger> cjwatson: Without encryption anybody that can get access to your HDD can change stuff on it.
<cjwatson> please read some introductory texts on security
<soren> hunger: Depends. Are you most worried about people messing with your data or about now knowing if they've done so?
<cjwatson> encryption's primary purpose is confidentiality
<cjwatson> you can sometimes get integrity out of it but there are much better ways
<hunger> soren: Basically I am doing full disk encryption. With cryptsetup (which is what I have to use) that amounts to encrypting all the partitions I have.
<cjwatson> since practically all of /usr is shipped in Ubuntu packages, I expect I could probably replace your separate encrypted /usr with an entirely new blob and you might well not notice
<cjwatson> since /var tells me what packages are installed and that's not encrypted unless you encrypt all of /, and if you do that and keep /usr on the same partition as / then you don't have a problem here
<hunger> cjwatson: /var is a seperate partition here and of course encrypted.
<cjwatson> the problem is only if you encrypt /usr and keep it separate from /
<cjwatson> don't do that, then
<hunger> cjwatson: And replacing /usr with a new blob will not work without a key:-)
<hunger> cjwatson: Seperate / and /usr is traditionally done (even though it is not much use anymore), so having that break when both are encrypted seems very strange to me.
<cjwatson> it's necessary for the time being
<cjwatson> would you rather we provided encryption as long as you don't have a separate /usr, or no encryption at all?
* hunger shrugs. If you think it is.
<cjwatson> have you read the reason why that restriction is there for the time being?
<hunger> cjwatson: maintainability.
<cjwatson> false
<cjwatson> I conclude therefore that you have not
<hunger> cjwatson: Why not move those two libs to /lib?
<hunger> cjwatson: I read the changelog entry. Not that much info in it:-)
<cjwatson> it would be possible to move them, yes
<cjwatson> it simply has not been done yet, and somebody needs to work out what to do with the initramfs
<cjwatson> it is not necessary to overreact to the restriction, given that cryptsetup was only moved into main literally this morning
<bigon> dholbach: are you there?
<alex-weej> if we're in UVF now does this mean we're not getting GTK 2.12 / GNOME 2.20?
* alex-weej is slightly confused
<ogra> gnome has a general freeze exception
<alex-weej> ogra: right
<ogra> so dont worry ;)
<alex-weej> there are several tooltip fixes in GTK trunk that i'm really starting to long for :P
<dholbach> bigon: yes
<bigon> dholbach: I've posted a comment about bug #138027
<ubotu> Launchpad bug 138027 in empathy "Please merge empathy (0.12) from debian (main)" [Undecided,In progress]  https://launchpad.net/bugs/138027
<dholbach> bigon: good, I'll check my mails in a bit
<asac> siretart: with network-manager 0.6.5-0ubuntu11 installed, try to switch networks and you will eventually see huge delays for some wpasupplicant operations when looking at tail -f syslog
<dholbach> bigon: it can't use python-distutils.mk for that reason, but the python packaging items I mentioned are ok to use
<bigon> dholbach: I don't see how it can be done since DEB_PYTHON_SYSTEM is only use in python-distutils.mk
<stgraber> asac: did you change something about wpa_supplicant in the latest NM upload ? looks like it now correctly disconnects here (I just tried suspending/resuming my laptop and it reconnected correctly instead of waiting for 10s)
<asac> stgraber: he? well i uploaded my opennet branch
<asac> stgraber: it tries a bunch of things to properly shutdown nm ... its DISABLE_NETWORK + AP_SCAN 0 + TERMINATE now iirc
<asac> s/shutdown nm/shutdown wpasupp)
<stgraber> asac: ok, maybe I just was lucky. I'll use it as usual and see if I have any unwanted behaviour
<asac> stgraber: so you say that suspend/resume is fixed?
<stgraber> looks like yes
<asac> stgraber: i have a bunch of bugs about that I would be happy to close ;)
<stgraber> let me try 4-5 more time then :)
<asac> thanks :)
<bddebian> Heya
<dholbach> bigon: I'm not sure it is
<ScottK> There's always a traditional debian/rules with calls to dh_pysupport or dh_pycentral.
<bigon> dholbach: http://www.pastebin.be/5235
<stgraber> asac: argh, I had two kernel freeze (I'll check what happens later), but NM worked almost correctly (it just took 3s to disconnect once, otherwise it was already disconnected)
<dholbach> doko: is DEB_PYTHON_SYSTEM only for python-distutils.mk?
<doko> dholbach: yes, I think so, part of cdbs
<dholbach> doko: so the variable isn't used anywhere else?
<doko> dholbach: not 100% sure, but I don't think so
<asac> stgraber: thanks
<dholbach> thanks doko
<dholbach> pitti: you can upload bughelper, if you like
<dholbach> bigon: in that case, that's ok :)
<Hobbsee> asac: got any thoughts on https://bugs.launchpad.net/ubuntu/+source/mozilla-thunderbird/+bug/133171 ?
<pitti> dholbach: bughelper?
<ubotu> Launchpad bug 133171 in mozilla-thunderbird "moztraybiff (tray icon enabler extension) doesn't work in gutsy version of thunderbird 2" [Undecided,New] 
<pitti> dholbach: I just did a p-lp-bugs upload
* pitti hugs the
* pitti hugs thekorn 
<bigon> dholbach: great :)
<dholbach> pitti: sorry, I meant that
<asac> Hobbsee: yes ... thanks
<doko> pitti: please could sync ecj (fixing current build failures seen on my rebuild tests)
<dholbach> pitti: I think I was quicker with my upload than you with yours :-/
<slavik> who is responsible for maintaing the drivers in the restricted driver manager?
<pitti> dholbach: as long as you got all three commits, that's fine :)
<asac> Hobbsee: now "triaged" :)
<dholbach> pitti: 3 commits?
<pitti> slavik: me for the UI part, the actual drivers -> kernel team
<pitti> dholbach: if you have r48, all is well
<slavik> where can I get in contact with the kernel team?
<slavik> or should I file a bug on launchpad?
<pitti> dholbach: but my push worked, so you didn't push your 'release' changes before uploading...
<pitti> slavik: #ubuntu-kernel should do
<slavik> the nvidia driver is horribly outdated on feisty, but I dunno if it's worth submitting a bug atm.
<slavik> haven't checked gutsy yet
<pitti> slavik: no, it's not; we will only fix gutsy
<StevenK> slavik: Did you try nvidia-glx-new?
<pitti> slavik: (it's not worth it, that is)
<pitti> slavik: but what StevenK says
<StevenK> There is in fact, three Nvidia drivers in Feisty
<superm1> is restricted manager making choices as to when to use nvidia-glx-new or nvidia-glx now too then?
<pitti> superm1: no, those lists are shipped in l-r-m
<slavik> StevenK: nvidia-glx-new is also outdated IMO (but I haven't tried) after the restricted manager's driver failed, I installed the one from nvidia's site, the 100.xx series
<Hobbsee> asac: :)
<superm1> but in theory nvidia-glx-new will work on all the hardware that is supported by nvidia-glx too though
<StevenK> slavik: I can't think of any reason to use 100.x instead of -new on Feisty.
<paran> superm1: that is not true.
<pitti> superm1: s/all/most/
<pitti> dholbach: I got an accept mail
<slavik> StevenK: does -new support 8800 series?
<superm1> paran, pitti didn't realize that there was hardware support dropped in the newer releases. (other than the break off between regular release / legacy )
<pitti> dholbach: erk, I mean a reject mail
<StevenK> slavik: So it would seem.
<pitti> dholbach: erk, I mangle a new changelog and reupload then
<paran> superm1: nvidia maintains two "legacy drivers" 1.0-71xx, 1.0-96xx and one current "100.14.11"
<dholbach> pitti: ok, thanks
<superm1> paran, ugh that really makes for a bad taste in my mouth.
<slavik> -new in feisty is 97xx
<pitti> doko: synced
<cjwatson> mvo: did you notice that your gnome-app-install 0.4.8-0ubuntu2 upload was rejected?
<slavik> also, would it be worth it writing a GUI bind zone configurator?
<cjwatson> mvo: I think your .dsc had a different md5sum for the .orig.tar.gz
<mvo> cjwatson: oh, thanks
<StevenK> mvo: Does that also fix the sexy-python -> python-sexy issue?
<paran> superm1: yeah, it sucks. off course they all have different ranges off supported cards.
<doko> pitti: thanks
<mvo> StevenK: yes
<superm1> paran, ah ha: http://www.nvidia.com/object/IO_32667.html
<StevenK> mvo: Great!
<superm1> that explains it all
<paran> superm1: anyway, all the three are in gutsy. packages nvidia-legacy, nvidia-glx and nvidia-new
<StevenK> nvidia-glx-legacy and nvidia-glx-new
<paran> oops :)
<superm1> paran, i'm hunting for a good way to query which one should be installed during ubiquity-frontend-mythbuntu yet.
<superm1> so i might just end up parsing the file shipped with l-r-m
<superm1> so what happens when they introduce another legacy series? :)  nvidia-glx-new-new?
<Hobbsee> wow, we can certainly tell that pitti is back
<StevenK> I think -new is a hold-over from Debian
<StevenK> Didn't Khensu have a Plan[tm]  or something?
<pitti> StevenK: no, it was a gross hack to avoid breakign edgy->feisty upgrades
<StevenK> Ah ha
<StevenK> Well, I feel suitably dirty now.
<pitti> I'm still in favor of merging them all into just one package and select at runtime by modaliases
<pitti> but packaging-wise, that's very complicated
<superm1> especially since they all need to ship libGL?
<pitti> still, the current 'splitting' approach cannot be continued endlessly
<pitti> it forces us to install obsolete versions, duplicates maintenance, and cannot be supported
<pitti> hi mathiaz
<pitti> mathiaz: are you aware of the current AA profile breakage? I think it's due to kernel/userspace desync
<superm1> well this splitting approach will eventually turn into a nvidia-glx-71xx nvidia-glx-96xx, gnvidia-glx-100xx and so on so forth if its continued i'd anticipate
<StevenK> Personally, I'm with pitti on this one.
<mathiaz> pitti: yes. that's correct.
<StevenK> pitti: Agreed, just thinking about it, it's a big mess to sort out, but I think it's a big win.
<mathiaz> pitti: The new kernel module has been uploaded on friday.
<pitti> mathiaz: so it'll be updated soon? it blocks some bug fixes from me
<mathiaz> pitti: now what needs to be done is to update the userspace in main.
<mathiaz> pitti: I already have everything in my brz branch, but I need a bit more testing
<mathiaz> pitti: and then it needs to be reviewed by a core-dev ( keescook )
<pitti> mathiaz: ah, cool; you rock
* dholbach hugs pitti
<StevenK> pitti: So the new package ought to be nvidia-glx, or nvidia-glx-all or nvidia-glx-unified?
<dholbach> bigon: one more thing: maybe we should change the branch to the one LP in debian/control?
<pitti> StevenK: -glx preferably, with C/R/P:'ing the others
<dholbach> bigon: unless we can sync completely?
<StevenK> pitti: *nods*
<StevenK> pitti: I seriously doubt it would fly for Gutsy
<ion_> pitti: https://launchpad.net/hardware-connected should help with the scripting part of making a package choose the correct nvidia driver version at runtime.
<superm1> ion_, still, but how do you get around the versions of all the other libraries that are shipped in those packages?
<superm1> adjust lots of symlinks on the fly?
<bigon> dholbach: done
<ion_> superm1: Yeah, thats what update-alternatives(8) is for.
<dholbach> bigon: rock
<bigon> dholbach: there still not merged ubuntu changes so we can sync
<dholbach> bigon: we can't sync at the moment, because of the different conflicts/replaces, no?
<superm1> currently no support under update-alternatives for all of the libGL family though, so that would need to be added as well, but does sound sensible
<bigon> dholbach: yes but there are also haze tp profile that are not yet in debian packages
<dholbach> bigon: right, yeah
<superm1> paran, pitti the nvidia-supported script in restricted-manager only generates listings for 'nvidia' and 'nvidia_legacy', so it would appear that restricted-manager isn't even offering support as of yet for the nvidia-glx-new stuff
<pitti> superm1: /usr/share/linux-restricted-modules/2.6.22-11-generic/modules.alias.override/nvidia
<pitti> superm1: that's shipped by l-r-m itself, as I said above
<ion_> superm1: Bug #134245
<ubotu> Launchpad bug 134245 in linux-restricted-modules-2.6.22 "[gutsy]  restricted driver namager claims 2 nvidia drivers in use" [Undecided,In progress]  https://launchpad.net/bugs/134245
<superm1> ah okay and that file is looking identical to what was generated by nvidia_supported in the restricted manager source package.
<bigon> dholbach: what will you doing with bug #132928 ?
<ubotu> Launchpad bug 132928 in devscripts "debcommit: add options to specify changelog path" [Unknown,Fix committed]  https://launchpad.net/bugs/132928
<dholbach> bigon: http://launchpadlibrarian.net/8856581/devscripts_2.10.7ubuntu2.diff3 is in debian svn then?
<geser> bigon: have you talked with StevenK about it as he cares about devscripts for now?
<bigon> geser: no I dont
<bigon> dholbach: is checking
<mvo> cjwatson: how card will it be to add the feisty-backports/debian-install release-upgrader udebs on the alternative CD to support pre-requists on the CD?
<cjwatson> mvo: trivial, stick them in a new section in the ship seed
<cjwatson> or maybe the installer seed
<mvo> cjwatson: nice! thanks, I will check that out today
<cjwatson> probably ship
<cjwatson> mvo: yeah, should be ship as otherwise dependency expansion will do bad things to the installer seed's output
<cjwatson> mvo: oh, hang on. feisty-backports.
<dholbach> bigon: the empathy patch looks good otherwise
<cjwatson> ok, that's actually sort of annoying
<cjwatson> mvo: it'll probably have to be a debian-cd patch
<dholbach> bigon: going to upload in a bit, might take a bit for the new binaries to go through binary new though
<bigon> dholbach: ok
<dholbach> bigon: let me know if you confirmed that the devscripts upload is ok
<dholbach> bigon: for command line changes, I'd be happier if they were made upstream first
<mvo> cjwatson: ok, thanks
<cjwatson> mvo: do they need to be in the CD's Packages files?
<cjwatson> in fact, do you need separate Packages files for them?
<cjwatson> as in /dists/feisty-backports/...
<bigon> dholbach: the cmd line option has been change in debian svn too (i'm sure) what I'm not sure is that the patch is _exactly_ the same
<dholbach> bigon: if you could check, I'd appreciate that and upload ASAP
<mvo> cjwatson: some form of packages file for them would be good as the release-upgrader searches for them within the apt cache and also checks the signatures via the regular apt mechanisms. but this could be worked around for the CD if required (its very handy for the network bits)
<dholbach> bigon: I just want to know if it's ok that your change is going to be assumed as 'is in debian already', when somebody does a merge
<cjwatson> mvo: the phrase "argh" comes to mind, but I'll see what I can do. could you file a bug on bugs.launchpad.net/ubuntu-cdimage so that I don't forget?
<mvo> cjwatson: yes, I will dig into it a bit and file a bug
<pitti> BenC: do you happen to know if the Intel 4965 WiFi chipset works under Linux?
<BenC> pitti: using it right now :)
<pitti> BenC: oh, cool :) thanks
<BenC> supported by the iwl4965 driver in gutsy's lum package
<pitti> BenC: (just looking for a new laptop)
<bigon> dholbach: I've made a patch with changes directly taken from the debian svn (for bug #132928)
<ubotu> Launchpad bug 132928 in devscripts "debcommit: add options to specify changelog path" [Unknown,Fix committed]  https://launchpad.net/bugs/132928
<dholbach> BenC: do you think I should assign review bugs for the kernel team to canonical-kernel-team instead of ubuntu-kernel-team?
<dholbach> bigon: you rock
<BenC> pitti: might I suggest the dell xps m1330
<pitti> BenC: I'm currently looking at the Latitude D430
<pitti> BenC: I want a 12" one
<BenC> dholbach: mainly we did that for private bugs, but I don't see why we couldn't use it to highlite bugs
<bddebian> *cough*
<BenC> pitti: the 1330 is a 13", but it's really light (sub 2lbs)
* dobey hugs his 10"
<dholbach> BenC: thanks a lot - it's not that many bugs coming that way anyway
* Hobbsee wonders how to find out what is using a particular module
<bddebian> Doesn't lsmod show relationships?
<pitti> BenC: how long does the battery last?
<Hobbsee> bddebian: hmm
<BenC> pitti: I have the low-end battery, and it's 2:10
<BenC> pitti: they have three battery options for it, I would guess max is probably 5-6 hours
<pitti> BenC: ah, nice; I have a list of candidates, and I throw away everything < 5 hours
<dholbach> bigon: uploaded
<BenC> pitti: it has webcam and finger-print reader options too, and you can also get 3g card for it
<bigon> dholbach: thx
<dholbach> bigon: thank YOU
<BenC> internal 3g, not like a cardbus card
<dobey> hola dholbach
<dholbach> heya dobey
<dobey> how's it goin?
<dholbach> dobey: good good - how are you?
<dobey> doing alright
<dobey> pondering on how to architect this rss parsing code a bit
<dobey> and what to get for lunch
<dobey> and i'm starving, so thinking about code is hard right now :P
<dobey> bbiab, later
<dholbach> hehe, enjoy your meal :)
<edulix> hi
<edulix> networkmanager - is there any of its developers over here?
<doko> Riddell-awa: I left some bug reports open as exercise for the kubuntu team (build failures with 4.3 in core kde packages) ;-)
<Hobbsee> doko: so i noticed.
<Hobbsee> doko: and the trick to fixing them is?  (disclaimer:  hvae only seen titles fo the bug reports so far)
<bddebian> Oh crap Riddell..  Hmm, what package was that again...
<doko> Hobbsee: I assume these should be already fixed in kde4 (Riddell told me that this is test-built against newer g++ versions), so maybe look in the upstream archives?
<Hobbsee> ah right, so there is no quick-fix, per se
<doko> Hobbsee: maybe for the kde packages (missing includes), but afaik you have your own repo, and there are still other packages to fix ..
<Hobbsee> doko: true.  i was more asking in the general case, rather than for each kde app specifically
<doko> Hobbsee: different bugs in different packages,
<Hobbsee> doko: true, i was wondering if the fix was the same in all cases.
<doko> and I hate to figure out what to patch in qt, what does generated, and so on ...
<Hobbsee> right
* Hobbsee yay's at being the viliage idiot.
* doko *grins*
* norsetto is away: Gone away for now.
<pitti> doko: wow, taking over the archive again? :-)
* pitti hugs doko
<Hobbsee> it seems to be a race of who can take over gutsy-changes - doko or pitti
<doko> Hobbsee: doing just maintainer change uploads is unfair ;-P
<Hobbsee> hehe
<geser> pitti: have you time to upload boost? bug #134684
<ubotu> Launchpad bug 134684 in boost "Upgrade to Version 1.34.1" [Wishlist,In progress]  https://launchpad.net/bugs/134684
<doko> pitti: did I ask for ecj -2, not -5?
<doko> the sync
* norsetto_limbo is away: Gone away for now.
<pitti> doko: I just synced whatever was in sid
<pitti> doko: if it's wrong, please file a sync bug or ask Mithrandir/seb128, I need to leave for Taekwondo now
<doko> Mithrandir: please sync ecj 3.3.0+0728-5 (bug 138542)
<ubotu> Launchpad bug 138542 in ecj "sync request" [Undecided,New]  https://launchpad.net/bugs/138542
<geser> keescook: Hi, do you see any reason why bug #91426 should be kept marked as private/security issue?
<ubotu> Bug 91426 on http://launchpad.net/bugs/91426 is private
<keescook> geser: no idea.  weird.
<geser> ok, then I'll make it private
<geser> s/private/public/
<xhaker> bdmurray, what about that ubuntu-qa membership?
<bdmurray> xhaker: I'm looking at it now. Thanks for the reminder.
* asisak was wondering why changelog does not indicate setting it private
<asisak> (BTW I was also convinced we are at -bugs based on the latest twenty minutes :))
<keescook> mjg59: around?  I was curious about bug #37234.  You mention that using SHMConfig is a security risk.  Is it larger than just local users being able to tweak the touch pad?  (i.e. does it allow them to reach into other memory areas?)
<pygi> doko, ping
<ubotu> Launchpad bug 37234 in xserver-xorg-input-synaptics "synaptics should allow runtime configuration (eg. Option SHMConfig on)" [Wishlist,Confirmed]  https://launchpad.net/bugs/37234
<pygi> Your final survey is in there. Not the one we need from your mentor.
<pygi> It is now past due and we will need to enter it. If you have not already
<pygi> done so please contact your mentor and let him know that we have still not
<pygi> received your final evaluation and it will have to be entered in.
<pygi> Thanks,
<pygi> Tiffany G
<pygi> ergh, sorry :D
<pygi> :-/
<pygi> apologies
<bdmurray> xhaker: could you join ubuntu-bugs?
<xhaker> bdmurray, ubuntu-bugs seems to be "invite" only
<bdmurray> The irc channel #ubuntu-bugs ?
<keescook> bryce: do you know where I can find the source for the synaptics driver?  Is it in xorg-server?
<keescook> ah, duh: xserver-xorg-input-synaptics
<ogra> :)
* ogra was about to say that :)
<keescook> heh.  clearly I need more coffee.  :)
<pygi> siretart, poke
<tormod> keescook: can I bug you with some ubuntu-main-sponsor'ing? I have some debdiffs lost/stuck in the queue, some should really be in before Gutsy release...
<keescook> tormod: sure, which bugs?
<tormod> bug #127273
<ubotu> Launchpad bug 127273 in laptop-mode-tools "laptop-mode init script links not created" [Undecided,Confirmed]  https://launchpad.net/bugs/127273
<tormod> bug #114793, bug #131858, bug #83690 (ok, the last one is not so critical)
<ubotu> Launchpad bug 114793 in linux-wlan-ng "linux-wlan-ng fails compilation" [Medium,Triaged]  https://launchpad.net/bugs/114793
<ubotu> Launchpad bug 131858 in grub "Update-grub does not add savedefault anymore" [Undecided,New]  https://launchpad.net/bugs/131858
<ubotu> Launchpad bug 83690 in grub "update-grub hardcodes to 'Ubuntu'" [Undecided,Confirmed]  https://launchpad.net/bugs/83690
<tormod> keescook: the three first are no-brainers, they just need a little push :)
<keescook> tormod: okay, I'll go look through them (just need to finish up a few other things first)
<tormod> keescook: thanks a lot!
<keescook> tormod: np :)
<keescook> tormod: I'd like to let mjg59 handle 127273 -- I'm not sure what is "correct" for the acpi script removal.  he'd know better.
<keescook> tormod: 114793 will need a UVFe, but that should happen without too much issue, I think.
<tormod> keescook: can you give mjg a ping about 127273? he seems to have forgotten about it.
<keescook> tormod: I think we already have now (he's online in this channel)  :)
<tormod> keescook: 114793, UVF would be much better than patching the outdated Ubuntu version. The problem is that few developers have the card themselves so few know the package: trust Debian and me :)
<keescook> tormod: yeah, I trust you for 114793 -- that's why I think the UVFe will go fine.  I just can't help with it personally -- I'm not on the UVFe team.  :)
<keescook> the two grub updates look fine to me.
<tormod> keescook: any suggestion for who to ask about 114793? It's been in the u-m-s queue since June...
<keescook> tormod: for that, I think you'll need to subscribe ubuntu-release and explain the situation (https://wiki.ubuntu.com/FreezeExceptionProcess)
<keescook> once they've ACK it, then a core-dev can upload it.
<keescook> tormod: grub fixes uploaded though.  I really like the title fix.  :)
<tormod> keescook: thanks!
<keescook> np
<tormod> keescook: just added UVF rationale to 114793. damn bureaucracy :)
<keescook> hehe, yeah.
<keescook> okay... late lunch time!  back in a bit...
<tormod> keescook: enjoy your meal :)
<siretart> pygi: huh?
<pygi> siretart, just wanted to say I've committed cdrkit support in Gnomebaker
<siretart> pygi: cool!
<pygi> siretart, ofcourse that's only in svn (not released)
<pygi> but it works pretty nicely
<pygi> siretart, it has a user preferences part where you can choose what to use if you have both cdrtools and cdrkit installed
<siretart> ah. I see
<siretart> well, I assume its mostly a matter to call the right tool. the commandline interface should be the same, ain't it?
<pygi> siretart, a tiny difference in addressing the devices if I'm not mistaken
<siretart> aha?
<pygi> bus,target,lun not working any more or something like that since 1.1.5 I think
<siretart> oh. thats... interesting
<pygi> siretart, I do remember tsmetana of fedora was telling me something about that
<mdke> can anyone help with this build error: http://paste.ubuntu-nl.org/37052/ ?
<stdin> mdke: is there a configure script?
<mdke> stdin: I don't really know anything about how the package works, lemme see
<mdke> there is a configure.in
<stdin> I think that'll be for autoconf to make the configure script
<mdke> stdin: yes
<mdke> any idea on the error?
<thom> mdke: ***Error***: You must have automake >= 1.9 installed
<thom> do as it says :)
<mdke> thom: hmm. guess the build-deps are wrong
<thom> guess so
<mdke> or maybe that doesn't count as a build dep
<mdke> I'll try, thanks
<thom> well, it's a dependency for it to build, so it definitely is
<mdke> thom: I think perhaps that is more building the source package, rather than the binary
<mdke> anyway, seems to have worked :)
<tormod> keescook: just saw that 114793 was assigned to canonical-kernel-team today, it's been assigned around in circles forever... Also very reassuring since their home page says "Do not use this team, use ubuntu-kernel-team instead."
* tormod is off to bed
#ubuntu-devel 2007-09-11
<mjg59> keescook: Any user can access arbitrary areas of memory that X has access to given SHMConfig, IIRC
<pygi> mjg59, are you open for a little kernel-related question at this early hours?
<mjg59> keescook: The driver should just be fixed to handle stuff based on X auth tokens, like Wacom does
<keescook> mjg59: agreed about the "needs fixing", however, afaict, the SHMConfig option of the synaptic driver "only" lets people muck with the synaptics settings. (I sent some email about it)
<mjg59> keescook: I still don't consider that an acceptable risk. Careful choices would allow arbitrary X input.
<mjg59> (Just limit the coordinate space to the thing you want clicked)
<mjg59> pygi: Sure
<keescook> mjg59: agreed, though I wasn't too sure how that could work, after I looked at the code.
<pygi> mjg59, are you aware of any problems with VIA VT6240 SATA controller perhaps due to a kernel/driver bug?
<mjg59> pygi: Not to the best of my knowledge
<pygi> mjg59, ok,thanks
<mjg59> keescook: Anyone with local access can effectively set arbitrary constraints on the touchpad coordinates and how they correspond to the screen. It pretty much means you can control where their next mouse button click is going to be
<calc> i'm getting failed to upload errors for ooo and ooo-l10n
<calc> is that due to a freeze or something else?
<keescook> mjg59: fair enough.
<mjg59> keescook: So you have an excessive quantity of influence over what the user can do, which is kind of bad
* keescook nods
<mjg59> (Though Intel have been buying me Tequila tonight, so you might not want to believe anything I say)
<ion_> Oh, i hadnt even noticed xorg 7.3 was released last week. Input hotplug 
<mthaddon> just got a "FATAL: Error running install command for nvidia" after latest gutsy upgrade for nvidia-glx - is it just me?
<mthaddon> or rather, my X server crapped out and after some recovery (gtk-displayconfig not too successful for me) and manually trying to load the nvidia module I get that (trying to see what errors it was giving)
<mthaddon> sorry, just read the topic header... will head over to #ubuntu+1
<f0rqu3> is there a newer fglrx package available?
<f0rqu3> 8.40 for example
<f0rqu3> the one in the repo is 8.34 :(
<dobey> f0rqu3: in the repo for feisty?
<f0rqu3> yes
<dobey> there might be a newer version available for gutsy
<f0rqu3> gutsy is older?
<bhale> no. newer
<dobey> why would there be a newer version of something in an older repo? :)
<f0rqu3> lol
<f0rqu3> fail
<f0rqu3> can I add its repo to feisty?
<zul_> no
<dobey> fglrx is probably bound to the kernel
<dobey> so that might be a bad idea
<dobey> if there's a compelling reason to release an update for feisty, it's probably best to file a bug detailing that reason, and requesting it be done
<f0rqu3> probably I will compile it myself when the 8.41 releases
<mekius> hi, when the live first boots up you get a menu, where are the settings/images for this menu?
<mekius> i would like to modify it
<mekius> any help is appreciated
<kagou> Good Morning :)
<pitti> Good morning
<StevenK> Morning pitti
<mdke> hi StevenK, I was reading on your interview that you're interested in working on a new about window; do you happen to have a spec or something already?
<StevenK> mdke: Sure. There are two specs, and some code on LP.
<mdke> StevenK: can you give me the details?
<StevenK> mdke: Looking it up now.
<mdke> btw you might already know this, but mpt did some similar work a few cycles back. I don't know how far he got, but it's probably worth touching base with him, unless you have already
<StevenK> Hold on, OTP
* mdke nods
<pitti> hey StevenK
<Lure> pitti: morning
<Lure> pitti: libgphoto2 is in my ppa, but I have at least one regression report, so I am not sure anymore we want to push it
<Lure> pitti: and the condition in postinst was wrong, so it is fixed now in merged package
<pitti> Lure: oh, what broke? if it's too bad, it's worth filing a bug upstream, they are pretty responsive
<pitti> so that it's sorted out with the opening of hardy
<Lure> pitti: <allee> Lure: bad news about libgphoto2 2.4.0 (with cannon powershot A40). gphoto2 --auto-detect -L works once, next try hangs after autodetecting :( 2 x Ctrl-c to hard abort. Then it works again, 2nd hangs. etc. I see same in digikam :(
<pitti> sjoerd: any idea why python-avahi contains SimpleGladeApp.py and depends on python-glade? it pulls in an awful lot of Glade/X11 dependencies but doesn't actually use any of it
<Lure> pitti: it works for me for Canon G3 (UMS) and 400D (PTP)
<pitti> hey mvo
<Lure> pitti: will talk with allee to check with upstream
<Lure> pitti: and try to find some more testers with other digital cameras
<mpt> mdke, StevenK's code is a rewrite of my code
<StevenK> Right, off the phone for a moment
<mpt> https://code.edge.launchpad.net/about-window
<StevenK> mdke: Sorry about that - the two specs are: https://blueprints.launchpad.net/ubuntu/+spec/about-ubuntu (which is mpt's) and https://blueprints.launchpad.net/ubuntu/+spec/about-ubuntu-revisited (which is mine)
<mdke> mpt: excellent; that's fine, I was just checking
<mdke> StevenK: there are two things I wanted to ask you about it. (1) was whether you have been thinking about merging the gnome and ubuntu about dialogues; I think it's confusing to have both, especially because your average user won't know what Gnome is. (2) was whether you can keep the documentation team in the loop about your project, especially in terms of how much of the existing document you're using, whether you envisage it remaining available in so
<StevenK> pitti has also had a poke around the code.
<mdke> Ill read the specs now
<StevenK> mdke: I've been thinking about that - so far, the current Python code fires off hal-device-manager - perhaps it should fire up yelp.
<dholbach> good morning
<mdke> StevenK: on (2)?
<StevenK> mdke: This neatly allows people to see quickly what version and so on they're running, but also lets them see more information.
<StevenK> mdke: Yup.
<mdke> morning dholbach
<mdke> StevenK: could be.
<mpt> StevenK, what's the use case for the "More Information" link?
<StevenK> mdke: Merging the Gnome and Ubuntu about dialogs I've not thought about, and secondly, that leaves Kubuntu and so on out in the cold.
<dholbach> hey mdke
<mpt> Kubuntu would, presumably, want a Qt About window :-)
<mvo> good morning pitti
<StevenK> Of course. I've modarlised the code so they can have one.
<mdke> StevenK: ok, let's think about it :)
<StevenK> mpt: You removed the More Information button from your spec, if I recall.
<mpt> StevenK, I don't remember whether it was ever there
<mpt> it may have been
<mdke> the Gnome/Ubuntu branding conflict is something I've come up against in documentation too; we reuse quite a lot of Gnome documentation, and I find it really confusing to have some documents continuously referring to "the Gnome desktop" when ever since the user has turned the computer on it's been branded as Ubuntu
<mpt> but I don't think it's useful
<mdke> but I don't know what the policy is with upstream and us about branding, I think it needs discussion
<mpt> Much of what's in the about page would make more sense in one or two help pages.
<MacSlow> mvo, dholbach: the workspace-mapping between compiz and metacity is a mess... that and #122549 are keeping me very busy for some days to come I'm afraid
<mdke> StevenK: anyway, just wanted to flag those things up so that we can think about / discuss them
<dholbach> bug 122549
<ubotu> Launchpad bug 122549 in compiz "[gutsy]  compiz fusion breaking gnome-screensaver behaviour" [High,Confirmed]  https://launchpad.net/bugs/122549
* dholbach hugs MacSlow
<mdke> dholbach: congrats on the new job, that's awesome
<dholbach> thanks a lot mdke :)
<StevenK> mdke: Sure. Scribble all over https://wiki.ubuntu.com/AboutUbuntuRevisited if you wish.
<mdke> StevenK: will do
* StevenK subscribes to the page so he knows when mdke scribbles. :-)
<sjoerd> pitti: It's what upstream ships inside the avahi module... But yeah it's a bit silly indeed
<holycow> hey guys
<allee> Lure, pitti: about gphoto problem: http://sourceforge.net/tracker/index.php?func=detail&aid=1791834&group_id=8874&atid=108874 no responds yet.  I've to wait for gerhard the canon expert
<ubotu> Sourceforge bug 1791834 "Powershot A40: 2.3.1 -&gt; 2.4.0 regresssion:  gphoto2 -L hang" [Pri: 5,Open] 
<Lure> allee: thanks for link - I have just send the request to mailing list as well
<pitti> sjoerd: so we could really remove the SimpleGladeApp.py and the dependency; I got a mail from someone wanting to use it for PXE, and those dependencies really hurt him
<sjoerd> python for PXE ? :)
<sjoerd> But well, yeah
<pitti> > mDNS package sharing would be very useful for the PXE clusters
<pitti> > we are running, but the x11 dependency kinda spoils the fun.
<pitti> sjoerd: thin clients, I assume
<sjoerd> I'll talk to lennart about moving SimpleGladeApp into avahi-discover
<sjoerd> aah
<sjoerd> That's about the only thing that uses it i guess..
<sjoerd> Maybe the service-applet too
<mdke> StevenK: lp does the subscribe to wiki page bit automatically on the spec
<StevenK> mdke: Ah
<mdke> they think of everything :)
<stdin> is there any reason that ubuntu-desktop and kubuntu-desktop need to share ~80 depends/recommends? why not put them in ubuntu-standard?
<\sh> guys, compiz and X are going mad somehow since the last update
<tepsipakki> \sh: in what way?
<Amaranth> \sh: nvidia?
<stdin> hmm, and things like acip, acpid, cups and hal really should be in -standard
<\sh> Amaranth, standard radeon (xorg driver)
<\sh> mouse movements are totally fast, or when you setup the mouse movement in gnome mouse config it's too slow
<Amaranth> and turning off compiz fixes this?
<\sh> and since the last startup (this morning) with compiz-fusion, background is black
<\sh> disabling compiz it's back to normal, but not the mouse movement
<Amaranth> ok, so i only need to figure out the black background :)
<Amaranth> \sh: is it just black or do you get ghosting too?
<\sh> oh....mouse acceleration settings in gnome-mouse-config isn't saved
<\sh> Amaranth, just black background
<Amaranth> hmm
<Amaranth> do you use the wallpaper plugin?
<\sh> Amaranth, nope
<Amaranth> hmm
<\sh> Amaranth, standard ubuntu background
<Hobbsee> good evening sabdfl
<\sh> Amaranth, I just removed all my .gnome* dirs and .gconf* dirs
<\sh> to be sure, it's not a wrong gconf setting or whatever
<Amaranth> \sh: try changing...oh
<\sh> seb128/dholbach: gnome-mouse-settings are not saved correctly, and it looks like only mouse acceleration is not saved
* \sh is going to have a cigarette now...and getting a new coffee...
<Amaranth> \sh: what is your screen resolution?
<dholbach> \sh: I told you that I don't know much about it - best to file a bug
<\sh> Amaranth, 1280x1024
<cjwatson> mekius: mostly in gfxboot-theme-ubuntu, though there are some extra files in /isolinux/ on the CD
<Amaranth> \sh: glxinfo -l | grep MAX_TEXTURE_SIZE
<\sh> Amaranth, 2048
<Amaranth> ok, that's not it
<Amaranth> \sh: wait, do you have a desktop manager running?
<Amaranth> nautilus, kdesktop, etc
<tormod> grub is now built on all platform (instead of just i386 and amd64) and fails on sparc,powerpc,ia64. should something be changed to avoid trying those builds? (the latest upload didn't change anything in that respect)
<\sh> Amaranth, the standard gnome stuff from scratch
<\sh> Amaranth, no kde , no other unsual stuff...plain gutsy
<Amaranth> so nautilus is showing a desktop
<Amaranth> i mean, you have icons and junk, right?
<Amaranth> just no wallpaper
<\sh> Amaranth, I have the menu bar , no icons on the desktop, background is black
<\sh> the panels are there, I can see windows with decorations
<Amaranth> do the icons come back when you kill compiz?
<Amaranth> or do you just not have them at all?
<\sh> Amaranth, when I disable effects  in the appearance configuration it all comes back
<Amaranth> \sh: ok, when compiz is running kill nautilus
<Amaranth> it'll restart
<\sh> Amaranth, oh sorry...right now I see that I don't have any window decoration buttons...just the window decoration itself, with no buttons
<Amaranth> o_O
<Amaranth> ok, i'm now blaming this on X :P
<Amaranth> do windows sometimes come up blank too?
<\sh> Amaranth, I just restarted the desktop effects (normal) and I have everything back but not the icons and background
<Amaranth> ok then, try killing nautilus
<\sh> Amaranth, done
<\sh> Amaranth, no nautilus{*} in my process list anymore
<\sh> and no restart of nautilus
<Amaranth> weird, gnome-session should have restarted it
<Amaranth> start it manually then
<\sh> ah background and icons are back
<Amaranth> now stop and start compiz again
<Amaranth> see if it happens again
<asac> siretart: ... managed to reproduce already? do you need any infos?
<\sh> Amaranth, ok...system->administration->appearance-> no effects == window deco is there, no metacity fallback, no buttons in the deco
<Amaranth> err
<Amaranth> no effects _is_ metacity
<\sh> Amaranth, with disabled effects, there is no key accelerators anymore (so no changing of desktops) no alt-tab is working nothing
<Amaranth> ok, that's just weird
<\sh> Amaranth, setting to normal effects brings back deco and buttons and key accells
<Amaranth> metacity is freaking out?
<\sh> metacity is running when I set to no desktop
<Amaranth> and it's broken?
* Hobbsee wonders why we disable automounting in hal
<\sh> yepp
<Amaranth> this is new
<\sh> metacity --replace I can see in my process list
<Amaranth> and also not something i know how to debug :P
<Amaranth> so when you use metacity your window decorations are broken and no key accels works
<\sh> Amaranth, hmm..the mouse is freaking out on all machines I have....gnome-mouse-settings is not saving the mouse accell...I'll file a bug, since it could be also the kernel, just because everything what's here is usb ...and even key repeat doesn't work anymore
<\sh> Amaranth, right
<Amaranth> sounds like you've got some more fundamental low level problem
<\sh> well, on the console everything works normal
<Amaranth> i meant with X
<\sh> so it's not the kernel with some strange usb issue...
<Amaranth> if metacity is broken then something is going really wrong
<\sh> Amaranth, looks like...
<\sh> I'll file a bug against xorg because of the mouse slow motion and keyboard probelms
<dholbach> Keybuk: what do you think about the patch in bug 57755 and putting it into udev? it'd be nice if this would get included... somewhere
<ubotu> Launchpad bug 57755 in gnupg "Udev Rules for SmartCard Support" [Undecided,New]  https://launchpad.net/bugs/57755
<dholbach> lamont: shall I prod you about bug 33586 again? :)
<ubotu> Launchpad bug 33586 in nmap ".desktop file cleanup for nmapfe" [Wishlist,Incomplete]  https://launchpad.net/bugs/33586
<dholbach> iwj: does the patch in bug 135086 look ok?
<ubotu> Launchpad bug 135086 in unzip "zipgrep: exit code always 0" [Medium,Triaged]  https://launchpad.net/bugs/135086
<\sh> bug 138826
<ubotu> Launchpad bug 138826 in xorg "[gutsy]  since last update of xorg mouse is in slow motion or too fast to see" [Undecided,New]  https://launchpad.net/bugs/138826
<\sh> dholbach, what's the right package for this gnome-mouse-settings applet?
<\sh> ah capplets-data
<dholbach> gnome-control-center
<\sh> yepp
<\sh>  bug 118593
<ubotu> Launchpad bug 118593 in gnome-panel "mouse preferences acceleration not saving" [Undecided,Invalid]  https://launchpad.net/bugs/118593
<\sh> already reported...
<dholbach> calc: will you include the patch of bug 134112 in your next ooo upload?
<ubotu> Launchpad bug 134112 in openoffice.org "added Xb-Npp-xxx tags accordingly to "firefox distro add-on suport" spec" [Undecided,New]  https://launchpad.net/bugs/134112
<geser> can someone sponsor uploading boost? bug #134684
<ubotu> Launchpad bug 134684 in boost "Upgrade to Version 1.34.1" [Wishlist,In progress]  https://launchpad.net/bugs/134684
<Hobbsee> ew
<Hobbsee> oh, pitti's approved that.
<tormod> mjg59: are you happy with bug 127273 now?
<ubotu> Launchpad bug 127273 in laptop-mode-tools "laptop-mode init script links not created" [Undecided,Confirmed]  https://launchpad.net/bugs/127273
<geser> Hobbsee: yes, it's approved already, I need now someone to upload it.
<slytherin> Can anyone tell me who maintains language-support packages? There is an unnecessary dependency in language-support-en. It depends on thunderbird-locale-en-gb but we don't ship thunderbird on CD now.
<pitti> slytherin: *raising hand*
<pitti> slytherin: however, the dependency is correct in terms of what language-support-XX is supposed to do
<pitti> slytherin: the problem might rather be that we do not actually want to ship the entire l-s-en on the CDs
<slytherin> pitti: As of now, we ship thunderbird-locale-en-gb on CD where as we don't ship thunderbird. Does it make sense?
<pitti> slytherin: in a way, yes; l-support-XX ships extra translations which aren't part of the language packs; the language packs ship a lot of translations for software which is not on the CD
<slytherin> pitti: Will be back in 15-20 minutes
<StevenK> pitti: I shall look at moving requestsync later tonight.
<pitti> StevenK: ah, good
<StevenK> pitti: I think it's a matter of uploading devscripts ubuntu3 that drops it, and adding C/R devscripts (<< 2.10.7ubuntu2) along with requestsync to u-d-t
<pitti> StevenK: << ubuntu3, yes
<asac> strange ... valgrind appears to be broken for me :/ anyone else sees this? http://pastebin.mozilla.org/197295
<calc> dholbach: its already in the one stuck in 'failed to upload'
<pitti> mjg59: meh, you forgot to commit your hal changes to bzr, doing that now
<dholbach> calc: ok, I didn't know just looking at the bug
<calc> pitti: is ooo/ooo-l10n stuck in 'failed to upload' due to a freeze or something else?
<dholbach> but good to know you're on it
<calc> dholbach: np
<pitti> calc: no, that's usually a bug; I guess the recent LP update overwrote my disabling of that dpkg Pre-Depends: check
<pitti> calc: give me some minutes to finish my current task, then I'll hack it in again and reprocess your uploads
<StevenK> pitti: And hit up the Launchpad guys to fix it? :-)
<mjg59> pitti: Hrm, sorry - I could have sworn I did
<dholbach> pitti: shall I move requestsync to ubuntu-dev-tools?
<mjg59> Did I commit one set and forget the second?
<pitti> dholbach: StevenK was about to, but sure
<pitti> mjg59: yes, only the last one (63_my_dbus_is_full_of_uints.patch)
<StevenK> dholbach: I've started on it....
<dholbach> StevenK: alright
<mjg59> pitti: Ah, right - sorry about that
<pitti> mjg59: the rest (before Fabio's upload) is in
<pitti> mjg59: no problem
<mjg59> pitti: I find the process of having the debian directory in bzr but not the rest of the package kind of awkward in this sort of case
<pitti> mjg59: did you take all those patches from upstream git? or is there anything still to be forwarded?
<mjg59> pitti: No, upstream is consistent
<pitti> great
<pygi> doko, any progress?
<Keybuk> dholbach: invalid, as it uses a group not in base-files
<dholbach> Keybuk: hm, ok
<Keybuk> as Tollef says, the rules are shipped with libccid
<dholbach> geser: ^ what do you think we should do with the patch?
<pitti> I guess people wouldn't bite me if I asked for a FF exception for bzr 0.90?
<pitti> StevenK: hit LP guys> that bug report already exists
<StevenK> pitti: Ah
<pygi> pitti, why would they? we do need bzr 0.90
<pygi> if I ain't mistaken 0.91RC will be out today?
<pitti> pygi: well, not exactly 'need', but it would certainly be cool
<pitti> would be quite a shame not to ship the latest stable
* pitti goes to test it
<geser> dholbach, Keybuk: gnupg does support some smart card readers directly. All is needed are the right permissions that gnupg can access it. The rules from libccid (which is no dependency of gnupg) need pscsd as they tell it about the new device.
<geser> so there are conflicting rules for some smart card readers depending on how one intends to use it
<Keybuk> geser: so the rules should be shipped in the packages?
<geser> Keybuk: preferable, but as gnupg and gnupg2 benefit from them I don't know where exactly it should get shipped
<Keybuk> me neither
<Keybuk> I think that the current policy of tending towards a unique group for every unique type of device is wrong anyway
<Keybuk> it's an awesome maintenance burden
<pitti> geser: until we get the full magic of CK+hal changing device permissions, using 'plugdev' seems appropriate to me
<geser> scard was suggested on the gnupg site (or some tutorial) to not allow everybody access to the smart card reader, but plugdev should also work
<Keybuk> "console users have permission to use all connected USB devices" \o/
<geser> Keybuk: any better ideas?
<pitti> Mithrandir, Hobbsee, cjwatson: can either of you take a look at bug 138858? I don't want to approve my own requests
<ubotu> Launchpad bug 138858 in bzr "FF exception request: bzr/bzrtools 0.90 for gutsy" [Undecided,New]  https://launchpad.net/bugs/138858
<geser> gnupg{,2} need only access to the usb-connected smart card reader, libccid and/or pcscd isn't needed
<Mithrandir> pitti: does it conflict with anything using the removed APIs?
<Keybuk> geser: ship rules inside gnupg?
<Keybuk> though those would conflict with those in libccid, no?
<Mithrandir> geser: hm, does that work with the ssh-agent in gnupg-agent?
<pitti> Mithrandir: not in the packaging; I'll check bzr-gtk and bzr-svn
<Mithrandir> pitti: if any of those use the removed APIs, I think we should add appropriate Breaks
<pitti> Mithrandir: ah, ignore me; they already have versioned bzr dependencies
<Keybuk> geser: probably better to just wait for the HAL/CK method
<pitti> Mithrandir: so we need to sync bzr-gtk as well
<Mithrandir> pitti: ok, sounds good to me then.
<geser> Mithrandir: after modifing /etc/X11/Xsession.d/90gpg-agent to start gpg-agent with --enable-ssh-support I can use my OpenPGP card for ssh authentication
<Mithrandir> geser: nice.
<geser> Keybuk: we would have then two rules files for the same device if that's no problem
<Keybuk> geser: that's a problem
<geser> Keybuk: any ETA when HAL/CK will be available? for hardy or later?
<Keybuk> hardy
<Mithrandir> Keybuk: why is that a problem?  The ccid rules mostly just do RUN+="pcscd --hotplug"
<pitti> geser: hardy; it already more or less works in gutsy
<Keybuk> Mithrandir: both also change modes/groups
<Keybuk> since I know that the behaviour may change in hardy, it seems foolish to add support now for something that we might break or alter in a few weeks time
<Keybuk> especially since this isn't a regression
<Hobbsee> geser: but does it do it for scp too?
<StevenK> scp uses ssh's authentication
* Hobbsee set it up that way, but....wait, my bad.
* Hobbsee looks for the dunce cap
<geser> Hobbsee: gpg-agent works also as a ssh-agent then, so you can use your gpg-key (if it has the auth capability) for ssh
<pitti> Mithrandir: ok, bug updated wrt. -svn and -gtk.
<Hobbsee> geser: yeah.  i knew that.  i'd had it working that wya once, but thought it wasnt working that way this time.  it turns out that i suck instead.
* Hobbsee was scp'ing to the host that didnt do key-based authentification, rather than any of the ones that did.
<Hobbsee> dunce cap material.
<geser> is a ubuntu-main-sponsor around who can upload bug #134684? it has already an approved UVFe by pitti
<ubotu> Launchpad bug 134684 in boost "Upgrade to Version 1.34.1" [Wishlist,In progress]  https://launchpad.net/bugs/134684
<dholbach> geser: I can do that
<geser> thanks
<pitti> Mithrandir: so if you are fine with this, can you please give your blessing in the bug?
<Mithrandir> pitti: done
<pitti> Mithrandir: cheers
<bigon> ScottK: are you there?
<ScottK> Yes
<bigon> ScottK: about tp-gabble, I don't see any uvfe request for the version 0.5.13
<ScottK> bigon: If this is about my latest reply, I was working via e-mail so it may have been on the wrong bug.
<bigon> ScottK: no problem with the reply, but you said in a previous comment that you had already an uvfe request but I don't find it
<ScottK> Ah.
<ScottK> Well in that case that would be the one I got wrong.
<Hobbsee> i thought there was one that had a second uvfe on it
<Hobbsee> not just cheese
<ScottK> bigon: I will confess that it's hard to keep all the telepathy packages straight in my head.
<bigon> Hobbsee: yep tp-gabble has 2 request, but not for the .13 which cause the regression
<Hobbsee> bigon: why does it have 2 requests?
<Hobbsee> oh, just 2x new upstream releases
<ScottK> We should probably take this to #ubuntu-motu as it's a Universe package.
<cjwatson> calc: please could you add the necessary Pre-Depends to ooo so that this stops happening, notwithstanding whether Launchpad is fixed?
<pitti> cjwatson: FWIW, I consider that needless ballast nowadays...
<cjwatson> calc: Pre-Depends: dpkg (>= 1.10.24) for any deb using a bzip2 data member
<cjwatson> pitti: I know, but it's better to have the ballast than to lose ooo binaries until such time as Launchpad is fixed
<pitti> calc: anyway, I have some time now, I'm going to rescue the current ones and reapply the LP hack
<pochu> does any archive admin has sync-day anytime soon?
<pitti> calc: hold on, it seems they already removed it; I can't find the test any more in production
<pitti> pochu: mine is on Friday; seb128 and Riddell are on holidays, so they won't do their's
<pitti> pochu: do you need something urgently?
<pitti> calc: ah, there it is, a grep revealed it; /me disables
<pochu> pitti: no, it can wait until Friday. I was just curious.
<sjoerd> pitti: Just talked to lennart. It's fine with him if SimpeGladeApp.py is moved to avahi-discover (IOW he's open to patches)
<pitti> sjoerd: ah, cool
<sjoerd> pitti: Will you do one ? Otherwise i'll probably prepare one later this week
<pitti> sjoerd: no time right now, maybe later; I'm not particularly interested in it, so I'd just file an upstream bug, I think
<sjoerd> ok
<sjoerd> I'll do one later this week then (upstream doesn't care to do it himself)
<pitti> calc: hm, I can't find the binaries anywhere
<pitti> calc: and the Pre-Depends: check is still disabled, so that wasn't it
<pitti> calc: did you get a rejection email?
<pitti> doko: FYI, I just fixed one of your pet bugs (bug 113145)
<ubotu> Launchpad bug 113145 in belocs-locales-bin "language-support-XX needs to be able to generate locales" [Medium,Fix released]  https://launchpad.net/bugs/113145
<lamont> dholbach: I'm curious about that patch... why did it need to build-depend gksu?
<mjg59> Does valgrind work for anyone at the moment? I'm getting vex amd64->IR: unhandled instruction bytes: 0x66 0x66 0x66 0x66
<elkbuntu> mjg59, asac mentioned something about it earlier
<elkbuntu> mjg59, http://pastebin.mozilla.org/197295
<elkbuntu> different error though, it seems
<mjg59> elkbuntu: Nope, same one
<elkbuntu> right, i only glanced, didnt see the same string you quoted
<mjg59> Line 10
<mjg59> Ok, so not just me. Turns out I'm not special.
<elkbuntu> aha. im going crossied folding leaflets for saturday
<elkbuntu> crosseyed*
<elkbuntu> well you and asac can go cry in a corner together at least :)
<pitti> hi mathiaz
<dholbach> lamont: it should depends, not build-depends
<lamont> dholbach: ok.  sadly, that permanently(?) forks it
<lamont> although with it being a Depend: not a build-depend I _could_ munge debian/control in the clean target... I so dislike debian/control.in files
<asac> elkbuntu: right ... its a painful especially because i wanted to fix crashes today
<dholbach> lamont: why?
<dholbach> lamont: debian uses gksu too, no?
<lamont> uh.. dunno.  does it?
<dholbach> to run a program as root, sure they do :)
* lamont uses 'sudo nmapfe' in an xterm....
<dholbach> gksu will make use of sudo in ubuntu and su in debian
<dholbach> so that should be fine
<asac> doko: maybe your binutils upload broke valgrind?
<lamont> dholbach: ah, ok
<lamont> where gksudo just uses sudo?
<asac> doko: like valgrind echo hallo (http://pastebin.mozilla.org/197295)
<pitti> calc: OO.o rescued, thanks to cprov
<calc> pitti: ok thanks :)
<calc> cjwatson: ok
<pitti> calc: pre-depends check was not yet disabled again when you uploaded first, but it's done now
<calc> pitti: oh ok, i'm guessing it will pop back up again next month?
<pitti> calc: let's hope that they fix it for good in RF by then :)
<calc> pitti: oh yea openoffice.org-l10n still shows failed to upload as well
<calc> oh now its good
<pitti> calc: known, cprov is reprocessing it as we speak
<calc> ah ok :)
<cprov> pitti: "fix it for good" is more like "break it hadly" because we will have to remove checks and tests, it can't be good :(
<cprov> https://edge.launchpad.net/ubuntu/+source/openoffice.org-l10n/1:2.3.0~rc1-1ubuntu1 -> rescued too
<bddebian> Heya
<calc> cprov: well that particular check/test is obsolete for several years now
<cprov> calc: it will get removed, no problem.
<calc> cprov: ok
* calc got business cards yesterday :)
<pygi> doko, around?
<mathiaz> BenC: did you get a chance to look at the apparmor patch for l-u-m I sent you on friday ?
<manchicken_> Are folks aware of this error in the flashplugin-nonfree installer: "update-alternatives: unable to make /usr/lib/midbrowser/plugins/flashplugin-alternative.so.dpkg-tmp a symlink to /etc/alternatives/midbrowser-flashplugin: No such file or directory"
<manchicken_> s/installer/package/
<bigon> manchicken_: see bug #138853
<manchicken_> Bot die?
<BenC> mathiaz: kylem handled all the apparmor stuff
<soren> calc: Cool! Then mine must be on their way, too! :)
<calc> network manager still sucks
<calc> it kills wired network connections on upgrade still it appears
<calc> or something does, i just upgraded my desktop in the other room and my network was dead when i tried to connect to it from my laptop
<pitti> cu later, I have an appointment now
<Kopfgeldjaeger> hi
<cjwatson> bryce: my new Dell laptop suffers from that notorious xresprobe bug where it buggers up the screen during installation; I can reproduce it reliably by booting into rescue mode and running '/usr/share/xresprobe/xprobe.sh intel'. Is there anything I can do to help you fix it?
<cjwatson> bryce: I tried adding vbetool save/restore stanzas before and after running X, but that didn't help
<doko> asac: which binutils version?
<asac> doko: latest? 2.18-0ubuntu2
<asac> doko: i haven't used valgrind for a few weeks ... so cannot tell if its related at all
<asac> doko: just a guess ;)
<doko> asac: hmm, so it worked with a pre-2.18 version?
<asac> doko: cannot say for sure ... i have recently upgraded my amd system to gutsy. before i only had an i386 gutsy
<asac> doko: but mjg59 complained today about valgrind as well ... so maybe its indeed a recent regression
<eugman> Normally I wouldn't ask in here but I honestly can't find the information. I want to turn a python game into a deb. However I can only find general packaging information. I don't know if I can do it with distutils somehow and where the data and lib files would end up were the game installed so I can change the script to be able to acess them.
<dobey> eugman: if you look at the solarwolf package, it's probably a good starting point
<eugman> Ok, so there isn't necessary a standard?
<dobey> there is the general debian packaging policy for python. i don't think there is anything more specific for "game written in python"
<dobey> i don't think ubuntu alters that policy, either
<dobey> eugman: http://www.us.debian.org/doc/packaging-manuals/python-policy/
<Mez> dobey, no,. ubuntu uses the debian python policy, i know cause i've been moaned at for not adhering to it
<dobey> Mez: yeah. ubuntu uses all the debian packaging policy. i don't think it is really deviated from much, if anywhere
<Mez> er, i think there are a couple of places (ubutnu specific maintainer fields mainly i think!)
<dobey> right
<eugman> ok well that and solarwolf probably covers what I need. I still don't know how to get a deb out of some python files and some data. Would I use destuitls?
<eugman> er distutils
<siretart> asac: hi
<siretart> asac: I have to say that since today, I also see these funny NetworkManager: <info>  SUP: response was 'TIMEOUT[CLI] ' messages in daemon.log
<siretart> asac: I've grepped through my logfiles, the started just today
<siretart> asac: and looking through my dpkg.log, I don't see something too fishy there either :/
<siretart> asac: well, I know you don't want to hear that, but when I compare dpkg.log and my daemon.log, these timeouts started after upgrading to network-manager 0.6.5-0ubuntu11
<siretart> so I'd suspect that upgrade causing the errors.
<siretart> hmmm.. and the changelog indicates that some code that might be relevant to the timeouts have been touched in that particular upload
<lamont> +TryExec=gksudo nmapfe
<lamont> +Exec=gksu nmapfe
<lamont> should those both maybe say 'gksu'?
<Amaranth> lamont: the TryExec should probably be _just_ 'gksu'
<lamont> TryExec=gksu
<lamont> Exec=gksu nmapfe
<lamont> like so?
* lamont makes gksu a Recommends: since nmapfe doesn't technically _require_ gksu
<Amaranth> lamont: yeah
<lamont> or is that evil?
<Amaranth> wait, not gksu
<Amaranth> i meant it should be 'nmapfe'
<Amaranth> hehe
* Amaranth needs more caffeine
<lamont> TryExec means that it tries that, and failure is an option?
<Amaranth> TryExec means it won't show it in the menu if that binary doesn't exist
<lamont> so it actually wants to be gksu
<lamont> or is it a list of binaries?
<Amaranth> in pyxdg it would probably just blow up
<lamont> (since the exec will fail if gksu isn't there...)
<Amaranth> let me check the spec
<DktrKranz> lamont, synaptic (which uses gksu too) recommends gksu because of kde
<DktrKranz> nmap
<DktrKranz> is available for both DE
<Amaranth> lamont: TryExec is not a list
<lamont> Amaranth: ok
<Amaranth> lamont: in pyxdg at least if you put in 'gksu nmapfe' it'll just fail so the .desktop would be marked as hidden
<lamont> heh
<lamont> ok
* lamont goes with:
<lamont> TryExec=gksu
<lamont> Exec=gksu nmapfe
<Amaranth> So either use nmapfe or nothing at all in there
<lamont> and Recommends: gksu
<Amaranth> TryExec is not required
<lamont> just drop it entirely?
<Amaranth> Well, it'd be better to have TryExec=nmapfe
<lamont> why?
<lamont> if nmapfe is installed, then you get the .desktop and the binary
<Amaranth> because if someone using alacarte to edit that entry in their menu alacarte makes a copy of the .desktop in ~/.local/share/applications and that does not go away when they uninstall it
<lamont> if it's not installed, then you get neither
<lamont> ah
<Amaranth> the TryExec would make that entry be hidden
<lamont> TryExec=nmapfe
<lamont> Exec=gksu nmapfe
<Amaranth> right
<Amaranth> then make gksu a depends
<jdstrand> I am helping #ubuntu-server and dendrobates out with https://blueprints.launchpad.net/ubuntu/+spec/ldap-authentication-client.  I have a situation where package A no longer provides a conf file.  package B is a configuration package for A and provides a different conf file for A.  Can I use B's debconf to prompt the user to delete (via B's postinst) package A's abandoned config file if it still exists, if B has a versioned depends on A?
<keescook> jdstrand: I can't quote a packaging rule that says it's okay, but it sounds reasonable to me.  :)
<jdstrand> keescook: I thought it reasonable too, but wanted to be sure
<MacSlow> Amaranth, do you happen to know why it is not possible to set 'vacuum' as the animation-tpye for 'minimize'... even after changing animation.xml and restarting compiz?
<Amaranth> MacSlow: it's not a minimize-type effect, i guess
<MacSlow> it's the same code as magiclamp I guess
<mvo> MacSlow: hm, that seems to work for me, lets see if I have the latest packages
<Amaranth> oh, i guess the latest oddities with compiz animation settings are upstream
<Amaranth> anyone else notice it doing stupid things with gecko tooltips, gecko menus, notification-daemon windows, etc?
<MacSlow> Amaranth, jup
<Amaranth> will make up a patch to revert these changes :)
<Amaranth> ah, they think the workarounds plugin makes some things they had not necessary
<MacSlow> dodge is funny
<Amaranth> hrm, that didn't help
<Amaranth> oh, typo
<\sh> Amaranth, re..you know what's the best...the upgrade worked on my home desktop without anyproblem...
<\sh> Amaranth, everything is working...or actually I should reboot my machine to see if I'm right
<Amaranth> \sh: hehe
<mvo> \sh: did you use update-manager for the upgrade?
<\sh> mvo, nope
<\sh> mvo, i never used update-manager
<_MMA_> Amaranth: Would you be the one to talk to about how "Show Desktop" can't be set to a corner now? Looks like i would set it in the "General" with "Hide all windows and focus desktop" but it doesn't work. I wan=snt sure if I should mention it upstream or on LP.
<\sh> mvo, but what I saw on my laptop and work desktop is brokeness in some gconf xml files...and the laptop and work desktop machine are dist-upgraded from feisty
<_MMA_> *wasn't
<\sh> Amaranth, mvo: give me some seconds to reboot the machine and see if everything is ok...
<MacSlow> Amaranth, I think I found a way to fix it
<MacSlow> Amaranth, need to touch the source (thus rebuild the package)... I wanted to avoid that initally
<\sh> re
<Amaranth> _MMA_: actually i don't remember that ever working
<\sh> Amaranth, rebooted, no black background nothing, even the mouse is ok
<Amaranth> \sh: cool
<_MMA_> Amaranth: Actually last time it worked for me was Edgy/Beryl. :-/
<_MMA_> gah *Feisty
<Amaranth> Actually it was not working for me in beryl either
<_MMA_> Oh well. :)
<Amaranth> mvo: should i put these settings changes in compiz-fusion-plugins-main or libcompizconfig's global.xml file?
<Amaranth> compiz-fusion-plugins-main
<Amaranth> that was a stupid question :)
<\sh> Amaranth, hopefully there is something with the X server which wasn't there before the update...I wonder
<mathiaz> pitti: could you have a look at bug 120085 ?
<ubotu> Launchpad bug 120085 in sysklogd "Various problems running syslogd with "-u syslog" option" [Medium,Triaged]  https://launchpad.net/bugs/120085
<mathiaz> pitti: I've attached a debdiff that should fix the problem, but I don't know if it could be accepted for gutsy.
<mhb> universe is enabled by default in gutsy, right?
<mathiaz> mhb: yes
<mhb> mathiaz: thanks, just checking
<ScottK> mhb: That's for new installs.  On upgrade it won't be enabled if it wasn't before, IIRC.
<asac> siretart: naturally those timeout messages start with the latest upload
<asac> siretart: i added them ... before it would just fail with wierd errors
<asac> siretart: i replace no reply with that reply if the client socket times out
<asac> siretart: the timeout is 2 seconds for normal operations and i bumped it to 12 seconds or so for operations that appear to take longer ... that helped alot of times, but not always ... those that still take longer are those you ses with TIMEOUT[CLI] 
<asac> siretart: i played around and found that those timeouts are operations that appear to block infinitely
<asac> siretart: so ... my request for help was about figuring out what wpasupplicant does when you see those timeouts
<asac> :)
<sbalneav> jcastro: So... How's it going, eh?
<lousygarua> hello, i'm from the ubuntu-il team and we've come up with an interesting suggestion to extend gettext functionality, is this the channel to discuss it?
<evand> lousygarua: the ubuntu-devel-discuss mailing list would probably be best.  Many of the developers are already gone for the day.
<dobey> lousygarua: what do you want do?
<YokoZar_> hmm, flashplugin-nonfree doesn't seem to be working for me in Gutsy.  Still says no flash installed.
<lousygarua> dobey: in hebrew there we usually translate sentences to fit male users, but some guy in the team thought we can hack it so it detects female users and just uses female po file or whatever for them
<lousygarua> dobey: it can also solve many of our translation debates
<agoliveira> lousygarua: I'm a bit of language freak so, would mind explain me why is this kind of translation needed in hwbrew?
<agoliveira> hebrew
<lousygarua> agoliveira: in hebrew (and arabic, etc..) sentences like "How would you like to partition your disk?" go differnetly for male and females
<lousygarua> agoliveira: we usually phrase them for males because that's standard, or try using a plural form
<dobey> hrmm
<agoliveira> lousygarua: I see. In portuguese we have such kind of differences as well.
<luisbg> lousygarua, the same happens in spanish
<luisbg> lousygarua, the norm is to use the male version when it can include both male and female
<dobey> lots of languages have similar male/female/neuter forms
<lousygarua> hmm so the ubuntu project can really do something new and innovative here
<luisbg> some cool ubuntu feature to gnome could be to ask if the user is male or female
<dobey> does gettext not support multiple sex forms?
<luisbg> and make the .po translation be gender intelligent
<dobey> i know it supports multiple plural forms
<lousygarua> dobey: i never encountered multiple sexes in gettext stuff
<dobey> but there really is no way to know whether a male or female is sitting in front of the screen
<luisbg> dobey, it can be held in the user account information
<luisbg> *could*
<luisbg> IMHO ubuntu women would really digg the idea
<lousygarua> luisbg: dobey: exactly. we are in a multiple user environment on unixes
<dobey> luisbg: but if one user is logged in, and another person is sitting at the keyboard...
<luisbg> dobey, that would be as illogical as having one person use anothers password
<luisbg> or what is behind it
<luisbg> it's documents, it's saved firefox passwords, and all that
<lousygarua> dobey: i don't mind the OS to think i am a girl when i'm fixing something on my g/f's laptop or whatever
<luisbg> each person should have 1 user
<dobey> luisbg: logic is not what users are about.
<dobey> they are humans, not computers.
<lousygarua> dobey: in the future we can add special devices that recognizes if you are a male or a female on runtime. i don't think it should bother us now
<wasabi> I'd hate to have one of those devices "malfunction"
<cjwatson> lousygarua: I'd really like to ask that this not be done in a manner specific to Ubuntu
<_MMA_> :)
<lousygarua> wasabi: lol
<cjwatson> lousygarua: it is very important that such critical infrastructure as gettext be standard across systems
<lousygarua> cjwatson: of course. but it seemed logical to me to go here first, or at least get the ubuntu support before i contact upstream
<cjwatson> I believe there is a mailing list dedicated to discussion of gettext
<lousygarua> cjwatson: i'm still lookign for one :)
<lousygarua> cjwatson: there's also a problem with systems that just wont' store sex information about the user
<cjwatson> I'm not wild about the idea personally, but TBH upstream is going to be much better informed than folks here about the feasibility
<luisbg> lousygarua, contact upstream and please let me know what they reply
<luisbg> I'm curious how this can follow on
<cjwatson> https://lists.sourceforge.net/lists/listinfo/translation-i18n
<wasabi> nvidia-glx-new.  Why doesn't this replace nvidia-glx?
<wasabi> (I do not refer to dpkg Replaces metadata, I mean, why doesn't nvidia-glx cease to exist)
<wasabi> It's a bit confusing having two packages, and sort of makes coexisting graphics cards... non-intuitive?
<luisbg> wasabi, +1
<wasabi> I'm not asking for a vote. I'm asking for a real reason.
<wasabi> I'm sure there is a real reason.
<wasabi> Just can't seem to find it. =)
<luisbg> I've heard they -new supports more cards
<agoliveira> -new includes series 100 driver which is much newer
<wasabi> Uh huh. Sure. And it supports old cards too, as far as I can tell.
<_MMA_> There is some overlap but -new goes higher.
<agoliveira> wasabi: I'm not sure. I vaguely remember reading that the new drivers dropped support for series 2 cards.
<luisbg> shouldn't they merge?
<_MMA_> That might be a big package. :)
<wasabi> That's silly.
<wasabi> Grrr. So coexsting series 2 drivers with new stuff is not possible?
<luisbg> two small better than one big?
<agoliveira> In my case (Asus G1 laptop) I need a series 100 driver or I can't switch to an external LCD via DVI
<agoliveira> wasabi: As I said, not sure.
<wasabi> op
#ubuntu-devel 2007-09-12
<keescook> mjg59: 133823
<mjg59> keescook: Only thing I can think of is a blacklist issue
<keescook> mjg59: yeah, that's what I though too, but I see no mention of it.
<keescook> mostly I'm just curious, and at this point I can't really debug it more without hardware
<calc> evand: you here?
<evand> calc: yes
<calc> evand: which odf converter is what we should be using it looks like its for windows from odf -> ooxml
<calc> evand: perhaps i am a bit confused
<evand> can you rephrase that?
<calc> it appears that the ODF translator command line tools are for use in windows
<calc> to convert from openoffice to office xml
<evand> http://odf-converter.sourceforge.net/ is the one that worked for me
<evand> freespire has a deb (looks hairy though): http://apt2.freespire.org/CNRUbuntu/pool/main/o/odf-converter/
<calc> evand: ah ok, i'll look at that to see what they did with it
<evand> calc: awesome, thank you
<lamont> ttf-*-fonts needs to use dpkg triggers. kthxbye
<pygi> doko, ping
<elmo> in 10 minutes titanium.canonical.com, the machine hosting wiki.ubuntu.com, help.ubuntu.com and other launchpad-enabled wikis, will be shutdown for some necessary maintenance, ETD is 5 minutes
* mneptok panics and calls 911
<bddebian> Noooo
<LongPointyStick> oh dear
* LongPointyStick removes mneptok's phones
<pygi> LongPointyStick, xD
<elmo> (titanium / wiki.u.c etc. is back)
<TheMuso> Would a core dev mind doing a no-change rebuild upload for gnome-speech so it can be built against the new espeak? Thanks.
<TheMuso> If any are around and not busy...
<pygi> TheMuso, it's 4:22 in the morning xD
<TheMuso> pygi: There are core devs in other timezones you know.
<pygi> TheMuso, possibly =)
<snap-l> I thought everyone used the one true TZ: EST+5
<snap-l> Tell these slackers to wake up! :)
<LongPointyStick> TheMuso: doing
<LongPointyStick> done
<TheMuso> LongPointyStick: Thanks heaps. I don't think its worth a bug filing for something so trivial.
<LongPointyStick> :)
<LongPointyStick> no problem
<mneptok> "I don't think its worth a bug filing for something so trivial."  -  last words of my pediatrician before he got his license revoked.
<TheMuso> mneptok: haha
<TheMuso> I think this is somewhat different.
<mneptok> TheMuso: you obviously haven't seen my thought-to-speech routines. they're ... somewhat obfuscated.
<TheMuso> heh
* mneptok is the inspiration behind gnome-stfu
<calc> evand: odf-converter sucks, it is written in windows and apparently just happens to sometimes work on linux, having to rewrite most of the makefiles to some extent in some cases they don't exist at all :-\
<calc> evand: but maybe by tomorrow night I will have something to test with on the current version
<pitti> A beautiful morning, Ubunteras and Ubunteros!
<mdke> morning pitti
<superm1> Ubuntueras haha..
<bryce_> heya pitti
<dholbach> good morning
<superm1> pitti, do you have a few moments to discuss two SRU bugs that I subscribed ubuntu-archive to earlier?  I anticipate that they will be jostling discussion before they are touched, so its probably better to discuss them before I head to bed in a bit
<superm1> the past two archive admins that have touched it at least it sparked discussion :)
<LaserJock> good morning dholbach
<superm1> mornin bryce_ dholbach
<dholbach> hey LaserJock, hey superm1
<dholbach> how are you guys doing?
<superm1> i'm getting sleepy :S
<LaserJock> I need to go to bed
<LaserJock> heh
<superm1> been finally going through and cleaning up my t-bird the last few hours
<superm1> nice to have things finally going in the right places and marked read
<pitti> superm1: no problem; please just point me to them, and I'll comment in the bug
<superm1> bug 134726 and bug 134801
<Ubotu> Launchpad bug 134726 in mythtv "MythTV 0.20.2 SRU " [High,Fix committed]  https://launchpad.net/bugs/134726
<Ubotu> Launchpad bug 134801 in mythplugins "Mythplugins 0.20.2 SRU " [High,In progress]  https://launchpad.net/bugs/134801
<dholbach> good night then :)
<superm1> they should both be at the stage of the (revised) MOTU SRU process where an archive admin will need to touch them to copy over to -updates
<superm1> the process was revised at the last MOTU meeting, and can be seen at http://wiki.ubuntu.com/MOTU/SRU
<pitti> doko_: ah, so db4.6 is meant to go back to universe for gutsy?
<pitti> doko_: so we still need to rebuild pam and fix the b-dep of rpm?
<soren> Is it expected that evolution-data-server eats 1.8GB RAM?
<Mithrandir> no
<\sh> since this morning I don't have any shadows anymore with compiz-fusion..but fusion is running, and all other effects are there
<soren> Mithrandir: Didn't think so. :) I also never expected to need swap space in a desktop machine with 4GB of RAM.
<ion_> Hm, would a new program still make it into universe? (I could package apt-mark-sync)
<pitti> hey mvo
<mvo> hey pitti
<pitti> mvo: do you have some time to do some SRU verifications for https://edge.launchpad.net/ubuntu/+milestone/ubuntu-6.06.2 ?
<pitti> mvo: some are trivial to test, but I already tested some myself, and some are mine, so I cannot test them
<pitti> mvo: in particular: 62986, 137849, 57445, 58935
<mvo> ok
<pitti> mvo: thanks; shouldn't take much time
<Mithrandir> pitti: I'm starting to look at getting the ubuntu-mobile packages into main and it's a fair amount of MIRs.  Do you want me to write normal ones or do you have a suggestion on a better way to do it?
<pitti> Mithrandir: the standard MIRs would be quite useless IMHO, since there is no security record and Debian bugs, etc.
<Mithrandir> pitti: some packages come from Debian, etc, though.  Like, matchbox or contacts.
<pitti> Mithrandir: I think there should just be a list of packages, Ian and I review them, promote the innocent ones, and file bugs about things that prevent main promotion; is that ok for you?
<Mithrandir> sounds like a plan to me.
<pitti> Mithrandir: ah, those should have MIRs then
<pitti> Mithrandir: I meant the hildon framework mainly
<Mithrandir> yeah, understood
<pitti> there's not really a question of whether to promote them anyway, since it's an important goal
<Mithrandir> do you want that in private mail or a wiki page or something else?
<Mithrandir> sure, but getting review means we get forced to fix any shortcuts we've taken.
<pitti> Mithrandir: public wiki page should do IMHO; there's nothing private about the packages in the archive anyway
<Mithrandir> sure
<Mithrandir> I think we've fixed most of the shortcuts, but getting a second eye on them would be good
<pitti> yeah, I still insist of a review of a package before promotion :)
<pitti> yep, that would be good
<Hobbsee> Mithrandir: this is so you can bypass the universe mess, right?  :)
<Mithrandir> Hobbsee: no, it's actually not, it's so I have less pain when dealing with moblin-image-creator when doing lpia images (since lpia lives on ports.u.c rather than archive.u.c)
* Hobbsee shoots daggers at the uni IT department
<Hobbsee> Mithrandir: ahhh....
<Mithrandir> Hobbsee: I realise it might look differently, though
<Hobbsee> Mithrandir: i'ts no particular problem.  like you say, the stuff was always intended to go to main :)
<pitti> cjwatson: can you please have a quick look at bug 103291? this looks like a straightforward patch which might also be suitable for dapper.2
<Ubotu> Launchpad bug 103291 in lilo-installer "lilo-installer fails on HP (Compaq) SmartArray controllers (/dev/cciss)" [Undecided,New]  https://launchpad.net/bugs/103291
<sladen> mdz: mjg59: sorry I wasn't online last night.  AFAICT, 90% of the seeks that tracker is doing are  seek(), read(), seek(), write() on it's own index files.  ...rather than being sensible and holding the database *in RAM*...
<cjwatson> mobile MIRs> we're supposed to be moving to bugs anyway; perhaps this would be a good opportunity to try it out
<cjwatson> pitti: ok
<pitti> cjwatson: I thought the bugs only track the status, whereas the actual report stays in the wiki?
<Mithrandir> pitti: if we do bugs, I'll just file bugs for all the components, you guys go "yes, yes, no, no, yes, no" and I do full MIRs in the wiki for those that you go no on?
<pitti> Mithrandir: WFM
<cjwatson> pitti: that wasn't clear to me
<pitti> I didn't follow the discussion about this migration closely, since I was on vac
<pitti> how are those bugs grouped, is there a mir-review team or so?
<pitti> iwj: ^
<Mithrandir> there should be, at least
<cjwatson> it hasn't been organised yet AFAIK
<ion_> Heh, i seem to have missed new universe packages freeze by two weeks.
<norsetto> Quickie for the archiver, are binaries builds for new packages automatically added to the archive, or they need manual intervention (since we are past the NPF)?
<Hobbsee> they'll still get stuck in binary NEW
<Hobbsee> (binaries for new packages, or newly-named binaries from old packages still go thru the NEW queue)
<norsetto> Hobbsee: I see! thx.
<Hobbsee> which is quicker than source NEW
<norsetto> Hobbsee: is there a way actually to remove something from the queue?
<StevenK> norsetto: Bug -archive to REJECT it
<norsetto> hey -archive! reject it :-)
<pitti> norsetto: hi; which packages?
<pitti> norsetto: however, binary reject is a bit evil, and we don't do it very often; what's the reason?
<norsetto> pitti: he is back! feeling a new man?
<pitti> norsetto: you bet! with that ring now chained to my hand... :-P
<norsetto> pitti: :-D
<norsetto> pitti: its superseeded so just to avoid more work, but I think that removing most probably is more mork that just keep it there
<StevenK> pitti: No no, it's a ball and chain, and it's around your ankle. :-P
<norsetto> I hate mork ......
<pitti> norsetto: sorry, I cannot make much sense from that sentence; which package troubles you?
<Hobbsee> pitti: a newer version of the package coming in, so makes no sense to review the current one sitting in the queue, i think
<norsetto> its rutilt. There is  0.15-0ubuntu2 in the new binaries queue and will be superseeded by  0.15-0ubuntu3 which is also in the queue
<norsetto> Hobbsee: thx for the translation :-)
<hunger> It would be nice to be able to uninstall tracker without having to uninstall ubuntu-desktop.
<pitti> norsetto: ah, indeed, I see both versions in the queue
<pitti> norsetto: don't worry, that's not a problem at all
<hunger> Or at least to be able to stop tracker from getting started when logging into KDE.
<norsetto> pitti: ok, thx, I'll keep that in mind for the future
<StevenK> pitti, Mithrandir: In terms of mobile stuff, I fixed moblin-chat a few days ago for NBS stuff, but it has never passed binary NEW.
<Hobbsee> why is tracker a dependancy, not a recommends?
<Hobbsee> particularly seeing as it has a habit of eating CPU
<mvo_> Hobbsee: on ubuntu-desktop its a recommends
<Amaranth> Hobbsee: it doesn't eat CPU
<mvo_> heh :)
* mvo_ waves to Amaranth
<Amaranth> hey
<Hobbsee> Amaranth: oh, hard disk?
<Amaranth> Hobbsee: It can do that, yes
<Amaranth> Hobbsee: But apparently the kernel is at fault there
<mvo_> it does not need to eat cpu, io is much better :P
<Hobbsee> mvo_: that's what i'd thought.  oh well
<StevenK> I would lay blame at the IDE chipset and disk drive. :-)
<StevenK> Well, some of the blame, anyway.
<Amaranth> jamiemcc has put a lot of effort into making tracker run as fast as possible (max out your CPU and IO) but automatically scale down when something else wants to use some CPU and IO
<Amaranth> But apparently the IO part is broken due to a problem with the scheduler
<Hobbsee> ooh...30mbps connections...
<Amaranth> But a clean install of gutsy doesn't have the problem, he was going to try to figure out why
<Amaranth> Hobbsee: Run out your quota in 15 minutes :)
<mvo_> the fact that a clean install is fine, is really interessting
<Amaranth> Indeed
<Amaranth> I can't think of anything related to IO scheduling that would be different between upgrades and clean installs
<jamiemcc> can someone raise the priority of this bug please:
<jamiemcc> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/131094
<Ubotu> Launchpad bug 131094 in linux-source-2.6.22 "Heavy Disk I/O harms desktop responsiveness" [Undecided,Confirmed] 
<cjwatson> doko_: is it OK if I just fix gcc-snapshot bugs in Debian and ignore the Ubuntu bugs until we next sync?
<mvo_> jamiemcc: I raised it, but please note that feisty comes with 2.6.20, 2.6.15 was used in dapper .)
<jamiemcc> mvo_: thanks - my fiesty has 2.6.15!
<mvo_> jamiemcc: that sounds like a bug in the upgrade :/
<jamiemcc> mvo_ yeah
* mvo_ vaguely remembers that he fixed a problem with the kernel selection in feisty->gutsy
<doko_> cjwatson: sure, if it's just a single package. we had an archive rebuild over the weekend, so I did want to fix (or file) all known problems
<cjwatson> doko_: yeah, groff
<cjwatson> (I can merge it if you want, just trying to avoid unnecessary work :-))
<mvo_> doko_:  are you ok with me upload ia32-libs? (http://people.ubuntu.com/~mvo/tmp/ia32-libs_2.1ubuntu2.debdiff) ? I just copied libxcomposite1 from build/ to pkgs/ to get it included in the resulting binary
<cjwatson> is anyone here using lilo on CCISS RAID devices?
<StevenK> Yes, but the install is *ancient*
<StevenK> cjwatson: ^
<cjwatson> StevenK: what do you pass to raid-extra-boot?
<cjwatson> I'm wondering if raid-extra-boot=mbr-only is reasonable for hardware raid the same way it is for software raid (well, at any rate it's what lilo-installer does for /dev/md*)
<StevenK> cjwatson: Nothing like mbr greps out of /etc/lilo.conf, but like I said, it's an ancient install.
<cjwatson> ok, I think mbr-only means "behave how you used to behave in lilo 21 please"
<StevenK> This is 22.2
<cjwatson> hmm
<cjwatson> any raid-extra-boot at all?
<StevenK> cjwatson: Happy to provide the lilo.conf if you like
<StevenK> cjwatson: Nope
<cjwatson> StevenK: if you could stick it on a pastebin that'd be lovely
<StevenK> Pastebin works well, since I have to bounce through three machines to reach it.
<StevenK> cjwatson: http://paste.ubuntu-nl.org/37186/
<cjwatson> (there's paste.ubuntu.com now, BTW, though I don't think it's really been advertised)
<StevenK> I wasn't aware, I shall try and keep it in mind. Thanks.
<cjwatson> at your convenience, I'm certainly not trying to stop people using paste.ubuntu-nl.org :-)
<Mithrandir> the world clearly has too few pastebins.  Everybody should have their own
<norsetto> pitti: about bug 35638: no diff with aa-complain cupsd (kernel logs attached)
<Ubotu> Launchpad bug 35638 in linux-source-2.6.22 "Printer is not detected properly over USB" [High,Confirmed]  https://launchpad.net/bugs/35638
<ion_> mithrandir: Its called cat >~/public_html/foo
<pitti> norsetto: ok, thanks; so it's not just a bug in the AppArmor profile
<StevenK> ion_: That works for me. Not everybody has their own webserver. :-)
<norsetto> pitti: don't know, apparmor failed to load profile during upgrade actually
<pitti> norsetto: ah, ok; that definitively rules it out
<pitti> norsetto: apparmor kernel and userspace are out of sync ATM, and new apparmor FTBFS
<pitti> norsetto: (I'll discuss this with mathiaz today)
<StevenK> pitti: Thanks for the bug close.
<doko_> mvo: please include the sources as well
<doko_> pitti: I think it's better to have it off the cd, and maybe out of main. we can reconsider this for hardy
<doko_> harty even
<StevenK> hardy is right
<illovae> hello o/
<mvo> doko: the source is already included in srcs/, it seems that for some reason it was just not moved out of the builds/ directory
<doko> mvo: ohh, I see. looks ok
<mvo> doko: build/ and pkgs/ are both in the source package and contain ~100 packages and some look identical. can/should I clean build/ or something before the upload (I'm not familar with this package)
<doko> mvo: ok, I'll build that on ronne
* ogra curses about upstreams putting -Werror everywhere
<cjwatson> \sh: re bug 103291, if I upload a fix to gutsy shortly, do you think you could test a daily build?
<Ubotu> Launchpad bug 103291 in lilo-installer "lilo-installer fails on HP (Compaq) SmartArray controllers (/dev/cciss)" [Undecided,New]  https://launchpad.net/bugs/103291
<cjwatson> I'm not taking quite the same approach as the patch that the bug reporter provided, because that had some bugs
<\sh> cjwatson, yepp...i would do it tomorrow then, when I have to install a new hp box from scratch by cd
<\sh> cjwatson, using the server edition :)
<asac> heno: i marked bug 135727 fix released ... as its on todays bug list I wonder whether I should just remove it?
<Ubotu> Launchpad bug 135727 in linux-source-2.6.22 "[Gutsy]  ipw3945 unable to connect to WPA-Enterprise Network after Kernel Upgrade" [Undecided,Fix released]  https://launchpad.net/bugs/135727
* mvo goes for lunch
<heno> asac: thanks! I've just marked it fixed on the list. Fixing is also a valid way of working with bugs on bug day :)
* heno hugs asac
* asac hugs heno 
<asac> heno: right ... was just sure how to mark it as fixed ;)
<asac> ah ok green means fixed ;)
<\sh> keescook, ping quagga...0.99.7+0.99.8 has a low impact DoS ... do you want to file an UVF for 0.99.9?
<\sh> oh well, looks like that quagga needs to be fixed in debian, too...so better to fix repackage 0.99.9
<soren> pitti: What could cause apport to not act upon a segfault? trackerd segfaults on my box, but apport doesn't seem to care.
<pitti> soren: it crashes here as well
<soren> pitti: Does your apport care?
<pitti> soren: reasons could be: it crashed several times in a row, at some point it gets ignored to avoid spamming you too hard
<pitti> soren: or, at some point you clicked 'ignore crashes for this version'
<soren> pitti: I don't have *any* tracker crashes in /var/crash.
<soren> How do I check if I've done that?
<pitti> soren: hm, that's weird then
<pitti> soren: do you have a ~/.apport-ignore.xml?
<soren> pitti: Oh, hang on.
<soren> pitti: Ah, I'm an idiot. There is a crash there. And old one, though.
<soren> pitti: trackerd is not in my ~/.apport-ignore.xml, though.
<ion_> ~/.config/apport/ignore.xml would be nicer. :-)
<soren> pitti: Does it check if the crash is identical to an old one, perhaps?
<StevenK> ion_: Twitch
<pitti> ion_: yes, on my list
<pitti> soren: it does, yes; and it keeps a counter in the crash report
<pitti> soren: it won't report it more than three times
<soren> pitti: Clever.
<soren> pitti: Ah, I see you already reported it.
<pitti> soren: and fixed upstream
<soren> pitti: Uh.. That automatic debian bug report thing looks clever.
<soren> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=440997
<Ubotu> Debian bug 440997 in tracker "tracker: getenv() implicitly converted to pointer" [Important,Open] 
<pitti> cool
<hunger> Will you package the VMWare tools? VMWare seems to have released them under GPL/BSD and LGPL.
<hunger> See: http://open-vm-tools.sourceforge.net/
<pitti> oh, cool
* hunger thinks so, too. Especially since they do not install well on gutsy:-)
<evand> calc: yikes, good luck
<hunger> pitti: I'll volunteer to test any open-vm-tools debs somebody comes up with on gutsy;-)
<elkbuntu> heh, i think there will be a queue for that
<slytherin> Can anyone tell me what is the chance that libtheora 1.0 beta 1 will get an freeze exception provided there is enough justification for that. Consider that it will be released in around 1 week time.
<heno> mvo: lots of compiz crash bugs coming in like bug 127213
<Ubotu> Launchpad bug 127213 in compiz "compiz.real crashed with SIGSEGV in read()" [Undecided,Incomplete]  https://launchpad.net/bugs/127213
<asac> siretart: there? got my messages about the TIMEOUT?
<mvo> heno: looking
<heno> is that a known recent upload?
<heno> mvo: erm, sorry the bot in #ubuntu-bugs suggests these are new, but they are clearly not
<heno> broken bot wrt LP perhaps?
<mvo> heno: poissble, I just came in
<mvo> (after a longer lunch break)
<ScottK> pitti: eclipse - 3.2.2-3ubuntu2 FTBFS on AMD64.  The error was "debian/control did change, please restart the build" - Would a give-back be sufficient to deal with that do you think?
<\sh> pitti, ping...quagger has a DoS and some bugs...would you agree, to fix the version in gutsy, to merge 0.99.8 from debian unstable and fix the DoS (which is there since ages, I think) with cherrypicked patches  from 0.99.9 (which is not in debian)
<pitti> ScottK: no, I don't think so; if the package modifies its own debian/control during build, that's a bug that sohuld be fixed
<pitti> \sh: that sounds fine, if it goes through the standard freeze exception process (i. e. if it only fixes bugs, no new features)
<ScottK> pitti: I'm a bit confused why it did that as it built fine on the other archs.
<pitti> ScottK: I can retry it *shrug*
<\sh> pitti, we have 0.99.7 and 0.99.8 fixes bugs of .7 and introduces new bugs which are fixed in .9 ... and the DoS is fixed...I would take the DoS fix to patch quagger for our old releases as well
<ScottK> I'd appreciate it.  If it fails again, I'll go work on it.
<siretart> asac: hi
<pitti> ScottK: right, it does modify control on build
<pitti> uncompress-stamp: debian/control
<siretart> asac: yes, I did. I'll take a look into this.
<pitti> debian/control: debian/control.in debian/rules
<pitti> ScottK: so I'd rather have this fixed
<ScottK> pitti: I'll have a look at it.  Thanks for checking.
<pitti> ScottK: please look at http://archive.ubuntu.com/ubuntu/pool/universe/e/eclipse/eclipse_3.2.2-3ubuntu2.diff.gz
<pitti> ScottK: the test is to prevent changing debian/control from underneath the buildd
<ScottK> Which certainly makes sense.
<pitti> ScottK: apparently the idea is to manually do this before building the source package, and I guess on amd64 the dependencies changed for some reason
<pitti> not sure who did that, but if such evilness needs to happen at all, it's better suited in the clean rule
<ScottK> OK.  That's in the Debian package.  I'll pass it on and work it out with them.
<pitti> ScottK: cheers, thanks
<ScottK> What they are trying to do is to accomodate Debian/Ubuntu differences automagically with (clearly) indifferent results so far.
<asac> siretart: ok if you have questions let me know
<asac> siretart: interestingly enough there are still cases where wpasupplicant doesn't return an error code, but has a garbage reply
<asac> siretart: you might see those cases in daemon.log as well
* Mithrandir sighs and kicks NM's nuts.
<asac> siretart: unsure how to reproduce these (more or less rare) cases
<asac> Mithrandir: try to rephrase please ;)
<Mithrandir> asac: "NM fails to receive dhcp reply, dhclient works fine".  ipw2200, unencrypted.
* ogra holds NM tight from behind, so Mithrandir can kick again :)
<asac> Mithrandir: ok ... can you reproduce? ipw2200 is pretty similar to ipw3945 from code pov ... so there might be similar issues
<asac> Mithrandir: no dhcp reply ... or does NM refuse to try dhcp at all?
<Mithrandir> and now the card refuses to associate at all.  *sigh*.
<asac> Mithrandir: ok ... can you enable driver debugging and submit the log?
<asac> Mithrandir: https://wiki.ubuntu.com/DebuggingNetworkManager
<slytherin> hell core developers. Can anyone tell me what is the chance that libtheora 1.0 beta 1 will get an freeze exception provided there is enough justification for that. Consider that it will be released in around 1 week time.
<asac> Mithrandir: there is a paragraph on how to do that for ipw3945 ... ipw2200 should be similar
<slytherin> s/hell/hello
<Mithrandir> asac: I guess I can, if I manage to get it working at all.
<asac> working at all?
<asac> as long as the driver is loaded you should be able to capture the driver log
* Hobbsee now starts to wonder if her uni network is botched, or if it's NM/dhclient playing up
<asac> Hobbsee: can you show me syslog?
<Hobbsee> asac: it was earlier this afternoon (i've rebooted since then), and doing it manually with dhclient also botched it.  if you still think there's any point...
<Hobbsee> as in, i couldnt connect at all.
<Hobbsee> should ahve tried on windows, i guess.
<Chipzz> asac: btw, did you take a look at the new log I posted (ipw2200 problem)
<Hobbsee> it was the same 'no leases available thing' though
<asac> Chipzz: bug id?
<Chipzz> asac: no bug, we talked about it on irc
<Hobbsee> irc is not a substitute for the bugtracker.
<asac> Hobbsee: well if dhclient doesn't work it can still be a driver bug
<asac> Hobbsee: capturing a syslog with driver logging enabled might help
<Hobbsee> asac: that's what i'm wondering.  i'll try it tomorrow
<Chipzz> asac: http://chipzz.safehex.be/random_associate
<Hobbsee> (and man i'll be pissed if my wifi doesnt work tomorrow)
<asac> Hobbsee: take this link with you :) ... https://wiki.ubuntu.com/DebuggingNetworkManager
<ScottK> And then be sure to look it up when your wifi isn't working ...
<Chipzz> asac: from the log it appears the driver is actually actively looking for an open wireless network to connect to, so it isn't random
* Fujitsu couldn't connect to the wifi at school at all today (using ipw2200, both NM and wpa_supplicant manually)
<Chipzz> asac: it is however unwanted behaviour
<Hobbsee> ScottK: i saved the page :P
<ScottK> Hobbsee: Sure, but it was funnier my way.
<asac> Chipzz: can you please summarize again what you did when you captured that log?
<asac> Chipzz: just loaded driver + setting essid?
<Chipzz> asac: jups
<Chipzz> asac: I figured out the root cause of why it's doing that though I think
<asac> Chipzz: ?
<Chipzz> asac: the problem basically is there were too many AP's around here on one channel (channel 11), which caused jamming/poor reception
<Hobbsee> ScottK: :)
<Chipzz> asac: so the driver can't associate
<cjwatson> heno: IIRC ubotu reports a new bug if a new task is created on an existing bug
<Chipzz> asac: in which case the driver decides that despite the fact that I did specify an essid, it should still scan for the best possible network (and that's the actual bug)
<asac> Chipzz: what value for essid did you set when you captured that log?
<Chipzz> asac: "nighty"
<heno> cjwatson: ah, ok thanks
<Chipzz> asac: which is WEP-secured; but for some reason, looking at the log, it is looking only at non-secured networks
<Chipzz> Sep  5 22:48:07 localhost kernel: [268410.992000]  ipw2200: U ipw_best_network Network 'hades (00:18:84:18:a9:52)' excluded because of privacy mismatch: off !
<Chipzz> = on.
<Chipzz> Sep  5 22:48:07 localhost kernel: [268410.992000]  ipw2200: U ipw_best_network Network 'FON_LNW (00:18:84:18:a9:51)' is a viable match.
<Chipzz> Sep  5 22:48:07 localhost kernel: [268410.992000]  ipw2200: U ipw_best_network Network 'chipzz (00:13:10:92:e4:0f)' excluded because of privacy mismatch: off != on.
<StevenK> pitti: Have you got a sec?
<pitti> StevenK: yes
<StevenK> pitti: Would you pushing the Big Red Shiny Button to let boost out of binary NEW? It has built everywhere.
<StevenK> Would you mind, even.
<pitti> StevenK: can do
<StevenK> pitti: The old boost libraries are now marked as NBS, since we jumped from 1.34.0 -> 1.34.1.
<StevenK> pitti: I have prepared 32 rebuild-only uploads, I'm in the middle of test building the lot of them.
<pitti> StevenK: I'll prod the uploader about doing the transition of the rdepends
<pitti> StevenK: ooh, you rock
<StevenK> I'm seriously close to killing the test builds, though.
<StevenK> % grep 'Build needed' */current | cut -d\  -f3 | sed 's/,//' | ./time-add
<StevenK> 09:30:03
<pitti> StevenK: didn't geser already test everything?
<asac> Chipzz: i don't see any "nighty" in that log
<StevenK> pitti: I've already had 3 build failures, so I guess not.
<pitti> StevenK: hm, he might only have tested main then, right
<StevenK> Which is like one package
<pitti> (three or so)
<StevenK> Ah
<StevenK> Anyway, my current Evil Plan is to wait for these things to finish pedalling, and then uploading everything that built in the morning.
<asac> Chipzz: reconnect ...
<asac> anything i missed?
<Chipzz> asas	     as	no ;)
<Chipzz> argh
<asac> that looks strange ;)
<StevenK> pitti: Why it looks to be nearly everything that links against boost to take close to an hour to build, I'll never know.
<Chipzz> asac: no you didn't miss anything ;)
<pitti> StevenK: lots and lots of C++ and template processing, etc.?
<StevenK> Probably.
<Chipzz> asac: that';'s irssi screwing up tabs over a slow connection for some reason
<Chipzz> ;)
<asac> Chipzz: 15:57 < asac> Chipzz: i don't see any "nighty" in that log ? any idea?
<StevenK> C++ and templating makes me cry.
<StevenK> Actually, C++ makes me cry
<Chipzz> asac: yeah, like I said, the signal frmo that ap is getting jammed due to 4 AP's being on the same channel
<asac> anyway ... there should be at least "nighty"in that log ... otherwise the log does not capture the right timeframe
<Chipzz> (my guess anyway)
<asac> Chipzz: so your problem is gone?
<Chipzz> asac: that's exactly the whole problem: poor/no reception for that AP, which causes the driver to associate to something random
<Chipzz> which it shouldn't
<Chipzz> asac: I fixed the symptoms by switching the AP to some other channel, but there's still a bug in the driver IMO
<Chipzz> ie, that the driver associates randomly despite an essid and key being set
<asac> Chipzz: welll ... then get the right log to me
<asac> Chipzz: it should start right when driver is loaded
<Chipzz> asac: that *is* the right log :)
<Chipzz> the ap is "out of range"; expected behaviour: fail to associate; behaviour being seen: try to associate to the best open network
<asac> at what time did you run iwconfig essid ?
<asac> Chipzz: my problem is that i don't see that the essid is set from userspace in that log
<Chipzz> asac: that's being ran from ifup
<Chipzz> (I suspect)
<asac> Chipzz: please don't do that
<asac> Stop everything .... just load driver and use iwconfig essid "nighty"
<Chipzz> I do modprobe ipw2200, at which point udev (I think?) automatically runs ifup
<asac> Chipzz: please post your /e/n/interfaces
<asac> Chipzz: please remove that eth1 entry and see if you can reproduce the wrong behaviour by just using iwconfig essid
<Chipzz> may be quite hard since the problem is fixed by setting the ap to another channel, but I'll look into it
<Chipzz> asac: so you think this is actually a bug in ifup?
<Chipzz> I suspect more of a race condition actually
<asac> not sure
<asac> the log doesn't contain any hint that the essid is actually set
<asac> Chipzz: which debug_level did you set?
<Chipzz> 65535 iirc
<Chipzz> but I may be mistaken
<\sh> pitti, keescook : regarding quagga DoS...I'll do as I explained, merging 0.99.8 from debian, fixing the bugs from 0.99.8 with patches from 0.99.9 and filing an UVF Report with explanation
<pitti> \sh: thank you
<pitti> StevenK: NEWed
<asac> Chipzz: plesae be sure it is ... i don't see any debug output for IPW_DEBUG_ASSOC
<\sh> pitti, I'll file security bugs for dapper, edgy and feisty as well...and fix at least the DoS
<asac> Chipzz: and thats the most important part here
<Chipzz> asac: and actually, putting the essid/key in /e/n/i is (was) the only way I could get this wireless to connect properly
<pitti> \sh: you rock
<Chipzz> though this may be a bug that has been fixed
<\sh> pitti, oh and BTW...congrats :)
<asac> Chipzz: thats interesting to investigate as well ... do you have some time and can join #ubuntu-mozillateam?
<pitti> \sh: *beam*
<Nafallo> ehrm... does unattended-upgrades restart quagga itself? ;-)
<asac> Chipzz: too much noise for this channel to debug something like this ;)
<soren> pitti: Do you think the vmware tools are actually cool enough to work on the packaging?
<soren> pitti: I've started at: https://code.edge.launchpad.net/~shawarma/open-vm-tools/packaging
<pitti> soren: as vmware user I can only say "Yes" :)
<cjwatson> \sh: OK, I uploaded a fixed lilo-installer, so if you could test tomorrow's daily I'd greatly appreciate it
<hunger> soren: If you need somebody to test: Just ping me.
<pitti> soren: I usually don't install them for short-lived VMs, but if it's as easy as an apt-get, I'd probably doit
<soren> hunger: Will do.
<Nafallo> vmware better then xen then?
<soren> pitti: Right. There's a checkvm utility we could use somehow to automagically install them if we're running in a vm.
<pitti> soren: originally I thought about integration into restricted-manager, but if it's open source now, then this wouldn't fit any more
<soren> pitti: No, ironically that makes it less obvious how to integrate it. :)
<pitti> soren: well, we can still put it there; after all, VMWare itself is not free :)
<\sh> cjwatson, promised :)
<pitti> soren: and it provides all the necessary infrastructure for it
<soren> pitti: True.
<pitti> soren: is checkvm free software? and reasonably small?
<cjwatson> \sh: cheers
<soren> pitti: stripped, it's at 6k.
<pitti> soren: oh, wow; I hoped it was just a 10-line shell script poking in /proc or /sys
<soren> pitti: And yes, it's free as in LGPL.
<\sh> cjwatson, btw..I'm doing the installation around 7am UTC...when is the daily iso run?
<cjwatson> that's too early
<soren> pitti: No, it's a tiny bit of assembly code.
<pitti> \sh: I can build an extra daily for you tonight
<cjwatson> \sh: the cron job *starts* at 6:31 UTC but it might well not be finished by 7:00 (or at any rate I can't guarantee that the mirrors will be up to date)
<kleinernik>  in the postrm script, under the purge section, should a config-file-directory be removed by using rm -rf or by using rmdir --ignore-fail-on-non-empty (LP: #32521)
<cjwatson> \sh: please check the .list file alongside the image and make sure that it contains lilo-installer 1.22ubuntu2
<cjwatson> kleinernik: it depends, there's no one answer I'd consider universally appropriate
<\sh> pitti, don't worry :) no need
<pitti> \sh: wouldn't be a problem
<\sh> cjwatson, ok...if I can manage I delay it abit...or use another machine later tomorrow...
<cjwatson> kleinernik: I think it's probably not a good idea to remove files that might have been created by the sysadmin, personally
<\sh> we are in the middle of building a new structure, so I have enough machine on sale for testing
<Nafallo> \sh: just let pitti build it tonight ;-)
<kleinernik> cjwatson: ok, but isn't this the purpose of using purge?
<cjwatson> the linked c.o.l.a post does not clarify (and in any case comp.os.linux.advocacy is not an authoritative statement of policy)
<cjwatson> kleinernik: purge removes configuration files owned by the package, which is not the same thing
<pitti> kleinernik: the purpose is to remove everything the package created itself, but not backups from sysadmins, etc. (or worse, live files)
<Nafallo> \sh: so then if the bug isn't solved you can hit cjwatson with it early :-)
<cjwatson> kleinernik: or even aside from the sysadmin, consider some other package that installed a file in /etc/gallery but for whatever reason (I don't care) doesn't depend on gallery; purging gallery shouldn't remove that file
<kleinernik> cjwatson: oh, ok, thank you. i guess than we can close bug  #32521?
<Ubotu> Launchpad bug 32521 in gallery "purge doesn't remove all config files" [Medium,New]  https://launchpad.net/bugs/32521
<cjwatson> kleinernik: no
<\sh> Nafallo, hehe...well, I think cjwatson and others and even myself are in the same situation as you were when your DC had a breakdown ;)
<cjwatson> kleinernik: you're on the wrong track, I think
<cjwatson> kleinernik: /etc/gallery/config.php and /etc/gallery/htaccess are created by the gallery package, right?
<Nafallo> \sh: not the DC, the fibre between to DCs. no services affected :-P
<cjwatson> kleinernik: so forget about rmdir --ignore-fail-on-non-empty vs. rm -rf; those are not the only two choices
<Nafallo> two
<bddebian> Heya
<cjwatson> kleinernik: another viable option is for gallery to explicitly remove just those files it knows it (may have) created
<kleinernik> cjwatson: oh, ok than i can add extra lines to remove explicitly the package files
<geser> StevenK: which packages didn't build with the new boost?
<geser> StevenK: I know that miro needs a small fix (a patch needs to be dropped)
<Hobbsee> a whole lot, if boost is up to standard.
<geser> StevenK: I've also already prepared the rebuilds (without kde packages) for universe (but didn't test them all) but I'm waiting for the new packages to leave NEW
<geser> StevenK: should I care for the rebuilds or will you do it?
<StevenK> geser: I'll do it, it's fine.
<StevenK> geser: miro, and democracyplayer, amusingly enough
<pitti> geser: I NEWed them a while ago, they should be available in about an hour
<StevenK> geser: If you do miro, I'll upload everything else in about eight hours.
<geser> StevenK: I've a fixed miro
<StevenK> geser: Great. Wait an hour and upload it. :-)
<geser> does democracyplayer needs fixing or will it be removed soon as it got renamed to miro?
<StevenK> geser: I was going to talk to RAOF about that.
<geser> StevenK: I see bug #138953 is already fixed
<StevenK> geser: So let's leave it for the moment.
<Ubotu> Launchpad bug 138953 in ubuntu-dev-tools "Wrong Replaces on devscripts" [Medium,Confirmed]  https://launchpad.net/bugs/138953
<Skiessi> why tribe 6 cd isn't released?
<StevenK> Er yes
<Hobbsee> Skiessi: see https://wiki.ubuntu.com/GutsyReleaseSchedule
<Hobbsee> er
<Hobbsee> http://tinyurl.com/3ytk9g
<geser> StevenK: is miro the only package FTBFS so far?
<StevenK> geser: miro, democracyplayer and something else.
<StevenK> Both miro and democracyplayer are due to boost, I suspect the something else ... ah yes, bfilter is due to chroot brain-damage or something, I need to dig.
<pitti> hello mathiaz! The man I was waiting for
<StevenK> geser: Could I see this patch for miro?
<pitti> mathiaz: if you have some minutes today, I'd like to discuss the current apparmor dependency problems?
<mathiaz> pitti: hi. I'm just going thourgh your emails about apparmor
<pitti> mathiaz: the biggest problem so far is that the source is dep-waiting on latex2html
<pitti> mathiaz: but that's multiverse, so promotion to main is not an option
<pitti> mathiaz: how was the documentation built in earlier versions?
<geser> StevenK: either drop debian/patches/30_libboost_python.patch (which I did) or add _1 to the library name in that patch
<pitti> mathiaz: we might need to only ship the HTML docs, or alternatively, use hevea?
<mathiaz> pitti: I don't remember right now.
<kleinernik> cjwatson: sorry, one more question, should purge remove files, that are not installed when the package is installed, but are created by a script the user calls to setup the program?
<cjwatson> kleinernik: maybe. it's a judgement call and depends on the exact circumstances
<pitti> kleinernik: IMHO yes, since they are related to the package
<StevenK> geser: So noted.
<geser> StevenK: it tries to link to the old name (which doesn't exist now) but the new boost packages provide links to the library without the whole suffix so that patch is needed
<cjwatson> pitti: but if they might be created by some other package instead then extra care is called for
<pitti> right
<geser> * isn't needed anymore
<kleinernik> cjwatson: in case of gallery, the two file mentioned in the bug report are created by a script configure.sh, which the user has to run as root to setup gallery, therefor i can add a line in postrm to remove them on purge, right?
<kleinernik> quit had to go home
* pitti hands kleinernik a /
<\sh> doko, bash bug 76807 .. would you like to fix it with a new upload, or should I attach a debdiff with the fix?
<Ubotu> Launchpad bug 76807 in bash "/etc/skel/.bashrc sets HISTCONTROL twice in succession." [Wishlist,Confirmed]  https://launchpad.net/bugs/76807
<doko> \sh: need to do another bash upload, yes.
<\sh> doko, cool...so dholbach can remove it from the low hanging fruit bug table ,-)
<dholbach> I think there was a nother bash patch pending on a bug somewhere
* dholbach checks http://daniel.holba.ch/sponsoring/
<dholbach> \sh: you can remove it and *your* name to it :)
<dholbach> bug 103929 also
<Ubotu> Launchpad bug 103929 in bash "Bash prompt string looks for xterm-color, gnome terminal identifies as xterm" [Wishlist,In progress]  https://launchpad.net/bugs/103929
<ogra> SIGH ...
<AlinuxOS> pitti, hello ;)
<\sh> dholbach, added a comment to the list
<dholbach> \sh: gracias
<ogra> why is texlive-base generating all this crap in my pbuilder again ? i thought that dep for gome packages was cleaned
<ogra> *gnome
<pitti> hi AlinuxOS
<AlinuxOS> pitti, I'll re-download libwnck and metacity from launchpad and I'll test issue 139139 again.
<AlinuxOS> https://bugs.edge.launchpad.net/ubuntu/+source/libwnck/+bug/139139
<Ubotu> Launchpad bug 139139 in libwnck "String "Always On _Top" doesn't compare in libwnck for non English languages" [Undecided,Invalid] 
<ogra> (building gnome-power-manager since 30min and still no go ....watching textex doing stuff :( )
<ogra> RAAH ...
<geser> pitti: do you know if GPL with a non-commercial clause is "free" enough for multiverse or is it even non-redistributable? see the license for linuxsampler on http://www.linuxsampler.org/downloads.html
<pitti> AlinuxOS: hold on, danilo is currently testing a Rosetta import issue; that might be it
<geser> pitti: it was removed from Debian because of the licence
* ogra kicks g-p-m in the guts ... why do you darn thing have a --enable-compile-warnings option if you still hardcode -Werror everywhere !
* ogra cries
<pitti> geser: hm; I'm prone to say that it is enough for multiverse, as long as the license is consistent in itself
<pitti> geser: I. e. they modified the GPL text hard enough to not contradict the non-commercial clause
<cjwatson> dholbach: can you remember to change the name and e-mail address in the changelog trailer when you upload something (ubuntu-dev-tools), so that the proper person is recorded as doing the upload?
<pitti> AlinuxOS: ah, it's a missing build dep, I'll fix it
<AlinuxOS> pitti, ok, thanks.
<cjwatson> ogra: -Werror is a good thing IMO
<AlinuxOS> cjwatson, hello ;)
<cjwatson> certainly for upstreams that actually pay attention to compiler warnings, where they probably really do indicate a problem
<ogra> cjwatson, not if upstream doesnt fix the bugs it causes  :P
<ogra> cjwatson, its my constant thing since three releases .... if development starts, upstream enables Werror so g-p-m breaks on sparc and ia64 ... with a warning ... at the end of the dev cycle he disables it again ... he knows the bug with the 64bit arches
<ogra> and i wuld expect if there is a configure option --enable-compile-warnings=no .... it would suppress Werror
<ogra> but apparently that has no effect at all
<cjwatson> the right answer is to contribute patches to fix said compiler warnings (or errors, whichever), not to ignore them indefinitely
<cjwatson> surely they are not all that difficult to deal with
<ogra> well, i have no clue about sparc and all i was told by sparc people is "just disable Werror"
<geser> pitti: from the webpage it looks like an additional clause to me (but I'm not a licencing expert) see also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=328121#35 which states that it's non-distributable (but I don't know if the author is right)
<Ubotu> Debian bug 328121 in linuxsampler "linuxsampler: Inconsistent and non DFSG free license" [Grave,Open] 
<cjwatson> ogra: IME it is not necessary to have a particular clue about the details of an architecture in order to fix its compiler warnings. We have sparc porting machines you can use for test-builds
* ogra goes googling for sparc and warning: cast increases required alignment of target type
<ogra> oh, fun
<ogra> its not even in g-p-m its a gstreamer bug it seems
<ogra> sigh
<cjwatson> if you are sure you don't care and want to get rid of that using -Wno-cast-align would be more appropriate than removing -Werror
<ogra> ok
<cjwatson> though I suspect it's a real bug
<ogra> well, it seems very a common message on sparc systems
<ogra> according to the google hits i get
<pitti> geser: I downloaded http://download.linuxsampler.org/packages/linuxsampler-0.4.0.tar.bz2 and it seems broken to me: it ships with a pristine GPL in COPYING and only mentions the restriction in README
<pitti> geser: which makes it an invalid license and thus indistributable IMHO
<geser> ok, thanks. I'll add a comment to the package on REVU about it
<pitti> geser: ah, it had been removed in feisty
<geser> yes, it was in Debian and Ubuntu and was removed because of the license
<mathiaz> pitti: I've had a look to use hevea instead of latex2html
<mathiaz> pitti: but hevea cannot build the documentation. It fails before the end of the document.
<pitti> mathiaz: hm, too bad; so maybe we should only ship the doc as PDF for now
<mathiaz> pitti: so I'll remove the html doc and only leave the pdf version of documentation
<pitti> mathiaz: did you also see my bug about the missing perl dependencies?
<mathiaz> pitti: yes. That's the next thing on my list.
<mathiaz> pitti: I don't think there is any workaround - so I'll write the MIR.
<pitti> mathiaz: right, that's the correct approach IMHO
<calc> evand: i got it packaged (more or less) but it seems OOo isn't using it, will look into it further
<calc> evand: but it does work at the command line
<dholbach> cjwatson: I'll do that from now on
<cjwatson> dholbach: (dch -r does it, FWIW)
<dholbach> alright, thanks a lot
<evand> calc: that's odd.  Is that a regression?  The version I used (the deb from freespire) worked in OO.o from Feisty
<AlinuxOS> cjwatson, hello, I've filed +unified 2 bugs, as you told me some time ago: https://bugs.edge.launchpad.net/debian-installer/+bug/94177 but I'm not sure if my bug comment is clear.
<Ubotu> Launchpad bug 94177 in console-setup "Georgian fonts for Fixed16 & Fixed14" [Undecided,In progress] 
<wasabi> Hmm. The initramfs uses udevsettle.
<wasabi> I wonder if there is no longer a need for that.
<wasabi> Hmm. Actualy it doesn't seem to use it anymore. Take that back.
<wasabi> in other news, 2.6.22-11 does not detect my sound card. =/
<ogra> wasabi, disabling udevsettle doubles the speed my thin client boots
<wasabi> Yeah, it looks like it's only enabled in the nfs boot now.
<ogra> might be to make sure the interface is *really* there
<ogra> but i dont see any probs here with dropping it
<wasabi> I wouldn't be comfortable with taking a position on NFS. I have no machines that test that.
<ogra> especially on very slow clients its a bump in bootspeed (200MHz 64M)
<wasabi> I'd imagine it would be possible to detect that the network is properly up in a way other than waiting for udev, though.
<ogra> boots +20sec with udevsettle
<wasabi> Actually, I'd imagine NFS would just block until it was up. ;0
<ogra> it retries the mount
<ogra> but i guess it will break if no device is there
<ogra> but to be honest i disabled udevsettle generally over here since gutsy started and havent seen any bugs related yet
<ogra> so i suspect we could just drop it there as well
<calc> evand: hmm i'll have to take a look and see if the freespire debs work better than mine
<ogra> wasabi, even though i'd like to hear from Keybuk about that before we break stuff that might have an intention
<calc> evand: OOo may be defaulting to using internal docx filter instead of the odf-converter one
<hunger> soren: open-vm-tools build and install fine for me. Kernel modules are missing, but I assume you know that;-)
<Keybuk> ogra: about what?
<ogra> Keybuk, the only script in initramfs that uses udevsettle is the nfs script, wasabi amd me were wondering if we could drop it ...
<Keybuk> it probably doesn't do anything
<ogra> not having it seems to have no bad sideeffects for me
<Keybuk> udevsettle doesn't do anything useful
<ogra> it delays the boot
<evand> calc: you mean in your tests?  I know it was using the odf-converter one for me as it said loading external plugin or something to that extent and took longer-than-usual to convert
<Keybuk> iiiiiish
<Nafallo> hmm. not the same odf...
<ogra> Keybuk, last two lines of /usr/share/initramfs-tools/scripts/nfs-top/udev
<ogra> # We need to wait for the network card drivers to be loaded
<ogra> /sbin/udevsettle
<ogra> if i drop that is seems to do no harm
<mathiaz> pitti: I've written the first MIR for librpc-xml-perl and added to the MIR queue.
<Keybuk> hmm
<Keybuk> interesting point
<Keybuk> the nfsmount script has a loop in it now
<Keybuk> so that's not necessary
<ogra> right
<Keybuk> it'll just keep tryinging the ipconfig and nfsmount until it works
<ogra> right, so you think we can drop it ?
<Keybuk> yeah
<ogra> good, i'll do some more stresstesting and make sure i didnt lie ... and then fix it :)
<hunger> I read that there is a vmware mouse driver for xorg... is that available in ubuntu?
<EvanCarroll> I'm not sure if anyone else has reported this, or if this bug was introduced in today's patch, but if you mistype a cmd the usual catcher that refs the corresponding apt package is broke.
<EvanCarroll> using gutsy of course
<EvanCarroll> GDOME has a review that is no longer supported and only works with one version of GDOME, and how XML::LibXML defers you to GDOME for an OO interface to DOM Building
<EvanCarroll> m/t
<Leftmost> Is it possible to get only the Ubuntu patchset for a package? I.e. if I wanted to look specifically at the changes between a base package and the Ubuntu version, how would I go about that?
<soren> Leftmost: "apt-get source packagename" and then look at the .diff.gz you get.
<Leftmost> Ahh, alright. Thanks.
<ogra> well, rather make a debdiff between the debian and ubuntu source packages :)
<Leftmost> Hmm. Out of curiosity, does anyone know where changes have been made that allow networkmanager and madwifi to cooperate? The upstream versions of the packages don't cooperate at all.
<AlinuxOS> asac__, hello
<mathiaz> keescook: are you working on some apparmor bugs ?
<asac> AlinuxOS: hey
<AlinuxOS> asac, hello, how's going https://bugs.edge.launchpad.net/ubuntu/+source/mozilla-firefox-locale-all/+bug/88677 bug fixing ?
<Ubotu> Launchpad bug 88677 in mozilla-firefox-locale-all "Georgian Language support." [Undecided,Confirmed] 
<asac> AlinuxOS: bug updated.
<AlinuxOS> asac, thanks... if there is some problems...I'll ping you. ok?
<asac> AlinuxOS: sure... its properly targetted ... so my workflow should catch it.
<AlinuxOS> asac, thank you!
<wasabi> So does apport provide anyway to submit kernel dumps? :)
<emdash_> i'm working on a free software project (www.pitivi.org) which depends on the latest gstreamer. we'd like to make packages of this software available to users running feisty. what would be the best way of going about this? are there maintainers who would be willing to handle building packages? are there repositories on which we could host the packages?
<Amaranth> emdash_: Sounds like you want the PPA system
<Amaranth> emdash_: https://help.launchpad.net/PPAQuickStart
<emdash_> thank you
<emdash_> i'll look into that
<emdash_> looks like i need to do some homework first
<torkel> emdash_: pitivi is already available in feisty, 0.10.2 though
<emdash_> we are entering a 0.11.x unstable release period
<emdash_> also 10.2 has no features
<emdash_> we'd like to make periodic development releases so that people can try pitivi
<emdash_> and so that when people complain that it doesn't do anything we can point to the package repository and say "install this version"
<emdash_> http://www.joelonsoftware.com/articles/fog0000000069.html
<emdash_> oops
<emdash_> ignore that
<keescook> is linux-image-2.6.22-11-xen supposed to exist for amd64 or does it FTBFS which is why it's i386 only?
<zul> keescook: no it didnt get added in the last upload, hopefully the one coming up
<keescook> zul: okay, but it's meant to work?
<zul> yep a couple of users are using it right now afaik
<keescook> cool; I had a friend ask about it and figured I'd ask.  :)
<superm1_> zul, are you expecting the unionfs mess to be sorted in the upcoming upload, or is that later?
<zul> superm1_: no idea
<superm1_> k
<jwendell> Hi, ScottK
<ScottK> Hello.
<jwendell> ScottK, please, consider to ship vinagre in gutsy, i really like to have users testing it...
<ScottK> jwendell: For that you can use PPA.
<ScottK> I understand what you want, but there is limited time for the archive admins that have to review all new packages.
<ScottK> There are 5 people on motu-uvf.  You need to convince 2, so maybe half the others will agree with you.
<Ng> anyone seeing segfaults from network manager (or maybe wpa supplicant, I'm not sure) recently?
<mneptok> Ng: i've been seeing NM prevent shutdown
<mneptok> but ... NM hates me.
<mneptok> and i hate it. there's a beautiful symmetry.
<wasabi> Hmm. Audio driver ceased working in 2.6.22-11
<Amaranth> wasabi: got linux-ubuntu-modules?
<wasabi> linux-restricted you mean?
<Amaranth> no
<wasabi> Oh I see. Hmm. No I didn't.
<Amaranth> the hda-intel driver moved there
<wasabi> Ahh. Why?
<wasabi> And why wasn't this installed by default? :)
<Amaranth> it is installed by default if you have the linux-generic metapackage
<wasabi> No metapackage that I can see.
<wasabi> Oh. Hmm.
<Amaranth> and it moved there because we got a version from alsa directly
<wasabi> Hmm. These driver packages should kick off udev to reprobe. :0
<wasabi> Thanks. That did it.
<Lure> what does "failed to upload" build failure mean? How can we fix it?
<Lure> example: https://edge.launchpad.net/ubuntu/+source/kdepim/4:3.5.7enterprise20070907-0ubuntu1/+build/386972
<Lure> same for lpia
<Lure> doko: gcc crashed on sparc when building kdepim: https://edge.launchpad.net/ubuntu/+source/kdepim/4:3.5.7enterprise20070907-0ubuntu1/+build/386977
<Fujitsu> Lure: It means that Soyuz broke, and you should poke one of the Soyuz guys.
<Lure> Fujitsu: who are soyuz guys?
<Fujitsu> cprov: ^^
<Lure> Fujitsu: thanks a lot!
<Fujitsu> np
#ubuntu-devel 2007-09-13
<mekius> on the live cd, it starts up with a boot menu, is there anyway to change the background of this?  what files do i need to unpack/edit/etc?
<wasabi> Blah. New kernel has also caused my bcm to be unable to scan/connect to anything.
<pitti> Good morning
<StevenK> Morning pitti
<StevenK> pitti: Most of the boost stuff has been sorted out - schroot fails to build, which has been fixed in Debian, and there are no Ubuntu changes. Would you mind sync'ing it? (It's a -1 to -1.1 jump)
<pitti> StevenK: not at all, doing
<StevenK> The other is sfftobmp, which is maintained by doko_
<pitti> StevenK: does that mean 'please sync it'?
<StevenK> pitti: sfftobmp? No, it's unchanged in Debian.
<StevenK> pitti: It means I need to talk to doko_. :-)
<desertc> What do you think - Is Valve bringing their Steam Engine to Linux?
<desertc> http://www.valvesoftware.com/job-SenSoftEngineer.html
<maikmerten> nope, looks more like server backend, not client
<maikmerten> Oh, missed "Port Windows-based games to the Linux platform."
<desertc> Yes, was just going to point it out.  I was thinking servers, too, when I first saw it.
<desertc> It would be interesting, I think, for Ubuntu, if there was Steam Engine for Linux.  It is a very popular commercial software distribution system.
<maikmerten> OTOH they may only want to port the server part of Windows games to Linux
<YokoZar_> steam runs perfectly in Wine desertc
<desertc> But that is not a supported solution.
<YokoZar_> Well having a supported version of Wine would be.  Then it'd be trivially easy to support, especially compared with rewriting the whole thing using another software library
<keescook> I must be up too late!  good morning pitti!  :)
<YokoZar_> Not to mention most of the steam apps use Windows only stuff (eg Direct X) that requires Wine
<YokoZar_> So unless they're going to rewrite everything, they'll have to rely on Wine at some point.
<pitti> hey keescook!
<desertc> YokoZar_, That supported "wine+WinApp" is the path the game EveOnline is taking.
<keescook> pitti: I've got a cupsys that just built with some minor changes to the profile (use @{PROC} @{HOME}), if you don't anything anything about to go in, I can go ahead and upload it.
<YokoZar_> Which is why Wine should make a 1.0 release, and why we should include it with Hardy.  That way Valve can just say "use Ubuntu Hardy or later" rather than, say, "use a version of Wine greater than 0.9.44, except 0.9.48 and 0.9.52 which have regressions)
<YokoZar_> desertc: It's also what Google did with Picassa.  They just bundled a copy of Wine with Picassa, and targetted that directly
<pitti> keescook: sure; please send me a debdiff, though, so that I can commit it to the bzr/svn
<YokoZar_> desertc: if we, at the distribution level, support a Wine version, then ISVs won't need to go through all that hassle.  And, let's be honest, almost no one knows that much about Wine, especially Windows people.
<desertc> YokoZar_, That is an option - I will grant you that.  I think it is in Free Software's best interest (and Ubuntu's) to have commercial companies supporting real-Linux solutions, because they will be compelled to work with the community.
<desertc> I do not think simply getting a Windows app running on Linux through Wine gets much for the community in the long run, even if it is another application that runs on Linux in the short-term.
<YokoZar_> Valve is as close to a Microsoft shop as you can get.  They do everything in Direct X, and Gabe Newell actually worked for MS.  Even still, they have quite literally tens of thousands of users using Wine.
<YokoZar_> What difference does it make if an ISV makes a proprietary app for Linux that works via Wine or a proprietary app that works via SDL?  The app is still proprietary, and the library is still free.
<YokoZar_> This is especially irrelevant with full screen games, where we don't even have to worry about look and feel matching
<desertc> I think that companies that use SDL help improve SDL.  Also, companies that work with the Linux community, tend to give back to the community by opening their code - a new library or a software engine.
<YokoZar_> Well, Google helped improve Wine in much the same way.
<pitti> keescook: I have a pending fix in svn, though
<YokoZar_> desertc: I think that tendency isn't because they're apps work on Linux, it's because community-minded companies make Linux apps.  I don't see Valve opening anything, even if everything worked on Linux perfectly.
<keescook> pitti: doh, I just sent and uploaded.
<pitti> keescook: that's fine, thanks
<YokoZar_> desertc: Still, you raise an interesting question about short and long term consequences.  Do you think that more Linux users is good for Linux in the long run, even if they're using Wine for some of their apps?
* StevenK watches the buildds choke over the rebuilds he uploaded.
<desertc> I don't agree with you on that point.  Valve may not open something today, but if that engineer they are hiring is a FOSS developer, then he will be in a position to effect the Valve decisions one day.  Maybe 5 years from now Valve will make a valuable contribution to FOSS because of it.  If they chose to simply use Wine, then there would be assuredly be no such contributions.
<desertc> Now I have to run, too late for me here.  Night!
<desertc> Thanks for your thoughts, YokoZar_
<kagou> good morning
<StevenK> pitti: Can I convince you to look at a few things in the NEW queue?
<pitti> StevenK: you can
<StevenK> pitti: virtualbox-ose, which has had it's DFSG and maintainer troubles sorted out, and kompozer because tonyyarusso is getting begged by users.
<pitti> \sh_away: erk, I forgot to build the new CD images for you, I was distracted with some phone conf calls yesterday, sorry; were this morning's images enough for testing?
<dholbach> good morning
<mdke> morning dholbach
<dholbach> hey mdke
<mdke> dholbach: do I have to do the version number for gnome-user-docs manually? I had been under the impression it was generating it automatically when i did "dch -i"
<dholbach> no, it just increments the last numerical part of the version number
<mdke> dholbach: aha. Ok i'll do that now
<dholbach> you imported new stuff from upstream, so you have to bump it manually
<dholbach> thanks a lot
<dholbach> I'm looking through the sponsoring queue at the moment, so I'll notice, once you've changed the bug
<mdke> dholbach: pushed. I also merged again from upstream (changes to one po file), do I need to do a new debdiff?
<doko> pitti: please demote db =)
<dholbach> mdke: no, not necessary
<dholbach> mdke: I'll look at the bug again
<pitti> doko: \o/
<mdke> dholbach: thanks
<dholbach> mdke: rock on :)
<dholbach> mdke: I'll change it to ubuntu1
<dholbach> mdke: or do you want to do it?
<mdke> oh damn. Feel free to do it and I'll do it in the branch
<dholbach> ok, I'll push it to my fixes branch
<mdke> dholbach: I already pushed
<dholbach> ok great
<dholbach> doing a test build
<mdke> thanks dude
<dholbach> de rien
<dholbach> hum, it should be 20070912, sorry for being picky
<dholbach> I'll push it to my branch later on, so you can simply merge from there
<mdke> dholbach: i think 13 works
<mdke> that's today
<dholbach> 12 was the last commit upstream
<mdke> dholbach: true, but the merge was done today, so it's in sync with today's svn
<mdke> I don't mind if you change it though
* Hobbsee waves
<mdke> hi Hobbsee
<dholbach> ok, I'm happy with both - it's just the sniplet I added at the end of the build checks the last note in 'ChangeLog'
<dholbach> hey Hobbsee
<mdke> oh i see, ok
<dholbach> mdke: I'll also add a (LP: #12345) to automatically close the bug you opened
<mdke> oh wow, that's cool
<MacSlow> Greetings everybody!
<dholbach> hey bigon
<bigon> dholbach: hi :)
<dholbach> bigon: do you think we should have something like http://wiki.ubuntu.com/DesktopTeam/TODO for the ubuntu telepathy team?
<Hobbsee> asac: it's not NM mangling (from yesterday).  it's that the Uni IT department sucks, and cant make their connection work :)
<MacSlow> hi Hobbsee
<dholbach> bigon: I know that the telepathy todo list wouldn't get that full, but maybe we could attract some new followers for the team :)
<dholbach> bigon: I know of at least 4 packages we should get in also (for hardy) :)
<dholbach> mdke: pushed to my branch, uploading the package now
<dholbach> (still pushing...)
<bigon> dholbach: yep a todolist is maybe a good idea :)
<bigon> dholbach: which packages?
<dholbach> bigon: CupsAndString 0.1, soylent 0.1.0, banter 0.1.10, decibel 0.5.0
<dholbach> bigon: I'll create that wiki page
<pitti> calc: still here by chance?
<pitti> doko: the CDs recently exploded because java-gcj-compat was added (which pulls in libgcj8-jar); any idea why?
<\sh> cjwatson, pitti: the daily i386 iso from this morning (what I need to test) is oversized
<pitti> \sh: right, see above ^; just trying to figure out the reason
<doko> pitti: didn't look, but probably OOo now depends on java-gcj-compat instead of gij ?
<pitti> yeah, it's most certainly due to OO.o
<\sh> pitti, yepp, just wanted to tell you that I can't test or I'm trying to get an 800MB blank media, which is quite impossible here
<bigon> dholbach: I've already made a package for soylent but I never upload it because It think soylent need a bit more work before be really usable
<dholbach> nice
<dholbach> but that's a good start
<asac> Hobbsee: good ... thanks ;)
<Hobbsee> asac: :)
<Lure> pitti: morning
<pitti> doko: ah, indeed; most apps still prefer gij, but -officebean pulls it in
<Lure> pitti: we got bug fix for canon second try problem and it "works for me", just need confirmation from allee if it helps him too
<pitti> Lure: ah, good!
<Lure> pitti: have sent mail to kubuntu-devel@/ubuntu-devel-discuss@ for wider testing
<Lure> pitti: if you have time, it would be good to review merge I did -> it is in my ppa
<doko> calc: pretty please, merge new stuff from debian, don't reapply all ubuntu changes on each merge ...
<doko> pitti: is officebean really on the cd?
<pitti> doko: yes, it's also a new package on CD
<pitti> doko: got introduced on image 20070912
<Kmos> edge is not working for apport
<Kmos> LP beta :-(
<dholbach> the new pylpbugs knows how to work with edge - pitti: maybe you need to update the cookie?
<pitti> dholbach: how so? the apport retracer bot user is not in -beta-testers, so it uses the normal lp
<dholbach> oh ok
<pitti> doko, calc: bug 139309
<Ubotu> Launchpad bug 139309 in openoffice.org "Please drop -officebean dependency" [High,New]  https://launchpad.net/bugs/139309
<pitti> Kmos: you mean on the client side? do you have the very latest python-launchpad-bugs?
<Kmos> pitti: i've my system updated
<Kmos> pitti: the one changed by dholbach yes
<StevenK> doko: sfftobmp in Debian doesn't build with the new boost, would you like me to NMU it and then get it sync'd?
<doko> StevenK: go ahead
<asac> StevenK: hey ... did you upload gnash?
<doko> mvo: the command-no-found bugs ... I suppose a rebuild of the database would help
<StevenK> asac: Yes, yes, I did.
<asac> StevenK: why don't you stop when you see something like: Xs-Vcs-Bzr: http://bazaar.launchpad.net/~ubuntu-core-dev/gnash/ubuntu
<StevenK> asac: I only realised that was a bad move *after* it hit upload.u.c. I'm so sorry.
<asac> ok
<siretart> is patches.ubuntu.com currently disabled? or is it a temporary problem wrt processing new uploads?
<StevenK> asac: It was only a changelog entry, which I can commit and push to that branch when I get home, if you wish?
<asac> StevenK: no its ok ... will do it
<asac> StevenK: if I have questions, I let you know :)
<StevenK> asac: Okay. Sorry for the trouble.
<asac> np
<Kmos> pitti: i got the OOPS-621EC17 when tried to report the bug.. after I click on "Continue" on Edge (Beta)
<Kmos> always got timeout and OOPS
<pitti> Kmos: ah, LP bug then
<Kmos> i've some packages to report :-(
<Kmos> pitti: https://edge.launchpad.net/ubuntu/+source/flashplugin-nonfree/+filebug/rja7OGcXmR2N7PDRI9OX8izu2pu
<Kmos> this is the url
<pitti> Kmos: hm, that works for me
<Kmos> pitti: you clicked on continue
<pitti> no
<Kmos> try to do it
<pitti> Kmos: works
<pitti> Kmos: but I won't actually file the bug since I don't have a good subject/description
<Kmos> ok
<Kmos> strange to not work here
<Kmos> pitti: you're in LP beta right?
<pitti> yes
<Kmos> https://bugs.edge.launchpad.net/ubuntu/+source/flashplugin-nonfree/+bug/139255
<Ubotu> Launchpad bug 139255 in flashplugin-nonfree "package flashplugin-nonfree 9.0.48.0.0ubuntu9 failed to install/upgrade: " [Undecided,New] 
<Kmos> it's already reported
<asac> Kmos: can you please attach more info to that bug?
<Kmos> asac: sure
<doko> pitti, calc: lapack3 and refblas3 were pulled in as well (we might want to build with the internal sp-solve again)
<Kmos> do you want my crash report ?
<asac> Kmos: well ... the report claims that flash cannot be installed ... if that is not your problem then I misunderstood :)
<Kmos> asac: yes, it's also my problem
<pitti> StevenK: kompozer? Oh noes, yet another mozilla tree copy?
<pitti> those recently fork like hell
<asac> Kmos: please add that info
<Kmos> asac: done
<Kmos> pitti: it's a newer nvu.. like bugs fixed
<asac> Kmos: i don't understand ... do you get that crash report while installing?
<asac> Kmos: further, the initial reporter mentions a md5sum mismatch
<Kmos> asac: upgrading
<tonyyarusso> pitti: Well, at least this one is replacing a package rather than adding one (as nvu was dropped from the repos for feisty)
<Kmos> asac: that tried after to install
<pitti> why can't packages like this build against firefox-dev or so?
<asac> Mithrandir: bug 139255 .... you forgot to take care that the midbrowser dir exists ;)
<Ubotu> Launchpad bug 139255 in flashplugin-nonfree "package flashplugin-nonfree 9.0.48.0.0ubuntu9 failed to install/upgrade: " [Undecided,New]  https://launchpad.net/bugs/139255
<tonyyarusso> I'm not sure...I'll need to ask about that
<asac> pitti: this discussion is (as always) really fruitless
<asac> pitti: we have xulrunner 1.9 in mozillateam archive ... before that you cannot do such things with mozilla trees ;)
<pitti> tonyyarusso: (it won't work, don't worry; that's an upstream problem)
<tonyyarusso> pitti: (ah, phooey)
<Kmos> asac: so, i've clarified the bug ? =)
<asac> Kmos: i don't see how the crash is related ... but otherwise yes.
<Kmos> update-alternatives: unable to make /usr/lib/midbrowser/plugins/flashplugin-alternative.so.dpkg-tmp a symlink to /etc/alternatives/midbrowser-flashplugin: No such file or directory
<Kmos> this is one bug
<Kmos> maybe fir it
<Kmos> fix it
<pitti> it is apparently possible for epiphany or galeon
<asac> pitti: thats not a xul application
<asac> pitti: those are just gtkzmozembedders ;)
<pitti> ah, ok
<asac> anyway kompozer is even from the 1.7 branch
<asac> i'll leave it to the reader to figure out what that means :)
<pitti> asac: stuck with obsolete code which is full of known security holes?
<Kmos> http://www.aptana.org/
<Kmos> it's better to have this one
<Kmos> than kompozer
<asac> pitti: yeah ;) ... though kompozer doesn't really do remote stuff as a main use-case ... so the severity might be different.
<pitti> asac: you mean if it contains remote images or other remote content in a HTML page, it won't fetch and display them?
<asac> pitti: i am not sure ... but I would think it will
<asac> pitti: so yes ... you probably can trick users into executing local code by sending a specially crafted html page and ask him to open it in kompozer ... but you could do that with python and other scripts as well ;)
<asac> pitti: but i see the difference ;)
<zyga> doko: why did you move #135794 back to c-n-f?
<doko> zyga: bash.bashrc references /usr/lib/command-not-found, which is found in the current package. where is the problem?
<pitti> sjoerd: got a minute to talk about bug 118919? would it be fine for you to move dbus-launch to dbus proper, and have only the Xsession.d script in dbus-x11?
<Ubotu> Launchpad bug 118919 in dbus "dbus-launch does not exist in dbus" [High,Confirmed]  https://launchpad.net/bugs/118919
<zyga> doko: oh? then the bug is fixed
<zyga> doko: sorry for not checking this
<dholbach> calc: can you take a look at bug 135086? :)
<Ubotu> Launchpad bug 135086 in unzip "zipgrep: exit code always 0" [Medium,Triaged]  https://launchpad.net/bugs/135086
<Hobbsee> dholbach: do you know who could tell me about the purpose of gparted-disable-automount.fdi ?
<dholbach> dholbach: no idea - maybe people in #gparted on irc.gnome.org?
<pitti> dholbach, Hobbsee: I recently disabled automounting of fixed disks in hal, so that patch might be obsolete
<dholbach> pitti: I didn't touch gparted for ages
<Hobbsee> pitti: right.  because, obviously, it's breaking automounting - completely.
<pitti> Hobbsee: sounds like it would inhibit gnome-volume-manger and the KDE pendant from automatically  mounting newly craeted partitions while you work with them in gparted?
<pitti> Hobbsee: can you put that file somewhere?
<Hobbsee> pitti: ahhh.  right.
<Hobbsee> pitti: no, sorry, i rm'd it, and had everything automount properly again.
* Hobbsee can go and pull it from the source if you wish, though
<Hobbsee> i was *wondering* why my SD card wouldnt automount, at all.
<Hobbsee> nor my USB stick
<pitti> Hobbsee: sounds like it should be kicked then :)
<Hobbsee> sure enough, with that removed, it all works fine, and i dont have to mount via the command line anymore
<pitti> Hobbsee: I guess it did a blunt volume.ignore=True for all volumes or so
<Hobbsee> pitti: i wanted to know why it was actually there, before killing it :P
<Hobbsee> right
<Hobbsee> OTOH, do i *really* want to touch hal?
<pitti> Hobbsee: why would you?
<Hobbsee> pitti: i thought that patch was in the hal source.
<pitti> blimey, no
<pitti> Hobbsee: gparted probably
<Hobbsee> oh, hmm.
<allee> Hi Pitti, looks like the latest python db4,5/4.6 broke apt-listchanges.  bug 139259
<Ubotu> Launchpad bug 139259 in apt-listchanges "apt-listchanges crashed with DBInvalidArgError in hashopen()" [Undecided,New]  https://launchpad.net/bugs/139259
<DktrKranz> pitti: when have time, could you please check bug 130059 ?
<Ubotu> Launchpad bug 130059 in plr "[SRU]  R_HOME environmental variable not set" [Medium,In progress]  https://launchpad.net/bugs/130059
<Moniker42> hey, i wouldn't normally come to the dev channel looking for support - but i have a SATA drive that works perfectly well in ubuntu but isn't detected by the BIOS and breaks the Windows XP install disc (doesn't get to bluescreen / asking for SATA drivers even)
<Moniker42> it's stumped everyone i've asked...
<pitti> DktrKranz: bug updated
<DktrKranz> thabks
<DktrKranz> *thanks
<sjoerd> pitti: What we want to do at some point is to have a dbus-launch without X11 deps in dbus proper and have dbus-x11 have a dbus-launch-x11 variant
<sjoerd> pitti: dbus-x11 is useless if you have the dbus-launch depending on x11 in it :)
<pitti> sjoerd: hm; well, the benefit of dbus-x11 for me was to get rid of that Xsession.d script
<sjoerd> Heh, no the Xsession.d is what you want on every desktop
<sjoerd> What you want to get rid of is the x11 depends for headless machines running dbus
<pitti> bryce: FYI, I just sponsored a new -amd for Q-FUNK to Debian; we might want to sync that
<StevenK> pitti: So it would seem - why kompozer seems fit to include a mozilla source tree is beyond me.
<StevenK> doko: Do you have any preference if I use dpatch, or would you rather I edited the source files directly for sfftobmp?
<doko> StevenK: I don't care for that package
<mvo> hey mjg59! thanks for your compiz upload. do you want me to add you to the compiz-packagers team so that you can directly commit uploads to our bzr repository?
<sladen> mvo: he's asleep.  ati, specs, avivo etc
<mvo> oh, right
<mjg59> mvo: Yeah, that'd be helpful.
<mvo> mjg59: cool, I do that now. is it all rs480 chips that give trouble? I have three pci ids for it (one is the rs480m)
<xhaker> mvo, i think i have one rs480, those are ati  xpress 1100
<xhaker> mvo, right?
<mvo> xhaker: it seems to be. does it give you trouble with compiz?
<Amaranth> mjg59: What was the problem?
<Amaranth> Maybe we can detect it another way
<xhaker> mvo, i haven't tried. it shouldn't work anyway, i hear that there are some problems because it doesn't use direct memory, and shared instead
<Amaranth> Although I suppose we'll need pciid blacklisting for intel
<Mirv> cjwatson: are you sure gutsy installer strings are exported to rosetta correctly? carlos now made an import that added ca. 100 strings, but they were almost all related to Mythbuntu. using the 20070913 live image all the problems in bug 132157 are still there.
<Ubotu> Launchpad bug 132157 in ubiquity "Untranslated strings in gutsy installer" [Undecided,New]  https://launchpad.net/bugs/132157
<carlos> Mirv, cjwatson: I got it from http://people.ubuntu.com/~cjwatson/installer-po/
<mvo> Amaranth: do you know any specifc one to blacklist?
<Amaranth> no
<Amaranth> and for intel we could actually do something other than pciid blacklisting
<Amaranth> if intel and only texture xv output: no compiz
<Mirv> cjwatson/carlos: those do seem to have at least many of the texts that are currently not translated. besides some bug in installer the only other option I can think of is that the places for strings were changed, but the strings themselves stayed the same from feisty, so no new untranslated strings came to Rosetta but getting the updated files from Rosetta now to installer would fix the translations. though it would probably still leave th
<xhaker> mvo, nvm what i said earlier about the shared memory on rs480, didn't notice the newer version on the repos of the ati driver
<mjg59> Amaranth: compiz kills rs480 immediately
<tepsipakki> mjg59: so now that I've been running it happily on my r200 it refuses to start after an update?
<mjg59> tepsipakki: Yes. I blacklisted it on ati, because we currently have no mechanism for more fine-grained control.
<tepsipakki> mjg59: do you have such card?
<tepsipakki> I mean, have you tried with a newer driver..
<tepsipakki> ..which is now in UVF queue
<mvo> mjg59, tepsipakki: I just added pciid backlisting, so the next version wil be happy again
<mjg59> tepsipakki: This was with current git head, and it was Dave Airlie who was complaining about it
<tepsipakki> mjg59: right :)
<tepsipakki> mvo: excellent, thanks
<mjg59> mvo: Excellent, that sounds like it'll work nicely
<mjg59> mvo: Do you want me to dig out the set of PCI IDs? I can't remember whether there's more than one that fall into that class
<mvo> mjg59: I wonder if we should also blacklist i965 under intel if video does not work there
<mjg59> mvo: Probably, yes
<mvo> mjg59: I added three (took them from the ati website) rv480,rv480 andd rv480m
<mjg59> But it worries me a great deal that we didn't seem to have bug reports on this
<mvo> mjg59: I assume you have a machine where the error shows?
<xhaker> mjg59, it's probably because the people with this card are used to install fglrx
<mjg59> xhaker: Currently there's no way to do that, given that X exits immediately
<xhaker> mjg59, this card didn't have acceleration without it
<mjg59> mvo: Yes
<mvo> (ids: 1002:{5954,5854,5955})
<mvo> mjg59: what does happen? black window? crash?
<mjg59> mvo: Instant crash
<mvo> *ick*
<mjg59> But there's a large number of people with this hardware, and nobody complaining loudly, which makes me worry that basically nobody is testing this (or nobody expects it to work if they are)
<xhaker> mjg59, is that card supposed to have direct rendering ?
<xhaker> i'm testing it right now
<mjg59> xhaker: Yes
<mvo> mjg59: if that is true, then this would be very bad. I think we need to make very clear in the that all compiz bugs should be reported so that we get a more accurate picture. maybe a blog post or a mail to ubuntu-devel-announce?
<mjg59> mvo: Yeah
<xhaker> mjg59, i'm always getting direct rendering: No with the ati driver
<mjg59> xhaker: I'd file a bug, then. Might just be a missing ID.
<xhaker> hmm.. with LIBGL_DEBUG= verbose "unable to find driver: r300_dri.so"
<Mirv> ah, the 20070913 installer I'm running is now at 122%, interesting :D
<Mirv> hmm now it crashed, but I think it's the corrupt CD anyway, since I forcily wrote 716MB
<mjg59> xhaker: Do you have libgl1-mesa-dri installed?
<xhaker> mjg59, yes.. it's there.. 7.0.1-1...
<ogra> Mirv, take a DVDRW or 800MB CD for the oversized images
<tepsipakki> xhaker: you have /usr/lib/dri/r300_dri.so?
<mjg59> xhaker: Mine contains /usr/lib/r300_dri.so
<mjg59> Sorry, /usr/lib/dri
<Mirv> ogra: yep, it's just that my only DVDRW drive doesn't work in linux for writing anything :( (Plextor PX-755SA SATA drive)
<ogra> gah, thats bad indeed
<xhaker> tepsipakki, mjg59: it's there.. reading more carefully.. "dlopen... failed... undefined symbol.. _glapi_get_dispatch
<mjg59> xhaker: Do you have the fglrx libGL installed?
<StevenK> doko: Do you want to a see a debdiff for sfftobmp?
<xhaker> mjg59, yes.. that might be it.. should i update alternatives?
<tepsipakki> xhaker: just purge fglrx
<mjg59> xhaker: Yes
<Mirv> xhaker: fglrx diverts the correct libGL and breaks non-fglrx
<tepsipakki> the mother of all evil (=bugs :)
<xhaker> mjg59, confirmed. it crashes.. even though i think this is progress.. it has direct rendering now.. :)
<hunger> Hmmm.... this output from aptitude is unexpected: "Removing linux-ubuntu-modules-2.6.22-9-generic ..." followed by "update-initramfs: Generating /boot/initrd.img-2.6.22-9-generic".
<StevenK> hunger: Which means /lib/modules/2.6.22-9-generic still exists
<hunger> StevenK: Those lines happend one after the other. Once aptitude is done the initrd is properly removed.
<StevenK> hunger: So ubuntu-modules got removed, but the linux-image was still installed?
<hunger> StevenK: Oh, forget it. I overlooked the modules in the first line.
* hunger shuts up.
<pitti> bryce: hm, today's live CD has ridiculously large fonts; is that due to the DPI now being fixed to 100 in the X server?
<pitti> bryce: not sure what the default was in feisty, but maybe more like 85?
<Seveas> pitti, 96 is default -- on new installs it's set to 126 in gnome
<Seveas> annoying :)
<pitti> ah, that might be it, too
<Seveas> even on upgrades from feisty to gutsy it's set to 126
<ogra> Seveas, thats progress :) we expect users to have at least 30" displays now :P
<Seveas> hehe
<Seveas> it was annoing on 1024x768
<StevenK> ogra: I'll use one if you provide it
<ogra> heh
* agoliveira sees very well and likes small fonts, thank you very much :P
<ogra> i need my TV :)
<Seveas> the 'Advanced' button in the font properties thing was invisible
<Seveas> so I couldn't change it!
<pitti> ogra: but those usually have a lower DPI than those tiny 11" laptop screens, don't they?
<ogra> pitti, higher imho
<pitti> ogra: 30" on 150 dpi? that's like 3000x2500 pixels...
<Seveas> yummy
<ogra> yeah :) crisp
<Seveas> I could live with that resolution :)
<pitti> but such high DPIs strain your eyes to the max...
<hunger> pitti: They do?!
<hunger> pitti: Fonts just look better with a higher DPI here.
<ogra> yeah
<pitti> hunger: well, sure, if you scale everything up, but then it's quite moot :)
<ogra> antialiasing is better etc
<hunger> At least as long as I do not abuse the system to display 5pt fonts (which are actually still readable if you get *very* close to the screen).
<hunger> pitti: The only thing that annoys me is that you guys keep changing font sizes (or probably better DPI settings) at least twice each release cycle:-)
<pitti> hunger: not only you
<StevenK> pitti: Just curious, can you sync from Incoming?
<pitti> StevenK: yes; it's a little more effort, but not too much
<Whoopie> mjg59: Hi, any specific reason why you removed s2ram from the uswsusp package? Asking because of bug 134238
<ubotu> Launchpad bug 134238 in uswsusp "Please re-enable build of s2ram binary" [Undecided,Confirmed]  https://launchpad.net/bugs/134238
<Whoopie> working with bluekuja on the uswsusp package.
<mjg59> Whoopie: Because it's inappropriate for Ubuntu
<Mirv> mjg59: oh btw bug 86666 has the full vbetrace in case you didn't notice it, but I understand it's a rather low priority thing
<ubotu> Launchpad bug 86666 in usplash "Feisty crashes after grub, before boot process, if usplash is enabled (amd64)" [High,Triaged]  https://launchpad.net/bugs/86666
<Whoopie> mjg59: but what if the users want to use it although it needs tweaking some scripts?
<Whoopie> mjg59: shall we close the bug report then?
<mjg59> Whoopie: There's no reason to use it on Ubuntu
<ogra> mvo, i have displayconfig-gtk in my menu as a non admin user ... i guess thats not intended
<calc> doko: i don't reapply the ubuntu stuff each new merge, i take the debian diff between bzr revisions and apply it to the ubuntu bzr, which is effectively like applying the ubuntu changes each time but without the chance of breaking things as much, we are supposed to writing the changelog entries like we merged from debian though
<calc> doko: each #ubuntu1 upload is supposed to list all remaining changes from the debian version
<calc> doko: but each #ubuntu1+ can list just changes from the #ubuntu1 upload, which is what I am doing now
<doko> calc: just missing my entries from bzr (which is not current) and which makes it difficult to follow ...
<calc> doko: sorry i wasn't able to commit them yesterday I was at the doctor/emergency room most of the day :(
<calc> doko: i will be getting them committed today
<calc> doko: my wife appears to be recovering on her own though the doctors still couldn't determine what was wrong with her when I left the ER last night, she was supposed to be checked into a room eventually :\
<calc> doko: supposed to since I haven't head from her yet since cellphones don't work in the hospital
<calc> er heard
* calc bbiab
<unggnu> hi all
<unggnu> Is it possible that the new Ati driver xorg-driver-fglrx 8.41.7 make it to Gutsy since they should be around 50-90% fastern than the old one?
<xerakko> anybody has tested new ati driver?
<geser> you mean the fglrx one or the FLOSS one?
<mjg59> xerakko: The Novell driver has not been released yet
<xerakko> the fglrx
<xerakko> the 0.41.7
<xerakko> the fglrx 8.41.7
<Amaranth> xerakko: from what i've heard it actually breaks r500 and older a lot
<Amaranth> xerakko: the main focus was r600
<xerakko> :(
<superm1> unggnu, not to mention that it has a big warning on the driver download page not to package it in distros
<Amaranth> driver next month is supposed to catch the rest up
<superm1> it breaks my r300 FirGL hardware
<Amaranth> right, it's only for r600
<Amaranth> if it works on older cards you got lucky
<unggnu> superm1, ok, sorry :)
<tepsipakki> 8.42 should also add aiglx support
<tepsipakki> ..finally
<unggnu> would be great
<xerakko> yes, but if it only works in r600 cards I fucked again :/
<\sh> damn...what was the name of the kernel driver to use the LSI Logic SCSI Hostadapter for a vmware instance?
<unggnu> Could someone of the acpi-support guys have a look at https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/136380 . At least a comment what is wrong with the patch please. Thanks.
<ubotu> Launchpad bug 136380 in acpi-support "[Gutsy]  sonybright.sh doesn't use the correct value range" [Undecided,New] 
<zul> \sh: buslogic or something like that
<\sh> zul, buslogic was the old one...but LSI Logic is the new...I wonder what I forgot in my kernel that my vmware instance is not booting up anymore...damn
<\sh> if some of the main devs is so nice and check bug 139376 and push it to the archive admin?
<ubotu> Launchpad bug 139376 in quagga "[sync request]  please sync quagga 0.99.9 " [Undecided,New]  https://launchpad.net/bugs/139376
<\sh> s/some/one/
<\sh> oh damn
<\sh> I need sleep...it needs a merge
<terlmann> ok is there anyone here who would help me get something implemented right away ? a policy I mean , not a feature or fix to code.
<terlmann> elmos smurfs and rabbits. is there a cookie monster in here too ?
<Hobbsee> terlmann: is this the same thing as you were saying in #ubuntu+1?
<terlmann> YEA!!
<Hobbsee> terlmann: and you are really bad at asking useful questions
<azeem> and you're root
<terlmann> and telinit one
<terlmann> nice of you to notice
<Hobbsee> let me read the whole thing, sec.
<\sh> zul, it was fusion mpt for vmwares lsi logic support...and this I missed out in my kernel config ;)
<Hobbsee> terlmann: dude, no.  just no.
<terlmann> could I submit a petition to test ?
<Hobbsee> dapper --> hardy will already support that.  LTS --> LTS.  not random versions to later random versions
<Hobbsee> no.
<Hobbsee> and really, #ubuntu isnt the discussion for that either.
<Seveas> there isn't really any place to discuss that
<Hobbsee> terlmann: you can use a clean cd to upgrade, if you wish.  save /home.
<terlmann> I was counsuling a user of hoary who wanted to upgrade.
<Hobbsee> terlmann: yes, i know.  i can read.
<Hobbsee> terlmann: and it's been discussed before, and the answer is still no.
<terlmann> Fine.
<terlmann> now onto todays topic for me
* \sh wonders what was the question ;)
<Seveas> \sh, supporting hoary -> gutsy
<StevenK> Directly?
<Hobbsee> \sh: supporting hoary --> feisty or hoary --> gutsy.
<Hobbsee> StevenK: yes.
<StevenK> Hoarty is completly unsupported
<StevenK> Er, Hoary
<\sh> Seveas, Hobbsee ah...no that doesn't work ,)
* Hobbsee hates to think of the overhead for being able to upgrade to any newer version from any other.  just no.
<Seveas> \sh, and never will unless someone pays developers to make it work
<Hobbsee> \sh: we know. terlmann doesnt seem to
<terlmann> is there someone in here who can teach me how to develop a specialized ubuntu derivative. I want to make a specialized pre-dapper like os with extremely limited hardware support that can outrun the devel on the i686 architecture.
<\sh> actually it's a FAQ which is written somewhere on the wiki or the ubuntu.com pages...when I remember correctly
<terlmann> devil*
<Hobbsee> there's a derivatives mailing list too, i believe
<Hobbsee> terlmann: btw, if people in #ubuntu+1 tell you it's a stupid idea, it's unlikely that we think differently.
<bddebian> Heya
* Hobbsee notes it's very useful to be omnipotent
* ScottK has tried dapper --> gutsy and gotten there, but not without more trouble than it was worth.
<terlmann> Its unrecommended and unsupported. If you got flamed for recommending it and breaking systems, I can see the motive for not doing so.
<Seveas> ScottK, warty->hoary was like that for me
<Hobbsee> terlmann: because of the sheer amount of work in making sure all the dependancies work.  time better spent doing other things.  think about it.
<StevenK> To be honest, if you have a mirror very close, you can jump from Hoary to Feisty in an afternoon
<Seveas> StevenK, not without some pain (iirc, lvm package breaks)
<terlmann> well I did it. I went hoary-feisty in one fell swoop. with only one command. then recently I decided to try it with warty - gutsy.
<Seveas> but you can do warty->gutsy if you want to and know how to debug package problems :)
<Seveas> !worksforme | terlmann
<ubotu> terlmann: Common Sense: Just because you can, does not mean you should (and especially recommend to others). Think before you do. "Works for me" does not mean it is ok. The latest version of everything is not always useful if you aim for stability. Please see http://geekosophical.net/random/worksforme/
<terlmann> Seveas : the limitations on upgrade paths are reduced when we are discussing fresh installs right ?
<StevenK> Seveas: I did Dapper -> Edgy -> Feisty in an afternoon with no pain at all
<Seveas> sure, but if you do a fresh install, why not install the latest version anyway...
<Amaranth> dapper->hardy is going to be fun
<terlmann> what if you dont have the latest disk ?
<Seveas> download it
<StevenK> Amaranth: And is going to result in fun discussions at Boston
<terlmann> what if you cant ?
<Seveas> you're going to have to download the packages anyway
<StevenK> terlmann: Or order one from shipit.ubuntu.com
<Hobbsee> Amaranth: fsvo fun.  i think people are still ignoring that problem.
<terlmann> some people insist on using what they have. not my way , but they do.
<Amaranth> StevenK: yeah, that'll be interesting
<Seveas> terlmann, that's their problem
<terlmann> was there a release before warty ?
<Hobbsee> Amaranth: it's probably not bad if you update the toolchain and apt first.  although, will the GUI tools then break?
<ScottK> terlmann: If you did hoary -> feisty you almost certainly have pty problems you need to find and fix.
<Hobbsee> terlmann: dude...if you don tknow that kind fo stuff, and want to change policy...
<Seveas> terlmann, you could try debian woody --> ubuntu gutsy :)
<terlmann> ScottK : it replaced everything , but it worked.
<Amaranth> Seveas: potato
<ScottK> terlmann: Appeared to work.  Not the same.
<ogra> Seveas, why woody ? bo was great too :)
<Seveas> ogra, ;)
<terlmann> ScottK : not appeared. worked perfectly
<ScottK> OK.  There's an unfixed PTY bug that will bite you when you skip edgy.  Good luck with that.
<\sh> well, this discussion is totally useless...for users it's not recommended...and if someone is good, he follows the normal upgrade paths...
<terlmann> and goes through dapper to edgy
<terlmann> sounds logical
<Amaranth> it's faster to backup and do a fresh install
<StevenK> \sh: Or he deals with breakage and keeps both pieces
<ScottK> Agreed.  As I said, I did it as an experiment and then did a fresh install after.
<\sh> StevenK, he could also use a knife to cut himself...yeah, can be done, but it's painful
<StevenK> \sh: That might be more productive. :-)
<StevenK> pitti!
<pitti> re
<StevenK> pitti: How long does the NBS list take to regenerate?
<pitti> StevenK: depends on how long it is, but usually < 10 mins
<StevenK> pitti: Because I note the publisher has just finished, and I want to see if I missed anything obvious.
<pitti> StevenK: started
<StevenK> pitti: Danke
<terlmann> Im going back to +1 , dont want to waste your space. konversation closed.
* StevenK is waiting for a mail from ries..
<StevenK> pitti: Right, if you wouldn't mind sync'ing sfftobmp 3.0-7.1 from Incoming
<pitti> StevenK: cron.NBS finished
<StevenK> pitti: Ah, excellent.
<StevenK> pitti: You could let through virtualbox-ose from binary NEW if you wished, too. :-)
<dholbach> PPA and Ubuntu Packaging 101 in #launchpad in 4 minutes
<Keybuk> dholbach: doesn't that clash with the team meeting? :p
<Keybuk> (different channel
<dholbach> if you mean the launchpad team meeting, no that's over :)
<Keybuk> the community development team meeting ;)
<evand> if we used Exchange, this kind of thing would never happen.
<Keybuk> +1
<Keybuk> though I need to try out that esdgcal plugin
<Hobbsee> evand: it's more fun having lots of mental arithmetic
<Keybuk> http://code.google.com/p/google-calendar-backend/
<evand> AWESOME
<pitti> StevenK: syncs
<StevenK> pitti: Could I also convince you to wave your Wand of Death at bug 139261?
<ubotu> Launchpad bug 139261 in democracyplayer "Please remove democracyplayer from the archives" [Undecided,Confirmed]  https://launchpad.net/bugs/139261
<ogra> Keybuk, overwhelming content
<pitti> StevenK: remove democracy? our path to world dominance? :-)
<StevenK> pitti: :-P
<ScottK> Path to something.
<StevenK> pitti: The bug contains the reason why, and it's just another rdepends on the old boost
<mvo> community development team meeing? when/where?
<Keybuk> ogra: SoC
<Keybuk> mvo: now, #ubuntu-meeting
<\sh> pitti, bug 139376 you get a debdiff latest tomorrow morning...hopefully with patches to dapper/edgy/feisty as well
<ubotu> Launchpad bug 139376 in quagga "[UVF exception]  please update quagga 0.99.9 " [Undecided,New]  https://launchpad.net/bugs/139376
<pitti> StevenK: miro does not build a transitional package
* \sh goes home now...
<StevenK> pitti: It Provides/Conflicts/Replaces democracyplayer. Not enough?
<pitti> StevenK: nope, you need a real transitional package
<pitti> StevenK: Provides: never win over real packages on upgrades
<StevenK> pitti: Okay, I shall tell RAOF all about it tomrorow, and he can fix it.
<StevenK> pitti: Right, it looks like I dealt with 90% of the boost rdepends today, there's 4 source packages left, all of them under control.
<pitti> StevenK: dp removed
<Mithrandir> StevenK: you seem to have put in quite a lot of work there, thanks a lot.
<StevenK> Mithrandir: Not a problem. :-)
<StevenK> pitti: Oh thanks, I was expecting you to leave it until the new miro was uploaded.
<pitti> StevenK: doesn't make much of a difference (except for binary NEW)
<StevenK> Ah
<StevenK> pitti: Would you mind keeping an eye on wengophone's ia64 build? When it builds could you drag it out of binary NEW?
<pitti> StevenK: can do
<StevenK> Mithrandir: Oh, and this lot of work was nothing - I uploaded 72 packages for the libcurl transition mess.
* Mithrandir chalks up a couple of beers for SK
<StevenK> Just as long as they aren't American. :-P
<Seveas> he said beer, not piss ;)
<Mithrandir> the US has plenty of good beers.  Just not the big brands.
<StevenK> Since American beer is like having sex in a canoe
<pitti> fucking close to water?
<StevenK> Exactly. :-D
<StevenK> But okay, based on Mithrandir's comment, I shall change my joke to be s/American/main-stream American/
<Mithrandir> at least I had good beer when I was in Boston
* pitti dreadfully reminds the first (and last) Bud can he bought on a camping place for barbecue
<ScottK> Ugh.  Yeah.
<StevenK> Muahaha
<StevenK> That'll learn you
<pitti> s/reminds/remembers/
<StevenK> pitti: Did any Australian buy you a Fosters while you were over here?
<pitti> StevenK: I might have had it, I don't remember any more
<pitti> only that we had lots :)
<Mithrandir> Fosters isn't _that_ bad.  Just boring.
<StevenK> Fosters *is* that bad, compared to some of the other beers we have on offer.
<Mithrandir> oh, sure, but it's not nearly as bad as some of the bad US beers.
* StevenK idly wonders if he can convince pitti to bring some German beer
* ScottK prefers beer you drink with a fork (Guiness for example).
<Mithrandir> as an example of good US beer, you have most of the Anchor beers.
<Spads> Mendocino Brewing COmpany
<ScottK> Unfortunately it doesn't travel well.
<Hobbsee> mmm....brains.
<Spads> Red Tail Ale
<Spads> very nice stuff
<Hobbsee> brains are better than beer.
<pitti> StevenK: limited baggage :/
<StevenK> I might bring a 8-pack (that's right, it doesn't come in 6 packs) of Tooheys Extra Dry Premium
<StevenK> It's *dangerous* to drink, since it's so smooth
* StevenK pushes floe and hooker up hill. Build quicker!
<Mithrandir> I guess I could get some from either Ngne  (naked island) or Hndbryggeriet (the hand brewery) and bring.
<Mithrandir> only is they're bottle-conditioned, so they need to sit still for a bit before being consumed.  Like, a couple of days.
<StevenK> Oh, floe has started on wengophone. Yay.
<StevenK> Mithrandir: *Neat*
<StevenK> Oh, for want of more baggage space. Coopers is a bit like that.
<Mithrandir> coopers is good.
<Mithrandir> well, since UDS is for a week, it's not really a problem
<Hobbsee> assuming your luggage gets there :P
<StevenK> Haha
<Seveas> Hobbsee, you should be thrown in the pool for that :)
<StevenK> Mithrandir and I are about the same size, I can be convinced to bring a few extra shirts. :-)
<Hobbsee> Seveas: no, no, you've learned not to throw me in the pool, right?
<Hobbsee> Seveas: you've learned that attempting to break people's wrists is bad.
<Seveas> hehe
<Mithrandir> StevenK: shirts is usually not the problem.  It's the socks and such
<StevenK> Mithrandir: Oh, I've got my own problems with socks. :-)
<Mithrandir> with socks or SOCKS?
<StevenK> Both
<superm1> it appears that ubuntu-desktop is depending upon ubufox which is depending upon apturl, does this mean apturl was decided to be on by default then on new gutsy installs?
<dholbach> hum, is there a problem with cvs.freedesktop.org or http://bugs.freedesktop.org/ ?
<mvo> dholbach: I heard freedesktop.org is currently hit very hard because of the amd register documentation that is now hosted on www.x.org and that draw some attention ( ~70.000 downlods)
<dholbach> oh right
<dholbach> ok
<gnomefreak> superm1: if ubotufox needs it than yes. last i heard ubufox will be installed by default
<superm1> i'm kind of surprised ubufox would need it
<superm1> it appears ubufox is actually a recommend of *-desktop
<gnomefreak> maybe one of hte options it allows you to change would need it?
<gnomefreak> superm1: the des. still says ubufox - modifications for ubuntu firefox (default) install
<illovae> hello o/
<superm1> the big thing ubufox provides was a way to install extensions system wide
<gnomefreak> so im assuming its installed with normal install but asac would know best if it was or wasnt accepted for default install
<mvo> dholbach: we need a worumx update ;)
<gnomefreak> mvo: apt-listchanges is borked keeps segfaulting seems like (i removed it but thought i would let you know)
<dholbach> mvo: I think a uvfe was filed for it
<dholbach> mvo: ah no, it wasn't
<mvo> someone should :)
<mvo> gnomefreak: oh?
<mvo> gnomefreak: do you have a backtrace?
<gnomefreak> ill install it and grab it
<superm1> mvo, being listed as maintainer on apturl, do you know whether it was accepted for the default install then?
<superm1> or why asac depends upon it for ubufox?
<gnomefreak> superm1: i just asked him but he seems afk atm
<gnomefreak> hmmm let me see if logs have it
<mvo> superm1: it is already a dependency of some firefox thing, so it should be in
* mvo checks
<superm1> mvo, yea its a dependency for 'ubufox'
<asac> superm1: apturil is currently used for plugin finder wizard that allows you to install plugins packaged in ubuntu
<mvo> superm1: its on the CD already so I expect that it is part of the defaul tinstall
<superm1> asac, ah i see
<superm1> mvo, i remember reading about it, but that there was uncertainty regarding if its an unsigned apt repo or if you dont have the apt-key in your apt-keyring already, has that been resolved?
<mvo> superm1: it will not support unsingend repositores
<superm1> mvo, okay so it won't support PPAs then for now.
<mvo> superm1: unfortunately no, also it was deisgned with ppa in mind.
<mvo> superm1: its a limitation of ppas currently that they are not signed (and that is no good IMHO)
<superm1> mvo, yeah for now, we are mirroring our PPA off site and signing the release to simplify things
<gnomefreak> mvo: i cant find logs atm ill ping you when and if it happens again
<gnomefreak> seems to have done it on both upgrades i did yesterday and today
<superm1> mvo, okay well i'll play with it a bit then :) one more question, did you see my mail earlier this week or so ago about how the .desktop files get updated in g-a-i?
<mvo> gnomefreak: ok, thanks
<mvo> superm1: maybe :) did you send it to me personally? or to a list?
<superm1> mvo, to you personally
<superm1> i had thought perhaps it might have been overlooked for that reason :)
<mvo> superm1: ha! I have it and marked it as important :)
<gnomefreak> mvo: im gonna guess and say if it cant find changelog it segfaults. espeak update just showed changelog and didnt seg.
<mvo> superm1: I will try to answer it soon, please just keep naging me, I'm a bit overloaded currently with regular work, my backlog for mail is terrible
<superm1> mvo, no biggie, didn't want to nag too badly :)
<mvo> superm1: right :) but please do, otherwise it may fall to the floor.
<StevenK> Amaranth: Oh, I spoke to Bart today - according to him, metacity *does* talk when switching
<Amaranth> StevenK: hrm
<Amaranth> accessibility checker lies then
<StevenK> Amaranth: It could be Orca doing it
<Amaranth> but metacity has to do the accessibility stuff so orca can 'read' it
<StevenK> Yes, of course.
<StevenK> Amaranth: Try it yourself, Orca is brain-damagingly easy to set up
<pitti> asac: networks are just overrated *sigh*
<asac> pitti: yeah ;)
<ogra> pitti, yeah, we should use drums again :) will make work fun ... no gym anymore for canonical develpers :)
<asac> ok i pasted the log to the bug
* pitti hands ogra a floppy disk with is IRC answer
<ogra> lol
* ogra goes to search for HW with floppy
<pitti> asac: just in case you got the wrong impression: I would love to see n-m get decoupled from ifupdown
<StevenK> I have a whole two machines with floppy drives
<ogra> i still have a handfull in the basement
<ogra> but none of them in a bootable state
<pitti> asac: instead, I'd rather have it read the current status with ioctls and route, so that these changes becomes upstream compatible, too, and don't mess with other network setup tools either
<pitti> it's just so utterly hard to get it right
<asac> pitti: i didn't know that before ... but after the chat we had, I already saw that ;)
<StevenK> Actually, I have two working floppy drives in my junk pile
<asac> pitti: network-manager 0.7 has lots of things
<pitti> asac: ooh, is there a 0.7 released now?
<asac> unfortunately not
<asac> but its ment to be the "great" solution afaik ;)
<asac> hopefully be avail for gutsy+1
<asac> if we want to contribute ... we should do it there ;)
<asac> so its not worth to put too much effort into 0.6.5
<pitti> ack
<StevenK> Have upstream a plan about 0.7?
<gnomefreak> mvo: i found a crash report ill report bug and upload for you
<StevenK> Hmph.
<StevenK> Launchpad, show me more than fifteen lines of the build log!
<StevenK> (While the build is running)
<Keybuk> http://arstechnica.com/journals/linux.ars/2007/09/12/ubuntu-technical-board-votes-on-compiz-for-ubuntu-7-10
<Keybuk> heh
<StevenK> pitti: wengophone built everywhere, drag it out of NEW at your leisure
<asac> StevenK: what do you mean by "Have upstream a plan about 0.7"? do you ask for a prospective release date?
<pitti> StevenK: done
<StevenK> pitti: Thanks
<StevenK> asac: Not just a release date, but testing and rc's and so on
<asac> StevenK: since its a gnome project i hope that they try to release on next gnome release ;)
<Keybuk> asac: planned features?
<asac> StevenK: then rc's et al would be aligned with gnome as well i guess
<asac> Keybuk: haven't looked in detail
<StevenK> pitti: virtualbox-ose has built everywhere it's going to if you wish to drag it out
<asac> Keybuk: but will do so as soon as i am done with nm for gutsy ;)
<StevenK> Speaking of, P-a-s needs to be updated for it
<pochu> asac, Keybuk: http://live.gnome.org/NetworkManagerToDo
<Keybuk> "Work is in-progress to create a dbus-based control interface for wpa_supplication."
<Keybuk> ironic
<Keybuk> didn't they just rip out the dep on dhcdbd so that they could control it directly, rather than across D-BUS?
<asac> "KILL KILL KILL dhcdbd (DONE)" :)
<Keybuk> so they appear to have contradictory goals
<Keybuk> D-BUS simultaneously GOOD and BAD
* ogra scratches head about bug 139405
<ubotu> Launchpad bug 139405 in gnome-screensaver "screensaver does not start when you bring up a right click menu" [Medium,Triaged]  https://launchpad.net/bugs/139405
<ogra> i dont want my screensaver to start if i use my mouse ...
<asac> Keybuk: i think they prefer to communicate over dbus instead of unix sockets.
<Keybuk> yes, because sockets are hard
<Keybuk> and D-BUS is near=impossible
<asac> ;)
<Keybuk> developers appear much more macho if they use D-BUS
<Keybuk> :p
<hunger> ogra: I guess that bug is about right-clicking, have a menu appear and then doing nothing for ages with the menu still visible.
<asac> yeah ... they like to highly asynchronous behaviour ... no idea why
<Keybuk> after all, you can establish a simple two-way D-BUS connection in only 10,000 lines of C
<asac> hehe
<hunger> ogra:
<ogra> hunger, hmm, how is that related to the screensaver
<asac> yeah ... implement tcp on top of dbus ... thats great
<hunger> ogra: screensavers should trigger after x min of inactivity.
<ogra> right
<Keybuk> ogra: the upstream bug may explain more
<ogra> oh, you mean if the popup menu just *sits* there on the screen ?
<hunger> ogra: Independent of wether that inactivity happened after right-clicking on the desktop or not.
<Keybuk> you can inhibit screensavers from starting by leaving a menu open
<Keybuk> (some of us used to use this as a feature, of course :p)
<ogra> hehe
<ogra> ok, then i understand
<ogra> it read like the OP wanted the screensaver to go off while the right mouse button is in use :)
<hunger> ogra: Now that would be silly:-)
<Keybuk> of course, that bug needs careful fixing
<hunger> ogra: But otoh... users sometimes have silly ideas;-)
<ogra> yeah, thats what made me scratch my head
<Keybuk> since it would be a bug if, after the screensaver was unlocked, the menu wasn't still open ;)
<ogra> lol
<hunger> any progress on the open-vm-tools package since yesterday?
<keescook> okay, anyone know why enabling desktop effects seems to just kill my window manager?
<Keybuk> uhh
<Keybuk> because that's what it does?
<Keybuk> :)
<keescook> Keybuk: heh, well, right, but it doesn't start the _new_ decorator.
<superm1> keescook, desktop effects calls compiz --replace
<Keybuk> new decorator or new window manager?
<Keybuk> (they're different things)
<superm1> so it needs a new decorator and window manager
<Keybuk> try compiz --replace on a terminal
<keescook> now all my window borders are gone.  :)
<keescook> perhaps there is some gconf wipe I need to do?
<Hobbsee> you havent switched to kde, have you?
<keescook> Hobbsee: nopers
<Keybuk> keescook: is the window manager still working?
<tepsipakki> keescook: start gtk-window-decorator?
<Keybuk> ie. do window shortcuts work like Alt=F4
<Hobbsee> that's normal for kde, as k-w-d tends to segfault
<keescook> Keybuk: alt-f4 works against my xterms
<keescook> tepsipakki: compiz says it did start it
<keescook> Starting gtk-window-decorator
<Keybuk> ok, then you've not got the decorator for some reason
<keescook> kees     12073  0.0  0.3 127932 10048 pts/1    S+   09:49   0:00 /usr/bin/gtk-window-decorator --replace
<wasabi> I'm having random segfaults since ... updating gutsy yesterday.
<wasabi> Unsure if it's kernel or a dependency... since gdb itself usually crashes.
<wasabi> metacity just died.  weee
<keescook> wasabi: yeow.  do you use XFS?
<wasabi> Nope.
<keescook> hmp
<wasabi> Yeah, file corruption could be a possibility... just not sure how to isolate it.
<keescook> tepsipakki: any thoughts on how to further debug?
<wasabi> Let me reinstall the entire stack under metacity and see if it continues or something.
<keescook> wasabi: try comparing the md5sum of packages?
<wasabi> debsumming.
<wasabi> Oh. I've got some crap prelinked.
<wasabi> So that's not of much help.
<superm1> mvo, in playing with apturl a bit, its not possible to activate both universe and multiverse from an apt url is it?
<superm1> i can seem to do one or the other, but not both
<mvo> superm1: sounds like a bug, could you please report that?
<superm1> sure
<Hobbsee> mvo: what's your opinion on putting a conflicts/replaces libsvg, for libsvg1?
<keescook> mvo: is some incantation to clear the conf settings for compiz back to default?
<Hobbsee> mvo: it's outside of the packaging system, but it's going to hit every user who installed beryl-crack.
<mvo> keescook: there is a button for this in "compizconfig-settings-manager". we could also add this to the apperance capplet
<mvo> Hobbsee: sounds not bad to me if it helps users
<keescook> mvo: okay, thanks
<Hobbsee> mvo: i wonder if we need to do anything with libsvg-dev
<lamont> ltsp-build-client --security-mirror doesn't like to be redirected...
<lamont> adds a /ubuntu to the URL
<wasabi> keescook: Well, found an app that consistantly segfaults.... in libc.
<Hobbsee> mvo: done
<wasabi> Heh. Nice. I just reinstalled libc, and it works now!
<wasabi> dangerous stuff, that
<keescook> mvo: ccsm is nice, and things are working okay except that I still have no window borders and 3d windows are just black.  :P
<mvo> keescook: you call that "working" ?
<mvo> keescook: does it help if your run "gtk-window-decorator --replace" ?
<keescook> mvo: well, no, it's unusable, but I mean, I can confirm that the animations and things work
<mvo> keescook: do you have a nvidia ?
<keescook> mvo: decorator was already running.  yup, nvidia (I know there are issues with it, which is why I thought I'd go test it a bit)
<mvo> keescook: what kind of nvidia is it?
<keescook> GeForce 6100
<keescook> on-board
<keescook> (C51G)
<keescook> mvo: ah-ha! needed:     Option "AddARGBGLXVisuals" "true"
<mjg59> Keybuk: Why did you assign 60042 to acpi-support?
<mvo> keescook: ha! isn't that set automatically by the enable-nvidia script (or restricted-manager)? if not, we should file a bug :)
<Keybuk> mjg59: uhh, didn't I assign that to powernowd?
<keescook> mvo: well my xorg.conf pre-dates restricted-manager, so perhaps a test for it?
<mjg59> Keybuk: No?
<Keybuk> oh, I know, I did, but then got confused about the silly LP change where clicking on the "Affects" doesn't do the right thing
<Keybuk> and then put it to the wrong package in my dizzyness
<Keybuk> let me fix that
<Keybuk> (since powernowd is the init script that fiddles with the cpufreq stuff atm)
<doko> Hobbsee: does kmplayer build for you?
<Hobbsee> doko: havnet tried, tbh
<doko> Hobbsee: would you mind to start a build?
<sladen> must. rename.  powernowd.
<Hobbsee> doko: at 3.22am?  yes, i would mind.
<Hobbsee> doko: send me an email, and i'll try it after some sleep
<Keybuk> sladen: powernowdbd
* sladen runs away screaming
<sladen> dbcpowernowdd
<keescook> heh
<Keybuk> I, for one, will not mourn the passing of *that* package
<Keybuk> dhcdbdbdbdbdbdbdbd...what's up buck?
<Keybuk> then I just have to get rid of udev-udeb :p
<ikonia> best tweeky impression ever
<lamont> so, um, today's livecd... should I actually get running Xwindows? :-(
* lamont wanders off
<sladen> lamont: nah, somebody setup teh bomb on the X server
<Ng> does our thinkpad acpi module not have the fan control patches? (http://www.thinkwiki.org/wiki/How_to_control_fan_speed claims they are in mainline from 2.6.20, but I don't see the same control options in gutsy)
<lamont> sladen: really?
<lamont> I mean, it does want fglrx... :(
<lamont> was trying the livecd to see if I could figure out a working config that gave me 1680x1050 instead of 1024x768
* lamont gets dragged to lunch
<lamont> heh.  my bad... it came up
<sladen> ahhh, trackerd
<sladen> turns your CPU back into a 20Mhz part
<wasabi> oooh. system lock up that time.
<wasabi> ssh died... was still able to ping
<wasabi> well this is no good!
<ogra> sladen, just replace it with trackerd to speed up :) http://www.eyrie.org/~eagle/software/tracker/trackerd.html
<bhale> sladen: you can turn it off in tracker-preferences, but it still will start up trackerd and spin the hell out of your disk if it feels like it
<Arador> yeah, it's weird that it insist in doing things when you've turned it off in the preferences
<jamiemcc> sladen: uncheck enable watching and enable Evolution email indexing and restart trackerd - it should behave
<jamiemcc> arador: its a known bug which im fixing
<sladen> bhale: well yes, you /can turn it off in the preferences/.  However, that wouldn't have any effect on the trackerd still running in the background, until you logout/reboot
<bhale> sladen: well. ive seen it start up anyway
<sladen> bhale: *and*, whenever trackerd gets reinstalled/upgraded ... it resets itself to enabled.
<bhale> oh REALLY
<bhale> brilliant.
<bhale> mine was certainly unchecked when i found it beating my disk to a pulp, though
<bhale> on battery power, too
<bhale> seems like a backwards default to me
<sladen> stabby, stabby, stabby, kill, kill, kill
<Arador> in my box trackerd manages to halt applications for many seconds, but it looks more like a bad kernel behaviour than a trackerd bug
<mjg59> Trackerd was, until recently, demonstrably broken - you can't call lseek() 100 times a second and expect throughput to be high
<jamiemcc> mjg59: unless its cached
<jamiemcc> by kernel
<mjg59> jamiemcc: Which you can't guarantee at all
<sladen> type  C-x C-s  in emacs and watch it hang
<jamiemcc> mjg59: true
<mjg59> Especially if you're making tiny writes over a very large area
<jamiemcc> but it should not cause very high iowait
<wasabi> Should not having debsums be something people should FIX? :)
<sladen> the I/O is not on the files isn't supposed to be indexing, but on  seek(), read(), seek(), write()  (mmap'ed?) on its data-base files
<mjg59> Knowing how much of an issue it still is in 0.6.2 would be much more helpful
<jamiemcc> mjg59: the way the indexer works has not changed for a long time
<jamiemcc> only recently did we add sqlite but the mechanics are the same
<jamiemcc> an index is word -> array of hits
<jamiemcc> when array grows we have to reaalocate pages
<jamiemcc> adding a hit means doing a read/write op
<sladen> jamiemcc: can't that be done *in memory* and serialised to disk once an hour?
<jamiemcc> sladen: we cache in memory yes
<sladen> jamiemcc: rather than holding the working-set on disk
<mjg59> jamiemcc: As I said, if you're calling lseek() and writing a tiny amount of data repeatdly, there's no way you're going to get any sensible throughput
<jamiemcc> next version will do index merging which means creating a small tmp index
<jamiemcc> mjg59: we did that in feisty very fast
<mjg59> jamiemcc: At some point those writes need to hit disk. If you're spreading them out far enough, you can't collate them.
<jamiemcc> 0.5.4 does that
<mjg59> It's simply impossible
<sladen> a 50MB write costs the same as a 5 byte one
<jamiemcc> with elevator in the kernel it should reorder the writes into an optimal order
<sladen> tiny is not the problem, it's the quantity
<jamiemcc> fsync is off by the way
<mjg59> jamiemcc: Again, that assumes that the writes are close enough that they /can/ be reordered into an optimal order
<sladen> trackerd needs to *not do those writes* in the first place
<jamiemcc> well basically we cache up wroites and use padding to reduce reallocation
<sladen> trackerd needs to do *one* 50MB write each time it has fully filled a database
<mjg59> jamiemcc: Once the index file has reached a GB or so, that's simply not going to happen.
<jamiemcc> mjc59: agree
<jamiemcc> thats why I say its scalable up to 1gb
<jamiemcc> 1gb index == 10GB text
<mjg59> And as a result, your maximum throughput is going to be around 25K/sec
<mjg59> jamiemcc: Ok. Is it going to be scalable beyond that within a month?
<jamiemcc> yes with index merging
<jamiemcc> we will merge at 64mb intervals
<mjg59> That sounds good
<jamiemcc> so a tmp index is created and then merged with the buig one
<jamiemcc> big
<sladen> jamiemcc: okay, does that means you'll only touch the disk for the index files once every 64MB ?
<jamiemcc> no we create a small index which the kernel can cache
<jamiemcc> 64mb is small and should never be slow to read or write
<sladen> and this "small index" is still being accessed with  seek(), read(), seek(), write ...
<jamiemcc> yes but those seeks are on cached pages in ram
<sladen> bad assumption
<jamiemcc> kernel uses spare memeory to cache disk pages
<sladen> *IF THERE IS ANY SPARE MEMORY*
<jamiemcc> you will need 64mb spare yes
<jamiemcc> we can make the merge index smaller if you like
<jamiemcc> 32mb?
<Arador> just curiosity: does trackerd uses fadvise()/madvise() to tell the kernel that it's not going to need to read data again? (since I suppose it should be the standard behaviour in a indexer, shouldn't it?)
<jamiemcc> arador: just committed that the other day
<sladen> 256MB, OpenOffice running, trackerd raping the disk in the background, i/o => swap => thrash
<jamiemcc> ubuntu 7.10 has 512mb min memory
<jamiemcc> in the specs
<mjg59> Still fairly easy to push into swap with that much, sadly
<sladen> I guess the thing is to do the index-merging operations when there is RAM to do so
<jamiemcc> alternative is to cache in memory?
<mjg59> Explicitly operating on in-memory data structures and then pushing them out as a single linear write might make more sense
<jamiemcc> mjg59: only an issue during initial index though
<mjg59> jamiemcc: Yeah, but right now that can take about two days :)
<jamiemcc> well we have an in memory cache but its only 2mb
<sladen> if you alloc(64MB) and are not doing anything (because people are trying to use their machine for work), you should get paged out == but that's fine
<Arador> jamiemcc: nice, because it looked like it was the problem I was hitting - trackerd would cause the kernel to cache all the stuff it was indexing, so the kernel would "uncache" the applications I'm using to make room :/
<jamiemcc> mjg59: on debian unstable 800mb database took 3 hours to index
<sladen> it's taking 2 hours to produce a 50MB database here
<jamiemcc> sladen: kernel bug
<jamiemcc> vmstat 1 and check wait states
<jamiemcc> my 400mb database took a lilttle over an hour
<sladen> jamiemcc: kernel bug ... but  killall -9 trackerd  seems to solve it
<mjg59> jamiemcc: When I was monitoring it, it was entirely seek bound (and each of those seeks was hitting disk)
<jamiemcc> sladen: when I did a fresh install of tribe 4 kernel bug went away
<sladen> jamiemcc: fresh install == empty disk == nothing to index == nothing to do!
<mjg59> jamiemcc: There's no way that an updated system will differ from a clean install in terms of kernel
<jamiemcc> tribe 3 has the bug and it persists
<jamiemcc> some setting somewhere?
<mjg59> No
<mjg59> The problem must be elsewhere
<jamiemcc> I will add tribe 3 again tonoight and confirm
<jamiemcc> 2 people have confirmed that fresh install solved the issues
<sladen> jamiemcc: it will.
<sladen> jamiemcc: empty disk
<jamiemcc> with identical home directory
<Hobbsee> sigh.  i would have had time to do the build too.  night all.
<jamiemcc> well 0.5.4 on feisty never produced a single claim of slowdown and iondexer works same way
<jamiemcc> excessive seeks might slow indexing but not the system
<sladen> hard-disk => 10msec seek => maximum 100 seeks/seconds
<jamiemcc> sladen on uncached yes but stuff close together on disk is usually < 1ms
<jamiemcc> 10ms is avaergae across whole disk
<mjg59> jamiemcc: Rotational latency still gets you
<sladen> jamiemcc: the use case to optimise is not running trackerd on an unused system
<jamiemcc> sladen: you have 50mb db and have more than 50mb free memory then kernel wll cache it 100% so you should never have a slow down
<mjg59> Especially on laptops, where you're looking at 70rps
<sladen> jamiemcc: it's to optimise the case of *other people wanting to use the CPU for real work*
<jamiemcc> sladen its niced +19 and disk io best effort 7
<jamiemcc> same as on feisty with 0,5,4
<mjg59> sladen: Calm, please
<sladen> jamiemcc: yup, so those writes are likely to end up >1msec apart (other things attempting to get scheduled)
<jamiemcc> well fsync delays it so they are bucnhed up together
<jamiemcc> levator write in the kernel should optimise it
<mjg59> jamiemcc: Switching to using it by default is likely to have resulted in it being exposed to a much wider range of users
<jamiemcc> mjc59: it affected me in tribe 3
<jamiemcc> I had to do celan install of tribe 4 to get it to go away
<jamiemcc> same set of files took ages to index and slowed desktop massively
<mjg59> I'm immensely reluctant o conclude that it's a kernel bug, because (a) nobody in the wider Linux community has started complaining that their database has slowed down, and (b) whether this behaviour is evident or not is unrelated to the kernel you're running
<jamiemcc> only gutsy kernel is affected
<jamiemcc> debian is not
<mjg59> jamiemcc: If it's fine in a clean install and not in an upgraded one, it's not a kernel bug.
<jamiemcc> even without tracker running people complain on gutsy that disk io is harming desktop
<jamiemcc> mjc59: could it be some other  process then?
<mjg59> That would seem rather more likely, but it's still not clear why it would be different on an upgraded system
<jamiemcc> initial config might be different for a rocess
<jamiemcc> it might use an old config
<mjg59> Desktop applications will be getting stuff from gconf, so will get the new defaults. System ones will be in /etc, where they'll be overwritten unless the admin manually changed them
<jamiemcc> mjg59: could pdflush or something have an effect?
<mjg59> jamiemcc: That's a kernel thread
<jamiemcc> yes but its responisble for flushing the disk
<mjg59> Yes, but it has no configuration
<jamiemcc> I thought you could set dirty page buffers
<jamiemcc> and how often to flush
<mjg59> So clearly yes, it could have an influence - but that doesn't explain the difference between upgrades and reinstalls
<mjg59> jamiemcc: You can, but we don't ship any configuration
<siretart> asac: hmm. it seems that with wpasupplicant 0.5.8, I get a lot fewer TIMEOUTs than with 0.6.0.
<mdomsch> packaging question
<mdomsch> is there a way to install a file into /etc/* without it automatically being considered a conf file?
<Mithrandir> all files in /etc are configuration files, but not all of them are conffiles
<Mithrandir> you can create non-conffile configuration files by creating them in the postinst.
<mdomsch> that's what I was afraid of
<mdomsch> honestly, it's not a configuration file nor a conffile, but it has to go in /etc/kernel/{prerm,postinst}.d/ because that's where linux-image expects it to go
<Mithrandir> why do you claim it's not a configuration file?
<mdomsch> it's a script called by linux-image.postinst to invoke another package (in my case, DKMS)
<mdomsch> e.g. like a trigger
<Mithrandir> yes, and in what way is that not a configuration file?  /etc/dhcp3/dhclient-script is a script invoked as part of the DHCP sequence, this sounds very much the same
<Mithrandir> Seveas: any chance we could get ubotu in #ubuntu-kernel?
<mdomsch> indeed, very similar
<mdomsch> ok, great, then it is and I'll let it be treated as such
<Seveas> @join #ubuntu-kernel
<mdomsch> thanks
<mdomsch> if doing apt-get install linux-image-2.6.20-15-generic linux-headers-2.6.20-15-generic
<mdomsch> is there a way to guarantee the ordering that the postinst scripts of those get run?
<mdomsch> in my limited tests, it seems linux-image.postinst gets run after linux-headers.postinst
<mdomsch> but is that actually deterministic?
<kdean06> I've got a question pertaining to a license found in an Ubuntu package. I e-mailed the maintainer about two weeks ago, and haven't gotten a responce. The package is copywritten by Canonical, so is there an "upstream" contact for this?
<mc44> kdean06: which package?
<kdean06> ubuntu-calendar-*
<tonyy> kdean06: what's the question?  maybe there's a chance someone here will know.
<kdean06> tonyy, My question is specifically if the package allows redistribution, and if so under what terms.
<kdean06> There's no license on that package at all, only copywrite notice.
<tonyy> kdean06: You've checked the source package?
<kdean06> Yes, it's got no license... The contents of the package are graphics, not code, or at least, not licensed code.
<tonyy> It should still have full licensing info in debian/copyright though...
<kdean06> The changelog file contains not license reference, and the copyright only gives "Copyright 2004 Canonical Ltd." and the upstream author.
<Keybuk> kdean06: what is the package?
<kdean06> The link, from packages, which is identical to the debian/copyright file, is http://changelogs.ubuntu.com/changelogs/pool/main/u/ubuntu-calendar/ubuntu-calendar_5.03-2/ubuntu-calendar.copyright
<tonyy> kdean06: you're quite right
<kdean06> Keybuk, ubuntu-calendar*
<Keybuk> ubuntu-calendar is probably not redistributable
<tonyy> kdean06: jdub is the maintainer, and currently on IRC, but likely away
<Keybuk> Mithrandir: around?
<Keybuk> tonyy: jdub isn't at Canonical anymore
<tonyy> Keybuk: Ah...I think I knew that.  Still listed as the maintainer though ;)
<tonyy> (feisty pkg)
<Keybuk> those packages haven't been touched in *years* :p
<tonyy> I noticed it had 'warty-updates' in it...
<kdean06> That might explain why he hadn't responded to my inquiries. :)
<lamont> ogra: where do the ltsp folks hang out?
<ogra> #ltsp
<ogra> but if you have a question sbalneav and me are here :)
<ogra> we are essentially the ltsp dev team ;)
<lamont> trying to get ltsp happy on gutsy...
<Mithrandir> Keybuk: on the phone
<lamont>         lpadmin (104)
<lamont> Info: updating inetd config
<lamont> that's where ltsp-build-client hangs
<lamont> with update-inetd running and blocked on something - I wonder if it's the lack of /proc et al in the chroot
<lamont> ogra: or is gutsy ltsp scary atm?
<ogra> lamont, no, it should be fine
<lamont> ogra: got a convenient howto?
<ogra> but i fixed some bugs in the update-inetd code ...
<lamont> and wth does it use /opt instead of /srv?
<ogra> https://help.ubuntu.com/community/UbuntuLTSP/QuickInstall
<ogra> nostalgic reasons :)
<ogra> i think we'll switch soon, i get that question more and more often recently :)
<lamont> uh... pg does not exist
<sbalneav> lamont: At the time ltsp started up, /srv wasn't there yet :)
<lamont> sbalneav: yeah
<lamont> UbuntuLTSP/LTSPQuickInstall
<ogra> lamont, weird, i'm using it since 1.5 years ...
<lamont> and,uh, yeah.  I'm at the "sudo ltsp-build-client" step, and it's hung
<ogra> more likely in the ltsp-update-image step (which is run by ltsp-build-client)
<sbalneav> Man, if ltsp moves to /srv, I'm gonna have 8 years of muscle memory to undo.  cd / o tab l tab :)
<lamont> root      3496  0.0  0.0   3968  1532 pts/1    S+   11:30   0:01          |   \_ /bin/bash /usr/sbin/ltsp-build-client --mirror http://archive.mmjgroup.com/ubuntu --security-mirror http://archive.mmjgroup.com gutsy-security main universe restricted multiverse
<lamont> root     24364  0.0  0.0   3844  1356 pts/1    S+   11:37   0:00          |       \_ /bin/sh /usr/sbin/ltsp-update-image -a i386
<lamont> root     24403  0.0  0.4  12808  9700 pts/1    S+   11:39   0:00          |           \_ /usr/bin/perl -w /usr/share/debconf/frontend /usr/sbin/update-inetd --group LTSP --add 2000               stream  tc
<lamont> debconf seems to be very unhappy with ltsp-update-image
<ogra> hmm
<ogra> it uses passthrough
<lamont> and it's 13:27 here, so I I think that means it's hung...
<ogra> yeah
<ogra> likely my recent changes, sorry
<lamont> and nothing in /proc about it
<lamont> and oh btw, you'll notice that --security-mirror seems to append /ubuntu automagically to the name
<ogra> even though i built an image today that worked, weird+
<lamont> which will break ports, if nothing else...
<ogra> can you bug that ?
<lamont> ogra: yeah
<ogra> thanks :)
<lamont> and at some point, it'd be nice if it used ipv6's built in ipsec instead of ssh-ing everywhere...
* lamont tries a dist-upgrade, just for giggles
<okaratas> hello
<ogra> erll, we somewhat rely on the ssh ability to offer siocekts for established tunnels ... not sure thats easily replaceable by ipsec
<ogra> *sockets
<lamont> right
<wasabi> Sillyness.
<wasabi> Compiz crashes my X server on my plain ol' new NVidia card.
<lamont> I just meant for the getting-back-to-the-server default stuff
* ogra tries an ltsp-update-image to reproduce ...
<wasabi> Sounds like it should be enabled by default to me!
<lamont> wasabi: compiz doesn't do anything on my computer... but then, I don't install it.
<lamont> hrm... actually, it is installed.
<lamont> but fglrx isn't, since I like to have working suspend
<Keybuk> wasabi: file a useful bug report instead of whining
<lamont> Keybuk: party pooper. :-)
<ogra> wasabi, else Keybuk will take out the ability to disable compiz :P
<wasabi> oh noes. =/
<ogra> hmm, finishes fine here, weird
<ogra> grmbl
<ogra> i should probably use up to date software ...
<okaratas> ls
<okaratas> clear
<okaratas> hm sorry, please...
<ogra> no, we'll never forgive
<ogra> :)
<ogra> lamont, i think i know what broke ... ltsp-update-image tries to write to $CHROOT/etc/ltsp which doesnt exist
<ogra> lamont, sudo mkdir /opt/ltsp/i386/etc/ltsp && sudo ltsp-update-image
* lamont complies
<lamont> how much does server speed affect the client machine's performance?
<ogra> not at all ... the client runs as standalone diskless system ... the question is how much does server speed affect the users sessions ;)
<ogra> since after login 98% of your stuff run on the server
<lamont> why would it run on the server/
<ogra> the client is only an input/output device
<lamont> client is basically a remote display with stuff?
<lamont> riht
<ogra> yeah
<lamont> hrm... I hope my family doesn't mind when I dump all 3 of them on a PIII/933.
<ogra> its boots to a login manager, which then basically does ssh -X user@server /etc/X11/Xsession
<lamont> 2-way, so it's not quite _that_ bad
<lamont> that directory fixed the update-image
<ogra> yay
<lamont> docs on how to update things, etc?
* ogra fixes in his branch
<lamont> and what use is made of the image?
<ogra> https://help.ubuntu.com/community/UbuntuLTSP/LTSPWithoutNFS
<lamont> and should I worry that i386.img is 129MB
<lamont> ?
<ogra> not many docs yet
<lamont> tahnks
<ogra> no. thats perfect
<ogra> (the chroot is over 300MB :) thats a pretty good compression rate )
<dobey> does the xgl package in gutsy enable itself as an alternate session that you can choose through gdm?
<ogra> i'd like to get rid of the chroot at some point to save diskspace, but for gutsy we want to give users an easy ability to switch to fs if they want
<ogra> s/fs/nfs/
<lamont> ogra: so clients are chrooted into that chroot, and anything they need should be installed in that chroot, and run ltsp-update-iameg
<lamont> eys?
<tonyy> dobey: gutsy doesn't use xgl I'm sure
<lamont> yes, even?
<ogra> yeah
<moquist> ogra: LTSPWithoutNFS is a good read.
<moquist> (thx)
<dobey> tonyy: not by default, but the package is installable, and enables itself when you install it
<ogra> if you want extra stuff on the client, thats the way to do it ... but usually the default image in combination with lts.conf should do
<ogra> moquist, thanks :)
<ogra> lamont, its a bit manual work still, i hope to have http://people.ubuntu.com/~ogra/LTSPManager/ ready for hardy that will do everything in a nicer way :)
<lamont> ogra: it would be nice if ltsp-manager had an instance that didn't drag in dhcp-server...
<mathiaz> keescook: I've updated the apparmor package.
<lamont> since the machine where I have the roots is _NOT_ the dhcp server for the network.
<ogra> lamont, yeah, i'll take that into account ... the initial thing was designed for a standalone server
<mathiaz> keescook: I've published a new version in my branch, which has an updated avahi-daemon profile.
<ogra> plan is to have it being an enterprise tool at some point to manage all your ltsp servers in a network
<lamont> ogra: having it Recommend the dhcp server and depend standalone| $theotherone would be nice
<ogra> but its still in pre alpha ... i'm simply missing the time
<lamont> of course, if it's not standalone, then you have to tell me to copy the dhcp snippet over...
<lamont> yeah - I'll wind up removing ltsp-manager for now
<ogra> or have remote clients on every server somehow ...
<ogra> yeah, its more a mockup than an ap atm
<lamont> well... my config is one server, dhcp is "over there" though on a different box
<ogra> i'll add a popup warning and a note to the package description before release
<lamont> of course, the 121 packages it dragged in were a bit amusing
<ogra> heh, yes supporting a lot of stuff costs a lot
<ogra> oh, you mean ltsp-manager ?
<ogra> eek
<lamont> after removing ltsp-manager and ltsp-server-standalone, apt-get autoremove removed 121 packages
<lamont> you want the list?
<lamont> (the machine is basically ubuntu-{minimal,server}
<lamont> er, s/server/standard/
<ogra> oh, you'll need -desktop
<Mithrandir> Keybuk: I'm around for about five minutes more now.
<ogra> unless you want to run the desktop elsewhere ... then it gets intresting :)
<lamont> ogra: won't I need desktop in the chroot, rather than the real root?
<ogra> yeah
<ogra> in the real root was what i meant
<lamont> ??
<ogra> <lamont> (the machine is basically ubuntu-{minimal,server}
<ogra> the machine needs -desktop
<lamont> s/machine/machine's real root/
<ogra> yeah
<lamont> the client chroot is whatever ltsp-build-client built
<ogra> right
<lamont> sufficient? or does the real root need -desktop?
<ogra> the real system needs a desktop where you can log in to from the client
<lamont> client logs in (with ssh) and runs what?
<ogra> as i said, the login manager does basically: ssh -X user@server /etc/X11/Xsession
<ogra> in gutsy we added the option to set DISPLAY pointing to the client, so you can circumvent encryption for X but keep secure passwords if you find encryption to slow
<ogra> lamont, btw, sbalneav works on the edubuntu-docs package that should have more detailed docs, its in his PPA
<ogra> we have the most recent ltsp docs in there
<sbalneav> lamont: You just trying out ltsp?  Or this for work?
<lamont> sbalneav: family
<sbalneav> Cool
<wasabi> Hmm. I suspect this new kernel has hosed my vmware too
<wasabi> blah
<ogra> sbalneav, eeek BASE=${BASE:-"/opt/ltsp/"} .... IMGDIR="${BASE}/images" ... CHROOT="${BASE}/${ARCH}"
<ogra> double dahes everywhere
<ogra> *dashes
<sbalneav> yeah, I fixed that
<ogra> you didnt commit, did you ?
<sbalneav> don't know where that last dash came it
<ogra> or push
<sbalneav> I did indeed. At least I think so...
<lamont> ogra: those are called slashes. :)
<ogra> heh, right
<sbalneav> lemme check
<ogra> i should stop for the day, 12h are enough
* lamont quits poking
<sbalneav> Whoops
<sbalneav> no I didn't
<sbalneav> Hold fix now...
<ogra> sbalneav, bad thing is that everyone using the 5.0.28 and 29 packages has the image entry with double slash in inetd.conf now :/
<sbalneav> How did we get that in there?
<ogra> it uses ${IMAGE}
<ogra> for update-inetd
<ogra> and it uses ${IMAGE} to check if the image is already there
<ogra> next check will be without doubleslash now ... so it wont find it and add an entry *sigh*
<ogra> its just a wasted extra entry, but still ugly
<sbalneav> Well, chances are not a huge number of people are affected.
<ogra> well ... my friend <joebob777as7> will be ...
<sbalneav> ok, pushed
* ogra had his head exploding from ltsp/compiz questions today
<ogra> merged, pushed, packaged, uploaded ... :)
* ogra calls it a day
<ogra> but before ....
* ogra hugs moquist for well done moodle packaging work 
<desrt> moodle rocks my world!
<ogra> night all
<desrt> ta :)
* desrt hugs moquist too
<Mithrandir> yo, desrt
<desrt> hello.
<Mithrandir> how's you, yourself, .ca and Annika (sorry about the spelling if that's wrong)
<desrt> i am fine.  my country is starting to cool off and anneka is in ottawa
<desrt> did i send you the picture near the beach?
<Mithrandir> I don't think you, did, no.
<wasabi> wonder if the new nvidia driver is causing all these segfaults. =/
<wasabi> wonder if nv even supports my card in 2d
<Kopfgeldjaeger> cu
<tepsipakki> wasabi: if X starts, the driver supports your card
<wasabi> heh.
<tepsipakki> oh you meant to switch nvidia -> nv?
<wasabi> yeah
<tepsipakki> I'd be surprised if it didn't support what's in the blob
<tepsipakki> since nvidia maintains both
<wasabi> What's in the blob?
<wasabi> Oh.
<tepsipakki> er, supported by the blob
<lucky_lucas> Is the ati driver blacklisted until the release ? Or may we have it back in a while ?
<torkel> lucky_lucas: I think they changed it in the latest release not to blacklist all ati cards, but instead doing it by using pci id's
<lucky_lucas> ok, it's safer like this, because I had systematic crash when running compiz
<lucky_lucas> And I have read that compiz will be enabled by default so it was somehow critical
<asac> siretart: i saw that too ... the interesting thing is that i sometimes still get garbage replies with 0.6.0 while i don't get that with 0.5.8
<asac> siretart: i don't say that this is a bad thing ... i only say that there appears to be a case where wpasupp really returns garbage ...
<stdin> hmm, apparmor doesn't seem to want to release, it was published nearly 24 hours ago but it's not in the archive yet
<mathiaz> stdin: yes. There are some dependcy problems.
<mathiaz> stdin: it still depends on some packages that are in universe. It has been fixed in the bzr tree.
<stdin> ahh, ok
<keescook> mathiaz: okay, great
<keescook> mathiaz: though something odd is going on -- apparmor should be published (https://launchpad.net/ubuntu/+source/apparmor/2.1+961-0ubuntu2) but is not showing up in the archive.
<mathiaz> keescook: may be an archive-admin should have a look at it ?
<keescook> mathiaz: yeah, asking now...
<geser> keescook: apparmor is in bin-NEW because of libapparmor1-dev
<keescook> geser: aaaah, thanks.  where'd you see that?
<geser> https://edge.launchpad.net/ubuntu/gutsy/+queue
<keescook> I wish that was linked from the packages.  ;)
<geser> and when you expand one of the apparmor entries you can see a NEW before the -dev package
<geser> keescook: start at https://edge.launchpad.net/ubuntu/ -> Series: gutsy -> Actions: Show uploads
<ajmitch> at least binary NEW packages tend to be processed quite fast, if there's an archive admin awake
#ubuntu-devel 2007-09-14
<keescook> geser: cool
<keescook> ajmitch: true, true.
<gnomefreak> ajmitch: some, im waiting on a few to be released but they havent been pushed from new yet about a week or so
<ajmitch> gnomefreak: binary NEW?
<gnomefreak> https://edge.launchpad.net/ubuntu/gutsy/+queue
<gnomefreak> think that is source or both as i have seen binaries in there
<geser> gnomefreak: it's very selective right now
<Fujitsu> gnomefreak: Both.
<geser> open sync request aren't also processed for over a week now (my oldest one is one week old)
<pochu> pitti will process them tomorrow
<geser> good to hear
<gnomefreak> them being released isnt such a big deal since i can build and install but just commenting from above ;)
<gnomefreak> hm
<gnomefreak> i thought 1 failure to build on an arch stopped all binaries from release
<ajmitch> then we'd never get anything done :)
<gnomefreak> i see amd64 not built yet or failed and 386 .debs are in repos
<geser> or less archs
<gnomefreak> ajmitch: good point
<geser> gnomefreak: you don't need to rebuild packages in bin-NEW on your own, looks like you can fetch the deb manually from the queue
<gnomefreak> i dont see .debs for it
<gnomefreak> how do i tell if its ftb or not?
<gnomefreak> without loooking through all 3300 ftbs
<gnomefreak> nvm
<gnomefreak> found it
<geser> gnomefreak: goto https://edge.launchpad.net/ubuntu/gutsy/+queue, expand the one you want and you will find links to the debs
<gnomefreak> geser: nope it hasnt been pushed to farm yet
<geser> gnomefreak: which package are you interested in?
<gnomefreak> amarok2
<gnomefreak> i found koffice2 in repos for 386
<geser> ah, it's in source-NEW
<gnomefreak> yes thats the only NEW i know of
<geser> so it didn't reach the buildds yet
<gnomefreak> looks like it
<geser> each packages does through the NEW queue twice: one time for the source package and one time for new debs
<gnomefreak> ah but same link for both? just the white mark on them means bins are there
<gnomefreak> them=icons
<geser> yes, that page lists both types
<geser> when you hover other the icon you get an tooltip saying which type it is
<gnomefreak> ah cool ty
* Keybuk smiles at Mirco's blog
<Keybuk> gotta love geeks
<Keybuk> their first instinct when seeing a fire in their house is to take a picture of it, then put it on their blog
<Keybuk> rather than putting it out
<ion_> :-D
<geser> :)
<geser> no livestream?
<keescook> hmpf, still get blank fullscreen when using 3d on nvidia with compiz.  and suddenly no decorator again.  :P
<wasabi> weee kernel oops
<wasabi> this new kernel is kicking my ass
<gnomefreak> wasabi: -11?
<wasabi> Yeah
<wasabi> Oh, looks like it's VMware's fault anyways.
<wasabi> Or, at least, it's RELATED to vmware.
<gnomefreak> gdm is broken there is no menu items xubuntu login screen is fine but default gdm is broken as well as ones i installed
<kagou> Good morning
<desrt> NO!
<desrt> coNP is an awesome nick
* asisak is sorry.
<asisak> Hey desrt BTW :)
<desrt> i guess one of your branches rejected :(
<desrt> hell o:)
<desrt> it is time for bed.  bye bye
<pitti> Good morning
<kagou> hello pitti
<StevenK> Morning pitti
<StevenK> pitti: libboost*1.34.0 can be NBS'd out at your leisure
<pitti> yay!
<ScottK> pitti: In the interests of removing view-cvs (which is now obsolete), I'd appreciate it if you would have a look at Bug 139283 and the resulting binaries after it builds (view-vc has been FTBFS from us since we got it in the spring).  Once it's published, I'll have the bug to remove view-cvs to you.
<ubotu> Launchpad bug 139283 in viewvc "Please sync viewvc (universe) from Debian unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/139283
<pitti> does any KDEish person feel like rebuilding okular against new poppler?
<StevenK> I tried, it breaks
<pitti> doko_: ecj-bootstrap{,-gcj} is NBS, but kaffe builds against it; what is the replacement?
<pitti> doko_: oh, and eclipse-gcj, too
<pitti> StevenK: I guess you already looked at 'sear'? this is the single package that holds back three NBS packages
<pitti> StevenK: oh, okular doesn't work with the new poppler API?
<StevenK> pitti: No, okular just doesn't build at all
<StevenK> pitti: I'm waiting for Riddell
<pitti> StevenK: Riddell is on vac, btw
<StevenK> I know that
<StevenK> pitti: sear is being dealt with by man-di, he's the Debian maintainer
<pitti> StevenK: sorry, sync-source.py got broken
<MacSlow> Greetings everybody!
<pitti> StevenK: feel free to use http://people.ubuntu.com/~pitti/scripts/syncpackage to sync viewvc for now
<pitti> hey MacSlow! got powah again?
<superm1> hey pitti today (friday) is your queue clearing day right?, mind if i bug/remind you again about looking over those two sru bugs? :)
<pitti> superm1: which ones?
<abooker> If one wished to produce a script that resized the rootfs, is there a particular place one could check out a few distro specifics?
<superm1> pitti, bug 134726 bug 134801
<ubotu> Launchpad bug 134726 in mythtv "MythTV 0.20.2 SRU " [High,Fix committed]  https://launchpad.net/bugs/134726
<ubotu> Launchpad bug 134801 in mythplugins "Mythplugins 0.20.2 SRU " [High,In progress]  https://launchpad.net/bugs/134801
<ScottK> pitti: Looking.
<pitti> superm1: I don't normally look for universe SRU bugs, only when someone actually uploads something to the queue
<superm1> pitti, they're both already in proposed, its at the point when they need to be copied to -updates
<pitti> superm1: ah, of course I do look for verification-done tags
<pitti> superm1: yep, will do that
<superm1> thanks
<StevenK> pitti: Sync viewvc why?
<ScottK> StevenK: I think he meant me.
<MacSlow> pitti, for the moment yes... and I hope it will stay that way... but then... that's what I thought yesterday morning too... well and yesterday went not that smooth power-wise.
<StevenK> Ah ha
<pitti> ScottK: I did, sorry
<ScottK> No problem.  I'm used to it.
<pitti> superm1: I won't copy them to -updates until gutsy is fixed, BTW
<superm1> pitti, what do you mean?
<pitti> superm1: the gutsy tasks of those bugs are still open
<superm1> what's wrong with gutsy?
<StevenK> pitti: Ah, more things about okular - it's now in kde4graphics, so the okular source package can probably just die, but like I say, I want to talk to Riddell about it
<superm1> oh then i labeled the tasks wrong
<superm1> they're both resolved in gutsy already
<superm1> the version in gutsy is 0.20.2
<pitti> superm1: if those are fixed in gutsy, then please set them to fixreleased
<superm1> i'll fix those tasks then
<pitti> superm1: ah, I see; thank you!
<superm1> pitti, there we go, those should be marked right.  it didn't occur to me that the task without a distro label meant gutsy.
<pitti> superm1: well, it means 'current development release'
<superm1> right
<abooker> Hmm OK, I'll take that as a piss off you script writing kiddie.  I apologise for taking up your time.
<StevenK> pitti: I can fix eclipse, if you wish
<pitti> StevenK: oh, you know what the replacement is?
<StevenK> pitti: Yup, I've done a few
<pitti> abooker?
<pitti> WTH?
<StevenK> pitti: ikvm can be fixed, but requires a UVFe.
<StevenK> pitti: kaffe is then the only one left, and I don't think it builds
<StevenK> kaffe also hasn't been updated since bofore Etch released
<StevenK> before, even
<ScottK> pitti: I'm having trouble with your syncpackage script.  I have the package locally here.  Would it be a problem if I just dput it?
<pitti> ScottK: oh, trouble?
<ScottK> Yes.  I'll get you the error.
<pitti> ScottK: if you mangled the source.changes for s/unstable/gutsy/, then it should work
<ScottK> Ah.  OK.  Let me try than then.
<pitti> ScottK: and Origin: debian/unstable
<StevenK> How did sync-source.py break?
<pitti> psycopg.ProgrammingError: ERROR:  column "published" does not exist at character 397
* pitti looks clueless
* StevenK sighs at the band next door, along with their canine accompiment
<ScottK> pitti: Is there a preferred mangling method (first time I've had to do it)?
<pitti> ScottK: what's wrong with the script?
<StevenK> (Next door's two dogs don't like the band practising, so bark a lot - my dog doesn't seem to mind, which is interesting)
<StevenK> % diff -urNP ikvm-0.28.0.0 ikvm-0.34.0.2 | diffstat | tail -n 1
<StevenK>  181 files changed, 265313 insertions(+), 209945 deletions(-)
<mdke> dogs have different tastes in music I guess
<StevenK> Oh, *wonderful*
<ScottK2> pitti: http://pastebin.ubuntu-nl.org/37392/
<StevenK> ScottK: No point even asking, based on that diffstat, right? :-)
<pitti> ScottK2: how did you call this?
<ScottK2> It looks like it gets the two files and then keeps going and dies on Python-Version: current
<ScottK2> Getting
<pitti> ooh
<pitti> ScottK: right, it probably assumes that Files: comes last in the .dsc
<ScottK2> python ../syncpackage http://ftp.de.debian.org/debian/pool/main/v/viewvc/viewvc_1.0.3-2.1.dsc gutsy
<pitti> ScottK: which was true those two years ago when I wrote it
<ScottK2> Of course
<StevenK> pitti: You could use the DSCParser in Linda ...
<pygi> doko_, poke? ?^_^
<viviersf> Mithrandir, ping
<ScottK2> pitti: Is it looking to find anything other than orig.tar.gz and diff.gz?
<Mithrandir> viviersf: iz contentless ping.
<pitti> ScottK2: no (except for native packages, etc)
<pitti> ScottK2: it should probably just call dget nowadays
* ScottK2 looks at the script some more...
<StevenK> pitti: Agreed, calling dget is much less work. :-)
<StevenK> pitti: I'm half tempted to not test build eclipse ... Which makes me feel naughty.
<viviersf> Mithrandir, quick question, is there anything different building custom gutsy images than in feisty ?
<dholbach> good morning
<Mithrandir> viviersf: custom ISOs?  No, the procedure is the same as it's been since dapper.
<StevenK> pitti: -3ubuntu2 built fine, and it looks like it will take 2 hours to test build, and all I did was change the Depends line in debian/control.
<pitti> StevenK: sounds fine to throw at the buildds...
<viviersf> Mithrandir, ya like custom distros. okay weird cos my scripts dont work in gutsy anymore. prolly like a kernel change or something :(
<pitti> StevenK: even if it FTBFSes, it's not the end of the world
<StevenK> pitti: Agreed. I don't think it will.
<StevenK> pitti: Uploaded.
<StevenK> ScottK: Ping, did you see the diffstat for ikvm?
<ScottK> pitti: And then I dput it after I run the script, right?
<pitti> StevenK: so what did you change the depends to, i. e. what replaces ecj-bootstrap?
<ScottK> StevenK: I haven't looked.
<StevenK> ecj-boostrap-gcj -> ecj-gcj
<pitti> ScottK: yep
<pitti> StevenK: aah
<ScottK> or I forget.  It's lat here.
<StevenK> ScottK: I can repaste
<Mithrandir> viviersf: oh, unionfs is busted at the moment.
<viviersf> Mithrandir, ah damn! okay that would explain it. Thanks man :)
<ScottK> pitti: Bug #139283 is done, so you can usubscribe the archive if you care about such things.
<ubotu> Launchpad bug 139283 in viewvc "Please sync viewvc (universe) from Debian unstable (main)" [Undecided,Fix released]  https://launchpad.net/bugs/139283
<StevenK> pitti: If you've NBS'd out boost, can you remove the lists?
<pitti> StevenK: I NBSed some more stuff, so I'll just regenerate the lists
<StevenK> pitti: Works for me.
<ScottK> pitti: Also, I've got a stack of sync requests pending.  Is there any problem if I just do them all this way?
<pitti> StevenK: hm, needs another publisher run
<StevenK> pitti: I'll bug you in an hour, then. :-)
<pitti> ScottK: not really, if you triple-check that the changelog is correct (-v like)
<pitti> ScottK: that script more or less just does what sync-source.py is doing
<ScottK> pitti: OK.  Thanks.
<ScottK> I think I'm going to go to bed now, but I'll attend to it tomorrow if sync-source.py doesn't have a magic recovery in the meantime.
<siretart> asac: hm. I see. So I wonder if we really shouldn't go back to 0.5.8 for 7.10
<ScottK> pitti: When you say triple check the changelog is correct, I'd like to know exactly what you want checked for so I don't mess it up...
<ScottK> Then I'm really going to bed.
<pitti> ScottK: that it mentions the right versions, i. e. all changelogs since the last gutsy version
<pitti> ScottK: like what you do with -v for merges
<ScottK> OK.  Got it.  Thanks.
<dholbach> mdke: can we close  https://bugs.launchpad.net/ubuntu/+source/gnome-user-docs/+bug/139064 ?
<ubotu> Launchpad bug 139064 in gnome-user-docs "Please update gnome-user-docs from bzr" [Undecided,In progress] 
<ScottK> pitti: I enjoyed getting the sylpheed-claes removal bugmail.  Thanks.
<ScottK> Good night all.
<pitti> bye ScottK
<Fujitsu> Night ScottK.
<ScottK> claes/claws.
<dholbach> mdke: did you merge from http://bazaar.launchpad.net/~dholbach/gnome-user-docs/fixes ?
<pygi> Keybuk, ping
<Keybuk> pygi: hi
<pitti> superm1: oh, sorry, mythplugins needs a proper upload to -updates
<pygi> Keybuk, would you be so kind to add me to the code.google.com soc project? Thanks
<superm1> pitti, i'm guessing because of the ~proposed1 that was missed?
<pitti> superm1: right; mythtv is ok
<pitti> superm1: is it ok to copy mythtv without mythplugins?
<superm1> yea i thought that might be trouble, wasn't sure if you can correct it before copying
<superm1> pitti, i can upload the mythplugins right now if you'd like
<superm1> so you can do them both at once
<pitti> superm1: no, copying means verbatim copy without any bit of change
<pitti> superm1: that would be good
<superm1> ah i see
<pitti> superm1: what it (more or less) does is to only copy the Packages.gz entry without touching /pool at all
<Keybuk> pygi: err, SoC has ended?
<pitti> superm1: (some more db changes in the background, of course, but that's whatit comes down to for users)
<superm1> ah i wondered how pockets worked.  do i need to upload the orig.gz still too?
<pygi> Keybuk, yes, but I meant add me to this so I could upload code: http://code.google.com/p/google-summer-of-code-2007-ubuntu/
<pitti> superm1: nope
<superm1> okay that will make these quick uploads
<Keybuk> pygi: it does not appear that I can
<Keybuk> pygi: ask doko
<pygi> Keybuk, ok, when he's back
<pygi> oh, he's here :p
<pygi> doko, poke, add me to the project please :)
<superm1> pitti, okay those should be up
<doko> pygi: looking ...
<pitti> superm1: I'll reject the uploads, you uploaded to -proposed
<superm1> pitti, oh i can actually just put them right to -updates then
<dholbach> calc: bug 135086? mjg59: bug 127273?
<superm1> okay whoops :)
<pitti> superm1: yep
<ubotu> Launchpad bug 135086 in unzip "zipgrep: exit code always 0" [Medium,Triaged]  https://launchpad.net/bugs/135086
<ubotu> Launchpad bug 127273 in laptop-mode-tools "laptop-mode init script links not created" [Undecided,Confirmed]  https://launchpad.net/bugs/127273
<superm1> pitti, can i use that same version number, or do i need to bump again?
<pitti> superm1: no, please reuse the number, just fix s/proposed/updates/ in the changelog
<superm1> k
<superm1> pitti, okay should be back up again
<dholbach> calc: oh, also bug 5462
<ubotu> Launchpad bug 5462 in mc "Dutch translation: wrong shortcut" [Medium,Confirmed]  https://launchpad.net/bugs/5462
<pygi> doko, kk
<pitti> superm1: ok, all done; thanks
<superm1> thanks pitti appreciate it
<pitti> siretart: I'm not that happy about accepting cdrtools from source NEW, since it would probably break upgrades
<pitti> siretart: i. e. it would replace cdrkit with cdrecord on upgrades which still have the transitional packages installed
<pitti> siretart: and we don't want to force people to automatically move from main to multiverse packages
<siretart> pitti: what kind of problems do you foresee?
<siretart> query?
<pitti> siretart: see above, automatically upgrading from cdrkit (main/supported) to cdrtools (multiverse, not supported)
<pitti> siretart: and, freeze-wise, this is a new upstream version etc.
<Q-FUNK> https://bugs.launchpad.net/ubuntu/+source/evince/+bug/135832
<ubotu> Launchpad bug 135832 in evince "evince: libgtkprint support is broken" [Low,Incomplete] 
<Q-FUNK> howdy!  would anyone have a clue about this one?
<soren> Where are the fields in the Release file documented?
<saispo> scripts/mod/../../include/linux/input.h:30: erreur: expected specifier-qualifier-list before __s32
<saispo> anyone know i can fix that ?
<siretart> \o/ :)
<\sh> pitti, could you have a look at bug 139376
<ubotu> Launchpad bug 139376 in quagga "[UVF exception]  please update quagga 0.99.9 " [Undecided,New]  https://launchpad.net/bugs/139376
<pitti> \sh: can you please attach the debdiff between current gutsy and your new source?
<\sh> pitti, even it's a new source? sure, no problem :)
* pitti -> quick appointment and lunch break, bbl
<pitti> \sh: yes, it'll be big, but it's convenient for reviewing
<pitti> \sh: thanks
<pitti> \sh: (yes, debdiff works for new sources, too)
<\sh> pitti, give me 5 secs ;)
<mvo> asac: network-manager is in "no network connection" mode again also my interface is manually managed
<\sh> pitti, attached
<asac> mvo: i filed bug 139566 for you now
<mvo> asac: thanks!
<asac> mvo: can you please attach some info .. like: is this always the case?
<ubotu> Launchpad bug 139566 in network-manager "network-manager is in "no network connection" mode even though all interface are manually managed" [Undecided,New]  https://launchpad.net/bugs/139566
<mvo> asac: sure, I'm happy to attach anything you need
<asac> mvo: ok i'll ask in bug
<mvo> asac: it seems to be not always the case, it worked a while. but then I usually suspend/resume my machine and hardly ever boot it.
<mvo> asac: but currently I do have to boot it as fglrx breaks suspsend :(
<asac> now i have to reboot ;)
<Mithrandir> hm, can I tell requestsync to send me a bcc?  I like keeping copies of my outgoing mail.
<Mithrandir> hm, why doesn't malone mark bugs in removed packages as fix released or invalid or something?
<illovae> hello :)
<siretart> pygi: see gutsy-changes: Accepted cdrtools 10:2.01.01a33-0ubuntu1 (source)
<Kmos> Mithrandir: yes, you can.. you need to modify the source :)
<Kmos> or ask pitti to do it in the next version
<\sh> hmmm...
<\sh> Errors were encountered while processing:
<\sh>  /var/cache/apt/archives/vim-common_1%3a7.1-056+2ubuntu1_i386.deb
<\sh>  /var/cache/apt/archives/vim-runtime_1%3a7.1-056+2ubuntu1_all.deb
<\sh> while creating a dapper chroot
<StevenK> What error?
<\sh> dpkg: error processing /var/cache/apt/archives/vim-common_1%3a7.1-056+2ubuntu1_i386.deb (--unpack):
<\sh>  trying to overwrite `/usr/share/vim/vimcurrent', which is also in package vim-runtime
<\sh> hmm...
<\sh> that's strange
<\sh> I just use dapper and dapper-security archive...
<\sh> and this version is not in dapper
<\sh> argll.found it
<\sh> my script is borked setting up pbuilderrcs
<cjwatson> keescook: don't we need to fix bug 139265 now that we have a new version of pam?
<ubotu> Launchpad bug 139265 in samba "localized pam == no samba password changing" [Undecided,New]  https://launchpad.net/bugs/139265
* Mithrandir ruffles dholbach
<Mithrandir> more icons!
<dholbach> yoohoo
<pitti> cjwatson: right, we do; vorlon mentioned it some days ago
<mjg59> mvo_: If compiz locks up rv350, it's likely to affect a lot of other chips in that family. r300 isn't terribly stable in terms of 3D
<pitti> cjwatson: probably with calling passwd with  LC_MESSAGES=C or so
<mvo_> mjg59: right. the only r300 I can get access to easily is a rv350, so I need to watch out for more reports
<geser> doko: do you know what could be the cause for "libgcj failure: gcj linkage error.", "Incorrect library ABI version detected.  Aborting."?
<geser> it's bug #132923
<ubotu> Launchpad bug 132923 in pdftk "pdftk aborts on start" [Undecided,Confirmed]  https://launchpad.net/bugs/132923
<doko> geser: rebuild with a recent gcj
<laga> hi guys. how are the translations for ubiquity handled, if not in launchpad?
<pitti> dholbach: how does compare-packages differ from debdiff?
<dholbach> pitti: it diffs all the binary packages
<cjwatson> laga: they're handled in Launchpad but the translations are only actually merged back by hand; I'm in the process of doing that now
<cjwatson> dholbach: so does debdiff if applied to a pair of .changes files
<pitti> dholbach: right, debdiff old.i386.changes new.i386.changes
<dholbach> oh... ... ...
<cjwatson> laga: most packages use language packs, but ubiquity can't because it would need all language packs to be installed on the live CD which isn't feasible
<dholbach> pitti, cjwatson: how do you get an old *.changes file for a build that you don't have on your disk already?
<dholbach> I'm happy to drop compare-packages, just trying to find out a clever workflow
<pitti> dholbach: that's pretty tricky indeed; how does c-p do it?
<pitti> dholbach: for this case I would just compare the .debs one by one
<dholbach> it doesn't, you either need your own mirror or get debs
<pitti> dholbach: I'm not saying that c-p isn't a good idea, I'm just curious what it does :)
<dholbach> but at least they are easier to get
<cjwatson> debdiff --from foo_1.deb bar_1.deb --to foo_2.deb bar_2.deb
<dholbach> ok, gotcha
<cjwatson> rtfm :-)
<dholbach> changes committed in ubuntu-dev-tools
<Mithrandir> or have a fake-changes command that gives you a fake .changes file for a set of .dscs/orig.tar.gz/.tar.gz/.deb files, so you can do debdiff <(fake-changes foo_1.deb foo_2.deb) foo_2.changes
<pitti> evand: gobuntu-meta is not currently seeded; is it meant to stay in main for gutsy, for CD building etc.?
<StevenHarperUK> Hi im looking for a Guide to using po translation files in PYTHON for my GTK project - can anyone help?
<pitti> StevenHarperUK: you probably don't want to use .po files directly, right?
<pitti> StevenHarperUK: you should just use the standard gettext Python module
<dholbach> StevenHarperUK: try using python-distutils-extra
<StevenHarperUK> Im have an XMl file at the moment
<StevenHarperUK> Whats the correct way
<pitti> dholbach: oh, cool; in apport and r-m I still have custom code to build .mo, etc.
<dholbach> glatzor rocks :)
* pitti hugs glatzor in absence
<StevenHarperUK> Is there a GUIDE to making an APP Multi lingual using PO files ?
<pitti> cjwatson: hmm, component-mismatches still contains lots of fallout from mobile (like claws-mail, mce-dev, etc.)
<laga> cjwatson: alright. i was going to translate the mythbuntu frontend into german. is it too late now?
<dholbach> StevenHarperUK: python-distutils-extra is a package including a python module that helps with translations in python projects
<StevenHarperUK> Is there a Guide to doing that?
<StevenHarperUK> An API - or example would be a great start
<dholbach> apt-get source python-distutils-extra contains an example
<dholbach> bzr get http://bazaar.launchpad.net/~ubuntu-art-pkg/example-look/dev       to
<dholbach> too
<\sh> pitti, I can't upload ;) could you upload it? :)
<pitti> \sh: oh, sure
<\sh> pitti, thx :)
<\sh> pitti, fixes for the other distros are coming...dapper is attached
<StevenHarperUK> Theres nothing there http://bazaar.launchpad.net/~ubuntu-art-pkg/example-look/dev/
<dholbach> run  bzr get <url>
<StevenHarperUK> ta
<cjwatson> laga: no
<cjwatson> pitti: as I noted in my mail, I can only get rid of some of them; things that get pulled in through build-depends are too hard to get rid of without another pile of germinate runs which would be computationally expensive
<cjwatson> StevenHarperUK: info gettext
<pitti> cjwatson: understood, thanks
<laga> cjwatson: ok, where can i translate it then? i've got the source here but you said it was handled in launchpad
<cjwatson> laga: https://translations.launchpad.net/ubuntu/gutsy/+source/ubiquity/+pots/ubiquity
<cjwatson> laga: actually, cancel that
<pitti> \sh: uploaded
<\sh> pitti, thx
<cjwatson> laga: https://translations.launchpad.net/ubuntu/gutsy/+source/debian-installer/+pots/debian-installer is what you actually want to translate
<cjwatson> it's a combined set including translations of the whole installer, not just ubiquity
<laga> cjwatson: thanks a lot!
<StevenHarperUK> I want to make my own Project that is a python GTK app use the Proper Ubuntu Multi lingual implementation instead of my own XML effort
<StevenHarperUK> mine works, but I want to use Launchpad to get Translations
<laga> hum.
<laga> StevenHarperUK: for mythbuntu-control-centre, we just ripped the translation stuff out of restricted-manager
<laga> StevenHarperUK: you need the Makefile, AFAIK, and then you add the files which need to be translated to po/POTFILES.in
<laga> i'm not sure how to upload translations to launchpad, though :)
<StevenHarperUK> How are these used in Python thou : I need some sample code, the art example has no actual python code
<laga> check the source of restricted-manager or mythbuntu-control-centre (only aailable in gutsy)
<StevenHarperUK> you have a URL for the source?
<laga> StevenHarperUK: BTW, this assumes you're using glade
<cjwatson> xgettext knows how to extract translatable strings from python source so it should work as it would for C code
<cjwatson> see info gettext
<cjwatson> (or indeed xgettext can extract from glade files too)
<StevenHarperUK> My text is already in an XML file
<StevenHarperUK> I want to switch to the po method
<laga> StevenHarperUK: are you using glade?
<cjwatson> then use the appropriate tool to extract strings to a .pot file
<cjwatson> if the XML file is useful for something else, keep it and extract the strings in a makefile; if not, junk it and keep the generated .pot file
<StevenHarperUK> I dont use make
<StevenHarperUK> I use debtools to make by debs
<cjwatson> that's usually a mistake
<StevenHarperUK> its python its all different
<cjwatson> note that debian/rules is a makefile
<geser> doko: I rebuild pdftk and it still has the same problem
<laga> StevenHarperUK: are you using glade? *sigh*
<StevenHarperUK> Ill find a Current python project that uses these (resricted-manager) and have a crawl over it
<StevenHarperUK> no *sign*
* laga shakes head
<cjwatson> pitti,evand: I've fixed the Gobuntu desktop seed to include gobuntu-desktop
<pitti> cjwatson: thanks
<doko> geser: yes, afaik it needs some work
<geser> doko: is the problem in pdftk or in gcj-4.2? or somewhere else?
<doko> geser: pdftk, hot it is built
<pitti> ajmitch: can mono sensibly be built against libgda3 instead of 2? it's the only remaining rdependency
<pitti> ajmitch: and IIRC previous mono versions did not build against it (since libgda2 was once in component-mismatches for demotion)
<ajmitch> pitti: afaict the use of libgda in mono is in a not-very-maintained System.Data provider
<ajmitch> so I don't know if that code is even useful, or used at all :)
<pitti> ajmitch: just asking because libgda2 now appears in component-mismatches again, so it would be nice to change that to libgda3 or drop it
<tahorg> hi, is there a timeline for fixing xen in gutsy amd64 ?
<ajmitch> I can try & look at it in the morning
<Kopfgeldjaeger> hi
<pitti> ajmitch: thanks
<ajmitch> along with that samba update I was doing before they released 3.0.26 to fix a security problem
<ajmitch> which I'll need another UVF exception for, I guess :)
<pitti> ajmitch: see my current post to u-devel@ :)
* ajmitch waits for mail to arrive
<ajmitch> pitti: I don't see any recent post
<pitti> erk, yes, I just saw that my local mailq is full of stuff
<pitti> I guess my SSL certificate expired, or so
* pitti grumpily drops everything else and fixes it
<ajmitch> oops :)
<\sh> pitti, bug 139569 ready for review and security upload...dapper/edgy/feisty debdiffs attached :) thx :)
<ubotu> Bug 139569 on http://launchpad.net/bugs/139569 is private
<pitti> \sh: hm, any reason not to make it public? it's a published issue after all
<ajmitch> pitti: what was in this important mail to u-devel? :)
<\sh> pitti, aeh...It's default when selecting "Security Bug" ;-)
<pitti> ajmitch: dropping UVF, hang on, still scp'ing SSL keys around and refreshing :)
<ajmitch> alright..
<evand> thanks cjwatson
<\sh> bug 139569 <test>
<ubotu> Launchpad bug 139569 in quagga "quagga in dapper/edgy/feisty are vulnerable to malformed community string in bgpd" [Undecided,New]  https://launchpad.net/bugs/139569
<\sh> pitti, changed :)
* ajmitch is glad that the samba issue only affects 3.0.25, which is only in gutsy
<Fujitsu> \sh: Your edgy debdiff is a bit empty.
<\sh> argl
<\sh> moment
<\sh> Fujitsu, now ;) I'm faster then my harddrive
<pygi> siretart, will do
<siretart> pygi: sorry? what will you do?
<pygi> siretart, look at gutsy-changes for acceptance of cdrtools :)
<siretart> ;)
<pygi> siretart, I'll talk to you about this in sec :)
<dholbach> mvo is on planet.ubuntu.com - yay! :)
<dholbach> mvo_: you need a hackergotchi!
<LongPointyStick> hackergotchis are overrated
<LongPointyStick> oh yes, i should change mine.
<ajmitch> blogs are overrated
<StevenK> ajmitch: Agreed.
<LongPointyStick> mneptok: where's that image of the green thing with the pointy stick?
<StevenK> pitti: Can I convince you to let virtualbox-ose out of binary NEW?
<pitti> StevenK: no, because I did that several hours ago already
<StevenK> pitti: I see that. Thanks ever so. :-)
<StevenK> kagou: ^
<kagou> StevenK, :p
<StevenK> pitti: It looks like kaffe builds. You might even be able to convince me to upload it.
* pitti hands a beer to StevenK 
<pitti> and a package of Toffifee
<\sh> hopefully it was the last vmware instance I deployed today...now to the real things
<StevenK> Mmmm, German beer
<ajmitch> StevenK: it'd be worth having the next UDS in germany at that
<StevenK> pitti: ikvm is the last one - but the current version in Gutsy won't do a rebuild, and the upstream changes between it and the version in Debian are *massive*.
<StevenK> ajmitch: Indeed. I don't think Germany has had a UDS yet.
<StevenK> Means I get to brush up on a language I haven't spoken in 14 years
<ajmitch> doing better than I am then :)
<\sh> StevenK, an UDS in germany? let's do it in karlsruhe ;)
<StevenK> \sh: No fair, you're biased. :-P
<ajmitch> StevenK: ikvm is universe, and I'd say it's rarely used
<StevenK> ajmitch: Agreed.
<\sh> I think United Internet , Astaro and other companies who are using opensource will come :)
<ajmitch> what's the current build problem with it?
<\sh> StevenK, hmm..then let's do it next year in cameroon...;)
<StevenK> I'd have to chedk.
<pygi> siretart, pm ^_^
<StevenK> ajmitch: Gimme a minute to polish kaffe.
<StevenK> polish off
<ajmitch> no problem
<StevenK> pitti: Right, build of kaffe finished. Shall I throw it over to the buildds?
<pitti> StevenK: please! you rock!
* LongPointyStick is all for a UDS in germany.
<ajmitch> apart from the flights
<ajmitch> & that it'd cost quite a bit :)
<\sh> short ways for many ubuntu devs ;)
<StevenK> E: Package mono-classlib-2.0 has no installation candidate
<ajmitch> aha
<ajmitch> so just a bad build dependency
<StevenK> I don't think that's the error I had when I looked at it quite some time ago
<ajmitch> probably not
<ajmitch> what arch are you building that on?
<StevenK> amd64
<StevenK> I am pondering just being naughty and uploading
* ajmitch tries to recall what it was changed to
<ajmitch>       - Removed obsolete mono-classlib-{1,2}.0 transition packages.
<ajmitch> from october
<StevenK> So it should be upgraded anyway
* ajmitch thinks that getting a new upstream version in would be less hassle
<StevenK> (ikvm, that is)
<ajmitch> yep
<StevenK> pitti: Mind reading ajmitch's and I conversation? I know it's a universe package - do you have any objections to me just uploading it sans UVFe?
* StevenK actually finishes off the merge.
<StevenK> ajmitch: What does dh_makeclilibs do?
<StevenK> ajmitch: IE: is it safe to drop, or do I need keep it around?
<ajmitch> it does tend to be rather useful, it's the equivalent of dh_makeshlibs
<ajmitch> if you don't have it, get cli-common-dev
<StevenK> Which is Build-Depend'd on.
<StevenK> Right, merge done.
* StevenK test builds again
<ajmitch> aha, finally got pitti's mail
<ajmitch> pitti: that sounds fairly sensible, especially if motu-uvf agree to the same for universe
<StevenK> ajmitch: Right, ikvm builds and installs fine.
<ajmitch> great
<StevenK> pitti: +1 from me about the freeze consolidation
<StevenK> ajmitch: So, should I upload this thing? :-)
<ajmitch> sure, why not?
<StevenK> Because I don't have a UVFe...
<ajmitch> for universe, though you're on the uvf team? :)
<StevenK> Requires two acks. :-P
<ajmitch> we were a bit more relaxed about it for edgy & feisty when it warranted it :)
<pitti> StevenK: ikvm> fine for me, if you are know what you are doing
<ajmitch> soren should be alive still
<pitti> s/you are/you/
<StevenK> pitti: Mmmm. It's uploading.
<StevenK> pitti: Hopefully, in one publisher run, we can kill ecj-bootstrap{,-gcj}
<pitti> ajmitch: when you are going to touch samba anyway, do you think you could take a look at bug #139265?
<ubotu> Launchpad bug 139265 in samba "localized pam == no samba password changing" [High,New]  https://launchpad.net/bugs/139265
<ajmitch> sure
<pitti> ajmitch: I expect it's adding a LC_MESSAGES=C environment to the passwd call, or unset LANG/LC_ALL/etc.
<ajmitch> yeah, I read the bug report earlier
<ajmitch> I'd better sleep now though, almost 2
<pitti> ajmitch: thanks, good night!
<ajmitch> night
<mathiaz> ajmitch: night !
<cjwatson> ajmitch: if you do it by setting LC_MESSAGES then you should unset LC_ALL too; otherwise setting LC_ALL would also work (but might have other consequences)
<cjwatson> apologies if I'm preaching to the choir
<EtienneG> pitti, is 6.06.2 still on track for the 21st ?
<mathiaz> pitti: it seems that apparmor has not been published on archive.u.c
<pitti> EtienneG: no, unfortunately not, there have been delays in the kernel fixes
<StevenK> Mmmm, 6.06.2
<EtienneG> pitti, have a new release date been announced ?  (if yes, maybe https://launchpad.net/ubuntu/+milestone/ubuntu-6.06.2 should be updated)
<norsetto> I see something strange in the archive, apparently the viewcvs binary is produced by two sources (viewcvs and viewvc) so I guess the older one is obsolete and should be removed?
<RainCT> hi
<RainCT> why doesn't update-manager show that 7.10 is available (with -d) if you run it with sudo?
<pitti> norsetto: right, viewvc replaces viewcvs
<mvo_> RainCT: do you run it with sudo or without?
<RainCT> without it works, but with sudo it says nothing about the update (using -d on both)
<LongPointyStick> pitti: interesting mail.
<norsetto> pitti: ok; I got confused as I just pactched a bug in viewcvs and it got rejected :-) should I file a remove bug?
<pitti> norsetto: please, so that we have documentation for it; someone just pointed it out this morning
<norsetto> pitti: will do, thx
<mvo_> RainCT: that sounds like bug #127263
<geser> RainCT: does it also happen with "sudo -- update-manager -d"?
<ubotu> Launchpad bug 127263 in update-manager "update-manager cannot find meta-release info" [Medium,In progress]  https://launchpad.net/bugs/127263
<mathiaz> mvo_: yesterday I asked someone in ubuntu-server to try to use do-release-upgrade -d to upgrade a feisty server to gutsy. But it failed with no distribution found in the meta file (something like thhat).
<mvo_> mathiaz: with or without sudo?
<mathiaz> mvo_: with sudo
<mvo_> pitti: if you could have a look at #127263 that would be most appreciated, I would like to get it into feisty-proposed
<mathiaz> mvo_: the command he used was "sudo do-release-upgrade -d"
<mvo_> mathiaz: that is probably #127263 as well :/
<norsetto> bug 139037 :-)
<ubotu> Launchpad bug 139037 in viewcvs "Please remove viewcvs source from Gutsy" [Wishlist,Confirmed]  https://launchpad.net/bugs/139037
<mvo_> mathiaz: there is a fix, it is hopefully available in -proposed soon
<RainCT> geser: $ sudo -- update-manager -d            usage: sudo -K | -L | -V | -h | -k | -l | -v
<mathiaz> mvo_: ok. I asked him to install update-manager-core from -updates.
<mathiaz> mvo_: I'll ask him again later then.
<pitti> mvo_: can you please get it fixed in Gutsy?
<mathiaz> pitti: In the apparmor update, I've renamed libapparmor-dev to libapparmor1-dev, which is the reason why apparmor wasn't published in the archive as of yesterday.
<mathiaz> pitti: libapparmor1-dev was waiting in NEW.
<pitti> mathiaz: right, but kees named it back
<pitti> mathiaz: so I rejected libaparmor1-dev
<pitti>   apparmor | 2.1+961-0ubuntu3 |         gutsy | source, amd64, i386, powerpc
<mathiaz> pitti: yes. But as of now, it won't build correctly.
<pitti> and 0ubuntu3 is there
<mathiaz> pitti: The reason I renamed it was that I tried to follow the library guide
<pitti> mathiaz: but usually, -dev packages shuold not have a soname
<mathiaz> pitti: and according the command given there to figure out the name of -dev, it should be libapparmor1-dev
<pitti> mathiaz: not unless you actually want to support several sonames in parallel, which doesn't seem appropriate for apparmor
<mathiaz> pitti: beside the fact that lintian emits a warning when building the package.
<mvo_> pitti: its fixed in gutsy with the 0.72 upload, I updated the bugstats
<pitti> mathiaz: i. e. it does make sense to have libqt3-dev and libqt4-dev, because we want them in parallel
<pitti> mvo_: just saw it; weird that LP didn't close the task
<mathiaz> pitti: so I renamed to libapparmor1-dev and provided libapparmor-dev and conflict libapparmor-dev.
<mathiaz> pitti: ok. So it's better to keep libapparmor-dev.
<pitti> mathiaz: weird that lintian complains about it
<mathiaz> pitti: The warning is the reason why I looked into renaming it.
<pitti> I don't remember getting this for libpq-dev
<pitti> in fact I don't, right
<mathiaz> pitti: I'll try to rebuild it and see if I still get the warning.
<mathiaz> pitti: but as of now, libapparmor-dev is emtpy...
<pitti> mathiaz: hm, that *is* a bug indeed :)
<mathiaz> pitti: (and it's not on http://archive.ubuntu.com/ubuntu/pool/main/a/apparmor/)
<pitti> mvo_: I'd rather have it intercept OSError than Exception, but *shrug*
<pitti> libapparmor-dev | 2.1+961-0ubuntu3 |         gutsy | amd64, i386, powerpc
<pitti> mathiaz: ^ hmm
<pitti> indeed, WTH?
<pitti> it is on drescher
<pitti> might be a mirroring problem
<pitti> mvo_: out of interest, why does that code exist twice?
<mvo_> pitti: it does not, debdiff shows it two times, one is a symlink
<alex-weej> GTK+ 2.12 GOGOGOGOGOgogogogogog
<mvo_> pitti: update-manager and the release-uprader share this code to get meta-release information but in order to be able to ship updated versions the release upgrader has its own "copy"
<mvo_> pitti: I'm fine with changing it to OSError if you prefer that
<pitti> mvo_: it's just a bit more robust, but it's just nitpicking
<soren> ajmitch: hm?
<pitti> mvo_: so, fine for me
<alex-weej> is it too late to make changes to the desktop-effects UI so that we can add warnings about failing GLX and stuff?
<mvo_> pitti: thanks, uploaded
<zul> hi sabdfl
<mathiaz> keescook: I've fixed libapparmor-dev build for the apparmor packages.
<mathiaz> keescook: I've pushed the changes in my branch.
<pitti> mvo_: accepted/bug updated
<mvo_> pitti: cool, thanks!
* pitti radiates hate towards yada
<Hobbsee> hehe
<Hobbsee> pitti: just remove it.
<pitti> Hobbsee: just doing the last rebuilds for Maintainer: foo, and the last four packages hate me (which don't unpack/edit/debuild -S)
<StevenK> pitti: There's only one more package in main that needs yada
<pitti> yeah, I'm doing universe
<StevenK> Except that infinity is ignoring me
* Hobbsee would suggets uploading it anyway, then.
<Hobbsee> how long has he had?
<StevenK> Since before FF, I think
<StevenK> I last touched the changelog on the 8th of August
<StevenK> So, 5 weeks, give or take
<StevenK> pitti: Can you twist his arm? :-)
* pitti reminds StevenK that he is *much* closer to infinity than pitti
<StevenK> pitti: I'd really really like yada in universe for Gutsy. Well, actually, I'd prefer it out of the archive, but ...
<StevenK> Yeah, but Melbourne sucks
<pitti> StevenK: so why don't just upload your's?
<Hobbsee> ew, melbourne.
* Hobbsee goes and kills all the melbournites off.
* Hobbsee checks for Fujitsu
<Hobbsee> oh, whoops.
<StevenK> Because I'm waiting for feedback from infinity. And he had some good points the first time he looked.
* StevenK shivers.
<StevenK> I just read the debdiff. I had forgotten how *evil* the yada generated rules file is
<Hobbsee> probably created by a melbournian bar tender.
<StevenK> No, created by dexter. Much worse.
<Hobbsee> heh.  right.
<ScottK> Speaking of removing ... Bug #139037 is availalble for doing some archive removing...
<ubotu> Launchpad bug 139037 in viewcvs "Please remove viewcvs source from Gutsy" [Wishlist,Confirmed]  https://launchpad.net/bugs/139037
<geser> doko: found the pdftk build problem, it uses some local copies if gcj files: # older versions of libgcj might not have the MD5 algorithm (from # libgcj CVS on March 7, 2004; diffed September 5, 2006 w/ gcc 4.1.1)
<geser> doko: do you know since when MD5 is in libgcj?
<pochu> pitti: isn't today your archive day? :)
<Hobbsee> not that he's admitting to
<realist> StevenK, Hobbsee; you two are from Sydney I presume?
<pitti> pochu: yes
<Hobbsee> realist: no, i'm from antarctica
<realist> Hobbsee: that's better than Sydney, I suppose ;-)
<realist> Should've held APEC summit there.
<pitti> pochu: what do you need to get done?
<pitti> pochu: I did everything except syncs (sync tool is broken)
<pochu> woops, it's a sync :-)
<pochu> But it's not urgent
* Hobbsee is a penguin.
<Hobbsee> realist: but yeah, i am in sydney.  apec in antarctica, or even canberra would be great.
<pochu> pitti: oh if you can take a look at bug 137990
<ubotu> Launchpad bug 137990 in liferea "New upstream release 1.4.2" [Wishlist,Incomplete]  https://launchpad.net/bugs/137990
<StevenK> APEC is all over, there's no point complaining about it
<realist> I wasn't complaining. I'm in Melbourne :-)
<Hobbsee> then you suck.
<Hobbsee> why would anyone want to live in melbourne anyway?  :)
<realist> Melbourne > Sydney
<Hobbsee> in your dreams, perhaps
<keescook> cjwatson: yup, that does need fixing.  I'll get on it.
<pitti> keescook: good morning!
<pitti> keescook: ajmitch also agreed to look into the samba locale issue
<keescook> pitti: ah, okay, I will let ajmitch handle it then, since he is more familiar with samba.
<keescook> is bazaar.l.n having issues?  I can't seem to merge some branches.
<pitti> pochu: done, bug updated (approved)
<pochu> pitti: thanks a lot
<ScottK> pitti: syncpacakge isn't a great fan of "-" in the upstream version either.  I could probably do some work to modernize the script.  Do you feel it would be a worthwhile effort?
<pitti> ScottK: sure, it seems useful at times like this
<pitti> ScottK: I guess with rmadison and dget around it could also get a whole lot simpler
<ScottK> Right.  Well there's rewrite the whole thing and then there's make it work in a few corner cases it has trouble with.  I'm a lot more likely to have time for the latter.
<pitti> ScottK: or bug me to do it myself :)
<pitti> if it's blocking people's work, it's a good excuse for me to fix it
<ScottK> Sure.  Once you see my code, you'll be motivated for a complete rewrite.
<ScottK> So far lines after the Files: lines and"-" in the upstream version are the problems I've hit.
<ScottK> I just commented out the smarts for that case and set stuff to what it needed to be.
<ScottK> It should be easy enough to deal with those issues generally though.
<Nafallo> win 1
<soren> lose 2
<bddebian> Heya
<ScottK2> pitti: Here is, I think, a workable solution for syncpackage to lines coming after the Files section in .dsc (it seemed to work for me): http://pastebin.ubuntu-nl.org/37435/
<pitti> ScottK: hm, maybe "if not l[0] .isspace()"?
* ScottK looks
<ScottK> pitti: Not sure.  It seems that running out of things ending in .gz is a reasonably reliable way to know you're out of the Files: section.  I don't know enough about what one might expect to see in a .dsc to really know.
<Keybuk> getting a picture from my phone to my desktop is annoyingly difficult
<pitti> ScottK: it's a multi-line, i. e. as long as the lines start with spaces, you are still parsing Files:
<ScottK> Right.
<pitti> ScottK: i. e. until you either hit EOL or a line with a non-space in the first column
<Keybuk> I had a Python dsc parser somewhere
<ScottK> That makes sense.
<Mithrandir> Keybuk: right click bluetooth icon, choose "browse device", choose phone, copy files?
<Keybuk> Mithrandir: desktop doesn't have bluetooth
<Mithrandir> Keybuk: does too
<Mithrandir> oh, your desktop doesn't
<Mithrandir> -desktop does. :-)
<Keybuk> it's not very common in desktop computers
<Mithrandir> USB BT adapters cost about about two pence.
<ScottK> pitti: That works too.  I do agree it's better.
<Mithrandir> ok, more like ten or twenty quid, but still not very expensive
<Spads> and the security violations bluetooth allows are priceless
<pitti> oh, wow
<Keybuk> Mithrandir: I have a USB cable
<Keybuk> but it's about 2 metres away
<Keybuk> therefore annoying
<pitti> I just sticked in my BT dongle, and hey, Gnome *did* something
<Mithrandir> pitti: yes, it gives you the ability to, like, browse your phone.
* pitti enables BT on his phone
<Mithrandir> Spads: apart from all the fun bits of broken implementations, you mean?
<geser> pitti, ScottK2: isn't l[2]  the second char in l? I guess that's not what you want
<pitti> obex://[00:16:bc:04:c8:a1]  is not a valid place
<pitti> hmm
<cjwatson> Keybuk: you might have to get out of your chair
<cjwatson> geser: l[2]  is the third character
<Keybuk> cjwatson: I'm trying my phone's e-mail ability to see whether that works <g>
<pitti> I am supposed to check the spelling of my bt addresses? :)
<wasabi> Hmm. I'd agree that it's not common, but it will be.
<wasabi> Every MS wireless mouse we have in the office uses bluetooth now... and all the Compaq's you can buy come with it.
<geser> cjwatson: yes, you are right, but it's still not what ScottK wants
<Mithrandir> pitti: is gnome-vfs-obexftp installed?
<cjwatson> indeed
<pitti> something is missing, though, my phone can't associate with my desktop, and neither the other way round
<ScottK> geser: It's actually the third item in the list l in this case.
<pitti> Mithrandir: that did the trick, thanks
* ScottK is confident pitti will get it fixed up.
<Keybuk> cjwatson: my chair has wheels ... *wheee*
<pitti> wow, that's, like, MAGIC :)
<Hobbsee> hehe
<Mithrandir> pitti: care to add that to -desktop's recommends too?
<Hobbsee> welcome to 2007, pitti :P
<geser> ScottK: but l is still the whole line at this place, you get a list of tokens after the l.split()
<pitti> Hobbsee: last time I tried that it wasn't possible in gnome yet (maybe a year ago)
<pitti> Mithrandir: 75.2 kB, that doesn't sound too bad
<Hobbsee> pitti: ahh.  works just fine on kde.
<Mithrandir> pitti: it needs mainification, but that shouldn't be too bad either.
<Hobbsee> wouldnt know about your variant, though
* pitti hugs mvo_ 
<ScottK> geser: I don't think so, but I have to run.  I'm sure pitti will get it sorted
<pitti> mvo_: I clicked on a .mid file on my cellphone obex browser, and it offers me to install kmid; yay easy-codec-installation :)
<bdmurray> pitti: Does restricted-manager always ask you to restart after installing a new X driver?  I noticed the restart dialog on Feisty last night.
<pitti> bdmurray: after enabling nvidia/ati, yes
<pitti> bdmurray: we don't have a convenient method to restart only X, except for Ctrl+Alt+Backspace
<pitti> (but I don't want to recommend that, since it kills your apps without asking for saving, etc.)
<bdmurray> pitti: Hrm, but if somebody wanted to test Compiz on the Live CD . . .
<pitti> bdmurray: logging out and back in doesn't suffice (at least for me), ctrl+alt+backspace does the trick, though
<superm1> pitti, is there no nice signal you can issue to gdm to restart?
<bdmurray> pitti: Right - but if somebody is told to reboot after installing the proprietary driver when running the Live CD.  They'll reboot and need to install it again.
<pitti> superm1: you can call the init script, sure
<superm1> pitti, so why not offer the person to restart the session that route (only when in live mode)?
<pitti> bdmurray: right; the rebooting is easily available from update-notifier, so I used that
<pitti> superm1: that applies equally to the installed system, I think
<superm1> i guess you would still need to have it rmmod the radeon kernel module though
<superm1> if its loaded
<pitti> no, rmmod is out of the question, that wreaks havoc
<pitti> disabling can only safely happen with a reboot, but enabling can happen with a gdm restart
<alex-weej> anyone have any idea when gtk 2.12 will be uploaded?
* lamont looks around for an archive admin to pester about #139534
<geser> alex-weej: I wouldn't expect it before monday and as seb128 is on vacation (afaik) this may take a while longer
<lamont> bug 139534 even
<ubotu> Launchpad bug 139534 in palo "Please sync palo (main) from Debian unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/139534
<alex-weej> geser: oh panties :( ok thanks
<alex-weej> broken tooltips are driving me up the wall! :P
<Mithrandir> lamont: sync-source is b0rked atm, so not in a bit
<DrakeJustice> somebody point me at a guide for usplash generation in gutsy, plz?
<DrakeJustice> !
<lamont> Mithrandir: ah, ok.  I'll just shove 1.15.hppa99 into my repo then.
<keescook> pitti: but if they reboot a livecd, won't they just be back to needing to enable the proprietary driver again?  (i.e. there is no way to enable a proprietary driver via the liveCD)
<bdmurray> keescook: Isn't that what I said?
<pitti> keescook: as we said, you need to restart gdm
<keescook> bdmurray: yeah, I thought it wasn't understood.  pitti: right, I understand what needs to happen, but I'm saying a non-techie may not understand.
<lamont> hrm... slapd and racoon both need to be taught lsb boot messages
<bdmurray> l/win 5
<Keybuk> l/lose 10
<bdmurray> gah! I'm down 5 it seems
<Lure> pitti: UVFe submitted 139652
<Lure> pitti: bug 139652
<ubotu> Launchpad bug 139652 in libgphoto2 "UVF exception 2.3.1 -> 2.4.0" [Undecided,New]  https://launchpad.net/bugs/139652
<pitti> Lure: sorry, I have to run now
<pitti> darn, I lost track of time
<pygi> siretart, do you have a few seconds?
<ogra> Amaranth, ping ...
<Amaranth> ogra: pong
<ogra> Amaranth, mind joining #ltsp for a second ?
<ogra> we have a user there who desparately wants to get compiz on ltsp and it seems we cant get it working for him
<LaserJock> keescook: got a minute?
<keescook> LaserJock: sure, though I may be distracted by things.  :)  what's up?
<LaserJock> keescook: I'm trying to figure out how to read search results from http://cve.mitre.org/
<LaserJock> keescook: I'm working on a MIR so I did a search on the app
<LaserJock> and I got 36 results
<keescook> heh.
<LaserJock> but I'm trying to figure out how to figure what applies to the version we have, etc.
<keescook> what's the package?  (or rather, what is the search URL you ended up on?)
<LaserJock> http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=moodle
<keescook> That tends to be the "art" to dealing with CVE -- they're not always correct, and sometimes they don't have version info at all.
<keescook> ah, yes, moodle.
<LaserJock> we have version 1.8.2 btw
<keescook> yeah, there is a lot to dig through, and working with moodle's changelogs should be the most helpful here.
<LaserJock> ah, ok
<manchicken> Hmm... There's something wrong with suspend/resume and powermanagement on these System76 Darters under Gutsy.
<keescook> the work is to map their fixes to given CVEs
<keescook> LaserJock: this is what makes an upstream "good" or not when dealing with security fixes -- do they refer to CVEs in changelogs, are they good about splitting out patches, etc.
<keescook> if they're not, it's a lot of reading code to sort it all out.
<LaserJock> hmm, first job is to *find* a changelog :/
<keescook> hehe
<manchicken> At first I thought the power management thing was just KDE, but it seems to be a desktop-independent problem.
<\sh> LaserJock, did you try the security tracker of debian first?
<LaserJock> no, where is that?
<ogra> by the looks of it nost of these CVEs are fro versions like 1.4, 1.5, 1.6  ...
<ogra> *most
<LaserJock> keescook: they have a "Moodle Security Center" at least, although it's always worrying that they've got so many problems they have a whole center for it ;-)
<ogra> very likely they are fixed .... just find the proof ...
<LaserJock> ogra: yeah, I just want to make sure they are *fixed*
<\sh> LaserJock, http://security-tracker.debian.net/tracker/
<LaserJock> \sh: ahh, that is nice
<LaserJock> oh, that rocks!
<\sh> LaserJock, well, it needs a bug in the dbts to be listed but it helps us in the moment
<\sh> it helps me ;)
<LaserJock> it has a bunch of the moodle CVEs and tells you what version they were fixed in
<LaserJock> ok, all the CVEs on Debian are fixed in our version
<LaserJock> *phew*
<keescook> sweet
<LaserJock> it looks like 1.6 was a bad time in moodle history ;-)
<LaserJock> or rather <1.6
<ogra> yeah
* ogra reviewed 1.6 back in breezy iirc
<ogra> or 1.5
<ogra> it was horror
<\sh> LaserJock, tbh...most of the things where a patch is available is already in ubuntu, or is fixed in no time from pitti and kees...so ubuntu is very safe (passive meaning) and secure (active meaning)...
<\sh> LaserJock, and thx to debian ...
<ogra> \sh, yeah, we're just checking if keescook or pitti are slacking :P
<\sh> ogra, oh...I think pitti and kees are having fun sometimes ;)
<ogra> yeah :)
<\sh> and checking 3 distros at one time sometimes, it's nasty :)
<\sh> cherry picking patches is also no fun at all (tm) ;)
<keescook> hehe
<\sh>  keescook: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=441433 have fun ;) and celebrate ,-)
<ubotu> Debian bug 441433 in php5 "CVE-2007-3806, CVE-2007-2519 and CVE-2007-3799" [Important,Open] 
<\sh> keescook, it looks like that 5.2.4 is fixing most of the crap
<\sh> oh no...they fixed the CVEs from 5.2.2. ;)
<keescook> \sh: yay for php.  :)
<\sh> keescook, oh wonder...5.2.4. is fixing some new CVEs (CVE-2007-3806 e.g.)
<\sh> but it's also correcting fixes for old CVEs ;)
<keescook> \sh: yeah, I'm going to sort those out.  seanius (debian maintainer) and I have back-ported various CVEs as they've come up prior to 5.2.4 getting released, so I need to sort through them.
<geser> \sh: the last firebird2.0 in Debian unstable fixed 7 CVEs. Luckily for keescook and pitti firebird2.0 is in universe (and only since gutsy)
* \sh thinks he needs to switch from php to python and django
<\sh> geser, yeah I saw it ;) Just lurking on the debian security tracker ;)
<mathiaz> keescook: bug 139683
<ubotu> Launchpad bug 139683 in apparmor "package apparmor-utils 2.1+961-0ubuntu3 failed to install/upgrade: dependency problems - leaving unconfigured" [Undecided,New]  https://launchpad.net/bugs/139683
<geser> django is cool, but look also on turbogears which is also quite nice (I use it currently for a project at work)
<mathiaz> keescook: I think this is because the kernel was upgraded at the same time as the apparmor packages, but since it's not running the new module yet, apparmor fails to reload.
<keescook> mathiaz: ah, right, you dropped the error handlers...
<mathiaz> keescook: so we could ignore a failed reload on an upgrade ?
<keescook> the only way I know of is with the error handlers.
<keescook> mathiaz: can you add those back in, but change the text to say something about needing to check that the "apparmor" kernel module is loaded instead of the m-a goo it had before?
<mathiaz> keescook: sure.
<mathiaz> keescook: are you sure --no-restart-on-upgrade DTRT for the postinst script ?
<keescook> mathiaz: yes, I tested that.  It basically only does a "stop" on a "remove", not an "upgrade".
<keescook> but it does still attempt a "start" on configure (which we want), and I manually added a "reload" after the 'start' in the case of it needing a reload (start when already started just skips doing anything)
<mathiaz> keescook: yes.. I understand now. I was just looking at the postinst script.
<mathiaz> keescook: prerm does the right thing.
<keescook> cool.  It seems the error handler for the postinst just needs to catch the "start" failing.  (And perhaps we should adjust the "reload" call to be "|| true" just to be safe?
<mathiaz> keescook: I've used --error-handler=true
<mathiaz> keescook: in another package I fixed.
<keescook> hah!  that's good.  :)
<mathiaz> keescook: should we just fix the postinst script ?
<mathiaz> keescook: I think that --error-handler=true will have an impact on all maintainer sripts.
<mathiaz> keescook: hum.. it won't work since dh_installinit doesn't handled the reload call.
<keescook> mathiaz: it'll work for the "start", but the "reload" will need it fixed manually
<mathiaz> keescook: --error-handler will also modify prerm script.
<keescook> I think that's fine.
<keescook> (that's the way I had it before)
<mathiaz> keescook: that's the diff: http://paste.ubuntu-nl.org/37447/
<keescook> mathiaz: looks good.  you want me to add it, or is this in your bzr already?
<mathiaz> keescook: it will be in my bzr tree in a couple of minutes
<mathiaz> keescook: pushed.
<mathiaz> keescook: there is also another change: ignore .dpkg-dist files when loading profiles.
<keescook> ah!  good, yes.
#ubuntu-devel 2007-09-15
<emdash_> nn/win 10
<emdash_> gar
<slavik> UVF = Upstream Version Freeze?
<cjracker> iirc
<ScottK> slavik: Yes.
<slavik> k
<slavik> I had an idea ... dunno if it was though of, but what about alsa-oss package by default and also software mixing for all devices that don't support it?
<c1|freaky> if i reported a bug for kernel 2.6.20 on feisty, i upgraded to gutsy now theres 2.6.22 - the bug is about cpu frequency scaling which doesnt work - and i now want to report that this is still not working, can i just post a comment under the bug for 2.6.20 ? or should i file a new bugreport?
<slavik> hmm, cpu scaling works here ... (feisty)
<slavik> I am on c2q though
<c1|freaky> <-- amilo M 1437G gutsy
<slavik> what cpu?
<c1|freaky> Intel Pentium M - Dothan i think
<c1|freaky> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/93331
<ubotu> Launchpad bug 93331 in linux-source-2.6.20 "Kernel doesn't scale my CPU." [Medium,Fix released] 
<\sh> hmmm...does anyone know what this error message could be?
<\sh> Rejected:
<\sh> Attempt to upload binaries specifying build 375243, where they don't fit.
<siretart> any archive admins around?
<siretart> hi \sh!
<\sh> moins siretart
<Kopfgeldjaeger> hi
<siretart> \sh: do you remember who this guy was that was interested in fai in ubuntu?
<siretart> avinc something, but I don't remember exactly
<\sh> logfiles....
<\sh> siretart, when was it?
<\sh> alvinc was the nic
<siretart> ah, thanks
<siretart> do you know him? do you have his email adress?
<\sh> http://people.ubuntu.com/~fabbione/irclogs/ubuntu-motu-2007-09-05.html
<\sh> nope..
<siretart> hm.
<siretart> seems to be his lp id as well
<siretart> thanks
* Hobbsee tries out wine again
* \sh ducks and goes out of hobbsees way
<\sh> hmmm...sending a window to virtual desktop no. doesn't work with compiz...but moving it right or left works...do I miss something?
<kylem> win 27
<TomaszD> hi. Is it me or is bluez-gnome in gutsy completely different from the standard one? If so, where is the translation for this thing? It seems like a cruel joke when people struggle to keep the standard thing up-to-date and all of a sudden I see a different bluetooth-properties applet where everything is in English despite the fact that bluez-gnome is fully translated into Polish.
<TomaszD> Rosetta shows that bluez-gnome is fully translated and that's true, I maintain it upstream.
<\sh_away> keescook, thanks for the upload
<gnomefreak> noticed gb mirror is down/not grabbing packages
<Kmos> TomaszD: I think you need to talk to carlos about that on #launchpad
<TomaszD> Kmos, ok thanks
<\sh_away> anyone who wants to sponser bug 47232? ;)
<ubotu> Launchpad bug 47232 in redland-bindings "example file provided in /usr/share/doc/python2.4-librdf doesn't work" [Medium,New]  https://launchpad.net/bugs/47232
<siretart> any ftp-archive admin around? there are some packages in universe which aren't supposed to be there :/
<__pablo__> hello world
<__pablo__> exist a plugin in dev for rhytmbox to use tap_eq?
* minghua sighs and shakes head at a package that has a half-cooked ubuntu-specific patch that causes missing dependency.
<finalbeta> tap_eq?
<finalbeta> I'll assume you need equalizing, and thus no
<__pablo__> yes
<__pablo__> i use it as a plugin for ladspa
<__pablo__> but i don't set it in simple way
<__pablo__> but in ~/.asoundrc
<__pablo__> manually
<__pablo__> ps:: excuse me for my english
<__pablo__> i think that a plugin to set tap_eq will be very usefull... now my linux box sound very well... but if i need to modify the eq set is problematic
<finalbeta> I'm sure everyone agrees to you, and this feature has been requested for years now. Someday...
<__pablo__> audacius had this feature... i don't think that is very difficult port it to rhytmbox
<ace_suares> Dear ppl, I have severe problems with OO in Kubuntu Feisty. I asked in openoofice.org-devel but they point me back to ubuntu
<Hobbsee> !weekend
<ubotu> 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.
<ace_suares> I reported the problem extensivly in launchpad but hitherto no answers...
<ace_suares> hi Hobbsee
<Hobbsee> hi
<ace_suares> yes it is weekend....
<ace_suares> sweet saturday and my machine hangs and i need to reboot :-(
<ace_suares> it seems to be difficult to pinpoint this problem
<ace_suares> since it's OO interacting with what not (X ? KDE ?)
<ace_suares> and maybe it's a freak thing only to be seen on multihead machines and not all developers have multihead
<Riddell> ace_suares: you are yet to say what the problem is
<Riddell> calc is the dude for openoffice though
<ace_suares> I will paste about 7 lines...
<ace_suares> calc: (Thanks ridell)
<ace_suares> My openoffice on ubuntu feisty crashes whenver I touch the menu (for instance file) but I can't see how to debug this
<ace_suares> it hangs the entire machine and only reboot can save me
<ace_suares> I have to to the reboot from another machine via ssh
<ace_suares> because everyting hangs, and I can't use my keyboard anymore
<ace_suares> furthermore, as soon as the screensaver kicks in, I loose an entore screen on my 3-head machine
<ace_suares> and X is just working around it by only using the two screens that did NOT have OO running
<ace_suares> ridell: hope this makes sense
<FoxII> woo! I'm in
<FoxII> Any high up devs here? As In those that are 'permenantly' involved with ubuntu?
<keescook> \sh_away: you bet.  thanks for the patches.  :)
<Hobbsee> !weekend | FoxII
<ubotu> FoxII: 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.
<FoxII> Thank you Hobbsee :)
<FoxII> My question is (and I'm willing to wait. I know the time that developers put into this project); The relationship between developers and members who are testing and how the development between the both is not hindered by flaming and/or complaints. I understand fully that both are viable and likely to happen, but I would like to know how this is limited and how the developers keep the testers happy with regard to devel
<FoxII> opment, even with development of 'back-end' parts which are not initially included in global updates.
<Hobbsee> oh, you're from the forums arent you?
<FoxII> If that makes sense. I will try to explain further if possible.
<FoxII> yes, Hobbsee, it was suggested to try here for my question to be answered. I hope that is okay :)
<Hobbsee> hardly anyone here at this time of night
* Hobbsee --> bed
<Hobbsee> it is a weekend, after all
<FoxII> Ihm, I understand fully for those that are left. hehe. I can wait for a reply. :)
<Doctor_Nick> hey, apparently there was a demo yesterday about using launchpad to create and submit packages, does anyone know where i might find that
<beuno> Doctor_Nick, https://help.launchpad.net/PPA101/20070913
<Doctor_Nick> thanks
<beuno> :D
<pygi> siretart, ping if you're here
<pygi> ok, you're not :p
<okaratas> hello
<okaratas> ompaul, hello
<ompaul> hi
<gnomefreak> will /etc/gdm get regenerated if i rm it when gdm starts after reboot?
<mjg59> gnomefreak: No?
<gnomefreak> the setting look right but i am still missing gdm menu
<gnomefreak> looking to start with clean conf
<wasabi> So reinstall the config file.
<mjg59> If you delete files in /etc, then in most cases the packaging system will assume that you've done it deliberately and not recreate them
<gnomefreak> using --purge didnt change it in any way
<wasabi> Uh huh. dpkg -i --force-conf or something
<wasabi> --force-confmiss
<gnomefreak> said it wasnt empty so not removing so im looking for other choices atm
<wasabi> missconf. one of those. it's in the man page, plain as day
<gnomefreak> options was there just the screen is too big for the monitor screen, that would explain why xubuntu's login screen worked
#ubuntu-devel 2007-09-16
<m1ke> apt package manager appears to be broken.  It fails to completely update,and I get the same error daily for this last week.  http://www1.uploadhut.com/viewimage.php?type=2&id=23369-Screenshot-synaptic.png
<stdin> everything seems fine here
<m1ke> apt package manager appears to be broken.  It fails to completely update,and I get the same error daily for this last week.  Then it always wants me to reboot my computer, but the problem is never fixed.  http://www1.uploadhut.com/viewimage.php?type=2&id=23369-Screenshot-synaptic.png
<stdin> m1ke: this isn't a support channel
<geser> Mithrandir: can you please move cdrecord, mkisofs and cdda2wav (build now from cdrtools in multiverse) to multiverse. Thanks.
<enyc> geser: at least you know who ta ask ;-)
<enyc> geser: ?where do i find the information on why packages are in multiverse/restricted [licensing notes] ?
<pochu>  /usr/share/doc/$package/copyright
<geser> it's usually because of the license which is also included in the copyright file
<enyc> i see ;-)
<enyc> thankyou ;-)
<enyc> hrrm that is in binary pkg... can I find copyright in source pkg too?
<pochu> yes, in debian/copyright
<geser> Hi pitti :)
<geser> pitti: can you please move cdrecord, mkisofs and cdda2wav (build now from cdrtools in multiverse) to multiverse. Thanks.
<enyc> geser: i can see a snag here.........
<geser> enyc: the binary debs have the same copyright file as the source package, you can get both also from packages.ubuntu.com
<enyc> geser: when somebody had dapper/edgy... they have mkisofs.  when they install feisty a "dep" pagkae installs the genisoimage replacement, leaving a dummy mkisofs package there too....
<pitti> hey geser
<Kopfgeldjaeger> hi
<pitti> geser: oh, aren't they? the ones in main should be the transitional packages from cdrkit
<enyc> geser: then if they upgrade to gutsy.... they end up with old mkisofs-multiverse on account of 'upgrading' the mkisofs package [??] 
<enyc> pitti:  they were... in feisty... however  multiverse now has cdrtools there...
<pitti> geser: I had a long discussion about this with siretart yesterday, and it was not an easy decision
<pitti> geser: done
<enyc> pitti: seems that cdrtools license changed and the original author is getting annoyed about the forked genisoimage/wodim/etc...  mess ;-)
<enyc> pitti: whats happened?
<pitti> enyc: right, but the license has always been like that
<enyc> pitti: i actially have a 'confusing' email from schilly (cdrtools author) in reply to  a bug i replied in etc... ;-)
<pitti> enyc: but cdrkit is not maintained any more, so we want to provide the original cdrtools in multiverse
<enyc> pitti: "like that" ?
<pitti> enyc: license-wise
<enyc> pitti: im confused
<enyc> pitti: "like that" not defined in enyc
<pitti> enyc: I don't know the older licenses precisely, but the current cdrtools license is not free
<enyc> [ok] 
<pitti> enyc: it was in source new, and I reviewed it, so it put it in multiverse
<geser> iirc cdrkit was forked from cdrtools as it still was all GPL
<enyc> pitti: i am now concerned there is an upgrade-path-problem for people who upgrade from edgy>feisty>gutsy  ... as edgy>feisty proaly leaves "mkisofs" dummy pkg there, having installed "genisoimage" ... if they upgrade to gutsy... they then may "upgrade" mkisofs to  multiverse-mkisofs [?] 
<pitti> enyc: right, but only if they have multiverse enabled
<pitti> enyc: if they do, they most probably want it (since it's better hw-support-wise), and if they don't have multiverse, they won't have an upgrade problem either
<pitti> geser: right, but forked from an ancient branch
<enyc> pitti: [ok] 
<enyc> pitti: thankyou for comments ;-)
<StevenK> Isn't the current cdrecord and co using the OpenSolaris license because Shilly touches himself over OpenSolaris?
<geser> yes, it's a mix of GPL and CDDL
<Fujitsu> Ooh, special.
<StevenK> That's it, CDDL
<siretart> hi
<siretart> pitti: I've uploaded a new cdrkit package earlier today dropping the transitional packages. the override entries for 'cdrecord' 'mkisofs' and 'cdda2wav' need updating
<pitti> siretart: thanks, I saw
<pitti> siretart: that'll still be an issue for LTS->LTS upgrades, though
<pitti> siretart: people who don't have multiverse enabled won't auto-upgrade to cdrkit now
<siretart> pitti: perhaps we can a bof in boston about that
<siretart> because it's a matter of what we actually want
<siretart> StevenK: the current cdrtools is highly delicous. in the end, it seems to be okay for sun's lawyers. pitti and I agreed that the license is very likely to be okay for multiverse, and we both agree that it isn't for universe
<siretart> pitti: btw, there are indeed file conflicts in the mkisofs/icedax packages for cdda2ogg. I think I'm changing the packages to use alternatives, with cdrtools at a higher priority. I'll look into it this evening
<pitti> siretart: thanks
<pygi> siretart, meh, problems again? :)
<pygi> enyc, in the end, solution is to use neither cdrkit or cdrtools :D
<enyc> pygi: ;-)
<pygi> I'm serious, you know :p
<enyc> pitti: i didnt know there were plans for LTS>LTS upgrades
<pitti> enyc: we won't support apt-get dist-upgrade, but using update-manager should work
<StevenK> pitti: But dapper doesn't have update-manager for servers.
<pitti> StevenK: we'll have to upload it to dapper-updates, I think (same as we did for edgy)
<pitti> StevenK: "it" == update-manager-core
* StevenK nods.
<StevenK> Does that give a command line client?
<pitti> yes
<StevenK> Way cool.
<StevenK> Perhaps we should target that for dapper.2?
<ompaul> is sladen in the house?
<attunix> How do I make a usplash?
<Whoopie> mjg59: Hi, would it be possible to get the hardware mixer and software mixer on Thinkpads in sync?
<AnAnt> Hello, is there a problem with LP ? I can't login using Firefox. When I try elinks, I can login, but I can't post !
<mxq> hi everyone
<mxq> im trying to use metacity and gtk theme from ubuntu studio in arch linux everything is ok, except the colour of hilighted metacity buttons i copied themes from /usr/share/themes is there something more i should do? if you could give me direction where i could look.
<zul> mxq you might want to talk to the ubuntu-studio folks
<mxq> i asked them but didnt get an answer
<mxq> i asked also gtk+, gnome-uk, ubuntu-pl,
<mxq> and archlinux.pl
<terlmann> does the archive you distribute called linux.2.6.22.tat.bz2 contain the 2.6.22 performace patch  ?
<mxq> terlmann: you asking me?
<terlmann> and if I unzip 2.6.23 files and |patch them into it, will that break the source ?
<terlmann> no , anyone here
<mxq> sorry
<terlmann> you guys to distribute this stuff ;-)
<terlmann> do*
<terlmann> and do I need to copy my patch .tar.bz2 files into the usr/src/linux dir or do I untar them from the /usr/src dir ? will patch put the patches into the correct place ?
<terlmann> I guess it will
<pochu> is the sync tool working again?
<geser> pochu: you mean bug #139550?
<ubotu> Launchpad bug 139550 in soyuz "sync-source.py broke: column "published" does not exist " [Undecided,In progress]  https://launchpad.net/bugs/139550
<pochu> geser: looks like
<geser> Hi Hobbsee
<Hobbsee> hi geser
<sladen> ompaul: sladen is /always/ in the house.
<Hobbsee> sladen!
<ompaul> sladen, :) you got mail
<sladen> ompaul: coo, lucky me.  what's a happening
<ompaul> sladen, not a lot
<sladen> ompaul: which email box, I'm wonder where it's been filtered to?
<ompaul> ahh sladen.org
<sladen> hello Hobbsee, is it dark in Australia yet?
<Hobbsee> sladen: long dark.
<ompaul> sladen, they are +9 on londonium
* ompaul wonders where sladen is
<Hobbsee> sladen: it's 1.14am here
<sladen> ompaul: halfway between Gtenburg and Stockholm on the train.  About 3 hours away from tollef and simira's place if I wasn't trying to catch this ferry
<ompaul> k
<Hobbsee> nice :)
<Hobbsee> sladen: say hi to them fo rme :P
<pygi> siretart, around?
* LaserJock wonders why people feel the need to write GUIs that must be started from terminals
<ompaul> LaserJock, in support of twm :)
<LaserJock> heh, perhaps ;-)
<LaserJock> rkward has this in their .desktop: Exec=konsole -e rkward -caption "%c" %i
<LaserJock> so not only does it have to be started with a terminal, that termial has to be konsole
<poningru> heh
<Kopfgeldjaeger> does anyone how how i could build (a debian package) of rutilt? i think the Makefile is somehow special... when i dpkg-buildpackage it, it tries to remove files in /usr/share and also tries to create such files
<Hobbsee> Kopfgeldjaeger: #ubuntu-motu for universe packages. i think norsetto recently uploaded it
<Kopfgeldjaeger> oh, cool, thanks
<bluekuja> LaserJock, are you sure about rkward bug?
<bluekuja> usually it's not a good thing to modify makefiles directly
<bluekuja> without a patch
<bluekuja> if there's no patch system, it can be easily added for next patches too
<LaserJock> we use minimal delta
<LaserJock> there's no real reason to add a patch system there, IMO
<bluekuja> LaserJock, yeah, but working on a makefile directly that way is bad
<bluekuja> with an automake call everything will be deleted
<LaserJock> he modified Makefile.am
<bluekuja> yea
<LaserJock> that should be fine
<bluekuja> LaserJock, I trust you then
<bluekuja> that's fair enough
<LaserJock> well, why would that be a problem?
<bluekuja> LaserJock, had a bad experience on one of my packages on debian for it
<bluekuja> so wanted to have a clear vision of it
<LaserJock> well, I don't think the makefile.am should be touched during build or anything
<bluekuja> LaserJock, by running automake
<bluekuja> the modified file will be makefile.in
<bluekuja> am I right?
<bluekuja> I mean final output
<LaserJock> right
<LaserJock> and then a ./configure should give you a Makefile
<Hobbsee> geser: dude, it's a weekend.  file a bug, dont expect the archive guys to be around to do your bidding.
<Hobbsee> oh, he was there.
<LaserJock> bluekuja: so modifying Makefile.am shouldn't be a problem
<bluekuja> LaserJock, so the makefile changes everytime
<bluekuja> at configure run
<bluekuja> of course
<LaserJock> yes, modifying a Makefile when there's autotools stuff that's gonna wipe it out is not good
<bluekuja> LaserJock, exactly
<LaserJock> but in this case a patch isn't going to do anything
<[miles] > hi, can anyone tell me which channel is best to ask about packaging building questions please?
<jdong> elmo: yo, you around? http://ubuntuforums.org/showthread.php?p=3374712 seems like forum server is somehow tripping an odd firewall alert for some users?
<LaserJock> if you patch the Makefile it's gonna do the same thing
<desrt> [miles] ; probably #ubuntu-motu
<LaserJock> patch system vs. no patch system isn't going to change that
<bluekuja> LaserJock, yeah, was confused with second option
<bluekuja> LaserJock, thanks for this clarification
<elmo> jdong: err
<elmo> jdong: those are just reply packets and a very broken piece of software that's false alarming over nothing
<jdong> I'm looking at this silly arno-iptables script and seeing what rule matches that message...
<jdong> elmo: I suspected something that simple
<[miles] > ah ok thanks desrt
<jdong> elmo: alright thanks, got it handled
<elmo> jdong: cool, thanks
<elmo> jdong: FWIW, we get this a lot with archive.ubuntu.com too :(
<jdong> elmo: the iptalbes rule responsible seems plain nonsensical to me
<bluekuja> LaserJock, I asked him to upload a new debdiff
<bluekuja> with terminal=true
<bluekuja> and that's all
<bluekuja> LaserJock, is that ok for you?
<LaserJock> yeah, if it works
<bluekuja> LaserJock, ok
<bluekuja> gonna tell him to test it before
<pygi> new Gnomebaker released :P
<IntuitiveNipple> Does anyone know how user-created Gnome menus (alacarte) are linked to their Applications? The application desktop files don't have a "Category" key like system desktop config files do
<LaserJock> IntuitiveNipple: I believe they are hard-coded into the applications.menu
<IntuitiveNipple> what are?
<LaserJock> the category
<LaserJock> i.e. the .desktops are explictly added to the category you want
<IntuitiveNipple> The files for the custom-created directory and the application desktop files are in ~/.local/share/... but I can't see how gnome associates the application with the menu
<IntuitiveNipple> Yes, I know, but these alacarte-created application desktop files don't have a Category key - I can't see how they are being placed in the custom menu as a result :)
<LaserJock> IntuitiveNipple: the applications.menu are in ~/.config/menus/
<LaserJock> IntuitiveNipple: I'm saying that .desktops are expeclicity added to the applications.menu file
<LaserJock> *explicitly
<IntuitiveNipple> Ahhh! nice one, thanks! I thought from reading the gnome docs it scanned the directories and built the menus by merging based on the files, I didn't see anything describing the ~/.config/menus/applications.menu
<IntuitiveNipple> mucho gracias - I've been puzzling over that so I can but all the KVM/QEMU apps and links to virtual images in one place
<IntuitiveNipple> And people reckon Windows is convoluted! :)
<LaserJock> so you want to ship menu modifications?
<IntuitiveNipple> No... I want to put all my QEMU related stuff in one place (Qemu-launcher, qemuctl) etc
<IntuitiveNipple> I had a "Virtual Machines" custom menu folder with the virtual machines in, wanted to pull everything into there
<LaserJock> ah
<IntuitiveNipple> So all I need to do is make a copy of the installed system desktop config file in the ~/.local/share/... and then reference it in ~/.config/menus/applications.menu ?
<LaserJock> well, why don't you just use alacarte?
<IntuitiveNipple> This all began when I was trying to 'drag' an application from 'Accessories' to the custom menu folder and it won't do it, so I set out to find out how it all works
<IntuitiveNipple> I prefer playing around with the XML; I learn more although it's more stressful :)
<LaserJock> yeah, and you can mess up your menus :-)
<LaserJock> but it can be fun
<IntuitiveNipple> I don't mind, they are the least of my concerns!
<IntuitiveNipple> I'm building a whole bunch of virtual machines for easier beta-testing now I've hacked the BIOS/NVRAM and enabled hardware VT, so its all good fun
* mjg59 implements runtime synaptics configuration
<LaserJock> that sounds nice
<mjg59> Well, it deals with some stupid number of unhappy people
<LaserJock> I just use what I'm given
<Husio> hello
<Husio> I have simple question about bazaar: If I've just merged some files and I don't want to commit changes of that merge.. what should I do?
<gnomefreak> Husio: just commit them locally
<gnomefreak> Husio: dont push them
<gnomefreak> Husio: you can use bzr uncommit <#> at any time, when using bzr bd is really only time you need to commit but that still doesnt mean push
<Husio> ok, thanks :)
<gnomefreak> bzr merge than fix conflicts than bzr resolve
<gnomefreak> that should fix issues than just bzr commit if you plan on building with bzr bd
<Husio> heh, another bug or I've done something wrong :>
<gnomefreak> Husio: best place for bzr is #bzr, i just use it alot more than i wish i did
<siretart> has the publisher been stopped? I'm waiting for over 3 hours for a confirmation of my latest 2 uploads...
<pygi> siretart, gnomebaker with cdrkit support is out
<pygi> but I see ubuntu is recommending cdrtools now xD
<siretart> pygi: it is?
<pygi> siretart, that's what I gather from recent happenings and mails in my inbox =)
<siretart> aha
<pygi> but oh well
<Riddell> siretart: "IOError: [Errno 13]  Permission denied: '/srv/launchpad.net/ubuntu-security-queue/incoming/.lock'" looks a bit broken
<siretart> Riddell: oh. I assume that no reupload is necessary then, right?
<Riddell> siretart: shouldn't be
<siretart> ok. thanks for notice!
<LaserJock> with the new default directories is it possible to turn some off?
<LaserJock> like I don't need Public and Templates
<alex-weej> it's occurred to me that apport hasn't caught a crash for donkeys
<alex-weej> is there some setting to get it to catch segfaults?
<`23meg> LaserJock, http://www.freedesktop.org/wiki/Software/xdg-user-dirs says you can turn the whole thing off, or change the names of the dirs
<`23meg> but it may be outdated; take a look at the config files
<ashridah> Hey. Testing out the packages for pidgin 2.2 that just went into gutsy. It won't allow msn or gtalk protocols to work, because of a missing SSL library, but i can't see which ssl library it'd be referring to, since libssl is installed, and nothing's suggested. known?
<ashridah> aha, seems to require nss
<pochu> maybe libnss3-0d
<ashridah> yeah, that's not it, that's installed.
<ashridah> ldd /usr/lib/purple-2/ssl-nss.so is referring to packages that are in firefox, but aren't in the linker path
<ashridah> so, libnss3.so => not found, libsmime3.so => not found libssl3.so => not found libsoftokn3.so => not found
<ashridah> yep, using export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/firefox/ worked, so something's changed in firefox or something, it would appear
<ashridah> hrm, no, that hasn't changed in a while, just pidgin not finding them
* ashridah files bug
<pygi> siretart, ping!
<`23meg> ashridah, are you sure it's pidgin 2.2? it's just out and isn't in Gutsy as far as I can see
<ashridah> hm.
<ashridah> actually, i may well have picked up a version from some other repo
<ashridah> haha. yep. oops :)
<ashridah> thought i'd taken that out ages ago
<Chipzz> version of pidgin in gutsy is 1:2.1.1-2ubuntu2
<Chipzz> ashridah: you can check by doing apt-cache policy pidgin
<ashridah> hm, didn't know that one.
<ashridah> yeah, i'm dropping the foreign pidgin now
<ashridah> mm. bug's gone
<`23meg> FFe bug to get 2.2 in Gutsy: https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/139686
<ubotu> Launchpad bug 139686 in pidgin "Pidgin 2.2.0 in Gutsy" [Undecided,New] 
<`23meg> you may want to help with testing
<ashridah> heh, i thought i was originally. I may take a look, but i suspect it was just the third party package i was using
#ubuntu-devel 2008-09-08
<ScottK> Ampelbein: See http://tinyurl.com/6jjs2k
<Ampelbein> ScottK: ah, ok. thanks for the hint.
<ScottK> You're welcome.
<RAOF> TheMuso: Ping, re bug #182731 and my patch attached to the Debian bug.
<ubottu> Launchpad bug 182731 in alsa-plugins "Provide a lib32asound2-plugins package" [Wishlist,Confirmed] https://launchpad.net/bugs/182731
<TheMuso> RAOF: Let me catch up on email first, then I
<TheMuso> RAOF: Let me catch up on email first, then I'll take a look./
<RAOF> TheMuso: Thanks.  I should have though of it earlier in the dev cycle, but it's only just popped back into my bugmail.  I'd basically like your opinion on whether it'd be worth a FFe.
<TheMuso> RAOF: Ok.
<RAOF> Is the gcc buildd breakage fixed?  It seems gtk-nodoka-engine got hit on ia64 and hppa.  The mail to ubuntu-devel seems somewhat ambiguous to me on this point.
<TheMuso> RAOF: With your pulseaudio oddities, are you using kernel 2.6.27-2-generic?
<RAOF> TheMuso: Yes.
<TheMuso> RAOF: And how did 0.9.11 go in comparison? Added to that, have you considered trying pulseaudio git master?
<RAOF> 0.9.11 introduced the pops & craziness; 0.9.10 worked fine.
<RAOF> I haven't tried pulseaudio git; I will if you like (once internet exists at home again).
<RAOF> I also haven't tried alsa/alsa-lib git.
<RAOF> (Although crimsun suggests that alsa git should fix it).
<TheMuso> Right, I saw that. I'll checkout the latest alsa-lib git commits and see if I can find which one it is, and make a package for testing.
<TheMuso> If not upload the aptch directly to intrepid.
<RAOF> TheMuso: Did you have any thoughts on the "make libasound-plugins generate libasound32-plugins" patch?
<TheMuso> RAOF: Still not there yet. I am still processing bug mail.
<TheMuso> Mail processing alone has tgaken me all day so far, due to having a week off, and having to catch up.
<RAOF> Aaah, of course!  You're back from holday!
<RAOF> Sorry for adding to the pile.  Feel free to ignore me for a while :)
<RAOF> (I trust your week off was fun/relaxing/profitable/enjoyable)
<ajmitch> he probably spent the week thinking about bugs
<TheMuso> RAOF: Very refreshing mentally, yes indeed.
<RAOF> Good to hear.
<TheMuso> ajmitch: I actually managed to spend the week not thinking about work, which was my aim. :p
<ajmitch> TheMuso: well done, I'm impressed :)
<TheMuso> ajmitch: Its not that hard really. Just don't check ubuntu related email, and get off IRC.
<floam> jdong: google implies you know the answer to a question of mine: http://209.85.173.104/search?q=cache:W07g0VIiRf4J:irclogs.ubuntu.com/2006/12/05/%2523ubuntu-devel.html+ubuntu+%22amd64+to+x86%22&hl=en&ct=clnk&cd=9&gl=us
<TheMuso> slangasek: Thanks for the heads up on the debian dmraid work. I was actually going to send my changes to them this week, but they beat me to it. I'll work with them now to get the code usable etc.
<floam> jdong: basically, how would one trick ubuntu into letting me reinstall all my pacakges as x86 if I'm on an amd64 install?
<RAOF> floam: I believe the answer is 'dpkg --get-selections > pkglist', followed by debootstrapping an IA32 install, followed by 'dpkg --set-selections < pkglist'.
<floam> RAOF: thanks.
<floam> RAOF: shall I manually remove packages that exist only in amd64 like "lib32gcc" from that list?
<floam> or will dpkg --set-selections not freak the heck out?
<RAOF> I don't believe that dpkg --set-selections will freak out, no.  It just won't be able to install it.
<RAOF> Note that I haven't actually _performed_ this proceedure at any point; I'm quite happy with my x86-64 install.
<floam> I would be, but this is an install on a 64MB VPS, and I kind of didn't think of the RAM ramifications of 64bits when I first installed.
<floam> heh, RAMifications. sorry.
<RAOF> Yeah.  More general purpose registers probably doesn't offset doubling the size of all your pointers ;)
<floam> ok, here it goes. I'm going to prey debootstrapping a mounted / doesn't cause fire.
<floam> RAOF: hm, I'm not sure it worked.
<floam> no errors, and debootstrap sure did a bunch of stuff
<floam> but after --set-selections nothing appears to want to be done if I apt-get install, and it's definitely not already occured
<floam> /sbin/init is x86-64, and anything else I check.
<floam> and it's going for amd64 debs even if I --reinstall something.
<floam> (I did a sudo 'debootstrap --arch=i386 intrepid /')
<RAOF> Hm.  I'd've thought that would have worked.
<floam> hmmm
<floam> apt-get clean might have changed the situation
<floam> it's now going for i386 if I reinstall something.
<floam> but it's still not wanting to do that all on it's own.
<StevenK> Into / ?
<StevenK> Blink
<floam> StevenK: yep
<RAOF> Heh.  "aptitude reinstall ~n"!
<floam> it's kind of okay if everything breaks, since I'd have to reinstall anyways to get what I want.
<StevenK> That's .... insane
<floam> RAOF: it sure got a big list of stuff to reinstall together
<floam> but
<floam> : I wasn't able to locate file for the libgpmg1 package. This might mean you need to manually fix this package.
<lifeless> floam: please, never ever ever write docs for ubuntu. thanks.
<floam> I guess that might mean it was something that was amd64 only, so I can nuke it
<floam> lifeless: I'd never dream of it.
<floam> nuking worked and it's going.
<floam> RAOF: it fetched a lot of stuff but "E: Couldn't configure pre-depend coreutils for dpkg, probably a dependency cycle."
<floam> don't think I'm going to nuke either of those.
<RAOF> That seems like a bad plan, yes.
<floam> is there a way to have it just reinstall every package irrespective of deps
<floam> since they shouldn't really matter, since I've got everything that it will end up needing one would think
<slangasek> TheMuso: great :)
<floam> RAOF: I'm doing it manually, I will achieve success at some point, or at least fail honorably
<TheMuso> RAOF: re https://launchpad.net/bugs/182731 I thought you had attached a debdiff/implementation to the bug. I think its worth considering, but it depends on how much work it is to do it.
<ubottu> Launchpad bug 182731 in alsa-plugins "Provide a lib32asound2-plugins package" [Wishlist,Confirmed]
<RAOF> TheMuso: There's a debdiff attached to the Debian bug.
<RAOF> TheMuso: Sorry, I obviously didn't make it clear.
<TheMuso> RAOF: NP, I'll dig that up.
<RAOF> I _think_ it applies directly to the Ubuntu package, too, but I can't test it until my internet works again!
<StevenK> RAOF: You say, connected to IRC.
<RAOF> ...At Uni.
<RAOF> I'm not entirely sure they'd be happy with me bootstrapping an Intrepid chroot and going buildd-crazy.
<StevenK> RAOF: Why not? It's like, what, 100MB? :-)
<ajmitch> would only take a few minutes to build
<RAOF> Other impediments include: no root access.
<lifeless> RAOF: clearly, you should leave uni :P
<StevenK> RAOF: fakechroot :-P
<TheMuso> RAOF: It wouldn't apply, as alsa-plugins in intrepid is now 1.0.17. You would also have to drop the jack build-depend.
<TheMuso> RAOF: Without testing myself however, does any of the resulting new binary packages depend on ia32-libs?
<floam> RAOF: .. and at some point through this, the system is back to trying to use amd64 packages. I think I'm going to have to reinstall from scratch and give up.
<pitti> Good morning
<StevenK> Morning pitti
<RAOF> TheMuso: I think they would, actually.  Yes.
<TheMuso> Well then its no go, as ia32libs is universe.
<RAOF> Arse.
<TheMuso> Unless we split out new 32-bit packages for all pieces that ia32-libs is needed for.
<StevenK> I can't see that getting promoted, either
 * TheMuso agrees with StevenK.
<RAOF> To be useful we'd need a libpulse32 at least.
<TheMuso> RAOF: Yeah. This is something to consider for intrepid+1 though perhaps...
<StevenK> Unless TheMuso and I fly to Germany and threaten pitti with grevious bodily tickling until he gives in, or something.
<RAOF> TheMuso: Right.  Or when magical dpkg fairies make no-change multiarch a reality.
<TheMuso> StevenK: I'm of the opinion we just make bi-arch packages for the bits we need, like what RAOF is proposing re alsa-plugins.
<TheMuso> But even so, thats for next cycle,.]
<TheMuso> Morning pitti.
<pitti> wow, no dist-upgrade today?
<pitti> oh, broken gcc, right :/
<RAOF> That's not fixed yet?
<TheMuso> RAOF: No.
<RAOF> Bummer.  It has, however, lead to my discovery of the "retry" button in launchpad.
<pitti> hi tkamppeter
<tseliot> hi pitti
<tseliot> did you have a look at my 2 new branches for jockey?
<pitti> hey tseliot; not yet, last week I got again too distracted, but working on jockey this week
<tseliot> ok
<tseliot> pitti: BTW part of the code (x-kit, the recommended version) is already being tested in envyng 2.0 in Intrepid.
<pitti> tseliot: right, and also from the screen size configuration applet, right?
<tseliot> pitti: yes. right
<pitti> it's also in main since last Thursday or so, so we can use xkit in j now
<tseliot> yes, it's great news
<tkamppeter> hi pitti
<dholbach> good morning
<quadrispro> hi
<quadrispro> anyone on bug #257215?
<ubottu> Launchpad bug 257215 in fop "Please add dependency on ant-optional" [Undecided,Confirmed] https://launchpad.net/bugs/257215
<cjwatson> liw: python-fstab> you seem to have everything in the .orig.tar.gz, resulting in "dpkg-source: warning: diff `./python-fstab_1.2-0ubuntu1.diff.gz' doesn't contain any patch". Is that deliberate or should it just be packaged as a native package?
<liw> cjwatson, er, it should be packaged as a native package... I'll see to it, thanks
<cjwatson> liw: debian/copyright is inconsistent (v2 vs. v3)
<cjwatson> liw: otherwise it's fine, let me know when that's fixed in bzr and I can sponsor it straight from there
<liw> hm, my build automation can't handle native packages, I thought I'd fixed that
<mdz> pitti: do you happen to know what's likely to have broken thinkpad hotkeys in intrepid?
<liw> oh, the version number is not one for native packages, that's why
<pitti> mdz: no idea, I'm afraid; hal and hal-info only changed marginally; are they controlled directly by the kernel?
<mdz> pitti: they used to generate acpi events via thinkpad_acpi
<pitti> right, just found /usr/share/hal/fdi/information/10freedesktop/30-keymap-module-thinkpad-acpi.fdi
<mdz> pitti: ought they to show up in lshal -m?
<sladen> some thinkpads do, some don't.  There's 3 levels of fall-back; however RH were superseding that with a HAL replacement
<mdz> hmm, no, apparently not
<liw> cjwatson, pushed the copyright change to bzr; will you build the whole source package from there, or shall I create a new tarball and dsc?
<pitti> mdz: I really don't know, never had a thinkpad
<mdz> the one which does work (the soft RF kill switch) doesn't generate an event in lshal -m
<amitk> Why doesn't libgphoto2 install udev rules anymore?
<sladen> mdz: /etc/acpi/events/ibm-wireless is handled by a shell script and doesn't get passed anywhere else
<pitti> mdz: I don't get events for things like volume up/down either, Dells have their own custom smbios wiring for those; I just get lshal events for suspend/resume, lid close, etc.
<mdz> I do see hal-addon-acpi read an ibm/hotkey HKEY event from acpid
<cjwatson> liw: I can just change it in bzr, but I'll need you to adjust the changelog too
<cjwatson> err, I meant "build it from bzr"
<liw> cjwatson, I thought I did
<mdz> sladen: how are the others meant to work? via HAL or directly to acpi-support?
<cjwatson> $ bzr up; head -n1 debian/changelog
<cjwatson> Tree is up to date at revision 28.
<cjwatson> python-fstab (1.2-0ubuntu1) intrepid; urgency=low
<liw> cjwatson, I didn't change the version, though
<cjwatson> liw: I meant that it should be something that's right for native packages
<liw> cjwatson, oh, right -- something (lintian?) complained when I had it as a native package, but you're right, it should be one
<liw> (or rather, it should not be one, actually, but that's a bigger change)
<sladen> mdz: I'm not sure of the status;  acpi-support was supposed to be going away to be replaced by big-shiny-sledgehammer-solution (HAL).  I don't mind other distros doing the work, but it would be good if the replacement worked
<sladen> mdz: got frustated/lost interest
<cjwatson> liw: right, should be properly either one thing or the other :)
<mdz> volume keys still work without acpi-support, so that seems to be handled by something else now
<mdz> the wifi kill stops working though
<liw> cjwatson, I'll make it properly non-native, if you can wait a few minutes
<sladen> mdz: the volume keys are in hardware
<cjwatson> liw: sure, thanks
<mdz> sladen: what causes them to pop up the volume meter?
 * StevenK gently prods pitti to do some NBS work.
<liw> cjwatson, ok, done; I split the .deb packaged version into its own branch (.../python-fstab.deb-packaging); I'll upload to REVU, so you can use the same .orig.tar.gz as I have, if that's ok?
<sladen> mdz: recent thinkpads; ACPI events; older/fallback is (was) via the NVRAM listener, with both getting converted to keystrokes and ejected.  The keystrokes are listened for by gnome-volume-manager which deisplays the change
<sladen> s/gnome-volume-manager/g-s-d/
<sladen> s/ejected/injected/
<mdz> sladen: my sleep button is handled by sleepbtn.sh which uses acpi_fakekey which seems to have no effect, even when gnome-power-manager is running
<StevenK> pitti: evince-gtk-dbg evince-gtk libgucharmap6 can all be killed.
<sladen> mdz: sleep button is a standard ACPI event;  it'll work without any special thinkpad_blah extras
<sladen> ..or not
<mdz> pitti: does your sleep button work?
<pitti> mdz: yes, perfectly, both the lid and the button itself
<pitti> RFKill, too
<pitti> StevenK: right, and I'll kill the empty ones while I'm at it
<StevenK> pitti: \o/
<mdz> pitti: this has all regressed for me in intrepid and I'm trying to work out why
<cjwatson> liw: ok, sure
<pitti> mdz: just for testing, could you boot with the hardy kernel and see whether it makes any difference? to check whether it's an user or kernel land problem?
<mdz> I think the primary reason is bug 260314, but even when I manually run g-p-m it doesn't work
<ubottu> Launchpad bug 260314 in gnome-power "gnome-power-manager frequently crashes with SIGSEGV in IA__g_closure_invoke() or g_closure_invoke()" [Unknown,Fix released] https://launchpad.net/bugs/260314
<sladen> rfkill on thinkpads is entirely soft (doesn't even yank the USB).  rfkill on most other laptops is hard for either the USB bluetooth and/or the rfkill on the wifi card
<mdz> sladen: mine has two (a hard switch and a soft key)
<mdz> the soft key seems to only affect bluetooth and 3g, while the hard one kills wifi as well
<sladen> mdz: the Fn-F5
<slangasek> mdz: the soft key not affecting wifi looks like a regression due to a kernel change
<slangasek> because /sys/class/net/wlan0/device/rf_kill no longer exists for iwl3945, at least
<pitti> oh, I thought that would be a network-manager problem, it stopped working properly as soon as we switched to 0.7
<pitti> (had a quick discussion with asac, but no real debugging yet)
<mdz> slangasek: I don't have that either with iwl4965, but I do have /sys/class/net/wlan0/device/rfkill:rfkill5
<mdz> interestingly, if I get gnome-power-manager running, it will sleep on lid close as expected
<mdz> but still will not sleep with the sleep button
<slangasek> yes, that's analogous to what I see; so the interface has changed, I don't know yet if that's intentional
<mdz> who's supposed to hear the sleep button if not g-p-m?
<sladen> mdz: you may have to configure g-p-m with what action it should take on SLEEP prss
<slangasek> acpi-support did at least /have/ code at one point to suspend iff g-p-m is not running
<mdz> sladen: this worked fine in hardy
<sladen> mdz: Power Management->General->Action->When Suspend button is pressed, do: [. .... ]
<mdz> sladen: 'Suspend'
<slangasek> sladen: which would still be a regression from hardy if it became un-set
<mdz> but pressing the sleep button doesn't generate any activity in g-p-m --verbose
<sladen> HAL was set to call pmi on Ubuntu;  did pmi get replaced with one of the other suspend frameworks?
<sladen> but you're not even seeing the D-Bus call go out from g-p-m to HAL
<sladen> mdz: do System->Quit...->   do you get shown the Suspect option, as g-p-m queries for the available capabilities an if you get a timeout g-p-m won't have a positive assertion that the suspect capability is avilable to be called
<liw> cjwatson, it's now in REVU: http://revu.ubuntuwire.com/details.py?package=python-fstab
<slangasek> currently, I get ACPI events from Fn-F[1-3] and Fn-F[5-9].  Fn-F4 is the 'sleep' button; I assume it generated an ACPI event in hardy, but don't know for sure
<mdz> sladen: running /usr/lib/hal/scripts/linux/hal-system-power-suspend-linux manually does work (though the -hybrid- version doesn't, I'm not sure which is actually called)
<slangasek> and the 'power' button doesn't generate an ACPI event
<mdz> sladen: we don't have Quit at the moment in intrepid; we have the old upstream gnome logout/shutdown dialogs
<mdz> neither shows sleep/suspend for me
<mdz> ah, shutdown shows it iff g-p-m is running
<pitti> slangasek: yes, hal has used pm-utils since at least hardy
<slangasek> I think that was meant for the other sla? :)0
<pitti> erm, sladen ^
<sladen> mdz: sorry, yes, my Intrepid laptop install failed a month ago and I grapped other one when leaving a month ago
<seb128> mdz: no, we have the new upstream dialog ;-)
<pitti> slangasek: yes, ETABDISEASE
<pitti> seb128: btw, I find that much more pleasing already than the old upstream one; up to the point where it is actually *bearable* :-)
<mdz> seb128: oh, i don't yet
<seb128> mdz: maybe you didn't restart your session since the update?
<mdz> seb128: btw bug 260314 seems to be fixed upstream, is there a new tarball available with the fix?
<ubottu> Launchpad bug 260314 in gnome-power "gnome-power-manager frequently crashes with SIGSEGV in IA__g_closure_invoke() or g_closure_invoke()" [Unknown,Fix released] https://launchpad.net/bugs/260314
<seb128> pitti: good ;-) we could get a variant listing all the action using this model
<mdz> seb128: probably not, no
<mdz> this session started 2 sep
<pitti> seb128: that would get too big then again IMHO (7 buttons)
<seb128> mdz: ted is supposed to working on the update, I'll ask him when he's around
<seb128> mdz: right, might still be using the old dialog then, the new gnome-session has been uploaded the same day
<cjwatson> liw: and r29 of python-fstab.deb-packaging?
<seb128> pitti: right, depends if we want all the actions on one dialog
<pitti> seb128: well, you know my opinion :)
<pitti> seb128: but anyway, I think mpt should have the say here
<seb128> right
<liw> cjwatson, that's the right one, yes
<pitti> StevenK: NBS slaughtered
<StevenK> pitti: \o/
<cjwatson> liw: uploaded
<pitti> StevenK: your's, libsmbios{1,xml1}, the empty ones, and linux*
<dholbach> soren: I think I have bad news for you: http://paste.ubuntu.com/44484/
<StevenK> pitti: I suspect the list needs a regen after the next publisher run?
<pitti> yes
<dholbach> (hardy amd64 host, intrepid guest)
<liw> cjwatson, thank you
<slangasek> seb128: while we're on the subject, have you seen bug #267018? :)
<ubottu> Launchpad bug 267018 in gnome-settings-daemon "regression: g-s-d no longer handles Fn+F7 as xrandr --auto" [Low,Confirmed] https://launchpad.net/bugs/267018
<seb128> slangasek: didn't before now but I'll have a look, thanks for the bug report ;-)
<slangasek> great, thanks. :)
<slangasek> I investigated it as far as I could, but I don't know how hal is supposed to pass the key from acpid to g-s-d so couldn't check if it was working right
<seb128> oh, buildds are broken right, going to be fun to upload the new GNOME today
<pitti> seb128: well, we'll need a giant give-back-everything anyway
<pitti> doko: btw, I think I can get you an affected buildd chroot, if you need it for investigation?
<mdz> seb128: ok, meanwhile I've backported that one fix because it's crashing for a lot of people and generating dupes
<seb128> mdz: please upload, thanks ;-)
<mdz> seb128:   gnome-power-manager_2.23.6-0ubuntu2_source.changes: done.
<seb128> cool
<seb128> pitti: does suspend work for your D430 currently on intrepid?
<pitti> seb128: yes
<pitti> seb128: however, I remember BenC saying that 2.6.27-2 has a major regression, and that it is fixed in the coming -3 upload
<seb128> ok
<pitti> (regression in suspend)
<pitti> was blocked by a5
<seb128> it doesn't for me, it blank the screen but doesn't power down
<seb128> and doesn't wake up either
<soren> dholbach: Dear, oh dear. How did you do that?
<mdz> the kernel part works fine for me, it's just harder to trigger without the sleep key working :-)
<pitti> seb128: sudo pm-suspend works?
<dholbach> soren: booted it up, started an upgrade
<dholbach> soren: didn't do much
<seb128> pitti: I'll try in a bit
<mdz> pitti: when you press your sleep button, do you see output in gnome-power-manager --verbose?
<pitti> mdz: yes, http://paste.ubuntu.com/44488/
<soren> dholbach: "it"? :)
<mdz> pitti: ah, so the event is coming from hal
<dholbach> soren: I the intrepid guest
<dholbach> s/I//
<pitti> 11:02:24.277: computer_logicaldev_input_1 condition ButtonPressed = power
<soren> dholbach: Ok. Hardy host, still?
<pitti> mdz: ^ lshal -m for power button
<dholbach> soren: yeah
<mdz> pitti: is your power button set to suspend or something?
<pitti> mdz: it triggers the logout/switch user dialog
<pitti> just like ctrl+alt+del
<mdz> pitti: oh, I am talking about the sleep button (moon symbol) which is supposed to suspend immediately
<pitti> (which is wrong, it should trigger the shutdown/reboot/suspend dialog)
<pitti> mdz: oh, I pressed the hardware power button
<pitti> mdz: ok, trying
<mdz> I would think that with evdev, this would actually have a *better* chance of working but it seems not
<pitti> mdz: I see an applet for switching off, but not one for suspend?
<mdz> pitti: applet?
<pitti> mdz: well, which moon symbol do you mean then?
<mdz> pitti: the one on the keyboard
<pitti> oh, that
<mdz> pitti: on my F4 key, there is a blue moon, and Fn+F4 in hardy put the system to sleep
<mdz> pitti: sorry, I should have said key rather than button
<pitti> mdz: right, I tend to forget about it, I mostly work docked with my kinesis :) trying...
<pitti> mdz: however, in ealier verrsions, the moon was hibernate (since suspend is already lid close)
<pitti> trying, brb
<mdz> pitti: I have a separate key for that
<pitti> mdz: right, confirmed; moon (Fn+F1 for me) does nothing, no gpm output either
<mdz> pitti: do you know if it worked in hardy?
<pitti> mdz: and Fn+F3 (battery status) doesn't work either any more (worked fine for hardy)
<seb128_> pitti: suspend seems to work today
<pitti> mdz: yes, definitively worked in hardy (both keys)
<mdz> pitti: I think evdev has broken this, but I'm not sure where to file the bug (hal-info?)
<seb128_> I've sometime the boot stopping on a corrupted flashing screen, does anybody knows what information could be useful for a bug report?
<slangasek> evdev has also toasted my media keys, and my compose key :/
<pitti> hm, I don't know about the evdev plumbing either, so it's as good as any for a starting point
<pitti> mdz: watching hal in debugging mode might probably help, too
<pitti> if hal reacts to the key, it sounds like hal-info problem; if nothing triggers hal, it's a lower-level -evdev problem
<pitti> seb128: through normal lid close and g-p-m, too, or just with sudo pm-suspend?
<seb128> pitti: I tried pm-suspend and then the gnome dialog
<pitti> great
<mdz> pitti: [5352]: 10:12:24.864 [D] addon-acpi.c:195: event is 'ibm/hotkey HKEY 00000080 00001004
<lool> Hmm would someone be so kind to lookup why linux-lpia wasn't accepted yesterday evening and during this night?  I tried pushing it twice from remote hosts, but I realize the process to prepare the .changes was special
<mdz> lool: if you didn't get an email, I think you need to ask the soyuz team
<lool> mdz: I didn't; will do thanks
<pitti> mdz: ah, a sign of life at least
<mdz> pitti: however I know acpi-support is converting that into an input event
<mdz> and I don't see anything receiving that
<mdz> I think this all supposed to work through standard evdev events
<pitti> how do those look like? (I don't know evdev at all, I'm afraid)
<mdz> pitti,slangasek: the closest bug report I've found so far is bug 258177
<ubottu> Launchpad bug 258177 in ubuntu "Special keys (dim display, lock screen) don't work anymore on intrepid wiht my X61s" [Undecided,New] https://launchpad.net/bugs/258177
<mdz> but that might be bug 255008 in disguise
<ubottu> Launchpad bug 255008 in xorg-server "Up arrow key mapped to Print [screen]" [High,Fix released] https://launchpad.net/bugs/255008
<mdz> shall we open a new bug report about ths and figure out where to put it later?
<pitti> sure, as a place to collect all the debug info so far
<mdz> pitti,slangasek: bug 267682
<ubottu> Launchpad bug 267682 in ubuntu "Hotkeys no longer working in Intrepid (evdev?)" [Undecided,New] https://launchpad.net/bugs/267682
<cjwatson> linux-lpia> sorted elsewhere
<cjwatson> classic "unsigned .changes => no mail telling you it went wrong"
<lool> I generated the checksums by hand and signed the .dsc then updated the .changes then forgot to sign it ah it's really to hard by hand; I should write some helper to do this
<lool> Simply the reverse of debrsign
<lool> cjwatson: thanks again
<StevenK> lool: It needs a --backward option? :-)
<pitti> lool: debsign -r ?
<pitti> lool: works fine for me
<lool> pitti: Oh yeah, that's more like it
<lool> Keybuk: Hey, we have a couple of issues with the upstart script we are using the start the Xorg session in ubuntu-mid images; the first issue is that when we moved to intrepid, startx would fail if called directly because the xinit "was this called from console" check was failing, this was solved by prepending the command with openvt; now the issue is that upstart seems to spawn multiple of these
<lool> currently it's exec openvt -w -s -- su -l ubuntu -c "startx -- -br"
<Keybuk> err, I don't know anything about the first one
<Keybuk> that sounds like xinit/startx voodoo
<Keybuk> and I've _never_ understood why there are so many ways to start /usr/bin/X
<lool> Keybuk: Could it be that the upstart behavior with vts / consoles changed slightly?
<Keybuk> if Upstart is spawning multiple, it sounds like your command is exiting?
<Keybuk> Upstart doesn't really *have* any "behaviour" in this regard
<Keybuk>        -w     wait for command to complete. If -w and  -s  are  used  together
<Keybuk>               then  openvt  will  switch back to the controlling terminal when
<Keybuk>               the command completes.
<Keybuk> sounds like openvt exits in the foreground ;)
<Keybuk> can you really not start x from /dev/console?
<lool> Yeah, I suggested -e instead of -w, but wasn't sure whether upstart was happy with that, but I guess it would be
<Keybuk> what is the exact error you get if you just do exec su -l ubuntu -c "startx -- -br" ?
<lool> Keybuk: Perhaps we can, I could try with </dev/console >/dev/console 2>&1
<lool> Keybuk: If we just do this, we see nothing
<Keybuk> lool: stdin/out/etc. should already be /dev/console!
<Keybuk> you have "console owner" in your job file, right?
<lool> Keybuk: One I added /dev/tty redirects, I started seeing the permission check for user is on console thing
<lool> Keybuk: We don't, but I tried using that
<lool> before coming up with openvt
<Keybuk> permission check?
<Keybuk> what does that look like?
<lool> I had to add console owner and dev/tty redirections to see the error spit by xinit
<lool> Keybuk: I mean the "is user on console" Xorg permission check
<Keybuk> how does it check that?
<lool> I didn't look it up, I thought it was looking at permissions of current tty
<Keybuk> there is no current tty
<lool> well the one of startx
<Keybuk> that's what I mean
<Keybuk> upstart doesn't actually activate any ttys
<Keybuk> you're just on /dev/console at that point
<Keybuk> which is whatever that's plumbed into in the kernel
<Keybuk> it's not a tty itself
<lool> Keybuk: So I reverted to console owner + su only (no openvt), the error message displayed in loop after "start session" is "X: user not authorized to run the X server"
<lool> Keybuk: This wasn't the case in hardy, so either Xorg or upstart changed in that respect; perhaps the check was changed
<StevenK> lool: Actually, in Hardy, ume-config-common ran sed on Xwrapper.conf
<lool> StevenK: ahh that explains
<StevenK>     sed -i -e 's/allowed_users=.*/allowed_users=anybody/' /etc/X11/Xwrapper.config
<lool> so we were disabling the security check, nice
<StevenK> Yes.
<StevenK> And you wanted reasons to boot ume-config-common out of the archive.
<lool> Oh the gconftool calls in postinst were good enough for me
<StevenK> Heh
<lool> Ok, so I'm really looking at a problem which exists since gutsy and was worked around by disabling security checks
<norsetto> Any archiver willing to help with bug 263863? It just needs to accept a new binary from hardy NEW.
<ubottu> Launchpad bug 263863 in claws-mail-extra-plugins "Some plugins don't load with the new 3.5.0 version" [Undecided,Confirmed] https://launchpad.net/bugs/263863
<NCommander> hey StevenK
 * StevenK waves
 * NCommander waves back
<NCommander> How goes your $TIME_OF_DAY StevenK ?
 * StevenK is about to cook curry for dinner
<NCommander> Damn, I haven't had good curry in years :-/
<wgrant> NCommander: How do you survive!?
<NCommander> not easily
<lool> Keybuk: The "is user on console" check is a Debian one it seems (xorg/debian/local/xserver-wrapper.c) and is implemented with a fstat on stdin to check whether it's a char device with VT_MAJOR_DEV as major
<lool> Keybuk: I'm not sure /dev/console satisfies, it's major 5 instead of 4
<Keybuk> . o O { xinit-blacklist }
<lool> Keybuk: But we could add support for /dev/console in this Debian wrapper
<Keybuk> that would seem sane
<lool> I first thought it was based on utmp info as login was setting this up before calling into pam, but it seems not
<Keybuk> never rely on utmp ;)
<lool> Yeah utmp stuff is scary
<Keybuk> it's not scary so much as wildly inaccurate
<lool> Like it strips "/dev/" and then "tty" to setup your utmp record
<Keybuk> that's pretty usual
<lool> I find it weird to rely on pathnames
<alien> sabdfl: ping
<Keybuk> utmp dates back to the days when you could trust your fellow users ;)
<lool> Exactly how it feels
<Keybuk> it's from the security thought processes that gave us NFS
<lool> The ordering of calls isn't very paranoiac
<Keybuk> utmp is intended to tell you which user is on which console
<Keybuk> and it's so good at it, and so reliable, it's been reinvented at least twice :p
<Keybuk> (pam_foreground, ConsoleKit, etc.)
<lool> Heh
<lool> bryce: Mind if I push to the ubuntu branch of git.debian.org:/git/pkg-xorg/debian/xorg?
<lool> bryce: Or would you rather review and pull?  I never pushed to the ubuntu branches
 * pochu waves
 * ion_ substitutes pochuâs wave function with one without aliasing.
 * NCommander uses his COM magic to generate a return_wave callback
<pitti> nerds!
<pitti> o/ pochu
<pochu> hey pitti :)
<tjaalton> lool: what do you mean by push?
<lool> tjaalton: to git.d.o/git/pkg-xorg/debian/xorg.git (ubuntu branch)
<tjaalton> lool: you have changes?
<lool> tjaalton: git.debian.org:~lool/public_git/pkg-xorg/debian/xorg
<tjaalton> cool, I'll have a look
<lool> I'm discussing with jcristau (hey) whether it would make sense to merge in the Debian branch
<lool> tjaalton: When building the ubuntu branch, I get ./debian/changelog.Debian.old: no such file or directory; is this something missing from git, or shall I be running something before building this branch?
<lool> It's mentionned in debian/x11-common.install
<doko> pitti: now that infinity is around, maybe it is more straight forward to have a look at the buildd
<tjaalton> lool: seems like it was dropped recently
<tjaalton> lool: I'm unable to use that repo of yours..
<tjaalton> lool: and the changelog was mistakenly dropped for some reason I fail to see
<ogra> mumble ... evolution doesnt like me anymore :(
<davmor2> ogra: turn your top shelf ornament 20 degrees counter clockwise should work fine then :)
 * ogra tries ... 
 * ogra cries ... now the ornament fell off 
<tjaalton> lool: changelod.Debian.old added back
<ogra> davmor2, it has a print on the back "only turn clockwise" :P
<davmor2> ogra: are you by chance trying imap into an account?
<ogra> no, i subscribed my evo cal to my google cal last friday
<davmor2> ogra: np's turn it 340 degrees clockwise ;)
<ogra> since then i expericence hangs and lockups ... and none of the google appointments show up
<davmor2> ah pass I never got that to work properly so quit :)
<ogra> well, it works for various distro calendars and for the fridge schedule
<ogra> so i expected it to work with my googe cal as well ... but apparently i'm wrong :P
<ogra> *google
<lool> tjaalton: What's the issue with my repo?
<mdz> doko: what is the latest news on un-breaking intrepid builds?
<lool> tjaalton: Oh sorry, handed you a ssh:// link; try with git://git.debian.org/git/users/lool/pkg-xorg/debian/xorg
<tjaalton> lool: yeah, thanks
<tjaalton> lool: but still, it only has the .git directory if I clone it?
<lool> tjaalton: Didn't set a HEAD, you can either check ubuntu or my feature branch
<tjaalton> lool: ah, much better
<lool> tjaalton: There, I've setup a HEAD for you (pointing at ubuntu branch)
<lool> I also pushed the dev-console-support branch if like jcristau you mind the way I merged in ubuntu
<ogra> tjaalton, seems nsc has the same issue as the vga drievr
<ogra> *driver
<ogra> tjaalton, (with Xorg -configure)
<tjaalton> ogra: yes, is -nsc still needed?
<ogra> no idea
<tjaalton> ogra: I know geode doesn't support all hardware yet..
<ogra> we'd need to ask Q-Funk
<ogra> i updated bug 265035
<ubottu> Launchpad bug 265035 in xserver-xorg-video-psb "Xorg -configure breaks on  undefined symbol: xf86GetPciVideoInfo" [Undecided,New] https://launchpad.net/bugs/265035
<ogra> psb doesnt seem to be causing the hang
<tjaalton> -nsc recently got support for pciaccess though, so it's fixed upstream
<ogra> i dont even get any message about it anymore
<ogra> ah
<ogra> needs a sync i bet
<tjaalton> it'll likely get removed from debian ;)
<ogra> -nsc ?
<ogra> i thought that was the new one
<tjaalton> no, -geode
<ogra> wasnt -amd split into -geode and -nsc ?
<tjaalton> ogra: I'm not sure but don't think so
<ogra> i think it was
<\sh> hmm...something seems wrong with the detection of raid controller on HP hw...
<Riddell> mvo: synaptic question, should this work?
<Riddell> gksudo "echo libxine1-ffmpeg i | synaptic --set-selections --non-interactive"
<\sh> I have a p400i and a p800 (additional card)...p400i is the default boot controller regarding the bios...but our kernel just don't want to boot from /dev/cciss/c1d0 (which is somehow the p400i in our kernel)
<ogra> tjaalton, dropping it would mean that we lose all GX1 geodes
<ogra> that would be a pretty bad idea
<ogra> (-geode only suports GX2 and LX)
<ogra> *supports
<tjaalton> ogra: right, so we won't drop it until geode supports those
<ogra> ah
<mvo> Riddell: yes, is it not working for you?
<Riddell> mvo: no, just exits here
<mvo> Riddell: and libxine1-ffmpeg is not already installed?
<Riddell> mvo: nope
<mvo> Riddell: let me check
<mvo> Riddell: its possible that gksudo is playing tricks here, when I run this as regular root it works fine, I check further
<mvo> Riddell: could you please try  gksudo "sh -c 'echo \"2vcard i\"|synaptic --non-interactive --set-selections'" ?
<mvo> Riddell: out of curiosity, what do you need it for?
<Riddell> mvo: that works
<Riddell> mvo: it's for amarok's codec install script
<mvo> cool
<tjaalton> lool: btw, what's the use case for the change?
<tjaalton> s/use case/motivation/
<lool> tjaalton: See also above discussion with Keybuk: when we try to startx from an upstart job in ubuntu-mid images, we fail the "user is on console" permission check
<tjaalton> lool: ah, ok
<lool> tjaalton: This is because stdin/stdout/stderr point at /dev/console, not ttyN
<lool> tjaalton: I don't quite know what the intent of the console check is in startx though; perhaps it's opening too much if we allow /dev/tty?
<StevenK> pitti: Can you please bump the priority of linux-lpia so it builds before the backlog?
<tkamppeter> pitti, I have answered all your stuff about CUPS today in the morning. Did you see it?
<Hobbsee> StevenK: bumped.
<StevenK> Hobbsee: Danke
<Hobbsee> you're welcome
<kwwii> pitti: Andreas and lots of others have suggested using a newer snapshot of the murrine engine which apparently fixes bugs
<kwwii> pitti: the original snapshot I made was just a random day early in the cycle
<pitti> tkamppeter: yep, saw it, thanks! the only missing thing is re-proposing the (recommended) patch upstream, other stuff was settled
<pitti> StevenK: done
<Hobbsee> pitti: i presume you've got a fixed version of buildd.py somewhere, that lets you rescore?
<pitti> Hobbsee: I didn't touch it in weeks
<pitti> it just works
 * norsetto hugs doko
<pitti> kwwii: sure, if you tested it and it works well
<Hobbsee> pitti: strange - 'im not sure if it does, as i just manually rescored them.  And i bumped the prio's before via buildd.py, but nothing happened.
<pitti> I'm off for a long phone call
<tedg> Should debian/change log be chronological or sorted by version number?
<Hobbsee> tedg: uh?...
<Hobbsee> tedg: both.  but primarily version #.
<tedg> Hobbsee: So if someone added a patch to an older version, but one wants to merge that patch in, where should that person's changelog entry go?
<StevenK> tedg: One should ignore it, and add a new changelog entry
<Hobbsee> what steve said.
<StevenK> tedg: Also stating the work came from "x"
<Hobbsee> tedg: the idea is that the only changelog entries there are teh ones where the package actually went into the archive.
<Hobbsee> (which then makes the question void)
<tedg> Hmm, but when I've merged stuff from Debian previously I've kept their changelog entires, should I not be doing that?
<tedg> I've kept them, but put them in bellow a top one which explains the complete change.
<Hobbsee> er, excluding debian stuff, then.
<Hobbsee> or where archive = {debian, ubuntu} archive.
<tedg> Hobbsee: Okay, thanks.
<Hobbsee> tedg: y/w
<StevenK> tedg: Sure, but that's merging stuff from Debian which exists in another archive. This is a patch from someone else, which hasn't been seen by either
<tedg> Well, actually in this case the patch was pushed to the archive, but my changes haven't been.  So I think it's clear that I should include their entry, and then view mine as deltas against theirs as users (turns out there are some people who don't follow my PPA) would view it as a change.
<Keybuk>  16:33:30 up 1 day, 19:20,  6 users,  load average: 58.62, 39.70, 19.22
<Keybuk> I need a unicode "eep" character
<vinu76jsr3> I have a jar file and I want to convert it to debian package(.deb) what are the steps
<geser> vinu76jsr3: first find the source code for it
<vinu76jsr3> I have the jar file of the app and I created it myself
<vinu76jsr3> so I have .java source also
<geser> vinu76jsr3: then read https://wiki.ubuntu.com/PackagingGuide/ and if you have questions please ask in #ubuntu-motu
<tedg> Keybuk: No, we just need to wait for Intel to sponsor a little line in there "Upgrading to Intel's new 64 core processor will help" :)
<Keybuk> tedg: heh
<Keybuk> I suspect the real problem is that it's a UML
<Keybuk> and the ultrasuperhypermegavisor isn't bothering to give the guest any time
<soren> Keybuk: Linode?
<geser> @archive admins: do we need to sync the last version from debian where the only reason for the upload was to get it moved from contrib to main before we can move it from multiverse to universe?
<Keybuk> soren: Bytemark
<soren> Ah.
<soren> Those things look pricy.
<cjwatson> geser: no
<cjwatson> geser: it might confuse somebody a bit less down the line if we do, but it's not mandatory
 * calc will be uploading OOo 3.0rc1 later today to ppa
<kees> geser: does your experience of 262843 include NFS?
<geser> kees: no, I don't have NFS here
<kees> geser: okay, good -- that removes some variables from the issue.  :)
<geser> kees: I've only seen this happen with 2.6.27-2.3. I currently using 2.6.27-1.2 again.
<kees> geser: ah, interesting.
<tkamppeter> pitti, about the (recommended) patch, I think it will not be possible to convince Mike to revert his step of filtering out (recommended).
<pitti> tkamppeter: are other distros carrying it as well?
<pitti> bye everyone, have a nice evening
 * ogra pokes todays archive admin ... mighty slangasek 
<slangasek> ?
<ogra> slangasek, i'D like to close bug 261873 partially
<ubottu> Launchpad bug 261873 in xf86-input-evtouch "make evtouch devices work with hal-input in intrepid" [High,Triaged] https://launchpad.net/bugs/261873
<ogra> err
<ogra> sorry wrong bug
<ogra> bug 263493 rather
<ubottu> Launchpad bug 263493 in ubuntu "Please package applications from netbook-remix" [Wishlist,Confirmed] https://launchpad.net/bugs/263493
<ogra> three apps are sitting in NEW
<ogra> (window-picker-applet, go-home-applet and maximus)
<slangasek> well, a number of other things are sitting in new ahead of them. :)
<ogra> all had a REVU review and i am the release manager for ubuntu-mobile to allow FFe's
<ogra> (which i did at the bug)
<slangasek> ok
<ogra> oh, did you plan to do more today ?
 * ogra wasnt expecting :)
<un> i dunno if this is a good channel to ask, but my Makefile.am keeps generating a 'dist dist-all' rule when it should be 'dist-all' only... anybody got any ideas, or *channel
<ogra> un, -> #ubuntu-motu might be a better one
<un> ogra: thnks
<slangasek> ogra: hmm?  it's still before noon my time
<ogra> heh, yeah, i need to stop judging by daylight i guess ... dark here
<un> ogra: i think they are busy... do you know of an autotools specific channel?
<asac> cjwatson: does NM detect your driver name with 2.6.27 kernel properly now? or do you still see this "NULL(info.linux.driver)" thing in syslog?
<ogra> un, not really
<cjwatson> Sep  4 11:09:16 sarantium NetworkManager: <info>  eth1: driver is 'NULL(info.linux.driver)'.
<cjwatson> asac: it seems to be *working*, but ...
<un> ogra: thx anyway
<cjwatson> (well, aside from it leaving both eth0 and eth1 up simultaneously)
<asac> cjwatson: damn. so the driver still isnt fixed :(
<asac> cjwatson: is that b43?
<cjwatson> asac: I think this is with wl, FWIW
<cjwatson> 0c:00.0 Network controller: Broadcom Corporation BCM94311MCG wlan mini-PCI (rev 01)
<cjwatson>         Kernel modules: ssb, wl
<cjwatson> b43 may well have been fixed, can't easily tell right now
<un> cjwatson: i just installed b43 from the fwcutter and im wifi'ing right now...
<asac> cjwatson: ok. thanks. do you know what will be the default in intrepid? (me confused about the broadcom mess)
<cjwatson> un: sure, like I say it works
<cjwatson> un: (I'm not looking for wireless help here; this is a continuation of an old exchange with asac)
<cjwatson> asac: I can't swear to the exact state; I suspect it depends on the exact PCI ID
<un> cjwatson: sry...
<cjwatson> un: (the point of wl, BTW, is to get rid of the need for fwcutter)
<un> cjwatson: schweet...
<alex-weej> does anyone know what happened to the multi-arch stuff that was planned for debian? it was my understanding at the time (handful of years ago) that it would be the end of the need for things like an ia32libs amd64 package
<lool> slangasek: When you have some time, I'd like to discuss elisa 0.5.x
<johanbr> cjwatson, asac: Adam Williamson made an interesting point on the bcm43xx list: maybe it'd be possible to cut the firmware out of the wl driver, since that's redistributable and the firmware by itself isn't ?
<cjwatson> I can't say I know any of the details myself
<cjwatson> presumably whether that's worthwhile depends on whether the wl driver is pretty inside
<mnemo> apparently, the old games "heretic" and "hexen" has been released under the GPL now --> http://sourceforge.net/forum/forum.php?forum_id=864305  would be nice to have them packaged in debian/ubuntu
<ogra> mnemo, try #ubuntu-motu ... https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
<un> anyone know of a decent autotools channel?
<torkel> un: you already asked it about half an hour ago
<un> torkel: fine...
<slangasek> ogra, StevenK: the debian/copyright in go-home-applet is wrong, it says GPL v3 "or any later version" and the source only says v3
<ogra> ouch
<slangasek> ogra, StevenK: can I get a reupload with this fixed?
<s0u][ight> hello is there somewhere i can find linux-image-2.6.26-5-generic
<s0u][ight> because it is removed in the intrepid repos
<s0u][ight> and 2.6.27-2-generic refuses to compile compat-wireless
<s0u][ight> or is there someone who could help me with it
<s0u][ight> http://pastebin.ca/1197397
<geser> s0u][ight: LP has it still, you need to dig a little to find it there
<s0u][ight> launchpad?
<ogra> slangasek, is dropping "or any later version" ok for you for now ?
<ogra> cause i know upstream is massively busy :)
<slangasek> ogra: that's what needs fixed, yes
<s0u][ight> someone who knows what the problem is with the error i get
<geser> s0u][ight: my quick guess is that the kernel interface changed in the meantime
<s0u][ight> any suggestion to fix the problem?
<ogra> slangasek, ubuntu2 uploaded
<slangasek> ogra: heh, why not a reupload as ubuntu1?
<ogra> because i want to keep a record of the change :)
<slangasek> ok
<ogra> version numbers are so cheap :)
<s0u][ight> i'm not familiar with launchpad can someone help me finding the image and headers for intrepid 2.6.26-5-
<slangasek> ogra: for maximus, I see several source files with copyright holders that aren't listed in debian/copyright...
<slangasek> ./src/eggaccelerators.c: * Copyright (C) 2002  Red Hat, Inc.; Copyright 1998, 2001 Tim Janik
<ogra> sigh ... i really thought they were proper
<slangasek> ./src/tomboykeybinder.c: * Copyright (C) 2008 Novell
<ogra> ugh
<slangasek> that's, er, roughly half the source code in the package :)
 * ogra grabs source and adds names ... 
<ogra> slangasek, err
<slangasek> ?
<ogra> i'm not sure we look at the same debian/copyright
<s0u][ight> found something i think
<ogra> src/eggaccelerator.{c,h} are Copyright Red Hat, authored by Havoc
<ogra> Pennington and Tim Janik and are under the terms of the LGPL 2 or later.
<ogra> src/tomboykeybinder.{c,h} are Copyright Novell, and are also under the terms
<ogra> of the LGPL 2 or later.
<ogra> thats in debian/copyrght here
<cjwatson> s0u][ight: https://launchpad.net/ubuntu/+source/linux should be a good place to start
<slangasek> ogra: checking again
<s0u][ight> cjwatson, i need binaries :)
<slangasek> ogra: whoops, you're right; sorry
<ogra> :)
<s0u][ight> but found it never mind
<cjwatson> s0u][ight: yes, you can get to it from there. the bit that may not be obvious is that at some point (once you've clicked through to the version you want), you need to select "build for i386" or some such
<cjwatson> s0u][ight: ok
<slangasek> ogra: I don't find it very clear to list the licensing blurbs interspersed between the copyright statements like that :/
<s0u][ight> but i have allready installed 2.6.27 will these 2 conflict
<s0u][ight> meaning with gcc or so?
<cjwatson> they shouldn't
<cjwatson> you can coinstall images and headers of different versions
<cjwatson> in the specific case of the kernel, anyway; that's not true in general
<s0u][ight> do these kernel images and headers need any other dependencies
<ogra> slangasek, yeah, agreed, i'll fix that with the next upload if thats enough for you
<s0u][ight> meaning can i install them just like dpkg -i
<slangasek> ogra: I've accepted it, if you agree that it should be fixed then feel free to do so at any point :)
<ogra> i surely will, its confusing :)
<cjwatson> s0u][ight: if you already have another kernel image and set of headers installed, their dependencies should be sufficient; the dependencies don't change often
<cjwatson> s0u][ight: you may need to grab the corresponding linux-restricted-modules as well if you rely on those
<s0u][ight> cjwatson, yes i was going to download that .deb package too
<s0u][ight> because i installed that one of intrepid's latest too
<s0u][ight> :)
<slangasek> ogra: ok, all three accepted
<ogra> gracias :)
<s0u][ight> cjwatson, is it normal that i only find x86/86_64 version of the kernel headers?
 * ogra sends a hug in slangasek's direction
<s0u][ight> will it cause problems?
<cjwatson> s0u][ight: you're looking on the wrong architecture then, I presume. Yes, it will cause problems
<s0u][ight> :s
<slangasek> ogra: hope that can make it through customs unmolested :)
<ogra> heh
<s0u][ight> can you help me with finding the i386 version
<cjwatson> s0u][ight: start at https://launchpad.net/ubuntu/+source/linux/2.6.26-5.17/+build/693768
<cjwatson> s0u][ight: also https://launchpad.net/ubuntu/+source/linux-restricted-modules/2.6.26-5.12/+build/690347
<s0u][ight> cjwatson, no binaries?
<cjwatson> they're there
<cjwatson> look in the "resulting binaries" column. Yes, you have to follow a bunch of links I'm afraid
<cjwatson> behind those links, there's a "Downloadable files" section
<jpds> Can somewhere remind me where the -dbg builds are?
<s0u][ight> only the headers remained to download :)
<s0u][ight> cjwatson, installing atm :)
<cjwatson> jpds: ddebs.ubuntu.com
<jpds> cjwatson: Thank you very much.
<s0u][ight> cjwatson, while installing the headers i get dependency is not satisfiable
<cjwatson> ok, sorry my prediction was wrong, but you'll need to sort that out on your own system; #ubuntu may be able to offer help
<s0u][ight> but what is wrong?
<s0u][ight> anyway this sucks and i need to go
<s0u][ight> so anyway laters
<cjwatson> the problem you're having with 2.6.27-2 is likely to be best fixed by updating compat-wireless from somewhere, or bugging the ath5k maintainer if there's no update
<cjwatson> rather than by reverting
<Nilbus> I'm the president of NCSU LUG, and we're looking to host linux installfest right after the 8.10 release.  Any idea how early or late in the month that is likely to be released?
<cjwatson> Nilbus: http://wiki.ubuntu.com/IntrepidReleaseSchedule
<s0u][ight> cjwatson, it is the latest compat-wireless
<Nilbus> cjwatson, thank you.
<Nilbus> Oct 30
<Nilbus> so late :P
<jpds> Nilbus: All good things take time.
<Nilbus> :)
<Nilbus> I am excited anyway
<lool> Keybuk: Hmm I finished investigating the other way we were starting the MID desktop (the openvt thing), and using openvt's -e fixed many issues, as you guessed -w was causing forks, but I face a stupid problem:
<lool> Keybuk: the xorg vt is switched to near the end of the boot, I see Xorg starting up, and then I'm moved back to one of the other ttys, presumably because they startup as well
<lool> Keybuk: Nothing particular in syslog, I guess this is just racy; I guess the only option is to explicitely trigger an event after the other ttys are all loaded if that's what I care to keep, to then trigger the xorg session job?
<android6011> how is support for ar5007eg wireless cards coming in intrepid?
<Haegin> suggestion for the next possible version of ubuntu:
<NCommander> Haegin, Jumpy Jackrabbits
<Haegin> when going into recovery mode, don't mount anything other than /boot and / and don't check discs
<NCommander> oh, features ;-)
<NCommander> Not names
<Haegin> no, a feature
<Haegin> thought i would mention it while i wait for ubuntu to finish failing to check my 200GB partition I am currently trying to get to root mode to check
<Haegin> just a good thing it isn't my 500GB drive else I might be here all night
<NCommander> Haegin, you can Ctrl-C the disk check ...
<Haegin> nope
<NCommander> WOrked fine for me the other night
<Haegin> hangs for a moment if i hold the button down but keeps on trucking
<slangasek> Haegin: why should /boot and / be treated differently than the others?  If there's a fs recovery issue, it could be on either of those filesystems as well
<Haegin> ill try the othre 2 keyboards that are pulgged in
<Haegin> slangasek: because you need them to get to the root terminal to fix problemn
<slangasek> you certainly don't need /boot for that
<slangasek> and there are various rescue activities one can do without first mounting / ...
<Haegin> you need boot to boot the system though which is necessary to get to mounting /
<Haegin> slangasek: i don't care if they are not checked
<slangasek> no, you never need to mount /boot as part of the boot.
<Haegin> but /boot and / shouldn't take long anyway to check as they should never be too big
<Haegin> whereas my media drives take forever
<slangasek> well, I think that's an arbitrary line between /boot and $other_filesystems
<Haegin> and are certainly not needed for me to get to the root shell
<Haegin> slangasek: fine, don't check boot
<Haegin> just don't check $other_filesystems either, it is pointless as far as i can see
<Haegin> spending 30minutes waiting for something to fail is annoying to say the least
<slangasek> Haegin: I think the right place where this would need to be changed is in sysvinit; perhaps you could file a bug report?
<Haegin> ok, will do, thanks
<android6011> so noone know anything about ar5007eg atheros wireless support?
<slangasek> android6011: no, at any given moment #ubuntu-devel is not likely to be the right place to ask about support for a particular piece of hardware; you could try #ubuntu-kernel, or else you might want to file a bug report against the kernel (or if one is already filed, subscribe to it)
<android6011> ok thanks
<Haegin> android6011: also try #madwifi for that
<android6011> Haegin: I know there is a working driver, I am just looking to see if it is in interpid at all
<Haegin> android6011: ah, compile it in if it isn't
<android6011> ya i know, i have in several disks, im also just wanting to know for live cd use
<calc> cool! suspend/resume works on my laptop finally on amd64 arch
<calc> just booted up intrepid alpha5, i think i will upgrade to it since i can run amd64 now, whee! :)
 * calc thinks the logout window is a bit of a downgrade from the old one
<calc> all wordy and stuff
<wgrant> The italics and bad icons are particularly odd.
<mathiaz> slangasek: jdstrand told me that you've granted a FFexception for landscape-client.
<slangasek> mathiaz: yes
<mathiaz> slangasek: is there a bug number somewhere ?
<slangasek> no, it was verbal
<slangasek> is that still not uploaded?
<mathiaz> slangasek: ok - I'm about to upload the package
<slangasek> ok, yes please :)
<mathiaz> slangasek: ok. thanks for confirming this.
<slangasek> lool: do we still need to talk about elisa 0.5, if I just approved the FFe? :)
<Laney> Are we getting the Hardy logout window back?
<lool> slangasek: haha well if you'd approve it we'd both skip discussing it :)
<slangasek> lool: ok :)
 * lool hopes the beer / FFEs exchange rate isn't too bad these days
<slangasek> it gets better the more beers I have, right?
<lool> slangasek: For you, yeah
<slangasek> heh
<slangasek> I was thinking supply and demand :)
<lool> seb128: Do you mind if I defer testing and pushing of pango1.0 to tomorrow?  packaging committed, but I'm a bit tried TBH
<seb128> lool: not at all, I'll go to bed soon too, there is still around 18 tarballs to update tomorrow + the new that will be rolled later
<lool> slangasek: thanks
 * lool waves 'night
 * slangasek waves
<seb128> 'night lool
#ubuntu-devel 2008-09-09
<owh> I'm looking at bug #113919 which applies to Hardy - and earlier. The suggested patch to fix is now in Intrepid. I asked on #u-bugs about backporting,  but the wiki indicates that this is probably an SRU, rather than a backport. Any advice?
<ubottu> Launchpad bug 113919 in dosfstools "fsck crashes checking external FAT drive" [Medium,Confirmed] https://launchpad.net/bugs/113919
<StevenK> slangasek: Sure, I'll sort it out
<slangasek> StevenK: ogra already did
<StevenK> That's what I get for living in an .au timezone :-)
<slangasek> shall I find another bug to put you to work on? ;)
 * StevenK is poking at linux-lpia.
<StevenK> Want -lpia metapackages
<cody-somerville> What a useless arch
 * StevenK silences cody-somerville with a glare
<owh> Anyone?
<owh> Not all at once :)
<slangasek> owh: "follow the SRU Procedure"? :) https://wiki.ubuntu.com/StableReleaseUpdates
<owh> slangasek: I read that, but I know that I don't have enough information to build that whole process.
<owh> Or are you telling me to just "jump in"?
<cody-somerville> Well, luckily you don't have to build the entire process - just the package. :p
<cody-somerville> yes!! :D
<slangasek> well, alternatively find someone who does and make them do it?
<cody-somerville> \o/
 * owh volunteers cody-somerville
<owh> :)
<cody-somerville> owh, wadaya want anyhow? : P
<owh> Seriously, I'm happy to jump in, but I thought I'd come and talk to someone before I did.
<slangasek> if the bug is fixed in intrepid, someone must have fixed it there, so they would have the necessary info?
<owh> slangasek: To me it appears as if Intrepid just synched the latest version.
<owh> No bug as such.
<slangasek> ah
<slangasek> well, there was still a bug, even if there wasn't a bug report
<slangasek> (or rather, there was this bug report, but it wasn't linked to the changelog)
<owh> I think I can get my head around that one...
<slangasek> evand: is usb-creator targeting main directly for intrepid?
<owh> cody-somerville: Well, to start with, some winning lotto numbers, then a neck massage, and an SRU for dosfstools, think you can handle it?
<owh> :P
 * slangasek looks up last week's winning numbers, to help out
<cody-somerville> I hear StevenK is good with the neck massages (keybuck swears by them).
<owh> Yeah, but stevenk is on the other side of the country.
<cody-somerville> owh, and where do you think I am? Hint: not under your bed.
<owh> At least it's the same country :)
 * owh hasn't checked of late :)
 * cody-somerville is in Lexington, MA, USA atm fyi
<slangasek> "USA ATM FYI" FTW
<StevenK> Haha
 * owh has stevenk in Sydney.
 * StevenK might, or might not be in Sydney
<owh> Heh
<cody-somerville> owh, Can you file a bug re: your SRU request.
<owh> cody-somerville: I'm following the dot-points in the URL that slangasek indicated, I've just subscribed ubuntu-sru and I'm now updating the bug report description.
<cody-somerville> whats the bug #?
<slangasek> 113919
<slangasek> owh: so you haven't extracted the patch to be included in the SRU yet/
<slangasek> ?
<doko> lool: libmdns -> lib32mdns depends? are you on crack?
<doko> ;p
<owh> slangasek: Well, the patch file is already available via a debian link, but I'll include it.
<owh> I figured that it made more sense to use the current version of dosfstools, rather than a single diff.
<owh> Is that incorrect?
<slangasek> for an SRU, that's incorrect
<owh> Ok, I understand.
<cody-somerville> owh, congratulations, you're correct that you're incorrect
<owh> cody-somerville: :P
<owh> Hmm, the more I think about this, the more I think that this is going to go nowhere.
<cody-somerville> owh, You need to create a patch that specifically fixes the segfault and nothing else.
<owh> cody-somerville: That patch exists in Debian.
<owh> cody-somerville: Mind you, it also "fixes" an if-else into a switch-case.
 * owh thinks I should stop going down the dots, remove ubuntu-sru for a bit and get some ducks lined up first.
<owh> The wiki dot order doesn't seem that correct. Nominate and subscribe before you do any work...
<owh> Is that intentional?
<slangasek> perhaps not
<owh> Or was the intent that you could start the process and run away for someone else to pick up?
<slangasek> we should probably switch 2 and 3 around in that list
<owh> Yeah, that's what I was thinking.
<owh> Done
<owh> Ahh the plot thickens, there is an actual bug that requested the sync.
<owh> Bug #244407
<ubottu> Launchpad bug 244407 in dosfstools "Please sync dosfstools 2.11-5 (main) from Debian unstable (main)." [Wishlist,Fix released] https://launchpad.net/bugs/244407
<slangasek> ScottK: ah, hmm; so in between the clamav sync FFe request and my acking thereof, you did an ubuntu1 upload?
<StevenK> owh: That fixes it for Intrepid, not Hardy
 * StevenK kicks HAL for not mounting USB disks anymore
<owh> StevenK: The SRU process seems to assume that a bug for the development version needs to exist before you can SRU it.
<StevenK> owh: Or is fixed in the development release
<owh> StevenK: Right. It then goes on to say: "update the bug report" [for the bug that is marked "Fix released".
<Keybuk> a.b.c.d - - [08/Sep/2008:19:09:01 -0500] "GET /brainstorm?idea=test HTTP/1.1" 200 55 "http://summit.netsplit.com/uds-jaunty/sponsorship" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008072820 Firefox/3.0.1"
<Keybuk> *sigh*
<Keybuk> SOME people just can't leave things alone :p
<Keybuk> "oh, look, a webapp; I know, I'll take it apart, read the javascript, and attempt to break holes in it" :p
<LaserJock> Jackalope?!
<StevenK> Haha. I was waiting for that.
<LaserJock> that's like so redneck :-)
<owh> Keybuk: "Never attribute to malice that which can be adequately explained by stupidity."
<Keybuk> heh
<Keybuk> yeah I just approved Mark's post
<cody-somerville> lol
<LaserJock> I don't think I ever had one
<LaserJock> but every gas station when I was growing up sure did
<Keybuk> hilariously google managed to leak the code name
<Keybuk> and I have absolutely no idea how
<Keybuk> since it clearly indexed a page almost 30 minutes before it was linked from anywhere
<owh> Keybuk: Perhaps someone read some web-mail with it?
<slangasek> jackalope?  I thought the theme was animals, not characters from bad early 90s shows on ABC
<Keybuk> slangasek: you don't play the second and far more fun game?
<slangasek> hmm?
<Keybuk> not guess what the codename will be, but guess what Mark will have been drinking/smoking/reading/watching when he comes up with it?
<slangasek> oh, I don't play either game. :)
<Keybuk> kinky koala!
<StevenK> I refuse to upload to a release called "kinky"
<LaserJock> jaunty is a bit interesting, I instantly think of jaundice
<LaserJock> the idea of a jaundiced jackalope just isn't really sounding motivating ;-)
<cody-somerville> http://www.engadget.com/2008/03/21/ubuntu-hardy-heron-8-04-released-in-beta/
<slangasek> that's... odd
<cody-somerville> Interesting, someone suggested it Mar 21st 2008 5:02AM
<Keybuk> cody-somerville: it's a common suggestion actually, shows up in the forums
<Keybuk> there aren't many animals or adjectives for j anyway
<slangasek> that thread shows a reasonable number of real animals as options. :)
 * cody-somerville is off to party in Boston :P:
<Keybuk> enjoy
<bddebian> Jumpy Jackrabbit
<LaserJock> Jittery would have been fun
<bddebian> I was thinking that too but couldn't think of an animal :)
<LaserJock> I could have gotten behind Jittery Jackalope
<TheMuso> PulseAudio 0.9.12 just released, and heading to my PPA shortly.
<RAOF> TheMuso: Cool.  That makes it easier :)
<TheMuso> RAOF: Yeah. I'll also pull latest alsa git and see if I can find any fixes relating to pulse there for your issue.
<ScottK> slangasek: Yes, but there was nothing in it that needed to be kept.  Sorry I forgot to update the bug.  The only thing it did was drop Recommends we didn't want in Main and Debian dropped them too.
<slangasek> ScottK: ok
 * cjwatson wonders if this trend for getting some kind of MOTU points for taking a bug with a patch in it and appending a debdiff with that patch plus a changelog entry is really valuable
<StevenK> cjwatson: IMHO, no.
<cjwatson> if you need sponsorship, the patch is going to need review anyway, so are you really adding anything? the work has one bit of informational content, namely "this patch needs to be reviewed"
<cjwatson> I'm concerned that it seems to be ending up as a mechanical patch->debdiff transformation task, when the task of a reviewer should be to sanity-check the patch, argue with its author if necessary, and then upload it if it's good (not just put it through another stage of review)
<jelmer> cjwatson: and forward it upstream?
<jelmer> if applicable, of course
<cjwatson> and all the rest of it, yes
<cjwatson> (do not interpret exclusion from my list as anything other than "cjwatson forgot to mention it")
<jelmer> heh, ok
<owh> I have been given a patch that includes a merge of an if and a switch, which results in an indent change - which in turn obscures an actual code change within the same block. A diff -ruN shows the whole code-block, but a diff -bruN shows the actual code change. Is there a preference or policy which version I should add to a bug?
<cjwatson> mostly I'm worried that there are some people who are wasting their time transforming patches into debdiffs when the developer on the other end would have been perfectly happy with a patch if given time to respond, and a debdiff is no better
<cjwatson> owh: the former if you want the patch to be applyable mechanically; the latter if you want it to be understood by humans. Since it's often desirable to have both facilities, you might just want to attach both.
<owh> Excellent.
<lifeless> cjwatson: I think there is value in having debdiffs; namely that folk that want to test can do so with less knowledge of the package internals
<lifeless> cjwatson: because its a patch against the build system, not the code per se
<cjwatson> lifeless: the target of bug reports is not typically testers
<lifeless> cjwatson: cause or effect :P
<cjwatson> lifeless: let's take bug 267103 as an example
<ubottu> Launchpad bug 267103 in usb-creator "usb-creator FTBFS with "/bin/sh: python2.4: not found"" [High,Fix committed] https://launchpad.net/bugs/267103
<cjwatson> starts off with a suggested patch (incidentally in debdiff form), fair enough
<lifeless> cjwatson: ok, so a FTBFS can be autotested if there is a debdiff patch
<lifeless> cjwatson: whereas a human is required for a non-debdiff patch, with current facilities
<cjwatson> Matt and I review, and I suggest an alternative formulation which is a one-liner and preparing a patch is a waste of time (it'll take the developer as long to download and apply the patch as it would to just change the one word); also I happen to know that the developer is currently working on the package anyway and so a patch is more useful than something that tromps over debian/changelog where they're going to have to ...
<cjwatson> ... resolve the conflict
<lifeless> sure
<cjwatson> the original submitter then reformulates this as a debdiff, whereas in fact this has negative utility
<lifeless> I guess I'm making a philosophical point
<lifeless> as for the debian/changelog conflict, that is surely programtically mergable
<cjwatson> or bug 264471, where Evan submits a perfectly good patch, and somebody transforms it into a debdiff with no additional value
<ubottu> Launchpad bug 264471 in germinate "Typo in germinate.1" [Low,Fix committed] https://launchpad.net/bugs/264471
<cjwatson> lifeless: you are making a number of reasonable points, but none of the qualities you're striving for are ones I think are interesting for Ubuntu bug reports ...
<cjwatson> a human being required to review a patch is a feature
<cjwatson> we do not want to automatically merge patches
<lifeless> agreed; for inclusion to trunk
<lifeless> I'm totally behind that
<cjwatson> I think what you're missing is that many of the cases at hand are utterly trivial
<cjwatson> but because the policy is "prospective MOTUs shall get some changes sponsored, and in order to get a change sponsored there must be a debdiff", there is a deleterious social effect where prospective MOTUs redo other people's work in a different form (adding little value along the way) in the expectation that they'll get credit for it
<lifeless> oh, getting what you measure for
<StevenK> Because a debdiff gives a changelog with the all important their name in it
<cjwatson> whereas, in fact, they have been misled because most developers reviewing their change will see the transformation and note that not much work was involved
<cjwatson> particularly when they are transforming a patch that was already submitted by another developer
<lifeless> This is why I was arguing for a totally social peer-review metric for MOTU readiness back at MV, rather than strongly predefined criteria
<cjwatson> StevenK: *exactly*
<lifeless> because I think its impossible to write good predefined criteria, but totally possible to say to sane folk "Is person X ready"
<lifeless> I didn't realise that that concept had degraded so far :(
<cjwatson> I understand the need to have some mechanical assistance in assessing readiness, since there are a lot of people involved
<lifeless> I don't understand that yet, having followed NM for quite some time
<cjwatson> I found it useful while on the community council to have mechanical metrics for how much people had done as a supplement to comments from their peers
<lifeless> hmm, in the asia membership board we look at what folk have done; I don't have a scale for it though
<cjwatson> I'm not sure this is necessarily a problem with the existence of metrics, though; the problem is that we're suggesting that developers with zero experience should be reviewers
<lifeless> mainly 'lots' vs 'little' and 'trivial' vs 'ongoing'
<cjwatson> whereas, in fact, what we should be doing is advising people to fix bugs all by themselves first, and after they have gained experience (i.e. >= already MOTU) they can help out with reviewing patches from contributors
<lifeless> thats definitely a problem, reviewing is something that takes practice, and knowing whats good vs bad
<cjwatson> exactly
<cjwatson> hmm. I should go back to bed, but thanks for refining my IRC rant :) I may turn that into a mailing list post or something
<owh> I'm looking at a patch and I think there is an error, but I'm not a C++ programmer, so I'm wondering if someone can have a look at this partial diff and tell me that I'm wrong. http://ubuntu.pastebin.com/m217fd2ab
<lifeless> cjwatson: my pleasure :)
<NCommander> cjwatson, I assume you've gone to bed?
 * owh annotated the concerns http://ubuntu.pastebin.com/m32b6d894
<owh> Does my concern make any sense to anyone, or am I just dribbling?
<cody-somerville> That pastebin is useless w/o context.
<owh> cody-somerville: What kind of context is needed for it to become useful?
<cody-somerville> owh, probably the entire sourcefile if not more :P
<owh> The actual diff came from here: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;filename=dosfsck-lfn-3.diff;att=1;bug=152550
<owh> cody-somerville: If I just look at it from an assignment perspective, then is the patch not using the old value for lfn->id ?
<cody-somerville> Maybe thats correct?
<owh> cody-somerville: Well, it changes the code where the only other patches in the code are checks to deal with 0 overflows. It's the only such change and I would expect an annotation.
<owh> But you raise an interesting point, which I had not considered.
<owh> So, I'll go ask the person who added it to Debian :)
<cody-somerville> owh, yea, I'd say it is intentional
<owh> cody-somerville: What makes you conclude that?
<cody-somerville> because all the if statements have been changed to compare against slot instead of lfn->id & LFN_ID_SLOTMASK
<sistpoty> hm... cjwatson raised an interesting point. nonetheless, I believe there's some value in turning a patch into a debdiff, as it jumps the point between just patching and packaging.
<sistpoty> the point not solved imho boils down to what which person did, and hence is technically knowing about s.th.
<owh> cody-somerville: Which is covered by the assignment at the top.
<StevenK> sistpoty: Just adding a changelog to a patch does not mean it's worth brownie points
<owh> cody-somerville: But it's the only place where the meaning changes.
<sistpoty> StevenK: well, kind of with the brownie points. It means adding a meaningful changelog to me (as in what and moreover *why* s.th. was changed)
<cody-somerville> owh, The meaning isn't changing.
<cody-somerville> owh, the patch is correct
<sistpoty> StevenK: nonetheless, I agree that it's only a small piece of a brownie
<owh> cody-somerville: The meaning *is* changing because lfn->id changes.
<sistpoty> and funnily enough, back then when I was just a motu, the review of the dofsck (or whatever it's called, I just don't recall) by owh, is s.th. I consider more worthwhile than any patch in the first place
<cody-somerville> owh, I'm not going to argue with you. If you have any further questions about the patch, ask the author.
<sistpoty> *dosfsck*
<owh> sistpoty: Huh?
<owh> cody-somerville: I will ask the author, but thanks for your eyeballs.
<sistpoty> owh: that was quite some time ago... remember? the infamous bug was that dosfsck shouldn't check anything by default, which lead to two or more bugs uncovered within dosfsck (or was it someone else who finally kept me from proposing a patch that just wasn't wrong)?
<owh> Yup, that was me :)
<sistpoty> heh
<owh> Ah, so that was a compliment :)
 * owh blushes
<sistpoty> owh: see, that was imho a great contribution, much better than turning a patch into a debdiff ;)
 * owh is still partial to dosfsck and still at it :)
<owh> IIRC we both had out boot-prints all over that patch sistpoty :)
<sistpoty> owh: yes, and it was great imho :)
<owh> It fixed stuff and people cheered - all good :)
<owh> sistpoty: I still haven't gotten to the bottom of codepages and dosfsck yet - so if you're bored :)
<sistpoty> owh: sorry... I *do* have a copy of the MS manual about dosfs now (actually since some time)... but I haven't found time yet to go much further than downloading that *g*
<owh> sistpoty: I even got as far as someone giving me a filesystem with a different codepage on it, but I got buried in trying to figure out how to deal with multi-byte characters without my head exploding. Since then it seems to have gotten harder too, someone pointed out that you can change the codepage whenever you want - lovely :(
<sistpoty> heh, sounds like fun :(
<owh> Hey, if I can fix one dosfstools bug per quarter, I'm doing more than most :)
<owh> How do I unsubscribe the ubuntu-sru from a bug?
<ScottK-laptop> You have to be in ubuntu-sru to do it.
<owh> So, I can subscribe them, but not unsubscribe them - joy :(
<ScottK-laptop> Yes.
<sistpoty> owh: yep, long-standing LP bug. thought it was fixed (but must have mistaken it to be fixed anytime soon (whatever that means))
<owh> Heh
<owh> It's good that one of the members of sru was right here encouraging me to "jump in", so I did - we then changed the SRU procedure around a little so we wouldn't subscribe U-sru before documenting the bug :)
<sistpoty> kees: sorry about bug #249936, I wanted to follow up on this with the warning being present for ignoring short writes... sorry for the inconvenience!
<ubottu> Launchpad bug 249936 in glibc "fread declared with __wur (warn_unused_result)" [Low,Invalid] https://launchpad.net/bugs/249936
<sistpoty> (and I agree after having heard more on why the warning does make sense)
<sistpoty> heck, short reads even *g*
<cody-somerville> How would one go about signing a ton of packages via a script w/o having to enter their password for their key a bunch of times?
<RAOF> With gpg-agent, I would assume.
<cody-somerville> RAOF, thanks :)
<NCommander> cjwatson, you around?
<NCommander> Does anyone know if backports are available on unoffical architectures?
<calc> its 6am there so probably not
<calc> and i dunno about the question
<calc> i only use amd64/i386, i have a m68k but its about as useful as a doorstop
<NCommander> calc, you do know I am a debian m68k porter ...
<calc> NCommander: oh, no offense, i have a quadra 840av it doesn't have dma disk support
<calc> NCommander: i can type faster than it can display when its doing disk io
<NCommander> calc, that's being worked on now int he 2.6 branch
<calc> and i can barely touch type ;-)
<calc> cool :)
<calc> i bought it about 8 years ago and maxed it out to 128mb ram but it was just way to slow to do anything with
<NCommander> calc, I plan to port Ubuntu to m68k ...
<calc> good luck :)
<calc> fluxbuntu might work ;-)
 * calc somehow doubts getting gnome onto it will work
<NCommander> Xubuntu is likely
<NCommander> We did build KDE on m68k
<calc> NCommander: oh i'm sure it will all build, just not run fast enough to be usable ;-)
 * calc used to watch the slow kde builds on debian since he maintained kde
<NCommander> calc, well, at the moment, have an interest of getting backports available for PowerPC and the other port architectures
<cjwatson> NCommander: backports are built for all ports
<NCommander> cjwatson, I can't find lpia on us.archive.ubuntu.com or ports.ubuntu.com
<NCommander> oh wait
<NCommander> I'm an idiot :-)
<NCommander> cjwatson, your a kubuntu developer, right?
<cjwatson> look harder ... http://ports.ubuntu.com/ubuntu-ports/dists/hardy-backports/main/binary-lpia/
<cjwatson> NCommander: no
<NCommander> ok :-/. I have a FTBFS for kdenetwork for hardy on lpia
<NCommander> ^fix
<cjwatson> well, I am in the sense that I have upload privileges to all of Kubuntu, but I don't use it
<NCommander> cjwatson, heh, Ok, no problem, I'll just wait for ScottK to reappear
<NCommander> cjwatson, do chroot problems build features (marked as chroot problems) get auto-retried, or does someone need to do it?
<cjwatson> NCommander: I don't think it's automatic, but often enough whoever fixes the chroots just gives everything back
<NCommander> ah
<NCommander> I feel like doing something productive :-/
<NCommander> cjwatson, know any good todos?
<Hobbsee> chroot problems get done automatically, afaik.
<Hobbsee> i think, anyway
<cjwatson> NCommander: I only just woke up, and it's before 6am ... not so much
<Hobbsee> cjwatson: you were meant to answer with all teh work you had to do :)
<dholbach> good morning
<lool> doko: Well I find the rationale for a libmdns -> lib32mdns depends more motivating than the one which pushed for a lib*mdns dep in jdk packages
<pitti> Good morning
<StevenK> Morning pitti
<persia> Good morning pitti.  It was suggested that you might know current practices for update-manager maintenance?  The last update broke update-manager-hildon, and I'm unsure if it's better to fix it now in the source, or wait for a bzr branch to appear.
<lool> doko: (See my email) well I wasn't actually thinking of a depends dep, rather recommends; it's hard to express "if you have libmdns and ia32-libs"
<pitti> persia: hm, I don't have particular knowledge about it; mvo is the maintainer, I think you should talk directly to him
<persia> pitti: Just hoping you might know as it's early yet :)  Thanks.
<persia> mvo!  Good morning.  I've an update for update-manager, but it applies against bzr, and there's newer source in the archives.  If uploading, what's the best way to proceed?
<mvo> persia: update-manager in the archive and in bzr are not in sync ?
<persia> mvo: At least not lp:~ubuntu-core-dev/update-manager/main
 * dholbach can feel mvo's blood pressure rising (and that although he lives 700km away from here)
<mvo> persia: oh, that is bad, let me check how that happend
 * mvo hugs dholbach
<dholbach> :-)
 * persia looks for Riddell
 * dholbach hugs mvo back
<mvo> persia: I really don''t like it when the packages gets out of sync
<persia> mvo: I was thinking that I could pull the current archive source, commit, make my changes, commit, and request a merge.  Would that model make sense to you, or do you seek the detail changes in the current upload?
<mvo> persia: let me please first check what happend
<persia> mvo: OK.  Let me know, and I'll push my changes.
<mvo> Riddell: could you please push your update-manager changes into the  lp:~ubuntu-core-dev/update-manager/main branch (you probably just forgot a bzr push)
<mvo> persia: thanks, where is the branch that you want to be merged? (what location)
<persia> mvo: I haven't pushed yet, because of the confusion.  I'll update the changelog and push now.
<mvo> persia: ok, thanks
<pitti> doko: wow, uploading gcc at 5:40 in the morning? :-)
<pitti> hey seb128
<seb128> hello pitti
<evand> slangasek: yes, I plan to file a MIR in the morning.
<cjwatson> jdstrand: I'd appreciate it if you could have a look at bug 262451 for your next ufw upload
<ubottu> Launchpad bug 262451 in dpkg "dpkg: ../../src/packages.c:221: process_queue: Assertion `dependtry <= 4' failed." [High,Confirmed] https://launchpad.net/bugs/262451
<tjaalton> so what do I have to do to get xserver 1.5.0 accepted?
<cjwatson> tjaalton: file bug describing changes and asking for exception, subscribe ubuntu-release
<tjaalton> cjwatson: k, will do
<tjaalton> cjwatson: I can upload it already so it's ready in the queue?
<Riddell> mvo: update-manager merged
<mvo> Riddell: thanks
<StevenK> mvo: Upload it :-)
<mvo> StevenK: I will, almost ready
<cjwatson> tjaalton: if you upload it, it will go straight through without confirmation (unless it hits NEW for some reason). The archive is not frozen by any technical means
<tjaalton> cjwatson: ok, in that case I won't upload
<tjaalton> if any member of the release team would have a look at bug 268055, I'd appreciate it. all video drivers need to be rebuilt so I'd like to get on with it ;)
<ubottu> Launchpad bug 268055 in xorg-server "Please accept xorg-server 1.5.0-1ubuntu1" [Undecided,New] https://launchpad.net/bugs/268055
<amitk> soren: kvm still crashes when shutting down a VM (windows xp). 6 apport pop-ups come up before it actually shuts down.
<soren> Wow. :)
<amitk> soren: bug #259336
<ubottu> Launchpad bug 259336 in kvm "kvm crashed with SIGSEGV in __libc_start_main()" [Medium,New] https://launchpad.net/bugs/259336
<amitk> soren: anything I can do to help debug?
<amitk> so new kernel isn't changing things much for me
<soren> amitk: I forget... This is with kvm 72 userspace and kernel modules as well?
<amitk> soren: Version: 1:72+dfsg-1ubuntu2
<soren> amitk: And kernel?
<amitk> soren: 2.6.27-2-generic
<soren> amitk: Could you try installing kvm-source?
<soren> It does the dkms thing to provide more up-to-date modules.
<amitk> soren: nice! much better, with and withoug kvm-intel module. No crashes.
<amitk> *without
<soren> amitk: Without the kvm-intel module? Then you're in qemu-mode => very, very slow.
<amitk> soren: I know. I tried both ways - w/o modules and with update modules from kvm-source. And now there are no crashes.
<TheMuso> tjaalton, pitti, is there a way I can debug issues relating to notebook keys for adjusting brightness etc and xorg input hotplug? I think the hotplug broke this for a couple of machines I have access to, and I'd like to track down the problem.
<pitti> TheMuso: sounds like bug 267682, it has a few pieces of information
<ubottu> Launchpad bug 267682 in ubuntu "Hotkeys no longer working in Intrepid (evdev?)" [Critical,Triaged] https://launchpad.net/bugs/267682
<TheMuso> pitti: Thanks, will have a read.
<slytherin> dholbach: Any idea who handles bluetooth packaging currently?
<TheMuso> pitti: Is this bug also related to not seeing volume/brightness indicators hon screen when pressing such keys?
<pitti> TheMuso: ATM they don't do anything at all, right?
<pitti> TheMuso: well, on some models they are hardwired
<TheMuso> pitti: Well the volume/brightness gets changed, but no indicator is displayed.
<pitti> so they will have an effect, but the GUI doesn't notice them
<pitti> same bug in the end, yes
<TheMuso> Yep.
<TheMuso> Right, I don't know enough about those bits to be sure, thanks.
<soren> amitk: Lovely. That's very useful input. Thanks!
<dholbach> slytherin: #ubuntu-mobile I'd say
<slytherin> dholbach: waiting for StevenK there. :-)
<doko> pitti: didn't arrive yet in my time zone :-/
<StevenK> mvo: update-manager wants nvidia-common!?
<ogra> StevenK, lrm uses it iirc
<StevenK> nvidia-common is only on amd64 and i386
<StevenK> mvo: There's no nvidia-common on lpia
<ogra> why ?
<ogra> there might be lpia devices with nvidia onboard cards at some point
<StevenK> Because it's Architecture: i386 amd64
<ogra> right, that needs fixing imho
<ogra> though it might be tricky with binary drivers :)
<StevenK> nvidia-common itself is tiny
<mvo> StevenK: it needs it just for the modinfo stuff
<mvo> StevenK: ok, if lpia does not have nvidia anyway, then I need to patch that out
<tjaalton> pitti: I'll modify hal bzr a bit, debian-setup-keyboard should use the same model as in console-setup and force rules to be evdev instead. that means updating xkb-data, x-x-i-evdev, g-s-d as well
<tjaalton> this will fix the problems with ABNT2 & jp106 models
<Riddell> slangasek: let me know if you work out what caused the samba4 compile error, we have the same problem in kde4libs
<StevenK> mvo: Well, ogra has a good point, but patch it out.
<tjaalton> (once the evdev rules in xkb-data are updated)
<pitti> tjaalton: sure, please go ahead; please use UNRELEASED, dch --release, and debcommit --release if you upload yourself
<ogra> to date there are no such devices yet
<ogra> so we might be able to ignore it for now
<StevenK> ogra: That's my plan
<StevenK> mvo: Ping me when you upload it
<tjaalton> pitti: yes, I'm reading the "bzr packaging" session logs now to see how things are done :)
<StevenK> ogra: And I daresay fast 3D is not a first level requirement :-)
<ogra> heh, yeah
<mvo> tjaalton: I'm working on the gnome-control-center keyboard global keyboard setting right now, what is the plan for evdev and the console? I understand that the console will still use pc105 (or 104 etc)?
<pitti> tjaalton: if you feel unsure, just commit your patch, and I'll do the upload for you, but don't be shy to upload yourself
<tjaalton> mvo: this will let people to change the model again, and not force evdev
<tjaalton> pitti: sure, thanks
<mvo> tjaalton: aha, ok. is there work on gnome-control-center required for this too?
<tjaalton> mvo: don't think so, g-s-d forces the model (or ignores it) so that patch should be dropped once hal/xkb-data are updated
<TheMuso> seb128: Hi, was reading the gnome-session changelog to try and find the origin of the logout dialogs, and you noted it was from bugzilla. Mind pointing me to where? I need to see about fixing the dialogs so they are accessible to assistive technologies...
<mvo> tjaalton: ok, thanks
<seb128> TheMuso: http://bugzilla.gnome.org/show_bug.cgi?id=507101
<ubottu> Gnome bug 507101 in general "New UI for logout/shutdown dialogs" [Minor,New]
<TheMuso> seb128: Thanks.
<seb128> TheMuso: but don't spend too much work on it, we have no decision yet on whether we will keep this one or if we want something similar to what hardy had
<TheMuso> seb128: Ok, thanks for letting me know.
<seb128> TheMuso: you can also talk to vuntz, he hangs on #ubuntu-desktop usually, he's working for novell and pushing those changes upstream now
<seb128> let him know if there is any issue, he will probably be interested by those
<TheMuso> seb128: Ok thanks.
<asac> cjwatson: @multiple active devices: do you see packet loss? or do you just assume that you loose packets?
<asac> NM folks say that there shouldnt be an issue with packet loss. if they are on different subnets NM will assign higher prio through metrics to the faster connection
<asac> if they are on the same subnet, kernel should use whatever was there first
<asac> if thats not the case NM folks want to fix metrics instead of allowing to deactivate connection or providing "old" mode that only allows one active connectoin
<asac> cjwatson: so if you have other arguments against "multiple active" devices other than packet loss, please let me know ;)
<pitti> asac: does "active connection" translate to "multiple defaultroutes"?
<asac> pitti: yeah
<asac> pitti: hmm
<asac> pitti: strange. actually thats not the cas
 * asac confused
<asac> i think i have to wait for the NM boss to shed a light on this
<pitti> asac: hm, if not, how else do they work then?
<kwwii> pitti: I have package which builds locally but does not build in my PPA...is there any info on where to look for the problem?
<pitti> kwwii: the build log should help, if you can send the URL
<pitti> kwwii: I'm about to go to lunch, ok to deal with this in an hour?
<cjwatson> asac: yes, I get packet loss
<pitti> cjwatson: did you get multiple default routes with the same metric from nm then?
<cjwatson> I think it's that the acks come back on the wrong route or something like that
<kwwii> pitti: sure, no worries
<cjwatson> pitti: I don't recall, but can test when I get home
<kwwii> pitti: it seems to want intltool >= 0.37.1 but not get it
<kwwii> http://launchpadlibrarian.net/17439954/buildlog_ubuntu-hardy-i386.gtk2-engines-murrine_0.60-0ubuntu1%7Eppa2_FAILEDTOBUILD.txt.gz
<pitti> kwwii: hm, hardy has 0.37.1-1ubuntu1
<pitti> checking for intltool >= 0.37.1... ./configure: line 11320: intltool-update: command not found
<pitti> kwwii: I rather think that your package is missing an intltool build dependency altogether
<kwwii> pitti: ahhh, that would be it...let me check
<pitti> kwwii: it seems to pull in intltool-debian rather, whatever that is, and it is 0.35.something
<pitti> bah, why does such a thing even exist? the patch should be in the main intltool package
<kwwii> pitti: freaky, in the earlier svn snapshots that wasn't a problem
<kwwii> I do not have it in my build depends, I assume I should add it there
<pitti> kwwii: I guess they raised the required intltool version recently?
<asac> cjwatson: ok so i understood correctly. could you attach the route table and the syslog taken after you reproduced this to bug 262152?
<ubottu> Launchpad bug 262152 in network-manager "brings up both wired and wireless interfaces; hard to pick just one through the UI" [Medium,Triaged] https://launchpad.net/bugs/262152
<asac> thanks
<cjwatson> asac: will do. FWIW they are on different subnets
<pitti> mpt: just mailed you back wrt. the jockey UI (with screenshot)
<asac> cjwatson: ah ok. then thats why i dont see multiple default routes here
<pitti> lunch o'clock, bbl
<mpt> ok
<StevenK> mvo: Thank you for the quick 0.93.3 upload. *hugs*
<zyga_> hello, are there any .mac/idisk like projects for ubuntu?
<jdstrand> cjwatson: re ufw> sure
<kirkland> cjwatson: hey
<cjwatson> kirkland: yo
<kirkland> cjwatson: I was hoping to find a server iso built overnight
<kirkland> cjwatson: to test grub-installer from the ISO
<kirkland> cjwatson: any idea why one didn't build?  or when the next one might?
<pitti> mpt: thanks for your UI feedback; I'll fix the small things later, I first want to have something to present for a FF exception; do you think the general structure/design is ok now?
<cjwatson> kirkland: did you check the build logs?
<cjwatson> http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/
<kirkland> cjwatson: thanks, i'll check; didn't have that url
<mpt> pitti, sure
<cjwatson> should be ubuntu-server/intrepid/daily-*.log under that, or some such
<kirkland> cjwatson: i'm on it ;-)
<slytherin> kirkland: The last I checked no CD was built on 9th
<cjwatson> sly	yes, he wants to know why
<slytherin> right, I just wanted to say that it was not specific to server image
<tseliot> pitti: are you going to include the support for x-kit in the FFE?
<pitti> tseliot: it will be a separate request
<dholbach> pitti: do you know anything new about seahorse-agent? :-)
<tseliot> pitti: ok, if you need a hand just let me know
<pitti> dholbach: just that it works wonderfully :)
<dholbach> oh?
<cjwatson> kirkland: looking at it myself, I can't say it's obvious
 * dholbach installs seahorse-plugins
<pitti> dholbach: apt-get install seahorse-plugins
<kirkland> cjwatson: i'm not seeing anything either
<pitti> dholbach: I discussed that with seb128, it will become a seahorse depends/recommends, but I think it isn't yet
<seb128> pitti: yeah, forgot to change that yesterday, feel free to do so
<cjwatson> looks like check-installable is falling over
<dholbach> pitti, seb128: thanks for taking care of it
<cjwatson> but why no error message, I'm not sure
<pitti> seb128: sure, taking the 'lock' on it now
<kirkland> cjwatson: yeah, just hangs there....
<cjwatson> no evidence that it hangs, though, it just exits
<tseliot> pitti: does Jockey (with guidance) touch the ServerLayout section in the xorg.conf?
<cjwatson> though there are some old hung processes
<tseliot> pitti: have a look at this bug report: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-177/+bug/261816
<ubottu> Launchpad bug 261816 in linux-restricted-modules-envy-2.6.24 "nvidia: Multiple versions in DKMS" [Medium,In progress]
<cjwatson> kirkland: trying a manual run to see what happens
<kirkland> cjwatson: thanks a lot
<pitti> dholbach: FYI, uploaded with the recommends
<dholbach> pitti: rock on
<pitti> tseliot: no, it doesn't
<tseliot> pitti: ok, I just wanted to be sure
<pitti> tseliot: indeed, no idea how it came there
<cjwatson> kirkland: oh, it was hung actually. not sure why
<cjwatson> unfortunately now that I've realised it was hung I've already destroyed the evidence; maybe it'll do it again
<tseliot> pitti: I'll see if it has something to do with xorg autoconfiguration
<cjwatson> slytherin: BTW the Ubuntu (non-server) dailies built fine today, so I'm not sure what you mean
<cjwatson> slytherin: maybe you just looked too early in the day, before the cron jobs went off
<cjwatson> kirkland: and there it goes, publishing fine now, no idea what was wrong :-(
<kirkland> cjwatson: if by "evidence" you mean the build log, I still have it cached in my browser
<cjwatson> I meant the state of the running processes. The build log is kept anyway
<kirkland> ah
<cjwatson> kirkland: anyhow, ISOs will appear under http://cdimage.ubuntu.com/ubuntu-server/daily/20080909.1/ shortly
<doko> pitti: these rebuild tests are a pita ... for now I find unrelated problems, but none with the compiler.
<doko> - pygtk ftbfs even with the existing hardy setup
<doko> - perl fails due to a buildd misconfiguration, letting one test fail (don't know how this was built at all)
<jdstrand> cjwatson: hi! I should have the fix for bug #262451, but wanted to make sure my test environment reflected that of the bug
<ubottu> Launchpad bug 262451 in dpkg "dpkg: ../../src/packages.c:221: process_queue: Assertion `dependtry <= 4' failed." [High,Confirmed] https://launchpad.net/bugs/262451
<jdstrand> cjwatson: it simply appeats that iptable_filter is not available, and that ufw is not enabled yet
<cjwatson> my test environment is ... how can I put this, not as reduced as it might be
<cjwatson> if ufw isn't enabled, why is it touching iptables-restore?
<StevenK> My minimal chroot isn't any more.
<jdstrand> cjwatson: that is indeed the bug
<jdstrand> cjwatson: which was introduced in some cleverness in my application integration
<StevenK> I had a plan to find stuff in the chroot that ubuntu-minimal didn't pull in and purge it. Not sure how yet.
<jdstrand> (I forgot an _is_enabled() check)
<cjwatson> jdstrand: ah, right
<jdstrand> cjwatson: actually, just this little conversation is enough for me. thanks!
<MacSlow> damn
<cjwatson> jdstrand: I'm away from my normal environment, but I think doing a netboot install, selecting the desktop task, and putting pkgsel/include=openssh-server on the kernel command line should reproduce it
<cjwatson> jdstrand: dpkg might not actually fail, as I think that part's more sensitive, but you should be able to spot the ufw trigger failure in the syslog
<cjwatson> however I haven't had time to narrow it down yet - I only realised that that was the proximate cause at obscene o'clock this morning
<jdstrand> cjwatson: I appreciate it, and sorry you had to deal with this bug at that time of the morning :(
<cjwatson> jdstrand: meh, I wasn't up just to deal with that; I was preparing to catch a train and trying to wake up. (obscene being early not late)
<mvo> StevenK: is update-manager on lpia fine now?
<StevenK> mvo: Yes, thanks :-)
<mvo> excellent!
<MacSlow> evand, any bug know from the cd-image of 3rd of sep. regarding to the grub-installation on the harddisk?
<MacSlow> evand, just wondering if it's something like that or just a hosed cd-r
<jdstrand> cjwatson: it'll get uploaded today
<cjwatson> jdstrand: great, thanks
<cjwatson> MacSlow: what's the failure?
<MacSlow> cjwatson, after the installation it just does not boot and grub reports an error ... I'll try another cd-r of a newer cd-image
<cjwatson> which error? grub can report several
<cjwatson> you never win by paraphrasing error messages :)
<MacSlow> one sec
<evand> heh
<MacSlow> cjwatson, evand: it's "Error 15"
<MacSlow> GRUB Loading stage1.5.
<MacSlow> GRUB loading, please wait...
<MacSlow> Error 15
<MacSlow> and then it just sits there
<cjwatson> error 15 translates to "file not found" from grub and often means that grub is being pointed to the wrong disk or partition
<MacSlow> hm ok
<cjwatson> do you have multiple disks in this machine, or a USB stick inserted?
<MacSlow> cjwatson, no just one disc with several partitions
<cjwatson> hm, not sure why that would happen with a single disk
<MacSlow> cjwatson, I am in the middle of updating the hardy-installation to intrepid and wanted to use the new installer
<dholbach> seb128, pitti: works nicely!
<seb128> dholbach: excellent ;-)
<evand> MacSlow: was this using the /home preservation functionality in the installer?  That is, did you go to the advanced partitioning page and uncheck the format boxes?
<MacSlow> evand, yes
<evand> hrm, yikes.
<MacSlow> evand, did I miss something there?
<evand> I'm wondering if that's connected to why grub is failing for you.
<MacSlow> I just hope my /home partition is still intact
<evand> Can you please file a bug and attach your logs from the install (/var/log/installer/*) as well as a listing of /boot?
<MacSlow> evand, ok ... btw the integrity check of the CD returned no errors
<evand> ok
<didrocks> Hi everyone. I worked on a NBS (icedjava7-jre). Can someone remove it, please? http://people.ubuntu.com/~ubuntu-archive/NBS/icedtea-java7-jre
<davmor2> Macslow: daft question but you did set the mount points didn't you?
<mathiaz> cjwatson: what does () mean in the seeds ? ex: * (landscape-client)
<MacSlow> davmor2, sure
<StevenK> mathiaz: Recommends, I think.
<davmor2> Macslow: thought you probably would of but it best to check the obvious hasn't been overlooked :)
<cjwatson> mathiaz: StevenK is right. See the germinate(1) manual page
<mathiaz> cjwatson: StevenK: thanks
<pitti> tseliot: do you currently have a branch with only the 'recommended' addition? I'd like to review/merge them separately (x-kit branch comes next)
<pitti> tseliot: or a patch, for that matter
<MacSlow> evand, I cannot retrieve the contents of /var/log/installer/* only the listing of /boot
<MacSlow> evand, I assume that's not enough for a useable bug-report
<tseliot> pitti: no, I don't, however you can cherry pick  the commits from 362 to 366 and ignore commit 365: https://code.launchpad.net/~albertomilone/jockey/jockey-generic
<evand> MacSlow: odd, is /var/log/installer missing?
<pitti> tseliot: ok, thanks
<pitti> StevenK: NBS packages cleaned up
<MacSlow> evand, on none of hte partitions I can find /var (it used to be a separate partition)
<evand> very yikes
<MacSlow> evand, I've three partitions that only hold the lost+found directory
<MacSlow> evand, well at least my /home partition was left untouched
<evand> MacSlow: do me a favor and create a bug report anyway with the listing of /boot and `sudo parted /dev/sda print all`
<MacSlow> evand, well at least my /home partition was left untouched
<MacSlow> evand, ok
<evand> glad to hear that, though sorry about the rest of your partitions
<MacSlow> evand, well there's no data loss so it's not much of a problem
<MacSlow> evand, against what package should I file it?
<evand> hrm, partman-target would probably be best
<cjwatson> MacSlow: might also be worth outlining what your partition scheme used to look like as best you can, to aid reproduction
<seb128> asac: did you add this nspluginwrapper bugpattern yesterday?
<MacSlow> cjwatson, of course
<ogra> Riddell, mind o take a look at netbook-launcher in the queue ? http://revu.ubuntuwire.com/details.py?package=netbook-launcher has a revu review already, bug 263493 is the FFe exception (its an ubuntu-mobile pakcgae for which i approve FFe anyway)
<ubottu> Launchpad bug 263493 in ubuntu "Please package applications from netbook-remix" [Wishlist,Confirmed] https://launchpad.net/bugs/263493
<ogra> s/o/to/
<Riddell> ogra: aww, you spoilt my perfect empty New queue
<ogra> sorry :/
<asac> seb128: http://paste.ubuntu.com/44929/ ... i didnt find time to properly test it ... if you say that that looks fine i can just commit
<Riddell> ogra: :)
<Riddell> ogra: it includes a copy of another library, how come that isn't a separate package?
<ogra> its a svn checkout that wont go in the normal upstream
<asac> seb128: committed
<ogra> at least thats how njpatel explained it
<Riddell> ogra: seems ugly.  but accepted
<ogra> thanks a lot :)
<seb128> asac: looks correct to me too
 * ogra adds the netbook packages to the seeds
<asac> seb128: http://bazaar.launchpad.net/~ubuntu-bugcontrol/apport/ubuntu-bugpatterns/revision/11
<asac> seb128: do we want to upload that?
<asac> or will this happen automagically?
<tedg> Okay, so when I have an FFe that get accepted, but it needs a sponsor, do I subscribe main-sponsors to the FFe or create another bug?
<pitti> tedg: just sub'ing u-m-s is sufficient
<seb128> asac: I think it's using the only datas
<seb128> s/only/online
<asac> oh cool
<Riddell> asac: knm issue.  knetworkmanager might get some work done on it in a couple of weeks so we can wait and hope that happens before beta, fix it ourselves (likely beyond my ability) or revert back to a nm daemon that we know works
<asac> Riddell: yeah. NM finally stabilizes
<tedg> pitti: Thanks.  Done.
<asac> so there is hope that we dont need to run after it
<Riddell> asac: mm hmm, but as it stands we have a version that doesn't work with knm
<tkamppeter> pitti, hi
<asac> Riddell: where is the knetworkmanager svn?
<asac> Riddell: NM 0.7 finally has a final release date: 4 weeks from now. i guess knetworkmanager will be fixed for that.
<Riddell> asac: http://websvn.kde.org/branches/work/knetworkmanager/
<asac> Riddell: it is you who committed 4 hours ago?
<asac> ;)
<Riddell> yeah I added a compile fix
<MacSlow> evand, there you go https://bugs.edge.launchpad.net/ubuntu/+source/partman-target/+bug/268186
<ubottu> Launchpad bug 268186 in partman-target "installation using manual partitioning fails " [Undecided,New]
<Riddell> hschaa is the main developer but he's away for at least a couple of weeks
<asac> Riddell: the changes NM did since it worked shouldnt be that intrusive
<asac> Riddell: mostly some dbus API changes
<asac> Riddell: which dont really add new features
<asac> Riddell: is there an easy instruction on how to build that?
<asac> Riddell: last time it was too tricky for me :(
<asac> (as you might remember)
<tkamppeter> pitti, it is about driver auto-download (https://blueprints.edge.launchpad.net/ubuntu/+spec/jockey-printer-driver-support)
<pitti> tkamppeter: hi
<tkamppeter> Yo write that s-c-p does not have the D-Bus interface yet. Did you talk with Tim Waugh about that?
<zyga_> (again) are there any .mac/idisk like projects for ubuntu?
<pitti> tkamppeter: s/have/use/; no, I didn't talk with him about it yet (not since our meeting in London)
<pitti> tkamppeter: I want to get the 0.5 jockey release out (with that feature) first
<pitti> tkamppeter: still working on some bits, and I want to stabilize the interface
<Riddell> asac: svn co svn://anonsvn.kde.org/home/kde/branches/work/knetworkmanager/
<evand> MacSlow: thanks
<tkamppeter> Will the 0.5 Jockey go into Intrepid?
<asac> Riddell: yeah. i got that  ;)
<Riddell> asac: cd knetworkmanager; cp -r kdetoys/admin .
<Riddell> asac: from your local copy of kdetoys that I'm sure you have
<MacSlow> evand, I hope it's at least of some use to you
<asac> Riddell: i am sure i dont have that ;)
<asac> Riddell: have never heard of it before ;)
<pitti> tseliot: btw, I just committed some robustifications for the jockey trunk test suite
<pitti> tseliot: in your mail you mention that two tests fail; do they fail for you on trunk as well, or just after your modifications? in the former case, I'd like to find out and fix it
<pitti> tseliot: well, in the latter case as well, of course, but then we need to look at some different place
<Riddell> asac: well any copy of that admin directory, it's in svn somewhere of course but I can never remember where (I should find it and set the svn external really)
<Riddell> asac: make -f Makefile.cvs; ./configure --prefix=/usr
<asac_> Riddell: reconnect :/
<MacSlow> evand, I'll grab a recent cd-image and try again
<Riddell> asac: well any copy of that admin directory, it's in svn somewhere of course but I can never remember where (I should find it and set the svn external really)
<Riddell> asac: make -f Makefile.cvs; ./configure --prefix=/usr
<tseliot> pitti: I have modified the code in trunk and and in the ubuntu specific branch and in both cases the 2 tests fail only after my modifications
<pitti> tseliot: ok, I should be able to reproduce that then, will have a look
<tseliot> ok
<asac_> Riddell: i think the admin directory was what bit me in london :/
<pitti> tseliot: does the test suite in trunk run successfully for you now?
<asac_> i dont feel confident that i can bootstrap that without much fiddling
<asac_> Riddell: how are the packages built?
<asac_> do they ship that admin dir?
<tseliot> pitti: let me try again, just to be sure
<Riddell> asac_: yes, I add it
<Riddell> asac_: it's just like gnome-common or whatever it's called, but it should be set with an svn external
<pitti> tseliot: ok, I reviewed the recommended branch, that looks fine
<tseliot> pitti: great
<tseliot> pitti: FAILED (failures=2, errors=3), however no test regarding the xorg.conf is involved
<pitti> tseliot: ugh; let's take this to /msg
<tseliot> ok
<tkamppeter> pitti, Will the 0.5 Jockey go into Intrepid?
<pitti> tkamppeter: most probably, yes
<tkamppeter> pitti. is the DBUS API for s-c-p already defined or are you still working on it?
<sbalneav> tkamppeter: Hey, some time ago I bumped into a bug in Cups, I've submitted a patch upstream: http://www.cups.org/str.php?L2831, patch fixed multi-tray printing for OpenOffice.org in hardy.  Would you be interested in me filing a LP bug so an SRU can go through?
<ubottu> CUPS bug 2831 in Core CUPS Software "%%IncludeFeature: functionality not working correctly" [Priority low,Closed w/resolution]
<Riddell> asac: yay, I worked out how to set the external so admin gets included with a checkout now (although it'll take 10 minutes to get into anonsvn)
<pitti> tkamppeter: no, that's defined and works, just not documented properly yet
<tkamppeter> pitti, what do you think about an SRU for cups about CUPS bug 2831 (as sbalneav asks for) and also for bug 218663?
<ubottu> CUPS bug 2831 in Core CUPS Software "%%IncludeFeature: functionality not working correctly" [Priority low,Closed w/resolution] http://www.cups.org/str.php?L2831
<ubottu> Launchpad bug 218663 in cupsys "cups remote https administration hangs" [Undecided,New] https://launchpad.net/bugs/218663
<tkamppeter> pitti, could you document the DBUS API quickly so that we can make a patch for s-c-p to trigger Jockey for driver download?This would enable especially network printers to make use of driver download.
<pitti> tkamppeter: I'll respond later, need to finish something and have a phone call
<asac> Riddell: ok. then its just the make line above?
<Riddell> asac: yes
<Riddell> asac: apt-get build-dep knetworkmanager first will help
<asac> Riddell: yeah. thats clear
<thom> doko: are you likely to look at LP:264808 before intrepid release?
<samtb> i'm trying to create a bzr branch of mplayer so i can create personal packages that track the official releases but some of the launchpad branches don't seem to be setup and others give bzr: not a branch
<samtb> could someone please explain what the setup is on launchpad?
<tjaalton> pitti: so, I did the change in hal, now I should run bzr co, then dch --release, a new bzr co or?
<doko> thom: hmm, was not yet on my radar ...
<thom> doko: ok; i'll dig a bit and see if i can cook up a patch
<samtb> e.g. ubuntu-hardy says "this branch has not been pushed yet" on the lp page - the next best option appears to be plain mplayer/ubuntu which gives "not a branch" with bzr
<cjwatson> lp:~ubuntu-dev/mplayer/ubuntu looks right; I checked that out and made a change to it the other day
<cjwatson> lp:mplayer is the upstream source; lp:~ubuntu-dev/mplayer/ubuntu is the current version in Ubuntu
<samtb> that's what i thought - really i want hardy for the moment, but i don't mind getting more recent updates
<doko> thom: there are two things: fixing ant, and maybe changing OpenJDK to generate byte code for1.5.
<cjwatson> the other branches are things other people have created for one reason or another, and may or may not be sane
<samtb> bzr: ERROR: Not a branch: "http://bazaar.launchpad.net/~ubuntu-dev/mplayer/ubuntu/.bzr/branch/".
<cjwatson> samtb: what is your bzr command?
<tjaalton> pitti: and I can't commit, "cannot lock Lockdir($url): transport operation not possible..."
<samtb> bzr branch lp:~ubuntu-dev/mplayer/ubuntu dev
<samtb> or co
<samtb> note that it works for the trunk
<samtb> or for nhandler's version
<samtb> s/trunk/upstream
<cjwatson> samtb: all I can say is that it works for me; you might need to use a newer version of bzr
<cjwatson> http://bazaar-vcs.org/Download
<slangasek> Riddell: hrm, is there a samba4 compile error that I'm meant to be looking at? :)
<cjwatson> it's unusual for the version in hardy not to be good enough, but maybe that's the case here
<samtb> bzr from latest hardy... should work surely?
<cjwatson> I don't know why it wouldn't; that branch seems to be using a relatively old disk format
<cjwatson> oh
<cjwatson> samtb: have you done 'bzr launchpad-login YOUR_LP_USERNAME'?
<cjwatson> if not, try that, and repeat ...
<samtb> i'm using edge.... does that make a difference?
<samtb> (no, i will try login
<tjaalton> pitti: bah, I'll upload and commit later if I get it to work
<cjwatson> samtb: so am I
<\sh> isn't bzr launchpad_login only for using bzr+ssh ? when not bzr launchpad_logined it should default to http
<cjwatson> samtb: it fails over http: for me too, but succeeds for bzr+ssh
<cjwatson> \sh: see the comment I just made :)
<\sh> cjwatson: that was missing, yes :)
<Riddell> slangasek: maybe not, you're in the changelog but I see it's not your upload
<james_w> tjaalton: you need to "bind" to a bzr+ssh:// version of the url
<samtb> okay.... so i need to use the direct link replacing http with bzr+ssh?
<cjwatson> samtb: this feels like something you should ask about on #launchpad or #bzr
<james_w> tjaalton: as opposed to a http one, as that is not writeable.
<cjwatson> samtb: lp: should work if you've done launchpad-login
<cjwatson> but I think this is a bug somewhere ...
<tjaalton> james_w: uh, of course
<slangasek> Riddell: is it reproducible locally?
<cjwatson> oddly, it works for other branches
<cjwatson> $ bzr branch http://bazaar.launchpad.net/~ubuntu-core-dev/anna/ubuntu anna
<cjwatson> Branched 412 revision(s).
<samtb> with my email it says no such user, so i guessed what my username would be and it says no keys registered, which is untrue
<Riddell> slangasek: I expect so if you have amd64, the kdelibs one is
<cjwatson> samtb: do you have a Launchpad account? (most people who do know what the username is)
<slangasek> Riddell: might be header breakage, wouldn't be the first time; but the compiler used to also tell you where the first definition was that's getting overridden, and it's not doing that here
<slangasek> (in the samba4 case, that is)
<cjwatson> samtb: if you guessed, how can you be certain that that LP account has your SSH keys registered?
<samtb> i do have a launchpad account, i have registered ssh keys
<samtb> i'm logged in now on edge
<samtb> but i log in with email
<samtb> and like you said, it works with other branches
<cjwatson> samtb: hover over the link with your name in at the top right, just to the left of the "Log Out" button
<cjwatson> it should link to https://edge.launchpad.net/~YOUR_USERNAME
<samtb> sorry, i'm being dumb, yes i guessed it right
<cjwatson> samtb: anyway, I think you do need help from #launchpad or #bzr (not sure which) for why that branch can't be pulled over HTTP
<samtb> okay thanks will try over in launchpad
<tjaalton> pitti: ok, pushed, although I forgot the debcommit --release -part :)
<Bor_Ed> evening. is it too late to request device support for 8.10 intrepid this late on dev state?
<thom> doko: argh, it's not just ant of course; there's a tonne of stuff which is 1.6 only now
<thom> xalan, xerces are the two obvious ones
<doko> yes, falling back to 1.4 or 1.5 is more work
<avb> hey
<avb> guys, there is a weird bug exists in intrepid for me and i cant decide against what should i place a bug
<thom> it's more work but i think going to 1.6 only is gonna cause people a tonne of issues
<avb> the problem is that gnome-screensaver locks up machine when its running on pc with intel videocard
<avb> accourding to forum users have it only with i965 chipsets
<avb> http://ubuntuforums.org/showthread.php?t=905459
<avb> so, there is few things
<avb> 1. bug goes away when u disable 'Unredirect Fullscreen windows'
<avb> in compiz settings
<avb> so, probably bug in compiz
<avb> 2. $ glxinfo|grep render
<avb> direct rendering: No (LIBGL_ALWAYS_INDIRECT set)
<avb> thats a second issue. why for now compiz for i965 starts with LIBGL_ALWAYS_INDIRECT and there is no DRI
<avb> so probably a bug in mesa
<avb> 3. probably a bug in intel driver
<avb> so maybe one of maintainers is here?
<avb> and we can find a sence of bug togeather?
<cjwatson> Bor_Ed: #ubuntu-kernel's probably a better place, unless it's some particular application that's missing
<cjwatson> Bor_Ed: it's not necessarily too late, though cutting it fine
<Bor_Ed> cjwatson: thanks for answering... the prob is with v4l-dvb since the mantis driver kit seems to be only choice for most dvb-c and dvb-t cards here and builds without work on 9.10
<avb> he
<avb> mine second issue
<avb> :)
<Bor_Ed> cjwatson: just can't build the .deb myself and drop it to the maintainers
<cjwatson> Bor_Ed: well, getting a binary .deb is rarely much use, but patches to the source code are welcome
<Bor_Ed> cjwatson: no need for patches since the latest released tree builds just fine and work too
<cjwatson> Bor_Ed: I can only give generic advice, though - don't know anything much about v4l-dvb myself
<Bor_Ed> cjwatson: I have 2.6.27 from the install, build-essential etc and the source builds against them... though it's probably too much work for linux newbie still to locate source and build the stuff... and it's ~270 devices missing from the sys because of that
<cjwatson> Bor_Ed: #ubuntu-kernel is a much better place for this
<Bor_Ed> cjwatson: I'll try that, thanks
<cjwatson> particularly if given very specific information about which hardware isn't working properly and which tree fixing it
<cjwatson> fixes
<Bor_Ed> gone... thanks again
<nrg> does any know if genisoimage's "Directories too deep
<nrg> issue is being worked on?
<pitti> tjaalton: forgot debcommit --release> no problem, that should happen precisely when you actually upload, to maintain consistency
<pitti> tjaalton: bzr co, dch --release, debcommit -r (that will automatically do bzr co)
<pitti> tjaalton: just pulled; so, do 'debcommit -r' instead of the second 'bzr co', and all will be good (don't worry for now)
<pitti> tjaalton: I retroactively added the 0.5.11-3~ubuntu8 tag
<sbalneav>  /win 6
<slangasek> bryce_: where do I file a bug about the fact that I can't keep my RWIN key mapped to Compose?
<tjaalton> pitti: ok thanks, I need to use bzr more ;)
<bryce_> slangasek: hmm
<tjaalton> slangasek: I hope the uploads I did a while ago help with that
<slangasek> tjaalton: how long ago is "a while ago"?
<slangasek> and for which package?
<tjaalton> 1-2h
<slangasek> ah
<tjaalton> now the model is forced as evdev, but with these uploads the evdev driver will use the evdev ruleset instead
<slangasek> so I still need to wait for it to be published, then restart my session?
<bryce_> slangasek: xkeyboard-config is an okay thing to file keyboard bugs against; often the real bug is somewhere else but we can move them from that
<tjaalton> which is new
<bryce_> slangasek: yeah
<slangasek> what package should I be looking for?
<tjaalton> hal/xkb-data/x-x-i-evdev/gnome-settings-daemon :)
<tjaalton> all of them
<slangasek> heh, ok
<ogra> mind you it can take a small centuriy for them to build ...
<slangasek> will this also coincidentally fix the fact that my media keys are no longer generating events over dbus, or do I need to file a separate bug on hal for that? :)
 * ogra is still waiting for binaries of the packages slangasek approved 24h ago
<ogra> the queue is still extremely long ...
<slangasek> hmm, really?  I'm surprised it hasn't cleared yet
<ogra> 849 for https://launchpad.net/ubuntu/intrepid/+builds?build_text=&build_state=pending
<tjaalton> slangasek: xev doesn't show anything?
<tjaalton> what about evtest?
<jcristau> XKBOPTIONS=compose:rwin should work
 * ogra wonders if we shouldnt use dbus-monitor nowadays
<slangasek> tjaalton: for the media keys?  It /does/ show keypresses, but hal needs to pick those keys up and translate them into dbus events so that apps that don't have the focus can listen
<tjaalton> if the settings are reset during the session, it's likely not a bug in xkeyboard-config but the server/evdev or desktop
<tjaalton> slangasek: yeah, well I think what happens is that evdev has grabbed the device so that doesn't happen
<slangasek> jcristau: well surely, the "Right Win-key is Compose" option in gnome-keyboard-properties should do that/
<tjaalton> slangasek: see bug 267682 for my analysis on this (with the help of #xorg-devel)
<ubottu> Launchpad bug 267682 in ubuntu "Hotkeys no longer working in Intrepid (evdev?)" [Critical,Triaged] https://launchpad.net/bugs/267682
<jcristau> slangasek: no gnome here, i wouldn't know ;)
<slangasek> tjaalton: ummm. ok, I just retested, and the media keys /don't/ show keypress events and /do/ generate the dbus events
<slangasek> argh
<tjaalton> hah
<slangasek> and this, without restarting X since the last time I tested :P
<slangasek> (compose is still broken though!)
<slangasek> jcristau: "setxkbmap -option compose:rwin" - did the trick, but not very permanent...
<slangasek> (and I don't want to have to set it in xorg.conf :)
<jcristau> it can go in /etc/default/console-setup aiui
<slangasek> hmm
<tjaalton> yes
<slangasek> I'm pretty sure I'm missing the point of getting rid of xorg.conf settings if we're just going to add the same settings to a different config file :)
<tjaalton> well those are then shared with console too :)
<ogra> they apply to both, console and X that way
<slangasek> how do you list more than one XKBOPTIONS value?  space-separated?
<jcristau> comma-separated
<slangasek> k
 * sebner wonders if upstart (ready since 12 august) will make it into intrepid or remaing for jaunty since mark wants "faster boot"!?
<slangasek> sebner: what do you mean?  upstart has been the init system for a while now.
<sebner> slangasek: sure but I'm speaking about the 0.5 release
<slangasek> ah
<davmor2> slangasek: I'd lose quick search from synaptic if I were you
<slangasek> davmor2: I think you mean to address yourself to the desktop team
<davmor2> type t into quick search and it instantly lowers your options to nvidia-glx-96 and nvidia-glx-177
<dendrobates> doko: I want to remove zope3-sandbox from server-ship and I was told to run it by you.  Any objections?
<dendrobates> pitti: what do you think about moving radeontools and vbetools to Suggests in pm-utils?
<pitti> dendrobates: IIRC vbetool is actively used by pm-utils for implementing popular quirks; I don't know about radeontool
<pitti> dendrobates: both together are a mere 20 KB, so I guess size is not the reason you want to get rid of them? :)
<dendrobates> pitti: pm-utils is being pulled into server through recommends, and I am just looking to deal with possible complaints about bloat.
<pitti> dendrobates: good point; I guess suspend/resume isn't really something you'd expect/install on servers
<pitti> dendrobates: but these two recommends are fundamentally right IMHO; instead we should maybe look for throwing out pm-utils altogether on servers?
<pitti> dendrobates: I'm ok with dropping the hal recommends on it, and instead pull it in through something else
<dendrobates> pitti: thanks.
<pitti> explicit seeding, or maybe gnome-power-manager
<pitti> dendrobates: can you pleaes file an intrepid-beta milestoned bug and assign it to me?
<pitti> dendrobates: can't do it right now, but ASAP
<dendrobates> pitti: sure.  np
<pitti> dendrobates: I just want to think a little more clearly how to pull it in
<pitti> dendrobates: thanks
<soren> I always forget this: What's the #define that tells me if I'm compiling on amd64 or i386?
<geser> soren: are you looking for __x86_64__ and __i386__?
<soren> geser: That sounds about right :)
<soren> geser: Yes, fantastic. That did the the trick. Thanks very much!
<brandon|work> what is the best way to install kde from svn?
<Riddell> brandon|work: see techbase.kde.org
<brandon|work> k
<brandon|work> thanks
<Riddell> or use kde-nightly
<brandon|work> Riddell, project neon?
<Riddell> brandon|work: yes
<brandon|work> cool
#ubuntu-devel 2008-09-10
<ckyle> where do i find info on syscalls in ubuntu? mmap() and stuff? thx
<ckyle> does it come w/ os?
<mok0> ckyle: man mmap
<mok0> (after installing manpages-dev)
<NCommander> lamont, give a moment to talk about ports?
<erast> anyone interested in porting their .deb packages to OpenSolaris/Nexenta ?
<erast> we have bunch of SSH dev. accounts to ZFS zones on gnusolaris.org
<NCommander> erast, Nexenta seemed kinda dead last time I looked; is there an amd64 port yet?
<erast> yep
<erast> i think community growing
<NCommander> erast, I'd install it expect my trackpad doesn't work in Solaris
<erast> we ported Hardy Heron recently and released first alpha
<NCommander> erast, what are you using for infrastructure, dak I assume
 * NCommander has played with Nextena and is interested
<erast> dpkg-buildpackage
<erast> dput
<erast> normal stuff
<NCommander> erast, I meant server side ;-)
<erast> debarchiver
<NCommander> erast, i.e., what handling the incoming and such
<NCommander> seriously?
<NCommander> I'm suprised it scales that well
<erast> why not
<erast> 95% of packages compiles as is
 * NCommander used dak when he was hosting debian-68k testing
<erast> i.e. apt-get source -b
<NCommander> erast, you should be running a buildd to build all debs automatically
<erast> i think tim (rootard) working on new autobuilder for nexenta
<erast> its going to use ZFS and Zones
<NCommander> erast, I won't mind helping to set that up
<NCommander> I've run and adminned buildds before
<erast> that'd be great
<NCommander> Where's the dev channel?
<erast> #nexenta
<erast> but first, do you want to try to get SSH login and try to build couple of packages ?
<ilovefedora> hello how can i install php 5.2 on ubuntu 6.06
<NCommander> I think I need help
<cody-somerville> NCommander, I can help you.
<NCommander> cody-somerville, how?
<mcasadevall> cody-somerville: bah, so much for the GUI
<mcasadevall> cody-somerville: anyway, I need some SRU love
<cody-somerville> mcasadevall, okay.
<cody-somerville> bug #s?
<mcasadevall> cody-somerville: one bug, 11 packages
<mcasadevall> It's a transition
<mcasadevall> brb
<mcasadevall> I need to just reboot this machine
<mcasadevall> cody-somerville: I dunno what I did
<mcasadevall> But I seriously hosed this laptop
<cody-somerville> :|
<mcasadevall> cody-somerville: I'm right now deleting stuff, and then backing up
<mcasadevall> I reformat tonight
<cody-somerville> lol
 * mcasadevall decides if he wants to install xubuntu/kubuntu/ubuntu/ubuntu-stdio/mythbuntu
 * mcasadevall backs up
<TheMuso> ogra-Q1: Did you push your casper changes to a bzr branch somewhere? At least from what Colin has given me, they are not in trunk. I'd like to merge them into trunk, and would prefer to do it from another bzr branch if available, so that its logged in the bzr log, and not just in the debian changelog.
<cody-somerville> xubuntu, duh :P
<TheMuso> RAOF: Pulseaudio 0.9.12 is in my PPA. Let me know if you still have those issues. If so, I'll pull latest alsa-lib git and package them up for you to test.
<RAOF> TheMuso: I'll test it this evening, thanks.
<TheMuso> RAOF: np
<TheMuso> New paprefs and pavucontrol will be uploaded to my PPA as well.
<RAOF> Oooh! Are they shiny? </ferret>
<TheMuso> Dunno really, but I think they are needed to work properly with the newer pulseaudio.
<RAOF> It'd probably be simple enough to whip up a lib32pulse, if you'd like me to.
<TheMuso> RAOF: Would that solve the alsa-plugins needing ia32-libs issue?
<RAOF> Yes.
<TheMuso> RAOF: Added to that, pulseaudio uses cdbs.
 * RAOF cries
<RAOF> Ok.  Perhaps it's _not_ easy enough to whip up a lib32pulse.
<TheMuso> The other problem with a lib32 pulse, is all the extra module packages would have to be 32-bit as well.
<RAOF> The pulse-module-* ?
<TheMuso> Yep.
<RAOF> Really?  I'd've thought they'd only be interesting for the daemon.
<RAOF> We wouldn't be getting a 32bit daemon, right?
<RAOF> Anyway; I'll add "spend a couple of unrewarding hours hitting CDBS with a stick" at the bottom of my TODO
<TheMuso> heh ok
<TheMuso> RAOF: Ah of course, you are right.
<mcasadevall> ScottK: hola
<ScottK> NCommander: Heya.
<NCommander> ScottK: I have a fix for kdelibs on amd64
<NCommander> ScottK: uploading it somewhere might a trick however, my X11 installation is somewhat hosed
<ScottK> NCommander: Can you just mail me the debdiff?
<NCommander> ScottK: how can I do that easily: mail scott@kitterman.com << *file* right?
<NCommander> (well, you can just wait also until when I reboot off the liveCD)
<ScottK> Yes.
<ScottK> Whichever.
<NCommander> ScottK: I tried emailing it, I'm not sure if it will work
<NCommander> ScottK: I confirmed it on amd64, and apachelogger confirmed on i386
<ScottK> NCommander: I greylist, so it'll be a bit before I get it.
<ScottK> OK.
<NCommander> ScottK: won't work then, no return path on my email
<ScottK> NCommander: If it got to your mail server, it should be able to handle it.  Greylisting is done during the SMTP dialogue, so that shouldn't matter.
<NCommander> ScottK: it is?
<NCommander> ScottK: Oh, interesting, then it should work I hope
<ScottK> Sure.
<NCommander> Its just you can't access my SMTP server from the net
<NCommander> I'm suprised on how affective grey listing was
<ScottK> You deliver to your MTA, your MTA talks to my MTA.  My MTA says 450 come back later, and then later your MTA comes back and acceptes it.
<ScottK> As long as it can access mine, it works.
<NCommander> neat
 * NCommander waits on his Xubuntu disc to finish burning
<NCommander> so ... slow ....
<NCommander> bbl
 * calc bought a new car tonight :)
<avb> which one? :)
<avb> which brand
<calc> 2009 Honda Fit (Jazz in europe)
<avb> nice :)
 * avb is a bmw fan
 * calc can't justify that high a payment ;-)
<avb> yeh, but it worth this moneys
<calc> mine is only 475/mo for 36mo
 * NCommander hits his head repeatively on his desk
<avb> im highly satisfied with 2001 X5 and 94 325i
<avb> :)
 * calc likes the bmw/mercedes
<calc> i've ridden in them in the past, very nicely built just a bit out of my price range at least for now
<avb> 325i convertible is owesome
<calc> plus i don't think i would want a toddler in one of those they would screw it up  ;-)
<avb> i still love it
<calc> i have a 1yr old son
<avb> but in the city X5 is the best
<calc> it appears the fit gets around 42mpg for me, at least on the drive back home from the dealer, it was about 40mi away
<avb> man, dont tell me about a fuel :)
<avb> i prefere not to think about it
<calc> i'm pretty sure that has to be the best fuel economy for a car in the US that isn't hybrid
<avb> it not so hurts then :)
<calc> lol, ok
<avb> 13mpg ....
<calc> ouch
<NCommander> hey persia
<persia> NCommander: Hello.
<NCommander> persia, ever do something stupid and kill a lot of files by accident :-)
<calc> rm -rf ~ works ;-)
<persia> NCommander: Like half my home directory 150 minutes ago?
<calc> i've done that a few times i think
<NCommander> Well, my backup didn't properly write
<NCommander> It seems -devel having a data failure issue :-)
<NCommander> so I just blew away my entire HDD
<erast> NCommander: i could teach you how to use ZFS snapshots on home dirs - you gonna love it :-)
 * avb investigated a problem with DRI with intel
<NCommander> erast, I'm not using opensolaris on a laptop
<avb> finaly seems i see a problem
<NCommander> I'm just smart enough to actually backup my SSH and GPG keys to my cell phone's flash device
<avb> Mesa 7.1 is a problem
<NCommander> and should the phone get lost
<NCommander> Its a five minute call to remotely wipe it
<erast> well, ZFS like a drug... once you tried it - you will not be comfortable with anything else again
<avb> seems first time i will do a rollback to ubuntu-1 and ubuntu+2
<NCommander> erast, this won't have helped, I reparitioned the HDD
<NCommander> erast, I wanted to remove the old NTFS crud left behind by Vista
<avb> erast: one problem is that there is no zfs in linux
<calc> and solaris is... yuck :-\
<erast> well there is - zfs on fuse
<NCommander> I actually like solaris
<NCommander> erast, the performance hit is unacceptable
<erast> solaris - sucks... nexenta - cool :-)
<calc> of course my experience with solaris was 2.6/7 so maybe its somewhat better now, it was horrid back then
<NCommander> At least my system decrufted now
<avb> i feel solaris is works like a shit on x96
<NCommander> erast, you really should work towards supporting more than just the Ubuntu LTSs
<avb> x86
<NCommander> Just my two cents
<avb> and also, their coreutils sux
<avb> completely
<NCommander> avb, BSD and IRIX are worse
 * calc used solaris on sun sparc hardware
<NCommander> (well, FreeBSD does work in that respect, but NetBSD is worse)
<calc> i just reinstalled debian onto them after getting fed up with how useless they were :)
<avb> BSD ever works? :)
<avb> i thought that on firewalls only
 * NCommander finishes building his pbuilder chroots
<calc> solaris didn't even have top installed by default
<calc> i was surprised at how little useful utilities came with it
<avb> and ps -ef
<erast> NCommander: may be one day this will happen, but for now we are going after LTS only, and as i said earlier nexenta makes sense for servers - on desktop opensolaris still sucks
<avb> i hate a time when i ought to work with solaris
<calc> i was probably spoiled by having used Debian before Solaris
<avb> and also from admin point of view sparc is not betten then intels
<erast> calc: consider nexenta, its ubuntu LTS...
<avb> maybe its cool to code for it, but in the rest it sucks
<erast> the userland at least
<avb> erast: are we getting speedstep, suspend to ram stuff there? :)
<NCommander> I just want my trackpad to work
<avb> and normal smp support
<avb> ?
<calc> nexenta doesn't work on Sun hardware, so why use it at all since there is already Ubuntu ;-)
<NCommander> My battery was detected when I ran it
<erast> we actually have it already in the latest builds
 * calc no longer has sun hardware though
<erast> calc: who told you that? :-)
<avb> unfortunately how hard linux kernel sucks, its still the best in OSS world
<erast> we running datacenter of Thumpers x4500
<erast> on nexenta
<NCommander> avb, having used freebsd maybe not
<calc> erast: nexenta.org says it runs on AMD/Intel 32/64 bit
<avb> the rest is just a joke
<calc> erast: doesn't mention sparc at all
<calc> erast: or i am blind :)
<calc> "Nexenta Operating System runs on Intel/AMD 32/64bit hardware and is distributed as a single installable CD."
<avb> NCommander: i did. this shit even cant run on all the laptops
<erast> you said - Sun hardware
<avb> boot sometimes just hands
<avb> im not telling about smp again
<erast> x4500 - is Sun hardware too, you know
<avb> which is a complete fault
<calc> erast: ah i mispoke, i meant real sun hardware UltraSparc ;-)
<calc> :)
<erast> well its a matter of resources...
 * calc thinks Sun should just dump opensolaris and adopt a good userland like what nexenta appears to be
<erast> I actually compiled nexenta kernel for sparc - but haven't had enough time to package and bootstrap ISO
<avb> i wish to have a kernel clean like netbsd
<erast> calc: +1
<avb> but with all features of linux
<avb> :)
<NCommander> erast, I can help with the bootstrapping
<avb> and with a gnu toolchain for sure
<NCommander> But I think I should help with your buildd situation first ;-)
<erast> NCommander: to generate ISO, we using nexenta-builder package, take a look
<NCommander> Well, I think you need to build the packages first ;-)
<calc> personally i think they should dump the kernel too for x86/amd64 and contribute to FLOSS properly, but that may be going a bit too far ;-)
<erast> NCommander: yes... a lot of missing dependencies in Hardy repo..
 * NCommander has his development toolchains reinstalled
<NCommander> :-)
<calc> and open up stuff like ZFS so linux can use it :)
<NCommander> now to figure out what else I need to reinstall
<avb> yeh
<avb> and fuck licensing bullshit
<persia> !ohmy
<ubottu> Please watch your language and topic to help keep this channel family friendly.
<erast> calc: the problem with ZFS & Linux is that Linux "layers" needs to be totally redesigned
<avb> BSD can be used in GPL
<avb> cant
<avb> thats a joke
<Vger_> BSD can be used in GPL code
<avb> persia: sorry :)
<Vger_> GPL can't be used in BSD code
<calc> erast: well if the licensing was open, which aiui it isn't
<avb> Vger_: ZFS is BSD, not?
<Vger_> I'm not sure
<erast> huge portion of ZFS dual licensed GPL/CDDL
<calc> erast: aiui from reading a few months ago ZFS is patented to hell and not licensed so that it could be in the kernel in any case
<avb> ah
<avb> ok
<Vger_> I thought it was under Sun's open source license
<avb> anyway
<calc> erast: oh maybe they improved it since i read then
<erast> GRUB zfs module is GPLed
<avb> its realy terrible
<Vger_> Yes
<avb> all this licensing issues
<calc> erast: yea the GRUB bit is ok afaik, just not the fs driver itself
<avb> even free licenses cant be mixed
<calc> oh well i'll just wait for ext4
<avb> what we can talk about the rest of them
<Vger_> Opensource has created its own restrictions that's more vile than proprietary code
<erast> its pretty much all you need
<Vger_> But it's our own fault.
<calc> avb: they can just not Sun's
<Vger_> For being dumb :(
<Vger_> And listening to Stallman
<calc> licensing proliferation is bad
 * Hobbsee wonders if this is really related to ubuntu development?
<calc> all there really needs to be is BSD/LGPL/GPL :)
 * calc shuts up since this is way off topic
<Vger_> This is an awesome topic!
<Vger_> Moar!
<NCommander> I would consider nexenta somewhat ontopic, it is an Ubuntu derivative
<Hobbsee> NCommander: by the same logic, we should provide support for things like medibuntu in #ubuntu, and that doesn't happen either.
<erast> NCommander: yeah, but CDDL vs. GPL vs. BSD debates - not really...
<calc> btw if anyone needs a new computer this is a pretty good deal: http://www.buy.com/retail/product.asp?sku=209217089&adid=17653&dcaid=17653
<Hobbsee> Vger_: more in #ubuntu-offtopic.
<calc> someone showed me it earlier today
<NCommander> What's the default font on Ubuntu for menu titles?
<Vger_> Not bad
<avb> heh
<avb> no i see why ubuntu is so slow :)
<avb> now
<Vger_> Slow?
<avb> quad core cpu, 6gb ram is not bad :)
<pwnguin> because developers buy quad core computers and dont notice when it's slow ;)
<Vger_> lol
<calc> NCommander: whatever default maps to Sans (I think)
<avb> yeh, on mine brand new core2duo 1.6 its slow
<calc> NCommander: playing with fontconfig probably would tell you somehow
<Vger_> I thought the developers were too busy playing games on their new quad core computers to notice Ubuntu is slow
<avb> and cpu is always hot
<avb> its not about ubuntu
<NCommander> Well, I changed it, and now I don't know what it was ;-)
<avb> its about developers
 * Hobbsee also, wonders how this is related to ubuntu development.
<calc> Ubuntu isn't slow on a quad core ;-)
<avb> :) auch
<avb> its better for me to go to offtopic
<calc> i'm going to upload new OOo whenever i get license go ahead from Sun
<pwnguin> well obviously, we're going to make jaunty fast by requiring really expensive hardware
<Vger_> Stop starting things you can't finish!
<calc> hopefully tomorrow morning before the platform meeting
<erast> ok, i wonder how nexenta patches could be integrated with ubuntu, so we don't have to rebuild LTS each time it released?
<calc> pwnguin: fast boots with required SSD's ;-)
<pwnguin> you know, ive got a couple years worth of bootcharts now
<Vger_> pwnguin, Ubuntu is going Windows Vista route?
<avb> pwnguin: little laptops cant be fast :)
<pwnguin> its too bad they're stored in png
<calc> iirc my current laptop can boot Hardy in around 20s
<pwnguin> by default?
<Vger_> I changed the bootup to load GDM first
<Vger_> So I can login and do things in the first 10 seconds
<Vger_> :p
<calc> pwnguin: yea, but i don't know if bootchart counts everything
<calc> pwnguin: iirc it was ~ 20s on bootchart
<NCommander> What command in ubuntu-dev-tools can grab things from a PPA easily
<pwnguin> bootchart counts to gdm sleep by default
<avb> and its totaly unusable for next 40 seconds more :)
<calc> pwnguin: i have a fairly stock install though
<Vger_> Why does Ubuntu need to load up cups and all the other crap before GDM?
<calc> i have a c2d 1.7ghz 4gb ram laptop
<calc> Vger_: it might not actually be doing what you think it is, or otherwise it probably has a good reason
<Vger_> I've never been able to find a good reason for it
<calc> Vger_: we looked at boot time stuff in several sessions at UDS in May
<calc> i'm sure there will be a lot of them in Dec at Google UDS as well
<avb> the best job in intrepid is a new mail storage format
<Vger_> So much could be solved for bootup in Ubuntu
<avb> it stop leaking
<StevenK> Vger_: Then bring it up at UDS :-)
<NCommander> hey StevenK
 * StevenK waves
<avb> that was pissing me off last 2 years
<Vger_> Like loading non-essential stuff in the background instead of waiting for it before you actually get to login and use the WM
<calc> Vger_: got a bootchart to show?
<Vger_> StevenK, might be a good topic :)
<NCommander> StevenK, KDElibs on amd64 was fixed at the cost of my home folder
<calc> Vger_: i'm pretty sure the stuff that is loaded before GDM generally needs to be, or you are reading the chart wrong
<StevenK> NCommander: kdelibs ate your ~?
<RAOF> NCommander: Yay? \-:?
<Vger_> Like what, postgresql and cups?
<TheMuso> RAOF: I just uploaded some git fixes for alsa-lib into my PPA. Let me know if anything changes.
<NCommander> StevenK, no, the instantly finally caught up with me
<Vger_> Why does that need to be loaded up before gdm?
<NCommander> I only lost a few class notes, so I'm not so screwed
<calc> Vger_: postgresql isn't in official Ubuntu
<StevenK> NCommander: EPARSE
<calc> Vger_: so it probably hasn't been tweaked
<NCommander> er, insanity
<Vger_> Yes, but if you install it
<Vger_> It will add to your bootup time
<calc> Vger_: not sure about cups
<RAOF> TheMuso: Cool.  I'll get to that in a couple of hours.
<calc> Vger_: well there are loads of things you can install from universe that will slow down boot most likely
<NCommander> Scott got the patch before the machine committed died
<Vger_> calc indeed
<Vger_> It shouldn't
<Vger_> But it does
<pwnguin> Vger_: its completely controllable whether it starts at boot or not.
<calc> Vger_: i agree that this should be fixed, maybe make a point of involving MOTU to help with some of the work
<NCommander> StevenK, know any good todos?
<pwnguin> but id argue postgresql should start at or near boot by default
<StevenK> NCommander: Things to do, or programs to manage a todo list?
<Vger_> pwnguin, yes it's controllable if you know how
<Vger_> Like I did
<Vger_> But most won't do it and complain Ubuntu boots up too slow
<calc> pwnguin: you could stick it towards S99 though
<pwnguin> what palent do people install postgres but not know where the services menu is?
<calc> pwnguin: if it starts in 20s or 60s its not too big of a deal
<pwnguin> planet even
<NCommander> StevenK, the former and later
<StevenK> NCommander: Oh, both? :-)
<calc> pwnguin: just because you can change it doesn't mean it shouldn't have logical defaults
<Vger_> pwnguin, surprisingly many
<StevenK> NCommander: I like Tasque for managing my todo list.
<NCommander> StevenK, yup
<calc> so i agree that all things that start on boot should have reasonable start up times to help keep boot time down but what those are for each package depends on what else uses them, etc
<pwnguin> calc: when im running a server, postgresql at startup sounds lke a reasonable default
<calc> and upstart, i think, should help a lot in this case
<RAOF> And the gnome-do tasque plugin makes it even more awesoem!
<calc> once everything is converted over to using upstart scripts
<pwnguin> i imagine upstart is going to be making a jump forward in jaunty
<Vger_> People are impatient that's for sure
<StevenK> RAOF: I'd like gnome-do more if it didn't leak like sieve
<avb> boot time is okay, the problem is productivity of a software
<RAOF> StevenK: The recent gtk-sharp upload should've fixed almost all the leaking.
<avb> terminal is loading like a second
<RAOF> StevenK: It wasn't our fault, honest! :P
<StevenK> RAOF: \o/
<avb> thats ridiculus
<StevenK> RAOF: I've not installed gnome-do on my desktop
<calc> avb: is that a regression in 8.10?
<avb> nautilus... i even dont want to talk about this crap
<RAOF> StevenK: For those playing at home, gtk# used to leak a pixmap each time you loaded an icon from the theme.
<calc> avb: for me gnome-terminal is well under 1s load on 8.04
<avb> calc: no, its a regression since gnome 2.0 :)
<StevenK> RAOF: The entire pixmap?
<RAOF> Yes
<calc> avb: maybe its a speed of computer issue? )
<calc> :)
<StevenK> Blink
<avb> c2d 1.66 :)
<StevenK> RAOF: Almost sounds SRU-worthy
<calc> avb: i have a c2d 1.73 and its fast as i blink pretty much
<NCommander> StevenK, are you on an SRU team?
<StevenK> NCommander: Nope
<calc> certainly not slow enough to be annoying to me anyway
<NCommander> StevenK, or willing to roll roughly 12-14 packages to hardy-proposed?
<NCommander> (I can give you debdiffs)
<avb> unfortunately there is no better laptop then lenovo x61 in the world
<avb> in other case i will have it
<avb> :)
<calc> things that annoy me are things like nautilus screwing up file timestamps on copies (setting them to current time)
<avb> calc: try xterm :)
<StevenK> NCommander: Eek!
<calc> avb: loads in roughly the same time for me, gnome-terminal or xterm
<Vger_> I prefer the Fujitsu T2010 than the X61 tablet though :P
<Vger_> But I love my T61p
<Vger_> Runs linux nicely
<StevenK> calc: You know cp does that by default, right?
<calc> StevenK: yea and cp can do something else if you tell it to, nautilus can't
<NCommander> StevenK, is that a no?
<avb> calc: once u have g-t opened, its pretty fast :)
<RAOF> StevenK: Maybe; it's a tiny patch (basically telling the code generator that, yes, you get ownership of the Pixbuf returned from LoadIcon)
<calc> and no other file manager on other OSes do that braindead stuff either
<StevenK> NCommander: That's ... insanity
<calc> avb: maybe that was the issue i already have it open for irc
<avb> yeh
<NCommander> StevenK, be happy, it was worse
<avb> cold start is realy slow
<NCommander> StevenK, four rebuilds, and eight patches to fix dependencies and one code change
<calc> i think i managed to make it take 2s to load
<StevenK> NCommander: For hardy-proposed?!
<calc> then it was in cache when i quit it and it loaded in < 1s
<NCommander> StevenK, we had a broken gnat package
<NCommander> StevenK, so every Ada package is broken
<NCommander> StevenK, the changes are minor, dependencies changes. Only two needed minor code changes to build
<calc> the nautilus crap makes me have to manage all my files in gnome-terminal (yuck)
<pwnguin> NCommander: so basically the risk of regression is best quantified "lol"
<calc> but at this point its not really nautilus itself at fault aiui its the gvfs backends that are buggy now
<NCommander> pwnguin, given the current packages are not even installable, I got to say regressions are nil
<calc> it works properly on local filesystem now when i last tested it but still screws up on things like smb:
<avb> calc: yeh. worm start is better. still i believe, that a lof of work should be done in pango and freetype
 * NCommander can see StevenK shaking in his shoes
<avb> coz im 80% sure that this is a problem
 * StevenK isn't wearing shoes
<NCommander> StevenK, figure of speech
<avb> and another issue what i hate is an open dialog speed
<avb> thats totaly unaceptable
 * Hobbsee stomps on StevenK's bare feet then.
<RAOF> NCommander: It's usually pronounced "Quaking in his little moonboots" :)
<StevenK> Hobbsee: Ouch!
<Hobbsee> avb: so, fix it?
<NCommander> well, does anyone want to help if StevenK runs away in fear?
<NCommander> ;-)
<avb> Hobbsee: yeh, im going :)
<avb> for now i just complaining for a bad life
<avb> :)
<avb> ok guys, was nice to talk, have a good day/night :)
<avb> 2am, time to sleep
<StevenK> TheMuso: So, why does libgtk2.0-dev Conflict against libgail-dev?
<TheMuso> StevenK: The gtk+2.0 package in intrepid contains libgail's functionality.
<StevenK> TheMuso: Ah ha. So the libgail-dev Build-Depends just gets dropped?
<TheMuso> Yep.
<StevenK> TheMuso: Sounds like a win for accessibility, if it's in the toolkit directly.
<TheMuso> Indeed it is.
<lamont> libgail-dev would get dropped if you also build-dep libgtk2.0-dev...
<StevenK> Damn it, sbuild. libtldl7-dev Provides: libtldl3-dev
 * TheMuso has felt for a while now that moving to a new libtool version was not worth it.
<NCommander> pitti, hi
<NCommander> Oh, lamont, hello
<NCommander> oh *****
<NCommander> pitti, I want to warn you there is going to be a fairly large (for -proposed) upload coming
<dholbach> good morning
<lamont> StevenK: versioned provides do not exist...
<StevenK> lamont: Oh, duh
<RAOF> That's sometimes bugged me.  Is there some technical reason why versioned provides don't exist, or is it just another possible feature waiting to be implemented in dpkg?
<NCommander> StevenK, its anonying
<NCommander> RAOF, I'm told the design of dpkg makes it difficult (I asked about that awhile ago)
<NCommander> RAOF, but I'm honestly not sure
<persia> RAOF: Consider the case where foo build-depends on bar >= 0.8 and baz 0.1 provides bar.  Should baz Provide bar-0.8?  what happens if something seeks bar-0.9?
<NCommander> lamont, got some time to talk?
<RAOF> persia: So you manually bump the version it provides, in much the same way as you'd currently bump the shlibs
<RAOF> Specifically, the version of bar that baz provides is a piece of package metadata that is independent of the package version of baz.
<persia> RAOF: OK.  I can accept that argument.  Now, check how dpkg handles versions and dependencies, and fix it :)
 * RAOF is too suceptible to adding stuff to his TODO list.
<RAOF> I was actually thinking: Hm... it's been a while since I've played C++.  Maybe I'll do that.
<RAOF> With the one small problem that there's no way I'd get around to it!
 * NCommander apt-get source's dpkg's source code
<NCommander> persia, that being said, dpkg upstream been VERY difficult to work with to the point driving other contributors away
<NCommander> (there was a massive funk on this on the d-devel mailing lists)
<StevenK> Since when?
<NCommander> StevenK, since at least the current maintainer took over. THere was a massive battle of egos on debian-devel
<persia> NCommander: I refuse to believe anyone's assertion that another is difficult.  My experience has always been that human compatibility is not transitive
<NCommander> I'm just summarizing what transpired on d-devel, which ended with an attempted hijack of dpkg
<lamont> RAOF: given that package A and B have no relationship in version numbers (generally), having versioned provides becomes problematic if you want to describe versions in there
<lamont> and besides, why make the build system more complicated than it needs to be, esp when you can say A | B (>=ver) ?
<NCommander> lamont, it's more of an issue of transitional packages
<lamont> NCommander: burning through email before heading to a meeting
<NCommander> lamont, when xfce 4.5.80 was packaged, a versioned provides would have removed the requirement for transitional packages so Replaces would work
<lamont> NCommander: certainly there are cases where versioned provides would be useful.
<NCommander> (on the other hand, if there was a way to force Replaces to work even if there is no change to system state would be nice)
<lamont> OTOH, that way lies madness. :)
<NCommander> lamont, at some point, I'd like to talk to you on the topic of Ubuntu porting (as in porting to new architectures)
<lamont> Replaces: doesn't do what you think it does then... .:-)
<lamont> since it's purely a "if that package and I both provide the file, then I win
<lamont> "
<lamont> NCommander: ah, sure - in UK this week, which makes for some wonderful time slew
<NCommander> Sorry, I'm thinking conflicts unless my memory is going
<NCommander> Its 02:30 here
<lamont> and pretty much putting in 14+ hour days between everything that's going on
<RAOF> lamont: There would certainly be cases where versioned provides would break down, but for the fairly common case of "yes, I, libfoo really do provide a libbar interface compatible with >= 2.3" it'd be nice.
<lamont> RAOF: yep.
<NCommander> lamont, generally speaking, I have a desire to do a port of Ubuntu to either ppc64 or MIPS(el)
<NCommander> RAOF, well, Breaks is a step in the right direction which at least removed the need for versioned conflicts
<StevenK> I thought versioned Conflicts worked
<RAOF> They do, don't they?
<RAOF> Breaks is for a different purpose, AIUI
<NCommander> StevenK, they do, but they are greatly depreciated by upstream
<NCommander> (er, Debian)
<NCommander> There is a mark in the latest policy guide not to use a versioned conflicts unless absolutely impossible to avoid, and to consider using Breaks instead
<lamont> NCommander: steps (for your more simple case): 1) start with something older that works - say etch, 2) drop a build-essential chroot of etch on the machine, and start building toolchain bits for intrepid (or hardy, better yet), iterate until you've built everything in the chroot from the current release. 3) do it all over again starting with your results from (2).
<NCommander> lamont, no, that part I know, I've done it before
<lamont> NCommander: ah, cool
<NCommander> lamont, I meant more the part on getting it on ports.u.c ;-)
<lamont> ah...
<NCommander> lamont, (I did a rebootstrap of amd64 out of total boredom from scratch; no debian)
 * NCommander thinks he did four rebuilds
<NCommander> before the result was installable
<RAOF> That wasn't boredom though, was it?  That was build-the-world-with-PIE?
<NCommander> RAOF, yeah well, when I got stuck, I spent five hours on a train doing that
<NCommander> RAOF, so I had a general idea what to do if I could work out the toolchain issues
<NCommander> I don't mind running dak or something, but if it was possible to get a port to be "blessed" with at least being hosted by canonical
<lamont> that part is simple-ish: 1) work out with folks, and ship not less than 3 machines to the data center (4 preferred)  of course, you'll need to make sure that people believe in things enough to provide rack space and such for said machines.  2) work with the buildd guy (that'd be infinity) to point him at an archive for him to do the DC bootstrap from
<NCommander> lamont, ouch, for ppc64, I guess I could send canonical four PS3s ;-)
<StevenK> And rack them how?
<RAOF> Under the TVs, surely.
<NCommander> StevenK, someone made a rack for PS3 since they were doing cell work on them
<StevenK> RAOF: And how many TVs have you racked? :-D
<NCommander> StevenK, they made a mount so it could be placed in a U3 rack I think
<RAOF> StevenK: 1!
<lamont> 3U each? ouch
<StevenK> RAOF: !?
<lamont> OTOH, that beats 9+U
<StevenK> lamont: What in the DC is 9+U?
<NCommander> lamont, it was awhile ago
<lamont> StevenK: besides the ciscos?
<NCommander> lamont, anyway, I dont have $PS3_PRICE*4
<StevenK> lamont: Yup
<lamont> dunno - the tour hasn't happened yet
<NCommander> lamont, I really really want armel, to the point having started that port before getting fed up with my slow as hell ARM box, and I'm told that one is getting done soon-ish
<pitti> Good morning
<StevenK> pitti!
<pitti> NCommander: heh, ok
<NCommander> pitti, we're working to fix the Ada packages on Hardy
<StevenK> NCommander picked on me.
<NCommander> StevenK, it could be worse
<slangasek> StevenK: versioned conflicts work on an individual level.  When you get an archive full of them, your dist-upgrades look like "remove the world" if using apt-get, and "duh, I think you told me not to do anything" if using aptitude
<StevenK> Haha
<lamont> moof
<lamont> NCommander: so.. you were saying?
<lamont> hrm... actually time for me to head officewards - back online in about 15-20 min
<NCommander> lamont, well, you explained it that Ubuntu must always host the buildd machines (I thought hppa for some reason was done outside at first)
<lamont> it was
<lamont> and hosted on people.ubuntu.com/~lamont/hppa/$mumble
<NCommander> lamont, ah. I see. I figure at point I'll do the port, and then run a donation drive for the Canonical DC :-)
<lamont> NCommander: yeah - it's best to get a port together and get a community behind it first, and then pursue getting it into the datacenter and such - a much easier path
<NCommander> lamont, well, I plan to do an armel port if I don't see something before intrepid+1 opens, mostly because I want to do a netbook remix port for internet tablets
<lamont> the other path is harder, and results in people asking why anyone should care about a port that maybe 6 machines in the world are using...
<lamont> OTOH, 3 of those machines are buildds. :-)
<NCommander> lamont, or the 20 m68k Debian buildd cluster
<NCommander> (be warned, I will probably try and port Ubuntu to m68k ....)
<lamont> s/20/70 or so/ last I heard
<StevenK> Noooooooooooooooo
<lamont> StevenK: he's welcome to try porting it.
<StevenK> Damn doorstep architecture
<NCommander> StevenK, yes, I do Ada and m68k
<lamont> when it breaks, we'll laugh at him when he files bugs
<lamont> anyway.  afk for 20 min or so
<StevenK> Haha
<NCommander> StevenK, I fix everyones FTBFS, in retrospect, its not that big of a quirk
<wgrant> pitti: Isn't there a more feasible solution for keeping virtualbox unbroken in hardy? Say, adding a rebuild of the modules to the ABI bump process? Not that hard...
<pitti> wgrant: that would require the kernel team to "adopt" the package
<wgrant> pitti: For very restricted values of "adopt".
<wgrant> Alternatively, there could be a more sane SRU process for kernel module rebuilds, and the appropriate maintainers could be notified of ABI bumps before the world breaks.
<NCommander> wgrant, you do know virtualbox has a setup script to do extactly that?
<NCommander> (/etc/init.d/vboxdrv setup)
<wgrant> NCommander: We have packages as well.
<NCommander> We do?
<NCommander> That's news
<wgrant> Yes.
<wgrant> virtualbox-ose-modules-*
<wgrant> DKMS is the ideal solution, but that luxury is not had in Hardy.
<NCommander> wgrant, DKMS just got backported
<NCommander> wgrant, maybe as an exception it can be introduced as a new package via -updates
<wgrant> I don't really think that rewriting a package is ideal for an SRU.
<NCommander> wgrant, I don't know anything about DKMS, I was just suggesting
 * lamont returns
<lamont> dear gnome keyboard, if I suspend the laptop for 20 minutes, that should _SO_ count as a break. kthx
<superm1> someone still needs to DKMSify the intrepid virtualbox package anyhow too
<RAOF> Heh.  The break's not for you, it's for GNOME.  And as far as it's concerned, no time has passed!
<lamont> meh. ntp snapped time forward - that's time passing
<RAOF> TheMuso: Hm.  Pulse seems to die trying to load module-esound-protocol-unix.
<RAOF> pulseaudio -vvv doesn't seem to be terribly verbose about the problem.  I wonder if it's the missing link to libauth-cookie.so that ldd can't find?
<NCommander> lamont, have you returned?
<pochu> dholbach: thanks for the sponsorship!
<NCommander> dholbach, how much do you know about SRUs?
<seb128> NCommander: oh you are hiding now?
<NCommander> seb128, after I blew away ~, yes
<seb128> NCommander: SRUs are described on the wiki
<NCommander> seb128, er, I need someone to sponsor SRU uploads to -proposed
<seb128> NCommander: oh? how did you do that?
<seb128> NCommander: bug #nnnn?
<NCommander> seb128, didn't check to make sure my backup was actually readable
<NCommander> seb128, its one bug, 11 packages
<seb128> what are the changes about?
<NCommander> seb128, Hardy shipped with gnat-4.2 which broke most of the ada packages in Hardy
<NCommander> Mostly because the previous maintainer hardcoded gnat-4.1 all over the place
<lamont> NCommander: yeah, sitting in a meeting
<NCommander> I fixed the dependencies, and added code patches to get the rest building
<NCommander> (its relatively small changes all around)
<seb128> NCommander: do you have a bug number describing the changes, etc?
<NCommander> seb128, there is a spec on the wiki that was approved by a member of motu-sru, I did the work with his approval, but he hasn't been on in awhile, and I'd like to at least get these into proposed
<NCommander> seb128, https://wiki.ubuntu.com/HardyGnatTransition
<seb128> NCommander: did you read https://wiki.ubuntu.com/StableReleaseUpdates ?
<NCommander> seb128, yes, all packages have proper X.1 versioning strings
<seb128> NCommander: need a bug explaining the changes, etc before uploading, I'm fine doing sponsoring if you have the bug open, the debdiff attached, etc
<NCommander> seb128, hold on
<NCommander> seb128, I was told by SRU however for binary rebuilds on packages that don't have an ubuntu version string to use Xbuild0.X
<seb128> NCommander: right, "build" means it'll be overwritten by syncs automatically
<NCommander> seb128, yeah, its two binaries rebuilds, and nine minor patchs
<NCommander> seb128, https://bugs.edge.launchpad.net/ubuntu/+bug/268260
<ubottu> Launchpad bug 268260 in ubuntu "GNAT 4.2 Transition Tracking Bug" [Low,In progress]
<NCommander> gnat-gps is a rather odd issue
<NCommander> It's got a major policy violation in it as of right now (in hardy), it doesn't follow the python policy at all
<NCommander> I can fix it, but its a very invasive change since I need to do some heavy patching to the build system to fix it
<seb128> NCommander: alright, let's word it differently, when you have a task for a package update and a debdiff closing this task ready to upload attached to the bug I'll review and sponsor it
<NCommander> seb128, so you want me to attach all 11 debdiffs to these bugs?
 * NCommander has already rerolled the source packages w/ proper versioning strings so its not that difficult
<seb128> NCommander: SRU uploads require paper work, proper tagging, testing, etc so yes, read the wiki page if you didn't
<seb128> NCommander: we need to be able to review updates and track which ones have been tested, etc
<NCommander> seb128, I've done SRUs before, but never did them inmass, I was under the impression if its a single issue affecting multiple packages a single bug will do
<NCommander> Let me fix that now then
<NCommander> seb128, do I need to discuss tag creation on the lists?
<seb128> NCommander: each package needs to be tested though
<seb128> NCommander: what tag? no, you are free to use tags as you want
<NCommander> Ok
<NCommander> Launchpad doesn't have a link-bugs feature, does it
<NCommander> seb128, it should be noted in advance some of these packages depend on each other, I'll try to note the order of what depends on what
<NCommander> seb128, https://bugs.edge.launchpad.net/ubuntu/+source/asis/+bug/268458
<ubottu> Launchpad bug 268458 in asis "GNAT 4.2 Hardy Transition" [Undecided,New]
<ogra> \sh, bah, you stole my idea blogging the duerer drawing :)
<NCommander> seb128, https://bugs.edge.launchpad.net/ubuntu/+source/libaws/+bug/268260 - this is quickly becoming the bug from hell
<ubottu> Launchpad bug 268260 in gnat-4.2 "GNAT 4.2 Transition Tracking Bug" [Low,In progress]
<seb128> NCommander: that's alright, but since I've already lot to do and those are universe I'm pondering letting the sponsoring to MOTUs ;-)
<stefanlsd> seb128: whats your feelings on getting the 2.5.1 pidgin into intrepid. couple of people have been using my PPA and reported no problems.  Or will we rather wait for debian?
<seb128> stefanlsd: no feeling I'm overworked and didn't have time to look at it yet, still working on the GNOME 2.23.n updates
<stefanlsd> seb128: oki.  tell them to not work you so hard  :)
<\sh> ogra:  ;)
<asac> Riddell: http://paste.ubuntu.com/45232/
<asac> any idea?
<pitti> tseliot: any chance you could do a proper release of x-kit (or use the current version) and put the tarball on launchpad.net?
<pitti> tseliot: e. g. look at https://edge.launchpad.net/jockey, there you have the 'trunk' series, various releases from that, and "downloads"
<NCommander> asac, that's pretty
<pitti> tseliot: I updated README.txt for s/guidance/xkit/ and need to put in a download URL
<tseliot> pitti: sure
<pitti> tseliot: if you register the 'trunk' series and make it the 'default' series, then "bzr get lp:x-kit" would start to work, too
<pitti> (I think you still have to link the branch against the series for that, though)
<tseliot> pitti: something like this? https://launchpad.net/xorgparser/0.3
<pitti> oh, it's xorgparser, not x-kit?
<pitti> I looked at https://edge.launchpad.net/x-kit
<tseliot> pitti: no, x-kit is the whole project
 * NCommander falls
<NCommander> seb128, ok, bug report from hell filled out
<tseliot> pitti: and BTW you can do bzr branch lp:xorgparser
<pitti> tseliot: right, I tried with x-kit, since the source package is x-kit, too
<tseliot> pitti: yes, that's the only part of X-Kit which I have released so far
<tseliot> pitti: I know, it's a bit confusing
<pitti> ok, nevermind
<pitti> I put in https://launchpad.net/xorgparser/+download as download URL
<pitti> tseliot: I fully reviewed your x-kit branch, fixed another bug (in disable() you changed the indentation of xorg.conf writing, which caused it to be written only if there previously was a device section)
<tseliot> pitti: how do I put a tarball in that link?
<tseliot> pitti: ah
<pitti> tseliot: https://edge.launchpad.net/xorgparser/trunk, click on 'register a release'
<pitti> oh, there is already one for 0.3: https://edge.launchpad.net/xorgparser/0.3
<pitti> tseliot: on that page you shold have "add download file" or so (I can't see it since I'm not the project owner)
<pitti> yep, that's where i see it in jockey, so it should be there for you
<NCommander> hey TheMuso
<pitti> tseliot: chasing the test regressions now
<tseliot> pitti: ok, I'll do a release so that your link can actually work.
<pitti> tseliot: many thanks
<tseliot> pitti: good, if you need a hand with that, I'm here
<RAOF> Yeah.ls
<RAOF> ENOTSHELL
<RAOF> You know, it'd be cool if irssi silently ignored shell commands :X
<Riddell> asac: mm, no, where's the admin directory from?
<asac> Riddell: from knetworkmanager svn
<asac> Riddell: let me check something
<Riddell> asac: fresh checkout and make -f Makefile.cvs works fine here
<asac> Riddell: yeah. most likely because build-dep doesnt succeed to install
<vovkav> hi! What is the easiest way to profile the entire linux system with large granularity? Just to see how much time is spent in kernel-libc-libxxx-apllication?
<asac> Riddell: dpkg: error processing /var/cache/apt/archives/kdelibs4-dev_4%3a3.5.10-0ubuntu1_amd64.deb (--unpack): trying to overwrite `/usr/bin/ksvgtopng', which is also in package kdebase-runtime
<asac> Riddell: is kdebase-runtime old and there is a missing conflict?
<Riddell> asac: ksvgtopng should be removed from kdelibs4-dev (and has been but there's a compile error)
<Riddell> asac: you can safely --force-overwrite
<asac> Riddell: ok
<asac> i removed kdebase-runtime now ... apparently didnt hurt. now i have all build-deps. lets try
<asac> Riddell: all find. sorry for the noise ;)
<asac> fine
<Riddell> yay
<asac> Riddell: now it bailed out with:
<asac> knetworkmanager-openvpn.h:34:39: error: knetworkmanager-vpnplugin.h: No such file or directory
<vovkav> hi! What is the easiest way to profile the entire linux system with large granularity? Just to see how much time is spent in kernel-libc-libxxx-apllication?
<wgrant> Hmmmm. My laptopload cycle count
<wgrant> Er.
<wgrant> My laptop's load cycle count has just started increasing rather rapidly.
<NCommander> wgrant, would you like to help me upload some packages :-)
<wgrant> NCommander: I'm rather busy with uni work, sorry.
<NCommander> wgrant, Sure, no issue. I just need to find someone who likes doing SRU work :-)
<Riddell> asac: are you doing builddir!= sourcedir?
<asac> Riddell: huh?
<asac> Riddell: i used the commands you gave me
<asac> and ran make in the same directory
<asac> ./configure --prefix=...
<asac> Riddell: should i do something else?
<kwwii> asac: is there any way that Firefox could use a different skin when the gnome theme changes?
<Riddell> no, that should be fine
<asac> Riddell: config.status:s,@KNETWORKMANAGER_CFLAGS@,|#_!!_#|-I$(top_srcdir)/src,g
<asac> looks ok
<asac> Riddell: hmm
<lool> Blah my desktop hung up again and nothing in the logs
<asac> kwwii: what are you trying to achieve?
<asac> kwwii: fix theme bugs in a skin?
<cjwatson> asac: re yesterday, indeed both interfaces have been given the same metric. I attached stuff to bug 262152
<ubottu> Launchpad bug 262152 in network-manager "brings up both wired and wireless interfaces; hard to pick just one through the UI" [Medium,Triaged] https://launchpad.net/bugs/262152
<asac> cjwatson: ok thanks. would a fixed metric be good enough to fix your use-case?
<kwwii> asac: well, I have other themes which need a skin to look right...the idea is that when I select the theme firefox should also look ok without having to select the theme everywhere
<asac> kwwii: yes i understand.
<asac> kwwii: but no, changing skin on theme change doesnt work
<asac> kwwii: can you identify which elements are not configurable in gnome theme?
<asac> i think the right approach is to look if those can be made configurable
<cjwatson> asac: I just tried fiddling the routing table and that doesn't seem to help
<cjwatson> asac: I think the problem might be that (if you look at the routing table I attached) I still need to use hosts on the wireless subnet, but I would prefer to do so via a wired route when an Ethernet cable is attached; for example my nameserver is 172.20.153.2
<Riddell> asac: meh, it compiles for me whatever I do
<asac> cjwatson: metrics worked quite well in the past for me
<asac> cjwatson: oh. so its not a packet loss issue
<kwwii> asac: until now the biggest problem is the url entry box and teh menu that drops down from it I think
<cjwatson> asac: well, it is though. When I have both interfaces up, packets sent to 172.20.153.2 don't come back
<cjwatson> asac: oh, sorry, ignore that last bit, I screwed up
<asac> cjwatson: from what i see your routing table only has one default route
<asac> so there shouldnt be any metric required
<cjwatson> asac: hm, should I have a default route for eth1? I'd rather not - eth0 can get to every host that eth1 can
<cjwatson> and the less I use wireless, the better wireless works for those hosts that need it
<asac> cjwatson: right. thats correct
<cjwatson> (I'm on the edge of the tolerances for my router)
<asac> cjwatson: and if NM behaves that way i dont see what is wrong
<cjwatson> right now, this ssh connection to 172.20.153.17 is going via wireless
<asac> ah
<cjwatson> oh, hmm, metrics are the other way round from what I was thinking, aren't they?
<cjwatson> the higher the metric, the less the link will be used
<asac> yes
<asac> cjwatson: but that only works if there is a tie-break required
<asac> so maybe 172.20.153.0    0.0.0.0         255.255.255.128 U     0      0        0 eth1
<asac> just pulls in everything for that subnet
<cjwatson> asac: yeah, it seems to
<cjwatson> I bumped that metric to 10, but it still wins
<asac> cjwatson: did you explicitly setup this subnet split in your dhcp servers?
<cjwatson> yes
<asac> cjwatson: what were the reasons to make wireless serve a different internal subnets?
<asac> and why is the dns server in the wireless net?
<cjwatson> I have a strange setup because I have a wireless router downstairs, and have never got round to running a wire upstairs so the machine that I actually want to use as a default router and DNS server (because it understands VPNs and the like) is connected to the rest of the world by wireless
<cjwatson> it's backwards from most people's, but it's necessary until I get round to more physical layer work
<cjwatson> the different subnets gave me control that I found I needed to make it all work; and it did work fine until n-m came along and decided it could have both interfaces up at once :)
<asac> cjwatson: ok. just wanted to ask if the subnets split is really required
<cjwatson> for now, yes
<cjwatson> oh, plus I understand subnetting better than I understand Ethernet bridging; I prefer that sort of thing to be explicit :)
<cjwatson> I suspect that, in general, with a crowded wireless network that's having trouble coping at the best of times, subnetting puts less load on it than bridging would
<cjwatson> since the wireless network only needs to see packets definitely destined for it
<asac> cjwatson: ok. ill show that routing table to the NM master and see what he thinks. i doubt however that this is the "use-case" he asked for to convince him to introduce an "old" mode feature
<asac> or to add more complexity to the UI.
<asac> cjwatson: you can certainly disable your wireless network by right clicking ;)
<Riddell> asac: oh, I have network-manager-kde installed and it's using the knetworkmanager-vpnplugin.h from that
<asac> but i see that this might be cumbersome
<cjwatson> it sucks
<cjwatson> asac: it shouldn't be looked at as an "old" mode. This is a regression
<asac> cjwatson: i agree that his arguments arent really consistent
<asac> cjwatson: a) he always says that NM is only useful for managing your primary network connection
<asac> b) he says that he doesnt see the case for the 0.6.6 behaviour.
<asac> but lets see.
<asac> maybe this can convince him
<asac> Riddell: ok ;)
<asac> Riddell: so top_srcdir is wrong?
<Riddell> yes
<asac> Riddell: http://paste.ubuntu.com/45256/
<asac> ?
<Riddell> asac: yep
<asac> Riddell: ok that fixes that
<asac> Riddell: now i end up in http://paste.ubuntu.com/45257/
<asac> Riddell: can you commit that fix?
<cjwatson> asac: I want NM to manage my primary network connection. It's just that depending on the situation that might be one of two interfaces. This isn't unusual, is it?
<cjwatson> in fact I thought that was NM's core usefulness
<liw> isn't that the case for every laptop with both wired and wireless?
<asac> cjwatson: right. Ill talk directly to dan about this as soon as he is online
<asac> cjwatson: i only talked to his co-worker about this last time
<cjwatson> thanks
<asac> who mostly knows what dan williams wants ... but only mostly
<asac> Riddell: so whats the right/outdated signature? the one in vpnplugin.h or in openvpn.cpp ?
<Riddell> asac: that's the question, upstream left it between the two
<Riddell> asac: I think QMap<QString, QString> is the new one
<Riddell> asac: yes, according to r848503 'Again NM API changes (breaks all VPNPlugins)'
<asac> Riddell: good. so he forgot openvpn
<asac> lets see if i can temporarily disable it
<tkamppeter> pitti, hi
<Riddell> asac: try  --with-openvpn=no
<Riddell> to ./configure
<asac> Riddell: int OpenVPNConnectionType::mapConnectionType2String(CONNECTIONTYPE connType)
<asac> hehe
<asac> confusing function name
<TheMuso> RAOF: Hrm. The module should be present in /usr/lib/pulse-0.9/modules. Got any more info, or have you attached it to the bug already?
<TheMuso> RAOF: ah, you emailed me, thanks.
<asac> Riddell: ok enabling/disabling wireless works
<asac> Riddell: how knetworkmanager supposed to work? i dont see any APs in the applet drop down
<asac> Riddell: is there a way to make knetworkmanager more verbose?
<Riddell> asac: right click -> edit connections -> new connctions -> a list should be there
<asac> Riddell: yeah. that exists
<asac> Riddell: but activating such a connection doesnt do anyhting
<asac> but i dont see any error on the console either
<asac> (nor anything on NM side)
<Riddell> asac: I don't think it has much in the way of debug output
<ogra> asac, so if i run a dhcp server on my desktop machine (i.e. on ltsp servers) i see some issues ... could it be that NM starts the static interfaces from /e/n/i very late in the bootprocess ?
<Riddell> asac: do you have anything listed in the New Connections dialogue?
<asac> Riddell: yes. thats all working
<asac> Riddell: what isnt working is the "ActivateConnection" dbus call. i get the callback, but i am not sure where the signal emitted there is dealt with
<asac> Riddell: emit ActivateConnectionAsyncReply(_asyncCallId, _active_connection);
<asac> Riddell: who is listening for that?
<TheMuso> ogra: Did you get my message earlier about your casper changes and a bzr branch? You had a different nick, so you may not have.
<ogra> no, i didnt
<TheMuso> ogra: Oh ok. Was just wondering whether you had your changes somewhere in a bzr branch so I can merge them back into trunk, as Colin gave me a tarball of what he had as the latest bzr branch.
<TheMuso> ogra: It would be nice to have them logged properly, instead of something like "merge changes back from oliver" :p
<ogra> the casper branches i looked at were all broken
<ogra> and nobody could tell me where the actually used branch is
<TheMuso> ogra: Yeah, but I think its possible to push to if you have a local copy.
<Riddell> asac: nothing (according to grep)
<TheMuso> i could be wrong though
<Riddell> asac: the whole of src/dbus/ files seem to be new since the current version in the archive
 * TheMuso discovers that Colin hasn't actually pushed his casper changes to LP...
<ogra> TheMuso, right, there is something wonky wiht the casper branch ... some error in importing from the old bazaar
<TheMuso> yeah I know
<ogra> and indeed i use to make my changes in a local copy via bzr pull ... but pushing that didnt work
<ogra> i think i have the debdiff lying around somewhere, so it shouldnt be hard to generate something out of that for a time where the branch is fixed
<TheMuso> ogra: Getting the debdiff is no problem.
<cjwatson> TheMuso: hmm, I haven't? oh well, you have the branch, you can push it
<ogra> cjwatson, wjere to  ?
<ogra> *where
<ogra> i wasnt able to push to the ones i found on LP
<TheMuso> cjwatson: Right, I thought it was a case of tried, but failed.
<cjwatson> ogra: I've been able to commit to the branch on LP OK
<ogra> hmm
<ogra> weird
<cjwatson> the branch is screwed, though; not an LP problem as such
<ogra> i know i tried to push to the one owned by ubuntu-core-dev
<ogra> and that didnt work
<cjwatson> don't fret too much about it
<asac> Riddell: yeah. ill look into it
<ogra> well, i dont want my changes being lost  :)
<asac> Riddell: first step is updating the introspection files ... which also should reveal the actual api changes required
<ogra> in case someone only uses the branch and not the source package
<cjwatson> https://bugs.edge.launchpad.net/bzr/+bug/246880 is as far as I've got
<ubottu> Launchpad bug 246880 in bzr "ghost fetch issue: fail when fetching a text referenced by a live revision introduced by a ghost revision" [High,Triaged]
 * TheMuso subscribes to that bug.
<ogra> kwwii, did you notice that the gnome-control-center shell app has a hardcoded white background ?
<lool> cjwatson: Should the current trunk be moved on the side (or shall we move to a new branch) to continue development in bzr and keep the data for bzr's upstream to look at later?
<ogra> kwwii, its very hard to read the golden fonts on it in the dark human theme
<TheMuso> lool: I was thinking of the same thing, but haven't bothered because I haven't had to touch casper till now.
<cjwatson> lool: that's an option, but I've escalated to poolie now, let's try to exhaust that first
<lool> cjwatson: Thanks
<cjwatson> lool: if we do get stuck I could use bzr fast-import to give us all the history at least since we switched to bzr
<cjwatson> it'd break any existing branches of course but since the trunk is screwed there are hardly any of those
<seb128> NCommander: new pangomm and gtkmm versions available
<pitti> hi tkamppeter
<MacSlow> Anybody with an intel Pro/Wireless 3945ABG wlan-nic working under interpid (2.6.27-2-generic)?
<Riddell> mvo: update-manager bzr seems out of date with the archive
<Riddell> MacSlow: lspci tell me I have  03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection
<Riddell> MacSlow: works here with 2.6.27-2-generic
<MacSlow> Riddell, *sigh*
<Riddell> MacSlow: not using knetworkmanager are you? :)
<MacSlow> Riddell, I only have it working for about 1 minutes and then get numerous timeouts of the iwl3945 modules reported in the output of dmesg
<MacSlow> Riddell, correct I'm not running knetworkmanager :)
<Riddell> no timeouts in my dmesg
<MacSlow> Riddell, there's also not much showing up in reported bugs in launchpad ... I guess I'm once again the only person being exposed to this problem
<mvo> Riddell: oh?
<mvo> Riddell: let me check
<mvo> Riddell: fixed, sorry
<Riddell> mvo: glad it's not just me who does that :)
<mvo> Riddell: heh :)
<Riddell> mvo: I'm adding the midding update-notifier-kde.install file then uploading
<Riddell> missing
<mvo> Riddell: cool, thanks. I will probably do another upload today but I need to wait on niemeyer first
<Riddell> mvo: then I'll just commit and not upload
<ogra> cjwatson, hibernate to /dev/ramzswap is disabled, right ?
<ogra> (the compcache device)
<cjwatson> ogra: I don't remember doing anything explicit there
<ogra> oh, i thought you said that back at UDS even
<cjwatson> ogra: ... but apparently I'm just forgetful. Yes, it is disabled.
<ogra> ok
<cjwatson> oh, wait, looking in the wrong place
<cjwatson> ogra: drat. No, it isn't, but will be in just a moment
<cjwatson> (base-installer works that stuff out)
<ogra> good :)
<ogra> there was just a question how it affects hibernate and i couldnt remember if we actually did have it disabled
<cr3> cjwatson: your fix to dpkg enabled the automated testing to kick in again, thanks!
<jdstrand> cjwatson: hi! fyi, ufw and netboot d-i should be in good shape now
<jdstrand> cjwatson: I had a thought about integrating ufw into the installer. something along the lines of redhat's 'Enable firewall' with some rudimentary ports stuff. Is this something that you would be open to for intrepid+1?
<cjwatson> cr3: I didn't touch dpkg; you can thank jdstrand for his ufw fix
<cr3> jdstrand: ^^^ thanks :)
<jdstrand> cr3: heh, well, you can also blame me for the breakage... but your welcome! :)
<cr3> jdstrand: I don't blame breakage, these things happen during development :)
<siretart> does the ubuntu live cd autoload the kernel module dm_mod?
<emgent> happy network manager!
<emgent> Program received signal SIGSEGV, Segmentation fault.
<emgent> [Switching to Thread 0xb6f81730 (LWP 6857)]
<emgent> 0xb7f17545 in ?? () from /usr/lib/libnm-util.so.0
<stefanlsd> emgent: :)
<emgent> heya stefanlsd :)
<emgent> i have to go out now, see you later people
<lool> siretart: Last time I checked it didn't do so for me
<jdstrand> hi emgent!
<lool> siretart: I wanted to mount my lvm over md, I'm not sure how I solved it in the end; something like installing mdadm and lvm2 (the later probably installed), then udevadm trigger, then vgscan or something like that
<cjwatson> ogra: base-installer and ubiquity fixed so that /dev/ramzswap won't be selected for hibernation (at least after the next ubiquity upload)
<ogra> cjwatson, gracias :)
<siretart> lool: k, thanks
<tkamppeter> pitti, hi
<pitti> hey tkamppeter
<tkamppeter> pitti, bzr pull --remember bzr+ssh://bzr.debian.org/pkg-cups/cups/debian-trunk/ does not accept my password
<cjwatson> tkamppeter: is your Launchpad user name the same as your local user name?
<cjwatson> tkamppeter: if not, you want this in ~/.ssh/config:
<cjwatson> Host bazaar.launchpad.net
<cjwatson>         User till-kamppeter
<tkamppeter> pitti, Launchpad account or alioth (Debian) account?
<pitti> cjwatson: it's bzr.debian.org
<cjwatson> ... I'll shut up then - although the same principle applies
<tkamppeter> I tried also bzr pull --remember bzr+ssh://till-guest@bzr.debian.org/pkg-cups/cups/debian-trunk/
<tkamppeter> but I got
<pitti> tkamppeter: if you didn't set your alioth name in .ssh/config, try bzr+ssh://till-guest@bzr.debian.org/...
<cjwatson> I'm not sure that bzr.debian.org runs a smart server. Try sftp:// rather than bzr+ssh://.
<pitti> cjwatson: I use bzr+ssh://mpitt@bzr.debian.org, WFM
<lool> tkamppeter: Try to ssh till-guest@bzr.debian.org
<tkamppeter> pitti, this is what I tried. I got asked for the password, entered it, and got
<tkamppeter> Server does not understand Bazaar network protocol 3, reconnecting.  (Upgrade the server to avoid this.)
<pitti> tkamppeter: right, but that's just a warning, I get it, too
<pitti> bzr.d.o just has bzr 1.3
<tkamppeter> Then I got asked for the password again, entered it and got
<tkamppeter> bzr: ERROR: Not a branch: "bzr+ssh://till-guest@bzr.debian.org/pkg-cups/cups/debian-trunk/".
<pitti> which doesn't help to make it faster :(, but for political reasons I didn't put the debian bzr trunks onto LP (just a mirror)
<lool> tkamppeter: I use /bzr
<jcristau> tkamppeter: bzr.d.o/bzr/pkg-cups/...?
<lool> tkamppeter: Right you need a /bzr
<lool> bzr branch bzr+ssh://bzr.debian.org/bzr/pkg-cups/cups/debian-trunk
<jcristau> tkamppeter: /pkg-cups doesn't exist
<lool> Worked for me
<lool> Branched 543 revision(s).
<pitti> ah, indeed
<lool> tkamppeter: You might to run a ssh agent to avoid typing your passwords over and over again (or better use ssh keys)
<broonie> Well, you need the keys for the agent anyway.
<lool> uh right, I meant to present things the other way around
<lool> Anyway, use an agent, use keys, if possible use passwords on your keys :)
<tkamppeter> lool, I have upoaded my key to Alioth now.
<asac> StevenK: so NM how do you know that its nm-applet that kills your X?
<lool> tkamppeter: dumped hourly or so, might take some time to be up-to-date
<StevenK> asac: Because I click the applet and then X dies.
<tkamppeter> pitti, now I succeeded. I have broken it by a "bzr upgrade", but now I have deleted everything and I am starting over.
<pitti> tkamppeter: broken? upgrade doesn't work, due to its history of being a svn import, but it just fails, doesn't break
<pitti> tkamppeter: but good
<tkamppeter> pitti, can you make a new announcement, with correct paths and telling the users about the warnings?
<pitti> yes
<tkamppeter> pitti, I have uploaded the last change (patch from ion_ for bug 263049) to the bzr now. I had already uploaded it to SVN, but it seems that you had already converted the SVN before.
<ubottu> Launchpad bug 263049 in system-config-printer "CUPS test page does not display correct print job data. pstopdf filter needs improvements, test page needs some changes" [Medium,Invalid] https://launchpad.net/bugs/263049
<pitti> tkamppeter: oh, thanks
<ion_> Converted?
<tkamppeter> pitti, another question: I have always built CUPS by running svn-buildpackage from within the SVN repo directory. Is there an equivalent for bzr?
<ion_> bzr-buildpackage :-)
<pitti> tkamppeter: what ion_ said, but I have never used either so far
<pitti> tkamppeter: I just use debuild
<tkamppeter> pitti, does debuild also join the debian directory from the repo with the original source or do you do that manually?
<pitti> tkamppeter: no, I just unpack the orig.tar.gz into the source tree, just as with normal source packages
<pitti> debclean works :)
<pitti> but I should really try bzr-buildpackage some day
<ion_> By default, git-buildpackage refuses to build a source package if the tree contains uncommitted changes, which quite nicely prevents accidental uploads of local changes. :-)
<tkamppeter> pitti, I am installing it now.
<ion_> I assume bzr-buildpackage does that, too.
<ion_> git-buildpackage has pristine-tar integration, which is teh awesome.
<james_w> ion_: it doesn't, I had complaints about doing that
<tkamppeter> ion_, I had uploaded you last patch to SVN, without knowing that the SVN got EOL hours before. Today pitti told me that he has moved to BZR and his BZR repo did not contain your patch. So it seems that pitti has moved shortly before I committed your patch.
<pitti> tkamppeter: sorry, I am not allowed to change permissions on svn.d.o to lock down the svn repo
<ion_> I can rebase the patch against the current bzr HEAD. If you have the bzr URL handy, please paste it. If not, iâll look for it at launchpad myself.
<pitti> tkamppeter: but if that happens, I can easily merge new svn changes into bzr trunk
<siretart> pitti: perhaps a postcommit hook that always fails would do?
<tkamppeter> pitti, ion_, the patch is already manually committed into the bzr repo. It was small and simple to commit.
<ion_> Alright
<asac> StevenK: clicking on applet also triggers a scan. so the "going down" might be the applet, but might also be the driver
<asac> StevenK: is just X crashing? or the whole system?
<tkamppeter> pitti, but the postcommit hook which siretart suggests is a good idea, as someone else could accidentally upload into the SVN black hole.
<StevenK> asac: Ahh. X dies and comes back
<asac> StevenK: when you log in, first thing: killall nm-applet
<asac> StevenK: then when thats gone, start it from the console and capture stderr/stdout
<asac> maybe we can see something
<pitti> tkamppeter: well, it's not a black hole, we'll get commit mails
<ion_> https://code.edge.launchpad.net/~pitti/cups/debian-trunk ?
<asac> OR run it under a debugger ... which might catch the issue before X goes down
<pitti> tkamppeter: in practice, the two of us are the only ones who commit nowadays
<pitti> ion_: that's the mirror, yes
<asac> StevenK: anyway. i cannot really see a reason why that might happen. nm-applet is quite a simple application UI wise :(
<pitti> ion_: http://bzr.debian.org/bzr/pkg-cups/cups/debian-trunk/ is the master
<asac> StevenK: do you use a custom theme?
<asac> or are those the NM icons used in the main distro?
<StevenK> asac: I think it's the normal icon
<tkamppeter> pitti, ion_, I am currently building with "bzr-buildpackage --merge". fakeroot is used automatically, but to automatically get the source code from ../tarballs "--merge" needs to be supplied.
<StevenK> asac: It could be the scan that's doing something odd.
<tkamppeter> The result lands in ../build-area
<StevenK> asac: Since iwlist scan returns nothing since the driver is horked
<asac> StevenK: if the driver is as flaky as i think it is it could cause problems.
<asac> but getting no results shouldnt be a big issue alone for nm-applet
<ogra> StevenK, did you try to manually compile madwifi ?
<ogra> for me on -generic on the Q1 it doesnt crash X with ath5K but doesnt connect either
<tkamppeter> pitti, it does not build into the build-area, but into ..
<tkamppeter> pitti, but it builds and installs fine.
<tkamppeter> pitti, another question: You have added CUPS to the UFW: /etc/ufw/applications.d/cups
<pitti> tkamppeter: jdstrand did, but yes, it's there (just for ubuntu)
<tkamppeter> For CUPS only port 631 seems to be opened. Will it still be possible for CUPS and its backends to access ports 443, 631, 515, 139, and 9100?
<tkamppeter> Will cups-lpd still be able to listen on port 515?
<pitti> jdstrand: ^
<tkamppeter> pitti, will you soon put cups 1.3.8-10 into Debian and Ubuntu? Or is there still something planned to be done?
<pitti> tkamppeter: I was mainly waiting for ion_'s patch to land, which you just did
<ogra> evand, lool proposed i should show you https://launchpad.net/usb-imagewriter .... its essentially a dd gui frontend and might make a good company for usb-creator (there are screenshots, though its functional it needs some improvement)
<jdstrand> tkamppeter: all /etc/ufw/applications.d/cups does is add an application profile that users can use when adding rules to their rulesets. eg 'ufw allow Cups'. Nothing is done automatically and the firewall is not enabled by default
<jdstrand> tkamppeter: that said, it sounds like adding additional profiles might be a good idea.
<evand> ogra: neat
<evand> noted
<jdstrand> tkamppeter: the stance that is taken is not to add an appliation profile for every conceivable port that could be used, but only for the very most common
<jdstrand> tkamppeter: eg, one might argue that cups-lpd doesn't need its own profile, because it is for compatibility and the admin likely knows she needs to open port 515
<liw> evand, do you have a url handy for your usb image creator, if one wants to try it out? (I am going to re-install a machine in the relatively near future)
<jdstrand> (and can do so (as always) with 'ufw allow printer'
<jdstrand> (or 515/tcp, ...)
<evand> liw: 0.1.2 is in universe, bzr at lp:~ubuntu-installer/usb-creator/trunk
<liw> evand, oh, cool, thanks
<evand> you will undoubtedly run into issues with device ordering and grub.  That will be fixed once I have UUID support in grub-installer.
<jdstrand> tkamppeter: if you'd like to add additional profiles to /etc/ufw/applications.d, feel free to do so-- and I'd be happy to review/help in any way I can
<evand> (the USB key will appear as the first disk during installation, making it the default target for grub as well as causing ordering issues once removed)
<jdstrand> tkamppeter: if the profile that is in place is not appropriate for the default installation, please file a bug and assign it to me
<dendrobates> pitti: any chance of promoting  smartpm and update-motd?  I really want to test landscape-client in the installer.
<ion_> % apt-cache search landscape server
<ion_> %
<ion_> Is that going to change?
<Adri2000> eh, I asked myself the same question when I noticed this package -- btw, I don't think the canonical ad in motd is a good idea
<ion_> If not, iâll stay a happy puppet user. :-)
<dendrobates> Adri2000: we are working on softening that.
<Adri2000> good
<Adri2000> dendrobates: can landscape-client be used with something other than landscape.canonical.com?
<dendrobates> Adri2000: yes you can write your own landscape-sysinfo modules.
<dendrobates> Adri2000: the package is changing so it only installs the needed portions for that and not the entire client, as well
<Adri2000> but can I write my own landscape.canonical.com from scratch, and use it to manage my ubuntu machines with landscape-client installed?
<dendrobates> Adri2000: sure the client is gpl, you can do what ever you want.
<Adri2000> ok
<dendrobates> Riddell: any chance of promoting  smartpm and update-motd?
<dendrobates> Riddell: for a kubuntu user.  :)
<pitti> dendrobates: eww, we need smart in main?
<davmor2> pitti: current cd builds are failing because of it :)
<dendrobates> pitti: landscape-client requires it.
<pitti> davmor2: that's a bug in the seeds then
<davmor2> pitti: The following packages have unmet dependencies:
<davmor2>                     Depends: update-motd but it is not installable
<davmor2>   landscape-client: Depends: smartpm-core (>= 1.0) but it is not installable
<dendrobates> pitti: the server daily iso's are building fine.
<dendrobates> pitti: but the installer silent fails when you select landscape client.
<pitti> uh, I even have landscape-client installed
<pitti> why's that, are we going to ship the full package on the CDs?
<dendrobates> yes, but we will only install the part needed to run landscape-sysinfo.  mathiaz is breaking up the package now.
<pitti> I thought we'd ship only a stub, and customers would then activate Canonical's repo to get the real thing?
<dendrobates> pitti: this is on server, desktop can do it's own thing.
<Treenaks> pitti: is it known that lang-supp-writing-en is broken? or is that just my system misbehaving?
<pitti> Treenaks: --verbose ?
<Treenaks> pitti: great idea :)
<Treenaks> uhr
<superm1> is landscape-client going to be useful on most desktop systems?
<pitti> superm1: no
<superm1> pitti, then how did it make it into dependencies to be on desktop CDs?
<Treenaks> pitti: ah, hunspell vs myspell
<dendrobates> pitti: it won't ask any questions and will not be configured and the daemon will not run, unless you select it in d-i.
<Treenaks> pitti: my bad, sorry
<pitti> dendrobates: right, but it takes some extra 2 MB CD space, and isn't useful for 99% of desktop users
<cjwatson> dendrobates: have you escalated the issue of landscape using smartpm when the rest of Ubuntu doesn't? It will cause problems
<cjwatson> real upgrade problems, that we're going to have to work around in complex ways
<dendrobates> pitti: it is worth noting that desktop users that upgrade will get it.
<pitti> that's my other concern why I don't think that having smart in main is a good idea ATM
<pitti> especially not after FF
<pitti> dendrobates: right
<cjwatson> (I don't know of anything specific, but I can guarantee you that a new dependency resolver will have its own set of issues)
<pitti> I assumed that we'd always just keep the stub, and keep the real client in a caonical repo
<dendrobates> cjwatson pitti: since it is in the server seed,are you removing it form the desktop?
<pitti> dendrobates: did slangasek approve the real landscape-client upload yesterday? (FF exception)
<mathiaz> pitti: yes
<niemeyer> Hello there!
<cjwatson> dendrobates: I'm not sure we will be able to do that effectively
<pitti> dendrobates: I'm not sure; if we don't have the stub any more, then most probably yes
<dendrobates> slangasek: gave us a FFE and kees and jdstrand did a code review.
<pitti> but that won't help for upgrades
<smarter> could someone please take a look at bug #267705?
<ubottu> Launchpad bug 267705 in facile "Main Inclusion Request: facile" [Undecided,New] https://launchpad.net/bugs/267705
<cjwatson> dendrobates: we can perhaps do that for update-manager upgrades, but not for apt upgrades
<niemeyer> Can I help the ongoing discussion anyhow?
<cjwatson> (not without massive overkill such as conflicts)
<cjwatson> niemeyer: I am very concerned about Landscape using smartpm when it's not something that's part of the Ubuntu upgrade testing process
<pitti> niemeyer: why did we suddenly provide the real landscape client in the ubuntu repo?
<cjwatson> pitti: we always intended to
<pitti> (and smart in main, too)
<cjwatson> niemeyer: without it being something we test regularly, the probability approaches 1 that we're going to break it at some point
<pitti> cjwatson: hmkay, wasn't aware of that (since it seems fairly useless without a support contract)
<niemeyer> pitti: I'm not sure I understand your question.. was it supposed to always be an empty package?
<dendrobates> pitti: and the stub was in main.
<cjwatson> niemeyer: certainly smart has been on our radar for a while, but at this point Landscape seems to be forcing the issue
<niemeyer> cjwatson: Smart should comply to the package relations defined
<cjwatson> niemeyer: so should apt, but theory and practice often differ
<niemeyer> cjwatson: How is it forcing the issue now?
<cjwatson> it just doesn't work that way
<niemeyer> cjwatson: It's not like we suddenly started using Smart in Landscape
<cjwatson> I am not alleging a particular bug in smart; I'm merely speaking from experience of having to work around problems in all kinds of tools
<niemeyer> cjwatson: We've been using it for 3 years now
<cjwatson> niemeyer: because now we have been asked to include the client in the distro
<cjwatson> niemeyer: which means that we have to support smartpm in main
<niemeyer> cjwatson: That's not a decision we've done now
<pitti> niemeyer: forcing> we are suddenly confronted with MIRs for smart and other things for packages which are already uploaded, and all that past FF without discussing how to support a second package manager in intrepid
<cjwatson> niemeyer: Ubuntu is now also promoting Landscape to some extent, which hopefully translates into more users
<niemeyer> cjwatson: The inclusion of landscape-client was discussed back in Dapper
<cjwatson> niemeyer: I was in those discussions, and don't recall smartpm being mentioned
<niemeyer> cjwatson: Smart is a dependency of Landscape since day 1
<cjwatson> niemeyer: I'm also very concerned that this partitions the set of Ubuntu users into two package management camps, and we're going to have to support them both
<cjwatson> regardless of whether this is a current decision or not, it is a current problem
<niemeyer> cjwatson: I'm not trying to make people use Smart
<pitti> niemeyer: I guess we have never been really aware of that, since so far it was completely separate from Ubuntu, and our testing efforts, as well as bug tracking
<cjwatson> but everyone who uses Landscape for upgrades will use Smart, no?
<niemeyer> cjwatson: We are just trying to offer good server-side package management
<cjwatson> in order to support that usefully in Ubuntu, we need to be testing Smart
<niemeyer> cjwatson: and Smart enabled us to do it quickly, and well
<cjwatson> we are not doing so right now, and it doubles our upgrade testing work
<cjwatson> I appreciate and respect your reasons. Nevertheless, it has created a problem for us
<niemeyer> cjwatson: Smart uses the repositories from APT itself
<cjwatson> yes, I know.
<niemeyer> cjwatson: We'll be happy to try to solve your problems in any way we can
<cjwatson> it is nevertheless a completely separate implementation. We have worked around bugs in APT before; I'm not saying Smart is bad software, but experience of software engineering strongly indicates that at some point we will have to work around bugs in Smart
<niemeyer> cjwatson: But let's step back
<niemeyer> cjwatson: Landscape is in development for 3 years, and it uses Smart
<cjwatson> Landscape has not, in any real sense, been in Ubuntu for three years.
<cjwatson> (which you know as well as I)
<niemeyer> cjwatson: Okay
<niemeyer> cjwatson: So what do you suggest we do?
<cjwatson> the number of existing Landscape users is tiny compared to the number of Ubuntu users
<cjwatson> we have a *lot* of experience with upgrade problems, and they are complex and tend to be unanticipated with the best of goodwill
<niemeyer> cjwatson: So do I :-)
<cjwatson> What would it take to make Landscape use apt?
<niemeyer> cjwatson: But that doesn't change things
<cjwatson> while it is still the standard package manager in Ubuntu
<niemeyer> cjwatson: This is impossible in the short term
<niemeyer> cjwatson: For Landscape to do what it does we use a good amount of the logic in Smart
<cjwatson> in that case, either (1) we need to restructure the Landscape packages in Ubuntu so that we don't have to include smart in main or (2) we need to find a way to have enough resources to test Smart upgrades as part of our routine QA
<pitti> so, I don't see a good and quick solution to that, short of reintroducing the stub for intrepid, and discussing how to integrate smart in our testing efforts and the package tools in jaunty
<cjwatson> for (2), remember that much of our routine QA for upgrades comes from thousands of people testing Intrepid and reporting bugs
<cjwatson> we can't just magic up that sort of effort
<niemeyer> pitti: Sure, we can discuss that possibility
<cjwatson> what's the stub in question?
<cjwatson> also, does landscape-sysinfo require smartpm?
<radix> cjwatson: landscape-sysinfo does not
<pitti> cjwatson: stub> I meant the empty package we've been carrying until Monday
<radix> not now, anyway. we are considering further features that will, but probably not before the beta freeze
<cjwatson> I don't think that will be acceptable; this is a major headline feature and it's important to Canonical
<pitti> hmm
<pitti> niemeyer: so the actual plan is to just ship sysinfo, and the current, complete, package is just an interim state?
<cjwatson> pitti: the requirement is to ship the Landscape client
<pitti> hm
<cjwatson> I don't see any way to satisfy the constraints here without magicking up vast amounts of upgrade testing efforts of all kinds of Ubuntu (at least server) combinations
<jdstrand> cjwatson: side-stepping smartpm in main for a moment, just having smartpm installed doesn't change update-manager or apt-get IIUC. though both installed simultaneously is both confusing and problematic in its on right
<jdstrand> cjwatson: so won't it still be the 'small number' of landscape users that are affected by these upgrades?
<jdstrand> cjwatson: further, this 'small number' have been using smart for sometime...
<cjwatson> that's correct, but since we now have parts of the distro that refer to landscape, I think it's incumbent on us to ensure that that works
<cjwatson> I don't think we can reasonably assume that the number of landscape users will remain static
<jdstrand> I heartily agree (and mentioned some of this in emails)
<radix> in fact we hope that it doesn't :-)
<jdstrand> sure, I was just trying to think about the problem differently
<cjwatson> what can the landscape team do to ensure widespread testing of server upgrades?
<tkamppeter> pitti, I asked you yesterday whether you could document the DBUS API quickly so that we can make a patch for s-c-p to trigger Jockey for driver download as this would enable especially network printers to make use of driver download. You told that you will answer later. Have you any answer now?
<cjwatson> I assume you have some degree of automatic testing, although it can't possibly cover all combinations
<pitti> tkamppeter: oh, sorry; erm, "yes" :-)
<niemeyer> cjwatson: The Landscape team itself can't do widespread testing of server upgrades, of course
<cjwatson> niemeyer: who does?
<niemeyer> cjwatson: But we can certainly discuss what's the proper way of doing testing of upgrades with Landscape, within a Canonical context
<cjwatson> within an Ubuntu context too
<cjwatson> if there are problems, they will reflect on Ubuntu
<niemeyer> cjwatson: I would like to isolate the things we're discussing at ocne
<niemeyer> once
<niemeyer> cjwatson: We have several things mixed
<niemeyer> cjwatson: Are all the concerns coming from the fact that Smart is going to main?
<cjwatson> well, part of the concern arises from the fact that this is landing late, two weeks after feature freeze
<pitti> niemeyer: well, that, and shipping an ubuntu package which doesn't use our standard packaging tools, without prior discussion, or without us being prepared to do appropriate testing with it
<niemeyer> cjwatson: So that's *yet* another issue
<cjwatson> that is not necessarily your problem, but it contributes to the Ubuntu team being uneasy
<pitti> niemeyer: well, sorry, that was wrong
<pitti> niemeyer: "discussion with the distro team"; it has certainly been discussed at length in general
<dendrobates> cjwatson: it is landing late, because we wnated to do a thorough security review.
<cjwatson> dendrobates: yes. Nevertheless, that means it's late
<cjwatson> late things that are easy aren't necessarily a problem, but this is a late thing that's hard
<niemeyer> cjwatson: I feel very bad about it.. I personally thought the package had been integrated for a while, and I feel bad for not following more closely, but that's a separate issue I would like to discuss in another moment so that we can get back to the aforementioned concerns
<jwendell> hi, pitti. Any reason for not having consolekit 0.3 in intrepid?
<cjwatson> and I agree that the security review being already done alleviates some other problems
<cjwatson> niemeyer: that which package had already been integrated - landscape or smart?
<slangasek> hum, yes, this is significantly more complicated than what I understood I was granting a FFe for; we hadn't discussed that any new dependencies were being pulled in that would need MIRs
<pitti> jwendell: there isn't a particular reason reported for it, and we are past FF
<dendrobates> cjwatson: there was pressure to shove it in that I resisted.  It is entirely my fault that it is landing when it is.
<cjwatson> dendrobates: understood. I'm not trying to apportion blame
<jwendell> pitti, it's needed by the new gdm (2.24)
<niemeyer> cjwatson: Both.. Landscape is in development for three years, as I've been unfortunately been saying repeatedly.  Many of the people involved into the discussions know about that, so I didn't think that was going to be brought up so late (now).
<cjwatson> but niemeyer asked for other concerns and that's definitely one of them
<pitti> jwendell: hm, maybe, but we won't use that in intrepid
<cjwatson> I find it surprising that smartpm wasn't mentioned as a distro concern before now, but I can't find any records of it
<jwendell> pitti, yeah, I know... I'm trying to get is usable in intrepid to make an alternative package
<pitti> jwendell: nothing wrong with preparing a PPA package, or requesting a FFE if the changes aren't too intrusive and backwards-compatible
<pitti> jwendell: the primary reason is "we don't update to new upstream versions unless someone cares and asks"
<jwendell> pitti, ok, thanks
<pitti> jwendell: (after FF)
<pitti> jwendell: BTW, both seb128 and MacSlow have packages for the new gdm, so don't start from scratch
<jwendell> seb128, ??
<jwendell> really?
<mdz> dendrobates: already here
<seb128> jwendell: the packaging is on launchpad in the ubuntu-desktop bzr
<cjwatson> we did have a spec a couple of years ago for smartpm (https://blueprints.launchpad.net/ubuntu/+spec/smartpm), but it was never very high priority and hasn't happened
<seb128> jwendell: I didn't upload binaries to a ppa though because it's too broken to be pushed to users
<tkamppeter> pitti, thanks, tell me when you have the doc ready.
<cjwatson> (for use of it in Ubuntu, I mean)
<seb128> jwendell: what do you want the new gdm for exactly? it just does less than the previous one
<pitti> tkamppeter: where do you think should that be? there is a README.txt, but it's mainly for jockey developers
<seb128> jwendell: it's buggy, it has no graphical theme, no configuration gui, etc, etc, etc
<pitti> tkamppeter: but for the time being it could stay there, I figure
<dendrobates> mdz: I thought that it was widely known that landscape used smart.  I understand the concerns and share them, but I am surprised at the resistance at this time.
<tkamppeter> pitti, or you add an interface doc file (or section in README.txt) for the interfaces to work together with other programs.
<niemeyer> cjwatson: So what do you think we should do to understand how to best address the concerns?
<pitti> tkamppeter: I'll do a section in README.txt for now; at some point I'll write manpages and move it there then
<cjwatson> niemeyer: explain to me what your upgrade testing involved
<cjwatson> involves
<niemeyer> cjwatson: Upgrade testing of what, when?
<tkamppeter> Riddell, I have a question to PDF printing output of KDE and Qt.
<cjwatson> niemeyer: Ubuntu, using Landscape
<cjwatson> niemeyer: you have a server upgrade feature, yes?
<tkamppeter> pitti, thanks in advance
<niemeyer> cjwatson: Can you please define "server upgrade" in more details?
<mdz> dendrobates: this is the first time that the client is being fully released in Ubuntu, nothing about it has been common knowledge until now
<cjwatson> niemeyer: upgrading an Ubuntu system from one release to another, or applying security updates
<niemeyer> cjwatson: The first thing isn't supported by Landscape at all at this point
<niemeyer> cjwatson: As it's not supported by APT, in fact
<cjwatson> that is entirely false
<cjwatson> change sources.list, apt-get dist-upgrade
<cjwatson> we recommend update-manager in its stead, but that method is still entirely possible and used by a significant fraction of Ubuntu users
<niemeyer> cjwatson: I thought the only supported way of doing release upgrades was via update-manager
<cjwatson> that doesn't mean it isn't supported by APT
<cjwatson> it just means it's not the method we recommend
<niemeyer> cjwatson: We're talking about policy, not tools
<pitti> niemeyer: it's debian's official method, and due to our heritage, a lot of Ubuntu users do it that way, too
<cjwatson> in practice we often do accept bug reports from apt-get dist-upgrade and deal with them where it makes sense to do so
<slangasek> policies don't stop users from using the tools
<cjwatson> because they often indicate package bugs that should be fixed
<cjwatson> so our policy is a little more broad than the outward presentation of it might indicate
<niemeyer> Nothing stops users from upgrading the distribution in any way they want, but not all paths will be tested
<niemeyer> THis is what I mean
<cjwatson> apt-get dist-upgrade is widely tested, in reality
<niemeyer> You guys were bringing up tested paths
<niemeyer> So I'm trying to stay within a given context
<cjwatson> niemeyer: is it *possible*, tool-wise, to perform an upgrade from one Ubuntu release to another using Landscape?
<niemeyer> cjwatson: So that's the reality, Smart can do distribution upgrade if the user does it manually
<cjwatson> right, Smart can, but do you present it in Landscape?
<niemeyer> cjwatson: No, there's no way to do it via Landscape only
<cjwatson> OK, that simplifies things somewhat
<niemeyer> cjwatson: The user would have to change the repositories
<jdstrand> hmm, would a user know to use smart in this instance, or would the user go to update-manager or apt-get?
<niemeyer> cjwatson: This doesn't change things much, of course.. the user can still do the distribution upgrade if he really wants to
<cjwatson> sure, but I care about the new paths that we're presenting to users
<niemeyer> cjwatson: But we don't advertise that as such, and we won't
<cjwatson> could we separate the Smart libraries needed by Landscape from the binary that users can use standalone?
<cjwatson> and ship only the libraries
<cjwatson> I would be happier if we were only shipping the parts Landscape strictly needed
<kees> hm, where is the main/universe mismatch output?  I've been wandering germinate output but haven't found it yet.
<cjwatson> kees: http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt
<niemeyer> cjwatson: Landscape needs Smart installed.. we can name it landscape-smart if that's the case
<cjwatson> niemeyer: Which parts of Smart does Landscape need? Does it need /usr/bin/smart?
<kees> cjwatson: ah! thanks, I wasn't looking in the top-level. gah
<niemeyer> cjwatson: Yes, for running "smart update"
<niemeyer> cjwatson: We can do it in different ways of course
<cjwatson> niemeyer: Could it use the library interface to that instead, please?
<cjwatson> niemeyer: Then it would be trivial to support Smart *only* for use by Landscape, since the command-line client wouldn't be provided
<niemeyer> cjwatson: We certainly can hide in any way wanted
<jneves> asac: I hope this is not off-topic here: NM 0.7 (hardy, from the PPA) doesn't seem to accept/save my PPP options (and the umts modem doesn't work with them enabled)
<cjwatson> niemeyer: how does Smart deal with dpkg conffile resolution?
<cjwatson> (I'm thinking now of problems likely to affect server users)
<cjwatson> (on security updates)
<jdstrand> I know that smart can be run alongside other package managers, but am concerned that if release upgrades aren't supported, and people use apt or upgrade-manager to upgrade to another release, and then start using smart again, what the consequences might be (and also the possibly untested package combinations)
<niemeyer> cjwatson: We can have "landscape-smart" as well, for instance
<cjwatson> I'm not sure landscape-smart would help. That would introduce extra complexity later
<cjwatson> and it would introduce dual maintenance, which is something we generally abhor
<niemeyer> cjwatson: I meant just the executable name
<cjwatson> oh, I don't think that would really help
<niemeyer> cjwatson: Leaving inside landscape-client
<niemeyer> Living even
<cjwatson> smart is not a name Ubuntu users are familiar with, and neither is landscape-smart; they're identical from that point of view
<cjwatson> surely it would be very little harder just to use the library interface?
<radix> what about /usr/share/landscape/landscape-smart?
<cjwatson> I thought Landscape was written in Python
<radix> cjwatson: we use the library interface in the client, but we need something to run in cron
<dendrobates> cjwatson: we could, of course, easily split the package and only install the python lib.
<niemeyer> cjwatson: We use the smart command line commonly to debug issues
<slangasek> jdstrand: what's the possible issue that you see there?  I would hope that smart is treating the existing /var/lib/dpkg, /var/lib/apt metadata as authoritative
<cjwatson> oh. In that case /usr/share/landscape/landscape-smart would be fine
<niemeyer> cjwatson: I wouldn't like to ask users to execute python and run code to debug things when necessary
<niemeyer> cjwatson: Cool
<cjwatson> it just reduces the risk of us having to deal with users having found smart and done untested upgrades with it
<cjwatson> note that untested is a much stronger statement than unsupported, so I don't consider users finding apt-get to be a problem in the same way
<tkamppeter> jdstrand, thanks for the clarification on ufw profiles.
<pitti> tkamppeter: http://bazaar.launchpad.net/~jockey-hackers/jockey/trunk/revision/378
<jdstrand> slangasek: I am not entirely sure there is an issue, not having used smart myself. but IIUC, Recommends are treated differently in smart, so we'd likely have many different package combinations that may or may not be tested
 * pitti -> gotta run now, cu tomorrow
<niemeyer> pitti: Heh
<niemeyer> pitti: You sounded so interested in that topic.
<dendrobates> jdstrand: imo, smart is going to have to install recommends.
<dendrobates> jdstrand: it will have to be fixed.
<jdstrand> dendrobates: does it currently? I wasn't aware of the change
<slangasek> jdstrand: well, unless smart plans to autoremove Recommends, I don't see much room for horrible failure scenarios when one specifically /does/ use apt for the upgrade :)
 * jdstrand nods
<dendrobates> jdstrand: no
<niemeyer> jdstrand: Ok, about the things you've brought up
<niemeyer> jdstrand: Indeed Recommends are not handled by Smart right now
<niemeyer> slangasek: Smart doesn't consider anything in /var/lib/apt
<ahasenack> https://bugs.launchpad.net/smart/+bug/268143 is about the Recommends handling
<cjwatson> niemeyer: how does Smart deal with dpkg conffile resolution?
<ubottu> Launchpad bug 268143 in smart "smart should treat Recommends as apt does" [Undecided,New]
<niemeyer> cjwatson: It doesn't do anything special about this
<niemeyer> cjwatson: It just runs dpkg
<cjwatson> niemeyer: does it ensure that the user has a terminal (emulation) so that they can respond to dpkg conffile prompts?
<niemeyer> cjwatson: For Smart, it doesn't
<norsetto> jdstrand: thx for fixing bug 268084, works a charm now
<ubottu> Launchpad bug 268084 in ufw "ufw fails badly during installation/upgrade if proc is not mounted" [Undecided,Fix released] https://launchpad.net/bugs/268084
<niemeyer> cjwatson: For Landscape, it runs Smart with options to run dpkg non-interactively right now
<cjwatson> niemeyer: that's going to be a real problem in practice
<slangasek> niemeyer: so smart has to re-download all the packages files?
<niemeyer> cjwatson: In practice, it hasn't been a problem so far
<niemeyer> cjwatson: But it's certainly our desire to make things better over time
<cjwatson> niemeyer: your test cases are inadequate, then, I'm afraid
<jdstrand> norsetto: np :)
<cjwatson> niemeyer: this means that any change to a dpkg-handled conffile in an Ubuntu update will be ignored by people upgrading using Landscape
<niemeyer> cjwatson: I'm saying "in practice"
<cjwatson> well, no, that's not true
<cjwatson> niemeyer: this means that any change to a dpkg-handled conffile in an Ubuntu update will be ignored by people upgrading using Landscape, if they have already changed that conffile themselves
<cjwatson> niemeyer: it is a problem in practice for Ubuntu.
<cjwatson> niemeyer: the effect of this will be that, at some point in the future, we will get obscure bug reports that turn out to be because a configuration file didn't get updated, and the user was provided no guidance about this
<niemeyer> cjwatson: Yes, it will not work well in some cases indeed
<niemeyer> cjwatson: This is a bug we have to fix on Landscape
<cjwatson> Is there a bug filed about this? Can it be release-critical for Intrepid/
<cjwatson> ?
<james_w> norsetto, I saw in that report that apport also fails in that situation, did you report that as well?
<niemeyer> cjwatson: No, it can't be release critical for Intrepid
<cjwatson> Why not?
<norsetto> james_w: IIRC apport didn't report since it was over the number of max allowed bugs (or crashes, or something like that)
<niemeyer> cjwatson: First, because we have a development schedule too.  We have to verify what it will take to implement support for this, and come up with a plan.
<cjwatson> all our existing package management tools handle conffiles, and in many cases this has been something we've taken care to add to them
<jneves> asac: edited what I needed through gconf-editor (I looked at the source for the keys) - the interface isn't working
<niemeyer> cjwatson: Then, I consider this as a bug in Landscape, not in Ubuntu.
<cjwatson> niemeyer: you're asking us how you can best address the concerns; this is one of the problems that is of concern
<cjwatson> Landscape is a package in Ubuntu now, and thus I think it makes sense to talk about certain bugs in it being RC for intrepid
<james_w> norsetto, the terminal log in your bug shows apport falling over try to get /proc/<pid>/cmdline which obviously fails for the same reason as ufw
<niemeyer> cjwatson: Of course.  This is a concern of myself too.  I have discussed this problem with dendrobates in the past.
<cjwatson> niemeyer: Does Landscape offer the ability to install and remove individual packages?
<niemeyer> cjwatson: If you want to mark it as RC for Intrepid and follow on with it, I can't prevent it.
<niemeyer> cjwatson: I'm not in a position to offer you a fix for this in time or Intrepid.
<niemeyer> s/or/for/
<niemeyer> cjwatson: Yes, it offers it.
<norsetto> james_w: well, what happened in that case is that dpkg failed a certain number of packages in the trigger_awaited state, and I do remember having seen a message saying that it was not going to be reported because it was above a certain threshold, but, really, I only glanced at it
<cjwatson> niemeyer: does it record which packages were automatically installed and which were manually installed, in a way which will be compatible with 'apt-get autoremove'? (Note that you can manipulate apt's state here using apt-mark.)
<niemeyer> cjwatson: No, it doesn't.  That feature was added after Landscape was born and we didn't catch up.
<cjwatson> I think that will need to be added. (Note that I'm not mentioning everything that comes to mind, only the things I think make sense in this context and that I expect to cause problems in practice.)
<niemeyer> cjwatson: Ok, one more thing to fix.
<cjwatson> I'm going to have to continue this at another time, sorry - I'd love to try to get this sorted out now but I'm expected elsewhere
<cjwatson> thanks for answering our questions thus far
<niemeyer> cjwatson: Cool, just let me know when would be a good time and I'll be happy to follow up.
<niemeyer> cjwatson: No problem.
 * niemeyer looks for lunch
<norsetto> james_w: I guess your case is covered by bug 215380 ?
<ubottu> Launchpad bug 215380 in apport "Unhandled exception: TypeError: stat() argument 1 must be (encoded string without NULL bytes), not str" [Low,Confirmed] https://launchpad.net/bugs/215380
<james_w> norsetto, I just found that, I think it might be
<nxvl> popey: i LOVE your bug reports
<nxvl> popey: the screencast is a lovely and helpfull idea
<kees> ack, wtf?  why does policykit show me as the registrant?  https://edge.launchpad.net/policykit
<kees> james_w: I've made you the registrant.  I think I was marked that way since I was the first to report a bug against it upstream.
<mathiaz> dendrobates: is lp:~dendrobates/landscape-client/intrepid-packaging
<mathiaz> dendrobates: the most update-to-date ?
<popey> :) thanks nxvl
<dendrobates> mathiaz: yes.
<mdke> can a package have itself as a build-dep?
<seb128> mdke: no
<slangasek> why not?
<slangasek> it's not a /good/ thing, but it's not impossible
<seb128> slangasek: doesn't really make sense and you require boostraping?
<mdke> heh, and I thought it was a stupid question
<seb128> bootstraping
<slangasek> seb128: there are compilers that have themselves as build-deps, unfortunately
<mdke> this would be a lot less complicated
<slangasek> because they can't do a ground-up bootstrap in the source package
<seb128> slangasek: right, that was a short reply for "usually not a good idea"
<slangasek> ok :)
<slangasek> mdke: which answer makes it less complicated?  If a "no" is less complicated, just go ahead and pretend it's "no" :)
<seb128> mdke: you should give details on what you want to do
<slangasek> in practice, bootstrapping new packages that self-depend is awkward because of the need for packages to build in the DC
<NCommander> slangasek, one of the worst offers is GNAT, since its the only free ada compiler
<NCommander> sladen, offenders
<mdke> seb128: I'm playing around with making a txt version of the ubuntu serverguide
<mdke> seb128: and so far, using lynx -dump, I get to this - http://launchpadlibrarian.net/17522613/serverguide.txt - which has loads of ugly footnotes at the bottom
<bryce> where are acpi events logged?
<mdke> seb128: I figured that if I use an installed version of the server guide to generate the txt, the links in the footnotes won't look quite so appalling
<mdke> (because at least they will point at files which the user has installed)
<cjwatson> mdke: either convince it to use relative links, or just postprocess the output
<mdke> obviously I could just run sed over the links
<mdke> right
<cjwatson> a self-build-dep that needs to be kept up to date every time is going to be completely infeasible
<cjwatson> that's not even a self-build-dep on the previous version - you have to get the current one installed before you can complete the build
<cjwatson> you could use fakechroot or something, but honestly postprocessing is going to be a *lot* easier
<mdke> fair enough
<mdke> thanks :)
<Riddell> dendrobates: why do you need smartpm and update-motd?  generally these things need a MIR
<Riddell> tkamppeter: what's your PDF and Qt question?
<dendrobates> Riddell: never mind there is an on going discussion.
#ubuntu-devel 2008-09-11
<RAOF> Dear pulseaudio.  When I ask you for debug output, I'd ideally like it on stdout, not stderr.  kthxbye.
<slangasek> is that conventional?
<RAOF> I'd generally expect "pulseaudio -vvv | tee ~/pulselog" to have some output in ~/pulselog, yes.
<seb128> wrong expectation then
<RAOF> Maybe I don't do this often enough, then.
<LaserJock> debug output is generally considered error output isn't it?
<slangasek> I would be inclined to expect it on stderr, myself
<RAOF> Hm.  My expectations are obvously wrong, then.
<LaserJock> RAOF: don't worry, I always expect | to catch stderr :-)
<seb128> NCommander: oh, you are there
<seb128> NCommander: I though you didn't manage to reboot ;-) did you read my comments about the gtkmm update before?
<slangasek> asac: is bug #229745 still in progress?
<ubottu> Launchpad bug 229745 in xulrunner-1.9 "after fix for #215728 - Committing to urlclassifier3.sqlite still causes excessive CPU usage and disk I/O (the 2nd)" [High,In progress] https://launchpad.net/bugs/229745
<seb128> NCommander: the configure.in requires new libglib, libgtk, etc versions and you didn't upgrade the build-depends
<seb128> anyway time to go to bed, you can work on fixing that until tomorrow ;-)
<kees> asac: so, I'm still trying to figure out why n-m tries to DHCP for me.  Everything in /etc/network/interfaces is static.
<nxvl> slangasek: are you planning the archive changes already?
<slangasek> "the archive changes"?
<nxvl> maving it from main/universe to seeds
<nxvl> as in team specific seeds
<slangasek> I haven't been directly involved in that transition
<TheMuso> nxvl: Thats a long way off yet I believe.
<nxvl> TheMuso: yeah, me too, just making sure
<nxvl> but it's going to be a jaunty goal to move everything to bzr, right?
<slangasek> that's been stated, yes
<slangasek> bryce: ok, so I've added a 'USA' layout to my keyboard preferences, but I don't see anywhere in here that will let me /switch/ to it...
<slangasek> oh, apparently if I drag and drop so that USA ends up as the default, it'll switch for me :P
<bryce> ah
<slangasek> Fn+F2 still gives me XF86AudioMute, tho
<persia> slangasek: You've clearly been using unintuitive interfaces for too long :)
<slangasek> persia: hmm?
<persia> slangasek: That you're looking for a widget to switch, rather than just dragging things about.
<slangasek> persia: er, why in God's name should I have to /drag/ anything to express "I want to change the current setting"?
<poolie> bryce, fwiw Fn-F2 for Lock does work
<slangasek> the effect of dragging it appears to be to change the default
<slangasek> I don't want to change the default, I want to change the current setting
<poolie> Fn-F4 (sleep) says "action is forbidden on this computer"
<poolie> Fn-F12 (hibernate) does nothing
 * persia retreats from an indefensible position intended humourously
<slangasek> persia: mmk :)
<slangasek> persia: sorry, perhaps you should try taking a position that's more obviously a parody rather than one that looks congruent to the position held by real "usability" folks :)
<ScottK-laptop> Isn't that parody almost by definition?
<persia> Has it gotten to that point already?
 * ScottK-laptop looks around for seele...
<bryce> heh
<slangasek> bryce: also, fwiw, I had the keymapping magically right itself before my last reboot; I don't know what I did to make that happen, but I can't reproduce the effect now
<slangasek> mm, manually running setxkbmap -model evdev seems to fix the mapping per xev; why was that wrong?
<bryce> hmmm
<bryce> this sounds familiar
<jcristau> slangasek: new xkb-data wants rules=evdev, instead of model=evdev, in order to unbreak stuff like jp106 and abnt2
<jcristau> where 'new' is whatever version timo uploaded in the last few days
<slangasek> well, so be it; but why do I have to specify anything manually, given that this is a fresh X session from this morning? :)
<bryce> slangasek: so with the right mapping, does sleep work?
<slangasek> bryce: no
<bryce> what's the xev output now?
<slangasek> hrm, /etc/default/console-setup is written out by gnome-keyboardboard-properties, I guess?
<persia> jcristau: Really unbreak jp106, or just sorta unbreak it?
<slangasek> now I have XKBMODEL="pc104", that doesn't really help much
 * persia has been overriding with GNOME preferences since Dapper
<jcristau> persia: make it possible to unbreak it
<persia> OK :)
<slangasek> bryce: XF86ScreenSaver
<bryce> lol
<slangasek> ?
<slangasek> this is for Fn+F2, which is the lock icon, surely that's correct?
<jcristau> slangasek: same keycode in both cases?
<slangasek> I don't know, no one asked for that while it was still in my scrollback
<bryce> slangasek: oh okay I assumed it was mapped to sleep
<bryce> slangasek: does your sleep key work?
<slangasek> I don't know, I'm not interested in sleeping? :)
<slangasek> I believe I'm still running the kernel that the alpha-5 technical overview says will break on resume. :)
<bryce> ah
<bryce> hrmm
<bryce> ok well I guess I've done as much as I can on this bug.  It's quite different from what I see on dell
<bryce> and unfortunately I don't have a thinkpad
<slangasek> well, I'm happy to test anything you want, or provide further debugging feedback
<slangasek> I can even test sleep if necessary, but there's a general problem with the extra keys not being seen where they need to be, so I'd rather debug something with less destruction potential first
<jcristau> slangasek: might be interesting to see the output of 'xkbcomp :0 -' in the broken case
<RAOF> TheMuso: pulseaudio status report: 0.9.12/alsa-lib from your PPA/alsa-driver 1.1.18rc3 _still_ exhibit underruns.
<poolie> bryce, still here?
<bryce> poolie: yep
<TheMuso> RAOF: Right.,
<slangasek> jcristau: which broken case, the broken case where it sends the wrong keysyms, or the broken case where it sends the right ones but nothing picks them up the way it's supposed to?
<poolie> bryce, on my x61s after rebooting (and getting past bug 263782)
<ubottu> Launchpad bug 263782 in linux "intrepid hang with screen corruption during boot with 2.6.27-2-generic on x61" [High,Triaged] https://launchpad.net/bugs/263782
<TheMuso> RAOF: what part of alsa are you using that is 1.0.18rc3?
<poolie> the sleep button says 'forbidden by policy' and the hibernate button does nothing
<jcristau> slangasek: wrong keysyms
<RAOF> TheMuso: alsa-driver.
<poolie> hth
<poolie> is there a bug i should subscribe to or something?
<jcristau> slangasek: the other one involves gnomeish stuff, which i'd rather not look at ;)
<TheMuso> RAOF: Right.
<RAOF> TheMuso: As in; grab the alsa-source package, update to 1.1.18rc3, disable a patch or two, and run module-assistant :)
<TheMuso> RAOF: Yep I know what you mean.
<RAOF> Good.  Just in case there was some ambiguity; ALSA's crazy!
<TheMuso> RAOF: I might take this to the pulseaudio guys then. I'm suspecting it may be alsa specific, but its better to be sure.
<poolie> wow amazing, hibernate works!
<slangasek> jcristau: http://people.ubuntu.com/~vorlon/xkbcomp-ftw.txt
<slangasek> jcristau, bryce: re-selecting generic/evdev in gnome-keyboard-properties under 'layouts' is sufficient to recreate the b0rkage
<TheMuso> RAOF: Are you RAOF if alsa-driver git fixes it, then we know where to start looking, and pick the commit we need and et it into the kernel.
<slangasek> and setxkbmap -rules evdev clears it
<TheMuso> RAOF: sorry started writing something, forgot to clear it. :)
<RAOF> TheMuso: I am RAOF, yes.  And I'll pull alsa-driver git and module-assistant it.
<jcristau> slangasek: yeah, that says 'key <I160> {         [   XF86AudioMute ] };
<jcristau> '
<TheMuso> RAOF: hehe
<jcristau> which is, err, wrong
<slangasek> jcristau: sure; it seems to get a total of 9 keys wrong, looking at the diff
<bryce> poolie: interesting... sounds like you're seeing a completely different issue than everyone else
<RAOF> TheMuso: Heh.  I've just browsed alsa-driver git.  Turns out, 1.0.18rc3 _is_ git head.
<poolie> bryce, i filed bug 268823, hth
<ubottu> Launchpad bug 268823 in ubuntu "x61s suspend and hibernate buttons don't work; suspend 'forbidden by policy'" [Undecided,New] https://launchpad.net/bugs/268823
<poolie> i'm pretty chuffed at least hibernate is working though
<bryce> poolie: ok thanks
<bryce> yeah neither sleep nor hibernate work for me
<jcristau> slangasek: i think gnome-keyboard-properties shouldn't be allowed to set the model to evdev anymore.. not sure how that's been handled
<slangasek> jcristau: well, it's changing the 'rules' that clears the breakage, not the 'model', does that make sense then?
<NCommander> hey TheMuso, I'm working on fixing a PPC specific issue in hardy (the changes are in proposed, just waiting for an archive admin to approve it to proposed)
<jcristau> slangasek: aiui, the broken state is with rules=base, model=evdev, and setting the rules to evdev fixes it. is that right?
<bryce> <slangasek> jcristau, bryce: re-selecting generic/evdev in gnome-keyboard-properties under 'layouts' is sufficient to recreate the b0rkage
<bryce> <slangasek> and setxkbmap -rules evdev clears it
<bryce> is gnome-keyboard-properties forcing rules=base?
<TheMuso> RAOF: bummer!
<RAOF> TheMuso: There's possibly one interesting commit in alsa-lib after the patches you've applied to .17a, but 0.9.12 doesn't seem to check for the availability of the new API, so it's probably not going to do anything.
<TheMuso> RAOF: What commit is interesting?
<RAOF> TheMuso: The one just before 1.0.18rc3; adding snd_pcm_avail and snd_pcm_avail_delay; I only notice these because I seem to recall Lennart complaining about the lack of that API.
<TheMuso> RAOF: Oh they are not in my alsa-lib package, because that introduces new symbols, and I thought it may be better staying away from that. I can drop that commit in my package if you like. Added to that, I'd say the next version of pulse may use that.
<RAOF> Yeah.  The next version may well, but it doesn't seem that pulseaudio git is using it yet.
<TheMuso> RAOF: And if I was to add that, I may as well move alsa-lib to 1.0.18rc3.
<RAOF> Right.
<TheMuso> Next cycle, I plan top get a better handle on the kernel side of things also. Its taken me a little while to get going with audio stuff, but I feel I'm almost on top of everything.
<bryce> slangasek: hmm, setting my layout to dvorak and back to us isn't breaking for me
<RAOF> TheMuso: Yay!
<jcristau> slangasek: can't reproduce your broken keymap by playing with setxkbmap here. will try to look again tomorrow. xkb makes me sad.
<bryce> and for me, input.xkb.rules = 'base'  (string)
<bryce> although oddly  lshal | grep xkb still shows layout='us' even when it's set to dvorak
<jcristau> bryce: hal just has the default stuff for when the device is added to x
<jcristau> so, that's everything but odd
<bryce> oh
<bryce> jcristau: is there a cmdline tool to see what the rules are currently set to?
<jcristau> xprop -root _XKB_RULES_NAMES, or setxkbmap -print, assuming gnome sets that (i have no idea whether it does)
<bryce> yep looks like it does
<bryce> _XKB_RULES_NAMES(STRING) = "base", "evdev", "us,us", ",dvorak", "grp:alts_toggle"
<slangasek> bryce: _XKB_RULES_NAMES(STRING) = "evdev", "evdev", "us", "dvorak", "lv3:ralt_switch,grp:alts_toggle,altwin:menu,compose:rwin,compose:ralt"
<bryce> slangasek: that is with it working properly or brokenly?
<slangasek> bryce: that's with the wrong keysym being generated
<bryce> hmm
<slangasek> and there's no difference after I run setxkbmap -rules evdev
<bryce> ok, but running that fixed it last time?
<slangasek> it still fixes the xev output
<slangasek> but it appears not to affect the xprop value
<bryce> gahh
<bryce> brb
<ScottK-laptop> slangasek: If you're still up and about, I'd appreciate it if you'd accept the kdenetwork in hardy-backports.
<tjaalton> slangasek: you have all the latest updates, meaning that gnome-settings-daemon no longer forces model=evdev?
<slangasek> tjaalton: it would be clearer if you would define "latest" in terms of package versions; I have 2.3.92-0ubuntu3
<slangasek> er, 2.23.92-0ubuntu3
<tjaalton> slangasek: yeah, sorry. that's recent enough :)
<slangasek> tjaalton: it does appear, however, that this version only became available today, and that I downloaded it this afternoon, after my last restart
<slangasek> tjaalton: so did -0ubuntu2 still have the problem?
<tjaalton> slangasek: ubuntu2 was the one that no longer forced it
<slangasek> ok
<slangasek> then I've had that installed since before my last reboot
<tjaalton> yeah
<slangasek> ScottK-laptop: done
<slangasek> asac: how do I get NM 0.7 to not stomp on my domain search preferences as configured in /etc/dhcp3/dhclient.conf and/or /etc/resolv.conf, without also having to hard-code a DNS server preference?
<NCommander> slangasek, is there a reason you can't configure those settings in NM?
<slangasek> NCommander: ?
<RAOF> slangasek: I can't see a way myself, no.
<NCommander> slangasek, WHy can't you set the domain search preference in NM?
<NCommander> slangasek, it allows you to set it
<slangasek> NCommander: are you looking at the same version of NM that I am?
<NCommander> I dunno, how can I check?
<RAOF> slangasek: You're asking for an option between "DHCP for everything" and "DHCP for IP only", right?
<slangasek> NCommander: dpkg -l network-manager-gnome?
<slangasek> RAOF: yes
<RAOF> Yeah.  I can't find one.
 * NCommander reread slangasek and realized the same
<NCommander> ^question
<slangasek> RAOF: really, I want a statically-configured search domain that never, ever gets touched regardless of which network connection is active
<slangasek> but I would settle for being able to configure my domain search without having to statically configure DNS servers
<NCommander> slangasek, where is NM's development?
<NCommander> ^based
<RAOF> I'm not even sure what the 'search domain' _is_ :)
<NCommander> RAOF, a search domain is a domain that is automatically searched if there isn't an entry in the hosts file
<NCommander> i.e., at my school, all computers are on rh.rit.edu
<slangasek> the domain, or list of domains, configured with the 'search' option in /etc/resolv.conf
<persia> RAOF: essentially let's you type "archive" and automatically get "archive.ubuntu.com" if you have it set.
<NCommander> Normally if I want to access goober on my network, it needs to be goover.rh.rit.edu
<RAOF> That's pretty cool.
<NCommander> But if I was to set the domain to rit.edu, then I can type goover.rh
 * RAOF now wants to set one!
<persia> RAOF: Set lots, for extra fun :)
<slangasek> RAOF: <boggle> hmm, now I have an inkling of why no one has complained about this missing feature before now :)
<slangasek> NCommander: NM's development> in GNOME?
<RAOF> NCommander: http://www.gnome.org/projects/NetworkManager/ if you want a url :)
<persia> slangasek: I suspect most of those that use the feature have been the same set of people who routinely purged network-manager on install.
<NCommander> persia, doesn't having a lot of search domains cause a lot of unnecessary DNS traffic since it will ping those DNS servers before checking the rest
<slangasek> persia: all the other options for managing wireless on a laptop appear to suck at least as much, so I've been giving NM the benefit of the doubt :)
<slangasek> persia: it /looks/ like NM 0.7 is good enough that I can finally have proper kerberos logins on my laptop
<persia> NCommander: Well, depends on frequency of use of the domains.  At one nameless financial institution we used 14 search domains as a result of various mergers to support ease of access.
<NCommander> i.e., if i had ubuntu.com in my search domains, and then I tried to go to say somesite.com, won't it try somesite.com.ubuntu.com first?
<persia> slangasek: Yep.  NM 0.7 hit the threshold of usability, so now the hard bugs get exposed.
<NCommander> slangasek, since I've been in a similar boat before I got my current router, I'll look into coding this feature for you :-)
 * NCommander knows said pain
<StevenK> NCommander: There's an option for that -- if the name contains more than n dots, it must be fully-qualified
<slangasek> well, this is a laptop - it's going to be connected to lots of networks, all of which will have the wrong domain search
<StevenK> slangasek: Why Kerberos on your laptop?
<slangasek> because Kerberos is the One True Way
<slangasek> obvi
<persia> Actualy kerberos and reliable VPN on the laptop sounds like the right solution to lots of problems.
<StevenK> You went to Stanford, didn't you!
<StevenK> Didn't you!
<slangasek> nope, Iowa State
 * NCommander has used Kerberos with CVS
<NCommander> God that hurt
<slangasek> and we ran AFS and Kerberos at ISU too
<NCommander> Kerberos is awesome ONCE you get it setup
<NCommander> But it hurts getting it setup
<StevenK> We were planning to use it at $OLD_WORK
<StevenK> And then I left. So now I don't care.
<NCommander> I got a crash course in kerberos adminning Windows Active Directory
<NCommander> WEEEE
<RAOF> Any protocol named after the three headed dog guarding the underworld has _got_ to be cool.
<NCommander> slangasek, ping me tommorow or the day after, and I'll probably be able to tell you how much pain is in store for adding the necessary code to NM
<slangasek> um
<dholbach> good morning
<RAOF> NCommander: Do you actually _sleep_?  Stop making me feel inadequate! :)
<slangasek> so I'm going to ping you, and you're going to give me a pain quote? :)
 * slangasek waves to dholbach 
<NCommander> RAOF, you haven't seen my quit message
<NCommander> or away
<dholbach> hi slangasek :-)
<StevenK> slangasek: "Ouch, that ping hurt!"
 * NCommander has quit IRC (This creature sleeps beyond the reach of time itself)
<NCommander> :-)
<RAOF> Heh.
<NCommander> (ten geek points if you know the reference)
 * RAOF doesn't think so.
<slangasek> NCommander: John McCain's introduction at the RNC
<NCommander> slangasek, O_o;, Uh, well, its actually from a 12 year old game
<RAOF> That sounds right up my alley.
 * StevenK tries to think what came out in 1996
<NCommander> RAOF, super nes
<NCommander> Hrm, it might be older
 * NCommander checks a release date
 * RAOF never had a snes.
<NCommander> 1995
<NCommander> so 13 years
<RAOF> Or, in fact, _any_ console but an xbox.
 * StevenK never had a SNES, either
<NCommander> Had a rather bad PS2 port
 * StevenK hugs his slimline PS2
<NCommander> Geeze, you guys were deprived. Go play some final fantasy :-)
<NCommander> (although this quote doesn't come from FF)
<RAOF> Oooh, no, I lie!  I also have a gamecube!
<RAOF> s/have/had/.
<NCommander> Man, I didn't think the reference was that obscure
<StevenK> Haha. Where did it go?
<RAOF> It stayed in Hobart with my brother.
<StevenK> Ah
<RAOF> Actually, I think one of my friends has it at the moment.
<NCommander> anyway, the quote is from Chrono Trigger (1995 - Squaresoft)
 * RAOF remembers final fantasy: crystal chronicals as surprisingly fun multiplayer
<StevenK> Brotherhood of the travelling gamecube?
 * StevenK hides
 * NCommander remembers as FF: CC as pain pure and simple
<NCommander> And not the good pain
<RAOF> Repetitve music attack!
<NCommander> The only cool part in that game was when you traveled through mana gates
<StevenK> RAOF: I thought was Tetris?
 * NCommander loves Tetris
<NCommander> My longest game lasted eight hours
<NCommander> Damn cheap game boy batteries
<slangasek> NCommander: I'm pretty sure all my memories of Chrono Trigger (which is still in the house here, somewhere) have been pushed aside by more arcane matters, sorry :)
<NCommander> \o/ - slangasek + 10 geek points!
<NCommander> (for having PLAYED chrono trigger)
<NCommander> That game was awesome
<slangasek> heh
<NCommander> I plan to buy it when its released for the DS
<NCommander> There goes another six months of my life
<NCommander> (or one Ubuntu release cycle where I'm just going to probably be MIA)
<NCommander> slangasek, the quote is near the end of the game when you get Epoch, and you turn off the Nu, and then try to talk to it, it says "This creature now sleeps beyond the reach of time itself."
<superm1> NCommander, yeah that is one of my favorite games too. i look forward to it on DS as well.  it's a shame the sequel to chrono cross never materialized
<NCommander> superm1, I didn't really care for chrono cross. Radient Dreamers which CC was based off was awesome though if you like those types of games
<NCommander> One of the most anonying but favorite games of mine is Legend of Zelda Majora's Mask
<superm1> oh very indeed that was an annoying game, i fear i ended up referring to some guides with what i was "supposed" eg what time to meet people
<NCommander> Its one of the few games I couldn't beat without a guide
<NCommander> Stone Tower was near impossible
<superm1> yup
<NCommander> Even with a guide, you have JUST enough time to get to the boss
<NCommander> Still, that game screws with your head
<TheMuso> NCommander: Just like ubuntu development does sometimes.
<NCommander> TheMuso, I'm so screwed most of the time it makes sense
<NCommander> Go having no social life
<NCommander> (until I was 16)
<NCommander> Twilight Princess was awesome, it does not have so much mind screwing as Majora's Mask which is why it once my second favorite
 * NCommander wishs Riven was available for Linux
 * NCommander finds the Song of Heading song for his cell phone
<NCommander> er, HEALING
<TheMuso> NCommander: I remember seeing somewhere that riven runs well under wine.
<slangasek> tjaalton: so we established that I have the right version of gnome-settings-daemon... no other guesses? :)
<NCommander> TheMuso, now I'd just have to find it, and then go insane trying to beat the fire marble puzzle
<tjaalton> slangasek: so your keymap works otherwise, but not some of the special keys?
<slangasek> tjaalton: yes; the basic 104/105 keys (depending on whether I'm plugged into the KVM) seem to work ok
<NCommander> slangasek, https://edge.launchpad.net/ubuntu/hardy/+queue?queue_state=1&queue_text= - BTW, would you mind approving for -proposed the gnome-python-extras (it needs a binary only rebuild to resolve an issue on PPC)
<tjaalton> slangasek: good to hear. I need to check if the mappings are 1:1 between the old and new method (kbd vs. evdev), seems that they are not
<tjaalton> slangasek: and if true, it shouldn't be too hard to fix
<slangasek> NCommander: not just now; I'll have a look at it Monday at the latest
<NCommander> slangasek, cool, thank you
<tjaalton> slangasek: do you know how the event flow worked on hardy? I don't know what role hal/gpm play in this
<slangasek> tjaalton: gpm shouldn't play any role in the stuff I'm interested in
<slangasek> tjaalton: I believe hal was involved and that something's gone askew in that regard in intrepid, but I don't know details
<tjaalton> slangasek: btw, would you ack bug 268055 and bug 268071
<ubottu> Launchpad bug 268055 in xorg-server "Please accept xorg-server 1.5.0-1ubuntu1" [High,Confirmed] https://launchpad.net/bugs/268055
<tjaalton> :)
<ubottu> Launchpad bug 268071 in xserver-xorg-input-synaptics "Please accept xfree86-driver-synaptics 0.15.1-0ubuntu1" [Undecided,Confirmed] https://launchpad.net/bugs/268071
<tjaalton> slangasek: ok, I'll take a look at hal. AIUI acpi-support should be obsolete, so it's a bit confusing to have it installed by default..
<tjaalton> s/take/have/
<slangasek> er, why do people keep asserting that it's obsolete?
<slangasek> nothing else is handling my Fn+F5 (wireless toggle) key, and as far as I'm concerned, nothing else should be handling it
<tjaalton> ok, so hal uses it?
<slangasek> I don't know
<tjaalton> so confusing..
<slangasek> but acpi-support provides handling of certain acpi events directly
<tjaalton> hm, ok
<slangasek> events which I don't see any reason for hal to even touch
<slangasek> why add 4 layers for events where 1 layer currently suffices?
<slangasek> regarding the freeze exceptions, I don't have time to look at those tonight, I'll have a look in the morning
<tjaalton> slangasek: could I poke someone else closer to my timezone?
<slangasek> tjaalton: sure, I think every other member of the release team is closer to your timezone ;)
<tjaalton> ah, lp shows a couple of candidates
<TheMuso> tjaalton: Are those packages in a PPA? I'd like to try them. If so, which PPA?
<tjaalton> TheMuso: synaptics is, xorg-server isn't since it wouldn't install (video drivers need to be rebuilt against it)
<tjaalton> TheMuso: http://ppa.launchpad.net/tjaalton/ubuntu/pool/main/x/xfree86-driver-synaptics/
<tjaalton> TheMuso: note that it's not the new 0.15.2 which was released yesterday
<tjaalton> although it has two patches that are in .2
<TheMuso> tjaalton: oh ok
<TheMuso> I was interested in 0.15.2. Never mind then, I'll wait to see if it hits the repo any time soon.
<lamont> ScottK: so on the script to un-chroot... do I have that one?
<tjaalton> hrm, subversion backport in hardy is broken, can't check certificates and complains
<tjaalton> ScottK-laptop: do you know about that ^^
<pitti> Good morning
<tkamppeter_> Riddell, hi
<Martiini> pitti .. where do you live
<tkamppeter> pitti, I have tried your D-Bus interface. From the command line it works as advertized as long as the driver is not already installed.
<pitti> tkamppeter: right, if it is already installed it doesn't do anything
<tkamppeter> With the driver installed I got bug 268649
<ubottu> Launchpad bug 268649 in jockey "jockey-gtk crashed with DBusException in call_blocking() (dup-of: 253224)" [Undecided,Invalid] https://launchpad.net/bugs/268649
<ubottu> Launchpad bug 253224 in jockey "jockey-gtk crashed with DBusException in call_blocking()" [High,Confirmed] https://launchpad.net/bugs/253224
<pitti> tkamppeter: thanks, could be a timeout (will look late)
<pitti> later
<pitti> tkamppeter: that thing also still needs a progress dialog for "Searching for drivers..."
<pitti> tkamppeter: it's just barely working now and needs bug fixes
<tkamppeter> pitti, but now to a new, independent problem: I do not succed to trigger the driver download window when doing the DBUS call from a Python program.
<tjaalton> ScottK-laptop: I think libneon needs a backport as well
<tjaalton> ScottK-laptop: see debian bug 474139
<ubottu> Debian bug 474139 in libneon27-gnutls "libneon27: Breaks access to some Subversion repositories" [Normal,Closed] http://bugs.debian.org/474139
<tkamppeter> pitti, see http://pastebin.ubuntu.com/45673/
<tkamppeter> This program actually makes Jockey running (one sees it in the output of "top"), but the Jocky window does not open.
<tkamppeter> pitti, splix is not installed on my box.
<tkamppeter> Riddell, I want to know, how you made Qt/KDE outputting PDF when one sends a print job to CUPS. It is for a general documentation on how to make a system using the PDF printing workflow.
<pitti> tkamppeter: do you get a crash report for it?
<pitti> tkamppeter: or does search_driver() return normally? (you don't print its result)
<tkamppeter> The small Python program does not cause a crash report.
<pitti> tkamppeter: or, rather, crash report -> exception message
<pitti> tkamppeter: (since you catch DBusErrors)
<tkamppeter> The program does not raise an exception. It prints the "Done." and not the "D-Bus Error".
<pitti> tkamppeter: ok, let's debug that in /msg
<didrocks> hi everyone
<didrocks> I removed a NBS (icedtea-java7-jre) recently
<didrocks> is it possible to remove it from the archives (and from people.ubuntu.com)
<didrocks> http://people.ubuntu.com/~ubuntu-archive/NBS/icedtea-java7-jre
<tjaalton> asac: what's up with urlclassifier3.sqlite, seems to grow at a fast rate for some users (on hardy)?
<tjaalton> asac: ok, I see there are bugs about it..
<tjaalton> user quota is 200MB, so ~50MB for that alone is a lot
<dholbach> WTF... somebody tried to order an Acer laptop under my name?!
 * dholbach just got a call, that address was incomplete
<norsetto> anyone has a link explaining what is the plan for the xen kernel on intrepid?
<wgrant> norsetto: domU is in the normal kernels, AFAIK. And dom0 support isn't planned, also AFAIK.
<EruditeHermit> is it possible to report a bug for a PPA that contains packages that might enter intrepid?
<wgrant> EruditeHermit: Only if an Ubuntu developer uploaded them to the PPA and explicitly says you're allowed to.
<EruditeHermit> wgrant: if not, is there anything I can do?
<norsetto> wgrant: ok thx, I guess that means that the dependency on the linux-xen meta package we have on hardy can be dropped for intrepid
<EruditeHermit> wgrant: I reported it upstream but they won't fix it until the next release which will miss intrepid
<wgrant> EruditeHermit: What makes you think it will be in Intrepid?
<EruditeHermit> wgrant: OOo3
<EruditeHermit> wgrant: I read in the forums it might make it
<wgrant> calc: ^^
<EruditeHermit> http://www.openoffice.org/issues/show_bug.cgi?id=93399
<ubottu> Error: Could not parse XML returned by OpenOffice.org: HTTP Error 404: Not Found (http://openoffice.org/issues/xml.cgi?id=93399)
<EruditeHermit> its late I have to sleep
<EruditeHermit> perhaps I'll pursue it tomorrow
<EruditeHermit> gnight
<EruditeHermit> thanks wgrant
<wgrant> Night EruditeHermit.
<tjaalton> asac: forcing urlclassifier.updatecachemax for now, will have to do until the quota is something larger :)
<asac> tjaalton: hmm
<asac> good point
<Riddell> mvo_: can you remember why we kept the KDE 3 version of dist upgrader available?  it's causing problems when it cycles through what can be run http://paste.ubuntu.com/45680/
<tkamppeter> Riddell, I want to know, how you made Qt/KDE outputting PDF when one sends a print job to CUPS. It is for a general documentation on how to make a system using the PDF printing workflow.
<mvo_> Riddell: I kept it under the (incorrect) assumption that we need it for people without kde4, but I think that is not true so feel free to bzr rm
<mvo_> Riddell: also I thought I removed it from the list of modules that are tried
<mvo_> Riddell: let me check
<mvo_> Riddell: could I get the /var/log/dist-upgrade/main.log from this? I'm curious why it tries to load the KDE version (it should try, gtk, kde4 and text in this order)
<Riddell> tkamppeter: it's explained here http://doc.trolltech.com/4.4/qprinter.html
<Riddell> tkamppeter: "On X11, QPrinter uses the Common Unix Printing System (CUPS) or the standard Unix lpr utility to send PostScript or PDF output to the printer."
<Riddell> tkamppeter: and this is what controls the output per application http://doc.trolltech.com/4.4/qprinter.html#setOutputFormat
<tkamppeter> Riddell, does this mean that you have patched all applications adding a setOutputFormat(QPrinter::PdfFormat)?
<Riddell> tkamppeter: no patch, it's what Qt does anyway, see this code http://paste.ubuntu.com/45717/
<Riddell> so if CUPS is new enough Qt sets it to PDF
<tseliot> pitti: what is "handler_id" that you pass update_driver_info_ui() in jockey-gtk?
 * Riddell points apachelogger towards mvo_ 
<tkamppeter> Riddell, so then in the upstream world Qt were the first ones to switch to the PDF printing workflow?
<Riddell> tkamppeter: yes I believe so
<ScottK> tjaalton: Thanks.
<ScottK> lamont: Russell Cocker emailed it to you.
<tkamppeter> Already before my Japanese co-workers finished the CUPS filters
<pitti> tseliot: the string from handler.id(); it should be stored in the tree model, so that you get it in the event handler
<pitti> tseliot: look at update_tree_model() in jockey-gtk
<tseliot> pitti: can it be something like this? NVIDIA accelerated graphics driver (version 173)
<pitti> tseliot: no, it's somethign like xorg:nvidia:173
<tseliot> pitti: hmm
<Riddell> mvo_: seems he doesn't have that log
<pitti> tseliot: the return values of Backend.available()
<pitti> tseliot: what you printed is Handler.name()
<tseliot> pitti: ah, ok
<mvo__> apachelogger: is that on a hardy->intrepid upgrade?
<apachelogger> mvo: yes, hardy KDE 3 -> intrepid to be precise
<tjaalton> pitti: btw, do you have time to ack bug 268055 and bug 268071?
<ubottu> Launchpad bug 268055 in xorg-server "Please accept xorg-server 1.5.0-1ubuntu1" [High,Confirmed] https://launchpad.net/bugs/268055
<ubottu> Launchpad bug 268071 in xserver-xorg-input-synaptics "Please accept xfree86-driver-synaptics 0.15.1-0ubuntu1" [Undecided,Confirmed] https://launchpad.net/bugs/268071
<mvo> apachelogger: and you have no /var/log/dist-upgrade/main.log when that fails?
<tjaalton> xorg-server is holding back xorg
<tjaalton> pitti: there's a newer synaptics upstream, which includes the two patches that my package has
<tjaalton> hmm I mentioned that on the bug..
<apachelogger> mvo: getting one right now
<apachelogger> mvo: http://paste.ubuntu.com/45724/
<mvo> apachelogger: thanks, I look into it
<Riddell> mvo: it's probably in the way adept runs it
<tjaalton> ScottK: I've built neon27 0.28-2 on hardy, and can't reproduce the problem with that, so svn should depend on that version
<tjaalton> ScottK: ..once it's backported :)
<ScottK> tjaalton: Thanks.
<Riddell> mvo: yeah it is, we add  *proc << "--frontend" << "DistUpgradeViewKDE";
<mvo> Riddell: oh, ok
<mvo> Riddell: then I rename kde4 to kde and it should all be fine
<Riddell> yep
<mvo> thanks for clarifiying
<broonie> Meh. Why is there nothing except git-am for  applying patch serieses?
<mvo> Riddell: is it worth keepng distupgradeviewkde3 around for reference or is the kde4 version complete and good enough so that this is not needed?
<james_w> pitti: Hey, I saw someone ask yesterday about consolekit 0.3. Are we pulling that in now? I found a couple of Fedora patches we need if not.
<pitti> james_w: unless there is a particular need to upgrade and do a FFE, we wouldn't
<pitti> james_w: what do we need it for?
<james_w> pitti: for me it just includes the patches I'll pull in, so I'm just interested in saving work if we do go to 0.3
<james_w> it sounds unlikely though, so I'll prepare a debdiff.
<pitti> james_w: if 0.3 is by and large bug fixes, we can consider it; haven't looked at it at all
<james_w> I haven't looked at it in that detail.
<ScottK> tjaalton: From my reading of those bugs, the problems all occur with later versions of libneon than we have in Hardy.  I'm not sure I want to mess with it.  Did you have an actual problem with the hardy backport?  I also found http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498351
<ubottu> Debian bug 498351 in libneon27-gnutls "libneon27-gnutls: latest upgrades broke svn https auth" [Important,Open]
<james_w> http://gitweb.freedesktop.org/?p=ConsoleKit.git;a=blob;h=b60fff3f1f41b7daf17427e998a2868cf9303460;hb=f0fb2d1cfd0f0ea3ad922175e895a9e751498a03;f=NEWS
<tjaalton> ScottK: the problem was with the subversion backport and current libneon
<james_w> bit of a mix of fixes and new stuff
<TheMuso> Is it just me, or is cdimage rather slow at the moment?
<TheMuso> Accessing via http.
<ScottK> tjaalton: Then I think you're having a different problem then the Debian bugs because those are all with later versions than we have in Intrepid even.
<tjaalton> ScottK: but turns out that since RHEL5 has only 1.4.2 I need to back out the upgrade since using 1.5 also updates the local repo so 1.4 clients don't work anymore
<ScottK> tjaalton: Yes, this is why the backport is important so that people who need access to 1.5 repos can get it.
<Riddell> mvo: the qt 4 one is complete, no need for the old one
<ScottK> tjaalton: I just woke up.  If you'd file a bug against hardy-backports, I'll look at it again later.
<tjaalton> ScottK: that also means that I need to clear my own copy if I want to use RHEL5
<tjaalton> ScottK: heh
<TheMuso> hrm seems fine now.
<tjaalton> ScottK: the error message I got was about the certificates, like on 474139
<tjaalton> updating neon27 fixed that
<ScottK> OK.  Please file the bug then.
<tjaalton> ScottK: sure thing, thanks
<tseliot> pitti: have a look at this: http://albertomilone.com/ubuntu/jockey/jockey-kde.png
<pitti> tseliot: nice! (something went wrong with the "Install" keyboard accelerator)
<tseliot> pitti: I'll look into it
<Riddell> tseliot, pitti: Qt uses & as accelarator indicator, GTK uses _ so it gets interprited as a literal underscore (and an automatic accelarator added anyway)
<pitti> ok, let's explain it here, was doing it in /msg
<Riddell> replace("_","&") or the like is the way to go
<pitti> Riddell, tseliot:
<pitti> ui.py has all user visible strings
<pitti> and uses _
<pitti> and ui.py's _() method has a convert_keybindings argument which needs to be True for strings with accelerators
<pitti> aah
<pitti> Riddell, tseliot: kde/jockey-kde's convert_keybindings() is not really implemented
<pitti> it needs to convert _ to & and __ to _
<pitti> I did that so that we don't have to translate all those strings twice, when they only differ by _ vs. &
<tseliot> pitti: ah, ok, I'll do complete that method then
<pitti> tseliot: only gotcha is to not convert __ to &&
<pitti> i. e. a simple .replace() isn't enough
<tseliot> pitti: yes, I know
<pitti> will probably become a regexp replace with look-ahead
<tseliot> pitti: 'Turn o_ff Driver' i.e. 'Turn o&ff Driver' looks like this: http://albertomilone.com/ubuntu/jockey/jockey-kde1.png
<tseliot> Riddel: any ideas on this ^^
<pitti> hm, weird; code-wise it looks alright?
<tseliot> pitti: yes, I made the program print the string, just to be sure
<tseliot> pitti, Riddell: this works though: http://albertomilone.com/ubuntu/jockey/jockey-kde2.png
<tseliot> why is 'Turn o&ff Driver' useless while 'Turn &off Driver' is not?
 * tseliot > lunch. Bbl
 * pitti lunches as well
<Riddell> tseliot: maybe something else is already using the f accelarator?
<Riddell> tseliot: you can just miss out the accelarator entirely and it usually picks something sensible
<tseliot> Riddell: I don't know if something else is using the f accelarator (automatically?) it is possible though.
<tseliot> pitti: would it be ok if I set 'Turn _off Driver' instead of 'Turn o_ff Driver' in ui.py?
<soren> update-manager is not going to suggest upgrading to Intrepid for Hardy users is it?
<persia> soren: It depends on whether they are LTS users or regular users.
<wgrant> meta-release-lts != meta-release, so I presume not.
<wgrant> persia: How is that defined?
<soren> persia: And how do we tell the difference?
<persia> wgrant: If someone upgraded to hardy from gutsy, I expect they are still tracking meta-release.
<persia> For new installs, it's probably meta-release-lts
<cjwatson> I didn't know update-manager tracked that
<wgrant> I wasn't aware that it was set upon installation.
<wgrant> But I guess that might make sense.
<soren> My meta-release config says:
<soren> URI = http://changelogs.ubuntu.com/meta-release
<soren> URI_LTS = http://changelogs.ubuntu.com/meta-release-lts
<soren> So if I were an "LTS user" both would point to -lts?
<soren> persia: Or what are you saying exactly?
<persia> soren: I'm a little confused.
<mvo> soren: not by default
<soren> join the club.
<persia> I thought it tracked at install, but I could be mistaken.
<pitti> tseliot: absolutely
<mpt> tseliot, it should be "Off", not "off"
<mpt> (regardless of access key)
<tseliot> mpt: ok, I'll fix it. Thanks
<mpt> oh, KDE version
<mpt> Actually, I'm not sure of KDE capitalization rules
<Riddell> I'd agree
<tseliot> ok
<mpt> ah yes, they're the same as for Gnome afaict
<tseliot> mpt, Riddel: is there some document you can recommend me about capitalisation in uis?
<tseliot> UIs
<mpt> <http://wiki.openusability.org/guidelines/index.php/Design_and_Layout:Visual_Design:Text_and_Fonts> is the relevant section of the draft KDE guidelines
<tseliot> Riddell: I always forget the 2nd "l" in your name. I should use TAB to auto-complete your name
<tseliot> mpt: thanks
<mpt> It says that "Prepositions having less than five letters" should not be capitalized, and "Off" is a preposition, but in this particular label it's being used as an adverb rather than a preposition.
<mpt> (Same with "Turn On".)
<tseliot> ok
<tseliot> Riddell: is there a way to make the UI adapt its size when the content of a label is changed and it's too long to fit in previously allocated space?
<mpt> Hmm, KDE says "less than five letters", Gnome says "three or fewer letters" ... ooh, controversy ;-)
<Riddell> tseliot: mm, it should do that magically
<Riddell> tseliot: if a label is using word wrap somewhere in the layout that can confuse it, resize(self.sizeHint()) should work (but not when called in the same method as setting the new text)
<mvo> funny that openusability uses colors to code "not started", .., "finished" - for me its difficult to see the difference between "not started" and "finished"  (the others are ok)
<pitti> tkamppeter: cups uploaded to experimental and intrepid
<kwwii> asac: in firefox the menubar takes the text color from the menu itself it seems...is there any way around that? ie is there some subclass that it uses which I could reference in a gtk theme?
 * ogra remembers a quest from mdz ages ago to get netpbm out of main ... 
<ogra> mdz, is that still necessary ? i just noticed it gets puled in by recommends
<ogra> *pulled
<mdz> ogra: it has been a security nightmare
<mdz> ogra: you can check with kees if that's still seen to be true
<radix> Is there a way to subscribe to get notifications of all changes to a package?
<ogra> kees, ping, whats your opinion on netpbm ... seems recommends pull it in again in intrepid
<ogra> radix, easiest is to subscribe to $(release)-changes
<radix> Ok, I guess i'll just have to do a bunch of filtering :)
<ogra> but that shows all uploads indeed
<ogra> beyond that i bet you can use LP :)
<radix> yeah, I was wondering if LP would do it, but I couldn't find anything
<jdstrand> ogra: well, I can answer that. it had 6 CVEs in 2005, 1 in 2006 and 1 in 2008. certainly not stellar
<ogra> https://launchpad.net/ubuntu/+source/<packagename>
<ogra> jdstrand, well, that sounds like we could keep it
<jdstrand> (and 3 more from earlier years)
<ogra> i just had that in the back of my head ... i thought it was licensing back then
<jdstrand> don't remember...
<ogra> predates your time i think
<jdstrand> maybe by a bit, but I was certainly kickin back then :)
<ogra> :)
<ogra> seb128, do you have a bug open for "switxh user option is shown if fusa isnt installed" in the logout dialog ?
<ogra> *switch even
<seb128> ogra: switch user doesn't required fusa, it just calls gdmflexiserver which is a gdm thing
<ronny> hi
<ronny> managed to get a weird issue on my intrepid
<ronny> after the last update, the up key is bound to making screenshoots instoead of up
<ogra> seb128, well, i'd like to have the possibility to disable it in the dialog
<tseliot> Riddell: sizeHint() doesn't seem to solve the problem here. If I use adjustSize() then the dialog grows vertically (but I want it to grow horizontally)
<seb128> ogra: having a gconf key for that would probably be nice
<ronny> however the key combination config says screenshoots are on the print key
<ogra> seb128, ubuntu-mobile works somewhat similar to a live system with autologin through gdm and a fixed system user ... there is no account to switch to
<ronny> any idea?
<ogra> its currently greyed out by default though ... but somewhat makes no sense to be shown at all
<tseliot> Riddell: for example, "This driver is installed and currently" in this screenshot is only part of the content of the label: http://albertomilone.com/ubuntu/jockey/jockey-kde.png
<ronny> anyone?
<tjaalton> ronny: upgrade again
<Riddelll_> tseliot: are you calling it on the top widget or the label?
<tseliot> Riddelll_: I tried both ways
<ronny> tjaalton: no upgrades availiable ?!
<Riddelll_> tseliot: are you calling it in the same method as where the text is set?  you typically have to call it after processEvents has happened
<tjaalton> ronny: what mirror do you use?
<ronny> de.archive.ubuntu.com
<ronny> tjaalton: which one should i use?
<tseliot> Riddelll_: the method which is connected to a signal (when an item is selected in the treeview) calls several methods, among which there are both the one which changes the label and sizeHint()
<tjaalton> ronny: what version of xkb-data is installed?
<tseliot> Riddelll_: otherwise I wouldn't know when to call sizeHint
<Riddelll_> tseliot: I sometimes resort to a QTimer.singleShot
<ronny> tjaalton: 1.3-2ubuntu2
<tkamppeter> pitti, OK
<tjaalton> ronny: and 'xprop -root |grep XKB', put it on pastebin.ubuntu.com
<tseliot> Riddelll_: I do something like this: http://pastebin.com/d5aae5c7e
<amitk> ouch... a recent intrepid upgrade leaves with no desktop - only my wallpaper and a mouse cursor. Any pointers to debugging?
<amitk> /s/leaves/left me/
<ronny> tjaalton: http://paste.pocoo.org/show/85014/
<amitk> Xorg.0.log has messages regarding "AUDIT <timestamp...> X: client 4 rejected from local host
<tkamppeter> pitti, I have seen the mail notification of the closing bug 263049
<ubottu> Launchpad bug 263049 in cups "CUPS test page does not display correct print job data. pstopdf filter needs improvements, test page needs some changes" [Medium,Fix released] https://launchpad.net/bugs/263049
<tjaalton> ronny: what about if you change the model to generic pc105?
<ronny> tjaalton: now both entries are '"evdev", "pc105", "de", "", ""'
<ronny> tjaalton: still no change on the breakage tho
<jcristau> ronny: what keycode/keysym does xev report when you press up?
<ronny> http://paste.pocoo.org/show/85015/
<jcristau> ronny: i want the keypress, not keymapnotify
<jcristau> if there is one, that is
<kees> ogra: I'm against netpbm going into main -- there are already several image libraries that can be used instead.  (and it is still gettings CVEs opened against it)
<mvo> ogra: what is pulling itin?
<ronny> jcristau: cant see one, might have missed it somewhere, is there a sensuble way to filter?
<ogra> kees, it *is* in main
<ogra> mvo, groff for one
<kees> ogra: arg, so it is.
<ogra> mvo, and i just saw that there was an oversigth in a tuxpaint merge
<ogra> i dont know how it got to main though
<ogra> nobody filed a MIR since it was demoted
<jcristau> ronny: not afaik
<kees> well, it's been in main since dapper, so unless it's easy to remove from main, I guess leave it as it stands.
<ronny> hmm, sems to work again
<ronny> just had to kill x11 even more often
<tjaalton> ronny: so you didn't restart your session in between?
<ogra> kees, weird ... i'm pretty sure it was demoted in hoary or breezy
<ronny> tjaalton: a few times
<ronny> i just messed up somewhere in betwen
<ronny> i just reconfigured everything again, killed x11 again, and this time it worked
<ronny> thanks for the help
<tseliot> Riddell: I have tried singleshot but it didn't work. I also tried to call sizeHint() when another button is clicked but nothing changes. The only solution is to resize the window manually...
<tjaalton> ronny: no problem. if it breaks again, ask on #ubuntu-x
<ronny> oh, ok
<ronny> cu
<cjwatson> kees,ogra: groff's build-dependency on netpbm predates Ubuntu, so netpbm will always have been in main, since long before we were doing MIRs
<cjwatson> I'm certain that that build-dep was never broken
<ogra> oh
<amitk> seb128: I just upgraded by intrepid machine and a reboot later after typing my password I only get my wallpaper and mouse cursor, no session
<seb128> amitk: is your lo interface correctly working?
<amitk> seb128: yes. ping localhost works.
<seb128> amitk: anything in .xsession-errors?
<amitk> seb128: I saw something in Xorg.0.log "AUDIT <timestamp....> X: client 4 rejected from local host"
<amitk> seb128: .xsession-errors: Unable to create /home/amit/.dbus/session-bus
<seb128> amitk: is dbus-x11 installed?
<amitk> seb128: yes
<amitk> seb128: gnome-panel is not installed anymore
<seb128> re
<seb128> amit: seems to be a dbus issue
<amitk> seb128: got my desktop back. The previous upgrade was a partial one and I didn't look carefully enough. But for some reason gnome-panel and related stuff was uninstalled. Reinstalling ubuntu-desktop fixes it.
<seb128> amitk: ah good
<mvo> amitk: oh? did you do a partial upgrade with update-manager?
<amitk> mvo: yeah
<mvo> amitk: and that removed ubuntu-desktop for you, hrm, that is bad
<amitk> mvo: if /var/log/dist-upgrade helps, I can supply that
<frafu> seb128: Hello, if I am correct, your are maintainer of gdm in ubuntu. If so, could you please have a look at https://bugs.edge.launchpad.net/ubuntu/+source/gdm/+bug/264834 ?   thanks.
<ubottu> Launchpad bug 264834 in gdm "RFE: Add gesture to start onboard and mousetweaks at login (patch supplied)" [Undecided,New]
<seb128> frafu: I've no clue about a11y and gesture
<frafu> All it takes, is to add a few lines to the AccessDwellMouseEvents file for gdm to recognize the two new gestures. The diff that I provided should add the necessary lines.
<seb128> frafu: alright, will consider if for the next upload
<frafu> seb128: thanks
<dendrobates> cjwatson: is it possible to select and hide the server seed(Basic Ubuntu Server) in d-i?  I think having a tasksel task that needs to be selected is confusing.
<tkamppeter> pitti. did you have a lokk at the Jockey/D-Bus issues?
<pitti> tkamppeter: not yet, still having 6 parallel /queries and ongoing discussions; a bit crazy ATM, but I'll get to it, promised
<pitti> tkamppeter: best is to file bugs and assign them to me
<cjwatson> dendrobates: I think so, sure; I think I asked whether you wanted that to start with and you said no
<cjwatson> dendrobates: can't do it now, but file me a bug on https://launchpad.net/ubuntu-cdimage/+filebug
<cjwatson> dendrobates: I thought it was shown in order to make it easy to deselect it; it's selected by default
<dendrobates> cjwatson: if I did, I was horribly confused, which is believable.  I'll submit the bug right away.   ta
<Koon> slangasek: could you please have a look at bug 254434
<ubottu> Launchpad bug 254434 in likewise-open "package libwbclient0 2:3.2.0-4ubuntu3 failed to install/upgrade: trying to overwrite `/usr/lib/libwbclient.so.0', which is also in package likewise-open" [High,Fix released] https://launchpad.net/bugs/254434
<Koon> slangasek: to be complete the fix needs a Replaces/Conflicts for libwbclient0 in samba
<mathiaz> james_w: does bzr bd still support building from the working tree ?
<james_w> mathiaz: yeah, it's the default
<mathiaz> james_w: in intrepid bzr bd --help says that the working-tree has no effect
<james_w> mathiaz: the option has no effect, as it's the default
<asac> pitti: there? could you look at the firefox -3.0 bits in bin NEW?
<pitti> asac: there yes, just having a load of about 4 :)
<pitti> asac: enough to do it during my archive day tomorrow?
<asac> pitti: sure
<asac> pitti: since you already know most of the details
<pitti> tseliot: merged jockey-generic to trunk and pushed
<tseliot> pitti: ok, thanks
<ScottK-laptop> bryce: Any chance you're ready to see displayconfig-gtk go away?   I think it's about to be the last remaining user of guidance-backends.
<pitti> ScottK-laptop: you saw my FFE for moving jockey to x-kit?
<ScottK-laptop> pitti: I did and I strongly endorsed it.
<ScottK-laptop> pitti: I tried to approve it (forgot it was Main and not Universe).
<bryce> ScottK-laptop: yeah I've actually got the change committed to our xorg git tree, but unfortunately there's also some changes checked in there that require the xserver 1.5.0 merge go in first, and that was waiting on a FFe last I looked
<ScottK-laptop> bryce: Is there a bug then then I can add my "please let guidance-backends die" endorsement to?
<bryce> no
<tjaalton> well, there's bug 268055
<ubottu> Launchpad bug 268055 in xorg-server "Please accept xorg-server 1.5.0-1ubuntu1" [High,Confirmed] https://launchpad.net/bugs/268055
<bryce> yeah, indirectly getting that one approved would help unstick things
<bryce> or I could just do a quickie xorg upload just with that one change
<pitti> mpt, mvo: "I think the rosette ribbon icon, that Add/Remove Programs previously used..." -> do you happen to have an icon name for that?
<ScottK-laptop> bryce: If you can do an upload that makes it OK for guidance-backends to go away, I'll buy you a beer | $BEVERAGEOFCHOICE then next time I see you.
<tjaalton> bryce: noooo, don't give in :)
<pitti> mpt: do you mean /usr/share/icons/hicolor/16x16/apps/application-supported.png ?
<pitti> mpt: unfortunately it's too small, and only bitmap; I prefer SVG icons
<bryce> tjaalton: it'd be a welcome respite from headbanging on keyboard mapping bugs ;-)
<tjaalton> bryce: hehe
<tjaalton> pitti: did you notice when I asked about that FFE bug (and bug 268071)?
<ubottu> Launchpad bug 268071 in xserver-xorg-input-synaptics "Please accept xfree86-driver-synaptics 0.15.1-0ubuntu1" [Undecided,Confirmed] https://launchpad.net/bugs/268071
<pitti> tjaalton: sorry, too much stuff going on today
<tjaalton> pitti: ok
<pitti> tjaalton: commented
<tjaalton> pitti: thanks. 0.15.1 is a bug fix release just like .2
<pitti> tjaalton: no FF matter then
<tjaalton> ok.. I thought all new upstream releases were
<tjaalton> silly me :)
<pitti> no, hasn't been like that for quite some time
<pitti> tjaalton: don't worry, it's much better to be too cautious :)
<tjaalton> pitti: excellent, I'll upload those asap then
<tjaalton> pitti: another thing.. since we now rely on the evdev driver, I'd like to update the package to HEAD. includes bugfixes and properties support, bringing most of the features that -mouse had
<tjaalton> pitti: mvo has been using a snapshot for some time now without a problem ;)
<tjaalton> as have I
<pitti> tjaalton: properties support> would missing it mean a regression from hardy?
<tjaalton> pitti: well, it allows to set the options while the session is running..
<pitti> tjaalton: like mouse speed, etc.?
<tjaalton> so there's no need to edit an fdi fiel
<tjaalton> -le
<tjaalton> don't know about the speed
<pitti> mouse speed setting with the gnome applet currently works for me
<tjaalton> that would still work
<slangasek> seb128: do you know if anything you've uploaded would explain the disappearance of bug #252174 in the timeframe indicated in the bug log?
<ubottu> Launchpad bug 252174 in gvfs "gvfsd-trash crashed with SIGSEGV in g_main_context_dispatch()" [High,Triaged] https://launchpad.net/bugs/252174
<pitti> tjaalton: if the chagnes are reasonably small and you tested them, please upload it now (right past an alpha)
<mvo> tjaalton: evdev? yes, I use it daily still. works fine for me
<tjaalton> pitti: I mean that it shouldn't cause regressions.. Right, will do
<pitti> tjaalton: no, what I meant is, would the lack of properties support with the current version be a regression from hardy?
<pitti> tjaalton: i. e. what kind of properties are we tlking about?
<tjaalton> pitti: well, regression in the sense that currently it doesn't support some options that -mouse used to support, and backporting only those is more work
<tjaalton> hmm, that sounds like I'm lazy ;)
<pitti> tjaalton: oh, you mean options in xorg.conf?
<pitti> tjaalton: ok, please go ahead then
<pitti> tjaalton: we'll probably want the bug fixes anyway
<tjaalton> pitti: yeah, for instance the one that after resume you might not have keyboard or mouse ;)
<pitti> *shrug* who needs that...
<tjaalton> heh :)
<pitti> tjaalton: I got a shiny joystick yesterday :)
<tjaalton> pitti: ooh, which one?
<pitti> just a simple one, Thrustmaster
<tjaalton> pitti: remember to paste the lshal output and file a bug, I need to add an fdi file anyway, at least for my logitech's
<pitti> I discovered that current dosbox finally runs x-wing
<pitti> :)
<tjaalton> evdev doesn't necessarily handle them too well
<pitti> and my old sidewinder (gameport) just doesn't work with inux
<tjaalton> heh
<pitti> tjaalton: well, I just need /dev/input/js0 for dosbox
<pitti> tjaalton: and I tested it with a LInux game, too (SearchAndRescue), worked fine
<pitti> tjaalton: I haven't tested the x input driver for it, though
<tjaalton> just plug it in and see if every button and axis works
<NCommander> slangasek, I looked at network applet, it doesn't seem SO hard to be able to allow you to set search domains
<cjwatson> doko: have you noticed bug 247694?
<ubottu> Launchpad bug 247694 in directfb "FTBFS in latest archive rebuild" [High,New] https://launchpad.net/bugs/247694
<tripwyre> Hi, can someone point me to a Kernel Module API reference or cookbook style reference?
<Treenaks> tripwyre: http://www.amazon.com/Linux-Kernel-Development-Novell-Press/dp/0672327201
<slangasek> mpt: I take issue with the phrasing "install and turn on" in reference to a driver :)
<Treenaks> tripwyre: it might be a bit old in places (like any book about a moving target), but it's a good start
<slangasek> mpt: how about "install and activate"?
<pitti> slangasek: alternative proposals were "Engage!" and "Make it so"
<slangasek> pitti: hahaha
<slangasek> well, these are mostly video drivers, right?  So we could "main screen turn on"...
<pitti> slangasek: no, we have wifi and printer drivers, too, for example
<pitti> we had vmware, too
<tripwyre> Treenaks: thanks, I expected something on the web.
<Treenaks> tripwyre: you asked for a book :)
<slangasek> "main screen turn on", "print screen turn on", "faithful without cable talking turn on"
<pitti> slangasek: (FWIW, the current German translation in jockey for the previous "Enable" string is pretty much "Activate"
 * slangasek thinks he deserves an honorary engrish degree for translating wifi as "faithful without cable talking"
<Martiini> langasek ..
<Martiini> steve langasek .. you tha man
<Martiini> slangasek .. hello ..
<sebner> slangasek: around?
<Martiini> where is langasek from
<Martiini> is he check
<Martiini> czeckhoslovakian .. i mean
<_MMA_> Czech or Slovak now. :)
<_MMA_> (If I remember right)
<Martiini> ok .. he isnt here apparently
<sebner> so I missed him for 10 minutes :P
<_MMA_> Martiini: He is. You're not looking hard enough. :)
<Martiini> sebner:  do you work with langasek
<sebner> Martiini: define "work with"
<Martiini> in the same office .. do you know langasek personally
<Martiini> is he from check
<Martiini> Im drunk btw
<Martiini> but not drunk beyond comprehension .. haha
<sebner> Martiini: no, sorry.
<Martiini> I posted a stupid thread to forums.debian.net .. tiled "Will linux become as good as OSX or vista" .. for which i got called troll .. obviously
<sebner> Martiini: alcohol is evil ;)
<Martiini> do you guys think linux distros can become a dominating force like microsoft OS-s or apple OS-s
<Martiini> yea .. I know .. I know how people use linux . but whenever i use linux on my laptop .. it pisses me off ..like flash not working on firefox 3 .. and .. kde4 not compatible with gnome ..  updates break system ..  etc etc .
<Martiini> I bought sicpack of beer and its all gone .. haha
<slangasek> Martiini: I'm of Czech descent; I'm from the US
<slangasek> sebner: yo?
<sebner> slangasek: you remember nfdump bug filed by you
<sebner> +?
<slangasek> sebner: yep
<sebner> slangasek: I contaced DM and he'll upload a new version to fix the stripping issue but he is right when he says that the -dbg package isn't empty. ;)
<Martiini> slangasek:  were you born in US
<Martiini> does it mean your parents are form czeck and you were born in US
<slangasek> sebner: it's empty in Ubuntu; not in Debian
<slangasek> Martiini: yes, why?
<sebner> slangasek: Why? I made a testbuild and it's apparently  *not* empty
<Martiini> ok .. nice to make aquaintance
<norsetto> does anyone know if zul is alive?
<slangasek> sebner: well, I think I mentioned in the bug that it's probably an adverse interaction between the package's own dbg stripping, and the Ubuntu buildd handling of automatic dbgsym packages
<LaserJock> norsetto: I sure hope so
<slangasek> sebner: so you may need to install pkgbinarymangler to reproduce the rpoblem
<slangasek> problem
<Martiini> Can you guys kick debian people in the ass .. so debian based distros can overtake Apple and Microsoft dominated software market
<sebner> slangasek: ah, I see
<sebner> slangasek: btw, he introduced it to find/fix a bug
<norsetto> LaserJock: I mean, alive in the metaphorical sense ;-) If he is around or on holidays or whatever
<sebner> Martiini: lol
<Martiini> i want to see EVERYONE use linux on their devices .. laptops, phones, servers
<norsetto> Martiini: kitchen ovens, refigerators, food dispensers ...
<ion_> I have OpenBSD on the router.
<Martiini> yes .. .everything on this planeet shoud run linux ..
<Martiini> we need touchscreen devices running linux .. not OSX
<norsetto> I'm quite sure we will one day have software operated toilet seats too
<Laney> norsetto: Imagine the core dumps...
<norsetto> Laney: hehehe
<Martiini> norsetto:  do they not have software operated toilets in japan
<mathiaz> norsetto: zul is on vacation today - he should be back tomorrow.
<slangasek> Martiini: so how did you come to ask if I was Czech?  Even some Czech people I've met didn't recognize my name as Czech without the diacritics. :)
<norsetto> mathiaz: ah ok, thx!
<Martiini> slangasek:   i dont know .. let me think
<ion_> slangasek: How is it written correctly?
<slangasek> ion_: LangÃ¡Å¡ek
<ion_> Alright
<Martiini> slangasek:  I dont know how i thought you may b czeck .. heh .. maybe its on the internet somewher
<slangasek> possible
<Martiini> slangasek:  do you work in california somwhere
<Martiini> i didnt realise its 9/11 today . .. ha
<sebner> slangasek: if the empty dbg package acceptable since we'll fix the stripping issue which the next sync?
<slangasek> sebner: yeah; I've questioned the legitimacy of the -dbg package existing at all in Debian, but that's not your problem :)
<slangasek> Martiini: Oregon.
<sebner> slangasek: fine :) I'll file a sync request then when debian package was uploaded. thx again for the hint :)
<Ampelbein> hi... i guess somehow i managed to break the lemon-buildmachine with a package of mine. (https://edge.launchpad.net/+builds/lemon) Can someone look into this issue? its been ~4 hours now in this state. i'm sorry.
<cjwatson> infinity: ^-
<cjwatson> Ampelbein: the relevant people are all on European time this week due to a meeting, so it may take a little while
<Ampelbein> ok. just wanted to say i'm really sorry. i don't know how this could have happened.
<cjwatson> happens, don't worry too much about it
<Martiini> slangasek:  hey .. when are yougoing to fix this major bug https://edge.launchpad.net/ubuntu/+bug/1
<ubottu> Launchpad bug 1 in ubuntu "Microsoft has a majority market share" [Critical,In progress]
<norsetto> Martiini: fixed already
<Martiini> no its not
<Martiini> I will finf you some statistics
<norsetto> no need, I can see no microsoft in the market which is in front of my house every saturday
<Martiini> norsetto:  how about this http://www.w3schools.com/browsers/browsers_os.asp
<Martiini> yes.. but major software developers write software for windows not linux
<Martiini> i get called a troll for raising this subject on linux forums  .. but I know im right
<_MMA_> Martiini: This isn't the channel to raise it either as this is a development channel. Not general chat.
<unfo> hi all, is there a ubuntu usability channel?
<_MMA_> unfo: Good question. Maybe #ubuntu-desktop?
 * _MMA_ looks for the IRC list.
<_MMA_> unfo: This might be of some help: https://help.ubuntu.com/community/InternetRelayChat#Channels
<unfo> _MMA_: i see from your link and from googling there is no such channel but that #ubuntu-desktop is close.  Thanks for the link.
<_MMA_> np
<NCommander> jdong, for any backport I'm doing with source level changes should be uploaded to the PPA, right?
<ScottK> NCommander: There's no requirement for that.  Debdiff in the bug is what we need.
<NCommander> ScottK, the wiki seems to suggest otherwise
<ScottK> Hmmm. OK.
<NCommander> Its your call
<NCommander> Since either you or jdong will be uploading
<norsetto> NCommander: I don't think jdong can upload actually
<NCommander> ScottK, https://bugs.edge.launchpad.net/hardy-backports/+bug/267391 - upload please :-)
<ubottu> Launchpad bug 267391 in hardy-backports "Please Backport aMSN" [Undecided,New]
<ScottK> NCommander: norsetto is right, because jdong is not core-dev.  I'm on my way out the door just now.  I'll add that with the Ada stuff to my stack.
 * NCommander loves (ab)using ScottK for backports :-)
<seb128> slangasek: do you think this gvfs bug is a high priority issue?
<ScottK> NCommander: In the meantime, please look at amule and do an FFe for it.
<NCommander> ScottK, amule? What's wrong with it
<ScottK> NCommander: There's an open bug on it being outdated.  I didn't get to if before FF.
<ScottK> It's in the bug.
<slangasek> seb128: the gvfsd-trash crasher?
<NCommander> ScottK, I'll ask SRU for the FFe first, and if its granted, then do the packaging
<seb128> slangasek: yes, we mainly see crashes due to apport
<ScottK> NCommander: You mean motu-release, right?
<slangasek> seb128: well, we see a lot of them though - 93 duplicates...
<NCommander> Oh, yeah
<NCommander> d'oh
<NCommander> :-P
<slangasek> seb128: so if the bug still exists, I think it ought to be high-priority?
<seb128> slangasek: I'm trying to push upstream to get it fixed for GNOME 2.24
<slangasek> seb128: ok - has it been diagnosed then?
<slangasek> the backtraces I saw didn't look meaningful
<seb128> slangasek: it's not trivial to fix, it seems to be due because dbus is used in threads which is not a thing to do
<norsetto> NCommander: you better do the packing first, we need build and install logs
<slangasek> seb128: ah, doh
<NCommander> Ah, thank you norsetto
<norsetto> NCommander: just in case, since its your first FFe (I think): https://wiki.ubuntu.com/FreezeExceptionProcess
<slangasek> seb128: what are the consequences of gvfsd-trash crashing, btw?  does it manage to respawn itself somehow after the crash?
<seb128> slangasek: no consequence, so crash seem to be mostly at shutdown and showing up next time the users log in, and yes the gvfs services are automatically spawned when required
<slangasek> seb128: ok, so effectively this is apport-generated noise more than anything
<seb128> right, and I've added an apport bug pattern now
<seb128> so it should stop duplicates
<norsetto> seb128: is it normal that /usr/lib/gtk-2.0/modules/libferret.so is common between libgail-common and libgtk2.0-0 yet they do not conflict with each other?
<seb128> norsetto: there is still a libgail in intrepid?
<norsetto> seb128: apparently
<norsetto> seb128: libgail-common |   1.22.3-1 | intrepid/universe | amd64, i386
<seb128> norsetto: you can file a remove request, libgail is in gtk now
<norsetto> seb128: makes sense, thx!
<pochu> norsetto: it has rdepends, shouldn't those be rebuilt/whatever first?
<norsetto> pochu: yes, I was checking that, glade has a depends on it and should be rebuild
<seb128> NCommander: hi
<NCommander> hey seb128
<seb128> NCommander: did you read my comments about gtkmm yesterday? ;-)
<NCommander> seb128, I have that odd feeling I had to do something for you
<NCommander> seb128, Yup
<NCommander> seb128, I remember now, sorry about that
<seb128> NCommander: that's alright, no hurry ;-)
<NCommander> seb128, I am rolling a debdiff now
 * NCommander is having backporting fun
<norsetto> seb128: libgail-gnome-module is not affected ?
<seb128> norsetto: I didn't look at it in details but I think it's still useful
<norsetto> seb128: ok, I'm asking since we need to rebuild glade and I see that its also quoted as a depends (as well as gail17 which should also obviously go)
<seb128> norsetto: I'm surprised glade is buggy, mvo rebuilt it when the new gtk has been uploaded
<norsetto> seb128: yes, but those depends are hard coded
<norsetto> seb128: its the old glade (in universe) not glade-3
<norsetto> seb128: unless you tell me that the glade in universe doesn't make any sense (it has two rdepends with are recommends, I can check if they can use glade-3 instead)
<norsetto> 4 rdepends actually, still all recommends
<seb128> norsetto: glade in universe has a sense, glade-3 has a different set of issues and some people still use the universe version
<norsetto> seb128: ok, then I rebuild it without the harcoded depends and see if those 4 are broken by it or not
<tseliot> seb128: I would like to talk to you about the g-c-p tomorrow, ok?
<seb128> tseliot: what?
<tseliot> seb128: about the gnome-control-panel
<tseliot> s/panel/center
<seb128> tseliot: tell now, I'll still be around for half an hour probably
<seb128> I'm too tired to look at code changes but I'm fine discussing on IRC ;-)
<tseliot> seb128: in my patch for gnome-desktop, the behaviour is preserved and the functions which were available before didn't change, at least not in their behaviour
<tseliot> xrandr-capplet.c changed a bit but AFAIK is not meant to be used by anything else
<tseliot> from what I remember I didn't break the ABI
<seb128> tseliot: <tseliot> yes, that would be necessary as I had to move one function (to compute the virtual resolution) from the capplet to gnome_rr_config.c
<tseliot> seb128: but xrandr-capplet.c doesn't even have a header file
<seb128> tseliot: you are adding some non upstream api to libgnome-desktop apparently though, or I'm getting that incorrectly?
<tseliot> seb128: yes
<seb128> tseliot: if upstream comes with a similar function but change the name we either need to divert or to break api and abi then
<seb128> if we drop the function you distro patched than an abi compatibility breakage
<tseliot> seb128: I can talk to upstream. BTW Federico wants to include my work in opensuse.
<tseliot> yes, I see your point
<seb128> if you do an ubuntu specific api prefix the function name using ubuntu or protect it on UBUNTU_SPECIFIC defines or something
<seb128> so it's clear it's not upstream and can break
<seb128> but always a good idea to open bugs upstream about such changes too to get their opinion and let them know about the changes we do
<tseliot> seb128: yes, sure I can do that.
<seb128> tseliot: thanks, if you do that I'm fine with the changes
<tseliot> seb128: the xrandr-capplet.c checks the existence of a python file which is specific to ubuntu (and soon to suse too)
<tseliot> therefore I'll simply remove it
<tseliot> and keep it as a patch
<tseliot> would this be ok too?
<tseliot> so that the rest can be accepted by upstream
<seb128> tseliot: looks good yes
<tseliot> and we only add that check
<tseliot> seb128: ok, great. Are there any deadlines for this?
<seb128> tseliot: upstream or in ubuntu?
<tseliot> seb128: both
<seb128> in ubuntu you still have some weeks to do changes
<seb128> GNOME is code frozen next week until GNOME 2.24
<lucas> mp
<seb128> so GNOME changes are probably for either 2.24.1 or 2.25
<lucas> rah
<seb128> hey lucas
<tseliot> seb128: ok, thanks for your time
<seb128> tseliot: np, thanks for your work on those changes ;-)
<norsetto> seb128: filed, should I subscribe ubuntu-archive or you want to have the honour?
<seb128> norsetto: please subscribe the team
<norsetto> seb128: okki dokki
<seb128> norsetto: thanks
<norsetto> seb128: thx to you, and good night
<seb128> 'night
<slangasek> augh, why are my volume up/down buttons on my keyboard adjusting a volume setting that's not reflected on the GNOME mixer applet?
#ubuntu-devel 2008-09-12
<slangasek> pitti: hmm, sqlite is still in main for intrepid; I think that was only needed for transitioning, and needs to be dropped now
<slangasek> pitti: (throwing this at you on IRC because I'm in the middle of three other things, feel free to bounce it back at me later ;)
<User546> anyone know anything about checksums?
<slangasek> ... yes?
<wgrant> Hmm. It is not encouraging to see somebody like that coming from a US tertiary institution.
<LaserJock> wgrant: how so?
<slangasek> eew, intrepid is creating /initrd.img and /vmlinuz symlinks in my root
<wgrant> LaserJock: I would have thought that university students should be smart enough to ask smart questions and not leave after 31 seconds.
<LaserJock> uhhh
<LaserJock> sorry, I just got done teaching 20 freshmen how to use Excel, I better keep my mouth shut
<wgrant> Hah.
<nixternal> gahahahha
<nixternal> and they taught LaserJock why he loves windows so much!
<bryce> ScottK-laptop: xorg uploaded; displayconfig-gtk is a thing of the past.
<LaserJock> what was most disturbing is that they were having a hard time figuring out Office 2003 as they were only used to Office 2007
<wgrant> LaserJock: Wow.
<wgrant> That's interesting.
<wgrant> I didn't realise that we already had people who have only used Office 2007...
<LaserJock> apparently
<LaserJock> and I haven't even used Office 2003 so I'm not much help
<LaserJock> next week though I'm hoping we have our Xubuntu lab finished
<f4hy> Hi all, What is the correct course of action to request for a newer version of a package for ibex, or better yet how would I package it myself and get it included?
<slangasek> f4hy: we're in FeatureFreeze for intrepid, so all new packages need to go through https://wiki.ubuntu.com/FreezeExceptionProcess
<f4hy> slangasek, hmm, well thats too bad. BOINC is at an unstable pre-release version in 8.10, was hoping to fix that
<slangasek> uhm, why doesn't the version number look like an unstable pre-release?
<slangasek> 6.2.12-1
<f4hy> slangasek,  would have to talk to the boinc guys about that, because 6.2.12 is not a full release for it.
<f4hy> slangasek, even when your run it, under "about" for the manager it says everywhere "pre-release"
<f4hy> also, messages get sent from the server asking to upgrade from the unstable version
<f4hy> "This is a development version of BOINC and may not function properly" is displayed under messages when first run.
<f4hy> So, to me that sounds like a bad thing, and do you think it would be reason enough for a freeze exception on it? or is the freeze a pretty hard limit
<slangasek> the guidelines for freeze exceptions are explained on the wiki page; the final decision on the risk/reward of any particular freeze exception here would be made by the motu-release team
<f4hy> 6.2.15 is the next stable release, and i think 6.3.0 is out. But i think it should at least get to the next stable
<f4hy> slangasek, alright thanks. I guess I will look into it. I think 6.2.15 is upstream in the debian repos so hopfully that will help
<slangasek> actually, Debian has 6.2.14 in unstable and 6.2.18 in experimental
<slangasek> I wouldn't dare to guess which of those are unstable pre-releases or not
<f4hy> slangasek, *sigh* that is unfortunate.
<calc> hi
<TheMuso> calc: Hi/ Are you safe?
<TheMuso> calc: As in, has your home been spared?
<superm1> well it's not hitting until tomorrow/saturday i thought?
<superm1> at least that's when we're getting all the rain resulting from it.....
<calc> TheMuso: yea, for now the hurricane will start to hit around 6pm tomorrow it looks like
<calc> TheMuso: but it looks like it is going east of us which is good if it does
<TheMuso> calc: GOod to hear.
<calc> i went back to my place for now, if it looks bad tomorrow around noon i'll head back out
<calc> fortunately the evacuation routes were much better this time, last time it took upwards of 20hrs to get to shelter for some people
<calc> i think they didn't really have a plan before, heh
 * calc headed to bed, bbl
<calc> i evacuated earlier than need be due to the bad experience before and the fact i have 1yr old son this time
<calc> it would have been bad to have him on the road that long
 * calc really gone to bed now :)
<dholbach> good morning
<doko> cjwatson: yes, waiting on 255275 (pitti needs to handle this, won't approve myself)
<ScottK-laptop> pitti: I've left you Bug 269272 as a present for your archive day.  Enjoy.
<ubottu> Launchpad bug 269272 in displayconfig-gtk "Please remove displayconfig-gtk source and binaries" [Medium,Confirmed] https://launchpad.net/bugs/269272
<ScottK-laptop> bryce: ^^^
 * ScottK-laptop no goes to sleep and dreams of it going away while he is sleeping.
<ScottK-laptop> no/now
<wgrant> It had a short life.
<TheMuso> 5~/c
<persia> doko: The python-2.5 and openjdk-6-jre packages include some .desktop files to launch the interpreters.  These are not shown by default.  Is there a reason we want to ship the files?
<doko> persia: why do you care if these are not shown by default?
<doko> hmm, I would be surprised by a .desktop file for a java interpreter
<StevenK> mobile-basic-flash shows them
<persia> doko: I care only because we're using a different menu system :)  I was surprised by both interpreter entries.  I see the point to openjdk-6-policytool.desktop, but not to python-2.5.desktop, openjdk-6-java.desktop or openjdk-6-javaws.desktop
<doko> well, it's policytool, not the interpreter
<persia> -policytool is, but openjdk-6-java.desktop execs /usr/lib/jvm/java-6-openjdk/bin/java -jar
<persia> Perhaps that's only supposed to be a MimeType registration entry?
<persia> similarly, python-2.5.desktop execs /usr/bin/python2.5 in a terminal, which seems a little odd.
<wgrant> So we have no significant theme changes for Intrepid, again?
<ion_> Thatâs awesome, considering the theme that was the default in intrepid for a while. :-)
<wgrant> Not a fan of NewHuman?
<ion_> I could live with it if everything else didnât have an eye-hurting contrast against it, most of the websites i frequent for instance. :-)
<wgrant> Right.
<pitti> Good morning
<ion_> ing
<wgrant> Evening pitti.
<StevenK> Morning pitti
<pitti> slangasek: hm, but it still has 4 reverse dependencies
<pitti> slangasek: one of which is bacula, which we promoted fairly recently; sorry, didn't catch that in the MIR
<pitti> ScottK-laptop: yay! I'll hand this to StevenK who is craving for killing something :-P
 * Hobbsee looks up
<Hobbsee> did someone mention killing?
 * NCommande wakes up
<NCommande> Killing?
<NCommande> Can we use a chainsaw ;_0
<NCommande> morning ScottK
<sleepster> how does one help the ubuntu dev?
<dholbach> sleepster: check out https://wiki.ubuntu.com/MOTU/GettingStarted - it links to a lot of important information
<sleepster> thanks
<atari2600a> hey
<atari2600a> don't mean to be annoying
<atari2600a> but what's that apt-get arguement to get a system up into the 8.10 repositories?
<Treenaks> atari2600a: this is not the channel for support, try #ubuntu+1
<atari2600a> fail
<atari2600a> kay, thanks
<atari2600a> leaving
<wgrant> Why is there Landscape advertising every time I log in?
<cjwatson> bug 268447
<ubottu> Launchpad bug 268447 in landscape-client "MOTD should not point to https://landscape.canonical.com if you are not a customer" [Undecided,New] https://launchpad.net/bugs/268447
<sleepster> so I should just help debugging MOTDs
<sleepster> in order to contribute
<Hobbsee> wgrant: because mneptok wants to deal with more painful users?
<persia> sleepster: I'd recommend finding anything that annoys you, and which you can understand, and fixing that.  You'll get more involved from there.
<Q-FUNK> hi! could anyone chekc bug #241307 and tell me what else I could do to help get this fixed at least for Intrepid (and preferably Hardy too, since Hardy is what broke it and it's LTS)?
<ubottu> Launchpad bug 241307 in linux "kernel oops during bootup in LTSP" [Undecided,New] https://launchpad.net/bugs/241307
<wgrant> cjwatson: Thanks.
<sleepster> thanks persia
<sleepster> I just have all this time, so I am trying to contribute to a project I like.. which is this
<cjwatson> pitti: FYI firefox is in new with abrowser (in place of webbrowser); does it meet with your approval? I'd rather not approve it myself since I was involved in the naming discussion
<pitti> cjwatson: yes, I quickly discussed that with Alex a couple of days ago, and I can live with it
<pitti> cjwatson: I'll shove it through NEW today
<cjwatson> great
<asac> pitti: thanks ;)
<tkamppeter> pitti, did you also package Jockey 0.5alpha1 for Ubuntu Intrepid?
<pitti> tkamppeter: yes, just uploaded
<tkamppeter> pitti, Thanks
<Riddell> pitti: about bug 269314, who's alberto?
<ubottu> Launchpad bug 269314 in jockey "Adapt KDE interface to new UI workflow" [High,In progress] https://launchpad.net/bugs/269314
<pitti> Riddell: tseliot
<Riddell> ah, top bloke
<pitti> :)
<tseliot> Riddell: right
<tseliot> ;)
<cjwatson> I always thought he was a bit of a waste land
<tseliot> cjwatson: that's a good one
<cjwatson> sorry, short notice and all that :)
 * Riddell doesn't get it
<cjwatson> oh, I should have used "a bit hollow", that's a much better reference
<cjwatson> Riddell: "The Waste Land" by T. S. Eliot
 * pitti is confused
<pitti> aah
<tseliot> Riddell, pitti: http://en.wikipedia.org/wiki/T._S._Eliot
<tseliot> and http://en.wikipedia.org/wiki/The_Waste_Land
<tseliot> cjwatson: how come do you know Eliot?
<cjwatson> tseliot: I don't particularly well, but it's hard to grow up in the UK without at least picking up a few references
<pitti> cjwatson: oh, did you clean up NEW? when I looked earlier, there were still 44 packages, and now my current accept tells me it's down to 8
<pitti> cjwatson: thank you
<tseliot> cjwatson: aaah. I studied Eliot in my 1st exam at the university but I had never heard of him before. I live in Italy, after all
<cjwatson> pitti: I did language packs and smart, yes
<cjwatson> only five minutes or so
<pitti> asac: just looked at NEW; I still don't understand the structure
<pitti> asac: abrowser-3.0-branding says "This is a meta package that will point to the latest abrowser package"
<pitti> asac: neither is true, it's not a meta package, and is specific to 3.0
<pitti> asac: and there is no actual metapackage for it which would serve that purpose
<pitti> so how is this meant to work?
<pitti> asac: i. e. will you remove that bit from the abrowser-3.0-branding description and upload another version which actually *has* an "abrowser" metapackage?
<pitti> cjwatson: since you were involved in the discussion, do you happen to know how that's supposed to look like? ^
<asac> pitti: there should be an abrowser package
<pitti> oh, of course, it's arch:all, sorry
<asac> pitti: description can be fixed afterwards (when i fix the branding package)
<asac> please dont block this on that
<pitti> asac: no, I won't; sorry, I missed that one
<asac> the branding package still ships files called awesome- ... basically because fixing that requires a new orig.tar.gz
<asac> ok thanks
<pitti> asac: oh, both packages replace firefox-3.0? is that intended?
<pitti> asac: NEWed to main
<asac> pitti: thanks. ill look at the replaces. i didnt touch them since i first did those packages (just renamed). so i dont remember for sure right now
<asac> pitti: ah .. yes both branding packages replaces firefox-3.0 because they ship files previously in that package
<tkamppeter> pitti, downloaded Jockey 0.5 from Launchpad and rebuilt, "Details" button at "License: Free" does not work (driver splix from OP).
<pitti> asac: ah, maybe it should be versioned then
<pitti> tkamppeter: ah, indeed, that still needs to be fixed
<pitti> tkamppeter: second
<asac> pitti: yeah. but i ran into versioned replaces issues in the past ... basically because hardy firefox will get a higher version on new security uploads
<asac> pitti: so thats the best i could come up here (without risking to break hardy -> intrepid)
<pitti> asac: should be (<< 3.0.2+build3+nobinonly-0ubuntu2)
<pitti> asac: i. e. the current version that has the split packages
<asac> pitti: yes. but hardy will soon have 3.0.3
<pitti> oh, if hardy gets 3.0.3
<pitti> indeed, nevermind then
<asac> pitti: i know its not nice. but its ok that way imo
<pitti> tkamppeter: bug 269352
<ubottu> Launchpad bug 269352 in jockey "Details button in GTK UI does not work" [High,Triaged] https://launchpad.net/bugs/269352
<tkamppeter> pitti, and the new driver list display is a one-timer. I run jockey-gtk twice, the first time all is OK, the second time only "splix" appears at the top and the details do not appear, also the action button stays grayed out, containing the label "Action".
<pitti> tkamppeter: where do you run that from? the current 0.5 intrepid package, or a bzr branch, or trunk?
<pitti> liw: does python-fstab have a FF exception? is it needed for intrepid?
<tkamppeter> Current 0.5 Intrepid package. I downloaded the source package from LP, as it is not on the mirrors yet. Then I rebuilt on an Intrepid box.
<pitti> liw: (it's in source NEW)
<bigon> could someone uplaod my SRU for bug 255307 to -update as the fix has been confirmed to fix the issue
<pitti> tkamppeter: hm, can you please file a bug about it with the details? please also include "jockey-gtk --list" output
<ubottu> Launchpad bug 255307 in pymsn "Can't connect to msn accounts" [Medium,Fix committed] https://launchpad.net/bugs/255307
<pitti> bigon: will walk over SRU in a bit
<ogra> pitti, is the code jckey uses to determine if restricted HW is there big ? i wonder if we could use that same code in the lrm initscript/initramfs scripts ... lrm eats at least about 5secs of your boottime for initializing even if teher is no HW that it needs
<pitti> ogra: what is "restricted hardware"?
<ogra> well, HW that needs restricted drivers i meant indeed :)
<ogra> i would like to see lrm off by default until uts actively used
<ogra> *its
<pitti> ogra: hm, what does lrm do during that time, link the .ko for the various wifi drivers?
<ogra> it mounts the tmpfs etc
<pitti> ogra: it does not install/contain the video drivers any more
<ogra> and wastes your ram and your bootime
<pitti> and the wifi drivers should by and large be handled like normal kmods
<ogra> imho it shoulndt bs sued/started at all until jockey has the chekmark set for the first time
<pitti> ogra: yes, indeed it should check whether it already built the .ko files and don't do all that magic then
<ogra> *used
<ogra> right
<pitti> ogra: but jockey depends on the .ko files and the modules.aliases to be present and current
<ogra> http://mg.pov.lt/hardy-20080822-1.png ... that wastes 5 secs for lrm-manager and friends
<pitti> so jockey can't know whether your wifi card needs a restricted driver, unless we have it available already
<pitti> ogra: well, that's not entirely true actually, since eventually we can use an online DB, but ATM we don't, we just use local modalises
<pitti> ogra: so one possibility would be that lrm shipd the modaliases pre-generated and then checks whether there is hardware which matches any of those, and then builds the .ko files
<pitti> ogra: that part of the code is reasonably isolated
<pitti> but it still takes a second or two
<ogra> well, i see S07linux-restricted-modules running there, firing off lrm-manager which then spawns ld_static
<ogra> imho S07linux-restricted-modules shouldnt happen at all i.e. only if enabled deliberately through an /etc/default file
<ogra> which can be seeded by jockey
<pitti> ogra: but we don't want all users to use jockey just to get their wifi card working, which would otherwise Just Work(tm) out of the box
<ogra> hmm
<ogra> i think i misunderstood jockey then ... i thought its for all restricted drivers, not only fglrx and nvidia
<ogra> but indeed that wlan example makes sense
<pitti> ogra: you can indeed use it to disable those restricted drivers, yes
<ogra> yeah
<doko> oha, a user submitting a bug report about a failed gmail login \o/
<Q-FUNK> :D
<pitti> ogra: the problem is that jockey relies on modalias files (it needs to get the hardware -> driver mapping from somewhere, after all, and so far modalias files are the standard means to do it
<pitti> ogra: but as I said, I think the built .ko files should be cached and not rebuilt/rechecked on every boot
<ogra> ok, i'll take a look at that in jaunty ...
<ogra> my usecase is that i want to just install linux-generic in ubuntu-mobile for netbooks but 90% of them dont use restricted HW at all
<ogra> though there might be someone with a USB nvidia card or somehing similar weird so i dont want to lose the functionallity in general
<pitti> USB gfx!
<pitti> does that actually exist? :-)
<ogra> yep
<pitti> ogra: wifi driver might be an issue
<ogra> i doub you find nvidia though
<pitti> ogra: NB that we don't install *any* nvidia bits by default in intrepid any more
<pitti> well, except their modalias lists
<ogra> yeah, it wasnt a really serious example :)
<ogra> but in any case lrm is quite a serious waste of ram and bootime
<ogra> so it should work more fine grained
<asac> ogra: ltsp installs > 30 users + firefox
<asac> ogra: what are your experiences?
<ogra> i have no 30 clients :)
<asac> ogra: you shoujld be subscribed to a bug of a user
<ogra> asac, i saw the bug and i see complaints on the ltsp ML
<asac> ogra: sure. i thought you might know people that have such installs
<ogra> one thing is that the session killig doesnt properly work if users just shut down the cliet HW
<asac> ogra: ok. so its a confirmed bug? i hoped its an issue in how its setup
<ogra> so you might have FF processes hanging around and keeping the lock
<ogra> another issue might be that these admins dont regard that you cant use 30 times the same user
<ogra> and anoter might be that /home gets mounted dynamically on login from an nfs share
<ogra> it really needs more research
<ogra> one simple fact is that gnome-session doesnt seem to clean up properly on exit
<pitti> ogra: I think the main problem is that the license doesn't allow us to ship the .ko files pre-linked; that would make it so much more efficient and avoid all this runtime linking stuff
<ogra> pitti, well, but it should be easy to add a check to the lrm initscript and make it just exit if lrm isnt required ... i'll look into that for the jackalope :)
<pitti> ogra: not as easy as you think IMHO
<pitti> ogra: but it should indeed be easy to make the boot check much more efficient (if the .ko files are already there, do nothing)
<ogra> right
<liw> pitti, python-fstab hasn't got an FFe, I am going to ask for an FFe for system-cleaner once mvo (or someone) uploads it, and system-cleaner needs python-fstab
<ogra> i'm sure *something* will be possible :)
<pitti> ogra: indeed
<pitti> ogra: and since Jaunty's goals include "boot-faster stripes", it's an adequate target :)
<ogra> yep, and falls into my duties for ubuntu-mobile as well
<ogra> thoug we might not define startup as boot ...
<persia> That's best bit about jackaloupes being mythical: one can use allegory to redefine the user experience.
<liw> persia, er, a non-existent user experience does not sound good
<ogra> but that might even make sense for ubuntu as a default (never shutdown after first boot of the system but hibernate and make that very fast)
<liw> ogra, is there a power use difference between hibernation and shutdown? I guess not
<ogra> hibernate writes the ram to your disk and shuts down
<pitti> ogra: I almost always hibernate, yes (except for kernel updates, or from some time to time when there's a new X or large GNOME changes)
<ogra> but you can very likely make the resuming extremely fast
<pitti> liw: no, it's completely off
<ogra> if you profile and adjust that a bit
<pitti> and booting from hibernation is faster than a "cold boot" (for me, anyway)
<pitti> but it still takes ages
<ogra> so boot time only affects you on first reboot after install and for HW changes
<pitti> (compared to windows)
<wgrant> Suspend serves me fine.
<ogra> pitti, i bet that depends... virgin windows is actually fast ... my GF boots way slower than ubuntu on her XP with 5 years of installed apps though
<ogra> wgrant, suspend needs power
<wgrant> Except it takes ages (15-20 seconds) to suspend, but just a couple of seconds to resume.
<liw> I have no machines on which hibernation works reliably, but resuming from hibernation always seemed to take more frustratingly long than just booting
<ogra> but from a user POV there is no real difference between hibernate and boot
<pitti> ogra: there is a lot, it keeps all your apss open
<pitti> apps
<wgrant> ogra: True, but I can leave this laptop for a couple of days without it going flat.
<pitti> whereas gnome-session entirely forgot how to save/restore your session in intrepid, unfortunately
<liw> ogra, some tasks like cleaning up /tmp and periodic fsck needs to be handled in some useful way, if there are no semi-frequent boots
<pitti> wgrant: I don't use suspend at home, because I take out the battery at home
<liw> of course, those tasks should be handled in some useful way separate from booting anyway
<pitti> and I don't want to waste power over night by leaving the plug and thus the AC adapter on
<persia> liw: Depends.  Having a non-existent user-experience of booting might just be fixing /tmp and fsck differently.  What else is routine and need not be exposed to users?
<pitti> doko: BTW, there is no need to create separate "SRU" bugs like bug 269299
<ubottu> Launchpad bug 269299 in glibc "glibc_2.7-10ubuntu4 for hardy-proposed" [Undecided,New] https://launchpad.net/bugs/269299
<pitti> doko: please just create hardy tasks for the actual bugs you fix
<pitti> and sub ubuntu-sru to them
<pitti> mvo_: is bug 268052 relevant for intrepid? if not, please close the intrepid task
<ubottu> Launchpad bug 268052 in app-install-data-commercial "SRU for db2, opera, parallels" [Undecided,Fix committed] https://launchpad.net/bugs/268052
<pitti> mvo_: also, any idea about the failure in bug 241431 ?
<ubottu> Launchpad bug 241431 in update-manager "edgy to feisty upgrades fail due to use of old-releases" [Medium,Fix committed] https://launchpad.net/bugs/241431
<mvo_> pitti: let me check
<mpt> pitti, yes, that rosette icon
<mpt> pitti, having it scalable is a good idea, but I don't think it's as important as having the right icon in the first place
<pitti> mpt: hello
<mpt> Using an Ubuntu icon isn't particularly meaningful in this context
<pitti> mpt: I sent you an updated status yesterday with an updated screenshot; let me know what you think
<pitti> mpt: well, I initially thought "tested by the %(os) developers", so I used "distributor-logo"
<mpt> slangasek, why do you take issue with it?
<pitti> but the certification icon is nice as well
<pitti> Riddell: hm, did you accept the hardy SRUs in https://edge.launchpad.net/ubuntu/+source/kio-umountwrapper ? there is no LP # associated with them
<Riddell> pitti: let me look
<mpt> pitti, yep, that looks good
<pitti> \o/
<mpt> though those not-installed icons are pretty alarming for something that's not even being used
<Riddell> pitti: bug 186729
<ubottu> Launchpad bug 186729 in kio-umountwrapper "Cannot uninstall kio-umountwrapper" [High,In progress] https://launchpad.net/bugs/186729
<mpt> pitti, is there a grey equivalent?
<pitti> mpt: the red bullet?
<mpt> yes
<pitti> Riddell: ah, it got positive feedback; I'd move this to updates, unless you object?
<Riddell> pitti: yeah please do, sorry about the missing bug number not sure how I forgot that
<pitti> Riddell: no problem, it just leads to stalled processing; I'm just walking over all the old ones
<mpt> pitti, would you prefer feedback here or by e-mail?
<pitti> mpt: by email actually, so that I can work on it in the plane on Monday
<mpt> ok
<pitti> mpt: thanks
<asac> if i do cat /proc/locks i get numbers like: 08:06:4767745 ... those include major/minor device ids
<asac> any idea how i can see what major/minor device a nfs mounted partition has
<Hobbsee> evand: how much has the installer changed since alpha 5?  I installed off it today, and noticed some bugs in it.
<ogra> asac, ?? nfs is a filesystem
<ogra> there is no devices
<ogra> *device
<ogra> so no major minor device number
<asac> ogra: how would nfs locks show up in /proc/locks
<asac> ogra: ok. but is there something similar to a minor number?
<ogra> no idea
<ogra> for either of the questions
<asac> too bad.
<mvo_> asac: the nfs root mini howto says "mknod /dev/nfsroot b 0 255"
<asac> ;)
<asac> mvo_: ah
 * asac looks at nfsroot
<asac> hmm ... doesnt exist here
<ogra> well, thats for rootfs on nfs afaik
<pitti> mpt: I didn't find another matching stock icon; "stop" maybe (gray rectangle, as in music players)
<pitti> mpt: but then I'd rather make the icon consistent to what is shown on the "Turn on/off" button
<mvo_> ogra: (I missed most context and thought I just add the snippet of information I have :)
<ogra> :)
<mpt> pitti, actually I'd rather that button didn't have any icons at all :-)
<pitti> mpt: and that uses the 8-edge red sign wiht a white X
<mpt> pitti, because it competes for attention with the actual status icon
<pitti> mpt: if you say so
<ogra> asac, i case you look for firefox context, i think the /proc/locks stuff is kernel only
<ogra> based on the flock system call
<asac> ogra: ffox uses fcntl and the locks show up as posix locks
<asac> ogra: the current issue i have is sqlite
<pitti> mpt: oh, another possibility: I could use the stock icons for "connected" and "not connected" (the plug)
<asac> which appears to use flock and somehow breaks on nfs
<asac> ogra: well. i still want to verify that that lock without running pid is on that nfs partition
<asac> but i ma quite sure
<ogra> asac, http://www.time-travellers.org/shane/papers/NFS_considered_harmful.html
<ogra> look for flock
<siretart> asac: flock() does not lock files over NFS.  Use fcntl(2) instead
<siretart> asac: see flock(2), section NOTES, first paragraph
<asac> siretart: exactly
<ogra> In Unix, there are two flavours of file locking, flock() from BSD and lockf() from System V. It varies from system to system which of these mechanisms work with NFS.
<asac> siretart: i know about that
<mvo_> asac: flock does not work on nfs (see flock(2))
<asac> siretart: however since 2.6.12 client its supposed to be supported
<mpt> pitti, is the "stop" icon the one Empathy uses for "Offline"?
<ogra> asac, lockd is usually responsible for locking on nfs btw
<ogra> might be that we dont enable it by default
<ogra> since ltsp switched from nfs to nbd i'm not up to date anymore :/
<asac> ogra: so. disregarding that sqlite should probably use fnctl, http://nfs.sourceforge.net/ says that flock is supported since 2.6.12 clients ... where can i see the client version?
<siretart> locking is btw the only reason why linux needs portmapper as nfs client...
<ogra> ogra@osiris:~$ apt-cache show nfs-common|grep Version
<ogra> Version: 1:1.1.2-4ubuntu1
<amitk> cjwatson: FYI: LPIA kernel is ready to be uploaded. This is an ABI bump.
<asac> ogra: is that really the client version?
<cjwatson> amitk: thanks
<ogra> asac, thats cntaining nfs-client
<asac> ogra: i looked at it and assumed that its too low given that nfs refers to 2.6.12
<cjwatson> amitk: 2.6.27-3, I take it?
<amitk> cjwatson: yes. persia will upload it soon.
<pitti> mpt: http://people.ubuntu.com/~pitti/tmp/STOCK_STOP.png and http://people.ubuntu.com/~pitti/tmp/STOCK_DISCONNECT.png
<pitti> mpt: DISCONNECT's counterpart (CONNECT) is a plug which is plugged in, STOP's counterpart would be "PLAY" (gray triangle, as in totem/rhythmbox)
<mpt> pitti, eek, stop definitely
<cjwatson> amitk: cool, thanks
<mpt> I mean, STOCK_STOP definitely
<pitti> mpt: and for enabled ones, STOCK_PLAY (more consistent counterpart) or STOCK_OK (the green check mark, better contrast)
<pitti> mpt: i. e. the one on http://people.ubuntu.com/~pitti/tmp/jockey-new.png on the button
<mpt> pitti, neither, whatever Empathy uses for "Available"
<pitti> is there a screenshot anywhere? otherwise I'll install it
<mpt> or, if it exists, the green opposite of the red ones in that screenshot
<pitti> ah
<pitti> it doesn't exist as a stock icon
<pitti> but I can grab it from somewhere, of course
<mpt> ok
<zul> cjwatson: can we get the tomcat-server added to tasksel please?
<pitti> mpt: heh, tango has nice icons for sun and moon as well :-P
<ogra> asac, i think that refers o the kernel module side
<ogra> (sorry in a call)
<asac> ogra: no problem.
<asac> ogra: ill ask the reporter to go the hardway (e.g. find / -inum inode_no)
<pitti> mpt: ok, using empathy-available.svg then (copying)
<mpt> pitti, where did you get the bulbous red one from?
<pitti> mpt: that's one of GTK's stock icons (STOCK_STOP)
<Riddell> how do I report a bug in a translation?
<pitti> Riddell: against language-pack-LL
<pitti> and subscribe ubuntu-l10n-LL
<mpt> pitti, so is there a GO opposite?
<pitti> mpt: erm, sorry, stock icon for "No"
<pitti> mpt: and the opposite, yes, is the green check mark
<mpt> oh, bother
<mpt> ok
<tseliot> Riddell: I have solved the problem with the label in jockey-kde
<pitti> ATM jockey uses NO/YES
<pitti> mpt: so now I could change it to STOP (the grey square) and the green round "available" one
<Riddell> tseliot: ooh, how
<Riddell> ?
<Riddell> pitti: thanks
<tseliot> Riddell: somehow an additional vertical layout ended up in the ui and prevented the ui from resizing properly
<pitti> mpt: you don't like the green check mark for enabled drivers? it's a stock one, so jockey wouldn't need to ship it
<Riddell> tseliot: ah, how annoyingly fiddly
<tseliot> Riddell: yes, I was looking anywhere but in the right place...
<pitti> mpt: oh, I just saw that the official GTK upstream GTK_STOCK_YES is indeed a green round circle, apparenlty that has been replaced with a checkmark in our ubuntu theme
<mpt> pitti, what I think would make most sense is a small, round, light grey bulb that becomes a small, round, glowing gren bulb when it's activated.
<mpt> green, rather
<mpt> I don't think it makes sense to use a checkmark, because it's too similar to a checkbox and because it understates the effect of the change.
<pitti> ok
<norsetto> zul: hi, was wondering if you could check bug 268762? Don't know much about xen myself so I could just talk rubbish
<ubottu> Launchpad bug 268762 in xen-meta "ubuntu-xen-desktop has wrong dependencies in intrepid" [Undecided,Confirmed] https://launchpad.net/bugs/268762
<soren> zul: ^^
<zul> norsetto: yeah Ill try to have a look at it today
<norsetto> zul: much obliged
<pitti> mpt: http://people.ubuntu.com/~pitti/tmp/jockey-new-stop_connected-icons.png
<mpt> Oh, they're not even the same size :-(
 * wgrant cries.
<wgrant> Why is there a checkbox labeled "This driver is not installed"?
<pitti> wgrant: it's not a checkbox, it's a "stop" icon
<mpt> Yeah, that's a very Windows XP checkbox
<pitti> bwah, icons
<wgrant> Ohh.
<wgrant> I thought it was a nice double-negative checkbox.
<mpt> or a Mac OS 8/9 close box
<mpt> kwwii!!!
<mpt> We need halp
<pitti> I can has an icon?
<Hobbsee> pitti: noes.  no gummy bear, either.
<pitti> wgrant: http://people.ubuntu.com/~pitti/tmp/jockey-new.png is the current state
<wgrant> What's wrong with a checkbox?
<pitti> wgrant: s/box/mark/?
<wgrant> pitti: That looks dangerous.
<mpt> wgrant, it's not momentous enough
 * mpt continues to suffer from a lack of good words to describe these issues
<wgrant> Do those that aren't enabled actually need an icon?
<mpt> wgrant, I think that would look unnervingly like this window didn't know whether they were activated or not
<pitti> I think the best way forward right now is to have lunch, before I entirely miss preparing myself for the release meeting later on
<mpt> wgrant, especially if all the drivers in the list happen to be turned off.
<wgrant> mpt: True.
<wgrant> Anyway, /me -> bed. Have fun working it out.
<kwwii> mpt: wassup?
<mpt> kwwii, do you have time to draw us four small icons?
<mpt> for the Hardware Drivers window
<_MMA_> mpt: They have to be custom? There's nothing that conforms to FreeDesktop we can use?
<mpt> _MMA_, no, see the previous 59 minutes discussion
<mpt> (Also, it's an awkward choice of words to imply that "confirms to FreeDesktop" requires using no custom icons. The standard icon names never have covered, and never will cover, all the icons every app ever needs.)
<_MMA_> mpt: I've seen most of it. And sure, not everything is covered there. I just don't wanna see more icons that cant be themed. As I'm heading an effort currently for a new set.
<_MMA_> *new set for Ubuntu.
<ogra> as the guy who works wiht desktops that use 48px panels on touchscreens i'd like to bg you guys to use scalable icons :)
<kwwii> mpt: send me an email with the description of what you need and/or a screenshot of the current stuff and I will see what I can do
<ogra> *beg even
<ogra> the human theme is a mess with that
<mpt> thanks kwwii, will do
<ogra> i have to use gnome on ubuntu-mobile to make te icons usable eith fingers
<ogra> *with
 * norsetto wonders about the size of ogra's fingertips
<Robot101> huge, in comparison to the pixels on a high-res mobile lcd touchscreen
<ogra> norsetto, they are 48x48px on 1024x600 7" screens :)
<Robot101> :)
<ogra> well, index is probably 36x36 :) but i use my fat thumb quite often
<cjwatson> zul: somebody needs to create the seed
<zul> cjwatson: its already done in my branch ready to be merged
<evand> Hobbsee: There were a few changes that went in after alpha-5.  Have you created bug reports for these issues?
<ScottK-laptop> StevenK: If you're still about, I also have Bug 269393 for you.
<ubottu> Launchpad bug 269393 in kde-guidance "Please remove kde-guidance source and binaries and guidance-backends binary from Intrepid" [Undecided,Confirmed] https://launchpad.net/bugs/269393
<Hobbsee> evand: not yet.
<StevenK> ScottK-laptop: Always happy to remove stuff
 * ScottK-laptop figured.
<norsetto> StevenK: If you're still about, I also have Bug 268713 for you.
<ubottu> Launchpad bug 268713 in gail "libferret.so overwrite attempt - libgail-common versus libgtk2.0-0" [Undecided,Confirmed] https://launchpad.net/bugs/268713
<cody-somerville> norsetto, let the man sleep :P
<StevenK> norsetto: Aye, will do.
<norsetto> cody-somerville: why!? :-)
<cody-somerville> norsetto, A tired StevenK is a grumpy StevenK :P
<norsetto> StevenK: thx, I knew I could count on you :-D
<norsetto> cody-somerville: just trying to make him happy ;-) (<StevenK> ScottK-laptop: Always happy to remove stuff)
<cody-somerville> hehe
<Hobbsee> evand: ah, so i'm not mad.  I hit https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/264599 too
<ubottu> Launchpad bug 264599 in ubiquity "Intrepid: manual partitioner fails to use remaining space fully" [Undecided,New]
<cjwatson> zul: /wg 112
<cjwatson> oops
<evand> Hobbsee: hrm, ok
<Hobbsee> evand: ah, most of the stuff I found seems to already be reported.  I hit  https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/259713 (before a resize), and https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/264595 (after doing a resize), and found that / doesn't get automatically ticked to format by default.  I'm sure there's a bug for that somewhere too, but I can't find it right now.
<ubottu> Launchpad bug 259713 in ubiquity "Intrepid alpha partitioner regression(s)" [Undecided,New]
<ion_> 112? Dayum.
<Hobbsee> evand: I also had X blow up twice during the install, so had to install a second time, but I doubt that's due to you.
<Hobbsee> evand: FWIW, i also found it non-obvious how to leave a partition the current size - it seems the field is there to only change it - i was afraid it would randomly resize my partitions if i did, or did not, change the values in that field - it's all just a bit unclear - particularly when it says sizes like '0' to start with
<evand> I sure hope it isn't :)
<Hobbsee> fortunately, my
<Hobbsee> fortunately, my 'doze still works.  I was half expecting it not to, after dying the first time while partitioning.
<evand> Leaving it untouched *should* leave it as is, but a bug like this throws everything out the window.
<Hobbsee> evand: yeah....i think it probably would have, it was just the GUI that was unclear.
<Hobbsee> evand: oh, and the timezone setter map thing is a nightmare - maybe it was because the window wasn't properly done, or something.  I'm not sure, but I found it very hard to actually select my location on it.  I thought there was a ffe bug to fix that, a while ago.
<Hobbsee> so perhaps that's the improved version
<Hobbsee> it also picked the wrong time, the first time around.
<evand> Yeah, there's still at least one fix needed for that, which will go in before release.
<Hobbsee> cool :)
<evand> It was supposed to be replaced by a *much* better version, but I ran out of time in implementing it.
<evand> so that will happen for Jaunty.
<Hobbsee> ah, yes.
<Hobbsee> I see that bug now.
<norsetto> evand: is bug 268115 relevant for you ?
<ubottu> Launchpad bug 268115 in auto-install "Not actually a bug, just a big source of trouble" [Undecided,New] https://launchpad.net/bugs/268115
<mdz> asac: the most recent firefox update gave me ugly widgets.  I don't see a bug report about it; am I the only one?
<asac> mdz: ugly widgets?
<mdz> asac: http://people.ubuntu.com/~mdz/temp/Screenshot-firefox.png
<evand> Hobbsee: That sounds very similar to a bit from ubiquity-visual-refresh that mpt suggested, which I hope to sneak in with a UI freeze exception.
<ogra> looks more like a theme issue
<mdz> different shade of gray, different drop shadow
<Hobbsee> evand: interestingly, a friend of mine recently installed ubuntu, and got very confused on the partitioning section - had no idea what it was, so went with the defaults - all was fine, but there might be more you can do to make it newbie-friendly - maybe add a link with an explanation somewhere, or something.
<Hobbsee> evand: good luck :)
<mdz> ogra: it's only firefox...but then, that's the only app I restarted
<asac> mdz: yeah. thats the "default" gtk theme ... looks like your gnome theme is somehow not honoured
<mdz> yeah, it affects rhythmbox as well
<asac> hmm ... at least the widgets. the icons are right
<mdz> anything I start since the update
<evand> Hobbsee: I did add a visual representation of the partition table on both the automatic partitioning page (shows you the disk before and after) and the manual partitioning page (shows you what the disk will look like as you chang eit)
<asac> mdz: sounds more like a theme bustage
<Hobbsee> that looks like motif.  I saw that on hte livecd today, and wondered why that was there.
<evand> Hobbsee: so hopefully that's a helpful start
<asac> mdz: what else was upgraded?
<Hobbsee> evand: oh, that'd be good - but i think this particular one was the screen first.
<asac> maybe you need a restart of gnome session?
<mdz> asac: lots
<evand> ok
<mdz> I just tried restarting gnome-settings-daemon and that made it worse
<seb128> mvo__: there?
<mdz> I need to reboot for the new kernel anyway, I'll just do that and it will probably sort itself out
<ogra> human-theme was updated on wed.
<asac> mdz: thanks. lets hope ;)
<Hobbsee> mdz: if you open up the appearances section, do you get a message saying human-murrine or something isn't installed?
<Hobbsee> bah.
<mvo> seb128: yes
<asac> ogra: but does a theme update require a restart?
<asac> ogra: engine update i could imagine
<ogra> it shouldnt
<seb128> mvo: bug #269215 looks weird, just to let you know in case you screwed something
<ubottu> Launchpad bug 269215 in gconf "There is a problem with the configuration server. (/usr/lib/libgconf2-4/gconf-sanity-check-2 exited with status 256)" [Undecided,Confirmed] https://launchpad.net/bugs/269215
<ogra> asac, well: * Added gtk2-engines-ubuntulooks to Conflicts and Replaces
<ogra> not sure what that implies though
<asac> oh ... so the engine has been removed ;)
<ogra> the old one
<ogra> it shuld use murrine afaik
<asac> ogra: is there a replacement?
<asac> ah ok
<ogra> since a while already
<ogra> but only kwwii could tell :) i'm only following artwork loosely
<asac> ok. feels like changing engine during upgrade can cause such issues
<mvo> seb128: thanks, I check it out, the diff http://launchpadlibrarian.net/17534395/gconf_2.23.2-0ubuntu2_2.23.2-0ubuntu3.diff.gz looks pretty safe though
<ogra> well, the gtkrc shouldnt point to that engine anymore
<ogra> but if you use a theme that does this might break it
<mdz> nope, that didn't fix it
<seb128> mvo: indeed
<Hobbsee> [23:24] <Hobbsee> mdz: if you open up the appearances section, do you get a message saying human-murrine or something isn't installed?
<seb128> mdz: try opening the appearance capplet and see what is selected there?
<mdz> seb128: my theme is set to 'custom' now
<mdz> Hobbsee: ^^
<Hobbsee> hm.
<mdz> but I have not changed it
<mdz> "this theme wil not look as intended because the required GTK+ theme 'Human-Murrine' is not installed"
<seb128> mdz: grep for gtk in the dpkg.log so see which themes got installed or removed?
<Hobbsee> ah yes, that's the error message.
<mdz> ii  gtk2-engines-murrine                      0.53.1+svn20080529-0ubuntu3           cairo-based gtk+-2.0 theme engine
<ogra> ouch
<Hobbsee> seb128: fwiw, that's also on an alpha5 cd, at least some of the time.
<mdz> perseus:[~] grep 'remov.*gtk' /var/log/dpkg.log
<mdz> 2008-09-08 09:56:26 remove libgtk2.0-dev 2.14.1-0ubuntu1 2.14.1-0ubuntu1
<ogra> -dev
<mvo> Riddell: could you please commit your changes to compiz into the compiz bzr?
<mvo> Riddell: (probably just a forgotten bzr push)
<Hobbsee> tjaalton: oh, is there a new mesa to test?
<ogra> mdz,
<ogra> human-theme (0.24) intrepid; urgency=low
<ogra>  .
<ogra>    * fixing problem in setup.cfg
<Riddell> mvo: to compiz?
<ogra> night have a typo or some such
<ogra> the same upload removed ubuntulooks
<Riddell> mvo: oh, that right, hang on
<tjaalton> Hobbsee: yes, but if the drirc trick didn't work, maybe the new mesa won't either. but please, do test :)
<mvo> Riddell: thanks
<Hobbsee> tjaalton: got a location?
<tjaalton> Hobbsee: the archive?
<mdz> Hobbsee: you saw this as well? is there a bug open?
<Hobbsee> mdz: i saw it on a live cd today.  I've nto reported a bug so far.
<asac> mdz: apparently the old engine was replaced by murrine
<Hobbsee> mdz: I've just checked the ISO testing thing, where nothing was raised - which is surprising.
<ogra> but probably not in gtkrc
 * ogra just runs a dist.-upgrade and will debig if seeing the same
<Hobbsee> tjaalton: oh, i didn't think you'd uploaded it yet, with the upcomming alpha, and being uncertain as to whether it fixes the problem or not.  My mistake.
<ogra> but i use human-dark here by default
<asac> mdz: ah sorry. you already dealt with that
<ogra> *debug :)
<asac> (didnt see in my scrollback)
<tjaalton> Hobbsee: it fixes the problem for me, and a couple of other users
<Hobbsee> tjaalton: ah, right.
<norsetto> ogra: you should really do something about your fingertips ;-)
<Hobbsee> zomg, argh!  human-dark!
<ogra> norsetto, well, i'm better with cellwriter :)
 * Hobbsee curses custom-made white-on-white text.
<ogra> Hobbsee, i use it on ubuntu-mobile so i try to keep it on my lappie as well to see issues
 * jdong ponders the wording human-dark a bit....
<Hobbsee> I don't have a human-murrine after installing.  I wonder if that's intentional.
<Hobbsee> ogra: ahhh
<ogra> beyond that i really got used to the dark one, its slick
<Riddell> mvo: hmm, ~compiz/compiz/ubuntu/ ?  I'm not in that team
<jdong> how come nobody ever told me about the dark variant?
<ogra> jdong, it was the default for quite some time during intrepid
<jdong> ogra: guess I've been out of touch then :)
<pitti> sorry, my computer crashed over my lunch break; I probably lost some IRC pings
<jdong> silly migrating hardy settings to intrepid :)
<mvo> Riddell: ok, could you please push to oyur peronal repo and I will merge?
<dholbach> soren: what do I do about "serial0 console" in KVM again?
<mvo> Riddell: or if you don't have it in bzr, I will do a debdiff and merge myself
<mvo> Riddell: I can add you to the team too if you want
<soren> dholbach: -v
<dholbach> soren: I have a intrepid session open in virt-manager and hit some keys and now it just says "serial0 console"
<soren> dholbach: Oh. Heheh..
<soren> dholbach: ctrl-alt-1
<dholbach> soren: it's a black screen and whatever I press it won't let me go back to do my work again
<dholbach> it sucks!
<dholbach> thanks a lot soren :)
<soren> dholbach: :)
<mvo> Riddell: nevermind, I merged it manually
<pitti> mpt: I looked through the Tango icons; they do have an off bulb, but not a lighted bulb
<Riddell> mvo: ok, i put it in ~jr/compiz/ubuntu/
<pitti> mpt: the closest I can find is a sun and a moon, as I said, but in small sizes they look clumsy
<Riddell> mvo: including the change from the previous upload
<Hobbsee> dholbach: is it possible to get an address set for the ubuntu-core-dev team, or something?  I saw you did some team mangling, but it appears we're still getting mail from uninformed people assigning/subscribing us to bugs.
<dholbach> Hobbsee: I didn't do any team mangling
<mpt> pitti, ok, I'll sort this out with kwwii
<pitti> mpt: many thanks
<dholbach> Hobbsee: and I'm not a team admin, I think somebody on the TB might know better
<mvo> thanks Riddell
<Hobbsee> dholbach: ah.  Could you get it sorted out, or should I poke? :)
<dholbach> Hobbsee: it'd be great if you could ask what the status is there
 * ogra grumbles about the reboot notiifcation
<Hobbsee> dholbach: OK, will do - although i'm planning to head to bed.  Monday it is.
<Hobbsee> ogra: be greatful it's not like XP's...
<dholbach> Hobbsee: ROCK
<Hobbsee> dholbach: PAPER.
<infinity> Hobbsee: SCISSORS
<Hobbsee> infinity: *grin*.  I was wondering if someone would get the reference
<ogra_> mdz, g-s-d doesnt start at all for me ...
<ogra_> so my themeing is broken as well now
<mdz> ogra: it starts fine for me
<mdz> but the theming is not right
<ogra> it segfaults for me
<ogra> oh, no it doesn, but exists
<ogra> getsockname(12, {sa_family=AF_FILE, path="/tmp/orbit-ogra/linc-292e-0-4cae298d9ba0e"}, [44]) = 0
<ogra> writev(11, [{"GIOP\1\2\1\0\220\1\0\0", 12}, {"@J\303\277\0\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\315\340\270"..., 400}], 2) = 412
<ogra> clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb6e41748) = 10545
<ogra> exit_group(0)                           = ?
<ogra> Process 10542 detached
<ogra> aha!
<ogra> logout/in fixed it
<ogra> and i found that gnome-panel couldnt resolve my hostname on login
<ogra> but my dark theme is ok again
<ogra> theme switching works as well
<RicardoPerez> hi! anybody knows when will be the intrepid translations opened?
<cjwatson> they already are
<cjwatson> first language packs went into intrepid last week, and https://translations.launchpad.net/ubuntu/intrepid is open
<cjwatson> ArneGoetje: did you mail ubuntu-translators@ to let them know about this?
 * ogra tries of the theme survives a new boot
<cjwatson> I've changed the translation focus (https://translations.launchpad.net/ubuntu) to intrepid now
<RicardoPerez> cjwatson: great, thanks a lot for the response :)
<ogra> all fine even on a second boot
<ogra> though i had no usplash on shutdwom
<slangasek> mpt: because drivers are not something that one turns on
<mpt> slangasek, that's begging the question a little, isn't it? :-) You do *something* to them to make Ubuntu think about using them when it wouldn't have before.
<pitti> argh, again
<mpt> "Activate" might be better, though I'm a little concerned that it's too close to "Use", when it doesn't necessarily mean that Ubuntu will end up using the driver at all.
<mpt> Then again, maybe "Turn On" has the same problem.
<pitti> bryce, tjaalton: since today, my computer hard-locks at some point of idling, I strongly assume it happens when X tries to switch off the monitor for screensaver
<slangasek> mpt: well, the English center of my brain goes "hnyaaaaah" at the use of the phrase.  I can't offer you a more substantial argument. :)
<persia> How about "Enable"/"Disable" ?
<Koon> slangasek: about likewise-open, dendrobates told me you were working on a more-compatible PAM fix -- do you still want me to file a FFe for the 4.1.2982 update proposed on bug #262264 or would that be orthogonal to your efforts ?
<ubottu> Launchpad bug 262264 in likewise-open "Fails to join a domain: Unknown pam configuration" [Critical,In progress] https://launchpad.net/bugs/262264
<slangasek> persia: that's what was there before, and has been rejected :)
<persia> But there aren't any other good words that are both accurate and short :(
<mpt> persia, "disable" is ok, but "enable" tends to be unhelpfully vague.
<slangasek> I think 'Activate' is closer
<mpt> ok, fair enough
<mpt> "Activate" it shall be
<persia> But what if the user "Activates" it, and it doesn't actually get loaded or used?
<slangasek> Koon: ah, hold off on filing an FFe for the moment, please
<slangasek> persia: how is that different than enabling it and having it not be loaded or used?
<mpt> persia, then the status text will say "This driver is activated but not being used."
<Koon> slangasek: ok
<persia> slangasek: Well, when something is enabled, it might be active and it might not be: it's correctly vague.  When something is activated, yet inactive, it seems wrong.
<persia> mpt: How can something be activated but not active?
<slangasek> to me, activated means that it's in a state that's ready for use, not that it's in use
<mathiaz> slangasek: I've reworked the landscape-client package, splitting it in two packages - here is the changelog http://paste.ubuntu.com/46261/
<ogra> pitti, do you have an intel card and use compiz ?
<mathiaz> slangasek: do I need to request a FFexception ?
<tseliot> persia: enabled (e.g. in the xorg.conf) but not in use i.e. the module is not loaded (e.g. if blacklisted, etc.)
<slangasek> mathiaz: hrm, I thought splitting the package had been rejected as a solution
<ogra> pitti, there is a bug in compiz apparently that causes such things, i switched to metacity and the prob went away, Ng had a similar issue
<mathiaz> slangasek: hm - which solution are you refering to then ?
<pitti> ogra: yes
<Ng> ogra: pitti: see https://bugs.launchpad.net/bugs/262605
<pitti> ogra: ah, indeed
<ubottu> Launchpad bug 262605 in mesa "[intrepid] X locks up or crashes when screensaver activates" [High,Confirmed]
<persia> tseliot: Precisely.
<pitti> until yesterday I had metacity
<pitti> since gnome-session didn't get along with the compiz startup detection magic
<pitti> Ng, ogra: thanks!
<ogra> :)
<Ng> I believe tjaalton tracked it down to some mesa vblank thing
<pitti> bryce, tjaalton: this seems to be it
<slangasek> mathiaz: the solution that was being discussed the other day was to adjust smartpm (as depended on by landscape-client) so that it's only available under /usr/share/landscape/, and proceeding with an MIR, I thought
<slangasek> mathiaz: or is the smartpm dep itself an issue for CD size?
<mathiaz> slangasek: the pkg split for smartpm has already happened
<mathiaz> slangasek: this is another pkg split for the landscape-client.
<cjwatson> slangasek: this is arising from landscape-client having had a stub in desktop for a long time
<pitti> slangasek, mathiaz: and to keep the landscape-client stub on new desktop installs and upgrades, and only ship the sysinfo part on servers (AFAIUI)
<mathiaz> slangasek: ^^ - correct
<cjwatson> slangasek: we were just talking about this on the phone, and agreed to exchange mail about exactly what all the desired upgrade behaviours were before committing to a split
<cjwatson> AIUI
<cjwatson> smartpm is a separate deal but also required
<cjwatson> anyway, we have a release meeting now ...
<tjaalton> pitti: try upgrading mesa and tell me if it still hangs
<pitti> tjaalton: oh, very fresh mesa? I dist-upgraded like 3 hours ago
<tjaalton> pitti: 7.1-1ubuntu2
<pitti> tjaalton: and restarted my session today due to the kernel update, which caused compiz to run now; that's what triggered it, I assume
<tjaalton> pitti: yes
<pitti> tjaalton: awesome, will try (still have ubuntu1)
<tjaalton> pitti: the real fix will land in the kernel drm once upstream figures out what it is :)
<pitti> tjaalton: ah, the changelog has an ill-formatted bug, thus the bug is still oopen
<tjaalton> pitti: I left it on purpose, since someone said that the drirc workaround didn't work
<pitti> tjaalton: ah, ok; I'll restart X and my session after the meeting and try, and comment on the bug
<pitti> to collect some testing data
<tjaalton> pitti: great, thanks
<mpt> kwwii, e-mailed
<slangasek> persia: are you available to stand in for mobile on the release meeting?
<persia> slangasek: Sure, although I've not prepared things.  Let me try to get someone else (or I'll stand in in a few minutes)
<cjwatson> sbeattie: (from #ubuntu-meeting) it's more or less http://people.ubuntu.com/~cjwatson/bzr/britney/cdimage/ with configuration tweaks)
<slangasek> persia: well, see mail from lool that he can't make it and he doesn't think davidm is available
<persia> Heh.  OK :)
<sbeattie> cjwatson: thanks!
<kwwii> mpt: got it, I'll see what I can come up with and we can discuss it more per email
<ogra> kwwii, did you notice mdz's theme probs (apparently showing up also on the liveCD)
<tkamppeter> pitti, I have reported some bugs on Jockey
<pitti> tkamppeter: I saw them, thank you
<pitti> tkamppeter: something to play with on my long 11 hour flight to Portland next Monday :)
<tkamppeter> pitti, WDYT when will you have the D-Bus API and the asynchronous D-Bus call bug ready so that I can make the patch for s-c-p and hal-cups-utils to ask Jockey for drivers?
<pitti> tkamppeter: you mean the bugs fixed? I hope I can do it next week, doesn't sound too hard; the general functionality is there, after all
<tkamppeter> pitti, I would like to do the s-c-p and hal-cups-utils part then and post an FFe.
<pitti> tkamppeter: nice; in either case it could already go upstream then
<pitti> tkamppeter: since I'll continue to develop jockey upstream independently of the intrepid release, too
<tkamppeter> pitti, it will naturally go also upstream into s-c-p.
<tkamppeter> pitti, it cannot even break Fedora when they do not ship Jockey, as if the D-Bus call does not succeed to contact Jockey I will simply let the error get ignored.
<cjwatson> zul: updated tasksel on its way
<zul> cjwatson: thanks
<calc> yea this storm is looking nasty, i think i'm going to go to dallas after all, it circled back to try to hit us :\
<calc> and i only have about 6-8hr left to get out before the wind starts picking up a lot
<davidm> come on up
<calc> the current model moved it back directly on top of our place (or within 1/2 mile anyway)
<calc> last night it had moved all the way east of houston, so i was hoping it would be safe enough, heh
<davidm> calc, will you be bringing your sister too?  We have room
<calc> i can see if she wants to come along
<liw> calc, good luck
<tedg> calc: Oh, still choosing him over me -- I see how it is ;)  Drive safe!
<calc> ok well can't reach her right now so i'll ask her in person
<calc> tedg: its a matter of driving time, thank you very much for the offer though :)
 * calc hugs tedg 
<tedg> I understand, I was just harassing you.  I do think you should stop tying and go though :)
<tedg> typing.
<calc> yep, i am breaking the stuff down now
<calc> wind speed here will be TS level by 4pm
<tedg> Nice, current models don't have us getting over 30 mph.  They were predicting 50 mph last nigh.
<tedg> night.
<calc> hmm i'm surprised it went down for you overnight since the hurricane strenghtened since then
<tedg> It's going further east for us.  More missing us than less strength.
<sbeattie> calc: good luck!
 * calc shutting down now, should be leaving in 30m or so
<pitti> dendrobates: FYI, smart promoted, bug 260443 commented
<ubottu> Launchpad bug 260443 in update-motd "main inclusion request: update-motd" [Medium,Incomplete] https://launchpad.net/bugs/260443
<dendrobates> pitti: could you please look at the update-motd mir as well?
<pitti> dendrobates: just did, see the bug :)
<cjwatson> pitti: is xinput OK to promote, do you think? xorg depends on it now
<cjwatson> it's pretty trivial
<dendrobates> pitti: you are great, thanks.
<pitti> cjwatson: oh, sure; thought it was already
<cjwatson> I'll do that
<pitti> dendrobates: don't thank me until you see my ramblings about it :)
<cjwatson> heno: ^- xinput should fix xorg installability I think
<heno> cjwatson: great, thanks
<radix> pitti: heyo, there seems to have been a problem uploading a change to smart that seems to have happened just as it was being added to main
<radix> we got some strange errors
<pitti> radix: ah, "failed to upload"?
<radix> pitti: sec, I'll find an URL for you
<radix> I have email logs from the buildd talking about it
<radix> the state is "Failed to upload"
<pitti> radix: yes, that happens if you promote a source while binaries are currently being built; soyuz quirk
<radix> aha
<pitti> radix: right, known issue
<radix> whew, I'm glad you know about it
<pitti> radix: the easiest solution is to just have them be built again in about... 1:30 hours
<radix> pitti: do I have to do something for that?
<radix> or is it automatic?
<pitti> radix: just ask any core developer to do so
<pitti> you can't do it yourself, I think
<radix> right ,I'm not even a MOTU yet :)
<pitti> radix: I think I'll still be online at that time, so shold I forget, just prod me
<heno> cjwatson: any chance we could respin a few images with these fixes so we can test our testing?
<cjwatson> radix: why the Pre-Depends?
<cjwatson> heno: sure, if I'm still around when it's time
<heno> great, thanks!
<hunger> Is it possible to turn of stack smashing protection when building a deb for intrepid?
<radix> cjwatson: ok, so smartpm-core installs a symlink /usr/bin/smart -> /usr/share/smart/smart; python-smartpm installs /usr/share/smart/smart
<radix> cjwatson: smartpm-core invokes 'smart' in its own postinst
<cjwatson> hunger: -fno-stack-protector
<cjwatson> radix: that only requires Depends
<dendrobates> pitti: those are completely reasonable and helpful comments on update-motd.
<radix> cjwatson: does a Depend guarantee that the depended-upon package will be unpacked before the depending package?
<cjwatson> radix: you would only need Pre-Depends if you were invoking smart in smartpm-core's preinst
<cjwatson> radix: yes, absolutely!
<radix> humm, we actually found an error
<cjwatson> Pre-Depends is usually not the right fix, and policy explicitly says that you must discuss new Pre-Depends
<cjwatson> precisely because they're usually the wrong fix and complicate upgrades
<radix> ah. woops. :-(
<cjwatson> what was the error?
<pitti> radix: so, even easier then -- just get a fixed package uploaded, it should build fine
<mathiaz> radix: are you refering to the python-gobject bug ?
<mathiaz> cjwatson: https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/268838
<ubottu> Launchpad bug 268838 in landscape-client "registrating clients doesn't work when installing the package" [High,New]
<radix> mathiaz: no, this is about the smartpm-core/python-smartpm split
<radix> sec
<mathiaz> cjwatson: I've used a Pre-Depends to fix the bug above ^ ? Is this correct ?
<cjwatson> no, it is not
<mathiaz> cjwatson: what would be the correct fix ?
<cjwatson> I'm not sure, but it ain't pre-dep
<cjwatson> seems like bug 121341
<ubottu> Launchpad bug 121341 in python-support "python modules need to work during dist-upgrades" [High,Confirmed] https://launchpad.net/bugs/121341
<cjwatson> in any case having smartpm-core pre-depend on python-smartpm is a really nonintuitive approach to fixing a bug that's to do with the interaction between landscape-client and python-gobject!
<pitti> slangasek, tjaalton: can I have some 15 mins to catch up with some stuff and take a quick break?
<tjaalton> pitti: sure
<cjwatson> you use python-central for python-smartpm so shouldn't run into this problem there
<mathiaz> cjwatson: hm - I think I've stepped in the middle of a conversation
<mathiaz> cjwatson: I think we're discussing two issues here.
<mathiaz> cjwatson: but you're right that the issue I ran into (landscape-client) is related to bug 121341
<ubottu> Launchpad bug 121341 in python-support "python modules need to work during dist-upgrades" [High,Confirmed] https://launchpad.net/bugs/121341
<persia> mathiaz: The quick & dirty solution to your issue is for python-gobject to use python-central
<cjwatson> agreed, but we probably don't have the effort to do that across the board
<radix> cjwatson: the smartpm-core -> python-smartpm is unrelated to the landscape-core -> gobject
<radix> pre-depends
<radix> however, mathiaz and I are in the same office and may have created a shared misunderstanding of ideal solutions to these kinds of problems :)
<cjwatson> the reason why Pre-Depends is generally undesirable is that it forces dpkg not to be able to use the usual approach of "unpack everything, configure everything"
<cjwatson> but instead partitions the package set being upgraded into multiple unpack/configure chunks
<cjwatson> sometimes it is necessary, but should be kept to a minimum and other approaches found where possible
<cjwatson> loops involving Pre-Depends are much harder to solve, and sometimes impossible
<niemeyer> cjwatson: I'm investigating the issue here with radix and andreas
<cjwatson> Pre-Depends/Pre-Depends loops are irresolvable, and Pre-Depends/Conflicts is a pain
<cjwatson> niemeyer: right, I'm just giving advice on the packaging metadata
<niemeyer> cjwatson: What should be the correct order if there are two packages depending on each other?
<cjwatson> niemeyer: undefined
<niemeyer> cjwatson: Not saying this is the case, just trying to figure it out
<cjwatson> niemeyer: in practice dpkg configures the ones without postinsts first, if any
<cjwatson> packages do sometimes do that, and it's OK as long as it doesn't matter at maintainer-script time
<niemeyer> cjwatson: Ok, so the Depends unpack ordering is advisory only?
<cjwatson> err, you misunderstand
<cjwatson> Depends enforces configure ordering
<niemeyer> cjwatson: So what's the ordering when there's a loop?
<cjwatson> you don't care about unpack unless you have preinsts
<cjwatson> like I say: undefined (unless one package is missing a postinst)
<niemeyer> cjwatson: Ok, I guess I see
<slangasek> cjwatson: Depend doesn't guarantee unpack ordering, no...
<cjwatson> and that's an implementation detail of dpkg rather than a policy definition
<cjwatson> A Depends: B guarantees B unpacked before A configured
<infinity> cjwatson: It's totally defined! *cough*
<cjwatson> infinity: undefined by policy :)
<infinity> cjwatson: Though I don't recall if it's alphabetical, or order passed to dpkg on the command line...
<infinity> (often the same thing, when debootstrap is involved)
<niemeyer> cjwatson: Cool, so I believe it's a bug in the ordering of Smart then
<cjwatson> niemeyer: I'm curious why you think you're relying on unpack ordering
<cjwatson> are you *sure* it's unpack ordering? python packages often do lots of work at the configure stage
<niemeyer> cjwatson: For Smart that ordering is advisory but breakable depending on other relations
<pitti> mvo: as for your current compiz 1:0.7.7+git20080807-0ubuntu7 upload, it already does start automatically again?
<cjwatson> niemeyer: can you give me an example?
<niemeyer> cjwatson: I'm not entirely sure yet, no.. I'll join radix and andreas on debugging now
<mathiaz> persia: right - I'll ask lool or seb128 about it
<mvo> pitti: there is a gnome-control-center upload needed for this. I'm doing that now
<niemeyer> cjwatson: I can't yet, but will have a better idea (and perhaps a fix) later today
<slangasek> unpack ordering should really never matter except in cases where you do have a preinst, AFAICS
<infinity> Even then, it almost never matters, unless your preinst does some pretty vile stuff.
<slangasek> s/pretty vile //
<cjwatson> in the absence of loops: A Depends: B guarantees A configured after B configured. A Pre-Depends: B guarantees A unpacked after B configured. A Conflicts: B guarantees B removed (not unpacked) when A unpacked. A Breaks: B guarantees B not configured when A unpacked.
<mvo> pitti: gnome-c-c uploaded, should be good now (compiz should start again)
<infinity> slangasek: Well, most of my preinsts only depend on Essential.
<slangasek> infinity: debconf preinst ftw :)
<mvo> pitti: actually, the compiz change is probably enough to make it auto-start, but it can't be turned off anymore :) that is the g-c-c upload for
<infinity> slangasek: debconf hasn't been around for a decade, I refuse to acknowlege its existence.
 * slangasek blinks at bug #268364
<ubottu> Launchpad bug 268364 in ucf "Bug in /usr/bin/ucf when upgrading Hardy" [Undecided,New] https://launchpad.net/bugs/268364
<pitti> asac: bah, with the new ffox I constantly get the EULA displayed on startup
<pitti> mvo: hm, I thought the problem was in gnome-session; I dist-upgraded yesterday, and this morning I got compiz automatically
<niemeyer> cjwatson: Thanks for the summary, I'll ensure this is the case
<cjwatson> niemeyer: seriously though, if somebody actually tells me what the problem is, I may be able to help rather than just spewing rules :)
<niemeyer> cjwatson: That's the output they radix and ahasenack got: https://pastebin.canonical.com/9112/
<niemeyer> s/they/that/
<ahasenack> cjwatson: the actual error is at line 115 of that pastebin
<cjwatson> niemeyer: oh, wow, definitely a Smart bug. It should pass *everything* to dpkg --unpack in one go unless there are packages there that declare Pre-Depends: on something that isn't configured yet.
<niemeyer> cjwatson: Cool.  I'm surprised that this didn't break up before.
<cjwatson> so am I
<niemeyer> cjwatson: Luckily, the ordering logic in Smart is done in about 50 lines with a high-level description
<cjwatson> however, you need a correct high-level description before this is an advantage :-)
<niemeyer> cjwatson: I'll just check which constraint from your description above is missing, and then post the fix
<niemeyer> cjwatson: That's what I was trying to say, but you beat me to it
<cjwatson> heh
<pitti> tjaalton: screensaver hasn't blown up yet, so this looks good
<niemeyer> cjwatson: I've tried to follow the policy document entirely, but I probably misunderstood it
<tjaalton> pitti: good :)
<cjwatson> niemeyer: you may have misread "installed" as "unpacked"
<cjwatson> hmm, no
<pitti> tjaalton: bug commented
<cjwatson> anything in policy that uses the word "installed" requires careful reading, but it does actually often mean "unpacked"
<pitti> tseliot: I'll disconnect my laptop from the dock and reboot, to do the test Bryce asked me to do; back in 5
<cjwatson> should probably get that fixed ...
<ykphuah> asac: are you around?
<niemeyer> cjwatson: I think we found the issue
<niemeyer> cjwatson: The new python-smartpm package has a Conflicts relation with the old smartpm-core package
<cjwatson> ah, heh, that's a bug in the package
<cjwatson> I actually thought about mentioning that when I saw it in NEW
<cjwatson> silly me for not doing so
<cjwatson> Replaces is quite sufficient
<niemeyer> cjwatson: Doesn't that mean that both might be installed at the same time?
<niemeyer> cjwatson: Should we use Breaks perhaps?
<cjwatson> Replaces is good enough.
<cjwatson> it's just a file move
<niemeyer> cjwatson: Ok, cool
<cjwatson> I think this is still a smart bug, mind
<niemeyer> cjwatson: Right, that's what I was going to ask
<niemeyer> cjwatson: What's the specification about this situation?
<cjwatson> let me just construct a test case and see what apt+dpkg does: I suspect it's: unpack smartpm-core, unpack python-smartpm, configure python-smartpm, configure smartpm-core
<cjwatson> I think that's the correct resolution
<niemeyer> cjwatson: Due to the Conflicts relation, Smart has put the upgrade before the actual installation of the secondary package
<cjwatson> right, but in the process it broke Depends
<niemeyer> cjwatson: Could be.. it depends mostly on what's the expected outcome
<cjwatson> if it had been Pre-Depends, it ought to have refused entirely
<cjwatson> but Depends/Conflicts should be resolvable while satisfying both constraints
<niemeyer> cjwatson: Like, is it ok to have the conflicting package present during unpack?
<cjwatson> no, but in my proposed resolution you don't
<niemeyer> cjwatson: I guess you do
<cjwatson> no. the new smartpm-core is unpacked first and that's the only thing being conflicted on.
<niemeyer> cjwatson: Or maybe I misunderstood it
<pitti> mvo: hm, compiz seems to have forgotten to not start if it is already running in another X? I just get a blank screen now in the guest session
<niemeyer> cjwatson: Ah, gotcha
<niemeyer> cjwatson: I'll review the ordering for this case then
<mvo> pitti: and no fallback to metactiy either?
<niemeyer> cjwatson: Thanks a lot for these details
<mvo> pitti: compiz works only on the first head that is a know issue
<pitti> tjaalton: I commented on bug 267628
<ubottu> Launchpad bug 267628 in f-spot "f-spot.exe crashed with SIGSEGV in _dl_close() (dup-of: 189335)" [Undecided,New] https://launchpad.net/bugs/267628
<ubottu> Launchpad bug 189335 in f-spot "f-spot.exe crashed with SIGSEGV" [Medium,Confirmed] https://launchpad.net/bugs/189335
<niemeyer> We'll have lunch and fix it once we're back.
<mvo> pitti: but it should fallback to metactiy
<pitti> mvo: well, maybe it does fallback, but since it at first tries to start as compiz, I get the white screen and can't see anything
<mvo> pitti: can you give me the output of ~/.xsession-errors in the guest session?
<pitti> mvo: while it failed? sure, let me try
<pitti> mvo: http://people.ubuntu.com/~pitti/tmp/xsession-errors
<pitti> mvo: this is after a full startup of guest, judging by the changing mouse cursor (which is the only thing I see)
<mvo> pitti: that is on your intel i945 or 965?
<liw> mvo, any progress on system-cleaner? (still not pushing :)
<pitti> mvo: 945GM/GMS, 943/940GML Express Integrated Graphics Controller
<cjwatson> mvo: he may not be pushing, but I am. :)
<mvo> *cough*
<mvo> ok
<cjwatson> (feature goal, already late)
<mvo> I have a look in some minutes
<mvo> pitti: thanks, I suspect its a x bug that it pretends to be able to have a second dri capable head. what is the output of glxinfo in the guest
<asac> ykphuah: more or less
<pitti> mvo: I guess that I can do that with metacity, too?
<mvo> pitti: yes that should work
 * pitti h4x0rs /usr/bin/compiz again
<cjwatson> mvo: thanks
<mvo> np
<pitti> mvo: http://people.ubuntu.com/~pitti/tmp/glxinfo.primarysession.txt and http://people.ubuntu.com/~pitti/tmp/glxinfo.guest-session.txt
<mvo> pitti: hm, that looks like X pretends to be able to deal with that, I ask on #ubuntu-x
<pitti> mvo: shall I file a bug about this? with those two files attached?
<mvo> pitti: yes, I think that is a good idea, we can then reassign between x and compiz if needed, but for now I think its X :)
 * mvo wonders if it is just him or if the name "easystroke" sounds slightly odd
<cjwatson> it sounds like it would be best-placed in Soho
<mvo> pitti: it looks like tjaalton found the answer already I will add a workaround to the compiz wrapper
<pitti> mvo: bug 269509
<ubottu> Launchpad bug 269509 in xserver-xorg-video-intel "white screen on second session with compiz: pretends to have a second DRI capable head where it doesn't" [Undecided,New] https://launchpad.net/bugs/269509
<pitti> tjaalton: you rock, fixing bugs faster than I can even report them :)
<tjaalton> pitti: heh :)
 * mvo hugs tjaalton
 * tjaalton hugs mvo
<pitti> mvo, tjaalton: so is it actually a bug in the driver, and mvo's change in compiz is just a workaround? or shall we assing above bug to compiz straight away?
<mvo> pitti: I would maintain its a driver bug, but it seems to be easy enough in compiz to work around it
<mvo> pitti: so a x and a compiz task is probably the right answer
<mvo> I would still be interessted in the answer from X upstream if the glxinfo output shoudl be "DRI: no" or not
<pitti> mvo: right, agreed
<pitti> doko: ppl binary-NEWed (just libppl-doc, rest was already from libppl), and libppl removed
<doko> pitti: binary libppl-c-dev removed as well? and the ppl blacklist for syncs removed?
<rom1v> hi
<tjaalton> pitti: it's a driver bug, but it's also well known upstream. Needs all the new stuff that's been on the works (and that might not be enough.. not sure)
<pitti> doko: yes and yes
<doko> thanks
<rom1v> is there a way to disable the history (logfile) which logs every task we do on the computer : ~/.recently-used and ~/.recently-used.xbel
<JontheEchidna> pitti: about bug 263017, should I just attach a debdiff to the bug or would a jockey-hacker have to make the changes in bzr?
<ubottu> Launchpad bug 263017 in jockey "jockey-kde crashed with ImportError in <module>()" [High,Triaged] https://launchpad.net/bugs/263017
<pitti> JontheEchidna: debdiffs are fine; you can of course also create your own branch, fix it there, and propose for merging, but that's quite some effort for a two-line patch :)
<pitti> JontheEchidna: please assign the bug to me if you attach a patch; thanks!
<JontheEchidna> pitti: ok, I'll attach it in a second
<pitti> JontheEchidna: ah, seems easy enough; no debdiff required
<JontheEchidna> ok
<pitti> JontheEchidna: if you have fun doing them, go ahead, but "missing dependency" is trivial enough
<JontheEchidna> see, that's why I asked ;-)
<pitti> JontheEchidna: fixed in bzr
<JontheEchidna> cool
<pitti> JontheEchidna: I'll also adapt the dependency description upstream in README.txt
<mathiaz> seb128: lool: I'm currently blocked by bug 121341. What do you think about moving python-gobject to use python-central rather then python-support ?
<ubottu> Launchpad bug 121341 in python-support "python modules need to work during dist-upgrades" [High,Confirmed] https://launchpad.net/bugs/121341
<mvo> liw: do you have a packaging branch for system-cleaner?
<pitti> mathiaz, seb128: could then also use DH_PYCENTRAL=nomove if it is enough to work with python 2.5 (and not with 2.4)
<liw> mvo, bzr+ssh://bazaar.launchpad.net/%7Esystemcleaner-hackers/systemcleaner/trunk.deb-packaging/
<pitti> but for such a central package this might not be an option
<pitti> so long, good bye everyone! I'm off next week for the Linux Plumbers Conf
<slangasek> mathiaz: ping
<mathiaz> slangasek: yop
<slangasek> mathiaz: are you set up to be able to test likewise-open?
<mathiaz> slangasek: not really :/
<slangasek> I'm not, someone's changed around the VMware guests again
 * slangasek mumbles 
<mathiaz> slangasek: dendrobates may be
<slangasek> ok, I can't really check whether likewise-open dtrt with PAM if I can't do a test join
<slangasek> nah, he pointed me at you ;)
<slangasek> well, for the moment I'll resort to old-fashioned code inspection then
<geser> when a package gets added to P-a-S are the debs for the other archs automatically removed on the next upload?
<slangasek> geser: no
<dendrobates> slangasek: coffedude is on and off line today, due to a family issue, but you might email him the diff.
<slangasek> geser: only the buildds look at P-a-s, package removals from the archive have to be done by an archive admin
<slangasek> dendrobates: it's his diff that I'm trying to vet :)
<slangasek> I haven't even gotten that far yet
<geser> slangasek: so a removal request should be filed for the now unsupported archs?
<slangasek> geser: yes, please
<cjwatson> niemeyer: I've verified that the behaviour of 'dpkg -i' in this case (when given both packages on the command line at once) is as I described (unpack smartpm-core, unpack python-smartpm, configure python-smartpm, configure smartpm-core), so that should be considered canonical
<cjwatson> niemeyer: http://people.ubuntu.com/~cjwatson/smartbug.tar.gz contains test cases; run 'make test'
<niemeyer> cjwatson: Wow, that's awesome.  Thanks a lot.
<geser> kees: re bug 262843: have you tried already 2.6.27-3.4? I'm using it now (for some hours) and didn't see this problem yet with this version
<ubottu> Launchpad bug 262843 in linux "[2.6.27-2.3] (sometimes temporary ?!) system deadlock with io_schedule " [High,Triaged] https://launchpad.net/bugs/262843
<kees> geser: yeah, I pulled it down last night, but haven't rebooted yet (I'm on 1.2 at the moment)
<bigBear> why did they choose 2.6.27?
<geser> kees: looks like -3.4 has still the problem :(
<jlc> Is there a list of boot options some were for the install cd?  Alpha 5 installer crashes on my system, I'll need to reboot and capture the error again, just wondering what options there are for kernel boot
<Treenaks> jlc: have you tried the 'photo camera' option? :P
<jlc> :)
<jlc> i come from a rh/fedora side, and have used ubuntu off/on but dont know all the options yet
<kees> geser: feh.  that sucks
<jlc> is #ubuntu-testing channel more for users using testing releases?
<thom> or #ubuntu+1
<jlc> cool, thanks
<jlc> I'll just lurk here
<lfaraone|ffm> Hey, how do I request that my wikiusername be changed?
<cjwatson> it's just your Launchpad username now isn't it?
<lfaraone|ffm> cjwatson: I changed my lp name, and that didn't cross over to w.u.o
<cjwatson> lfaraone|ffm: hmm, I don't know; try #canonical-sysadmin
<psufan> which one of you canucking geniuses decided it would be cut to turn on super anal justify mode in 6.06 lts
<psufan> nano
<psufan> so that every goddamn time I try to move a line it puts them all together
<psufan> what trhe fuck
<psufan> this had to have been someone's idea of a joke
<norsetto> yawn
<psufan> 8.x is way better but 6.06 should have been named
<psufan> CRACKY CRACKMONKEY
<ScottK-laptop> !ops
<ubottu> Help! bhale, infinity, Hobbsee, jdub, thom, fooishbar, fabbione, mdz, lamont, or Keybuk
<ScottK-laptop> PriceChild: Thanks.
<pwnguin> anyone know how big ubuntu-minimal is today?
<bcurtiswx> My question: bug 269226 has been confirmed by me, but I've found its not a firefox issue but a font issue.  Nobody in the bugs channel knows which package to assign, any advice?
<ubottu> Launchpad bug 269226 in firefox-3.0 "Web page font rendering issues (palatino font)" [Undecided,Confirmed] https://launchpad.net/bugs/269226
<toresbe> I'm still not getting any sensible data off the current loop console line on the PDP-11. I think it might be a wiring issue...
<toresbe> oops, ECHAN
<_MMA_> bcurtiswx: It's late in alot of the world, and a Friday. It might be slow to get an answer.
<bcurtiswx> thankfully its not that important of a bug
<bcurtiswx> :-)
#ubuntu-devel 2008-09-13
<hardwire> yo.
<calc> hello
<calc> i am now safe at davidm's house :)
<wgrant> calc: How're things over there?
<calc> wgrant: much better up here than where i live ;)
<calc> its already up to 27mph wind at my house
<calc> projected 80mph+
<calc> no trees to buffer it where i live either
<calc> its clear cut in the neighborhood and backs up to a large AM radio tower array
<wgrant> Ah.
<calc> oh the plus side that means no trees to fall on the house
 * flyback bbl, mabye
<NCommander> hola wgrant
<wgrant> Hi NCommander.
<NCommander> how goes it wgrant?
<wgrant> NCommander: Busy as usual. :(
<NCommander> wgrant: sounds like fun. I'm trying to kill the backports queue again
<ScottK-laptop> Lovely.
<ScottK-laptop> Clearly you don't want me uploading Ada SRU's then.
<NCommander> ScottK-laptop: Right now, I'm just focusing on fixing Subversion :-)
<ScottK-laptop> Cool.
<ScottK-laptop> Is this the libneon thing?
<NCommander> ScottK-laptop: yeah
<NCommander> I'm rolling a debdiff to switch the build dependency, and then I'm going to shove it in the PPA
<NCommander> We should look at making the same change in intrepid, since the bug exists there too
<persia> Intrepid likely ought be fixed *before* backports.
<NCommander> persia: well, I'm not sure if it should be fixed
<NCommander> The Debian maintainer made a change from openssl->gnutls
<NCommander> (hardy used libneon backed on openssl)
<ScottK-laptop> NCommander: You're going to have to explain it then, because as I read what was said to be the relevant Debian bug it didn't seem to apply to the versions we had.
<NCommander> There is a bug in gnutls that currently breaks SVN when you try and use SSL certificates
<NCommander> Oh, good
<NCommander> I didn't realize we already patched around that bug
<ScottK-laptop> No, I think our versions are before it was introduced.
<ScottK-laptop> OTOH, someone was saying they had the problem, so dunno.
<NCommander> Three people acked the bug
<ScottK-laptop> I may just be incorrectly versioned in BTS.
<ScottK-laptop> I/It
<NCommander> so its a confirmed issue in the hardy backport
<ScottK-laptop> OK.  Can you reproduce it?
<NCommander> No, since I don't have an SSL certificate
<NCommander> ^system setup
<NCommander> I'm rolling a backport with the proposed fixed, and then uploading to the PPA, and asking people to test that
<ScottK-laptop> OK.
<NCommander> I figure that's the best way to test it
<ScottK-laptop> The best way is for the developer to reproduce the problem and see it go away, but absent that and if you're willing to take on the karmic load of enticing people to install packages from unsigned repos, yes.
<ScottK-laptop> That's the metaphysical karma, not the LP kind.
<NCommander> ScottK-laptop: I'm just following the instructions from the backports wiki page
<ScottK-laptop> Ah.  You are just following orders.
<NCommander> Well, there is a work around (an ugly one) for the current issue, Read the current bug?
<ScottK-laptop> Not today.
<ScottK-laptop> What's the bug?
<NCommander> https://bugs.edge.launchpad.net/hardy-backports/+bug/265065
<ubottu> Launchpad bug 265065 in subversion "Subversion 1.5.1 does not work with SSL certificates" [Undecided,New]
 * ScottK-laptop looks
<ScottK-laptop> You can do the .p12 -> .pfx thing with openssl too can't you?
 * ScottK-laptop looks into that so we can at least have a work around that doesn't require a Windows box.
<NCommander> ScottK-laptop: not a clue
<ScottK-laptop> The answer will make your eyes bleed.  I think it's a bogus clue.
<ScottK-laptop> symlinking one lib for the other is ugly, but I'm not suprised it works.
<NCommander> ScottK: its proof enough for me that switching the build-dep will likely fix the bug
<wgrant> Is switching the build-dep legal?
<persia> It's considered a code-changing backport.  I thought there was a requirement that any such bugs must first be fixed in intrepid (as with SRUs).
<wgrant> Is Subversion appropriately licensed to link to OpenSSL?
<NCommander> wgrant: its not subversion that links to openssl
<NCommander> wgrant: its one of its build-deps that is
<NCommander> libneon can be linked to openssl or gnutls
<NCommander> In intrepid, via a sync, SVN was switched to link against libneon gnutls
<persia> Oughtn't we just backport that then?
<NCommander> It appears that intrepid is currently unaffected
<NCommander> libneon?
<NCommander> It has a good number of rdepends :-/
<ScottK-laptop> persia: It's not quite the same thing.
<ScottK-laptop> Often we have to do things in backports that aren't directly relevant to the development release.
<persia> ScottK-laptop: OK.  As with all things backports, I'll defer to you.  I just don't like fixing bugs in backports if the bugs exist in the main trunk, and generally think it's better to do a fresh backport than fiddle with an outdated one.
<ScottK-laptop> The most awful thing I've had to do (to make a backport work on Dapper) was to take the Feisty version of a package, swap in the Dapper versions of debian/rules, and grab one file out of the upstream source from Hardy and slam it all together.
<ScottK-laptop> It worked.
<ion_> Wtf? Why does Firefox show an EULA?
<NCommander> ScottK-laptop: what package?
<wgrant> ion_: I thought I saw a page load up this morning with "mozeula" on the end, but I closed it too quickly to notice.
<wgrant> ion_: So I wasn't imagining things?
<ScottK-laptop> NCommander: I think it was avscan.
<NCommander> ow :-P
<ScottK-laptop> I had to do something ugly to python-clamav in Dapper too.
<wgrant> ion_: I THINK I JUST DIED OF A CAPITAL LETTER OVERLOAD.
<wgrant> We must be able to disable that by default.
<wgrant> It also seems to be wrong, as I don't think we have any blobs (except for the logo) in the Ubuntu version.
<ScottK-laptop> persia: svn isn't GPL, so openssl linking isn't an issue.
<persia> wgrant: ^
<wgrant> ScottK-laptop: Ah, convenient.
<NCommander> ScottK-laptop: it won't be so bad if clamav didn't believe in breaking the API/ABI every release without bumping the soname
<wgrant> NCommander: At least they have releases.
<NCommander> wgrant: your refering to ffmpeg I assume
<ScottK-laptop> NCommander: They actually bump the soname now, but the problem is they don't provide any transition.
<ScottK-laptop> We just changed over to libclamav5, so they are bumping it.
<wgrant> NCommander: I am.
<ScottK-laptop> It was a good update too, only 1/3 of the rdpends FTBFS this time.
<ScottK-laptop> Usually it's 100%
<NCommander> ScottK-laptop: That PHP one was evil
<wgrant> PHP is evil.
<ScottK-laptop> That was mostly libtool's fault though.
<NCommander> I don't think my NMU got uploaded yet
<ScottK-laptop> wgrant: Right, so what happens with you build a php library with libtool to integrate with libclamav.  It's like a black hole of evil.
<ScottK-laptop> NCommander: Nope.
 * NCommander just happens to be immune to backports
<NCommander> er blackholes
<wgrant> ScottK-laptop: Something bad, I suspect.
<NCommander> wgrant: your eyes would bleed if you saw the size of the hack I put in place to fix it
<wgrant> But if we also throw ffmpeg into the mix, I suspect that a LHC-esque world destruction will commence.
<NCommander> wgrant: it could be worse, ffmpeg could ship a debian folder
<wgrant> IIRC mplayer does.
<wgrant> So why wouldn't ffmpeg?
 * ScottK-laptop hands wgrant http://hasthelargehadroncolliderdestroyedtheworldyet.com/
<NCommander> ScottK-laptop: BTW< do you have one of those nokia internet tablets?
<ScottK-laptop> No.
<ScottK-laptop> Actually I have an old one around here somewhere.
<ScottK-laptop> N770 I think.
<wgrant> ScottK-laptop: Haha.
<NCommander> ScottK-laptop: care to enable root, give it access to some large space, and turn it into a buildd for Kubuntu-arm?
 * NCommander managed to get an arm port in the agenda at the last Kubuntu meeting :-)
<ScottK-laptop> Hmmm.
<ScottK-laptop> That'd take a long time to build anything.
<NCommander> ScottK-laptop: On my arm board (266Mhz/32MB), building GCC took roughly 16 hours
<NCommander> Beating out m68k by two or three orders of magatitude.
<NCommander> (GCC on m68k takes a week, GCJ takes another one. We don't have GNAT (yet))
<ScottK> NCommander: Did you see http://suihkulokki.blogspot.com/2008/09/marvell-mv78x00-board.html
<NCommander> and suddenly my wallet cried out in pain and was suddenly silenced
<NCommander> Scott, got any idea what that thing runs?
 * NCommander can't even find that board on their webpage :-/
<ScottK-laptop> Nope.
<NCommander> ScottK-laptop: Its a pity QEMU still doesn't have armel support
<persia> That there is a very nice piece of equipment.  Clearly there need to be lots of them in lots of places :)
<NCommander> persia: it would be a good buildd, I'll probably end up supplimenting my armel buildd with distcc to speed it up
<persia> NCommander: I'm tempted as a desktop.  Probably has significantly lower heat production than my current system (which can only operate ~9 months a year)
<NCommander> persia: I want an ARM or MIPS based netbook badly
<NCommander> persia: well, china has a prototype of the later so it may just happen
 * NCommander will port ubuntu to armel hopefully ;-)
<persia> NCommander: Seriously, chat with the mojo folk.  There's work already done there, and at least three other private ports of which I have heard.
<NCommander> persia: they do arm, not armel
<NCommander> persia: and #mojo doesn't exist :-)
<persia> NCommander: #handhelds@OFTC, but it seems to be mostly an email-driven group.  Anyway, differences between arm and armel aren't that huge, when compared to differences between {arm|armel|} and i386.
<persia> Still a good source of hints and guidance for your quest
 * NCommander nods
 * NCommander waits to see if his post shows up on planet
 * NCommander wishes he was a core-dev so he wouldn't have to tor^W ask Scott to upload backport fixes
<NCommander> THat being said, I'd be afraid an offical arm port of Ubuntu will end up like PowerPC, which gets relatively little love
<persia> NCommander: It's a matter of interest and use.  As long as there is enough hardware, I suspect it will get used.  powerpc was significantly more active before new ones stopped being sold, and most people didn't have them anymore.
<persia> With current hardware, I'd expect an armel port to be mostly interesting for NAS, routers, and MIDs.
<persia> (where NAS and routers are probably handled by ubuntu-server, and MIDs by ubuntu-mid)
<NCommander> Well, I've been working to fix most of the larger issues w/ PPC
<persia> Of course, that's just speculation: I could be wrong.
 * NCommander has a rather large sweet spot for that architecture
<persia> Excellent!  Do you have both "regular" PPC and ps3 HW?  I believe both need a bit of attention.
<NCommander> Just regular PowerPC
<NCommander> But I've been testing anything that hits hardy-proposed thats PPC specific
<NCommander> My largest pet peeve ATM is we don't have Kubuntu or Xubuntu CDs for ports
<NCommander> SPARC also needs huge amounts of love
<NCommander> I have a friend who tried Ubuntu SPARC and went back to Debian within a release citing unstabilitiy. My brief experiences tend to agree with him
<persia> REVU runs on sparc.
<NCommander> The issues may be resolved by now ;-)
<ScottK-laptop> Pretty well except when they hard drive died.
<ScottK-laptop> they/th
 * NCommander notes that for future reference someone asks me to fix a Sparc related FTBFS
<ScottK-laptop> e
<NCommander> It seems the only architecture I can't fix FTBFS for is now HPPA
<persia> NCommander: You have access to ia64?
<NCommander> d'oh
<NCommander> Everyone forgets ia64
<NCommander> Intel wants to forget ia64
<persia> Yeah, and it's starting to get in sad shape.
<NCommander> My one or two experiences with ia64 scared me for life likely
<persia> ia64 was up-to-date for hardy: it just doesn't seem to have gotten any attention for intrepid yet.
<NCommander> persia: know where I can find a community ia64 box?
<NCommander> ScottK: I've been thinking
<NCommander> ScottK: Could we possibly backport debhelper 7 (which is very different from six if you use the new style commands) under a different source package name so it would be easier to do actual backporting?
<ScottK-laptop> No.
 * NCommander waits fodr Scott to explain the reason which I likely overlooke
<NCommander> *overlooked
<ScottK-laptop> That's way past my crack-o-meter limit.
<ScottK-laptop> NCommander: It's not just a new name, it'd have to be co-installable so it'd have to live in a completely different namespace, but still work the same.
<NCommander> ScottK-laptop: so dump it out of the path, and then in packages that legit. need it, just add the PATH to the top of the rules
 * NCommander runs from scott before his crack-o-meter explodes
<persia> NCommander: backports is inherently crack, but is supported because it's high-quality crack, cut with only the finest ingredients, with significant quality control.
 * ScottK-laptop looks around for his advocation of NCommander for UCD.
<persia> backports stays supported only so long as our crack is better than other crack.
<NCommander> persia: hence why Dapper backports have died
<ScottK-laptop> NCommander: No, I think anyone still using Dapper either really wants exactly an unchanged system or is just lazy.
<NCommander> ScottK-laptop: We just got a dapper backporting request :-)
<ScottK-laptop> Note that I still have a Kubuntu Dapper desktop.  I'm reason number 2
<ScottK-laptop> NCommander: Is it tested?
<NCommander> ScottK-laptop: I said we got a request to do a backport, I didn't say I touched it ;-)
 * NCommander is subscribed to backport emails
<ScottK-laptop> K.  Let me know.
<NCommander> ScottK-laptop: I thought you advocating on my UCD
<ScottK-laptop> Right.  I did.  Now I'm wondering if I made a mistake.
<NCommander> *advoacting/advocated
<ScottK-laptop> ;-)
<NCommander> ScottK-laptop: -_-; It was an idea
<NCommander> Not like I already generated a source package or somethng ...
<NCommander> I fix libtool bugs. You need to realize at some point, my tolerance for horrible hacks is somewhat high :-P
<ScottK-laptop> True
<NCommander> wow, someone ported openjdk to m68k
<NCommander> O_O;
<persia> Could someone please give-back https://launchpad.net/ubuntu/+source/debian-installer/20080522ubuntu14/+build/715838 ?
<persia> It should build now.
<NCommander> I feel like fixing something
<NCommander> anyone know any good fixs?
<NCommander> er, anything that needs a good fix?
<persia> You've fixed all the FTBFS already?
<NCommander> Almost all in main
<NCommander> er
<NCommander> guess CUPS broke since the last time I looked
<ScottK-laptop> persia: Retried.
<persia> ScottK-laptop: Thank you.
<ScottK-laptop> No problem
 * NCommander looks at the Debian failed statats
<persia> NCommander: Have you been introduced to conflictchecker yet?
<NCommander> no
<persia> heh
<NCommander> should I run now?
<persia> http://conflictchecker.ubuntu.com/ has all the possible file conflicts for all the possible versions of packages that aren't already covered by a Conflicts: relation.  Some of them are spurious.  Others would benefit from versioned Conflicts: and possibly Replaces:
<ScottK-laptop> Or even integration with the update-alternatives system.
<persia> Fixing them all means fewer failed upgrades for people.  While there is upgrade testing between ISOs, there isn't much for every possible package, hence conflictchecker.
<NCommander> possible-conflcts 0 kb
<NCommander> this sounds like britney on steriods
<persia> http://conflictchecker.ubuntu.com/possible-conflicts/intrepid/main.txt
<NCommander> WTF
<NCommander> Clicking that link opened OOo
<persia> Yes, something like britney's great-grandchild after an intensive breeding program.
<persia> It's CSV.  Use a browser that doesn't try to parse everything if you want to see the text.
<NCommander> I dont' even grok the output of this
<wgrant> NCommander: It lists a package, another package, and a file that is shared between them.
<wgrant> I'm not sure why it's listing SPRs that didn't originate in Hardy.
<persia> NCommander: Looking at the first line: it appears that the bison package was split in feisty, pulling out bison-doc.  This might conflict with the bison from Dapper.
 * flyback is sick of spending weekends working on work stuff
<persia> wgrant: It lists everything because someone might have an old version installed, from some point.
<NCommander> I think you hurt my brain
<wgrant> persia: They shouldn't ever have an old version if a new version exists. That's not a supported upgrade path.
<persia> wgrant: conflict checker isn't about "supported upgrade paths".  It's about supporting all possible upgrade paths.
<wgrant> persia: Perhaps.
<NCommander> Looks like an insane amount of work
<persia> wgrant: No, that's what conflictchecker does.  Whether it's worth fixing them all or not is a different question.
<ScottK-laptop> NCommander: Sounds perfect for you.
<persia> NCommander: Obviously, you'll want to apply some filters to look for sane upgrade paths, etc.
<persia> wgrant: If you look, you'll notice that a number of the conflicts aren't even published anywhere: they were just intermediate versions during some development cycle.
<NCommander> I'm going to go get dinner first
<wgrant> persia: True.
<NCommander> Then maybe see if I can stomach this kind of work
<persia> NCommander: If you find a class of conflicts you believe ought be handled by the checker, feel free to update https://code.launchpad.net/conflictchecker
 * NCommander runs in fear
<NCommander> Nice, you found something more evil than libtool FTBFS :-)
 * persia ties little red bows on conflictchecker, and lays out a trail of candy
<NCommander> This is something that should be built in Launchpad for easy review and data parsing
<persia> NCommander: It just seems to be the class of stuff you like.  A large volume of repetitive tasks that require a moderate amount of technical knowledge, and a willingness to look where most fear to tread.
<NCommander> just moderate?
<NCommander> Bah :-P
<persia> I'm happier it's external: that way we can hack it to make it better.  Next year, I'll probably agree with you.
 * NCommander watches his ego deflate faster then the devaluation of the dollar
<persia> NCommander: Not a measure of your technical knowledge, it's just that you seem to prefer volume rather than the 2-month bugs.
<persia> If you prefer *hard* bugs to volume, feel free to clear out oldlibs :)
<NCommander> oldlibs?
<NCommander> Oh, finding rdepends and removing them
<NCommander> right?
<NCommander> WHere's the current NBS list?
 * NCommander might as well get to work
<NCommander> brb
<persia> Section: oldlibs.  Stuff that wasn't ever ported to a new API, and we support the old API (sometimes for years) because of two or three defunct upsteams.
<ScottK-laptop> NCommander: Or if you want, you can figure how to embed a copy of the newer ghc6 compiler in the DARCS package since it runs dog slow and we don't have enough time to to a proper transition of all the ghc6 packcages to the new (not brokenly slow) library.
<persia> Or we can come up with more hard bugs :)
<ScottK-laptop> I think maybe we scared him.
<persia> I hope not.
<persia> zirconium seems not to want to do anything right now :(
<NCommander> ScottK-laptop: I went away from keyboard
<NCommander> yay, dinner
<NCommander> Dacrs as in darcs VCS?
<ScottK-laptop> Yes.  Darcs as in the VCS.  It's written in Haskell and is not at all happy with our current gch6.
<ScottK-laptop> It's the only solution I've come up with.
<ScottK-laptop> Dunno if it's at all feasible or not.
<ScottK-laptop> Seemed like your kind of challenge.
<NCommander> Well
<NCommander> I know Ada
<NCommander> How can Haskell be?
<NCommander> ScottK-laptop: Dont' expect a debdiff, since it would be massive
<ScottK-laptop> Dunno.
<NCommander> Is upstream dead on dracs?
<NCommander> er
<NCommander> wait
<NCommander> What am I trying to do again?
<ScottK-laptop> Not AFAIK.  The problem isn't in darcs, it's in our ghc6
<NCommander> oh
<NCommander> OH!
<NCommander> Ew
<ScottK-laptop> Get the new GCH6 from Debian and find some magic way to build darcs against it and have it use it without having to transition every Haskell package in the distro.
<ScottK-laptop> Yeah, like I said, you're kind of thing.
<ScottK-laptop> There's probably even bootstrapping of some kind involved.
<NCommander> Would be creating a new ghc source package (ghc6-something) be acceptable?
<ScottK> NCommander: Dunno.
<ScottK> NCommander: Bug 263773 has the reference discussion.
<ubottu> Launchpad bug 263773 in ghc6 "ghc 6.8.2 has important performance bug, should be updated to 6.8.3" [Medium,New] https://launchpad.net/bugs/263773
<NCommander> Yeah
<NCommander> just found that
<NCommander> I think its the only sane way to do it
<ScottK-laptop> Whatever you consider, I'd ask sistpoty about it, since he coordinated the last GCH6 transition.
<NCommander> sid and intrepid have the same ghc version
<ScottK-laptop> Hmmm.  Maybe it's a new upstream then.
<NCommander> is anyone who is on release still awake?
<ScottK-laptop> NCommander: Main or Universe?
<NCommander> ghc is universe
<NCommander> so universe
<ScottK-laptop> You mean someone other than me?
<NCommander> Your on -release?
<NCommander> I thought you resigned that position
<ScottK-laptop> Yes.  No, I quite motu-sru.
<NCommander> Oh
<NCommander> Ok
<ScottK-laptop> Remember the flamestorm over Ruby Gems?
<NCommander> ScottK-laptop: I didn't realize you were still -release
<ScottK-laptop> If you don't associate that with me, then my duck and cover worked better than I ever imagined.
<ScottK-laptop> OK.
<NCommander> Well, what I'd like to do if you believe ghc6.8.3 is worth it is put it as a seperate source package (ghc6-*something*), then transition each package by hand that needs the performance tweaks
<ScottK-laptop> NCommander: I think it's worth considering and the sistpoty is the expert.  Run it by him.
<NCommander> When jaunty is opened, Debian should have finished the transition, we sync the resulting ghc packages, and then zap the old ones
<NCommander> He's not online, but I left a comment in that discussion
<NCommander> I'm looking at oldlibs
<NCommander> A bunch of these no longer have rdepends
<persia> NCommander: Debian is releasing Lenny RSN: there oughtn't be a leftover transition we can't do something about for intrepid.
<NCommander> Does that mean I should start filing removal requests?
<persia> NCommander: You're looking at reverse depends, reverse recommends, reverse build-depends, and reverse build-depends-indep?
<persia> If there's something in oldlibs with *none* of those, it can likely go.
<ScottK-laptop> persia: I'd say Debian is scheduled to release Lenny soon.
<NCommander> persia: I just checked apt-cache rdepends, is there a quick way to check all that?
 * ScottK-laptop hands NCommander grep-dctrl.
<persia> ScottK-laptop: Fair enough, but I don't expect Intrepid before Lenny.
 * NCommander needs the manual
<persia> NCommander: apt-rdepends tries to do some of it, but grep-dctrl is definitely the right tool.
<NCommander> So what command do I type?
 * NCommander has bad luck with advanced grep like commands
<ScottK-laptop> NCommander: There's also a cheater script for it in ubuntu-dev-tools named something like reverse-build-deps.
<ScottK-laptop> Look at that and you'll get the idea.
<NCommander> Its clear on libdb1-compat
 * NCommander looks up filing a removal request
<NCommander> anyone running hardy?
<persia> NCommander: You could create a hardy chroot ...
<ScottK-laptop> NCommander: https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Removing%20Packages if you didn't find it already.
<NCommander> I am
<ScottK-laptop> NCommander: I'm running hardy.
<NCommander> ScottK-laptop: want to run reverse-build-depends on libdb1-compat?
<ScottK-laptop> I'll do it.
<ScottK-laptop> NCommander: Nothing.
<NCommander> Yeah
<NCommander> Ok
<NCommander> Removal request filed
<NCommander> https://bugs.edge.launchpad.net/ubuntu/+source/db1-compat/+bug/269674
<ubottu> Launchpad bug 269674 in db1-compat "Request for Removal: unneeded oldlibs" [Undecided,New]
<ScottK-laptop> When I was doing some cruft cleaning for Hardy, I ended up asking for removal of a GCC 2. something package.
<NCommander> ScottK-laptop: For any packages I need to get free from the rdepends in Debain, will you sponsor NMUs?
<ScottK-laptop> NCommander: IANADD.
<NCommander> oops
 * NCommander files a removal request for atm-dev, which was a transitional package which has now existed for two LTSs, and is safe to remove
<ScottK-laptop> NCommander: IIRC there is slypheed package and a sylpheed-gtk2 package.  If that memory is correct, I'm pretty sure sylpheed can die.
<NCommander> Don't see it in oldlibs
<NCommander> And I can't find reasons why things were put in oldlibs
<NCommander> oh, I see
<ScottK-laptop> No.  That's not in oldlibs, it's just a generic thing that can die.
<NCommander> It appears dead
 * NCommander attacks gnucash
<ScottK-laptop> OK.
<StevenK> NCommander: What's the bug for atm-dev? :-)
<NCommander> StevenK: I need to tweak the source package to stop making atm-dev
<NCommander> StevenK: want to kill libdb1-compat while I do that?
<NCommander> StevenK: https://bugs.edge.launchpad.net/ubuntu/+source/db1-compat/+bug/269674
<ubottu> Launchpad bug 269674 in db1-compat "Request for Removal: unneeded oldlibs" [Undecided,New]
 * NCommander wants to kill every oldlibs now ;-)
<StevenK> NCommander: Once you tweak the source package, it will get NBS'd out
<NCommander> Score, care to sponsor that upload then?
<NCommander> And should I bother with an SRU to remove it from hardy?
<StevenK> NCommander: Nope.
<NCommander> I'll see about doing an NMU on this for Debian
<NCommander> (which may or may not be successful)
<NCommander> (the package is quite dead, four NMUs in a row)
<ScottK-laptop> NCommander: Removals virtually never happen after release.
<NCommander> legal reasons usually are the only reason, right?
<ScottK-laptop> That'd be the main one.
<ScottK-laptop> IIRC there was one time due to security concerns.
<NCommander> StevenK: rolling linux-atm
 * StevenK won't be doing a NBS run today
<NCommander> StevenK: but would you upload a package that would create a NBS?
<StevenK> I dunno.
 * NCommander confirmed it builds
<StevenK> :-P
<persia> Are there any buildd admins about today?  I'm having a queuing issue.
<NCommander> StevenK: https://bugs.edge.launchpad.net/ubuntu/+source/linux-atm/+bug/269683
<ubottu> Launchpad bug 269683 in linux-atm "Patch to remove atm-dev" [Wishlist,New]
<NCommander> I think I got gnucash building on goffice-0-6
<NCommander> :-)
<NCommander> another oldlibs bites the dust
<NCommander> ScottK: you should have pointed me to the oldlibs list ages ago
 * flyback still thinks "cranky crackmonkey" was a better name for ucuntu 6.0666
<flyback> go ahead and ban me too, i'm not going to be around much longer to give a fuck
<flyback> 8.04 seems sane though
<NCommander> StevenK: I filed a bug against the Debian package on atm-dev
<NCommander> ScottK or StevenK: https://bugs.edge.launchpad.net/ubuntu/+source/gnucash/+bug/269687
<ubottu> Launchpad bug 269687 in gnucash "Change of dependencies from goffice 0.4 to 0.6" [Undecided,New]
<persia> NCommander: I seem to remember there being some regressions in gnucash when that was last tried in gutsy.  Are you sure they are solved now?
<ScottK-laptop> NCommander: Which goffice is in oldlibs?
<ScottK-laptop> NCommander: Also, siretart (IIRC) has done some looking into this package at times.  I'd check with him.
<persia> LaserJock as well.
<ScottK-laptop> NCommander: Why are you building the Hardy version of kdenetwork in your PPA?  Didn't I upload that one already?
<NCommander> ScottK-laptop: I uploaded it to testbuild it at some point. Its just been pending constantly for some reason
<NCommander> ScottK-laptop: looking at both slackware and MacPorts, the change has been made without regressions
<ScottK-laptop> Ah.  OK.
<ScottK-laptop> Well it's not pending now.
<ScottK-laptop> I take that back.  Separate issue.
<ScottK-laptop> It's building anyway.
<NCommander> Do you know what the regressions are?
<NCommander> I can test now
<NCommander> (or if you wish to point me at the bug)
<persia> I don't remember clearly: if both slackware and MacPorts have migrated, it's likely safe.
<NCommander> I just ran gnucash, and tried a few basic operations, and it appears to be safe
 * NCommander added an account, and put more money then I have into it
<NCommander> persia: well, macports transitioned three upstream releases ago, and slackware around the same time.
<NCommander> So it should be safe
 * flyback is really starting to believe that terrorists have the right idea when dealing with assholes that piss you off
 * realist wonders if the NSA is listening...
<flyback> I hope so
<flyback> they can come ot my house and shoot me
<flyback> it's a win win for everyone
 * flyback decides that if he ever contacts his biological father his words of wisdom will be "NEXT TIME USE A FUCKING CONDUM"
<NCommander> ScottK: are you still around?
<slangasek> NCommander: do you want to at least talk with the Debian gnucash maintainer, please, before bumping its library dependencies based on nothing more than what other OSes are doing?  "It builds and lets me create an account" is not exactly a high QA standard for something that handles people's money.
<NCommander> slangasek: I filed a bug against Debian asking them to make the same change, and the justification behind it.
<NCommander> slangasek: if upstream supports goffice 0.6 natively (the package was ported to support 0.6 at some point in development), I've got to assume its relatively safe
<slangasek> no, you don't /have/ to assume that
<slangasek> there are lots of ways in which linking against goffice 0.6 instead of 0.4 might be broken for non-obvious reasons, only on Debian/Ubuntu
<NCommander> slangasek: so what do you suggest I do then
<slangasek> test it more extensively, and/or find a gnucash user to do some testing
 * NCommander nods
<RAOF> Why did the launchpad feel the need to try rebuilding miro on hppa?  It still fails, because python-gtk2-dev is still not installable.
<NCommander> Ok, but since I'm not a regular user of gnucash, do you have any ideas where I could find a good tester?
<NCommander> RAOF: my fault, sorta. I posted an SRU on gnome-python-extras
<NCommander> RAOF: which triggered the rebuild.
<slangasek> no; you're the one who's pushing a library change for the package in advance of Debian, I think it's your responsibility to find the testers
<NCommander> slangasek: I realize that. Then I will try and find a gnucash user who is willing to help test it
<persia> NCommander: #ubuntu-bugs is often a good place to troll for testers, or #ubuntu+1
 * flyback would like to find the idoits who did his grandma's drive way and convinced her that since the olddrain pipes from the gutter were now blocked, the solution was to just cap over the downsports and force the water to all the way to another corner of the house to drain
<NCommander> persia: thanks, that's helpful, I'll post gnucash to my PPA so testers can easily install it
 * flyback returns wet and miserable from unlocking the shit
<slangasek> flyback: this is a channel for Ubuntu development; please take your random comments (and inappropriate language) somewhere else
<flyback> I could say the same about your buggy distro
<Phil_S_> I'm new to the world of development. I read the wiki, but still have a question. Where's a good place for new people to start? The wiki makes it look like you have to be seasoned pro to get in at square one. (sorry if this is a dumb question)
<RAOF> Phil_S_: That's certainly not the case; which wiki page is so discouraging?
<RAOF> Phil_S_: #ubuntu-motu is likely the best place to start if you want to do packaging work; #ubuntu-bugs will likely be useful if you want to start triaging bugs.
<Phil_S_> Okay, I'll try #ubuntu-motu. I was looking through the wiki for UbuntuDevelopers and must have side tracked before finding a starting point. Thanks for the help.
<Mithrandir> kees: kill -9 $$ ?
<slangasek> Mithrandir: heh, a little delayed? :)
 * Hobbsee curses - damned intrepid bugs.
<Mithrandir> slangasek: slightly. :-)
<Hobbsee> oh, ewwww!
<Hobbsee> we have EULA's on ubuntu now?
 * Mithrandir ruffles the crazy green alien.
<Hobbsee> hey Mithrandir!
<persia> Hobbsee: It's optional.  epiphany-browser also works.
<Hobbsee> persia: i like firefox, though.  I just don't want a eula, which i apparently can't officially accept or decline.
<persia> Hobbsee: Well, the accept-or-decline thing is a bug, but I think the EULA is just part-and-parcel of the odd Firefox licensing anyway.
<Hobbsee> persia: yeah, well.
<Hobbsee> persia: i just don't really want to see it thrown in my face like that.
<persia> So, it's either use iceweasel or have a EULA, I think.  I saw some traffic about abrowser that might be a workaround.
<wgrant> abrowser doesn't seem to be a workaround.
<wgrant> At least it wasn't for me.
<wgrant> Why does $NEW_VERSION require a EULA when < $NEW_VERSION doesn't? This seems suspicious and wrong.
<persia> wgrant: I suspect an upstream change of some sort, although I've not inspected the code.
<persia> Also, I thought abrowser was supposed to be trademark-free (no branding).  How does that require a EULA?
<wgrant> It seems a rather odd change for a 0.0.1 increment.
<wgrant> persia: Maybe somebody forgot to turn it off.
<persia> That would make sense.  abrowser *ought* to be a workaround.
<wgrant> It doesn't seem to mention trademarks.
<wgrant> It just says that a portion of the code might be available.
<wgrant> And that I need to read the EULAs of the other pieces of software that the installer may ask me to install.
<wgrant> Both of which are false.
<persia> Right.  I can accept the idea of a click-through EULA, but only if it's actually accurate.
<wgrant> Well, the first is true.
<wgrant> It's not click-through, though.
<persia> And the second is a good idea.
<wgrant> What installer?
<wgrant> We do not have the installer of which it speaks.
<persia> libapt and similar sorts of things.
<RAOF> So, I've got a somewhat strange i18n bug from gnome-do.  When the translation .mo file is installed under /usr/share/locale/[lang]/LC_MESSAGES translations don't work; when it's under locale-langpack it works.
<persia> It's a good idea to read the licenses, although it's generally true that anything in main or universe is at least free to use for any purpose.
<wgrant> The end of section 3 appears to be the only mildly useful piece of information.
<RAOF> I'm pretty clueless about i18n.  It's my understanding that installing the mo files to /usr/share/locale/[lang]/LC_MESSAGES should work.  Any ideas why it doesn't, and why moving them to locale-langpack makes it work?
<terminator_> When will the 96.xx.07 driver be in envyng
<RAOF> After someone answers my question about translations, hopefully :)
<wgrant> Hmmm, the EULA has " | Ubuntu" on the end of the title. This must mean it is deliberate.
<terminator_> tseliot, when will the envyng program work with legacy cards using 96.xx.xx
<tseliot> terminator_: you should really ask nvidia about this. It's not my fault
<terminator_> I know it's not your fault and I did write nvidia and I am waiting for a reply
<terminator_> I just thought you might have am ideaa when it would be ready.
<tseliot> no, sorry
<terminator_> OK , thank you.  I will keep pestering nvidia for an answer.
<NCommander> persia: you still awake?
<persia> NCommander: typically
<NCommander> persia: I'm curious if you believe removal of gtk 1.2 from the archive (that is, fixing or porting all of its rdepends), is a worthwhile goal for jaunty
 * NCommander notes the last release of gtk was sometime in '02
<NCommander> er, 1.2
<persia> NCommander: I've thought it was a worthwhile goal for each release since feisty.  Mind you, I don't think it's worth removing any applications.
<NCommander> persia: I'm filing a bug with taks on every rdepend (132) for gtk1.2 towards that goal
<NCommander> And I'm going to work probably through all of jaunty removing gtk1.2 from the archive by clearing its rdepends one by one
<NCommander> and filing patches with Debian and upstreams
<persia> NCommander: OK.  Towards accomplishing that, could I convince you to port searchandrescue to the new joystick API?  It uses the linux 2.2 API (which is still supported), but that requires a GTK1.2 joystick calibration tool, which breaks joystick calibration for everything else.
<NCommander> persia: I don't own a joystick so I can't say I'm suited for that goal due to lack of hardware
<NCommander> I should be able to assume that GTK 2 has a joystick calibration tool as well, right?
 * NCommander found the joystick code in search and rescue
<NCommander> That uses libjsw, and not gtk directly
<NCommander> So it appears the changes need to be made there, and not in sar
<NCommander> so the package that needs porting to be specific is jscalibrator
<NCommander> *specifically
<persia> NCommander: No.  jscalibrator and libjsw need to be deleted with prejudice.
<persia> (read the changelog to see how I developed this opinion)
<NCommander> ow
<NCommander> I'm unaware of any other joystick libraries
<NCommander> Then again, only search and rescue use libjsw
<NCommander> persia: so should I should try and kill libjsw if possible?
<NCommander> persia: SDL has a joystick library, probably the best chance of porting this successfully
<NCommander> persia: ew, libjsw and searchandrescue were written by the same author. I don't think they want to dump their own joystick library
<persia> NCommander: searchandrescue is dead upstream.  Debian will accept the patch as soon as squeeze opens.
<persia> (well, not "dead", but no longer of real interest to the primary developers)
<persia> It's exceedingly likely that Fedora will also accept the patch, as interest has been expressed.
<NCommander> persia: I don't have joystick hardware so I can't do it. The best I can do is port the calibration rtool, and leave an open tracker item
<persia> NCommander: gizmod will let you map any arbitrary input device to any other arbitrary input device with a couple lines of python.  Just mirror your mouse to be a 2-axis, 5-button joystick.
<NCommander> persia: SDL hooks right into the kernel joystick driver, and I don't think gizmod would emulate joydev
<persia> NCommander: It does.  gizmod works at the device layer.
<NCommander> I'll look into it
<persia> Mind you, gizmod is complex enough that everyone else also writes dedicated userspace drivers for random input devices, and there's talk of extending DeviceKit so that gizmod is obsolete, but for now it's still easier than using uinput directly.
 * NCommander finds that porting packages with funny font manipulation feels like an oncoming headache
<s0u][ight> why did intrepid change kernel where they use an rc kernel?
<persia> s0u][ight: There were reports of issues with 2.6.26 that were known solved in 2.6.27, and it was believed that 2.6.27 would fix more problems than would be introduced by the inevitable regressions.  Whether this is true has yet to be determined.
<s0u][ight> like with compat-wireless there are now 2 versions introduced
<s0u][ight> and some patches i need don't apply for the new one
<NCommander> 2.6.27 broke ACPI on my laptop it seems :-/
<NCommander> Or at least, power management
<cjwatson> NCommander: please see my comment on your bug report about libdb1-compat; when the maintainer is an Ubuntu developer, it might be worth talking with them about it :)
<theclaw> is it possible with the alternate ubuntu installer to encrypt just one partition, and not the whole drive?
<NCommander> cjwatson: the package was synced from Debian though
<cjwatson> wgrant: abrowser shouldn't display the EULA; that's definitely a bug, and worth filing separately from the one you already filed
<NCommander> uh oh
<cjwatson> NCommander: yes, I'm aware of that :)
 * NCommander aims gun. Shoots foot
<wgrant> cjwatson: Filing, thanks.
<NCommander> cjwatson: ok, well .... now that I've already shot myself in the foot, I'll mark that invalid :-)
<cjwatson> NCommander: ok, thanks
<s0u][ight> cjwatson, remember me trying to install the 2.6.26-5-generic?
<cjwatson> yes
<NCommander> cjwatson: does that also apply to ncurses5?
<cjwatson> NCommander: I know nothing about that
<s0u][ight> the linux-headers-2.6.26-5-generic didn't install because i didn't have the linux-headers-2.6.26-5 in my repos :)
<cjwatson> NCommander: best would be to look back through the history for the reason it was introduced
<cjwatson> there's usually a bug report or something
<cjwatson> s0u][ight: that would be it
<cjwatson> theclaw: yes, you can do that with manual partitioning, though it's fiddle
<cjwatson> fiddly
<NCommander> Oh, it was done since some things didn't support the new ABI of ncurses5
<NCommander> er, api
<cjwatson> theclaw: create a partition, mark it as use as: physical volume for encryption, select configure encrypted volumes, follow prompts, then you should get a new region of free space in the main partitioning display on which you can create a normal partition
<cjwatson> theclaw: I don't recall whether doing this for your root filesystem works, though
<theclaw> cjwatson: oh, I overlooked this "configure encrypted volumes" option, thanks
<mld|dude> Hey! I want to make a new geometry-file for my Typematrix and share with you guys, is there any cool apps to do this or do I need to do it in text-mode..? if so, is there something I need to have in mind? Thanks in advance
<theclaw> cjwatson: that's a bit strange: in the encrypted lvm volume, I could create only one partition; the other space was labeled as "unsued" and I couldn't create a new partition there, but just "show information"
<theclaw> cjwatson: I hope I can do this later on
<theclaw> why does it want to have lilo installed instead of grub?
<theclaw> it wants to install lilo on /dev/mapper/sda5_crypt
<cjwatson> theclaw: yes, you can only create one partition; if you want more than one, create a single partition there, mark it as "physical volume for LVM", select "configure the logical volume manager", and create multiple logical volumes.
<cjwatson> theclaw: sounds like you tried to put the partition containing /boot on LVM. grub doesn't work with that
<cjwatson> (or at any rate the installer code believes it doesn't)
<cjwatson> theclaw: you probably just need to create a separate unencrypted /boot
<theclaw> cjwatson: no, I didn't, boot is a seperate partition
<theclaw> cjwatson: I forgot to set the bootable flag
<theclaw> cjwatson: it works now, but I created just a single partition inside lvm, no physical volume
<theclaw> cjwatson: can I put this partition in a new physical volume without reinstalling?
<cjwatson> only if you have enough space on the disk to move all the data elsewhere temporarily, and if you're familiar with using the LVM tools by hand
<cjwatson> if the installation is new and there's nothing important there, it would probably be easier to just blow it away ...
<theclaw> oh mz.
<theclaw> oh my.
<theclaw> so do I get this right? I create a "physical volume for lvm", i.e. at the moment I'm not using LVM at all? I'm just using dmcrypt?
<theclaw> *sigh*
<cjwatson> that's right
<cjwatson> assuming you *didn't* create a physical volume for LVM
<cjwatson> I did say it was fiddly :-/
<theclaw> I just created a physical volume for encryption, yep.
<theclaw> I thought it does all that "behind the scenes" and that it's just a installer-bug which caused the 1-partition-limit ;)
<theclaw> yep, then I'll blow all away again
<theclaw> thanks cjwatson :)
<theclaw> for your help
<theclaw> no big deal reinstalling, anyway.
<theclaw> I feel like a idiot now :)
<theclaw> *an
<cjwatson> don't. the partitioner's support for complex block devices is more complicated than it should be.
<theclaw> hmm
<theclaw> when I create a volume inside a volume group, it seems that the size of this volume can't be set to an arbitrary value
<cjwatson> can you be more specific?
<theclaw> sorry; I set it to '48000 MB', but it's 50331 MB
<theclaw> (50331 MB is shown it "configuration details"
<theclaw> hmm
<cjwatson> $ bc -lq
<cjwatson> 48000*1024*1024/1000/1000
<cjwatson> 50331.64800000000000000000
<cjwatson> it's using the wrong units
<theclaw> thanks
<theclaw> maybe mib works
<cjwatson> doubt it
<cjwatson> this is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=411943
<ubottu> Error: Could not parse data returned by Debian bugtracker: global name 'ls' is not defined (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=411943;mbox=yes)
<cjwatson> it's fixed in current partman-lvm but I wasn't happy about pulling the changes involved into intrepid after feature freeze
<cjwatson> so we'll get it in jaunty
<theclaw> okay
<theclaw> haha that's so confusing; sometimes it also displays the correct values!
<theclaw> or, no, doesn't :)
<theclaw> sorry, I'm kinda confused now, but so what, I have to do it only once ;)
<theclaw> "This issue has been in partman for quite some time. There's absolutely no
<theclaw> reason to consider it anything than a cosmetic issue.
<theclaw> (sorry, two lines) - what an arrogant ..
<cjwatson> theclaw: perhaps, but his motives at the time were to try to produce a stable Debian release and he was responding to the relatively high severity set on the bug. You need to read it in context
<cjwatson> Frans is a good guy
<theclaw> I didn't think about that
<theclaw> thanks alot for your help cjwatson :)
<Gelikafkal_> #pennergam
<cjwatson> no problem
<Gelikafkal_> #pennergame
<cjwatson> Gelikafkal_: please don't spam here.
<Gelikafkal_> yes
<Gelikafkal_> ok
<Gelikafkal_> i've tried something out
<theclaw> the misc-fixed bitmap-font seems to be installed, however I can't select it in gnome terminal; I did enable bitmap-fonts with 'dpkg-reconfigure fontconfig-config', and I can also select helvetica, for example; xlsfonts also lists misc-fixed-*
<theclaw> any idea why?
<calc> hello
<james_w> hey calc
 * calc still hanging out at davidm's :)
<calc> the hurricane followed me up to his place, they are expecting gusts of 50mph here
<calc> not nearly as bad as what happened at my place i'm sure, hopefully its still intact when i get home
<calc> i think they expected gusts ~ 95mph there
<calc> 3mil people in houston have no electricity :\ i'm guessing that includes my house
<calc> "The cityâs last direct hit from a hurricane came from Alicia in 1983, when 750,000 CenterPoint customers lost power. It took 16 days to restore all service."
<calc> and this storm did double that
<slangasek> heh, who added 9MB to the live CDs overnight? :P
<ScottK-laptop> There was a language pack run last night?
<calc> wasn't me :)
<calc> i was hiding from a hurricane :)
<Nafallo> calc: wimp ;-)
<calc> Nafallo: :-P
<slangasek> oh, it's probably whatever pulled in tcl/tk
<slangasek> python, seemingly
<slangasek> calc: you didn't make any font changes in OOo, by chance?
<slangasek> ttf-dejavu is now being pulled in too, for 2.5MB
<slangasek> doko: it looks like something is wrong with the new python build, it's pulling in all of (blt -> (tcl8.5, tk8.5), tcl8.4, tk8.4) now
<doko> slangasek: it is. it is the _tkinter_failed.so stuff. the damn python configure wants to build with 8.5, and then fails. 8.5 seems to be installed, but not the -dev package. feel free to fix. I'm away for today
<slangasek> hmm, ok
<doko> I can look at it tomorrow
<slangasek> it may end up waiting for you, I don't think I have time to tackle it today
<calc> slangasek: didn't make any changes in the past couple days anyway
<slangasek> calc: this may be the first successful livefs build since the landscape-client issue; did you make any changes regarding font deps in the couple days before that? :)
<slangasek> I think the likely culprit is fontconfig-config, I'm just not sure why
<slangasek> yah, fontconfig-config is pulling in ttf-dejavu because its deps get pulled in before whatever pulls in ttf-freefont and ttf-bitstream-vera, both of which are also included and satisfy the | dep
<calc> slangasek: the last time i changed anything in OOo was for the 8ubuntu1 upload
<calc> slangasek: i've been working on updates since then but haven't uploaded anything else yet
 * slangasek nods
<slangasek> calc: ok, you're off the hook then ;)
<slangasek> ah, the extra fonts also trace back to the python dep on tcl8.4
<slangasek> that makes it easy
<erast> hi
<Tonik> is there some unofficial build of Nautilus offering more view options than just Icons and List?
#ubuntu-devel 2008-09-14
<CrankWidow> hmm.. is apt-get installing recommends by default now?
<CrankWidow> or is my debconf set wonky..
<ScottK-laptop> CrankWidow: It's default in Intrepid.
<CrankWidow> thus.. --no-install-recommends will be a new few chars in my apt-get commands :)
<CrankWidow> esp when packages recommend module sources
<ScottK-laptop> CrankWidow: If recommends are excessive, please file bugs.
<CrankWidow> sounds like a plan
<CrankWidow> moving true recommendations to suggestion status?
<CrankWidow> err.. mild recommendations
<CrankWidow> sorry.
<ScottK-laptop> CrankWidow: Before filing bugs, I recommend reading the definition for Suggests/Recommends in Debian Policy.
<CrankWidow> word
<calc> my sister is reporting to me about the damage around my home
<calc> apparently its fine but lots of flooding nearby
<Hobbsee> you know, what would make intrepid perfect would be if it supported all of my multimedia keys.
<wgrant> Hobbsee: System->Preferences->Keyboard Shortcuts doesn't help?
<slangasek> Hobbsee: regression from hardy for you?
<Hobbsee> slangasek: regression from gutsy.
<Hobbsee> wgrant: nope.
<Hobbsee> my "next track" never gets a keycode, at all.
<slangasek> the current model doesn't use X keypress events for media keys
<Hobbsee> what's the official way for debugging it now?
<slangasek> hal grabs them directly and dumps them to dbus
<slangasek> dbus-monitor, perhaps?
<Hobbsee> slangasek: right - i get the rest of the keys thru that, but not next track.
<slangasek> hmm
<slangasek> then I guess that's hal's fault :)
<Hobbsee> tail -f /var/log/kern.log doesn't mention it, so the kernel's not ignoring it.
 * Mithrandir tickles the green alien
<Hobbsee> hey Mithrandir!
 * Hobbsee stomps on Mithrandir's feet
 * LaserJock wonders why Hobbsee thinks that would hurt
 * Mithrandir watches Hobbsee's feet turn blue as she stomped on steel-toed boots.
 * wgrant stomps on LaserJock.
<Hobbsee> Mithrandir: awww
 * Mithrandir hugs Hobbsee 
<Hobbsee> LaserJock: based on what I saw at UDS, when I stomped on someone else's foot, apparently it does hurt.
 * Hobbsee hugs Mithrandir back :)
<Hobbsee> racarr's foot.
<LaserJock> well, no offense, but that's not saying much
<Hobbsee> heh.
<Hobbsee> slangasek: i don't suppose you have a guide or something that talks about keycodes and hal?
<Hobbsee> hm, lshal -m doesn't come up with *any* of the keys, whether they're picked up in xev or not.
<LaserJock> slangasek: are the dailies being tested at all yet?
<slangasek> Hobbsee: no, I only have what I've gleaned over the past week while debugging my own keyboard issues :/
<slangasek> LaserJock: "yet"?  daily CD images have been getting smoke tested for some time, in between the periods of breakage
<LaserJock> slangasek: I was thinking in preparation for the next Alpha
<Hobbsee> slangasek: right. :-S so on that basis, what should I do for reporting a bug about this?
<slangasek> LaserJock: ah; we're a bit early for that, currently we have a problem with python2.5 pulling in 9MB of tcl/tk crap
<slangasek> Hobbsee: um... file a bug on hal, and make pitti fix it :-)
<LaserJock> heh
<slangasek> LaserJock: (which is a problem because it makes the liveCDs oversized...)
<LaserJock> sure
<LaserJock> I was just gonna maybe build a new Intrepid VM and wondered what my chances of getting it to install were
<LaserJock> man I wish VMware Player could do snapshots
<slangasek> should be pretty good
<wgrant> LaserJock: Why not use something less restrictive like KVM or VirtualBox?
<LaserJock> well, because VMWare Player is the fastest
<LaserJock> it's a pain, granted, but it seems to have the best performance
<LaserJock> I suppose I could install vmware server to make VMs and do snapshots and player for actual use
<LaserJock> but that seems like an awful lot of work
<LaserJock> is KVM any faster than qemu if you don't have a CPU with vmx/svm?
<persia> Recent versions of KVM won't even fall back to qemu if you don't have the right CPU.
<persia> Installing kqemu-source can help to make qemu faster on such chips.
<LaserJock> I see
<Hobbsee> slangasek: saying what?  Beyond "this key doesn't work on this machine"
<slangasek> I don't know
<slangasek> but I think saying just that much is sufficient to establish that there's a bug, so
<johanbr> Hobbsee: dell?
<hardwire> we talking windows here?
<Hobbsee> johanbr: yes.
<Hobbsee> johanbr: 6400
<johanbr> I have the same problem here on my Inspiron 1420.
<slangasek> hardwire: uh... never? :)
 * hardwire heard "key"
<hardwire> I just assume the worst
<slangasek> we also have keys in Ubuntu (?)
<hardwire> oh yeh. :)
<calc> hey got a question its important
<calc> where is the information for the top panel bar stored in the user dir?
<RAOF> ~/.gconf
<calc> davidm's panel bar got eaten, maybe by the deskbar-applet 2.22.3 update
<calc> RAOF: oh it is?
<RAOF> Yup.
<RAOF> Specifically, /apps/panel, I believe.
<calc> ok we'll try backing his up the overwriting it
<RAOF> gconftool-2 --recursive-unset /apps/panel should reset the panels to the default layout.
<calc> still doidn't work
<erast> hi
<calc> trying the new command now
<erast> NCommander told me that debarchiver obsolete. in nexenta we still using it, what is the preferred tool these days?
<NCommander> erast: its not really obsolete, but its not meant to handle an entire archive, it has no NEW queue or other advanced features last time I used it
<erast> i forgot, what is the new tool?
<calc> the killed the bar entirely, lets see on login
<calc> that fixed it, thanks! :)
<erast> regarding buildd and missing deps, we uploaded ~ 100 new packages including xorg and samba
<erast> wow... nexenta's version of debarchiver indeed prehistoric... 0.4
<calc> he ran low on disk space in home earlier today and apparently gconf decided to eat the panel
<calc> but now its fixed :)
<NCommander> erast: wow, upgrade that antique :-)
<NCommander> if nothing else
<NCommander> jdong: I'm uploading the updated ktorrent to the PPA
<jdong> NCommander: cool
<erast> NCommander: i'm thinking if Nexenta developers need to send patches directly to its immediate upstream (ubuntu) or to the debian maintainers?
<NCommander> erast: interesting question, probably upstream unless upstream is completely dead
<ScottK> erast: It probably depends if the package in question was modified by Ubuntu.
<ScottK> NCommander: We're not dead.
<ScottK> erast: Also it's important to explain what the patch is for and why it's relevant in Debian/Ubuntu.
<NCommander> ScottK: I meant the package maintainers, as upstream as in them
<NCommander> jdong: https://bugs.edge.launchpad.net/hardy-backports/+bug/267494
<ubottu> Launchpad bug 267494 in hardy-backports "Please backport ktorrent to 2.2.7" [Wishlist,Triaged]
<erast> ScottK: OpenSolaris porting fixes mainly
<ScottK> erast: Probably to Debian then unless it's a package with a big Ubuntu diff already.
<jdong> NCommander: looks pretty good from the debdiff; do you think you can find a few people to test it, or give it a longer term test with DHT enabled?
<jdong> NCommander: I've been a bit gun-shy about ktorrent updates because they tend to regress like that
<NCommander> I don't use ktorrent
<NCommander> (or hardy even regularly)
<NCommander> So I have no idea where to find testers
<ScottK> Isn't there an #ubuntu-torrent
<jdong> NCommander: put a link up to the PPA in the bug report and let's wait a week to see if anything happens
<jdong> NCommander: I've been through enough ktorrent releases to know not to trust their 0.0.1 release bumps
<NCommander> jdong: ok
<suornam> hi
<suornam> sometimes i find myself updating my system, and i forget to give the go-ahead to download all the packages
<erast> NCommander, ScottK: added section to Nexenta policy: http://www.nexenta.org/os/NexentaRepositoryPolicyMain
<erast> thanks
<suornam> has there ever been any talk over potentially just starting the download any way and then asking only upon installation? some sort of option to aptitude or apt-get perhaps?
<suornam> i know opera does something similar when you download files, it begins to cache some percentage of it and if you decide not to download a file, opera discards it
<jdong> suornam: most browsers do this. it'll start downloading while waiting for you to answer the question
<jdong> whether or not APT will do it is another story
<jdong> you can make your own alias to first apt-get -d install
<jdong> then apt-get install
<bryce> JonCruz, whoa that's awesome
<suornam> jdong: interesting
<jdong> and poof.
<wgrant> At least it wasn't a 15-second driveby
<wgrant> Does anybody know anything about checksums?
<wgrant> And now I part in about 10 seconds.
<NCommander> Oh geeze
<NCommander> I'm getting a Mozilla EULA
<NCommander> I thought this was fixed
<LaserJock> anybody know if you have to tell qemu to use kqemu? or does it just use it if it finds it?
<LaserJock> nvm, I think I figured it out
<wgrant> NCommander: It's not a bug.
<wgrant> NCommander: See bug #269656
<ubottu> Launchpad bug 269656 in firefox-3.0 "AN IRRELEVANT LICENSE IS PRESENTED TO YOU FREE-OF-CHARGE ON STARTUP" [High,Confirmed] https://launchpad.net/bugs/269656
<NCommander> wgrant: well, its in a bug ;-)
 * NCommander runs for the bad pun
<TheMuso> RAOF: Just a heads up theres another pulseaudio revision to be downloaded and installed. I have fetched a few fixes from git.
<RAOF> TheMuso: Testing it right now; still underruns!
<RAOF> Not a lot, and it seems that some songs trigger this more than others.
<TheMuso> Hrm very interesting.
<TheMuso> RAOF: You a member of the pulse-rt group?
<RAOF> Yes
<TheMuso> gah!
<TheMuso> I need to give pulse a run from my various hda capable systems.
<RAOF> It's grabbing it's realtime signal, nice value, and HPET just fine.
<RAOF> (Incidentally, "Fresh high-resolution timers available! Bon appetit!" is a cool debug message)
<TheMuso> Agreed.
<TheMuso> RAOF: If you can reply to your bug with some fresh log messages, I'll talk to Lennart about it. I suspect its alsa, but need his confirmation from reading the logs.
<RAOF> I'll try some different players, too.
<RAOF> Hm, next piece of interesting behaviour?  It only prints I: underrun messages if I've got a pavucontrol connected.  If I don't, it still underruns, but doesn't print a message.
<TheMuso> RAOF: Very interesting.
<RAOF> Woo!  That's somewhat of a regression, too!
<TheMuso> RAOF: What is?
<RAOF> Transferring a stream from usb -> hda.  It transfers immediately, then switches back to usb after ~1/4 of a sec for ~1/2 a sec, then settles back on hda.
<TheMuso> ouch! I have a USB sound card, so I'll try that myself a bit later.
<TheMuso> RAOF: What did you use to transfer the stream? Maybe using the pactl command to transfer it may yield different results.
<RAOF> TheMuso: Same result with pactl
<TheMuso> RAOF: Ok, I'll check it out myself later, and take it up with Lennart. I am starting to think that we will have to stick to 0.9.10.
<RAOF> Grr.
<RAOF> The underruns aren't _that_ annoying :/
<RAOF> You know, it may be that gstreamer is also involved in this, given the strange apparent codec-dependency.
<wgrant> FWIW, I appear to be getting underruns on 0.9.10.
<wgrant> But only from a day or two ago.
<TheMuso> wgrant: Would it be possible for you to try 0.9.12 from my PPA? http://launchpad.net/~themuso/+archive? Note that this will also pull in a new libasound2, with some fixes from git.
<wgrant> TheMuso: Sure, doing so now.
<TheMuso> wgrant: Thanks.
<NCommander> RainCT: please do me a favor, and join #kubuntu-devel and talk with apachelogger
<slytherin> Mithrandir: are you still looking into the bluetooth packages?
<slytherin> can anyone please ack bug #268097
<ubottu> Launchpad bug 268097 in bluez-utils "Please move bluez plugins to main" [Undecided,New] https://launchpad.net/bugs/268097
<NCommander> saivann: ping
<saivann> NCommander : pong
<NCommander> saivann: I did some debugging on the gnucash printing issue
<NCommander> It's not a bug in goffice/gnucash
<NCommander> It only manifests itself with -0-6 because gnucash will use GTK's print mechanism over its own
<saivann> NCommander : You speak about missing options when gnucash is built with libgoffice 0.6 ?
<NCommander> yeah
<NCommander> Its a rather interesting case
<saivann> NCommander : Oh, so what is the guilty package? :)
<NCommander> gtkprint
<NCommander> https://bugs.edge.launchpad.net/ubuntu/+source/gnucash/+bug/269687
<ubottu> Launchpad bug 269687 in gnucash "Change of dependencies from goffice 0.4 to 0.6" [Low,Confirmed]
<NCommander> If you try something else that uses gtkprint, like gnumeric
<NCommander> Same problem
<saivann> NCommander : Did you find a bug in gtkprint for that issue?
<NCommander> Well, er ...
<NCommander> I don't have a printer
<saivann> NCommander : Ah :)
<NCommander> So its kinda hard for me to test beyond this
<NCommander> What printer are you trying?
<NCommander> (it might be an issue with your specific printer vs anything else)
<saivann> NCommander : That makes sense
<saivann> Ncommander : Mmh I doubt that it's printer specific because I have the same result with my HP printer and with cups-pdf printer
 * NCommander plugs in his HP printer
<NCommander> It may not work, but at least Ubuntu sees it
<saivann> NCommander : HP, normally all HP printers works!
<saivann> NCommander : Do you know how we can test more applications that uses gtkprint? How to find these?
<NCommander> Most GNOME ones use it
<NCommander> gnumeric uses it
<saivann> NCommander : Oh.. yeah, even gedit
<NCommander> weee
<NCommander> PLugging in a new printer crashed things
<NCommander> saivann: well, can you set page opens in gedit/gnumeric?
<saivann> NCommand : The problem is exactly the same with gtkprint, unfortunately
<saivann> s/gtkprint/gedit/
<NCommander> at least its not gnucash specific
<NCommander> (gnucash's code is a horrid trainwreck of messyness)
<saivann> NCommander : Definitively not, and since it's not breaking anything too important, I think that we can't consider this as a blocker for libgoffice 0.6
<saivann> NCommander : The reports are still printed correctly, we should report the gtkprint issue so this bug get fixed everywhere. Apparently, this bug also appears on hardy, so this is not a regression
<NCommander> I can see at least two bugs related to this issue filed against gtk+2.0
<NCommander> https://bugs.edge.launchpad.net/ubuntu/+source/gtk+2.0/+bug/183126
<ubottu> Launchpad bug 183126 in gtk+2.0 "default page size not respected by applications" [High,Incomplete]
<NCommander> https://bugs.edge.launchpad.net/ubuntu/+source/gtk+2.0/+bug/258794
<ubottu> Launchpad bug 258794 in gtk+2.0 "gtkprint doesn't use the ppd default paper size" [Low,Triaged]
 * NCommander reassigns the bug to gtk
<saivann> NCommander : I guess that 183126 should be a duplicate of 258794
<NCommander> https://bugs.edge.launchpad.net/debian/+source/gnucash/+bug/269687 - bug reassigned, although I can't seem to drop the remote watch
<ubottu> Launchpad bug 269687 in gtk+2.0 "Page Size greyed out in gtkprint applications." [Medium,Confirmed]
<saivann> NCommander : I just tested with gutsy and feisty and the bug is not there, the bug appeared with hardy
 * NCommander nomiates for release
<NCommander> saivann: Well, the bug is filed
<NCommander> siretart: ping
<NCommander> saivann: aside from this issue, did you find any other goffice-0-6 bgs?
<siretart> NCommander: what's up?
<saivann> NCommander : No, and the fonts are cleaner, it even fixes a crash bug that I did not get to find
<NCommander> siretart: ghc6 :-)
<siretart> haskell!
<NCommander> Namely the 6.3 transition
<saivann> siretart : Hi
<siretart> hey saivann
<NCommander> We have a few packages that really need the speed improvements of 6.3
<NCommander> But the transition would take too long and its too late in intrepid's cycle
<NCommander> I suggested we package 6.3 ghc as a seperate source package, and then rebuild each package that needs it (darcs comes to mind)
<NCommander> I was told to talk to you on this
 * siretart never touched a haskell related package before. are you sure you don't confuse me with sistpoty?
<NCommander> oh wait
<NCommander> shoot
<NCommander> damn, not enough coffee DEVERROR
<NCommander> saivann: so you going to upload my debdiff :-)
 * NCommander notes it should be updated to include the new bug numbers
<siretart> saivann: what's the plan with gnucash? go with the new upstream version? or backport the patches?
<saivann> siretart NCommander : I want to work with debian since we sync the package. There is a lot of chances that 2.2.7 get released in the next week so I want to get it into debian and then sync it
<NCommander> saivann: well, we need to also get this change into Debian
<saivann> Ncommander : I think that we should include your patch, yes. Did you forward this to debian?
<NCommander> saivann: I made a request that the change be made, but I didn't post a debdiff
<NCommander> (there is a link to the Ubuntu bug)
<saivann> NCommander : I'll take care of the debian patch
<NCommander> saivann: I'll do that, I need another NMU for my NM application ;-)
<saivann> NCommander : Oh, go ahead then :)
<NCommander> Well, someone still needs to upload the patch; are you the debian gnucash maintainer?
<saivann> NCommander : No, the debian maintainer is Thomad Bushnell, and he generally uploads new gnucash version in a short time, especially when you gives him a already prepared package
<saivann> Thomas Bushnell*
<NCommander> I know him
<NCommander> He works on Hurd ;-)
<saivann> NCommander : If he does not update gnucash to 2.2.7 in the required time, we'll have to do a ubuntu package. I'll make sure that we don't miss the train.
<saivann> NCommander : Nice :)
<NCommander> I'll roll a NMU patch
<siretart> saivann: out of curiosity, do you think that package would make it to lenny? if yes, why?
<saivann> siretart : Oh, I'm not aware of current debian release cycle, I assumed that it would be easily updated to 2.2.7 since it's a bugfix release
<siretart> saivann: no, every debdiff gets hand reviewed since the beginning of the freeze.
<saivann> siretart : Thanks for this information. Then it might be interesting to re-consider using upstream patches and creating a ubuntu package..
<saivann> siretart : I have no idea if it can get into debian at this point, in your opinion?
 * NCommander tests building in sid
<saivann> NCommander : You said that gnucash was one of the last app that depends on libgoffice 0.4 ?
<siretart> saivann: without having reviewed the diff between the versions, I cannot answer that. it mainly depends how many bugs with severity >= important the new release fixes
<siretart> you might convince thomas to upload to experimental, though
<NCommander> saivann: the only other rdepends is gnome-chemistry-utils, and that already moved to goffice-0-6 upstream
<NCommander> I haven't seen if the old source will build against goffice-0-6
<NCommander> If it does, that clears the rdepends on 0-4
<saivann> siretart : That sounds like a possibility, however, would it be really "unclean" that we release our own gnucash package for the 2.2.7 if it is not uploaded to debian in time?
 * NCommander would like to drop goffice this release if possible
<NCommander> 0.4
<NCommander> I want to drop gtk1.2 for jaunty ;-)
<siretart> saivann: just make sure that we end up with the same orig.tar.gz as in debian
<siretart> saivann: but since we are in freeze as well, a freeze exception is necessary in ubuntu as well
<NCommander> saivann: a goal of mine is to remove gtk 1.2 from Ubuntu and Debian, care to help work towards that goal?
<saivann> siretart : Yes, if there is no critical bug fixes in 2.2.7, I'll simply request patches for libgoffice and HBCI to be added to the package as a update
<cjwatson> NCommander: are you volunteering to port the remaining programs to gtk2? great!
<NCommander> cjwatson: well, I'm learning how to
<NCommander> cjwatson: 132 rdepends left
<NCommander> That's going to be a fun bug :-)
<NCommander> Probably a record too
<cjwatson> putty is ported upstream, btw, just waiting for a new release
<NCommander> cjwatson: the only problem I found with 1.2 to 2.0 porting is that freeing code from depericated APIs is a pain
<saivann> NCommander : I would, but I already have many projects :) However, I'll do my best so your debdiff for gnucash gets uploaded for intrepid
<NCommander> i.e. using PangoLayout over gtk_draw_screen
<NCommander> cjwatson: any tips ;-)?
<cjwatson> RTFM ;-)
<NCommander> RTFM isn't that greatly detailed
<cjwatson> (carefully ...)
<cjwatson> the GTK manuals are excellent
<NCommander> the porting one isn't
<cjwatson> IME, anyway
<NCommander> It's pretty vague
<cjwatson> sure, but you can figure it out from the ordinary reference documentation (old and new)
<NCommander> The problem with porting to 2.0 is I don't know 1.2 at all ;-)
<NCommander> "What does this function do?"
<NCommander> ;-)
<cjwatson> hence using the old reference docs as well
<saivann> NCommander : Perhaps that bug 269687 would need to be reported upstream, can you do that?
<ubottu> Launchpad bug 269687 in gtk+2.0 "Page Size greyed out in gtkprint applications." [Medium,Confirmed] https://launchpad.net/bugs/269687
<NCommander> saivann: do you have access to a sid box?
<NCommander> (lets just see if it exists in Debian)
<saivann> NCommander : No I don't
<NCommander> we need a vict^W voluteer
<NCommander> cjwatson: BTW, can you weigh in on a bug for me?
<cjwatson> NCommander: that depends on the bug
<NCommander> cjwatson: https://bugs.edge.launchpad.net/ubuntu/+source/ghc6/+bug/263773 - do you believe my solution is fessible
<NCommander> (ghc6 fun)
<ubottu> Launchpad bug 263773 in ghc6 "ghc 6.8.2 has important performance bug, should be updated to 6.8.3" [Medium,New]
<cjwatson> I really don't know anything about Haskell and don't think I'm qualified to judge, sorry
<NCommander> cjwatson: roughly speaking, would it be acceptable to package the new version of the compiler as a new source package, and then transition the packages that need it
<cjwatson> yes, I did understand the comment, but I still don't want to make a decision about a language family I don't use and whose packaging I've never looked at
<cjwatson> I don't know what implications that might have
<azeem> darcs seems to Build-Depend on quite a few haskell libs
<NCommander> cjwatson: ok
<NCommander> azeem: yeah, I noticed that too, its not a pretty situation
<azeem> NCommander: so what are you going to do with those?  Have new source packages for them as well?
<NCommander> azeem: now that you pointed that out, I retract my idea
<NCommander> cjwatson: are you able to edit distributions on Launchpad, or do I need to find a LP admin to get one changed
<cjwatson> NCommander: only Ubuntu
<NCommander> cjwatson: strange. I'm in the drivers for Nexenta, but I can't edit the distribution at all to add annoucements
<cjwatson> you'll need to ask #launchpad for help
 * azeem ponders starting http://NCommanders.occupation.of.the.week.com
<NCommander> azeem: It's not like this intentionally happens to me
<NCommander> azeem: I woke up this morning with the intent on porting search and rescue to SDL,a nd somehow ended up teh Nexenta archive admin and a core dev for them
<azeem> happens to me all the time
<NCommander> azeem: I mean, I was/am a hurd porter who got involved in m68k, fixed a bug in Ubuntu, got involved in backports, became an Xubuntu dev, then a Kubuntu dev, now an Nexenta archive admin
<NCommander> ARGH
<NCommander> Its hard to even find a chain of events that link all those together!
<azeem> you forgot kfreebsd!
<NCommander> oh yeah
<NCommander> kfreebsd!
<NCommander> I even ran a dak server for m68k o_O;
<NCommander> And I host buildds for m68k without having any m68k hardware
<NCommander> (go emulators go)
 * NCommander just needs help
<NCommander> sadly, hurd never implemented that function
<azeem> which function?
<NCommander> ncommander_needs_help()
<azeem> ah
<NCommander> I do hold my Hurd CVS commit rights though as a badge of honor ;-)
<NCommander> "Incredibly high tolerance for pain"
<NCommander> ;-)
<azeem> did you ever commit something?
<NCommander> one line of code actually made it into the CVS repo
<NCommander> :-)
<NCommander> (ID string for realtek card I had)
<NCommander> I also placed both my entropy patch and my GDB work in branchs
<azeem> oh, I checked the Hurd repo, not Mach
<NCommander> I don't think I commited anything to hurd directly
<NCommander> Just mach
<NCommander> (And a small patch to GCC)
<NCommander> I wish we had a totally open laptop though (free bios and hardware), with a free CPU core
<NCommander> Maybe something based around the open SPARC chips ...
<NCommander> damn, that would be awesome
<saivann> NCommander : I think that your gnucash patch should be applied to current gnucash package, we should not wait on debian for that since the intrepid final release will come fast
<saivann> NCommander : Can you re-upload a clean patch to bug 270200 ?
<ubottu> Launchpad bug 270200 in gnucash "Change libgoffice dependency from 0.4 to 0.6" [Undecided,New] https://launchpad.net/bugs/270200
<NCommander> saivann: sure, give me a moment
<saivann> NCommander : You original debdiff had unnecessary things in gnucash-2.2.6/po/POTFILES, please drop that
<saivann> NCommander : The debdiff will get uploaded more easily if it's 100% revelant ;)
<NCommander> saivann: :-P
<NCommander> I posted the debdiff against Debian
<saivann> NCommander : Thanks!! So we'll be able to sync again in the future, but from now on, I think that we'll simply update the ubuntu package
<NCommander> saivann: yeah, now tb just needs to upload
<NCommander> saivann: any other bugs you want me to close?
<saivann> NCommander : BTW, bug 269687 would really need some attention. Can you do something to improve this?
<ubottu> Launchpad bug 269687 in gtk+2.0 "Page Size greyed out in gtkprint applications." [Medium,Confirmed] https://launchpad.net/bugs/269687
<NCommander> saivann: er?
<saivann> NCommander : No, just close 270200 in your changelog
<NCommander> What do you want me to change?
<saivann> NCommander : I mean, is there something more you can do to help bug 269687 getting fixed?
<ubottu> Launchpad bug 269687 in gtk+2.0 "Page Size greyed out in gtkprint applications." [Medium,Confirmed] https://launchpad.net/bugs/269687
<mcasadevall> Sorry
<mcasadevall> Laptop chose a great time to decide to ignore its keyboard existed
<saivann> mcasadevall : :P
<saivann> mcasadevall : you're on intrepid?
<mcasadevall> yeah
<saivann> NCommander : Next time, perhaps you can try CTRL + ALT + F6 and CTRL + ALT + F7 to switch between consoles, that is a workaround in my case
<NCommander> didn't work
<saivann> NCommander : Ah
<saivann> NCommander : Well I was saying, is there something more you can do to help 269687 regression to be fixed? (debug information, patch, upstream contacts, etc)
<NCommander> I need to see if it happens in Debian
<NCommander> Which would be my first debugging stop
<NCommander> saivann: what was that bug number?
<saivann> NCommander : 269687 for gtkprint regression, 270200 for libgoffice 0.6
<saivann> NCommander : I only have a stable debian here, which does not use the good gtkprint version in gedit
 * NCommander nods
<saivann> NCommander : However, I have openSUSE here in VirtualBox and it has the same issue
<saivann> In gedit
<NCommander> Sounds like an upstream issue
<saivann> I'm updating openSUSE to see if the problem is fixed by any patch
<NCommander> saivann: very strange, I have to add libgtkhtml3.14 as a build-dep on Ubuntu, but on Debian, I don't O_o;
<saivann> NCommander: Really? If ./configure detects that libgtkhtml3.14 is available, it's probably that it has been installed as a dependency of another package, I guess
 * NCommander shrugs
<NCommander> gnucash likely hasn't been rebuilt since the gtkhtml changes
<NCommander> saivann: I'm just waiting for gnucash to finish building
 * NCommander doesn't like to upload debdiffs without testing building and installability
<saivann> NCommander : Great :) I also uploaded your changes to gnucash packaging team PPA, so it will be possible to test it before it gets accepted as a update
<slangasek> ... there's a gnucash packaging team now?
<NCommander> saivann: Er, shouldn't it just get uploaded, I thought bugfixs didn't need an Ack
<NCommander> and what slangasek said
<azeem> it's the BSG
<slangasek> azeem: <snort>
 * NCommander thinks of Battlestar Galatica
<NCommander> I think thats the sign I need sleep
<saivann> slangasek : Yes :) https://edge.launchpad.net/~gnucash
<slangasek> I don't think the Brotherhood of St. Gregory has a PPA
<slangasek> saivann: ...why?
<slangasek> given that gnucash is currently a sync from Debian...
<NCommander> slangasek: ask siretart, he made the team
<saivann> slangasek : Well, probably to help people working in team on gnucash
<saivann> slangasek : At this point of intrepid release cycle, do we need to do any special request to change libgoffice build-depends from 0.4 to 0.6?
<Mithrandir> slytherin: I haven't had the time lately, no
<NCommander> saivann: it clears a bug (a few of them), thats a bug fix I think
<saivann> NCommander : Of course, but it's also a migration, not only fixing bug
<slangasek> saivann: my opinion is that reorganizing package dependencies should have to go through the freeze process
<siretart> slangasek: yes, I created the gnucash team for mainly for having a PPA to provide test packages and backports.
<slangasek> siretart: ah, hmm
<siretart> slangasek: the main difference from the 'official' package was it enabled hbci, which until recently wasn't possible in ubuntu
<siretart> I wonder if ubuntu-dev should be a member of ~gnucash, so that all ubuntu devs can upload there
<NCommander> slangasek: OK, works for me, I'll write a feature freeze exception
<saivann> slangasek : I agree with siretart that it's a good idea to have a gnucash PPA, it's pretty useful sometime
<saivann> NCommander : Gnucash package is currently building here : deb http://ppa.launchpad.net/gnucash/ubuntu intrepid main , in case you want to add this as a reference in the Freeze Exception process
<NCommander> saivann: Its just a bug fix so you need to state which bugs it closes, any known regressions, and that I just wanted motu-release to approve it since its a dependency change
<NCommander> TheMuso: poke?
<saivann> NCommander : I think that the bug description already mention all that, anything missing in your opinion?
<NCommander> saivann: nope
<saivann> NCommander : Thanks for your work on this :)
<NCommander> -release is fun, only Scott isn't in Europe so whenever I need them, they're alseep or I am :-P
<NCommander> that is if I slept ;-)
<saivann> NCommander : Haha :P Yeah, I think we fell almost the same :)
<saivann> feel*
<NCommander> saivann: its sorta become a running joke on #ubuntu-motu that I simply don't sleep
<saivann> NCommander : :-D, Almost the same for me when I'm working on mozilla locales package, or Brother printer drivers packages :D
<saivann> NCommander : 269687 is reproducible on openSUSE with all updates, I guess we should report this upstream
<NCommander> works for me, but the bug is kinda vague
 * NCommander did the updates for Gnucash, you can have the fun of the upstream bug ;-)
<saivann> NCommander : No problem, thanks again :)
<mrooney> slangasek: james_w mentioned I might mention bug #231130 to you and kwii, it might save ~2MB on the ISO
<ubottu> Launchpad bug 231130 in ubuntu-wallpapers "simple-ubuntu.png is really elephant-skin.jpg and is toooo big (was converted from jpg to png)" [Low,Confirmed] https://launchpad.net/bugs/231130
<james_w> would running module-assistant at update-initramfs time be a really bad idea?
<james_w> someone that understands these things better than me may want to respond to bug 241053
<ubottu> Launchpad bug 241053 in loop-aes-utils "loop-aes module is not available when update-initramfs is run" [Undecided,New] https://launchpad.net/bugs/241053
<DaBonBon> hi. is there any chance that texlive 2008 will make it to intrepid now?
<DaBonBon> it's a significantly updated version, and if intrepid misses it, we won't have a new one for 6 months
<DaBonBon> and 6 months after that a new version will be released
<lukehasnoname> Is cdimage.ubuntu.com
<lukehasnoname> down
<lukehasnoname> eh
<mdz> lukehasnoname: it seems to be, yes
<lukehasnoname> it's back up for me
<lukehasnoname> heh
<mdz> there are multiple systems load balanced, it may be that one of them is down
<lukehasnoname> ah
<lukehasnoname> makes sense
<jdong> canonical may be having some flukes? Earlier this morning the forums were on-and-off with the frontend proxy throwing 503's
<mdz> I've filed an RT about cdimage
<lukehasnoname> I noticed that too. Is ubuntuforums hosted by Canonical?
<lukehasnoname> in other news, o3magazine.com is down as well, I think
<lukehasnoname> I'm going home, be back in a few
<TheMuso> NCommander: What can I do for you?
#ubuntu-devel 2009-09-07
<YokoZar> ArneGoetje: I'm worried about weird bugs from symlinking what was a .otf to a .ttf since .ttf is a subset.  Should I?
<literal> Please direct me elsewhere if I'm asking in the wrong place, but why doesn't the lib32asound2 package include a pulseaudio plugin? The libasound2-plugins package has it, and the descriptions for both packages are identical (they both mendion pulse).
<literal> This is causing skype to crash on login unless I remove pulseaudio from my system completely.
<literal> Running on 64bit karmic.
<TheMuso> literal: It has to do with the way the 32-bit packages like lib32asound2-plugins are built. A fix is coming, not for that package, but for another package that will provide the pulse plugin.
<literal> Ok, good to know.
<literal> Which package will provide it?
<literal> In the future, that is.
<TheMuso> literal: ia32-libs
<literal> ok
<TheMuso> c
<TheMuso> woops wrong tab
<dholbach> good morning
<jussi01> good morning dholbach
<dholbach> hiya jussi01
<dholbach> zul: can you take a loook at bug 378240?
<ubottu> Launchpad bug 378240 in xen-3.3 "Please merge xen-3.4 (3.4.0-2) from debian unstable" [Wishlist,Confirmed] https://launchpad.net/bugs/378240
<dholbach> can somebody please have a look at bug 414298?
<ubottu> Launchpad bug 414298 in devscripts "Please merge devscripts_2.10.53 from Debian unstable" [Undecided,Confirmed] https://launchpad.net/bugs/414298
<dholbach> i gave it an initial review already, but I'll feel better with another pair of eyes
<dholbach> it blocks bug 414471
<ubottu> Launchpad bug 414471 in git-buildpackage "Sync git-buildpackage 0.4.56 (universe) from Debian unstable (main). Note: this requires devscripts (>= 2.10.49). Hence, this request depends on LP #414298." [Wishlist,In progress] https://launchpad.net/bugs/414471
<dholbach> ogra: does bug 373100 look good to you?
<ubottu> Launchpad bug 373100 in thin-client-manager "Thin Client Manager shows nothing in 9.04" [Undecided,New] https://launchpad.net/bugs/373100
<dholbach> asac: how does bug 323752 look to you?
<ubottu> Launchpad bug 323752 in mobile-broadband-provider-info "Movistar (MÃ©xico) is missing" [Medium,In progress] https://launchpad.net/bugs/323752
<dholbach> bug 416933 too
<ubottu> Launchpad bug 416933 in mozzemberek "Sync mozzemberek 0.1.5-1 (universe) from Debian unstable (main)." [Wishlist,New] https://launchpad.net/bugs/416933
<Ryan52> geez dholbach, you get crazy amounts of stuff done :)
<Ryan52> even if indirectly by pinging others.
<dholbach> Ryan52: let's hope they get to it and do it :-)
<dholbach> just trying to clean up the sponsoring overview a bit for the release
<pitti> Good morning
<TheMuso> pitti: If you could get me that symaptic command-line for use in installing packages, hat would be useful, thanks.
<TheMuso> pitti: Or if you could tell me where to find it, thats fine too.
<pitti> oh, I thought I had it in jockey, but seems I'm using python-apt now
 * pitti grabs out of early history
<pitti> TheMuso: ah, there we go: http://bazaar.launchpad.net/%7Eubuntu-branches/ubuntu/hardy/restricted-manager/hardy/annotate/head%3A/RestrictedManager/RestrictedManagerGtk.py#L73
<pitti> TheMuso: the "self.gtk_idle()" is for showing a bouncing progress bar
<pitti> TheMuso: that's why I eventually replaced it with python-apt, then you get proper numerical progress
<TheMuso> pitti: hrm ok thanks.
<asac> dholbach: 416933 looks good. confirmed
<asac> dholbach: the other not. i commented and removed sponsors
<ogra> help ! why is my inbox being flooded with rosetta mail ?
<pecisk> is loosing icons of all main menu categories identional or could be a bug? (after upgrade) If first one, then it is worst decision ever made by gui guys :)
<pochu> pecisk: it's a design decision, but I think it's been reverted
<pecisk> I think is going from one extreme to another
<pecisk> it's
<pecisk> too much icons are burden for eyes, but also they help
<loic-m> Is the removal of the possibility to change the number of workspaces also a design decision?
<pecisk> loic-m, smells like bug
<pecisk> it just doesn't change value
<pecisk> it = dialog
<loic-m> What package is workspace-switcher in?
<pecisk> loic-m, gnome-applets?
<pecisk> not sure
<loic-m> nope, at least the files installed doesn't look like it
<pecisk> loic-m, or it could be gnome-panel
<seb128> loic-m, it's a known bug
<loic-m> Idoesn't appear to be it
<loic-m> seb128: started with Karmic Alpha 5 (different from the old bug)
<seb128> pecisk, it's not a decision made by us but by GNOME
<seb128> loic-m, what old bug?
<pecisk> seb128, ohhhh
<loic-m> Old bug was only the login at install could change the number of workspaces, no new user
<pecisk> seb128, hopefully it will be reverted in Ubuntu?
<seb128> pecisk, dunno yet, but I guess that will change before karmic
<pecisk> sight
<seb128> loic-m, dunno about this bug but the current one is a glade->gtkbuilder error
<loic-m> In Karmic Alpha 5, even the login used at install can't, because the number of column/rows is stuck to 0
<seb128> I expect it will be fixed today or tomorrow
<seb128> I never had the "old bug"
<loic-m> Wasn't a problem in Alpha 3
<loic-m> but fresh Alpha 5 install it's like that
<loic-m> ok, thanks
<loic-m> I'll use gconf in the meantime
<pecisk> Jesus Christ, all main menu icons are gone
<loic-m> seb128: at least without compiz, users added after install can't get more workspaces than 2 when right-clicking on workspace switcher. And AFAIR it's also the case with compiz light effect enabled
<seb128> loic-m, again that bug is well known and will be fixed today or tomorrow
<seb128> loic-m, no need to keep talking about it or describing it
<loic-m> s/light/normal
<loic-m> I can't help, I'm but a bot
<tseliot> pitti: is "nvidia-graphics-drivers-71" in karmic or has it been removed already? If it's still there, can you remove it, please?
<pitti> tseliot: still there
<pitti> tseliot: doesn't work with current x.org any more?
<tseliot> pitti: no, and Nvidia don't plan on fixing it any time soon
<tseliot> pitti: therefore its removal is the only solution
<pitti> tseliot: done
<tseliot> pitti: thanks a lot
<pitti> seb128: \o/ seems the retracers finally behave
<seb128> pitti, good job!
<pitti> weekend with wife away -> productive :)
<pitti> (but boring to the point when I start doing nasty things, like cleaning the flat and clearing out my lockers and desk..)
<seb128> lol
<mr_pouit> does someone know if the new gdm supports changing its background picture? (I'm able to change the logo using gconf, but not the background)
<seb128> mr_pouit, it uses the default system background image
<seb128> ie the same that you have a default wallpaper
<seb128> you can probably set the background image for the gdm user to change it
<mr_pouit> is it /desktop/gnome/background/picture_filename?
<mr_pouit> (because there is no background image at all here)
<seb128> mr_pouit, correct
<seb128> mr_pouit, weird, libgnome has a default value for that key
<mr_pouit> mmh
<mr_pouit> % gconftool-2 --owner gdm --get /desktop/gnome/background/picture_filename
<mr_pouit> /usr/share/xfce4/backdrops/xubuntu-jaunty.png
<mr_pouit> if this is correct, this is indeed weird, as I can't see it
<seb128> mr_pouit, well this key has a value for you apparently no?
<mr_pouit> seb128: yeah, but gdm doesn't display the image
<seb128> mr_pouit, I don't know then
<seb128> could be that it takes the default system value and not the gdm user one
<seb128> I've not really played with that yet
<james_w> anyone know if we are supposed to transition to the split zope.* packages from the zope3 package?
<wgrant> james_w: You will have to eventually. Has Debian decided yet?
<mr_pouit> ok, thanks anyway, I'll wait for an ubuntu theme that changes the background then :p
<james_w> wgrant: they are in the process
<james_w> wgrant: we have some packages synced, but they are still in universe
<wgrant> james_w: Ah, great.
<wgrant> james_w: Zope 3 has been split completely and renamed upstream, so we must follow.
<james_w> wgrant: sure, but I want to know if we are doing it for karmic
<geser> james_w: see bug #419262 and Debian already removed zope3 from unstable
<ubottu> Launchpad bug 419262 in zope3 "please remove zope3 from karmic" [Undecided,New] https://launchpad.net/bugs/419262
<james_w> geser: thanks
<james_w> geser: teach me for working on bugs before AA duties :-)
<al-maisan> wow! pulseaudio just had my CPU heat up to 93 degrees centigrade.
<al-maisan> .. and it usually never exceeds 70 degrees.
<pitti> !
<al-maisan> I did a 'sudo apt-get upgrade' this morning, followed by a reboot. At some point pulseaudio crashed but I was working and too busy to notice until I saw the CPU temperature value :/
<Laney> pulseaudio: Keeping you warm in Winter
<al-maisan> yeah :)
<soren> cjwatson: So, apparantly, I forgot to bzr push after my most recent Eucalyptus upload. Is there a trick to fix this (since both you and Dustin have pushed to the branch since then) or do I just merge your changes and then push?
<cjwatson> soren: did you at least commit and tag locally?
<soren> cjwatson: Alternatively, I could grab the branch currently on Launchpad and merge my commit into that one.
<soren> cjwatson: I did, yes.
<cjwatson> soren: then merge and push, it doesn't much matter which way round
<cjwatson> soren: I strongly recommend using a bound branch ('bzr help bind') to avoid this problem in future
<elmo> what's the process for requesting a change in component these days?  it was originally meant ot be part of the sync of rancid, but got missed
<soren> cjwatson: It used to be bound, but that blew up in my face when the two of us where both committing a lot at the same time. I'll bind it again now that things are calmer.
<cjwatson> soren: blew up how?
<soren> cjwatson: I
<cjwatson> mostly the explosions that happen with bound branches are explosions you want
<cjwatson> i.e. "somebody else just committed, you need to update before you can commit"
<soren> I just got annoyed by not being able to commit anything locally, because every time I tried, you had updated something, I'd fix the conflicts, commit again, and you had made another commit. I just couldn't keep up. I unbound the branch so that I could get something done and then I dealt with it afterwards.
<pitti> soren: bzr rebase FTW :)
<soren> pitti: I
<soren> m not proud of it, but that's essentially what I ended up doing by hand.
<soren> :)
<pitti> rebase works quite well for such situations IMHO (but merging should just do as well, but leaves some litter in the history)
<soren> rebase isn't that horrible if you're only dealing with your own patches. I don't like it if other people's patches are involved.
<soren> Merges clearly show the context in which someone committed and tested their code. Reapplying their patches in a completely different point in history may have unwanted sideeffects, and it looks like the original committer's fault.
<pitti> elmo: change component> if it's universe->main, subscribe ubuntu-mir to the bug, otherwise ubuntu-archive
<cjwatson> mvo: did you have a chance to look at bug 387112 and figure out how we might resolve this? I've committed the debconf change but as mentioned in a comment it won't actually help *this* upgrade
<ubottu> Launchpad bug 387112 in debconf "package cups-pdf 2.4.6-4ubuntu2 failed to install/upgrade: " [Undecided,Confirmed] https://launchpad.net/bugs/387112
<elmo> pitti: reopen the old sync bug?
<elmo> pitti: or open a new one?
<pitti> elmo: reopening will do
<al-maisan> Oh no, there we go again, pulseaudio trying to convert my laptop in a space heater :/
<mvo> cjwatson: no, sorry. I have a look now
<al-maisan> How does one debug a problem like this?
<pitti> al-maisan: it takes 100% CPU?
<pitti> al-maisan: usually, I'd run it in foreground mode with --debug (or --verbose or something like this) and see if it's looping on something
<al-maisan> pitti: yes, I attached strace to it but it just sits there..
<pitti> al-maisan: if that doesn't help, attach strace to it and see what it's failing on
<pitti> al-maisan: ah, so it uses 100% CPU, but strace doesn't show anything?
<al-maisan> pitti: yes
<pitti> that shows that it's busy wit calculations
<al-maisan> apparently
<pitti> al-maisan: so foreground/debugging would be my next step, and then installing -dbgsym and attaching gdb, to see what it's looping on
<al-maisan> pitti: OK .. thanks!
<pitti> speaking of debugging, /me dives deeper into gdm
<pitti> gdm is a hilarious pile of indirected and abstracted indirection abstractions *sigh*
<al-maisan> pitti: I don't envy you :P
<pitti> al-maisan: likewise, though :)
<al-maisan> :)
<mvo> cjwatson: we could patch the old debconf to remove the use statement when the upgrade starts - what do you think?
<cjwatson> mvo: sounds workable
<cjwatson> (horrible, but workable)
<mvo> ok, I assign it to me then
 * drhorrible mvo
<cjwatson> michael vogt's sing-a-long upgrader
<mvo> lol
<TheMuso> If a ports kernel with a new ABI number FTBFS, plesae don't NBS the older kernel out of the archive till the newer one is available.
<TomaszD> slangasek, hey, thanks for helping out, here's another curious case https://bugs.launchpad.net/ubuntu/+source/nautilus-share/+bug/425677
<ubottu> Ubuntu bug 425677 in nautilus-share "nautilus-share appears not to be using any translations at all" [Undecided,New]
<hyperair> hmmm? nautilus-share?
<hyperair> not using translations eh..
<TomaszD> yep
<hyperair> this is a curious case.
<hyperair> are you sure about this?
<TomaszD> well, I have fully updated karmic in vbox with all the langpacks applied
<TomaszD> and it's in English
<hyperair> find /usr/share/locale -name 'nautilus-share*'
<hyperair> try running that
<TomaszD> no result
<hyperair> then you don't have it installed
<TomaszD> how come I can see the window then, in English
<TomaszD> when I try to share a folder
<hyperair> i meant that you don't have the nautilus-share translations installed
<TomaszD> oh, well, yes.
<TomaszD> that's a bug then.
<hyperair> so it's not nautilus-share's bug
<Laney> http://packages.ubuntu.com/search?searchon=contents&keywords=nautilus-share&mode=filename&suite=karmic&arch=any
<hyperair> i'm not sure which package's involved though
<hyperair> ah.
<hyperair> the langpack-gnome-XX-base packages.
<hyperair> TomaszD: please try installing the said package and trying again.
<TomaszD> it's already installed
<seb128> $ dlocate nautilus-share.mo
<seb128> language-pack-gnome-de-base: /usr/share/locale-langpack/de/LC_MESSAGES/nautilus-share.mo
<seb128> ...
<seb128> what locale do you use?
<TomaszD> pl
<TomaszD> (pl_PL)
<hyperair> TomaszD: http://packages.ubuntu.com/karmic/language-pack-gnome-pl-base
<seb128> in fact translations are installed
<seb128> nautilus-share probably doesn't init the gettext domain correctly
<TomaszD> yes they are, I'm suspecting a bug in n-s
<TomaszD> right, something like that
<hyperair> hmm
<hyperair> wrong directory.
<hyperair> i believe it looks in /usr/share/locale
<seb128> no, that's the the upstream dir
<seb128> we strip those and install langpacks in locale-langpack
<seb128> to avoid conflicts
<hyperair> doesn't the path need to be updated?
<seb128> the translations are found since the context menu entry is translated
<seb128> but the tab is all english
<hyperair> hmm, is that so?
<hyperair> wait
<hyperair> tab?
<TomaszD> the dialog window
<seb128> the nautilus preferences tab
<hyperair> okay which parts are not translated exactly?
<seb128> the nautilus tab
<hyperair> is that all?
<hyperair> what about the stuff inside it
<seb128> and the dialog
<hyperair> hmm
<seb128> only the context menu entry is translated
<hyperair> i see.
<hyperair> this probably came from the glade->gtkbuilder transition
<seb128> when clicking "share this folder" the dialog is translated
<hyperair> eh?
<TomaszD> huh
<hyperair> okay, that is strange.
<hyperair> ery strange
<hyperair> the gettext domain is bound when nautilus_module_initialize is called
<hyperair> if the preferences dialog didn't get translated, the standalone dialog shouldn't either.
<TomaszD> it doesn't get translated either way for me
<seb128> it's not
<seb128> only the context menu item is translated
<seb128> and the dialog asking if you want to install samba
<TomaszD> this dialog about samba is actually translated, but I don't it's a part of nautilus-share
<hyperair> it is part of nautilus-share.
<TomaszD> ohh kay :)
<hyperair> this sounds like the other translation issue i had with the standalone window
<TomaszD> alright guys I'm way over my head with this, getting back to translating GNOME, the deadline is approaching fast
<hyperair> mm have fun
<TomaszD> by the way, policykit-gnome has an outdated translation template in launchpad, thus making it impossible to translate properly, I'm gonna report this in a moment
<hyperair> seb128: do i need to call gtk_builder_set_translation_domain?
<hyperair> hmm i'll try that and see what happens. TomaszD: could you test a patch when i upload it to a PPA later?
<TomaszD> hyperair, sure, as long as info lands in my mailbox or someone calls me out here, I'll make some time to test it
<TomaszD> I'll be here all day, GNOME is a huge project...
<hyperair> TomaszD: thanks
<hyperair> =)
<hyperair> i'll be done in less than half
<seb128> hyperair, you don't if it uses the standard domain for the software but it might be required in the nautilus case to set it again
<hyperair> alright, i'll do that then
<hyperair> seb128: basically just after gtk_builder_add_from_file right?
<seb128> hyperair, yes
<seb128> trying
<hyperair> i have no useful locales to test
<hyperair> my, my.. what's eating the buildds?
<TomaszD> well that's scary, my karmic install just died.
<hyperair> O_O
<hyperair> sounds fun
<pitti> hyperair: https://launchpad.net/builders/
<hyperair> that's a lot of waiting builds
<TomaszD> http://imgur.com/OoLh9.png
<TomaszD> I just rebooted normally :(
<hyperair> sounds like you screwed over your system clock nicely =)
<hyperair> set it right and you're good to go =D
<TomaszD> I have touched nothing
<hyperair> or wait half an hour
<TomaszD> fsck fixed it, but I doubt it was my fault there
<hyperair> well something changed your system clock
<davmor2> TomaszD: It's known bug
<hyperair> oh O_o
<TomaszD> ah, good to know.
<hyperair> say, will there be a gnome-shell ppa?
<hyperair> or at least something with the latest unstable?
<seb128> hyperair, universe
<hyperair> seb128: that's got .0. now is .2
<hyperair> and of course, we can't get anything new in since featurefreeze is on
<hyperair> unless gnome-shell gets an exception?
<seb128> hyperair, right, some people have been on vac in august
<hyperair> ah
<seb128> hyperair, and required build-depends just got updated this weekened
<seb128> hyperair, GNOME has a standing exception
<hyperair> ah i see
<hyperair> what are the conditions?
<seb128> ?
<hyperair> nevermind
<seb128> GNOME has an exception that's it ...
<hyperair> i see
<seb128> that's this way since warty
<hyperair> how come, though?
<hyperair> out of curiosity
<seb128> we trust GNOME schedule to enforce freezes, respect timelines, etc
<hyperair> aah
<seb128> gnome-shell is a bit of a special case but that's a technology preview and we said we would track GNOME3 components too
<hyperair> special case meaning frozen or not frozen?
<seb128> we will do the updates
<hyperair> ah
<seb128> it's a special case for GNOME since they don't follow freezes etc
<seb128> so technically we could not grant exception for that one
<seb128> but as we said we would track GNOME3 updates
<seb128> geser, thanks for the empathy fix, don't forget to subscribe the sponsor team though when you have something that needs to be uploaded
<hyperair> ah
<geser> seb128: I usually do that but wasn't sure if subscribing ubuntu-main-sponsors is right here as the sponsor should ideally also be able to commit the changes to the ubuntu-desktop bzr (or can all core-dev commit there?)
<seb128> geser, anybody who can upload can commit there
<geser> thanks, will remember that
<TomaszD> any gnome-settings-daemon wizards around? What is this "Share Folder" string in the template, where in the UI is that used? isn't it redundant, with nautilus-share?
<TomaszD> sorry, that was meant for #ubuntu-translations
<TomaszD> *translators
<seb128> TomaszD, there is no such string in the source
<TomaszD> oh crap, I meant gnome-system-tools, sorry!
<fagan> Hey, im trying to run gnome-zeitgeist in karmic and I get this error http://pastebin.ubuntu.com/266684/  it works fine in jaunty.
<fagan> Anyone have a clue what needs to be changed to fix it ?
<fagan> bzr branch lp:~gnome-zeitgeist/gnome-zeitgeist/new-interface is the code thats failing
<fagan> Hmmm this question is kinda borderline for this channel I suppose but all im really asking is what changed in python or maybe pygtk since jaunty
<Turl> fta: hi, may I PM you?
<hyperair> TomaszD: https://launchpad.net/~hyperair/+archive/bugfixes <-- grab the nautilus-share deb from here and install it.
<TomaszD> hyperair, right, one moment
<TomaszD> hyperair, no change, logged out and back again to be sure, but no change
<hyperair> hrm damnit
<hyperair> seb128: is this some bug in gtkbuilder?
<seb128> I doubt it
<seb128> it could be nautilus which reset the domain or something
<hyperair> hmm
<hyperair> that's painful
<seb128> it's a small bug I would not say that
<hyperair> which means digging needs to be done in nautilus code
<hyperair> how painful
<hyperair> actually i'm very tempted to just rewrite the entire thing to not use gtkbuilder at all
<seb128> I doubt it's a nautilus bug, the totem tab is correctly translated
<hyperair> hmm seriously?
<seb128> yes
<hyperair> question. is totem's done using gtkbuilder?
<hyperair> or manually constructed
<seb128> dunno
<hyperair> hmm strings seems to show properties.ui and fullscreen.ui.
<hyperair> but dpkg -L doesn't show
<Keybuk> kees: around?
<kees> Keybuk: a bit; on my android, on holiday. sup?
<seb128> totem-common: /usr/share/totem/properties.ui
<seb128> seems it's using gtkbuilder
<Keybuk> kees: have a binary I wanted you to run, and supply the output of
<Keybuk> in a "who do I know who loves to have a difficult filesystem setup" kind of way :p
<kees> heh, sure. what is it?
<elmo> a r00tkit
<Keybuk> kees: it's the udev/upstarty mount thing
<pitti> heh, it works for kees â it must work for everyone?
<Keybuk> pitti: exactly ;)
<pitti> I bet it breaks single-partition, no-raid, no-lvm, no-crypto default ext4 :-)
<kees> if i don't have to reboot, i can do it now. otherwise i can run it when i get home tonight
<Keybuk> kees: you don't have to reboot
<Keybuk> kees: amd64 or i386 ?
<kees> Keybuk: amd64
<Keybuk> ok, two seconds
 * kees waits for customized rootkit
<cjwatson> "here's the source, but you need to use the gcc from this PPA"
<Keybuk> http://people.canonical.com/~scott/mountall
<Keybuk> run as
<Keybuk> sudo ./mountall --debug --tmptime=infinity
<Keybuk> and capture the output (tee would be good to use)
<Keybuk> it'll almost certainly pause
<Keybuk> at which point, run udev udevadm trigger --subsystem-match=block from another window
<Keybuk> if you have NFS mounts, etc. it'll still pause, so run killall -USR1 mountall
<Keybuk> it should eventually declare "finished"
<kees> heh
<Keybuk> (this should all be perfectly safe)
<Keybuk> I'd like the debug output ;)
<ion> keybuk: Mind sharing the sauce?
<Keybuk> ion: it's in the Upstart package in the ubuntu-boot PPA
<ion> Thanks
<pitti> ion: what do you believe we are, free software or what?
<kees> Keybuk: one moment...
<pitti> ion: you have a complex setup, too?
<ion> pitti: On my server, i have lvm over md. Nothing more complex than that.
<pitti> ion: still, good test case probably :)
<davmor2> Keybuk: how complicated would you like a setup and in what arch i'll let you have ssh access to a box you can break ;)
<Keybuk> in theory, there should be no setup that this doesn't work on
<Keybuk> I've tested it in the most arbitrarily complex setups that don't even work right now
<RainCT> oops - can some archive admin please reject   gnome-voice-control - 0.4-0~ppa3?
<Keybuk> so LVM-over-RAID-over-two-loop-devices-one-on-a-USB-key-one-on-NFS works
<cjwatson> Keybuk: have you tried wubi?
<Keybuk> and swap on that works too
<pitti> RainCT: sorry, that doesn't work
<cjwatson> that adds the extra constraint of one of the bits being implemented using FUSE
<Keybuk> cjwatson: I'm not sure that wubi makes any difference, unless it needs special handling during boot (of which there is none in the current scripts ;)
<pitti> RainCT: uploads are accepted straight into soyuz, they don't need to wait for a publisher in the "ACCEPTED" queue any more nowadays
<RainCT> Oh. Well, it'll FTBFS anyway.
<cjwatson> Keybuk: I thought there was code to shove the fuse process into omitpids
<cjwatson> maybe that's later
<cjwatson> Keybuk: there's definitely magic in the initramfs
<Keybuk> cjwatson: right, this replaces the bits in rcS only
<cjwatson> ah, ok
<pitti> RainCT: do you plan to upload it to karmic?
<cjwatson> you might have to care when you do umountall :-)
<Keybuk> cjwatson: indeed ;)
<pitti> RainCT: I stopped the upload cronjob for now, so we have some minutes to consider
<cjwatson> pitti: in theory, if we get into the right five-minute window, we can rm it from ~lp_queue
<RainCT> pitti: Yes, I plan to get a FFe for it within the next days (but it still needs some testing, I'm getting crashes here).
<pitti> cjwatson: right, that's why I just stopped the process-upload.py cron
<RainCT> (The "Accepted" mail was already send some minutes ago though. I didn't notice it until it closed the related bugs.)
<pitti> ah, too late then, I think
 * ion added the ubuntu-boot PPA to sources.list.d and now runs safe-upgrade. Letâs see whether iâll still come online after the reboot. :-P
<pitti> I see it in the queue, but I don't want to mess with that
<Keybuk> ion: DON'T
<Keybuk> STOP!
<ion> Hah, ok
<cjwatson> that good?
<Keybuk> there's one or two key bits missing ;)
<Keybuk> if this works, then I'll put those in
<Keybuk> *then* people can test
<Keybuk> but right now, it won't boot
<pitti> cjwatson: you removed it from ./accepted/upload-20090907-162446-001727/ ? or what do you mean
<RainCT> pitti: Oh well, thanks anyway. I'll fix it within the next days (or worst case upload a "really" package with the old version)
<cjwatson> pitti: no, I didn't touch anything
<Keybuk> kees: any luck?
<cjwatson> pitti: if it's been accepted, there's not much sane we can do - build records have already been created
<pitti> cjwatson: ah, "that good" referred to Keybuk's OMGNOO! :)
<cjwatson> yeah
<kees> Keybuk: yup, ran fine
<Keybuk> kees: got the output?
<kees> Keybuk: yup, sending you email (typing is slow on this tiny keyboard :) )
<Keybuk> np
<Keybuk> great
<ion> /* FIXME look up underlying device
<ion> I could contribute some âlook up underlying deviceâ code, since i already have a sh prototype somewhere. :-P
<kees> Keybuk: ok, sent
<Keybuk> ion: I was hoping you would
<Keybuk> I left that out precisely because you said you were working on it <g>
<ion> Hehe
<Keybuk> kees: How Many Disks ?!
<kees> physically or logically?
<Keybuk> see, this is why I use you as a test case ;-)
<kees> hehe
<kees> it seems like it did the right thing with the fuse mounts, the autofs mounts and the unmounted lv chroots
<cjwatson> come on, show the rest of us
<Keybuk> yeah it should
<Keybuk> kees: did it mount the unmounted things?
<Keybuk> to me it looks like it left your system in the right state
<Keybuk> cjwatson: lol, debug output of a tool is very uninteresting ;)
<kees> Keybuk: no, i think it didn't change any mounts
<cjwatson> oh I dunno, d-i's debug output has been very interesting in the past, e.g. http://www.ubuntu.com/usn/usn-262-1 ;-)
<cody-somerville> cjwatson, Keybuk: http://www.ubuntu.com/community/processes/newdev seems to say that two people from the community council or just folks who are administrators of the ubuntu-dev team can approve developer applications. I've never heard of that before... does that page need updating?
<cjwatson> cody-somerville: mm, that whole page looks a bit out of date
<cjwatson> it would probably be better to turn most of it into wiki references
<ScottK> james_w: Since today is a holiday in the US (so I assume slangasek is off today) I'd appreciate it if you'd put your archive admin hat back on and look at 425775.
<cjwatson> I don't recall that two-community-council-members rule
<Keybuk> right, the CC can't approve ubuntu developer membership
<Keybuk> (they don't even have the requisite LP powers)
<cjwatson> administrators of the ubuntu-dev team => techboard (well, nowadays, developer-membership-board)
<kees> cjwatson: people.canonical.com/~kees/mountall.debug if you really want to see it :)
<cody-somerville> Is the only needing two people from the TB also incorrect?
<ScottK> james_w: It should help with some armel build failures.
<cjwatson> that's disappointingly fewer than I expected :)
<cjwatson> cody-somerville: a work of fiction, as far as I can tell. https://wiki.ubuntu.com/UbuntuDevelopers is more accurate
<elmo> Keybuk: wanna bet? ;-)
<cjwatson> elmo: not all of them have the requisite LP powers. :-)
<cody-somerville> lol
<Keybuk> elmo: duckie abuse doesn't count ;)
<ion> keybuk: This might be a stupid idea, but how about adding a char **locks parameter to spawn, and having it open the given /var/lock files and flock them with LOCK_EX after fork and before exec? When fsck is spawned, e.g. {"/var/lock/mountall-fsck-sda", "/var/lock/mountall-fsck-sdb", NULL} would be passed as the parameter if sda and sdb are determined to be the physical devices.
<Keybuk> ion: you'd need to clean them up as well
<ion> Ok, if a few zero-byte files in tmpfs is a big deal. :-)
<Keybuk> things should be clean ;)
<ion> Heh
<ion> keybuk: Oh, btw, mountall requests an ecryptfs passphrase from the user. I have an ecryptfs mounted at ~/Private.
<Keybuk> ion: ?
<Keybuk> you mean mount does?
<ion> Yeah
<Keybuk> have you got --debug output, not sure why it would have run mount for you
<ion> keybuk: http://pastebin.com/f7963f585
<ScottK> james_w: Thanks.
<Keybuk> ion: err, that looks like an ecryptfs bug!
<ion> keybuk: How about creating the directory /var/lock/mountall on startup and recursively deleting it before exiting? An internal queue still a better idea?
<Keybuk> ion: it's asking for a passphrase even when called with -f (fake. ie. add to mtab)
<ion> Ok
<Keybuk> ion: only if you can figure out the sequencing to make sure /var/lock is mounted before any disk is checked :p
<ion> Ah, good point :-P
<Keybuk> I suspect that dir-o-locks is not going to work
<hyperair> TomaszD: could you check something -- does it matter whether you open the standalone window or the properties window first?
<TomaszD> hyperair, doesn't matter
<hyperair> hmm.
<hyperair> what about if both are open?
<TomaszD> tried that just now, no change
<hyperair> basically the standalone window is translated but the properties window isn't eh..
<TomaszD> no here, I can give you a screenshot if you don't believe me ;)
<TomaszD> *not here
<hyperair> hmm a screenshot might be nice, but i believe you =)
<TomaszD> hyperair, http://imgur.com/1bBf2.png
<hyperair> ooh gnome shell
<hyperair> wait a sec
<hyperair> the entire standalone window isn't translated either!
<hyperair> seb128: i thought you said the standalone window was translated!
<TomaszD> don't mind the tacky theme, I'm just messing, this is a test install ;)
<seb128> no, I said that nothing out of the context menu item and the "do you want to install samba" was translated
<hyperair> ah.
<hyperair> whoops
<hyperair> TomaszD: could you try downgrading to nautilus-share 0.7.2-9 and seeing if you see the issue?
<hyperair> that's pre-glade-to-gtkbuilder transition
<TomaszD> hyperair, where do I get the old deb package?
<hyperair> TomaszD: which architecture are you using?
<TomaszD> i386
<dpm> hyperair: I can also reproduce this. Did the translation domain remain the same in the transition to gtkbuilder?
<hyperair> dpm: yes it did. but i didn't touch the .po files while converting the .glade to .ui
<hyperair> TomaszD: https://launchpad.net/ubuntu/+source/nautilus-share/0.7.2-9/+build/1089292
<TomaszD> oh crap
<TomaszD> gdebi-gtk has the same exact issue
<hyperair> ?
<TomaszD> I just noticed that now while installing nautilus-share
<TomaszD> it's not translated
<TomaszD> I mean, partially it is
<hyperair> hmm
<TomaszD> I'll go check if that's my lang's problem, but nothing in the UI changed
<TomaszD> hyperair, I can confirm that the downgraded version has no issues with the translation whatsoever
<hyperair> TomaszD: aha. okay, thanks for confirming. i'll work on fixing it then
<TomaszD> yep, I checked, gdebi's translation is also broken
 * hyperair doesn't handle gdebi
<mdz> The following NEW packages will be installed:
<mdz>   grub
<mdz> that doesn't seem right
<ScottK> Would some archive admin with shell acess (maybe james_w) please move mgltools-gle from Universe to Multiverse?  It's got a not-for-commercial-use license so it got accepted in the wrong pocket by mistake.
<james_w> ScottK: would you file a bug for reference please?
<ScottK> james_w: Sure.
<james_w> ScottK: what's the not-for-commercial-use clause?
<ScottK> james_w:   1. Grant Of Limited License; Software Use Restrictions. The programs received by you will be used only for NON COMMERCIAL purposes. This license is issued to you as an individual.
<ScottK> james_w: Bug #425818
<james_w> I don't see that in the copyright file
<ubottu> Launchpad bug 425818 in mgltools-gle "Please move mgltools-gle to Multiverse" [High,New] https://launchpad.net/bugs/425818
<ScottK> It's in the LICENSE file in the source package.
<james_w> ok
<hyperair> TomaszD: i noticed you've got commit access to nautilus-share's git repository. do me a favour and change the line "interfaces/share-dialog.glade.in" to "[type: gettext/glade]interfaces/share-dialog.glade.in"
<m3F> About sound in Karmic: when i try to play sound with Nautilus putting my mouse over the sound file i succeed. But when i try to pley music with Listen/Rythmbox i always fail and players brake out Pulse in the process. An automatic bug report was sent from my Ubuntu Karmic instalation. My sound card is Creative Audigy SE. I used to have problems with this card in Ubuntu Hardy and before it. But with Ubnut Jaunty all was good. Now problems are back wit
<m3F> h Karmic (i know it is in alpha, i am just reporting the bug). Even the annoying sounds are back (annoying noises when sounds start and end).
<james_w> moved in karmic
<james_w> can we move in released versions?
<ScottK> james_w: Thanks.  We can.  Let me double check that version.
<hyperair> TomaszD: that should fix it upstream. now i need to get the patch downstream =)
<TomaszD> hyperair, are you sure? :>
<TomaszD> about this fix
<hyperair> TomaszD: almost completely sure. test build it and check? =)
<TomaszD> oh boy
<hyperair> haha
<TomaszD> I'm gonna include you as the author of the commit :P
<TomaszD> one moment
<hyperair> no problem
<hyperair> oh yeah, you might like to refresh all the .po files as well
<hyperair> remove the nautilus-share.pot, and run make update-po inside the po directory
<ScottK> james_w: It applies to Jaunty too.
<james_w> ok, thanks
<TomaszD> hyperair, and commit all those as well or just for my local build?
<hyperair> TomaszD: commit *.po, and POTFILES.in but not nautilus-share.pot or POTFILES
<TomaszD> alright
<james_w> ScottK: did you file in Debian?
<ScottK> james_w: Not yet.
<james_w> ok, thanks for catching this
<TomaszD> wait a moment hyperair, where should I find this line?
<hyperair> TomaszD: po/POTFILES.in
<TomaszD> ah, of course..
<hyperair> TomaszD: intltool doesn't detect *.ui files as translatable, so if you run make update-po, all the strings get commented out
<hyperair> TomaszD: that's why the [type: gettext/glade] needs to be set
<TomaszD> hyperair, the line you talk about reads [type: gettext/glade]interfaces/share-dialog.ui
<hyperair> TomaszD: it does? already?
<TomaszD> yes, no "glade" part though
<TomaszD> in the name
<hyperair> ah.
<hyperair> let's see..
<hyperair> it is gettext/glade isn't it?
<hyperair> -interfaces/share-dialog.ui
<hyperair> +[type: gettext/glade]interfaces/share-dialog.ui
<hyperair> well that's done then
<hyperair> hah
<hyperair> ..i'm beginning to really regret patching configure and Makefile.in
<TomaszD> hyperair, so I don't have to touch anything then?
<hyperair> nothing =)
<TomaszD> *phew*
<hyperair> haha =)
<hyperair> i should probably poke federico for a new upstream release
<hyperair> there's been loads of translation changes
<hyperair> it'll also allow me to drop my crazy long series of patches
<TomaszD> good idea
<hyperair> there's also 10 odd bugfixes i submitted when i took over this package =\
<ScottK> james_w: I'll also upload a fixed debian/copyright for Karmic (and file a bug with Debian).
<blue0488> how is this alpha?
<arand> alpha-ish
<hyperair> well well. i thought 1 hour was bad for waiting time, but 8 hours?
 * hyperair sighs
<hyperair> TomaszD: https://launchpad.net/~hyperair/+archive/bugfixes/+build/1207117 <-- if you're around when this finishes, please test =)
<TomaszD> ETA: 9hrs
<TomaszD> if I'm awake in 9hrs, I'll be a dead man
<hyperair> ;-)
<hyperair> another time then.
<hyperair> TomaszD: would you trust me enough to use a deb i compiled on my machine? (i'm lazy to wait for the buildds to finish)
<TomaszD> hyperair, I have no trust issues... not in an isolated testing virtual machine :)
<hyperair> ahaha
<hyperair> okay then =)
 * hyperair starts pbuilder-karmic-i386
<Laney> It takes about 20 seconds from "GRUB loading" to the menu appearing
<Laney> is that normal?
<hyperair> TomaszD: http://dl.getdropbox.com/u/169656/nautilus-share_0.7.2-11ubuntu1%7Ehyper2_i386.deb
<hyperair> Laney: no
<sebner> Laney: not really but I didn't install the latest update from today yet
<Laney> not today
<Laney> it's been like that for ages
<Laney> since grub 2
<sebner> Laney: takes 2-3 seconds here
<hyperair> same
<TomaszD> hyperair, back to square one :(
<hyperair> =(
<hyperair> TomaszD: could you temporarily move the nautilus-share.mo files from /usr/share/locale-langpack elsewhere?
<Laney> hyperair: can't you test by launching with LANG set to something else?
<hyperair> hmm
<hyperair> good point eh
<hyperair> let's see if that works..
<TomaszD> I thought you didn't want to have to install new langpacks
<TomaszD> otherwise, just use LANG, yes
<hyperair> well.. the package i've created isn't stripped of .mo files
<hyperair> unlike the nautilus-share package in ubuntu
<TomaszD> ah, true
<hyperair> now then, what was your LANG set to again?
<cjwatson> Laney: you're not the only person who's reported it, but neither I nor anyone else has managed to track it down yet
<cjwatson> Laney: try 'set debug=disk' at the top of /boot/grub/grub.cfg and you might be able to see which disk it's probing (or 'set debug=all' if you want everything, but that might scroll by rather fast)
<hyperair> how does one decompile a .mo?
<seb128> you can run msgunfmt on it
<hyperair> hmm it seems that gtk_builder_set_translation_domain needs to be set *before* add_blah_blahh..
<hyperair> but still it's pretty strange why it didn't work before..
<hyperair> hmm
<hyperair> maybe it's --as-needed?
<hyperair> no wait, can't be either
<hyperair> ah totem also uses the set_translation_domain trick
<hyperair> TomaszD: http://dl.getdropbox.com/u/169656/nautilus-share_0.7.2-11ubuntu1%7Ehyper3_i386.deb
<hyperair> this one works on my system using pl_PL.UTF-8
<TomaszD> hyperair, almost! the "Create Share" button is left untranslated
<hyperair> !! WHAT
<ubottu> I am only a bot, please don't think I'm intelligent.
<c_korn> lol :)
<hyperair> TomaszD: that's another bug. but thanks for pointing it out =O
<hyperair> it's supposed to be Create _Share, but i patched it into Create Share
<hyperair> whoops..
<hyperair> TomaszD: http://dl.getdropbox.com/u/169656/nautilus-share_0.7.2-11ubuntu1%7Ehyper4_i386.deb
<TomaszD> take 4...
<hyperair> hehe
<TomaszD> aaand cut
<TomaszD> good job everyone, great acting hyperair, 100% correct
<hyperair> woo
<TomaszD> and now I finally see where do I have to fix those accelerator conflicts
<hyperair> =O
 * hyperair falls asleep on keyboard
<ulaas> exit
<ulaas> quit
<ulaas__> help
<ulaas__> learning irssi :) sorry
<RainCT> seb128: Hey, can you please also ack bug 303628?
<ubottu> Launchpad bug 303628 in gnome-voice-control "[Karmic FFe] Update gnome-voice-control package to version 0.4" [Undecided,In progress] https://launchpad.net/bugs/303628
<seb128> RainCT, seems fine to me feel free to upload
<RainCT> seb128: Thanks :)
#ubuntu-devel 2009-09-08
<blue0488> how do you get freenode chat in empathy?
<TheMuso> pitti: Thanks for that synaptic invocation code, however I am dealing with C++ which means I will have to do a little more fiddling to get the same functionality, and since its a universe package, I am more enclined to simply disable the install functionality of paprefs.
<trip0> how does xsplash work?
<trip0> does it require gdm?
<TheMuso> trip0: Gdm loads xsplash via dbus when gdm starts, then the session script loads xsplash when the user logs in using gdm.
<TheMuso> trip0: I think thats how it works anyway.
<trip0> TheMuso: so [login-manager] needs to start xsplash via dbus
<trip0> is xsplash a deamon or somthing?
<trip0> daemon*
<TheMuso> trip0: Not sure. I think gnome-session signals it to be killed over dbus though.
<ion> keybuk: Hereâs an untested implementation. It probably breaks your system and leaks memory, but itâs a start. Hey, at least it compiles without warnings. :-P http://heh.fi/patches/mountall/
<ion> keybuk: Iâll have a better capability to test mountall patches as soon as i can get my system to run *some* version of mountall. ;-)
<ion> keybuk: As in, boot using it
<dholbach> good morning
 * slangasek waves
<dholbach> hiya slangasek
<liw> hello, mister Holbach, mister Langasek
<dholbach> SeÃ±or Wirzenius?
<dholbach> Como estas? :)
<liw> que? :)
 * poningru provides a flower for dholbach to wear
<poolie> could i get some ubuntu python maintainers to look at bug 392355?
<ubottu> Launchpad bug 392355 in bzr "C extensions placed in wrong directory on karmic" [High,Confirmed] https://launchpad.net/bugs/392355
<poolie> it seems to fairly seriously break programs that build compiled extensions on karmic
 * YokoZar has been waiting for python2.6 binary to be in sync with source package version so he can update ia32-libs all day now...
<dholbach> https://edge.launchpad.net/ubuntu/+source/python2.6/2.6.2-0ubuntu4/+build/1188649
<dholbach> Missing build dependencies: libreadline6-dev
<dholbach> YokoZar: ^
<YokoZar> Hmm yeah...should that take all day?
<YokoZar> Since the depend needs to finish first
<dholbach> the build depends is missing
<YokoZar> Does that mean the build depends is being rebuilt?
<dholbach> aha
<dholbach> https://edge.launchpad.net/ubuntu/+source/readline6
<dholbach> it's in universe
<dholbach> python2.6 is obviously in main
<dholbach> not sure that requires a MIR
<dholbach> but it's something the archive admins should look into
<pitti> Good morning
<dholbach> hopefully we won't have 2 readline versions in main for karmic
<dholbach> hi pitti
<pitti> TheMuso: OOI, how is it harder in C++? Anyway, I'm fine with just disabling it
<YokoZar> So this is basically a chain of 5 blockers that lead me to readline6 now: Some patches to wine (failing to build) --> needs ia32-libs update --> needs new python2.6 --> needs libreadline6-dev --> needs an MIR
<pitti> YokoZar: just needs a MIR bug, not a full wiki page; it's just a new version after all
<YokoZar> Ahh ok
<YokoZar> Poke doko for me he caused this ;)
<slangasek> pitti: OTOH, does this mean we're stuck with two versions of readline on the CDs now, or is someone taking responsible for transitioning us to readline6?
<slangasek> heh, "taking responsible"
<pitti> slangasek: wine isn't on the CD?
<YokoZar> no but python2.6 is
<slangasek> pitti: readline6 needs an MIR because of python2.6; everything else uses readline6
<pitti> ah, I see
<slangasek> 5
<YokoZar> The only thing this has to do with Wine is that python2.6 failing to build is blocking ia32-libs
<pitti> $ apt-cache rdepends libreadline5|wc -l
<pitti> 325
<pitti> we might not finish that in karmic..
<slangasek> yep - so why do we want to start it, I wonder
<pitti> it's an extra 150 kB, so it won't kill us, but perhaps it's possible to build python2.6 with libreadline5?
<slangasek> the change was made in an Ubuntu point revision - so yes, it should be possible
<pitti> right, in http://launchpadlibrarian.net/30822021/python2.6_2.6.2-0ubuntu3_2.6.2-0ubuntu4.diff.gz
<pitti> that pulled in new upstream code
<slangasek> ah, hmm
<slangasek> mvo: morning!
<pitti> but nothing that seems to check the version of libreadline
<mvo> hey slangasek
<slangasek> mvo: does it alarm you if I greet you eagerly? :-)
<YokoZar> We could just try an upload with the older version and see if it still works ;)
<mvo> slangasek: it does :P
<pitti> slangasek: so yes, should be possible
<slangasek> mvo: do you think you could take a look at https://launchpad.net/ubuntu/+source/vips/7.18.1-1ubuntu3/+build/1207710 ? regression introduced by the zlib1g change, only affects !64-bit archs :/
<YokoZar> slangasek  has a pile of work for mvo I bet
<mvo> slangasek: startling even
 * slangasek grins
<mvo> slangasek: *weh* sure, I have a look
<slangasek> mvo: in the future I will try to greet you eagerly when I'm not asking you to do work
<slangasek> to put you more at ease
<YokoZar> (and lull you into a trap)
<mvo> :)
 * mvo makes a pot of tea and attacks the zlib problem
<poolie> mvo, over here
<poolie> i was just going to ask you about https://edge.launchpad.net/ubuntu/+source/python2.6/2.6.2-0ubuntu4/+build/1188649
 * mvo waves to YokoZar
<pitti> slangasek: I'll change python2.6
<slangasek> pitti: ok
<mvo> pitti: so you take care of the above build-failure?
<mvo> (or is there another python2.6 change in the works)
<pitti> mvo: it's in depwait
<pitti> mvo: or what do you mean?
<mvo> pitti: it seems that libreadline6-dev is in universe
<pitti> mvo: right, that's what we just discussed, I'll change it back to 5
<mvo> pitti: thanks, I missed the earlier part of the discussion (joined too late)
<mvo> poolie: ^--- pitti deals with it :)
 * pitti hugs mvo
 * pitti hugs poolie, too
 * mvo hugs pitti
<pitti> poolie: you wrote an awesome VCS, you deserve some help :-P
<YokoZar> pitti: thanks ;)  Nice to have the german crew working on this through the night
<pitti> "night"?
<pitti> I already slept in, until 8:30..
<YokoZar> Yes, real time is where I live.
<poolie> :)
<poolie> thanks pitti
<poolie> i don't desperately need it fixed but i'd like if someone could at least triage it
<YokoZar> slangasek: what do you think of including some of the various thumbnailers that are stuck in universe onto the CD?
<slangasek> eh?
<slangasek> I think this is late in the cycle to be proposing new features to squeeze onto the CD
<YokoZar> Well one I proposed at UDS (gnome-exe-thumbnailer)
<YokoZar> but when I was making it I found gnome-raw-thumbnailer (gives thumbnails of digital camera raw files) and two other minor ones
<poolie> pitti, mvo, so how about https://launchpad.net/bugs/392355 (sorry to nag)
<ubottu> Ubuntu bug 392355 in bzr "C extensions placed in wrong directory on karmic" [High,Confirmed]
<slangasek> YokoZar: installing gnome-exe-thumbnailer pulls in 600K of installed packages onto my system when I try to install it; this really should have been seeded earlier in the cycle, IMHO
<slangasek> YokoZar: you can file a bug against ubuntu-meta and/or start a discussion on ubuntu-devel -- either of those is better than trying to persuade me personally to seed it :)
<YokoZar> How about I give up in despair and come to the next UDS with a petition to switch to memory sticks and DVDs ;)
<mvo> poolie: no problem, its more a doko type question, but I can have a look too. I probably need a bit (because I need to compare old/new python-defaults)
<poolie> cool, thankyou
<cjwatson> oh, I reassigned it to python2.6 on the assumption that it was probably a problem with the code there
<cjwatson> if it belongs on python-defaults after all, feel free to reassign it back ...
<YokoZar> Does ubuntu have anything like a build/test farm for different arches that developers can get shell access to?  I seem to remember Debian having something like this
<slangasek> Canonical has porter machines that employees can access; unfortunately there are no porter machines open to the Ubuntu community
<YokoZar> slangasek: thanks
<pitti> slangasek: hm, python2.6 is FTBFS
<pitti> make[1]: *** No rule to make target `libpython2.6.so', needed by `python'.  Stop.
<pitti> but nothing that points to the libreadline change..
<slangasek> yuck?
<pitti> so I better not upload this
<slangasek> if you insist :-)
 * pitti uploads to his PPA to check whether it's some local issue
<liw> hm, the new gdm greeter in karmic does not have any (visible?) way to invoke failsafe sessions
<liw> gnome-session: Fatal IO error 11 (Resurssi ei tilapÃ¤isesti ole kÃ¤ytettÃ¤vissÃ¤) on X server :0.0.
<liw> that's ... intriguing
<pitti> liw: choose a user, then choose xterm session?
<liw> pitti, how do I choose xterm session?
<pitti> liw: in the session chooser in the bottom bar
<liw> I haven't got one
<pitti> liw: did you choose a user first?
<liw> er, sorry, mea culpa
<liw> (that was confusing to me)
<liw> anyway, the real problem is that my SO's account can't log in
<liw> this has been going on for a few days, but I've only had time to look at it now
<liw> hm, I created another account, and it, too, fails to log in via gdm
<poolie> hi liw
<poolie> thanks for looking at it cjwatson
<liw> hi poolie
<dpm> hi pitti, good morning. Thanks for copying the listed jaunty langpacks to -updates. May I ask you to also copy the 'es' language pack? The Spanish guys did some last minute testing and posted a message on the list (http://tinyurl.com/m87dto), but they didn't CC you. It would be quite good to have it in -updates, since that particular one solves quite a lot of bugs (sorry for not getting the list of languages all at once)
<pitti> dpm: done
<dpm> pitti: thanks!
<liw> does anyone else have a problem with logging in with accounts other than their own? (easy to test: create new account with 'adduser tomjon' and then switch user to it)
<liw> bug #426159 is the one I reported about this
<ubottu> Launchpad bug 426159 in gnome-session "Cannot log in via gdm" [Undecided,New] https://launchpad.net/bugs/426159
<seb128> no issue there to log with different accounts
<seb128> and gnome-session didn't change for a while I doubt it's due to it
<seb128> look into your Xorg.n.log?
<seb128> the .xsession-errors has lot of display not available errors, could be xorg crashing for you
<liw> why would it crash for tomjon but not liw?
<davmor2> liw: it doesn't like tomjon
<seb128> does it crash for tomjon if you try to start that session first?
<seb128> it could be a "second xorg session is crashing" sort of issue
<liw> seb128, I did not have another session open when logging into tomjon
<seb128> ok so I don't know
<seb128> would be useful to have gnome-session debug log
<seb128> do you get the issue if you run gnome-session?
<liw> how do I get a gnome-session debug log? how do I run gnome-session?
<mvo> slangasek: so, the problem with the zlib stuff is that off64_t is not defined on 32bit machines unless USE_LARGEFILE64 is used. I can add a #if _FILE_OFFSET_BITS ==64 && !defined(_LARGEFILE64_SOURCE) #define off64_t off_t #endif #endif - also I have to say that I don't really like this, its getting ugly and this messing around is not to my liking
<seb128> liw, start a non GNOME session either by selecting the debug one in gdm or using startx
<seb128> liw, and run gnome-session --debug
<liw> seb128, attached to bug
<seb128> looking
<liw> seb128, and it got reassigned to xorg-server
<seb128> right, chrishcoulson seems to think the same thing than me
<seb128> liw, when you run gnome-session by hand does it start normally?
<seb128> liw, do you use compiz for your normal user?
<liw> seb128, nope, it dies before anything shows up (like panels), in a few seconds
<seb128> liw, can you start the debug session and just run compiz there?
<seb128> I would say that compiz makes your xorg crash
<seb128> you might not be using it with your normal configured session?
<liw> seb128, I use metacity with my account liw, not compiz; compiz won't start on this machine
<seb128> well the gnome-session log shows that it tries starting
<liw> I'll see what starting it manually does
<seb128> thanks
<seb128> if that crashes xorg you know what the difference and the issue is
<liw> it's dead. dead I tell you. dead, dead, dead. dead as a 3D accelerated dodo.
<liw> i.e., X crashes after running compiz manually from tomjon's xterm session
<seb128> liw, ok, so it's an xorg bug, adding the Xorg.0.log to the bug would be useful
<seb128> look to /var/crash too if there is a .crash about it
<seb128> compiz does some capability detection on start but that should not crash xorg
<liw> removing compiz does not prevent the problem, though
<seb128> how removing it?
<seb128> you can run gconf-editor and change /desktop/gnome/session/required_components/windowmanager
<mvo> cjwatson: could you please double check http://paste.ubuntu.com/267107/ ? it fixes a ftbfs for 32bit plattforms where off64_t is not always defined (I'm not too happy about it, but I don't see a really cleaner way - testing #if __off64_t_defined would be possible but even more ugly)
<liw> I removed the compiz package
<seb128> it's gnome-wm by default which tries to be clever but you can set any wm you want there
<liw> oh, but there's a million compiz packages
<liw> there, removing all of them fixed it
<mvo> cjwatson: alternatively we can just revert my upload and see what upstream comes up with
<seb128> liw, still add your xorg infos to the bug it should not crash
<liw> seb128, I already did
<seb128> ok
<sistpoty|work> mvo: I guess you should at least at !defined(off64_t) to it, so that zlib.h can be included twice
<sistpoty|work> add even
<cjwatson> mvo: I think I'd prefer it if we had a zlib_off64_t define which is defined to off_t [_FILE_OFFSET_BITS=64] or off64_t [_LARGEFILE64_SOURCE], rather than scribbling over off64_t itself
<cjwatson> mvo: seems less likely to cause failures elsewhere
<cjwatson> mvo: (adjust name of zlib_off64_t to whatever seems locally suitable, of course)
<mvo> cjwatson: yeah, that makes sense, I create a new diff now
<mvo> sistpoty|work: thanks
<cjwatson> the problem with #define off64_t is that off64_t is actually a typedef elsewhere
<cjwatson> and so it seems likely that you'd create weirdness ...
<mvo> cjwatson: agreed, I did test, but of course not all cases, so being careful is better
<mvo> cjwatson: does http://paste.ubuntu.com/267126/ look ok?
<liw> would it be simpler to just #include sys/types.h or whatever defines off*_t? or is that harmful from namespace pollution reasons?
<liw> oh, no, I misunderstood the probelm
<cjwatson> mvo: yeah, that's what I was thinking and looks better to me
<mvo> cjwatson: great, thanks a lot for your review
<geser> btw: just curious why does it happen at all on 32bit? from a quick look at features.h and unistd.h off64_t should be defined in the _LARGEFILE64_SOURCE case?
<cjwatson> geser: you've got it the wrong way round; it happens on 32-bit and when _FILE_OFFSET_BITS=64 but *not* _LARGEFILE64_SOURCE
<cjwatson> _FILE_OFFSET_BITS=64 means "just make everything 64-bit, don't bother with the separate *64 versions of things"
<geser> ah
<lool> Is there a way to do a touch in a patch?
<pitti> lool: not that I know of; but you could patch the file to just have a newline or so?
<lool> Yeah, I was looking for something a bit more elegant but that will do
<lool> thanks
<TheMuso> pitti: Well not harder, just got to do things differently.
<Keybuk> the PPA system hates me, it keeps giving my builds scores like "4" and says it'll build in 27 weeks
<Daviey> Keybuk: you need to pay, and get a private PPA with automatic natural scores :)
<maxb> I thought 4 was the special score auto-assigned to rebuild archives?
<Keybuk> Daviey: fortunately being a TB member means I can fiddle the scores myself ;)
<maswan> Keybuk: Buy a new shiny bladecenter full of neat bl460c g6 blades with plenty of ram, those are speedy. ;)
<Keybuk> maswan: ?! on my salary !!
<Daviey> Keybuk: hah
<maswan> (also, gives incentive to someone else to fix the issues I've found so far ;) )
<hyperair> seb128: did you request a sync, or should i?
<seb128> neither of those, I will sync it today I was waiting for the binary to be on the mirrors
<hyperair> ah. okay then
<TomaszD> hyperair, hey. So, how about fixing another translation problem today huh? :) gdebi is ready and waiting :P
<seb128> ready to what?
<hyperair> TomaszD: maybe next week
<TomaszD> seb128, to get fixed ;)
<TomaszD> hyperair, ok
<hyperair> if nobody has already fixed it by then =)
<hyperair> out of curiosity, what's wrong with gdebi?
<TomaszD> hyperair, not really sure, seems to be that there are similar symptoms to nautilus-share
<TomaszD> but not much else I can tell
<hyperair> it's probably a one-liner change
<hyperair> lemme test this out
<hyperair> TomaszD: as i thought. a one-liner change.
<hyperair> TomaszD: today's your lucky day. i got gdebi fixed =)
<TomaszD> hyperair, awesome! thanks!
<hyperair> is there a bug for this?
<TomaszD> hyperair, https://bugs.launchpad.net/ubuntu-translations/+bug/425812
<ubottu> Ubuntu bug 425812 in gdebi "gdebi does not use translations at all" [Undecided,New]
<TomaszD> hyperair, I'm curious, was that a POTFILES.in breakage?
<hyperair> TomaszD: no. not at all.
<hyperair> TomaszD: gtkbuilder is a screwed thing when it comes to translations. =\
<TomaszD> well it's a good thing the whole GNOME project isn't moving to... well shit
<hyperair> seb128: if i'm going to have to manually set_translation_domain for every gtk builder object i have, i believe gtkbuilder is the one at fault.
<seb128> right
<seb128> how did you fix the nautilus-share one?
<hyperair> by setting the translation domain
<hyperair> the same thing goes for gdebi
<hyperair> i poked around totem's code and found that it also does the gtk_builder_set_translation_domain function
<Keybuk> slangasek: system-config-printer's udev-configure-printer hook - does that *need* to be a udev hook?
<Keybuk> slangasek: or, to phrase the question better
<seb128> it's weird, other software work fine without that
<seb128> ie update-manager, alacarte
<Keybuk> does that binary do anything which could affect the configuration of the device in such a way that other applications or tools using that device should wait for it to be complete?
<hyperair> seb128: seriously?
<seb128> well I just looked to alacarte and it only does the gettext domain call
<seb128> same for update-manager
<hyperair> hmm
<hyperair> how strange, eh..
<hyperair> nowhere else?
<hyperair> at all?
<seb128> I think things coming from nautilus are special because nautilus change the gettext domain
<TomaszD> seb128, neither update-manager nor alacarte work fine
<seb128> but standalone applications should just work
<TomaszD> alacarte is also broken
<TomaszD> I just checked
<seb128> TomaszD, categories are translated there
<TomaszD> seb128, yes, but "Menus", "Items", all the buttons are not
<hyperair> seb128: make sure you look at the parts that are *only* specified in the .ui file, not parts which are modified by the app
<seb128> right
<hyperair> seb128: nautilus-share and gdebi's issues were like that.
<hyperair> and i don't think gdebi has any change of translation domains
<seb128> right
<hyperair> by the way, glade worked perfectly wrt translation domains
<TomaszD> update-manager has the same problem really, it was just mudded slightly because the template wasn't regenerated
<seb128> I'm wondering if pygtk is not broken
<seb128> TomaszD, that has nothing to do with templates
<hyperair> maybe a test app would be good..
<TomaszD> I know, but the old strings which were translated a long time ago don't show up as translated seb128
<seb128> TomaszD, and?
<TomaszD> so that leads me to believe that there is an additional problem, ie. gtkbuilder one
<seb128> well C softwares are not broken
<hyperair> let's try gtkmm
<TomaszD> alright, I thought update-manager was a python application, not a C app
<seb128> it is a python application
<TomaszD> ok, so it was just a general comment about C apps
<seb128> ?
<TomaszD> yours
<TomaszD> nevermind :)
<seb128> I say I didn't notice an issue with C softwares
<seb128> so I would blame pygtk rather than gtk
<TomaszD> right, that's what I was trying clumsily to refer to
<TomaszD> what else is there using gtkbuilder, I believe computer-janitor and usbcreator need looking into as well
<liw> TomaszD, er, what? what's up with c-j?
<TomaszD> liw, sorry I'm losing track of my bug mail, it would seem you have fixed the issue
<TomaszD> :)
<liw> ok
<seb128> doesn't seem a gtk issue in any case, ld preloading the jaunty version does no difference
<TomaszD> liw, but! if this app is using gtkbuilder, you might want to look at the hints about about this "gtk_builder_set_translation_domain" thing
<TomaszD> *above about
<liw> I don't want to read through lots of backlog, please summarize
<TomaszD> liw, "...i'm going to have to manually set_translation_domain for every gtk builder object i have..."
<TomaszD> liw, might be a bug somewhere, but this seems to be a good workaround
<seb128> that's not what he wrote exactly
<seb128> and I would rather focus on finding the pygtk issue than workarounding every software
<TomaszD> that's reasonable, but there is no guarantee of finding the issue, and shipping with untranslatable apps isn't a nice prospect, at least that's how I see it
<liw> if it can't be fixed in pygtk, then file bugs, but please wait with that until pygtk is deemed unfixable for karmic
<TomaszD> sure, I'll try to remember that
<liw> thanks
<seb128> TomaszD, why wouldn't it be fixable, there is months before karmic
<seb128> I think it's a matter of debugging for one hour or so
<TomaszD> seb128, you know, I'm freaking out because the release of GNOME is near (I'm an upstream translator), I'm probably influenced by that
<seb128> TomaszD, we will have 2.28.1 in karmic
<TomaszD> seb128, well that's a relief
<seb128> TomaszD, http://bugzilla.gnome.org/show_bug.cgi?id=574520
<ubottu> Gnome bug 574520 in documentation "gtk.Builder translations fail" [Normal,New]
<soren> cjwatson: Bug #425922 looks like something in your domain to me. Would you agree?
<ubottu> Launchpad bug 425922 in eucalyptus "Eucalyptus component registration process is manual " [Medium,Triaged] https://launchpad.net/bugs/425922
<TomaszD> seb128, so it's not a bug, it's just a specific way of handling translations?
<cjwatson> soren: yes, probably
<soren> cjwatson: Would you mind terribly if I reassigned bugs about the avahi magic in Eucalyptus to you?
<seb128> TomaszD, not sure yet
<TomaszD> ok
<seb128> ogra__, could you push your tomboy changes to bzr?
<cjwatson> soren: ok by me
<ogra> seb128, is that really needed ? they should hit debian today with a new upstream
<seb128> ogra: what? updating bzr when you upload a package maintained in bzr? yes
<ogra> ok
<seb128> the reason I ask it's because rodrigo ask us about it
<ogra> ok
<seb128> it seems to block him in online service changes
<ogra> will do before end of my day
<seb128> heh
<seb128> rodrigo is waiting on it now
<seb128> it's blocking him to do changes
<ogra> i'm in meetings
<seb128> *shrug*
<seb128> if you don't do it properly please don't change desktop packages and ask for sponsoring next time
<seb128> we will fix this one now
<ogra> i'm on it
<seb128> ok thanks
<soren> cjwatson: Cool, will do.
<engla> DktrKranz: Hey! kupfer-ping! Is it viable to update c10 in ubu karmic with a spanish translation file (complete). And should I make a c10.1 release or is c10-2 by you to prefer?
<hyperair> seb128: gtkmm fails as well
<seb128> I'm a bit puzzled by that
<seb128> the jaunty gtk makes no difference
<hyperair> see for yourself: http://dl.getdropbox.com/u/169656/testgtkbuilder-0.1.tar.gz
<hyperair> i've only added pl.po translating "button" to "bla" for testing purposes, but you can copy it over to your locale and update LINGUAS to test
<ogra> seb128, pushed
<hyperair> seb128: ^^
<seb128> ogra: thanks
<blackxored> there will be improvements for flash in karmic?
<seb128> hyperair, ok
<directhex> seb128, do i need to do the full FFe paperwork for an upstream update to one of f-spot's deps?
<seb128> directhex, which one?
<directhex> seb128, flickrnet
<seb128> directhex, no such source in karmic
<Laney> seb128: libflickrnet
<seb128> directhex, Laney: synced
<Laney> you beaut
<Laney> now we need to untransition f-spot
<Laney> s/un//
<directhex> Laney, what changes are there other than that? can it just be synced too?
<Laney> no, there's some patch from lool that we didn't apply in sid
<seb128> Laney, like direct sync from debian or do we have other changes?
<seb128> ok
<Laney> the gnome-screensaver fixes he did I didn't apply
<seb128> I though that had been sent to debian too
<seb128> I guess next round then
<Laney> yeah I thought I'd wait for upstream
<Laney> but there's no reason we couldn't apply them in patches/
<Laney> but it's been uploaded to sid anyway so we need to merge
<Laney> oh, those changes didn't get uploaded to Karmic... we could just sync if they aren't critical
<Laney> seb128: what do you think?
<seb128> let's sync and see if it builds? ;-)
<Laney> it will build just fine, but lool wanted to avoid the gnome-screensaver build dep
<Laney> sync+possible ubuntu1 sounds good to me
<seb128> did debian add this one?
<directhex> in this case "debian" is Laney
<Laney> yeah, and its what is in 0ubuntu1 now
<seb128> ok
<seb128> directhex, I know but he's not uploader, the sponsor might do changes
 * Laney doesn't know how important avoiding the build dep is
<seb128> the build-dep is already in karmic so that will not change a lot
<seb128> and it's minor, it's just to make the buildd work easier
<Laney> ok then
<lool> Laney: It's ok if it gets dropped in the end  :)
<Laney> lool: It was applied upstream wasn't it?
<lool> this stuff was merged upstream so just use the new configure flags when the new upstream release supports it
<lool> Yes
<Laney> will do then
<lool> thanks
<DktrKranz> engla: -2
<engla> hey. ok
<DktrKranz> engla: btw, did you contact upstream asking to integrate it?
<DktrKranz> engla: c11 is out, I guess ulrik will release 12 soon, and I'll update it in Debian when that happens.
<engla> DktrKranz: Pardon the missed introduction! ; I'm ulrik
<DktrKranz> engla: whoops :)
<engla> I should have said, hi, it's me
<RainCT> Keybuk: I asked you before about D-Bus. Apparently there is a default timeout value which can be overriden when doing a call - do you happen to know where that is defined?
 * DktrKranz kicks himself for not using /whois 
<Keybuk> RainCT: in the headers
<Keybuk> dbus/dbus-connection-internal.h:#define _DBUS_DEFAULT_TIMEOUT_VALUE (25 * 1000)
<Keybuk> this is not a userspace interface
<Keybuk> from the API, supplying "-1" for any timeout value means "the default"
<Keybuk> supplying "0" means "immediately timeout"
<Keybuk> supplying anything from 1...INT_MAX-1 means "this many ms"
<Keybuk> and INT_MAX means "never timeout"
<RainCT> Keybuk: thanks! :)
<directhex> hm, by my sums, karmic's mono footprint is about the same as gutsy's, and over 10 meg smaller than intrepid's
<superm1> slangasek, something went wrong with the hash sum mismatch in apt during the last mythbuntu cd build.  can you take a look at it? http://people.canonical.com/~ubuntu-archive/cd-build-logs/mythbuntu/karmic/daily-live-20090908.log
<TomaszD> superm1, sorry to bother you, but where can I find the template for mythbuntu-control-centre or mythbuntu-common for karmic?
<superm1> TomaszD, i'm not sure translation support is fully in place yet for karmic
<superm1> everything got rewritten
<TomaszD> superm1, oh, ok.
<superm1> TomaszD, would you be able to help get things in order?
<superm1> do you have experience with such things?
<TomaszD> superm1, not really. I'm just a translator.
<superm1> TomaszD, ah okay.  will try to let you know when things are sorted out then
<TomaszD> superm1, but what needs to be done, is the gettext domain not set, are the strings not marked for translation?
<superm1> TomaszD, since it's a universe package, the translations need to be shipped in it, and the package hasn't been prepped for that
<TomaszD> superm1, if you don't hear from me then I wasn't able to do much
<TomaszD> :)
<Keybuk> huh
<Keybuk> PPA has been saying "starting in 1 minute" for over an hour now
<soren> A microsoft minute.
<pitti> Keybuk: with a queue size of 468, good luck..
 * amitk had heard of "A New York minute". What is a microsoft minute?
<Keybuk> pitti: several of the buildds are sitting idle though
<soren> amitk: It's hard to say. http://www.urbandictionary.com/define.php?term=Microsoft+Minute
<YokoZar> pitti: Are you going to end up having to include libreadline6 for python2.6?
<pitti> YokoZar: I think we can revert it back to 5
<pitti> but it fails to build (for other reasons), so I can't actually upload it
<pitti> this needs doko, I'm afraid
<ogra> OMG we're screwed without doko !
<ogra> (and /me wholeheartedly means it ... )
<RainCT> uhm.. stupid question, why is the netbook remix download 950MB big?
<pitti> absolutely
<pitti> RainCT: it's just meant to be < 1 GB
<pitti> RainCT: unlike ubuntu desktop, it's not meant to be distributed on CDs, but installed from USB stick
<RainCT> but shouldn't it be smaller than the desktop thing?
<pitti> just in resolution :)
<pitti> (FWIW, I'd love if it was smaller...)
<ogra> Riddell, more langpacks :)
<pitti> ogra: tab disease
<ogra> heh
<ogra> RainCT, indeed
 * sistpoty|work only has a 512 Mb USB stick and feels outdated... OTOH he doesn't have a netbook as well *g*
<ogra> thanks for mentioning :)
<RainCT> oh well, then have dynamic img generation for each language on request :P
 * RainCT hides
<RainCT> pitti, ogra: well, thx for the info
<jdstrand> slangasek: hi! so I'd like to add some items to the release notes for karmic. I see https://wiki.ubuntu.com/KarmicKoala/TechnicalOverview, but wasn't sure if that was the right place. (I feel like I am missing something obvious...)
<ogra> RainCT, well, evand is such a slacker and didnt implement that yet in usb-creator :P
<jdstrand> slangasek: where is the right place to add them?
<seb128> is anybody around who has enough clue about -Bsymbolic-functions to understand why it makes evolution memos crash?
<seb128> and would it be considered bad taste to build evolution without that option?
<TomaszD> seb128, looks like alacarte got fixed upstream http://ftp.gnome.org/pub/GNOME/sources/alacarte/0.12/alacarte-0.12.3.news
<TomaszD> :)
<seb128> TomaszD, right, I discussed with cosimoc on IRC earlier
<TomaszD> seb128, ah
<seb128> I asked him to test on fc11 since he's using that
<seb128> to make sure that was not an ubuntu bug
<seb128> and he had the issue too
<seb128> kees, hey, do you know about -Bsymbolic-functions? ;-)
<sistpoty|work> seb128: -Bsymbolic-functions means that symbols (referring to functions) resolved within that thing won't be looked up dynamically iirc
<seb128> sistpoty|work, <mbarnes> wonder if this is related to the fact that CompEditor is defined in a private library that both the main application and calender module statically links to
<seb128> sistpoty|work, would that be an issue?
<sistpoty|work> seb128: could well be
<seb128> sistpoty|work, do you have any idea what would be the right way to fix that?
 * seb128 is thinking to build without -Bsymbolic-functions for now
<sistpoty|work> seb128: not without looking at the code actually... is any of these a weak symbol (and hence probably meant to be overriden by the other)?
<seb128> I just fear to be tracked by the security team or whoever decided we need to set that on by default
<seb128> dunno
<seb128> http://bugzilla.gnome.org/show_bug.cgi?id=594473 is the issue
<ubottu> Gnome bug 594473 in Tasks "evolution hangs when opening multiple notes" [Normal,Unconfirmed]
<seb128> "(evolution:10798): GLib-GObject-WARNING **: cannot register existing type `CompEditor'"
<seb128> is what is displayed when trying to open a memo on karmic
<cjwatson> http://edos.debian.net/weather/ is a great visualisation
<cjwatson> we should run this on Ubuntu
<sistpoty|work> seb128: fwiw -Bsymbolic-functions indeed seems to cause this problem
<sistpoty|work> seb128: the expansion of G_DEFINE_TYPE yields (among others) one non-static function: http://paste.ubuntu.com/267378/
<sistpoty|work> seb128: which in turn registers the type, unless the static volatile variable is set
<sistpoty|work> seb128: so if that function is resolved at runtime (as without -Bsymbolic-functions) it will resolve to the very same function and hence have the same static volatile variable
<sistpoty|work> seb128: with -Bsymbolic-functions, these will be two different functions and hence two calls to  g_type_register_static_simple
<sistpoty|work> (sorry, the g_type_register_static_simple is the next line, which I skipped already in pastebin)
<sistpoty|work> seb128: but I wouldn't know by hand how to best solve this, apart from linking against the static library only once - if that's possible
<seb128> ok, thanks for the explanations!
<sistpoty|work> np
<seb128> I think I will just turn the option for now as a workaround and let upstream deal with the build system changes
<seb128> btw do you know why we have this flag on by default on ubuntu?
<sistpoty|work> not really, maybe for faster loading times? But I guess kees certainly does know ;)
<seb128> ok
<seb128> sistpoty|work, thanks again!
<sistpoty|work> no problem ;)
<james_w> seb128: I believe the desired way to turn things of is to add an explanation to the CompilerFlags wiki page with the package name and a reference to the bug report that prompted the chane
<james_w> https://wiki.ubuntu.com/CompilerFlags
<seb128> james_w, thanks
<cjwatson> pitti: I've unhosed the desktop package sets now - should be much more sensible-looking
<pitti> cjwatson: nice, thanks! (If only I knew where to look in the first place.. :-) )
<cjwatson> for the contents?
<pitti> is it possible with edit_acls.py?
<cjwatson> yes
<cjwatson> ./edit_acl.py -P karmic-ubuntu-desktop query
<cjwatson> for instance
<cjwatson> sorry, any documentation that is present is more by luck than judgement
<pitti> oh, that's what I tried an hour ago
 * pitti updates branch
<pitti> ah, great!
<cjwatson> I wrote this code today, so you will need to be up to date, yes ;-)
<cjwatson> the sets are generated from seeds, more or less, so at this point I think I can safely say that any oddness you see comes from there
<slangasek> Keybuk: udev-configure-printer - I really have no idea, I've only just noticed it
<pitti> cjwatson: oh, in that new system, would it pe possible to restrict uploads of language-{pack,support} to ~ubuntu-langpack?
<Keybuk> because if it doesn't directly affect the device node
<Keybuk> and doesn't store anything in the udev db
<Keybuk> it can be done as an Upstart job
<cjwatson> pitti: we could special-case the language packs, yes, although I sort of feel that core-dev ought to be able to upload them in an emergency
<pitti> cjwatson: ok, true that
<cjwatson> but we could put them in a package set that is uploadable by ~ubuntu-langpack too
<pitti> it's just prone to be overwritten
<Keybuk> slangasek:   start on filesystem and usb-device-added ...
<slangasek> superm1: that apt hash mismatch is our standard "we don't have locking completely right on mirroring on antimony" bug; it should fix itself on the next build, or I can trigger a rebuild
<pitti> especially since for karmic the stuff gets uploaded automatically
<Keybuk> slangasek:   start on filesystem and <whatever subsystem lp are in>-device-added
<cjwatson> pitti: it's technically possible to make it a restricted set, certainly
<slangasek> jdstrand: release notes for karmic - open bugs against the ubuntu-release-notes project, please
<cjwatson> pitti: can you mail the TB list about it?
<cjwatson> pitti: (PS I'm not sure whether restricted sets will have a useful effect until we stop having component permissions in there too)
<pitti> cjwatson: will do; although there's something to be said for emergency fixes, I'll note that
<pitti> cjwatson: will send after our meeting
<jdstrand> slangasek: thanks
<superm1> slangasek, would you mind triggering a rebuild then? there was some stuff I particularly wanted to test on what would have been on that build
<hyperair> seb128: you made any progress with the gtkbuilder issue?
<seb128> upstream seems to advice to call set_translation_domain in every pygtk software
<seb128> http://bugzilla.gnome.org/show_bug.cgi?id=574520
<ubottu> Gnome bug 574520 in documentation "gtk.Builder translations fail" [Normal,New]
<hyperair> but that's pygtk.
<hyperair> what about the gtkmm one i linked you to?
<seb128> hyperair, I've no clue about gtkmm it might have the same issue
<slangasek> superm1: I think that one worked
<superm1> slangasek, yup i see a  good one now.  thanks
<mterry> kees, re: rsyslog hang, do you do anything special to make it hang?  Like, a special sequence of stop/restart/start or under extreme load, or whatever?  Having a hard time casually trying to reproduce.
<slangasek> Keybuk: so upstart has a way to specify that a rule should be run when a given device is added via udev?
<slangasek> Keybuk: I guess that doesn't solve the problem for distros still stuck using sysvinit? :)
<kees> mterry: generally it's happened across package upgrades.
<mterry> kees, OK
<ScottK> cjwatson: I've just read the backscroll on the TB meeting and I'd like to chat with you about the team for Kubuntu upload rights when you have a moment.
<pitti> cjwatson: sent
<Keybuk> slangasek: yes
<Keybuk> you get <subsystem>-device-added and <subsystem>-device-removed
<cjwatson> ScottK: hi
<ScottK> cjwatson: I don't think kubuntu-ninjas is the team you want.  We use that for access to the private PPA where we stage uploads, but there all uploads from there to the archive get a core-dev review first and there are people who I am confident are not ready for direct upload rights on that team.
<cjwatson> ok
<ScottK> cjwatson: I think what's needed is a new kubuntu-dev team that would (at least initially) be a subset of kubuntu-ninjas.
<cjwatson> all right, fine by me
<cjwatson> none of that is getting applied to upload privileges until it clears the owners of the respective teams + TB anyway
<cjwatson> the Kubuntu package set has an archive permission of ubuntu-core-dev attached to it, so no change currently
<ScottK> OK
<ScottK> cjwatson: Is there something I need to do to document this or have you got the action.
<cjwatson> what we'll need to know is how the team is managed, since if it's owned by anyone other than TB/DMB, it amounts to a delegation of upload rights
<cjwatson> err, a delegation of the ability to grant upload rights
<ScottK> Right.
<cjwatson> I have an action to start some mail conversations already - I'll make sure you're included on the Kubuntu one
<ScottK> I'd suggest it to be initially owned by DMB and have the current core-dev in kubuntu-ninjas on it.
<ScottK> OK
<ScottK> There are some I'm comfortable with immediately adding, but we ought to have some process for that beyond ScottK says.
<ScottK> Thanks.
<ScottK> cjwatson: Also Riddell is offline until Thursday, so don't expect quick reaction from hime.
<ScottK> hime/him
 * Night-Horse away
<cjwatson> ScottK: been dragging on for months so I'll live ;-)
<rgreening> pitti: ping
<smoser> jjohansen, i was supposed to ask in your kernel meeting, but forgot/missed.
<smoser> you're working on getting a karmic-ified ec2 kernel, right ?
<jjohansen> yes
<jjohansen> it is currently failing to link
<jjohansen> karmic has some patches that aren't in mainline, that the xen patches need to be updated for
<jjohansen> I have high hopes of getting it up today
<mathiaz> cjwatson: hi - about the ubuntu-server team role in archive reorg - what do you need from me?
<smoser> jjohansen, you rock. thanks.
<jjohansen> smoser: I'll let you know as soon as I have an aki
<cjwatson> mathiaz: at some point, it would be good for the server team to figure out a team that consists of those people who should be able to upload server-related packages, and talk to the TB about its membership practices
<mathiaz> cjwatson: ok - anything related to server-related package sets?
<mathiaz> cjwatson: who's gonna decide what goes in there?
<cjwatson> that's set up, determined from seeds
<cjwatson> bzr get lp:ubuntu-archive-tools && cd ubuntu-archive-tools && ./edit_acl.py -P karmic-ubuntu-server query
<mathiaz> cjwatson: great - thanks
<mathiaz> cjwatson: so the ubuntu-server-dev team would have people that have upload rights to the packages listed above^^?
<cjwatson> that's the idea
<Keybuk> pitti: If I mark something Won't Fix, I would appreciate you at least talking to me first before undoing that
<Amaranth> cjwatson: how does that work with packages that end up in more than one seed?
<cjwatson> Amaranth: they may go in multiple package sets, and therefore be uploadable by multiple teams
<cjwatson> (see the spec)
<Keybuk> ion: *cough*
<Keybuk> looks like, err
<Keybuk> s/starting udev/started udev/ in /etc/init/udevtrigger.conf
<arand> kees: regarding bug #418135 , I was thinking of trying to pick together debdiffs for intrepid and hardy (just adding the 61-patch), or do you have other plans regarding that?
<ubottu> Launchpad bug 418135 in glib2.0 "Permissions of symlinked source file/folder set to 777 if symlink is copied via nautilus" [Undecided,Confirmed] https://launchpad.net/bugs/418135
<kees> arand: yeah, that's what I was going to try too.  had a bunch of other stuff to do first, though.
<arand> kees: But would me poking in it help?
<kees> arand: yeah, absolutely; if you can prepare the debdiffs that'd be great.  they need to be tested too, if possible.
<arand> kees: Ok, I'll try to do as much as I can.
<kees> cool
<RainCT> uhm usb-creator-gtk is broken.. how do I install the netbook remix now :/
<mok0> RainCT: Install Xubuntu on your netbook...
<mok0> RainCT: It's sooooo nice
<RainCT> Heh. Nit
<RainCT> * Heh. Not my netbook, btw, but my neighbour's.   I haven't gt one yet.
<mok0> RainCT: Oh... does your neighbor know about this? :-P
<mok0> RainCT: you can use dd to put the image on the usb stick
<mok0> usb-creator-gtk is just a wrapper around that :-)
<RainCT> mok0: I installed Ubuntu on an old laptop of the girlfriend of his son (who had heard about free software before thanks to another LoCo member who is all the time doing conferences and stuff :)), and she (with the help of office asking for 200â¬ for activation) now convinced him that Ubuntu is awesome :P
<mok0> RainCT: yay
<RainCT> usb creator in jaunty doesn't support .img, awesome
<RainCT> mok0: okay, so what's that command? :)Ã§
<mok0> RainCT: arhgh I have too google
<kirkland> ogra: ping, regarding qemu-kvm
<mok0> https://help.ubuntu.com/community/Installation/FromImgFiles
<mok0> perhaps
<mok0> RainCT: in the Mac OSX section it tells you have to do it with dd
<mok0> s/have/how
<RainCT> mok0: ah great, thanks!
<kirkland> ogra: http://pastebin.com/f94d727b
<kirkland> ogra: that's the build annoyance I'm seeing, hoping you can fix for me
<ebroder> Anybody from ubuntu-sru who could look at bug #330766?
<ubottu> Launchpad bug 330766 in pulseaudio "pulseaudio hangs, prevents login, home as ntfs" [Unknown,Fix released] https://launchpad.net/bugs/330766
<ion> keybuk: Heh
<Keybuk> what moron invented a syntax that changes behaviour depending on the *tense* of the config file
<Keybuk> oh
<Keybuk> me
<ion> :-P
 * Night-Horse away
<ion> Thanks for the information! We appreciate it!
<cjwatson> Keybuk: you should require correct use of the subjunctive mode too
<cjwatson> er, mood
<cjwatson> "let variable be value" or some such
<ion> keybuk: So, that change, and i should be able to use the ubuntu-boot updates (and have a booting system)?
<ion> Or at least a system iâd be humanly able to fix :-)
<cjwatson> for bonus points, make the subjunctive have some kind of counterfactual meaning
<Keybuk> ion: you can just upgrade now
<Keybuk> the fix is in ubuntu-boot
<Keybuk> though I would appreciate before/after bootcharts
<ion> How about a config parser that uses a wigger mode on Mondays, a rastafarian mode on Tuesdays, a pirate mode on Wednesdays etc?
<ion> keybuk: Alright
<ion> yarr, start on startup, ye scurvy dog
<Keybuk> avast apache
 * Keybuk senses an initctl easter egg
<ion> :-)
<jdstrand> slangasek: I'm looking at https://bugs.launchpad.net/ubuntu-release-notes/+bugs for submitting a bug, as you advised ealier. What I see there seems to be bugs and not features. I have some feature items to add to the release notes. is that still the appropriate place?
<slangasek> jdstrand: mmm, the release notes don't discuss features
<jdstrand> slangasek: I might be using the wrong term then, sorry
<slangasek> jdstrand: the https://wiki.ubuntu.com/KarmicKoala/TechnicalOverview that you looked at before carries through to release time, but is not what we link to as "release notes"
<jdstrand> slangasek: where do I go to add new features? I seem to remember we had something in the wiki in the past that talked about all the cool new stuff going on
<slangasek> sure, that's the page
<slangasek> https://wiki.ubuntu.com/KarmicKoala/TechnicalOverview
<jdstrand> slangasek: ok thanks :)
<ScottK> slangasek: What do you think about having LP do a test rebuild of Karmic now that we're past FF?  I'm opportinistically finding a fair number of gcc 4.4 related build failures.  I think a rebuild would be helpful.
<ScottK> slangasek: I think Universe could definitely use it.
<ScottK> Trying to fix the cyphesis-cpp FTBFS I've found issues in 3 of 4 packages I touched.
 * ScottK tosses in a reminder about wfmath/426401
<slangasek> ScottK: in favor of it; though there's been turnover in the IS team so I'm not sure what the odds are of actually getting that rebuild going in the short term
<cjwatson> we can do test rebuilds without much IS involvement now, although I don't think we can make them use their own output yet
<wgrant> LP rebuilds are a little less heavyweight than the old ones.
<wgrant> Right, they don't publish at this point.
<cjwatson> I can kick one off tomorrow, if having the PPAs MUNCHED TO DEATH won't inconvenience anyone too badly
<cjwatson> somebody might want to mail me a reminder though
<ScottK> cjwatson: Even that would have surfaced two of the three issues I found, so I think it's good.
<wgrant> cjwatson: The priority issue is fixed -- they will score way behind even retried PPA builds.
<cjwatson> I wown't have time to actually deal with the output though
<cjwatson> wgrant: ah, cool
<wgrant> Even behind langpacks, in fact.
<ScottK> cjwatson: As long as the output is available, it'll be a useful QA tool.
<slangasek> cjwatson: who are the set of people who can do that? buildd admins?
<wgrant> There is an LP issue at the moment which will cause some of those builds to fail to upload, but that shouldn't matter due to the lack of publishing.
<cjwatson> slangasek: I can't remember at the moment; seems plausible but my browser just died and I want to go to bed rather than rebooting it. :-)
<wgrant> ('some' being only those that haven't succeeded before)
<slangasek> ok. :)
<cjwatson> slangasek: at the very least I would expect anyone in the TB to be able to do it
<cjwatson> but I'll see if I can track down more precise permissions for you later ...
 * ScottK gets back on the road.
#ubuntu-devel 2009-09-09
<ion> keybuk: Huh. mountall seems to say that / is mounted and that FHS is mounted and let rc-sysinit begin, even though / is still mounted readonly. Then mountall seems to receive an udev event about the / partition appearing, and proceed to fsck / while rc is trying to get the system started (with everything screaming about not being able to write to /).
<Keybuk> that's odd
<Keybuk> I don't think it does that here
<ion> keybuk: If fsck makes changes to the / partition, i manage to login via getty and then the system reboots suddenly.
<Keybuk> I'll investigate
<Keybuk> do you have the debug log?
<ion> I wonder what's the best way to get one? mount a tmpfs at /mnt before mountall in mountall.conf and redirect the output to a file in there?
<Keybuk> oh
<Keybuk> I see
<Keybuk> it triggers FHS too early
<Keybuk> and it looks like it doesn't clear the needs remount flag either
<Keybuk> will fix tomorrow
<Keybuk> oh
<Keybuk> I've fixed this already
<Keybuk> I just hadn't applied the patch
<ion> :-)
<NCommander> pitti, you around?
<TheMuso> NCommander: Likely in bed.
<arand> I'm using quilt to add a patch to a package (for SRU), but I notice that an older patch has a one-line offset when applying it, should it be refreshed or should I just leave it alone?
<slangasek> arand: for SRU, I don't think it's worth bothering with
<arand> slangasek: aknowledged.
<ArneGoetje> YokoZar: no need to worry
<johanbr> dtchen, that "15 sec latency" bug I was talking about... https://bugzilla.redhat.com/show_bug.cgi?id=521276
<ubottu> bugzilla.redhat.com bug 521276 in gstreamer-plugins-good "Something about jitter buffer makes VoIP over GStreamer useless (delay around 15 sec)" [High,New]
<johanbr> it's fixed by a gstreamer patch in git: http://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=058776bcf1ab218b509d19685a0b528d71c65f98
<dtchen> johanbr: yep, i saw it earlier, but i'm not in a position to do much about it presently
<johanbr> alright
<johanbr> patching and rebuilding the current karmic package makes everything work as expected
<johanbr> would an lp bug be useful?
<dtchen> johanbr: absolutely
<johanbr> alright, just a few minutes
<ion> keybuk: Still around?
<jumpingjack> hello! anybody here? i need some advices :)
<hyperair> !ask | jumpingjack
<ubottu> jumpingjack: Please don't ask to ask a question, simply ask the question (all on ONE line, so others can read and follow it easily). If anyone knows the answer they will most likely reply. :-)
<jumpingjack> Is there way in ubuntu to get the text under mouse cursor everywhere on the desktop? What language or framework i should use? I'm new in linux, so i need a help with starting..
<jumpingjack> i don't need a solution, i need a way to start from
<pitti> Good morning
<pitti> Keybuk: well, I left my comment in the bug; that was a bit too trigger-happy IMHO
<pitti> NCommander: hi
<NCommander> pitti, I got a question on calibre, you moved a bug onto python-qt4 which is RC, but pyqt doesn't promise a stable ABI,so calibre needs a binNMU to get going again
<NCommander> (I think, I have yet to test that theory)
<pitti> NCommander: but a followup upload was said to not fix it..
<pitti> well, I could never reproduce it myself anyway
<NCommander> pitti, I want to move the bug back to calibre, its currently blocking pyqt4 into testing (which in turn has KDE blocked). It doesn't seem toi be a pyqt4 issue specifically
<NCommander> (kdebindings is chugging along just fine)
<pitti> well *shrug* sure
<dholbach> good morning
<didrocks> morning o/
<dholbach> heya didrocks, hi amitk
<didrocks> hey dholbach :)
<amitk> morning dholbach
<apachelogger> asac: so... firefox installer is in main and on the latest cd images, time to resolve the remaining issues ;) ... I didn't find a firefox icon in the app-install data (+ I think Kubuntu doesn't have the data installed currently), so I suppse the only options we have is getting TB approval or detach the icon from the branding package (i.e. create a seperate package for the icon)
<apachelogger> shtylman is going to come up with a kubuntu-installer-style packag ethat can be shared among ubiquity and k-f-i, so we can free additional CD space :)
<dholbach> pitti, seb128: what do you think about bug 407817?
<ubottu> Launchpad bug 407817 in gnome-icon-theme "gnome-icon-theme does not allow alternative start-here icons" [Low,New] https://launchpad.net/bugs/407817
<dholbach> bdrung_ worked hard on it
<dholbach> sorry, fell out of the internet
<dholbach> pitti, seb128: what do you think about bug 407817?
<ubottu> Launchpad bug 407817 in gnome-icon-theme "gnome-icon-theme does not allow alternative start-here icons" [Low,New] https://launchpad.net/bugs/407817
<dholbach> bdrung_ worked hard on it
<seb128> dholbach, I don't like alternative much and I don't think a distro specific hack is the way to go there
<seb128> dholbach, I think the logo icon to use should rather be a gconf key
<dholbach> bdrung_: ^ what do you think?
<bdrung_> seb128: what do you mean with "distro specific hack"?
<seb128> what are you trying to do? allow customization of the gnome-panel menu icon?
<bdrung_> gconf would be a solution, too.
<seb128> gconf would work on any distro
<bdrung_> seb128: yes
<seb128> and not rely on alternatives which is a debian,ubuntu thing
<seb128> it would also allow users to change the icon
<seb128> rather than having a system setting you can't change
<bdrung_> that's a good point
<bdrung_> when we have a gconf key for that, you can drop my changes
<mr_pouit> seb128: Bug #253416 << maybe gnome-panel checks before displaying the issue, but it still installs a desktop file
<ubottu> Launchpad bug 253416 in ubuntu "[Xubuntu] yelp can not find ghelp:about-ubuntu" [Low,New] https://launchpad.net/bugs/253416
<mr_pouit> so another menu system will display itâ¦
<seb128> I'm too busy today to start a discussion about that
<mr_pouit> of course (!)
<mr_pouit> I don't think adding something like NotShowIn=XFCE; (or similar) needs a big discussion
<mr_pouit> (instead of reaffecting the bug to something else)
<seb128> the entry has nothing to do there in fact I think
<seb128> it should rather be moved in the documentation
<seb128> and gnome-panel should be patched to display it if available
<ogra> kirkland, using -s in the debhelper invokations might help
<kirkland> ogra: i'll try that
<kirkland> ogra: which ones?
<ogra> kirkland, all under the binary-static target i think+
<ogra> s/+//
<kirkland> ogra: hmm, that didn't work
<kirkland> dpkg-gencontrol: error: current host architecture 'amd64' does not appear in package's architecture list (i386)
<kirkland> +
<ogra> kirkland, well, just add amd64 to Architecture then
<ogra> though -s should work as i understand it
<ogra> "It understands that if the control file lists "Architecture: i386" for the package, the package should not be acted on on other architectures. " from the manpage
<kirkland> ogra: hrm
<ogra> just add amd64 to Architecture: ... will just get me some more bugs for the binary i guess
<ogra> there is no reason it shouldnt build, i just think the syscall translation layer doesnt work so well on amd64
<ogra> doko, hey !
<ogra> doko, "debian/*.shlibs: Update to the version from the branch." ... could that solve my ld-linux3-dev issues with the d-shlibs override ?
<ogra> (from your binutils upload
<ogra> )
<doko> ogra: no, I don't think so
<ogra> meh, ok
 * ogra had hopes :)
<pitti> tseliot: do you happen to have some time to test the intrepid-proposed nvidia-common in bug 303825?
<ubottu> Launchpad bug 303825 in nvidia-common "linux-image-2.6.27-9-generic failed to install/upgrade : run-parts: /etc/kernel/postinst.d/nvidia-common exited with return code 10" [Undecided,Fix committed] https://launchpad.net/bugs/303825
<tseliot> pitti: sure
<YokoZar> doko: just a poke about the python2.6 stuff I filed/subscribed you to earlier (the FTBFS is blocking me from updating ia32-libs which in turn is FTBFSing Wine ;) )
<dholbach> YokoZar: doko is on vacation or at least travelling right now
<pitti> doko: I tried building python2.6 locally and in my PPA, and it failed three times with three different errors :-( (https://edge.launchpad.net/~pitti/+archive/ppa/+build/1207804 and https://edge.launchpad.net/~pitti/+archive/ppa/+build/1207804)
<YokoZar> ahh ok
<pitti> well, he did a binutils upload this morning :)
<dholbach> ok
<dholbach> I'm sure it's not the first time for doko to do that while on vacation ;-)
<doko> dholbach: I'm back
<pitti> doko: ah, hey! had a nice vacation?
<doko> pitti: yes, thanks!
<pitti> doko: beach and cocktail? Or the hiking/bike style? :-)
<doko> pitti: there's a promotion request pending for readline6 binaries ...
<pitti> doko: well, if we want to start the readline6 transition now, ok; but python2.6 still doesn't build
<doko> pitti: no, just running and beach
<pitti> nice
<doko> pitti: it's not a transition, there are two development packages, and the readline6 source already is in main, because of readline-common
<pitti>  readline6 | 6.0-2ubuntu2 | karmic/universe | source
<doko> pitti: which is wrong, because readline-common is in main
<pitti> ah, bug 421035 is incomplete
<ubottu> Launchpad bug 421035 in readline6 "sync & promotion request (unstable -> main)" [Undecided,Incomplete] https://launchpad.net/bugs/421035
 * pitti promotes source
<doko> ahh, this was asked while I was away ...
<pitti> ok, rest of binaries promoted
<pitti> bug updated
<doko> hmm, strange, no diffs anymore in the ui to the previous version
<pitti> seb128: retracer> *nnng* bad gateway; WTH is up with LP today?
 * pitti restarts retracers again
<seb128> pitti, edge timeout
<pitti> seb128: but apport isn't on beta-testers
<seb128> my versions script fails on similar errors
<arand> I'm poking in an SRU for glib2.0, noticing that in kk patch 61_* is added, however a 61_* patch already exists in intrepid version, should I simply use 62_* for intreipid alone or should it be changed throughout?
<doko> pitti: about the build failure: I'll see on which archs the buld fails with -fprofile-use, and then disable it on these archs
<arand> i.e. the 61_* patch in intrepid are a completely different patch, with the same number prefix.
<pitti> doko: ok, thanks; at least it shouldn't be on depwait any more in 1 hours 15 mins
<seb128> arand, the number are just for ordering
<seb128> arand, you can use any number you want
<arand> seb128: even though the same patch are going to be added in all releases, consistency in naming may be ignored?
<seb128> arand, we don't care
<seb128> the patch just need to be applied in a way which works
<seb128> the naming, ordering, etc is a detail
<spaetz> r-base is broken in Ubuntu karmic for all. Doh, could somebody apply the correct fix as described in
<spaetz> https://bugs.launchpad.net/ubuntu/+source/r-base/+bug/426360
<ubottu> Ubuntu bug 426360 in r-base "[PATCH] r-base suppresses ALL error messages forever" [Undecided,New]
<spaetz> ? It would be embarassing if that goes into karmic gold
<pitti> I subscribed the sponsoring team
<james_w> spaetz: if you subscribe "ubuntu-universe-sponsors" to bugs like this then they will get reviewed and uploaded when approved
<cjwatson> I've also subscribed Dirk Eddelbuettel, who's the Debian R maintainer but who was also responsible for this Ubuntu-specific change; he doesn't seem to be subscribed to all Ubuntu r-base bugs
<doko> cjwatson: do we plan to include dpkg 1.15.4 in karmic?
<cjwatson> possibly
<cjwatson> I haven't looked over it in detail yet but it's not out of the question
<cjwatson> doko: what do you need it for? the install-info transition?
<doko> cjwatson: yes, that would be convenient
<cjwatson> I'm not going to say yes straight away because the changelog is massive, but I'll look at it
<dholbach> did we ever come to an agreement if we want merge proposal for ~ubuntu-dev stuff on ubuntu-devel@?
<dholbach> if we don't want that stuff, I'll just reject those mails now
<dholbach> is there a way for us to turn that off?
<james_w> dholbach: well, they were explicitly turned on, so they can be turned off again
<pitti> james_w: bug 414298 ack'ed
<james_w> thanks pitti
<EricInBNE> if I want to contribute to a package in 9.10, where can I go to download the dev packages?
<EricInBNE> *new ubuntu users
<ScottK> EricInBNE: We aren't accepting new packages for 9.10 anymore.  We are concentrating on getting bugs fixed and things working.
<ScottK> !development | EricInBNE
<dholbach> james_w: hm?
<EricInBNE> ScottK, its for bugfixing an existing package
<ScottK> EricInBNE: Excellent.
<ScottK> EricInBNE: What package?
<EricInBNE> ScottK, recently changed from fedora to ubuntu.
<james_w> dholbach: there was a change made in the Ubuntu teams on LP last year such that code review emails would go to ubuntu-devel@
<ubottu> EricInBNE: Interested in becoming an Ubuntu Developer? Get started here: https://wiki.ubuntu.com/UbuntuDevelopment
<james_w> dholbach: that change could be undone if desired, but it was an explicit decision to send them there
<ScottK> EricInBNE: Welcome.
<EricInBNE> ScottK, looking to contribute to the Android execution environment.
<dholbach> james_w: ok... do you know if that was documented somewhere?
<ScottK> I see.
<james_w> not offhand
<ScottK> dholbach: Do you have suggestions for what channel EricInBNE should be asking about contributing in?
 * ScottK needs to run off for a few hours.
<EricInBNE> ScottK, is that in .10? I couldnt find it. mjfrey mentioned he is looking for a few replacement pkgs on his weblog
<ScottK> EricInBNE: I'm not sure.
<ScottK> I suspect #ubuntu-mobile would be the place to ask, but I'm not certain.
<dholbach> yep, that's what I'd say to
<dholbach> too
<EricInBNE> is launchpad the analog to rawhide? or is there another code repo
<dholbach> check out https://wiki.ubuntu.com/UbuntuDevelopment
<pitti> EricInBNE: karmic (the current Ubuntu development version) is the pendant to Fedora rawhide
<asac> cjwatson: superblock having offset of my timezone a known issue?
<dholbach> it should explain a lot about how the archive works
<cjwatson> asac: bug 423247
<ubottu> Launchpad bug 423247 in clock-setup "Superblock last mount times cause fsck to fail" [High,Fix released] https://launchpad.net/bugs/423247
<cjwatson> (probably)
<asac> ok cool
<asac> will check if update makes this go away
<liw> death to timezones! utc everywhere!
<asac> i guess there is no way to not run fsck now?
<asac> ;)
<cjwatson> asac: update? it was an installer bug
<asac> cjwatson: i get this on a regular install
<cjwatson> so upgrading will make no difference
<asac> cjwatson: second time now
<asac> its an old install
<cjwatson> install of what?
<cjwatson> oh, not my problem then :)
<asac> ubuntu?
<cjwatson> I mean what vintage
<asac> hmm
<asac> feels too similar to be not the same ;)
<cjwatson> there are lots of similar issues
<cjwatson> if it's an old install, could you talk with Keybuk?
<asac> Keybuk: ^^ ... on reboot i have to run fsck, because superblock has my timezone offset
<cjwatson> of course it could be that the old installation broke your hardware clock
<cjwatson> date; hwclock --debug --show
<seb128> I got that several times too recently
<cjwatson> cat /etc/default/rcS
<cjwatson> well, grep ^UTC= /etc/default/rcS
<asac> fsck is running ... will run that afterwards
<cjwatson> basically, one possible cause is that the hardware clock has been rendered wrong at some point in the past, and it's only fixed up by NTP once the network comes up
<seb128> I got the issue several times on karmic
<asac> cjwatson: hmm. you say the hardware clock was always wrong? or you think just intermediately during karmic?
<seb128> ie it's not only a one time problem due to old values
<asac> otherwise we need to do something because loads of users will end up with fsck ;)
<asac> seb128: i got it the second time now. feels like on every reboot where i did an dist-upgrade in between
<cjwatson> if that's the case, the way to fix your computer is to fix the hardware clock: if /etc/default/rcS says UTC=yes, then it should be the time in UTC; if it says UTC=no, it should be the current local time
<cjwatson> seb128: I only fixed the installer bug after alpha 5, a few days ago
<cjwatson> asac: I think the installer bug has been around for ages and ages
<hyperair> am i right in assuming this only happens if your system clock is in local time?
<cjwatson> hyperair: you mean hardware clock; and I don't think you're right
<asac> cjwatson: so ok. lets assume i had that installer bug. now its broken. the solution cant be to say: "fix your hardware clock" thats good for me, but not for users
<hyperair> hmm
<seb128> well, shouldn't we do something so user upgrading don't get that confusing login to manually run fsck on reboot?
<cjwatson> yes, feel free to suggest something that actually works :-)
<asac> i need to understand why it suddely started to break now
<cjwatson> I agree it's a problem but have no bright ideas
<cjwatson> asac: because Scott took out a workaround
<seb128> same as asac
<asac> it always worked till recently
<seb128> can't we keep the workaround?
<asac> so something must have changed. and thats where we probably need to fix it
<cjwatson> it introduced other problems ...
<seb128> if we don't have better ideas ...
<hyperair> what was the workaround?
<asac> we need to understand both impacts. fsck on every second reboot is worst you can get
<asac> its close to complete system breakage
<cjwatson> I don't know the details, and cannot participate further in this discussion without them
<asac> hehe
<asac> thats ok ;)
<asac> lets wait
<asac> fsck run takes about 1h anyway ;)
<directhex> oh, hurrah, requestsync now correctly doesn't allow me to sponsor my own main requests
<geser> ?
 * maxb has also seen that timezone-fsck issue twice on rebooting an existing system
<ion> keybuk: Around?
<seb128> and it's not like it was a fsck normal run in usplasg
<seb128> it's a command line prompt which invite you to run commands
<cjwatson> yes, I *know*&
<seb128> ie it's broken enough that most normal users will declare the system screwed and reinstall
<cjwatson> yes, I *know*
<cjwatson> you can stop explaining how important it is now. :-)
<geser> directhex: is this a bug or not? I'm not sure from your statement
<seb128> ok, let's wait for Keybuk to comment then
<directhex> geser, it's an unbug
<seb128> well, I have the impression that you argue that we traded an issue for an another one
<directhex> geser, i was able to run requestsync for ages to sync packages in main, and didn't need a sponsor as i'm a motu
<seb128> but apparently that was a false impression ;-)
<seb128> as long as it's on the karmic list I'm fine with it
<cjwatson> seb128: no, I'm arguing that "just put the workaround back" probably isn't the right answer, and we should actually think about it instead ;-)
<seb128> let's people who understand what's going on work on it
 * seb128 goes back to desktop land ;-)
<Keybuk> seb128: do I have to comment?
<seb128> Keybuk, no
<seb128> Keybuk, I trust you to do whatever is required to sort that for karmic ;-)
<asac> Keybuk: i would appreciate if you could explain whats the problem ;)
<seb128> better to spend your time working on the bug rather than explaining it again on IRC
<Keybuk> which bug?
<asac> Keybuk: superblock has UTC offset for me on reboot ... requiring fsck
<asac> its an old install
<seb128> same here
<Keybuk> asac: every time, or just after this one reboot?
<seb128> it doesn't happen every time though
<asac> Keybuk: its the second time in a row now
<davmor2> Keybuk: https://bugs.launchpad.net/bugs/423247 I'm assuming
<seb128> I didn't notice what trigger it yet
<ubottu> Launchpad bug 423247 in clock-setup "Superblock last mount times cause fsck to fail" [High,Fix released]
<seb128> I had the issue several times
<Keybuk> when it next happens, stop at the fsck error
<Keybuk> and grab me
<seb128> some of those have been forced reboot after a broken suspend resume
<Keybuk> you'll need to run "grep ^UTC /etc/default/rcS", "date" and "hwclock --debug --show"
<asac> Keybuk: ok. this reboot was forced reboot too
<seb128> ie, resume, computer hangs, press the power button several second, turn computer on again, get the issue
<asac> so maybe it only happens then
<asac> yea
<asac> i will try to reproduce once current fsck finishes
<Keybuk> seb128: likewise if you can reproduce, stop at the moment things are inconsistent
<seb128> ok
<ion> keybuk: I added another patch, that one removes /forcefsck in a root_hook. http://heh.fi/patches/mountall/
<Keybuk> ion: could you mail these to me, I don't keep track of IRC logs ;)
<ion> keybuk: The URL has the patches. Is that okay?
<Keybuk> ion: sure, but mail it to me ;)
<ion> Will do
<Keybuk> asac, seb128: the only clock bug that I am aware of was that the first/second reboot after installing, you'd hit the fsck error
<Keybuk> once you've passed it, it's fixed and there are no issues
<Keybuk> if you're hitting the fsck error on an installed system, you have an entirely different but that I am not familiar with
<seb128> ok, I've an entirely different bug then
<seb128> I got it several times in karmic
<Keybuk> it's possible that you two have entirely different bugs
<asac> Keybuk: colin said the clock-setup bug was around for long time in installer. you know what caused this show up now in karmic?
<seb128> and I'm pretty sure each time after broken resume and forced power aoff and on cycles
<Keybuk> "fsck has time inconsistency" is a bit like "human has a runny nose"
<Keybuk> asac might have a cold, where you might have swine flu, etc.
<Keybuk> asac: yes, I know why clock issues are showing up in karmic suddenly
<asac> my superblock time is exactly offset by my timezone
<seb128> same here
<Keybuk> asac, seb128: in which direction?  negative timezone or double timezone?
<asac> fsck says: "time == UTC", but superblock == "my timezone time"
<Keybuk> asac: don't suppose you can pastebin me the contents of your /etc/adjtime file?
<asac> fsck is currently running. i will get you that right after
<Keybuk> ok
<Keybuk> seb128: what way is the timezone math for you?
<seb128> I don't remember, I had the issue several days ago
<seb128> $ grep ^UTC /etc/default/rcS
<seb128> UTC=no
<seb128> if that matters
<seb128> I will try to power down the laptop later but not now ;-)
<Keybuk> seb128: your /etc/adjtime file would be helpful
<Keybuk> see that's interesting
<seb128> $ cat /etc/adjtime
<seb128> 0.193938 1252449040 0.000000
<seb128> 1252449040
<seb128> LOCAL
<Keybuk> the fact that you have UTC=no means that you can't possibly have the same bug as asac
<asac> Keybuk: http://paste.ubuntu.com/267881/
<asac> no adjtime at all
<seb128> re
<seb128> ok, that broke again
<seb128> I get it every time I shut down the laptop not properly
<seb128> I'm on my netbook now
<seb128> Keybuk: what info do you need?
<seb128> now =13:
<seb128> superblock = 15:...
<seb128> 13:40:20 is now
<asac> Keybuk: http://paste.ubuntu.com/267883/ ... thats --show --debug
<seb128> no rcS UTC=no
<seb128> date says 13:45:02
<seb128> hwclock says the same
<asac> let me try to reproduce now .... /me hits powerbutton
<seb128> oh
<seb128> hwclock --debug --utc
<seb128> Time read from clock ... 13:46
<seb128> Wed Sep 9 15:46
<asac> Keybuk: so i was wrong. time == "timezone time" ... superblock time == "timezone time + my timezone offset" ... so yeah double timezone offset
<seb128> so hwclock is acting as if UTC=yes was used
 * asac should better know what time it is ;)
<Keybuk> seb128: sorry rewind
<asac> i am now in the "do fsck state"
<ion> keybuk: Whoops, i hadnât re-exported the patches. The URL contains patches that actually work now. :-P
<seb128> me too
<Keybuk> seb128: what is the exact fsck output at the point it fails?
<Keybuk> asac: likewise, what is the exact fsck output right now?
<ion> keybuk: At least rm-forcefsck was broken.
<seb128> ups
<seb128> Keybuk: "/dev/sda6: Superblock last write time (Wed Sept 9 15:40:20 2009
<seb128> now = ... 13:....
<Keybuk> seb128: please, I do need the whole thing
<seb128> UNEXPECTED INCONSISTENCY
<Keybuk> don't abbreviate it
<Keybuk> the times are quite important
<seb128> 15:40:20
<seb128> 13:40:30
<Keybuk> ok, so your superblock was last written at 15:40:20
<Keybuk> and your "time now" is 13:40
<Keybuk> your time now looks correct to me
<seb128> yes it is
<directhex> hm. what's the quick way to check why a package was promoted to main?
<seb128> the 15: is two hours in the futur
<Keybuk> it's 11:50 UTC, 13:50 CET
<seb128> directhex: which one?
<Keybuk> seb128: you have UTC=no in /etc/default/rcS ?
<seb128> I've UTC=no
<seb128> yes
<directhex> seb128, libgluezilla
<Keybuk> seb128: your /etc/adjtime file has LOCAL in it?
<seb128> directhex: dunno, look for bugs
<seb128> Keybuk: yes
<Keybuk> seb128: what does "date" say?
<seb128> 13:51:38
<asac> Keybuk: http://www.flickr.com/photos/asacasa/3903749434/sizes/l/
<Keybuk> and /etc/localtime is a file not a symlink?
<Keybuk> seb128: hwclock --debug --show ?
<seb128> it's a file
<Keybuk> asac: could you provide the same bits of information as seb128
<directhex> hm, i wrote the MIR. i need to see someone over memory issues
<geser> directhex: look at the MIR bug #362854
<seb128> Time read from the hw clock ... 13:52:34
<ubottu> Launchpad bug 362854 in gluezilla "include into main" [Undecided,Fix released] https://launchpad.net/bugs/362854
<Keybuk> seb128: could you pastebin it so it doesn't get lost
<seb128> Hw clock time 13:52:34
<Keybuk> I do need the entire output
<seb128> Wed Sep 9
<asac> Keybuk: time is the same as seb
<directhex> geser, look at who wrote the MIR attached to the bug!
<seb128> Keybuk: not sure, I'm at the boot fsck prompt
<asac> Keybuk: UTC=no in rcS
<asac> Keybuk: and no adjtime file at all and localtime is not a link
<seb128> Keybuk: give me all the commands you want, I will put that to a log, reboot and pastebin
<Keybuk> asac: and hwclock output?
<Keybuk> seb128: hwclock --debug --show
<Keybuk> that's about all I can think of for now ;)
<seb128> all times are 13:...
<seb128> but --utc says 15
<asac> Keybuk: looks pretty identical to what i pasted from running session: http://paste.ubuntu.com/267883/
<asac> i can get a photo if you want
<seb128> I don't know why --utc adds 2 hours
<seb128> that doesn't make sense to me
<seb128> ie --debug --show has all to 13:
<seb128> --utc is 15:...
<Keybuk> seb128: because it does
<cjwatson> --utc assumes that your hardware clock is kept in UTC; the time that hwclock --show shows is always in local time
<cjwatson> so it's add, not subtract
<seb128> ah ok
<asac> for me --utc is correct: 11:50
<Keybuk> right, --utc isn't "show me the time in utc"
<Keybuk> it's "if the hwclock was in utc, what would the time be"
<spaetz> james_w:(and others) thanks for the ubuntu-universe-sponsors tips
<Keybuk> asac: err, that doesn't make sense
<asac> http://www.flickr.com/photos/asacasa/3903756212/
<asac> hwclock photo
<asac> Keybuk: not sure if you missed it, but i have no /etc/adjtime at all ... is that ok?
<Keybuk> asac: do that with --utc on the hwclock line as well
<Keybuk> asac: yes, that's ideal
<asac> sure
<seb128> I don't get how the superblock got a time 2 hours in the futur
<Keybuk> are you using ext4 or ext3 ?
<asac> Keybuk: http://www.flickr.com/photos/asacasa/3902980651/ ... and ext3
<asac> sorry. photo is not best quality ;)
<Keybuk> asac: did you say you had UTC=no or UTC=yes ?
<asac> Keybuk: =no
<asac> in rcS
<Keybuk> huh
<Keybuk> well, your hardware clock is in UTC
<Keybuk> isn't it?
<Keybuk> oh, no
<asac> Keybuk: the hwclock --utc output shows 1500 ... thats wrong
<Keybuk> sorry, had the images round the wrong way
<Keybuk> yes
<Keybuk> so that's correct
<asac> thats UTC + 2* offset
<Keybuk> your hardware clock is in local time
<asac> k
<Keybuk> ok
<asac> does that give any hints?
<Keybuk> everything is absoutely right
<Keybuk> could you do the fsck -y
<Keybuk> then finish booting
<Keybuk> and grab me then again
<Keybuk> let's see if it's something about the running system
<asac> everything is allright, except: http://www.flickr.com/photos/asacasa/3903749434/ :)
<asac> ok doing that now
<seb128> running fsck takes ages
<Keybuk> hmm
<directhex> yay @ whomever is on archive admin duty today
<Keybuk> Last write time:          Wed Sep  9 13:09:55 2009
<Keybuk> so that's in local time
<Keybuk> I wonder whether it's supposed to be in local time or UTC
<seb128> Keybuk, I'm back from fsck if you need infos
<arand> I seem to get that error often after update-reboots: http://imagebin.org/63162
<Keybuk> seb128: finish up the boot as normal
<Keybuk> seb128: then in the normal system, run "hwclock --debug --show" and "date" again
<seb128> Keybuk, right, I'm back at GNOME after fsck there
<Keybuk> seb128: it'd also help to have the output from "tune2fs -l YOURDISK"
<asac> http://paste.ubuntu.com/267883/
<asac> that was in the reboot state for hwclock --debug --show
<asac> my fsck hasnt finished, but thats how it was after last fsck ;)
<asac> Keybuk: ^^
<seb128> Keybuk, http://paste.ubuntu.com/267895/
<asac> btw, paste.ubuntu.com has a time issue too  i think ;)
<asac> 05:12:37 +0000 for seb128's paste
<Keybuk> seb128: thanks, now try "tune2fs -c 29 /dev/sda6" then "tune2fs -l /dev/sda6"
<seb128> Keybuk, http://paste.ubuntu.com/267898/
<Keybuk> ok
<Keybuk> so your "last write time" is in CET
<Keybuk> (in tune2fs output)
<Keybuk> now could you run "shutdown now" (no -h plz)
<Keybuk> that'll take you down into single user mode
<Keybuk> from there you should be able to "mount -o remount,ro /"
<seb128> let me restart my IRC on the netbook so I'm still online while doing that ;-)
<asac> Keybuk: i assume you dont need me until finished with seb128 ? otherwise system has booted
<Keybuk> asac: if you could do the tune2fs bits, that'd be helpful
<asac> k
<asac> but not the shutdown?
<Keybuk> not yet, just tune2fs first
<Keybuk> one step at a time
<asac> kk
<Keybuk> want to check what your last write times are in the "up" system
 * ogra is fishing for an idea ... 
<ogra> i have a static qemu wrapper that enables me to build and use chroots with arm binaires on x86 using the binfmt systemn
<asac> oh no
<asac> X hanged
<asac> right when i wanted to copy the past
<ogra> if i chroot into such a chroot, i can apt-get install ubuntu-desktop ...
 * asac typing
<ogra> my prob is that as soon as it comes to mono, the install hangs
<asac> http://pastebin.com/f40cfa057
<asac> Keybuk: ^^
<pitti> Keybuk: ubuntu boot testing> yay!
<ogra> simply because mono installs an armel binfmt wrapper *inside* the chroot ... which indeed cant execute
<seb1281> Keybuk: ok, got prompt and remount
<seb1281> next?
<Keybuk> remount succeeded?
<seb1281> yes
<Keybuk> wow
 * Keybuk has to SysRq that
<Keybuk> now try fsck -a /dev/sda6
<seb1281> clean
 * ogra wonders if anyone has an ide how to wrap binfmt wrappers in binfmt wrappers 
<ogra> *idea
<seb1281> Keybuk: it says the disk is clean
<Keybuk> seb1281: ok...
<Keybuk> seb1281: sh -x /etc/init.d/hwclock.sh stop
<Keybuk> I'm interested in the line that calls hwclock
<seb1281> /sbin/hwclock --rtc=/dev/rtc0 --systohc --localtime
<Keybuk> ok
<Keybuk> hwclock --debug --show
<Keybuk> all the times still right?
<seb1281> yes
<Keybuk> and tune2fs -i /dev/sda6
<Keybuk> what's the "last write time" ?
<seb1281> -j?
<Keybuk> err -l sorry
<cjwatson> ogra: are you sure that the problem is one of wrapping? because I'm pretty sure that the kernel uses the normal exec path when it executes binfmt handlers, including binfmt_misc itself; I know this because when I was writing binfmt-support first, I installed an ELF handler for the ELF binary format as a test, and my system fell over :-)
<seb1281> 14:24:44
<seb1281> ie correct
<Keybuk> seb1281: ok, "reboot -f" from here
<Keybuk> does the system come up without an fsck?
<arand> Seems like I was able to create the fsck issue by running "dkpg --configure -a" && "apt-get -f install"
<cjwatson> ogra: it wouldn't just be that the mono handler installed inside the chroot conflicts with the one outside the chroot?
<seb1281> ie, reboot?
<ogra> cjwatson, well, binfmt looks for the magic in the binary
<ogra> and then execs the wrapper
<Keybuk> seb1281: yes, but using that command
<cjwatson> ogra: or indeed that the kernel doesn't honour the chroot-ness when executing the binfmt handler
<cjwatson> ogra: yeah, I know how binfmt works :-)
<ogra> in my case it would additionally have to wrap a call to qemu-arm-static around that
<cjwatson> no, I suspect that the problem is that binfmt_misc is executing the binfmt handler outside the chroot
<ogra> yes
<cjwatson> the call to qemu-arm-static would be implicit if it were *actually executing an arm binary*
<cjwatson> but it isn't
<seb1281> Keybuk: yes, no fsck it boots just fine
<ogra> qemu-arm-static is static because it's in the chroot ;)
<cjwatson> it's executing the i386 handler for the same thing outside the chroot
<ogra> right
 * seb1281 wonders if it would be faster for keybuk to set UTC=no and sit on the power button too ;-)
<cjwatson> the only way I can think of to fix this would be for binfmt-support to somehow figure out the path from the real root to the chroot, and prefix everything with that
<cjwatson> but then it would also have to resolve conflicts between handlers inside and outside the chroot
<cjwatson> this gets *very* complex ...
<ogra> but that would mean to fiddle with the host install
<pitti> seb1281: FYI, libgdata packaging/security looks fine; waiting for MIR to get rationale/maintainer/subscriber/i18n check, etc.
<ogra> yeah, that whole thing is very complex
<seb1281> pitti: thanks
<ogra> but will rock once it works :)
<seb1281> pitti: I will do that later if nobody beats me to it (which I doubt I've been trying to find olunteers for a week without success now)
<seb1281> chrisccoulson said he would do it if nobody does
<seb1281> but I prefer him to keep working on the bugs he's tracking ;-)
<cjwatson> ogra: yes, at the moment I don't think this can be done without fiddling with the host
<ogra> hmm, k, i'll think about a not to evil way for that
<cjwatson> a more elegant approach would probably involve binfmt_misc recognising and remembering the filesystem namespace of the process registering a handler with it
<cjwatson> I think that would be a really good thing to fix, actually
<cjwatson> userspace isn't really the right place to deal with this
<ogra> right, my biggest prob is currently that i want some tool like livecd-rootfs that rolls an armel rootfs
<ogra> if i can somehow have something wrapped around the chroot calls inside that script it would already massively help
<ogra> oh, you would fix it in-kernel ?
<cjwatson> ogra: yes, I think that makes a lot more sense
<ogra> indeed
<cjwatson> the kernel should invoke the binfmt handler in the same filesystem namespace that registered it in the first place
<ogra> though i dont see that solving my prob
<cjwatson> it would solve it perfectly, as long as it could cope with having different handlers for the same thing in different namespaces
<ogra> if the kernel invokes "/usr/bin/cli" from the binfmt_misc handler, it doesnt matter where /usr/bin/cli actually lives
<cjwatson> yes, it really does
<ogra> since /usr/bin/cli needs to be executed by qemu-arm-static
<cjwatson> you misunderstand :-)
<ogra> oh, wait, binfmt looks only at the magic
<cjwatson> if it executes /usr/bin/cli in the chrooted filesystem namespace, then that /usr/bin/cli will be an arm executable, and so when it execs it it'll go through its binfmt handlers again and find that it needs to use qemu-arm-static to execute that binary
<ogra> so it *would* use qemu-arm-static because the magic inside the chroot is the right one
<ogra> yeah, sorry, i was dense for a second
<ogra> indeed
<ogra> thats the stacked scenario i was looking for
<Keybuk> seb128: so what causes you to hit fsck?
<cjwatson> right, all that already works, the bit that doesn't work is just the namespacing
<ogra> yup
<seb128> Keybuk, press the power button for some seconds to shutdown the box
<seb128> Keybuk, on next boot I get the issue
<Keybuk> next "normal" boot
<Keybuk> or next boot with unclean shutdown?
<seb128> Keybuk, ie sit on the button to force powerdown don't let the soft do the job
<blackxored> hello
<seb128> force the box down by sitting on the button
<seb128> and press the button once again to turn it on
<Keybuk> seb128: what about force by S U B ?
<seb128> S U B ?
<Keybuk> seb128: Alt+SysRq S U B
<ion> My laptopâs keyboard makes S and B possible, but not U. :-)
<seb128> Keybuk, let me try
<cjwatson> what, alt+sysrq involves fn+u or something?
<cjwatson> get a better laptop :-)
<ion> You have to hold down fn to get sysrq from the delete key, and U happens to be one of the letters that do something else (numpad-4) with fn.
<Keybuk> on some laptops you have to do Alt+Fn+SysRq, then release the Fn key, while still holding down Alt+SysRq to press S then U then B (individually)
<Keybuk> on other laptops, like the dells, you do Alt+PrntScrn
<ion> keybuk: Iâll have to try that.
<Keybuk> seb128: could you file a bug on e2fsprogs with this information
<Keybuk> title should be something like "after hard power off, fsck on boot fails because last mount time is in the future"
<Keybuk> attach all the bits you've gatherered
<Keybuk> (then I get Ted to look as well)
<soren> ion: You can let go of the Fn key once you've pressed sysrq.
<seb128> Keybuk, no fsck when rebooting this way
<seb128> let me try something
<ogra> cjwatson, hmm, actually that sounds like an easy way to do harmful stuf from within a chroot ...
<cjwatson> ogra: I disagree; it actually fixes a trivial way to break out of the chroot
<seb128> Keybuk, I tried a suspend cycle to see if that changed some values on the filesystem but no
<ogra> as long as i know what binfmt support is installed on the host i could actually break out of my chroot
<cjwatson> unless you mean the current situation
<Keybuk> seb128: so safe sync/unmount cycle does not cause this
<Keybuk> but forced power off causes it every time for you?
<ogra> cjwatson, i mean the current behavior
<ogra> :)(
<seb128> Keybuk, I would say yes, it happened 3 times on 3 forced shutdown so far
<ogra> sounds like a serious security issue
<cjwatson> ogra: not really hugely serious since there are loads of ways to break out of chroots anyway, but yeah
<Keybuk> ok
<cjwatson> ogra: but yeah, I think I thought about that at more or less the same time you did :)
<ogra> heh
 * ogra takes a break ... to much mono found its way into my brain today ... 
<highvoltage> ogra: ouch!
<tseliot> pitti: the fix for bug 303825 works here (I had to install Intrepid to test it). I added a comment in the bug report.
<ubottu> Launchpad bug 303825 in nvidia-common "linux-image-2.6.27-9-generic failed to install/upgrade : run-parts: /etc/kernel/postinst.d/nvidia-common exited with return code 10" [Undecided,Fix committed] https://launchpad.net/bugs/303825
<Keybuk> seb128: I can replicate this
<Keybuk> you do need UTC=no
<Keybuk> and you do need to force the power off, rather than unmounting safely
<Keybuk> and the best bit is, dumpe2fs and e2fsck are disagreeing about the last write time of the superblock ;)
<seb128> ah good
<seb128> I was pondering trashing my netbook install to have a test box
<seb128> but if you get the issue it's better ;-)
<pitti> tseliot: thanks
<ion> keybuk: Bootcharts, as requested. http://heh.fi/tmp/ubuntu-boot/
<ion> Dunno why the bar height is different in the charts.
<cjwatson> seb128: did you see Martin's comment in bug 351577 to the effect that you should go ahead and add the build-dep to evolution?
<ubottu> Launchpad bug 351577 in libpst "[MIR] libpst" [Undecided,Fix committed] https://launchpad.net/bugs/351577
<seb128> cjwatson, yes but current evolution requires a new lib version which fails to build and I didn't manage to sort that yet...
<seb128> cjwatson, thanks for the reminder though ;-)
<cjwatson> likewise tracker->vala apparently
<seb128> dunno about this one, was the bug from chrisccoulson?
<cjwatson> yes
<ScottK> cjwatson: Yesterday when I asked about an LP archive rebuild, you said something about a reminder today, so here it is.
<cjwatson> ScottK: oh yes, thanks
<ScottK> NP
 * cjwatson tries to remember the runes
<seb128> cjwatson, he's not on IRC right now but I will ask him about it when he joins later
<cjwatson> thanks
<jjardon> asac, ping
<asac> jdstrand: please ask directly if my nick is here ;)
<jjardon> hello, some time ago I told you about the posibility of a upgrade of mobile-broadband-provider-info package
<jjardon> because it has some new providers
<jjardon> Could you upgrade the package now?
<cjwatson> ScottK: building now. https://launchpad.net/ubuntu/+archive/test-rebuild-20090909
<ScottK> cjwatson: Thanks.
<cjwatson> I didn't bother building on lpia
<Keybuk> seb128: I think I've cracked this bug
<Keybuk> and I'm going to start pulling faces at Ted Tso
<Keybuk> it's an ext3/4 bug
<ebroder> Can anybody from ubuntu-sru ACK bug #330766? It's affecting our site deployment when users run out of quota
<ubottu> Launchpad bug 330766 in pulseaudio "pulseaudio hangs, prevents login, home as ntfs" [Unknown,Fix released] https://launchpad.net/bugs/330766
<seb128> Keybuk, oh, good job ;-) let me know if you open any launchpad or upstream bug about the issue
<Keybuk> seb128: can you please confirm though
<Keybuk> are you using ext3 or ext4
<Keybuk> that's very important
<seb128> ext3 on all my machines
<Keybuk> are you *sure* on the netbook?
<seb128> yes
<Keybuk> if it's running karmic, did you go out of your way to use ext3 not ext4
<Keybuk> can you give me /var/log/dmesg from that computer
<seb128> I used the netbook to do IRC, not to try the bug
<Keybuk> ah right, dmesg from the machine with the bug
<seb128> that's my d630, I installed intrepid and didn't reinstall since
<seb128> just upgraded
<Keybuk> sure
<seb128> what do you want in the dmesg?
<Keybuk> just the whole log please
<seb128> Keybuk, http://people.canonical.com/~seb128/dmesg
<seb128> Keybuk, sda6 is the partition which triggers the fsck
<seb128> "[   21.959392] EXT3 FS on sda6, internal journal"
<Keybuk> sweet
<Keybuk> [    3.696914] EXT3-fs: sda6: orphan cleanup on readonly fs
<Keybuk> [    3.710783] ext3_orphan_cleanup: deleting unreferenced inode 4636785
<Keybuk> [    3.710803] EXT3-fs: sda6: 1 orphan inode deleted
<Keybuk> [    3.710804] EXT3-fs: recovery complete.
<Keybuk> [    3.712723] EXT3-fs: mounted filesystem with writeback data mode.
<Keybuk> that was the important bit from yours
<seb128> Keybuk, ok, thanks
 * Keybuk can't stop grinning about this
<ogra> inodes are overrated anyway
<Daviey> ogra: they are until you run out. :)
<ogra> i have a pot with them on the desk and a funnel on my disk :P
<cjwatson> ogra: can you make ltsp-client-core stop depending on unionfs-fuse? I assume you're using aufs again ... see bug 379952
<ubottu> Launchpad bug 379952 in unionfs-fuse "Main inclusion request: unionfs-fuse" [Undecided,Incomplete] https://launchpad.net/bugs/379952
<ogra> cjwatson, hrm, i thought stgraber did that already
<ogra> kirkland, did the change work ?
<kirkland> ogra: no :-(
<ogra> huh ?
<kirkland> ogra: Build Log: https://launchpad.net/~kirkland/+archive/ppa/+build/1209629/+files/buildlog_ubuntu-karmic-amd64.qemu-kvm_0.11.0~rc2-0ubuntu3~ppa1_FAILEDTOBUILD.txt.gz
<ogra> you made it Architecture: i386 amd64 ?
<kirkland> ogra: funny, that works when i build locally (just adding amd64 to the Architecture list)
<kirkland> ogra: yeah, that exactly ... that builds fine on my laptop
<kirkland> ogra: but not when i push it to the ppa or buildd
<ogra> might need the -s too
<ogra> i know the buildds runs stuff in a slightly different order than debuild
<ogra> erm, in your log it doesnt even build it
<liw> I have a new computer-janitor package that I would like to have uploaded; it has bug fixes only; are we late enough in the cycle to require an exception process?
<liw> hm, I think we are
<jdub> StevenK: does go-home-applet need to depend on netbook-launcher?
<cjwatson> liw: bug fixes only are fine at the moment without any particular kind of exception process
<liw> cjwatson, good, thanks
<geser> kirkland: try passing --binary-arch if you want to simulate an amd64 build on the buildd with your pbuilder
<geser> kirkland: the problem is: on the i386 buildd the binary target is used, which depends on your binary-static, binary-indep and binary-arch targets, on amd64 only the binary-arch target is called and it doesn't depend on the binary-static target so no qemu-arm-static is getting build
<ogra> geser, oh, thats a good hint ... i dont get why -s isnt respected by debhelper at all though
<geser> ogra: it isn't? what makes you believe it?
<ogra> geser, kirklands local tests
<ogra> geser, when he added -s across the board to all debhelper calls in binary-static having qemu-arm-static as Architecture: i386 in control, a build on his amd64 still attempted to run the debhelper stuff in binary-static
<geser> ogra: it depends how kirkland called his pbuilder. Without the --binary-arch option it behaves like the i386 buildd even on amd64 -> the "binary" target gets called which calls then binary-static
<ogra> well, depends also if he even uses pbuilder :)
<geser> ogra: the manpage for debhelper doesn't say if -pqemu-arm-static will build it regardless of any architecure setting (and any -a or -s flag), need to look into the source
<ogra> well, as i understand the manpage it should only build i386 with "-s -pqemu-arm-static"
<ogra> (if it is Architecture: i386 at least)
 * amitk is wondering why showkey is complaining of a missing file descriptor
<amitk> showkey
<amitk> Couldn't get a file descriptor referring to the console
<ogra> buy another console :)
<amitk> ogra: that would mean getting a new dev box too, same error on 64bit karmic
<amitk> nevermind, it seems to require sudo. Weird error message though.
<cjwatson> ogra: -pqemu-arm-static will build that specific package even if -s isn't given
<ogra> yeah, strace agrees
<cjwatson> if you don't want that, change debian/rules
<ogra> cjwatson, but if -s is given ?
<cjwatson> then you get the combination of (same-arch packages) and (qemu-arm-static)
<cjwatson> they concatenate
<ogra> ah
<zul> I forget do we need a FFE for a merge from debian that fixes a bug in launchpad
<cjwatson> zul: not if it doesn't add features
<zul> cjwatson: thanks
<geser> ogra: my perl is not the best, but if I understood the debhelper code correct -s -p is OR and not AND combined, so a package specified in -p gets added always to the list of packages to do
<ogra> geser, yes, thats what cjwatson said :)
<kees> Keybuk: you mention network filesystems in the boot testing call.  I use autofs for my NFS, not static mounts -- is this still a problem?
<Keybuk> kees: autofs should be ok
<liw> does anyone here have skype, acroread, or google-earth installed from .debs? if so, could you give me the exact package names?
<slangasek> mathiaz: are you doing the seed change for bug #424051?
<ubottu> Launchpad bug 424051 in ubuntu-meta "FFe: Install apport in ubuntu-server by default" [Wishlist,Confirmed] https://launchpad.net/bugs/424051
<slangasek> (I see that you're subscribed)
<mathiaz> slangasek: I can do that
<mvo> liw: picasa is another common one
<mathiaz> mvo: hi!
<mathiaz> mvo: did you get a chance to look at bug 413789?
<ubottu> Launchpad bug 413789 in mysql-dfsg-5.1 "mysql-server has been kept back with dist-upgrading" [High,Triaged] https://launchpad.net/bugs/413789
<mvo> mathiaz: no, sorry
<mathiaz> mvo: I've subsribed to the bug - is that enough to get it on your radar?
<mvo> mathiaz: not currently :( I have it on my radar now, but for urgent stuff I need irc pings currently, I'm way behind with bugmail
<mathiaz> mvo: allright - I'll keep that an eye on it too - thanks!
<mvo> thanks
<slangasek> Keybuk: ok, shall we stop abusing #-meeting? :)
<Keybuk> slangasek: but I like abuse!
<Keybuk> err, wait
<slangasek> Keybuk: so the only delta vs. what I've sent to Joey should be for the handling of upstart-native jobs, and the maintainer script fixups to remove existing init scripts
<Keybuk> yes, I think so
<slangasek> the latter can be sent upstream, the former can be kept as an Ubuntu delta right now since Debian can't have any native upstart jobs yet anyway
<Keybuk> and the maintainer scripts using upstart commands rather than invoke-rc.d (which doesn't work)
<mathiaz> Keybuk: hi! I'm looking at the server seed in karmic and there are two wireless packages in there (wireless-tools and wpasupplicant - the latter with your name beside it)
<mathiaz> Keybuk: is there a reason to have these in the default server install?
<slangasek> Keybuk: no, that's a bug in upstart-job, it exists to give init script compat and it's not doing it if start-if-started returns an error. :)
<Keybuk> slangasek: it's a bug in insserv actually, it doesn't know about upstart-job
<Keybuk> and it's a bug in invoke-rc.d because *it* doesn't know about upstart-job
<kees> slangasek: do you have a moment to look at bug 426658 ?
<ubottu> Launchpad bug 426658 in pam "Today I have upgraded the PAM from 1.0.1-9ubuntu1 to 1.0.1-9ubuntu1.1 on Jaunty. After the upgrade, I cannot seem to unlock the screen after gnome-screensaver locks it. I am still able to login in gdm, or in the virtual console." [Undecided,New] https://launchpad.net/bugs/426658
<Keybuk> ie. they don't *call* upstart-job to ask
<Keybuk> and even if they did, for upstart-native jobs, the reply would be "what's a runlevel?"
<slangasek> Keybuk: oh; well, that's a bug pere committed to fixing, yes
<slangasek> kees: yes, drilling into that this morning
<kees> slangasek: ok, thanks
<kees> slangasek: anything I can help with?
<slangasek> kees: make sure unix_chkpwd still has right perms in the package
<slangasek> otherwise, I can't see how it's a pam bug
<Keybuk> slangasek: uploaded a boot6 with --replace inverted to --upstart-only, and the "upstart (>= 0.6.0)" dep used in the upstart-only case only
<Keybuk> if you don't mind, you have a better rapport with Joey than me, do you mind feeding him the changes?
<ScottK> liw: For skype you get choices.  skype-ubuntu-intrepid, skype-ubuntu-hardy, skype-debian.  I'm currently using the Debian one (for Lenny) because it seemed to work best on Karmic.
<slangasek> Keybuk: sure, will do
<Keybuk> slangasek: you're right, --upstart-only is better
 * Keybuk has to modify less <g>
 * slangasek grins
<kirkland> mdz: soren: I just saw the minutes from the tech board, that sun-java is being removed...  so I should be trying to move alfresco to use openjdk for the appliance images?
<mdz> kirkland, those are based on 9.04 afaik
<mdz> or expected to be, since that's where alfresco is available
<kirkland> mdz: ah, okay
<kirkland> mdz: i can roll with that
<soren> kirkland: Yes. Did you not get my e-mail on the subject?
<kees> slangasek: unix_chkpwd is ok
<slangasek> pitti: bug #426905> since ubuntu-desktop Recommends: empathy, won't it be pulled in on (approximately) /all/ systems on upgrade?
<ubottu> Launchpad bug 426905 in computer-janitor "Please offer pidgin for cleanup" [Low,Triaged] https://launchpad.net/bugs/426905
<seb128> slangasek, that's the intend I think
<slangasek> seb128: right, so pretty much everyone will get the offer to remove it
<seb128> slangasek, well, seems we have little clue about how the janitor is working
<seb128> will that happen in the dist-upgrader?
<seb128> or is that something users go to do some cleaning
<arand> kees: I think I've done what I can on Bug #418135 . I'm not sure if my suggestion for the hardy patch is the best idea (eepecially since I only half-know what I'm doing), or what to do about dapper (does the bug even affect a server version)?
<ubottu> Launchpad bug 418135 in glib2.0 "Permissions of symlinked source file/folder set to 777 if symlink is copied via nautilus" [Undecided,Confirmed] https://launchpad.net/bugs/418135
<mathiaz> slangasek: re bug 424051 - I've added apport to the server seed in ubuntu.karmic. Is there anything else that shoud be done?
<ubottu> Launchpad bug 424051 in ubuntu-meta "FFe: Install apport in ubuntu-server by default" [Wishlist,Fix committed] https://launchpad.net/bugs/424051
<kirkland> soren: i did, i was going to work on that today
<kirkland> pitti: hey, some users are complaining about the .face not being accessible in encrypted-home setups
<slangasek> mathiaz: you can do an ubuntu-meta upload if you wish :)
<kees> arand: yeah, I think that sounded like a reasonable approach.  I'll double-check it too.
<kirkland> pitti: i have a suggestion how we could hack around this
<pitti> kirkland: oh, indeed, and neither ~/.dmrc, I suppose (which has your default session)
<mathiaz> slangasek: hm well - it doesn't need to be in the default install right *now*
<kirkland> pitti: i see where debian/patches/09_gdmsetup.patch tries a few different locations
<mathiaz> slangasek: so I'll rely on the next upload :)
<slangasek> mathiaz: heh, ok
<kirkland> pitti: i was going to add a check to look for it in /home/.ecryptfs/$USER/.face
<kirkland> pitti: and modify the About Me thingy to copy .face there, if that dir exists
<kirkland> pitti: what do you think?
<pitti> kirkland: ah, great idea; same for ~/.dmrc?
<kirkland> pitti: sure...  anything else?
<kirkland> pitti: what reads/writes .dmrc ?
<kirkland> pitti: i'm not familiar with that one at all
<pitti> kirkland: gdm
<kirkland> pitti: ah, okay
<pitti> kirkland: it saves your default session type, keyboard layout, and language, i. e. the things you can change in gdm
<kirkland> pitti: okay
<kirkland> pitti: and where's the about-me code?  the thing that writes out .face ?
<kirkland> pitti: gdm source as well?
<seb128> kirkland, gnome-control-center
<kirkland> seb128: thanks
<pitti> ah, seb128 beat me to it, thanks
<Magilum> Hey, is there a repository of all the updates in -security or in -updates in a given release cycle, or a repository of all (including past) SRU's? I'm doing research in dynamic software updating, and Ubuntu's updates over a release cycle seem like a great data source
<kees> Magilum: deb archives are organized as pools, but you can get the lists of packages for a release in the "dists" subdirectory of the archive
<kees> Magilum: e.g. http://archive.ubuntu.com/ubuntu/dists/hardy-security/
<kees> see main/binary-i386/Packages* or main/source/Sources*
<cjwatson> you can also mine data about update publishing out of Launchpad using its API
<Magilum> kees: I mean more like the metadata, like the SRU's or equivalent document for -security uploads. Optimally, I'd like to see the reason for any particular update, rather than just the fact that an update happened.
<cjwatson> http://help.launchpad.net/API  https://edge.launchpad.net/+apidoc
<cjwatson> the only coherent and consistent descriptions of each update are (a) the changelog (b) any associated bugs
<Magilum> cjwatson: That seems like a rather extreme solution... is there no other option?
<cjwatson> Magilum: I'm not quite sure what you're after; personally I find the API is a very good way to get hold of data that nobody'd previously thought of presenting in the particular form I want, but in some cases of course there may be better presentations already available
<cjwatson> you could also try the -changes mailing list archives on lists.ubuntu.com
<cjwatson> they don't tell you about SRUs that failed validation though
<cjwatson> or rather, they tell you about everything regardless of validation
<Magilum> Okay, so a good source for the data I'm after about these updates is mining a package's changelog (which should have the bugs linked in it, right?) from launchpad?
<kees> the -changes mailing list lacks -security updates, unfortunately.
<Magilum> We're doing research in dynamic software updating; if you guys have heard of KSplice, that's an example of an implementation.
<kees> Magilum: for -security the bugs aren't always listed, but the CVEs usually are.
<Magilum> kees: Just as good, we just need to know what sort of patch it is.
<cjwatson> for example, when I was preparing the change summary for 8.04.3, I used http://paste.ubuntu.com/268067/ and http://paste.ubuntu.com/268068/ to automate a lot of the work for me
<cjwatson> pretty hacked-up but you can probably get the idea
<Magilum> So is there no database of all completed SRU's?
<cjwatson> that's what Launchpad's for
<kees> SRUs are different, and will almost always have their bug #'s in the changelog
<slangasek> kees: bug #426923
<ubottu> Launchpad bug 426923 in pam "Cannot login after libpam upgrade to libpam* 1.0.1-4 ubuntu5.6" [Undecided,New] https://launchpad.net/bugs/426923
<cjwatson> any source publication to -updates is a completed SRU or a security update
<cjwatson> and you could look at the Distribution field of the changes file to determine which
<slangasek> kees: did we find the one Ubuntu user who was affected by the bug?
<kees> slangasek: dunno.  how can we start debugging their situations?
<Magilum> So basically the only (or best) way of doing this is via launchpad's API?
<cjwatson> it's not absolutely the only way, as there are exports of some of the data in various other places in various forms; but if you're looking for a database to query, LP is it
<slangasek> kees: well for that case, I suppose 'debconf-show libpam-runtime' should tell us whether this was the reason he's now locked out
<slangasek> kees: but of course he needs to get access to his system first
<slangasek> we could tell him to look for a root shell listening on a high port
<kees> ugh
<slangasek> do we have a recovery mode howto somewhere?
<kees> https://wiki.ubuntu.com/RecoveryMode
<slangasek> awesomesauce
<slangasek> oh, apparently you're on top of that bug
<Magilum> cjwatson: What and where would those exports be?
<cjwatson> the ad-hoc things we've mentioned, like the -changes mailing list, the security update web pages, etc.
<cjwatson> and the archive itself although that only gives you things that are currently published not the history
<Magilum> ah, okay.
<cjwatson> perhaps the full changelog of each individual package
<cjwatson> that kind of thing
<Magilum> you don't have the older packages in the repository?
<cjwatson> we don't really keep separate per-domain databases, it isn't economical
<cjwatson> no, they get expired shortly after they've been superseded - the pool is enormous as it is
<cjwatson> we only keep ones that are actually current in some Packages/Sources files
<Magilum> Do they exist anywhere?
<Magilum> I'm interested in seeing what in the code changed
<cjwatson> they're archived in the Launchpad librarian, referenced from the Launchpad database, yes
<Magilum> Alright, thanks.
<cjwatson> that's the only place I'm aware of that archives everything (or close to everything; we have expired some old binary packages from releases that aren't supported any more, though not source packages)
<Magilum> So the librarian doesn't have source packages?
<kees> Magilum: LP keeps a debdiff between package versions, but that only started recently.
<Magilum> kees: How recently?
<cjwatson> the librarian has source packages, yes
<cjwatson> you may have misread me if you think I said otherwise
<cjwatson> my comment was "we have expired some old binary packages from releases that aren't supported any more, though [we have] not [expired any] source packages"
<kees> Magilum: I think a little over a year
<Magilum> Ahh, okay. thanks.
<cjwatson> mm, the package diffs are not necessarily always between the pairs of packages you want, but yes, they can be useful
<kees> right
<Magilum> Ideally, I would have patches that laid out the growth of the program in a nice line, with metadata as to what each patch did
<Magilum> I'm guessing the best thing to do would be to mine Launchpad and launchpad-librarian?
<kees> Magilum: as an example, nss 3.12.3.1-0ubuntu0.9.04.1 is not longer available in binary form (a newer release was made) but the source is still available: https://launchpad.net/ubuntu/+source/nss/3.12.3.1-0ubuntu0.9.04.1
<kees> Magilum: for that, check with james_w, he's been doing that with bzr trees that track each source package
<Magilum> oh, that'd be fantastic.
<Magilum> Are they public? james_w?
<cjwatson> oh, yeah, that too
<cjwatson> they're public, yes
<cjwatson> https://code.launchpad.net/ubuntu/+source/<sourcepackagename>
<cjwatson> not necessarily everything is imported there as yet - there are still some importer problems
<cjwatson> but I think the coverage is now pretty good
<Magilum> how long has that been going on?
<slangasek> seems to still be about 50-50 odds on the packages I try to find branches for ;)
<Magilum> how far back do they go, rather?
<cjwatson> only for a few months, but he imported as much history as he could find from LP
<cjwatson> so I would expect they'll go back as far as you need
<Magilum> that's fantastic
<Keybuk>  * Mounting securityfs on /sys/kernel/security...
<Keybuk> mount: securityfs already mounted or /sys/kernel/security busy
<Keybuk> mount: according to mtab, none is already mounted on /sys/kernel/security
<Keybuk> 									 [fail]
<Keybuk> kees: ^ OMG! THE SKY IS FALLING! THINGS ARE EXACTLY WHERE THEY SHOULD BE! ARGH!
<Keybuk> :p
<Keybuk> kees: could you set OGRA=n on that script? :)
<Magilum> Do the branches have a single continuous history, or are they totally disjoint from the ones in other pools (if that's the right word). I notice there's a branch for $package in hardy, one for hardy-proposed, one for hardy-updates, etc
<Keybuk> jcastro: you should so post that bootchart on twitter
<jcastro> Keybuk: I didn't want to steal your thunder, feel free to post it yourself.
<jcastro> but I can if you'd like
<Keybuk> jcastro: it's better marketing if it's anecdotal
<jcastro> he ok
<Keybuk> besides, mine are better ;)
<jcastro> heh
<cjwatson> Magilum: they're supposed to have common history where appropriate
<Magilum> cjwatson: Where would they be disjoint?
<cjwatson> where the history is in fact disjoint :-)
<cjwatson> sorry, I shouldn't have said "where appropriate", that was confusing
 * cjwatson -> elsewhere
<Magilum> AAhh, the bzr repo's james_w has are in 2a format.
<kees> Keybuk: erm?
<kees> Keybuk: oh, is /proc/mounts not listing it as securityfs?
<kees>         if ! grep -q ^securityfs /proc/mounts ; then
<kees>                 log_action_begin_msg "Mounting securityfs on ${SECURITYFS}"
<kees>                 if ! mount -t securityfs securityfs "${SECURITYFS}"; then
<kees> Keybuk: or rather, I assume it should be the 3rd column, not the first that is checked?
<kirkland> pitti: okay, cool, .face fixed in gdm
<kirkland> pitti: http://paste.ubuntu.com/268101/
<kirkland> pitti: how do i test .dmrc ?
<kirkland> pitti: i'm not familiar with it at all
<superm1> kirkland, don't you just put it in your home directory and restart gdm?
<kees> Keybuk: what would you recommend as the cleanest way to make sure a given fs is mounted in a particular location?
<kirkland> superm1: right... but what the heck does .dmrc actually do?
<kirkland> superm1: and how can i tell if its working or not
<superm1> kirkland, defines the defaults for your user, keyboard, language and login session
<superm1> (to override the system defaults for these things)
<superm1> so if you want to make sure yours is being read, put a session in it that's different than the system's
<jdstrand> Riddell: hi! are you planning an upload of qt4-x11 today? I plan to upload a fix for CVE-2009-2700
<jdstrand> Riddell: http://qt.gitorious.org/qt/qt/commit/802d8c02eaa0aa9cd8d0c6cbd18cd814e6337bc6
<kees> Keybuk: you can set ulimits in upstart service definitions, right?
<ScottK> jdstrand: I think he's offline until tomorrow sometime.
<kees> Keybuk: oh, nm, found it in http://upstart.ubuntu.com/wiki/Stanzas
<jdstrand> I'll take that as a 'no' then :)
<jdstrand> ScottK: thanks!
<RainCT> Keybuk: Saying the PPA doesn't improve boot speed was a bad move, now there's no incentive to test it! :P
<ScottK> There's still the thrill for the first reboot and waiting to see if it comes up or not.
<soren> kirkland: Ok, good, didn't mean to pester you or anything. I had had mail issues on my shiny, new laptop, so I wasnÍ't completely sure all my e-mail had gotten through.
<kirkland> soren: no problemo
<kirkland> soren: i reinstalled yesterday too
<kirkland> soren: similarly, i didn't mean to pester you about getting started on that image either
<kirkland> soren: i just wanted to make sure I wasn't making it more difficult than it needed to be
<soren> kirkland: This time, I've added all my $HOME/.*rc files to bzr and added a Makefile that'll install all the packages I can't live without. Blowing this box away now shouldn't be too much of a problem.
<kirkland> soren: that's really funny too... i've been carrying around the same $HOME/* since about edgy
<soren> kirkland: I deliberaly don't do that.
<kirkland> soren: just yesterday, i pruned *all* .*rc that I didn't recognize
<kirkland> there was some cruft in there
<kirkland> dustbunnies
<kirkland> soren: as for testing this image ...
<soren> Every time I acquire a new system, my $HOME gets more and more organised this way. I start out with a clean slate and only copy stuff over when I need it. After a while, I grab a full backup, and de- or recomission the machine.
<kirkland> soren: it's trivial for me to do so in kvm
<kirkland> soren: i can try to setup UEC here, if you tell me it's in better shape than last week, and worth trying an install now
<soren> kirkland: I have an upload pending that should take care of a few things, actually.
<jjohansen1> kirkland: well we have a karmic kernel that can be tested
<kirkland> soren: cool, i'll look out for that
<kirkland> jjohansen1: ah
<soren> kirkland: Oh, I just looked. It's not something that should affect anything you need.
<kirkland> soren: so i should use karmic's vm-builder to generate a jaunty amd64 image with alfresco
<soren> kirkland: I'd use what's in bzr.
<kirkland> soren: vmbuilder from bzr ?
<kirkland> soren: you mean?
<soren> kirkland: Yes.
<kirkland> soren: hrm...
<kirkland> soren: is that going to land in karmic?
<soren> Yes.
<kirkland> soren: eta on that?
<pen1234> http://www.thaiadpoint.com/tap8.1/bin/redir.php?p=2042&l=1357&u_id=363435
<kirkland> soren: i only ask for the sake of the reproduciblity of images
<pen1234> http://www.thaiadpoint.com/tap8.1/bin/redir.php?p=2042&l=1357&u_id=363435
<soren> kirkland: I doubt I'll have the time this week.
<kirkland> soren: okay
<donri> why is the software store needed, and why can't you use and help improve gnome-packagekit instead? how compatible will the software store be with the packagekit api? e.g. will it work with the pango and gstreamer plugins?
<slangasek> mathiaz: thbbt, I'm uploading ubuntu-meta to get that FFe off my list :)
<slangasek> mathiaz: well played :)
<mvo> donri: PK can not use debconf, we would love to fix this, but it got not accepted upstream
<donri> isn't debconf what interrupts installations to prompt for input?
<mathiaz> slangasek: thanks! ;)
<donri> isn't the upstream concern merely that all prompts should go before installations so that installations run uninterrupted? couldn't this be made to work with debconf?
<slangasek> donri: no, it can't.
<donri> i'm curious, why not?
<slangasek> because debconf is used for communicating errors during package installs, and prompting in cases where we don't know prompts are needed until packages have started to be unpacked and installed.
<kirkland> seb128: pitti: do either of you guys want to eyeball my patches to gdm and gnome-control-center for Bug #426724 ?
<ubottu> Launchpad bug 426724 in gnome-control-center "login-screen has no user-pictures" [Wishlist,In progress] https://launchpad.net/bugs/426724
<kirkland> seb128: pitti: i've tested that they "do the right thing"
<kirkland> seb128: pitti: you guys might look at them from an upstreamable perspective, as I have no cred in the gnome world :-)
<soren> slangasek: thbbt?
<slangasek> soren: <raspberry_sound/>
<soren> slangasek: Oh, it's an onomatopoieticon?
<mneptok> thttpd?
<slangasek> soren: yes
<soren> twss
<mneptok> !info thttpd
<ubottu> thttpd (source: thttpd): tiny/turbo/throttling HTTP server. In component universe, is optional. Version 2.25b-6 (jaunty), package size 59 kB, installed size 240 kB
<kirkland> pitti: seb128: http://paste.ubuntu.com/268159/
<kirkland> pitti: seb128: http://paste.ubuntu.com/268160/
<soren> slangasek: I would *never* have guessed :)
<slangasek> mathiaz: well - I would be uploading ubuntu-meta, anyway, if the darn script noticed that the seed had changed
<seb128> kirkland, open a bug and subscribe the sponsor team to it?
<seb128> kirkland, it's late european time now, I'm busy with other things and pitti is away for the evening
<kirkland> seb128: okay, you'd rather me do that than upload myself?
<seb128> kirkland, I will have a look tomorrow morning
<kirkland> seb128: cool, thanks
<seb128> kirkland, well I would prefer to have changes upstream before being uploaded yes
<seb128> otherwise nobody will upstream those later
<kirkland> seb128: alright, i'll attach the two debdiff's to the bug then
<seb128> thanks
<kirkland> seb128: and subscribe you/pitti
<kirkland> seb128: thank you ;-)
<Keybuk> kees: well, firstly you should *not* do that
<Keybuk> kees: you're wasting time, cpu, I/O, etc. during boot just to find out whether some other part of the boot worked or not
<Keybuk> far better just to fail loudly as normal
<Keybuk> mountall will already have mounted securityfs
<fabrice_sp> kirkland, are you looking after FTBFS of pycryptopp ?
<Keybuk> (and yes, you're reading the wrong field, field 1 can contain anything, field 3 is the type)
<kirkland> fabrice_sp: no, sorry, no time
<kees> Keybuk: so assume it's mounted and explode if it's not there?
<Keybuk> exactly
<fabrice_sp> I'll submit the debdiff then (it's the classical --install-layout python stuff)
<kees> Keybuk: ok
<Keybuk> I've got that converted to Upstart anyway
<Keybuk> which does "start on filesystem", and filesystem checks for securityfs already
<Keybuk> but it's worth saying ;)
<kees> Keybuk: where does mountall.sh get its knowledge of securityfs's mount location?
<Keybuk> kees: mountall is a binary in the Upstart source package in the ubuntu-boot PPA
<kees> Keybuk: right, but if someone doesn't have ubuntu-boot...
<Keybuk> they will don't worry
<slangasek> mathiaz: oh, haha, there's no ubuntu-server metapackage
<slangasek> mathiaz: so the bug is fixed, then
<kirkland> soren: ping
<kirkland> soren: http://paste.ubuntu.com/268172/
 * popey pokes directhex with a friendly stick
<kirkland> apw: around?
<kirkland> apw: i talked to rtg last week about upping our /dev/loop* to something more reasoanble, say 32 or 64
<kirkland> apw: he said he'd need to investigate the memory cost ... do you happen to know?
<kirkland> apw: seems other distros set that a bit higher than our 8
<kirkland> apw: and eucalyptus recommends 32, or it throws warnings in init
<popey> directhex: libgconf2.0-cil appears to not exist in jaunty.. which is a problem for backporting tomboy 0.15.x suggestions?
<bdmurray> slangasek: I wanted to add that a new package should have an apport package hook to the new package inclusion guidelines.  Does that seem reasonable?
<slangasek> bdmurray: seems reasonable to me; those are guidelines for main though, aren't they? (so the domain of the MIR team)
<bdmurray> slangasek: I was looking at https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews#NewPackage in particular
<bdmurray> so not necessarily main
<slangasek> bdmurray: ah, ok
<slangasek> # Non-native packages must have verifiable cryptographic path to upstream source
 * slangasek peers
<slangasek> ok, I don't know what these rules are targeted at, then; that's certainly not something that gets checked as part of new processing
<bdmurray> What documentation is refered to for new packages in universe then?
<RainCT> mvo: Hey. You may be intersted in the last comment on http://bloc.eurion.net/archives/2009/how-to-help-with-package-screenshots/
<mvo> RainCT: sweet, that sounds very nice
<mvo> RainCT: I talked to him a while ago when I created the get-screenshot button in synaptic and he is just a incredible nice guy
<rgreening> pitti: ping
<directhex> popey, for jaunty... that sounds correct
<directhex> popey, it was unneccessarily ABI-bumped
<directhex> popey, change the dep to libgconf2.24-cil
<popey> ahh
<popey> thank you
<soren> kirkland: ah, that again.
<kirkland> soren: i worked around it, but hit a few more issues
<kirkland> soren: 2 things i wanted to discuss
<soren> kirkland: Ok.
<kirkland> soren: before vmbuilder ...
<kirkland> soren: kqemu ....
<soren> Oh.
<soren> kirkland: Ah, yes.
<kirkland> soren: upstream qemu and kvm projects have both disabled it, noting that it's basically unsupported
<kirkland> soren: we would need to configure that on to support it in Ubuntu
<soren> kirkland: It's a shame, really. I'd like to keep it around (I happen to know that jdstrand uses it), but it would end up in main. :(
<kirkland> soren: there's a few users complaining about this now
<kirkland> soren: yeah, i'm on the fence
<kirkland> soren: i don't guess i really mind it in universe
<kirkland> soren: but in no way do we want to endorse it in main
<kirkland> soren: when upstream is saying that it's unsupportable
<soren> kirkland: ..but it would be in the same binary, right?
<soren> No way to split it out.
<soren> AFAIK.
<kirkland> soren: right
<kirkland> soren: we'd have to do a separate build, and spit out a different binary deb for universe
 * jdstrand does use it
<jdstrand> it is fairly flaky on karmic though
<kirkland> jdstrand: oh?  how are you using it in karmic?
<jdstrand> iirc I could have VMs with 384M of ram, but not 256 or 512
<jdstrand> kirkland: I was using it in Dublin
<kirkland> jdstrand: not through qemu-kvm, huh?
<soren> Ok, just for kicks: Can some please calculate the HMAC_SHA1 with key "12345678901234567890" and data 0 (ASCII 0, not '0')? I have a document that says it should yield one value, but I'm getting another.
<jdstrand> kirkland: I did use qemu-kvm once to test the libvirt/apparmor stuff
<cjwatson> meh, why on earth is a watch file or get-orig-source a requirement in those "new package guidelines"?
<jdstrand> (for kqemu)
<cjwatson> rule of thumb: if something is only sporadically followed among the packages in main, making it a requirement for all new packages may not make sense :-P
<cjwatson> bdmurray: I think what's happened is that the MOTU review practices have been borged into that page
<cjwatson> bdmurray: archive admins doing new queue review are usually experienced enough that their own judgement is a pretty good set of guidelines in itself, and TBH I'd rather leave them to it most of the time, as long as we get the basic licensing checks done; if I were to point people at a set of guidelines, I'd use http://ftp-master.debian.org/REJECT-FAQ.html
<kirkland> soren: okay, i suppose we ignore kqemu for now?
<cjwatson> bdmurray: as for apport package hooks, it often makes sense, but not always - consider a command-line tool which simply filters its input in some way. There's really no sensible way to write an apport hook for such a thing
<kirkland> jdstrand: i would not have expected kqemu to work at all with qemu-kvm ...
<cjwatson> bdmurray: so there definitely needs to be discretion in there
<kirkland> soren: okay, vmbuilder ... i'm hitting a few errors
<kirkland> soren: i was able to change the parted calls to use "linux-swap(new)"
<kirkland> soren: that seems to work
<cjwatson> use (v1) please
<kirkland> cjwatson: i saw some posts from you about this topic, actually
<kirkland> cjwatson: hmm, (v1) didn't work ...
<cjwatson> let me check if that patch is in place
<jdstrand> kirkland: well, I was using it with libvirt, so I used "<domain type='kqemu'>" with <emulator>/usr/bin/qemu</emulator>
<jdstrand> kirkland: at the time, it didn't blow apart
<jdstrand> kirkland: I may have had a kqemu-source module laying around
<kirkland> jdstrand: hrm, okay
<cjwatson> oh, meh, it isn't!
<cjwatson> you'll have to use (new) for now, yes
<cjwatson> but expect that to change again in future; (new) will keep on working at least for a while
<kirkland> cjwatson: okay, confirms what i saw
<cjwatson> calling things "new" is bad design in general though, which is why I got it changed upstream
<kirkland> cjwatson: i tried v1 first, then fell back to (new)
<kirkland> cjwatson: oh, i agree, and support your quest ;-)
<bdmurray> cjwatson: my intent is to modify the documentation so new packages will be aware of apport package hooks when making a new package.  I modified https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages but wanted something that stressed it more.
<bdmurray> cjwatson: I realize it doesn't always make sense to have one
<kirkland> soren: okay, so once i fix VMBuilder/disk.py to use linux-swap(new) ... the install proceeds
<cjwatson> bdmurray: that's fine, I just don't want us to go too far the other way and end up with a bunch of silly apport hooks that do very little of any use. It's probably only really an issue when the package is likely to get a lot of bugs
<kirkland> soren: then blows up at bootloader installation
<cjwatson> or a lot of hard-to-diagnose bugs
<kirkland> cjwatson: btw, i don't know that I'm going to have time to fix grub2 to install onto each disk in a raid
<jdstrand> bdmurray: fyi, the apport report is in the usual place
<kirkland> cjwatson: at least, not without a few pointers
<cjwatson> kirkland: I was under the impression that that was on my plate
<mathiaz> cr3: hey - reviewing your apport merge proposal
<kirkland> cjwatson: oh, good, i thought you thought i was fixing that
<mathiaz> cr3: isn't the apport support a new feature?
<kirkland> cjwatson: thanks, i haven't filed a bug yet ... i'll do that now (unless there's already one)
<mathiaz> cr3: hm - s/apport/checkbox merge proposal/
<cr3> mathiaz: nope, it was added before ff. I just improved it following complaints :)
<cjwatson> kirkland: go ahead
<soren> kirkland: Ah, yes, the grub2 thing.
<kirkland> soren: do you have a fix for this too?
<soren> kirkland: I do not, unfortunately.
<jdstrand> soren, kirkland: zul was working on that at one point
<kirkland> soren: a work around?
<soren> kirkland: For different reasons, I will have to find a fix for it tomorrow.
<soren> kirkland: Install grub1? :)
<jdstrand> I do not know the status
<mathiaz> cr3: same question for the dmi detection
<mathiaz> cr3: it seems that this two things add a lot of new code
<cr3> mathiaz: dmi was there as requested by launchpad, but it didn't work unfortunately and I couldn't fix it before ff
<mathiaz> cr3: and what about apport symptoms support?
<kirkland> cjwatson: https://bugs.edge.launchpad.net/ubuntu/+source/grub2/+bug/427048
<ubottu> Launchpad bug 427048 in grub2 "grub2 needs to install the bootloader to each disk in a RAID1 array providing /boot" [High,Triaged]
<kirkland> cjwatson: i filed against grub2, assigned it your way, triaged it, and targeted at alpha6
<kirkland> cjwatson: sorry if any of that is inaccurate
<kirkland> soren: i don't see a grub1/2 toggle in vmbuilder :-)
<cjwatson> kirkland: that's fine although a6 might be ambitious
<kirkland> cjwatson: okay, retarget for beta?
<kirkland> cjwatson: i'll leave that to your discretion
<cr3> mathiaz: I was hoping that could be considered a bug against checkbox reporting irrelevant bugs
<kirkland> cjwatson: i just wanted to make sure it was milestoned, assuming that was okay by you
<cr3> mathiaz: however, we could consider that a feature and I could go through the ffe process if that would make you feel more comfortable
<cjwatson> kirkland: leave it be for now; sure
<soren> kirkland: That's what I'll add tomorrow. :)
<kirkland> soren: okay, cool, i'll fix other stuff in the mean time
<soren> kirkland: well... Not really. I'll just fix it, so that things Just Work[tm].
<kirkland> soren: cheers ;-)
<mathiaz> cr3: IIUC the workaround that bdmurray introduced in the previous upload was fixed?
<mathiaz> cr3: ie not reporting agains the linux package?
<cr3> mathiaz: yep
<cr3> mathiaz: ie, if there's no corresponding package and there's no corresponding symptom, then don't report a bug
<cr3> mathiaz: I will be revising all the tests later to make sure that a relevant package is assigned to each test so that bugs can be reported for each test
<cr3> mathiaz: I need to jet, but I'll be back online later. thanks for looking into my merge request!
 * slangasek chuckles at bug #400222
<ubottu> Launchpad bug 400222 in malone "new status ajax menu let you change bugzilla watch status" [High,Fix committed] https://launchpad.net/bugs/400222
<RainCT> how can I fix my install if ~ubuntu-boot/+archive/staging is evil? apt-get inside chroot from Live USB?
<slangasek> https://wiki.ubuntu.com/RecoveryMode?
<slangasek> what kind of evil was it?
<RainCT> slangasek: Haven't tried it yet, asking just in case (I need my laptop tomorrow morning).
<slangasek> heh
<RainCT> btw, any idea when the diff stuff for 'aptitude update' will land?
<mathiaz> mdz: re bug 194140 - should I assign it to mvo?
<ubottu> Launchpad bug 194140 in cyrus-sasl2 "Dependency cycle prevents upgrade of libsasl2-2" [Low,Incomplete] https://launchpad.net/bugs/194140
<mrooney|w> is there anywhere to track the number of language packs on the default ISO over past releases of Ubuntu?
<mrooney|w> more specifically I'm trying to figure out the total size consumed by langpacks on the ISOs over time
<slangasek> the number installed can be extracted from the .manifest files accompanying the ISOs
<slangasek> on releases.u.c and old-images.u.c
<slangasek> sorry, old-releases.u.c
<mrooney|w> slangasek: excellent, thanks
#ubuntu-devel 2009-09-10
<mrooney|w> do you happen to know off-hand if the trend has been towards more or less?
<slangasek> mrooney|w: I doubt there's a clear trend; we always stuff as many langpacks on as we can, some releases we manage more, some we manage fewer
<slangasek> overall the trend is probably towards "less"
<mrooney|w> I'm interested to know to know if Ubuntu is getting bigger or smaller over timem when you subtract the langpacks from the 700MB
<mrooney|w> ah ok
<RainCT> Survived the reboot with GDM not showing up unless being started manually and /etc/resolv.conf getting "nameserver 127.0.0.1" as content.
<RainCT> No visible speed change (forgot to do a benchmark before, will get one now), and I've also seen this: http://img215.imageshack.us/img215/1502/10092009118.jpg
<RainCT> although maybe the ML would be a better place to say all this :P
<bluefoxicy> http://static.arstechnica.com/windows_linux_bb_9.png
<bluefoxicy> I can't figure out how "hundreds of updates a month" are hard to maintain in the context of Ubuntu specifically
<RainCT> bluefoxicy: Why do you even look at such stuff? :)
<bluefoxicy> this is a direct lie and false advertisement, even out of context.  In context, ... we're talking about netbooks, aimed at end-users in freaking Best Buy, who just turn on Automatic Updates in whatever OS they use.
<bluefoxicy> RainCT:  Actually what's interesting me here is that encouraging the dissemination of false information about a specific business competitor by a third party may be slander, unethical, and illegal.
<bluefoxicy> Microsoft basically directly attacked Canonical, LTD with libelous written-word falsehoods and encouraged a third party to repeat the written word as slanderous spoken word in a false advertisement campaign.
<mdz> mathiaz, not necessarily, but I think you should ask him for help diagnosing whether it is an apt bug or a packaging bug (and what the problem is exactly)
<TheMuso> slangasek: If you deny an FFE, what do you usually set the bug to? I am responding to the alsa FFe, and don't think its worthwhile at this time, and I want to be sure the status is consistant with other denied FFes.
 * TheMuso will just use wont fix for now.
<slangasek> TheMuso: didn't I already mark that 'wontfix'?
<TheMuso> slangasek: don't know, I am just responding to bug mail as I go through it. If you did already, then sorry. :)
<Riddell> jdstrand: I've no plans to upload qt4, did you do your upload?
<ScottK> Riddell: I saw it recently listed as building in their PPA
<liw> is there any chance that the gdu-notification-daemon dialog can be shut up so it doesn't uselessly whine at me every time I log in?
<dholbach> good morning
<pitti> Good morning
<pitti> kirkland: test .dmrc> just select a different session (like "xterm") or a different keyboard layout and check ~/.dmrc that it has the setting afterwards (and that it exists in the first place)
<pitti> kirkland: will look at the bug and comment there; thanks for working on this!
<dholbach> is anybody else waiting for a upload confirmation of LP too?
<pitti> I'm waiting for LP to display my bugs, or file one
<pitti> it keeps timing out
<dholbach> pitti: * spm has changed the topic to: ** Launchpad Is Having Issues atm ** | [.......]
<spm> pitti: dholbach: fwiw, edge appears unaffected, only lpmain seems to be having woes.
<pitti> hm, not really
<pitti> filing a bug on edge times out as well
<spm> heh. I'll rephrase - I have a sea of nagios red on lpmain; not on edge :-)
 * dholbach goes back to all the emails he wanted to write for a longer while
<dholbach> pitti: how can I submit a crash report to LP later on?
<dholbach> I just got "502: bad gateway"
<pitti> spm: heh, ok; so then I'll just hope that fixing production will magically fix edge, too :)
<pitti> dholbach: cancel, and then click on /var/crash/... in nautilus or ubuntu-bug /var/crash/... later on
<spm> pitti: you and me both... :-)
<dholbach> pitti: thanks, I'll do that
<dholbach> it's funny: LP is broken, then I decide to do emails, then evo crashes on me and I can't send the crash report in
<dholbach> seems like I should do something completely different today
<dholbach> I know it sounds a bit like "my dog ate my homework" :)
<pitti> dholbach: same for me; I was supposed to debug an X hang on suspend, and kernel -10 broke suspend
<liw> dholbach, I had that happen once in school
<liw> dholbach, although it happened to the teacher
 * StevenK tries to convince edge to talk nicely to him
<dholbach> liw: the dog's teacher ate your homework? sounds like you were on the safe side then and nobody could accuse you of shamelessly lying :)
<liw> dholbach, yes :)
<liw> the whole class's homework, to be exact
<StevenK> Haha, way cool
<dholbach> nice :)
<YokoZar> What package has the "system restart required" notifier?
<YokoZar> I don't think it's update manager
<dholbach> update-notifier
<YokoZar> thanks dholbach
<YokoZar> dholbach: actually I'm not sure that's it either.  I'm talking about the actual "System restart required.  In order to complete the update of your system, it needs to be restarted.  Until you do so, security updates..."
<YokoZar> grepping through update-notifier and update-manager doesn't give me that as a string anywhere :(
<dholbach> you mean the upgrade from one distro release to another?
<YokoZar> No like after you install a kernel update
<slangasek> no, it is update-notifier
<YokoZar> hmm maybe I'm looking wrong
<slangasek> the strings are provided by the individual packages
<dholbach> daniel@miyazaki:~/update-notifier-0.87$ grep -ri restart * | wc -l
<dholbach> 125
<dholbach> daniel@miyazaki:~/update-notifier-0.87$
<dholbach> there's a lot of restart in there :)
<\sh> where is the gnome .desktop entry gone after latest karmic updates? ;)
<pitti> \sh: you mean the gnome session in gdm?
<\sh> pitti: yepp
<pitti> \sh: sounds like bug 426800
<ubottu> Launchpad bug 426800 in xubuntu-default-settings "lost gnome in gdm session chooser" [High,Triaged] https://launchpad.net/bugs/426800
<YokoZar> ah, found it in the .ui dialog
<YokoZar> I guess this makes sense
<\sh> pitti: ihh...sounds like removing xfce will bring it back then...
<superm1> \sh, just xubuntu-default-settings for now
<superm1> once the proper solution is in place for gdm to use default.desktop, those hacks can be dropped on mythbuntu-default-settings and xubuntu-default-settings
<\sh> superm1: I wanted to remove xubuntu anyways..cause I don't use it .. just installed it earlier to test something...
<ivoks> pitti: hi! around?
<pitti> ivoks: hey
<ogra> Keybuk, ??
<pitti> superm1: second-next on my list
<ivoks> pitti: hey, regarding bug 426652
<ubottu> Launchpad bug 426652 in corosync "Please sync corosync 1.0.0-5 (main) from Debian experimental" [Undecided,New] https://launchpad.net/bugs/426652
<ivoks> pitti: you've acked the upload
<pitti> right after unbreaking DVD builds
<ivoks> pitti: there's an issue with compression level of orig.tar.gz in ubuntu's package; so, if you could upload it manually, that would be great :)
<pitti> oh, fakesync?
<ivoks> don't know what fakesync is :/
<StevenK> spm: Edge now gives 'please try again' immeadiately
<spm> StevenK: yes
<StevenK> spm: Oh, so you know. Okay. :-)
<spm> :-)
<spm> yes. sorrry. terse atm :-)
<pitti> ivoks: -ENOLAUNCHPAD, sorry; can you assign it to me and ask for a fakesync in the bug?
<pitti> ivoks: (later on, I mean, when it comes back)
<ivoks> pitti: sure
<spm> ** launchpad should be back to normal now **
<slangasek> whee
<slangasek> spm: thanks :)
<pitti> spm: merci
<pitti> oh, now going offline?
<cjwatson> pitti: I think I already muttered about fakesync when denying the archive admin request in that bug
<pitti> ivoks: ah, I get the bug now; doing
<ivoks> pitti: awesome, thanks!
<seb128> shrug, edge is not able to reassign bugs since yesterday
<seb128> it keeps timeouting
<seb128> bah, edge keeps timeouting and that drops the comments I write when going back
<seb128> very annoying
 * seb128 switches to non edge
<apachelogger> ArneGoetje: language-selector gnome and qt are so incredibly different, it's not even funny
 * pitti chuckles
<pitti> $ sudo service network-manager start
<pitti> Rather than invoking init scripts through /etc/init.d, use the service(8)
<pitti> utility, e.g. service network-manager start
<pitti> Keybuk: hmm... ^ want a bug for that somewhere?
<ArneGoetje> apachelogger: I know. And I'm trying to port some of the functionality from the gnome to the qt version
<apachelogger> ArneGoetje: IMHO the qt thing needs a complete rewrite
<apachelogger> it's ab abomination of Qt
<slangasek> pitti: hmm, and does it know not to spit that out when called from rc?
<pitti> slangasek: I didn't see those on boot, but then again it's made very quiet by default
 * slangasek nods
<ArneGoetje> apachelogger: I won't be able to do that as I have no idea about qt or pyqt. I just want the combobox for input method choosing to get in.
 * apachelogger aint got no idea about python :D
<apachelogger> ArneGoetje: combobox population implemented, moving on to applying the setting
<ArneGoetje> apachelogger: is my description in the mail enough for you to understand what's going on?
<apachelogger> ArneGoetje: sure :)
<soren> Is there a 64 bit equivalent to htonl?
<ArneGoetje> apachelogger: thanks a lot for helping out :)
<slangasek> pitti: <blink> I'm cc:ed on this mail because... I filed bad FFe requests? :-)
<pitti> slangasek: heh, no; "CC" FYI, not because it's aimed at you :)
<slangasek> pitti: huh, how were you able to conclude that quickly that bug #427224 was bugfix-only?
<ubottu> Launchpad bug 427224 in pulseaudio "Feature freeze exception request for pulseaudio v0.9.16 final." [Undecided,Invalid] https://launchpad.net/bugs/427224
<pitti> slangasek: I read the upstream changelog
<slangasek> http://launchpadlibrarian.net/31581311/pulseaudio-changelog.txt?
<slangasek> half of those one-liners are completely opaque to me, so I have no idea if they're bugfixes :/
<apachelogger> ArneGoetje: btw, did you take a look at making kde langpacks depend on kde-l10n-$code? Riddell said that youd give that a shot IIRC
<pitti> hm, they mostly sounded like code cleanup; and it's just rc -> final, too, and TheMuso also said it's just bug fixes
<slangasek> ah, so he did
<Riddell> apachelogger: recommend I think rather than depend
<apachelogger> something default-installish at least :D
<ArneGoetje> apachelogger: it's in the latest language-selector code. please give it a try. when starting up, l-s should give a message about missing packages for the given language. the check should include several kde related packages now.
<apachelogger> Missing: ['kde-l10n-engb', 'gnome-user-guide-en', 'kde-l10n-es', 'language-pack-gnome-es', 'gnome-user-guide-es', 'openoffice.org-l10n-es']
<apachelogger> sweet
 * apachelogger hugs ArneGoetje
<ArneGoetje> apachelogger: see data/pkg_depends in the source tree
<StevenK> ArneGoetje: We will just sync the new ibus into karmic?
<slangasek> StevenK: the new upstream version?
<StevenK> slangasek: At this point, just trying to figure out the plan, so ... maybe?
<ArneGoetje> StevenK: I think so. Unless you have any reason not to do so...
<StevenK> ~,
<apachelogger> mvo: bzr upgraded the app-install-data-ubuntu branch, should now be a bit faster :)
<apachelogger> good thing that bzr2 is supposed to handle large histories better
<mvo> apachelogger: wehh, great :)
<mvo> apachelogger: many thanks (also for your work on software-store!)
<apachelogger> ArneGoetje: lp:~apachelogger/language-selector/karmic-qt++ merge r273..274
<apachelogger> mvo: I didn't do work on software-store?
<mvo> apachelogger: eh, typo - software-properties
<mvo> apachelogger: my fingers auto-complete software- to software-store these days it seems ;)
<apachelogger> oh, yeah, that also needs some more love still :)
<apachelogger> work all over the place, but fist utf8ing in apturl-kde
<apachelogger> Riddell: btw, did you ever consider implementing that stuff in some python module?
<apachelogger> def _ and def utf8 are a perfect example of code duplication
<ArneGoetje> apachelogger: thanks a lot
<Riddell> apachelogger: well it's all a cludge the utf8 stuff, I'm hoping python 3 will fix it
<apachelogger> Riddell: ScottK said that it will still be some time until that becomes default, so I think that a more maintainable implementation would be a good idea :)
<Keybuk> pitti: bug for what?
<pitti> Keybuk: "service" saying that you should run "service"
<Keybuk> pitti: that's a server bug
<Keybuk> err service bug
<pitti> ok, sysvinit then?
<ogra> <Keybuk>  kees: could you set OGRA=n on that script? :)
<ogra> Keybuk, that was in my lastlog output without much context, mind explaining what you were referring to ?
<ogra> did i trash something without knowing ?
<Keybuk> ogra: don't worry ;)
<ogra> ok :)
<Keybuk> I believe I was making light fun of your occasional habit of panicing about things unnecessarily
<Keybuk> just like that init script was doing ;)
<ogra> ah :)
<pitti> done, bug 427277
<ubottu> Launchpad bug 427277 in sysvinit ""service start" complains about using the init script and recommends using "service"" [Low,New] https://launchpad.net/bugs/427277
<stooj> Hi all. I've written a wee gui in python. How can I graphically prompt for a sudo password?
<pitti> stooj: ideally you wouldn't need to; but first, what is wee?
<stooj> pitti: Heh. Sorry. Wee = small.
<pitti> ah
<stooj> pitti: I have a collection of DVDs that used to be part of a LinuxMCE collection.
<pitti> stooj: so, the "modern" way of doing privileged things is to have a d-bus backend with PolicyKit-protected functions
<pitti> and GUIs running as normal user, calling the d-bus functions
<pitti> if your frontend itself needs root privileges, then start it through gksu in its .desktop file
<pitti> e. g. /usr/share/applications/synaptic.desktop
<stooj> OK. The gui just runs an mount command when you choose a file in a filepicker
<pitti> eww
<stooj> So, d-bus would be the way to go.
<stooj> Bad?
<pitti> stooj: well, devicekit-disks already provides that d-bus interface for mounting for you
<pitti> and you don't even need to  mess with d-bus yourself; if you have GNOME, you can call gvfs-mount from python
<pitti> there's a nice library libgdu for this, but it doesn't have a Python binding right now
<pitti> but doing the mount through devkit-disks should be okay
<pitti> stooj: you can just call "devkit-disks --mount /dev/sdc1", or (for more control), call the corresponding d-bus method
<stooj> Wow. OK.
<stooj> Any documentation in particular I should look at for that?
<pitti> stooj: http://hal.freedesktop.org/docs/DeviceKit-disks/ is pretty comprehensive
<pitti> "man devkit-disks" should probably get you going in 2 minutes
<pitti> Keybuk: just as a warning, I uploaded a new gdm to fix an alpha-6 bug; this has a higher version number than your PPA
<stooj> Many thanks pitti!
<Keybuk> pitti: no problem
<Keybuk> "bzr update" for me ;)
<Keybuk> pitti: talking of which, any idea when all of the network-manager updates in the bzr branch will be uploaded?
<apachelogger> mvo: any objections to making apturl use debhelper 7 automation?
<Keybuk> http://img193.imageshack.us/img193/9544/travislaptopkarmic20090.png
<Keybuk> ^ I wonder what the "exe" is
<Keybuk> pitti: you have the mysterious "exe" in your graph too
<Keybuk> but it goes away again after the first boot
<Keybuk> wonder whether it's an ext4 thing
<mvo> apachelogger: no
<cjwatson> apachelogger: dh7++
<cjwatson> (for whatever that's worth :-) )
<apachelogger> hehe
<jdstrand> Riddell: not yet, but will today for sure
<liw> dh7: the power of cdbs, and the obfuscation of cdbs, but with the good taste of joeyh
<directhex> yum yum joeyh
<apachelogger> mvo: should apturl get bug reports related to encoding within the next few days, then I seriously screwed up ... now encodes to utf8 all over the place (as seen in gdebi)
<apachelogger> other than that is apturl-kde all awesome now and lintian all happy again
<mvo> apachelogger: wonderful, I think if its following gdebi, then we should be fine
<apachelogger> *nod* I still think we should move that stuff to one module imported by all of our pyapps though
<evand> pitti: am I okay to reopen bug 395103, given your discovery in the upstream report that the existing patch breaks variants?
<ubottu> Launchpad bug 395103 in gdm "Gnome doesn't have my configured keyboard layout after login anymore" [High,Fix released] https://launchpad.net/bugs/395103
<ogra> Keybuk, the exe ?
<ogra> Keybuk, clearly the first steps of http://www.tuxradar.com/content/ubuntu-rewrite-linux-kernel-using-mono
<apachelogger> about time
<kelemengabor_> Heya
<kelemengabor_> yeah, that is the penguinfucker's night
<cjwatson> kelemengabor_: that's unnecessary; please cut it out
<kelemengabor_> cjwatson: nevermind
<kelemengabor_> just I try little spammer troll-bot
<cjwatson> try it somewhere else
<kelemengabor_> it is run under ubuntu sucked penguin 12.4 release candidate
<liw> hm, that's the third troll/spammer I see in two days
 * ScottK notes the +o came less than a minute after the initial troll.  Very solid reaction time.
<cjwatson> it only took that long because for some reason my /op alias wasn't working
<cjwatson> oh, that's because I called it /opself, bah
<liw> heh, I had a habit of using my native language for naming scripts, aliaes, and other such things I wrote for myself, so they'd not be confused with stuff that came from elsewhere
<ogra> Keybuk, geez, thats an insanely long changelog
<liw> then I kept forgetting which native language I used in each instance, since I have to choose from
<ogra> (sysvinit)
<pitti> Keybuk: I noticed that I get a couchdb instance started, for no reason; that's a bug as well; perhaps "exe" is something from erlang
<Keybuk> no, the exe is happening inside the initramfs
<pitti> Keybuk: network-manager> redirecting to asac; I don't know
<asac> dont see the question. repost please ;)
<cjwatson> exe> presumably /proc/$pid/exe
<rgreening> pitti: I need some assistance with build_kdeui in python-distutils-extra and using the kde ui file to generate translations in the usb-creator project. I am at a loss. I see build_kdeui can generate a .py file, but my app uses the pyqt.uic.loadui method to load the ui directly rather than a compiled version.
<rgreening> pitti: so, I was wondering what the correct way to generate the necessary pot info sould be for this project to combine with the gtk pot/po (if you have some pointers)
<pitti> rgreening: hi
<pitti> rgreening: for .ui> right, Apport still uses loadUi() as well; your setup.py manually needs to install the *.ui files in data_files
<pitti> rgreening: I spoke with some KDE devs, and they said that the preferred way would be to build and ship the .py files instead, which is why distutils-extras does that by default; but you don't need to use that, of course
<rgreening> pitti: done that. so it loads the ui fine. The issue at hand is getting the translations template to include my stuff in the ui
<pitti> rgreening: pot> usually you just have one domain for the project, and try to share as many strings between the projects as possible; you want to have several domains?
<pitti> ah
<rgreening> pitti: no, want to merge to domain usbcreator
<asac> anyone knows a eager + not-so-overloaded debian ftpmaster?
<rgreening> just to make sure we don't miss any differences
<pitti> it's not picking them up automatically?
<rgreening> pitti: for example, I use Close not Exit, in the window. there are some minor differences.
<rgreening> nope.
<pitti> rgreening: indeed, seems you found a bug
<rgreening> pitti, maybe you could have a look at usb-creator in lp and see what I may be doing wrong
<Riddell> rgreening: we use extractrc to extract strings from .ui files, see the script extract-messages.sh
<pitti> rgreening: mind to report it against python-distutils-extra? I'll fix it ASAP, but probably not today
<rgreening> Riddell: doesn't that require cdbs
<florian__> Hey guys. I saw that UIFreeze is in place for Karmic. Is there a place we can see what it will look like ? I search the wiki with no success.
<Riddell> rgreening: no, it's from upstream KDE
<cjwatson> asac: pick on one of http://lists.debian.org/debian-devel-announce/2009/08/msg00004.html ?
<rgreening> Riddell: are there any required deps to ensure extract-messages is called?
<pitti> florian__: grab the current daily CD and start the live system?
<Riddell> rgreening: I did say I'd look at i18n for usb-creator, although I utterly failed to get to it yesterday I'm afraid
<florian__> pitti: not a bad idea... is there anything easier ?
<rgreening> pitti: I'll try what Riddell suggest first. If it still doesn't work as expected, I'll open a bug report.
<Riddell> rgreening: cdbs kde.mk will call it, you can also call it any other way you wish.  it uses Messages.sh files
<asac> cjwatson: good idea. fresh blood :)
<pitti> rgreening: cool, thanks
<rgreening> Riddell: so I include a Messages.sh and where do I call extract-messages.sh? In the makefile I assume
<rgreening> pitti: ty. I'm so not good with translations :)
<kirkland> cjwatson: in qemu-kvm, we have a very simple shell script called 'kvm-ok' that basicly does egrep "flags.*:.*(svm|vmx)" /proc/cpuinfo
<kirkland> cjwatson: i often ask people to run that, to tell me if they have VT
<pitti> rgreening: don't worry; distutils-e is supposed to extract them, but it seems that fails for some reason
<kirkland> cjwatson: i was thinking that script belongs somewhere more basic than qemu-kvm package
<cjwatson> kirkland: oh, I dunno, qemu-kvm sounds OK
<rgreening> pitti: what are the requirements to enable it to extract them?
<cjwatson> we don't really have any more general place that I can think of
<kirkland> cjwatson: because i often tell them to run kvm-ok, which they run that script, find out they can't do VT, and then uninstall the package
<pitti> rgreening: me fixing the bug, I suppose :)
<rgreening> maybe I misses something
<rgreening> lol
<kirkland> cjwatson: i was thinking pciutils, perhaps
<pitti> rgreening: you can of course have a manual po/POTFILES.in with everything
<cjwatson> kirkland: stick it on a web page then :)
<cjwatson> well, maybe shell scripts on web pages not a great plan
<cjwatson> kirkland: pciutils doesn't make sense to me, but I can't think of anywhere better
<rgreening> pitti: does the kdeui file need to be tagged with a special tag in POTFILES.in? like the text: gettext/glade is?
<kirkland> cjwatson: web page didn't do it; telling people to do that grep didn't do, hence the stupid script
 * rgreening wishes there was documentation for all this :)
<kirkland> cjwatson: it can stay where it is, i suppose; i was just thinking that it's a little strange to install a package to run a script to tell you if you can use the package at all; would be nice to know that ahead of time
<pitti> rgreening: I know that GtkBuilder .ui files work with "[type: gettext/glade] file.ui"
<rgreening> pitti: so, does the kde ui have an equiv?
<pitti> rgreening: hm, according to intltool-extract(8) apparently not :-(
<rgreening> heh
<pitti> it should really..
<rgreening> pitti: should the setup be using auto mode for this to work?
<pitti> rgreening: well, it won't make much difference; if intltool can't handle them, then auto mode can't do magic
<rgreening> ok
 * rgreening wishes translations were easier :) or at least more documented :)
<rgreening> Riddell: so, if I want to merge the .pot into the same domain, the sample Messages.sh I have assumes a seperate domain.. suggestions?
<pitti> rgreening: you want to merge two .pot files? I think msgcat can do that
<pitti> (untested)
<rgreening> msgmerge maybe also?
<pitti> I don't think so
<pitti> that joins on msgids
<rgreening> ah, so that may be what I was doing wrong
<rgreening> haha
<rgreening> pitti: you are golden :P
<rgreening> I'll try the msgcat...
 * rgreening really wants to ship usb-creator-kde with working translations
<kirkland> cjwatson: do you ack, nack, or abstain, on the move of kvm-ok from kvm to pciutils?
<kirkland> cjwatson: i ask because we're about to do a qa community call for testing of kvm, and the qa team wants to give the community easy instructions to find out if they can participate or not
<Laney> oh dear
<cjwatson> kirkland: abstain leaning towards nack; it's not a pci thing
<Laney> I shouldn't have remotely updated with the new boot stuff
<kirkland> cjwatson: fair enough, thanks
<ScottK> Laney: Defintely not.
<Laney> dhcp-20-65:~ laney$ ssh laney@home.orangesquash.org.uk
<Laney> ssh: connect to host home.orangesquash.org.uk port 22: Connection refused
<Laney> :(!
<Daviey> Laney: no worries, use the serial console to resolve it :P.
<Laney> oh yeah... that...
<Laney> nah it's my workstation at home, I can just prod it when I get back later
<rgreening> pitti: just to confirm, if this was working as expected, I wouldn't need to add build_kdeui to my setup.py nor call it, as the build_il8n (in theory) would handle the kde ui file if listed in the po/POTFILES.in, correct?
<rgreening> if so, then I'll file a bug to get that working.
<pitti> rgreening: those are two entirely different things
<YokoZar1> slangasek: Just a heads up, one last UI change that I hoped to sneak through after mpt and I discussed: http://yokozar.org/blog/archives/142  -- I uploaded a bzr branch just before feature freeze, though the package isn't live yet.
<pitti> rgreening: extracting strings from KDE *.ui files to the POT doesn't work, and needs intltool support
<rgreening> yeah, just wanted to confirm that kdeui was something different than what I was trying to achienve
<pitti> rgreening: build_kdeui is for compiling *.ui into *.py files which you would ship instead of the *.ui files
<rgreening> ya. cool. Ok, I'll file a bug about the second part then. ty pitti
<jcastro> Keybuk: fyi I filed bug 421422 about the desktopcouch launching xulrunner
<ubottu> Launchpad bug 421422 in xulrunner-1.9.1 "xulrunner dependency is overkill - only spidermonkey is needed" [Wishlist,Confirmed] https://launchpad.net/bugs/421422
<jcastro> Keybuk: sorry, I meant bug 427036
<ubottu> Launchpad bug 427036 in couchdb "Launching xulrunner affects boot time" [High,In progress] https://launchpad.net/bugs/427036
<soren> doko: Is python-central still our preferred python packaging system?
<Keybuk> jcastro: cool, can you subscribe me
<rgreening> pitti: bug 427358
<ubottu> Launchpad bug 427358 in python-distutils-extra "extracting strings from KDE *.ui files to the POT doesn't work, and needs intltool support" [Undecided,New] https://launchpad.net/bugs/427358
<jcastro> Keybuk: done, you don't have a boot tag for bugs or anything do you?
<Keybuk> no
<Keybuk> (since you can't subscribe by tag)
<jcastro> I see
<ScottK> soren: On the off chance you care, the Debian Python teams have picked python-support to standardize on.
<soren> ScottK: Is python-central frowned upon?
<soren> ScottK: Or is it just a preference?
<ScottK> The DD that sponsors ~70% of sponsored uploads for those packaging teams will no longer sponsor python-central stuff.
<ScottK> The perception in Debian is that python-central is not maintained.
<ScottK> My view is that each one has it's advantages and disadvantages.  Python-support has improved a lot recently.
<soren> ScottK: Ok, thanks.
<pitti> Keybuk: $ sudo stop -q anacron
<pitti> stop: Unknown instance:
<pitti> Keybuk: anacron isn't a daemon, so does that command even make sense?
<pitti> Keybuk: (it's in /usr/lib/pm-utils/sleep.d/95anacron and currently breaking suspend)
<pitti> I'm not quite sure whether it should be a daemon, controlled by /etc/init/anacron.conf, or a cronjob, controlled by /etc/cron.d/anacron
<pitti> Keybuk: but the manpage doesn't talk about a daemon at all, and ancron -s just processes pending jobs and returns
<cr3> mathiaz: do you think it would be reasonable to reuse bug #426613, regarding checkbox 0.8.2, in order to apply for a FFE?
<ubottu> Launchpad bug 426613 in checkbox "Candidate revision checkbox_0.8.2" [Undecided,New] https://launchpad.net/bugs/426613
<Keybuk> pitti: I already fixed that in the PPA
<Keybuk> "stop anacron" *will* stop any running anacron instance
<Keybuk> ie. if cron.daily is underway
<pitti> Keybuk: great, thanks
<Keybuk> which is what the sleep.d is trying to do
<Keybuk> it just needed an || :
 * pitti dist-upgrades -- lots of new stuff
<Keybuk> just minor tweaks
<Keybuk> pitti: I'm surprised that I haven't got any of one bug report, and more more of another
<Keybuk> the one I've had a couple of reports of, which I expected, is the "computer just sits on boot with the hard drive light on"
<Keybuk> ie. fsck running ;)
 * Keybuk hadn't hooked the progress stuff up yet
<pitti> Keybuk: argh, dist-upgrade just killed my session again
<Keybuk> the other is that gdm is currently started even in recovery mode ;)
<pitti> does anything there restart gdm or so?
<Keybuk> pitti: nope
<Keybuk> I think X crashes
<superm1> pitti, for your 15_default_session, it looks like the file name is favors is default.desktop, not default.session, correct?
<superm1> or would either work?
<pitti> superm1: erm, sorry, yes; I meant xsessions/default.desktop
<superm1> no problem, thanks :)
<Laney> Keybuk: Might have something for you later... when I discover why my PC didn't boot ;)
<Keybuk> Laney: ?
<Laney> I upgraded to the PPA and it never came back up
<Keybuk> Laney: I'd like to help with that "discovery" :)
<Laney> well I'll be going home in a couple of hours so we can check it out then
<Keybuk> ok
<Keybuk> anything unusual or non-standard about your setup?
<Keybuk> in particular, the contents of your /etc/fstab /
<Laney> I've got it partitioned into a few LVs
<Laney> across... 4 disks I think
 * seb128 grrrs at Keybuk for opening a collection of tasks on the same bug
<seb128> which means spamming everybody subscribed to any of those components
<Laney> Boots took ages before anyway, probably because it's been upgraded since forever (http://orangesquash.org.uk/~laney/chicken-karmic-20090910-1.png)
<genii> Are there any plans to package Clonezilla?
<Keybuk> seb128: I was told to do it that way <g>
<seb128> who told you to do that?
<Keybuk> seb128: robbie
<Keybuk> besides, that's how LP is supposed to work ;)
<seb128> robbiew, could you please not recommend people to do that? ;-)
<Keybuk> seb128: just ignore the bug
<Keybuk> Laney: huh, lvm taking that long kinda implies that you have an actual problem there
<Laney> well I wouldn't be surprised if some of the disks are on the way out (indeed I have ordered the replacements)
<robbiew> seb128: if you are talking about the FFE...slangasek recommend that
<doko> soren: yes
<seb128> *shrug*
<seb128> ok
<Laney> so yes it could just be a coincidence
<seb128> the issue with such bugs is that you get email for every change to any of the tasks
<Keybuk> seb128: the counter-argument to that issue is that if you're a bug contact, you should be aware of changes to those packages *and* how they fit in with the other tasks
<seb128> ie when there is 19 components you don't care about and one you are subscribed to, you get all the trafic for the 19 other by email
<seb128> Keybuk, I just dislike multi-tasking, it makes it also almost impossible to rely comments to your component
<Keybuk> I don't really find that it makes much difference
<Keybuk> it all ends up in your mail folder anyway either way
<Keybuk> it's no worse than having two subscribers to the bug both replying to requests for information
<ScottK> The problem is once one package is fixed and you really don't care anymore.
<seb128> anyway let's not discuss for hours how launchpad sucks ;-)
<pitti>  hm, but having tasks on a bug is how LP is supposed to work
<pitti> but it's missing the possibility of unsubscribing from bugs where you don't have open components any more that you are sub'ed to
<ScottK> Yep
<seb128> pitti, I found that making different tasks basically impossible to track and flooding people by email
<seb128> it's fine when a bug needs a change in several components to be fixed
<Laney> there was an LP bug about supporting negative subscriptions
<seb128> but thinks like freeze exception would be better tracked with different bugs
<seb128> if you start mixing question and concern about 15 different components in one bug it becames really hard to read or to find what applies to your component
<Laney> bug 204980
<ubottu> Launchpad bug 204980 in malone "bug contacts should be able to unsubscribe from implicit subscriptions" [High,Triaged] https://launchpad.net/bugs/204980
<pitti> seb128: well, actually you wouldn't want to get these FFEs in the first place, would you?
<seb128> pitti, I would like to know what's going on with gdm
<seb128> but I don't care about all the other things there
<seb128> but right if I could opt-out that would be fine I guess
<seb128> which is the bug Laney listed
<pitti> *nod*
<mathiaz> cr3: yes - bug 426613 can be used to ask for a FFe.
<ubottu> Launchpad bug 426613 in checkbox "Candidate revision checkbox_0.8.2" [Undecided,New] https://launchpad.net/bugs/426613
<cjwatson> my rule of thumb is that if it's the same bug that needs to be fixed in several places in order for the bug to go away, use tasks
<cjwatson> if it's the same issue that is independently present in N different places, then use separate bugs
<cjwatson> so, let's say, that bug where upstart and some bit of the installer had to cooperate to get /etc/event.d/tty1 setting up getty properly for 8-bit text, that was a good case for tasks
<cjwatson> but something like that mega-bug about all the different packages that need to use dpkg --print-architecture rather than --print-installation-architecture should really have been one bug per affected package
<cjwatson> IMO
<sgallagh> mathiaz: ping
<mathiaz> sgallagh: hey - just sending emails to sssd-devel
<sgallagh> mathiaz: Yeah, I saw the first one. I wanted to make sure you pulled in both patches that were likely to affect you
<mathiaz> sgallagh: yop - I've also included the proxy enumration patch
<sgallagh> mathiaz: Ok, great :)
<mathiaz> sgallagh: anything else worth integrating?
<sgallagh> mathiaz: Looking at the git log right now :)
<sgallagh> mathiaz: I think most of the rest of the patches we've pushed lately have been related to new functionality since 0.5.0, so you should be alright.
<mathiaz> sgallagh: there was a thread about testing as well (started by jenny)
<mathiaz> sgallagh: are there any tests publicly available?
<mathiaz> sgallagh: great! thanks for keeping me in the loop
<sgallagh> mathiaz: There are some unit tests available in the tarball
<sgallagh> mathiaz: It's hard to make the rest of the tests public, because they rely on the availability of a remote data provider to work (e.g. LDAP and Kerberos)
<mathiaz> sgallagh: right - I'm looking into this as well
<mathiaz> sgallagh: one option I'm investigation is to use ec2
 * pitti looks at /builders..
<pitti> amd64  9   7790 jobs (four days)
<pitti> i386 15 14434 jobs (three days)
<pitti> WTH?
<mathiaz> sgallagh: with public AMIs
<sgallagh> mathiaz: I'm not familiar with it. Can you give me some details?
<pitti> oh, archive rebuild test?
<mathiaz> sgallagh: ec2 is amazon's public cloud
<mathiaz> sgallagh: it should be possible to create a default ldap+krb infrastructure
<sgallagh> Too many acronyms/initializations to keep track of :-P
<mathiaz> sgallagh: and run tests in there
<sgallagh> That's a very interesting idea
<mathiaz> sgallagh: right - it can be a bit overwhelming if you're not following all of this closely
<sgallagh> Could we move this discussion to #freeipa? I think there are a few others who'd love to be involved in this
<mathiaz> sgallagh: sure
<kirkland> cjwatson: is it possible to downgrade a karmic system from grub2 to grub1 ?
<cjwatson> install grub, make sure /boot/grub/menu.lst is right, and then run grub-install?
<cjwatson> I don't really want to spend time supporting that though ...
<kirkland> cjwatson: no problem, i'm trying to work around a bug in vmbuilder, it doesn't work with grub2
<cr3> mathiaz: FFE completed, now we play the waiting game. good thing I prepared well before Alpha 6
<RainCT> Keybuk: Hey. Tried the boot stuff out with both PPAs now. The first boot worked but took 90 seconds instead of 40 before; now it's failing to boot with: "mountall: unable to write pid file: read-only file system" (and a moment later: "init: module-init-tools main process (xxxx) terminated with status 1")
<ion> rainct: In /etc/init/mountall.conf, comment out âexpect daemonâ and replace âexec mountall --daemon...â with âexec mountall --debug...â
<mathiaz> mvo: hi
<ion> rainct: That should provide a nice amount of debug output.
<mathiaz> mvo: I've got another bug for your apt debugging skills - bug 194140
<ubottu> Launchpad bug 194140 in cyrus-sasl2 "Dependency cycle prevents upgrade of libsasl2-2" [Low,Incomplete] https://launchpad.net/bugs/194140
<RainCT> ion: there is no such file (nor an /etc/init/ directory)
<RainCT> err ignore that
<ion> Which both PPAs, btw? ubuntu-boot and
<RainCT> Yes, doing what you said now. Stupid me, trying /etc when I have the filesystem in /mnt :)
<ion> Ah, i misread what you said. Itâs module-init-tools that returns 1, not mountall. The problem is probably not in mountall then.
<ion> Do you have /etc/modules?
<RainCT> ion: Yes, contains "lp" and "rtc"
<RainCT> (both PPAs = ubuntu-boot/ppa/ubuntu and ubuntu-boot/staging/ubuntu)
<RainCT> ion: So should I try out the mountall thing?
<ion> rainct: Try adding the line âconsole outputâ to module-init-tools.conf first, and also add âset -xâ as a new line immediately after the âscriptâ line.
<RainCT> ion: OK. Is "console output" right after author or where should that go?
<kees> slangasek: thanks for helping triage 426658.  one down.  :)
<ion> rainct: Anywhere, except for inside the script block
<RainCT> ok, trying it out..
<popey> directhex: when you have a little time, I'm still having issues building tomboy if you wouldn't mind helping me.
<seb128> evand, bug #421212 is similar to the one you reopened?
<ubottu> Launchpad bug 421212 in gdm "gdm ignores keyboard layout selection" [Low,New] https://launchpad.net/bugs/421212
<pitti> evand: BTW, I already talked to upstream about that; they don't seem to want to replicate the entire variety of variants and options in hal/gdm..
<pitti> since bug 395103 originally was karmic RC, but fixed for most folks, I would either like to see it being closed again and have a new bug for the remaining issues (whcih aren't likely to be fixed in karmic), or downgrade that bug, which changes history
<ubottu> Launchpad bug 395103 in gdm "Gnome doesn't have my configured keyboard layout after login anymore" [High,Confirmed] https://launchpad.net/bugs/395103
<evand> pitti: that's problematic for us, as (as far as I can tell) the current code completely breaks dvorak being set in XKB_VARIANT (see bug 408292)
<ubottu> Launchpad bug 408292 in ubiquity "Keyboard layout setting did not take effect in installed system (dup-of: 395103)" [Medium,Confirmed] https://launchpad.net/bugs/408292
<ubottu> Launchpad bug 395103 in gdm "Gnome doesn't have my configured keyboard layout after login anymore" [High,Confirmed] https://launchpad.net/bugs/395103
<pitti> okay, but still it's a different cause now; we might need some workarounds for that
<pitti> evand: if it's important, can we please bump the prio of bug 421212, set it to karmic, and use that?
<ubottu> Launchpad bug 421212 in gdm "gdm ignores keyboard layout selection" [Low,New] https://launchpad.net/bugs/421212
<evand> absolutely
 * pitti doesn't like reopening old bugs
<pitti> ok, great
<evand> apologies for reopening your old bug
 * pitti shuffles bugs
<pitti> evand: none needed, just coordinating here :)
<RainCT> ion: it doesn't find the rtc module
<evand> :)
<pitti> evand: how's that now?
<ion> rainct: Ok, that isnât the problem either. Dunno then...
<evand> pitti: Looks good.  I just moved mdz's bug to be a duplicate of the new master.
<RainCT> ion: well, thanks :)
 * RainCT looks at Keybuk
<ArneGoetje> apachelogger: any chance we can get the language-selector changes uploaded?
<evand> pitti: thanks for sorting that
<pitti> evand: thanks to you; I don't have a clear idea yet how to fix that in gdm, since it requires changes in gnome-settings-daemon as well (hopefuully not in the stack below, like libxklavier)
<pitti> but I'll have a look at it
<evand> best of luck
<evand> if you need any help testing, do let me know
<pitti> testing should be easy
<kees> Keybuk: do you have an ETA for the udev signal bug getting fixed?  I can upload it if you don't have other changes pending (which I suspect you do...)
<Keybuk> kees: I'm waiting on an upstream release
<kees> okay
<kees> Keybuk: is that coming soon?  :)  My VMs keep breaking.
<Keybuk> kees: yes
<Keybuk> *shrug* karmic ;)
<Keybuk> ion: the modprobe failure thing is fixed
<Keybuk> though don't know why it would stop the boot
<Keybuk> nothing waits for module-init-tools (and even if it did, nothing waits only for success)
<ogra> i have a slowdown as well due to modprobe, remember ?
<ion> Yeah, it probably isnât the one stopping the boot. I only wanted the modprobe output in case it had been something like âread-only filesystem, can write blahblahâ.
<ogra> (with my unsupported touchscreen that has no driver and gets probed in a loop)
<ion> Which would have strongly suggested an issue in mountall. :-)
<ion> Oh, now that i think of it, modprobe probably doesnât need to write anything ever.
<Keybuk> yeah
<Keybuk> the virtual 1/2 type lines in the mountall --debug output are the important ones
<Keybuk> they tell you why it's waiting
<Keybuk> so far, all three people complained have "remote 0/4" or something in there
<Keybuk> and I get to do the "I told you not to try it if you had network filesystems" dance
<mathiaz> zul: so what's the state of moving puppet into main?
<zul> mathiaz: almost done, working on enabling the testsuite
<zul> ill take one more crack at it today
<mathiaz> zul: great!
<Keybuk> (and that's easy to fix 'echo initctl emit net-device-up > /etc/network/if-up.d/somescript' ;)
<soreau> Hello. I am having some trouble with snd_46xx on an old thinkpad and I found something that I want to try but I need a modules.conf file which of course doesnt exist. If I create one, where should it go so it will be respected?
<Pici> soreau: Under /etc/modprobe.d/
<soreau> Pici: ok thanks
<Laney> Keybuk: Interested in doing some debugging? sreadahead main process ... terminated with status 1, mountall: unable to write pid file: read only FS, debug pre-start process terminated with status 1, module-init-tools terminated with status 1
<mathiaz> zul: there are a lot of puppet dependencies in universe - http://paste.ubuntu.com/268694/
<mathiaz> zul: do all the required src packages have MIR written?
<mathiaz> zul: it seems that some of them are useless - like rails, wwwconfig-common
<zul> mathiaz: dont think so
<mathiaz> zul: it seems that the dependencies need to be reviewed - and only relevant one should be kept
<mathiaz> zul: before puppet can be moved to main
<zul> kees: ^^^
<kees> holy cow
<kees> zul:  your MIR report said only 3 weren't in main??
<zul> kees: uh...wtf
<zul> i need to go look at this again
<zul> puppetmaster recommends rails
<mathiaz> zul: also - one of your upload disables starting puppetmaster at install time - why?
<mathiaz> zul: right - I think most of what got pulled in are recommends - these can be dropped to suggests
<mathiaz> zul: dropping rails would be a good start
<mathiaz> zul: unless puppetmaster requires rails to run :/
<zul> mathiaz: i disabled it because it was required for the MIR
<mathiaz> zul: hm - in bug 408297? where?
<ubottu> Launchpad bug 408297 in puppet "MIR for puppet." [Undecided,Incomplete] https://launchpad.net/bugs/408297
<zul> mathiaz: see kees' comment: https://bugs.launchpad.net/ubuntu/+source/puppet/+bug/408297/comments/1
<ubottu> Ubuntu bug 408297 in puppet "MIR for puppet." [Undecided,Incomplete]
<mathiaz> zul: are you refering to debian bug 518831?
<ubottu> Debian bug 518831 in puppet "puppet: Default configuration is broken" [Important,Open] http://bugs.debian.org/518831
<zul> mathiaz: yes
<mathiaz> zul: IIUC the fix is to not start puppetd (ie the client) - I don't think the puppetmaster should be disabled as well
<zul> mathiaz: noted
<zul> actually its not started as well
<mathiaz> zul: bug 427466 - can I assign it to you?
<ubottu> Launchpad bug 427466 in puppet "puppetmaster not started by default" [Undecided,New] https://launchpad.net/bugs/427466
<kees> Keybuk: given that alpha6 is next week, do you mind if I upload the udev fix now, just to get it solved?  it may be causing issues with rsyslogd too
<zul> mathiaz, of course
<superm1> kees, if you do upload, coulud you also cherry pick http://git.kernel.org/?p=linux/hotplug/udev.git;a=blobdiff;f=extras/hid2hci/70-hid2hci.rules;h=e133afd62546a37a598ffd317badd0cb7081823e;hp=b332c168e981682eb58e29699b64f7b154fb6663;hb=8a0217ffd432e56231b0d1bccda71449bca5f8f6;hpb=2ffc9cc1917b1bb6fe86881a94a47dce9aa15168 ?  i was figuring we'd wait till udev 147, unless opportunistic
<kees> superm1: sure
<zul> mathiaz: you dont need rails for puppetmaster
<zul> mathiaz: rails would only be useful for the testsuite
<zul> and that seems to be broken atm still :(
<mathiaz> zul: right - if the test suite requires rails, it means it will be a build-dependency
<mathiaz> zul: and thus rails would have to be moved to main as well
<mathiaz> zul: and I don't think this is something we wanna do
<mathiaz> zul: (ie moving rails to main)
<mathiaz> zul: does all the test require rails?
<zul> mathiaz: it needs rails to build
<zul> and to run
<mathiaz> zul: to build and run the tests?
<mathiaz> zul: or to build puppet?
<zul> mathiaz: to build and run the tests
<mathiaz> zul: hmmm
<mathiaz> kees: ^^ what's your opinion on this?
<mathiaz> kees: I don't think we should pull rails into main
<mathiaz> zul: which part of rails is required?
<zul> but there is a MIR for rails that look it got approved
<mathiaz> zul: ?
<zul> havent got that far yet its still failing for me and im not a ruby expert
<mathiaz> zul: I don't a MIR for rails on wiki.u.c
<zul> i was wrong about the rails MIR must have been look at something else
<mathiaz> zul: I don't *see* a MIR for rails on wiki.u.c
<zul> yeah so its not something we want in main
<kees> I don't want rails in main
<zul> neither do i
<mathiaz> kees: zul: great - we all agree then :)
<kees> heh
<mathiaz> that means tests can't be enable in the build
<zul> ill fix that puppet bug then
<mathiaz> zul: can they still be run outside of the build process?
<mathiaz> zul: ie - could they be packaged separately?
<zul> mathiaz: i think so havent tried yet
<mathiaz> zul: I think the first step is to try to get them running
<mathiaz> zul: if that works try to package them - or leave instructions in a readme file
<zul> gotcha
<mathiaz> kees: ^^ would that work for you?
<kees> mathiaz: you're proposing documentation how to run the tests and verifying that they pass (but not during the build)?
<mathiaz> kees: yes
<kees> mathiaz: yeah, that seems like a fair compromise
<NCommander> any archive admin, can someone binNEW linux-mvl-dove? I'm kinda depwait for that to pass through the NEW queue
<kees> superm1: does the hid2hci commit fix a specific LP bug?
<NCommander> jdstrand, you around?
<jdstrand> NCommander: yeah
<superm1> kees, let me see, looks like it was bug 385934
<ubottu> Launchpad bug 385934 in bluez "Dell Bluetooth 370 does not work after resume from suspend" [Undecided,Confirmed] https://launchpad.net/bugs/385934
<NCommander> jdstrand, can you debinNEW a kernel for me?
 * NCommander has been depwait on this since yestreday :-/
<kees> superm1: okay, thanks.
<jdstrand> NCommander: did you try StevenK or Muharem? (it is thier day)
<jdstrand> NCommander: if they aren't available I can do it
<NCommander> jdstrand, LP was very unstable last night, so StevenK didn't want to try deNEWing anything at risk of breaking LP, and Muharem doesn't seem to be on (or at least, I can't see him on IRC)
<jdstrand> NCommander: is LP any better now?
<NCommander> jdstrand, its not 502ing forme anymore
<jdstrand> alright
<NCommander> jdstrand, thanks, sorry that you keep getting hit with the random kernels
<cr3> is there a way to detect whether a script is running in a live environment programmatically?
<NCommander> cr3, why?
<cr3> NCommander: if I'm running from live, I could easily use echo ubuntu | sudo -S in order to run commands as root without having to prompt the user for a password they might not even know
<cr3> NCommander: oddly, I thought there was no password and gksudo wouldn't even ever prompt anyways
<NCommander> cr3, sudo should just give you root on the live envirionment sans password
<cr3> NCommander: thanks for the confirmation, even better then :)
<NCommander> cr3, well, you could just download a livecd and check ;-)
<ahe> join #launchpad
<robbiew> udevadm trigger is not premitted while udev is unconfigured.
<robbiew> Gave up waiting for root device. Common problems:
<robbiew> -Boot args (cat /proc/cmdline)
<robbiew> Â Â -Check rootdelay= (did the system wait long enough)
<robbiew> Â Â -Check root= (did the system wait for the right device?)
<robbiew> -Missing modules (cat /proc/modules; ls /dev)
<robbiew> ALERT! /dev/disk/by-uuid/05d79451-0ad0-43fc-9f51-a2c98b4831f2 does not exist.
<robbiew> Dropping to a shell!
<robbiew> argh!
<robbiew> i hate this bug
<robbiew> kees: ^^^^^ once I fix this, should I run the script in bug 358654 to find the offending package(s)?
<ubottu> Launchpad bug 358654 in watershed "udevadm trigger is not permitted while udev is unconfigured" [Medium,Fix released] https://launchpad.net/bugs/358654
<jelmer> aaa~>
<kees> robbiew: yes please :)
<robbiew> kees: shell script identifies: fuse-utils and initramfs-tools
<robbiew> Keybuk broke it! ;)
<jdstrand> NCommander: done
<robbiew> well at least if initramfs-tools is the culprit...from the ubuntu-boot ppa...fun times!
<NCommander> jdstrand, +1 beer (to be redeemed at next meatspace meet)
<ScottK> Did someone say beer?
<NCommander> ScottK, jdstrand gotten stuck NEWing every ARM kernel since they seem to land around Fridays :-/
<ScottK> I see.  Well I'd suggest something stronger than beer then.
<engla> DktrKranz: ping
<DktrKranz> engla: pong
<jdstrand> heh, np
<apachelogger> ArneGoetje: sure, in a bit
#ubuntu-devel 2009-09-11
<ArneGoetje> apachelogger: thanks a lot. :)
<morfic> is ARM here to stay? somehow had the idea i read ubuntu dropped ARM support, i would love to be totally wrong on this though :)
<directhex> morfic, ubuntu/arm hardware will be in the shops for xmas
<morfic> i'd be happy to just keep ubuntu on this device if ubuntu is supporting it for a while
<kees> jcastro: in http://identi.ca/notice/9803393 did you mean you were trying to _raise_ your vrms score?  :)
<greg-g> kees: he's an instigator like that :)
<kees> I suspected.  :)
<LaserJock> I wonder how high I can get mine?
<kees> that's the meme I'm working on now.  ;)
<LaserJock> darn, only 0.7%
<LaserJock> how the heck am I gonna tick off the FSF with that low of a score!!
<LaserJock> and 1/2 of my score is from ATI/nvidia drivers, which I don't need
 * kees is waiting for a massive apt-get to finish...
<superm1> i dont think it's fair to count the modaliases
<superm1> they're flat text files, nothing non-free about them
<jcastro> you need all the sun java stuff to really make a difference
<stooj> Does anyone know of a python programme that uses policy kit?
<kees> I'm attempting to install all of multiverse and partner.  ;)
<LaserJock> so if I install all of multiverse I can get to 30%
<LaserJock> what we really need is a web-vrms that looks for non-free web apps
<kees>   342 non-free packages, 15.2% of 2252 installed packages.
<kees>   172 contrib packages, 7.6% of 2252 installed packages.
<greg-g> nice
<greg-g> LaserJock: that sounds like a great Fx plugin: "Sorry, vrms says that this site has non-free javascript and runs on .NET, you can't go here"
<[reed]> kees: what program is that?
<kees> [reed]: vrms
<[reed]> ah
<LaserJock> I'd love to run vrms on the Windows Vista desktop I just got today for work
<LaserJock> I'm sure I'd have a slightly higher score ;-)
<dholbach> good morning
<billybigrigger> so i ibus taking over for xorg for input?
<billybigrigger> now any keyboard and mouse issues should be attempted to be debugged through it?
<YokoZar> Does anyone else have Applications->Accessories->gedit instead of Applications->Accessories->Text editor?
<billybigrigger> i have gedit
<poolie> doko: thanks for the fix for bug 392355, i'll test it
<ubottu> Launchpad bug 392355 in bzr "C extensions placed in wrong directory on karmic" [High,Confirmed] https://launchpad.net/bugs/392355
<directhex> hm. one of my syncs seems to have evaporated
<directhex> https://bugs.launchpad.net/ubuntu/+source/mono/+bug/426759 is "Fix Released", but I can't find it on the package publishing history nor the karmic queue
<ubottu> Ubuntu bug 426759 in mono "Sync mono 2.4.2.3+dfsg-2 (main) from Debian unstable (main)." [Wishlist,Fix released]
<ogra> cjwatson, "Run usplash at the native resolution if KMS is available." where does usplash get the info about the theme/resolution to use for that ?
<ogra> (i'm trying to convince it to use the matching framebuffer res on armel without defaulting to 640x480 and without making Keybuk unhappy by looking for a file that holds the res from initramfs)
<cjwatson> ogra: can you use bzr log / bzr diff? the patch is fairly simple
<cjwatson> if you read the diff and still don't understand, then ask me :)
<directhex> blarg, why is my system so much less stable post-format?
<Laney> you should have installed warty and upgraded
<directhex> this system has never had warty
<Laney> thats your problem right there
 * Laney runs
<pitti> Good morning
<simon-o> Hi, I fixed a bug and uploaded the branch. It is enough to file a merge proposal or do I need to subscribe ubuntu-main-sponsors to the bug?
<mvo> simon-o: for what package and bug?
<simon-o> mvo: bug 376400 package graphviz
<ubottu> Launchpad bug 376400 in graphviz "dot2gxl gets segfault even with simple graph" [Undecided,Confirmed] https://launchpad.net/bugs/376400
<mvo> simon-o: subscribing ubuntu-main-sponsors is probably a good idea then
<mvo> to ensure it is picked up by the sponsoring queue
<simon-o> mvo: thanks, I just subscribed them.
<mvo> simon-o: thank you for working on it!
<slytherin> are there any rescue images for karmic? I got a unbootable PC because of bug 424503 and I don't want to download whole karmic daily CD. :-(
<ubottu> Launchpad bug 424503 in grub2 "Boot fails with Out of Range Pointer error" [High,Confirmed] https://launchpad.net/bugs/424503
<YokoZar> slytherin: you could try a stick image...but those are larger than the CD
<YokoZar> so not really ;)
<slytherin> ahh, I will download the CD image.
<slytherin> sad thing is I didn't even have backup of old cd image (2 days old). So I can not even use jigdo/zsync.
<cjwatson> you can use the netboot image to rescue
<cjwatson> in a pinch
<cjwatson> http://cdimage.ubuntu.com/netboot/
<slytherin> cjwatson: I will try when I go home. Thanks for info.
<slytherin> cjwatson: mini.iso is the image, right?
<cjwatson> yeah
<zyga> mvo: hello
<zyga> mvo: is there any list of small tasks that 3rd parties could help you with the app store?
<mvo> zyga: I have a "TODO" file in the source, there is also the "bitesize" tag in the bugreport
<mvo> zyga: the bugreports of software-store
<zyga> mvo: let me check that! :-)
<mvo> zyga: there are quite a few smallish UI bits that are not done exactly as the spec says
<mvo> :)
<zyga> mvo: is it possible to do development on jaunty?
<mvo> zyga: difficult, it uses aptdaemon and that is not available on jaunty
<mvo> zyga: it would be a good idea to isolate that into a common class that can then be exchanged for a Mock class (or even a synaptic backend ;)
<mvo> zyga: then it can be run under jaunty just fine AFAICS
<mvo> zyga: that would be a nice task, something like the backend/ dir in update-manager
<zyga> mvo: I'm fine with karmic kvm but I'll reinspect in a second - I need to find & fetch sources first
<mvo> zyga: bzr get lp:software-store should do the trick
 * mvo hugs zyga - great to have you back here :)
<zyga> :-)
<zyga> I'm ill so I have some time off from my regular work
<zyga> mvo: I've got it - let me have a look at what's already there
<lool> cjwatson: hola
<lool> cjwatson: You might remember chaning usplash to use the native kms resolution
<mvo> zyga: oh, get well
<lool> cjwatson: (I do see that usplash is not that much relevant anymore but still)
<lool> cjwatson: You actually changed the init/shutdown scripts to not pass -x / -y
<lool> cjwatson: But that causes usplash to try to modeset to the first res in the linked list of themes
<lool> cjwatson: Which is 640x400
<lool> cjwatson: So we're actually using 640x400
<lool> cjwatson: I tried an ugly patch to use the /sys values from the native kms virtual size and pass these as usplash xres/yres
<lool> cjwatson: And result was nice
<lool> cjwatson: So I wanted to double check whether it was intentional or not to use 640x400 (ogra suggested it might be to get the 640x400 centered around black)
<cjwatson> lool: I thought that it would normally simply use the boot resolution
<cjwatson> the intent was that it would do so
<ogra> usplash does only what you tell it :)
<ogra> and uses 640x400 if you dont tell it anything
<cjwatson> that isn't really true, when it comes up bogl_xres is set to the native resolution
<cjwatson> something slightly odd is happening if that isn't the case
<lool> cjwatson: if there's no -x/-y and no usplash.conf, usplash uses the first theme res as default xres/yres and modesets to that
<cjwatson> ok, that was not my expectation. feel free to fix
<lool> cjwatson: Ok thanks
<cjwatson> I don't think you should use /sys though; it would be better to have an option to usplash to use whatever resolution the framebuffer is currently in
<lool> cjwatson: Do you see any issues with reading these values from /sys?
<cjwatson> I do, it's ugly :)
<lool> cjwatson: I absolutely agree
<cjwatson> usplash is perfectly capable of figuring out the current fb resolution - it's just a matter of picking a theme based on that
<cjwatson> I'd absolutely be in favour of such a change
<lool> Ok
<lool> It's not a 5 minutes change like reading from /sys though but I agree it's the right thing to do
 * ogra only sees usplash_bogl_set_resolution(int xres, int yres) but no "get_resolution" in usplash_bogl.c
<cjwatson> getdimensions
<zyga> mvo: is it possible to replace aptdaemon with something like packagekit?
<ogra> ah, right, i see it
<zyga> mvo: I'm just wondering how to run it right now
<zyga> mvo: is it conceptually the same thing?
<mvo> zyga: yeah, packagekit, synaptic, aptdaemon, its just the install backend
<mvo> zyga: ideally it should be a backend class so that the backend can easily be switched
<zyga> mvo: it looks like atpdaemon is used everywhere, including the ui
<zyga> mvo: if that's what you want I could try to hack it to move all stuff to backend and just glue the current code to use that backend
<zyga> I'll probably move to karmic to get aptdaemon though
<zyga> i'll be easier this way
<zyga> mvo: is there any particular abstract interface thingy you like (like from abc import ... ) ?
<mvo> zyga: ok, my plan is to eventually move the aptdaemon stuff all out into a single place, but I have not had time for that, so just using karmic is easier for now :)
<mvo> zyga: no preferences here
<zyga> mvo: okay
<lool> cjwatson: the svga backend (but not the bogl backend) sets the res on init; should I care about that backend or is it ok if I only cover the bogl one?  I dont know whether the SVGA backend is actively used and whether it's important that it sets the res
<cjwatson> lool: svga is used on x86
<cjwatson> lool: for arm you don't need to worry
<lool> Pff bogl does a kernel ioctl with xres/yres set to the defaults of 0 and this is kernel driver specific
<zyga> I've got karmic :-)
<geser> looking at http://launchpadlibrarian.net/31587515/buildlog_ubuntu-karmic-amd64.cmake_2.6.4-1ubuntu2_FAILEDTOBUILD.txt.gz I wonder what's the right fix. Move the missing header file from libxmlrpc-c3-dev to libxmlrpc-core-c3-dev or merge both -dev packages again as it was split so libxmlrpc-core-c3-dev could get into main but currently both libxmlrpc-c3 and libxmlrpc-core-c3 are in main so there is no
<geser>  real reason for the split.
<Keybuk> kees: yes, I do mind
<Keybuk> kees: pulling random patches makes it hard to test things, and in general I do not want any patches in the Ubuntu package - we should only ship the upstream releases with no changes
<Keybuk> there will be a new upstream release rsn, I will package that as soon as it's out
<Keybuk> so be patient
<Keybuk> we are not releasing *tomorrow*, there is plenty of time
<james_w> I'm looking for other opinions from other devs on https://code.launchpad.net/~statik/ubuntu/karmic/couchdb/fix-bug427036/+merge/11543
<lool> cjwatson: (I'm moving ogra's /sys reading from initramfs-tools to usplash but still intend to replace that stuff with proper usplash code)
<ogra> lool, but please remove the dependency on mxcfb (else you need to read /proc/cmdline again from the usplash script) and make it look more like cjwatson's fix
<lool> ogra: ?
<lool> ogra: I'll show you what I have
<ogra> ok
<ion> keybuk: Do you have time to review the current mountall patches?
<ogra> i have the code pretty much in my head (how i would do it)
<ogra> lets see if we match :)
<lool> ogra: http://paste.ubuntu.com/269076/
<lool> ogra: I'm still finishing it, there's a typo (res instead of virtual_size)
<ogra> even better than mine (i wouldnt have touched colins part :) )
<ogra> yours fixes both :)
<lool> Well I know it's ugly but at least it's consistent and will use the right res immediately for everybody and we used to check /sys for kms already
<lool> But I intend to remove the /sys checks when I'm done
<ogra> yeah
<ogra> hacing it all in the C code will even make usplash.conf obsolete :)
<ogra> *having
<Keybuk> ion: not yet; I'm working on the network stuff
<Keybuk> ion: but I did briefly look through them and they looked ok
<Keybuk> ion: can't find the URL?
<lool> ogra: I dont really know why we bother with usplash.conf in the usplash init-top and _down scripts since usplash will parse the .conf by itself if we dont set it on the cmdline
<pitti> james_w: replied in the merge request
<james_w> thanks pitti
<james_w> pitti: tangential question, could you tell me what led you to vote "Abstain" on that request
<ogra> lool, yeah, thats redundant
<james_w> (so I can pass on the feedback to the LP devs as I think this is a failing in the UI)
<ion> keybuk: http://heh.fi/patches/mountall/
<Keybuk> ion: yeah found it
 * Keybuk has a weird issue where if I reply to a mail, it appears to get deleted
<ion> Huh
<Keybuk> I'm not convinced it's not PEBCAK
<pitti> james_w: there wasn't anything else that said "I just want to add a comment"
<pitti> james_w: perhaps I should just have left it as "Select.."
<james_w> did you use one of the "Reply" links, or something from the table at the top?
<pitti> james_w: "reply"
<james_w> ok
<james_w> thank
<james_w> s
<pitti> james_w: in retrospect I should probably have voted "needs fixing", but I set it first before typing the comment
<lool> Can usplash.conf have anything else than xres and yres?
<lool> like verbose or something
<lool> I think not but perhaps I'm wrong
 * ogra thinks not either
<Amaranth> verbose is a grub boot line thing
<Amaranth> afaik usplash only has those two options
<ogra> well, usplash has three more options beyond -x and -y
<ogra> but i dont think it is able to read any of them from usplash.conf
<ogra> (only -p and -c would be relevant at all even)
<ogra> ah, no -v probably too :P
<ogra> lool, the code in libusplash.c only reads x/y it seems
<Keybuk> ion: they look ok to me
<Keybuk> thanks for your hard work on that
<Keybuk> I shall merge those in once I've finished the network testing :D
<ion> np
<ion> Aye :-)
<sridhar> hii
<cjwatson> soren: do the walrus/cluster/sc have to be running in order to register them, or is it better if they aren't?
<ogra> cjwatson, what do we do about the binfmt/mono/chroot issue, do you agree its worth having a bug for it ? (probably even security flagged)
<cjwatson> ogra: sure, seems like a kernel bug, though it would really be best to take it up with upstream
<ogra> hmm
<ogra> i still need to do a proof of concept first before i like to go upstream (set the interpreter in binfmt/cli to $chroot/$path_to_interpreter instead of /$path_to_interpreter to trigger teh right magic bit)
<cjwatson> ogra: it won't work
<cjwatson> the interpreter will look for files in the host system if you do that
<pacopil> online boxing game http://www.kobox.org/kobox-fande-Nourine.html
<lool> pitti: I see you were working on usplash changes; FYI I pushed some changes
<lool> pitti: is this for A6?
<pitti> lool: maybe, need to wait on some input from design team
<pitti> lool: I don't mind it being uploaded now, though
<lool> pitti: So your changes are uploadable?
<pitti> lool: yes, they are
<lool> Ok cool
<ogra> cjwatson, https://bugs.launchpad.net/linux/+bug/427863 in case you are intrested (linked to the upstream report)
<ubottu> Launchpad bug 427863 in linux "binfmt allows breaking out of chroots due to not respecting namespaces" [Undecided,New]
<kirkland> pitti: did you get a chance to look at Bug #426724 ?
<ubottu> Launchpad bug 426724 in gnome-control-center "login-screen has no user-pictures" [Wishlist,In progress] https://launchpad.net/bugs/426724
<pitti> kirkland: still on my list; I reviewed the patch and left a comment there
<pitti> kirkland: I'm way too busy today, I'm afraid, but I hope I can slip it in next week
<kirkland> pitti: cool
<kirkland> pitti: hmm, for some reason, LP didn't email your comments
<bigon> https://edge.launchpad.net/ubuntu/+source/kvm O_o disapears from karmic?
<kirkland> pitti: i'll drop the asprintf part, and resubmit
<MacSlow> pitti, seb128: where's the gnome-session type (vanilla vs. stratiatella) selected (in which file)?
<pitti> kirkland: right, that's the easy part; I need to do the same for ~/.dmrc (feel free to beat me to it, of course)
<kirkland> pitti: i couldn't immeidately find that code ...
<pitti> MacSlow: argh, I think stracciatella-session still needs porting to the new gdm as well
<kirkland> pitti: the part that reads/writes dmrc.  .face was much more obvious
<pitti> kirkland: hm, I don't know it off-hand either, I'm afraid (I'm not very familiar with the gdm code base yet)
<pitti> MacSlow: but it should actually be pretty easy, it's just dropping a new file into /usr/share/xsessions/
<kirkland> pitti: alrighty, i'll take another look while i'm fixing asprintf()
<MacSlow> pitti, ah ok
<MacSlow> thanks
<cjwatson> bigon: qemu-kvm
<bigon> cjwatson: oh right thx
<bigon> :)
<pitti> kirkland: cheers
<kirkland> pitti: okay, i found the dmrc load and save code, that's pretty straightforward
<pitti> kirkland: so if you can read ~/.dmrc, use that, otherwise fall back to ~/.ecryptfs/.dmrc?
<kirkland> pitti: unfortunately, though, we don't have the user's name easily on hand at that point, only their home
<kirkland> hmm, that should work
<kirkland> pitti: thanks
<cumulus007> Hi, how often are updates of ubuntu translations from launchpad distributed?
<soren> cjwatson: Uh... I'm not sure to be honest.
<dpm> cumulus007: for development releases, every few days, unless there is a freeze in between. For stable releases, approx. monthly. You might also want to check out the #ubuntu-translators channel if you're interested in Ubuntu translations
<cumulus007> dpm: Thanks for the info :)
<jdstrand> seb128: this may not be your area, it might be devicekit's, but nautilus shows under Places all my schroots that are under /dev/mapper. This is somewhat undesirable as I have 13 of them. Is this a known bug? is there a preference I can set somewhere?
<seb128> jdstrand, it's probably a gvfs issue
<seb128> can you open a bug with a gvfs-mount -li log and maybe a testcase?
<jdstrand> ok
<ogra> Keybuk, are there plans to pull insserv in ? seemingly debootstrap adds a dep on it ( NCommander told me )
<cjwatson> (fwiw this is not something that is up to debootstrap, it's just the messenger)
<soren> upstart depends on it as well, doesn't it? By way of sysvinit or something?
<NCommander> soren, it looks like it's been living in universe though
<soren> NCommander: It's a new dependency,presumably.
<NCommander> soren, right. As it stands, modules-tools-init fails to configure since update-rc.d tries to use insserv, and boom, broken base system
<cjwatson> sysv-rc Depends: insserv; perhaps a mismerge
<soren> cjwatson: I'm not sure. Keybuk recently uploaded a new insserv, so it's definitely on his radar :)
<NCommander> cjwatson, update-rc.d tries to call it :-/
<cjwatson>   * debian/sysv-rc.postinst: Don't try and use insserv by default, though
<cjwatson>     everything's in place for you to try if you like.  It can be activated
<cjwatson>     with:
<cjwatson>         USEINSSERV=yes dpkg-reconfigure sysv-rc
<cjwatson> so I think the dependency and the attempt of update-rc.d to use it is a mistake
<soren> Ah.
<ogra> definately :)
<cjwatson> I'm not going to touch it at the moment though, leave it to Scott :)
<NCommander> :-)
<cjwatson> since there's a sysvinit in the ubuntu-boot PPA
<mneptok> cjwatson: do you know who is building Empathy packages for Karmic?
<mneptok> Empathy was removed during a dist-upgrade >12h ago due to a shared lib problem. no sign of a rebuilt version based on the newer libs.
<cjwatson> https://launchpad.net/ubuntu/+source/empathy says bigon was the last uploader
<mneptok> k
<mneptok> thanks. still working on the first cuppa, so LP is too much for my fingers just yet. :)
<seb128> mneptok, what architecture do you use?
<mneptok> seb128: amd64
<mneptok> seb128: i had trouble finding a HPPA laptop
<mneptok> :/
<seb128> was probably an arch all any mismatch
<ogra> use a sparc one
<mneptok> ogra: i tried. Larry Ellison came in the night and stole it.
<ogra> bah, bad guy
<bigon> mneptok: some pkg are still stuck in new queue
<bigon> seb128: did you had the time to let pass empathy trough the new queue?
<mneptok> bigon: d'accord. j'attend.
<Turl> fta: can you have a look at https://bugs.launchpad.net/ubuntu/+source/prism/+bug/246822 ?
<ubottu> Launchpad bug 246822 in prism "Prism should be updated to new upstream version 1.0b1" [Wishlist,Confirmed]
<seb128> bigon, mneptok: done now
<kees> Keybuk: argh, sorry, I had already uploaded.  I only did it because it was causing me a lot of problems in my VMs (since all the signal handlers where broken, and doing dist-upgrades over ssh was tanking)
<mneptok> seb128: thanks. waiting for it to trickle down, i guess. no updates to install here.
<seb128> mneptok, right, you need to wait an hour for next publisher run
<mneptok> seb128: you expect an American to *wait*?! ;)
 * mneptok scrambles the bombers
<jdstrand> cjwatson: I am either doing something wrong or mass-sync/backport.py is busted: http://paste.ubuntu.com/269246/
<jdstrand> cjwatson: hi btw!
<jdstrand> cjwatson: I tried with '-l production' too, but got the same error
<cjwatson> err, blink, didn't see that when I last used it
 * jdstrand scratches head
<jdstrand> cjwatson: I did just get python upgraded on my machine...
<cjwatson> jdstrand: who's the requestor of this particular bug? (LP id)
<jdstrand> cjwatson: dobey
<jdstrand> cjwatson: bug #397431
<ubottu> Launchpad bug 397431 in jaunty-backports "Please backport python-oauth 1.0~svn1053-0ubuntu1 from Karmic to Hardy" [Wishlist,In progress] https://launchpad.net/bugs/397431
<jdstrand> cjwatson: my backport.py invocation is in the paste
<ScottK> slangasek had an interest in that one too.
<cjwatson> it's not just backport.py anyway
<cjwatson> >>> launchpad.people['dobey'].preferred_email_address
<cjwatson> Traceback (most recent call last):
<cjwatson> so it's either a launchpadlib (or deps) bug or an LP bug
<jdstrand> yeah, hmm
<jdstrand> I hate those
<jdstrand> cjwatson: ok, thanks. I'll get this to the attention of the right people
<cjwatson> ta
<lool> doko: lp:~lool/glibc/eglibc-vfp-testsuite-updates
<lool> doko: Could you please merge this when you upload ubuntu9?
<lool> I created an ubuntu10 on top
<lool> doko: Fixes testsuite failures on armel
<lool> NCommander: ^
<lool> Keybuk: Can you help with the insserv MIR?  LP #427709
<ubottu> Launchpad bug 427709 in insserv "[MIR] insserv" [Critical,Triaged] https://launchpad.net/bugs/427709
<lool> I can guess the rationale etc. but it's a bit weird that I document why it's needed myself and then tend to the review
<ogra> you could as well just shove it in and write "because"
<NCommander> doko, this is low priority, but I'll see if I can do something to help fix powerpc failures (I'm not sure if I'll have any free cycles in the near future to look at it :-/)
<doko> lool: done
<lool> doko: thanks!
<lool> doko: Are you uploading this today BTW?
<lool> doko: Or shall we revert the glib changes on armel
<pitti> stgraber: sabayon was removed from Debian, with "ROM; almost completely broken"; should we follow suit? are you using it in edubuntu?
<pitti> it doesn't have any rdepends
<pitti> ./ubuntu.karmic/dvd: * sabayon            # desktop profile management
<pitti> ./edubuntu.karmic/supported: * sabayon            # desktop profile management
<pitti> that's it
<pitti> seb128: ^
<doko> lool: I'll upload, just finished testing on lpia
<jdstrand> cjwatson: fyi, the backport.py issue is bug #319432
<ubottu> Launchpad bug 319432 in launchpadlib "RelativeURIError when trying to access an redacted object" [Low,Triaged] https://launchpad.net/bugs/319432
<lool> doko: ok thanks!
<cjwatson> thanks
<cjwatson> mvo: do you have any idea what it is that causes all these "Package foo is already installed and configured" bug reports?
<RainCT> seb128: Hey. I've got a question. The Zeitgeist binary package is currently called 'zeitgeist-core' but I think I'd better have it as just 'zeitgeist' now, any opinions on this? (basically what I'm wondering is whether a transitional package would be needed)
 * pitti chuckles
<seb128> RainCT, don't bother doing a transitional package no if was never in stable
<pitti> Removing candidates:
<pitti> ia32-libs-tools 14 in karmic
<pitti> ment: (From Debian) RoThe Project; Most idiotic breakage ever
<pitti> oops :/
 * pitti wonders whether to remove it from karmic as well
<pitti> cjwatson, slangasek: does that touch our multiarch efforts? ^
<RainCT> seb128: Great, so I can just rename it with the next revision?
<seb128> yes
<cjwatson> ia32-libs-tools is the ia32-apt-get thing, isn't it? I didn't think that we'd changed our ia32-libs to use that (intentionally not)
<RainCT> seb128: ok, thanks :)
<cjwatson> jdstrand: you could always edit the script temporarily and hardcode an e-mail address :)
<pitti> cjwatson: right
<pitti> cjwatson: no, we didn't, we still have the usual mega-.deb with the .so files included
 * pitti kills it, easy enough to revive
<slangasek> pitti: doesn't affect us in the least
<ulaas_> hi. what is the default theme for karmic gnome desktop?
<ulaas_> still human?
<slangasek> cjwatson: geser is reporting that a large number of the rebuild failures are false positives due to bug #412933; can we stop the rebuild run if it's ongoing, and do another one once that's fixed?
<ubottu> Launchpad bug 412933 in eglibc "bayonne FTBFS with g++-4.4: wrong prototype for strchr()" [Medium,Triaged] https://launchpad.net/bugs/412933
<slangasek> (I'll look at fixing that in eglibc today)
<cjwatson> slangasek: I'd be happy to stop it, but LP timeouts loading the relevant page at the moment
<slangasek> heh, ok
<slangasek> geser: ^^ :)
<cjwatson> I don't get it though, eglibc is clearly trying to arrange for C++ strchr(const char *) -> const char * and strchr(char *) -> char *, and the prototypes look right for that. What's wrong with it?
<cjwatson> obviously that makes no sense in C :-)
<cjwatson> it appears to have been a change made for ISO C++ conformance
<slangasek> oh, really?
<jdstrand> cjwatson: is backport.py supposed to be able to handle backporting to a suite where the package doesn't already exist?
<jdstrand> cjwatson: eg, foo is in karmic, but not in hardy. should backport.py be able to put foo in hardy-backports?
<mvo> cjwatson: "foo already install and configured"> I think I have a fix in bzr
<slangasek> cjwatson: do you have a reference handy?  (And if that's the reason, why is the eglibc code #if gcc_4_4'ed?)
<jdstrand> cjwatson: it doesn't now, and I am deciding if I should error out more clearly or fix it so it works
<cjwatson> jdstrand: it ought to just land in NEW; if it doesn't, that's a bug
<jdstrand> cjwatson: ok, thanks
<cjwatson> mvo: yay, I'd been wondering about that. Where, update-manager or elsewhere?
<cjwatson> slangasek: no, I'm just inferring from the fact that the relevant prototypes are guarded by #ifdef __CORRECT_ISO_CPP_STRING_H_PROTO
<cjwatson> slangasek: note that /usr/include/c++/4.4.1/cstring does stuff with that definition as well, so I infer that glibc and libstdc++ needed to cooperate on it, which is probably why it's specific to g++ 4.4
<mvo> cjwatson: in apt itself, it seems to mis-interpret a dpkg state
<slangasek> I think when I was looking at it before, I didn't even notice the difference in the argument type
<geser> slangasek: might not be the best reference but http://www.cplusplus.com/reference/clibrary/cstring/strchr/ talks also about two declarations for strchr() in C++
<slangasek> oops
<cjwatson> mvo: oh, neat
<slangasek> geser: right - sorry for steering you wrong
<geser> slangasek: so I can continue fixing it?
<doko> lool: I don't rush the upload now, I'm going to upload gcc-4.4 before the glibc build. will do that tomorrow, leaving now
<slangasek> geser: yes
<slangasek> geser: and I need to re-do a fix to kismet, reopen a bug, and apologize to quadrispro when I see him :)
<geser> slangasek: and you could also sponsor bug #427791
<ubottu> Launchpad bug 427791 in cwidget "[FTBFS] error: invalid conversion from 'const char*' to 'char*'" [Undecided,New] https://launchpad.net/bugs/427791
<cjwatson> right, so the problem in bayonne is that strchr(tone, '/') returns const char * - i.e. the warning is regarding the return value, not the first argument
<cjwatson> or the error, rather
<statik> hi doko, i'm having some problems with the latest python2.6 upload, bug #428004
<slangasek> geser: ack
<ubottu> Launchpad bug 428004 in ubuntuone-servers "building of python C extensions is broken" [Critical,Confirmed] https://launchpad.net/bugs/428004
<cjwatson> (it's being assigned to a char *)
<slangasek> cjwatson: yes, now that I've been pointed at the real difference between the difference in the prototypes, I grok why it's a bug
<statik> doko, i don't know enough about setuptools to fix it myself, but i think that bug report shows exactly what is failing
<doko> statik: hmm, poolie did acknowledge that something like this was fixed with the recent upload
<cjwatson> slangasek: *nod* just spelling it out since I'd gone to the effort of looking :-)
<slangasek> geser: ack, will grab after I unblock some folks waiting on FFes
<oussama> hello everybody
<statik> doko, yes thats what is so interesting about it! building in place was working fine for my team until today/yesterday
<doko> statik: will try to look at the weekend. I'm away now
<cjwatson> (p.s. I *love* being able to do https://code.launchpad.net/ubuntu/+source/bayonne rather than having to download the whole source
<cjwatson> )
<lamont> bug 396700
<ubottu> Bug 396700 on http://launchpad.net/bugs/396700 is private
<cody-somerville> pitti, Does apport include the contents of the DCD file in bug reports?
<geser> cjwatson: I hope you didn't manage to stop the rebuild
<ScottK> statik: I can build C extenstions that don't use setuptools, FYI.
<cjwatson> mvo: have lots of duplicates ;-)
<lool> pitti: Pushing new glib2.0 without --enable-assert-messages on armel as doko indicated he will only upload eglibc tomorrow
<cjwatson> geser: no
<slangasek> wgrant: I don't suppose http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20090909.html has a way to incorporate successful archive builds from later versions of the package?  (i.e., auto-detect that the bugs have been fixed)
<geser> slangasek: unless uploads to the main archive propagate also to this rebuild archive, a change in the script would be needed to check if there is newer version in the main archive than the rebuild archive and omit those packages
<slangasek> geser: sure - that seems like an obviously beneficial change to make to the script, though :)
<ogra> pitti, you guys discussed sabayon today ? i know sbalneav puts a lot of time into it but doesnt know much about packaging, it would be a shame to lose it
<ogra> pitti, he does all his work upstream and provides ppa's with our packages including his patches, i know it works fine for many people from his ppa, he just needs someone to spnsor and do the packaging from the motu crowd
<geser> can anyone advise me what would be the best fix for http://launchpadlibrarian.net/31643733/buildlog_ubuntu-karmic-i386.cmake_2.6.4-1ubuntu2_FAILEDTOBUILD.txt.gz? libxmlrpc-c3-dev got split into libxmlrpc-c3-dev and libxmlrpc-core-c3-dev to let libxmlrpc-core-c3-dev into main. cmake build-depends on libxmlrpc-core-c3-dev and the missing header is in libxmlrpc-c3-dev. The options are now to move the
<geser> missing header to -core-c3-dev or merge the both -dev packages again as both are now in main (don't know why)
<cjwatson> mvo: should we consider a stable update for that apt bug at some point, perhaps?
<mvo> cjwatson: yeah, I think that is a good idea, lets see if its really fully fixed or if there are other corner cases too
<jdstrand> cjwatson: fyi, updated backport.py to workaround the bug we discussed earlier and fixed synclib.py to handle NEW packages. backport.py and mass-sync both are working now
<jdstrand> (commits 68 and 69)
<cjwatson> jdstrand: thanks
<mneptok> bigon: FYI, i needed to manually re-install Empathy once the libs were updated.
<cjwatson> mvo: would you expect to see that bug on a package that does *not* have triggers itself?
<cjwatson> mvo: I've found lots on packages shipping triggers, which are presumably the same thing - but also lots on packages that don't seem to have triggers of their own
<cjwatson> mvo: I just searched for "already installed and configured" on https://bugs.launchpad.net/ubuntu
<mvo> cjwatson: the bug for packages that are shipping triggers (like man-db) should be fixed with bug #414631 (in bzr)
<ubottu> Launchpad bug 414631 in apt "package man-db 2.5.5-1build1 failed to install/upgrade: package man-db is already installed and configured" [Undecided,Fix committed] https://launchpad.net/bugs/414631
<mvo> cjwatson: the others will need extra analysis
<cjwatson> ok, I won't dup those
 * mvo looks at the output
<mvo> uh, many
<statik> ScottK: ah thanks for pointing that out about non-setuptools, I'll amend the bug summary
<mvo> cjwatson: I can do that monday, sorry that I have not gotten around to that apt upload yet :(
<cjwatson> no problem, thanks
<lool> jdstrand: I dont get the changes in 427663??
<jdstrand> lool: no, you wouldn't. the reporter was paulliu
<jdstrand> lool: if you ack I'll process
<jdstrand> lool: heh, that didn't come out quite right
<jdstrand> lool: I was answering your question in the bug:
<lool> jdstrand: oh sorry
<jdstrand> Jamie, I'm core dev so I dont think I need universe-sponsors?
<jdstrand> 13:22 < jdstrand> lool: no, you wouldn't. the reporter was paulliu
<lool> jdstrand: I mixed it with my own syncs
 * jdstrand didn't mean to come of snarky :)
<lool> jdstrand: let me approve it hold on
<jdstrand> off
<lool> jdstrand: approved thanks
<lool> jdstrand: and sorry
<jdstrand> lool: sure! glad to help :)
<paulliu> lool: thanks.
<NCommander> Does anyone know how big the entire archive is ATM?
<sebner> NCommander: ah good to see you, Did you get my mail a couple of days ago (about vtk) ?
<NCommander> sebner, no
<sebner> :(
<sebner> NCommander: I wrote to sonicmctails@gmail.com
<NCommander> sebner, might have missed it (all the LP bug mail goes there)
<NCommander> sebner, what was it?
<RainCT> Uhm.. Somehow knows how I can get apport to catch crashes of unpackaged stuff?
<NCommander> RainCT, package it :-)?
<sistpoty> RainCT: use gdb :P
<RainCT> NCommander: Heh. No, I want it for stuff under development
<RainCT> sistpoty: Tried that, but gdb loves freezing my session when the app it's running crashes
<sebner> NCommander: vtk ftbfs on armel, lpia and powerpc and at least there seems to exist a fix in debian bts for armel and I asked if you can take a look at it. (and maybe the other platforms (They ftbfs on another position))
<sebner> huhi sistpoty =)
<sistpoty> hi sebner
<sistpoty> RainCT: oh, that doesn't sound healthy for gdb
<sebner> sistpoty: debian websvn telle me: Prepare nexuiz 2.5.1! \o/
<sebner> *tells
<sistpoty> sebner: heh... must admit I've lost track a little bit of nexuiz
<NCommander> sebner, looks like an EJAVAPROBLEM
<RainCT> sistpoty: at least it's doing that for both gnome-shell and gnome-voice-control. Maybe it only happens with panel-related stuff :P
<NCommander> sebner, got a debdiff? I'll sposnor it
<NCommander> (after confirming a test build on armel or powerpc)
<sebner> NCommander: nothing yet because I don't have an armel machine to test so I wrote you a mail ;)
<sistpoty> RainCT: you could set a limit for coredumpsize (with limit) and look at the core dump?
<sebner> sistpoty: no worries, the commit message is 1h old ^^
<NCommander> sebner, hrm, odd
<NCommander> sebner, it was marked as NEW, but I didn't see it in my inbox
<sebner> NCommander: heh, no worries :)
<sebner> NCommander: I make a debdiff and you testbuild it? deal?
<NCommander> sebner, how big of a diff do we have from Debian?
<NCommander> sebner, I rather just NMU in Debian and sync it
<sebner> NCommander: aha! I just noticed that it seems debian fixed the issues
<sebner> NCommander: will need a merge though
<sebner> NCommander: dependency thing and python2.6
<RainCT> sistpoty: uhm I've done "ulimit -c 1000000", now what?
<NCommander> sebner, do that, I'll sponsor the change
<sebner> NCommander: well, you can review if you want, I can sponsor myself ^^
<NCommander> sebner, :-P
<sebner> NCommander: you are just the "armel" guy :P
<NCommander> and the powerpc, ia64, and sparc guy
 * NCommander kicks debbugs
 * sebner hugs NCommander :)
<sistpoty> RainCT: yep, then you should get a coredump if you start it from a shell and it crashes. You can then inspect the coredump with gdb
<sistpoty> RainCT: unless there's another limit that you also need to set, and which I constantly forget *g*
<RainCT> sistpoty: ah, where is this file supposed to appear? didn't get anything in the cwd
<sistpoty> RainCT: in cwd actually
<geser> ulimit -c?
<RainCT> 1000000
<sistpoty> RainCT: works for me at least: zsh: segmentation fault (core dumped)  ./test.bin
<sistpoty> RainCT: unless the program you try to debug has its own segfault handler
<geser> sistpoty: what's your value for /proc/sys/kernel/core_pattern?
<sistpoty> geser: core
<geser> RainCT: and you?
<sistpoty> (I don't have apport installed, maybe that makes a difference?)
<RainCT> geser: |/usr/share/apport/apport %p %s %c
<geser> set it to core
<geser> see man 5 core
<sistpoty> geser: nice, thanks for the info
<geser> if you pipe it to a command it doesn't get written to disk
<RainCT> maybe it just doesn't work with shell (it has a wrapper script and works as a plugin upon mutter or some weird stuff), I'll try it with gnome-voice-control but first I've got to eat something :P
<RainCT> sistpoty, geser: thanks for your help :)
<sistpoty> np ;)
<sebner> NCommander: http://paste.ubuntu.com/269358/ <-- if you are fine with it I'll upload it after a testbuild
<NCommander> sebner, uploading to my PPA
<sebner> NCommander: I don't have any space left on / so pbuilder dies. Let's wait for your ppa ^^
<NCommander> sebner, one of the joys of having a devirtualized PPA is that I can test it on all architectures at once
<sebner> NCommander: that's why you are the guy whom I wrote a mail :P
<NCommander> sebner, ;-)
<ScottK> NCommander: Would you please rescore r-cran-timedate?  I'm very curious to know if my sparc hack worked or not.
<NCommander> ScottK, https://edge.launchpad.net/ubuntu/+source/r-cran-timedate/290.85-1ubuntu1/+build/1238939
<ScottK> NCommander: That should be enough.  Thanks.
<ScottK> BTW, edge doesn't show the build score anymore.  Someone should complain about that
<NCommander> ScottK, I see it
<NCommander>     *   Start in 1 minute (7098709) Rescore build
 * ScottK looks again
<dutchie> is this the right place to poke my branch getting merged?
<ScottK> Urgh.  Started already
<NCommander> ScottK, if it still fails, I'll have to look at it manually; my SPARC box crashed while updating upstart
<NCommander> the upshot is it doesn't boot anymore
<soren> dutchie: Depends on what it's a branch of.
<dutchie> update-manager
<ScottK> NCommander: If you want to work on sparc, figure out why xvfb segfaults (see the previous revision's build log)
<soren> mvo: ^^ That's your cue :)
<NCommander> ScottK, sparc a miserable pile of fail ATM sadly
<NCommander> ScottK, I'm trying to work out why silo is crying in the corner
<dutchie> https://code.edge.launchpad.net/~jshholland/update-manager/string-fixes
<ScottK> That's definitely I higher priority
<ScottK> I/A
<mvo> dutchie: I'm having a look at the branch now
<mvo> dutchie: could you mail the translators too that some strings change due to this? Or maybe manual unfuzzing in the po files is enough, it seems that not many user affect strings are affected (just ~3?)
<dutchie> mvo: is that a translator's team?
<mvo> dutchie: there is a mailing list, give me a sec
<mvo> dutchie: https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
<mvo> dutchie: that is the mailing list - I upload the new pot to rosetta now
<mvo> dutchie: thanks very much for the branch, its merged now
<dutchie> \o/
<dutchie> i think that's my first contribution to a FOSS project that's been merged
<mvo> *woooohhh*
 * mvo hugs dutchie
<wgrant> slangasek: That's on my todo-list after I finish exams and stuff in a few hours.
<slangasek> wgrant: cheers :)
<simon-o> cody-somerville: bug 428104: I don't know why --without-ssl was in debian/rules and why it worked before
<ubottu> Launchpad bug 428104 in lftp "3.7.15 removes support for https" [Undecided,New] https://launchpad.net/bugs/428104
<cody-somerville> simon-o, I noticed that as well. autotools bug or something maybe
<zegusty> Does anyone know the driver level keyboard buffer size?
<cody-somerville> simon-o, ah, I see why
<cody-somerville> simon-o, new version of gnutls no longer ship libgnutls-extra-config
<cody-somerville> however, lftp doesn't FTBFS it just happily continues with ssl support dropped.
<simon-o> cody-somerville: ok, I see. but the --without-ssl is still nonsense. It should be --without-openssl
 * cody-somerville nods.
<cody-somerville> simon-o, just about to say that :)
<simon-o> cody-somerville: I don't see where libgnutls-extra-config is used. Just libgnutls-config (which was also dropped)
<cody-somerville> simon-o, sorry, I meant to say libgnutls-extra-config and libgnutls-config
<cody-somerville> Just libgnutls-config is used
<cody-somerville> I have a patch but I'm having trouble running autoreconf
<simon-o> cody-somerville: ftp://ftp.yar.ru/lftp/devel/lftp-3.99.14.tar.gz You can also check that package, it uses pkg-config to check for gnutls
<simon-o> let me know if I can help out
 * cody-somerville nods.
<cody-somerville> Thats how I'm doing it.
<cody-somerville> running autoreconf on that results in the same errors so I think there is a bug in autotools or something
<cody-somerville> I'll have to patch configure its self I guess
<sistpoty> cody-somerville: can you pastebin the errors (for my experience, usually it's not autotools that produce the error, but rather broken Makefile.am's or configure.ac's)
#ubuntu-devel 2009-09-12
<cody-somerville> sistpoty, http://pastebin.ubuntu.com/269459/
<sistpoty> *downloading source*
<cody-somerville> sistpoty, the patch I applied is http://www.mail-archive.com/lftp-devel%40uniyar.ac.ru/msg01706.html
<sistpoty> cody-somerville: interesting... I've fiddled a little bit to find out what went wrong, here's the resulting (non-cleaned) patch: http://paste.ubuntu.com/269465/
<sistpoty> cody-somerville: the guilty part seems to be nesting [] in other []
<sistpoty> cody-somerville: I must admit that I'm not 100% sure what the nested brackets do, or if these are allowed in the first place
<cody-somerville> interesting
<sistpoty> cody-somerville: the rest of the changes can be ignored (it just made vim happy to not have a ' in the strings)
<sistpoty> (and of course the spelling errors must be ignored *g*)(
<cody-somerville> the nested brackets just show up in the help output
<cody-somerville> so changing them to parenthesis should be safe
<cody-somerville> thanks! :)
<sistpoty> you're welcome ;)
<cody-somerville> so would I want to run autoreconf at build time or use that to generate the patch? The former, right?
<sistpoty> cody-somerville: personally, I prefer to run autotools at build time
<sistpoty> cody-somerville: iirc there are arguments against doing it, but the only valid one I've heard is that many people claimed a ftbfs to be a fault of changed autotools (due to maintainers not knowing what went wrong)
<sistpoty> (and hence blaiming autotools for it)
<RainCT> kirkland: Hey. Seems like if you create a user, run screen and later delete the user, an entry for it in /var/run/screen remains. If you then try to install or update byobu it will fail on postinst because it creates a .reload-required file for the user but can't do the chown.
<RainCT> kirkland: (also, why does it warn about the update on install?)
<sistpoty> RainCT: sounds like "delete user but not all files the user owns" problem? I assume slangasek has a stance on this one ;)
<slangasek> well, admins should be allowed to do that if they wish
<RainCT> Yeah, I don't want to delete it's files, only the user :)
<RainCT> *its
<sistpoty> RainCT: oh, so it's not the problem that a postint deletes a user... sorry for getting that wrong
<sistpoty> erm, postrm
<RainCT> sistpoty: no, it's the postinst doing this http://paste.ubuntu.com/269478/ where the user has been deleted (so chown $u fails)
<sistpoty> RainCT: ah, but that doesn't stem form postrm deleting a user
<sistpoty> RainCT: imo that's a mere bug of assuming that a user exists
<RainCT> sistpoty: yeah, I've never mentioned postrm deleting any user
<sistpoty> (just because there's a directory called like the username)
<sistpoty> RainCT: sorry, I didn't read good enough ;)
<RainCT> hehe np
<diwic> So I saw that fluidsynth-dssi FTBFS, and the fix was simple; to depend on liblash-dev instead of ladcca-dev
<diwic> That was probably my fault from the beginning, since when I updated fluidsynth to 1.0.9 I changed it to depend on liblash instead of ladcca
<diwic> But I fail to see why fluidsynth-dssi should need liblash.la at all
<tilgovi> Newbie packaging question: if a `make install` creates directories that do not match the preferred layout of ubuntu packages (of this type), should I modify the Makefile or is there a file in the ./debian directory that can remap these locations?
<tilgovi> do I create a patch for the Makefile or something else?
<tilgovi> or...does someone have a good newbie guide link lying aroundL
<tilgovi> ?
<azeem> try asking in #ubuntu-motu
<tilgovi> azeem: thanks
<darkham> where i can look changes between karmic daily live cds?
<c_korn> I wonder why -Wl,--as-needed is not automatically added to LDFLAGS by dpkg-buildpackage
<tripzero> who is the xsplash master
<tripzero> ?
<ulaas_> hey. where are my ctrl+alt+FX virtuals?
<hyperair> did you start your gettys?
<hyperair> ps -C getty
<ulaas_> hyperair, since when do they need starting?
<ulaas_> :)
<ulaas_> hyperair, they are running
<hyperair> then what do you see when you do ctrl+alt+fX?
<ulaas_> blinky cursor
<hyperair> no login prompt?
<hyperair> how strange
<ulaas_> hyperair, yeah
 * hyperair doesn't know
<ulaas_> and where is DontZap
<ulaas_> whats going on here?
<hyperair> DontZap? wasn't that in xorg.conf?
<maxb> âdontzapâ source package in Ubuntu    Deleted in karmic-release  (Reason: obsolete)
<ulaas_> obsolote, because?
<maxb> IIRC because xorg upstream removed the option from xorg.conf entirely
<tripzero> prolly because xorg.conf has that
<tripzero> ahh, it's not even in xorg.conf anymore?
<ulaas_> maxb, any other methods?
<ulaas_> gdm restart?
<maxb> there's something complicated that you can do with x key bindings to enable zapping
<ScottK> There's GUI for it.
<ulaas_> ScottK, ahh the hard way of doing simple things.. great. what is that?
<ScottK> I don't know for Gnome.  Don't use it.
<ScottK> It's in systemsettings for KDE.
<ulaas_> suddenly felt like trying my netinstall archlinux image..
<ulaas_> lemme grab a cdr
<sebner> ulaas_: in the system - keyboard settinsg
<sebner> *settings
<maxb> ulaas_: It's buried deep in gnome-keyboard-properties
<maxb> Layouts tab, "Layout Options...", "Key sequence to kill the X server"
<ulaas_> maxb. thanks man.
<cody-somerville> lol
<cody-somerville> Pressing alt+f4 dismisses the login window. Pressing it again asks you if you want to log out or switch users.
#ubuntu-devel 2009-09-13
<sistpoty> luisbg: mind to give an opinion for bug #423801? Thanks!
<ubottu> Launchpad bug 423801 in audacity "Sync audacity 1.3.9-3 (universe) from Debian unstable (main)." [Wishlist,New] https://launchpad.net/bugs/423801
<sistpoty> luisbg: also what do you think about bug #405318?
<ubottu> Launchpad bug 405318 in lmms "Please update lmms to 0.4.5 version" [Undecided,New] https://launchpad.net/bugs/405318
<kees> wgrant: thanks for the nominations work.  very very helpful for me.  :)
<kees> wgrant: do you have any idea how bug 322562 could be fixed?  it seems like something is just missing a tiny export for a collections link
<ubottu> Launchpad bug 322562 in malone "Cannot lookup bug list from CVE" [Medium,Triaged] https://launchpad.net/bugs/322562
<formolQC> hi.  i just installed alpha5, and fsck fail at first boot, does someone know what to do?
<LaserJock> bah, the icedtea6-plugin should be renamed to openjdk-6-plugin
<ian_brasil> formolQC, run fsck manually and then reboot
<formolQC> ian_brasil, I did, it didn't work
<hrickards> Am I right in thinking that because it's past the Feature Freeze for karmic, without being granted a Feature Freeze exception, I can only upload (well have uploaded by MOTU) new versions of my package (lives) that contain bugfixes, not new features? For anyone who's familiar with the lives versioning 1.1.2 adds new features whereas 1.0.2 is just bugfixes. Can I only upload 1.0.2? Also see bug #427836
<ubottu> Launchpad bug 427836 in lives "[new-upstream]LiVES 1.0.1" [Undecided,In progress] https://launchpad.net/bugs/427836
<hrickards> Anyone?
<hyperair> pretty much so
<hyperair> feature freeze basically means no new features
<hrickards> hyperair: Okay
<hyperair> also, it pays to be patient.
<hyperair> there are times when nobody who knows is actively staring at the channel so just wait until somebody who knows does
<hrickards> hyperair: Okay.
<Hobbsee> hrickards: if you do want to push new features, the earlier it is, the more likely a FFe will be granted.
<hrickards> Hobbsee: Okay. Do you think today's too late?
<Hobbsee> hrickards: for universe?  doubt it
<hrickards> Hobbsee: Okay. Would it be easier for me to wait a day or two until 1.1.2-2 gets into Debian, or just file a bug now.
<hrickards> Sorry, should have been would it be *better*
<Hobbsee> hrickards: day or two and sync :)
<Hobbsee> syncs == always easier, and usually better
<Hobbsee> in terms of maintenance and such
<hrickards> Honnsee: Okay
<hrickards> *Hobbsee*
 * Hobbsee suggests the tab key, for much easier irc'ing ;0
 * Hobbsee looks at her shift key, frowning at it for not working
<StevenK> Hobbsee: Perhaps your pinky isn't working :-P
<Hobbsee> :P
<hyperair> ...why does usb-creator cause my entire system to lag like hell?
<Lure> Riddell: point is that autologin ensures that my kde session with all apps is started asap; autolock is needed to have my business laptop secure
<Lure> Riddell: yes, I still need to enter password, but latency (time-to-working-session) is better with autlogin+lock
<elops> I am going to run Ubuntu as a file server for my small business (approx 5-8 computers will use the server) should I install Ubuntu server edition or would the desktop edition work just fine?  I am a bit of a novice with lunux, but not comps--Ubuntu seems to have a lot of clout any other sugestions are appreciated.
<JCass> My novice opinion is to start out with a normal desktop edition
<JCass> The Ubuntu server is just command line
<JCass> If you are comfortable with that then by all means, use Ubuntu Server :)
<directhex> doko, libreadline-dev - needed for karmic?
<doko> directhex: no, not necessary, maybe it would be nice to get libreadline5 off the CD
<pacopil> online boxing game http://www.kobox.org/kobox-fande-Nourine.html
<darkham> plese add a document of changes between daily discs
<darkham> would be helpful to users with known problems
<ScottK> darkham: https://lists.ubuntu.com/mailman/listinfo/Karmic-changes
<apachelogger> asac: any news on the trademark?
<cody-somerville> james_w, I have some questions about bzr-builder if you're around.
<EtienneG> slangasek a new sets of Eucalyptus packages have been built two days ago, but are still awaiting publication.  Is this because of FF?  do you have any idea when we expect they hit the archive?
<ScottK> EtienneG: Everything is on automatic right now, so it's not because of FF (I don't know what that would be).
<soren> They're binary new.
<soren> ScottK: Something you could take care of?
<ScottK> Perhaps later tonight.
<soren> Ok.
<soren> I somehow thought they'd been approved already. :(
<soren> EtienneG: Its because I split the -cloud package into -sc, -walrus, -java-common, and -cloud. They're new packages, so need approval.
<EtienneG> soren, thanks for the info ... do you have any idea how long it will take for these to be approved, and who I need to talk to to speed that up?
<soren> EtienneG: It takes 15 seconds once someone decides to do it.
<EtienneG> soren, good to know, thanks a bunch!
<soren> EtienneG: https://edge.launchpad.net/~ubuntu-archive/+members
<EtienneG> mdz, is that something that can be arranged?
<EtienneG> mdz, we where talking about the built but unapproved new set of packages for Eucalyptus
<EtienneG> 1.6~bzr672-0ubuntu2, more specifically
<mdz> EtienneG, yes, soren can speak to an archive admin and ask them to expedite it
<EtienneG> mdz, ok
<soren> EtienneG: ScottK is an AA, so that's what I did about half an hour ago.
<mdz> EtienneG, it is Sunday, though, and it may not get done until tomorrow unless it is incredibly urgent
<EtienneG> mdz, I guess I can survive with the current version for the moment
<mdz> EtienneG, you can still get the .debs from Launchpad, I believe
<EtienneG> mdz, indeed, I saw that
<mdz> soren, if ScottK doesn't happen to get to it today, please speak to a european-based ~ubuntu-archive member tomorrow and make sure it gets done early in the day, since we want it to be published and tested for alpha 6
<soren> mdz: Sure.
<EtienneG> and tested it will get, I assure you
<tripzero> did the latest updates blow away nvidia support?
<Gurpartap> cjwatson: hello
<superm1> if anyone with ~ubuntu-archive powers is around over the weekend, can bug 439032 be expedited?  we haven't had a good mythbuntu live disk generation in 3 days and were hoping to test some bug fixes that were recently integrated in preparation for a6.
<ubottu> Error: Launchpad bug 439032 could not be found
<superm1> and by that i mean bug 429032
<ubottu> Launchpad bug 429032 in ubuntu "Please sync libimage-size-perl 3.2-3 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/429032
<superm1> it's currently blocking us because image-size was removed from the archive without syncing the new package it was renamed to in debian in the last few days
<superm1> kirkland are you around? Daviey pointed out you've got some powers, maybe you can help ^?
<EtienneG> kirkland, if you do happen to service superm1 above, could you also expedite eucalyptus 1.6~bzr672-0ubuntu2 ?
<EtienneG> funny bug in LP ... if you try to create a bug with a very long title, it will OOPS with a timeout searching for similar bug.  If you shorten the title, it works.
<crimsun> TheMuso: slmodemd is causing havoc with pulseaudio, as exhibited in bug 394500. any suggestions what can be done for Karmic?
<ubottu> Launchpad bug 394500 in pulseaudio "[Karmic] processes holding /dev/dsp* or /dev/snd/pcm* cause "pulseaudio: card not found - Null Output / Dummy Output"" [Low,Confirmed] https://launchpad.net/bugs/394500
<TheMuso> crimsun: Ok
<slangasek> EtienneG: it's because they're in the new queue
<slangasek> EtienneG: I'm not going to have a chance to do new processing before tomorrow (at my regularly scheduled time)
<EtienneG> slangasek, ok, i can live with that if need be
<TheMuso> crimsun: hrm I am not sure how we solve this one. I wonder why they have slmodemd installed in the first place...
<TheMuso> Probably due to installing it from jockey I suspect.
<crimsun> TheMuso: indeed
<crimsun> i've been inspecting the sl-modem-daemon source, and it hardcodes modem:%d, which is unfortunate
<crimsun> i think perhaps we can extend module-udev-detect to report which processes are causing it to return "busy"
<crimsun> that way at least there's some indication of why people are receiving null/dummy output
#ubuntu-devel 2010-09-13
<mwhudson> so i've been told a bug i reported is fixed in a new package "which is due to be installed in the Debian FTP archive"
<mwhudson> can i see this new version somehow?
<mwhudson> it's not in http://packages.debian.org/sid yet
<ScottK> mwhudson: Is this the python-defaults one?
<ScottK> mwhudson: If it is, that was uploaded to Experimental, not Sid.
<mwhudson> ScottK: yes
<ScottK> It's in Experimental then.
<mwhudson> ScottK: so what is experimental then?  is it a bit like -proposed for ubuntu?
<ScottK> No.
<ScottK> It's for stuff that's not suitable for Unstable and then Testing.  In this case, because Debian is frozen for the Squeeze release, it was uploaded there to keep Unstable clear for any emergent bug fixing needed for Squeeze.
<mwhudson> ah ok
<mwhudson> can/should i do anything to prod the fix into maverick?
<ScottK> At this point you probably will.  I'd ask doko about it.
<mwhudson> ok
<doko> ScottK: ?
<ScottK> doko: Do we want to update python-defaults from experimental before release?
<ScottK> The 2.6.6-2 upload that was done today?
<doko> ScottK: yes, but not now
<ScottK> doko: OK.  When?
<doko> oh, python-defaults, not 3. yes this is ok
<ScottK> OK.
<ScottK> mwhudson: It it's not done by Wednesday, please remind me.
<mwhudson> ScottK: ok
<pitti> Good morning
<bilalakhtar> good morning pitti !
<pitti> hey bilalakhtar, how are you?
<bilalakhtar> pitti: fine, you?
<pitti> bilalakhtar: I'm great, thanks! back from a week of vacation
<tkamppeter> pitti, hi
<pitti> hello tkamppeter, wie gehts?
<pitti> tkamppeter: I saw your jockey patches, thanks! will look at them today
<tkamppeter> Gut, Du hast gefehlt auf dem IRC.
<pitti> tkamppeter: right, was on holiday, far away from the internets
<tkamppeter> pitti, the patches are very important, as Epson expects their packages to auto-download on Maverick and Ricoh is complaining for more than a year that PPD package auto-download is too slow, most important factor being Jockey, but the s-c-p part I have also accelerated by the compressed PPD archives and a bug fix in s-c-p.
<tkamppeter> pitti, the slow and space-consuming Foomatic XML database is also replaced by a compressed PPD archive now.
<amitarora> pitti: ping
<pitti> !ping | amitarora
<ubottu> amitarora: pong
<pitti> bah
<pitti> amitarora: hello; please just ask your question, don't ping
<amitarora> pitti: I got your reference from amitk .. this regarding bug# 627975
<amitk> bug 627975
<ubottu> Launchpad bug 627975 in powertop (Ubuntu) "PowerTOP: Remove hard coded values for C and P states" [Undecided,New] https://launchpad.net/bugs/627975
<amitarora> pitti: the bug has a patch for PowerTOP which makes it work on ARM boards as well ..
<amitarora> pitti: its been accepted upstream. The last comment has the details ..
<amitarora> pitti: can you please help getting it merged with PowerTOP branch for Maverick release ?
<pitti> amitarora: yes, I can sponsor it; I'll assign it to me
<amitarora> pitti: great, thanks!
<tkamppeter> pitti, an important bug we need to get fixed for Maverick is bug 494141. The fix is already described in the bug report, but I cannot upload it as it has to be done in the Samba package. It is a one-line patch on /etc/init/smbd.conf.
<ubottu> Launchpad bug 494141 in samba (Ubuntu Lucid) "CUPS starts after SAMBA; printers are not available (convert cups to upstart)" [High,Triaged] https://launchpad.net/bugs/494141
<pitti> tkamppeter: can you please discuss that one with slangasek?
<tkamppeter> slangasek, can you have a look at bug 494141? It is a one-line patch which will help users a lot, both in Maverickj and as SRU for Lucid.
<ubottu> Launchpad bug 494141 in samba (Ubuntu Lucid) "CUPS starts after SAMBA; printers are not available (convert cups to upstart)" [High,Triaged] https://launchpad.net/bugs/494141
<popey> greetings earthlings!
<pitti> \\//
<popey> bug 631103 could do with some attention, simple packaging error. Could a core-dev please take a look?
<ubottu> Launchpad bug 631103 in ffmpeg (Ubuntu) "[patch] maverick ffmpeg "Unknown input format: 'x11grab'"" [Undecided,Confirmed] https://launchpad.net/bugs/631103
<tkamppeter> pitti, about bug 604698, can we simply take my patch to do the Jockey (list packages) part and for the key verification part for Maverick simply include the Epson key in the distro (there is no other key yet) and implement the general key downloading in Natty?
<ubottu> Launchpad bug 604698 in jockey (Ubuntu) "Automatic printer driver download should support signed packages" [High,Triaged] https://launchpad.net/bugs/604698
<pitti> tkamppeter: we need to filter for Epson packages only then
<pitti> tkamppeter: but yes, that would work
<tkamppeter> pitti, if Jockey installs a package, does it go through the standard mechanism with key verification, like it happens with apt-get (there I get a warning and asked whether I really want to do it if the package does not have a known signature)?
<pitti> tkamppeter: yes, it does use apt for every package operation
<\sh> siretart, ping could you start a backport process for fai maverick to lucid , kthxbye :)
<tkamppeter> pitti, so we could use my patch plus including Epson's key in Maverick. Then we will create a key download functionality in Natty. If other manufacturers show up and want their drivers in Maverick, we could perhaps even add keys as update for Maverick.
<pitti> tkamppeter: plus a filter "only epson packages"
<pitti> (or noarch)
<tkamppeter> pitti, assuming that there is a non-Epson package on OpenPrinting, so having a key which is not included in Maverick. What happens if the user sees this package in Jockey and clicks on "Install". Will then a message pop up telling the user that this package has no known signature and the user gets asked whether he really wants it?
<pitti> no, such a question would be pointless
<tkamppeter> pitti, what would really happen in such a case?
<pitti> it would currently just install it anyway, since apt merely gives a warning if a key isn't present
<tkamppeter> pitti, so the selection of packages we accept is hardcoded in Jockey and not data-driven?
<pitti> tkamppeter: it's not hardcoded
<pitti> tkamppeter: right now we only offer Ubuntu packages, and as a compromise, (unsigned) noarch packages from openprinting
<pitti> adding epson key and a filter for it would start hardcoding
<tkamppeter> pitti, this (and any SRU to satisfy other manufacturers) would be a Maverick-only interim solution. From Natty on we should have real support for OpenPrinting's key link facility.
<pitti> *nod*
<pitti> tkamppeter: also, your patch would remove the support for unsigned PPD-only packages, AFAICS?
<tkamppeter> pitti, no, first, I have tested with Ricoh PPD packages, second, I have added a second search task to the task list. So when starting the task list two requests per printer are sent to OpenPrinting, one for the noarches and one for the signed.
<pitti> tkamppeter: ah, that wasn't in the originally sent patch then
<tkamppeter> pitti, the patch attached to bug 604698 does exactly this.
<ubottu> Launchpad bug 604698 in jockey (Ubuntu) "Automatic printer driver download should support signed packages" [High,Triaged] https://launchpad.net/bugs/604698
<pitti> tkamppeter: I meant http://launchpadlibrarian.net/55226929/download-also-signed-binary-printer-driver-packages.patch
<tkamppeter> pitti, I see, the patch is the wrong way around. Take the debdiff.
<tkamppeter> pitti, and in the debdiff the patch on detection.py.
<siretart> \sh: I put it on my todolist, but no promises, it is rather longish :-(
<diwic> seb128, ping
<seb128> hi
<seb128> contextless ping are not really useful though
<seb128> better to just ask your question
<diwic> seb128, you're sebastien bacher, right?
<seb128> yes
<seb128> why?
<diwic> seb128, you seem to have declined bug #433654 without giving a reason?
<ubottu> Launchpad bug 433654 in gnome-system-tools (Ubuntu) "Only one user gets sound with privilege "Use audio devices"" [Medium,Triaged] https://launchpad.net/bugs/433654
<seb128> could be
<diwic> for Maverick
<seb128> I've declined over 300 bugs
<seb128> the list had some 600 bugs
<seb128> still quite some to clean
<seb128> it's just that it's not tracked as a blocker for maverick, it's not a new issue
<seb128> nothing prevent to fix it though
<\sh> siretart, don't worry about time...I just want to have it from my table ;)
<diwic> seb128, okay, so I can just go requesting a sponsorship as usual given I write a patch for it?
<seb128> it's being discussed on #ubuntu-desktop by somebody else at the same time
<seb128> weird timing
<seb128> or you guys just discussed it somewhere else and decide to go ping different channels?
<seb128> but yes you can get any change uploaded
<diwic> seb128, probably there was a comment recently that woke us both up?
<seb128> the nomination is just a way for people to track issues for the release
<seb128> the release team can't track every bug
<seb128> not accepting the nomination just need not tracking it as a blocker issue for this cycle, it doesn't mean a fix can't be uploaded
<diwic> okay, I understand.
<seb128> need->mean
<cjwatson> in case anyone other than me noticed, I think I see why jigdo downloads of maverick always falsely claim an incorrect checksum right now
<cjwatson> lex79: they already seemed to be there
<tkamppeter> pitti, bug 604698 has an updated debdiff now.
<ubottu> Launchpad bug 604698 in jockey (Ubuntu) "Automatic printer driver download should support signed packages" [High,Fix committed] https://launchpad.net/bugs/604698
<pitti> tkamppeter: thanks
<tkamppeter> pitti, stop, I got into the find() trap of Python. Please wait for the next debdiff.
<tkamppeter> pitti, I have corrected the debdiff now, take the one of comment #5.
<tkamppeter> slangasek, hi
<htorque> hello, is irc-logging not working? http://irclogs.ubuntu.com/2010/09/13/ is empty.
<tkamppeter> mv, glatzor, can you have a look into bug 633913?
<ubottu> Launchpad bug 633913 in sessioninstaller (Ubuntu) "session-installer crashed with ModifyInternalError in _install_printer_drivers() when triggered by system-config-printer" [High,New] https://launchpad.net/bugs/633913
<tkamppeter> mvo, ^^\
<tkamppeter> mvo, glatzor, this is rather annoying to get all the pop-ups when system-config-printer is searching a driver for an unsupported printer.
<apw> pitti, something has gone very wrong with the burn down chart start value overrides for all my charts except for the overall
<apw> pitti, i am suspicious they are all at the value defined by ['all']
<apw> pitti, and so i am suspicious this is related to the burnup support that was merged recently
<pitti> apw: right, they currently keep crashing
<pitti> apw: I already mailed Clint
<ogra> but it makes the trendlines looks so good ...
<apw> pitti, i assume thats also why we have two days missing
<smoser> pitti, or someone on sru team, can I please get bug 634102 into lucid-proposed soon?  this is fairly serious issue for people using our images and the new instance size on EC2. The simple diff is at http://launchpadlibrarian.net/55301846/cloud-init_0.5.10-0ubuntu1.2_0.5.10-0ubuntu1.3.diff.gz .  I'm really sorry to nag.
<ubottu> Launchpad bug 634102 in cloud-init (Ubuntu Lucid) "t1.micro EC2 instances hang on reboot" [High,Triaged] https://launchpad.net/bugs/634102
<apw> cjwatson, we have an old binary package hanging around in the archive linux-libc-dev at version 2.6.35-903.8 for armel which is blocking binary uploads for armel.  this version is orphan against an old source package so I believe it should be reapable; who/how/what triggers that?
<apw> (all in maverick)
<cjwatson> I can check it out and remove it, but you still won't ever be able to upload the same package at the same version
<apw> when you say same version, do you mean exactly that version?
<cjwatson> yes
<apw> that i can cope with
<cjwatson> single-architecture removals don't always get noticed automatically
<cjwatson> wait, this still means the version will go backwards
<cjwatson> um, I don't have control over allowing that
<cjwatson> it's disallowed because apt clients will never notice the downgrade automatically
<apw> so the high water mark on a binary package is permentant regardless of the existance of a package at any version
<cjwatson> yes
<apw> cjwatson, is that something that can be fixed for this one binary package given enough genuflecting ?
<cjwatson> I'd recommend artificially bumping the version of just that binary package
<cjwatson> to something that's greater than 2.6.35-903.8 but less than 2.6.36-1.1
<apw> the package was generated in error, from a different source package and should never have been installed
<cjwatson> you can do this by invoking dpkg-gencontrol with the right options
<cjwatson> (-vVERSIONYOUACTUALLYWANT)
<cjwatson> so sed the source package version to replace the -21 part by (say) incrementing it by 1000
 * cjwatson quickly ctrl-c's this removal and hopes I caught it in time
<cjwatson> because if I remove linux-libc-dev then *nothing* will build on armel ...
<apw> argle
 * apw stares into the abys
<cjwatson> you can pass arguments to dpkg-gencontrol via dh_gencontrol by saying dh_gencontrol -plinux-libc-dev -- -vblah
<cjwatson> https://edge.launchpad.net/ubuntu/maverick/armel/linux-libc-dev/2.6.35-903.8 still says "Status: Published" so I hope I caught it
<apw> cjwatson, ok that is totally vile ... what a mess ... will go figure out the cleanest fix
* sladen changed the topic of #ubuntu-devel to: Archive: Open; LP: Back Up | FeatureFreeze in effect! | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-lucid | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<tkamppeter> pitti, have you seen my new debdiff?
<tkamppeter> mvo, hi
<tkamppeter> slangasek, ping
<mvo> tkamppeter: hello
<tkamppeter> mvo, it is about bug 633913, session-installer produces two annoying pop-ups when system-config-printer searches for drivers on the internet.
<ubottu> Launchpad bug 633913 in sessioninstaller (Ubuntu) "session-installer crashed with ModifyInternalError in _install_printer_drivers() when triggered by system-config-printer" [High,New] https://launchpad.net/bugs/633913
<tkamppeter> mvo, first is simply an error message where session-installer should error out silently and the second is a crash (causing apport pop-up).
<mvo> tkamppeter: ok, I check it out, thanks
<tkamppeter> mvo, I would like to have them removed/fixed before Final Freeze so that manufacturer printer driver download goes smoothly and quickly.
<mvo> tkamppeter: I uploaded a fix, please test once it hits the archive
<tkamppeter> mvo, thanks, will try it as soon as it arrives.
<kirkland> BlackZ: so have you tried booting a vm from PXE with the new etherboot package?
<kirkland> BlackZ: does it work?
<BlackZ> kirkland: no, that's the reason why I reintroduced the kvm-pxe package
<kirkland> BlackZ: see: https://wiki.ubuntu.com/VirtFeatureVerification
<kirkland> BlackZ: hallyn has a test case in there
<BlackZ> kirkland: looking
<BlackZ> kirkland: so, we should keep the kvm-pxe package, right? also, on http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt I read "# stevenk, we don't want qemu or kvm from Debian, talk to kirkland"
<kirkland> BlackZ: right, well, we need *some* package to provide a bunch of binary ROMs to pxe boot VMs
<kirkland> BlackZ: currently, that's kvm-pxe
<kirkland> BlackZ: though it could be provided by some other package, I suppose, if there's good reason
<kirkland> BlackZ: in that case, we'd need to update the depends/recommends throughout the archive on anything that has a dependency on kvm-pxe
<kirkland> BlackZ: this should NOT be done in maverick at this point in the cycle, IMO
<kirkland> BlackZ: as for qemu/kvm from Debian ... again, for Maverick, we're going to want to keep the qemu-kvm that we have in Ubuntu
<kirkland> BlackZ: for Natty, we should re-examine (lool has requested it too) re-introducing the qemu package back into Ubuntu
<kirkland> BlackZ: and possibly sourcing qemu-kvm from Debian
<kirkland> BlackZ: when I created the qemu-kvm package in Ubuntu, it didn't exist in Debian;  I offered it to the Debian maintainers, but instead, a DD created their own qemu-kvm package and uploaded
<BlackZ> kirkland: agreed; currently the package from Debian (etherboot-qemu) doesn't fix LP: #570870, maybe it's a path-related issue
<tkamppeter> mvo, the new version of sessioninstaller fixed the problem. Thank you.
<mvo> tkamppeter: cheers
<mvo> tkamppeter: thanks for testing
<chrisccoulson> hi, would a member of ubuntu-release be able to spare some minutes to look at bug 531867 please? :)
<ubottu> Launchpad bug 531867 in lightning-sunbird (Ubuntu) "[FFe] [needs-packaging] Lightning 1.0 Beta for Thunderbird 3" [High,In progress] https://launchpad.net/bugs/531867
<ScottK> didrocks: Would you please wait for the release team to approve FFe's before uploading.
<fos> A question about language-pack-kde-de-base in hardy: Since security update 20090105 a few translation files are missing. Is this a regression worth fixing?
<didrocks> ScottK: isn't seb128's comment an ack?
<ScottK> didrocks: He's not on the release team.
<fos> https://bugs.launchpad.net/ubuntu/+source/language-pack-kde-es/+bug/321297
<ubottu> Launchpad bug 321297 in language-pack-kde-fr (Ubuntu) "Dolphin and digikam in English after upgrade to "language-pack-kde-es 1:8.04+20090105.1"" [Undecided,Fix released]
<didrocks> ScottK: http://paste.ubuntu.com/493144/ be agreed firstâ¦
<didrocks> ScottK: so there is a mismatch there. knowing now. thanks
<ScottK> OK.  In any case the main thing is to get the bughugger update in now.
<didrocks> ScottK: right, rickspencer3 will fix it soon, but not today
<rickspencer3> maybe today
<seb128> ScottK, hey
<ScottK> Hello seb128.
<seb128> ScottK, every other cycle we had delegated approved for universe
<seb128> that's not the case this cycle?
<ScottK> Not that I'm aware of.
<seb128> why did that change?
<ScottK> Not sure.
<seb128> like the r-t doesn't want to delegate for universe anymore?
<seb128> it doesn't seem to make sense to me
<seb128> you guys are just claiming for extra work when you don't keep with the one you had before
<ScottK> seb128: I'm not trying to say the current situation is right or wrong.  Just that it is what it is.
<seb128> well are you sure there is not delegating this cycle?
<ScottK> We've changed a number of things with the merger of the motu-release.
<seb128> or it's just that nobody came to write an email saying who has delegation?
<ScottK> I recall someone suggested the idea on the -release list, but no one took it up.
<seb128> well honestly I think I'm rather helping by reviewing desktop change in universe
<seb128> but if you feel like it's adding work fine with me
<seb128> just seems to doesn't make any sense
<ScottK> We've gotten rid of almost all the difference between Main and Universe in the release processes and are aiming to eliminate it entirely.
<ScottK> It seems to me that we're keeping up with FFe requests OK, so it's not essential to have more people reviewing.
<ScottK> Personally, I'm a lot more worried about stuff like the Mesa FFe and what the implications of that are.
<seb128> slangasek, pitti: ^
<seb128> would it make sense to still have delegation?
<seb128> or extra people able to accept exceptions?
<pitti> I'd still trust seb128 for GNOME updates or Riddell for KDE, etc., so comments from you are highly appreciated
<pitti> NB that I'm not that active in ~release this cycle, since I'm on rotation
<cjwatson> I'm happy with delegations; I just don't particularly want it to seem as though we're riding roughshod over universe processes - there's a social benefit in making sure we're doing things right, so if there are delegations they should be explicit
 * cjwatson emerges briefly from trying to get kgdb to work, and dives back in
<tkamppeter> Can it be that LP is not automatically closing bugs on uploads with "LP: #..." in the debian/changelog any more?
<tkamppeter> pitti, did you see my last debdiff on the Jockey bug?
<pitti> tkamppeter: I saw it, yes
<mr_pouit> tkamppeter: it's broken
<pitti> tkamppeter: yes, LP has a regression for that, known
<michLinuxGuy> I am installing the beta and it seems to be frozen at "Retrieving file 2 of 6".  Is there a debug log somewhere?  If I run it from a terminal window, will I see some useful messages to stdout/stderr?
<cjwatson> tkamppeter: bigjools has promised me that the fix will be rolled out today.  In the meantime please close bugs manually
<cjwatson> (and you'll have to close bugs for anything during the broken period anyway - I don't think it will be retroactive)
<tkamppeter> cjwatson, mr_pouit, pitti, thank you, I have already manually closed a ptouch-driver bug today in the morning.
<ScottK> michLinuxGuy: You'll probably have more luck in #ubuntu-installer.
<michLinuxGuy> ScottK: thanks
<ricotz> could some have a look at bug 635646 ?
<ubottu> Launchpad bug 635646 in obex-data-server (Ubuntu) "Request no-change rebuild for maverick" [Undecided,New] https://launchpad.net/bugs/635646
<ScottK> ricotz: I'll take a look at it.
<ricotz> ScottK, thanks
<pavolzetor> Hallo, could someone help me with indicator applet?
<ScottK> ricotz: Done.
<pavolzetor> I don't know in which format should be icon passed to libindicate
<ScottK> pavolzetor: You might have more luck on #ayatana.  That's where the relevant developers tend to hang out.
<pavolzetor> thanks
<ricotz> ScottK, ta
<ScottK> No problem.
<kees> mdke: I'm uploading a small addition to the manpages. I don't think these are translated in the standard fashion, but do I need to send a note to ubuntu-translators still?
<tkamppeter> slangasek, around?
<Daviey> cjwatson, Are you still around?
<cjwatson> Daviey: yes
<Daviey> cjwatson, RE: the avahi udeb issue...  I essentially did a rebuild
<Daviey> cjwatson, but not convinced the shlibs issue is resolved
<cjwatson> doesn't seem to have worked
<cjwatson> I did suggest you test it first :)
<Daviey> ack
<cjwatson> oh, blast, I mistyped
 * SpamapS absolutely despises the tab completion setup for the sqlite3 command.. :-P
<Daviey> cjwatson, Oh well..  Are you going to be able to fix it shortly.. if notm, i don't mind taking it.
<cjwatson> Daviey: avahi 0.6.27-2ubuntu3 will be in the archive in a bit.  Once the binaries for that are published, you can rebuild eucalyptus
<cjwatson> Daviey: I suggest doing it locally first to check though
<Daviey> cjwatson, wilco... I guess i should test this from a local archive :)
<Daviey> hah
<cjwatson> ah, if you're going to increment Build-Depends, then you can upload straight away
<cjwatson> it'll just dep-wait
<Daviey> cjwatson, That is what i was *planning* to do... but i take your point about testing it locally first.
<smb> pitti, Hi Martin. May I ask for some sru love for the Hardy kernel and Lucid LBM and mvl-dove kernel in the accept queue? They are feeling unnoticed (well ok not the lbm one)
<ScottK> http://asset.soup.io/asset/1068/5622_78d3.png
<ion> Heh
<SpamapS> pitti: still around? I just pushed up fixes for the problems w/ the wi tracker
<pitti> SpamapS: back from dinner
<pitti> smb: probably not today; I had too much to do with post-holiday catch-up, I'm afraid
<smb> pitti, NP. I know the feeling
<slangasek> tkamppeter: replied on the bug
<pitti> SpamapS: thanks, merged
<slangasek> ScottK, seb128, pitti, cjwatson: I'm certainly ok with having such delegations, but am also unlikely to drive them forward right now, sorry
<SpamapS> pitti: do you know if the 'all' charts have been showing as all foreign for a long time?
<pitti> SpamapS: I'm not aware of that; but then again, I haven't actually looked at the charts that often in this cycle (I'm primarily focused on OEM matters)
<SpamapS> pitti: got it, I think it may have been forever.. but not sure. :P
<SpamapS> pitti: and thanks for merging. :)
<tkamppeter> slangasek, what is suitable for an SRU, switching CUPS to upstart or making samba re-scanning for CUPS?
<slangasek> tkamppeter: samba rescanning
<Laney> re-ping â can someone please look at sponsoring bug 539814?
<ubottu> Launchpad bug 539814 in tar (Ubuntu Lucid) "tar: futimens() with a bad file descriptor (AT_FDCWD) causes bootstrapping failure with kernels < 2.6.22" [Medium,Triaged] https://launchpad.net/bugs/539814
<tkamppeter> slangasek, how will this re-scanning work, is this some change in the upstream code of Samba? Will you do this fix?
<slangasek> it would need to be an upstream code change
<slangasek> I'm not in a position to implement it right now, no; someone should take it to upstream
<tkamppeter> pitti, WDYT, is there perhaps a solution on CUPS which is viable for Maverick (at least as SRU) to make CUPS being started before SAMBA?
<pitti> tkamppeter: I don't know how you can express that in upstart, I'm afraid
<pitti> you'd need to add a wait condition to samba which says "if cups is installed, wait for it to start, otherwise start right away"
<pitti> Keybuk: ^ can this be expressed somehow?
<slangasek> pitti: it can, but it gets tricky because you may also have cups installed without samba
<slangasek> so what you want is cups 'start on starting smbd or filesystem'
<Keybuk> you can't do that, no
<Keybuk> you do what slangasek said
<pitti> ah, and this will hold smbd in limbo while cups is being started?
<Keybuk> in the starting state
<Keybuk> so not limbo
<Keybuk> o/~ how low can you go?
<pitti> ah, thank you
<pitti> so, seems upstartification of cups is in order then
<tkamppeter> pitti, could we do an upstartification of CUPS in Maverick? Or at least as SRU for Maverick?
<pitti> upstartification is not SRUable
<pitti> so for maverick it might land still, yes; it's not that hard to test, after all
<tkamppeter> pitti, did you already upstartify another package?
<pitti> I wrote a tiny upstart job or two, nothing serious so far
<tkamppeter> pitti, probably then it is better if upstartify CUPS, also because of the handling with Debian (does Debian also use upstart)?
<tkamppeter> pitti, probably then it is better if you upstartify CUPS, also because of the handling with Debian (does Debian also use upstart)?
<pitti> tkamppeter: Debian doesn't use upstart right now, so this would be Ubuntu specific
<pitti> (i. e. dpkg-vendor query in debian/rules)
<tkamppeter> cjwatson, in bug 636887 a user complains that during an update of Lucid the file /usr/lib/cups/backend/hp (probably the package hplip) gets lost. Can it be due to hplip only being recommended in ubuntu-desktop? Should we perhaps promote it to Depends:
<ubottu> Launchpad bug 636887 in hplip (Ubuntu) "Backend /usr/lib/cups/backend/hp does not exist!" [Undecided,Incomplete] https://launchpad.net/bugs/636887
<pitti> Keybuk: while we are at this, do you think it's less of an evil hack to have cups' postinst add lp, ppdev, and parport_pc to /etc/modules? instead of having this in the init/upstart script?
<Keybuk> I think that if it needs them, it should modprobe them
 * ogra_ac disagrees
<pitti> ok
<ogra_ac> we dont have parports on arm :P
<pitti> parport_pc has modaliases, so this one should really just go
<ogra_ac> there should be a check if such a device is available at all
<pitti> but lp and ppdev don't
<pitti> ogra_ac: well, I surely hope that invalid modules in /etc/modules would just be ignored? (I'd test that, of course)
<Keybuk> aren't lp and ppdev built in? :p
<pitti> they aren't
<ogra_ac> they arent
<Keybuk> oh
<pitti> I wouldn't mind at all if they were, of course
<Keybuk> right, parport_pc is autoloaded
<ogra_ac> currently ther is an ugly hack in teh upstart script
<pitti> but I'd still need those for Debian
<Keybuk> just modprobe them then
<ogra_ac> building them in would be good
<ogra_ac> then we could handle it in teh kernel config
<ogra_ac> based on the arch
<Keybuk> assumedly the parport_pc module doesn't even exist on arm?
<Keybuk> so the modprobe would be a no-op anyway
<ogra_ac> it does
<ogra_ac> sadly
<Keybuk> hmm, no, wait that's autoloaded
<Keybuk> so it's only ppdev and lp
<Keybuk> and you want those on arm, right? :p
<ogra_ac> we had a bad bug that took us out of business because it was added to teh init script
<Keybuk> how the hell did it take you out of business?
<ogra_ac> and the kernel just locked up when it loaded
<pitti> someone added parport_pc despite the modaliases, since it reportedly is required on some systems
<Keybuk> did the module getting loaded cause the roof of your house to collapse?
<Keybuk> well, that's a kernel bug
<Keybuk> fix that bug
<ogra_ac> already fixed
<pitti> ogra_ac: do we really need to build parport_pc for arm systems in teh first place?
<ogra_ac> was in the beginning of maverick
<pitti> that's soo 1980
<ogra_ac> no, we dont
<ogra_ac> on arm you will always only have network or usb printers
<pitti> as the world should be
<ogra_ac> well, someone might develop an arm based network hub for printers at some point
<ogra_ac> one that also supports parport
<ogra_ac> but we'll worry if that happens :)
<pitti> one might also develop an USB<->grammophone adapter *shrug*
<ogra_ac> lol
<ogra_ac> they exist
<pitti> Keybuk: seems with upstart scripts I can completely drop all that pidfile voodoo?
<ogra_ac> www.amazon.de/Lenco-3866-USB-Plattenspieler-silber/dp/B000KPQ7U2
<ogra_ac> ;)
<Keybuk> pitti: well, upstart always knows the pid, so sure
<apw> pitti, i think those changes have merged up, but the burndown charts seem to still have bad starts
<pitti> SpamapS: ^
<pitti> apw: have to leave now, can you please take this up with SpamapS ?
<SpamapS> ?
<SpamapS> otp...
<apw> SpamapS, ... the burndown charts, the start of the burndown lines seem to be fubar'd ...
<apw> its looking like they are all the ['all'] value for the milestone versions, the overall graphs seem ok start wise
<apw> so i suspect that the ['foo'] entries are working and the [('foo', 'milestone')] entries are not
<pitti> tkamppeter: ok, I have a first upstart script for it, but I need to continue tomorrow; Taekwondo time now
<SpamapS> pitti we should spar in orlando ;)
<pitti> SpamapS: Kihap!
<SpamapS> apw: ah so its missing the trend start settings?
<apw> SpamapS, i'd say so, it looks like its chosen 'all'
<SpamapS> apw: so the team entries are broken?
<apw> SpamapS, if you look at the kernel team ones, the overall cycle one 'c-k-t' in the array appears sane and what i set
<apw> SpamapS, the ones for the individual milestones are off the chart
<apw> SpamapS, so the ones which would be [('c-k-t', 'maverick-alpha-1')] ... those look to have a massive value which I conjecture is the ['all'] value
<SpamapS> apw: whoa! hah ok I see it now!
<SpamapS> apw: and I think I know where its borked in the code too
<apw> SpamapS, yay, i've never had to actually run the collector so have no test environment to debug it
<SpamapS> apw: you can always just download maverick.db ;)
<apw> SpamapS, well indeed, i guess i mean i only ever play with the wiki stuff not the rest of the report stuff
<apw> as that bit always just works ... oops
<SpamapS> http://paste.ubuntu.com/493232/
<SpamapS> thats the offending code.. but it looks right to me.. hrm
<apw> unless milestone is broken
<apw> there is also an override in there in places, which might be makeing those get ignored
<apw> generate-all:    report_tools.run_reports(my_path, opts.database, basename, opts.config, trend_override=str(trend_starts['all']))
<apw> SpamapS, i am mildly interested in that line
<apw> SpamapS, i had not realised I can trivially test this as its a report side thing ... perhaps you could pm me the incantation to run the reports
<apw> and then i can try and debug it
<SpamapS> apw: ./generate-all
<SpamapS> ;)
<apw> heh ... stupid apw, ok if you don't fix it before me, i'll have a poke later/tommrrow
<SpamapS> actually its     ./generate-all -d path/to/maverick.db -c config/maverick.cfg
<SpamapS> I'm thinking maybe trend_starts doesn't get passed in properly.. debugging now..
<apw> ah ok let me know if you find it :)
<SpamapS> oh and -o /path/to/output/dir
<SpamapS> see Its not that easy.. there's still an incantation. ;)
 * SpamapS should probably stop thinking in-channel
<SpamapS> apw: oops.. if should have been elif ;)
<apw> SpamapS, doh so it is
<apw> SpamapS, you got a merge ?
<SpamapS> https://code.launchpad.net/~clint-fewbar/launchpad-work-items-tracker/server-team-mods/+merge/35320
<apw> SpamapS, ok that looks totally sane, merged
<apw> SpamapS, we'll find out in an hour if it worked
<jdstrand> slangasek: hey. would you mind looking at bug #628924 and giving an ACK or NAK as an ubuntu-sru member?
<ubottu> Launchpad bug 628924 in chromium-browser (Ubuntu Lucid) "chromium update: 5.0.375.127 -> 6.0.472.53" [High,Fix committed] https://launchpad.net/bugs/628924
<apw> ogasawara, ok those patches seem good to my testing, and they are in the pipe.  i will also kick off an armel build now but the more testing the better ... we do not want to double-beep the archive
<shadeslayer> jono: around?
<ogasawara> apw: ack.  I'll test it as well before I push.
<jono> shadeslayer, hey, on the phone
<shadeslayer> ok..
<SpamapS> apw: cool thanks!
<didrocks> cjwatson: hey, I got some reject when uploading gnome-bluetooth (dpkg-source can't extract it). kenvandine got the same issue last week and the workaround was to regenerate the tarball. Should I proceed or do you have some time to investigate?
<james_w> didrocks: where's the tarball?
<james_w> or better, the source package
<didrocks> james_w: http://ftp.gnome.org/pub/gnome/sources/gnome-bluetooth/2.31/gnome-bluetooth-2.31.90.tar.gz
<didrocks> hum, source package, can upload it somewhere, one sec
<didrocks> james_w: you should be able to dget -x http://people.canonical.com/~didrocks/gnome-bluetooth_2.31.90-0ubuntu1.dsc
<james_w> merci
<didrocks> merci Ã  toi :-)
<james_w> didrocks: go "+1" this: https://bugs.edge.launchpad.net/soyuz/+bug/637507
<ubottu> Launchpad bug 637507 in Soyuz "Uploads with extra data in the .tar.gz rejected unnecessarily" [Undecided,New]
<james_w> apologies for that not clicking the other day
<didrocks> james_w: confirmed. waow what an old bug, reading the link
 * kenvandine is surprised we don
<didrocks> james_w: the workaround is to redo the tar?
<james_w> didrocks: which one is old?
<kenvandine> t see it more
<james_w> didrocks: that's the only one I know of
<didrocks> james_w: (comment from william is quite old)
<james_w> only just over a year old :-)
<james_w> shows how many bugs are reported on Launchpad
<didrocks> yeah, just suprised we don't get it more
<didrocks> thanks a lot james_w :-)
<james_w> np
<james_w> seb128: retracers should work again on edge
<james_w> seb128: lifeless recommends switching to production anyway
<seb128> james_w, thanks, what was the issue?
<seb128> james_w, the issue with production is that fixes can take ages to land and that we don't test what's coming next
<james_w> seb128: edge was using mixed revisions of the code across different appservers, which screws up the API
<seb128> ie if edge is broken and get rolled in production we are screwed
<seb128> pitti, ^ just fyi
<james_w> seb128: indeed, however lifeless is also on a quest to get rid of the split
<seb128> james_w, ok, thanks for figuring that out
<james_w> np
<strycore> #ubuntu-app-devel
<strycore> + /join plz , 'kthxbye
<slangasek> jdstrand: ack or nack?  There's a choice? :)
<jdstrand> slangasek: at least theoretically
<jdstrand> slangasek: seriously though, there is a bit going on there and as this is an SRU and we don't have an exception in place yet, I felt uncomfortable pushing to -security without your guys
<jdstrand> s/your guys/you guys/
<jdstrand> slangasek: thanks for your ack. I'll copy over
<ScottK> jdstrand: Somehow the -update for chromium-codecs-ffmpeg ended up in Main.
<jdstrand> ScottK: I'll fix it. thanks
<ScottK> jdstrand: You're welcome.
<ScottK> jdstrand: Should I be suprised it looks different now?
<jdstrand> ScottK: I haven't changed anything yet, but am presently
<ScottK> OK.
<ScottK> Looks like i have some kind of oxygen (KDE) theme running now.
<jdstrand> yeah, went from 5.0 to 6.0
<jdstrand> 5.0 is no longer supported
<ScottK> OK.
<ScottK> Seems to work OK, it was just a bit suprising.
<jdstrand> welcome to the new world of browser updates
<ScottK> Yeah.  No kidding.
#ubuntu-devel 2010-09-14
<psusi> anyone know how to get emacs to find the right source file when using gdb?  it doesn't seem to have the right search path for the file names gdb is emitting and the info page is useless.
<YokoZar1> The Maverick Me Menu currently enforces one character tweets.  Because 140 is way too many ;)
<ScottK> That's where it was bound to end up eventually anyway.
<psusi> cjwatson, was it you that I talked with several months back about dropping the Ubuntu deviations to parted and dmraid that strip the 'p' character separating the base device from the partition number for dmraid devices?
<mwhudson> hi, i have a package who's postinst is failing
<mwhudson> is there some way i can lie to my system and say that it's configured ok, so that it doesn't fail every time i run apt?
<ajmitch_> you can be evil & edit the postinst in /var/lib/dpkg/info/package.postinst, just start it off with an exit
<ajmitch_> this won't stick around when you upgrade it, but will get you past the failing postinst
<mwhudson> in the land of kernel bugs, evil is king
<mwhudson> or something
<mwhudson> thanks anyway :)
<slangasek> what sort of kernel bug? :)
<mwhudson> slangasek: one that causes partitions from the sd card to be mounted read only on beagle boards
<slangasek> ah, fun
<mwhudson> which specifically makes update-initramfs' postinst not happy
 * slangasek nods
<mwhudson> are there any mirrors of ports.ubuntu.com ?
<oracle> featurefreeze?? why!?
<mwhudson> oracle: because. https://wiki.ubuntu.com/MaverickReleaseSchedule
<oracle> my battery was lasting a great deal shorter on fedora 11 than this ubuntu 10, did someone improve something?
<pitti> Good morning
<pitti> SpamapS: I just added you to the WI tracker team, so you can commit directly
<SpamapS> pitti: thanks! :) Any way you can have the errors cc'd to the team mailing list?
<SpamapS> pitti: btw, I don't do Tae Kwon Do, I do Kenpo Karate.. but they're very similar. :)
<pitti> SpamapS: oh, right, I should set up a ML for that team
<pitti> SpamapS: ML created, I need to wait for a few minutes until it works
<SpamapS> pitti: how long have you been training in TKD?
<pitti> SpamapS: since about 2001
<pitti> SpamapS: with about 1.5 years of break in between
<pitti> SpamapS: but I'm not that much of a fighter :) we don't do a lot of sparring
<SpamapS> pitti: I've been doing Kenpo for 3 years now. Great fun.
<pitti> SpamapS: we should exchange experiences over a beer in Orlando!
<SpamapS> pitti: yes for sure. :)
<lifeless> I can add some aikido yoshinkan in there
<lifeless> (more talk -> longer discussion -> moah beer)
<pitti> lifeless: sounds like a good plan
<lifeless> pitti: hey how are the retracers
<pitti> SpamapS: you should see it now on https://edge.launchpad.net/people/+me/+editemails
<pitti> lifeless: haven't checked again yet
 * pitti restarts them
<lifeless> pitti: please do?
<lifeless> thanks
<pitti> SpamapS: cronjob updated to mail the ML
<SpamapS> beer + martial arts + code == the beginnings of an awesome game engine? ;)
<SpamapS> pitti: sweeeet
<pitti> lifeless: seems the amd64 one is quite happy, it's been running since about midnight
<SpamapS> lifeless: I'd like to echo the sentiments of whoever said "launchpad seems faster today" .. I feel a bit more productive in bug management in general lately. :)
<lifeless> ok great
<lifeless> SpamapS: thanks!
<lifeless> SpamapS: (you could send it to the list, I'm sure the other devs would love to hear that)
<SpamapS> lifeless: will do :)
<pitti> argh, could LP please stop importing bug comments from 3 years old closed bugs which nobody ever looks at any more..
<pitti> or at least, stop telling about them
<bilalakhtar> pitti: does LP import bug comments from other trackers? really?
<pitti> apparently so
<apw> SpamapS, pitti,
<apw> how is the tracker today
<pitti> tkamppeter: is there a bug about smbd not waiting for cups?
<apw> SpamapS, just did a local run of the generators and its not regenerating the older svgs
<pitti> apw: you might need to run with -a for that
<pitti> I think it's not regenerating older milestone charts by default
<pitti> (to save cycles)
<apw> pitti, would the installed version also be -a or not -a
<pitti> not -a by default
<apw> as i think we need an expensive run to fix the older graphs
<pitti> due to the per-user charts, it currently takes aaages
<pitti> yes, we can run it once with -a for taht
<apw> i'll run it now to confirm they are fixed
<pitti> cheers
<apw> pitti, yeah that fixed the broken lines for me (-a)
<apw> pitti, do we do one -a per day still ?
<fargiolas> what is the better place to put gconf based customizations (let's say I want to build a custom ubuntu variant) so that they are kept over updates? is /usr/share/gconf/defaults dir meant for this kind of job?
<pitti> apw: http://bazaar.launchpad.net/~work-items-tracker-hackers/launchpad-work-items-tracker/trunk/revision/225
<apw> pitti, looks good
<pitti> tkamppeter: I committed upstartification into cups trunk, if you want to test
<tkamppeter> pitti, great. will try.
<pitti> tkamppeter: it still causes smbd to hang if I stop/start it manually (will discuss with Keybuk), but on a normal boot, both are running
<tkamppeter> pitti, some questions:
<tkamppeter> pitti, is the "author" field really for the upstream author of the program to be started? Or is it for the author of the upstart script?
<pitti> tkamppeter: not sure; gdm uses the upstream one, smbd has slangasek
<tkamppeter> pitti, the "pre-start script" (I assume that this is a shell (sh) script) has
<tkamppeter> [ -x /usr/sbin/cupsd ]
<pitti> tkamppeter: right, it's a sh -e script
<pitti> for preparing the environment, see man 5 init
<tkamppeter> as first line. does this really make sense? Should it not be something like
<pitti> tkamppeter: that'll fail the job if cupsd doesn't exist
<pitti> tkamppeter: since the script is set -e
<tkamppeter> [ -x /usr/sbin/cupsd ] || exit 1
<ion> Thatâs just redundant
<ion> OTOH, it documents itself better.
<ion> OTOH, anyone editing the code should be familiar with the semantics of sh and set -e anyway. :-P
<tkamppeter> OK.
<tkamppeter> pitti, I have looked into the upstart script now and it looks much simpler than an init script. Looks like upstart takes a lot of repeated stuff away from the developer or admin.
<pitti> right, I could drop all the pidfile and status handling
<tkamppeter> pitti, in the init script there are code sections "Get the timezone set" and "restart xprint". They are not in the upstart script. Are they obsolete?
<pitti> tkamppeter: I tested logs and jobs, and they have teh correct timezone without setting $TZ
<pitti> tkamppeter: I dropped xprint because handling it there would also require upstartification of xprint, and we don't really support xprint in Ubuntu anyway
<tkamppeter> pitti, the init script also contains
<tkamppeter> chown root:lpadmin /usr/share/ppd/custom 2>/dev/null || true
<tkamppeter>         chmod 3775 /usr/share/ppd/custom 2>/dev/null || true
<tkamppeter> Is this not needed any more?
<pitti> that should go into the postinst; no need to do it on every start
<pitti> tkamppeter: (it's in bzr now)
<tkamppeter> pitti, the debian/changelog has a small bug: The first item of my changes should start with debian/patches/default-ripcache-size-auto.dpatch. We had the patch before, we do not "Add" it.
<pitti> tkamppeter: ah, thanks; fixed
<pitti> tkamppeter: I merged the two maverick changelogs, since these aren't appropriate for a Debian upload
<tkamppeter> pitti, upstartification of CUPS seems to work well for me. There is even a backward compatibility interface, to comply with the LSB (very important for LSB-based driver packages).
<pitti> right
<pitti> tkamppeter: I added some preinst code to clean up the old init script; you shouldn't have any /etc/rc*/*cups* any more, and /etc/init.d/cups should be a symlink
<tkamppeter> pitti, clean-up works. Only thing to be done is now to coordinate with Keybuk so that the smbd script does not hang on manual operation.
<pitti> right, I'm waiting for him
<quadrispro> diwic_lunch, do you need help to push new fluidsynth release to git?
<tkamppeter> pitti, are my Jockey patches OK?
<pitti> still no time to look at them, sorry
<diwic> quadrispro, hi there!
<diwic> quadrispro, if you want to do something, be my guest :-)
<quadrispro> diwic, well, you'll see my changes soon
<diwic> quadrispro, should we try to get the LADSPA stuff up and working again? If so, you should pull changeset 360-363
<lucidfox> quadrispro, so you're a DD now? Congratulations!
<quadrispro> lucidfox, yep, get my new status on May, thanks! :)
<lucidfox> May? o_O
<quadrispro> diwic, well, having a look
<lucidfox> and only just changed fluidsynth?
<quadrispro> lucidfox, no, did a lot of stuff :)
<cjwatson> mvo: could you have a look at bug 637517?
<ubottu> Launchpad bug 637517 in OEM Priority Project "oem-config-remove-gtk crashed with AttributeError in _run_transaction()" [High,Confirmed] https://launchpad.net/bugs/637517
<quadrispro> diwic, I've switched the packaging to the 3.0 (quilt) format, so remember to run quilt pop -a after git-build'ing the package
<coolbhavi> hello archive admins, can you please sync https://bugs.launchpad.net/bugs/636822 as users like this package to be in sync with upstream as possible and personally I would like to see updated networks support in maverick
<ubottu> Launchpad bug 636822 in mobile-broadband-provider-info (Ubuntu) "Please sync mobile-broadband-provider-info 20100910-1 (main) from Debian unstable (main)." [Wishlist,New]
<diwic> quadrispro, okay
<diwic> quadrispro, thanks for your contribution :-)
<Laney> cjwatson: I might sync f-spot manually in lieu of an immediate fix to that bug, if that's OK? Or would you rather use it as a test case?
<quadrispro> diwic, we should move talking about fluidsynth in #debian-multimedia chan (on OFTC)
<cjwatson> Laney: I have another test case, though was sort of hoping to build up pressure on that bug ;-)
<Laney> cjwatson: final freeze is building up pressure on me ;)
<cjwatson> coolbhavi: I've been doing sync runs daily; there's no need to ask
<cjwatson> coolbhavi: get a sponsor to ack it and it will be done
<coolbhavi> cjwatson, okay!
<mvo> cjwatson: sure, will do
<directhex> cjwatson, my proposed fix would work. all we need is for Mike GemÃ¼nde to legally change his name to an ascii-only one, then the problem goes away.
<apw> cjwatson, when one boots the maverick beta image, let the burning man be, and then chose try ubuntu from the subsequent menu, the machine seems to hang for several minuts (about 3 on an atom) and apparently there is a large lzma running then, is this expected?
<cjwatson> apw: I don't know really
<cjwatson> apw: the initrd is lzma-compressed for space reasons
<cjwatson> do you mean that early?
<apw> i mean that early and for that long yeah
<cjwatson> not really much I can do
<apw> i have the try/install dialog for several minutes there
<apw> seems to be new behaviour is all
<cjwatson> it's been lzma-ed for a while
<ogra> get a faster CPU :)
<apw> ogra, you can talk!
<ogra> use ARM !
<apw> if an atom is struggling i don't see an arm finding it easy
<cjwatson> I'm not going to have time to look into it, I'm afraid; if you do and find something untoward, I'd be happy to look at fixing it
<ogra> apw, you havent used omap4 yet :)
<cjwatson> but I have my hands full with EFI
<apw> ogra, noone has :)
<apw> cjwatson, fair enough, will see if i can determine what its doing it do and whether it is necessary
<smoser> pitti, ping. https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/634102 is ready for sru review.  I don't think i've left anything un-done.  could you, or someone on the sru review team, please review ?
<ubottu> Launchpad bug 634102 in cloud-init (Ubuntu Lucid) "t1.micro EC2 instances hang on reboot" [High,Triaged]
<kristian014> hello
<kristian014> does anyone speak english?
<amitk> kristian014: that would be the default language
<kristian014> i need somebody to translate for me
<kristian014> isn't this a polish chat?
<amitk> it isn't a polish channel
<kristian014> ooohh ok
<kristian014> sorry
<kristian014> so does anyone speak polish??? lol
<cjwatson> try #ubuntu-pl
<kristian014> ok
<kristian014> thanks
<seb128> cjwatson, ev: hi, how is ubiquity installing translations?
<seb128> does it use aptdaemon?
<ev> seb128: langpacks?
<seb128> yes
<seb128> ev: bug #630924
<ubottu> Launchpad bug 630924 in Ubuntu Translations "Language packs are not downloaded during installation" [Critical,Triaged] https://launchpad.net/bugs/630924
<ev> indeed, it's on my list
<seb128> I'm wondering if you need a change similar to bug #612825
<ubottu> Launchpad bug 612825 in language-selector (Ubuntu Maverick) "can't install new languages (nothing happen)" [High,Fix released] https://launchpad.net/bugs/612825
<seb128> ev: ie http://bazaar.launchpad.net/~ubuntu-core-dev/language-selector/ubuntu/revision/380
<seb128> dpm, ^
<dpm> ah, thanks seb128, ev
<seb128> ev: well I just wanted to point the language-selector change in case that was useful
<pitti> hello smoser; I'll do an SRU round at some point this week, yes
<ev> seb128: no, it doesn't use aptdaemon.  It uses python-apt with Dir set to /target.
<seb128> ev: ok, ignore me then ;-)
<ev> heh
<ev> thanks for the pointer though
<smoser> pitti, thanks.
<sebner> bad seb128 uploaded b0rken nautilus :P
<seb128> sebner, how broken?
<sebner> seb128: pretty, https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/637704
<seb128> sebner, it works for me at least
<ubottu> Launchpad bug 637704 in nautilus (Ubuntu) "nautilus not starting" [Undecided,Confirmed]
<seb128> sebner, wfm
<sebner> :\
<seb128> we didn't get any complain on #ubuntu-desktop or other bugs
<sebner> seb128: well, at least 5 people seem affected
<sebner> 8 even
<seb128> I guess one of those 8 people need to debug the issue
<sebner> seb128: /me offers himself if you provide guidance
<seb128> sorry but ENOCLUE about that
<seb128> seems a libunique issue
<sebner> meh
<seb128> did you restart your session since the upgrade?*
<seb128> or nautilus?
<sebner> seb128: let me check
<sebner> seb128: wuhhh, the magic of open source strikes again :D
<mpt> cjwatson, doko: How can I find out whether a particular package has an archive override? (fonttools and fonttools-eexecop are the two packages I'm interested in)
<seb128> sebner, works after restart?
<sebner> seb128: yep, sorry for the noice
<sebner> *noise
<seb128> pedro_, ^
<pedro_> cool!
<Laney> can't nautilus arrange to bring that service up?
<pedro_> thanks for the info sebner
<seb128> Laney, it will be a non issue for upgrade from lucid
<seb128> Laney, the port to gapplication was only during the unstable cycle and reverted
<Laney> oh ok
<sebner> Laney: :)
<talat> hi i want to try develop a application that lets you uncharge and recharge the battery/ specify min. battery level on which to start charging.
<talat> change show a road for development i dont now where i must start
<talat> summury how can i control charing on ubuntu
<talat> ?
<talat> how can i control charging on ubuntu ?
<cjwatson> mpt: all packages have overrides
<cjwatson> mpt: you can look at what the overrides say by looking in the /ubuntu/indices/ directory on mirrors
<pitti> talat: the upower daemon (talk to it via dbus) tracks the charge level of the laptop battery, and also from devices
<pitti> talat: you can connect to it with the libupower-glib library, or via dbus directly, and listen to charge change signals
<pitti> talat: check "upower --monitor-detail" whether it knows about your's
<mpt> cjwatson, excellent, found just what I wanted, thanks. Now where do I report a bug that an override is incorrect? On the package itself, or somewhere else?
<cjwatson> mpt: doesn't matter exactly where (on the package itself is as good as any), but the important thing is to subscribe ubuntu-archive to the bug
<mpt> ok, thanks
<talat> pitti, upower give me some information. But how can disable charing ?
<pitti> you can't
<pitti> talat: assuming that you mean "charging"
<pitti> that's done by the hardware
<pitti> well, and BIOS, I assume
<pitti> there might be some machine specific tricks how to control it, but if there are, they aren't supported or known to me
<superm1> some hardware will have a hotkey to do it, but when it does, generally the BIOS is responsible and only sends a notification to the OS that it did it
<talat> superm1, pitti very interseting i dont think why i cant control my charger status. I guess electronical reponse.
<psusi> cjwatson: got a moment to talk about grub2, dmraid, and the ubuntu specirfic patches to remove the 'p' character from the names to separate the partition number from the base name?
<cjwatson> psusi: so, mostly I was just trying to avoid changing things, having only been reminded of this last week
<cjwatson> seems a bit late for a transition
<cjwatson> psusi: if you think it's actively important for some reason, we can do it, but I do know dmraid seems to be rather undertested just now
<cjwatson> figuring out what's wrong with grub2 on dmraid is on my to-do, since I've had a number of reports of problems and I suspect some of them are upstream
<psusi> cjwatson: I started looking at it again because ther was a post on the forums about grub failing to install now on dmraid.. so I started testing it last night, figuring it was because of the p... that grub-probe was getting confused by the device name when trying to identify the underlying device and partition number without the p
<psusi> so I dropped the patch to dmraid, and modified a patch to parted that had the same effect, and got the p showing up in the device name again, and the install worked up until it tried to install grub, where grub-probe still fails
<cjwatson> right, I can't offer specific advice there although I will be able to fix it once I have a chance to sit down and reproduce it ...
<psusi> the purpose of grub-probe is what exactly?  to map the kernel device you are trying to install on to a bios disk, partition, abstraction module, and fs?
<cjwatson> roughly yes
<cjwatson> also determines whether the boot loader will be able to read a particular file
<psusi> and how can it possibly do that with dmraid? ;)
<psusi> other than just assuming a dmraid device is hd0?
<cjwatson> grub has a certain amount of raid support
<cjwatson> which can be extended to dmraid
<cjwatson> but in any case it can probably just pick a disk and read off it
<psusi> well that's the thing... with dmraid you DON'T use a raid abstraction module, since the bios takes care of it
<cjwatson> well then, there should be little problem
<cjwatson> it just needs to know that at the right time, that's all
<psusi> yea, so I think grub-probe needs to notice it's a dmraid device, split the partition number off, and assume the base device is hd0... I think... hrm...
<cjwatson> I don't expect that there's a particular boot-time problem - it'll just be a matter of tedious OS device manipulation
<cjwatson> this is stuff I've done before
<cjwatson> in fact I *did* get it working at one point
<cjwatson> it has obviously bitrotted a bit
<psusi> yea, it worked in lucid
<cjwatson> but if you look at e.g. util/deviceiter.c you'll see a good deal of dmraid-specific code, written by me
<cjwatson> it just needs to be debugged back into a working state, that's all
<psusi> ahh
 * psusi reads on
<psusi> so did you just have it assume a dmraid device is hd0 or did you come up with some magic to figure it out?
<cjwatson> forget about hd0
<cjwatson> the drive ordering doesn't particularly matter these days anyway
<cjwatson> it just sticks any dmraid arrays on the end of the enumeration
<psusi> the mbr needs a bios disk number to read in the core doesn't it?
<cjwatson> nope
<psusi> how does it manage that?
<cjwatson> in the Unix-land utilities, we need a drive number in order to have a consistent bidirectional mapping, and otherwise it's irrelevant nowadays
<cjwatson> at boot-time, two things
<cjwatson> firstly, the core image is normally embedded right after the MBR, on the same disk, so it can just use %dl which the BIOS gives it
<cjwatson> secondly, the core image finds everything else using UUIDs
<cjwatson> (actually, if /boot is on the same disk as the core image, that's optimised away, and we just store the partition number)
<psusi> theoretically the bios is supposed to pass the mbr the bios disk number it was loaded from in the CL register, but I learned from working on the ReactOS boot loader that not all bioses do, which is why dos etc always hard code it to 80 in the mbr
<cjwatson> what usually happens is that the disk you boot from magically becomes 0x80 for that boot
<SpamapS> apw: add --all-milestones to generate the old milestones
<psusi> was it dl?  hrm... thought it was cl... either way
<cjwatson> but grub's mbr does have some sanity checks for things going wrong
<cjwatson> it's dld
<cjwatson> dl
<cjwatson> anyway, none of that is dmraid-specific
<psusi> yea, that's the other industry standard kludge... since does hard codes 80, the bios just makes whichever disk you boot from 80 ;)
<cjwatson> we set dl to 0x80 if it looks wrong, and otherwise use what we're given
<cjwatson> if it has the top bit set, it's generally right
<Sarvatt> what's the process for requesting a binary only pocket change for a package? libgl1-mesa-dri-experimental (which contains nouveau dri) is completely unsupported by upstream and is in main currently
<psusi> I see...
<cjwatson> Sarvatt: file bug, subscribe ubuntu-archive, we'll figure it out from there and ask you for more if need be
<Sarvatt> thanks!
<cjwatson> there was a patch on grub-devel recently for some dmraid issue, I think, which I haven't reviewed yet
<psusi> that's another oddity I've noticed... grub sets the device by name in the cfg, then uses the search command to search by uuid... seems redundant doesn't it?
<psusi> but that's neither here nor there... I'll go read code
<psusi> ohh, but you think it is too late then to drop the 'p' removal for mav?
<cjwatson> the 'set root' + search --fs-uuid is really just insurance
<cjwatson> yes, it's redundant, it's a just-in-case kind of thing.  occasionally it helps and it doesn't hurt
<cjwatson> dropping 'p'> I'd say only if it's needed to fix installation
<cjwatson> if it's needed, fine, we can do it
<psusi> heh, actually I ran into a situation where it does hurt... if you have multiple devices with the same uuid... like if you have an lvm snapshot ;)
<cjwatson> otherwise, sorry for forgetting it until now; I had incorrectly been thinking that it was bound up with lvm2, and it wasn't until I went to update lvm2 that I remembered that was wrong
<cjwatson> psusi: what I mean is that the 'set root' doesn't hurt
<cjwatson> LVM snapshots should be explicitly avoided in maverick
<cjwatson> if you can demonstrate this not happening correctly, it is a bug
<psusi> speaking of lvm2... when I installed it on the daily livecd last night, I got a bunch of errors... it seemed to be a result of it pulling in watershed and/or trying to rebuild the initrd
<cjwatson> but GRUB's LVM code definitely tries to avoid snapshots
<cjwatson> installing things that update the initramfs on the live CD is generally tricky
<psusi> I thought the trigger noticed it was on livecd and just bailed out
<cjwatson> FWIW, in general, anything that tries to use (hd0) or (hd0,1) type addressing at boot time in GRUB these days, without having a UUID search as well, is deprecated
<cjwatson> it's still supported because there'll be user configuration using it
<cjwatson> and it's easier to type at rescue mode or whatever
<cjwatson> but long-term it isn't reliable and can't really be made reliable
<cjwatson> there's somebody who sits spamming grub2 bugs on LP about how GRUB doesn't match BIOS drive ordering, missing the point that (a) there's no way for it to do so and (b) if it matters then it's a bug
<psusi> heh
<cjwatson> (yes, there's EDD.  it's supported on a subset of hardware, and the contortions required to get at it from userspace and do anything useful with it are moderately hideous)
<psusi> yea, reminds me of floppy detection... technically the drives were supposed to respond to a detect command to find out their size and capacity... but nobody bothered implementing that part of the spec, which is why you had to go into the bios and tell it what kind you plugged in... and the os has to get that from the bios and trust it... leading to idiots complaining that Ubuntu shows them a...
<psusi> ...floppy when they don't have one...
<psusi> who then complain when told to stop telling their bios they have one
<pitti> Keybuk: hello, how are you?
<pitti> Keybuk: I have a question about cups upstartification; do you have a minute for that?
<Keybuk> for you, I have ten
<Keybuk> and I do apologise, my brain has a lot of "new upstart" in it, so I might have to think how the current version behaves
<slangasek> pitti: FWIW, I understood that the chmod/chown in the cups init script was because admins might drop local files in this directory (ignoring the FHS); but maybe this was just wishful thinking on my part :)
<pitti> Keybuk: I created an upstart script and added the necessary transition bits (http://bazaar.launchpad.net/~pitti/cups/debian-trunk/revision/893); starting/stopping cups works, and booting works as well (both smbd and cups are running)
<pitti> Keybuk: but if I "stop cups; stop smbd", and "start smbd", (or even manually start cups), the start smbd keeps hanging forever, and "status smbd" says "smbd stop/starting"
<pitti> Keybuk: do you have a hint how I can debug that?
<Keybuk> right
<Keybuk> you'd need to restart dbus too
<Keybuk> and restart the filesystem ;-)
<pitti> I don't understand
<pitti> so smbd blocks on what exactly?
<pitti> status cups says "started"
<pitti> so smbd could just go?
<Keybuk> ok
<Keybuk> let me work it through with you
<Keybuk> so you've just run stop cups; stop smbd
<Keybuk> and everything looks fine
<Keybuk> now you run
<Keybuk> # start smbd
<Keybuk> upstart will begin starting that job
<Keybuk> the first thing it emits is the "starting smbd" event
<Keybuk> and it will _WAIT_ for that event to complet
<Keybuk> --
<Keybuk> so upstart looks for jobs with "on starting smbd", in this case cups
<Keybuk> cups isn't running (you stopped it), so cups will take the event
<Keybuk> but cups needs (you used "and") started dbus and filesystem too
<Keybuk> so cups isn't ready to start yet
<Keybuk> but because cups is holding the event, smbd isn't ready to start yet either
<Keybuk> it's a great example of bug #447654
<ubottu> Launchpad bug 447654 in upstart "init: using 'and' operators can cause hangs" [High,Triaged] https://launchpad.net/bugs/447654
<pitti> Keybuk: hm, but that even happens if I start cups before
<Keybuk> sure
<Keybuk> let's work that one
<Keybuk> --
<Keybuk> back at stop cups; stop smbd and everything is ok
<Keybuk> now you start cups, and cups *finishes starting*
<Keybuk> once again, it's in a reset state (the start on bit has been cleared)
<Keybuk> so start smbd, will cause "starting smbd", which will get picked up by the cups job for the next time it's started
<pitti> right, we are at
<pitti> $ status cups; status smbd
<Keybuk> so it's still blocked
<pitti> cups start/running, process 1751
<pitti> smbd stop/starting
<pitti> here
<Keybuk> right
<Keybuk> # initctl emit started dbus
<Keybuk> # initctl emit filesystem
<Keybuk> err
<Keybuk> sorry
<Keybuk> # initctl emit stopped udevtrigger
<Keybuk> not filesystem
<Keybuk> not sure why I had filesystem in my brain here
<pitti> ah, because it literally is "start cups when smbd starts", not really "cups needs to be started in order for smbd to start"
<Keybuk> yes
<Keybuk> basically
<Keybuk> what you've said there is
<pitti> argh, meeting now, back in 20 mins or so (sorry)
<Keybuk> "if smbd starts, wait for dbus and udevtrigger, then start cups"
<Keybuk> (and let smbd start)
<Keybuk> that can also work in the other order
<Keybuk> "after dbus and udevtrigger, when smbd starts, start cups then let smbd start"
<Keybuk> the problem is that once cups has started, it forgets that dbus and udevtrigger have been
<Keybuk> so if you ever "stop cups" you'll have to restart all those other things
<tkamppeter> Keybuk, is there no possibility for "make sure that the cupsd is running when smbd is started"?
<Keybuk> not currently, Upstart doesn't work that way
<Keybuk> in fact, if anything, it's designed to stop you doing that
<Keybuk> because "what if the user doesn't *want* cups running?"
<Keybuk> and "what if the user has disabled the init script?"
<Keybuk> and "what if the init script is still there, but the package is uninstalled?"
<Keybuk> etc.
<cjwatson> this all became much easier for me to think about when I realised that upstart start* and stop* events are events which are emitted at certain times and which block until all the jobs hung off them have reached their desired state
<cjwatson> rather than some kind of different abstraction
<Keybuk> well, that's all they are :p
<cjwatson> it was a bit like the epiphany where I realised that Verilog (a VHDL) was NOT NOT NOT procedural despite looking like it was
<Keybuk> few people realise that's how Upstart works
<cjwatson> and thereby managed not to fail my second year CS project ;-)
<Keybuk> I like to explain it like this:
<Keybuk> you have a conveyor belt
<Keybuk> at one end you put things ("events)" on it
<Keybuk> and at the other end is a great big masher that bond villains habitually fall into
<Keybuk> (nobody knows why, they just do, it has to be factored into the janitorial budget)
<Keybuk> emitting an event is making something and putting it on the conveyor
<Keybuk> and you're allowed to attach a piece of string to it if you like
<Keybuk> if you do, you know the event got mashed because the string went limp and you can do something else
<Keybuk> if you don't, you don't care
<cjwatson> ... I think I'll stick with my current mental model :-)
<Keybuk> so you can put an event on, wait for it to get mashed (using the string), and then put another event on, or carry on with what you're doing
<Keybuk> now, along the conveyor are the jobs
<Keybuk> they're allowed to take events off
<Keybuk> as long as they put them back when they're done
<psusi> I like it... attach string to second object, and when first object gets mashed, it pulls the second onto the belt
<Keybuk> psusi: exactly
<cjwatson> the thing that doesn't quite help with is that more than one job can take an event off the conveyor at the same time (right?)
<cjwatson> at which point the metaphor kind of breaks down a bit
<Keybuk> well, I guess
<Keybuk> but I like my metaphor
<Keybuk> :p
<cjwatson> well, not at the same time exactly, but concurrently anyway
<psusi> I see jobs as just a part of the conveyor belt... more jobs = longer belt
<Keybuk> maybe jobs get to put a kind of string on that stops things falling into the conveyor?
<mohanohi> there is an ever long bug in ubuntu : http://brainstorm.ubuntu.com/idea/15648/
<mohanohi> will it be solved?
<Keybuk> anyway, the key point as psusi says is that jobs themselves make events
<Keybuk> so jobs can line up waiting for other jobs
<Keybuk> and things can get stuck because they're waiting for things that got mashed
<mohanohi> eating lot of ram while copying to usb 2.0 drives files more than 1-2 gb
<mohanohi> and slowing down the transfer rate
<cjwatson> mohanohi: (not that this has anything to do with me, but) has somebody narrowed it down to the particular component of the OS that's causing a problem, and filed a proper bug?
<psusi> but can't events be both level or edge triggered?  like the run level... it's level... it never gets mashed, it just is
<mohanohi> cjwatson: donno
<Keybuk> psusi: no, they're always edge in upstart
<mohanohi> its around 2008
<Keybuk> the "state" of the runlevel is handled in /var/run/utmp
<Keybuk> when you run telinit, it reads this to get the PREVLEVEL and puts the argument in RUNLEVEL
<Keybuk> otherwise it's just an event "runlevel $RUNLEVEL $PREVLEVEL" is treated no differently than "control-alt-delete"
<Keybuk> it happens, if you missed it, go read utmp
<tkamppeter> auto-closing bugs on uploads with the fix did not return to work yet?
<psusi> so if you make a job start on runlevel 3, it will only start when you SWITCH to runlevel 3?  but if you're already at runlevel 3 and the job isn't running, it won't be started?
<tyarusso> psusi: correct
<psusi> bummer
<tyarusso> psusi: Otherwise it would be impossible to stop a service.
<psusi> good point
<psusi> so how do you make sure a newly installed service is started?  if you manually start it, but it isn't supposed to be running in the current runlevel....
<Keybuk> bug #307779
<ubottu> Launchpad bug 307779 in upstart "init: new jobs should be automatically started" [Wishlist,Triaged] https://launchpad.net/bugs/307779
<psusi> heh
<ion> psusi: Native Upstart jobs probably shouldnât care about runlevels if at all possible.
<cjwatson> tkamppeter: I'm told it's on its way, but it's already later than it was promised to me
<fta> sladen, yt?
<sladen> fta: yo
<sladen> fta: I spoke to agl yesterday.  See also https://wiki.ubuntu.com/Ubuntu_Font_Family#Howto for sign up details
<fta> sladen, ok
<sladen> fta: I couldn't replicate the issues with Chromium yesterday but apparently the errors are still arriving at your end
<sladen> fta: really it needs one or more of those users to tell us what (font family) version they're using and hopefully to grab that historial version and try with that
<fta> sladen, the reason i pointed to the ubuntu fonts is that all the crash reports i got were from people who have those fonts, the crashes started after they installed them, and disappeared as soon as they removed them
<fta> sladen, there's a bug in the upstream bts, and another in lp
<pitti> Keybuk: re (sorry, had a meeting)
<fta> sladen, plenty in the forums, and even more in my mailbox
<fta> sladen, but i'm not impacted, as i never installed those fonts
<pitti> Keybuk: right, so I should stop thinking about states, and only think about "edge triggers"
<Keybuk> absolutely
<pitti> Keybuk: so, in other words, do you consider the current cups start on condition buggy, or is it "correct" within the boundaries of upstart's models?
<pitti> i. e. "stop smbd" -> "just don't do that"?
<pitti> after all, a normal boot works just fine
<Keybuk> well, it's correct, you just can't stop/start manually
<Keybuk> there's lots of cases that doesn't work out so well
<pitti> ok, great; I was just worried about that bit
<pitti> Keybuk: thanks a lot for the explanation! (I'm sure you already gave it like 20 times to people, sorry)
<Keybuk> that's ok, I enjoy giving it :p
<pitti> heh
<psusi> why can't you stop smbd?
<sladen> fta: me neither, and nobody who seems to be able to replicate it
<psusi> sounds like you want cups to be stop on smbd stopping
<pitti> ugh, final freeze already?
<Keybuk> psusi: wouldn't help - see above
<pitti> psusi: no, I don't want that actually
<sladen> pitti: 10.10.10.10.10 stole two weeks
<pitti> psusi: the only point of that dependency is that samba can pick up cups printers to the windows network, but otherwise they are quite independent
<tkamppeter> pitti, Thursday, and I would very much like CUPS/Samba to work then and Jockey to be uploaded.
<psusi> ahh
<psusi> so why does stop smbd cause a problem?
<Keybuk> it doesn't
<Keybuk> it's start smbd
<psusi> why is that a problem?
<maco> could a core dev sponsor this?  https://code.edge.launchpad.net/~ilidrissi.amine/ubuntu/maverick/language-support-fonts-zh-hans/fix-625163/+merge/33977  the patch looks fine to me
<cjwatson> hm, language-support-fonts-* is generated by lp:langpack-o-matic
<cjwatson> if that patch is sponsored, it'll be overwritten at the next autogeneration
<pitti> tkamppeter: right, so I'll get that cups uploaded now, and will put jockey on my plate for tomorrow morning
<cjwatson> (I've said that in the review)
<Keybuk> psusi: go read above
<Keybuk> I explain it pretty carefully
<cjwatson> maco: (also there seems to be some subsequent? conversation in the bug)
<maco> cjwatson: oh ok. hrm why do bugs link to matching branches but branches dont link to matching bugs? how silly...
<psusi> ohh... so smbd is tied to cups, but cups is also tied to filesystem, so when smbd tries to pull cups onto the belt, it gets stuck because filesystem isn't also pulling
<psusi> so no masher for smbd
<maco> cjwatson: what about the part of the patch that adds an additional font to the metapackage's dependencies?
<cjwatson> maco: extra dependencies are fine, but there's a special file in lp:langpack-o-matic listing that stuff
<cjwatson> support-depends/maverick/zh-hans, I believe
<maco> oh so both the symlinks /and/ depends are handled in there. magic.
<didrocks> pitti: did you see my hilight on Quickly and FFe? (bug #638130)
<ubottu> Launchpad bug 638130 in quickly (Ubuntu) "[FFe] Quickly 0.6 in maverick" [Undecided,New] https://launchpad.net/bugs/638130
<pitti> didrocks: I didn't, no; probably got lost in the meeting marathon
<didrocks> pitti: no hurry but as I won't be there then until Fridayâ¦ :)
<nigelb> james_w: can you package training session on 23rd? (currently its maco, but I'm wonder if you could switch with ther)
<mathiaz> ScottK: hi!
<mathiaz> ScottK: what is the next step for bug 638213?
<ubottu> Launchpad bug 638213 in lucid-backports "Please backport puppet 2.6.1-0ubuntu1 from maverick" [Undecided,New] https://launchpad.net/bugs/638213
<lamont> ogra: NCommander: please don't change buildlive to email me.  I already get SMSed when the machine is down, as do others.  and then we have someone power cycle the machine when they're in the data center
<lamont> ogra: NCommander: if you want a productive task, get me some machines that I can power cycle remotely
<ogra> lamont, yeah, i thought so
<ogra> lamont, you will get them in november or december
<ogra> we're working on that
<lamont> I mean, sadly, it's one of those "yep, this is gonna suck" SMSes that I get all to frequently
<ogra> first we need stable HW and an OS running on it ;)
<lamont> hey yeah, that'd be just dandy!
<ogra> which will be there areoung maverick release date
<ogra> *around
<ogra> then we'll just wait for some mass production :)
<lamont> if it requires maverick for stability, I can live with that.  Just as long as lucid still builds with maverick underneath, of course.
<ogra> sure
<ogra> the HW we currently work on builds a kernel in 2.5h
<ogra> (current buildd time is 6h)
<lamont> The following packages will be REMOVED:
<ogra> and thats on a rotary disk ... with USB SSD that should speed up even more
<lamont>   hplip
<lamont> that's not very nice of it
<ogra> sadly no SATA yet
<didrocks> cjwatson: ok, so pitti got sidetrack about the Quickly FFe and Riddel is on vacation, can you have a look please? (bug #638130). I'll be back only on Friday and I would prefer pushing the new release before final freeze
<ubottu> Launchpad bug 638130 in quickly (Ubuntu) "[FFe] Quickly 0.6 in maverick" [Undecided,New] https://launchpad.net/bugs/638130
<didrocks> (or ScottK, if you are around)
<james_w> nigelb: I'd be happy to if maco is
<nigelb> james_w: she's inconvinienced on 23rd, hence the chance
<james_w> nigelb: then I'm fine with it
<nigelb> maco: you're okay with 30th?
<maco> nigelb: yeah
<nigelb> maco, james_w: thank you.  You both rock :)
<nigelb> james_w and maco: er preferred time? (sorry!)
<james_w> nigelb: are we still trying for the rotation of times, or just mixing it up/
<nigelb> james_w: right now, the focus is filling it up according to nhandler :)
<james_w> :-)
<james_w> I would go for something like 20:00 UTC then
<nigelb> ok!
<SpamapS> james_w: http://package-import.ubuntu.com/status/memcached.html#2010-06-09 01:31:43.802534  .. any ideas whats up with that?
<james_w> SpamapS: caused by LP downtime presumably, retried and marked as a spurious failure so that it will be auto-retried next time
<SpamapS> james_w: ah, so sometimes things just get stuck as broken, and have to be manually un-stuck?
<nigelb> james_w: do you have a name for your session?
<james_w> SpamapS: yeah, the way it works is that if the job crashes for any reason it has to be reviewed to check for bugs/abuse of the other systems.
<james_w> SpamapS: however there is a way to mark specific failures as probably-spurious and have them retried a number of times automatically without review
<james_w> nigelb: not yet, I haven't decided what I am going to talk about
<james_w> nigelb: suggestions welcome
<nigelb> suggestions...hrm
<papertigers> anyone know if those apple magic trackpad drivers in 10.10 work for the touchpad on the laptops?
<shadeslayer> jono: free for a sec?
<jono> shadeslayer, sure
<shadeslayer> jono: i was wondering if theres a tentative date by which the participants for UDS are confirmed
<shadeslayer> ( ive applied and it takes some time for visa's to be approved here )
<jono> shadeslayer, over the next week or so
<jono> hopefully this week
<shadeslayer> oh great .. thanks alot :D
<shadeslayer> night everyone :)
<Intrusion> hey there... I have a question
<Intrusion> I am wondering if there is a good place for a total newbie to learn development within the ubuntu community
<Intrusion> is there a small project that I could tinker with?
<Intrusion> something low priority, but helpful for someone who wants to hone my programming skills
<Intrusion> I am wondering if there is a good place for a total newbie to learn development within the ubuntu community
<Intrusion> something low priority, but helpful for someone who wants to hone my programming skills
<sladen> Intrusion: in about 3 weeks there will be lots of development things to work on.  At the moment Ubuntu is solidly bug fixing until release
<Intrusion> great
<Intrusion> is there a good place to stay up to speed with what needs to be done
<sladen> Intrusion: -> #ubuntu-motu
<Intrusion> ok... I will go and check in there
<Intrusion> thanks a lot for the help
<hallyn> feh!  command history misfire.  is there a 'bzr undelete' ?
<nigelb> hallyn: what are you trying to achieve/
<hallyn> heh, i did a bunch of valid 'bzr removes', then an invalid one
<hallyn> nm, i copied it back from elsewhere and re-'bzr add'ed it
<shadeslayer> hallyn: have you pushed the changes ?
<hallyn> no, but i hadn't committed and didn't want to re-do all the other uncommitted changes
<shadeslayer> bzr revert ?
 * hallyn would be more effective once he figured out how to do git-like cheap local branches followed by rebase -i
<hallyn> can i revert one 'bzr remove'?
<shadeslayer> or is that only after you commit changes?
<shadeslayer> hallyn: dunno.. might be able to.. #bzr would know
<hallyn> not sure
<nigelb> hallyn: heh, can't revert bzr remove unless you've commited
<nigelb> (I think so)
<hallyn> ok, i might play around so i know for next time, and/or go ask there, thx
<shadeslayer> git is the best for this sort of stuff :D
<hallyn> well as i was typing that, it occurred to me i shoudl actually be able to do something close to that
<hallyn> do a local 'bzr branch', commit after every little change, then do a merge -r1..20 in the main branch when i'm done
<hallyn> not *quite* as convenient as git rebase -i, but doable
 * hallyn goes to try
<beuno> hallyn, bzr rm --keep
<beuno> erm, ignore that
<beuno> you can cat
<beuno> so bzr cat FILENAME -r $revision
<hallyn> buxy: so 'bzr cat FILENAME -r $revision > FILENAME' ? :)
<hallyn> uh, huh
<hallyn> beuno: ^
<hallyn> apparently i shouldn't be allowed near a keyboard today
<nigelb> heh
<beuno> hallyn, yes, that should recover a file in your history
<beuno> I jumped in an didn't read things carefully
<beuno> so it may not be what you want  :)
<bilalakhtar_> mvo: Should I go ahead with fixing bug #367287 ?
<ubottu> Launchpad bug 367287 in ubuntu-restricted-extras (Ubuntu) "kubuntu-restricted-extras should depend on lame" [Low,In progress] https://launchpad.net/bugs/367287
<mvo> bilalakhtar_: yes
<bilalakhtar_> mvo: I asked you, since you're maint :_
<maco> bilalakhtar_: hint: before requesting anything of mvo, always offer tea
<maco> ;)
 * bilalakhtar_ offers mvo tea
 * mvo is on the phone so a bit slow
<cr3> marjo_: did you see my private messages to you, marjo (without trailing underscore)?
<sladen> what was the name of the third-party installed that then installed lots of non-free codecs and stuff?
<lifeless> mediabuntu or something?
<nigelb> sladen: ubuntu-restricted-extras or mediaubuntu ones?
<sladen> nigelb: no, no, the godforsaken piece of nightmare that even Michael Dell unfortunately recommended people use
<nigelb> oh?
<james_w> automatix?
<ajmitch_>  I think that's the one
<ajmitch_> it was quite popular & caused a lot of headaches
<nigelb> sladen: james_w was right, http://www.getautomatix.com/
<sladen> automatix, yup.  Thank you nigelb and james_w!
 * nigelb only googled :D
<nigelb> james did the work:)
<dylan-m> sladen: Careful with that, you might trigger its rebirth.
<nigelb> the site is out right now
<nigelb> sladen: ultramatix is probably the one that works now
<dylan-m> Its successor is actually ultamatix <http://ultamatix.com/>. I think automatix is gone at this point.
<soren> slangasek: Got a sec? I'm looking at the stuff you did with bridge-utils for Lucid.
<soren> slangasek: I'm curious what is meant to happen if "ifup br0" is called and br0 has a an interface listed in bridge_port that isn't around yet.
<soren> slangasek: Perhaps I'm reading it wrong, but looking at /usr/share/bridge-utils/ifupdown.sh from line 58 and onwards, it seems it just assumes the interface is around and attempts to add it and doesn't handle failure to do so.
<soren> slangasek: I'm asking because someone posted this and I got curious: https://lists.ubuntu.com/archives/ubuntu-server/2010-September/004619.html
<nigelb> james_w & maco: http://people.ubuntu.com/~nhandler/classroom.html
<nigelb> please do confirm that the time is suitable for you
<james_w> yes
<nigelb> :)
<nigelb> err, when does daylight savings change? not yet right?
<james_w> nigelb: I don't know actually
<nigelb> October :)
<soren> nigelb: Depends on wher eyou live.
<maco> er i meant 1900 UTC, not GMT
<nigelb> soren: We're smart enough not to have it :p
<rickspencer3> hey all
<maco> er hrmph confusing
<maco> james_w: does GMT move with BST or stay one second off of UTC always?
<maco> hiya rickspencer3
<rickspencer3> I'm trying to log a bug, I think it should be against the package that contains the following file: /build/buildd/glib2.0-2.25.15/gobject/gtype.c
<james_w> maco: GMT doesn't move
<maco> james_w: oh ok then
<rickspencer3> how do I find out what package this file is in?
<maco> rickspencer3: dpkg -S <path>
<rickspencer3> (doing my best based on Python output)
<rickspencer3> sweet
<maco> rickspencer3: if the package is installed that is. if not, apt-file search <file>
<ajmitch> rickspencer3: it's in the filename there, should be glib2.0
<maco> ajmitch: aw but my way he learns how to find things himself :P
<rickspencer3> well, lot of packages seem to answer to the call of glib2.0
<rickspencer3> so, just trying to narrow it down
<kklimonda> rickspencer3: this is a part of libglib2.0-0
<rickspencer3> sweet
<rickspencer3> thanks maco, ajmitch, and kklimonda
<kklimonda> rickspencer3: but I'm not sure if your crash isn't related to something higher - maybe pygtk would be a better guess? still a guess though
<ajmitch> it's useful having the package name in the build path :)
<rickspencer3> kklimonda, well, the warning looks glib(ish)
<rickspencer3> but what the heck do I know
<kklimonda> rickspencer3: sure, it's a warning from glib - but I wonder why did it show.
<rickspencer3> kklimonda, something in PyGtk
<rickspencer3> I'll upload a reproducer
<rickspencer3> kklimonda, do you think PyGtk is a better bet?
<rickspencer3> grid_filter.py:797: Warning: /build/buildd/glib2.0-2.25.15/gobject/gtype.c:4181: type id `0' is invalid
<rickspencer3>   gtk.main()
<rickspencer3> grid_filter.py:797: Warning: can't peek value table for type `<invalid>' which is not currently referenced
<kklimonda> rickspencer3: oh, you have a small test case? then report it against glib and someone will triage it :)
<rickspencer3> kklimonda, it's smallish ;)
<slangasek> soren: so I don't know that 'ifup br0' is handled particularly well, honestly; I don't think manual bring-up of bridge interfaces was on my radar, the changes were focused on fixing the auto-start case
 * slangasek pulls up the link
#ubuntu-devel 2010-09-15
<slangasek> soren: so if this is at boot time, the /intent/ is that the bridging interface will be brought up once any of the child interfaces are brought up; but the Debian maintainer of ifenslave-2.6 brought up a concern that there might not be any locking here, so if both child interfaces start in parallel, one could miss.  Does that sound like what you're seeing?
<rickspencer3> kklimonda, https://bugs.edge.launchpad.net/ubuntu/+source/glib2.0/+bug/638513
<ubottu> Launchpad bug 638513 in glib2.0 (Ubuntu) "PyGtk App Core dumps" [Undecided,New]
<kklimonda> rickspencer3: I've got a smaller testcase: http://pastebin.com/RwY03ht8
<rickspencer3> huh, I thought I tried something like that, and it didn't repro
<kklimonda> lets see if I can reproduce it in C
<rickspencer3> anyway, thanks for that
<rickspencer3> much better
<kklimonda> I can't reproduce it with a hasty written C program but it's way too late for me to debug it further.. but I think that pygtk may be to blame after all
<rickspencer3> kklimonda, makes sense
<rickspencer3> thanks for looking into it
<andreserl> slangasek, ping
<slangasek> andreserl: hey there
<andreserl> slangasek, hi. I just got your email. 1st. There was no FFe filed given that I understood these as a bug fix to get pacemaker in better shape, so I saw no need to file an FFe
<andreserl> second, the overriden warnings also appeared when the libraries were back in pacemaker itself
<slangasek> andreserl: fair enough; I happen to disagree that it doesn't need an FFe, but I see that it can be a matter of opinion whether this is a new feature vs. a bugfix
<andreserl> slangasek, third, what's your recommendation or approach to fix this :)
<slangasek> andreserl: the overridden warnings aren't new, yes - they're also not the reason for the reject
<slangasek> andreserl: my recommendation depends on how this package is intended to be used. Are you splitting these packages because another new package will be uploaded that uses libpacemaker-dev?
<andreserl> slangasek, not really. We, (me and ivoks) are trying to get pacemaker and cluster-glue into main. cluster-glue was rejected because of similar issue as pacemaker
<andreserl> so as discussed with ivoks, he came to a conclusion that the split was the best to make them *more policy* compliant
<slangasek> andreserl: heh - I would have rejected libcluster-glue as well if I had seen that :)
<andreserl> we've been trying to get this done in upstream (library split) however, they are not interested on it :)
<slangasek> what part needs done upstream?
<andreserl> slangasek, pacemaker, cluster-glue, and heartbeat have a similar separation of libraries
<andreserl> slangasek, upstream is working with debian on getting the packages, and as per ivoks discussion, they have rejected the need to have the library split in pacemaker and cluster-glue
<slangasek> I'm not sure what you mean, the libraries are already split
<andreserl> slangasek, I'm sure you;ll understand this better :) https://bugs.launchpad.net/ubuntu/+source/cluster-glue/+bug/527142/comments/13
<ubottu> Launchpad bug 527142 in cluster-glue (Ubuntu) "[MIR] cluster-glue" [Undecided,Incomplete]
<slangasek> ok; so it's more about a delta from the Debian packages
<slangasek> upstream library split isn't terribly interesting to me one way or the other
<slangasek> there are plenty of source packages in the archive that build both libraries and executables, and that's fine - the key point is in how you /package/ the libraries so that things don't break on upgrade
<slangasek> oh; and there are multi-level library interdependencies, and the libraries don't use symbol versioning
<slangasek> so partial upgrades --> segfaults, yay
<lifeless> if only it was partial upgrades --> partial segfaults
<andreserl> if you mean upgrading from ubuntu2 to ubuntu3 (which includes library split), it upgrades as expected according to my tests. Now, if this is the case, the same behaviour should be seen in other packages such as cluster-glue
<andreserl> given that besides pacemaker, cluster-glue and all other related packages come from upstream
<slangasek> andreserl: I mean that if one library changes soname and the other doesn't, and the library that doesn't gets upgraded, but an application that linked against both libs is not upgraded, you get segfaults
<andreserl> i see
<slangasek> andreserl: so are the libraries in libpacemaker guaranteed not to have any soname changes?
<slangasek> if that's the case, then this can be accepted
<slangasek> but first the file conflict between pacemaker and libpacemaker-dev should be resolved
<slangasek> (so it needs a new upload, no matter what)
<slangasek> lifeless: which part would you like to segfault? :-)
<andreserl> slangasek, afaik they wont have soname changes but I'm not sure. I'd rather talk to upstream and get back to you on that
<slangasek> ok
<slangasek> that's the main thing I'm concerned about here - forward-planning
<slangasek> it's a lot harder to retrofit a solution when it comes to lib upgrades
<andreserl> I see (notice that I'm not a library packager expert, in fact, this is my first attempt to package libraries)
<andreserl> anyways, on the side of the file conflict between pacemaker and libpacemaker-dev, what's the best approach to address this??
<slangasek> andreserl: well, the file that's conflicting doesn't belong in a -dev package because it's a runtime lib
<slangasek> so I guess putting it in pacemaker only would solve it :)
<andreserl> slangasek, oh I think I just realized what the issue is. So, yeah it's and easy fix
<andreserl> ok so, the only thing right now would be to guarantee that there won't be a soname change in future releases, correct?
<slangasek> andreserl: yes
<andreserl> slangasek, ok then. I'll discuss this with upstream and get back to you tomorrow. If this is the case, I'll have new packages ready for tomorrow :)
<andreserl> if not, you'll help me get the packaging in better shape :)
<slangasek> andreserl: sounds good :)(
<slangasek> :)
 * psusi wonders what the deal is with canonicalizing device names from /dev/mapper/foo to /dev/dm-x
<andreserl> slangasek, should I address any other lintian stuff such as: E: pacemaker: postinst-must-call-ldconfig usr/lib/service_crm.so
<slangasek> andreserl: that one seems to be a false positive, given that this is the same file that returns the improper-soname error :)
<andreserl> slangasek, ok then :) First error is fixed, now just waiting for upstream's word on the sonames :)
<mwhudson> ScottK: re python-defaults 2.6.6-2
<mwhudson> Sep 13 12:02:46 <ScottK>        mwhudson: It it's not done by Wednesday, please remind me.
<mwhudson> i don't think it's been done?
<ScottK> mwhudson: No.  It hasn't.  Unfortunately I'm heading to bed and it turns out I'll be offline almost all of tomorrow.  You might also ask doko.
<mwhudson> ScottK: ok, i'll poke him if i get the chance
<SpamapS> Hrm.. installing on a Dell mini 1012 w/ netbook edition 10.10 beta.. it seems the installer window is only using half the width of the screen
<pitti> Good morning
<SpamapS> wow... installing from 10.10-beta on a netbook has been, so far, extremely painful
<SpamapS> mutter and plymouth segfaulting.. hundreds of packages to update.. :-P
<slangasek> SpamapS: plymouth segfaulting, or being killed by the OOM killer?
<SpamapS> slangasek: Actually I think it was OOM killed
<SpamapS> slangasek: either way, install on netbook was horrendous
<SpamapS> and after upgrade, I can't login with a netbook session
<SpamapS> I just get a blank white screen :-/
<soren> slangasek: Nope, this dude only has one interface on the bridge.
<SpamapS> whoa, and gnome help is all unicode sequences instead of characters
<soren> slangasek: So if someone has "auto br0" in his /e/n/i, the networking upstart job will attempt to configure it, and adding the interface will fail. Right?
<soren> slangasek: Err... assuming the physical interface hasn't turned up yet, I mean.
<primes2h> Hello pitti! Is there a way to workaround this in apport-collect? It's a blocker bug. bug #628755
<ubottu> Launchpad bug 628755 in w3m (Ubuntu) "Impossible to log in in Launchpad using apport from a tty console" [High,Confirmed] https://launchpad.net/bugs/628755
<primes2h> btw, I'm thinking about marking it as "Critical". mmhh..
<pitti> primes2h: install links?
<pitti> primes2h: apport-collect also prints out the URL, so if you have this problem on a remote server, you can just open the URL locally
<primes2h> pitti: that is ubuntu-bug, apport-collect don't do it.
<primes2h> at least, I haven't seen links.
<primes2h> s/don't/doesn't
<pitti> primes2h: works here
<pitti> $ apport-collect 12345
<pitti> The authorization page:
<pitti>    (https://edge.launchpad.net/+authorize-token?oauth_token=DEADBEEF
<pitti> should be opening in your browser. [...]
<primes2h> pitti: Does it appear in a terminal?
<pitti> yes, that was from a temporary test user I su'ed to
<pitti> that's standard launchpadlib login_with()
<primes2h> pitti: I get the "The authorization page: bla bla" only when I quit w3m. I must run apport-collect on tty1 because GUI doesn't start. Does that link allow to upload info from the broken pc even if I put it on another pc browser?
<pitti> yes
<primes2h> pitti: I remember that using ubuntu-bug there is an explicit advise about using the link on another pc, in apport-collect there isn't. It would be nice to add it as well.
<pitti> that'd need to go into launchpadlib
<pitti> but yes, would be nice
<primes2h> pitti: btw, I'm going to try it.
<primes2h> pitti: I can open a bug about that improvement
<pitti> thanks
<davmor2> Hi guys I'm having issues with une this morning I upgraded and I get the new background and gdm, then once I log in I get a white background with a white arrow and that's all,  no unity/icons/toolbar etc
<gord> davmor2, yup, known issue. no fix yet. sorry :(
<davmor2> gord: thanks :)
<davmor2> gord: is there a bug report for it do you know?
<gord> davmor2, i'm not aware of one
<davmor2> gord thanks :)
<bilalakhtar> Is bug #604135 worth SRUing into Lucid?
<ubottu> Launchpad bug 604135 in mplayer (Ubuntu Lucid) "missing "Unsupported PixelFormat 10" fix patch" [Medium,Triaged] https://launchpad.net/bugs/604135
<pitti> tkamppeter: ok, got the speed up fixed and committed nwo
<pitti> tkamppeter: for the epson drivers, the current debdiff still doesn't do anything to actually install the key, etc.
<pitti> so we don't have any authentication at all
<pitti> and installing that key isn't trivial either
<bilalakhtar> pitti: Do you think bug #604135 should be SRUed? It is affecting everyone, though it occurs only with a certian type of file, and the fix is a single-line fix.
<ubottu> Launchpad bug 604135 in mplayer (Ubuntu Lucid) "missing "Unsupported PixelFormat 10" fix patch" [Medium,Triaged] https://launchpad.net/bugs/604135
<pitti> hey bilalakhtar, congratulations for joining the MOTU ranks!
<ogra> pitti, i have an apport question ...
 * bilalakhtar wonders how pitti came to know about his MOTU application
<bilalakhtar> Thanks pitti !
<ogra> pitti, is it possible to somehow tell apport in the hooks to assign bugs to a different LP project (other than ubuntu) ?
<pitti> bilalakhtar: SRU> seems fine, and the lucid task is already approved
<pitti> bilalakhtar: I saw you getting added to ~motu :)
<ogra> we'd need something like that for TI images
<pitti> ogra: yes, it is
<ogra> how ? i dont find it on the wikipage
<pitti> ogra: ubuntuone-client already does exactly that to also support PPA builds
<ogra> ah
<pitti> ogra: some pointers:
<ogra> yeah, its for a ppa
<pitti> /usr/share/doc/apport/crashdb-conf.txt
<pitti> /usr/share/doc/apport/package-hooks.txt.gz ("Customize the crash DB to use")
<pitti> ubuntuone example:
<pitti> - LP configuration: /etc/apport/crashdb.conf.d/ubuntuone-client-crashdb.conf
<ogra> tsk, who would think to look in the shipped docs :P
<pitti> /usr/share/apport/package-hooks/source_ubuntuone-client.py
<pitti> ogra: yeah, it was an utter waste to write them :)
 * ogra hugs pitti, thanks a lot :)
<pitti> ogra: that hook does pretty much what you need, I think
<pitti>     if not apport.packaging.is_distro_package(report['Package'].split()[0]):
<ogra> perfect, yeah, looks like
<pitti>         report['CrashDB'] = 'ubuntuone'
<pitti> ogra: that means: "if the package is an Ubuntu native one, report it against Ubuntu, otherwise against the "ubuntuone" crash database
<pitti> ogra: (i. e. a PPA version or local build)
<ogra> yeah
<pitti> ogra: the ubuntuone db is defined in untuone-client-crashdb.conf
<tkamppeter> pitti, so you have dropped the Epson thingy?
<pitti> tkamppeter: s/dropped/not committed/
<pitti> tkamppeter: just followed up on the bug
<pitti> I don't see an Epson specific hack which is significantly easier than just implementing the whole thing properly
<pitti> and I don't think it's correct/okay to statically ship the Epson key in the Ubuntu keyring
<pitti> we need to fetch the Epson key on demand and verify a trusted path to it
<pitti> since it could change at any time
<pitti> (which in this case means to fetch its fingerprint from the openprinting page and compare it)
<tkamppeter> pitti, so I have to tell Epson that we have no infrastructure to auto-download Epson driver, so best is a formal feature addition via UDS session?
<tkamppeter> pitti, I have hoped we get it in. For that I reported the bug already much earlier in the development period.
<pitti> right, but as I said, I'm not on platform this cycle, so I didn't have time for it
<pitti> and nobody else did it
<tkamppeter> pitti, did you not say after your first review on Monday that we restrict to Epson (what I did)? I also will advise Epson not to change the key for the time until Natty comes out (and we ship the real solution) and then we ship Epson's key with Maverick.
<pitti> that's the problem with keys -- nobody wants to exchange them, but you have to if they get lost, or broken, or stolen
<pitti> but we don't even have the code to import the current key yet
<pitti> i. e. we need to get to know the key ID, fetch it from the mirrors, and run it by apt-key
<tkamppeter> pitti, could we perhaps SRU the package with the key in case Epson replaces it.
<pitti> or hardcode the keyid, etc.
<pitti> mvo: ^ is it possible/okay at all to ship third-party GPG keys into the default apt keyring?
<pitti> mvo: e. g. if we want to support Epson printer drivers from openprinting.org?
<tkamppeter> The needed info about the key is here:
<pitti> also, all this would need a FF at this point
<tkamppeter> https://linux.avasys.jp/drivers/lsb/epson-inkjet/key/fingerprint
<mvo> pitti: that is possible, if we trust them enough to do that
<tkamppeter> This link is provided on all driver entry pages for the Epson drivers, like:
<tkamppeter> http://www.openprinting.org/driver/epson-ep-302/
<mvo> if the key needs to be exchanged we need to do a security update for the package
<tkamppeter> clicking on (Signed) at the download links (it is the same key for all packages).
<pitti> mvo: what would happen if they replace it with a new key? I guess we can't tell apt right now "require a valid GPG key for this repository", so once the key changes, we'd go back to the simple warning mode, right?
<pitti> once we start adding third-party keys in Jockey with apt-key, we'd need such a flag, I think
<mvo> pitti: you can test that in the backend, there is a is_trusted property on the version
<mvo> pitti: so jockey can just refuse to install packages that are unsinged
<ogra> mvo, if i create a /usr/share/app-install/channels/maverick-ti-ppa.list (and eula), will that work for the new apturl implementation ?
<pitti> mvo: ah, nice
<mvo> pitti: you can also use /etc/apt/trusted.gpg.d/ to put keys in if you want to avoid using apt-key
<mvo> ogra: it should
 * ogra would like to just put a favorite .desktop on the TI images that enables the ppa and installs SW 
<ogra> mvo, how would it get the key ?
<pitti> mvo: nice, just drop single .gpg keys there?
<pitti> mvo: thanks, so it seems everything is there from the apt side then
<mvo> pitti: yep
<mvo> ogra: just add a mavreick-ti-ppa.key file
<mvo> ogra: to the same package that ships the other stuff
<bilalakhtar> If an SRU diverges away from Debian, I should use the version number -Xubuntu0.1 right?
<bilalakhtar> where X is the debian version number
<pitti> bilalakhtar: right
<bilalakhtar> Thanks pitti !
<ogra> mvo, in /etc/apt/trusted.gpg.d/ ?
<mvo> ogra: no, just alongside the .eula and .lsit files
<ogra> ah, perfect
<mvo> ogra: in etc it would be enabled by default, that is probably not what you want :)
<ogra> well, it is :)
<ogra> the TI specific images should have the TI ppa enabled anywa
<ogra> y
<mvo> ogra: oh, in this case, just drop it in the trusted.gpg.d and sources.list.d and don't bother with apturl
<ogra> so it wont matter ... but its more elegant to have all files in one place
<ogra> mvo, ti want a favorite .desktop file that holds the package list so i think i need apturl
<ogra> s/ti/i/
<ogra> and i want a sexy way to show the TI eula :)
<ogra> mvo, btw, thats just awesome !
<mvo> ogra: test it first, I'm not sure the eula is implemented in the new world order (but if not its trivial to add)
<ogra> will do
<tkamppeter> pitti, did mvo's help give us a solution for the Epson driver download?
<pitti> tkamppeter: seems apt has all the building blocks that we need, yes; but the actual implementation of key retrieval, installation, and "is_trusted" checking still remains
<bilalakhtar> pitti: Package cluster-glue is awaiting the queue for getting into -proposed. Looking at the queue, there are many old packages also there, so is there a need to ping a person from the SRU team to get the package in proposed?
<pitti> bilalakhtar: no, it's mainly a matter for an SRU team person to make some time to review packages
<pitti> pinging won't really help, I'm afraid
<pitti> with the freeze being tomorrow, I guess everyone is busy with maverick until then
<bilalakhtar> pitti: thanks
<pitti> also, I was on vac last week, which didn't help SRUs either :)
<ari-tczew> cking: ubuntu-security-sponsors unsubscribed
<cking> ari-tczew, thanks, sorry about that
<ari-tczew> cking: no problem, everyone can do mistake
<smoser> apw, around ?
<apw> smoser, hi
<smoser> i'm really in need of some help on bug 606373
<ubottu> Launchpad bug 606373 in linux (Ubuntu Maverick) "cloud-init output does not get to console when booted with pv-grub and ramdisk" [High,Confirmed] https://launchpad.net/bugs/606373
<smoser> i've gotten some second hand info from jjohansen on what we think the problem is and , thus, how we think we could work around it
<smoser> but i've been unsuccessful in my attempts.
<apw> smoser, basically you lose the output at random i believe yes ?
<smoser> well, in my experience random is "only early in boot"
<smoser> you can see my init wrapper there
<apw> which would also make sense, if its the issue with the console right?
<smoser> output to /dev/console just sometimes doesn't get there.
<apw> from upstart jobs right?
<smoser> yes, from upstart jobs, but also reproduced in that little /sbin/init replacement (that then exec's upstart).
<smoser> see the attachment there.
<smoser> http://launchpadlibrarian.net/55625702/init-wrapper.txt
<smoser> basically it just forks a process that keeps attempting to open and write to /dev/console every second
<smoser> and then execs upstart
<smoser> not all output from the forked process gets to the console.
<apw> smoser, so that forked process is opening and closing /dev/console repeatedly right (from a quick scan)
<smoser> in the one i attached, i made sure to close all filehandles of the forked pid.  but i've also tested without the closing of FDs (so that a handle on /dev/console would always be open) and got the same results.
<smoser> apw, yes.
<apw> so that will definatly hit the issue
<apw> you should try something like this
<apw> #!/bin/bash
<apw> (
<apw>  sleep 120 </dev/console
<apw> ) &
<apw> sleep 1; exec real
<apw> and see if that sorts it out
<smoser> i've basically tried that
<apw> you could also run your currnet debug as a third procerss to confirm it changes things if you get me
<smoser> that was my first incantination
<smoser> but in the existing one there, i tested without closing file descriptors
<smoser> and the forked process, would then inherit stdio, stdin, stderr from the parent
<smoser> and would, thus, keep a reference open
<apw> and the parent is connceted to console ?
<apw> you sure ?
<apw> thats why i am being explicit in opening the console
<smoser> ramdisks exec /sbin/init </dev/console > /dev/console 2>&1
<smoser> additionally, I *do* get the "hello world" from the parent to the console
<smoser> we get some output, then it goes away, then we get some more
<apw> well to avoid the race you have to keep it open
<apw> if its still going missing with a confirmed open then it may be a differnet bug
<smoser> well i that forked process does not close it, then it is kept open
<smoser> so if you imagine that script , but with the following line commented out
<smoser>   exec 1>&- ; exec 0<&-; exec 2>&-;
<apw> the example in there now does close them
<smoser> then the original fd is still open
<smoser> yes
<apw> right so the example there is useless for avoiding the issue
<smoser> i tested last night with that commented out also
<smoser> i can re-test that if you'd like
<apw> ok then next step ought to be to replace echo with a C program that records the real exit status of open etc and prints them to stderr
<apw> and retest ... we need to find out if open fails and if write fails and if close fails, and with what
<apw> for the one that goes missing
<apw> remembver to 2>>${out}
<apw> smoser, making sense ?
<smoser> well, i also have python tests (cloud-init) that tried open()
<smoser> and did never received failure
<smoser> but i will try with C
<smoser> ie, in cloud-init when it ran, i would loop over a try to open("/dev/console") and wait until it succeeded
<smoser> but i never saw failures
<apw> well i care not what you test with, but in that context where we see 1 2 4 i want to know if userspace was told there was an issue
<smoser> and i lost output
<smoser> right.
<smoser> so python was not
<apw> smoser, this is all in ec2 isn't it?
<apw> or kvm ?
<smoser> i can probably reproduce in a vm
<smoser> would you like me to try that ?
<apw> nope, i want to know where you are testing: "Where is this testing occuring?"
<smoser> actually, yeah, thats obviously important
<smoser> as they have different /dev/consoel implementations
<smoser> what i'm reporting is in ec2
<smoser> yes
<apw> so we have no real idea if we sent the data out or not
<apw> and ec2 is somewhat nebulous
 * apw has a look if we could log in the kernel
<Chipaca> has python-aptdaemon's api changed since lucid?
<apw> smoser, what device is console on in ec2?
<apw> smoser, and have you ever had a report of this outside ec2?
<smoser> i'm testing on eucalyptus (kvm) now. i dont recall having seen it outside ec2.
<smoser> console on ec2 is /dev/console, but i believe our kernel is patched so that hvc0 == /dev/console
<soren> Doesn't EC2 pass console=/dev/ttyS0 ?
<smoser> no. eucalyptus does
<soren> Or am I confused?
<smoser> i can check that, but i dont think so.
<smoser> we boot with pv-grub now, and our command line does not have that.
<smoser> but we specify it
<apw> smoser, what does cat /proc/cmdline say
<smoser> apw, we started seeing it reproducibly when 2 things changed.  a.) ramdisk b.) using pv-grub as the loader rather then xen loading the kernel.
<apw> smoser, so ... a lot has changed
<apw> and didn't you change kernels then too?
<smoser> yes.
<smoser> lots have changed. we changed from a 'linux-ec2' to a -virtual  kernel with pvops also
<apw> right so basicall we threw out the bathwater, baby, bath, and the house ... so it could be anything
<apw> so which console driver does it use in this mode#
<smoser> the console is always been the xen console
<smoser> /dev/hvc0
<apw> ok ....
<smoser> but no console= command line is passed
<apw> i am sure that /dev/hcv0 has changed between the kernels in quesion
<apw> i wonder if we can log what is trying to go out via it in dmesg so you can see if its getting that far
<smoser> lucid command line:  root=/dev/sda1 ro 4
<smoser> maverick command line: root=LABEL=uec-rootfs ro
<smoser> we can control the maverick command line
<apw> smoser, so you use -virtual yes ?
<smoser> we could not control it in lucid
<smoser> lucid uname: 2.6.32-308-ec2
<smoser> maverick uname: 2.6.35-21-virtual
<apw> smoser, so i think i could log everything sent out via the console say at debug level
<apw> else it would be recursive of course
<smoser> which woudl get to syslog ?
<apw> yeah it should i think
<smoser> hm.
<smoser> but that might not benefit us
<smoser> as syslog isn't going to be up until upstart starts it
<smoser> oh
<smoser> but there is that buffer for syslog
<smoser> right ?
<apw> yeah, it'd be in dmesg
<smoser> that would be useful i think
<apw> so we could use that to try and work out if its gets that low or not
<apw> of course i have no way to debug it
<apw> ie to test it before hang
<apw> hand
<slangasek> soren: ah, the networking job; yes, that could cause a problem, indeed
<smoser> apw, ok, so: http://paste.ubuntu.com/494225/ is console output (the most recent boot) with /sbin/init of http://pastebin.com/q7kE2bbf
<soren> slangasek: Ok, so if I want a bridge, br0, with a single attached interface, eth0, what's the correct configuration? Do I have an "iface eth0" stanza at all or do I just have an "iface br0" stanza with bridge_ports eth0? What about "auto br0" or "auto eth0"?
<smoser> for 6 seconds, output to stdout of that forked process went no where.
<smoser> it went to console, then disappeared for 6 seconds, then returned.
<apw> cjwatson, Keybuk, does plymouth do anything clever with console output while it is on the screen ?
<Keybuk> apw: lots
<Keybuk> it takes it and buffers it, and logs it, and redirects it
<Keybuk> and sometimes adds salt
<apw> Keybuk, as in /dev/console output ?
<apw> and if so, how is it getting in the stream ?
<Keybuk> ioctl
<apw> urgle so we have a period during boot on ec2 of about 6 seconds around when mountall says its running where there is a gap in console output
<apw> Keybuk, ^^ might that be expected behaviour with plymouth around
<Keybuk> err. not sure
<Keybuk> I don't think so
<Keybuk> does it go into /var/log/boot.log ?
<apw> smoser, ^^ ?
<andreserl> slangasek, howdy!! I talked to upstream about the soname changes in pacemaker, and well he pretty much told me that they are not guaranteed to change, because they will, but that doesn't happen very often (as in bumping versions)
<smoser> looking
<smoser> awesome
<smoser> the lost data (and only the lost data) is in /var/log/boot.log
<apw> Keybuk, so does that mean that plymouth was running during that period ?
<Keybuk> Isure
<apw> Keybuk, do we have any control over whether plymouth repeats its input to the real console, or is it gone while plymouth runs
<apw> gah wish i understood plymouth better
<Keybuk> yes, plymouth plugins dictate which does what
<cjwatson> plymouth's details plugin is supposed to repeat things to the real console
<cjwatson> (src/plugins/splash/details/plugin.c)
<apw> smoser, is your missin init script output in there?
<apw> as well as the debug?
<cjwatson> it may not display anything if it thinks it's waiting for the answer to a question
<smoser> apw, yes.
<smoser> its all there.
<smoser> cjwatson, where would i see an indication that plymouth would be waiting for an answer to a question ?
<Wubbbi> Hey guys. Can someone confirm the white screen that I get after logging in in uptodate Maverick Netbook? I cant use it anymore. Update on way?
<smoser> filesystem will be clean (pristine image boot)
<cjwatson> smoser: if it were, it ought to be the last visible line on the console
<apw> i can't think of any questions it migth be asking though it might be offering cancel for fsck's i guess ?  for the shortest time
<smoser> not htere.
<cjwatson> Wubbbi: you're not the first person to report that today, but I don't do any netbook work myself so I know no more than that
<smoser> not there.
<apw> and anyhow we lose it for 6 seconds which sounds likely to be 'all' of the time plymouth is active during a boot ?
<apw> peraps the repeating just isn't working, disabled perhaps
<Wubbbi> Hmmm ... ok. But you must understand, that I cant use my Netbook now anymore. Well I can go to init 3 and do updates but no working. Well I know its Beta. I just wanted to tell you that this is a emergancy issue! :)
<zyga> ubuntu just got first spam blueprint
<zyga> https://blueprints.edge.launchpad.net/ubuntu/+spec/new-background-ubuntu
<smoser> apw, i did sudo sh -c 'for x in /etc/plymouth*.conf; do mv $x $x.disabled; done'
<smoser> then reboot
<smoser> http://paste.ubuntu.com/494238/
<smoser> the console log now has everything
<ogra_ac> zyga, we have a ton of spam blueprints already
<ion> zyga: Thatâs not spam, itâs just trolling.
 * zyga didn't know
<apw> smoser, i think that points squarly at plymouth then, especially as it itself logs the missing data as well
<smoser> i think so too :)
<apw> Wubbbi, fingers are being point at a mesa update
<apw> Wubbbi, see discussion on #ubuntu-x
<Wubbbi> apw: Will this mesa update fix it or do you want to say that there is no time to fix the white screen issue?
<Wubbbi> Well even I want to thank you guys. I know more now ^^
<apw> smoser, so do we need plymouth at all ?
<cjwatson> $ ldd /sbin/mountall | grep libply
<cjwatson>         libply.so.2 => /lib/libply.so.2 (0x00742000)
<cjwatson>         libply-boot-client.so.2 => /lib/libply-boot-client.so.2 (0x009ec000)
<cjwatson> i.e. yes
<smoser> so, someone want to point me at plymouth where it should be repeating stuff to /dev/console ?
<cjwatson> I did above
<cjwatson> search back for 'details'
<tkamppeter> pitti, WDYT should we do with Epson then?
<sladen> jono: around?
<apw> smoser, do we even have a graphical display on an ec2 instance... is there any point in running plymouth at all ?
<smoser> no.
<smoser> other than the world depends on it.
<cjwatson> plymouth is what gives you boot logging
<cjwatson> it will be much easier to fix it than to excise it
<smoser> yeah. so looking.
<smoser> so anyone suggest why i would see this on ec2 and not on eucalyptus ?
<smoser> other than just unlucky timing ?
<james_w> juliank: hi, is it possible with python apt to find out /why/ the packages are broken if cache.broken_count > 0
<james_w> juliank: I've found how to find which packages are broken, but I'm confused as to why they are broken in this case
<juliank> james_w: Probably not via apt.* API, only via apt_pkg API.
<james_w> juliank: that's fine for now, I'm just debugging right how
<james_w> now
<james_w> I think it's to do with Provides, but I can't reproduce in a test case, so I'm a little lost
<james_w> thanks for writing the docs though, it's helped me get this far
<juliank> james_w: You have to go through the reverse dependencies and check for conflicts/breaks there and go through the installed version's dependencies and check which one is not installed.
<juliank> If you don't need code, running aptitude why/why-not might make more sense.
<james_w> juliank: I'm doing something similar to chdist, but with "install" functionality which pretends that particular packages are installed by writing them to /var/lib/dpkg/status
<james_w> juliank: it works in my tests, but using on the Ubuntu archive leads to broken packages after "installing" the packages and reloading the cache.
<james_w> I've printed out the Depends/PreDepends/Conflicts for each broken package, and checked them against what was installed, and it looks like virtual packages are the problem, as Provides isn't currently written to /var/lib/dpkg/status
<juliank> james_w: Then why not just write the provides?
<james_w> juliank: that's what I'm going to do, but I want a test case to confirm my hunch first
<bilalakhtar> iulian: pign
<dmart> Keybuk: hi--- not sure if you had a chance to look yet, but I had some thoughts on the rpc.statd issue
<bilalakhtar> *ping
<dmart> Keybuk: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/525154 if you want to take a look
<ubottu> Launchpad bug 525154 in nfs-utils (Ubuntu) "mountall for /var races with rpc.statd" [Undecided,Triaged]
<Keybuk> dmart: it's not something I'm particularly looking at
<apw> cjwatson, if during a dist-upgrade a package is held back ... how do i find out why its held back
<dmart> Keybuk: any idea who is?  I think you and slangasek were the main people to have commented...
<Keybuk> I don't think anyone is
<apw> cjwatson, ahh found it, the armel binaries are still in binary new .... i wonder if we could tickle those
<dmart> Keybuk: it does look like it bites people using a resonably common server configuration, though I can work around it for myself
<dmart> My concern was around the fact that it seems impossible to express the correct start conditions for statd in upstart, and that this limitation may be affecting other things too.
<slangasek> soren: for a bridge, I don't know that you need any 'iface eth0' stanza at all; the 'iface br0' + 'bridge_ports eth0' + 'auto br0' seems to be enough, unless your eth0 needs other configuration
<Keybuk> dmart: it may indeed be impossible with the current upstart
<juliank> james_w: I have to be away for ~ 10 minutes now
<ogra_cmpc> lets switch back to sysvinit then
<ogra_cmpc> its still time before release :P
<slangasek> andreserl: so that means your package name for all of libpacemaker would need to change for each of those soname changes, and Conflict: with the prior package name; not pretty, but seems to be the best option
<Keybuk> ogra_cmpc: <censored reply>
<ogra_cmpc> heh
<slangasek> andreserl: in that case I think you should get a serial included in the libpacemaker package name up front (e.g., libpacemaker0 or libpacemaker1; doesn't matter what)
<Keybuk> though
<Keybuk> I can't possibly be upset today
<Keybuk> today is a GOOD DAY
<Keybuk> http://lists.fedoraproject.org/pipermail/devel/2010-September/142858.html
<dmart> Keybuk: anyways, there are some thoughts from me in the bug thread about how the problem could be solved ... but unfortunately I don't really have time to try it out just now, I just hit it as a side-issue.
<Keybuk> jonmasters: how the hell did that summon you? :p
<ogra_cmpc> poor lennart
<ogra_cmpc> heh
<slangasek> dmart: rpc.statd> on my list, I guess; though I don't know that I'm going to be able to get anywhere with really solving the outstanding nfs-utils upstart bugs until the new upstart features land
<ogra_cmpc> Keybuk, did you tell him that we are hiring an OO.o maintiner ? *g*
<ogra_cmpc> in case he wnats to leave fedora
<Keybuk> we could do with a pulse audio maintainer
<ogra_cmpc> we surely could, yeah
<dmart> slangasek, Keybuk: is there a wiki / tasklist for upstart features I could look at?  I'd be interested
<Keybuk> dmart: nope
<dmart> oh well
<james_w> juliank: I'm not seeing any way to get the Provides information for a given package, is there one?
<james_w> oh, provides_list in apt_pkg seems to be it
<andreserl> slangasek, the other option would be to move them back to pacemaker package itself, since those libraries are only for pacemaker itself
<slangasek> andreserl: if they're only for pacemaker, why were they split out at all? I thought this was because they would be dependencies of redhat-cluster?
<apw> slangasek, you wouldn't be able to stroke a linux through binary new would you?  armel only seems to be caught there
<andreserl> slangasek, right now, redhat-cluster depends on pacemaker-dev (I just checked), so the split was to make them dependant on libpacemaker-dev
<andreserl> slangasek, either way, we'll be disabling pacemaker's support in redhat-cluster given that cluster-glue won't be in shape, so I'd rather have redhat-cluster without pacemaker's support to not FTBFS
<slangasek> apw: yes, will grab it this morning
<slangasek> andreserl: so, I guess I don't understand the point of splitting pacemaker-dev and having redhat-cluster build-depend on libpacemaker-dev, if it wasn't going to use the libs
<ogra_cmpc> i dont get why armel is the only arch hanging there
<slangasek> seems like a pointless split to me
<ogra_cmpc> the i386 and amd64 binaries seem to not have that issue
<apw> slangasek, that being there looks to be breaking upgrades, and i'd like to know it is only that ... as we'd like to fold any fix into todays upload which was planned for a couple of hours
<NCommander> cjwatson: kirkland: ping, I need your archive foo: can you please release the linux/armel binaries?
<juliank> james_w: Yes, Package.provides_list [which versions provide this package] always works (and for the opposite view [what does this version provide] Version.provides_list)
<andreserl> slangasek, the idea was to make the package policy compliant for the libraries to get the MIR accepted, but since we are almost in FinalFreeze and unfortunately who's working on cluster-glue couldn't make it on time, we are also dropping pacemaker's support for RCHS
<RoAkSoAx> slangasek: /win 6
<james_w> juliank: yeah, the latter is what I wanted, thanks. It indeed fixes the problem, but I have no idea why I can't reproduce it in a test case yet
<RoAkSoAx> ups
<ogra_cmpc> NCommander, that was discussed ten mins ago
<slangasek> andreserl: well, I don't think the changes that were made here have any bearing on policy compliance
<jonmasters> Keybuk: explain summon me?
<andreserl> slangasek, we wanted to separate the libraries from the binaries
 * ogra_cmpc suggest to read backlog to NCommander before asking questions ;)
<slangasek> especially creating a libpacemaker-dev package that will be used as a build-dependency for only one package that doesn't use the libs
<Keybuk> jonmasters: I pasted a fedora-devel-list mail url and you literally appeared straight after
<slangasek> andreserl: which, unless it's done in a forwards-compatible way, is worse than /not/ splitting it
<slangasek> apw: accepted
<jonmasters> Keybuk: oh weird, maybe my client temporarily lost connection
<dpm> hi pitti, is there any way to see if the language packs are building? I'm looking here: https://edge.launchpad.net/ubuntu/+builds?build_text=language-pack&build_state=all, but I don't see any and I'm not sure if there is a better way to find out
<jonmasters> Keybuk: I got a text message though when you mentioned my name ;)
 * NCommander hides his head
<andreserl> slangasek, I agree, I now know that each library should have been split in their own package if we wanted to do the split, but now that I've talked with usptream about this, it's agreed that those libraries are only used by pacemaker and there would be no need to spliut the packages
<apw> slangasek, thanks you are a star, its all frantic over here
<pitti> dpm: lemme check
<slangasek> andreserl: great, sounds like we're now on the same page then :)
<pitti> dpm: hm, they were built, but upload failed
<pitti> KeyError: 'getpwuid(): uid not found: 2009'
<andreserl> slangasek, :). I'll roll back the changes and do a new upload
<pitti> hmm
<kirkland> NCommander: looking ....
<pitti> dpm: uploading now
<pitti> dpm: weird, it works when I run it manually, but not from cron
<dpm> pitti, ok thanks
<apw> does anyone know if i can rely on these two version number comparing equal: 2.6.35-22.11 2.6.35-022.11
<juliank> apw: The 0 is dropped, so yes.
<apw> thanks
<juliank> apw: That also means: "1.0-0" = "1.0" = "1." = "1.-0" = "1.-"
<Keybuk> errrrr
<Keybuk> that's wrong
<apw> juliank, are you sure about that
<apw> i don't read the explanation as saying that at least
<tumbleweed> he definitly is :P
<Keybuk> it's correct that -22.11 and -022.11 are equivalent
<apw> i see it saying that they are compared numerically, but that only the empty string at the end can be compared as 0
<Keybuk> but 1.0-0 and 1.0 are NOT equivalent
<Keybuk> neither are 1. and 1.0
<tumbleweed> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
<juliank> Keybuk: They are
<apw> 022 and 22 are both converted to 22 arn't they
<Keybuk> no they're not
<Keybuk> I wrote the current edition of the code in dpkg
<Keybuk> I'm pretty sure I know of what I speak
<smoser> $ dpkg --compare-versions 1.0-0 eq "1.-0" && echo y
<smoser> y
<juliank> Keybuk: Try it yourself.
<smoser> that is the definitive guide
<juliank> jak@jak-thinkpad:~$ dpkg --compare-versions 1.0 eq 1. && echo y
<juliank> y
<Keybuk> huh
<Keybuk> someone's changed it then
<Keybuk> because they shouldn't be
<apw> that doesn't match the description in the policy manual for sure
<Keybuk> 1.0-0 and 1.0 are different bases, one has a revision, one doesn't
<juliank> Keybuk: It's valid according to the policy
<apw> Then the initial part of the remainder of each string which consists entirely of digit characters is determined. The numerical values of these two parts are compared, and any difference found is returned as the result of the comparison. For these purposes an empty string (which can only occur at the end of one or both version strings being compared) counts as zero.
<apw> ^ from the policy
<juliank> 0 means empty string. No revision means empty revision string => 0 revision is equal to no revision
<apw> i'd say that says that the empty string should only compare at the end of the string
<Keybuk> right, you're not supposed to insert arbitrary empty in there
<juliank> Keybuk: Also, Policy states "The absence of a debian_revision is equivalent to a debian_revision of 0"
<apw> i am not sure from the policy how they should compare of course
<Keybuk> I guess 1.-0 comes out as
<Keybuk> <1><.><0><-><0>
<Keybuk> where the 0 gets implied, but dpkg never behaved that way
<Keybuk> does look like someone's tried to match the two together
<juliank> Keybuk: In practice, 1.0-0 becomes "1.-" in the parser, as it drops 0 at the beginning
<apw> then the parse definatly does not implement the words in the policy
<apw> regardless of which makes more sense
<lamont> Keybuk: there was a policy change recently that made 1.0 == 1.0-0
<juliank> apw: It does effectively. You can strip any zeros in front of a number without modifying the numbers value.
<lamont> for some value of recently
<Keybuk> juliank: you can strip zeros, yes, but you can't strip all zeros
<Keybuk> you're only supposed to strip from the beginning and end of the string, not in the middle
<juliank> Keybuk: Yes, it just strips those in front of a digit sequence.
<Keybuk> otherwise you could end up with 1.0.0-0 becoming 1..-
<Keybuk> juliank: that's wrong, then
<juliank> Keybuk: 1.0.0.0-0 is 1..-
<Keybuk> juliank: it *shouldn't* be
<Keybuk> go read policy carefully
<apw> the policy does tell you that it should only occur at the end of the string
<Keybuk> because then madness ensues
<apw> but it also doesn't tell you how to compare 1.. and 1.0.0
<sladen> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version  for reference, since I happened to paste it somewhere else a minute ago
<andreserl> slangasek, btw, can you please take a look to bug #527195 and leave your comment on the library split, as we are going to retarget it for natty? :) Thank you!
<ubottu> Launchpad bug 527195 in pacemaker (Ubuntu) "[MIR] pacemaker" [Undecided,Incomplete] https://launchpad.net/bugs/527195
<juliank> Keybuk: or not, but that seems to be a bug
<apw> sladen, yep same as whats in the ubuntu policy manual which leaves it undefined by stating it cannot occur
<juliank> Keybuk: OK, you're right in this point.
<Keybuk> this is deeply digressing from the fact that 22 and 022 are always equivalent in dpkg, of course
<juliank> 1.0.0.0-0 is not 1...
<apw> Keybuk, yeah, i may want to rely on that
<juliank> -
<Keybuk> apw: you certainly can rely on that
<apw> Keybuk, thanks for that
<apw> interestingly the policy does not say strip the 0's simply that a string of digits is copared using its decimal value
<juliank> Keybuk: The most straight-forward implementation of policy is http://git.debian.org/?p=users/jak/apt2.git;a=blob;f=systems/deb/debversion.c;h=07575615e9bfb60ab4627ba6ab65dbe4e535baf0;hb=HEAD (it's closer to the wording than dpkg's one, but yields the same results)
<MIH1406> Hi, I want to get a degree in programming what is the best program for that? "Computer Science", "Software Engineering" or what?
<juliank> (I wrote it because I wanted an LGPLed codebase)
<dpm> pitti, quick question: on bug 66550, can you think of anything obvious that might be missing in order to let the language entry appear in the gdm menu?
<ubottu> Launchpad bug 66550 in Ubuntu Translations "Yoruba language not shown in gdm menu" [Medium,Triaged] https://launchpad.net/bugs/66550
<juliank> And it behaves identically compared to APT when comparing all versions in Debian unstable against each other (although a bit faster)
<pitti> dpm: does that still happen? this obviously was reported against the old gdm (2.20 and earlier)
<pitti> dpm: otherwise no, I don't know off-hand how gdm reads the langauge list
<dpm> pitti, the original reporter said that this is still happening in maverick. In any case, I just wanted to know if it might be something obvious. Thanks
<pitti> dpm: looking at gui/simple-greeter/gdm-languages.c, it seems to read the available locales
<pitti> i. e. it should be in locale -a
<pitti> more precisely, it's parsing /usr/lib/locale/locale-archive, but so does locale -a
<dpm> pitti, ok, thanks. I'll try to install yoruba and see what happens  then
<pitti> good night everyone!
<dpm> night pitti!
<iulian> bilalakhtar: What can I do for you?
<iulian> bilalakhtar: Just to let you know, I usually don't respond to contentless pings.
<bilalakhtar> iulian: bug #639631
<ubottu> Launchpad bug 639631 in gworldclock (Ubuntu) "[FFe] Please merge gworldclock 1.4.4-9 (universe) from Debian unstable (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/639631
<bilalakhtar> since a user just asked for the fix, sorry
<bilalakhtar> the fix which is in that merge
 * iulian looks.
<bilalakhtar> was trying to save time and avoid tomorrow's freeze
<bilalakhtar> since the merge is ready
<bilalakhtar> just needed that exception
<iulian> bilalakhtar: Approved.  Please upload.
<bilalakhtar> Thank a lot, iulian !
<iulian> No problem.
<Keybuk> juliank: http://bazaar.launchpad.net/~ubuntu-core-dev/merge-o-matic/trunk/annotate/head:/deb/version.py
<Keybuk> I wrote that ages ago ;P
<Chipzz> Keybuk: I was reading your explanantion about upstart yesterday, and tbh, that looks pretty bad
<Chipzz> I mean, assuming that a service will start when you run "start service" is not unreasonable
<Chipzz> but apparently that's a broken assumption?
<Chipzz> I think that will come as a very big surprise to a lot of sysadmins...
<Keybuk> well, it is a bug
<andreserl> slangasek, btw.. just uploaded a new pacemaker rev rolling back the library split. Thanks for the help :)
<jdstrand> cjwatson: are you a moderator for technical-board@? I sent something a couple of days ago, but was told 'Post by non-member to a members-only list'
<jdstrand> cjwatson: if so, would you mind approving it?
<jdstrand> cjwatson: and hi btw :)
<Chipzz> Keybuk: are there any plans to fix the upstart design in that regard?
<Keybuk> yes
<Chipzz> great :)
<slangasek> andreserl: followed up on bug #527195
<ubottu> Launchpad bug 527195 in pacemaker (Ubuntu) "[MIR] pacemaker" [Undecided,Incomplete] https://launchpad.net/bugs/527195
<andreserl> slangasek, thank you! :)
<zedtux> Hello all, I'm trying to package into a Ubuntu/Debian package my python app. The package generation work fine, but the package install my app in /usr/lib/python2.6/site-packages/ instead of /usr/lib/python2.6/dist-pacakges
<zedtux> I don't really know how to fix it. I already have try with --install-layout=deb, that install my app with the python setup.py install, but package continue to install in site-packages...
<zedtux> I've followed the guide https://wiki.ubuntu.com/PackagingGuide/Python
<zedtux> and I'm using ubuntu 10.10
<zedtux> help ? :)
<mathiaz> Is there an automated way in LP to ask for no-op package rebuild (ie to pick a newer .so library)?
<mathiaz> Or the package still need to be uploaded to LP?
<mathiaz> SpamapS: ^^
<iulian> zedtux: Hi there.  I believe that #ubuntu-packaging is a better place to ask such questions.  #debian-python on OFTC is also a great place for Python packaging.
<zedtux> Thanks you iulian for your answer :)
<iulian> You're welcome.
<SpamapS> mathiaz: as long as you're looking for stuff to sponsor.. bug 638401 would be a good one. :)
<ubottu> Launchpad bug 638401 in php5 (Ubuntu) "automated tests run during build fail due to apparmor protections for mysqld unless build is done in /tmp" [High,Triaged] https://launchpad.net/bugs/638401
<soren> slangasek: Ta very much.
<smoser> cjwatson, around ? I have an understanding of what was going on with my console bug, and wanted some plymouth advice.
 * slangasek waves the plymouth flag
<slangasek> soren: so does that /work/, or are you thanking me for confirming the nature of a bug? :-)
<soren> slangasek: The latter.
<soren> slangasek: He destroyed the evidence. He reinstalled and stuff works now.
<soren> slangasek: So we'll never know what was wrong. I just wanted to make sure he was doing things by the book before we started ripping everything apart to find the problem.
<SpamapS> mathiaz: why did you mark bug 620441 as in progress again? Its awaiting sponsorship.
<ubottu> Launchpad bug 620441 in mysql-dfsg-5.1 (Ubuntu Maverick) "MySQL upstart stop job does not cleanly shutdown mysql" [High,In progress] https://launchpad.net/bugs/620441
<mathiaz> SpamapS: yeah - it's in progress
<mathiaz> SpamapS: IIRC it was in triaged
<mathiaz> SpamapS: I'm currently building mysql
<SpamapS> mathiaz: with UDD, should we leave the bug assigned to ourselves even after the merge proposal?
<mathiaz> SpamapS: I think so
<mathiaz> SpamapS: as you did most of the work
<mathiaz> SpamapS: it also shows that you're responsible for getting the bug to a 'Fix released' state
<slangasek> soren: ah, ok
<SpamapS> with "old style" sponsorship, I would  unassign and mark confirmed
<mathiaz> SpamapS: doing the sponsorship is secondary and IMO shouldn't change bug assignement
<SpamapS> mathiaz: I like it, and will change my procedure from now on.
<SpamapS> mathiaz: I will be offline for a couple of hours, anything else before I go?
<slangasek> smoser: that plymouth flag was waved for your benefit, fwiw :)
<kenvandine> lamont, could you please rescore https://edge.launchpad.net/ubuntu/+source/ubuntu-netbook-default-settings/0.8.6/+build/1961558
<smoser> slangasek, thanks
<smoser> :)
<smoser> funny
<kenvandine> it is the work around for the mesa bug/train wreck breaking UNE
<smoser> well, here, let me hit 'submit' on this bug and point you at the comment.
<smoser> slangasek, https://bugs.edge.launchpad.net/ubuntu/+source/cloud-init/+bug/606373
<ubottu> Launchpad bug 606373 in linux (Ubuntu Maverick) "cloud-init output does not get to console when booted with pv-grub and ramdisk" [High,Confirmed]
<slangasek> smoser: ah; can't provide any specific advice there. You've looked at the code?
<smoser> a bit. i see where it is looking at console= and doing things based on that.
<slangasek> smoser: I'm wary of trying to use "/dev/console" in place of a specific device, ISTR there are special semantics involved there - but Keybuk is the expert
<smoser> i was hoping that i could tell 'details' plugin that 'hey, even though i didn't put console= on the command line, i'd still like to see details'
<smoser> :)
<slangasek> oh, by default (on a system with fbcon), you get the details without having any explicit console= line
<slangasek> so that's not the issue per se
<slangasek> but it does this by sending it to a vt, and you definitely don't have vts here...
<smoser> i have to look more at that.
<achiang> mathiaz: did you ever figure out your LP "no-op rebuild" question?
<achiang> mathiaz: i'd like to be able to do that too occasionally
<SpamapS> seems to me that LP could simply trigger noop rebuilds whenever a new version of a -dev lib is uploaded.
<smoser> SpamapS, in a perfect world, yes.
<smoser> in one with limited hardware, hm...
<achiang> i wouldn't mind a manual process, but afaik there's simply no way to do it without bumping the package version and doing a new upload
<smoser> slangasek, well, it looks like i can run plymouthd with --tty=<string>
<slangasek> smoser: sure; but that hardly seems better / more maintainable than setting console= on the kernel commandline
<smoser> right.
<smoser> and i doubt that i can specify (and have it work) --tty=/dev/console
<smoser> as it is trapping /dev/console.. might go recursive
<smoser> thanks for help, slangasek
<slangasek> smoser: but --tty=/dev/hvc0, maybe?
<smoser> yeah, but no better as you said.
<smoser> and then, its hard coded in the image and wouldn't work for uec (where i want tty=ttyS0)
<smoser> so, i think i'm going to have to boot with console=hvc0
<smoser> that, or, mv /etc/init/plymouth.conf /etc/init/plymouth.conf.disabled
<smoser> (which does work in both places)
<cjwatson> jdstrand: done
<jdstrand> cjwatson: thanks!
 * cyphermox goes back home
<SpamapS> mathiaz: have you had more time to think about libdbi?
<tkamppeter> Can someone check the upload server upload.ubuntu.com? I get always [Errno 111] Connection refused. Worked half an hour ago.
<TheMuso> tkamppeter: Just trying to upload packages now, and I get the same thing.
<TheMuso> Oh well, I'll just get all the packages I need to upload into a queue dir.
<tkamppeter> TheMuso, I need to upload a package still before Final Freeze.
<TheMuso> So do I.
<Laney> are you guys trying ftp or sftp or both?
<TheMuso> ftp
 * Laney will try sftp
<ajmitch> otherwise it's emergency LP ping time?
<tkamppeter> I use dput. Do not know what dput uses.
<Laney> dput uses whatever your configuration tells it to
<Laney> ftp by default
<TheMuso> dput uses ftp by default.
<Laney> Unable to connect to SSH host upload.ubuntu.com; EOF during negotiation
 * Laney tries ppa.lp
<mathiaz> SpamapS: hey - yes
<mathiaz> SpamapS: so I'd lean towards not doing anything for maverick for the following reasons:
<mathiaz> SpamapS: 1. if we'd updated libdbi we'd have to rebuild a set of packages
<mathiaz> SpamapS: and that would increase our delta with debian
<tkamppeter> Upload server returned to work. Upload successful.
<mathiaz> SpamapS: 2. Nothing is broken in the archive now
<Laney> I wonder what I just uploaded to Â¬_Â¬
<mathiaz> SpamapS: so the tradeoff is that we may break 3rd party apps
<SpamapS> mathiaz: the delta with debian is temporary. I've been working heavily w/ the maintainer, and he's ready to import what we do.
<mathiaz> SpamapS: that would mostly be server side apps
<mathiaz> SpamapS: are you refering to the libdbi maintainer?
<SpamapS> Yeah, Thomas Goirand
<mathiaz> SpamapS: because if we rebuild all other packages, we'd *also* have to get their respective debian maintainers
<psusi> cjwatson, hey!  looks like debian fixed the dmraid issue, AND the memory leak: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594221
<ubottu> Debian bug 594221 in grub-common "Broken DMRAID support in grub-probe" [Important,Open]
<mathiaz> SpamapS: so I'd suggest we wait for the transition to happen in Debian
<mathiaz> SpamapS: 3. we're a bit too late in the release cycle for maverick
<mathiaz> SpamapS: we'd have to test that all rebuilds would actually work
<SpamapS> Can we expect it to go into maverick.1 ? Or is this going to have to be a backport?
<SpamapS> I think 3rd parties will accept the backport
<mathiaz> SpamapS: there isn't any maverick.1 - or are you refering to natty?
<SpamapS> mathiaz: I already tested all of the rebuilds
<SpamapS> but I agree
<SpamapS> its late
<SpamapS> archive is not "broken"
<mathiaz> SpamapS: yeah - if we were earlier in the cycle I'd sponsor it.
<SpamapS> Would be awesome if we could have both (libdbi-dev and libdbi0-dev) available so at least developers could choose.
<mathiaz> SpamapS: but IMO we're a bit late for the maverick cycle
<SpamapS> Realistically though...
#ubuntu-devel 2010-09-16
<SpamapS> Its only going to affect people who have built against 0.8.2, and use the error enums, and then move their app directly to maverick without recompiling.
<mathiaz> SpamapS: if they recompile on maverick it wouldn't be broken?
<SpamapS> nope
<SpamapS> It will be fine because maverick has 0.8.3
<mathiaz> SpamapS: so IOW the only broken use case is: a 3rd party app built on lucid wouldn't work on maverick?
<SpamapS> What won't be fine is if there's somebody mixing debian/backports.org/ubuntu packages and they end up depending on libdbi0 from squid (0.8.2) and then try to use it on ubuntu.
<SpamapS> s/squid/squeeze/
<SpamapS> right, app from lucid that uses the error enums will break on maverick
<SpamapS> or likewise, an app compiled on maverick that uses the enum will break on lucid
<SpamapS> its just a confusing situation
<SpamapS> The fear I have is that the breakage will be *really* subtle
<mathiaz> SpamapS: right - so I lean towards not updating the libdbi package in maverick and add a release note
<SpamapS> its not a missing symbol, its a missing constant value.
<SpamapS> so like, your app from maverick goes  if error == XYZ ...   you'll never match that value if you install the package on lucid
<mathiaz> SpamapS: ok - let's explore the other solution.
<mathiaz> SpamapS: all the packages required to be rebuilt are ready?
<mathiaz> SpamapS: how did you rebuilt them?
<SpamapS> ppa
<SpamapS> ran test suites where available too
<mathiaz> SpamapS: ready == the source has been modify to use libdbi-dev instead of libdbi0-dev?
<SpamapS> yeah
<SpamapS> I held off pushing for merge proposals until we decided what to do in maverick.
<mathiaz> SpamapS: do you have the PPA url?
<SpamapS> hrm.. I must have deleted the packages.. it was in https://edge.launchpad.net/~clint-fewbar/+archive/fixes/+packages
<SpamapS> rrdtool is still there though
<SpamapS> mathiaz: I wasn't very scientific about it I guess. ;)
<mathiaz> SpamapS: do you still have the source packages somewhere?
<mathiaz> SpamapS: IIRC it's possible to copy src package from PPA to the primary ubuntu archive
<SpamapS> mathiaz: what about having a new source package called libdbi084 that adds libdbi-dev to the archive...
<mathiaz> SpamapS: hm - that's too complicated
<mathiaz> SpamapS: if you still have all the source packages, I could sponsor them easily
<SpamapS> mathiaz: I always tack on ~ppa so that wouldn't work. but let me find the dir with all of them
<SpamapS> mathiaz: only rrdtool is in main
<mathiaz> SpamapS: given that you've already tried to the rebuild and tested them in the PPA that's a good thing
<SpamapS> though libdbi-drivers is supposed to be in main too and hasn't seeded yet
<mathiaz> SpamapS: has the MIR been approved?
<SpamapS> mathiaz: long ago.. just never seeded
<mathiaz> SpamapS: ok - I can do that too - is there a bzr branch to sponsor somewhere?
<SpamapS> mathiaz: its not Depended or Recommended by any main packages.. sort of a weird seed because libdbi is useless without them.
<SpamapS> why yes there is..
<SpamapS> https://code.edge.launchpad.net/~clint-fewbar/ubuntu-seeds/platform.maverick-add-libdbi-drivers
<SpamapS> I can propose for merging if need be
<mathiaz> SpamapS: I'll merge your branch
<SpamapS> mathiaz: if you look, there are already some branches linked to the bug report for the dependent packages
<SpamapS> mathiaz: crap.. I'm at starbucks and they seem to be blocking port 21. weird.
<mathiaz> SpamapS: so my proposal is to leave things as it is for maverick on libdbi
<mathiaz> SpamapS: and may be a release note
<mathiaz> SpamapS: I'm merging the libdbi-driver seed change
<SpamapS> mathiaz: I think thats 100% reasonable
<SpamapS> mathiaz: I think a release note in the "known issues" is definitely a good idea.
<SpamapS> mathiaz: lets leave it at that. Do I need to contact somebody about the release note?
<mathiaz> SpamapS: I'll open a task against the release-note project
<mathiaz> SpamapS: I'd suggest to update the description of the bug with a section outlining the release note to be added
<psusi> final freeze is in effect isn't it?
<mathiaz> SpamapS: once the release notes are being prepared the release manager will just need to copy'n paste the note for the bug
<SpamapS> soon
 * psusi hopes he can get this fix applied in time so mav doesn't ship with broken dmraid support
<SpamapS> mathiaz: ok, I'm satisfied that we've exhausted all avenues. ;)
<SpamapS> mathiaz: and actually I prefer this route, as it means we can just pursue this in Debian directly and get rid of any delta.
 * mathiaz nods
<mathiaz> SpamapS: we should revisit that for natyy
<mathiaz> SpamapS: natty
<mathiaz> SpamapS: given that squeeze is frozen it may take some time until Debian is released
<mathiaz> SpamapS: so if it's really important we may wanna schedule to do it in natty
<mathiaz> SpamapS: doing the work in Debian is also a very good option - there is not guarantee that it will be done in time for natty though
<SpamapS> mathiaz: *ugh*
<TheMuso> psusi: Let me know if you need a sponsor.
<SpamapS> We can at least get it into experimental
<SpamapS> so the devs can just bump those packages to unstable whenever they're comfortable.
<mathiaz> SpamapS: right - that's a good option.
<SpamapS> mathiaz: thanks for working through it with me. I'm sure we'll get it right for natty. :)  Should we remove the server-mrs tag?
<mathiaz> SpamapS: I'm doing something similar with the puppet package
<mathiaz> SpamapS: where the version in maverick is the actually the one from experimental
<psusi> TheMuso, actually I was noticing you do work on... wait, I might be thinking dmraid?  grub needs a patch to fix its brokeness for dmraid that developed during mav cycle... finished building now with debian's patch, going to boot live usb, install new package, and test installing now
<mathiaz> SpamapS: yes - I've also opened a task against the ubuntu-release-notes project
<SpamapS> mathiaz: I think when debian is in freeze, thats going to be a common thing.
<TheMuso> psusi: ok
<JanC> psusi: is that related to the naming of dmraid devices?
<psusi> TheMuso, but so far, looks like grub-pc is returning the correct results... and this patch also fixes those ANNOYING memory leak warnings ;)
<psusi> JanC, yes...
<psusi> it was looking for a device name containing mapper/ but the name gets canonicalized to dm-x
<TheMuso> lovely
<psusi> going to go test a new clean install using it now... bbiab
<mathiaz> SpamapS: https://code.edge.launchpad.net/~clint-fewbar/ubuntu-seeds/platform.maverick-add-libdbi-drivers
<mathiaz> SpamapS: ^^ I've merged the diff
<mathiaz> SpamapS: so you can update your branch accordingly.
<SpamapS> mathiaz: :-D cool
<SpamapS> mathiaz: I've been trying to keep all my branches marked accurately... they stack up quick. ;)
<mathiaz> SpamapS: yop - OTOH that gives you a lot of LP karma :)
<SpamapS> mathiaz: I should throw a party when I get to 10,000
<SpamapS> OK I have to run..
<SpamapS> mathiaz: thanks again, ttyl!
<mathiaz> SpamapS: sure!
<psusi> damn.... grub-install works fine now, but for some reason ubiquity says it fails.... updating daily iso and retrying
<psusi> it also says it is running it on /dev/sda the first time despite the fact that I told it to use the raid
<TheMuso> Yay dmraid. I am glad I don't deal with that garbage any more. :p
<psusi> heh, I'm using lvm to hold various install volumes that are split and I sometimes migrate across the dmraid disks, the ssd, and the 1.5 tb monster drive now ;)
<psusi> btw, has anyone figured out how to deal with the very annoying massive slow down of dpkg due to ext4 being retarded issue yet?
<TheMuso> Probably, I haven't investigated personally.
<psusi> alright, it works... once I installed the updated grub package both on the livecd and on the target during the install
<psusi> though ubiquity still claims it is installing grub to sda when it isn't
<TheMuso> interesting.
<psusi> so... what do I need to do now to get bug #634840 sponsored? ;)
<ubottu> Launchpad bug 634840 in grub2 (Ubuntu) "grub does not detect partitions properly on DMRAID" [Critical,In progress] https://launchpad.net/bugs/634840
<TheMuso> Ah if the bug is in grub2, then I feel a little less comfortable in touching the grub2 packaging...
<psusi> k... I'll have to poke cjwatson then
<TheMuso> I also dare say that that will be able to get in post freeze.
<psusi> do I need to do anything with the bug report?  like assign it to him?  or subscribe the release team or anything?
<TheMuso> Even going by the one line description.
<TheMuso> I'd have to read the docs to be sure, so no idea sorry.
 * TheMuso has done it before in previous releases, but can't remember.
<TheMuso> Probably a procedure similar to feature freeze exceptions.
<psusi> that bloody memory leak message has been in there since lucid was released hasn't it?  bloody annoying thing... nice that this patch fixes that too
<psusi> hrm... what now?  ureadahead?  e2defrag?  hrm...
<psusi> cjwatson, when you wake up, take a look at bug #634840.  Patch attached from debian, tested well for me, fixes dmraid issue, as well as the annoying memory leak that has been there since lucid
<ubottu> Launchpad bug 634840 in grub2 (Ubuntu) "grub does not detect partitions properly on DMRAID" [Critical,In progress] https://launchpad.net/bugs/634840
<TheMuso> s/c
<josh_> This room is out of hand.
<crimsun_> TheMuso: are you also merging in the latest stable-queue bits from pulse for upload?
<TheMuso> crimsun_: took care of them yesterday when I uploaded pulse.
<crimsun_> TheMuso: great!  thanks
<TheMuso> np
<Wubbbi> Hey guys. I found a strange bug. I use a netbook with broadcom Wifi and it realy works good. But now the problem. When I'm in Batterie mode ( even if the batterie is very very full ) my Wifi speed is like 3,4kb/s ... it takes 5 minutes to load google.com. In Lucid I dont have any problems. Well when I put in my Charger, the Wifi connection speeds up to normal speed. I dont have to reboot, no reconnect. I just put it in and its fast as
<Wubbbi> normal. When I put it out again, the connection slows down. Can you guys take a look on it? I even can give you more information!
<pitti> Good morning
<tkamppeter> pitti, morning.
<smb> pitti, Morning. I hate to ask but could we at least move the kernel stuff in Karmic-proposed into updates, even though the four reports also got no verification after 21 days?
<pitti> hello tkamppeter
<pitti> smb: hm, I'd like to see at least one report that it actually works
<smb> *sigh* yeah
 * smb hates those lazy buggers
<tkamppeter> pitti, I got everything into Maverick except the auto-download for the Epson drivers, but there it seems that I have to tell Epson that I asked the Ubuntu developers for including it but there was not enough man power to implement it.
<pitti> tkamppeter: right, unfortunately :/
<pitti> tkamppeter: after next UDS I'll be back and can spend some time on that
<tkamppeter> pitti, should we leave it as a bug report/feature request or should I create a blueprint/UDS session with apt and seurity people invited?
<pitti> tkamppeter: from my POV the bug is fine; I don't think there's need for further discussion, it's a SMOP now
<tkamppeter> SMOP?
<pitti> but if you prefer a blueprint for tracking, that's fine
<pitti> tkamppeter: "simple matter of programming"
<tkamppeter> pitti, OK. So no blueprint.
<tkamppeter> pitti, I think so, too. We have done all agreements with our security people, the LF, and the manufacturers, and the server side is completely implemented.
<tkamppeter> Tpitti, the thing was only that I do not have the knowledge to implement the client side and the person(s) with the knowledge did not have the time.
<tkamppeter> s/Tpitti/pitt/ ^^
<tkamppeter> pitti, I was so much behind this Epson thingy because Epson people were pressurizing, and I also wanted to turn a project into live I worked a longer time on, and I hoped by showing off the Epson auto-download in Maverick, the other manufacturers and also the other distros will quickly follow.
<pitti> mvo: can you please upload the fix for bug 633967 to maverick ASAP? this blocks the lucid SRU
<ubottu> Launchpad bug 633967 in apt (Ubuntu Maverick) "apt-ftparchive generates corrupt Sources stanzas for .dsc files without Checksums-* fields" [Critical,In progress] https://launchpad.net/bugs/633967
<pitti> tkamppeter: don't worry, the next Ubuntu release will come :)
<pitti> kirkland: can you please upload the fix for bug 590929  to maverick, so that the lucid SRU can go to -updates?
<ubottu> Launchpad bug 590929 in eucalyptus (Ubuntu) "[SRU] eucalyptus create and delete volumes sometimes fail on lvm commands (POC + ENT configs)" [Medium,Confirmed] https://launchpad.net/bugs/590929
<tkamppeter> pitti, at least I could cater for Ricoh: PPD selection sensitive to presence of PostScript add-on installed in printer and much faster PPD search and package download/installation.
<mvo> pitti: hm, that should be in already, let me check
<mvo> pitti: not sure why the bug was not auto-closed
<pitti> mvo: LP doesn't currently auto-close bugs
<pitti> if it was fixed only recently
<mvo> pitti: aha, ok. thanks
<smb> pitti, did you reject the hardy upload because of the events from yesterday or another reason. iow, should I bother to prepare it to re-upload later on?
<pitti> smb: I thought we agreed to wrap this into another update, but that uploading it by its own isn't worth it? also, I thought it's superseded by the security update now anyway
<smb> pitti, second is true. first maybe we did miss each other. I'd rather do that on its own on hardy as there are not really much normal things coming along there.
<pitti> smb: so just commit it, and we'll wait with the upload until something more urgent pops up?
<smb> pitti, That might be never. Because urgent things will likely be security and those wont take that. And then I end up pushing around a commit for the remaining lifetime of hardy and that is just a waste of effort.
<pitti> smb: then my gut feeling is to just forget about it; if it hasn't hurt anyone in over two years, then it's not a biggie now
<smb> pitti, Alright then. I rather not bother about that then
<pitti> YokoZar: hey, how are you?
<pitti> YokoZar: question for you in bug 606509
<ubottu> Launchpad bug 606509 in wine1.2 (Ubuntu Lucid) "Wine 1.2 Stable is released" [Undecided,Fix committed] https://launchpad.net/bugs/606509
<YokoZar> pitti: heya
<pitti> smb: is the linux-mvl-dove upload (lucid) still current, with yesterday's security update?
<smb> pitti, It basically is all moot atm
<pitti> smb: ok, rejecting then
<smb> ack
<YokoZar> pitti: per my comment on 606509 I'll get to work on a new gnome-exe-thumbnailer for Lucid
<pitti> YokoZar: in other words, you want to overwrite the current SRU and not publish it?
<YokoZar> pitti: no, hold it for now
<pitti> ack
<YokoZar> pitti: and I'll upload a new gnome-exe-thumbnailer and we release them together
<YokoZar> pitti: then the minor bugfix can follow
<pitti> YokoZar: no, I think we misunderstand
<pitti> YokoZar: I'll hold the current upload in the unapproved queue
<pitti> YokoZar: but I meant the pacakge which is already in lucid-proposed and got some testing
<pitti> i. e.  1.2-0ubuntu1~lucid3
<YokoZar> Yes hold off on moving that to -updates
<pitti> ok
<YokoZar> wait for it to go to -updates at the same time as a new gnome-exe-thumbnailer that isn't ugly
<YokoZar> the reason is if they install the old one it'll cache some ugly thumbnails that won't change
<pitti> ok; but then I'd still prefer ~lucid4 to be on top of ~lucid3, i. e. get its own changelog
<pitti> so that we don't invalidate all the testing that went into ~lucid3
<vish> could someone upload this for maverick? lp:human-theme fixes a small bug Bug #553393 ..
<ubottu> Launchpad bug 553393 in human-theme (Ubuntu) "Checkboxes and radiobuttons almost invisible using Human themes" [Low,Triaged] https://launchpad.net/bugs/553393
<vish> obviously someone still uses human theme ;p  .. they came to -artwork asking for a fix ;)
<vish> human theme is still in main.. maybe it should be moved to universe?
<jibel> pitti, I think that you can publish gzip from lucid-proposed to -updates. It was verified 4 weeks ago but the list of pending SRUs fails to report the status.
<jibel> pitti, bug 524366
<pitti> jibel: ah, the syntax is wrong in https://edge.launchpad.net/ubuntu/lucid/+source/gzip/1.3.12-9ubuntu1.1
<ubottu> Launchpad bug 524366 in gzip (Ubuntu Lucid) "Regression: CRC error an i386" [Undecided,Fix committed] https://launchpad.net/bugs/524366
<pitti> jibel: thanks
<cnd> pitti, do you know where didrocks or seb128 are?
<pitti> cnd: no, I don't; I think didrocks mentioned something about holidays until Friday
<cnd> ok
<mvo> seb is on vacation as well
<cnd> mvo, thanks
<ogra> hmm, so whats up with samba today
<pitti> l
<cnd> pitti, would adding an apport hook require an FFE?
<shadeslayer> jcastro: thanks for the sponsorship... thanks to canonical as well :D
<shadeslayer> could you tell me who else is coming from the Kubuntu team btw?
<pitti> cnd: no, those are fine
<cnd> pitti, ok, thanks!
<jjohansen> cjwatson: is it you I bug about a grub2 issue?
<cjwatson> yes
<jjohansen> cjwatson: okay, I have a multipath bug I am looking at but grub-probe is failing with error no mapping exists for X-part1
<jjohansen> where X is the multipath
<jjohansen> that exists in /dev/mapper/
<cjwatson> run it with -vvv and send me the output, together with ls -l of the relevant device nodes and the contents of /boot/grub/device.map (if any)
<jjohansen> cjwatson: okay, thanks
<ogra> can a buildd admin please bump https://edge.launchpad.net/ubuntu/+source/samba/2:3.5.4~dfsg-1ubuntu6/+build/1962200 and https://edge.launchpad.net/ubuntu/+source/ubiquity/2.3.19/+build/1962841 to very high ?
<pitti> ogra: done
<ogra> thanks
<ogra> pitti, if you want amd64 to build properly again i'd suggest doing that for samba on amd64 too
<pitti> ogra: it's already built on amd64
<ogra> oh, it was powerpc ... sorry
<pitti> bumped
<ogra> i just heard several people complain about it not being upgradeble this morning ... and amd64 handt built then
<ogra> bah, sigh, why is the armel queue so full
<ogra> pitti, can i get  https://edge.launchpad.net/ubuntu/+source/ubuntuone-client/1.4.1-0ubuntu1/+build/1961868 bumped too ? (last one, promised)
<pitti> ogra: nudged
<pitti> ogra: well, yesterday we had a gazillion "OMGfreeze" uploads :)
<ogra> pitti, yes, me too and i'd love to test them to find remaining bugs :=
<ogra> :)
<ogra> but that requires an image
 * ogra would like to have separate buildds for proposed/security on arm ... 
<chrisccoulson> pitti - well, i had to do a few OMGregression uploads yesterday ;)
<chrisccoulson> that happened to coincide with all the OMGfreeze uploads
<psusi> cjwatson: hey there, did you get my message from last night?
<cjwatson> psusi: yes, I followed up to the bug, it's on my to-do list now.  I want to get it upstream
<cjwatson> psusi: upstream's code freeze for 1.99 is in a few days and it would be good to get this sorted out there
<cjwatson> psusi: but I want to spend a bit of time thinking about it and reconciling it with other patches people have sent to achieve similar goals, rather than going straight ahead with it
<psusi> cool... but either way it's going to make it in maverick?
<cjwatson> yes
<cjwatson> I certainly don't want to release with broken dmraid support, as that's a recipe for lots of confusing bugs
<psusi> ahh, ok... I had actually debugged the problem to that same area of code myself before I found that patch from debian... looked good to me and tested well
<psusi> indeed
<cjwatson> well, just to be clear, it's a bug report from a Debian contributor rather than a patch that's been applied to Debian
<cjwatson> I'd want to fix it in Debian too
<psusi> ahh
<mvo> ogra: what was that samba issue you taked about earlier? hang in configure?
<ogra> mvo, arch any vs arch all and full build queue
<ogra> mvo, since arch all is built on x86 thats usually ahead so we get uninstallability
<mvo> ogra: aha, ok. there is another samba releated issue that I was wondering about
<ogra> ah, no, it was only installability issues during image build due to the above
<ogra> StevenK, still awake ?
<kirkland> pitti: fix is already in maverick
<kirkland> pitti: i updated the bug status, but its noted in the sru justification
<pitti> kirkland: ah, thanks
<ogra> al-maisan, hey, mind letting linux-ti-omap4 our of NEW ?
<al-maisan> ogasawara: sure, please give me a 10 minutes or so.
<al-maisan> I am just finishing something up..
<cjwatson> I can do it if you like
<al-maisan> cjohnston: that would be great
<cjwatson> though I see it's al-maisan's archive day
<cjwatson> but anyway :)
<al-maisan> if you don't get to it, I will do so in 10 minutes.
<ogra> al-maisan, lol, you messed up all tab completion that was possible the the last lines :)
<al-maisan> ouch :)
<al-maisan> cjohnston: sorry
<al-maisan> .. and, also sorry to ogasawara :)
<ogra> she is used to it ... i'll claim back stolen pings in beer at uds :)
<cjwatson> ogra,al-maisan: done
<cjwatson> I think cjohnston must be used to it by now as well
<al-maisan> thank you!
<ogra> TA
<mathiaz> cr3: o/
<mathiaz> cr3: re checkbox 0.10.3 - I forgot to update the branch before I uploaded the package
<mathiaz> cr3: could you prepare a 0.10.4 with the correct po file?
<cr3> mathiaz: if this could wait until monday, I could do even better and fix a bug that's been affecting the translators team
<mathiaz> cr3: well - final freeze is in less than 2 hours
<mathiaz> cr3: is it release critical?
<cr3> mathiaz: I think it would qualify as release critical, let me ask dpm
<cr3> dpm: hey dude, do you think the bug in Checkbox affecting translations of questions to be release critical?
<mathiaz> cr3: I'd ask the release manager as well
<hallyn> ttx: proposed a fix for bug 488285.  probably too late, but...
<ubottu> Launchpad bug 488285 in multipath-tools (Ubuntu) "multipathd segfault" [Low,Confirmed] https://launchpad.net/bugs/488285
<mathiaz> cr3: the release team is making the final call
<cr3> skaet: would you consider this bug release critical and be acceptable for an exception if fixed next week: https://bugs.edge.launchpad.net/ubuntu/+source/checkbox/+bug/514401
<ubottu> Launchpad bug 514401 in Ubuntu Translations "Translations are not loaded for the test descriptions in Checkbox" [High,Triaged]
<dpm> cr3, mathiaz, perhaps you guys can bring it up tomorrow in the release team meeting. For me personally, it would be important that checkbox could be used in any language
<cr3> dpm: agreed
<mathiaz> cr3: IIUC the most important bug has been fixed in 0.10.3?
<cr3> mathiaz: yes
<mathiaz> cr3: the remaining part is an updated po file that wouldn't be used for now unless another bug is fixed?
<cr3> mathiaz: yes, so lets wait until we get a verdict tomorrow
<skaet> cr3,  lets discuss tomorrow.
<mathiaz> cr3: ok.
<cr3> skaet, mathiaz: thanks folks!
<mathiaz> ttx: so re samba bug - new bugs are still pouring in
<mathiaz> ttx: should the package be blocked?
<ttx> mathiaz: not sure, it's a development release after all -- ask the release team, I'm on a call right now
<mathiaz> skaet: robbiew: cjwatson: slangasek: bug 639768 - samba fails to upgrade on maverick
<ubottu> Launchpad bug 639768 in samba (Ubuntu Maverick) "Samba process gets hung on maverick update" [High,Triaged] https://launchpad.net/bugs/639768
<mathiaz> bugs are pouring in LP - is it worth blocking the package on the mirrors?
<cjwatson> I don't like doing that in development releases - can we just get it fixed ASAP?
<mathiaz> cjwatson: I've started the investigation
<mathiaz> cjwatson: in the mean time we can just mark the bugs duplicated
<robbiew> mathiaz: yeah...I hit that last night
<robbiew> I just killed the upload, dpkg --configure -a, and did another dist-upgrade
<robbiew> it doesn't lock up the system or anything
<mathiaz> robbiew: hm
<mvo> it seems like ists enough to kill the "start smbd" process
<mvo> I helped some people with that problem last night and today
<mathiaz> robbiew: I've uploaded a new version of samba - but I don't see how it could produce that
<mathiaz> mvo: right - so start smbd is blocking
<mathiaz> robbiew: was your network down?
<robbiew> nope
<robbiew> I don't even use samba
<mathiaz> looking at the smbd upstart job: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/maverick/samba/maverick/annotate/head%3A/debian/samba.smbd.upstart
<mathiaz> line 4: start on local-filesystems
<mathiaz> would this be the reason why start smbd blocks on package upgrade?
<soren> mathiaz: I'd say no. that just specifies what will /automatically/ start samba. On upgrades, it would get explicitly restarted.
<mathiaz> robbiew: do you have logs in /var/log/samba/ ?
<mathiaz> robbiew: something like log.smbd?
<mathiaz> robbiew: it may give a clue why "start smbd" was blocked
<robbiew> let me check
<soren> mathiaz: Do we know that that is what is blocked?
<mathiaz> soren: I think so - see mvo comment above
<soren> \O/ it hangs for me on install.
 * soren investigates
<mathiaz> soren: 11:17 < mvo> it seems like ists enough to kill the "start smbd" process
<cjwatson> there was that recent change to cups
<robbiew> yeah...I think that's related
<cjwatson> which made it 'start on starting smbd' or similar, I believe
<soren> Ah, so it's cups, maybe?
<cjwatson> grr
<robbiew> mathiaz: I'll attach my log.smbd file
<cjwatson> misuse of 'and' in a way that's known to break upstart
<cjwatson> ++start on ((starting smbd or filesystem)
<cjwatson> ++          and started dbus
<cjwatson> ++          and stopped udevtrigger)
<robbiew> has CUPS related errors
<cjwatson> that means that when 'starting smbd' arrived, it will wait for dbus to start and udevtrigger to stop (since those edge events have long since come and gone at system boot)
<cjwatson> pitti: ^-
<cjwatson> started and stopped are *not states*
<cjwatson> I thought Keybuk went through this in detail on #ubuntu-devel a couple of days back?
<ogra_cmpc> yes together with pitti and till
<ogra_cmpc> yesterday even i think
<cjwatson> it's not obvious to me how to fix this
<cjwatson> http://irclogs.ubuntu.com/2010/09/14/%23ubuntu-devel.html#t16:28
<quadrispro> hi guys
<cjwatson> in which Keybuk explains exactly why this is broken
<cjwatson> pitti: so remember how the consensus on Tuesday seemed to be "ok, it will break if you start or stop smbd manually, but just don't do that" ...
<cjwatson> pitti: bit of an upgrade issue there ;-)
<pitti> cjwatson: just got a DSL reconnect, so I guess I missed a bit of the conversation
<pitti> cjwatson: oh, right
<pitti> you mean if we upgrade the samba package, it'll wait forever on cups
<cjwatson> and indeed it's doing so for lots of people
<cjwatson> bug 639768
<ubottu> Launchpad bug 639768 in samba (Ubuntu Maverick) "[Maverick] Samba process gets hung on maverick update" [High,Triaged] https://launchpad.net/bugs/639768
<pitti> urgh, so we better revert this for now, I think
<pitti> I haven't seen a good solution for "start cups before samba" yet
<cjwatson> perhaps we can decouple those two jobs, and instead signal samba somehow when cups is ready for it?
<cjwatson> reverting the entire upstartification may be painful
<pitti> that's the tricky bit -- you can have a system with samba and without cups
<cjwatson> the upgrade rules aren't designed for that
<pitti> cjwatson: oh, I'd keep the upstart job
<pitti> cjwatson: just drop the "on starting smbd"
<cjwatson> right
<pitti> the upstart script works fine, I think we can just as well keep it
<pitti> (except for that bit, of course)
<cjwatson> well, if you're signalling samba in a way which doesn't involve direct arcs in the upstart job graph, that would be easier
<cjwatson> you know, if you could send SIGHUP to it or something
<cjwatson> if it fails, whatever
<pitti> slangasek: ^ is there a way to tell smbd "go redetect the configuration" like this? (SIGHUP etc.)
<soren> pitti: As in reread its configuration file?
<soren> pitti: Or what exactly changes that samba needs to notice?
<slangasek> pitti: to go reread smb.conf?  sure, SIGHUP does it
<pitti> soren: I don't think that's in samba's configuration file; I guess it just asks cups?
<mathiaz> pitti: http://manpages.ubuntu.com/manpages/maverick/en/man8/smbd.8.html
<soren> pitti: My problem is that I don't know what "that" is in your question.
<mathiaz> pitti: you can force a reload by sending a SIGHUP to the server.
<pitti> soren: if only I knew :)
<cjwatson> will SIGHUP be sufficient to get it to notice that cups is now available?
<soren> Ok, why does CUPS need to wait for Samba?
<pitti> soren: I was told that we should start cups before smbd, so that smbd can pick up cups' printers and export them to the windows network
<slangasek> I believe so but would have to test that
<soren> Ah, I see.
<pitti> soren: but I don't know whether samba is using libcups or reading /etc/cups/printers.conf, etc.
<pitti> mathiaz: grabbing the bug, FYI
<mathiaz> pitti: ok
<ttx> ok, so this happens to be the first samba update since that problematic cups update, IIUC
<mathiaz> ttx: yes
<cjwatson> perhaps, after cups is fixed, samba ought to be reuploaded with a Breaks: cups (= thatversion)
<ttx> mathiaz: unlucky you :)
<mathiaz> ttx: well - better now than when the first security update for samba in maverick is published
<pitti> so I wonder whether I should only drop the "on starting smbd" for now, or add a killall -HUP smbd as well
<ttx> mathiaz: heh, yes
<cjwatson> use 'status' to find the pid of smbd according to upstart
<cjwatson> (yes, you have to do a little text parsing)
<pitti> cjwatson: except that there are two smbd processes
<pitti> $ status smbd
<pitti> smbd start/running, process 1213
<pitti> root      1213  0.0  0.1  93504  4784 ?        Ss   13:35   0:00 smbd -F
<pitti> root      1226  0.0  0.0  93504  1988 ?        S    13:35   0:00 smbd -F
<cjwatson> but at least the format is documented
<cjwatson> oh
<pitti> 1226 is a child
<cjwatson> which one do you need to SIGHUP?
<cjwatson> is it sufficient to SIGHUP the top one?
<pitti> also, I'm not sure whther that'd help at all
<pitti> The configuration file, and any files that it includes, are
<cjwatson> I'd suggest just dropping 'on starting smbd' for now while we research thiss
<pitti>        automatically reloaded every minute, if they change. You can force a
<cjwatson> *this
<pitti>        reload by sending a SIGHUP to the server.
<mathiaz> pitti: right - I'm not sure either
<cjwatson> but the configuration file is not changed in this case
<pitti> i. e. it doesn't seem necessary nor sufficient
<mathiaz> pitti: I'm not sure smbd would pick up the new printers
<cjwatson> the thing that changes is cups starting, which smbd can't detect
<pitti> ok, let's just drop the dependency for now
<mathiaz> pitti: if you drop the dependency and *restart* smbd in the post-script section of cups?
<mathiaz> pitti: hm - well - that would probably break existing smbd sessions
<pitti> mathiaz: that, and would be rather costly, too
<pitti> let's figure this out under less pressure; this has been broken for ages, after all
<pitti> uploaded for now
<pitti> a really cheesy workaound might also be to start smbd later? i. e. "start on runlevel [2345]" instead of "start on local-filesystems"?
<cjwatson> don't leave it up to chance like that, please
<cjwatson> we'll just get confused later
<mathiaz> pitti: ok - so the starting on smbd has been removed
<mathiaz> pitti: for now smbd will not pick up new printers from cups?
<pitti> mathiaz: right, same situation as since karmic
<mathiaz> pitti: ok
<pitti> tkamppeter: ^ FYI
<mathiaz> pitti: should samba be reuploaded with a breaks as suggested by cjwatson ?
<pitti> mathiaz: I'm not sure under which conditions that would help
<pitti> but it's certainly not wrong
<cjwatson> come to think of it I can't think of a condition where it would help
<cjwatson> I was thinking of upgrades from lucid, but those will just upgrade to the fixed cups
<cjwatson> perhaps partial upgrades
<cjwatson> ah yes
<cjwatson> user has already upgraded cups to the version currently in the archive, before pitti's fix today; there's some attractive bug-fix in samba, so they run 'apt-get install samba'
<cjwatson> bang
<cjwatson> a Breaks would encourage the package manager to upgrade cups as well
<mathiaz> cjwatson: well there was only one upload after the upstartification of cups
<cjwatson> yes, but there might be more
<cjwatson> partial upgrades - we can't necessarily assume that users are up to date on all packages in a level way
<cjwatson> particularly during development cycles when one thing or another is often broken, or when people sometimes just change one thing at a time
<mathiaz> cjwatson: gotcha
<mathiaz> cjwatson: so the following line should be added to the debian/control file of the samba package: Breaks: cups (= 1.4.4-4) ?
<jelmer> pitti, mathiaz: our print dev hasn't gotten back to me yet, but I've looked at the code and its intend at least is that the printers are reloaded on SIGHUP.
<pitti> jelmer: ah, splendid
<pitti> jelmer: thanks a lot for checking
<pitti> jelmer: while you are there: I have two smbd processes, one is the child of the other
<mathiaz> cjwatson: 1.4.4-4 being the version that added the upstart job, 1.4.4-4ubuntu1 being the one that pitti just uploaded
<pitti> jelmer: is it enough to send sighup to the parent, or do I need both?
<pitti> mathiaz: right, -4 is the only one that wreaks havoc
<mathiaz> pitti: ok - so I'll upload a new version of the samba package wich add a Breaks line
<pitti> mathiaz: cheers
<tkamppeter> pitti, the Ricoh guys are suggesting to let a straight PS workflow (pstops filter) happen when printing  PS on a PS filter. see e-mail.
<jelmer> pitti: not sure, I'll check
<cjwatson> pitti: right
<cjwatson> er
<cjwatson> mathiaz: right, that's what I'm thinking
<jelmer> pitti: fwiw it should update the list every "printcap cache time" seconds as well (defaults to 750)
<pitti> jelmer: ah, so it'll work after 13 minutes anyway?
<jelmer> pitti: I'm betting that's not an ideal time to have to wait for printers to come up on startup though..
<tkamppeter> pitti, they do it for two reasons: 1. They observe yellow backgrounds with some files, but this I cannot reproduce. I also have already fixed such kind of bug.
<jelmer> pitti: yep
<pitti> jelmer: right, so if sending SIGHUP to the parent smbd will cause it to reload immediately, then doing that is easy
<pitti> status smbd -> check for "running" -> parse out pid -> send sighup to that
<pitti> but that doesn't give me the child pid, just the parent
<tkamppeter> pitti, 2. There is a file which makes one of the Ricoh printers hang with the current workflow.
<pitti> tkamppeter: can we control the filter priorities (ps vs. pdf) on a per-driver level even?
<tkamppeter> pitti, no. The suggestion is to slightly lower the cost factor of pstops, so that only for the "input is PS and printer is PS" case the PS workflow happened. Possible solutions are implementing this or adding a remark in README.Debian.
<pitti> tkamppeter: why do we do ps -> pdf -> ps at all? so that we can do transformations like "4-on-1" in between?
<tkamppeter> pitti, the suggested change is replacing
<tkamppeter> application/pdf                 application/vnd.cups-postscript 66      pdftops
<tkamppeter> by
<tkamppeter> application/pdf                 application/vnd.cups-postscript 65      pdftops
<tkamppeter> in /usr/share/cups/mime/mime.convs
<pitti> tkamppeter: what's the potential regression from using pstops again?
<pitti> that'd apply to all printer drivers, not just Ricoh, right?
<pitti> but indeed I remember similar Debian bug reports which said that using ps works better
<tkamppeter> pitti, yes, this way we do the page management stuff, like 4-on-1 on PDF data, which always works. PS can be non-DSC-conforming and so a 4-on-1 on PS is not always performed.
<tkamppeter> pitti, yes, it applies to all PostScript printers and also to drivers which take only PostScript input (like foo2zjs).
<jelmer> pitti: <idra> jelmer, IIRC the parent should send a "reload config" message to all children when it receive a SIGHUP
<pitti> jelmer: ah, perfect
<pitti> jelmer: thanks a bunch!
<pitti> tkamppeter: so, if you think it's better that way, please commit to bzr
<jelmer> pitti: you're welcome, upstart ftw!
 * jelmer returns to sync source bugfixing
<pitti> cjwatson, tkamppeter, slangasek, mathiaz: so I'll add the SIGHUP to cups' post-start
<cjwatson> sounds good to me
<mathiaz> pitti: sounds good to me as well
<pitti> $ status smbd | awk '/process [[:digit:]]+/ { print $NF}'
<pitti> that seems to DWIM
<slangasek> pitti: technically no
<slangasek> pitti: you need to make sure it's 'start/running' if you're going to HUP it
<fta> highvoltage, what does it take to have bug 636894 fixed (in time)??
<ubottu> Launchpad bug 636894 in libvpx (Ubuntu) "please sync libvpx 0.9.2-1 from debian experimental (main)" [Undecided,New] https://launchpad.net/bugs/636894
<slangasek> so you aren't killing the pre-start script :)
<fta> highvoltage (oops, sorry, not for you)
<pitti> slangasek: ah, thanks; does it really need to be "start/running", or could it be anything/running?
<pitti> slangasek: i. e. "I intend to stop, but can't yet"?
<fta> (was "hi, ...")
<slangasek> pitti: if it's anything else, there's no reason for you to signal it :)
<slangasek> pitti: and in most cases, sending the signal would go to a process that's *not* smbd - so I think you should only worry about start/running
<pitti> status smbd | awk '/start\/running, process [[:digit:]]+/ { print $NF}'
<pitti> using that then
<pitti> ok, I added some logging to cups.conf, seems to work fine
<pitti> ok, committed
<pitti> tkamppeter: do you plan to do a commit for the ps stuff?
<highvoltage> fta: :)
<fta> highvoltage, xchat's fault :P
<tkamppeter> pitti, yes, I am preparing it now.
<tkamppeter> pitti, done.
<pitti> tkamppeter: hm, bzr pull doesn't give anything new
<pitti> tkamppeter: 11 minutes to go until freeze starts :)
<tkamppeter> pitti, resolved conflict and pushed again.
<pitti> hm, that commit looks weird
<pitti> tkamppeter: did you push --overwrite?
<pitti> on a conflict, you should uncommit, pull, fix, and commit again
<micahg> any AA available for a main sync before Final Freeze (6 minutes)?
<cjwatson> micahg: yes
<tkamppeter> pitti, I did only bzr push. I never used --overwrite.
<micahg> cjwatson: bug 636894 please :)
<cjwatson> is ubuntu-archive already subscribed to it?
<ubottu> Launchpad bug 636894 in libvpx (Ubuntu) "please sync libvpx 0.9.2-1 from debian experimental (main)" [Undecided,New] https://launchpad.net/bugs/636894
<micahg> yes
<cjwatson> ok, then I'll just do a sync-helper pass
<tkamppeter> pitti, conflict was only in debian/changelog, I have made sure that your newer comment got used.
<cjwatson> (of course, archive admin syncs bypass freezes anyway ... *cough*)
<cjwatson> at least I think they do, could be wrong
<micahg> cjwatson: does that script require a core-dev comment?
<cjwatson> not necessarily, it's interactive so we can apply judgement
<micahg> cjwatson: ah, ok
<cjwatson> though generally a main sync should have a main uploader's approval
<micahg> cjwatson: it has one indirectly
<cjwatson> however, I can look at it since you asked nicely
<micahg> cjwatson: thank you :)
<pitti> tkamppeter: please bzr pull  --overwrite; I fixed the branch
<pitti> tkamppeter: for some reason the last rev was messed up
<tkamppeter> pitti, did my attempt to solve the conflict revert the upstart script?
<pitti> tkamppeter: I don't know, I didn't look (want to get this uploaded..)
<pitti> the topmost change was a weird merge and shuffled the changelog
<tkamppeter> pitti, did you fix it, so that you can upload?
<pitti> tkamppeter: yes, doing now
<fta> cjwatson, thanks! (for libvpx)
<pitti> tkamppeter: 2 mins before freeze, nice timing! /me ^5s you
<tkamppeter> pitti, printing stack has boarded on last call, now we have a great Maverick (especially on Ricoh users).
<pitti> we lift off in time
<tkamppeter> pitti, to land exactly om 10/10/10 at 10:10:10.
<cjwatson> micahg: gar, another bug blocked on bug 635591
<ubottu> Launchpad bug 635591 in Soyuz "Regression: syncing packages with UTF-8 changelogs fails" [High,Triaged] https://launchpad.net/bugs/635591
<tkamppeter> pitti, on the advertizing screen of the metro of Berlin they announce release parties. I hope they will this time stop the metro for one minute to announce this great event :-).
<pitti> http://people.canonical.com/~pitti/scripts/syncpackage FTW?
<cjwatson> micahg: I think we can give this a freeze exception though
<cjwatson> pitti: the fix is supposed to land soon, and there is another bug blocked on it
<pitti> ah
 * cjwatson prefers not to use syncpackage if possible
* iulian changed the topic of #ubuntu-devel to: Archive: Open | FINAL Freeze in effect! | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-lucid | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
* pitti changed the topic of #ubuntu-devel to: Archive: FINAL Freeze in effect! | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-lucid | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<pitti> (the archive is not quite "open" any more)
<micahg> cjwatson: ok, thanks, should I subscribe to the soyuz bug and poke about libvpx when it's cleared
<cjwatson> I'm subscribed to the Soyuz bug, and have noted in it all the bugs which it blocks
<cjwatson> so I'll go through them myself
<micahg> cjwatson: great, thank you
<ari-tczew> does anyone from archive-admins is working on syncs?
<ari-tczew> (right now)
<chrisccoulson> ari-tczew, see the topic
<ari-tczew> ok chrisccoulson
<cjwatson> ari-tczew: I've been doing them at least daily for the last two weeks, and I processed one of yours immediately before the freeze.
<ari-tczew> cjwatson: yes, thanks
<cjwatson> ari-tczew: but as of now, as chrisccoulson points out, any change needs a final-freeze exception and needs a very good reason
<cjwatson> ari-tczew: although actually, if it's in universe and not on the CDs, it's still OK
<ari-tczew> cjwatson: I would upload a new package - clementine. it's a music player. what are the chances to upload?
<cjwatson> ari-tczew: you can certainly upload it; whether we accept it would be a judgement call on how complex it looks
<cjwatson> I suppose chances would be moderate
<cjwatson> it's a question of whether it's likely to need significant fixes to be of release quality
<ari-tczew> cjwatson: it's not related to main packages, so ubuntu's API won't be broken. :)
<cjwatson> I know, but the quality of universe does matter too
<cjwatson> as a MOTU you should be keen on that ;-)
<ari-tczew> cjwatson: ubuntu-release will decide about upload. :)
<ScottK> ari-tczew: You shouldn't propose it unless you are convinced it is appropriate.  We've got pleanty of things to do already.
<ari-tczew> ScottK: I'm convinced about this upload. It's a great music player and we should ship it with Maverick release.
<ScottK> ari-tczew: Why not just wait a month, put it in Natty, and then backport it?
<ari-tczew> ScottK: why not now?
<ScottK> Because the people that would have to review it are all busy with other things.
<ScottK> If we do it now, some other thing doesn't get done.
<ari-tczew> ScottK: I'm sad to hear this.
<ScottK> ari-tczew: This is why we have a new package deadline in the release schedule.
<ari-tczew> ScottK: when is the deadline for new packages?
<ScottK> ari-tczew: Same as feature freeze, August 12.
<highvoltage> ari-tczew: I don't think it's completely rational being disappointed, the deadline for new packages was more than a month ago already: https://wiki.ubuntu.com/MaverickReleaseSchedule
<highvoltage> ari-tczew: usually, after that, a FFU (or Feature Freeze Exception) has to be filed to get a new package in: https://wiki.ubuntu.com/FreezeExceptionProcess
<ari-tczew> ScottK: what do you need review in package?
<highvoltage> ari-tczew: after Final Freeze (today), upi
<highvoltage> oops, well, after final freeze you'll need an exception for that too
<ari-tczew> highvoltage: I know. 2 years ago also I provided FFe for kadu upgrade.
<ari-tczew> but it wasn't a new package like clementine right now.
<ScottK> ari-tczew: It's somewhat described in https://wiki.ubuntu.com/ArchiveAdministration
<ari-tczew> ScottK: when we will backport package from natty, new package will be published in -release pocket or -backport?
<ScottK> ari-tczew: Backport
<ari-tczew> ScottK: quite so I'm afraid. I'd give users this music player at start.
<ScottK> ari-tczew: I can understand being disappointed, but it's highly unlikely you'll get an FFe for it approved now.
 * ScottK has other this to get busy with.
<highvoltage> ari-tczew: moral of the story: if you want your packages in the archive, try to follow the schedule :)
<ari-tczew> ScottK: what about other admins?
<ScottK> I think it's unlikely.
<ari-tczew> ScottK: ok, but I can request FFe, right?
<ScottK> ari-tczew: You can.  I'd prefer you spend your time fixing FTBFS or NBS instead, but you can.
<cjwatson> ari-tczew: I thought you were focusing on security until release, btw? ;)
<ari-tczew> cjwatson: that's right. however, I loved use amarok 1.4 and clementine can give me similiar enjoy. I'd give people this great program. It can be a small argument for choice Ubuntu. ;)
<kees> ari-tczew: added you to ubuntu-sponsors
<ari-tczew> kees: thanks. :)
<kees> ari-tczew: np :)
<doko> Riddell: kdoctools : Depends: kdelibs5-data (= 4:4.5.1-0ubuntu4) but 4:4.5.1-0ubuntu5 is to be installed
<doko> please stop this insanity!  makes the packages uninstallable until built on armel too ...
<lex79> doko: kdoctools needs kdelibs5-data for dtd/kdex.dtd needed to build docs
<ogra_cmpc> lex79, i think doko refers to the =
<doko> exactly ...
<doko> that should be a >= 4.5.1
<lex79> ah, now it is kdelibs5-data (= ${source:Version})
<lex79> I can change to >=  ${source:Version}
<doko> lex79: doesn't help, think about it
<lex79> uhm right ;)
<lex79> I can drop that (= ${source:Version})
<ogra_cmpc> you actually want the upstream version
<ogra_cmpc> (and the epoch)
#ubuntu-devel 2010-09-17
 * TheMuso shkes his head. So many people filing bugs for audio using lucid's proposed 2.6.32-25 kernel series...
<SpamapS> is now a bad time to try and upload packages to a ppa for maverick? I am getting a lot of uninstallable stuff.. like.. cdbs and debhelper..
<SpamapS>  cdbs : Depends: intltool but it is not going to be installed
<slangasek> SpamapS: dunno what that is, things shouldn't be problematic right now given that we just froze.  How long ago was it, can you reproduce the problem in a chroot?
<slangasek> (I can't, but the chroot I'm in isn't a clean one)
<SpamapS> slangasek: I'm unable to update my chroot or pbuilder right now because my internet connection shuts itself down if I sustain downloads. :(
<SpamapS> technician coming tomorrow with a new DSL modem.. hopefully that fixes it. :-P
<SpamapS> slangasek: http://launchpadlibrarian.net/55773453/buildlog_ubuntu-maverick-i386.cassandra_0.6.5ubuntu1_FAILEDTOBUILD.txt.gz
<SpamapS> there's the full failed to build log
<avi_> Hello, can anyone tell me if there are any signals for appindicator menus themselves? Like not clicking a menu item, but clicking the indicator icon itself.
<persia> Could someone give-back all the failed langpacks on i386 ( http://qa.ubuntuwire.com/ftbfs/ ) gettext seems less broken now.
<TheMuso> persia: no shell access to mass give back here, but there are not a lot, so I'll give them back manually.
<persia> TheMuso, Thanks.  I was hoping a buildd-admin was around, but I figured it would be unpleasant for the Europeans to wake up to those.
<TheMuso> np should all be back in the queue now.
<persia> Also, thanks for cleaning up after me on 623242: I missed the flat volumes somewhere.
<TheMuso> np
<slangasek> SpamapS: ^^ would have been the gettext issue mentioned above, believed solved now
<UbuXubu> i would like to report a bug
<UbuXubu> i did a clean install of 10.04 a couple weeks ago and i let ubuntu have the entire disk.
<UbuXubu> it updated and has since updated a few more times.
<UbuXubu> the last update was small..maybe 5-6 of them. i tokk them all as i always do. after that when i log in the panels are gone?
<UbuXubu> so i did the terminal command and it worked but the panels are gone again everytime i log in.
<UbuXubu> soi was given a second termal command and it worked too, but anytime i log in the problem comes back.
<UbuXubu> so just for the heck of it i right clicked on the panels and installed one of those little widgets offered by ubuntu. i put a couple of them on each panel AND THAT FIXED IT?
<UbuXubu>  i am hoping this fix somehow leads the coders to what is wrong because i really dont want the widgets, but for now it keeps my panels frpm disappearing.
<UbuXubu> from*
<TheMuso> UbuXubu: If you wish to file a bug, you should file the bug on launchpad.net. I suggest you go to https://launchpad.net/ubuntu/+source/gnome-panel/+filebug to file your bug. The link I gave you is to file a bug against the component, otherwise known as package, that you are having problems with.
<TheMuso> !filebug | UbuXubu
<ubottu> UbuXubu: If you find a bug in Ubuntu or any of its derivatives, please file a bug using the command Â« ubuntu-bug <package> Â» - See https://help.ubuntu.com/community/ReportingBugs for other ways to report bugs - Bugs in/wishes for the IRC bots (not Ubuntu) can be filed at http://bugs.launchpad.net/ubuntu-bots
<MIH1406> Is there a program that check my sources against standards coding?
<pitti> Good morning
<poolie> pitti: hi, i wanted to see about getting bzr in to https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
<poolie> this is basically the process we follow now, but i think it would be worth fixing any accidental divergences
<poolie> and making it formally recognized
<pitti> poolie: this sounds reasonable to me, given its history, test coverage, and regression potential
<pitti> poolie: can you please mail technical-board@ about this, so that we can discuss it officially?
<poolie> we have put some SRUs up but in the last one someone (quite reasonably) questioned if it was ok to upload a whole minor release rather than individual patches
<pitti> then we can discuss it next Tuesday, or on the ML
<poolie> sure, just though i'd sound you out first
<poolie> np
<pitti> poolie: minor releases have always been okay as long as the individual changes all match SRU criteria
<pitti> hm, did someone already giveback all langpacks after the libunicode bug?
<pitti> libunistring0, actually
<pitti> ah, seems so; thanks
<ari-tczew> pitti: thanks for reject wrong file :)
<poolie> thanks
<poolie> pitti, sent, it's currently in the moderation queue
<pitti> poolie: I discarded the first post and accepted the second
<poolie> was it sent twice?
<poolie> how strange
<pitti> apparently so
<Foobar_> Hi, I want to start programming an open source project for learning purpose and for helping the open source community
<Foobar_> But I am confused in what type of project?
<Foobar_> Who can suggest a project for me that is not a duplicate of any other project?
<primes2h> pitti: I can't build apport. pastebin.ubuntu.com/494806 svg icon error.
<primes2h> ?
<primes2h> pitti: first of all, hello! :-)
<primes2h> pitti: it seems that symlink point at the wrong dir.
<cjwatson> TheMuso: shell access for give-backs> you don't need it - there's an ubuntu-build program in ubuntu-dev-tools, with a --batch option
<pitti> hello primes2h
<pitti> primes2h: no, the dir is correct; it rather looks like debian/tmp/usr/share/icons/hicolor/scalable/mimetypes
<pitti> doesn't exist?
<primes2h> pitti: text-x-apport.svg points to ../apps/apport.svg but apps dir doesn't exist.
<primes2h> text-x-apport.svg is into mimetypes
<primes2h> dir
<pitti> lrwxrwxrwx 1 martin martin 18 2010-08-25 12:51 ./data/icons/scalable/mimetypes/text-x-apport.svg -> ../apps/apport.svg
<pitti> -rw-r--r-- 1 martin martin 16628 2010-08-05 17:55 ./data/icons/scalable/apps/apport.svg
<pitti> seems fine here
<primes2h> pitti: it's present in ./data/icons/scalable/etc... but not in debian/tmp/usr/share/icons/hicolor/scalable/
<primes2h> pitti: just mimetype dir is present  in debian/tmp/usr/share/icons/hicolor/scalable/
<pitti> hm, they build just fine here
<primes2h> pitti: tried with pbuilder and debuild. Am I doing something wrong maybe?
<pitti> primes2h: not sure; perhaps put the complete build log somehwere?
<pitti> I did apt-get source apport; cd apport-*; debuild -b
<primes2h> pitti: same here, I've just modified source code a bit (two line added). dch etc..
<primes2h> pitti: I'll try to have a deeper look into
<pitti> primes2h: http://people.canonical.com/~pitti/tmp/apport_1.14.1-0ubuntu7_amd64.build if you want to diff the build dlog
<primes2h> pitti: Thanks!
<didrocks> cjwatson: do you know if there will be a script to close all ubuntu bugs from the last week upload or should we care about that ourself?
<cjwatson> didrocks: there is such a script which I am currently running ;-)
<didrocks> cjwatson: great! thanks :-) is everything working again now?
<cjwatson> didrocks: (you may have noticed me closing a number of your quickly bugs ...)
<cjwatson> I believe so
<cjwatson> if it isn't, let me know and I'll escalate
<didrocks> cjwatson: right, but as there were some minutes between emails, I was hoping you wasn't going crazy closing them manually :)
<cjwatson> well, not manually via a browser
<cjwatson> I have to pay some attention to it, as there are some cases where the bug would have been closed via the upload, but then somebody noticed it wasn't fixed after all
<cjwatson> so I have a script that looks for all the bugs that should be closed, then presents me all the bug comments and the proposed close message and lets me say close, skip, or open in browser
<cjwatson> and I apply judgement from there
<cjwatson> still much faster than having to open them all up in firefox or whatever
<didrocks> cjwatson: oh ok, some pretty touchy case in it and so, long task. good luck with that! Hope it won't take too long for you :-) thanks!
<didrocks> right
<cjwatson> it's not too bad, I'm up to r
<cjwatson> been poking it on and off since yesterday afternoon
<didrocks> (sweet, soon unity them ;))
<didrocks> then*
<cjwatson> my thought exactly.  I assume there are several bugs on the RC list that this will catch
<didrocks> right, there are also some others with yesterday's evening release. I'm still catching up on emails on beeing away from the last 2 days and will package the new stack then
<didrocks> it fixes also a bunch of bugs
<didrocks> the RC list is getting smaller for it, that's a good news :)
<zyga> what is bug watch updater (on launchpad)
<zyga> it has just changed the importance of a bug to critical
<cjwatson> zyga: see ubuntu-devel
<cjwatson> zyga: and note that it's changing the importance of the upstream task
 * zyga chcecks
<zyga> cjwatson, thanks, that explains it
<ttx> pitti: what's the status of bug 494141, now that we reverted the cups/samba stuff ?
<ubottu> Launchpad bug 494141 in cups (Ubuntu) "CUPS starts after SAMBA; printers are not available (convert cups to upstart)" [Undecided,In progress] https://launchpad.net/bugs/494141
<pitti> ttx: ah, that should be fixed now, let me close the bug
<ttx> pitti: good, thanks :)
<pitti> ttx: bug updated
<soren> The conclusion was that Samba would reload the printers on SIGHUP, right?
<pitti> right
<soren> Cool beans.
<cjwatson> didrocks: ubiquity 2.3.19 had its bugs auto-closed, at least
<didrocks> cjwatson: ok, thanks for the notice :)
<cjwatson> didrocks: should I close bug 631446 with the unity 0.2.38-0ubuntu1 upload?  there are several comments from after the upload, so I'm not clear on this
<ubottu> Launchpad bug 631446 in Ayatana Design "launcher tile label/quicklist x position" [Medium,New] https://launchpad.net/bugs/631446
<didrocks> cjwatson: yes please. It will be tracked in a separate bug report.
<cjwatson> ok, done
<cjwatson> didrocks: same question for bug 632991
<ubottu> Launchpad bug 632991 in Ayatana Design "launcher mouse wheel dragging elastic band jittering" [High,New] https://launchpad.net/bugs/632991
<didrocks> cjwatson: I'm asking to gord about that one, will get back to you then
<didrocks> cjwatson: don't close if for now. It will be closed by the upload I'll do in a couple of hours
<cjwatson> ok, skippin
<cjwatson> g
<didrocks> thanks :)
<cjwatson> didrocks: bug 622146, you said "let the unity opened" - does that mean that you want the unity (Ubuntu) task to stay open, despite closing it in the 0.2.36-0ubuntu1 upload?
<ubottu> Launchpad bug 622146 in unity (Ubuntu) "Add favourite launchers on first run" [Medium,Triaged] https://launchpad.net/bugs/622146
<ari-tczew> pitti: could you take a look on bug 557290 ? I think that this patch is useless.
<ubottu> Launchpad bug 557290 in gnu-smalltalk (Ubuntu) "Make gnu-smalltalk build on lucid" [Medium,Incomplete] https://launchpad.net/bugs/557290
<didrocks> cjwatson: no, both should be stayed open, there is finally the need of a last minute patch by Jason which should be there in today's upload as well.
<cjwatson> didrocks: ok, skipping that too
<cjwatson> gah, API timeouts
<pitti> ari-tczew: I didn't look at maverick build logs at all -- they could have failed for completely different reasons
<ari-tczew> pitti: so, I'm not convinced to patching lucid, if this patch couldn't fix FTBFS for maverick. I'll unsubscribe ubuntu-sponsors, do you agree with it?
<pitti> ari-tczew: what's wrong with the lucid one?
<ari-tczew> pitti: we are not sure whether it patch will be buildable for amd64, powerpc and sparc
<ari-tczew> and current source package built fine on all archs
<pitti> but that's easy enough to find out?
<pitti> https://edge.launchpad.net/ubuntu/+source/gnu-smalltalk/3.0.3-2
<pitti> it built fine in jaunty, but lucid has all binaries removed
<pitti> ari-tczew: and maverick amd64 indeed fails in a test case, but other arches succeeded
<Wubbbi> Hey :) I wanna change the source-Code of Firefox. I want to change the default settings in about:config of firefox. Where can I find it?
<ari-tczew> pitti: launchpad is not clear for me. 2009-10-29 18:02:30 CET  	Published  	 Lucid   	release  	universe
<ari-tczew> pitti: no words saying that it was deleted from lucid
<pitti> ari-tczew: the source isn't
<pitti> ari-tczew: but the binaries were removed obviously
<ari-tczew> but packages.ubuntu.com doesn't show lucid packages
<pitti> gnu-smalltalk |    3.0.3-2 | karmic/universe | source, amd64, i386
<pitti> gnu-smalltalk |    3.0.3-2 | lucid/universe | source
<ari-tczew> pitti: well, if my pbuilder will build package for lucid in i386, do  I should upload SRU for lucid-proposed?
<pitti> ari-tczew: sounds good
<ari-tczew> pitti: I'm not convinced, but I'll do it to your command.
<ari-tczew> pitti: and what about maverick status?
<diwic> Wubbbi, apt-src install firefox ?
<pitti> ari-tczew: I don't know; it looks like a separate problem, or the patch is already applied
<Wubbbi> diwic: I know how to get the SC. I just want to know in which file ( in the source-Code ) I can change the default about:config. So when I build and install it, the default config is the way I did it in the c
<ari-tczew> pitti: patch is already applied, right,
<Wubbbi> source-Code
<pitti> ari-tczew: so I guess the maverick task can be closed then
<ari-tczew> pitti: as fixed or invalid?
<pitti> fixed, if the patch is applied
<diwic> Wubbbi, okay. Sorry, I don't know that. You could try searching for a string you know exist in that file
<Wubbbi> diwic: ok thx
<ogra> GRRR samba
 * ogra starts getting annoyed by it 
<ogra> can a buildd admin bump https://edge.launchpad.net/ubuntu/+source/samba/2:3.5.4~dfsg-1ubuntu7/+build/1963227 ?
<ogra> its sitting there since two days now blocking all image builds
<zyga> has anoyne been getting lots of rendering artefacts on lucid with compiz and GMA945 recently?
<zyga> I managed to get a screenshot of one just now
<pitti> ogra: kicked
<ogra_cmpc> pitti, TA
<elmo> is there any official ubuntu stance/policy on folks following up to bugs and blindly saying "is this still a problem in $latest_version?" and setting the bug to incomplete?
<cjwatson> elmo: I wish there were.  I complain when I see people doing it
<ari-tczew> pitti: could I upload a SRU which fix 2 different bugs?
<pitti> ari-tczew: sure, the policy has a section about that
<ari-tczew> policy, policy, policy...
<hallyn> GAH  after about an hour of reading email etc, i just realized my mouse isn't working this morning.
<apw> elmo, JFo spamming you  ?
<JFo> ?
<JFo> apw, I shouldn't be... or should I?
<elmo> haha
<elmo> apw: nah, it wasn't JFo
<JFo> oh heh, I see what you asked about now elmo :-)
<pitti> hallyn: what does "isn't working" mean?
<hallyn> pitti: can't move the mouse with my touchpad
<hallyn> just got done with a few reboots to older kernels to compare
 * hallyn goes to file a bug
<pitti> hallyn: I think this could really do with a proper ubuntu-bug filed bug report, to get all the details
<pitti> we had a couple of -evdev and touchpad updates recently for multitouch
<hallyn> pitti: hm, ok, i'll reboot back into that kernel and try.  hopefully it doesn't present me a too crappy of a gui that i can't navigate with kbd
<hallyn> (it makes sense, though, i agree)
<hallyn> biab
<pitti> hallyn: you don't have an USB mouse?
<hallyn> pitti: not handy, no
<hallyn> it's ok, it did fine.  apart from trying to pull up chrome to do the filing (for which i don't have the equivalent of vimperator plugin installed)
<didrocks> hallyn: can you check on #ubuntu-touch? those are the people who made the changes
<hallyn> didrocks: didn't know about that one, thanks
<didrocks> hallyn: yw :)
<Sarvatt> hallyn: do you have an alps touchpad?
<Sarvatt> there's discussion about it right now in #ubuntu-kernel if so
<hallyn> Sarvatt: yes, i do, i'll head there, thanks.  (the ppl in #ubuntu-touchpad have been very helpful, they probably brought it up there)
<cjwatson> dpm: is the language-selector part of bug 630924 still release-critical?
<ubottu> Launchpad bug 630924 in Ubuntu Translations "Language packs are not downloaded during installation" [Critical,Triaged] https://launchpad.net/bugs/630924
<cjwatson> dpm: (it's been fixed in ubiquity)
<dpm> cjwatson, otp, will answer in a bit
<cjwatson> ok
<doko> slangasek: you touched libxml-twig-perl last. b-d on libunicode-map8-perl (universe), but I can't see when this was introduced
<cnd> how do I handle a bug where all that's needed is a package recompile due to a change in /usr/include/linux/input.h?
<cnd> the evdev protocol version bumped, which broke lsinput, but it should be backwards compatible as far as lsinput is concerned
<cnd> so a rebuild of input-utils would fix it
<cjwatson> bump the version by either one ubuntu revision (if it's already ubuntuN or buildN) or by appending build1 (if it isn't) and reupload
<cjwatson> so version 0.0.20051128-4ubuntu2
<cjwatson> er, input-utils has its own copy of linux-input.h though
<cjwatson> you'd need to refresh it
<cjwatson> this is often the way for userspace software that uses kernel headers
<cnd> cjwatson, there's a patch that already replaces linux-input.h with linux/input.h
<cnd> so it should just need a rebuild
<cjwatson> so there is.  what I said above, then
<cnd> I'll test in one minute
<cnd> cjwatson, is this something I should pursue for the RC freeze?
<cjwatson> sounds reasonable to me
<cnd> ok
<cjwatson> I mean it's completely broken right now
<cjwatson> you aren't likely to make it any worse
<cnd> yeah
<cnd> but there's more than one util that makes up input-utils :)
<cnd> there's three!
<cnd> but yeah, a rebuild isn't even like adding a patch one would think
<cjwatson> cnd: yes, and all three are broken
<cjwatson> I checked before I said anything :-)
<cnd> ahh, I didn't :)
<pitti> james_w: still online? I'm afraid I need some more help with bzr dh-make
<james_w> hi
<pitti> james_w: so, I just created https://edge.launchpad.net/udisks-automounter and want to package it the new way
<pitti> james_w: so I go into my ubuntu dir, and do
<pitti> bzr branch lp:udisks-automounter
<pitti> cd udisks-automounter
<pitti> bzr dh-make -v udisks-automounter 0.0.1 ~/upstream/udisks-automounter-0.0.1.tar.gz
<pitti> but this wreaks havoc
<pitti> james_w: this gives me http://paste.ubuntu.com/495363/
<pitti> james_w: i. e. it removes most of the files in my upstream tarball
<pitti> oh, perhaps it's stumbling over the fact that my upstream tarball doesn't have a single toplevel dir
<dpm> cjwatson, I think the language-selector task could be marked as fixed, as it happened to be another similar issue, but fixed in bug 612825
<ubottu> Launchpad bug 612825 in language-selector (Ubuntu Maverick) "can't install new languages (nothing happen)" [High,Fix released] https://launchpad.net/bugs/612825
<dpm>  (regarding your question on bug 630924 earlier on)
<ubottu> Launchpad bug 630924 in Ubuntu Translations "Language packs are not downloaded during installation" [Critical,Triaged] https://launchpad.net/bugs/630924
<cjwatson> dpm: ok, please go ahead and do that if you think it's appropriate then
<primes2h> pitti: hello, no luck. Tried to download source and build it only but same error http://pastebin.ubuntu.com/495312
<dpm> cjwatson, ok, done that then, marked as Fix Released
<primes2h> pitti: I'm trying to fix the link advise issue, but I can't test it if I can't build it ;-)
<james_w> pitti: wow
<cnd> is the process for RC freeze exception the same as FFE?
<james_w> pitti: that's a good one. It might be the toplevel dir thing, but I thought it should cope with that. Are you willing to try it with a toplevel dir?
<cnd> looks like there's a bullet point about milestone freeze exceptions on the wiki page
<cjwatson> cnd: upload, we'll review.  if it's non-trivial, make sure there's a bug filed and that ubuntu-release is subscribed
<pitti> james_w: yes, I just fixed the upstream Makefile to produce a proper tarball
<cjwatson> cnd: not really much point doing the bug dance for a rebuild-only upload though
<cnd> cjwatson, except that I need a bug dance to upload (ubuntu-sponsors subscription)
<pitti> james_w: looks much better already: http://paste.ubuntu.com/495367/
<cnd> unless you want to grant me core-dev status right now :)
<pitti> james_w: i. e. it didn't remove files, it just still complains about a "No such file or directory"
<pitti> james_w: the two additions are fine; make dist ships the pregenerated .c files from vala, but they aren't in upstream bzr
<SpamapS> slangasek: thanks for letting me know about the gettext issue, I'll retry the build
<pitti> james_w: oh - that might just be because I don't actually have dh-make installed?
<pitti> james_w: anyway, it's looking fine now, so sorry for the noise
<james_w> pitti: yeah, that will be it. Could you please file two bugs?
<pitti> can do
<james_w> thanks
<cjwatson> cnd: not so sure I'm allowed to ;-)
<cnd> darn :)
<apw> davidm, i hear you have a busted touchpad since you upgraded ...
<cnd> cjwatson, thanks for the help
<cnd> got everything filed as bug 628392
<ubottu> Launchpad bug 628392 in input-utils (Ubuntu) "lsinput protocol version mismatch error" [High,In progress] https://launchpad.net/bugs/628392
<smb> pitti, Would you be able to let the latest lucid kernel upload in. (its just a re-upload with security of the last proposed)
<pitti> smb: done
<smb> pitti, thanks
<apw> davidm, if so could you test the kernels here and report back, pretty urgent we get confirmation: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/641320
<ubottu> Launchpad bug 641320 in linux (Ubuntu) "Touchpad is not working since last kernel update in maverick" [Critical,Triaged]
<slangasek> doko: libunicode-map8-perl> but apparently that was in main before?
<slangasek> doko: because the package built
<slangasek> doko: if I didn't document it in the changelog, it's not an intentional delta from Debian on my part :)
<doko> ok
<davidm> apw, pulling down now, do I need the headers too?
<apw> only if you have like broadcom crap
<davidm> Nope no broadcom nvidia gpu however
<davidm> apw back in a bit, rebooting now
<smoser> i don't really understand what 'FinalFreeze' means, and how hard exceptions are.
<smoser> i have a complete understanding of bug 509562 and have a patch for it.  If i upload, will it get accepted ?
<ubottu> Launchpad bug 509562 in euca2ools (Ubuntu) "euca-bundle-image returns Odd-length string error" [Medium,Triaged] https://launchpad.net/bugs/509562
<cjwatson> if you think it should be in the release and is worth the risk, upload it and we will review it
<cjwatson> as usual, exceptions get harder the closer to release we are
<smoser> thanks.
<apw> davidm, ... did you make it back
<sistpoty|work> didrocks: are you up to handle FFe delegations for netbook again for this cycle?
<davidm> apw, that was "fun" I found out the hard way, first you remove the nvidia driver then you install kernel reboot
<davidm> And no that did not work for me, the pad was still dead
<sistpoty|work> superm1: are you up to handle FFe delegations for mythbuntu again for this cycle?
<superm1> yup
<sistpoty|work> great, thanks! superm1
<apw> davidm, can i get the dmesg off that machine with test kernel no pls.  pastebin perhaps
<ScottL> sistpoty|work,  ping
<sistpoty|work> cody-somerville, mr_pouit: are you up to handle delegations for xubuntu again for this cycle?
<sistpoty|work> ScottL: pong
<didrocks> sistpoty|work: some argued that delegations email wasn't sent, so, are not active. Consequently, I think that's a "no" :)
<ScottL> sistpoty|work, persia tells me that you might be looking for me for ubuntu studio release
<cjwatson> didrocks: he means, were the delegation mail to be sent properly, would you be willing to accept the delegation
<sistpoty|work> didrocks: I'm about to arrange delegations ;)
<davidm> apw, bug amended with my comments
<didrocks> sistpoty|work: cjwatson: oh ok. Of course, I'll be pleased to help there :)
<davidm> apw I'll grab you a dmesg
<sistpoty|work> ScottL: does that mean you'll volunteer? that would be excellent!
<sistpoty|work> didrocks: cool, great!
<didrocks> thanks sistpoty|work :)
<apw> davidm, have you tried the -19 kernel to confirm it works there ?
<ScottL> sistpoty|work, i'm not sure what i'm volunteering for actually :P
<ScottL> sistpoty|work, but as ubuntu studio lead i'll do what is necessary
<apw> davidm, for -19 read 'the previous one'
<davidm> apw dmesg dump attached to bug now
<sistpoty|work> ScottL: if anyone wants to upload a package that falls under the ubuntu studio set, and contains features instead of just bug fixes, you'll be in charge to decide if it should be accepted or not
<davidm> apw nope, I just got this machine yesterday first install had .21
<apw> davidm, could you try and older kerenel please, hallyn is reporting the revert working for him
<ScottL> sistpoty|work, i accept that charge
<davidm> apw if you can aim me at a URL where that kernel is at I'm happy to try
<sistpoty|work> ScottL: excellent, thanks!
<apw> hallyn, was it -22 which broke you?  ie -21 was a good kernel ?
<hallyn> apw: hm, i don't see a -21 in /boot
<hallyn> so 20 was good, and i'm not sure about -21
<sistpoty|work> highvoltage, stgraber: are you up to handle edubuntu FFe delegations for this cycle again?
<apw> hallyn, thats fine, any known good one is fine
<apw> davidm, https://edge.launchpad.net/ubuntu/maverick/+source/linux/2.6.35-20.29 ... click the appropriate arch on the right ....
<sistpoty|work> chrisccoulson: would you be willing to accept the FFe delegation for mozilla releated packages?
<chrisccoulson> sistpoty|work, sure, that's ok
<sistpoty|work> chrisccoulson: cool, thanks!
<sistpoty|work> micahg: would you like to act as additional delegate for mozilla related packages for this cycle again?
<micahg> sistpoty|work: sure :)
<sistpoty|work> micahg: excellent, thanks!
<Sarvatt> davidm: you have a vaio F? I just came across another bug where that machine is requiring i8042.nopnp for the touchpad to work
<apw> davidm, that dmesg is not from the test kerenl, its from an official -21 kerenl
<micahg> sistpoty|work: regarding my own requests, if need be, should I get chrisccoulson to ACK?
<cjwatson> the delegates are additions - the release team can always ack
<sistpoty|work> micahg: yes, please
<micahg> sistpoty|work: k
<highvoltage> sistpoty|work: yes, at this stage things are looking good so I'm happy to report that we probably won't need Edubuntu FFe's this release :)
<davidm> apw whoops, I had already rebooted, I'm about to test 20 will capture dmesg from that when I do
<sistpoty|work> highvoltage: even better, thanks!
<Darxus> Are there any stats on the number of cpu cores in machines running Ubuntu?
<persia> Darxus, No reliable ones: we can't even count installs, let alone be sure of the HW they run on.
<Darxus> Thanks.
<apw> davidm, and if -20 doesn't work either, then does booting the debug kernel with  i8042.nopnp on the kernel command line work
<Darxus> Do you think it would be reasonable to expect people with more than 16 cpu cores to compile their own kernel for maximum efficiency?
<sistpoty|work> oh, gotta run, bbl
<apw> Darxus, i would think its reasonable to expect they might be doing their own tweaking if they are needing a machine that size
<Darxus> apw: Yeah that's what I was thinking, thanks.
<davidm> apw, no love, with 2.6.35-20-generic my mousepad still dead
<davidm> apw so my system apparently is not regressed it's just borked.... :-(
<apw> davidm, and if -20 doesn't work either, then does booting the debug kernel with  i8042.nopnp on the kernel command line work
<apw> could you try either kernel actually with that
<Darxus> My questions were loaded.  The BFS CPU scheduler is faster than the mainline kernel's CFS scheduler for machines with no more than 16 CPUs.  But mainline won't accept BFS because 1) It's slower on machines with more than 16 cores, and 2) They're unwilling to allow a compile time option to select a cpu scheduler because it might devide developement time between multiple schedulers.
<Sarvatt> davidm: i'm seeing multiple bugs from people with vaio F series machines that need to boot with i8042.nopnp for the touchpad to work if you could try that
<davidm> apw tried that last night with a regular kernel and it did not work, nor did the longer version of that help
<apw> i would suggest trying it with the test kernel as well in case you are affected by both
<davidm> did kill my on-screen FN audio volume keys though
<Darxus> The relevant bug is bug #424927.  And the last comment is that BFS is unlikely to be accepted into Ubuntu before mainline.  And mainline isn't going to accept it for agravating reasons.
<ubottu> Launchpad bug 424927 in linux (Ubuntu) "include CK patch set (BFS)" [Wishlist,Confirmed] https://launchpad.net/bugs/424927
<davidm> apw the -22?
<apw> yeah the one i gave you, try booting that with the i8042.nopnp option
<davidm> OK I'll install that again (with headers this time) and add the command line info
<davidm> back in a bit
<apw> thanks
<davidm> apw with -22 and i8042.nopnp mousepad works :-)  And I still have my FN key for audio working too.
<davidm> Sarvatt, where are you seeing folks talking about the vaio F? I still have one more bug to sort my mic does not work.  Thanks
<Sarvatt> davidm: what does sudo dmidecode -s system-product-name give for your machine?
<Sarvatt> davidm: https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/638219 is one of them
<ubottu> Launchpad bug 638219 in xserver-xorg-input-synaptics (Ubuntu) "Touchpad does not work on Sony Vaio VPCF12M1E" [Undecided,New]
<apw> davidm, ok great ... Sarvatt do you have a bug number for the i8042.nopnp jobbie ?
<davidm> Sarvatt, VPCF1290X
<Sarvatt> there are a ton of VPC-F series and it looks like not all of them are affected because hallyn has one too and doesn't need it
<Sarvatt> which is going to making quirking fun :)
<apw> Sarvatt, is hallyn ok if he does supply it, that would make the quirk easier
<davidm> apw am I ok to keep using the test kernel for now?  I really like having my mousepad working ;-P
<Sarvatt> apw: here is another with the same model davidm has from JFo - https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/641324
<ubottu> Launchpad bug 641324 in linux (Ubuntu) "Sony Vaio touch pad is not working" [Undecided,New]
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.searchtext=vaio+touchpad&orderby=-importance&search=Search&field.status:list=CONFIRMED&field.status:list=FIXCOMMITTED&field.status:list=INCOMPLETE_WITHOUT_RESPONSE&field.status:list=INCOMPLETE_WITH_RESPONSE&field.status:list=INPROGRESS&field.status:list=NEW&field.status:list=TRIAGED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
<Sarvatt> almost all vaio F series
<davidm> the bug JFo filed the bug for me, LP was timing out
<Sarvatt> ah
<ogasawara> davidm: care to post a quick comment to bug 641320 that the test kernel indeed does work for you
<ubottu> Launchpad bug 641320 in linux (Ubuntu) "Touchpad is not working since last kernel update in maverick" [Critical,Triaged] https://launchpad.net/bugs/641320
<davidm> ogasawara, done
<davidm> now if I can find something on my internal mic and external mic in not working I'm gold
<davidm> can't use mumble without a mic of some sort
<mathiaz> rmcbride: hi - re bug 639768
<ubottu> Launchpad bug 639768 in samba (Ubuntu Maverick) "[Maverick] Samba process gets hung on maverick update - waiting on cups to start" [High,Fix released] https://launchpad.net/bugs/639768
<mathiaz> rmcbride: where does it hang?
<rmcbride> mathiaz: at "Generating /etc/default/samba" near as I can see after 3 attempts
<rmcbride> mathiaz: how can I help get more detail?
<mathiaz> rmcbride: is there a "start smbd" process on the system?
<rmcbride> mathiaz: Hmm, actually not in this case (it was doing that before I think) seems to be samba.postinst configure in two processes
<mathiaz> rmcbride: ok - so you're probably seeing a different bug/issue
<rmcbride> mathiaz: oh goodie :)
<davidm> apw thanks for the help, and I think I found a fix for my mic but it won't be built for about 6 hours yet
<rmcbride> mathiaz: I'll amend my comments in that bug and check for/file a new one as needed.
<mathiaz> rmcbride: great - thanks
<Willyant> I recently upgraded to Maverick and these are the bugs ive found when installing: Samba's "nmbd" process cannot be killed so i had to manually kill it using gnome-system-monitor.
<Willyant> The postinst script therefore fails.
<Willyant> My updatemanager crashed when i clicked on it as well.
<Willyant> (The icon)
<Willyant> Do i have to login to send the apport bugreports or is that only if i want to discuss them ?
<micahg> Willyant: bug 639768
<ubottu> Launchpad bug 639768 in samba (Ubuntu Maverick) "[Maverick] Samba process gets hung on maverick update - waiting on cups to start" [High,Fix released] https://launchpad.net/bugs/639768
<Willyant> Thanks micahg
<Willyant> The last poster in that thread has narrowed it down somewhat "Actually it seems to be hanging during 'samba.postinst configure' which is a different thing apparently."
<Willyant> The bug is in that package "samba" for ubuntu must kill "nmbd" but fails since itll not die. Maybe the smbd process keeps it alive and so smbd must be killed first ?
<micahg> Willyant: well, there could be more than one issue, IIRC the upgrade to ubuntu7 fixed it for me
<Willyant> Hehe, theres an ubuntu7 ?
<micahg> Willyant: 2:3.5.4~dfsg-1ubuntu7
<Willyant> ah, the samba package you mean ?
<micahg> yes
<Willyant> Ok, but i also tried updating to the new samba version and it also hung at postinst
<Willyant> Ill see what version i have now
<micahg> Willyant: did you upgrade cups as well?
<Willyant> I upgraded everything, or tried to. Theres nothing more to install now.
<Willyant> I think samba came before cups though...
<Willyant> Cups should come before samba because its a dep of samba (if it matters)
<Willyant> But thats not the problem.
<Willyant> try to kill "nmbd", youll have to do it quite a few times before it dies
<Willyant> Mine wont die if i issue a "killall -9 nmbd" for atleast 20 tries
<micahg> Willyant: why not just stop it?
<micahg> wfm
<Willyant> Something is restarting it. Yep, ill have a look at the init script to see whats going on
<Willyant> Aha, its also handeled by upstart
<Willyant> So the postinst script could be designed only for sysinit
<Willyant> Possible reason No1 :)
<Willyant> micha: "stop nmbd" in the postinst for samba kills it right away.
<Willyant> micha: Maybe you can add that in the thread ? -> "stop nmbd" in the postinst for samba kills it right away. Ive got to get coding.
<Willyant> Also put that "Using killall -9 or kill -9 pidof nmbd" wont kill it anymore.
<Willyant> Seems to also be an upstart bug to me. It should honour kill commands.
<mathiaz> Willyant: if you have issue with nmbd it's not bug 639768
<ubottu> Launchpad bug 639768 in samba (Ubuntu Maverick) "[Maverick] Samba process gets hung on maverick update - waiting on cups to start" [High,Fix released] https://launchpad.net/bugs/639768
<mathiaz> Willyant: please open a new bug rather than tagging along exisint Fixed Release bug
<Willyant> The normal PowerOff button has changed to a wall-eletricity switch. Hard to find and is different from all other Off-Switches. (Minor detail though)
<mathiaz> rmcbride: ^^ was Willyant report similar to what you've experienced with the samba stalled upgrade?
<rmcbride> mathiaz: reading scrollback
<rmcbride> mathiaz: yes, and in fact the comment referred to regarding "actually it seems to be..." was by me.
<Willyant> Nice work!
<Willyant> mathiaz: Thanks, but i had hoped someone could pitch in my experiences and atleast a working solution to the problem.
<rmcbride> mathiaz: I had written #641519 on the new behavior
<mathiaz> rmcbride: great thanks
<Willyant> It seems to be upstart that refuses to let it be killed by signals.
<rmcbride> ah
<rmcbride> that fits
<Willyant> Yep.
<mathiaz> Willyant: is bug 641519 what you're experiencing too?
<ubottu> Launchpad bug 641519 in samba (Ubuntu) "samba install hangs in 'samba.postinst configure'" [Undecided,New] https://launchpad.net/bugs/641519
<mathiaz> is there any messages in /var/log/samba/log.nmbd?
<mathiaz> (as it seems that it is nmbd that blocks)
<rmcbride> checking
<Willyant> Nope, the issues i had where all releated to a perl/dpkg command that hung because nmbd refused to be killed.
<rmcbride> nothing here either
<mathiaz> rmcbride: hm ok.
<Willyant> It hung the entire install process so thats not so good.
<mathiaz> rmcbride: are you able to reproduce it?
<Willyant> Otherwise everything was fine at install
<mathiaz> rmcbride: if so, could you add a 'set -x' in samba postinst script?
<mathiaz> rmcbride: it should be in /var/lib/dpkg/info/samba.postinst
<rmcbride> mathiaz: Yep. every time. I'll do that now
<Willyant> He can check that nmbd refuses to be killed
<Willyant> :)
<Willyant> Thanks!
<mathiaz> rmcbride: that way we should be able to see where the postinst script hangs
<Willyant> I saw that in gnome-system-monitor (enable the command view)
<rmcbride> mathiaz: well... in order to get back to a state where I can install, I have to apt-get purge samba, which nukes the samba.postinst that I edited :/
<rmcbride> ah Willyant I'll look at that
<Willyant> Good.
<mathiaz> rmcbride: hm right.
<rmcbride> well this is frustrating. nmbd is not active on my system.
<Willyant> nmbd -D
<Willyant> cjwatsons comments about it beeing a cups error seems entirely wrong. If you kill something with a signal of "-9" it should just die, always.
<mathiaz> rmcbride: you may wanna look into /var/log.samba/log.nmbd
<mathiaz> Willyant: you're seeing a different bug
<rmcbride> mathiaz: no such animal in this case
<Willyant> Checking...
<rmcbride> I have /var/log/samba/log.everylastmachineI'vesmbconnectedto
<rmcbride> but no nmbd
<Willyant> #639768 (Sorry cjwatson) ... wrong bug
<mathiaz> rmcbride: hm - I can properly install samba on a test vm here
<persia> mathiaz, Can you upgrade it?
<mathiaz> persia: I'm gonna try that now
<Willyant> can anyone paste the output of that samba postinst ?
<Willyant> Or tell me how i can obtain it...
<mathiaz> Willyant: this is what I see on the terminal: http://paste.ubuntu.com/495508/
<mathiaz> Willyant: it's a successfull install though
<Willyant> Im very sure it tries to kill the nmbd process by a signal but that doesnt work because upstart refuses that and or just restarts it again
<mathiaz> rmcbride: from which version were you trying to upgrade from?
<rmcbride> Willyant: here's my output with the hung install http://paste.ubuntu.com/495509/
<mathiaz> rmcbride: you should be able to get the information from /var/log/dpkg.log
<rmcbride> mathiaz: at first I was trying to upgrade yesterday
<rmcbride> mathiaz: looking
<rmcbride> mathiaz: today I'm just trying to install it after purging
<mathiaz> rmcbride: I'd like to know the last two versions of the samba package that have been installed
<mathiaz> rmcbride: so that I can reproduce an upgrade
<Willyant> Hmm, are old apport things stored somewhere ?
<rmcbride> mathiaz: 2010-09-10 16:36:30 status half-installed samba-common 2:3.5.4~dfsg-1ubuntu3
<rmcbride> mathiaz: that may not be the last though, still looking
<Willyant> Aww! The apport bugreport has been converted to my language so its useless for you
<Willyant> (Or... ehem: /var/crash/samba.0.crash)
<rmcbride> mathiaz:  2:3.5.4~dfsg-1ubuntu4 is the version fron yesterday
<rmcbride> mathiaz: or rather Wednesday
<Willyant> Thats me killing the post installation script though
<mathiaz> rmcbride: so IIUC you tried to upgrade from ubuntu4 to ubuntu7
<mathiaz> rmcbride: ubuntu4 was working correctly
<rmcbride> mathiaz: ubuntu5
<mathiaz> rmcbride: and the upgrade to ubuntu7 fails
<mathiaz> rmcbride: ah ubuntu5
<rmcbride> mathiaz: I hadn't gotten close enough int he log
<rmcbride> ubuntu4 was back on the 10th
<Willyant> Tags: maverick
<Willyant> Title: update-manager crashed with TransactionFailed in _run()
<mathiaz> rmcbride: so no 2:3.5.4~dfsg-1ubuntu6 ?
<Willyant> Thats the update icon i pressed
<Willyant> Its a segfault btw
<rmcbride> mathiaz: I do see ubuntu6 in the log from yesterday, but hte behavior was no different (in that the install hung)
<mvo_> Willyant: could you please report a bug?
<mathiaz> rmcbride: ok thanks
<mvo_> Willyant: about the u-m crash with the backtrace?
<mathiaz> rmcbride: I'll try to reproduce it here
<Willyant> mvo_: Yes, i have the backtrace
<rmcbride> mathiaz: OK. If I can help in any other way, do re-ping me. I'm highly motivated to help fix this :)
<mathiaz> rmcbride: cool - thanks!
<Willyant> mvo_: I can ul it so you can get it if you want ?
<mvo_> Willyant: please do , the full backtrace is important to fix the bug
<Willyant> Will do, hold on
<mvo_> something like paste.ubuntu.com is fine as well for now, but a real bugreport is better
<Willyant> Do with it as you like: http://mange.dynalias.org/linux/misc/ubuntu_Maverick_Update_manager_Crash/_usr_bin_update-manager.1000.crash
<mathiaz> rmcbride: is cups running on your system as well?
<rmcbride> mathiaz: it is
<mvo_> Willyant: yes, thanks
<mathiaz> rmcbride: ok - thanks
 * mathiaz installs cups as well
<Willyant> Np
<sistpoty> hey siretart, around? what do you think about bug #588203?
<ubottu> Launchpad bug 588203 in emacs23 (Debian) "[FFe] Please merge emacs23 23.2+1-4 (main) from Debian unstable (main)" [Unknown,New] https://launchpad.net/bugs/588203
<sistpoty> (I just don't know enough about the state of rdepends nor about emacs in general *g*)
<ScottK> Maybe barry knows.  IIRC he's of the church of emacs.
<sistpoty> ^^
 * barry wakes up
<barry> yep, i heart emacs
<barry> sistpoty: you want me to look at that bug?
<sistpoty> barry: yes, was about to write that :)
<sistpoty> barry: please keep a special look out on (build)-rdepends
<barry> :) looking...
<barry> sistpoty: you mean that differ from the current package?
<sistpoty> barry: or could be broken by the update
<barry> sistpoty: gotcha
<barry> sistpoty: i'll investigate and comment on the bug, okay?
<sistpoty> barry: that'd be great :)
<Willyant> mvo_: Another suggestion is to recompile gadmin-dhcpd with ./configure .... DHCPD_CONF="/etc/dhcp3/dhcpd.conf" instead of what it has now: DHCPD_CONF="/etc/dhcp3/dhcpd/dhcpd.conf" (Im not sure how this happened)
<sistpoty> (if (true) (print "sistpoty no good at emacs-lisp) (print "upgrade rejected"))
<Willyant> Hmm, i have won something called The Famous Why award. Is that any cool ? :)
<barry> this one is interesting: * Use -O1 rather than -O2 on ia64. Fixes a build failure (looks
<barry>      like a broken byte compiler) with newer versions of gcc
<barry>      (c.f. #207580).
<barry> maybe not related, but we've just gotten reports today of python being broken by some versions of gcc on 10.04.1
<sistpoty> barry: I doubt ia64 should be much of a problem :)
<Willyant> barry: Optimisations other then those the sources are packaged with is always risky.
<sistpoty> (of course if it's a genuine gcc problem not only on ia64, than that's very noteworthy)
<barry> Willyant: yep, and it's probably not related, it just caught my eye ;).  we don't know enough about the python problem yet, but we think it's gcc related.  let me see if i can dig up the python issue
<Willyant> Okies
<barry> http://bugs.python.org/issue9880
<barry> gcc 4.6 == bad apparently
<barry> doesn't affect mav, but it's still interesting
<geser> sistpoty: you sure you used enough brackets? :)
<Willyant> barry: Is this the python version used ?:  /usr/local/src/python-2.7... or it it a case of mixed /usr/lib links because its installed in a different location ?
<Willyant> Highly probable
<barry> Willyant: OP was building python 2.7 from upstream svn head.  there was an email thread on python-dev about it, and i could not reproduce no matter what pythons i had installed locally.
<barry> Willyant: i think the mixture isn't the problem.  python should be good about isolation there.  at least, it was not a prob for me
<Willyant> I see. Also watch aout for version changes, because pythons installer isnt exactly very good :)
<barry> ;)
<barry> doko has actually made py2.7 available in mav, which is nice (not officially supported though - wait til natty!)
<sistpoty> geser: no idea, I don't have vim bracket highlights in kvirc :P
<geser> sistpoty: all I know about lisp is that you need many, many brackets :)
<mr_pouit> sistpoty: yeah, sure (about xubuntu delegation)
<sistpoty> mr_pouit: cool, thanks!
<sistpoty> geser: heh
<Willyant> Ive built many B/LFS systems and i see the weaknesses in python. One is that for each new version it installs to different dirs and sometimes its failed to symlink. Not to speak of the addon things for python that must be recompiled to be linked to the new python directory. Seems like a pain.
<ScottK> It is.  Python 3 will be better.
<Willyant> gtk-clutter was also a pain to be fair
<Willyant> Good!
<barry> what ScottK said
<Willyant> Can the same packages be recompiled again once frozen ?
<sistpoty> Willyant: sure
<Willyant> Good... See my post on gadmin-dhcpd above^
<Willyant> Steps to reproduce the mal configured path: 1. Install and lauch gadmin-dhcpd 2. Watch it suggest the wrong default dhcpd config dir.
<Willyant> So the users will need to go into the settings and select a new path. Irritating.
<sistpoty> Willyant: I guess "--sysconfdir=/etc/dhcp3" might be at fault?
<sistpoty> (together with no additional flags passed)
<Willyant> Yep, it should be "/etc" and this should be set to the conf path DHCPD_CONF="/etc/dhcp3/dhcpd.conf"
<Willyant> Just change that conf path and set sysconfdir to /etc
<Willyant> ### Debian/Ubuntu/etc ###
<Willyant> # ./configure --prefix=/usr --sysconfdir=/etc \
<Willyant> # --localstatedir=/var/lib/dhcp3 --sbindir=/usr/sbin \
<Willyant> # DHCPD_CONF="/etc/dhcp3/dhcpd.conf" \
<Willyant> # DHCPD_BINARY="dhcpd3" \
<Willyant> # SYSINIT_START_CMD="update-rc.d -f dhcpd defaults" \
<Willyant> # SYSINIT_STOP_CMD="update-rc.d -f dhcpd remove" &&
<Willyant> # make && make install
<Willyant> Sais so in the package as well.
<Willyant> Latest is: http://mange.dynalias.org/linux/gadmin-dhcpd/gadmin-dhcpd-0.4.9.tar.gz (Also asks to update remote failover pool configurations:)
<sistpoty> Willyant: hm... not too sure if this won't break the upgrade path: configure:default_settings_path=`eval echo $sysconfdir`"/gadmin-dhcpd"
<sistpoty> Willyant: how about just adding DHCPD_CONF="/etc/dhcp3/dhcpd.conf"?
<Willyant> eval echo $sysconfdir will evaluate to /etc (Or should)
<Willyant> sistpoty: Will be much better as itll work out-of-the-box then.
<sistpoty> Willyant: sure it *should*, but did it for the last release?
<Willyant> :)
<Willyant> Show the configure script for gadmin-dhcpd...
<Willyant> Or a cmd to let me view it
<sistpoty> Willyant: dget -x http://archive.ubuntu.com/ubuntu/pool/universe/g/gadmin-dhcpd/gadmin-dhcpd_0.4.7-1.dsc (for lucid)
<Willyant> wget :)
<Willyant> sistpoty: E_NO_CONFIGURE_PARAMS :)
<sistpoty> Willyant: look at debian/rules
<Willyant> Url ?
<Willyant> The packager is doing military service atm :(
<sistpoty> sistpoty: just call dget (as found in devscripts)... it will download and extract the package
<sistpoty> (it's not a typo for wget :P)
<Willyant> Aha! :)
<Willyant> E_NO_SUCH_PKG
<sistpoty> hm? you'll need the url to the .dsc file as argument to dget
<Willyant> E_NOT_INSTALLED && E_NO_SUCH_PACKAGE
<Willyant> "dget"
<sistpoty> Willyant: devscripts
<Willyant> Thx
<cjwatson> Willyant: FYI, upstart doesn't and can't affect how a process deals with signals sent by kill
<Willyant> Something is ignoring the kills signals it recieves, maybe smbd restarts it ?
<Willyant> Or its a bug in nmbd
<cjwatson> the only way that upstart is involved in that is that it becomes the parent of processes which don't have a parent of their own
<barry> interesting.  sbuild is barfing on trying to install mailx package
<cjwatson> I have no idea, just letting you know that it's quite inaccurate to point at upstart for this
<cjwatson> and regarding cups, that wasn't a guess, we had debugged that problem very precisely.  I assume you're seeing something else.
<Willyant> cjwatson: Good to know. Then the nmbd process itself will not accept a kill signal or the smbd will start it up again.
<cjwatson> processes are entitled to wait for a while when they receive SIGTERM
<Willyant> But what kill signal does upstart emit ? (stop nmbd) ?
<Willyant> SIGKILL is instant
<Willyant> give or take a few microseconds
<cjwatson> assuming that the process isn't in uninterruptible sleep
<Willyant> Yeah.
<cjwatson> SIGKILL is an unfriendly way to stop a process anyway
<cjwatson> postinst scripts shouldn't use it
<Willyant> Its there because its a --force'd kill.
<Willyant> It should override everything as far as the kernel is conserarned
<cjwatson> no
<Willyant> It should override everything as far as the kernel is consearned
<cjwatson> you need a copy of Stevens :)
<cjwatson> anyway, upstart sends SIGTERM, waits a while, then sends SIGKILL if it has to
<Willyant> I am a copy of brilliance. I feel no need to know more copies of excellence ;)
<Willyant> Thanks!
<Willyant> So, then somehow SIGKILL doesnt work on "nmbd"
<cjwatson> stop(8) is probably the right way for the postinst to stop nmbd, unless there's some reason to do otherwise
<Willyant> Good, we have narrowed it down
<cjwatson> but if SIGKILL doesn't work, then the process is in uninterruptible sleep and there is no guaranteed way to stop it, at all
<Willyant> Naah, it must adhere to the KILL signal
<cjwatson> wrong
<cjwatson> guess you've never used NFS :)
<Willyant> I have :)
<cjwatson> then you've almost certainly encountered situations where the NFS server fails and all the clients go into uninterruptible sleep
<Willyant> Somewhat a mess of about 10 services (daemons including portmap)
<Willyant> That need to be started in order
<cjwatson> unless your experience is recent enough that all the mounts were with intr
<Willyant> "If something isnt restarting nmbd, like upstart then its a bug in samba"
<Willyant> Agreed ?
<Willyant> "Hmm, it could also be smbd that keep-alives the nmbd process"
<cjwatson> no, that's not a given either
<cjwatson> kernel bugs can leave a process stuck in uninterruptible sleep
<Willyant> Tell me what you think then ... Nope, thatd be a nmbd bug as well.
<Willyant> Youre talking zombies, this is not the case. Checked that.
<cjwatson> uninterruptible sleep != zombie.
<cjwatson> please, find a copy of "Advanced Programming in the Unix Environment" before using these terms
<Willyant> If i make a program and it goes into what you call "Uniterruptable sleep" itll be an infinite timout value or a spinloop.
<Willyant> Dont need one. I have several C books
<cjwatson> they're not telling you the right things; this is I/O wait *inside the kernel*
<cjwatson> it is a detail of Unix, not a detail of C
<Willyant> A linger you mean ?
<cjwatson> OK.  So.  Where is the evidence that the samba postinst is trying to kill nmbd?  It's not clear from your bug report.
<cjwatson> there's no process tree or anything in there, or strace of what the postinst is doing
<Willyant> Well, i tried to do as apport suggested. I opted to send a bugreport for that too, but im not sure it got thru because i was presented with a launchpad login. Forgot the user/pass
<cjwatson> the script that emits the last message in your bug report does not even try to stop nmbd, although it does try to start it
<cjwatson> I'm reading bug 641519
<sistpoty> cjwatson: btw, I think that bug #544139 might affect me too (xdm + fluxbox). Strange thing is that sometime if things get screwed up and I login, start konsole then any command seems to be mirrored to the first getty (and hence executed twice), howerver the first getty captures the plain output (e.g. of ssh-add's password, not a thing I like to have in any log)
<ubottu> Launchpad bug 641519 in samba (Ubuntu) "samba install hangs in 'samba.postinst configure'" [Undecided,New] https://launchpad.net/bugs/641519
<ubottu> Launchpad bug 544139 in consolekit (Ubuntu Lucid) "Active VT tracking can fail at startup" [High,In progress] https://launchpad.net/bugs/544139
<rmcbride> cjwatson: 641519 was written by me
<cjwatson> sistpoty: right, it *is* on my to-do list but other things keep bumping it off
<sistpoty> cjwatson: of course it might be an entire separate bug though
<cjwatson> rmcbride: ah
<cjwatson> Willyant: ok, so how did you arrive at the conclusion that it's trying to kill nmbd?
<sistpoty> cjwatson: if I can help in any way (unless it involves the kernel), feel free to ask :)
<cjwatson> sistpoty: an extra four hours per day would be nice
<cjwatson> sistpoty: or maybe babysitting
<cjwatson> :-)
 * sistpoty changes the time zones with his magic hand :P
 * Willyant Goes away like Obi Wan - I guess the bug wasnt important :)
<cjwatson> Willyant: um?  I'm trying to get to the bottom of what you reported
<cjwatson> but it's important to do it step-by-step and logically
<cjwatson> a good start would be to at least see a transcript of what's happening in your case
<Willyant> Well, a dpkg command was run as seen by a launched instance of gnome-system-monitor with the process command column enabled and i thusley saw: perl something .. dpkg ... nmbd stop/wait something. When i manually killed nmbd the install process continued.
<cjwatson> no terminal output from dpkg?
<Willyant> this stop/wait comes from upstart
<cjwatson> if you mean "stop/waiting", that actually means that as far as upstart is concerned the process isn't running and nothing has told it to start it
<Willyant> I think i have submitted 2 apport bug reports, unless you have to have a valid login to actually submit those ?
<cjwatson> you need a valid login to submit bugs to Launchpad, yes
<Willyant> Crud, ok. Then ive only shown you the bugreport on the crashing update manager
<Willyant> I can probably reproduce the thing, hold on...
<Willyant> apt-get remove samba ; apt get install samba and this is what i see to begin with: "smbd start/running, process 4133
<Willyant> start: Job failed to start"
<Willyant> smbd isnt running after a reinstall
<Willyant> ehm, i mean "nmbd"
<Willyant> nmbd -D
<Willyant> root      4172  0.0  0.2  12268  1476 ?        Ss   23:38   0:00 nmbd -D
<Willyant> root      4174  0.0  0.1   5168   740 pts/1    S+   23:38   0:00 grep nmbd
<Willyant> Then its running
<cjwatson> did the samba installation complete?
<Willyant> Yes, but previously perl and dpkg tries to run postinst and fails. Thats for sure.
<cjwatson> if not, was it with a hang, and if not a hang, was there an error message after "start: Job failed to start"?
<cjwatson> it's best to post an exact transcript to e.g. paste.ubuntu.com
<cjwatson> or pastebin.com or whatever floats your boat
<Willyant> StÃ¤ller in samba (2:3.5.4~dfsg-1ubuntu7) ...
<Willyant> update-alternatives: anvÃ¤nder /usr/bin/smbstatus.samba3 fÃ¶r att tillhandahÃ¥lla /usr/bin/smbstatus (smbstatus) i automatiskt lÃ¤ge.
<Willyant> smbd start/running, process 4133
<Willyant> start: Job failed to start
<cjwatson> please don't ever paraphrase error messages, it's the number one way to get developers not to look :)
<Willyant> Dont translate bash then :)
<cjwatson> is that the last text on the screen?  is it hung at that point?
<Willyant> Nope, it didnt hang
<cjwatson> so what do you mean by "perl and dpkg tries to run postinst and fails"?
<cjwatson> if the installation completed, then they succeeded
<Willyant> So the new version seems to be ok, but not the current Beta of Maverick. Checking to see if samba.conf is the same
<Willyant> smb.conf is the same.
<Willyant> So the new samba version seems to be ok.
<cjwatson> if the new version is working, great, we don't have to worry.  It will supersede the beta
<cjwatson> we do know that we've fixed bugs since beta ;-)
<Willyant> Good, but why wasnt this picked up before beta release ? /Just wondering
<cjwatson> that I can't tell you
<Willyant> Ok, can you diff the postinst scripts with current and prev versions for me ?
<cjwatson> er, I suppose I could, but it's already quarter-to-eleven on a Friday night for me.  You could do it yourself :-)
<Willyant> cjwatson: Okies, go out and party! :)
<cjwatson> sadly, I have three more bugs to fix
<Willyant> Ok, well we have solved this i think. It would have been a bad one.
<Willyant> cjwatson: Saw the crash i posted on update manager ?
<cjwatson> no
<cjwatson> not really likely to be involved in that
<Willyant> Here you go: http://mange.dynalias.org/linux/misc/ubuntu_Maverick_Update_manager_Crash/_usr_bin_update-manager.1000.crash
<Willyant> Okies
<Willyant> I just clicked the icon
<cjwatson> Ubuntu is a big project, not every developer does everything
<Willyant> But some can tell others to fix things to make things solid
<Willyant> I like all dists. I dont like bugs.
<cjwatson> I could, but the developer working on update-manager is already working as hard as he possibly can
<Willyant> Ok, good.
<Willyant> I like the new icon theme in Maverick, but the "Shutdown-switch" is far worse then the old one that was actually very good.
<Willyant> Melts into the panel and becomes almost invisible.
<Willyant> In contrast, the old switch had a nice graphical layout, but was a few pixels too high and wide.
<Willyant> But waay better
<Willyant> Show Icons in applications is back (Very good). I didnt like that.
<Willyant> cjwatson: Cant there be an "Anonymous submitter" for the apport bugs ?
<cjwatson> no, because then we would be unable to contact submitters for clarification
<cjwatson> bugs aren't fire-and-forget kinds of things
<cjwatson> we often need to find out more detail about something or other that apport doesn't capture
<Willyant> But they are generated by apport and i think it could be good to read if many applies to the same package.
<Willyant> Otherwise discarded
<Willyant> Make anonymous bugreports, have an evaluation script see if many are the same and then move to anonymous-reports
<Willyant> Im making a gui for torque cluster atm. Would this be a welcome addition granted its good ?
<Willyant> cjwatson: NFS guis are hard to make because of the many portmapper binaries needing to be started first. What are those used for ?
<cjwatson> no idea
<Willyant> Its the only application that requires them
<Willyant> Okies
<cjwatson> I try to avoid knowing about its intricacies
<Willyant> xinetd is also useless and i think it should be phazed out by patching the last thing requireing it (tftpd)
<Willyant> Or just run: in.tftpd ... There no server requires it.
<Willyant> It was meant to save a few kb of ram, but it makes servers suffer because they cant use all the features then.
<Willyant> (When not used)
<Willyant> And the servers get a bit slower
<Willyant> In terms of usability xinetd have done more bad then good.
<Willyant> cjwatson: This comes from 15 years of coding with many server developers.
<cjwatson> I'm not involved with that
<cjwatson> I do installer and bootloader work
<cjwatson> the only reason I chipped in on your samba problem was because you mentioned my name in connection with it
<Willyant> cjwatson: Do you have an oppinion on the matter ?
<cjwatson> no
<Willyant> cjwatson: Yes, i noticed that. Ok
<Willyant> cjwatson: Who can i speak to for dropping the obsolete xinetd package ?
<cjwatson> file a bug
<cjwatson> IRC is a hopeless way to report bugs, generally
<Willyant> For a 386 computer it could possibly be of use
<Willyant> Naah :)
<Willyant> Ive done it for many many years. Someone is always listening
<cjwatson> if you like having your bugs forgotten because the person who might deal with it happens not to be around, it's great
<Willyant> .
<cjwatson> please do not use this channel as a bug reporting channel
<cjwatson> we don't mind the odd comment alerting us to something serious
<cjwatson> it's primarily for discussion among developers
<cjwatson> if it became a bug reporting channel we would never get anything done
<Willyant> So developers doesnt like to fix bugs ?
<Willyant> Crusial bugs
<cjwatson> we are entirely happy to fix bugs reported through the system designed to help us track them
<Willyant> Aha, so then you think i cant report bugs on irc at all ? /We can talk about other things if you like. What do you suggest ?
<Willyant> Camping experiences ?
<Willyant> :)
<cjwatson> you don't need to talk about anything if you have nothing on-topic to say.
<cjwatson> you are dangerously close to being asked to leave.
<Willyant> My name is danger in that case. Now get back on topic please
<cjwatson> we welcome bug reports via our bug tracking system.
<Rankor> "Please see that not everyone going against your beliefs is a troll"
<Rankor> cjwatson
<cjwatson> this has nothing to do with going against my beliefs; it is to do with retaining the purpose of the IRC channel
<Rankor> "Development of Ubuntu"
<cjwatson> and I can't say I'm hugely impressed with nick-morphing either
<sistpoty> Rankor: that's a development channel nonetheless, we *need* to keep the discusssion more or less focussed on development
<cjwatson> you were advised that bug reports should go to the bug tracking system, multiple times
<Rankor> Im not sure where i digressed
<cjwatson> it's a perfectly simple thing
<cjwatson> Ubuntu is far too big a project for bugs to be reported just as a single giant stream of stuff on IRC
 * Rankor goes Obi Wan ... And like that... Pfsst
#ubuntu-devel 2010-09-18
<james_w> if there are any buildd admins around could you please bump the priority of https://edge.launchpad.net/ubuntu/+source/initramfs-tools/0.98.1ubuntu4/+build/1964533 as it breaks installing initramfs-tools on armel, and hence building images
<StevenK> james_w: Bumped.
<james_w> merci
<TheMuso> cjwatson: Good to know for the future, thanks.
<SpamapS> ugh.. bzr branching samba is.. painful
<SpamapS> 238964kB   372kB/s / Fetching revisions:Inserting stream:Estimate 110480/110699
<SpamapS> 165M	.bzr
<SpamapS> oi!
<persia> #bzr can probaby help more with data analysis to improve performance.  We just use what they send us.
<SpamapS> Its an impressive amount of data.. :-P
 * SpamapS hopes to only do this once ;)
<lifeless> package or upstream?
<lifeless> its a big tree (its big in git too)
<lifeless> SpamapS: how are we doing perf wise with Launchpad, a couple of months down the track.
<lifeless> from your perspective-as-user
<lifeless> persia: and you, any thoughts?
<persia> I get significantly more timeouts, to the point that I avoid using LP if there is another way to get the same data, but pages that do render render considerably faster.
<SpamapS> lifeless: most things are better. converting bugs to questions still stinks. ;)
<lifeless> yes
<persia> I'm really looking forward to the performance enhancement program ending, under the (perhaps false) expectation that this will lead to an increase in the timeout window for stuff that takes too long.
<lifeless> its being worked on , there is a patch atm to do the email component async from the web xact
<lifeless> persia: no, the timeouts are going to be clamped at 5 seconds
<SpamapS> I haven't gotten timeouts regularly on anything except converting bugs to questions, which I only do about once a month anyway.
<persia> Oh :([
<lifeless> persia: long transactions cause gc issues in the db server, locking issues (when the xact is a mutating one) and can cause cascading failures.
<lifeless> persia: the solution to things that are slow is to make them fast.
<persia> lifeless, Fair enough: now make it fast enough that I don't care that you clamp it at 5 seconds :)
<SpamapS> lifeless: your message about the problem of putting 1000 entries ina  todo list had me wondering if a unique key couldn't be used to coalesce those notifications.
<lifeless> persia: we'll be able to make exceptions when something goes screwy to raise the timeout, but those will be rare and temporary.
<SpamapS> lifeless: oh and to answer your first question, this is branch lp:ubuntu/samba
<SpamapS> 369M	.bzr
<SpamapS> final size of the shared repo
<lifeless> SpamapS: does it have full upstream history ?
<lifeless> persia: thats the goal; we're aiming for a <1 second response for nearly all (99%) of backend renders
<persia> lifeless, Things that I don't even bother trying to do anymore include: 1) filing apport bugs with lots of data (limited data is fine), 2) searching for anything at all, 3) attempting to look at "more data" beyond what I get by default (which usually isn't sufficient for the sorts of auditing I want to do)
<lifeless> persia: the first stage is 5 seconds, at which point the hard timeout will stop being lowered.
<SpamapS> lifeless: first entry is timestamp: Fri 2004-10-15 14:31:58 +0200
<lifeless> persia: search shouldn't timeout at all except for one case : Distribution:+search
<lifeless> SpamapS: guess not
<persia> I think that's a really good plan, and likely to get better results than turning off the timeout again once some performance work has been done.
<lifeless> persia: apport bugs is a high pri one, I mailed the list about the root cause today in fact
<lifeless> its just faulty programming, not intrinsically a lot of work though, so it can be fixed.
<persia> lifeless, search *shouldn't* timeout? Hrm.  I'll have to try that again.  Lots of times if I'm searching for something very specific, I used to have >30 second response times, and since the limit, I get nothing.  I'll try again, and report the results.
<lifeless> https://bugs.edge.launchpad.net/launchpad-project/+bugs?field.tag=timeout
<lifeless> master timeout list
<StevenK> It would be amusing if that page timed out
<lifeless> persia: search for 'search' in the text of that page you can see the known search isues
<lifeless> and I think I found a dup :)
<persia> Won't: it's already finding nearly the limit of the available window: one would have to report lots more bugs and do extensive URL hackery to get a timeout.
<StevenK> persia: I know that it wouldn't time out, I was just chuckling and thinking it would be ironic
<lifeless> we'll reject requests for too large a batch size anyway
<persia> lifeless, I'll definitely give it a try, but not likely before release, as my list of things I *really* want to get done isn't going down nearly as quickly as I'd prefer.
<persia> StevenK, It would be wonderfully ironic, yes.
<persia> lifeless, That's mixed news to me: sometimes I really want lots of rows (yes, I know, go use the API)
<lifeless> persia: sure, just saying if you get a search timeout: check that listing, if its not one of the search bugs on that page, file a bug.
<lifeless> persia:
<lifeless> bah
<lifeless> 300 is the cap
<lifeless> I think this is a bit noddy
<persia> I'll definitely do that.  From today, I'll put "searching on launchpad" back in my list of potentially acceptable actions to perform.
<lifeless> its a proxy for 'do not let users use too much resources'
<lifeless> but we have a more direct measure - the hard timeout
<persia> really, with the API in place, anything more than ~150 isn't likely to render usefully for anyone.
<lifeless> so I think we should consider remove it and just timeout if someone tries too much (and programatically ignore the errors)
<persia> Ah, if the only reason for the limit is to prevent timeouts, yeah, that should be dropped.
<lifeless> its the only reason i can think of
<persia> Indeed: helps identify things better that way.
<lifeless> certainly not aesthetics
<persia> If there are any other little "um, well, maybe this will make things faster" heuristic limits, those probably ought be removed as well.
<lifeless> persia: that limit isn't to make it faster; its to prevent bad behaviour - subtle but important difference
<lifeless> we have other ones with the same characteristics, at different layers, and I'm not [yet] ready to remove them.
<lifeless> when we're down to 5 seconds, yes.
<lifeless> but only when we've also got timeout caps on backend tasks
<lifeless> (which we don't today, partly because they are used to workaround frontend performance issues
<persia> Used to be I'd regularly review lists of 500-700 bugs with something in common, and perform useful actions as a result of that.  Would be nice to get that as a rendered list, rather than having to write my own frontend, but I admit I have somewhat specialised needs.
<persia> Which reminds me: was something done about the slowness of e.g. loading results 750-825 of 1237?
<lifeless> persia: the 300 batch size one I support removing happily.
<lifeless> persia: what slowness? we don't have a report on that atm
<persia> Well then, next time I have any excuse to do a big bug scan, I'll enable some timers in my browser, and report a bug if there is useful variance: I only have remembered subjective experience, which is useless for diagnostic purposes.
<lifeless> sure
<lifeless> if you look in the page source
<lifeless> there is a time report at the bottom
<persia> Oh, cool.  That makes life easy then.
<lifeless> thats the time that (for the moment, until that figure is universally healthy) we're using to analyse things.
 * persia tries to concoct an example
<persia> Very snappy indeed: Getting above 1.79 seconds requires more effort than I'm willing to spend at the moment.
<lifeless> persia: \o/
<persia> I did get a 20000 microsecond difference for 0-75 of 637 (+/- 20) vs. 225-300, but that could just be collision with other users.
<persia> (and I'll remember that other SI modifier any second now)
<lifeless> Âµ ?
<persia> No, that's the one I remember :p
<persia> m
<persia> Anyway, a fifth of a second or so.
<lifeless> we have quite a lot of noise atm
<lifeless> basically I'm not analysing anything once a page gets 99% of requests done in < 4 seconds: future work.
<persia> That's fair.  I'll definitely let you know about my next timeout, although I expect it will take some time for me to migrate my work back towards LP.
<lifeless> persia: fair enough
<lifeless> persia: anyhow; I think you can see some improvement ;)
<persia> I see massive improvement.  Enough that I'm tempted to try to use it as a tool again.
<lifeless> cool
<Kano> hi, i did install of maverick daily now, and i selected sda5 as target, but that stupid installer installed it to the mbr, why=
<ogra_cmpc> doko, i made it !!! got root on the ac100
<persia> ogra, Cool!  can you access a bootloader?
<persia> (or otherwise swap kernels)
<ogra_cmpc> persia, still trying to find out how to mount the bootloader partition
<ogra_cmpc> i dont want to swap kernel
<ogra_cmpc> i want to be able to boot from SD ... the kernel is fine (old though)
<persia> Sorry: I'm looking at a goal past the goal you mention :)  Ideally, be nice to have the SD slot free whilst running Ubuntu :)
<ogra_cmpc> heh, indeed
<ogra_cmpc> i only managed to break in right now so i didnt examine much yet
<persia> But, yeah, alternate booting would get you 90% of the way there.
<ogra_cmpc> right
<persia> I'm getting very tempted: it's much faster than a replacement for my Netwalker, and similar price.
<ogra_cmpc> there is no fstab or anything on android so it seems that everything is done by the bootloader/kernel cmdline
<persia> Yes.
<persia> Well, everything at boot time.  There's dynamic loading of USB devices for some flavours.
<ogra_cmpc> the init.rc looks suspiciously like an upstart script
<persia> Wouldn't surprise me, really.
<ogra_cmpc> i bet Keybuk would know if they used it
<zyga> Kano, please report a bug about ubiquity
<ogra_cmpc> oh ! there is a chroot binary, i should be able to chroot from init to an sd system
<persia> That won't get you device access :(
<ogra_cmpc> but a sanee system to work from
<ogra_cmpc> android is just unusable and painful
<ogra_cmpc> a shell whete all keys work would be a massive progress already :)
<persia> Well, true, and then cp lets you get contents back.
<ogra_cmpc> eventually i'd like to flash a sane fastboot onto it but thats far in the future i think
<ogra_cmpc> first step is done though :)
<persia> Excellent.  Let me know if you get so you can launch X from the chroot, or ssh into it: either is likely enough to make me want one.
<mdke> kees: sorry, I don't know anything about how manpages are translated - I guess any translations would come from upstream but I don't know for sure
<mdke> can I ask someone with permissions to request a translation export of all templates at https://translations.launchpad.net/ubuntu/maverick/+source/ubuntu-docs and send me the link
<mdke> I think that anyone in ~ubuntu-core-dev should be able to do this
<mdke> unfortunately due to something screwy about LP's permissions, I can't download these translations even though I can upload this package
<persia> mdke, You just want the tarball?
<persia> PO or MO?
<persia> (also, it doesn't seem to need core-dev: it's some other weird permission)
<mdke> persia: po tarball would be perfect, thanks
<persia> LP claims it ought be ~15 minutes.
<mdke> brilliant, thanks
<mdke> persia: if you could just msg or email me the link that would be great, I have to pop out now. Thanksa gain
<wzssyqa> can i request syncing packages from debian?
<wzssyqa> now, for 10.10 , I am maintainer of these debian packages
<jpds> wzssyqa: You can use the 'requestsync' script in the ubuntu-dev-tools package.
<torti> hi. in ubuntu 10.10beta when i install linus-source, extract the .tar.bz2, do "make oldconfig" and "make modules_prepare" before installing the vboxdrv (virtualbox 3.2), the resulting vboxdrv.ko has magicversion 2.6.35.4, thus cannot be loaded since the kernel has 2.6.35-22-generic. is this normal in the beta or is this a bug?
<torti> /linus/linux/
<torti> i think 2.6.35.4 comes from ubuntu's /boot/config-2.6.35-22-generic, because it has: CONFIG_VERSION_SIGNATURE="Ubuntu 2.6.35-22.32-generic 2.6.35.4"
<ScottK> torti: #ubuntu-kernel is probably a better place to ask.
<torti> thank you, scott
<Chipzz> jpds: you were wrong. He couldn't atm, freeze and all that (cfr topic)
<ScottK> Chipzz: Depends on what the package is and what the change is.
<sense> Why would Perl regexes from GTK#'s GAPI2 parser work on the Launchpad build farm, but not on my local installation? Is there any reasonable explanation for that?
<sense> The same GAPI2 version, the same files, the same string, the same regex.
<Aemaeth> why wouldn't the blueman applet be chosen over the other bluetooth that was installed?  blueman has better support for DUN and equivalent support for the other bluetooth features
<Aemaeth> ubuntu-one needs an option to backup / and enough to keep settings
<fagan> Aemaeth: well we are getting oneconf
<fagan> it backs up app configs
<fagan> theres no point in backing up / because a lot of it is stuff on the cd and that would take up a hell of a lot of space
<Aemaeth> i've never claimed my wants were rational
<fagan> ha
<Aemaeth> can skip anything that apt can get for you
<fagan> Well the config files are the most important things to back up
<Aemaeth> i'm not sure i could keep track of everything i've edited
<hyperair> hmm so it's ubunutone-etckeeper
<steve__> hello all, sorry for the off topic, but is there anyone that could chat to about trouble shooting a ?broken usb drive. Im hoping you may be more than averagely qualified to help) ;)
<hyperair> try #ubuntu
<steve__> hyperair, I have tried #ubuntu... but thanks for the idea. know of any other channels that could help?
<hyperair> your local ubuntu channel?
<hyperair> judging from your ip address, i'm assuming #ubuntu-g
<hyperair> b
<hyperair> er
<hyperair> #ubuntu-gb
<hyperair> i mean #ubuntu-uk
<popey> yeah, people about in -uk
<steve__> hyperair, Good plan, going to my first lug meet soon (finally) so will see if anyone has any ideas. ;) I will have a look see on #ubuntu-uk. Thanks and have a good one
<hyperair> np
<Ologn> Digg has this dugg - http://labs.adobe.com/technologies/flashplayer10/
<Ologn> That should solve some problems, hopefully
<penguin42> Oh that is nice
#ubuntu-devel 2010-09-19
<dashua> nicee
<verb3k> In checkinstall, what does the --backup option do exactly?
<psusi> if there is a bug in the toolchain, what should it be filed against?  gcc?
<persia> psusi, Depends which part of the toolchain :)
<psusi> I *THINK* it's ld
<psusi> I filed this bug all the way back in 2005 and it has not gotten any attention yet the problem has actually grown worse... I think it's because I never targeted it at a specific package.  bug #24692
<ubottu> Launchpad bug 24692 in Ubuntu "Amd64 ubuntu build hogs memory due to libs built with excessive alignment requirement" [High,Confirmed] https://launchpad.net/bugs/24692
<psusi> in maverick it seems we now have a default alighment of 2 mb, not just 1
<persia> psusi, Might track down whoever uploaded the alignment change.
<psusi> I don't even know where the setting is ;)
<persia> Might be nobody else does, hence the uncommented bug report :)
<psusi> hehe... maybe I check the logs and see who usually uploads gcc... someone has to be an expert on it ;)
<ebroder> Ugh. We need a duplicate bug finder for dkms failures
<ebroder> I'm up to...37 dupes of this fglrx bug?
 * psusi is glad he doesn't use fglrx anymore.... hooray open source drivers!
<persia> ebroder, I think the bugsquad has something called "recipes" that helps merge mass-duplicates.  Ask someone in #ubuntu-bugs.
<persia> I strongly believe it's harmful to claim bugs are duplicate without deep information.
<ebroder> Deep information? What do you mean? I'm reading the description (making sure they're installing fglrx, whether they know it or not) and checking the build log to make sure it's the same build error
<micahg> ebroder: the Ubuntu X team likes a separate bug for each piece of hardware
<persia> It's the making sure it's precisely the same error because one understands how the software works that is the deep information to which I refer.
<persia> micahg, Only where it's hardware-specific (and it very often is)
<micahg> persia: right and unknown = don't dupe
<ebroder> persia: I'm fairly confident on this one - the build-logs look *identical* with the exception of timestamps and l10n
<ebroder> And it's a build error - how can it be hardware specific?
<ebroder> (the bug I'm using as a parent for everything is bug #642518)
<persia> I don't mean to criticise your desire to duplicate them: I'm uninformed, and presume you to be informed.
<ubottu> Launchpad bug 642518 in fglrx-installer (Ubuntu) "package fglrx 2:8.723.1-0ubuntu4 failed to install/upgrade: fglrx kernel module failed to build" [Undecided,New] https://launchpad.net/bugs/642518
<micahg> ebroder: same with me, just providing info here
<persia> I mean to explain why I think it's a good idea for the reporters to have filed the duplicates in the first place, and point you at a resource so you can clean up more easily.
<ebroder> persia: I understand; sorry for getting defensive. I did probably jump in a bit aggressively, but this bit me indirectly, and seemed like something I could take care of
<persia> So, please, mark them as duplicates.  You may find "bug recipe"s useful in doing so.
<ebroder> I think I've got them all by now, but I'll keep that in mind next time :)
<persia> No worries.  Just wanted to make sure we understood each other :)
<ebroder> Ok, this sucks. The security update made compat_alloc_user_space GPL-only, when it wasn't before
<mdke> grateful if a release team member could have a look at / approve ubuntu-docs 10.10.3 when convenient
<lucidfox> Okay, bug #615300 just feels like one slap in the face too many
<ubottu> Launchpad bug 615300 in evolution (Ubuntu) "Evolution should have a default signature enabled" [Medium,Fix released] https://launchpad.net/bugs/615300
 * lucidfox considers filing "Evolution should *not* have a default signature enabled"
<ScottK> ebroder: Sounds like a bug that should be reported and brought to the attention of the security team.
<kees> ebroder: are you on maverick or an earlier release?
<ebroder> kees: Lucid. The issue is that the new compat_alloc_user_space is EXPORT_SYMBOL_GPL, while it used to be an inlined function declared in a header
<ebroder> And that's breaking fglrx - bug #642518
<ubottu> Launchpad bug 642518 in fglrx-installer (Ubuntu) "package fglrx 2:8.723.1-0ubuntu4 failed to install/upgrade: fglrx kernel module failed to build" [High,Confirmed] https://launchpad.net/bugs/642518
<ebroder> I have a fix, although I don't really like it, and I want someone more familiar with fglrx than me to pass judgement before I start pushing for sponsorship
<kees> ebroder: okay, thanks. this is a bug in the kernel update and we'l get it fixed asap; sorry for the glitch!
<ebroder> kees: Hmm, really? Are you guys allowed to decide that the symbol should be exported to non-GPL modules? I thought there was legal mumbo-jumbo surrounding all that
<kees> ebroder: it's a backported fix; it just wasn't backported correctly. it'll still be a problem for maverick.
<ebroder> Ok, great. fglrx will still need a patch, because it's looking for the function in the wrong header file, but that's easier to deal with
<ebroder> kees: Do you want me to file a bug about this?
<kees> ebroder: I think the existing uninstallability bug is enough, but thanks!
<lucidfox> So
<lucidfox> is bug #615300 going to be set to something other than "Fix Released" and reopened for discussion?
<ubottu> Launchpad bug 615300 in evolution (Ubuntu) "Set and/or enable default Evolution signature as "Sent from Ubuntu"" [Medium,Fix released] https://launchpad.net/bugs/615300
<fagan> lucidfox: I presume there will be more talk tomorrow about it when the canonical crowd are around
<vish> lucidfox: hmm , did anyone test the change?
<vish> i need to use evolution in Maverick
<lifeless> wheee
<lifeless> thats a fun bug :P
<fagan> lifeless: ill check it
<fagan> its not showing up on the bottom of my messages
<fagan> I sent a few messages today but its not showing up
<vish> fagan: might it just be a preference ?
<lifeless> AIUI its in your signatures lists you can choose from
<fagan> maybe
<lifeless> so you can turn it on
<lifeless> and for new accounts it may default on
<vish> something that the user can change if they want
<fagan> yeah its for new accounts
<vish> it seems to be another huge fuss over nothing.. or just  a preference but need to actually check it in action though ;)
<lifeless> it is minor; I don't really see the point though.
<lucidfox> Making this default for new account would be a huge mistake.
<lucidfox> No it's not minor
<fagan> Well id like the wording to be a lot better
<lucidfox> it's a recurring pattern
<fagan> thats all
<lifeless> lucidfox: snarfing passwords and mailing them to me would be major
<vish> lucidfox: is it not possible to change it?
<fagan> I dont mind it in there I just dont like the wods
<fagan> words
<vish>  to me it just sounds like using @"gmail"
<lucidfox> It's possible. I still don't like this being by default. And I don't like Canonical forcing a closed-doors decision on the users yet *again*.
<vish> but i wouldnt use it though .. i'd just change it to what i want to use..
<fagan> well lucidfox they are a private company they dont really have to run most things past the community
<fagan> its hard to dictate to someone thats giving you stuff for free
<lucidfox> If they care about their reputation, yes they need to cooperate with the community at large
<vish> lucidfox: so how to communicate?
<vish> lucidfox: the bug was a public bug..
<lucidfox> It wasn't. It went from filing to implementation in the span of... less than a day, I think. And by the form it was posted, it seems it was already decided behind closed doors by then.
<vish> lucidfox: why do people always assume the worst? :)
<lucidfox> I'm just judging by the history of Canonical's prior initiatives
<lucidfox> Rick Spencer filed the bug, then Sebastien Bacher almost immediately assigned it to the beta milestone. Then a package was uploaded implementing it, with no comments in between.
<fagan> lucidfox: well it might have been talked about on IRC beforehand
<avi__> Hey guys, so I've written this cool app in PyGTK and Glade. How can I package this up and distribute it?
<luca> hi everyone
<fagan> avi__: you should ask that on #ubuntu-app-devel
<avi__> awesome, will do. thanks!
<luca> I would need some help, but none is available in @ubuntu+1 currently .. maverick, kernel 2.6.32-23 (latest) refuses to install
<luca> currently I am without a workable kernel installed. Anyone with the same problem?
<micahg> luca: maverick should have a 2.6.35 kernel unless this is special hardware
<luca> sorry
<luca> 2.6.35
<luca> misspelled the kernel name
<luca> there seems to be some problem in the transition between 2.6.35-22 to 2.6.35-23
<luca> wondering if someone was having the same problem, maybe a fix.
<mdke> lucidfox: I agree with you, thanks for raising it
<ebroder> luca: Are you using proprietary drivers?
<ebroder> There's a known bug compiling fglrx against the most recent Lucid and Maverick kernels
<luca> broadcom for wireless, but it is not installed right now
<ebroder> Ok, never mind, then
<luca> (I know about the bug, I have been without fgrlx for some days now)
<avi__> _is
<kklimonda> lucidit would make more sense to bring this subject to u-d-d instead. Most developers don't ead forums nor use IRC at sunday.
<kklimonda> meh
<kklimonda> great, she's gone...
<kklimonda> anyone else cares about it enough to raise it on ML? ;)
<YokoZar> did ulimit -n change in maverick? It seems to be way too low 1024, iirc we had it much higher in previous releases
<rishi> I have a stripped down Ubuntu 10.04 which I am using as an appliance for collecting behavioral data for research. Part of it involves recording audio/video from an USB camera. The recording is initiated from an initscript. Now I find that if I am not running a desktop, ALSA finds plughw:1,0 to be busy. The open system call reports EBUSY. It looks like something changed in 10.04's boot sequence which is causing this.
<rishi> I ran a quick test on Ubuntu 9.10 and Fedora 13 and they seemed to be fine.
<rishi> Can anyone suggest what might be going on?
<rishi> I have run lsof, etc. on almost everything imaginable and there is no other process using the device.
<rishi> Now the funny part is that if I try to record manually, ie. log in and then use a shell, then everything is fine.
<bdrung_> doko: no time and no clue for fixing bug #643107.
<ubottu> Launchpad bug 643107 in openjdk-6 (Ubuntu) "Eclipse 3.5.2-6 FTBFS on armel" [Medium,Confirmed] https://launchpad.net/bugs/643107
<doko> bdrung_: modularizing the ant script might help
#ubuntu-devel 2011-09-12
<StevenK> pitti: O hai! I spent some time on the weekend trying to get ekiga to build with the new opal and pt, and it's hopeless. :-(
<pitti> Good morning
 * micahg thought pitti uploaded a new version of htat
<pitti> StevenK: but I already uploaded the new ekiga which works fine
<pitti> StevenK: I mentioned that on the bug which opal and ptlib referenced
<pitti> StevenK: sorry about the double-work
<pitti> bdmurray: it's meant to mark the bug as a dupe of the real master bug
 * mneptok waves to pitti
 * pitti throws some candies towards mneptok
<pitti> mneptok: how are you?
<mneptok> pitti: great, thanks!
 * mneptok is on a month-long vacation, and is quite relaxed
<pitti> mneptok: sounds nice! you are spending it at home, or in the internets? isn't that a good time for travelling etc.?
<pitti> uh, half of the armel builders offline?
<micahg> pitti: system upgrades, I was told they should be back soon
<mneptok> pitti: i spend most days on the motorcycle riding around New Mexico
<pitti> ah, cheers
<ScottK> slangasek: honeyd FTBFS when rebuild (needed for NBS) looks somewhat multi-arch like to me.  The error is "configure: error: Couldn't figure out how to access libc"
<lifeless> ScottK: win!
<ScottK> It is because it's clearly too hard for me, so somebody else's problem ...
<micahg> doko_: pitti: hopefully by EOD you can remove the old libav binaries (uploaded and building)
<pitti> micahg: yay
<didrocks> good morning
<ScottK> didrocks: I'm about to go sleep, since it's very late here, but I'd appeciate it if you could look into the qt4-x11 build failures today.
<didrocks> ScottK: I'll try having a look, not sure I got time (already busy schedule), but will try (saw some build failure on arm, right?)
<tkamppeter> pitti, hi
<pitti> tkamppeter: hey, how are you? enjoyed your holidays?
<doko> didrocks, ScottK see the ftbfs report
<didrocks> doko: do you have a bug # handy? (did you subscribe me to it? I didn't see it)
<didrocks> I guess it's bug #847224
<ubottu> Launchpad bug 847224 in qt4-x11 (Ubuntu Oneiric) "qt4-x11 ftbfs on armel (timeout building the docs)" [High,Confirmed] https://launchpad.net/bugs/847224
<doko> didrocks, see http://qa.ubuntuwire.org/ftbfs/
<didrocks> doko: yeah, I'll see that with ScottK about what to do to reduce the build time as it's the timeout killing the build
<didrocks> same on powerpc it seems
<micahg> wow, it used to be 10 hrs on armel, I guess it was raised
<didrocks> micahg: it's a timeout of no activity while building the documentation
<micahg> didrocks: I understand, the timeout used to be 10 hrs, I guess it's now 13.3
<doko> 800min ...
<didrocks> doko: anyway, the -doc packages are arch:all as you infered, let me see how to disable the build for other archs
<didrocks> hum, nice, seems Qt doesn't have an option to disable the build of documentation
<didrocks> seems it will need a painful patch arch-dep
<dholbach> good morning
<poolie> hi all
<poolie> could someone from the sru team (or archive admin?) promote the fix for https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/736216 in natty?
<ubottu> Launchpad bug 736216 in curl (Ubuntu Maverick) "bzr crashed with error in _curl_perform(): (28, 'SSL connection timeout at 298225') connecting to Launchpad" [Undecided,In progress]
<didrocks> hey dholbach, poolie
<poolie> hi there
<poolie> ... or, let me know what needs to be done
<dholbach> hey didrocks, hi poolie
<poolie> hi there
<doko> cjwatson, so building with -DGDK_DISABLE_DEPRECATED seems to be as bad as -Werror ...
<poolie> didrocks, could you suggest what i should do to get that sru to move?
<doko> micahg, did the qt4 security upload fail with this doc timeout too?
<didrocks> poolie: it seems you subscribe the ubuntu-sru team to it, isn't it? but the Natty curl status is fix committed, is there any reason?
<didrocks> "Accepted curl into natty-proposed" oh, it's already in -proposed
<poolie> i think the state is fixed in -proposed, not yet fixed in -updates
<poolie> it's in proposed
<poolie> it apparently works
<poolie> it needs to go into -updates
<didrocks> yeah, and there is verification-done-natty (but still verification-needed, I guess for other?) not sure if that puzzles pitti's script
<poolie> perhaps that's it
<didrocks> let's wait for him to have some time to have a look :)
<pitti> v-done-release is an invention of the kernel team, this tag isn't recognized by the SRU report page
<pitti> it should just be v-done
<pitti> anyway, can release now
<poolie> thanks
<pitti> done
<poolie> thanks pitti
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Beta 1 released | Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
<poolie> i'm surprised that ntfs mounts with umask=0 by default, although mount(8) says it's umask=077
<poolie> is that an intentional ubuntu change?
<tkamppeter> pitti, it is about bug 807261, the problem of cups-pk-helper breaking s-c-p.
<ubottu> Launchpad bug 807261 in cups-pk-helper (Ubuntu Oneiric) "cups-pk-helper makes system-config-printer asking for a password when adding a new printer" [High,New] https://launchpad.net/bugs/807261
<tkamppeter> pitti, I have added a longer comment to it.
<jamespage> morning all
<jamespage> doko - any chance you could sponsor those two branches you reviewed for me on Friday?
<doko> jamespage, sure
<jamespage> doko: thanks
<cjwatson> micahg: some of libav will still have to wait for insighttoolkit to finish its eight-day or whatever it is armel build so that itksnap and vmtk can be fixed - but yes, gnash was the other blocker, so thanks!
<cjwatson> doko: yeah, it should be a maintainer-only thing rather than a release tarball thing
<cjwatson> doko: also -DALLSORTSOFOTHERTHINGS_DISABLE_DEPRECATED
<tkamppeter> pitti, ping
<pitti> tkamppeter: pong
<tkamppeter> pitti, have you seen my message above?
<pitti> tkamppeter: yes; do you need me to do anythign with this bug?
<tkamppeter> pitti, I want to know what you think is the best solution without loosing any functionality.
<tkamppeter> pitti, There are the following possibilities:
<pitti> why do we need cups-pk-helper?
<pitti> for s-c-p?
<pitti> we haven't before
<pitti> I thought it's only needed for the upstream control-center printer capplet
<pitti> (which we don't use in ubuntu/unity, just with gnome shell
<tkamppeter> pitti, s-c-p does not need cups-pk-helper, so if there is nothing else needing it, one could simply make sure that it does not get pulled into the default installation.
<pitti> tkamppeter: it doesn't
<pitti> tkamppeter: if you install gnome-shell, it will be pulled in
<tkamppeter> pitti, what pulls it in currently is gnome-shell and gnome-shell I have installed, probably because my Oneiric is grown out of daily updates from Natty.
<pitti> does it hurt to have it installed?
<tkamppeter> pitti, we must assure that updaters from Natty and older will not get cups-pk-helper pulled in.
<pitti> the upstream capplet is hidden in the control center under UNity
<pitti> so nothing ought to invoke it?
<pitti> tkamppeter: why?
<pitti> tkamppeter: I thought s-c-p wouldn't use cups-pk-helper; you mean it does?
<tkamppeter> pitti, yes, if cups-pk-helper is installed, s-c-p asks for an admin password, even if the user is in the lpadmin group.
<pitti> bah
<pitti> it oughtn't
<pitti> tkamppeter: we can't assure that cups-pk-helper isn't installed, as people might have gnome-shell installed
<cjwatson> hyperair: could you please confirm my last comment in bug 756161?
<ubottu> Launchpad bug 756161 in geanydoc (Ubuntu Oneiric) "geanydoc version 0.4-0ubuntu3 failed to build on i386" [High,Confirmed] https://launchpad.net/bugs/756161
<pitti> tkamppeter: can we disable cups-pk-helper support in s-c-p easily? does it have a configure option?
<tkamppeter> pitti, I can also patch away the cups-pk-helper support in s-c-p by adding only two lines.
<tkamppeter> pitti, it is not a configure option, it is setting a variable to False at two points.
<hyperair> cjwatson: ah, that package's been obsoleted by geany-plugins afaik
<hyperair> cjwatson: rm please
<cjwatson> hyperair: right, that was what I said in my comment :)
<cjwatson> hyperair: shouldn't geany-plugins-doc Breaks/Replaces geanydoc as well though?
<hyperair> did you?
<cjwatson> hyperair: oh, it might not quite have saved yet when I asked you, reload
<pitti> tkamppeter: do you think that would be okay? it seems like the best solution to me
<tkamppeter> pitti, best solution would be to fix cups-pk-helper to support the user-in-lpadmin-group case, but probably this is more work, and not easy to project into the architecture of PolicyKit.
<pitti> tkamppeter: right
<pitti> tkamppeter: I think if/when we switch to cups-pk-helper and the upstream applet, we'll deprecate lpadmin in the desktop
<hyperair> cjwatson: right, i guess it should.
<pitti> it's one of the few "hardware access" groups that we still have, and it's a thorn in the eye
<cjwatson> hyperair: want a separate bug?
<hyperair> cjwatson: actually no. geanydoc is the source package name.
<hyperair> cjwatson: geany-plugin-doc is the binary package name
<cjwatson> oh
<hyperair> Package: geanydoc
<hyperair> Binary: geany-plugin-doc
<hyperair> Version: 0.4-0ubuntu3
<pitti> tkamppeter: we can then even configure polkit to allow access to local printers from a local desktop session (as these users have physical access anyway)
<cjwatson> so it's just an orphaned source package then, fine
 * cjwatson really must produce a report of those
<hyperair> well more like it should have been removed
<hyperair> i thought i got rid of all those already
<hyperair> hmm
<cjwatson> hyperair: oh well, this one's gone now, thanks
<hyperair> cjwatson: geanyprj also needs to be removed.
<hyperair> and that should be it.
<cjwatson> hyperair: that was done a while back, bug 825069
<ubottu> Launchpad bug 825069 in geanyprj (Ubuntu) "please remove geanyprj from the oneiric archives" [Undecided,Fix released] https://launchpad.net/bugs/825069
<hyperair> ah okay.
<hyperair> then that should be it :-)
<cjwatson> excellent
<tkamppeter> pitti, another solution would s-c-p trying cups authentication not allowing a password prompt and only if the authentication fails try cups-pk-helper and as last mean try cups authentication with password. But this would be a bigger change, perhaps not doable for Oneiric.
<pitti> tkamppeter: yeah, that even sounds upstreamable then
<tkamppeter> pitti, this would be a good idea, switch to PolicyKit instead of lpadmin-group-based access in s-c-p (keep lpadmin group only for the command line utils of CUPS) and allowing general access to locally defined print queues for local desktop users.
<tkamppeter> s/general access/general passwordless access/
<Daviey> Does syncpackage, when sponsoring a sync with a bug number default to giving attribution to the bug reporter?
<tumbleweed> not yet
<Daviey> tumbleweed: thanks.
<tumbleweed> Daviey: Bug 827608
<ubottu> Launchpad bug 827608 in Launchpad itself "Sync requester isn't credited with upload" [High,In progress] https://launchpad.net/bugs/827608
<tumbleweed> actually that's not even the sponsorship one, that's just a pre-requisite
<Laney> that was about self syncs
<Laney> sponsored syncs are in another one
<Laney> ah, which is linked frmo there: bug 827555
<ubottu> Launchpad bug 827555 in Launchpad itself "native syncs have no way to indicate sponsorship" [Low,Triaged] https://launchpad.net/bugs/827555
<Daviey> tumbleweed: ah! making good progress :)
<tumbleweed> Daviey: unfortunatly the sponsorship one is of low importance, so it may take a while...
<Laney> we can probably get people interested
<Laney> they seem good like that on this feature
<Daviey> \o/
<Daviey> Well i just did a sync which should have been sponsored, and yes - i now feel like an ass.
<Daviey> I don't think the chap will mind, thankfully.
<Laney> did the tool make you think it was going to be credited correctly?
<tumbleweed> it looks like we're going to have to sneak one more upload in, we can mention that
<Daviey> Laney: well.. i hoped :).. Considering it said i /could/ overwrite it if i appended --no-lp
<Daviey> so i thought! Ah!, it must be smart enough :)
<Daviey> Although, i did suspect it might not be.. having ack-sync pulled out from under me was kinda frustrating.
<tumbleweed> I don't think it's worth using --no-lp just for sponsorship attribution (I asked sponsorees if they minded not being attributed, and they didn't care)
<Laney> :q
<Laney> there appear to not be any open sync requests to test how sponsor-patch works
<Laney> woe
<Daviey> So syncpackage is still expected to close the bug, and not launchpad?
<Daviey> Not ideal when the sync isn't automagic.
<Daviey> as in, NEW.
<Daviey> Laney: I have one you can hijack.
<Laney> that's no worse than how it was before, but it might have been an opportunity to only close bugs on publication, indeed
<tumbleweed> but there's another feature request bug open for this
<tumbleweed> (although I doubt that'll help with the NEW case)
 * didrocks wonders why he gets some FTBFS on other deps not yet published on the same arch (explicitely set in debian/control)
<didrocks> was the same with unity-2d last Friday
<tkamppeter> pitti, for me it looks like that the quickest solution to solve the s-c-p/cups-pk-helper incompatibility problem in Oneiric is to apply the 2-line patch to make s-c-p not using cups-pk-helper.
<tkamppeter> pitti, letting s-c-p try password-less CUPS auth before PK auth and then passworded CUPS auth is a good idea to suggest upstream, too complicated to rush into Oneiric.
<tkamppeter> pitti, I am trying now another possible solution: Using, as you suggested, cups-pk-helper but opening up the right to manipulate local queues for all local desktop users without password. password is only needed for server settings and manipulating remote printers.
<tkamppeter> pitti, this I am doing by replacing most "auth_admin_keep" by "yes" in /usr/share/polkit-1/actions/org.opensuse.cupspkhelper.mechanism.policy.
<tkamppeter> pitti, WDYT? Which method should we use in Oneiric?
<tkamppeter> pitti, if we opt for using the cups-pk-helper-based solution, I can patch s-c-p to check for the SSH_CLIENT env variable to not use PK is s-c-p is run through SSH, a ~6 lines patch.
<debfx> mvo: would it be a problem for app-install-data if kubuntu stopped stripping translations from desktop files?
<bdrung> Laney, Daviey, tumbleweed: sponsor-patch just calls syncpackage (without --no-lp) and due to the mentioned bug it does not yet support crediting the requester.
<Laney> bdrung: shouldn't it do the AA way until that is fixed?
<bdrung> Laney: good idea. i hoped that this will be fixed before oneiric is released
<Laney> no idea about that
<tumbleweed> it won't be able to credit the requestor without an API change on teh launchpad function, so that seems to be a safe thing to do
<pitti> tkamppeter: re (sorry, was at lunch)
<pitti> tkamppeter: no, please don't replace with "yes", we should only do that for users who are in the "admin" group already
<pitti> tkamppeter: I think for oneiric we should just do the 2-line patch you suggested
<bdrung> tumbleweed: btw, the changes are ready for oneiric. currently sponsor-patch doesn't support sync request at all. now it supports it (except the crediting)
<tkamppeter> pitti, OK, will do so.
<pitti> tkamppeter: thanks
<diwic> pitti, is there a way to force a proper retrace of bug 838453 ? Apport's conclusion is wrong.
<ubottu> Launchpad bug 838453 in pulseaudio (Ubuntu) "pulseaudio crashed with SIGABRT in raise()" [Undecided,Confirmed] https://launchpad.net/bugs/838453
<tkamppeter> pitti, admin-group-only authentication (but asking for password) is the standard scenarion if one does not change the cups-pk-helper configuration. Would be great if cups-pk-helper would give the possibility to allow access for users in the admin group (in the lpadmin group) without asking for their password if they are logged in on the desktop already.
<pitti> tkamppeter: yes, that's possible, just not in the .policy file
<pitti> tkamppeter: but as we don't use cups-pk-helper, I wouldn't change it in oneiric now
<tkamppeter> pitti, so this would be a feature request for cups-pk-helper in Powerful Pitti, our next LTS.
<pitti> tkamppeter: heh
<pitti> tkamppeter: actually it would go into policykit-desktop-privileges, but either way, it's a simple change; I can do it easily
<tkamppeter> pitti, great. Will you add this to your TODO list or should I report a bug?
<pitti> tkamppeter: bug report will do fine
<pitti> we can target it to P
<tkamppeter> pitti, OK.
<Laney> cjwatson: pitti: I'm confused about appointing the new DMB member. Does the TB need to confirm it?
<pitti> Laney: erm, shouldn't DMB members be voted on?
<Laney> it has been?
<pitti> I thought the current DMB was the result of a poll
<Laney> did you miss the election?
<mvo> debfx: I don't think so, should be fine
<pitti> yeah, that's what confused me; what does the TB need to confirm then?
<pitti> Laney: ah, you mean adding it to the team?
<Laney> the results of the poll
<Laney> well, that too
<cjwatson> TB is the administrator so would need to take action on it
<Laney> I am asking if the TB needs to explicitly confirm
<Laney> or just push the buttons to add the new member
<cjwatson> I think we just push buttons
<pitti> I wouldn't see why, but I might miss something
<Laney> I thought I recalled you ratifying previous polls, but good
<Laney> was concerned because at the last minute I can't make the meeting tonight, so I wanted to ensure that micahg can be a full member at it
<pitti> Laney: I actually voted, I just seem to have missed the announcement of the result
<Laney> hasn't been done yet until after it's confirmed at this meeting
<Laney> but you can see the result on your poll link
<Laney> (FYI I have been trying to follow https://wiki.ubuntu.com/CommunityCouncil/Restaffing but found it a bit confusing on this point)
<pitti> does anyone have an idea how I work around the "Server presented certificate that does not match host staging.launchpad.net"  lplib error when trying to connect to staging?
<pitti> ('DNS', '*.staging.launchpad.net')
<pitti> that doesn't seem to include "staging.lp.net" itself
<pitti> ah, ignore me, it's the second part of subjectAltName, so it ought to work?
<pitti> ah, bug 839826 ?
<ubottu> Launchpad bug 839826 in python-httplib2 (Ubuntu) "Incorrectly checks for SSL certificate domain names" [High,New] https://launchpad.net/bugs/839826
<pitti> this even has a patch, trying that
 * Laney ran into that on Debian too
<pitti> works fine, sponsoring this
<Laney> DktrKranz: tumbleweed: ^ any chance of uploading to debian?
<DktrKranz> Laney: could do, non sure about "when"
<Laney> as you please, I built a package for myself
<DktrKranz> I think I could be able to prepare an upload on Wed at latest
<Laney> :-)
<jml> pitti: I'm still getting those tracebacks in .xsession-errors: http://paste.ubuntu.com/687590/
<pitti> jml: i. e. this still crashes for you? python -c 'from gi.repository import GLib; print GLib.markup_escape_text("a&b")'
<jml> pitti: yes. TypeError: markup_escape_text() takes exactly 2 argument(s) (1 given)
 * pitti scratches head -- this is oneiric current?
 * pitti tries on current live CD
<jml> pitti: yes. fresh update today.
<jml> pitti: if you want, I can give you some package versions.
<jml> pitti: but I'd neet to know which ones are relevant
<pitti> jml: I first test on current live CD, to check whether it's my system that is non-standard somehow
<jml> pitti: makes sense. thanks.
<pitti> no, works on current desktop live CD
<pitti> jml: dpkg -l libgirepository-1.0-1 gir1.2-glib-2.0 python-gobject
<jml> pitti:
<jml> http://paste.ubuntu.com/687594/
<pitti> gir1.2-glib-2.0     1.29.16-0ubuntu1
<pitti> there you go
<pitti> jml: you want 1.29.17
<pitti> jml: strange that you got the current version of libgirepository-1.0-1, it's built from the same source
<jml> pitti: for some reason, it's kept back
<pitti> what does sudo apt-get install gir1.2-glib-2.0 say?
<pitti> it might want to remove something, so don't say yes, just check what it complains about
<cjwatson> down to merely nine LP-batched pages of build failures ...
<pitti> jml: ^
<jml> cjwatson: yay progress?
<pitti> jml: well, I was referring to what I said before, but agreed to "yay progress" :)
<cjwatson> after a long and protracted war of attrition, the enemy is now merely nine times our size
<jml> pitti: will do. just need a sec for an upgrade I started to finish.
<cjwatson> but I think the lesson is "don't let the enemy get that large in the first place"
<pitti> cjwatson: doesn't the vast majority of the universe FTBFS just happen due to us having a different toolchain and through bad luck through autosyncs?
<jml> pitti: I think it just wants new packages: python-gobject-2
<pitti> i. e. do we actually have a realistic alternative to not introduce these?
<jml> pitti: nothing being removed
<pitti> jml: that's right
<pitti> jml: so it seems you have the old python-gobject, too
<cjwatson> pitti: no, but we did have a realistic alternative to leaving them untended for > six months
<pitti> jml: yes, you do
<jml> pitti: yeah, I do. Have just installed the latest gir1.2-glib-2.0
<cjwatson> with a large queue, people get into the mindset that build failures are basically normal and that there's no rush
<pitti> jml: don't you use dist-upgrade? a mere upgrade will hold them back, right
<jml> pitti: my dist-upgrade has been broken for a while.
<pitti> cjwatson: agreed to > 6 months
<jml> pitti: http://paste.ubuntu.com/687600/
<pitti> it's just not something I like to see us spending manmonths on right after the autosync wave
<cjwatson> the vast majority are easy; I fixed 15 build failures yesterday despite only being around for a few hours on a Sunday when others were asleep; if we'd been putting in consistent effort, there wouldn't be a problem
<pitti> jml: hm, flashplugin-installer is at 10.3.183.7ubuntu1
 * jml checks ppa
<jml> s
<jml>  flashplugin-installer : Depends: flashplugin-downloader but it is not installable
<cjwatson> (this is not to say that some people haven't been putting in consistent effort, but there aren't enough of them)
<Laney> which ftbfs list are you using?
<cjwatson> https://bugs.launchpad.net/ubuntu/+bugs?field.tag=ftbfs
<Laney> ta
<Laney> nemerle is binaries removed; close?
<directhex> IMHO we should just kill nemerle for real
<directhex> it's been a waste of archive space for years
<cjwatson> Laney: it'll still show up in test rebuilds if binaries are removed; if you close the bug it will just get refiled at some point, unless the source is removed
<cjwatson> removing binaries is a solution of sorts to NBS, but it doesn't eliminate FTBFS
<Laney> yeah we should probably just get it killed
<cjwatson> I don't object but would need a bug with rationale
<Laney> I have definitely made a net negative contribution to package numbers in Debian since I became a DD
<pitti> Laney: well, quality > quantity :)
<jml> Oh. Hmm.
<jml> flashplugin-downloader exists, but only for i386. amd64 seems to be out of luck.
<pitti> jml: flashplugin-downloader:i386 exists
<pitti> jml: perhaps you upgraded to oneiric early, but didn't set up multiarch as per slangasek's announcement?
<cjwatson> the idea was to magically transition people to that, but I don't think it's completed yet
<jml> pitti: well, *that* sounds plausible :)
<cjwatson> oh, could just be that, yes
<pitti> he made it sound like natty -> oneiric beta upgrade would work, but natty -> alpha-2 -> beta-1 wouldn't
<pitti> jml: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2011-August/000886.html
<jml> pitti: yeah, got it, thanks.
<didrocks> jml: I guess it's https://lists.ubuntu.com/archives/ubuntu-devel-announce/2011-August/000886.html
<jml> didrocks: thanks. I think I've got it though :)
<didrocks> jml: oupss, seems I didn't read the 2 last lines, sorry for repeating :)
<jml> didrocks: that's ok. :)
<debfx> pitti: pkgbinarymangler doesn't touch .desktop files if they don't have a Gettext-Domain key, right?
<pitti> debfx: it adds X-Ubuntu-Gettext-Domain to .desktop files if it can figure out the domain
<pitti> (and then removes translations)
<debfx> pitti: oh, how does it figure out the domain?
<pitti> debfx: ah, sorry, I mixed that up
<pitti> debfx: the answer to your question is "yes"
<pitti> debfx: dh_translations adds the -Domain: key
<debfx> ok, thanks
<pitti> debfx: (it's built from pkgbinarymangler source, but it's not done by pkgbinarymangler, the binary package)
<pitti> debfx: dh_translations checks a few standard places, like po/Makefile ("GETTEXT_PACKAGE"), setup.cfg ("domain="), and some cmake equivalent
<pitti> everything which doesn't use standard intltool/automake/python distutils/cmake needs to be fixed manually
<doko> pitti, alamanah and seahorse-plugins need a new upload
<debfx> pitti: dh_translations isn't run automatically though?
<pitti> doko: seahorse-plugins is gone
<pitti> debfx: no by debhelper; it's done by cdbs' gnome.mk (and perhaps pkg-kde-* cdbs modules)
<doko> pitti, fine, then please re-upload alamanah
<pitti> debfx: there's a --with-translations dh module
<pitti> doko: ah, you removed the binaries; right, doing
<pitti> doko: uploaded; will depwait until the libcruptui binaries get NEWed and published, but will sort itself out
<Laney> we can fix gdcm by syncing
<Laney> not sure if it needs ffe though
<Laney> http://sourceforge.net/apps/mediawiki/gdcm/index.php?title=GDCM_Release_2.0.18 "probably"
<doko> Sweetshark, please could you have a look at https://launchpad.net/bugs/835773
<ubottu> Launchpad bug 835773 in writer2latex (Ubuntu Oneiric) "writer2latex version 1.0.2-5ubuntu1 failed to build in oneiric" [High,Confirmed]
 * Sweetshark looks
<Sweetshark> eek, that dep might be ugly.
<hallyn> anyone in coredev have a few minutes to take a look at the fix for bug 838205 ?
<ubottu> Launchpad bug 838205 in systemtap (Ubuntu) "systemtap fails to compile simple tapsets" [High,Triaged] https://launchpad.net/bugs/838205
<hallyn> systemtap is unusable in o without it
<hallyn> zul: ^
<zul> hallyn: sure
<hallyn> zul: thanks
<tkamppeter> pitti, s-c-p uploaded and PK changes reported as bug 847896.
<ubottu> Launchpad bug 847896 in policykit-desktop-privileges (Ubuntu P-series) "cups-pk-helper/PolicyKit does not provide the desired authentication modes for system-config-printer" [High,New] https://launchpad.net/bugs/847896
<pitti> tkamppeter: I saw, thanks!
<charlie-tca> Can I assign bug 845549 to the desktop team?
<ubottu> Launchpad bug 845549 in lightdm (Ubuntu) "Do not ship /etc/lightdm/lightdm-gtk-greeter.conf" [High,Triaged] https://launchpad.net/bugs/845549
<dholbach> pitti, I think I can close https://bugs.launchpad.net/ubuntu/+source/python-httplib2/+bug/839826?
<ubottu> Launchpad bug 839826 in python-httplib2 (Ubuntu) "Incorrectly checks for SSL certificate domain names" [High,New]
<pitti> dholbach: oh, didn't that get auto-closed with the upload?
<dholbach> ok, closing :)
<Laney> Closes: vs. LP: ;-)
<pitti> argh, sorry
<pitti> dholbach: thanks!
<dholbach> de rien
<dholbach> Laney, do you think you can update your debdiffs.txt list?
<Laney> what for?
<Laney> bdmurray is tagging new ones
<Laney> s/tagging/dealing with/ (by subscribing spnosors)
<dholbach> oh, so they should all turn up on the sponsoring overview?
<dholbach> so is there a list of "old ones"?
<Laney> we only have to deal with the backlog
<Laney> that's my file
<dholbach> ok, can you update it? :-)
<dholbach> I came across a few ones that luckily were closed already
<Laney> closed since I generated it?
<dholbach> yep
<Laney> alright
<dholbach> thanks muchly
<Laney> dholbach: if I give you the script, can you get it running on some qa machine?
<dholbach> I guess I can - what does it need?
<Laney> just lplib
<dholbach> ok cool
<ubuntu__> hi all, Q). lh config --mode ubuntu --tasks "ubuntu-live" --distribution lucid hangs on grub, creating file /etc/default/grub/
<ximion> hi! could someone who has the required rights please mark lp bug #847591 as priority:"high" and mark it as "needs to be fixed until oneiric release" (target it to oneiric)?
<ubottu> Launchpad bug 847591 in packagekit (Ubuntu) "Error org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 127" [Undecided,In progress] https://launchpad.net/bugs/847591
<cjwatson> ximion: done
<ximion> cjwatson: Thanks!
<ximion> this bug renders PK unusable and will result in an FTBFS very soon, if it is the bug I have in mind
<ximion> (I'll provide a fix asap)
<dholbach> doko, I'll close https://bugs.launchpad.net/ubuntu/+source/seahorse-plugins/+bug/832888 - it seems the package was removed from oneiric
<ubottu> Launchpad bug 832888 in seahorse-plugins (Ubuntu Oneiric) "seahorse-plugins version 2.30.1-3ubuntu2 failed to build in oneiric" [High,Confirmed]
<doko> dholbach, yes, scroll back for pitti's comments
<dholbach> thanks
<desrt> doko: hey.  i was wondering if you could take a look at https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/838975
<ubottu> Launchpad bug 838975 in eglibc (Ubuntu) "weird pthread/fork race/deadlock" [Undecided,New]
<desrt> doko: it's causing the compiles for glib to occasionally hang on the builders
<doko> desrt, you're sure that this is not an glib issue?
<desrt> doko: i've attached a testcase that's written against pure libc
<desrt> doko: so it's either libc or kernel
<desrt> and i suspect libc (for reasons listed in the bug)
<doko> geser, pitti: vala issues in bug 832770 and bug 832760
<ubottu> Launchpad bug 832770 in vala-dbus-binding-tool (Ubuntu Oneiric) "vala-dbus-binding-tool version 0.1.6-1ubuntu3 failed to build in oneiric" [High,Confirmed] https://launchpad.net/bugs/832770
<ubottu> Launchpad bug 832760 in valatoys (Ubuntu Oneiric) "valatoys version 0.10.3-1 failed to build in oneiric" [High,Confirmed] https://launchpad.net/bugs/832760
<doko> soren, zul: does this still belong to server? bug 836997
<ubottu> Launchpad bug 836997 in user-mode-linux (Ubuntu Oneiric) "user-mode-linux: Missing build dependencies: linux-source-2.6.35" [High,Confirmed] https://launchpad.net/bugs/836997
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Beta 1 released | Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<zul> doko: dont think so
<doko> apw, ogasawara: is uns still maintained by the kernel team? or can it be removed? see bug 756096
<ubottu> Launchpad bug 756096 in uns (Ubuntu Oneiric) "uns version 3.2.0.24-0ubuntu5 failed to build on i386" [High,Confirmed] https://launchpad.net/bugs/756096
<apw> doko, erm no idea.  will have a look
<ogasawara> doko: I'm unaware of anyone from our team maintaining it.
<doko> jamespage, could you have a look at 835757? new minor upstream version in debian, which seems to address the build failure
<jamespage> looking at bug 835757 now
<ubottu> Launchpad bug 835757 in uimaj (Ubuntu Oneiric) "uimaj version 2.3.0-2 failed to build in oneiric" [High,Confirmed] https://launchpad.net/bugs/835757
<bregma> hey folks, I have a fix for a FTBFS bug in oneiric but I'm not sure where to go next, could I get some guidance?
<infinity> bregma: Follow up to the launchpad bug (or file one, if there isn't one) with a patch?
<bregma> what kind of a patch?  a merge request?  a debdiff?
<infinity> "A patch".
<infinity> People are far too picky about how they get their patches, and they shouldn't be.
<infinity> If you fixed the package, show us how.  Leave it to someone actually uploading the fix to worry about how to make it get there. ;)
<cjwatson> infinity++
<cjwatson> (aleph-2?)
<bregma> I have no idea what ;people uploading the fix' prefer, but I can provide any of debdiff, merge request to the repo on launchpad, or bare diff if that what someone would rather have, how am I supposed to tell?
<infinity> bregma: I like simple patches or debdiffs.  Others like merge requests.  Others still might like you to phone them and explain the fix.  I say, do what you find works best for you.
<infinity> bregma: We can deal with most/all of the above, and fretting over how you submit a patch isn't my idea of fun.  Just give us what works for you, and we'll make it work for us.
<dholbach> yeah, just attach the patch on the bug in LP (if there's a bug already) and subscribe ubuntu-sponsors - that should work
<nigelb> infinity: That's one of the best advice I've heard :)
<apw> doko, ok so this usn build failure seems to be include foobar again
<jamespage> doko: minor version upgrade on uimaj looks fine for sync - however will need a sync of maven-repo-helper as has a minimum required version higher that we have in oneiric by +x.x.1 which looks OK to me as well
<doko> jamespage, thanks, could you update the report?
<jamespage> doko: ack
<jamespage> doko: done
<doko> barry: please could you have a look at bug 835762? python2.6 hard coded?
<ubottu> Launchpad bug 835762 in ubuntustudio-controls (Ubuntu Oneiric) "ubuntustudio-controls version 0.4.7build1 failed to build in oneiric" [High,Confirmed] https://launchpad.net/bugs/835762
<micahg> barry: is there a reason why python-debian wasn't converted to dh_python2?
<Laney> dholbach: I'd forgotten how long this script takes to run ...
<dholbach> :)
<doko> apw, so yes, the world moves around the kernel ;-P
<apw> doko, no i mean its another case of broken handling of the includes ... different though, and not kernel fault, am working on fixing it
<doko> ahh, ok
<apw> doko, looks like long standning bad code.  probabally the compiler stopped doing something evil and it broke
<ejat> hi .. anyone looking into bug 811441
<ubottu> Launchpad bug 811441 in dbus (Ubuntu) "Unable to connect to the system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused (oneiric)" [Undecided,Confirmed] https://launchpad.net/bugs/811441
<SpamapS> hmm.. would it be an accurate statement that the alternate and mini isos don't use ubiquity at all?
<cjwatson> SpamapS: yes, except for oem-config
<SpamapS> cjwatson: I've just redirected bug 847782 to d-i from ubiquity then.. I'm thinking this is actually correct behavior from d-i .. and we may just close the bug.. but its probably worth a bit of discussion first.
<ubottu> Launchpad bug 847782 in debian-installer (Ubuntu) "Ubiquity writes a permanent ethernet entry in interfaces file" [Medium,New] https://launchpad.net/bugs/847782
 * SpamapS already s/Ubiquity/installer/ as well
<cjwatson> I'll have a look when my internet access isn't made of stale cheese.
<cjwatson> SpamapS: surely this is a bug in the new upstart network jobs?  the 'auto' line has been there a lot longer than they have; they're what broke things
<cjwatson> (unless the pre-upstart init scripts behaved the same way; I forget)
<ScottK> SpamapS: Can haz clamav in -updates?
<ejat> thanks cjwatson
 * ejat just upgrade to oneiric .. need to do the manual work around .. 
<SpamapS> ScottK: I did that last Friday I thought
<SpamapS> ScottK: its possible that sru-release timed out.. Is clamav big?
<ScottK> Not really.
<SpamapS> cjwatson: the pre-upstart scripts would wait for 1 minute per interface.
<ScottK> https://launchpad.net/ubuntu/natty/+source/clamav says it's not there.
<SpamapS> cjwatson: upstart did away with that waiting.
<SpamapS> cjwatson: which caused *a lot* of issues for server users with complex network setups.
<SpamapS> cjwatson: so the idea now is to wait only if its listed in /etc/network/interfaces .. but I may have underestimated how many people have an 'auto eth0' that will never come up. :-P
<SpamapS> ScottK: indeed it did not go through. Trying again.
<ScottK> Thanks.
<SpamapS> ScottK: succeeded this time
<ScottK> Cool.  Thanks again.
<ghostcube> ich kenne einen philosophie studenten der hat nen job gefunden :D
<ghostcube> nanananana
<ghostcube> ups wrong channel lol
<ghostcube> i hate quassel sometimes
<ghostcube> :D
<ghostcube> sorry guys
<barry> ScottK: or other kubuntuistas.  i just grabbed the daily image for kubuntu amd64, but when i try to install it in a vm, i get "No installable kernel was found in the defined APT sources".  it ask if i want to continue w/o installing a kernel, which the warning makes me think is a bad idea.  does anybody know if this is a temporary (i.e. archive) problem, or something more serious that warrants a bug report?
<barry>  
<ScottK> It was temporary.
<ScottK> The alternates were rebuilt after and should work.
<barry> ScottK: cool, thanks, i'll try again
<bdmurray> Is there somebody who might review my apport merge proposal and upload it?
<bdmurray> https://code.launchpad.net/~brian-murray/apport/ubiquity-dupe-sig-improvements/+merge/75050
<doko> barry, please don't set reports like bug 835001 to incomplete. it's reproducible in the rebuild. it doesn't have to ftbfs in the main archive
<ubottu> Launchpad bug 835001 in pyacidobasic (Ubuntu Oneiric) "pyacidobasic version 1.0-3 failed to build in oneiric" [High,Confirmed] https://launchpad.net/bugs/835001
<barry> doko: how can you debug it if it only ftb in the test rebuild then?
<doko> barry, does it really build in a clean/fresh pbuilder chroot?
<doko> most likely an issue with python versions
<barry> it built in my sbuild cleanly.  i'll retry it in pbuilder after finishing up on python-django-nova
<doko> Sweetshark, ooo-build-extensions is still in unstable, black-list it?
<doko> barry, fix uploaded
<barry> doko: fix for...?
<doko> the build failure
<barry> doko: acidobasic?
<doko> yes
<barry> doko: okay cool, thanks
<doko> Laney, https://launchpadlibrarian.net/79716630/buildlog_ubuntu-oneiric-i386.fregression_2100.76-3_FAILEDTOBUILD.txt.gz
<SpamapS> Hrm, so I just found that sary-ruby ftbfs on Ubuntu where it does build on sid because of libglib being multi-arch .. is Debian headed that direction already?
<NCommander> Who maintains the rmadison CGI? I'd like to see it properly work with ports architectures
<micahg> +1 :)
 * Pici as well
<soren> NCommander: I believe it's cjwatson.
 * NCommander pokes at the script
<soren> doko: I'd say yes.
<soren> doko: I'm on holiday for a couple of days. I'll take a look when I get back.
<doko> soren, thanks
<soren> doko: Thanks for pointing it out!
<RoboTux> Greetings everyone
<RoboTux> The tcc package in Ubuntu suffers a quite bad bug: it generates programs which only runs on Debian and Ubuntu
<RoboTux> The fix is in Debian and a merge package has successfuly been generated
<RoboTux> Could anyone update the package in Ubuntu to this new version? (the changes are small and tested since 2 months in Debian)
<RoboTux> https://bugs.launchpad.net/ubuntu/+source/tcc/+bug/820983 Here is the bug
<ubottu> Launchpad bug 820983 in tcc (Ubuntu) "Set a wrong path to ELF interpreter (breaks ELF ABI)" [Undecided,New]
<doko> I want to turn off compiz. 5th crash today ... what's the best option?
<micahg> unity-2d?
<doko> micahg, just install on top?
<micahg> doko: should be available from lightdm
<doko> hey, feels even faster ...
<RoboTux> Does anyone know who IÂ should ask about tcc?
<micahg> RoboTux: https://wiki.ubuntu.com/SponsorshipProcess
<RoboTux> Thanks
<doko> and colsXrows numbers are back again when resizing \o/
<cjwatson> NCommander,soren: not within my control; the mirror that CGI script is inspecting doesn't have ports on it
<cjwatson> NCommander,soren: not within my control; the mirror that CGI script is inspecting doesn't have ports on it
<geser> cjwatson: did you sync tecnoballz? if yes, it "Failed to upload": Require Pre-Depends: dpkg (>= 1.15.6) when using xz compression. (https://launchpadlibrarian.net/79382192/upload_2868254_log.txt)
<Laney> doko: ah, I had to use --build-dep-resolver=internal
<Laney> doko: we need to remove 'vr'
<doko> Laney, I assume, just the source?
<doko> ahh, no. binary and source
<Laney> yeah it has binaries too
<Laney> was removed from sid a while ago & provides an uninstallable real package which would otherwise be pure virtual
<SpamapS> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Beta 1 released | Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: SpamapS
<cjwatson> geser: hm, I did but I never got a failure mail.  I'll fix that, thanks
<Laney> native sync bug (due to not attributing you correctly)
<cjwatson> Laney: is that the same as the failure to show up in +uploadedpackages?
<Laney> I belive that's all the same bug, yes
<SpamapS> argh
 * SpamapS wonders when he'll be able to stop fighting unity/compiz and just use his computer. :-P
<infinity> SpamapS: When you switch to xubuntu.
<SpamapS> ;)
#ubuntu-devel 2011-09-13
 * SpamapS installed originally from Xubuntu
<SpamapS> I actually like Unity + Compiz when they work. A lot. Just tired of having to restart them because of some weird issue.
<SpamapS> has been much better the last 2 weeks
<micahg> SpamapS: there's always unity-2d
<SpamapS> micahg: indeed, it does seem to survive longer than unity between weirdness/crashing
<photon> hi. I am scanning through archive.ubuntulinux.org, and I noticed that some .deb files are fairly small (just a few kb), like http://archive.ubuntulinux.org/ubuntu/pool/multiverse/u/ubuntu-restricted-extras/. why is that? shouldn't they be megabytes given how much software is in them?
<gusnan> photon, those are probably pseudo-packages, not containing much information themself, but just dependencies on other packages with the actual stuff.
<TheMuso> That package in partiular is a metapackage, which pulls in other packages.
<photon> I looked into the .deb archive and in /DEBIAN/control, there are only recommendations, not dependencies, and even those are far less than what apt-get install ubuntu-restricted-extras would install. so I'm confused
<photon> maybe I'm looking int he wrong file.
<TheMuso> Yes, recommends are installed by default, so the recommended packages get installed.
<TheMuso> It means that you can remove one or more of the recommended packages, and the rest of the packages don't get removed with them.
<photon> Got it.
<pitti> Good morning
<pitti> doko_: vala FTBFS> looking
<didrocks> good morning
<SpamapS> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Beta 1 released | Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<SpamapS> oops
<micahg> heh
<broder> could i get a core dev to do me a favor and accept the series nomination on bug #848687?
<ubottu> Launchpad bug 848687 in linux (Ubuntu) "DRI applications hang after DPMS standby on i965" [Undecided,New] https://launchpad.net/bugs/848687
<dholbach> good morning
<SpamapS> broder: done
<dholbach> pitti, it seems like we need to bring libgdamm4.0 back if we want glom buildable at all
<pitti> dholbach: ah, glom isn't in Debian, so they could remove it
<dholbach> yep
<pitti> I guess someone can reupload it
<broder> SpamapS: thanks :)
<dholbach> pitti, ok - I'll have a look - seems like glom does not build - maybe a more recent version will fix it
<micahg> dholbach: upstream commented as such, but one of the build depends was removed
<pitti> presumably that very from above, libgdamm
<dholbach> I think upstream has a PPA - I'll have a look how much of their work we can reuse
<dholbach> I'll let you know
<micahg> sorry, missed that somehow...
<dholbach> pitti, maybe glom should be part of the please-update-these-desktop-packages overview, so we don't let old versions rot in the archive again :)
<pitti> nah, it's in universe
<pitti> a lot of universe packages are like that unfortunately :/
<micahg> dholbach: shows up here where it belongs: http://qa.ubuntuwire.com/uehs/no_updated.html, unfortunately, we need more people looking here :)
<dholbach> ok :)
 * micahg actually thinks that page is out of date...
 * micahg moves this to -motu
<Laney> I have been trying to unblock glom in Debian for ages :(
<Laney> current problem is jsogo refusing to maintain goocanvas properly
<dholbach> Laney, what's the issue?
<Laney> the current releases need a newer goocanvasmm which needs a newer goocanvas
<dholbach> ah ok, for now, I guess I just get 1.18.3 into Ubuntu which is the latest stable and builds
<dholbach> for P we can try something new
<dholbach> is it hard to get a new goocanvas into Debian?
<Laney> kind of is if the maintainer doesn't want to do it
<Laney> would the 1.18 release work?
<dholbach> yes, it looks good
<dholbach> I'm just sorting out a few other small issues while I'm at it
<dholbach> we just need to get gdamm4.0 added back to the archive
<dholbach> but I uploaded it already
<dholbach> can somebody get libgdamm4.0 out of NEW please? it was removed a bit too quickly (glom needs it)
<pitti> dholbach: done
<dholbach> thanks pitti
<ogra_> dholbach, do you still need an armel testbuild ?
<dholbach> ogra_, no it's all sorted
<dholbach> thanks ogra_
<ogra_> :)
 * doko can't decide if the archive looks like a garbage dump or a mortuary ...
<pitti> looks like a big city; shiny center, but some suburbs are really chabby
<pitti> "shabby"
<didrocks> pitti: I like this metaphor :)
<ajmitch> pitti: does this mean that a bulldozer needs to be driven through some suburbs?
<pitti> ajmitch: in some cases a bulldozer, in some cases a citizen's initiative with some mortar and paint :)
<pitti> hildon or gnome 2 panel applets were definitively in the bulldozer class, but most packages have relatively easy fixes
<ajmitch> it's sad to see the applets go :)
<dholbach> can somebody bulldoze libgdamm4.0 out of binary new? :-P
<doko> fun ...
<doko> Checking if libc on this machine contains:
<doko> grep: library_contents: No such file or directory
<doko>   vsprintf: No, I don't think
<doko> grep: library_contents: No such file or directory
<doko>     _doprnt: NO, THIS IS A PROBLEM: NO VSPRINTF AND NO _DOPRNT
<doko> SPIM WILL NOT RUN PROPERLY
<doko> grep: library_contents: No such file or directory
<doko>   vfprintf: No, I don't think
<doko> grep: library_contents: No such file or directory
<doko>     _doprnt: NO, THIS IS A PROBLEM: NO VFPRINTF AND NO _DOPRNT
<doko> SPIM WILL NOT RUN PROPERLY
<doko> grep: library_contents: No such file or directory
<doko>   strtoul: No, I don't think
<doko> grep: library_contents: No such file or directory
<doko>   strtol: No, I don't think
<doko> grep: library_contents: No such file or directory
<doko>   memcpy: No, I don't think
<cjwatson> doko: I'm guessing multiarch fallout
<doko> sure, I just did "like" the grep approach
<cjwatson> dholbach: one moment
<dholbach> cjwatson, thanks muchly
<doko> cjwatson, ahh, already done
<cjwatson> ah, ok, cool
<dholbach> fantastic, thanks
<dholbach> nice, we're down from 661 to 560 FTBFS bugs today
<nigelb> micahg: Congrats \o/
<ScottK> Sweetshark: What are the odds of the LO FTBFS on i386 getting fixed today?  FYI, it's breaking amd64 live CD/DVD builds at the moment.
<cjwatson> mvo: I could use help with bug 848907; I don't see why it should have broken recently
<ubottu> Launchpad bug 848907 in apt (Ubuntu) "apt crashes on initial installation of oneiric" [Undecided,New] https://launchpad.net/bugs/848907
<Sweetshark> ScottK: Im currently building with a fix. but LO has quite some buildtime ...
<doko> siretart, ping
<Sweetshark> ScottK: It just went past the critical corner, so its looking good.
<mvo> cjwatson: is that reproducable?
<cjwatson> mvo: I reproduced it after seeing a user report of the same thing, which he's experienced both yesterday and today
<cjwatson> mvo: haven't yet figured out how to reproduce it from the command line
<cjwatson> regfree crash suggests memory corruption of some kind, but getting valgrind into d-i is ... painful
<mvo> cjwatson: right, but its reproducable by installing kubuntu in a vm with the altnerative CD?
<cjwatson> that's all I did, yes
<mvo> thanks, I will rsync me updated images and try it out then
<cjwatson> I would expect Ubuntu to do the same thing; we haven't got to the flavour-specific parts of installation at this point
<cjwatson> I just made a 10G disk image and did a use-entire-disk install
<cjwatson> en_GB locale, otherwise all defaults
<cjwatson> will try it under strace now
<mvo> cjwatson: great, the rsync is running. you did the install inside kvm I assume? is there a chance to get a slightly better readable backtrace then from the screenshot ?
<cjwatson> kvm yes; maybe, will try hacking about at base-installer
<mvo> cjwatson: I can poke the code in the meantime, there were some changes in the cdrom autodetect code recently (~4 weeks ago) that might be the issue
<cjwatson> mvo: I think this is recent though, I didn't see it when I was preparing the partman-crypto fix this guy was testing
<cjwatson> mvo: I wonder if it's something to do with the recent eglibc upload (and hope it's not)
<cjwatson> I think the backtrace must be being printked or something; I guess I'll just leave it on a sacrificial console
<doko> Laney, did the comment should go to bug 831235?
<ubottu> Launchpad bug 831235 in gdcm (Ubuntu Oneiric) "gdcm version 2.0.17-3.1 failed to build in oneiric" [High,Confirmed] https://launchpad.net/bugs/831235
<Laney> yes
<Sweetshark> ScottK: the fix is uploaded to chinstrap and waiting for sponsoring.
<Laney> doko: as in, the Debian version builds fine
<doko> Laney, yes transient build failure, you shouldn't upgrade gcj during a test rebuild ;)
<Laney> the current one works?
<cjwatson> mvo: reproduced, but the backtrace goes all over tty1 even if the current console is tty3 :-(
<Laney> there were a lot of probems that we helped the maintainer with in Debian
<doko> yes
 * cjwatson extracts the strace
<doko> still running
<Laney> arch/indep issues
<ejat> is this bugs 847591 still in progress ? or already fix but not release
<ubottu> Launchpad bug 847591 in packagekit (Ubuntu Oneiric) "Error org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 127" [High,In progress] https://launchpad.net/bugs/847591
<ScottK> Sweetshark: Thanks.
<cjwatson> mvo: http://people.canonical.com/~cjwatson/tmp/base-installer.trace.xz - probably includes lots of junk, I'm about to start having a look
<cjwatson> that's attaching strace to bootstrap-base.postinst after run-debootstrap has been forked
<cjwatson> I suspect it isn't helping that locale-gen removes /usr/lib/locale/C.UTF-8 which is owned by the libc-bin package
 * cjwatson goes to fix that
<Sweetshark> ScottK: uploaded (thanks pitti)
<Laney> doko: you are right, it is transient. I can't get on https://buildd.debian.org/status/logs.php?pkg=gdcm&ver=2.0.17-3.1 to remind myself what the problem was.
<Laney> get logs from*
<doko> Laney, I had given it back: https://launchpad.net/ubuntu/+archive/test-rebuild-20110816/+build/2693757
<Laney> great
<Laney> I just knew 3.1 failed and -4 did not, but, well it's not reproducible so "oh well".
<Laney> oh, the red text gives you the log
<Laney> that does not look like a link.
<cjwatson> mvo: aha, reinstall libc-bin in /target after the crash and then apt segfaults again
<cjwatson> mvo: better screenshot attached
<cjwatson> so almost certainly due to:
<cjwatson>   * debian/patches/localedata/locale-C.diff: Don't include ISO14651
<cjwatson>     collation rules in C.UTF-8 locale.
<cjwatson> but I don't know if this represents an eglibc bug or a wrong assumption in apt
 * cjwatson installs gdb and valgrind to try to dig further
<stgraber> micahg: can you confirm you are now on the DMB mailing-list?
<mvo> nice cjwatson! that is really much more helpful
<cjwatson> mvo: ... and now valgrind output attached
<mvo> cjwatson: thanks, I wonder if the compilation error is new or maybe triggering the bug
<achiang> pitti: good morning, thanks for sponsoring some of my patches. i see that you created bzr branches... should i have done that on my own to save time?
<pitti> achiang: I did?
<cjwatson> mvo: it doesn't happen in LC_ALL=C
<achiang> pitti: well, someone created bzr branches. :) see LP: #770862 as an example
<cjwatson> now, I wonder if I can recreate it in an unstable chroot
<mvo> cjwatson: *ick* it doesn't?
<cjwatson> mvo: indeed; that's why I was suspecting that localedata change
<cjwatson> if I can recreate it in unstable, I'll ask debian-glibc about it
<cjwatson> there's no rationale for the change
<pitti> achiang: presumably the auto-importer
<achiang> pitti: ah, interesting. ok, thanks, i won't worry about it then
<dholbach> does the publisher run every now and then nowadays? seems like libgdamm4.0 still did not make it through binary new
<cjwatson> it's crashing
<dholbach> ah ok :/
<cjwatson> I'll escalate
<dholbach> thanks a lot cjwatson
<mvo> cjwatson: thanks, what channel? I would like to follow this - fwiw I think there is  a potential double free (or delte in this case) in the code that it worth fixing
<cjwatson> mvo: the mailing list
<mvo> ok
<hallyn> WTF?  alternate installer from sunday doesn't have a kernel it can install?
<jdstrand> pitti: hi! it just occurred to me that we don't have an equivalent of gdm-guest-session for lightdm
<ScottK> No.
<ScottK> hallyn: Look at the newer one.
<pitti> jdstrand: no, it's built into lightdm
<jdstrand> pitti: oh? are there docs on that?
<cjwatson> hallyn: see my discussion with mvo immediately above your question
<hallyn> ScottK: ok, thanks
<pitti> jdstrand: docs for what? it's in the indicator and also in the greeter
<cjwatson> ScottK: actually that wasn't really it
<cjwatson> ScottK: that broke something slightly different ...
<ScottK> Oh?
<jdstrand> pitti: sorry, I was not at all clear. I meant the apparmor profile
<cjwatson> ScottK: the weekend problem was wrong udebs on the CD, but this is apt falling over when trying to install the kernel on the target system
<cjwatson> or actually when trying to detect what to do
<mvo> cjwatson: I have some code that may fix the issue, it certainly fixes the double free but I'm not sure if that is enough. it seems to be only triggered (the double free) if there is a error in the regexp compilation
<pitti> jdstrand: hm, it ought to, but now that you mention it I can't see it
<jdstrand> pitti: shall I file a bug?
<pitti> jdstrand: please
<jdstrand> ok
<pitti> jdstrand: I discussed the four bugs you mentioned on Friday with Robert this morning, FYI
<pitti> jdstrand: one is fixed, one committed, I just sent an MP for the third
<jdstrand> pitti: I saw. thanks! I have updated our lists accordingly
<hallyn> cjwatson: (sorry, i'm not sure which you're pointing to, but it sounds covered, so great :)
<m4n1sh> provided with say -lzeitgeist-1.0 can I find out to which this shared library it will link to?
<m4n1sh> means the actual file path
<m4n1sh> or even the name would be enough
<jdstrand> pitti: fyi, bug #849027
<ubottu> Launchpad bug 849027 in lightdm (Ubuntu Oneiric) "lightdm does not provide an equivalent to the gdm guest session AppArmor profile" [Undecided,New] https://launchpad.net/bugs/849027
<pitti> jdstrand: thanks, bumped accordingly
<jdstrand> cool, thanks
<mvo> cjwatson: if I upload a new version to my PPA will you be able to easy test if my fix is sufficient (assuming the double delete is actually the real problem here)
<cjwatson> mvo: I think so
<doko> njpatel, re bug 817691, do you really mean glibc, not glib2.0?
<ubottu> Launchpad bug 817691 in glibc (Ubuntu) "[Oneric] unity-panel-service crashed with SIGSEGV in getenv()" [Critical,Confirmed] https://launchpad.net/bugs/817691
<bdmurray> superm1: Would you please look at my comments in bug 816199 and reconsider the fix?
<ubottu> Launchpad bug 816199 in dkms (Ubuntu) "dkms_packages.py crashed with ValueError in _apt_pkg(): package does not exist" [High,In progress] https://launchpad.net/bugs/816199
<slangasek> ScottK: honeyd> ack; would you like me to take this one?
<ScottK> slangasek: Yes.  Please.
<slangasek> ok, will do
<ScottK> Thanks.
<mvo> cjwatson: I uploaded it to https://launchpad.net/~mvo/+archive/ppa/+packages?field.name_filter=&field.status_filter=published&field.series_filter=oneiric
<mvo> cjwatson: its building currently
<njpatel> doko, yeah, going by what we found on Google and the other bugs in firefox etc with the same trace
<doko> njpatel, I'd rather assume some kind of memory corruption elsewhere. really doesn't look like eglibc's fault
<njpatel> doko, it might well be, maybe gettext?
<doko> njpatel, then why assign it to eglibc, both ubuntu and upstream?
<njpatel> doko, because the crash is in getenv and we needed some opinions from people familiar with that? I can guess it's in gettext but it doesn't make it so...
<njpatel> doko, if you have a better place let me know and I'll change it asap
<njpatel> doko, did you look at the linked bug list for the other projects?
<doko> njpatel, there is this one new report in unity, the other list are up to years old
<njpatel> urgh, really? what the hell was I reading then :/
 * njpatel looks
<doko> njpatel, and the fact that every of these apps is using gtk, is not very assuring
<njpatel> the top 8 reports are from 2011, most of them after june/july
<njpatel>  doko it does seem gtk is involved in most of them
<doko> njpatel, e.g. bug 278095 is about corruption of the env
<ubottu> Launchpad bug 278095 in at-spi "MASTER crash in getenv() ... spi_atk_bridge_exit_func()" [High,New] https://launchpad.net/bugs/278095
<njpatel> doko, yep, saw that, so unity-panel-service, gnome-keyring from O and evince and gnome-session from N
<njpatel> doko, thanks, I'll move it back to unity for now and ask upstream gtk if they have any ideas
<doko> pitti, didrocks, mterry, Sweetshark: any idea of the relevance of bug 725250?
<ubottu> Launchpad bug 725250 in lo-menubar (Ubuntu) "[MIR] lo-menubar" [Undecided,Confirmed] https://launchpad.net/bugs/725250
<slangasek> can someone tell me why the notification area seems to have completely disappeared from my panel due to an update sometime in the past couple of weeks?
<pitti> doko: no, it's too broken for that
<hallyn> ScottK: fwiw, today's alternate installer is no better :(
<mterry> doko, yeah, I don't think it's prime time yet
<pitti> doko: bug updated
<cjwatson> hallyn: yeah, on it :-)
<tjaalton> irc admins available? need the bot back on #ubuntu-x
<tjaalton> bugbot that is
<bdmurray> slangasek: bug 553745 has some mention of it occuring again in Oneiric - subsequently I've removed the bugpattern for it so we can get another crash report in
<ubottu> Launchpad bug 553745 in plymouth (Ubuntu Maverick) "plymouthd crashed with SIGSEGV in ply_event_loop_process_pending_events()" [High,Triaged] https://launchpad.net/bugs/553745
<superm1> sure bdmurray
<superm1> someone with buildd knowledge, is it actually possible to call apt-get source  to fetch a source package from ftpmaster.internal on a buildd during a build?
<slangasek> bdmurray: right, was talking to Jason about that - thanks, will be happy when we can get more info
<hallyn> cjwatson: great, thanks :)
<bdmurray> pitti: Could you review / merge https://code.launchpad.net/~brian-murray/apport/ubiquity-dupe-sig-improvements/+merge/75050 ?
<pitti> bdmurray: merged, thanks
<pitti> Riddell: "Give david.wonderly access to upstream docs" is the only remaining WI for desktop-o-kubuntu-documentation-review; is that blocked, or just needs to happen?
<Riddell> pitti: I've no idea, I'm not working on Kubuntu
<Riddell> pitti: but David is DarkwingDuck on #kubuntu-devel
<pitti> Riddell: right, but that sounded like an ACL issue
<pitti> like adding him to a team or so
<pitti> Riddell: I'm happy to postpone that one if you want, just reviewing leftover WIs
<Riddell> I have no opinion, you should ask the kubuntu team
<pitti> ok
<mvo> cjwatson: any luck with the ppa version?
<chrisccoulson> doko, hmmm, bug 831256 is a bit weird
<ubottu> Launchpad bug 831256 in dehydra (Ubuntu Oneiric) "dehydra version 0.9.hg20110609-1ubuntu1 failed to build in oneiric" [High,Confirmed] https://launchpad.net/bugs/831256
<chrisccoulson> i don't see how that fails :/
<cjwatson> mvo: not yet, I was chasing things down in eglibc: see thread at http://lists.debian.org/debian-glibc/2011/09/msg00036.html
<mvo> cjwatson: aha, nice!
<cjwatson> but it's true that segfaulting is a bad response to regcomp failing
<cjwatson> just a moment, testing
<cjwatson> mvo: right.  that does indeed fix the segfault, thanks, and valgrind is now happy.  of course we still need to fix the eglibc bug since now the regexes are incorrectly not recognised, and I suspect this will break other things
<cjwatson> hopefully aurel32 will reply quickly
<ahasenack> hi, could someone please nominate https://bugs.launchpad.net/landscape-client/+bug/813477 for maverick and natty?
<ubottu> Launchpad bug 813477 in Landscape Client "Update landscape-client to 11.07.1.1" [High,Fix committed]
<cjwatson> ahasenack: done
<Laney> I would if the ... oh, never mind
<mvo> cjwatson: yeah, much agreed, thanks a bunch for testing, I will upload the fix next
<ahasenack> cjwatson: thanks
<tjaalton> barry: ping re libfsobasics, libfsotransport; I believe these could be synced?
<tjaalton> seems that libfsobasics is blacklisted currently, is there a way for me to see why?
<slangasek> tjaalton: the blacklist is unfortunately not synced to anything public; let me look for ou
<slangasek> you
<tjaalton> slangasek: thanks
<tjaalton> i know it ftbfs
<slangasek> tjaalton: in fact, I don't see it in the blacklist - how did you determine that it's blacklisted?
<Laney> https://launchpad.net/ubuntu/oneiric/+localpackagediffs?field.name_filter=libfsobasics&field.package_type=all&field.package_type-empty-marker=1
<tjaalton> slangasek: I ran syncpackage
<tjaalton> Laney: ooh
<Laney> Launchpad autoblacklists when the Ubuntu version deviates AFAIK
<slangasek> right, so you have to override
<doko> chrisccoulson, given it back, and it did build. thanks
<cjwatson> slangasek: http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt FYI
<slangasek> cjwatson: oh, ok
<slangasek> cjwatson: where's the cronjob that syncs that?  I have trouble figuring out how things get to that directory
<cjwatson> slangasek: cocoplum:~lp_archive/dak/cron.sync
<cjwatson> but yeah, in this case it's more confusing UI from syncpackage
<slangasek> got it
<tjaalton> so, are the ffe-rules relaxed when fixing ftbfs bugs? :)
<slangasek> no
<tjaalton> damn
<slangasek> exceptions may be more likely to be granted, but there's still a need for due diligence
<infinity> (Unless you mean you've JUST fixed the FTBFS bug, which isn't a feature, and not subject to FF)
<infinity> But yeah, "I've added 7 new features, and accidentally fixed a build failure at the same time" doesn't fly. :P
<tjaalton> in these cases the packaging has been fixed too, but all our changes could be dropped as well
<tjaalton> i'll file bugs then
<bambee> Hi, plymouth is not shown at all on startup, except if I remove "vt.handoff=7" manually (also with CTRL+ALT+F1 during the boot process, it works). it works fine on reboot/shutdown. Any ideas ?
<bambee> the system does not switch back to vt 1... it's strange :\
<slangasek> how do you mean, "does not switch back to vt1"?
<SpamapS> slangasek: so, the "wait for interfaces" change has ruffled some feathers. It seems that d-i always leaves behind a permanent 'auto ethX' after installation.. which means a lot of people are upgrading and then seeing a 2 minute delay
<bambee> slangasek: I just wonder why I don't see anything (nouveau and kms work)
<bambee> if I type "CTRL+ALT+F1" during the boot process, I see plymouth, otherwise I see nothing
<slangasek> SpamapS: wait for interfaces> yep, caught that the other day in the mail trail.  Do you think it's feasible to clean that up on upgrade?  Or maybe we should exclude interfaces that are configured as merely auto/dhcp in favor of checking for NM running?
<slangasek> bambee: you see plymouth during the boot process only when typing Ctrl+Alt+F1, *and* vt.handoff=7 is being passed?
<cjwatson> I still think NM is a red herring; if NM was installed, then 'auto' lines would've been removed at the end of installation
<slangasek> oh?
<ScottK> slangasek: If it's relevant, bambee is on Kubuntu and it's not very good about transitions being invisible.
<slangasek> ScottK: well, so far we're discussing flavor-neutral bits of the boot
<ScottK> OK.
<SpamapS> cjwatson: ok so there's already some intelligence there in NM's postinst?
<ScottK> Just mentioning it because he may be seeing stuff that's normally not visible in Ubuntu.
<cjwatson> SpamapS: I gave specifics in the bug
<SpamapS> oh I haven't caught up yet
 * SpamapS reads
<bambee> slangasek: exactly
<slangasek> cjwatson: do you have any suggestions on where to look next with bambee's handoff issue?  Sounds like something falling down in the junction between grub, kernel and plymouth
<bambee> an interesting info: it works just fine with {kubuntu,ubuntu}-11.10-desktop-amd64 (the livecd), and it does not work on my system
<cjwatson> maybe plymouth:debug=file:/run/plymouth.debug (assuming oneiric)
<slangasek> bambee: could you try booting with that option, plus vt.handoff=7?
<cjwatson> plymouth is supposed to display on vt7, not vt1
<slangasek> indeed
<bambee> slangasek: sure
<SpamapS> cjwatson: I agree 100% with the position that a change in behavior at this change would be more harmful than good. I wonder if we can notify users in plymouth that the system is waiting for network configuration so, if nothing else, we know how to tell them to fix it when they report a slow boot.
<cjwatson> (because otherwise the smooth transition from grub to plymouth wouldn't work)
<cjwatson> SpamapS: that sounds straightforward and a good idea, yes
<slangasek> bambee: two major differences between the live CD and an installed system are the boot loader used, and the fact that plymouth is always started in the initramfs for a liveCD
<SpamapS> that should be easy to do in failsafe.conf
<slangasek> bambee: you could eliminate one possible source of this noise by installing the cryptsetup package on your installed system, which will cause plymouth to be started from initramfs on the installed system
<bambee> slangasek: trying with both (option+package), bbl
<bambee> slangasek: well, nothing is generated in /run   (/run/plymouth.debug does not exist)
<bambee> /proc/cmdline: BOOT_IMAGE=/vmlinuz-3.0.0-11-generic root=UUID=5b2e8c3c-eacf-494b-bb21-2363d0d235f2 ro plymouth:debug=file:/run/plymouth.debug quiet splash vt.handoff=7
<slangasek> bambee: blast; that's somewhat consistent with my own experiences trying to get output from plymouth in oneiric, but I was hoping cjwatson had the magic recipe (/run vs. /var/log)
<slangasek> bambee: so I'll take some time to hack on that today and see if I can figure out what's going on with logging.  In the meantime, can you try installing cryptsetup?
<slangasek> (and rebooting, of course)
<bambee> slangasek: sure, trying
<cjwatson> maybe try /run/initramfs/plymouth.debug instead
<cjwatson> historically I used /dev/.initramfs/plymouth.debug, actually, but nowadays somewhere under /run ought to work
<cjwatson> I haven't debugged plymouth since the /run transition
<slangasek> I thought the log only got written to disk when /etc/init/plymouth-log.conf fired
<SpamapS> cjwatson: one last question.. does d-i call ifblacklist_migrate.sh ? I only see it called in n-m's postinst configure if we're coming from before 0.6.5-0ubuntu12 ..
<bambee> cjwatson: trying too
<bambee> reboot
 * SpamapS can probably c/o d-i and confirm that if you don't know off the top of your head ;)
<dobey> hrmm, no patch pilot atm?
<cjwatson> SpamapS: yes, it does, that was why I mentioned it
<cjwatson> SpamapS: netcfg
<cjwatson> ./finish-install.d/55netcfg-network-manager:11:         sh /usr/lib/NetworkManager/ifblacklist_migrate.sh
<SpamapS> cjwatson: ahh ok, thanks. :)
<cjwatson> slangasek: true
<cjwatson> slangasek: but that should happen as soon as the rootfs is writable
<cjwatson> slangasek: actually, I don't think that applies to the debug log
<cjwatson> plymouth-log is about /var/log/boot.log
<slangasek> cjwatson: ok - I thought it did, I'll have a look at the code a bit later to confirm.  Anyway, it doesn't seem to work for me at all, possibly because the job races plymouth-stop
<cjwatson> which interestingly appears to date from 2011-07-13 on mmy system, hmm
<slangasek> maybe we should make 'plymouth quit' do a last-ditch attempt to write the logs
<dobey> hrmm
<dobey> should maybe ubuntu-sponsors be subscribed to all merge proposals into lp:~ubuntu-branches owned branches?
<SpamapS> dobey: effectively sponsors are, because they show up in the sponsorship queue
<ahasenack> SpamapS: hi, finally finished the other ubuntu releases for #813477, can you upload the missing Maverick and Natty packages?
<dobey> SpamapS: do they get spammed by LP for them though? or do they just show up on the queue page? :)
<SpamapS> dobey: the queue. I don't think I'd want to read all of ubuntu-sponsors' bugmail ;)
<SpamapS> ahasenack: ACK, will take a look later today, in the middle of a few things.
<ahasenack> SpamapS: ok, thanks
<bambee> slangasek: even with cryptsetup installed, it does not work
<dobey> SpamapS: well this isn't bug mail, it's code review mail. :)
<slangasek> bambee: thanks, that eliminates one source of difference.  The remaining major difference is the bootloader itself, which again points to the grub+kernel vt handoff
<bambee> cjwatson: plymouth produces no debug outputs here :\ (even with /var/log)
<dobey> SpamapS: hopefully it's not as bad as bugs mail
<SpamapS> dobey: the queue is, IMO, a much better way to approach it, as things are sorted by their age.. so right away you know which thing has been sitting in the queue the longest
<SpamapS> email is an interrupt driven system and favors the squeaky wheels
<bambee> slangasek: oh! I still have a 2.6.38 kernel here (just in case)
<bambee> I could test with the 2.6.38....
<cjwatson> bambee: "even with /var/log"> doesn't make sense
<dholbach> can somebody please get the glom packages out of binary new?
<slangasek> bambee: sure, that may also be a useful data point - even in the event that it works with the older kernel, this doesn't necessarily point to a kernel bug, but it at least gives us a place to look (i.e., git-bisect)
<dobey> SpamapS: i take it you mean https://launchpad.net/ubuntu/oneiric/+queue ?
<cjwatson> dobey: http://reports.qa.ubuntu.com/reports/sponsoring/
<dobey> cjwatson: ah, ok
<bambee> slangasek: it does not work with linux-image-2.6.38
<bambee> I don't think it's kernel related... (it worked fine on natty with linux-image-2.6.38)
<bambee> cjwatson: http://paste.ubuntu.com/688477/
<bambee> (plymouth.debug)
<cjwatson> dinner trumps plymouth debugging :-)
<bambee> btw, "[ply-utils.c]                               ply_open_module:Could not load module "/lib/plymouth/renderers/x11.so": /lib/plymouth/renderers/x11.so: cannot open shared object file: No such file or directory"
<Laney> bts --mbox show
<Laney> arg, sorry
<cjwatson> bambee: the X11 plugin isn't intended to be used there
<cjwatson> bambee: so that part is a red herring
<bambee> oh ok
<cjwatson> bambee: hmm.  there really isn't anything obvious (to me) there.  it looks as though plymouth's internal logic is doing all the right things, but it's just talking to nouveau wrongly :-(
<bambee> so , is it a problem with nouveau ? don't compute it worked just fine on natty with linux-image-2.6.38... and the kernel is still the same...
<cjwatson> I wouldn't expect so; presumably it's dealing with X just fine
<cjwatson> plymouth has a variety of horrible code to talk to each of the different framebuffer implementations in different ways, since at the time we first put that all together they all had different requirements
<cjwatson> it seems quite plausible that nouveau's requirements have changed and our plymouth package hasn't kept up
<bambee> mhhh
<dobey> can i bug someone to PLEASE sponsor a critical fix asap? https://code.launchpad.net/~dobey/ubuntu/oneiric/couchdb/fix-780972/+merge/75238
<cyphermox> dobey: looking at it now
<dobey> cyphermox: thanks
<slangasek> hallyn: do you know what hvm is?  (Bug #849224)
<ubottu> Launchpad bug 849224 in qemu-linaro (Ubuntu) "hvm domU doesn't start (qemu-keymaps can't load)" [Undecided,Incomplete] https://launchpad.net/bugs/849224
<hallyn> hardware assisted virtualization?
<hallyn> as in kvm
<Laney> doko: do you want to give back fgarch or are you happy the vr removal will have fixed bug #749138?
<hallyn> (or xen)
<ubottu> Launchpad bug 749138 in fgarch (Ubuntu Oneiric) "fgarch version 2110.80-1 failed to build on i386" [High,Confirmed] https://launchpad.net/bugs/749138
<Laney> (can't reproduce it)
<hallyn> slangasek: interesting.  we might need to talk to lool about that.  /usr/share/qemu is usually provided by qemu-common.
<hallyn> presumably qemu-linaro shoudl be patched to look under/usr/share/qemu-linaro?
<slangasek> hallyn: qemu-linaro *already* looks under qemu-linaro.  I don't know what the bug submitter is talking about, because "hvm domU" doesn't tell me what architecture this is...
<hallyn> no, it doesn't :)
<hallyn> slangasek: I also have no idea what v0.1.1-2ubuntu2 refers to
<doko> Laney, given back
<doko> could you close the report?
<Laney> yep
<slangasek> hallyn: ok, I'll not worry over it any more then, we'll wait for the response from the submitter - thanks :)
<Laney> thanks
<hallyn> np :)
<DktrKranz> Laney: python-httplib2 uploaded in sid
<Laney> \o/
<Laney> cheers!
<DktrKranz> :)
<lool> slangasek: hvm: I think this is by opposition with pv; in the latter case, paravirtual, the kernel is aware that it's virtualized, while it's not the case in the hvm case (e.g. to run windows); I think this is xen terminology but might apply to kvm
<cyphermox> dobey: done
<dobey> cyphermox: thanks much!
<slangasek> lool: ok - so in any case we have no idea what the submitter is doing
<bdmurray> pitti: is there any chance bugpatterns.xml was out of date on people.canonical.com for a while?
<bdrung> the ppa builder seems to have a problem on maverick: https://launchpadlibrarian.net/79806678/buildlog.txt.gz
<bdmurray> slangasek: is there a multiarch tag in use?
<slangasek> bdmurray: yes
<bdmurray> and that tag is multiarch?
<bdmurray> slangasek: and that tag is multiarch?
<slangasek> bdmurray: yes - sorry, I thought that was the first question :)
 * micahg added the multiarch tag to the wiki tags page
<bdmurray> micahg: maybe it should be official
<micahg> bdmurray: I thought I made it official already
<micahg> indeed, it autocompletes
<bdmurray> well neat
<lool> slangasek: Sorry hadn't looked at the actual bug; seems like someone trying to run a piece of xen by hand which expects the keymaps in usr/share/qemu; let's wait for his reply indeed!
<SpamapS> hmm, how does one make strings in upstart jobs translatable?
<JanC> SpamapS: what do you mean by "strings in upstart jobs"?
<SpamapS> JanC: I want to display a message to users when the system is waiting on something for a long time.
<JanC> that doesn't sound like an upstart issue, but something service-specific?
<SpamapS> JanC: no, its one of upstart's jobs
<SpamapS> but even if it were, say, apache's.. how would one make it translatable?
<SpamapS> the gettext cli program seems a likely candidate
<JanC> in general, daemon/service-specific messages can only be translated "inside" the daemon, but for anything outside that gettext is an obvious tool of course
<broder> SpamapS: wouldn't that be more plymouth's job?
<SpamapS> $PLYMOUTH message --text="Waiting for network configuration..."
<SpamapS> broder: not that I can see
<broder> SpamapS: how does, uh, mountall handle this?
<SpamapS> the burden lies on the origin of the literal string
<SpamapS> broder: _()
 * SpamapS assumes
<broder> i feel like i've seen a way to access gettext from sh...
<slangasek> SpamapS: by "make them translatable", do you mean "get them somewhere that they will be translated", or "get the right translated string into the upstart job"?
<SpamapS> slangasek: both. :)
<slangasek> the gettext commandline program should do for the latter
<slangasek> plymouth message --text=$(gettext -d upstart-jobs "Waiting for network configuration...")
<slangasek> or gettext -d upstart, if you can work out how to get it into upstart/po/upstart.pot in a semi-automatic fashion
<SpamapS> There's a lot of pieces of the boot that are english only.. so I'll leave it in the "lets solve this soon" bin, and not do it now..
<SpamapS> slangasek: the descriptions of all the upstart jobs would also be good to translate.. since they're used by the plymouth bridge
<slangasek> SpamapS: hmm, ick :)
<SpamapS> slangasek: seems like that would be much easier to do in a "semi automatic fashion" with dh_installinit
<slangasek> not particularly
<slangasek> dh_installinit runs when building binary packages
<SpamapS> slangasek: but then we have to have upstart know to feed it through gettext at the right moment. :-P
<SpamapS> slangasek: it could scan the init script it is installing, and produce the .pot, no?
<slangasek> the problem you need to solve is extracting the strings so that they can be fed to something that interfaces with launchpad translations, which looks at *source* packages
<slangasek> if LP Translations pulls .pot from binary packages at build time, I'm not aware of it
<SpamapS> slangasek: err, not installing, but rather, the init script it is setting up to install
<SpamapS> I see your point..
<SpamapS> wrong stage of package building
<slangasek> ScottK: the honeyd configure.in is making me angry
<ScottK> ;-)
<SpamapS> seriously, I think ESR may be right.. autoconf/automake need replacing. :-P
<SpamapS> If for no other reason than to knock all the bad habits out of peoples heads
<slangasek> I challenge you to show me a build system that doesn't encourage *worse* habits :)
<slangasek> anyway, honeyd fix in hand now
<ScottK> Cool.
<slangasek> well, except for the subsequent unrelated build failure
<TheMuso> /c/c
<charlie-tca> TheMuso: bug 836798 seems to be still happening
<ubottu> Launchpad bug 836798 in at-spi2-core (Ubuntu Oneiric) "natty to oneiric upgrade failed: Could not perform immediate configuration on 'python-pyatspi2'" [Critical,Triaged] https://launchpad.net/bugs/836798
<TheMuso> charlie-tca: Yes I know, I am subscribed to it, I will get to it today.
<charlie-tca> Okay
<charlie-tca> Just want to make sure I didn't mess you up with it
<slangasek> ScottK: hah; the other build failures are caused by API changes in libevent, which I see is precisely what puts honeyd on the NBS list
<ScottK> Excellent.
<ScottK> slangasek: If you want a break for something fun, have a glance at Debian 637509 and then remove it from Ubuntu.
<ubottu> Debian bug 637509 in ftp.debian.org "RM: dtc -- RoQA; consistently buggy and non-policy compliant" [Normal,Open] http://bugs.debian.org/637509
<slangasek> the latter is Debian bug #632765
<ubottu> Debian bug 632765 in honeyd "FTBFS with libevent 2.0 in experimental" [Normal,Open] http://bugs.debian.org/632765
<slangasek> heh, dtc
<slangasek> yeah, we can do that
<slangasek> oh good, honeyd is by the same upstream author as libevent
<slangasek> and is not ported to the new API
<ScottK> Lovely.
<ScottK> Only 13 RC bugs against dtc in Debian.
<SpamapS> slangasek: /win 21
<SpamapS> doh
 * slangasek runs to the window to look!
<SpamapS> shh don't tell anybody
<SpamapS> everyone will want one
<ScottK> Was it http://www.backcountry.com/sog-knives-double-headed-axe-w-nylon-sheath ?
<slangasek> ScottK: bug #845481 is a treat
<ubottu> Launchpad bug 845481 in dtc (Ubuntu) "URGENT: Please sync DTC 0.34.1 from SID" [Undecided,New] https://launchpad.net/bugs/845481
<ScottK> slangasek: I think you'll like https://bugs.launchpad.net/ubuntu/+source/dtc/+bug/845481/comments/1
<slangasek> heh
<Seq> Hello. My boot times in oneiric have skyrocketed to about 2.5 minutes. Can anybody help me see why? Here is the bootchart: http://i.imgur.com/XS36E.png
<SpamapS> Seq: bug 847782
<ubottu> Launchpad bug 847782 in upstart (Ubuntu Oneiric) "installer writes a permanent ethernet entry in interfaces file" [High,In progress] https://launchpad.net/bugs/847782
<SpamapS> Seq: I am about to propose a fix, that hopefully slangasek will take a look at for me. ;)
<SpamapS> Seq: the short description is .. if you have interfaces in /etc/network/interfaces that aren't actually able to be configured, you should likely remove the line 'auto ethX' from that file so that the system won't wait for them or try to bring them up at boot.
<SpamapS> slangasek: https://code.launchpad.net/~clint-fewbar/ubuntu/oneiric/upstart/add-plymouth-messages/+merge/75278 .. would you mind taking a peek?
<Seq> Thanks. I've removed the 'auto eth0' line, although there was no actual configuration indicating it was dhcp.
<SpamapS> Seq: so it had no configuration at all?
<Seq> only an 'auto eth0' line, it did not have anything such as 'iface eth0 inet dhcp'
<SpamapS> Seq: do you know why it might have been there?
<SpamapS> Seq: do you have a physical eth0 ?
<Seq> did the timeout value in /etc/failsafe.conf change recently? I mostly reboot when on wifi only, and I've been running oneiric for a few weeks now, rebooting every few days (mostly for kernel updates)
<Seq> SpamapS: yes.
<SpamapS> Seq: the timeout did raise from 30 -> 120 seconds about a week ago
<Seq> That could be it. I probably haven't rebooted in a week
<SpamapS> Seq: the proposed fix is just to display to the user that its waiting for network configuration..
<ScottK> That's not much of a fix.
<ScottK> (sorry)
<SpamapS> Seq: but I suppose we should also make sure that the interfaces we're waiting for actually have configurations!
<SpamapS> ScottK: your snark cuts me deep. ;)
<Seq> That would be a good start. I ditched the 'auto' line so hopefully it gets skipped over. But when I disabled 'quiet' and 'splash', I didn't get any indication either, just that cupsd had started.
<SpamapS> Seq: right, the MP I just linked to for slangasek has the messages bits added
<SpamapS> its not in oneiric yet
<ScottK> It's not really snark.  I've got a system that boots wicked fast and explaining to me why it's no longer fast once I upgrade it isn't going to make me into a happy user.
<SpamapS> ScottK: can't make everybody happy. :)
<SpamapS> Most users should *not* have these lines
<SpamapS> But I think its worthwhile to also make it not wait on any interfaces that will clearly *never* come up.
<ScottK> OTOH, compared to a UEC user upgrading to oneiric, only booting a bit slow is a detail.
<ScottK> SpamapS: Agreed.
<Seq> I've actually got an issue I'm planning on narrowing down tonight that causes my network to not work. Maybe it is related to bringing up an unconfigured interface..
<SpamapS> Seq: I would expect that ifup would still bring it "up", just not give it an IP
<SpamapS> Seq: which is actually what I'm testing right now
<Seq> If I'm on wifi and connect my dock (which has ethernet plugged in), each device is configured and working, but my routes get a little messed up. I need to disable both in NM, then pick either one to start again
<SpamapS> Seq: yeah maybe the auto line was borking your configs
<slangasek> ScottK: bug #849544
<ubottu> Launchpad bug 849544 in dtc (Ubuntu) "remove dtc from oneiric and blacklist: multiple security and policy bugs" [High,Fix released] https://launchpad.net/bugs/849544
<ScottK> slangasek: Thanks.
<Seq> SpamapS: Unfortunately I'm on that machine right now. I'm about to dock, so I may disappear for a second
<SpamapS> so, as I suspected, if you have an 'auto ethX' line with no config, it comes up instantly
<SpamapS> if the interface *exists*
<SpamapS> one of the whole points of this is we're waiting for interfaces that may take 2 minutes to be detected..
<SpamapS> Seq__: wb ;) so I tested auto eth1 with and without an eth1 attached to the system.. and without it.. you get the delay, but with it, you don't. This is desired behavior, as one thing we're waitign for is hardware detection that takes a long time.
<seq> So you said I shouldn't get the delay if it has 'auth eth0' while disconnected?
<seq> btw, I just tested again. If I have both network interfaces active, I lose speedy connectivity. Bringing up a web page takes minutes. If I have just one interface connected (either one) web pages load instantly
<seq> this is not necessarily related to the boot issue
<SpamapS> seq: are they both on the same network?
<seq> Yes
<seq> SpamapS: `route -n` > http://pastebin.com/3J11yM9u
<SpamapS> seq: that is a little weird.. not sure why you'd see the slowdown.. but can't you just turn wlan off when you plugin to ethernet?
<seq> If I recall, on previous releases the wifi route had a metric of 1, whereas the wired one was 0. They are both 0 here
<SpamapS> seq: interesting indeed
<seq> SpamapS: I could, but I'd prefer it just work magically like it used to.
<SpamapS> seq: yeah it should be magical like that if they're essentially on the same network
<seq> I'll try manually removing that route over wifi and adding it back with a metric of 1
<seq> SpamapS: Also, disconnecting wifi would sever existing connections, which I don't necessarily want to happen
<SpamapS> seq: as for your boot slowdown .. the issue isn't if its "connected" or "disconnected" .. but whether the hardware is present at all... if its not present, we wait.. in case it shows up (not entirely unlikely w/ servers ;)
<seq> SpamapS: eth0 is always present, it just usually isn't connected
<seq> I still had to wait 120 seconds
<SpamapS> seq: if it was present, with no configuration, the system should have booted. I just tested that and we don't wait, because ifupdown brings it "up"
<SpamapS> I wonder if there are situations where it doesn't show up until later. Hm.
<seq> It didn't do that here. Is there something I can poke to get additional output?
<seq> SpamapS: Never been a problem with it showing up before. It's just a standard e1000 on a standard intel chipset in a thinkpad
<SpamapS> seq: if you want to pull the failsafe.conf from that branch and put it in /etc/init/failsafe.conf, that would at least tell you its waiting on network configuration..
<seq> According to dmesg, it gets detected pretty quickly: [    2.213280] e1000e 0000:00:19.0: eth0: (PCI Express:2.5GT/s:Width x1) 5c:ff:35:00:6b:05
<SpamapS> http://bazaar.launchpad.net/~clint-fewbar/ubuntu/oneiric/upstart/add-plymouth-messages/view/head:/debian/conf/failsafe.conf
<SpamapS> seq: it would actually be really interesting to see ls -l /run/network
<cjwatson> why is there an auto line with no iface line anyway?  d-i won't do that
<seq> Is there something better than pastebin to post this to?
<SpamapS> cjwatson: I'm pretty sure we're going to dig up all the hacks and voodoo people have applied to their interfaces file with this change. ;)
<cjwatson> the only places it writes auto, it writes iface straight afterward
<SpamapS> seq: I like paste.ubuntu.com (easily accessed from cli with pastebinit)
<seq> This is a fresh install on oneiric, and I do not touched the interfaces file on machines that I use NM on
<cjwatson> seq: which installer?
<seq> alternate, I use dmcrypt+lvm
<cjwatson> I've audited the code and it never writes auto without writesing iface next
<cjwatson> *writing
<seq> Is there a log file I can check to see the install date?
<cjwatson> so I'd like to see the exact original contents of /etc/network/interfaces plus /var/log/installer/syslog
<SpamapS> cjwatson: perhaps more importantly, if there's only an 'auto ethX' line and it is detected, /etc/network/network-interface.conf brings it up.. so the system won't wait for that.
<cjwatson> give me the latter and it has the install date in it plus lots more
<slangasek> SpamapS: sent some comments on the merge request
#ubuntu-devel 2011-09-14
<SpamapS> slangasek: thanks! :) I had a much simpler one that basically just does "Waiting for network configuration ..." .. I suppose thats the right thing to do for a first pass. :)
<slangasek> SpamapS: "if there's only an 'auto ethX' line" - if that's the only line, with no iface, /etc/init/network-interface.conf certainly won't bring it up
<seq> cjwatson: Problem: About 40 minutes ago I removed the 'auto eth0' line
<cjwatson> then put it back from memory and pastebin that :-)
<SpamapS> slangasek: you sure?
<slangasek> SpamapS: er, absolutely
 * SpamapS just had it boot like lightning in that configuration
<slangasek> SpamapS: if the only thing in /etc/network/interfaces is the 'auto' line, there's nothing that tells ifup to do anything with the interface, only that it's *allowed* to be brought up automatically
<SpamapS> ok, this is weird
<slangasek> so it won't be brought up by ifupdown, ever
<SpamapS> it actually dhcliented it
<slangasek> not NM?
<SpamapS> http://paste.ubuntu.com/688722/
<SpamapS> no NM installed
<slangasek> -sf /usr/lib/NetworkManager/nm-dhcp-client.action
<slangasek> really? ;)
<SpamapS> oh wait
<SpamapS> HAHAH I did install n-m on this to test something
<SpamapS> argh
<seq> cjwatson: /etc/network/interfaces: http://paste.ubuntu.com/688725/
<seq> cjwatson: /var/log/installer/syslog: http://paste.ubuntu.com/688724/
<seq> cjwatson: I actually found the blank media, it was an amd64 alternate daily from 20110827
<SpamapS> ok so yeah, if n-m is installed, and there's only an auto line, the system ends up booting because n-m starts and brings it up
<SpamapS> (and its plugged in, of course)
<seq> SpamapS: /run/network http://paste.ubuntu.com/688728/
<seq> SpamapS: note that it isn't my boot state anymore
<SpamapS> seq: is that after a 2 minute delay?
<seq> I've brought stuff up since then
<SpamapS> seq: yeah thats not as helpful, but I think I get whats going on now anyway. Thanks.
<seq> no. I'd have to reboot. Unfortunately I only have the one machine currently, so I can't run my stable natty at the same time as my testing oneiric :/
<slangasek> SpamapS: right; so this is a bug in /etc/network/if-up.d/upstart:get_auto_interfaces(), treating things as auto interfaces that aren't really interfaces at all from ifupdown's perspective
<slangasek> probably needs to use ifquery + the check for auto
<cjwatson> seq: ok, so there was an iface line, but /usr/lib/NetworkManager/ifblacklist_migrate.sh removed it
<SpamapS> slangasek: ifquery has some kind of braindead notion of aliases that made it unsuitable IIRC
<SpamapS> slangasek: I'll ask smoser about it tomorrow.. I'm pretty much burnt out on debugging it for today.
<cjwatson> so therefore the upstart job needs to consider auto-but-no-iface as "ignore, it's NM's problem"
<cjwatson> since that's what the NM blacklisting script does
<seq> I'm free to test if I'm waiting on network with the original /etc/network/interfaces file with SpamapS' failsafe.conf from his proposed branch above. Any other things I should be aware of or consider?
<SpamapS> I have to agree though, that we should filter it out if it has no config in /e/n/i
<seq> or think you've got a handle on it?
 * cjwatson shoves back in the "not an installer problem" bin :-)
<slangasek> SpamapS: right, I'll be interested in the details as I was pretty sure I accounted for aliases when coding up ifquery
<SpamapS> slangasek: I believe the problem was that one couldn't easily match them up to the auto lines.. but my memory is fuzzy.
<SpamapS> cjwatson: thanks for looking at this so carefully. :)
<SpamapS> whole brain is fuzzy actually.. I'll get back on this in the morning.
<smoser> slangasek, you are sure that it is ?
<smoser> that it is a bug in that code identifying things as auto that are not ?
<slangasek> smoser: there is definitely a bug in the code, yes
<SpamapS> smoser: the code just looks for auto lines, it doesn't verify that they have configuration
<slangasek> it waits for 'auto' interfaces that are never defined
<smoser> so what should it be looking for ?
<slangasek> it needs to check both for the auto line and ask ifupdown to confirm that there's actually an interface definition
<smoser> ask ifupdown
<slangasek> yes, i.e. ifquery
<slangasek> to avoid writing your own interfaces(5) parser
<cjwatson> and since ifquery is an Ubuntu extension to begin with, it makes no sense to work around it rather than fixing it if it's broken
<smoser> agreed.
<smoser> the parser i have should support aliases:q
<seq> One more unrelated question for you: What does Meta+p do? In natty+unity I had this bound to move a window to top/right, but in oneiric+unity it just flashes the screen and causes X to hang for about five seconds.
<SpamapS> smoser: you mean mappings right?
<SpamapS> smoser: I'm trying hard to remember why it wasn't suitable
<smoser> when we were using ifstate it had sutff that worked to decide if something was up
<smoser> it read ifstate
<smoser> but now we dont read ifstate
<SpamapS> AH
<SpamapS> smoser: so we can just change get_auto_interfaces to use ifquery ..
<smoser> slangasek, do you have a suggestion on how to call ifquery ? ifquery --no-mappings ?
<smoser> i dont know. maybe. that would be nice
<SpamapS> smoser: as long as thats the interface name that comes in as $IFACE
<slangasek> smoser: not sure yet, but I guess 'ifquery --allow auto --list --no-mappings' is how we would /want/ it to work
<slangasek> (the --no-mappings doesn't seem to work so well in practice at the moment)
<smoser> it seems you dont need --allow auto
<smoser> :)
<smoser> i just tested that if i commented out 'auto eth0' and 'ifquery --list --no-mappings' then did not show it.
<SpamapS> smoser: I think thats just the default
<SpamapS> what I'm confused by is how to test the mappings
<smoser> and i'm not sure that --no-mappings is functioning right.
<smoser> well. anyway.
<smoser> we can come up with a solution here.
<YokoZar> slangasek: What's the status of OpenSSL 32 bit these days?
<SpamapS> smoser: yeah, --no-mappings is busted
<YokoZar> slangasek: The current build log for Wine:  https://launchpadlibrarian.net/79822996/buildlog_ubuntu-oneiric-amd64.wine1.3_1.3.28-0ubuntu1_BUILDING.txt.gz  (ctrl+F for not found)
<SpamapS> anyway, brain fried, and time for karate
<smoser> at very least 'ifquery --list 2>/dev/null' seems to ignore 'auto' interfaces that do not have configured section
<SpamapS> smoser: it shows mapped interfaces though, whereas the real interface seems to be passed to the scripts
<smoser> SpamapS, do you have an example interfaces ?
<SpamapS> smoser: auto eth0-foo\niface eth0-foo inet dhcp\n
<SpamapS> smoser: sudo ifup eth0=eth0-foo ...
<SpamapS> smoser: eth0 is passed as $IFACE
<SpamapS> smoser: but ifquery -a --list shows eth0-foo only
<smoser> is that a valid config ?
<SpamapS> smoser: yep, brought up the physical eth0 as the logical eth0-foo
<SpamapS> smoser: tho.. we can use $LOGICAL to check
<smoser> SpamapS, you should go to karate
<SpamapS> Yeah, late == pushups :)
<smoser> but that is not a config we're worried about i think
<SpamapS> smoser: I think $LOGICAL is the way to go
 * SpamapS is gone
<smoser> because in that config, eth0-foo is not an auto interface. and it wont be brought up by ifup on first boot.
<smoser> yeah
<smoser> i think its fine'
<slangasek> YokoZar: libssl0.9.8 is still included in ia32-libs; though perhaps the fact that I was hand-hacking it into the source package caused the dev symlink to not be where it should and we need to regenerate ia32-libs now that openssl0.9.8 source is in the archive?
<YokoZar> slangasek: I'll experiment with an ia32-libs freshening, see if that clears it
<slangasek> SpamapS: 'sudo ifup eth0=eth0-foo' - I don't think that's how it would be invoked in practice though
<YokoZar> slangasek: btw I'm gonna try building true multiarch wine and see if it's less broken ;)
<YokoZar> (it will likely build at this point, however it will complain about 15 different things being disabled since they're not multiarched yet)
<Seq> Is there a way I can force myself to end up at a basic shell in my initrd before my disks mount?
<pitti> Good morning
<pitti> bdmurray: hm, I don't see anything wrong with the cronjob
<stgraber> Good morning pitti
<stgraber> still wondering how you manage to wake up and start working before 6am ;)
<pitti> stgraber: I actually had thought it was 6 am, but seems my wife got up earlier today
<pitti> *yawn*
<stgraber> pitti: hehe :)
 * TheMuso is a 6am riser, although I don't jump on the computer for a good 2 hours after I get up. :)_
<dholbach> good morning
<doko> debfx, ScottK: please could you address this within the kubuntu umbrella: bug 770789
<ubottu> Launchpad bug 770789 in plasma-runner-amarok (Ubuntu Oneiric) "plasma-runner-amarok version 0.6-0ubuntu2 failed to build on amd64 with GCC-4.6/oneiric" [High,Confirmed] https://launchpad.net/bugs/770789
<doko> Daviey, please have a look at bug 756107
<ubottu> Launchpad bug 756107 in php-imap (Ubuntu Oneiric) "php-imap version 5.3.5-0ubuntu1 failed to build on i386" [High,Confirmed] https://launchpad.net/bugs/756107
<doko> debfx, ScottK: same for bug 832856
<ubottu> Launchpad bug 832856 in phonon-backend-xine (Ubuntu Oneiric) "phonon-backend-xine version 4:4.7.0really4.4.4-3ubuntu1 failed to build in oneiric" [High,Confirmed] https://launchpad.net/bugs/832856
<doko> pitti: please have a look at bug 832778 (pg 9.1 issue)
<ubottu> Launchpad bug 832778 in pgsql-asn1oid (Ubuntu Oneiric) "pgsql-asn1oid version 0.0.20100818-1 failed to build in oneiric" [High,Confirmed] https://launchpad.net/bugs/832778
<pitti> doko: thanks, will do
<doko> jelmer, please could you have a look at bug 832901?
<ubottu> Launchpad bug 832901 in pam-krb5-migrate (Ubuntu Oneiric) "pam-krb5-migrate version 0.0.9-1build1 failed to build in oneiric" [High,Confirmed] https://launchpad.net/bugs/832901
<jelmer_> doko, ok
<alexbligh1> Is it too late to request an update of Oneiric for a minor point release from upstream? (specifically bird-1.3.2 to bird-1.3.3 and ditto bird6). If not, how do I do it?
<dupondje> Ã¦Â­Â£Ã¥ÂÂ¨Ã¥Â¤ÂÃ§ÂÂÃ§ÂÂ¨Ã¤ÂºÂ gnome-menus Ã§ÂÂÃ¨Â§Â¦Ã¥ÂÂÃ¥ÂÂ¨...
<dupondje> suddenly there are things in Chinese ?! :)
<Daviey> I think i am doing it wrong.
<Laney> alexbligh1: if they are bug fix releases, then that's easy (request a sync). otherwise, it's a bit harder but can still be done if necessary (request a freeze exception)
<Laney> !sync
<ubottu> Helpful information for filing a sync request can be found at https://wiki.ubuntu.com/SyncRequestProcess
<Laney> !ffe
<ubottu> Feature Freeze Exception. See https://wiki.ubuntu.com/FreezeExceptionProcess for the freeze exception process.
<Daviey> cjwatson: I've created a udeb for libxmlrpc, but it also seems i need one for libcurl, and now libidn.. am i doing it wrong?
<cjwatson> if you're using libraries, you need them to be in udebs
<cjwatson> libcurl sounds an extremely unfun thing to drag in what with the openssl/gnutls duality
<Daviey> cjwatson: Well libcurl3.so seemed to be enough to satisfy the concern,
<Daviey> I'm trying to work out why the heck it needs libidn
<cjwatson> I do have to question whether it's still appropriate to be adding udebs at this stage ...
<cjwatson> especially if you're running into trouble
<Daviey> cjwatson: Well yes, that is a valid concern.
<alexbligh1> Laney, thanks. It's mostly bugfixes, including failing to use /etc/default/bird (which is my problem)
<ScottK> doko: 832856 is now a removal bug.
<ScottK> doko: 770789 too.
<sastudio> Hello,is there a way to get the last path that Nautilus accessed?
<sastudio> from a bash script or C
<sastudio> Anyone?
<ScottK> sastudio: That sounds like a question for #ubuntu.  This channel is for development of Ubuntu, not support.
<ScottK> cjwatson: Thanks for taking a crack at the boost related failures.  I'll see if there are any in the other archs stack I can figure out.
<cjwatson> ScottK: I think I'm out of steam for now, but have finished frogatto
<ScottK> Cool.
<sastudio> Forgive my mistake,since I needed it for developing a little project for Ubuntu I thought this was the right one.So no external ubuntu projects in here?
<didrocks> sastudio: (see /topic): #ubuntu-app-devel for application development on Ubuntu
<sastudio> @didrocks Thank you,Sir!
<udevbot> Error: "didrocks" is not a valid command.
<desrt> sastudio: may also want to try #nautilus on irc.gnome.org, but i suspect the answer to your question is 'no'
<micahg> slangasek: is there any was to use a bigger hammer for people on oneiric to enable multiarch?  we keep getting bug reports about flash not being installable
<slangasek> micahg: infinity was going to add a config file to dpkg
<slangasek> which would help us sweep up the people who run alphas but don't read release notes or u-d-a :)
<micahg> slangasek: that sounds great, thanks
<pitti> slangasek: hm, flicker-free boot doesn't work for me with gdm either
<pitti> slangasek: but anyway, great that you got this fixed!
<slangasek> pitti: define "not work"?
<pitti> (will take a look at the FFE soon, just saw it coming in)
<pitti> slangasek: it looks exactly like lightdm -- plymouth, then text, then X/gdm
<slangasek> hmm
<pitti> I thought it wasn't DM specific
<slangasek> I've not seen that at all
<slangasek> could be that something kills plymouth early for you for some reason
<slangasek> pitti: anyway, the flicker-free needs wider hardware testing before I'm comfortable landing it post-beta... any chance you have !intel video? :)
<pitti> slangasek: all intel here ..
<slangasek> ok
<slangasek> maybe you at least have a non-cryptsetup system, to test that case?
<pitti> I guess a more widespread call for testing might trigger more feedback?
<pitti> slangasek: yes, I have switched to ecryptfs a year or two ago
<slangasek> yay
<pitti> slangasek: but I know some people in my team with ati/nouveau :)
<pitti> oh, http://bazaar.launchpad.net/~vorlon/ubuntu/oneiric/plymouth/lightdm-integration/revision/1398 is all that's needed?
<pitti> i. e. that can easily be applied manually on test systems, no need to enable a PPA etc.
<slangasek> would be great to have their testing :)  if we need to put out a wider call, we can do that too
<slangasek> yes, it's a small change
<slangasek> just make plymouth-stop not stop
<pitti> slangasek: heh, without cryptsetup I only see plymouth for some 0.3 seconds :)
<slangasek> yep, that's pretty typical
<pitti> and a blinking text cursor for like 10 s before
<pitti> for some reason, looking for the root fs takes ages these days (http://people.canonical.com/~pitti/bootcharts/donald-oneiric-20110902.png)
<slangasek> the problem is it's a tradeoff between bringing up the splash early, or booting faster
<slangasek> hmm
<pitti> I think that's the main reason why I install cryptsetup these days :)
<pitti> (well, also because I still have an encrypted USB stick)
<slangasek> the wait-for-root is within resume.  do you have a broken resume setting somewhere on the disk?
<pitti> hm, this is a fresh beta-1 install
<pitti> but I kept the original partitioning
<pitti> so maybe the swap partition still has some cruft
<pitti> $ cat /etc/initramfs-tools/conf.d/resume
<pitti> RESUME=UUID=46fc4d23-f197-4536-b15c-99ac162fa2df
<directhex> lamont, would it be possible to arrange a non-package build on one of the i386 builders, since the only machines in the universe which reliably reproduce the problem we're showing are vernadsky and one other of the ubuntu buildds? i don't want to break the published package in oneiric with a speculative patch
<pitti> that one?
<pitti> slangasek: oh, http://paste.ubuntu.com/689186/ - might be that cryptsetup did that
<lamont> directhex: ew
<Laney> heh
<directhex> lamont, ew indeed
<lamont> directhex: give me a sourcepackage in a ppa somewhere
<directhex> lamont, you're a star :)
<slangasek> pitti: I don't think cryptsetup touches /etc/initramfs-tools/conf.d/resume
<pitti> slangasek: then it's probably ubiquity when you enable/have ecryptfs
<slangasek> could be
<micahg> lamont: I got a chroot error on an armel panda buildd, do you need anything from it or should I retry?
<lamont> micahg: which machine?
<micahg> lamont: nihal
<lamont> build record?
<micahg> lamont: https://launchpad.net/ubuntu/+source/gimp/2.6.11-2ubuntu3/+build/2784357
<lamont> micahg: I tossed it back into the pool just to see what it has to say
<lamont> the exact failure bothers me.
<lamont> data integrity issues are always an interesting corner case
<kirkland> pitti: slangasek: what's the ecryptfs question?
<micahg> lamont: ok, thanks
<lamont> and cleaned out filecache-default on the box, I'll go give back all the chrootwaits in a moment
<slangasek> kirkland: the question is, what created the bogus /etc/initramfs-tools/conf.d/resume on pitti's system that slows down the initramfs waiting for a device that apparently isn't there
<cjwatson> some bit of the installer creates that
<cjwatson> if the UUID then changes, probably nothing updates it
<cjwatson> base-installer and ubiquity both do it
<cjwatson> AFAIK the installer has to do that or else hibernation can't work
<cjwatson> it has nothing to do with ecryptfs anyway
<pitti> kirkland, slangasek: confirmed, when I clean up the conf.d/resume bit, it's 5 secs faster
<pitti> does hibernation even work on an encrypted swap?
<kirkland> pitti: slangasek: yeah, i concur with cjwatson;  I don't know of any part of ecryptfs that would have touched that
<pitti> kirkland: not ecryptfs itself; I mean, ubiquity probably sets up an encrypted swap if you choose to encrypt your home dir
<kirkland> pitti: yes, it used to, anyway, using ecryptfs-setup-swap
<directhex> lamont,  https://launchpad.net/~directhex/+archive/monoxide/+sourcepub/1940712/+listing-archive-extra
<directhex> lamont, i assumed you'd be happier if i gave it time to test-build successfully before you waste your time with it
<lamont> heh. ta
<directhex> lamont, previously it was reliably failing to build when building the docs (look for cs-errors in the build log) on vernadsky and... i think rothera. definitely vernadsky. upstream's patch should cause it to build okay but print some debug spew when it would previously fail (the debug spew would be helpful to pass to upstream)
 * lamont stuffs vernadsky on manual
<lamont> directhex: and this is mono, yes?
<directhex> lamont, yes
<lamont> 2.10.5-1+wtf1 to be specific
<directhex> lamont, yes
 * lamont puts all of i386/archive on manual, waits for zirconium to finish failing the build he killed
<lamont> directhex: there, building
<lamont> on vernadsky, even
<directhex> lamont, brilliant
<lamont> directhex: can you see the build?
<lamont> https://launchpad.net/~lamont/+archive/non-virt/+build/2784832
<directhex> https://launchpad.net/~lamont/+archive/non-virt/+build/2784832
<directhex> hah, yes then ;)
<directhex> lamont, and this way there's even a proper log. you're a star
<lamont> anyway, I'm going to leave it in your lap then
<lamont> but I'm going to kill the armel build
<lamont> unless there's some reason to leave it running
<lamont> it might be nice to see how long a panda takes to build mono
<micahg> +1, I'd be interested in seeing how long mono takes on a panda
<lamont> micahg: I shall let it live then
<directhex> longer than it used to. building the (C) runtime 4 times takes a while. the c# compiler is pretty fast on arm
<micahg> directhex: well, we can see apples to apples, that build took 7 hours on the old armel machines
<directhex> okay
<lamont> micahg: bbg3 or beaglexm, I wonder
<doko> hmm, why doesn't libjack-dev depend on jack1d?
<doko> -dev has a .so symlink to a library in jack1d
<doko> I'll call adding libraries in LDFLAGS monkey linking ...
<cjwatson> ScottK: uploaded libnet-server-perl from pkg-perl - testing in an amavis context would be welcome since this is entirely different from the patch the amavis people suggested
<ScottK> cjwatson: Thanks.  I'll see if I can find someone to test.
<cjwatson> jelmer: are you aware of bug 831374?
<ubottu> Launchpad bug 831374 in cia-clients (Ubuntu Oneiric) "cia-clients version 20110719 failed to build in oneiric" [High,Confirmed] https://launchpad.net/bugs/831374
<Laney> directhex: we have point passingness
<directhex> Laney, good good - but i missed the failure point, so need to wait for completion to access the log
<Laney> it didn't say anything
<Laney> maybe earlier
<Laney> did you export MONO_DEBUG?
<directhex> ..........
<directhex> sigh. this is why i shouldn't do hacking whilst on the clock
<Laney> oops
<cjwatson> bah, libnet-server-perl failed to build
<tkamppeter> when is beta2 freeze?
<micahg> tkamppeter: tomorrow
<directhex> Laney, can you take care while i go sit in a corner & sob?
<tkamppeter> is missing on https://wiki.ubuntu.com/OneiricReleaseSchedule
<micahg> skaet: ^^
<skaet> micahg, tkamppeter - thanks.  Fixed.
<Laney> directhex: don't think i will have time today
<directhex> blarg
<Laney> should just be one line though
<directhex> at least we know the build passes :/
<Laney> export MONO_DEBUG=1
<Laney> put it in for the next normal upload if you don't want to bug lamont again
<tkamppeter> skaet, thanks, another bug: beta1 is alink, beta2 not.
<directhex> Laney, i guess put it in the .6 upload?
<charlie-tca> tkamppeter: they don't become links until after they release
<skaet> tkamppeter, actually that link tends to get added after the release is out.  Its a pointer to the release notes.  :)
<Laney> directhex: yeah, if meebey does it soon. we can ask for it to be done on vernadsky again.
<Laney> b2 freeze is tomorrow though ...
<lamont> directhex: does that mean it failed in a way you didn't want?
<Laney> forgot to export MONO_DEBUG to get the debugging info upstream wanted
<directhex> lamont, it means it succeeded whereas previously it would have failed... but i forgot to enable the debug spew, because i'm an idiot
<lamont> lol
<lamont> if you want me to toss it through again, I'm fine with that.
<ogra_> funny, must be the first time i see someone asking for an FTBFS on purpose :)
<slangasek> wendar: is there something yet to be done wrt DEX for https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-python-versions ?
<Laney> imagine a build failure that only happens on two boxes, and imagine that both of those boxes are ubuntu buildds
<Laney> yeah...
<SpamapS> slangasek: so I've been monkeying with mapping's..
<SpamapS> slangasek: seems like ifquery doesn't work with them as I'd expect it to..
<slangasek> SpamapS: confirmed; I got halfway down that rabbit hole in the code yesterday before I gave up
<slangasek> if only ifupdown was written in C, I'd probably have it done already
<SpamapS> slangasek: Ok, so in light of that, we can take two stances. 1) we can add 'iface' to our parser that we already have in shell for 'auto' ...
<SpamapS> slangasek: amen brother.. webm terrifies me
<slangasek> 1) no no
<SpamapS> slangasek: 2) we can just say that mappings will be waited upon for 2 minutes
<slangasek> no, as discussed yesterday we should fix ifquery to actually dtrt with mappings
<SpamapS> honestly, what is the server use case for mappings ?
<slangasek> but you don't need to block on it, certainly
<micahg> cjwatson: is this anything I need to worry about/file a bug for? http://paste.ubuntu.com/689338/
<slangasek> SpamapS: so if you want to go for 2) with ifquery, that's perfectly fine with me
<slangasek> and then the ifquery bug can be on my shoulders... or on smoser if he's keen to take it :)
<SpamapS> slangasek: did you open a bug yet, otherwise I'll open one.
<smoser> SpamapS, so what is wrong with ifquery ?
<smoser> because i think it is right in the example you gave yesterday.
<wendar> slangasek: it's been adopted as a DEX project, so the workitem is DONE
<slangasek> smoser: ifquery doesn't do anything at all with mappings
<smoser> i dont think it matters.
<SpamapS> smoser: it is, but that example wasn't useful. ;)
<wendar> slangasek: there's still work to be done on the bugs, but our goal was to contribute, not close them all down
<slangasek> wendar: cool, ticking the box :)
<SpamapS> http://paste.ubuntu.com/689342/
<slangasek> smoser: right, for the server case the mapping bug probably doesn't matter.... I'm going to try to get it fixed in ifquery all the same
<SpamapS> smoser: this interfaces file (/map just echos 'FOO') doesn't show eth0
<SpamapS> So actually.. we can use ifquery, but note that mappings will *not* be waited on
<wendar> hmm... somethings up with bugs.debian.org
 * SpamapS throws ETOOMUCHINDIRECTION
<smoser> SpamapS, right, and eth0 would be auto'd on that.
<smoser> SpamapS, so do you want me to fix the upstart script to use ifquery ?
<slangasek> I do :-)
<SpamapS> smoser: to be clear, eth0 with that interfaces file is brought up at boot time, but is not shown in ifquery -a --list .. so it would not be waited on.
<SpamapS> I'm *OK* with that
<SpamapS> because I don't see a huge use case in mappings
<SpamapS> its like a poor man's NetworkManager
<smoser> right.
<smoser> ifquery shoudl be fixed, and we should open a bug
<smoser> but yeah.
<SpamapS> ok, I'll open said bug
<SpamapS> Yay throw it on the pile.. oi
<slangasek> throw it on my pile
<slangasek> (i.e., assign)
<SpamapS> ack
<smoser> i'll fix ifup upstart job to use 'ifquery --list'
<smoser> slangasek, SpamapS is that the "right" arguments ?
<smoser> as ifquery sparse documentation, hard to decide what is right
<smoser> seems to me that is right.
<SpamapS> I think it defaults to --allow auto, but I would explicitly pass that
<cjwatson> micahg: dunno, where's grub-pc configured to install GRUB to?
<slangasek> SpamapS: yes, please explicitly pass that, because I'm planning on fixing that in ifquery :)
<micahg>  cjwatson: no idea, I haven't modified this AFAIK
<slangasek> smoser: ^^
<cjwatson> micahg: debconf-show grub-pc
<directhex> lamont, i added the env var to https://launchpad.net/~directhex/+archive/monoxide?field.series_filter=oneiric
<micahg> cjwatson: it has a /dev/disk/by-id output
<smoser> slangasek, ok.
<chrome_> !release
<ubottu> Ubuntu releases a new version every 6 months. Each version is supported for 18 months to 5 years. More info at https://wiki.ubuntu.com/Releases & http://wiki.ubuntu.com/TimeBasedReleases
<SpamapS> slangasek: bug 850166 opened for you
<ubottu> Launchpad bug 850166 in ifupdown (Ubuntu) "ifquery does not respect mappings" [Undecided,Confirmed] https://launchpad.net/bugs/850166
<cjwatson> micahg: yes.  what exactly does it say though?
<micahg> cjwatson: /dev/disk/by-id/ata-ST9500420AS_5VJBCYN8
<cjwatson> micahg: ok, so it's managed to work around the problem but only in a fragile way because your partitioning is bad
<cjwatson> micahg: there should be at least 63 sectors before the first partition (nowadays, 1MiB is usuall)
<cjwatson> *usual
<cjwatson> micahg: it may be hard for you to change this now, of course
<micahg> yeah, the drive came preinstalled
<micahg> cjwatson: so, you don't need a bug report then I take it?
<cjwatson> micahg: nope
<micahg> cjwatson: thanks :)
<lamont> directhex: building on vernadsky: wtf2
<lamont> afk for a few
<directhex> thanks :)
<smoser> SpamapS, i think that bug is moderately bogus
<smoser> as 'ifquery' is then going to have to run code (/map) that is only expected to be run at ifup time
<smoser> i guess its not so bad. but kind of wierd
<SpamapS> Its a little weird, and might scare some people, but the scripts are meant to map every time ifup is run. Honestly, I'd be happier with just *ditching* mappings and saying thats what connman or network-manager is for.
<SpamapS> But easier, right now, is for us to just say that they won't be waited on.
<apw> pitti, do you have any binary.debs for the plymouth flicker issue
<apw> pitti, am trying to do some testing here
<chrisccoulson> jono - do you have evolution-couchdb installed btw?
<jono> chrisccoulson, aha!
<jono> installing now
<chrisccoulson> heh :)
<chrisccoulson> jono - it stil doesn't work though. i get a new error from the eds couchdb backend now :(
<jono> I think I uninstalled it as rodrigo suggested to get rid of the constant errors
<jono> well test now
<jono> chrisccoulson, ahh
<jono> thanks chris
<jono> thanks chrisccoulson
<chrisccoulson> np :)
<jono> chrisccoulson, I am getting an error about not opening ubuntu one address bug because of the process
<chrisccoulson> jono - i get "Cannot open book: Could not create DesktopcouchSession object"
<chrisccoulson> do you get something similar?
<jono> chrisccoulson, nope
<chrisccoulson> that comes from the evolution-couchdb backend, and suggests that desktopcouch is still broken for mw
<chrisccoulson> **me
<jono> There was a problem opening the address book "Ubuntu One" - the message returned was: Cannot open book: Cannot process, book backend is opening
<jono> that is what TB tells me
<chrisccoulson> jono - perhaps try killing e-addressbook-factory, restarting thunderbird and trying again. maybe it needs a restart to load the new backend
<jono> chrisccoulson, killed it, now I don't see an error but no contacts in the address book
<chrisccoulson> jono - yeah, it's broken here too. but it's also broken in evolution :/
<jono> chrisccoulson, good luck, pal
<chrisccoulson> heh :)
<chrisccoulson> thanks
<jono> it would suck if we have another release with broken U1 contacts
<chrisccoulson> was it broken last cycle too?
<chrisccoulson> i have to admit, i've never used it before because couchdb was the first thing i uninstalled after doing a fresh install ;)
<jono> chrisccoulson, it kind of worked
<jono> for a large number of contacts it broke
<dobey> hmm
<dobey> jono: what version of couchdb-bin do you have installed?
<dobey> oh
<dobey> nevermind
<lamont> directhex: lol
<lamont> directhex: let me know when you're ready for wft3
<directhex> dare i ask?
<lamont> make[9]: Entering directory `/build/buildd/mono-2.10.5/mcs'
<lamont> Invalid option for the MONO_DEBUG env variable: true
<lamont> Available options: 'handle-sigint', 'keep-delegates', 'reverse-pinvoke-exceptions', 'collect-pagefault-stats', 'break-on-unverified', 'no-gdb-backtrace', 'dont-free-domains', 'suspend-on-sigsegv', 'suspend-on-unhandled', 'dyn-runtime-invoke', 'gdb', 'explicit-null-checks', 'init-stacks'
<directhex> ._.
<directhex> bloody computers
<jono> dobey, :-)
<dobey> hrmm, evolution is weird
<SpamapS> anybody know how to get skype working on oneiric?
<SpamapS> do I have to download the skype from their site now? :(
<micahg> SpamapS: add natty partner repo, install skype:i386?
<SpamapS> no
<SpamapS> I forgot to add the foreign arch
<SpamapS> had already tried that.. :p
<dobey> hrmm
<directhex> lamont, wtf3 just uploaded to my ppa.
<dobey> skype + unity do not mix
<micahg> SpamapS: wfm
<SpamapS> micahg: its not necessary tho
<micahg> SpamapS: what's not necessary?
<SpamapS> micahg: its in oneiric's partner repo.. just need the i386 foreign arch
<micahg> SpamapS: no, it's not in oneiric's partner yet
<dobey> SpamapS: not according to my apt-cache :)
<SpamapS> really? hrm.. this is the suck
<ScottK> partner is rarely populated much before release.
 * SpamapS should just abandon skype anyway.. :-P
<dobey> SpamapS: is there a version of skype that works right with unity?
<SpamapS> It worked fine w/ unity 2d .. haven't been able to run it in a couple of weeks.. and since then I switched back to regular unity
<dobey> SpamapS: is there some indicator that handles the old notification area icons that's not installed by default in oneiric?
<SpamapS> err, they were whitelisted in natty
<micahg> AFAIK, the notification whitelist was dropped for oneiric
<dobey> there is definitely no icon on my panel in oneiric
<dobey> i closed the skype window and got left with a process with no UI :)
<dobey> of course, also a bug in skype, but i can't go patch it :P
<SpamapS> awesome, so enabling i386 as a foreign arch has made my i386-only printer drivers cause huge issues
<SpamapS> now apt wants to remove libc-bin
<ScottK> dobey: It's not really a bug in Skype.  It's Ubuntu being different than every other Linux distro and expecting the entire FOSS world to follow.
<ScottK> KDE implemented the same notification area technology, but with a fallback.
<ScottK> It's a deliberate choice to have issues like this.
<dobey> ScottK: no. it's a bug in skype if it doesn't properly handle the notification area not being there. if we have something running that is embedding the icon and just not showing it on-screen though, i would be inclined to agree
<ScottK> Whatever.
<barry> cjwatson, slangasek: so, by disabling python-docutils in python-defaults, i'm making progress again.  too early to declare victory, but i'm past the latest roadblock
<micahg> barry: was there a reason why python-debian didn't get ported to dh_python2 for beta1?
<barry> micahg: no reason i can think of except that perhaps it didn't make it onto the list of cd packages?
<barry> micahg: does it still need porting?
<micahg> barry: yes, Debian did it in the latest upload, but there are quite a few changes, I didn't know if they were safe at this point since that library is used heavily
<barry> micahg: let me take a quick look
<micahg> barry: I have a task open for the xubuntu CD conversion bug, feel free to take it
<barry> micahg: bug #?
<micahg> bug 847514
<ubottu> Launchpad bug 847514 in python-debian (Ubuntu Oneiric) "Convert Xubuntu CD to dh_python2" [Wishlist,Triaged] https://launchpad.net/bugs/847514
<barry> micahg: got it
<micahg> barry: thanks!
<dobey> ScottK: it has the same problem under gnome-shell. it doesn't properly handle the notification area icon not being embedded. -> bug in skype. :)
<ScottK> When infrastructure changes under an app with no fallback, I don't think that's a bug in the app.  It's poor project planning on the infrastructure's part, but there's not much chance of either of us fixing it, so we can agree to disagree.
<smoser> SpamapS, slangasek thinking more about that bug in ifquery...
<smoser> the way we're using it, not only would ifquery call the mappings scripts on 'list' (when normally they'd only be expecting to be called on ifup), but also we're going to be basically calling them recursively.
<[swe]jeppe> hi everyone
<smoser>  - ifup -a
<smoser>   - mapping script called
<SpamapS> and returned from
<smoser>   - upstart job calls ifquery -a --list
<smoser>   - ifquery calls mapping script
<SpamapS> repeatedly, but not recursively
<smoser> yeah
<smoser> SpamapS, bug 850226 opened.
<ubottu> Launchpad bug 850226 in ifupdown (Ubuntu) "static-network-up script waits for 'auto' devs without a config stanza" [Medium,In progress] https://launchpad.net/bugs/850226
<SpamapS> smoser: oh good thanks. :) I meant to do that yesterday
<[swe]jeppe> can someone tell me whats the biggest obstickle why its not working to play games on linux?
<dobey> [swe]jeppe: i don't think this is the channel for answering that, but i presume the answer is "you haven't installed them" :)
<Pici> [swe]jeppe: #ubuntu-offtopic is the channel for general discussion.
<[swe]jeppe> no, im just woundering whats block when u install games on linux. hard to explain in english
<barry> micahg: how truly odd.  bug 788514 has a task for python-debian, which is marked fixed released, and i have a branch sitting here with the necessary changes.  i usually never manually flip the fix released status, so i'm not sure what's going on.  maybe i never uploaded the change.  anyway, i'll do that now
<ubottu> Launchpad bug 788514 in pyxdg (Debian) "python packages on the CDs not using dh_python2" [Unknown,New] https://launchpad.net/bugs/788514
<Pici> [swe]jeppe: And this channel isn't for general disucssion, its a working development channel.
<[swe]jeppe> ok sorry will move :-)
<hyperair> hi. any ubuntu-release members around?
<smoser> slangasek, around ?
<smoser> so if i pass '--allow all' to 'ifquery --list', then it is busted at the moment.
<jdstrand> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Beta 1 released | Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jdstrand
<smoser> never mind.
<smoser> dugh
<slangasek> smoser: --allow auto :)
<smoser> it is also broken if i pass --allow moser-youre-an-idiot
<smoser> strange
<slangasek> smoser: as for ifquery calling the mapping scripts... the design says it's fine to call the mapping script as long as the interface is down, but not while it's up, but we don't need to call it while up to get the mapping because that's in the ifstate file... this is the bit that needs stitching together, and where I threw my hands up in irritation with noweb last night
<smoser> sweet sweet noweb
<slangasek> SpamapS: what i386-only printer drivers are giving you problems?
<SpamapS> slangasek: 3rd party
<SpamapS> slangasek: I had to force install them long long ago
<SpamapS> slangasek: canon pixma mp560 to be specific
<skiy1337> I've just written a piece of software. If you have an FTP server, it let's you store you documents on it.
<SpamapS> slangasek: it seems to be something else actually.. I removed them and apt still wants to uninstall libc-bin when I try to install skype:i386
<slangasek> SpamapS: oh, lovely
<hallyn> lp:ubuntu/libvirt is just an alias to lp:ubuntu/oneiric/libvirt right?
<slangasek> SpamapS: any better with 'apt-get install skype:i386 libc-bin'?
<hallyn> (quick test says 'yes' :)
<SpamapS> slangasek: yes that works.. but.. wtf?
 * SpamapS wonders why gcc-4.6-base:i386 is needed for skype.. :-P
<slangasek> SpamapS: because gcc-4.6-base is needed by libgcc1 is needed by $world :)
<SpamapS> lurvely
<slangasek> gcc-4.6-base is really very base
<slangasek> what's the delta of installs/removals look like between the "I want to remove libc-bin" and "ok boss" cases?
<SpamapS> wow.. one gets a week behind on upgrades and oneiric has replaced nearly everything
<SpamapS> slangasek: very similar, just this time it doesn't want to remove libc-bin
<slangasek> heh
<slangasek> then it's probably picking a bad upgrade path on account of eglibc being out of date; I've seen that a couple of times before
<slangasek> haven't gotten around to filing a bug for it yet, maybe you could?
<SpamapS> slangasek: a bug in apt?
<slangasek> SpamapS: yep
 * SpamapS looks through log to find what version of libc-bin was replaced
<SpamapS> Preparing to replace libc-bin 2.13-17ubuntu2 (using .../libc-bin_2.13-20ubuntu2_amd64.deb) ...
<SpamapS> slangasek: for the record, aptitude also just refused to do anything
<slangasek> how sensible of it :)
<SpamapS> alright, filed bug 850264 with, hopefully, enough of the details
<ubottu> Launchpad bug 850264 in apt (Ubuntu) "given a foreign architecture of i386 on amd64 machine, and an outdated libc, apt tries to remove libc-bin" [Undecided,New] https://launchpad.net/bugs/850264
<slangasek> SpamapS: looks good, thanks
<micahg> barry: ok, thanks much
<barry> micahg: no worries
<lamont> (took 1 hour, 34 minutes, 49.9 seconds) <-- micahg
<Amoz> notice like a boss
<hallyn> regcomp succeeds on "^\\s*(\\S+),(\\S*),(\\S+),(\\S+)\\((\\S+)\\),(\\S+),([0-9]+),?\\s*$" , but fails on "^(?:\\s*(\\S+))?\\s*(\\S+),(\\S*),(\\S+),(\\S+)\\((\\S+)\\),(\\S+),([0-9]+),?\\s*$" (identical except for the &(?:\\s*(\\S+))? at front).
<hallyn> I assume it's failing on the '?:'.  Can anyone confirm if that is not supported, and if there's another way to do that?  (namely, match the \s* if it is there, but not return it as a match)?
<hallyn> maybe i should just do '.*'...
<slangasek> hallyn: isn't that specific to perl regexp, not posix regexp?
<hallyn> slangasek: sadly it would seem so.  So is there any posix way to do that?
<hallyn> ATM I'm resorting to hacking the c code around it to discard the prefix if present
<hallyn> but ideally I could do it in the regexp
<broder> hallyn: you could look at the number of groups you get back, if that's the only one followed by a ?
<broder> (sorry, there's a bit too much punctuation in there for me to actually parse what's going on)
<hallyn> broder: the structure of the existing code is such that one function passes the regex and # expected fields into another  :(
<hallyn> now if i could have it return an empty match i suppose that would be fine
<broder> yeah, i can't come up with any way to do that
<hallyn> actually,
<broder> well...i guess you might be able to do something like (|\\s*(\\S+))
<broder> with no ?
<hallyn> that code does take multiple regexes, so maybe i could just pass 2
<hallyn> yeah that might work too ('|')
<broder> you'd want to be sure to drop the group around the inner \\S+
<hallyn> thanks - lemme see if what i'm doing now works, and then maybe i'll try that
<broder> it's not necessary, and changes the number of groups based on the matched expr
<hallyn> you mean '(|\\s*\\S+)' then?
<broder> yeah
<hallyn> ok thanks
<hallyn> (gotta run, may try that later)
<dupondje> how is it possible to have this: LANGUAGE=nl:zh_CN:en_AU:en ?!
<dupondje> selected nl in the control panel, and made it a weird combo ...
<dobey> jdstrand: hi. care to prioritize sponsoring of https://code.launchpad.net/~dobey/ubuntu/oneiric/ubuntuone-installer/release-174/+merge/75437 so it gets approved before string freeze? :)
<jdstrand> I'll look at it
<jdstrand> dobey: this needs a new orig.tar.gz
<jdstrand> dobey: can you provide me with a signed source package?
<dobey> jdstrand: huh, i've not had anyone say this before for merges into lp:ubuntu/ branches. where should i put the source package?
<jdstrand> dobey: well, it is a new upstream release and I want to be able to verify the checksums on the orig.tar.gz with the upstream source
<jdstrand> dobey: you drew the short straw getting a security/archiveadmin member :P
<jdstrand> dobey: chinstrap is fine
<dobey> jdstrand: https://chinstrap.canonical.com/~dobey/
<YokoZar> slangasek: uploading fixed ssl ia32-libs now...probably finish uploading in a few hours :D
<jdstrand> dobey: thanks, I'll process it now
<dobey> jdstrand: thanks
<slangasek> YokoZar: did it require anything more than the refresh?
<YokoZar> slangasek: I had to add SSL 1.0.0 in there as well
<YokoZar> (for Wine)
<jdstrand> dobey: can you adjust the perms of the dsc and debian.tar.gz files?
<slangasek> YokoZar: hmm.  how/why does it depend on the newer ssl?  I'm rather unhappy with the idea of having two copies of libssl in ia32-libs - one is quite bad enough
<YokoZar> slangasek: because ssl-dev requires the 1.0.0 copy and Wine is building against that
<dobey> jdstrand: fixed, sorry
<jdstrand> thanks
<slangasek> YokoZar: does it need headers or just the .so?  Far better to manually add the .so symlink if that's all it needs
<YokoZar> slangasek: I'm not sure it's good to open the can of worms of building with newer header files than the actual linked library...
<slangasek> certainly not, that's why I asked if it needs headers
<YokoZar> Yeah it does
<slangasek> sigh. ok.
<jdstrand> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Beta 1 released | Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<bdrung> jamespage: around?
<doko> "Gentoo sanity check failed!" does this even exist?
<desrt> doko: ;)
<broder> duh, why do you think it faileD?
<doko> bug 770749
<ubottu> Launchpad bug 770749 in libspf (Ubuntu Oneiric) "libspf version 0.999-1.0.0-p3.dfsg-3 failed to build on amd64 with GCC-4.6/oneiric" [High,Confirmed] https://launchpad.net/bugs/770749
#ubuntu-devel 2011-09-15
<dupondje> ls
<jelmer> cjwatson: I'll have a look
<cjwatson> thanks
<micahg> lamont: thanks!
<ScottK> doko_: libspf is about to be removed from Debian.  I'd just remove it along with it's two rdepends.
<ScottK> I'll mark in the bug.
<ScottK> Done.
<pitti> Good morning
<pitti> apw: no need to, you just need to edit /etc/init/plymouth-stop.conf and add "lightdm" to the list in pre-start
<pitti> freeflying: hey, how are you?
<pitti> freeflying: would you mind dropping indicator-applet from the ubuntu-chinese seeds (and create an oneiric branch for it), and update the metapackage?
<pitti> indicator-applet is gone now
<didrocks> good morning
<gador> morning
<dholbach> good morning
<doko> pitti: did you see the postgres ftbfs on armel?
<pitti> uh, no, I didn't; shouldn't I get mail about that?
<pitti> hangs in the test suite, hmm
<doko> start your day with http://qa.ubuntuwire.org/ftbfs/ ;-)
<pitti> doko: actually I started with http://people.canonical.com/~ubuntu-archive/nbs.html :)
 * pitti removes the old libindicator3 libpanel-applet-3-0 for good
<pitti> two to go, flashplugin-nonfree-extrasound and honeyd
<doko> nbs looks like a boring start meanwhile =)
<micahg> doko: I've got a couple of armel FTBFS syncs queued up for sync (inteltool drops armel, exo fixes the FTBFS)
<mvo> pitti: cdbs langpack.mk is no more right, can it just be removed and dh_translations will DTRT (context is rhythmbox-ubuntuone-music-store ftbfs)
<pitti> mvo: right, dh_translations is the new thing
<pitti> mvo: but don't bother about rhythmbox-ubuntuone-music-store
<mvo> why not? is it going to be dropped?
<pitti> mvo: I think we shoudl ship an empty package for not breaking upgrades
<pitti> mvo: ubuntuone is still all gtk2, and rb is gtk3
<mvo> oh
<pitti> i. e. the package is FUBAR right now
<doko> micahg, these two?
<pitti> mvo: I added a breaks: to that version, so from my POV we might just as well remove it from teh archive
<micahg> doko: yeah, I sync'd the other one just now
<pitti> mvo: and reintroduce it when it gets ported
<pitti> mvo: want me to?
<pitti> mvo: (and yes, it's a pity)
<mvo> pitti: yeah, please go ahead
 * mvo looks at something else in the list as a wake-up task then
<pitti> mvo: done; I didn't see an FTBFS bug for this, though
<mvo> pitti: I used http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20110816-oneiric.html#core
<pitti> right, but doko auto-filed FTBFS bugs for all packages usually
<mvo> hm, no idea then
<doko> mvo: these are superseded
<doko> wgrant: current debian and ubuntu version numbers would be nice, hint, hint ^^^
<wgrant> Those shouldn't be superseded.
<wgrant> I thought I excluded superseded packages from the packageset listing...
<doko> ahh, ok, these are the one problematic on the virtual builders
<micahg> those aren't superseded AFAICT
<doko> ScottK, could you/kubuntu have a look at  the libgwenhywfar ftbfs?
<freeflying> pitti: seems there is no package depends on that, guess we can drop it from archive if possible
<pitti> freeflying: ubuntu-chinese-desktop depends on indicator-applet-session, which doesn't exist any more
<pitti> that's the one that needs to be unseeded
<freeflying> pitti: I mean to drop ubuntu-chinese-desktop, looks there is no need for this package
<pitti> ah
<pitti> freeflying: I'm just not sure why it was introduced in the first place, so I'd appreciate a removal bug
<freeflying> pitti: assing or subscribe to someone/team?
<pitti> freeflying: ubuntu-archive; but you can just tell me the number
<freeflying> pitti:
<freeflying> 850695
<Amoz> dholbach, where can I find Mike Heald?
<dholbach> Amoz, try https://launchpad.net/~mike-powerthroughwords
<Amoz> dholbach, oh, he's not at IRC?
<dholbach> apparently not - let me check where he's from
<dholbach> the UK, might be waking up in a bit
<Amoz> actually, I'm just trying to get the ubuntu-friendly branch to execute, but I'm getting a "template 500.html not found"
<dholbach> I guess you can always just drop him an email
<Amoz> he rejected one of my merges a few minutes ago so he should be awake =)
<dholbach> oh ok
<dholbach> Amoz, passed on the ping :)
<Snicksie> i guess UK is already awake, its 9:12 AM there dholbach :p
<dholbach> I guess that depends on how long you sleep ;-)
<Amoz> btw, the UF site looks awesome
<dholbach> or if you have to take the dog for a walk first, etc.
<dholbach> :)
<jedimike> Amoz: hi
<Amoz> oh hai
<pitti> freeflying: thanks removed
<pitti> freeflying: (imagine a comma there :) )
<Snicksie> true dholbach :p
<Amoz> jedimike, I get a template error when trying to run the ubuntu-friendly website, could you give me a pointer? :)
<Amoz> jedimike, do I have to include the template directory in the settings.py?
<jedimike> Amoz: of course, what error are you seeing?
<jedimike> Amoz: you shouldn't need to...
<Amoz> TemplateDoesNotExist: 500.html
<jedimike> hmm, weird, which template?
<Amoz> actually I'm just branching, then runserver, and try to visit the site
<jedimike> it *should* just runâ¦ let me check my local_settings.py to see if I forgot something
<jedimike> Amoz: I think I see, it's not a template directory issue - can you create a local_settings.py file in apps/ and put DEBUG = True in it
<Amoz> oh...
<jedimike> Amoz: then we should be able to see the real error. Most likely a database issue if my guess is correct
<Amoz> ooooh
<jedimike> Amoz: I need to put a hacking.txt in there because there are a couple of setup steps you need to do
<Amoz> I'm not having any databases running.
<Amoz> yes please :) would be nice having a running setup
<jedimike> ah ok :) You can override database names and usernames in local_settings.py - I will get a hacking.txt file in there today!
<freeflying> pitti: another one #850705
<jedimike> Amoz: and please excuse some of the code duplication in there, it was initially produced in a 4 day sprint (which included wireframing and getting data imported from the results tracker system!)
<jedimike> cleanup is going to be my focus over the next week or so
<Amoz> jedimike, I think it looks awesome, and I'm no expert so I wouldn't know.
<jedimike> Amoz: thank you, I'll take the compliments where I can get them :D
<rbasak> The evolution first-run wizard says "Click on Forward" but the button is actually labelled "Continue", in en_GB anyway. Where should I report this?
<tkamppeter> pitti, can we do a small change on CUPS' AppArmor profile? See my last comment on bug 160092.
<ubottu> Launchpad bug 160092 in cups (Ubuntu) "apparmor rules break filters in /usr/local" [Medium,Fix released] https://launchpad.net/bugs/160092
<pitti> tkamppeter: yes, sure
<tkamppeter> pitti, should be trivial and so feasable for beta2.
<doko> apw, any progress on the kernel header include fix? bug 833035 is another fall out ...
<ubottu> Launchpad bug 833035 in labrea (Ubuntu Oneiric) "labrea version 2.5-stable-3 failed to build in oneiric" [High,Confirmed] https://launchpad.net/bugs/833035
<pitti> tkamppeter: I need to do two other bug fixes in cups anyway, I'll do that now
<apw> doko, i have a fix somewhere, damn it dropped off my radar
<apw> doko, you got the bug number save me hunting it down
<pitti> tkamppeter: committed
<doko> apw, bug 824377
<ubottu> Launchpad bug 824377 in linux (Ubuntu Oneiric) "ftbfs on i386" [High,In progress] https://launchpad.net/bugs/824377
<tkamppeter> pitti, thanks.
<tkamppeter> pitti, we should not simply drop the ipptool files out of the distro, but better make a separate, optionally installable binary package, named ipptool or cups-ipptool.
<pitti> tkamppeter: I didn't drop ipptool, just the example files
<tkamppeter> pitti, are these really only example files or does ipptool need them to perform its tests?
<pitti> tkamppeter: they are not referenced anywhere in the source / code
<tkamppeter> pitti, they are referenced in the man page, "man ipptool".
<doko> ScottK, could you/kubuntu look at kde-style-skulpture kompozer ftbfs?
<doko> jamespage, could you have a look at bug 831372?
<ubottu> Launchpad bug 831372 in jmol (Ubuntu Oneiric) "jmol version 12.0.40-1 failed to build in oneiric" [High,Confirmed] https://launchpad.net/bugs/831372
<doko> and bug 749219
<ubottu> Launchpad bug 749219 in jing-trang (Ubuntu Oneiric) "jing-trang version 20091111-3 failed to build on i386" [High,Confirmed] https://launchpad.net/bugs/749219
<doko> maybe just propose the removal ...
<jamespage> doko: I can in a bit
<doko> no haste ...
<kelemengabor> hi, is there any indicator-datetime dev around, who could take a look at bug #845473 and the proposed branch? currently, its i18n looks pretty bad, but the fix is really simple.
<ubottu> Launchpad bug 845473 in Ubuntu Translations "Strings from indicator-datetime do not appear translated" [Medium,Triaged] https://launchpad.net/bugs/845473
<pitti> didrocks: ^ who would be a good reviewer?
<didrocks> pitti: kelemengabor: tedg will probably be the best right now as ronoc is away
<didrocks> I'll ping him when he's around
<kelemengabor> thanks!
 * ogra_ sighs about appo
<ogra_> rt
<ogra_> making my system comple
<ogra_> tely unu
<ogra_> #sable
<ogra_> with it
<ogra_> 's
<ogra_> popu
<ogra_> p
<ogra_> windows forceful
<ogra_> ly
<ogra_> steali
<ogra_> ng the foc
<ogra_> us
<pitti> ?
 * ogra_ has closed about 120 popups up to 
<ogra_> now
<ogra_> and it doesnt seem to stop !
<pitti> uh, 99 ~ubuntu-archive bugs
<ogra_> hmm, now it stopped it seems
 * pitti goes to work on some
<ogra_> can we possibly make it not steal the focus at least
<janimo> is there no checkbox for 'do not report for this package' ?
<ogra_> janimo, not in this window
<ogra_> if i would click ok it would actually fire off the apport dialog
<ogra_> but that tears my system down to its knees
<jamespage> cjwatson: how would I go about requesting an addition to the ubuntu-server packageset?
<ogra_> and having to cliock it over 100 times would take hours (apport coming up takes 15-20 min after i clicked)
<cjwatson> jamespage: normally you should do so by seeding the additional package
<cjwatson> then it's semi-automatic
<cjwatson> (as in, occasionally I remember to run the script that works out the right package sets from the seeds and pushes them to LP)
<dpm> hi, could whoever who's patch piloting have a look at bug 542068?
<ubottu> Launchpad bug 542068 in Ubuntu Translations "Missing translations for "xterm failsafe session"" [Low,Triaged] https://launchpad.net/bugs/542068
<dpm> with people accessing that menu to switch between the unity and unity 2d sessions in lightdm, I assume that those strings have become more visible
<jamespage> cjwatson: OK - thanks - I'll take a look there
<Daviey> jamespage: openjdk7 is already seeded isn't it?
<jamespage> Daviey: hrm - don't think so
<jamespage> its not default yet
<Daviey> oh.
<scarleo> Hi, is there any reason to why aa-logprof updates apparmor standard profiles instead of adding changes to local/profile? Customizing standard profiles means they get overwritten every update
<jamespage> doko: merge proposed for jmol (bug 831372)
<ubottu> Launchpad bug 831372 in jmol (Ubuntu Oneiric) "jmol version 12.0.40-1 failed to build in oneiric" [High,In progress] https://launchpad.net/bugs/831372
<jamespage> looking at jing-trang now
<doko> jamespage, s/icedtea6-plugin/icedtea-plugin/
<doko> 6 is a transitional package
<jamespage> doko: OK - I'll update
<doko> jamespage, wait, already done
<jamespage> doko: ta
<jamespage> doko: merge proposed for bug 749219 as well
<ubottu> Launchpad bug 749219 in jing-trang (Ubuntu Oneiric) "jing-trang version 20091111-3 failed to build on i386" [High,In progress] https://launchpad.net/bugs/749219
<jamespage> bdrung: missed a ping from you last night - anything I can help with?
<bdrung> jamespage: yes. the question is whether we can get eclipse 3.7 into oneiric
<bdrung> jamespage: eclipse 3.7 from debian experimental needs an newer asm3 and lucene2
<bdrung> jamespage: asm3 needs an FFe (has a bunch of rdepends that needs testing)
<bdrung> jamespage: the newer lucene2 fails to build: https://launchpadlibrarian.net/79813945/buildlog_ubuntu-oneiric-i386.lucene2_2.9.4%2Bds1-3~oneiric1~ppa1_FAILEDTOBUILD.txt.gz
<bdrung> jamespage: do you have time to debug this build failure?
<smoser> anyone have thoughts on how big of a deal bug 850587 is ?
<ubottu> Launchpad bug 850587 in cloud-init (Ubuntu) "cloud-init fails to install if /tmp directory is noexec" [Undecided,New] https://launchpad.net/bugs/850587
<smoser> i dont' even see where i'm trying to use /tmp for execute
<Daviey> smoser: That bug is all over the Debian BTS.. :/
<smoser> so its a dupe of a debconf bug?
<Daviey> smoser: blame the templates.
<Daviey> smoser: ie, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=129289
<ubottu> Debian bug 129289 in debconf "noexec /tmp" [Wishlist,Open]
<cjwatson> I was sort of meaning to fix that debconf bug at some point; but noexec /tmp really doesn't provide significant security so it's not high priority
<cjwatson> it's so utterly trivial to work around
<smoser> is there a debian bug ?
<cjwatson> see above! :-)
<Daviey> http://www.google.com/search?num=100&q=site:bugs.debian.org#num=100&hl=en&safe=off&q=site%3Abugs.debian.org+noexec+%2Ftmp&aq=f&aqi=&aql=&oq=&gs_rfai=&pbx=1&fp=cdc8e99d0ce2089
<Daviey> smoser: ^^
<smoser> :)
<Daviey> just don't noexec /tmp :)
<cjwatson> yeah, for now, this is DDTT.
<Daviey> Fix Released :)
<cjwatson> no, it is a valid bug, it's just low prio
<smoser> bug 90085
<ubottu> Launchpad bug 90085 in debconf (Ubuntu) "When /tmp is mounted noexec, preconfigure fails" [Wishlist,Triaged] https://launchpad.net/bugs/90085
<smoser> cjwatson, so where would you assume you can put a file that will be guaranteed-ish to be not mounted noexec ?
<smoser> other than /bin
<cjwatson> dunno ottomh, on the phone
<smoser> i'm just curious
<smoser> ok
<cjwatson> we'd probably do something under /var
<smoser> bug 90085 is the ubuntu bug
<ubottu> Launchpad bug 90085 in debconf (Ubuntu) "When /tmp is mounted noexec, preconfigure fails" [Wishlist,Triaged] https://launchpad.net/bugs/90085
<cjwatson> yes, I saw that when you said it ten lines before ;-)
<smoser> i did ?
<smoser> oh. i did say it twice. man my brain is broken.
<didrocks> mdke_: hey, can you have a look at bug #844889? This is part 2 of an UIFe that was fully accepted last week (but all changes couldn't come in, so I asked dx to reask for an UIFe), as I understood you didn't take the sceenshots yet?
<ubottu> Launchpad bug 844889 in unity "UIFe: Dash - Shape and positioning of most of the elements in the Dash need adjustment (Part 2)" [Medium,In progress] https://launchpad.net/bugs/844889
<jdstrand> scarleo: that is an interesting question. it does not for historical reasons, but that might be a good thing to change. can you file a bug?
<scarleo> jdstrand: I have already: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/850830
<ubottu> Ubuntu bug 850830 in apparmor (Ubuntu) "aa-logprof updates standard profiles instead off changing local/profile" [Undecided,New]
<jdstrand> scarleo: thatnks
<jamespage> bdrung: sure - I'll take a look now
<bdrung> thanks
<GunnarHj> Riddell, RoAkSoAx: Hi, saw that you are patch pilots today. Can some of you possibly sponsor a language-selector MP before beta freeze? https://code.launchpad.net/~gunnarhj/language-selector/fontconfig/+merge/75045
<bregma> hey ho, could someone enlighten me on the Ubuntu policy of -dbg packages vs. -dbgsym packages?
<cjwatson> bregma: -dbg packages are for when the debug version actually needs to be different in some way (e.g. different compiler flags, #ifdef bits, etc.).  -dbgsym packages simply consist of the debug symbols filed off the objects in the main packages.
<bregma> cjwatson, is there any way to get -dbgsym packages from a PPA?
<cjwatson> that I don't know
<tkamppeter> anyone can help me tracking down from which program a notification message comes?
<tkamppeter> BigWhale (~b@193.77.150.34) has joined #ubuntu-desktop
<tkamppeter> <tkamppeter> I am trying to fix bug 842768. On normal print jobs a notification popps up telling that the printer is not connected. It is triggered by CUPS shouting a "connecting-to-device" state reason into the D-Bus, but I cannot find out which program picks up this. I have already uninstalled system-config-printer and the notification still appears.
<ubottu> Launchpad bug 842768 in system-config-printer (Ubuntu) "Cups notifies "printer ' xxx ' may be not connected " although printer is OK and printing is OK too" [Medium,In progress] https://launchpad.net/bugs/842768
<geser> bregma: IIRC no -dbgsym packages get build for PPAs
<geser> pitti: ^^ is that still correct? (no -dbgsym for PPA)
<ahasenack> SpamapS: hi, do you think you will have time to upload #813477 today?
<pitti> geser: right; technically we could, but there is no archive to publish them to
<tkamppeter> pitti, hi
<ahasenack> hi, can someone please sponsor the smart package in the unnapproved queue for lucid? https://launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text=
<tkamppeter> pitti, can you approve cups-pdf in natty-proposed and also Q-FUNK's cups-pdf upload for Debian?
<ahasenack> https://launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text=smart more specific url
<jamespage> bdrung: OK - so I think there are a couple of issues with the FTBFS of lucene2 from experimental
<stgraber> jamespage, cjwatson: I proposed a temporary fix for open-iscsi in bug 838809 that will at least fix installs for beta2, unless one of you knows how to make open-iscsi behave properly with already existing sessions.
<ubottu> Launchpad bug 838809 in Ubuntu Oneiric "authenticated and unauthenicated iscsi clients fails to complete boot" [High,Confirmed] https://launchpad.net/bugs/838809
<tkamppeter> pitti, can you help me with bug 842768?
<ubottu> Launchpad bug 842768 in system-config-printer (Ubuntu) "Cups notifies "printer ' xxx ' may be not connected " although printer is OK and printing is OK too" [Medium,In progress] https://launchpad.net/bugs/842768
<pitti> tkamppeter: I'm pretty much off for a long weekend; but I'm sure that SpamapS/RAOF will get to it soon, they handle SRUs pretty well these days
<jamespage> i) the version of libjidy-java we have in oneiric has a bug - see merge proposal on bug 841695
<ubottu> Launchpad bug 841695 in lucene2 (Ubuntu) "FTBFS with jtidy 7+svn20110807-1" [High,In progress] https://launchpad.net/bugs/841695
<stgraber> jamespage, cjwatson: If you're fine with that workaround, I'll implement it, close that bug and make sure we have another bug report for open-iscsi not mounting additional LUNs when the root is on iscsi.
<pitti> tkamppeter: can have a look next Monday
 * pitti waves goodbye
<jamespage> bdrung: ii) something related to the buildd running out of memory when you tested - trying to reproduce that now but works fine locally
<tkamppeter> pitti, so have nice holidays, will move all the stuff past-beta2 ...
<cjwatson> stgraber: yes, I'm fine with that for now.  You're at the limits of my iSCSI knowledge; it might be worth syncing up with the Debian maintainer (although admittedly our package could sorely use a merge with Debian and we have a bunch of patches still to forward ...)
<jamespage> stgraber: workaround sounds reasonable - at least it gets us back to a point pre beta-1 where iscsi root at least partially worked
<stgraber> ok, I'll push that for now and make a note to look at what's in Debian, see if they also have the problem.
<jamespage> brdung: we could sync jtidy from Debian as -2 should resolve the issue with this package - but the package switches build system which I was a little reticent todo at this point in the cycle
<cjwatson> HTML::Template version 2.6 required--this is only version 2.10 at blib/lib/HTML/PopupTreeSelect.pm line 7.
 * cjwatson giggles
<euroford> cjwatson: hi, the initial iso of Qin ubuntu is released, where could I find it?
<euroford> cjwatson: I can test it
<tkamppeter> Anyone can help me wit an indicator notification issue?
<apw> cjwatson, i am looking at a flicker free regression, and i am starting to wonder if grub is actually leaving the contents on the screen at hand over ... is there some simple way i can test that?
<cjwatson> euroford: did whoever told you that it was released not also give you the URL?
<cjwatson> if not, that was unhelpful of them :-)
<cjwatson> euroford: http://china-images.ubuntu.com/oneiric/daily-live/current/
<euroford> cjwatson: thanks
<cjwatson> apw: maybe use 'set debug=linux' and you should be able to see some debug output from GRUB on top
<euroford> cjwatson: I just received the email from lp
<cjwatson> oh
<euroford> cjwatson: could I release the URL in ubuntu-cn maillist?
<apw> cjwatson, well that does say things on the purple, then it loads the kernel and initrd, then 'instantly' to a human it drops back like it would with gfxpayload=text
<euroford> cjwatson: I think more people will involved in.
<cjwatson> euroford: yes
<cjwatson> apw: oh, on reflection, if GRUB is going to set the video mode it sets it late enough that it's hard to distinguish that from debug output
<cjwatson> apw: can I see grub.cfg?
<cjwatson> apw: also might be worth seeing what 'set' from the GRUB command line says gfxpayload is set to
<cjwatson> apw: actually the value of linux_gfx_mode is more interesting
<apw> cjwatson, http://people.canonical.com/~apw/grub.cfg
<Quintasan> dholbach: ping
<Quintasan> uhh I just got email,  I'll reply to that then
 * Quintasan has no access to the internet
 * Laney wonders how these messages are getting through
<apw> cjwatson, so linux_gfx_mode is text
<cjwatson> apw: is the card perchance blacklisted?
<cjwatson> apw: or did the last boot fail?
<apw> oh the last boot did fail
<cjwatson> the X guys asked me to set gfxpayload=text when the last boot failed on the grounds that that's more likely to work well
<apw> i suspect that invalidates all my testing
<ahasenack> pitti: hey, do you have postgresql 9.1 packages for lucid?
<apw> cjwatson, what do i set it to to override things
<cjwatson> apw: change 'set gfxpayload=$linux_gfx_mode' to 'set gfxpayload=keep'
<apw> cjwatson, you know that feels like it might put us in a 'my machine only boots the second time' spot
<cjwatson> possible, although that's better than "my machine won't boot at all"
<cjwatson> albeit more confusing
<cjwatson> I dunno, maybe you could argue that out with bryceh and RAOF :-)
 * cjwatson would rather do what clever people tell him is best, in this case
<apw> cjwatson, yeah can't fault the logic, perhaps i could ask for something on the purple to tell me :)
<ahasenack> pitti: found the ppa, nm
<cjwatson> "Safe mode" in a really chunky VGA font
<tgardner> is there a way to specify an alternate package mirror for the Live CD from the kernel boot command line ?
<apw> cjwatson, well at least that tells me why none of my testing make any sense, now when i crash the kernel early i really do have purple, so you are handing off to me with =keep
<cjwatson> tgardner: not for the live CD itself, but if you set mirror/http/hostname=foo.example.com (and mirror/http/directory=/example if it's something other than /ubuntu) then that should affect installation
<cjwatson> (IIRC)
<cjwatson> apw: ok, good, I think
<tgardner> cjwatson, I have a local mirror and just wanted to speed up installation tests
<apw> cjwatson, well i think i just invalidated 12 hours of build boot testing on due to the no handoff on crash
<cjwatson> apw: :-(
<cjwatson> though, not sure that's the major audience - but yes
<apw> cjwatson, well at least i am making some progress, i am at least getting into the kernel with purple
<dholbach> Quintasan, pong
<apw> cjwatson, ok i am getting =text on even reboot after a good boot, so perhaps i am blacklisted
<cjwatson> apw: should be able to compare PCI IDs
<cjwatson> apw: of course it's possible the blacklisting is buggy
<apw> cjwatson, my blacklists (assuming grub-gfxpayload-list is the right one) only has vmware filled in i think
<cjwatson> hmm
<apw> there is just a blank line in my 00_header line
<apw> file even
<cjwatson> from the command line, try:
<cjwatson> hwmatch ${prefix}/gfxblacklist.txt 3
<cjwatson> echo $?
<cjwatson> echo $match
<apw> cjwatson, is that the grub command line ?
<cjwatson> yeah
<apw> cjwatson, error: incompatible licence
<apw> and $? == 2
<apw> and $match == ''
<cjwatson> oh FFS
<cjwatson> bug on grub2 please?
<cjwatson> dead easy to fix
<apw> shall i shove my kernel bug over to grub2, i think that makes sense
<stgraber> oh, that's where the "incompatible licence" comes from ;) I saw that yesterday in a VM but wasn't quite sure where that was coming from.
<cjwatson> apw: yes
<cjwatson> totally my fault then, I thought I'd checked all our additions for that
<cjwatson> maybe I only checked in the Debian branch
<apw> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/850202
<ubottu> Ubuntu bug 850202 in linux (Ubuntu) "grub splash is erased before plymouth starts" [Undecided,In progress]
<cjwatson> fix uploaded
<cjwatson> that's probably buggered things up for a good part of the cycle :-/
<Daviey> apw: Ah!  I think i had that problem, but i blamed it on my hardware.
<Daviey> cjwatson: Do you have a few minutes to review some stuff?
<dpm> hi, could perhaps someone have a look at the patch for bug 542068?
<ubottu> Launchpad bug 542068 in Ubuntu Translations "Missing translations for "xterm failsafe session"" [Low,Triaged] https://launchpad.net/bugs/542068
<apw> cjwatson, its been wrong on my machine for a fair while for sure
<bdmurray> pitti: is bug 298217 missing the verification-needed tag?
<ubottu> Launchpad bug 298217 in libgksu (Debian) "no second attempt and no feedback when wrong password entered" [Unknown,New] https://launchpad.net/bugs/298217
<slangasek> apw: ping, re: bug #824377
<ubottu> Launchpad bug 824377 in linux (Ubuntu Oneiric) "ftbfs on i386" [High,In progress] https://launchpad.net/bugs/824377
<apw> slangasek, hi
<slangasek> apw: hey there - is this bug really "in progress" still?  I know last-kernel-of-the-cycle is impending
<apw> the kernel moves in to freeze, but we can still spin bug fixes for it, and that one would be one i think we can do
<apw> we move into SRU mode for the kerne
<SpamapS> ahasenack: heh, I've thought I'd have time the last two days. I'll take a look right now.
<ahasenack> SpamapS: super, thanks a lot
<slangasek> the fix doesn't help with archive build failures for the remainder of the cycle if it only goes to -updates; by "spin bug fixes", do you mean you would upload to the -release pocket?
<cjwatson> Daviey: in a bit, I'm doing some sysadmin here
<cjwatson> slangasek: they upload to release pocket but adhering to SRU rules
<cjwatson> AIUI
<slangasek> ah
<Daviey> I assume -updates only opens if something needs 0-day'ing once we have the release iso's?
<Daviey> cjwatson: thanks.
<SpamapS> Daviey: a little before the release iso's really. If its not critical for install day it starts falling into -proposed after beta2 (or at least, it did in 11.04 cycle)
<apw> cjwatson, confirmed that your new grub sorts out my issues, just a white flash as lightdm starts now
<Daviey> SpamapS: that just seems confusing. :/
<apw> cjwatson, i am supprised to find so few blacklists in the blacklist, ie none, is this separate from nattys list ?
<SpamapS> Daviey: IIRC it has something to do with space management too.. being on the release team, I'm sure you can auth things in if you want to, but I'm thinking its a case-by-case basis.
<ScottK> doko: I'll look at kde-style-skulpture.  kompozer isn't a KDE app (despite the name).  You want someone who knows about mozilla stuff.
<apw> slangasek,  yeah what colin said
<apw> slangasek, if i wasn't slammed with flicker-free-boot, boot-speed, and power-consumption spam i'd be right on it
<apw> slangasek, i will try and get it out for review in my AM so it can be in the next upload
<cjwatson> apw: check with tseliot for that; he's been doing the updates there
<cjwatson> Daviey: go ahead?
<apw> cjwatson, thanks will do
<Daviey> cjwatson: Would you be able to look at the branches on bug 831496?  introduces a new source package, xmlrpc-minimal, which links against the new binary package produced from curl (minimal configure options).
<ubottu> Launchpad bug 831496 in Ubuntu Oneiric "[FFe] Add cobbler enrollment support to server cd image" [High,New] https://launchpad.net/bugs/831496
<cjwatson> Daviey: wait, why do you need a new source package just to do a different udeb build?
<cjwatson> you really shouldn't need that
<cjwatson> just configure the curl udeb differently
<Daviey> cjwatson: So, if xmlrpc binary package build depns on a bloated curl libary, how can they co-exist?
<slangasek> apw: thanks, appreciated - it's nothing that should preempt those other topics to be sure, but it seems like an easy win so I just wanted to check if we'll still get it :)
<apw> slangasek, yeah i will put it top of my list in the mornign and hopfully that'll get done before things go to poop
<cjwatson> Daviey: shouldn't matter what it build-depends on; you pass minimal configure flags to the curl udeb build pass, and likewise to the xmlrpc udeb build pass
<slangasek> apw: :)
<cjwatson> (LP is being slow for me today so I haven't actually looked at the branches yet)
<apw> slangasek, your lightdm fixes were they just a change to plymouth-stop.conf ?
<Daviey> cjwatson: Sure, but xmlrpc needs to link against curl.. So *a* curl library needs to be in the build enviroment.  Considering both the minimal and bloated libcurl's provide the same *.so (one with less links), i'm not sure how that can happen?
<slangasek> apw: yep
<cjwatson> I'm going to have to finish soon today, as I'm about to get toddler-supervision responsibility passed to me
<apw> slangasek, and with that in place do you still get a vile white flash from lightdm starting ?
<cjwatson> Daviey: I think it will be easier to demonstrate this than to explain :)
<slangasek> apw: hmm, I don't recall seeing any white flashes - I get plymouth, then a black screen, then lightdm
<Daviey> cjwatson: Okay, are you going to be around later today, or is it a tomorrow thing?
<SpamapS> ahasenack: ok, sponsored into maverick/natty -proposed. I'll let one of my fellow SRU team members ack them in. :)
<cjwatson> the branches there are significantly at variance with how we normally do installer changes, though, so I'm going to have to nack them as they stand
<cjwatson> Daviey: I have a bit longer now, and then expect I'll be around later
<apw> slangasek, ok i am seeing (with waht pitti said was your fix) plymouth, clean handoff to X (cursor etc) then a clear to white, then lightdm shows
<cjwatson> there shouldn't be a -minimal variant as a deb at all
<cjwatson> it should only exist as a udeb
<Daviey> cjwatson: Okay... ignore the end binary for a moment... The issue is that xmlrpc links against curl.. curl normal is rather bloated.
<cjwatson> yes, but it shouldn't matter whether there's a bloated version in the build-dependency tree
<slangasek> apw: right; that's probably an issue with lightdm itself, from the conversation I had with robert_ancell my clear to black and your clear to white may be related
<SpamapS> Daviey: the minimal libcurl has a different ABI?
<Daviey> So we need a minimal version for xmlrpc to link against, right?
<Daviey> I don't see how that can be a ./configure option.
<apw> slangasek, as long as its not my problem and not yours we are good :)
<cjwatson> the minimal version only needs to exist as a udeb
<cjwatson> it does not need to be there when you're building
<slangasek> apw: I believe that's the case :)
<Daviey> cjwatson: But how can something else build depend on a udeb?
<cjwatson> it can't, and doesn't need to
<Daviey> I must be missing something.
<cjwatson> just link it against the regular version - it'll have the same soname
<slangasek> apw: do you know more about the post-grub blinking cursor?
<cjwatson> as long as it only uses symbols present in the udeb variant, it'll all work fine
<Daviey> Hmm, that didn't seem to be the case; perhaps i was mistaken.
<SpamapS> is it maybe just dh_shlibdeps getting confused?
<apw> slangasek, yes that one turns out to be a grub2 regression, get the now fixed grub2 thats publishing like right now and its resolved
<cjwatson> grr, my network is made of CHEESE
<slangasek> apw: ah, woot
<apw> slangasek, i have only the unavoidable black for modeswitch before plymouth and the white splash from lightdm
<apw> slangasek, for me if lightdm is sorted we are back to natty levels
<slangasek> excellent!
<apw> slangasek, but do update grub and repeat my findings ... you need ubuntu3
<slangasek> ack
<smoser> anyone more python friendly than me want to grab bug 810019 merge proposal?
<ubottu> Launchpad bug 810019 in distribute (Ubuntu Oneiric) "UserWarning printed on import pkg_resources'" [Medium,Confirmed] https://launchpad.net/bugs/810019
<smoser> that thing is *really* annoying
<cjwatson> Daviey: it's possible that somebody forgot to do dh_makeshlibs --add-udeb so that the udeb shlibs come out right
<cjwatson> anyway, I'm checking all the stuff out now
<cjwatson> unfortunately upgrading my stepson's machine from lucid to natty at the same time so it's caning the network
<Daviey> cjwatson: I did add a --add-udeb, but perhaps i was missign something.
<tkamppeter> Can someone upload gnome-settings-daemon before beta2 freeze? I have done a fix on it, bug 842768.
<ubottu> Launchpad bug 842768 in gnome-settings-daemon (Ubuntu) "Cups notifies "printer ' xxx ' may be not connected " although printer is OK and printing is OK too" [Medium,Fix committed] https://launchpad.net/bugs/842768
<ahasenack> SpamapS: thanks a lot for the proposed upload
<ScottK> doko: kde-style-skulpture is fixed.
 * cjwatson sends child 1 to look after child 2.  Daviey, I'm working on a revamped curl build now
<cjwatson> cc jamespage
<jamespage> reading backlog now
<Daviey> cjwatson: eek, don't want to get you in trouble.
<cjwatson> s'ok, they're just watching tv until we go to the pub
 * cjwatson <- dubious parent
<cjwatson> (it's a child-friendly pub :-) )
<jamespage> OK - I think I get it - in which case we should be able to revert to Daviey's original package update of xmlrpc-c
<cjwatson> just picking out the bits of the xmlrpc-c change to apply, while curl builds
<jamespage> curl: Drop the minimal-dev and libcurl3-minimal binary packages and just have the new udeb package
<cjwatson> I'll push amended branches to lp
<jamespage> ack
<jamespage> will the xmlrpc-c udeb build look for a libcurl udeb automagically?
<cjwatson> oh, incidentally, it's quite important that the udebs not be Priority: important (I'm fixing that too)
<cjwatson> yes
<cjwatson> well if we set it up properly yes
<jamespage> :-)
<cjwatson> if the udebs are Priority: important, they will be sucked into *every* netboot install
<bdmurray> mterry: do you have any ideas about bug 850744?
<ubottu> Launchpad bug 850744 in quickly (Ubuntu) "quickly crashed with ImportError in __main__: No module named quickly" [High,Confirmed] https://launchpad.net/bugs/850744
<Daviey> cjwatson: Wow.  I've really struggled to find docs on udebs :/
<cjwatson> a good chunk of the X/GTK stack is built like this
<doko> ScottK, thanks
<mterry> bdmurray, I switched to dh_python2 in the latest upload, I may have screwed that up
<bdmurray> mterry: okay, I ask since I just ran into that bug too
<tkamppeter> any core-dev around who can do an upload for me? bug 842768.
<ubottu> Launchpad bug 842768 in gnome-settings-daemon (Ubuntu) "Cups notifies "printer ' xxx ' may be not connected " although printer is OK and printing is OK too" [Medium,Fix committed] https://launchpad.net/bugs/842768
<doko> ScottK:
<doko> $ apt-cache rdepends scribus
<doko> scribus
<doko> Reverse Depends:
<doko>   scribus-template
<doko>  |scribus-template
<doko>   open-font-design-toolkit
<doko>   ezgo-imaging
<doko>   scribus-doc
<doko>   kubuntu-full
<cjwatson> jamespage: just waiting for the test suite now, I should have turned it off
<cjwatson> test 171...OK (170 out of 610, remaining: 21:17)
<doko> is this kubuntu only, or are there other reasons?
<ScottK> doko: Yes.  We ship it on our DVD.
<doko> ScottK, can we exchange this to scribus-ng? builds at least on armel
<jamespage> cjwatson:  x4 runs as well :-)
<ScottK> doko: Last I looked scribus was newer than scribus-ng.  There's a patch in Debian to fix the armel FTBFS that I think micahg was looking at.
<doko> ScottK, which was applied to scribus-ng
<ScottK> Sigh.
<cjwatson> jamespage: damn it.  will be faster to ctrl-c then
<doko> micahg, do you work on this one?
<jamespage> cjwatson: yep
<micahg> ScottK: doko, I didn't say I was working on it, I just pointed out it needed a merge from Debian, I could do it, but not before beta freeze
<ScottK> doko: I'm fine with switching.  I'm making another Kubuntu seed change now, so I'll go ahead and switch it if you or micahg will take get of updating scribus-ng from Debian.
<ScottK> Actually it looks like a sync.
<micahg> ScottK: actually, both of us did that already :)
<ScottK> OK.  rmadison doesn't know it yet.
<micahg> was about 12 hrs ago
<ScottK> doko: Would you please promote scribus-ng and demote scribus then?
<ScottK> OK
<ScottK> doko: Seed changes pushed.  I'll upload a new kubuntu-meta in a moment.
<doko> ScottK, hmm, the change was pushed to both packages
<doko> I'll look at the merge
<ScottK> doko: OK.  I'll wait in the meta upload.  Tell me which one I want.
<jamespage> bdrung: lucene2 built in PPA OK for me with new version of jtidy from Debian - https://launchpad.net/~james-page/+archive/java-universe-oneiric/+build/2786880
<ScottK> doko: Do you know yet which scribus I want?
<doko> ScottK, merging ... building ... uploading ...
<doko> itz kde, so it takes a while ;p
<dobey> doko: have a minute before beta freeze? :)
<ScottK> doko: So I should stick with scribus and not switch to ng?
<ScottK> doko: Actually it's just Qt.  No KDE in it at all.
<doko> ScottK, for now, yes
<doko> dobey, sure
<ScottK> OK.  I'll put it back.
<dobey> doko: jdstrand says https://code.launchpad.net/~dobey/ubuntu/oneiric/ubuntuone-dev-tools/release-020/+merge/75196 needs an FFe, but not clear to me how best to request that. it fixes the FTBFS you filed against it, but there have also been some other changes since the last release. and it's a package in universe that i don't think anyone other than us (u1) uses yet.
<doko> ScottK, ok to recommend icc-profiles-free, or is CD space tight?
<doko> dobey, I can't approve a FFe, but it looks ok.
<doko> slangasek, cjwatson: ^^^
 * cjwatson is slammed
<ScottK> doko: I'd rather not include it.  Looking at making that go away was on my TODO, so if you can handle it, that'd be great.
<doko> ScottK, icc-profiles-free, not icc-profiles ?
<ScottK> dobey: Universe or Main doesn't affect the need for an FFe.
<ScottK> doko: Let me double check.
<cjwatson> Daviey,jamespage: lp:~cjwatson/ubuntu/oneiric/curl/minimal-udeb and lp:~cjwatson/ubuntu/oneiric/xmlrpc-c/udeb
<doko> ScottK, it's main
<dobey> ScottK: i wasn't implying it did. i was asking doko for advice
<cjwatson> Daviey,jamespage: please check that those meet your needs - and I'd appreciate it if Daviey could deal with the upload if they do, since I'm away as of a minute from now
<Daviey> cjwatson: Really appreicate your help with that, will look at it now.
<slangasek> dobey: fwiw the process for requesting an FFe is here: https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze_Exceptions
<slangasek> I'm looking at the changes now
<cjwatson> this produces libxmlrpc-core-c3-0-udeb which Depends: libc6-udeb (>= 2.13), libcurl3-udeb (>= 7.16.2-1)
<ScottK> doko: I was thinking of something else.  We already ship it and it's fine.
<cjwatson> and libcurl3-udeb which Depends: libc6-udeb (>= 2.13), libcrypto1.0.0-udeb (>= 1.0.0), libssl1.0.0-udeb (>= 1.0.0), zlib1g-udeb (>= 1:1.2.3.3.dfsg-1)
<dobey> slangasek: yep, i understand the process. i'm just not sure what the best way to do that is for these changes. seems like doing for each of the bugs which might be considered a feature may be overkill, and an FFe on an FTBFS bug doesn't necessarily make sense to me
<cjwatson> I haven't tried building the cobbler stuff against it; you may need to adjust Build-Depends or something minor, but basically just build-depend on the regular xmlrpc-c stack and it should come out right
<slangasek> dobey: I wouldn't expect a separate bug for each feature, just one for the proposed update
<slangasek> dobey: I am surprised to see all of these changes in a single bzr commit?
<dobey> slangasek: so file a new bug just as '[FFe] upgrade to vblah?' instead?
<dobey> slangasek: they aren't a single bzr commit upstream
<slangasek> dobey: does the UDD branch for this package track the upstream branch?  That would be the ideal...
<dobey> no
<cjwatson> Daviey: gone now - SMS if you need me
<slangasek> dobey: filing a new bug for the FFe is fine, repurposing the FTBFS bug is also fine as far as I'm concerned
<Daviey> It seems to me, that if the ubuntuone team break their dev package, they get to keep the bits. :)
<Daviey> cjwatson: No, i'll wait until you are back.. Go and have fun. :)
<dobey> slangasek: ok
<slangasek> dobey: given that this merge request doesn't appear to include any of the upstream metadata expected by UDD (i.e., the output of 'bzr merge-upstream $newver'), it seems to me that we'd want to not merge this branch as is and just track a debdiff on the bug
<slangasek> dobey: unless you did a bzr merge-upstream and this just doesn't show up in the LP merge view?
<ScottK> doko: Would you please demote digikam to Universe.  It'll be in component mismatches once the current kubuntu-meta is published, but I'd like to get it moved now so we can get the new version in ASAP (it now has non-optional BD on a Universe package (that failed MIR) so demotion is the only solution for Oneiric)
<dobey> slangasek: i don't know how it stores that information; i did bzr merge-upstream --version= ../foo.tar.gz
<slangasek> dobey: ok, let me bypass LP's web UI then and see if I get the right thing using bzr here :)
<cjwatson> Daviey: FFE-wise I'm happy with this change (feel free to quote me on that); it was only the implementation that bugged me ;-)
<cjwatson> Daviey: I can review the debconf interaction once it's in the archive
<dobey> slangasek: i think http://bazaar.launchpad.net/~dobey/ubuntu/oneiric/ubuntuone-dev-tools/release-020/revision/1.1.3 is maybe what you are looking for on LP?
<slangasek> dobey: yep, looks like it - completely undiscoverable from the merge proposal page AFAICS though, heh :)
<Daviey> cjwatson: The debconf stuff is known to be less han perfect.. but i want to at least get /something/ in.
<dobey> slangasek: yeah, you have to go to the branch, then browse the code, and the click on the "(merged from upstream)" link in the metadata area :)
<Daviey> cjwatson: now, go away. Thanks :)
<bdrung> jamespage: thanks
<dobey> slangasek: added FFe bits to bug #848067
<ubottu> Launchpad bug 848067 in ubuntuone-dev-tools (Ubuntu Oneiric) "[FFe] ubuntuone-dev-tools ftbfs in oneiric" [High,Confirmed] https://launchpad.net/bugs/848067
<jamespage> bdrung: did that make sense?  we just need to sort out jtidy one way or the other and lucene2 should be just fine as-is
<bdrung> jamespage: yes
<bdrung> jamespage: do you have time to follow up jtidy and lucene2?
<jamespage> bdrung: yes although I will need a sponsor :-)
<bdrung> jamespage: i am happy to sponsor you once you got the FFe
<bdrung> jamespage: do you have time to track down asm3?
<jamespage> bdrung: jtidy should not need one - its just a packaging update - and so is the sync of lucene2 - we should probably go with a sync of both
<bdrung> jamespage: do you mind not getting the upload credits? then i would use the new sync lp api
<jamespage> bdrung: fine with me :-)
<bdrung> jamespage: the bigger task will be asm3. it has ~ 10 rdeps that needs testing
<jamespage> bdrung: I can't tonight but I can take a look tomorrow morning
<bdrung> jamespage: thanks
<jamespage> bdrung: I just updated bug 841695 with details of the syncs required.
<ubottu> Launchpad bug 841695 in lucene2 (Ubuntu) "FTBFS with jtidy 7+svn20110807-1" [High,In progress] https://launchpad.net/bugs/841695
<jamespage> (for jtidy and lucene2)
<bdrung> jamespage: jtidy synced. i will sync lucene2 once jtidy is built
<jamespage> bdrung: great
<bdrung> jamespage: btw, asm3 builds fine: https://launchpad.net/~eclipse-team/+archive/debian-package
<Daviey> jamespage: what is keeping asmX in main?
<jamespage> Daviey: nothing - I think they are all in universe now
<jamespage> yep - just checked
<Daviey> jamespage: asm3 still seems to be main, and it's not a candidate for demotion.
<Daviey> bah
<Daviey> I was looking in the wrong place.
<jamespage> :-)
<jamespage> bdrung: have you done any reverse-build testing against asm3 yet?
<bdrung> jamespage: no
<jamespage> bdrung: quite a long list - http://paste.ubuntu.com/690250/
<bdrung> sadly, yes
<jamespage> anyway - I said I'll look tomorrow - going to eat....
<stgraber> jamespage: just did a netinstall of oneiric, at least unauthenticaed iscsi root works fine now!
<stgraber> jamespage: though SpamapS change to ifupdown/upstart make the boot time over 2 minutes on iscsi root
<stgraber> (I get "Waiting for network configure..." then "Waiting up to 60 more seconds for network configure..." then finally "Booting system without full network configuration..."
<stgraber> that's because we don't configure any NIC and just keep the configuration from initramfs (ipconfig)
<ScottK> If there's an archive admin around, would you please demote digikam to Universe?
<jamespage> stgraber: great news!
 * jamespage worries about 2 minute wait times
<stgraber> yeah, I'm wondering if I'll see that problem with LTSP too. I should test that as it'd be bad going from 10s to 2 minutes for thin clients
<dobey> jdstrand: ping
<dobey> or any core dev, i guess, ping
<Daviey> dobey: You will have more success if you ask your question, nobody is going to stick their head about the parapit - it might be a hard quetion!
<Daviey> question*
<dobey> Daviey: it's not a question so much. my FFe was approved, and the merge proposal was already approved, so i just need someone to merge it and get my new upload into ubuntu :)
<dobey> Daviey: and jdstrand reviewed the merge proposal, so i thought it apt to ping him, but i guess he's busy
<jdstrand> dobey: I'm not piloting and don't have time atm.
 * jdstrand looks at patch pilot calendar
<jdstrand> dobey: I don't see patch pilots with privs coming online anytime soon
<jdstrand> dobey: that is the 0.2.0 new release?
<dobey> jdstrand: yep
<jdstrand> dobey: if you put the signed package on chinstrap, I'll figure something out today
<mterry> dobey, what's up?
<dobey> mterry: hey. can you merge https://code.launchpad.net/~dobey/ubuntu/oneiric/ubuntuone-dev-tools/release-020/+merge/75196 ?
<mterry> dobey, looking.  (btw, is ubuntuone-installer 0.7.4 going to be uploaded for beta2?)
<dobey> 1.7.4?
<dobey> it is already i thought?
<Daviey> dobey: erm, that package isn't in main, is it?
<mterry> dobey, I only see 1.7.3
<mterry> Daviey, you're right, it's in universe
<dobey> mterry: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/oneiric/ubuntuone-installer/oneiric/revision/6
<dobey> Daviey: no, it's in universe. sorry
<Daviey> mterry: are you taking it?
<mterry> Daviey, I can, sure
<mterry> dobey, sure, it's in bzr, but it's not in the archive
<mterry> dobey, did you dput it?
<jdstrand> I was doing that
 * jdstrand looks
<mterry> jdstrand, doing which?  the ubuntuone-installer?
<jdstrand> yes
<mterry> jdstrand, sweet, thanks
<jdstrand> I reviewed it yesterday and I have an .upload file
 * jdstrand looks around
<mterry> dobey, so you say the FFe is approved?
<dobey> mterry: yes, slangasek approved it
<dobey> mterry: https://bugs.launchpad.net/ubuntu/+source/ubuntuone-dev-tools/+bug/848067/comments/3
<ubottu> Ubuntu bug 848067 in ubuntuone-dev-tools (Ubuntu Oneiric) "[FFe] ubuntuone-dev-tools ftbfs in oneiric" [High,Confirmed]
<Daviey> I'm honestly suprised it's easier to have a package with such a small scope in the archive.
<dobey> Daviey: what do you mean?
<mterry> dobey, during a pbuilder build, I got the following:
<mterry> bin/u1lint:
<mterry>     232:  [W0511] XXX Testing that W0511 does not cause a failure
<mterry> ubuntuone/devtools/reactors/qt4.py:
<mterry>     26:  [F0401, install] Unable to import 'PyQt4.QtGui'
<Daviey> dobey: This package is only for u1 developers, right?
<dobey> Daviey: no
<dobey> mterry: huh
<mterry> dobey, (which stops the build)
<dobey> mterry: right; i just fixed/pushed that in my branch. forgot i needed to add python-qt4 to build-depends for that. sorry :)
 * mterry tries again
<dobey> Daviey: it is useful stuff that anyone can use. particularly useful if you have a python gtk/dbus using app you want to run unit tests on, without screwing with your live system, for example.
<mterry> down to the wire of 21 UTC
<Daviey> dobey: ahhh!
<dobey> Daviey: i literally spent a week trying to think of a better name for it, before giving up and just making the project with that name :)
<mterry> dobey, uploaded
<dobey> mterry: yay. did you see what was up with installer? it looks like it was merged, but not uploaded?
<mterry> dobey, jdstrand sorted it out and uploaded it
<dobey> mterry: ah ok, cool. thanks
<dobey> and on that note, i think it's time to call it a day :)
<dobey> just as the rain and thunder starts upâ¦ :-/
<mterry> dobey, see ya!
<mterry> dobey, happy beta freeze day!
<dobey> mterry: hah, you too!
<jdstrand> I don't know what happened. I had an .upload, but no email confirmation so I just did it again
<jdstrand> sorry about that
<astraljava> Hi all, I added a new branch under ~ubuntustudio-dev team, which is depended upon in our desktop seed. Does that require an FFe because of the new package?
<sladen> ScottK: I love your endless series of OOPs on that +distroseries bug!
* ChanServ changed the topic of #ubuntu-devel to: Beta 2 Freeze | Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
#ubuntu-devel 2011-09-16
<YokoZar> If I remove a binary package with a new source upload, does that require some archive admin tomfoolery?
<YokoZar> (wine1.3 waiting in queue removes ttf-symbol-replacement-wine1.3)
<broder> yes. "NBS" is the magic term you're looking for
<YokoZar> slangasek: What do you think of architecture-dependent header files in /usr/include?
 * YokoZar has now twice encountered -dev packages that have different, incompatible header files on 32/64 bit
<slangasek> YokoZar: well, they're certainly incompatible with multiarch.  http://lists.debian.org/debian-policy/2011/03/msg00151.html
<YokoZar> slangasek: welp, it turns out gstreamer-plugins-base0.10-dev is one such package
<ScottK> sladen: I don't.
 * ScottK would prefer it were just fixed and would stay fixed.
<sladen> ScottK: wuhhh?
<ScottK> sladen: That's a periodic problem that's intermittent.  They fix something, it doesn't time out, they change something else, it happens again.  That's why so many OOP's because it morphs over time.
<sladen> ScottK: ah, gotcha, the dup-notdup-dup-notdup-OOPen
<didrocks> good morning
<dholbach> good morning
 * bryceh waves to dholbach
<dholbach> hey bryceh
 * nigelb waves to bryceh 
<zma> hi, I would like to use apt-get build-dep so that it only loads appropriate header files from debÃ-src repositories. How to do it? I can't use build-dep normally because of faulty dependencies in those packages I work with.
<jamespage> bdrung: 4/29 r-b-d's of asm3 FTBFS with 3.3  - looking now
<jamespage> bdrung: tracking under bug 851659
<ubottu> Launchpad bug 851659 in asm3 (Ubuntu) "[FFE] Sync asm3 3.3.1-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/851659
<raphink> has nobody blogged in 3 days or is planet ubuntu broken?
<jussi> raphink: I think its broken - saw someone say that they had reported it and "it would take a couple of days to fix"
<jussi> [10:05:12] <pleia2> ejat: btw, filed a ticket re: planet, it's still broken :\
<jussi> [10:05:51] <pleia2> they said they'd look at it "within the next few days"
<Laney> :(
<bdrung> jamespage: thanks for tracking them.
<YokoZar> ScottK: Thanks for the early ack, I was gonna get around to making that bug the FFE tonight :)
<jamespage> bdrung: not looking to bad - then I saw eucalyptus-java-common
<jamespage> I don't currently have two spare bits of kit to test euca on with a new version of asm3
<apw> pitti, the current source for work-items stuff references the milestones.project field which is not in our oneiric.db, any idea of the history ?
<apw> pitti, seems to have come in via "merge James Westby's and Chris Johnston's redesign" which has completely changed the interface milestone_list losing its ordering, plus this reliance on a field we do not have
<apw> james_w, ^^
<jdstrand> cjwatson: gparted 0.8.0-1 added a Depends and 0.8.0-2 reduced that to Recommends on gpart (universe) for 'Add attempt data rescue for lost partitions'. Should this be moved to Suggests or should gpart get a MIR?
<cjwatson> I don't know
<cjwatson> at this stage I guess reduce to suggests
<jdstrand> ok, I'll do it real quick
<jdstrand> cjwatson: well, unless you are poking at gparted atm
<cjwatson> I'm not
<cjwatson> I haven't looked at the code to see how badly it fails without it; presumably not very since it's not Depends
<jdstrand> the comment in -2 is 'gpart is not available on all achitectures'
<jdstrand> which at least hints that fails gracefully
<jdstrand> cjwatson: Device/Attempt Data Rescue...
<jdstrand> cjwatson: 'Command gpart was not found
<jdstrand> cjwatson: This feature uses gpart. Please install gpart and try again.'
<jdstrand> yep, graceful
<cjwatson> jdstrand: ok, good
<hallyn> smoser: slangasek: SpamapS: that bug with networking being considered up before dhcp is done, did that get resolved?
<james_w> apw, yep, it's part of the new schema
<apw> james_w, well it seems our DBs are not of the new schema?  is there a migration path
<apw> james_w, also though it changes the semanatic of that routine which was intended to return them in due_date order, which returning a {} does not do any more
<james_w> apw, where are you getting oneiric.db from?
<apw> from ~platform
<james_w> running collect will update the schema as always
<james_w> right, the up to date databases live on status.ubuntu.com now
<slangasek> hallyn: yes
<elleuca> pitti, query?
<hallyn> slangasek: which package was the bug filed against?  I believe bug 850309 in natty is due to that
<ubottu> Launchpad bug 850309 in libvirt (Ubuntu) "libvirt fails to autostart VM attached to a bridged port" [Medium,New] https://launchpad.net/bugs/850309
<slangasek> hallyn: ifupdown
<hallyn> thanks
<apw> slangasek, the fix for the headers ftbs is out on our list for review
<slangasek> apw: cheers :)
<roadmr> hello!
<hallyn> slangasek: something seems to have gone weird with that 0.7~alpha5.1ubuntu4 ifupdown merge.  The 0.7~alpha5.1ubuntu5 one (which wasn't done through a merge request) failed to import, and when I manually try import-dsc, it gives me
<hallyn> bzr: ERROR: Unable to find the tag for the previous upstream version, 0.7~alpha5.1ubuntu4, in the branch: upstream-0.7~alpha5.1ubuntu4. Consider importing it via import-dsc or import-upstream.
<hallyn> smoser: ^ do you have a debdiff for bug 850226 by chance?
<ubottu> Launchpad bug 850226 in ifupdown (Ubuntu) "static-network-up event waits for 'auto' devs without a config stanza" [Medium,Fix released] https://launchpad.net/bugs/850226
<Daviey> hallyn: http://launchpadlibrarian.net/79907784/ifupdown_0.7~alpha5.1ubuntu4_0.7~alpha5.1ubuntu5.diff.gz ?
<hallyn> Daviey: yeah i can reconstruct from that
<hallyn> but not sure how to fix the udd tree :)
<hallyn> Daviey: interestingly, when I did pull-lp-source, it didnt download that diff
<hallyn> Daviey: so where the heck did you find that?
<Daviey> hallyn: on the LP page.
<Daviey> hallyn: https://launchpad.net/ubuntu/+source/ifupdown/0.7~alpha5.1ubuntu5 'Avaliable diffs'
<hallyn> Daviey: thanks!
<Daviey> ofc, LP can spell. i cannot.
<slangasek> hallyn: import-dsc may not work on account of this being a native package; there is no "upstream version"
<hallyn> slangasek: drat :)  thanks
<mterry> dpm, heyo.  I can't seem to log into wp-admin on developer.ubuntu.com now?
<dpm> mterry, hey! hm, perhaps something to do with the fix IS did recently regarding the certificate?
<dpm> mterry, have you tried http://developer.ubuntu.com? (without https)
<mterry> dpm, that tricked it, though the SSO page gave me a warning that the site wasn't recognized by Ubuntu SSO
<dpm> mterry, oh, weird, let me add a comment to the RT regarding that
<jamespage> bdrung: I think I've done as much testing as I can with libasm3-java 3.3.2;
<dpm> but glad you could log in
<cjwatson> slangasek: looking at xdeb, I found your change to disregard multiarch-foreign packages.  However nothing seems to actually take care of installing foreign-arch packages when that's required.  Do you know if anyone has a branch that does that?  In the meantime xdeb is sort of broken
<cjwatson> because if you try to build say any X library package, it ignores the x11proto-*-dev packages because they're multi-arch: foreign, but doesn't install the host-arch versions either
<bdrung> jamespage: thanks
<slangasek> cjwatson: hrrmm, I don't think I ran into that issue
<slangasek> x11proto-*-dev are arch: all as well
<Laney> doko: do you know of a graph showing stats for ftbfs/fixes resulting from your rebuild?
<cjwatson> slangasek: huh
<cjwatson> slangasek: in that case perhaps I have a different problem; trying to cross-build libx*, it was refusing to notice header files in /usr/include/X11/
<doko> Laney, no. rsalveti has one, but only counts the one seen on the production buildds
<Laney> yeah I know of a similar one too
<Laney> never mind
<cr3> skaet: ping, beta freeze question for you: I just noticed that the most recent checkbox package is missing the execute bit on some scripts, is that small enough a change to be acceptable or could it wait until after the freeze?
<skaet> cr3,  thanks for flagging.  Let me check on a few things and get back to you.
<sconklin> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Beta 2 Freeze | Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sconklin
<cjwatson> mvo_: can you give me an update on bug 742935 / bug 781874?
<ubottu> Launchpad bug 742935 in aptdaemon (Ubuntu Natty) "aptd crashed with OSError in release(): [Errno 9] Bad file descriptor" [Undecided,Triaged] https://launchpad.net/bugs/742935
<ubottu> Launchpad bug 781874 in aptdaemon (Ubuntu Natty) "<type 'exceptions.TypeError'>: __init__() takes exactly 2 arguments (1 given)" [High,Triaged] https://launchpad.net/bugs/781874
<cjwatson> in fact there are a few aptdaemon bugs on https://wiki.ubuntu.com/ReleaseTeam/Meeting/2011-09-16#Foundations
<smoser> stgraber, around ?
<stgraber> smoser: yep
<smoser> we're seeing build break of the ubuntu arm cloud images as a result of your change to friendly-recovery
<stgraber> smoser: fixed yesterday
<smoser> oh?
<stgraber> smoser: if that's the update-grub call failing
<smoser> utlemming, stgraber says fixed yesterday
<smoser> was our build failure with 0.2.15  ?
<jamespage> bdrung: please could you review bug 851900 and ack if you are OK with what I have covered
<ubottu> Launchpad bug 851900 in eucalyptus (Ubuntu) "Eucalyptus slow to startup with broken connections to :8443/register" [Undecided,New] https://launchpad.net/bugs/851900
<jamespage> no - not that one
<utlemming> smoser: correct
<stgraber> utlemming: you had it failing with 0.2.15? weird, 0.2.14 was supposed to be the buggy one
<stgraber> utlemming: do you have a build log?
<jamespage> bdrung: sorry - bug 851659
<ubottu> Launchpad bug 851659 in asm3 (Ubuntu) "[FFE] Sync asm3 3.3.2-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/851659
<utlemming> stgraber: yup http://uec-images.ubuntu.com/oneiric/20110916/log.stdout.stderr
<stgraber> utlemming: that's 0.2.14
<smoser> looking at https://launchpadlibrarian.net/80046327/friendly-recovery_0.2.14_0.2.15.diff.gz
<utlemming> stgraber: its at the very bottom, but only for ARMEL images
<stgraber> utlemming: Get:64 http://archive.ubuntu.com/ubuntu/ oneiric/main friendly-recovery all 0.2.14 [7242 B]
<smoser> i'm wondering why we'd hit that codee
<stgraber> fixed in 0.2.15
<smoser> yeah, utlemming that log shows 0.2.14
<utlemming> stgraber, smoser: you're right
<stgraber> smoser: that's the post-inst of friendly-recovery that calls update-grub if it's installed. In your case grub-common is installed but grub isn't. The fix now checks for both /boot/grub/grub.cfg and update-grub, that's how memtest86 does it so that should work for friendly-recovery too
<smoser> stgraber, fwiw, your [ -x $(which update-grub) ] is redundant
 * utlemming kicks another build of the armel images
<smoser> which is not going to show you something htat is not executable
<ahasenack> hi guys, can someone please take a look, and hopefully approve, the smart package sitting in the lucid upload queue? https://launchpad.net/ubuntu/lucid/+queue?queue_state=1
<smoser> and, also, you can do 'which' with 'command -v 2>/dev/null' to be posix sh internal
<smoser> anyway.
<smoser> thanks for fixing stgraber
<ahasenack> hmm, I don't see it in the maverick or natty upload queues
<ahasenack> zul: hi, did you upload smart (#244453) to maverick and natty too?
<zul> ahasenack: no i got delayed with other things ill do it right now
<ahasenack> zul: ah, ok, thanks
<mvo_> cjwatson: I check the release one next, #819328 should be fixed now and 812023 no lnger cause a error (but there reamins some more work to make it really nice and clean)
<cjwatson> mvo_: thanks!
<bdmurray> didrocks: did you test that bug pattern?  it didn't work for me
<didrocks> bdmurray: it's my first addition to the bug pattern, so I maybe screwed something, I looked at the wiki page though
<bdmurray> didrocks: there is a script in the bugpatterns branch for testing the pattern called test-local and that'll run the bug pattern against a specific bug
<bdmurray> didrocks: e.g. ./test-local 851169
<bdmurray> didrocks: I've pushed a fix.  Which wiki page was that by the way?
<didrocks> bdmurray: oh? I didn't know about the fix, the wiki page is at: https://wiki.ubuntu.com/Apport/DeveloperHowTo#Bug_patterns
<didrocks> bdmurray: thanks for the fix!
<bdmurray> didrocks: no problem, I'll update that wiki page with info about testing them then
<didrocks> bdmurray: yeah, that would be handful! thanks :)
<zul> ahasenack: done
<ahasenack> zul: thanks, so now someone else needs to approve it?
<zul> ahasenack: yep
<bdrung> jamespage: ack, we have to wait for the release team to review it
<bdrung> jamespage: http://bazaar.launchpad.net/~james-page/ubuntu/oneiric/jenkins/ftbfs-asm3.3/revision/4 -> why do you change the "Forma of this file is" line?
<jamespage> bdrung: because I can't use vim by the looks of things - that is a mistake
<jamespage> lemme just fix that
<micahg> multiarch broke?
<infinity> Archive skew, I assume.
<infinity>    libgcc1 | 1:4.6.1-9ubuntu2 |       oneiric | armel, i386, powerpc
<infinity>    libgcc1 | 1:4.6.1-9ubuntu3 |       oneiric | amd64
<infinity> micahg: ^--- When that shakes out, life will be good again.
<micahg> infinity: ok, figured as much, thanks
 * micahg wonders why some symlinks in ia32-libs adds 17.8MB to the binary size
<infinity> *raise brow*
<micahg> err, add 4.9MB to the binary, 17.8 to the installed size
<infinity> Without looking at the change, I'd be inclined to go with the general Internet wisdom of "ur doin it wrong".
 * micahg is just an observer in this case...
<micahg> YokoZar: ^^
<infinity> micahg: Did you miss the "- Also add libllvm2.9" part?
<micahg> infinity: yeah, that must be it :(
<micahg> YokoZar: nevermind
<infinity> micahg: Yeah, that's definitely it.  llvm is huge.
<infinity> It's also multiarched, so I'm not sure why it's in ia32-libs...
<infinity> YokoZar: What was the rationale for adding llvm to ia32-libs?
<slangasek> infinity: dependency of some of the mesa backends.
<slangasek> I was content to leave them broken, YokoZar seemingly less so
<infinity> slangasek: Irksome.  So not really fixable until mesa is also multiarched, I guess.
<infinity> Except... It is.
<infinity> But I suppose we still need lib32 insanity there for hysterical raisins.
<slangasek> infinity: it's all needed because of other libraries farther up the chain that aren't multiarched; the handful of packages that still have to be installed with ia32-libs should be dependency-complete on amd64, since we can't make ia32-libs Depends: libgl1-mesa:i386
<slangasek> but then, "fixing" libGL in the latest upload has regressed some binary-only software that was happier when it couldn't find it ;) (bug #851947)
<ubottu> Launchpad bug 851947 in ia32-libs (Ubuntu) "/usr/lib32/libGL.so.1 prevents Doom 3 from starting" [Undecided,New] https://launchpad.net/bugs/851947
<infinity> slangasek: Fun bug.  I assume that's a bad interaction with a binary driver or some such.  They used to dpkg-divert those paths.
<infinity> Maybe it's time to install the non-free nvidia driver and try to play Doom.
<Chipzz> infinity: with the added bonus of loosing some frustration. or was that the whole point to begin with? ;)
<infinity> Chipzz: I can play video games with nouveau these days (we've come a long way!), so the frustration vector with the non-free driver is entirely in the wrong direction.
<slangasek> infinity: well, we don't use dpkg-divert anymore, but update-alternatives :)
<slangasek> so if ia32-libs is now installing libGL to /usr/lib32, that could well be the problem, because the alternatives are meant to operate on ld.so.conf.d
<infinity> slangasek: Yeah, that's almost certainly the problem, if none of that's been looked at since dpkg-divert was given the boot from the binary drivers.
<slangasek> mvo_: still around?  Would you be willing to also install cryptsetup to test that case on bug #849954?
<ubottu> Launchpad bug 849954 in plymouth (Ubuntu Oneiric) "FFe: enable flicker-free boot with lightdm" [Medium,Incomplete] https://launchpad.net/bugs/849954
<slangasek> mvo_: you don't need to use cryptsetup, just have it installed
<Daviey> RoAkSoAx: How does testdrive know about the current candidate?
<Daviey> Does it use, http://iso.qa.ubuntu.com/qatracker/dllist ?
<i0n> is there anywhere I can find out what ./configure options the apache2 maintainer used when packaging httpd?
<slangasek> i0n: download the source package and look at it?
<slangasek> apw: do you know if there's a reason why udev's udev-fallback-graphics job and plymouth-splash/lightdm/gdm have duplicate checks for graphics-device-added and drm-device-added events?  It seems to me that they should really only be checked in one place or the other
<i0n> slangasek: i did, ive busted it open and looking at it im not finding how it assigns the install directories.. In src/debian there are some files like apache2.2-bin.dirs which look right, but im having a hard time seeing where they are called.
<slangasek> i.e., either udev-fallback-graphics should be emitted only when we *don't* get one of the other events, or we should check for that event exclusively rather than checking for it as well as the -device-added events
<slangasek> i0n: debian/rules is the makefile that controls package building.  You could also look at the build log in launchpad, which would show all the command output
<i0n> slangasek: thanks, im new to packaging on this level.
<i0n> slangasek: is there a dpkg command way to grab the source?
<slangasek> i0n: 'apt-get source <package>'
<i0n> hmm i copied the debian/ directory into the new apache source
<zul> barry: for the dh_python2 transition does it matter if the python version is 2.6.6-3
<barry> zul: 2.6.6-3~ specifically
<zul> barry: how come?
<Daviey> That is why dh_python2 support was added, wasn't it?
<Daviey> s/why/when
<mtaylor> sorry - just joined - can someone paste me the bit of this that I missed?
<barry> zul: python-defaults (2.6.6-3) unstable; urgency=low
<barry>  
<barry>   * Upload to unstable
<barry>   * dh_python2: egg renaming fixed
<barry>  
<barry>  -- Piotr OÅ¼arowski <piotr@debian.org>  Wed, 22 Sep 2010 23:03:15 +0200
<barry>  
<zul> barry: ah ok
<barry> zul: np!
<Daviey> Does anyone have thoughts on http://paste.ubuntu.com/691015/ (line 442), having difernet behaviour based on lsb_release output seems fugly to me..
 * mtaylor agrees with Daviey - would love a better solution - but would prefer fugly to no solution
<mtaylor> Daviey: I suppose I _could_ test for the existence of dh_python2...
<Daviey> mtaylor: I'm not convinced debian/rules should handle backports in the main stamp, at least.
<Daviey> Is it really unreasonable to run an extra script?
<mtaylor> Daviey: I understand
<mtaylor> I would HIGHLY prefer not to
<slangasek> IMHO this is why we have VCSes that let us cheaply manage different branches for each release, but YMMV :)
<infinity> Daviey: Different behaviour based on lsb_release is pretty common.
<slangasek> infinity: yes, but generally only for Ubuntu vs. Debian, not lucid/maverick vs. natty+
<Daviey> infinity: example?
<Daviey> Ahh, yes - seen that for upstart vs init.d
<micahg> slangasek: not true, we do it in the Mozilla products
<mtaylor> Daviey: how about this insteaD:
<mtaylor> WITH_PYTHON2 = $(shell test -f /usr/bin/dh_python2 && echo "--with python2")
<infinity> slangasek: Looked at the GCC makefiles lately?
<micahg> slangasek: I take that back, Mozilla is an exception to everything :)
<slangasek> mtaylor, Daviey: we are meant to be backporting dh_python2 for use with lucid and maverick via -updates or -backports yet this cycle; would it perhaps be sufficient to assume dh_python2 availability?
<mtaylor> slangasek: that's been part of the assumption ... but we're trying to release openstack diablo
<slangasek> infinity: yes, and gcc is the exception that proves the rule... :)
<infinity> slangasek: Perhaps. :P
<mtaylor> slangasek: and I currently cannot build packages for lucid
<slangasek> mtaylor: right
<ScottK> That's because no one finished the backport yet.
<ScottK> Someone should do that.
<Daviey> mtaylor: whey not wrap your package building with, [ -a debian/backports/$(lsb_release -c | awk '{ print $2 }') ] debian/backports/$(lsb_release -c | awk '{ print $2 }')
<Daviey> so run a backport script if it exists?
<mtaylor> slangasek: also - I'm not personally convinced about asking someone who adds ppa:nova-core/ppa to also add backports
<infinity> I see no particular issues with debian/rules being backport-friendly...
<ScottK> mtaylor: The intent is to put it in -updates.
<mtaylor> Daviey: why is that better/more desirable? that requires wrapper scripts
<slangasek> doko: ^^ barry mentioned that you have a tentative dh_python2 backport branch; is it in a state worth sharing with mtaylor?
<mtaylor> slangasek: yeah - if that was something I could pop into my ppa, that would make me very happy
<Daviey> mtaylor: i assumed you already had a script?
<mtaylor> Daviey: there is currently a script, but every line that exists in it is a bug imo
<barry> i'm also happy to take over doko's branch if it would help
<mtaylor> Daviey: you will find that I come from the "defaults should do sensible things" camp and find wrapper scripts to be hacks that indicate underlying system bugs
 * mtaylor would also be more than happy to help on doko's branch ... certainly not opposed to pitching in here :)
<Daviey> mtaylor: and WITH_PYTHON2 = $(shell lsb_release -c | perl -nle '/lucid|maverick/ && print "--with python2"') , isn't a hack!?
<doko> no branch. I'll try to push this out this weekend
<dobey> does a release team member still need to approve freeze exception on bug #850142 ? it has +1 from docs and translations
<ubottu> Launchpad bug 850142 in Ubuntu One Control Panel "UI Freeze exception: Remove the Bookmarks section from the Services tab" [High,In progress] https://launchpad.net/bugs/850142
<SpamapS> If the goal of the branch is to build on lucid -> current .. then it should just handle this in debian/rules by choosing whichever is available. How is that not working already with just 'dh' ?
<mtaylor> in any case - I expect someone to be able to pull a packaging branch and build a package using standard toolchains and not have to know about additional scripts that must be run in order to enable that
<dobey> SpamapS: dh doesn't default to python2 in anything yet. it defaults to python-support
<SpamapS> Is there some reason we can't just let it build with python-support ?
<cr3> skaet: any updates on the flag I raised earlier about checkbox and file permissions?
<dobey> SpamapS: too simple? ;)
<skaet> cr3,  yes, sorry.  its fine.  go ahead.
<SpamapS> its still in main
<infinity> Daviey: It's not much worse than old debian/rules files that use to do "test -x /usr/bin/dh_foo && dh_foo", which was a very common practice.
<SpamapS> this doesn't go on any CDs
<dobey> SpamapS: the fun part is if you are shipping a twisted plugin or something
<infinity> Daviey: Again, I don't see why you're annoyed with a backport-friendly rules file.
<SpamapS> I would be pretty surprised if nova/glance/swift had twisted plugins embedded. :)
<barry> doko: awesome, thanks!
<dobey> SpamapS: well anything similar to that. twisted is an example i saw problems with, because it uses python-central on lucid, but not on maverick+
<Daviey> infinity: I'm not annoyed, it just seems messy to support X releases with one rules file.
<barry> the main reason to backport dh_python2 is so that people can also back port oneiric/debian versions of converted packages more easily
<SpamapS> Daviey: what is the reasoning behind forcing dh_python2?
<infinity> Daviey: Honestly, I prefer it.
<mtaylor> Daviey: depends on from which perspective... NOT supporting X releases with one rules file is messy from an upstream perspective
<dobey> Daviey: i'd rather have 1 rules file, even if i have to do funky stuff to generate control from control.in and such, rather than N rules/control files, from the perspective of maintaining daily builds on N releases
<mtaylor> ++
<Daviey> mtaylor: I dunno, having a backport script seems to be cleaner to me.. easier to maintain, and a tidier rules file.  I guess that is preference.
<micahg> openjdk also uses one rules file for multiple releases
<Daviey> I've seen the script to mangle the package in a few areas.
<Daviey> It also allows you to mangle to control file etc.
<SpamapS> Whats tidier than a dh7 rules file with no arguments? :)
<mtaylor> now that's the tidiest!
<dobey> SpamapS: an empty rules files ;)
 * SpamapS got told
<mtaylor> dobey: ++
<SpamapS> ;)
 * infinity fears we've now abstracted so far that people find a 3-line rules file ugly, when a 1-line one would have sufficed if there wasn't that "icky 2-line hack".
<barry> yeah, unfortunately, even with dhpy2, you still can't quite get to a 3-liner
<SpamapS> infinity: ROFL
 * mtaylor has many packages that had 3 line dh rules files and worked just fine... turns out if upstream behaves itself ... :)
<dobey> if people would just stop writing new code, it would be easy
<mvo_> slangasek: re 849954 - sure I can do that
<slangasek> mvo_: thankee :)
<barry> mtaylor: yep.  more goo comes in when you want to run the test suite for multiple versions, have rest docs to build, etc.
<mtaylor> barry: TOTALLY
<barry> mtaylor: well, now that i passed pox's muster on my own packages, i'm going to look into fixing those problems.  eg. debbug 641314
<Daviey> mtaylor: note, that using the mangling method would have removed all the pain you have been experiencing trying to get one debian/ for all releases
 * YokoZar thought he removed the wine1.0 package last cycle...
<mtaylor> Daviey: there are many things that would have removed all of the pain I'm experiencing. I'm guessing we probably don't want to explore them all right now :)
<dobey> slangasek: can one of you give release team ok on bug #850142 ? it has OKs from docs/i18n
<ubottu> Launchpad bug 850142 in Ubuntu One Control Panel "UI Freeze exception: Remove the Bookmarks section from the Services tab" [High,In progress] https://launchpad.net/bugs/850142
<YokoZar> Say I'm removing wine1.0, can I: 1) Straight up have archive delete it, 2) Convert it into a dummy package depending on wine1.2, or 3) Delete it and ask update-manager to transition users?
<mvo_> YokoZar: I think (2) is best
<Daviey> mtaylor: Well if you think it helps the discussion..
<mvo_> YokoZar: hello btw
<infinity> YokoZar: Having update-managet do it is something we do when you fail to do (2) correctly.  It shouldn't be the default option. :P
<mtaylor> Daviey: nah. I doubt it would be useful in any way right now
<YokoZar> mvo_: Hey there :)
<YokoZar> infinity: Yes, the downside is this means it takes 2 LTS cycles to completely remove a package since you need the first to transition users and the second to breaks/replaces it
<infinity> YokoZar: However, you should probably produce the transitional metapackages from the 1.2 or 1.3 source, and just delete the 1.0 source completely.
<YokoZar> infinity: yes, of course
<Daviey> mtaylor: well best not say it then :)
<mtaylor> done!
<YokoZar> mvo_: Does software center still display dummy packages?
<infinity> YokoZar: Eh?  You can break/replace right now, it should just be versioned.
<mvo_> yes, but that is probably something we should fix (that it displays dummy packages)
<infinity> YokoZar: And then after the next LTS, you just silently drop the transitional package.
<infinity> mvo_: Filtering out "transitional" in descriptions would probably catch most of them.
<infinity> mvo_: Curious if there are any false positives in that list, though.
<RoAkSoAx> Daviey: nope not at the moment
<RoAkSoAx> Daviey: when I did that the dllist stuff wasn't yet being generated, but thanks for reminding me about that
<mvo_> infinity: yeah, I will check that out
<Daviey> RoAkSoAx: how are you doing it atm?
<RoAkSoAx> Daviey: (status, output) = commands.getstatusoutput("wget -q -O- http://iso.qa.ubuntu.com/qatracker | egrep 'iso.qa.ubuntu.com/qatracker/test'")
<Daviey> RoAkSoAx: awesome :)
<RoAkSoAx> Daviey: ;)
<SpamapS> damnit.. just figured out my Canon printer has been DoS'ing my wifi for the last day with mDNS.. no wonder network has been crap.
<YokoZar> infinity: I meant breaks/replace a non-versioned one and have no binary dummy in the archive.  Takes two LTS for that :(
<YokoZar> Not that I should be particularly concerned about binary dummys...
<infinity> Nope, still just the one.
<infinity> YokoZar: The trick, if your foo1.0 package is produced from foo1.2 sources is to have your Breaks/Replaces on << Source-Version, and then when you drop the transitional package (in the release after the LTS), you just change that Breaks to a Conflicts, and poof it goes away.
<YokoZar> Err ok 2 releases not 2 LTS releases
<YokoZar> (one of which is an LTS though)
<nigelb> SpamapS: In honor of the awesomeness http://c0016417.cdn2.cloudfiles.rackspacecloud.com/353omj.jpg
<infinity> YokoZar: I don't see a problem with that. :P
<micahg> infinity: YokoZar don't forget about removing the version when converting to conflicts :)
<infinity> micahg: Actually, the versioning still works in that case.  But sure, it's also correct to remove it. :P
<micahg> infinity: I've been told versioned conflicts does bad things to apt
<slangasek> correct
<slangasek> you should use versioned breaks+replaces, or unversioned conflicts+replaces, per Policy
<infinity> I suspect that depends on what it's trying to resolve.
<slangasek> other combinations are Nearly Always Wrong
<infinity> slangasek: Well, yes.  That policy is sane because it accidentally describes what Breaks and Conflicts are semantically meant to do.
<infinity> But from a "will it break" perspective, a versioned Conflict+Replace won't behave any worse than a versioned Break+Replace, it's just not quite correct.
<infinity> (But when the version spec ends up matching "every version ever", it's ultimately the same as unversioned)
<slangasek> no, a versioned Conflicts+Replaces *does* behave worse than a versioned Breaks+Replace
<slangasek> Breaks --> deconfigure before continuing, Conflicts --> remove or upgrade before continuing
<slangasek> very different impact on the resolver
<infinity> slangasek: In the above case?  Unless someone broke something in apt, I fail to see how it could.
<infinity> But yes, in many cases, fair enough.
<dobey> SpamapS: i don't even have my printer plugged in to ac power unless i need to use it for something
<SpamapS> nigelb: :-D
<nigelb> :)
<micahg> can we recommend from multiverse to partner since if partner isn't enabled, it should just ignore it?
<dobey> hrmm
<ScottK> micahg: You can.
<ScottK> The only requirement for multiverse is that it be legally distributable.
<micahg> ScottK: ok, thanks
<ScottK> It doesn't even have to be installable.
<cr3> skaet: regarding the flag I raised earlier, roadmr reported bug #852138 with the corresponding merge request
<ubottu> Launchpad bug 852138 in checkbox (Ubuntu) "Some files under scripts/ lack executable permission" [Undecided,New] https://launchpad.net/bugs/852138
<m4n1sh> doko: ping
<mtaylor> kirkland: ping
<kirkland> mtaylor: yo
<sconklin> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Beta 2 Freeze | Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
#ubuntu-devel 2011-09-17
<Kano> hi cjwatson
<sveinse> I remember finding a meta package which contains a lot of scripts and utilities for building deb packages, but I don't remember its name. Anyone who do?
<sveinse> found it: devscripts
<jtaylor> there is also packaging-dev and ubuntu-dev-tools
<shbk> i want to find out how many keys my keyboard has.  i have tried lshw , lspci,  hwinfo, sysinfo,hardinfo.  i am planning if this bash function to use it in c++ via   system() call, afterward receive output, parse it and take what i needed. i 've  almost all info about system which is needed.  but I'm confused with keyboard. how can i do this in c++ or bash?
<astraljava> Hello folks, I recently added a new bzr branch for a package (lightdm-theme) for our team, ~ubuntustudio-dev. We'd like to include it in oneiric, still. Does it need an FFe?
<SpamapS> astraljava: yes you will need to file a FFE, https://wiki.ubuntu.com/FreezeExceptionProcess
<astraljava> SpamapS: Thanks!
<astraljava> LP bug #852623, will it do?
<ubottu> Launchpad bug 852623 in Ubuntu Studio "[FFe] Please upload ubuntustudio-lightdm-theme for oneiric" [Undecided,New] https://launchpad.net/bugs/852623
<SpamapS> astraljava: it needs t be a bug in *Ubuntu*
<s1aden> SpamapS: astraljava: changed
<SpamapS> astraljava: also the process page I linked to has some files that it wants you to attach... since its a new package.. the whole source package would need to be attached (a debdiff doesn't make sense ;)
<astraljava> slangasek: SpamapS: Okay, thanks for your work! I am a little puzzled, though. Why does it affect ubuntu, when it's totally isolated to our flavor?
<astraljava> Oops, should have been sladen, sorry about that.
<astraljava> Eerr... s1aden. :)
<ScottK> astraljava: Ubuntu the project, not Ubuntu the desktop.
<ScottK> It's all in the same package archive.
<astraljava> ScottK: Oh, gotcha. Thanks!
<nikola> any pulseaudio devs around here?
<nikola> i have problem in oneiric
<nikola> i filed a bug here: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/852915
<ubottu> Ubuntu bug 852915 in pulseaudio (Ubuntu) "No sound after plugging in external speakers" [Undecided,New]
#ubuntu-devel 2011-09-18
<calc> anyone happen to know why curl in natty claims to support https in the package description but when you run it on the command line it says it does not support https?
<doko> ScottK, kde/kubuntu review? dvr ftbfs
<doko> ScottK, dovecot-metadata-plugin ftbfs
<doko> and if you are interested in dovecot, dovecot-antispam
<Rovanion> Is wine broken in 11.10 as of now? Seems like there are missing dependencies
<charlie-tca> bug 852835 blocks all use of software center in Xubuntu
<ubottu> Launchpad bug 852835 in software-center (Ubuntu) "software-center crashed with TypeError in _parse_menu_tag(): 'NoneType' object is not iterable" [High,Triaged] https://launchpad.net/bugs/852835
<charlie-tca> well, software center in Oneiric, at least
<broder> did oneiric break cd tray locking for anybody else?
<soreau> Hi guys, a new version of a package was just released. How can I file a request that there's an update for it in 11.10?
<soreau> It's just a game
<broder> soreau: you need to go through the FFE process
<broder> !ffe
<ubottu> Feature Freeze Exception. See https://wiki.ubuntu.com/FreezeExceptionProcess for the freeze exception process.
<soreau> broder: Well I was kinda meaning that I wanted to request the update for the typical package updates
<soreau> or how does that work?
<charlie-tca> soreau: too late for Oneiric that way. It will sync in P, if it is updated in Debian.
<soreau> charlie-tca: ok
<soreau> Is there an easy way to create packages for 32 and 64 bit from a source repository?
<broder> soreau: multiarch!
<broder> err wait, that might not actually be what you're asking
<soreau> !multiarch
<soreau> broder: ie. I'
<soreau> erm..
<broder> soreau: are you trying to create both arch: i386 and arch: amd64 packages at the same time, or are you trying to create, e.g., an amd64 package with i386 binaries in it?
<soreau> broder: ie. I do not have 64bit system available but I wanted to know if there's some way to still create packages for both 32 and 64 bit
<soreau> broder: The former
<broder> i don't think there's any way to do a 64-bit build without having at least a 64-bit kernel (you can always get the 64-bit userspace in a chroot)
<broder> ppa builders?
<soreau> broder: I was thinking maybe there's some server setup for this purpose, in a snadbox type environment
<soreau> sandbox*
<broder> soreau: like PPAs?
<soreau> broder: I don't really know how ppa's work
<soreau> I just wanted to create packages, not a ppa
<broder> well, ppas hold packages
<soreau> broder: Right, I want to build the packages, not create a package container
<broder> soreau: a PPA is an apt repository. it contains packages
<jtaylor> ppas also build packages for i386 and amd64
<broder> you can build the packages into a ppa, and then download them
<soreau> There's no way to do it without creating a ppa?
<jtaylor> a virtual machine might work
<soreau> jtaylor: How would a vm help?
<jtaylor> maybe some vm's can emulate amd64 on i386
<jtaylor> but maybe also not, haven't owned a 32 bit machine for avery long time :/
<soreau> maybe?
<soreau> well I'm looking for answers, not guesses ;)
<dtchen> (yes, at least vmware can.)
<broder> only if you have VT-x
<dtchen> I'm pretty certain my older laptop didn't have VT-x, but I don't have it handy to confirm
<soreau> broder: VT-x?
<broder> hardware virtualization
<soreau> So the easiest way is to just setup a ppa?
<broder> dtchen: under binary translation, vmware uses memory segmentation to isolate the guest from accessing host memory, and x86_64 screwed up segmentation enough that they can't do it for 64-bit guests
<broder> </virtualization_nerd>
<cjwatson> your choices are (a) have a 64-bit system already (b) get access to one (for this purpose, the PPA system is a convenient way to do that) (c) virtualise one somehow (d) cross-compile (a process which in principle is possible here but it will start with building an i386->amd64 cross-toolchain and then you'll have to experiment with tools and even then it might not work)
#ubuntu-devel 2012-09-10
<GTRsdk> Can program names be asked for in here?
<GTRsdk> If so... What programs are required to make the Printing app work the way it does (with the click to find network printers, and easy setup)?
<pitti> Good morning
<pitti> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #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
<dholbach> good morning
<ion> morning
<pitti> tkamppeter_: good morning
<pitti> tkamppeter_: can you please also forward the libusb1.0 debdiffs to Debian BTS?
<pitti> tkamppeter_: (bug 918774)
<ubottu> Launchpad bug 918774 in sane-backends (Ubuntu) "Migrate sane-backends to libusb 1.0.x" [Medium,New] https://launchpad.net/bugs/918774
<pitti> tkamppeter_: oh, these weren't your patches, nevermind; I'll forward them
<dholbach> can somebody please reject https://code.launchpad.net/~ianrob1201/ubuntu/quantal/libmoosex-semiaffordanceaccessor-perl/typo-fix/+merge/122370?
<pitti> dholbach: done
<dholbach> thanks pitti
<alkisg> pitti: hi, re: LP bug #1048207, the proposed patch works, but the script is indeed a bit unreadable wrt variables names, if you prefer I can rewrite it a bit so that it doesn't use temp files etc
<ubottu> Launchpad bug 1048207 in ubuntu-defaults-builder (Ubuntu) ""el complete" in langpacks.txt breaks build" [Undecided,Confirmed] https://launchpad.net/bugs/1048207
<pitti> alkisg: oh sorry, I mis-read it
<pitti> alkisg: I'll apply it soon, thanks!
<alkisg> Thank you too :)
<alkisg> Btw, ubiquity-dm breaks the keyboard layout for all languages that support multiple keyboard layouts. That affects all live CDs, I've seen it reported under multiple packages in LP, but I didn't see anyone working on it. I can invest some time to troubleshoot it if someone knowledgable about ubiquity can point me to the right direction. LP bug #975803, comment 5
<ubottu> Launchpad bug 975803 in ubuntu-defaults-builder (Ubuntu) "ubuntu-defaults-builder: setting language automatically results in non-standard keyboard layout" [Undecided,Confirmed] https://launchpad.net/bugs/975803
<alkisg> If I "maybe-ubiquity" is omitted from the kernel command line, then the keyboard layout is fine, both in custom live CDs and in the official one
<alkisg> That's pretty serious, as e.g. if someone wants to install ubuntu in greek now, he can't type english letters in the installer (username etc)
 * dholbach hugs pitti
 * pitti hugs dholbach back :)
<cjwatson> pitti: heads-up on bug 1048211, breaking all images - if you'd be so kind
<ubottu> Launchpad bug 1048211 in udisks2 (Ubuntu) "ubiquity-dm crash" [Undecided,New] https://launchpad.net/bugs/1048211
<pitti> cjwatson: whoops, will do; sorry about that
<cjwatson> thanks
<cjwatson> perhaps we could get it into Ubuntu first without waiting for the sync process to catch up, and then we can respin images?
<pitti> sure, I can upload a -6git1 or so
<cjwatson> ta
<pitti> I'll be done with my current sponsoring task in < 1 min, then will get to this
<pitti> cjwatson: uploaded; I'll need to do two more fixes anyway (tests uncover some bugs in xfsprogs and reiserfsprogs), so I'll do a proper -5 soon
<cjwatson> OK, thanks
<pitti> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #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:
<brendand> does anyone know where the tool 'rendercheck' is packaged?
<brendand> for precise preferably
<pitti> x11-apps: /usr/bin/rendercheck
<pitti> brendand: command-not-found is your friend? :-)
<brendand> pitti - yeah, but i have x11-apps installed and when  i try to run rendercheck, command-not-found doesn't help me out
<pitti> "dpkg -S rendercheck" then
<brendand> nothing
<pitti> that searches packages for installed files
<pitti> then it might be new in quantal, perhaps
<brendand> that's what i'm going to suspect
<cjwatson> brendand: packages.ubuntu.com can do per-series file lookups
<Laney> did we get all of the fontconfig warnings? anyone still getting them?
<pitti> Laney: I just sponsored a patch for fonts-arphic-uming an hour or so ago; the bug still had one open task
 * mlankhorst is back!
<pitti> bug 1034928
<ubottu> Launchpad bug 1034928 in fonts-sil-andika (Ubuntu) "Fontconfig warning: Having multiple values in <test> isn't supported and may not works as expected" [Undecided,Confirmed] https://launchpad.net/bugs/1034928
<Laney> pitti: yeah, I'm looking at that
<pitti> for me they are gone, though
<Laney> I see they're all closed, just making sure the bug had all of the required tasks
<Laney> same
<cjwatson> I'm seeing them from 25-wqy-zenhei, 90-fonts-baekmuk, and 90-fonts-unfonts-extra still, as well as *-arphic-uming
<pitti> the last one should be fixed now
<Laney> i'll add tasks for those first three, cheers
<xnox> Laney: i thought unfonts-extra were fixed together with unfonts
<Laney> maybe so
<Laney> but maybe not if people are still seeing the messages
<xnox> Laney: atk-bridge warning from gtk is annoying.....
<Laney> hmm?
<xnox> Laney: Gtk-Message: Not loading module "atk-bridge": The functionality is provided by GTK natively. Please try to not load it.
<Laney> never seen that
<Laney> what does it come from?
<xnox> Laney: any gtk app. Close all nautilus windows & run `xdg-open ~' from terminal....
<xnox> Laney: yeap unfonts-extra still not fixed, line 16 =(
<Laney> nope
<xnox> I wonder if I have a11y enabled then somehow for something and hence I get that.
<xnox> Laney: google search suggests that I am not the only one with that message
<Laney> you're never alone when it comes to warnings
 * xnox rather wishes I was never alone when it comes to relationships..... *sigh*
<cjwatson> cyphermox: I rebuilt tracker for something unrelated and got stuff like https://launchpadlibrarian.net/115371900/buildlog_ubuntu-quantal-i386.tracker_0.14.1-1ubuntu3_FAILEDTOBUILD.txt.gz - do you think you could fix it up?
<Andy80> hi all!
<Andy80> dholbach: hi! Why did you remove so precious informations from this page https://wiki.ubuntu.com/UbuntuDevelopment/BugFixingInitiative ? Luckly there is the history available https://wiki.ubuntu.com/UbuntuDevelopment/BugFixingInitiative?action=recall&rev=48 you completly removed all info about branching/committing/pushing etc... :(
<mpt> ev, though we may not easily be able to calculate "If all updates were installed", we could calculate the distribution of "How many days out of date (if at all) is the package each error occurred in"
<lifeless> ev: btw, wgrants fix has deployed, so it shold be a lot faster now.
<ev> lifeless: indeed, caught that this morning. Thanks to the both of you!
<ev> mpt: I'm not seeing how they're related
<mpt> ev, it would be a rough approximation of how quickly people install updates (though it would assume that updates don't reduce the error rate, which is hopefully a bad assumption)
<dholbach> Andy80, I wanted to have them in here http://developer.ubuntu.com/packaging/html/fixing-a-bug-example.html - we almost ran out of description typo bugs
<dholbach> Andy80, the rest were in packages which are very likely to be removed
<dholbach> (unless you are going to be fix typos in descriptions of packages which are in Debian)
<dholbach> Andy80, ideally we'd have all the "here's how you work the tools" bits and general explanation in the packaging guide and just what is specific to the bug fix, like "fix the typo" on the wiki page
<dholbach> so we don't duplicate too much
<ev> mpt: sounds reasonably straightforward. Are you still going to send that email to -tech asking for more ideas, or are you settled on this?
<mpt> ev, no, not settled at all
<ev> okay
<mpt> just thinking idly
<ev> sure
<cyphermox> cjwatson: sure, I'll take a look.
<cjwatson> thanks
<didrocks> can anyone mark https://code.launchpad.net/~bcurtiswx/ubuntu/precise/telepathy-glib/0.18.2-0ubuntu1/+merge/117176 as rejected? (was not against -proposed)
<stgraber> didrocks: done
<didrocks> stgraber: thanks :)
<pitti> didrocks: it can't -- there is no -proposed version of telepathy-glib yet
<pitti> UDD doesn't work like that for SRUs
<pitti> didrocks: so for sponsoring you'd checkout the precise branch, do the merge, prepare/build source package, but NOT push
<didrocks> ah, interestingâ¦ so it's a bootstrapping issue basically :)
<didrocks> hum, I've already pushed TBH
<pitti> and let the package importer sort it out
<didrocks> ah you mean
<pitti> didrocks: then perhaps please uncommit and push --overwrite
<didrocks> not the branch
<didrocks> yeah
<didrocks> will do that I think
<pitti> didrocks: yes, push to the precise branch, I mean
<pitti> personally, I prefer simple debdiffs for SRU sponsoring any day..
<cjwatson> Yeah, saves on thinking
<micahg> well, saves on thinking only if there's a non UDD Vcs-Bzr
<micahg> *there'a not a
<cjwatson> Which chances are would point to the development series anyway
<cjwatson> Not exclusively, but vast majority ...
<cjwatson> Can anyone explain to me why bug 1028213 is on http://reports.qa.ubuntu.com/reports/rls-mgr/rls-q-tracking-bug-tasks.html ?  It doesn't have a rls-q-tracking tag (nor, I think, should it).
<ubottu> Launchpad bug 1028213 in wine1.4 (Ubuntu Quantal) "Please remove gcc-4.5 from quantal" [High,Triaged] https://launchpad.net/bugs/1028213
<Laney> probably because of the milestone
<Laney> or the quantal task
 * xnox doko++
<xnox> good upload.
<xnox> doko: did you mean to have a comment on the second PRETTY_NAME as well?
<Laney> which upload?
<xnox> Laney: http://launchpadlibrarian.net/115385783/base-files_6.5ubuntu8_6.5ubuntu9.diff.gz
<cjwatson> Laney: Seems silly for rls-q-tracking-bug-tasks to include things that aren't rls-q-tracking bug tasks.
<cjwatson> bdmurray: ^- Do you know what's going on with the above?
<xnox> cjwatson: I agree. I sometimes assign stuff to myself and target to quantal, but it does not mean it's rls-q-tracking at all.....
<Laney> It's the workflow that Steve outlined some time ago
<xnox> Laney: is there documentation about it? maybe I am doing it wrong.
<Laney> there's no rls-q-tracking any more afaik
<xnox> yeah there is....
<doko> xnox, ohh, yes. do you want to fix it?
<xnox> Laney: or is there -incomming & -wontfix => transition to => quantal-series + assignee without any rls-q- tags?
<xnox> doko: ok.
<cjwatson> ah, yeah, maybe I lost track
<cjwatson> hm, rls-q-notfixing is kind of wrong though because I don't want to make (or seem like I'm making) that claim on behalf of YokoZar
<Laney> I suppose you should remove the quantal task
<cjwatson> can't untarget once it's been targeted
<cjwatson> I don't think
<xnox> doko: can the source file not be generated from lsb_release file?
 * cjwatson tries on qastaging
<Laney> I see a no entry button
<Laney> what does that do?
<Laney> I suppose it's a "-" actually
<stgraber> you can untarget by clicking on the minus sign
<cjwatson> that's what I was going to try
<Laney> I assume that untargets, not that I can recall ever using it
<xnox> I love how you can untarget "Ubuntu" and then there is simply a lingering task left.....
<Laney> have you actually done that?
<xnox> Laney: i believe so, maybe it's just the ajax rending....
<stgraber> I used it a few times to remove specific series from bugs, yes
<xnox> doko: done.
<bdmurray> xnox: rls-q-incoming has one 'm'
<xnox> ;-)
<bdmurray> cjwatson: did you sort out the answer to rls-q-tracking?
<cjwatson> Yeah
<cjwatson> My misunderstanding
<bdmurray> pitti: did you work on the software-properties drivers code at all?  bug 1028388
<ubottu> Launchpad bug 1028388 in software-properties (Ubuntu Quantal) "software-properties-gtk crashed with KeyError in show_drivers(): 'model'" [High,Confirmed] https://launchpad.net/bugs/1028388
<pitti> bdmurray: not really, that was cyphermox's work
<pitti> cyphermox: ^ could you have a look please?
<bdmurray> pitti: okay thanks
<cyphermox> yeah I was looking at it
<cyphermox> pitti: in fact it's didrocks now ;)
<cyphermox> the model/vendor stuff is in UbuntuDrivers AFAICT though
<cyphermox> still, I'm looking into it
<cjwatson> hah, yeah, I was just looking at that bug
<cyphermox> oops
<didrocks> cyphermox: if you have some time for that, I'll appreciate, I'm supposed to be on the +1 team, but that with the unity team to track and the desktop team, that starts to be quite a lot :)
<cjwatson> never mind, I didn't say so
<cjwatson> UbuntuDrivers.detect documents that vendor and model are only set in that dictionary if values for them are known
<cyphermox> didrocks: np, should be simple enough
<cjwatson> so software-properties clearly needs to handle the case where they're absent
<cjwatson> cyphermox: go ahead anyway, I have enough to do :)
<cyphermox> cjwatson: ah, I was wondering if it wouldn't be best to make them "(unknown)" in UbuntuDrivers in those cases where it's not available
<cjwatson> needs i18n though doesn't it?
<pitti> I ratrher wouldn't
<cyphermox> though that's not exactly pretty
<pitti> u-d-common has no i18n
<cjwatson> I figured that might reasonably be a frontend decision
<cyphermox> ah!
<cyphermox> yeah
<pitti> I can set them to None if that helps
<pitti> but either way you need to handle it
<cjwatson> for instance some frontends might just leave them out
<cyphermox> pitti: don't bother, we can do that in UI
<cjwatson> pitti: can't see how it'd make much difference; at least this failure is obvious
<pitti> but you can use results.get('vendor', _('Unknown')) in the UI
<pitti> get() is really convenient for these cases
<pitti> cjwatson: yeah, that's why I made it that way instead of None; just hides errors
<cyphermox> pitti: weird, my system used to be detected as requiring an nvidia card, now it doesn't
<cyphermox> s/card/driver/
<pitti> cyphermox: can you pastebin ubuntu-drivers detect?
 * pitti in a meeting, will lag
<cyphermox> yeah getting to it
<doko> mvo, https://launchpad.net/ubuntu/+source/aptdaemon/0.45+bzr856-0ubuntu1/+build/3769536
<mvo> doko: hello, thanks
<m_3> tedg: ping
<tedg> m_3, Howdy
<mpt> font-family:Ubuntu,'Bitstream Vera Sans','DejaVu Sans',Tahoma,sans-serif;
<mpt> ev, any reason you are preferring Vera over DejaVu?
<ev> mpt: I probably stole that from qa.ubuntu.com's CSS
<ev> so no, no reason
<ev> I can quickly swap them around
<stgraber> barry: are you aware of any chance in the recent python 2.7 that'd break argparse?
<stgraber> barry: arkose stopped working after updateing my quantal system this morning with:
<stgraber> AttributeError: 'str' object has no attribute 'append'
<barry> stgraber: i'm not
<barry> stgraber: bug #?
<stgraber> that's when calling args.bind.append() where args.bind is defined as:
<stgraber> parser.add_argument("--bind", dest="bind", type=str,
<stgraber>     default=[], action='append',
<stgraber>     help=_("""Add a bind mount to the container.
<stgraber> (allowed multiple times)"""))
<stgraber> no bug yet, just got it show up on a few of my machines, will try to get a minimal reproducer
<cjwatson> doesn't that want to be type="string"?
<stgraber> my guess is that type=str + defaults=[] + action='append' changed from defaulting to an empty list to defaulting to an empty string
<cjwatson> oh, argparse not optparse
<achiang> micahg: hi, i've updated https://bugs.launchpad.net/ubuntu/+source/wader/+bug/1046102 with a FFe justification... do i need to do anything else, or should i just assume the release team will see it by virtue of them being subscribed?
<ubottu> Launchpad bug 1046102 in wader (Ubuntu) "Sync wader 0.5.12-1 (universe) from Debian unstable (main)" [Undecided,Incomplete]
<micahg> achiang: well, it usually goes in the description, but they should see it
<barry> stgraber: you should probably just remove the type=str anyway since it's the default
<barry> should or could :)
<Laney> achiang: incomplete would probably mean that i wouldn't see it
 * micahg just fixed that
<achiang> Laney: oops, i didn't move the bug state away from incomplete. what should it be?
<stgraber> barry: minimal reproducer: http://paste.ubuntu.com/1196908/
<Laney> New is good
<stgraber> barry: works on older quantal, fails with current
<stgraber> barry: regression happens with both python2.7 and python3.2
<achiang> micahg: Laney thanks
<barry> stgraber: saved me from writing one :)  i just searched the python bug tracker and found nothing relevant
<stgraber> barry: FWIW, removing type=str fixes it
<ev> mpt: http://bazaar.launchpad.net/~ev/errors/trunk/revision/184 - fixed
<barry> stgraber: doesn't fail for me
<barry> % python2.7 /tmp/foo.py --test baz
<stgraber> barry: call it without the --test
<ev> mpt: and live on poppy-dev
<stgraber> barry: the problem is the default value
<mpt> ev, that's a big spike in Q yesterday
<ev> yeah, it's not filling me with confidence
<ev> filling in 12.04 now
<ev> (still waiting on the RT for the cron job for this)
<barry> stgraber: i think this is a misunderstanding of what 'default' does.  it doesn't initialize the dest afaik, but provides the value to use if --test isn't given
<barry> stgraber: but hmm
<stgraber> barry: my understanding is that when using both action="append" and default=[], args.test should always be a list, either containing what's past on the command line, or an empty one. Having it be an empty string doesn't make any sense.
<barry> stgraber: okay, i'm quite confused now.  let me look at upstream and do some code spelunking
<stgraber> barry: bug 1048710
<ubottu> Launchpad bug 1048710 in Ubuntu "Regression in argparse for both python2.7 and python3.2" [Undecided,New] https://launchpad.net/bugs/1048710
<stgraber> barry: I filed it against python2.7 as that's where I first noticed it, but as I said here and in the bug, the regression also happens with 3.2
<stgraber> for now I just removed the type=str from my local copy of arkose so I can work, I'll probably end up uploading that anyway as it's not required and happens to "fix" the bug...
<barry> stgraber: here's what's really weird:
<barry> (Pdb) print args.test
<barry> []
<barry> (Pdb) print type(args.test)
<barry> <type 'str'>
<barry>  
<barry> so args.test is the *string* "[]" :-o
<stgraber> oh wow
<stgraber> barry: oh, I guess it's basically setting it to type(default) which in this case would be str([])
<barry> stgraber: must be, yes.  confirmed in upstream hg head
<barry> stgraber: this is probably not relevant, esp. because it's only landed in unreleased 2.7.4:
<barry> - Issue #12776,#11839: call argparse type function (specified by add_argument)
<barry>   only once. Before, the type function was called twice in the case where the
<barry>   default was specified and the argument was given as well.  This was
<barry>   especially problematic for the FileType type, as a default file would always
<barry>   be opened, even if a file argument was specified on the command line.
<barry>  
<barry> stgraber: probably worth an upstream bug report because it's either a legit bug or a doco omission
<barry> stgraber: i'll file that
<stgraber> barry: thanks
<barry> stgraber: fwiw, 3.3 seems to dtrt
<doko> tkamppeter, http://people.canonical.com/~ubuntu-archive/component-mismatches.svg please could you file MIR's for the new foomatic-db dependencies?
<micahg> doko: are we going to have a test rebuild at some point?
<barry> stgraber: wtf?!  it "works" in ubuntu's py3.3rc2 but not in upstream hg head.  i bet python issues 12776 and 11839 are somehow involved.  anyway... http://bugs.python.org/issue15906 which i'll link to the ubu bug
<doko> micahg, yes, trying to get some mir's addressed first
<barry> pitti: ping
<barry> mterry: ping too
<mterry> barry, hi
<barry> pitti, mterry hi.  lp #887699 - i never got to this one.  i'm afraid we may not have time for quantal.  i don't know what it's blocking, and whether it's worth still trying to attack for quantal.  i'm also not sure how much work it is
<ubottu> Launchpad bug 887699 in python-distutils-extra (Ubuntu) "python-mkdebian: Support python3 projects" [Medium,Triaged] https://launchpad.net/bugs/887699
<mterry> barry, it's OK.  I assumed you weren't getting to it at this point.  The deal is that it's blocking Quickly from supporting Python 3 projects that users want to create (and we want to recommend them creating)
<mterry> barry, we can coast another release with only supporting python2 projects, but it should probably happen for 13.04, since we are getting out of step with what we ourselves recommend (python3) and what we are forced to recommend to app authors (python2)
<mterry> barry, though, in 13.04, we are looking at using pkgme instead, so maybe that bug becomes irrelevant?
<barry> mterry: okay.  i'll target it to 13.04 and bump the priority to high.  i'm working on the new blueprint for rocky raccoon
<infinity> We certainly want those two things to be well-tested and in lockstep by the next LTS, so the earlier, the better.
<barry> mterry: +1 for pkgme!
<micahg> any hope of only needing python3 by the next LTS?
<infinity> micahg: Define "need".
<micahg> images :)
<barry> micahg: not archive-wide but hopefully yes for ubuntu-desktop task and main (if there is a main <wink>)
<infinity> micahg: There's zero hope of everything in universe being ported to python2, but ubuntu-desktop, for sure.
<micahg> infinity: xubuntu desktop is on my mind ATM :)
<infinity> micahg: And it would be nice if the other -desktops could get there too.
<barry> i feel confident about twisted, not so confident about xapian, ecstatic that we can ignore launchpadlib stack, and worried about all the canonical-led projects. :)
<trism> Anyone working on a new upload of gnome-control-center? I added a debdiff with the upstream commit that fixes the pretty nasty bug 1041756 (don't know if anyone noticed the bug, been undecided since august)
<ubottu> Launchpad bug 1041756 in gnome-control-center (Ubuntu) "gnome-control-center and desktop environment crashes when trying to change full name in User Accounts" [Undecided,Confirmed] https://launchpad.net/bugs/1041756
<infinity> bdmurray: Did you want to fix #1038302 and supersede the current SRU in the queue?
<bdmurray> infinity: yeah, I guess.
<infinity> bdmurray: Doesn't make much sense to do them one at a time, IMO.
<bdmurray> infinity: I'd mentioned that in the other bug
<infinity> bdmurray: Yeah, I figured since you fixed it in Q, you might just do the P fix as well. :P
<infinity> bdmurray: If you'd like to grab the sources from the queue and just add your changes to it (you can reuse the version, I'll just reject the old one)
<bdmurray> infinity: okay, after lunch then
<ScottK> tjaalton: Would you please have a look at the last several comments in Bug #956071 and let me know if you think that's the fix is incomplete/there are other bugs or there's a regression in this update?
<ubottu> Launchpad bug 956071 in xorg-server (Debian) "Xorg crashed with SIGSEGV in XIGetDeviceProperty()" [Unknown,Confirmed] https://launchpad.net/bugs/956071
<infinity> ScottK: Yeah, looked incomplete to me too.  I was about to give it a regression tag.
<infinity> ScottK: It's hard to say if it's actually a regression or an incomplete fix, but the result of "some touchpads stop working" seems suboptimal.
<ScottK> infinity: I wasn't sure if it's 'not fixed, but better' or 'better for some/worse for others.'
<ScottK> True.
<tjaalton> ScottK: looks weird.. works perfectly on my t420s on precise
<tjaalton> but I'll reopen it then
<infinity> I tagged it and added a comment.  Would be nice if we could get some slightly less contradictory results. :/
<ScottK> Yes.
<infinity> If someone could walk someone through reproducers with $old and $new and make sure it was being done sanely, that would be lovely.
<infinity> (And by "someone", I mean "someone who claims it's still broken")
<tjaalton> I'll do that tomorrow
<tjaalton> didn't test hotkeys
<infinity> Thanks.
<tjaalton> heck, testing it now. and seeing that there's a cool icon popup when hitting the hotkey :)
<tjaalton> that was quick, needs only two cycles
<infinity> pitti: Can you grab the current ntfs-3g from -proposed, rebase your upload against it, and reupload with a -v to get both in the changes?
<infinity> pitti: (Didn't notice the two conflicting uploads before I accepted one..)
<tjaalton> infinity: hotkeys fail to enable it with the old version too
<tjaalton> the testcase was bad :)
<tjaalton> should've put xinput disable/enable there
<tjaalton> that works just fine
<tjaalton> it's still a bug, dunno about the other reports what they're seeing
<infinity> tjaalton: I don't want to know the answer to "why don't the hotkeys just call into the same codepath at xinput", do I?
<infinity> s/at/as/
<tjaalton> infinity: right, no idea why not..
<tjaalton> I'll check that tomorrow, updated the bug with my findings
<infinity> Thanks
<bdmurray> infinity: feel free to reject the old trousers
<infinity> bdmurray: Done.
<infinity> bdmurray: Erm.
<infinity> bdmurray: If I'm reading that diff right, the precise version didn't HAVE a prerm at all (broken or otherwise) until it was just now added...
<infinity> bdmurray: Yeah, grabbing the current binaries confirm that.
<infinity> bdmurray: So, I'm going to reject this, invalidate the precise task, and accept the old upload. :P
<infinity> bdmurray: I guess I could have checked that instead of taking your word for it in the bug trail.
<doko> Daviey, zul: horizon pulls in a bunch of packages into main, although MIR's are missing
<zul> doko: lessc?
<doko> zul, yes, less.js, see http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
<zul> doko: ack
<doko> jamespage, ceph pulls xml2 into main, which is missing a MIR
<Daviey> doko: horizon is known. It should not have a MIR, as it is pending being dropped
<Daviey> It's not a current blocker for cdimages, as it isn't on the cd, nor a build dep
<doko> just trying to clear component mismatches
<Daviey> doko: I'm not ignoring it either :)
<dobey> the langpack stuff will use translations from the upstream source, if the strings are not yet translated directly in ubuntu, right?
<doko> pitti, cjwatson: ibus-m17n was demoted in 2010, according to the seeds bzr log. however it's now (again?) in supported.
<doko> without a MIR
<doko> roaksoax, Daviey: the MIR's for celery and raphael were incomplete. I did open new tasks and assigned these to roaksoax
<roaksoax> doko: ok thanks will take a look at them
#ubuntu-devel 2012-09-11
<stgraber> barry: another thing blowing up in the archive after the new python landed: https://bugs.launchpad.net/juju/+bug/1048864
<ubottu> Launchpad bug 1048864 in juju (Ubuntu Quantal) "Latest python in quantal breaks juju test suite" [Critical,Triaged]
<stgraber> SpamapS: the same python fixes also caused https://bugs.launchpad.net/ubuntu/+bug/1048710
<ubottu> Launchpad bug 1048710 in python3.2 (Ubuntu) "Regression in argparse for Python 2.7, 3.2 and 3.3" [Undecided,Confirmed]
<SpamapS> stgraber: ah, so perhaps this is really just a dupe and the python regression will be fixed?
<stgraber> SpamapS: well, it's certainly a change of behaviour on the python side, now it's not completely clear whether it was intended or not and if it was, the doc is not reflecting that properly
<SpamapS> stgraber: for now I'll leave it in a holding pattern until folks smarter than I figure it out.
<slangasek> stgraber, SpamapS: should we be reverting this change to python if it's causing serious regressions?
<slangasek> (revert, and wait for a better fix)
<slangasek> doko: has anyone brought bug #1048710 to your attention?
<ubottu> Launchpad bug 1048710 in python3.2 (Ubuntu) "Regression in argparse for Python 2.7, 3.2 and 3.3" [Undecided,Confirmed] https://launchpad.net/bugs/1048710
<doko> slangasek, stgraber: handled for now by barry. I'm not that sure that this exposes regressions in many existing builds. but quantal will see a resolution for all pythonx.y packages
<slangasek> doko: ok
<slangasek> doko: sorry, just assigned the bug to you; feel free to reassign it to barry, or just take the credit for the bugfix when it's closed ;)
<stgraber> slangasek: so far juju and arkose are the only two that I'm aware of, it's apparently limited to pretty specific (weird) uses of argparse, so as it's, I think we can wait a few days. I worked around it in arkose for now (by removing the unnecessary type=str).
<stgraber> I see it's being looked at/discussed upstream, so hopefully we'll know more soon
<pitti> Good morning
<pitti> infinity: ntfs-3g> sure, will do; should have checked myself, thanks for pointing out
<RAOF> How good is errors.ubuntu.com at verifying that a precise-proposed package fixes a crasher bug that's not trivially reproducible?
<lifeless> RAOF: perfect
<lifeless> RAOF: it measures 'fixed' by 'not happening any more'
<lifeless> RAOF: which of course depends on a) reproduction and b) users reporting it
<pitti> infinity: done
<pitti> infinity: I rejected my previous upload
<lifeless> RAOF: the 'perfect' was sarcasm btw
<lifeless> RAOF: we don't (AFAIK) have any machine learning in there yet
<lifeless> RAOF: but it should be fairly goof
<RAOF> lifeless: People seem to be reasonably good at randomly hitting the crash, so not finding any crashes in the proposed version would be a reasonable herustic
<RAOF> *heurstic
<lifeless> ...
<lifeless> RAOF: heuristic ?
<RAOF> Heh.
<RAOF> I am *terrible* at spelling that.
<lifeless> RAOF: you need a better engrish heuristic :)
<RAOF> :P
<lifeless> </badjoke>
<infinity> pitti: Thanks.
<infinity> RAOF: I kinda like "herustic".  Like a log cabin decorated with Master of the Universe toys.
<infinity> Masters*
<tjaalton> infinity, ScottK: looks like the noise on bug 956071 has been sorted out, the hotkey issue is a separate bug
<ubottu> Launchpad bug 956071 in xserver-xorg-input-synaptics (Ubuntu Precise) "Xorg crashed with SIGSEGV in XIGetDeviceProperty()" [High,In progress] https://launchpad.net/bugs/956071
<infinity> tjaalton: Alright, that's good enough for me.
<infinity> tjaalton: Released to updates.
<infinity> tjaalton: Thanks for digging deeper.
<tjaalton> infinity: excellent, thanks
<tjaalton> I'll try to search for the hotkey bug, that must be reported
<tjaalton> the hotkey bug is in gnome-settings-daemon, hitting the key toggles /org/gnome/settings-daemon/peripherals/touchpad/touchpad-enabled
<tjaalton> bug 804109
<ubottu> Launchpad bug 804109 in gnome-settings-daemon (Ubuntu) "can't enable touchpad in Ubuntu (thinkpads)" [Low,Confirmed] https://launchpad.net/bugs/804109
<toabctl> pitti, i'm trying to introspect a p2p dbus connection (for bgo #681093) but get a "TypeError: Argument 1 does not allow None as a value". See example script here: http://paste.ubuntu.com/1198008/
<toabctl> pitti, the strange thing is, that "gdbus introspect ..." works well and there is the first parameter null
<toabctl> pitti, see http://git.gnome.org/browse/glib/tree/gio/gdbus-tool.c#n1436
<pitti> toabctl: answering in #python
<pitti> RAOF: the incompatible fglrx keeps breaking the ubuntu-drivers-common test cases; I just checked, and that seems to be right
<pitti> RAOF: do you know when we'll get a compatible fglrx?
<RAOF> I do not, no.
<pitti> ok; at least the tests do what they are supposed to do
<RAOF> Sarvatt or tselliot are your best bets for that knowledge; tjaalton is also has a reasonable chance of knowing.
<pitti> cyphermox: https://jenkins.qa.ubuntu.com/view/Quantal/view/AutoPkg%20Test/job/quantal-adt-network-manager/lastFailedBuild/ARCH=i386,label=albali/console -> is that perhaps a missing dependency?
<pitti> cyphermox: (dnsmasq)
<xnox> good morning =)
<tjaalton> pitti, RAOF: my bet is on week 41 or 42..
<dholbach> good morning
<dholbach> tseliot, do you think you or somebody else could respond to https://twitter.com/marcosbarbosa/status/245228540952473602?
<tseliot> dholbach: sure, we don't have an fglrx driver which support's Quantal's xserver ABI yet
<dholbach> ok
<pitti> jibel: in Jenkins, do we have tests that run under a full desktop session?
<pitti> jibel: I have a work item to write UI related suspend/resume tests (indicator integration, inhibition by movie player, low battery, and so on)
<pitti> jibel: but these would be full desktop integration tests
<jibel> pitti, there are a few to test unity with autopilot. They run on hardware. For example https://jenkins.qa.ubuntu.com/job/dx-autopilot-run/label=00000000-0000-0000-0000-8C89A516023C/
<pitti> jibel: ah, I was hoping for a VM (as on real hw it's rather brittle to set up auto-resume)
<pitti> jibel: but that shouldn't stop me, I could stub out the actual suspend call somehow
<pitti> jibel: I guess it would not be appropriate to stuff them into the daily image testing?
<jibel> pitti, we could run them as post-install test
<jibel> *tests
<pitti> jibel: would that be appropriate for now, until we have real adt-like integration tests?
<pitti> jibel: or should I rather try to use adt-*, and just depend on gnome-session etc. and run the stuff under xvfb?
<pitti> ah, unity and xvfb might not be that friendly to each other, I fear
<tkamppeter_> pitti, hi
<pitti> hello tkamppeter_
<tkamppeter_> I have some packages which are very close to Debian or even in sync, and they have recommends which we do not have in main, foomatic-db, see bug 1048982 and ghostscript, see bug 1048820
<ubottu> Launchpad bug 1048982 in printing-metas (Ubuntu) "[MIR] printing-metas" [High,Incomplete] https://launchpad.net/bugs/1048982
<ubottu> Launchpad bug 1048820 in fonts-droid (Ubuntu) "[MIR] fonts-droid" [High,Incomplete] https://launchpad.net/bugs/1048820
<pitti> tkamppeter_: I thought we used foomatic-db-compressed?
<jibel> pitti, my concern is that we can shoehorn the tests in the current daily image testing, but it will ported to utah soonish, which means porting the suspend/resume tests too.
<jibel> pitti, I'll look to provision a testbed for adt with a full desktop environment
<pitti> jibel: yeah, and they don't really fit into iso testing
<pitti> jibel: so perhaps we should just wait for UTAH for this?
<tkamppeter> Now for us these recommended packages are not really important, how to proceed without breaking sybcs and/or without getting extra delta.
<jibel> pitti, maybe but I have no ETA, gema will know
<pitti> tkamppeter: I don't understand bug 1048820
<ubottu> Launchpad bug 1048820 in fonts-droid (Ubuntu) "[MIR] fonts-droid" [High,Incomplete] https://launchpad.net/bugs/1048820
<pitti> $ apt-cache show ghostscript|grep droid
<pitti> $
<pitti> ghostscript doesn't recommend fonts-droid
<tkamppeter> pitti, we really use foomatic-db-compressed-ppds, but some automatic consistency checker seems to have found this stuff.
<tkamppeter> pitti, can one perhaps demote the binary package foomatic-db? Or is it not possible as it is a build dependency for other packages in main?
<pitti> tkamppeter: oh, I see -- it's libgs9-common which recommends it
<pitti> tkamppeter: yep, see "reverse-depends -b foomatic-db" - b-deps of m2300w and ptouch-driver
<tkamppeter> pitti, I did not set this, I even did not know that there is a package named fonts-droid. This probably comes from Debvian.
<pitti> tkamppeter: right, so what the bug says -- either we drop it to a suggests, or use a font which we already install
<pitti> I'm not that keen on adding YET another font to the default install
<pitti> we have plenty already
<tkamppeter> pitti, I do not have fonts-droid installed and I nver had problems with Ghostscript, so I would make a suggests out of fonts-droid.
<pitti> tkamppeter: sounds fine
<tkamppeter> pitti, problem is that we have another delta, as the Debian maintainer has probably some reasons to recommend it in a Debian environment.
<pitti> tkamppeter: as for foomatic-db, perhaps m2300w etc. also build with -compressed as a b-dep somehow?
<tkamppeter> pitti, problem is that m2300w and ptouch-driver ship Foomatic XML files and no corresponding PPDs, so the build process has to build the PPDs which needs foomatic-db.
<pitti> tkamppeter: so you could also drop printer-driver-all recommends to suggests?
<tkamppeter> pitti, I am investigating now whether the two driver packages really need foomatic-db to build ...
<tkamppeter> pitti, main problem of foomatic-db is that it is synced with Debian.
<pitti> tkamppeter: no, it's not -- 20120823-0ubuntu1 here ?
<pitti> jibel: ok; let me play around with how much of a session I can get in xvfb and the adt env
<tkamppeter> pitti, it is at least identical. Sometimes I update from OpenPrinting, sometimes OdyX. All in the debian/ directory is always the same.
<pitti> tkamppeter: ah, so perhaps some syncs are in order to get us to identical versions?
<pitti> tkamppeter: so ideally the foomatic-db build deps coudl be dropped
<pitti> tkamppeter: if not, we coudl change the foomatic package in Debian to add the recommends only when you build for Debian, but not for Ubuntu
<doko> pitti, is ibus-m17n wanted in main? you did add support for it in language-selector (but already in precise), and cjwatson seeded it in June
<pitti> hm, not sure -- it fell out of main after lucid apparently
<cjwatson> *shrug* I think I was just syncing up with something or other
<pitti> why does that only pop up now, hmm; /me reads seed history
<cjwatson> Probably with language-selector
<pitti> ah
<pitti> revno: 1738
<pitti>   drop ibus-m17n, it's a very little used package and has far inferior input methods compared to pinyin; use pinyin with small db-android instead; per Aron Xu <happyaron@ubuntu.com>
<pitti> timestamp: Fri 2010-08-20 14:33:14 +0200
<cjwatson> Yeah, but l-s should match the seeds either way
<pitti> so that's what caused it to drop out of main
<cjwatson> r2051
<pitti> we should drop it from l-s then?
<cjwatson> I have no opinion on whether -m17n is any good or not, but if it isn't, it should be dropped from the seeds and l-s in tandem
<pitti> ArneGoetje: hey Arne, how are you?
<pitti> ArneGoetje: do you know of m17n is still relevant for anything?
<pitti> cjwatson: yes, I agree
<cjwatson> bug 753476
<ubottu> Launchpad bug 753476 in language-selector (Ubuntu) "[te]ibus-m17n needs to be part of CD/DVD for indic language support " [Medium,Fix released] https://launchpad.net/bugs/753476
<cjwatson> filed some months after r1738
<pitti> ah, there we go
<pitti> right, then I guess let's just promote it back?
<pitti> . o O { yay for having history for everyting }
<cjwatson> This is what it's for ...
<pitti> doko: re-promoted then
<doko> thanks!
<mpt> ev, poppy-dev doesn't have the data point tooltips. Is that deliberate?
<ev> mpt: try now
<mpt> bueno
<mpt> So, what was the spike yesterday?
<ev> mpt: not sure yet - firefighting the django openid deployment. Will dig in a bit
<jamespage> doko: ceph currently has some binaries which are in universe - rest-bench being one of them which has this dep
<davmor2> pitti: I'm going to write a bug for the music player showing up in quantal as a usb driver what commands are you likely to want me to run to help you guys diagnose it?
<davmor2> pitti: also I'm assuming the fix you added to precise got pulled in right?
<davmor2> pitti: and would a comparison with what precise lists be useful?
<doko> jamespage, I assume I'll just have to add rest-bench-dbg to Extra-Excludes
<jamespage> doko, yes please - I really don't think the rest-bench packages need to go into main
<jamespage> radosgw is another matter
<xclaesse> any known bug that could cause gobject-introspection stuff to be commented out in generated Makefile ?
<xclaesse> building tp-glib from source does not build .gir, wondering if that could be a bug in ubuntu quantal gobject-introspection package or something like that
<bigjools> cjwatson: can I bug you for some help with a quantal upgrade please - it's left my machine in a bit of a state
<pitti> davmor2: re (sorry, was at the phone)
<pitti> davmor2: an useful piece of information/comparison would be "udevadm info --export-db", this will tell me whether the device was recongized as a player
<xclaesse> bah forget my question above, found my error :)
<cjwatson> bigjools: well, I may or may not know the answer, but sure
<bigjools> cjwatson: ok, I'll just paste some stuff
<davmor2> pitti: apparently AlanBell has a similar issue with his android phone too
<bigjools> cjwatson: but first problem is that I have two X servers running on different vts
<cjwatson> I know nothing of that
<bigjools> cjwatson: then this http://pastebin.ubuntu.com/1198419/
<cjwatson> bigjools: could you tar up /var/lib/dpkg and put it somewhere for me please?
<bigjools> sure
<cjwatson> probably not immediately worth debugging your X problem until your package database is in a remotely sane state
<bigjools> yeah
<cjwatson> but if it persists then you'll want somebody from the desktop team
<bigjools> ok
<bigjools> is U1 a suitable place for you to pick up files?
<bigjools> ah I'll stick it on chinstrap
<AlanBell> pitti: http://paste.ubuntu.com/1198424/
<cjwatson> U1 would mean I'd have to figure out why my syncdaemon is busted
<cjwatson> which I've been merrily ignoring
<bigjools> heh
<bigjools> I just thought that I'm not sure I can rely on mine in this state
<sladen> I think somebody posted me a weblink from U1 recently that no longer required extranous sign-up
<davmor2> pitti: udevadm stuff, quantal = http://paste.ubuntu.com/1198425/ and precise = http://paste.ubuntu.com/1198430/ and I just thought I'm not sure what package to write it against :(
<ev> mpt: is there anything in the javascript console?
<ev> errors, that is
<mpt> ev, [12:20:31.651] SyntaxError: JSON.parse: unexpected character @ http://poppy-dev.local/static/js/yui/build/json-parse/json-parse-min.js:7
<ev> mpt: does it change if you click on a bucket page and login first?
<mpt> ev, there's no buckets to click on
<cjwatson> bigjools: right, so this is basically http://lists.debian.org/debian-devel-announce/2012/03/msg00005.html
<cjwatson> (that won't especially help immediately, just for background)
<bigjools> ok, reading
<cjwatson> bigjools: I suspect this won't work, but try 'sudo dpkg -P libao4'
<bigjools> cjwatson: same dpkg error
<cjwatson> OK, let's edit dpkg's brain
<bigjools> \o/
<bigjools> trepanning
<cjwatson> bigjools: edit /var/lib/dpkg/status.  There are two paragraphs that start with "Package: libao4"; you want the one that also contains "Architecture: amd64".  Delete that paragraph.
<bigjools> ok
<cjwatson> (It should be "Status: deinstall ok config-files".
<cjwatson> The old dpkg incorrectly left this in a half-arsed state on a previous upgrade.
<bigjools> it's now an ex-paragraph
<cjwatson> Now 'sudo dpkg --configure -a'
<bigjools> doing stuff, but reporting dependency problems
<cjwatson> Yeah, expected since you were probably interrupted mid-upgrade
<bigjools> looks like it :(
<cjwatson> But it'll do what it can to start with
<cjwatson> Then 'sudo apt-get -f install'
<bigjools> ok it's done
<cjwatson> And after that I'd run 'sudo apt-get dist-upgrade'
<bigjools> zoiks
<bigjools> it wants to remove about 100 packages
<cjwatson> pastebin?
<mpt> ev, http://paste.ubuntu.com/1198449/
<cjwatson> bigjools: Out of interest did you use update-manager to do this upgrade - that is, if update-manager happened to have been smart enough to detect this problem earlier, would it have helped?
<bigjools> cjwatson: http://paste.ubuntu.com/1198460/
<bigjools> I did use update manager yes
<bigjools> and I suspect anything would have been better than this :)
<bigjools> short of leaving it unbootable
<cjwatson> Well, yeah, all I mean is we can't fix the bare apt-get dist-upgrade path so easily
<cjwatson> But in principle we can beef up u-m to help people who use it
<bigjools> so it wants to remove 238 in fact
<cjwatson> So, that's entirely multiarch-related stuff; it could be caused by any one of those packages being out of sync between amd64 and i386, which is a standard multiarch problem while running development releases
<cjwatson> If this were my system I would let it remove all of that and worry about putting google-earth-stable, skype, and wine1.4 (which are the application-level packages in there) back later
<bigjools> yeah
<cjwatson> Oh, with the exception of erlang-docbuilder which has genuinely been removed from quantal
<bigjools> well, I hit the button, let's see how it goes :)
<cjwatson> This systematic out-of-sync problem will be fixed once we start using -proposed to stage everything in a cycle or two
<mpt> ev, if the Launchpad info is effectively just for styling the rows, have you considered displaying them unstyled quickly, and then applying the class= attributes when the Launchpad data arrives?
<ev> mpt: yes, I've thought about it, but it requires fetching much of the same data twice
<mpt> ev, you changed the error: Timestamp: 11/09/12 12:34:10
<mpt> Error: SyntaxError: JSON.parse: unexpected end of data - Source File: http://poppy-dev.local/static/js/yui/build/json-parse/json-parse-min.js Line: 7
<ev> hmm
<ev> that shouldn't change
<ev> but try logging in off a problem page
<ev> clicking on a function link
<ev> that's what I think I fixed
<cjwatson> slangasek: ^- Do you know of a bug that corresponds to bigjools' multiarch upgrade disaster?  We should definitely do something about this in ubuntu-release-upgrader
<mpt> ev, success
<ev> yay
<ev> tuples should suffer an awful death
<ev> now to fix your javascript error
<ev> mpt: does http://poppy-dev.local/api/1.0/instances-count/?format=json&limit=365 work?
<davmor2> ev: that or just don't use them :P
<mpt> ev, I'm not going to count parentheses, but it looks right
<bigjools> cjwatson: ha, dist-upgrade shows 1988 packages to upgrade.  I am guessing my u-m bailed out very early :(
<ev> weird
<ev> davmor2: indeed :)
<bigjools> cjwatson: the question is, will it have missed important upgrade steps I need to care about?
<davmor2> ev: just use lists always see how much havoc that causes instead ;)
<cjwatson> bigjools: probably not; I don't think there are many quirks in the precise-to-quantal upgrade as yet
<bigjools> righto
<cjwatson> bigjools: you might want to ensure that all the PPAs you care about are enabled at the end of the upgrade
<bigjools> cjwatson: yeah, done that already, it's one of those automatic things you do after upgrades I guess
<cyphermox> pitti, no, dnsmasq-base is pulled in... there is something else; perhaps ifblacklist_migrate.sh isn't doing what it should well enough so the connections never come up; that would explain dnsmasq not starting
 * mpt winces at bug 947107
<ubottu> Launchpad bug 947107 in ubiquity (Ubuntu Precise) "No partition labels in 12.04 partition wizard" [High,Triaged] https://launchpad.net/bugs/947107
<ev> mpt: I've narrowed it down to just happening in Firefox. I'll figure it out after lunch.
<barry> doko via slangasek: are you looking at bug #1048710 or should i spend some time on that today?
<ubottu> Launchpad bug 1048710 in python3.2 (Ubuntu) "Regression in argparse for Python 2.7, 3.2 and 3.3" [Critical,Confirmed] https://launchpad.net/bugs/1048710
<doko> barry, please go ahead, you already started the upstream issue =)
<barry> doko: k!
<xnox> mpt: I did add a comment to it, after I did some minimal test. But still needs more time.
<roaksoax> doko: lowering javascript-common to Suggests for lp #1020278
<ubottu> Launchpad bug 1020278 in wwwconfig-common (Ubuntu) "[MIR] raphael" [High,Incomplete] https://launchpad.net/bugs/1020278
<roaksoax> would be the fix, is that ok with you?
<doko> roaksoax, sure, if it makes sense.
<roaksoax> doko: /win 13
<roaksoax> err soryr :)
<doko> infinity, ogra_ : https://launchpadlibrarian.net/115081690/buildlog_ubuntu-quantal-armel.pdf2djvu_0.7.12-2ubuntu5_FAILEDTOBUILD.txt.gz ??
<doko> cjwatson, cat is in the just rebuilt coreutils
<cjwatson> doko: what?
<cjwatson> Oh geez
<doko> but wait, this the pdf2djvu was built on friday, before the upload
<cjwatson> doko: Are you sure this isn't a toolchain regression?  I didn't touch cat at all
<doko> no, if built on Friday, this was before the binutils and gcc uploads
<doko> where does this message come from, kernel printf?
<doko> running a 2.6.38 kernel
<micahg> aren't some of the builders on precise?
<dobey> hrmm, how close to latest 3.6-rc kernel is the current quantal kernel?
<micahg> I think quantal is on 3.5.3
<cjwatson> Good question; I can't find that text in eglibc, which is where I expected to find it
<cjwatson> Oh, libgcc maybe?
<dobey> micahg: do you know if 3.6-rc is packaged anywhere for precise?
 * micahg just sees quantal in the mainline dir, kernel team would probably know more
<cjwatson> doko: src/libgcc/config/arm/linux-atomic-64bit.c
<cjwatson> in gcc-4.7
<ogra_> lovely
 * cjwatson neatly deflects blame
 * highvoltage is an expert at deflecting blame
 * highvoltage blames the education system for that
<doko> cjwatson, ok, fsf 4.7.why do we see this only now?
<doko> hmm, that's because we default to v5
<ogra_> is it even worth to put time into armel at all ?
 * ogra_ thinks we can count its lifetime in weeks anyway
<cjwatson> Personally I like ports to die by explicit decision rather than by falling apart
<ogra_> heh, true ... and fixing it will likely help debian ...
<ogra_> though i wonder why we cant just take that decision instead of wasing time on it :)
<SpamapS> barry: any word on that python argparse regression?
<barry> SpamapS: not yet, but working on it
<SpamapS> barry: ok. I have a slightly different failure case involving FileType.. but I think its basically the same problem.
<barry> SpamapS: if you can boil it down, can you add it to the (launchpad) bug report and i'll at least check it?
<SpamapS> barry: yeah I am doing that right now
<barry> cool
<SpamapS> barry: ok, test case posted to bug 1048710
<ubottu> Launchpad bug 1048710 in python3.2 (Ubuntu) "Regression in argparse for Python 2.7, 3.2 and 3.3" [Critical,Confirmed] https://launchpad.net/bugs/1048710
<slangasek> smoser: hi, did you see my pings over the weekend about testing the new mountall package in our iscsi cloud environment?
<slangasek> (well, cloud-init)
<smoser> slangasek, i mean to get to that today.
<slangasek> smoser: ok :)
<tkamppeter> pitti, I have eliminated the foomatic-db build dependencies in both m2300w and ptouch-driver.
<pitti> tkamppeter: nice!
<ev> mpt: fixed: http://poppy-dev.local/ops/instances/
<ev> so yeah, 3,341 on the 7th. 1,651 on the 6th.
<ev> for 12.10
<mpt> \o/
<mpt> 3341 what?
<mpt> Oh, right, the blue line
<mpt> So, that's the beta 1 release
<mpt> but why would that cause a spike, if we're dividing by the number of machines anyway?
<mpt> Maybe there's an influx of people trying previously-untested things?
<ev> hm
<xnox> mpt: is there a correlation between a spike with # of machines upgrading to quantal?
<ev> lets see what the 90 day user count did that day
<xnox> ;)
<mpt> aha
<mpt> I was thinking the division would remove that factor completely
<mpt> but it will only completely remove it 90 days later
<mpt> The first day, it removes only 1/90 of it
<mpt> or does it
<mpt> No, we're dividing by the 90-day total, not by the last-90-days average
<mpt> hmmmm
<ev> mpt: unique systems count for 12.10 was 20596 and 21612 for the 6th and 7th respectively
<mpt> A 5% increase
<mpt> tiny
<smoser> slangasek, to clear my memory... even if i have the moutnal fix, i'll still need some hacks though, right?
<mpt> ev, but you know what, the #1 error is in ubiquity. What happens to the error rate if you ignore just that error?
<smoser> because i need /run to be mounted (and mountall emitted) before cloud-init runs.
<mpt> I'm pretty sure it wasn't ubiquity yesterday, or the day before
<smoser> ho. wait, no. that will happen in parallel with your branch.
<ev> mpt: 551 and 565 for the 6th and 7th
<mpt> So there's the spike explained. It's ubiquity.
<xnox> =(
<xnox> too many daily iso testers?!
<ogra_> milestone testing :)
<ogra_> *snap*
<ev> I'm not so sure
<ev> if you look at http://poppy-dev.local/bucket/?id=%2Fusr%2Flib%2Fubiquity%2Fbin%2Fubiquity%3AValueError%3Awatch_debconf_fd_helper%3Aprocess_input%3Await%3Acleanup%3Apreseed%3A%3Clambda%3E%3Acommand
<ev> it's been pretty high for a few days
<ev> since the 25th
<ev> so surely that would make a longer spike
<ogra_> hmm, somehow my .local domain is different from yours :P
<mpt> xnox, not nearly as many daily iso testers as beta 1 testers, that's all.
<ev> ogra_: :)
<ogra_> but milestone testing usually starts somewhere on the weekend and only ends on next thu ...
<xnox> ev: what if you exclude ubiquity? (this is fiddling with numbers now)
<ev> xnox: exclude all ubiquity crashes?
<xnox> yeah.
<mpt> ev, the general increase in instances since the 23rd is (mostly) matched by an increase in error rate too, so I think that's just Feature and UI Freezes
<xnox> ev: that ValueError was high since forever =) see my last merge proposal to ubiquity, hopefully it will fix that.
<ev> yeah, could be
<ev> xnox: excellent
<ev> ugh, how did I break the date range selection *again*?
<mpt> ev, while you're there, use <input type="date"> for the date fields :-)
<xnox> ev: open a reverse port forward. There is a juju charm to do that using a cloud instance =)
<mpt> oh, you already are
<ev> I did
<ev> yeah
<mpt> I wonder why it isn't showing a calendar
<ev> because Firefox is a pile of rusted bolts
<doko> infinity, will you still merge clang and llvm-defaultgs?
<ev> xnox: will do
<ev> though it'd probably be more helpful to just deploy to canonistack
<ev> so bdmurray can see trunk
<ev> and whomever else wants to hack on this
<xnox> true it can has public IP =)
<slangasek> smoser: shouldn't need any hacks that I can recall
<bdmurray> How can I reset my compiz / unity settings back to default?  I think some setting is causing compiz to crash and respawn repeatedly
<ogra_> bdmurray, unity --reset ?
<ogra_> (not sure that still exists)
<bdmurray> ogra_: I think it does but wasn't sufficient
<xnox> rumour has it --reset is broken
<didrocks> t's removed from trunk btw
<didrocks> yeah, it's useless since the gsettings migration
<bdrung> what's the preferred way to ping an archive admin to accept a package in -proposed?
<cjwatson> For preference, ping one of ~ubuntu-sru instead
<cjwatson> (I don't know)
<bdrung> cjwatson: ping. can you accept ncurses in oneiric-proposed?
<bdrung> it in the queue for 10 days
<bdrung> s/it/it's/
<cjwatson> I suppose I asked for that, but I'd rather one of the more regular SRU folks did it
<cjwatson> hm, though it's easy
<bdrung> cjwatson: who belongs to the more regular SRU folks?
<ogra_> ubuntu-sru ?
<cjwatson> bdrung: done now
<bdmurray> I think there is a daily schedule somewhere for the ubuntu-sru team
<bdrung> ogra_: the question was, who of the nine ubuntu-sru members are the more active ones.
<bdrung> cjwatson: thanks
<ogra_> bdrung, indeed the one with the highest karma *g*
<bdrung> ogra_: the karma just tell you how active someone is, but not how active in one specific team ;)
<ogra_> details :P
<bdmurray> bdrung: here it is https://wiki.ubuntu.com/SRUTeamProcess
<bdrung> skaet added a section about publishing the uploaded packages just some weeks ago.
<bdrung> bdmurray: thanks. that list appeared on https://wiki.ubuntu.com/StableReleaseUpdates too. rechecking wiki pages for updates sometimes help. ;)
<doko> mvo, cjwatson: see bug #1048566, i386 only
<ubottu> Launchpad bug 1048566 in hwloc (Ubuntu) "[1.4.1-4] want to uninstall the whole system" [High,Triaged] https://launchpad.net/bugs/1048566
<cjwatson> doko: Thanks, I'll sort that out
<doko> cjwatson, just curious, whats the reason for that?
<cjwatson> Breaks: libhwloc0 in libc6, added with the following changelog entry:
<cjwatson>   * Remove the /etc/ld.so.conf.d/i486-linux-gnu.conf conffile on upgrade on
<cjwatson>     i386, since it's no longer shipped and we should give consistent results
<cjwatson>     on upgrade and install; and add a Breaks on the three library packages
<cjwatson>     in lucid that used this path.
<cjwatson> But libhwloc5 Provides: libhwloc0
<doko> ahh, ok
<cjwatson> The fix is probably just to drop that Provides since nothing cares
<cjwatson> Or possibly actually to version the Breaks in libc6
<cjwatson> That might be nicer
<doko> ok, I can do that,
<doko> removing the provides
<cjwatson> No, on reflection I'd rather version the Breaks
<cjwatson> That's more correct anyway I feel
<cjwatson> I'll just look up the right versions and such
<doko> thanks
<smoser> slangasek, lp:ubuntu/mountall installed into a quantal "ephemeral image", then the 'start networking' hack removed from cloud-init-nonet.
<smoser> kern.log at http://paste.ubuntu.com/1198891/
<micahg> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #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
<smoser> virtual-fileysstems seems to have blocked until after cloud-init-nonet
 * mlankhorst is having fun bisecting nfs rootfs failures ;s
<barry> SpamapS: i have a proposed patch in the upstream tracker, but there is a semantic issue that needs clarification before i can apply it upstream.  if others on python-dev agree with my analysis, i'll get this into the upstream branches, and patch the ubuntu packages.
<SpamapS> barry: \o/ thanks.. was not looking forward to working around it.
<needhelp1>  Hello all, im helping to pull some data for Ubuntu Beta releases and have a very short survey up on google documents found here. https://docs.google.com/spreadsheet/viewform?formkey=dFdSTUgzREoyeFZNSWRHSjlXMGYteGc6MQ    Anyone interested please take the survey and feel free to share the link. The results will be published in two weeks to the public domain.
<micahg> can someone please mark the following as WIP: https://code.launchpad.net/~alessandro-menti/ubuntu/precise/kile/fix-for-994498/+merge/118919 https://code.launchpad.net/~geoubuntu/ubuntu/precise/xmltv/1018756/+merge/118935
<infinity> doko: Yeah, I should do the clang merge, despite FF.
<doko> infinity, I'd like to start a test rebuild this week. so ...
<micahg> infinity: there's an open FFe request on it
 * micahg wonders if powerpc will catch up by the time the rebuild is  done :-/
<infinity> doko: Almost nothing build-deps on clang, I don't see that as a blocker.
<infinity> micahg: The rebuilds tend not to include PPC for capacity reasons.
<micahg> infinity: I know, was making a point still :)
<doko> infinity, but llvm-defaults ...
 * micahg thinks PPC has been chugging for a week straight
<infinity> doko: Oh, yeah, there's that.  I'll poke at it today.
<micahg> stgraber: could you mark the MPs above for me please?
<stgraber> micahg: sure
<stgraber> micahg: done
<micahg> stgraber: thanks
<highvoltage> =/win last
<micahg> cjwatson: can I leave Bug #433897 in your hands and unsubscribe sponsors?
<ubottu> Launchpad bug 433897 in console-setup (Ubuntu Quantal) "at boot, the font is not set by the upstart job" [High,Confirmed] https://launchpad.net/bugs/433897
<cjwatson> micahg: Yes
<micahg> cjwatson: thanks
<micahg> rsalveti: since you're core-dev now, can I unsubscribe sponsors from Bug #1034734 and leave you to file any needed paperwork and/or upload?
<ubottu> Launchpad bug 1034734 in flash-kernel (Ubuntu) "flash-kernel shouldn't prompt the user when updating initramfs in case there's no valid /etc/fstab" [Medium,Confirmed] https://launchpad.net/bugs/1034734
<rsalveti> micahg: sure, thanks
<micahg> rsalveti: thanks
<slangasek> smoser: virtual-filesystems blocked> interesting; will look
<smoser> thanks. i should point out that that boot was with a kernel/initramfs from precise.
<smoser> and that currently my iscis root seems busted in quantal using quantal initramfs and kenrel (i think open-iscsi changed somehow)
<smoser> debugging that.
<smoser> but i doubt kernel/initramfs affected you
<adam_g> http://paste.ubuntu.com/1199108/ <- is this error obvious to anyone? the same package installs fine and dandy on quantal, but often borks on precise
<cjwatson> adam_g: File collision between those two packages.  Either quantum-plugin-openvswitch-agent is supposed to be taking over a file from quantum-plugin-openvswitch in precise (in which case it needs a Replaces field and probably Breaks too; not Conflicts) or else this is an accident in which case remove the file from quantum-plugin-openvswitch-agent.
<cjwatson> Since those two packages have the same version I suspect you're accidentally installing it in both.
<infinity> Somewhat telling that it appears to be a directory in one of the packages.
<infinity> When the path certainly implies that it should be a binary.
<adam_g> cjwatson: the only reference to that file is in quantum-plugin-openvswitch-agent.install: bin/quantum-openvswitch-agent usr/bin. but at some point somehow, a directory is created @ /usr/bin/quantum-openvswitch-agent/
<cjwatson> Point me to the whole source package and I'll have a look.
<cjwatson> The error message suggests that the bogus directory is in quantum-plugin-openvswitch, not in quantum-plugin-openvswitch-agent.
<cjwatson> So I doubt quantum-plugin-openvswitch-agent.install is relevant.
<adam_g> wsure
<trism> in the precise package quantum-plugin-openvswitch package: ./usr/bin/quantum-openvswitch-agent/quantum-openvswitch-agent but in quantum-plugin-openvswitch-agent it is in /usr/sbin/quantum-openvswitch-agent
<adam_g> theres a packaging branch at lp:~openstack-ubuntu-testing/quantum/quantal-folsom-proposed and a src pkg @ https://launchpad.net/~openstack-ubuntu-testing/+archive/folsom-trunk-testing/+files/quantum_2012.2%2Bgit201209102130~precise-0ubuntu1.dsc
 * cjwatson branches
<infinity> bin/quantum-openvswitch-agent usr/bin/quantum-openvswitch-agent
<infinity> From debian/quantum-plugin-openvswitch.install
<cjwatson> Your source package does not match your branch
<infinity> That's almost certainly not what you want.
<cjwatson> The source package has the file infinity quotes
<cjwatson> Or rather that line in it
<cjwatson> The branch does not
<adam_g> wow, thanks
<adam_g> it was an issue of two packaging branches diverging on that one .install file, is all. thanks much
<slangasek> smoser: can you get a mountall --verbose log from this?
<smoser> slangasek, yeah.
<smoser> slangasek, well, second attempt got http://paste.ubuntu.com/1199190/ to kern.log
<smoser> (and apparent "working".)
<smoser> mountall --verbose output seems to not get to my serial log when i do 'console=/dev/ttyS0' and '--verbose' added to the mountall job (exec mountall --verbose --daemon $force_fsck $fsck_fix)
<slangasek> smoser: ah, this doesn't seem to include the output from mountall itself though :)  maybe capture that output to /run/mountall.log and capture that file?
<smoser> is /run guaranteed mounted ?
<slangasek> smoser: er... do you have an initramfs?
<smoser> yes
<smoser> so, yeah.
<smoser> k.
<slangasek> smoser: yep. alternatively, comment out the 'console output' and pick it up from /var/log/upstart/mountall.log after boot (upstart will buffer)
<smoser> slangasek, so is this not a bug that 'console output' does not infact get to console= kenrel param ?
<slangasek> smoser: probably
<smoser> slangasek, well this stinks.
<smoser> i can't make it fail like that original log i sent.
<slangasek> \o/
<slangasek> NOTABUG ;)
<smoser> do you see anything in that log that would indicate i just did something wrong ?
<smoser> i guess th emountall changes did make this more potentially racey
<smoser> but previously it was always fail or pass
<smoser> ok. well i think the thing to do here, as this seems to be "fixed" is to go on, assuming i made a mistake originally.
<smoser> and see if i cant get more clean reproducing of it.
<slangasek> smoser: I didn't see anything in the log that pointed to a problem; if you *can* reproduce it again, and only intermittently, I think it's probably a bug in my mountall code
<slangasek> smoser: so... I would like to know if it's reproducible; maybe only reproducible with mountall --verbose disabled :/
<smoser> nah. thats not it.
<smoser> cause i can't reproduce it at all
<slangasek> ok
<smoser> but ther eis a bug in console output
<smoser> upstart definitely stops writing to /dev/console at some point in boot
<smoser> which makes collecting output like this difficult
<doko> Laney, were you caring about mono, and could have a look at https://launchpad.net/ubuntu/quantal/+source/banshee-community-extensions/2.4.0-1ubuntu2 ?
<doko> NBS issue
<smoser> sbeattie, you have a minute? or jdstrand it seems like my http://paste.ubuntu.com/1199239/ isn't right.
<smoser> as it results in dmesg like: http://paste.ubuntu.com/1199242/
<micahg> why does pkgbinarymangler copy Enhances lines?
<alexbligh1> what is the approved way to produce an autoconf/automake package that also builds on (e.g.) Lucid where there is no dh_autoreconf, assuming the products of autoreconfig are not in the source package?
<micahg> alexbligh1: in archive or PPA?
<alexbligh1> micahg, currently for me, but would like to be in universe (guacamole)
<alexbligh1> (does not build on Lucid)
<micahg> alexbligh1: unless you're pushing to the lucid main archive (-updates/-security), dh-autoreconf is in lucid-backports
<alexbligh1> micahg, oh sorry, I want it to build without the user having to install dh-autoreconf etc. if possible.
<micahg> alexbligh1: hrm?  it's a build time dependency
<alexbligh1> what I'm asking is 'how did this used to work?'
<alexbligh1> yeah I want to make it not a build time dependency :-)
<tumbleweed> alexbligh1: why should the usres care about build time dependencies?
<micahg> you can read the manpage to see what it does, but I don't see why it matters
<tumbleweed> how it used to work involved a fair amount of pain (if you want to be able to clean up again)
<doko> roaksoax, see component-mismatches again, now zui3 pops up recommending javascript-common ...
<doko> yui3
<sbeattie> smoser: hrm, not sure. what happens when you run the apparmor_parser on /etc/apparmor.d/usr.sbin.dhcpd directly (e.g. sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.dhcpd)?
<Laney> doko: weird. hyperair: ^^^ ?
<alexbligh1> tumbleweed, micahg hmmm, just trying to make it easy to build from source but maybe lucid-backports is the way to go. I am taking it that then 'dh --with autoreconf' will work without also having to use debhelper >= 8.0? (I had assumed these were liked)
<alexbligh1> s/liked/linked/
<tumbleweed> they aren't linked
<smoser> sbeattie, it exits zero
<doko> Laney, hyperair? I did make the rebuild because of the updated libtaglib-cil
<roaksoax> doko: taking care of it now
<alexbligh1> tumbleweed, fair enough, sounds like lucid-backports is the way to go then.
<smoser> and
<smoser> [  994.961021] type=1400 audit(1347390084.089:18): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/dhcpd" pid=666 comm="apparmor_parser
<sbeattie> smoser: yep, that's cool, just making sure it didn't report an error
<smoser> yeah.
<smoser> ok so it seems maybe ijust *thought* it was complaining.
<smoser> sbeattie, what do you think about  my selection of '#include' filename there?
<smoser> is there a better conventional name than usr.sbin.dhcpd.d ?
<sbeattie> smoser: I think the name itself is okay, was just trying to determine if there was a better location (subdir) for that directory
<sbeattie> smoser: though I guess apache2.d is top level as well.
<sbeattie> smoser: I guess you could just call it dhcpd.d based on the apache2.d precedent
<smoser> that is what jdstrand suggested
<smoser> but it seemed strange to me to have a 'usr.sbin.dhcp', local/usr.sbin.dhcp, and then just 'dhcpd.d'
<smoser> but i'm good with that.
<smoser> i'll test that it seems to do what i think it does. thanks.
<sbeattie> smoser: yeah, that inconsistency bugs me a little, having them in the toplevel /etc/apparmor.d/ directory bugs me as well.
<bdrung> cjwatson: ncurses still appears on https://launchpad.net/ubuntu/oneiric/+queue?queue_state=1
<infinity> bdrung: Accepted.
<infinity> bdrung: Looks like Colin ran the fancy "tell the bug about it" script, but forgot to actually accept.
<infinity> cjwatson: ^
<bdrung> infinity: thanks
<smoser> stgraber, https://code.launchpad.net/~smoser/ubuntu/quantal/isc-dhcp/maas-lp1049177/+merge/123815 is my isc-dhcp changes.
<stgraber> smoser: thanks
<cjwatson> infinity: er, that's confusing.  I definitely typed the queue command ...
<cjwatson> but I no longer have that terminal open.
<infinity> cjwatson: Curious.
<smoser> slangasek, so are you thinking you're going to upload mountall?
<cjwatson> should probably make sru-accept do it all.
<smoser> i'll give it a quick test here in lxc container too, which would be a nice fix.
<infinity> cjwatson: And yeah, sru-accept should do it all.  Which would have the advantage of being able to remove the silliness about versions and bugs.
<infinity> cjwatson: Since we could examine the .changes in the queue and pull those two things.
<cjwatson> indeed.
<infinity> And it could helpfully error the heck out if it finds multiple copies of $source in $queue.
<infinity> I'd probably pay beer for that feature.
<infinity> Good beer.
<infinity> Fancy stuff, made by monks.
<stgraber> smoser: I'm still in the middle of regression testing my next bridge-utils upload, but I think I'll have enough time left to start poking at isc-dhcp today (maybe even upload it if I'm lucky)
<micahg> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #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> fabo: so the qemu-linaro stuff doesn't get lost, I unsubscribed sponsors since we can't upload yet, but you'll need to fill out the FFe paperwork since we're past feature freeze
<micahg> fabo: and then subscribe ubuntu-release
<Laney> doko: wtf, it built fine locally and then on the buildd when given back
 * Laney plays the x-files theme
<Laney> skew with banshee?
<smoser> stgraber, i moved https://code.launchpad.net/~smoser/ubuntu/quantal/isc-dhcp/maas-lp1049177/+merge/123815 from ubuntu-devel to you
<smoser> to avoid the chance that someone just thinks its easy andthey'll take it
<stgraber> smoser: cool, thanks
<stgraber> smoser: branch looks good, merged
<doko> Laney, maybe, that was uploaded before
<mlankhorst> cjwatson: can you remove nomodeset in recovery from grub-common? :-)
<smoser> slangasek, more info in bug 1031065 on mountall fix
<ubottu> Launchpad bug 1031065 in cloud-init (Ubuntu) "cloud-init-nonet runs 'start networking' explicitly" [Medium,Triaged] https://launchpad.net/bugs/1031065
<stgraber> mlankhorst: it's there on purpose
<stgraber> mlankhorst: IIRC I even added a warning saying that the resume option won't quite work for these using kms and that a full reboot would be required in such case
<mlankhorst> stgraber: yes and right now it will be even more harmful to keep the nomodeset since no driver really tests that path any more and we could always force a fallback to modesetting driver before vesa
<stgraber> mlankhorst: maybe slangasek or cjwatson will remember better than I do, but I believe the problem was that on some systems you couldn't get to friendly-recovery unless you were in text mode
<stgraber> mlankhorst: so it was decided that having friendly-recovery working was more important than having the resume boot function working
<mlankhorst> well maybe drm could be taught to pick up on noaccel instead
<cjwatson> mlankhorst: I've got an idea, how about the X team agree on this? :-)  It's there because bryceh and RAOF asked for it
<cjwatson> Now admittedly that predates the modesetting driver, but still, sort it out among yourselves ;-)
<stgraber> ;)
<mlankhorst> oh should be easy then
<mlankhorst> too tired, ill try tomorrow
<cjwatson> it was two UDSes ago I think
<dobey> anyone around who knows about langpacks and translations?
<dobey> infinity: do you? :)
<dobey> so upstream has translations included, which weren't before, and i want to make sure i'm doing the dh_translations and packaging correctly for something where the translations end up in the langpacks
<hyperair> hmm it doesn't look like bce actually requires taglib-sharp.
<hyperair> on the other hand, i broke the pc files in taglib-sharp
<hyperair> ah hang on, -2 should be right
<Laney> it does, but it's fixed
<Laney> apart from armel
<hyperair> weird
<hyperair> looks like a mono bug.
<hyperair> it says internal mono exception.
<Laney> yes
<hyperair> sorry, internal compiler error
<hyperair> hmm
<dobey> hi jbicha
<jbicha> dobey: hi
<hyperair> ah, bce doesn't really require new taglib, but banshee's .pc requires it.
<hyperair> hence the builddep.
<dobey> jbicha: did you see my new mail to ubuntu-doc today? wondering what you think of that
<hyperair> doko: are you handling the rest of the taglib-sharp rebuilds?
<dobey> hrmm, wonder if i should just upload this now as i have it, or wait for someone more knowledgeable about how langpacks/translations work in ubuntu to come along so i can bug them
<jbicha> dobey: I +1'd the logo tweak if it'll land soon :)
<dobey> jbicha: yeah. it's a new source package so will be a little bit more than a simple upload. but should have it uploaded in the morning. thanks
<dobey> it is unfortunately past my EOD at this point, so i really need to go right now though. :(
<jbicha> that's fine
<hyperair> Laney: so now that we've gotten the gconf issues out of the way, i can has banshee FFe?
<Laney> if you forward it to gconf upstream then I will upload it and then yes
<doko> hyperair, Laney: I don't think there are any more
<hyperair> doko: there aren't? okay then
<doko> not according to http://people.canonical.com/~ubuntu-archive/nbs.html
<hyperair> ok
<hyperair> Laney: honestly this bug looks like it should be marked as high priority. could we just upload the patch while waiting for upstream to ack it?
<hyperair> (i've forwarded it already)
<Laney> i didn't ask for them to ack it
 * hyperair doesn't want to see more duplicates of this bug report.
<hyperair> ah
<Laney> "if you forward it"
<hyperair> okay i've forwarded it, so hurry up and upload it already. =D
<Laney> i'll look at it tomorrow.
<Laney> (or get someone else here to do it now)
<hyperair> ...
 * hyperair goes back to sleep
<Laney> ajmitch is around :-)
 * hyperair grumbles.
<hyperair> i've got another half an hour of sleep to catch before i have to get to work
<ajmitch> Laney: ajmitch is working in between commenting on irc :)
<infinity> Laney: Where are you seeing armel/mono issues?
<Laney> infinity: on the banshee-community-extensions build
<Laney> hyperair: alright I'll do it now, just for you
<infinity> Laney: I'd give good odds that rebuilding the sad packages on a machine with a precise kernel will work.
 * infinity looks.
<Laney> infinity: Did they not all get upgraded already?
<Laney> going go to with 'no'
<infinity> Laney: No.  I'm harassing people harder to get it done.
<Laney> do we know which ones are good, then?
<infinity> Laney: caph, iara, sigbin.
<infinity> Laney: Retrying right now.
<Laney> caph got it, so fingers crossed
<infinity> Yes, that was intentional. :P
<infinity> Laney: We do output uname at the top of the build logs, so no need to guess.
<infinity> Laney: With either weird compiler confusion, or the lovely "this kernel is too old" message, checking the log for the kernel used and blaming natty if it's not 3.2.0 is always a good first step. :P
<infinity> Laney: (But I really do hope they all get upgraded by the end of the week and I can stop caring)
<infinity> Laney: Or, anything that vaguely relates to atomics.
<Laney> Not caring would be good
<Laney> hyperair: it is up
<infinity> Laney: (Which is actually what mono fails on more than not
<infinity> )
<Laney> now where's that FFe?
<infinity> Laney: Debian armel is going to have this exact same issue when they move to gcc-4.7 without updating all the buildd kernels, I really hope we can get all our ducks in a row on that.
<infinity> Laney: (Basically, gcc-4.7 or, in our case, 4.6+ (because we use some backported pathces) use kernel helpers to emulate some armv7 bits for homogenous atomic fun, so both armel ports explode miserably on this if the kernel is too old (>>3.1) to support that)
<infinity> s/>>/<</
<infinity> armhf, luckily, is fine, since it's armv7 by default, so doesn't invoke the helpers.
<infinity> Laney: Of course, this build failure could just be mono being generally sad, but I'm betting not.
<Laney> No, I think we had it with something else before
<Laney> looks like wheezy will have a good enough kernel, so Debian should (be able to be) alright
<infinity> Yeah, I didn't bother to read the log, I'm just assuming it's atomics.
<infinity> If it fails on caph, I'll look more closely.
<infinity> Laney: wheezy's kernels are fine, but the buildds may well not all be running them.
<infinity> Laney: But we'll cross that bridge when we get to it, it only starts mattering in jessie.
<Laney> will armel matter for that long?
<infinity> Given that Debian would like to suppose pre-v7 hardware, I'd say so.
<infinity> support, too.
<infinity> Stupid fingers.
<infinity> I'm sure we'll drop armel in Debian "some day", but that day's certainly not now, there's a ton of v5 and v6 stuff with retail availability still.
<infinity> Laney: Yep, looks like that fixed it.
#ubuntu-devel 2012-09-12
<doko> great, new poppler upload obsoleting today's maint+1 work
<hyperair> Laney: yay thanks
<infinity> doko: Heh, I was just complaining about that in #-release :P
<doko_> <infinity> Oh, thank god, I was worried we might go a whole month without a poppler ABI bump.
<doko_> <infinity> I wonder if maybe we should rename PlusOneMaint to PopplerAndEDSMaint.
<doko_> <doko> just staff two people from -desktop for the team, there's not much to do for -foundations
<TheMuso> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #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
<needhelp1>  Hello all, im helping to pull some data for Ubuntu Beta releases and have a very short survey up on google documents found here. https://docs.google.com/spreadsheet/viewform?formkey=dFdSTUgzREoyeFZNSWRHSjlXMGYteGc6MQ    Anyone interested please take the survey and feel free to share the link. The results will be published in two weeks to the public domain.
<sladen> needhelp1: could you publish some context (who you are;  what it's for (eg. Thesis research, graphics design)
<sladen> needhelp1: many people are unlikely to click random URLs, so you may end up missing out on results (but that depends on who your target audiences is, and we don't know that either!)
<needhelp1> sladen, im a college student
<needhelp1> sent you a pm also
<sladen> nb ^^, there's more context at http://nathanheafner.com/home/2012/09/11/ubuntu-beta-users-survey/
<lifeless> cjwatson: do you need another test from me ?
<pitti> Good morning
<fabo> micahg: thanks. dannf reported a recent bug and we rebased on latest upstream release 1.2.0. an update package should be submitted soon.
<TheMuso> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #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
<rose7676> help
<rose7676> The following packages have unmet dependencies:
<rose7676>  fglrx : Depends: xorg-video-abi-11 but it is not installable
<rose7676>          Recommends: fglrx-amdcccle but it is not going to be installed
<rose7676> E: Unable to correct problems, you have held broken packages.
<rose7676> ?
<pitti> rose7676: not much you can do right now -- current quantal fglrx driver is broken
<pitti> you need to wait until a compatible one gets uploaded, and use the free one until then (do give it a try, it shoudl work well)
<rose7676> pitti, The following NEW packages will be installed:
<rose7676>   fglrx-amdcccle nvidia-current-updates
<rose7676> 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
<rose7676> Need to get 73.7 MB of archives.
<rose7676> After this operation, 215 MB of additional disk space will be
<rose7676> ????? nvidia-current-updates
<pitti> mvo: ^ what was the magic again to ask apt to be verbose about dependency resolution?
<pitti> rose7676: what did you try to do, dist-upgrade?
<rose7676> 12.04
<rose7676> and 12.10
<mvo> pitti: -o Debug::pkgProblemResolver=true -o Debug::pkgDepCache::AutoInstall=true
<mvo> pitti: I guess we should add a --debug-resolver shortcut actually
<mvo> pitti: to make this more acessable
<pitti> that'd be great
<dholbach> can somebody please reject https://code.launchpad.net/~vpilvio/ubuntu/quantal/gpiv/typo-fix/+merge/123450?
<dholbach> shadeslayer, I'm not sure what to do with https://code.launchpad.net/~andreagrandi/ubuntu/quantal/kdevelop-custom-buildsystem/typo-fix/+merge/121225
<pitti> dholbach: done
<dholbach> thanks
<shadeslayer> ugh, I forgot about kdevelop .... it's in my PPA atm, need to include that fix
<shadeslayer> can I assign code reviews to myself?
<shadeslayer> hmm ... can't even subscribe myself
<dholbach> shadeslayer, I added you to it
<shadeslayer> thx
<cjwatson> lifeless: nothing more to test right now; I tried to set up a simpler reproduction environment (just linear dmraid), but it passed; so I think this is specific to striped, and I need to remember how to set that up
<ev> mpt: we finally finished the deployment: https://errors.ubuntu.com/
<mpt> \o/
<ev> I'm most annoyed by that unchecked-by-default teams checkbox
<mpt> ... I see no checkbox
<geser> looks great
<ev> mpt: when you are thrown into the openid check
<geser> is there an explanation for the colors in the ranking table?
<mpt> heh
 * ev metaphorically bangs his head on the desk
<mpt> geser, we're trying to work out how to do without one, but haven't succeeded yet. In the meantime: grey = not observed in the latest version, red = supposedly fixed but observed since.
<shadeslayer> dholbach: can I close branch merges with the changelog?
<shadeslayer> or is that only for boogs
<dholbach> shadeslayer, no, but you can mark it merged (or merge the branch via bzr and it should(?) get auto-merged)
<mpt> ev, I just realized that if the default table is top errors for all Ubuntu users, eventually a majority may fall into the "not observed in the latest version" category, because they'll be in old releases but not the development release. Already it's 41/100.
<ev> hmm yeah
<mpt> ev, I suppose that could be refined to "not observed in the latest version on the same release".
<ev> how would you do that though?
<ev> oh
<shadeslayer> dholbach: Actually, there's a new upstream bugfix release that I'm planning on uploading
<dholbach> cool
<geser> mpt: is it intended that the bug link doesn't point to the "master" bug for duplicated bugs? (like for the jockey-gtk entry at rank 11 which also points to a private bug where I first thought it was a broken link because I wasn't logged in into LP)
<lifeless> geser: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/764414
<ubottu> Launchpad bug 764414 in apport (Ubuntu) "private master bugs are confusing and lead to more duplicate filings" [Wishlist,Triaged]
<geser> lifeless: in this case the master bug is public, but errors.u.c links to 927985 (which is private) instead of 734376 (master and public)
<mpt> geser, I don't know how that part works, sorry, ask ev
<lifeless> geser: oh, thats interesting, and unusual.
<jamespage> doko_, just finishing up a rebuild test for java 7 - FTBFS now look much better but > 150 packages build bytecode for >= Java 7 only
<shadeslayer> dholbach: will be fixed once I QA everything from : https://launchpad.net/~rohangarg/+archive/experimental/+packages
<ev> geser: I'll look into it shortly
<xnox> ev++ good deployment of errors, hunting some info down now.
<ev> xnox: cheers
<ev> geser: so the information for that comes from apport's crash-digger
<tjaalton> infinity: so, the touchpad hotkey mess is due to acpi-support. /etc/acpi/asus-touchpad.sh gets triggered as well, and it can mess things up if it's a synaptics touchpad..
<tjaalton> also, if you happen to have the touchpad disabled setting in g-s-d and boot the machine up, there is no user-friendly way to get the touchpad working again, since the properties are flip-flopped so it'll always be disabled (nice that synaptics has two properties to disable the device..)
<tjaalton> g-s-d does the right thing
<tjaalton> pitti: what happened to https://blueprints.launchpad.net/ubuntu/+spec/acpi-support-deprecation :)
<pitti> tjaalton: I guess it died off at the last mile :(
<tjaalton> yeah :/
<tjaalton> was wondering why one laptop with Alps worked fine, and the other with synaptics hit these weird issues, but it was because asus-touchpad.sh doesn't recognize Alps :)
<silverarrow> hi
<silverarrow> is it possible to track down why a video streams when it is not suppose to ?
<silverarrow> I mean, figuring out what is working more than all the error messages
<didrocks> jamespage: just to double check, the packages you want in main in addition to those that already promoted are radosgw and python-ceph, right?
<jamespage> didrocks, yes please
<didrocks> jamespage: doing the promotion now
<jamespage> ta
<didrocks> yw :)
<jamespage> didrocks, BTW I just hit a bug in radosgw on armhf - bug 1049582
<ubottu> Launchpad bug 1049582 in ceph (Ubuntu) "radosgw crash on armhf architecture" [Undecided,New] https://launchpad.net/bugs/1049582
<jamespage> it works just fine on x86 - I will raise this with upstream today - have a call later on
<didrocks> jamespage: ok, I don't block on that then, trusting you to keep track :) promoted
<didrocks> jamespage: btw, looking at the python-ceph package, it can certainbly be arch: all (if you have another upload to do)
<didrocks> but no hurry :)
<jamespage> didrocks, ack
<jamespage> I'll put that on my list TODO
<didrocks> thanks
<doko> jamespage, you did disable the openvswitch-datapath-dkms package in openvswitch, however xcp-networkd still depends on it. should the dependency just dropped?
<jamespage> doko, I did because its broken in quantal; however I think zul was looking at fixing it up again to work with the 3.5 kernel
<doko> jamespage, could you track this? it shows up in NBS
<jamespage> its provided by the kernel; so thats probably a reasonable course of action if we can't ressurect this
<jamespage> doko, sure - leave it with me
<doko> thanks
<doko> janimo, ping
<janimo> doko, hi
<doko> jamespage, the 150 bytecode for 7 packages are no good. I assume these are all packages which don't use one of the helper tools for the build?
<jamespage> doko, I suspect so - maven stuff will be OK; javahelper to
<jamespage> they will probably all be ant/Make custom builds
<jamespage> doko, I have the list - will be raising bugs soon
<jamespage> like today
<doko> is there already a lintian check?
<jamespage> doko, yes - and experimental one "incompatible-java-bytecode-format" - thats what I've been checking for
<jamespage> doko, http://paste.ubuntu.com/1200436/
<doko> jamespage, sort by source/component would be nice
<jamespage> I think about 7 of those are in main
<jamespage> I will do that - just trying to finish something else first
<pitti> meh - if there is one package that really benefits from -proposed uploads, it's eglibc..
<ogra_> too late
<smagoun> didrocks: Hi, I don't understand why you marked bug 1040839 'Fix Released'. You comment makes it sound like it should be marked "WontFix".
<ubottu> Launchpad bug 1040839 in thunderbird-couchdb (Ubuntu Quantal) "Thunderbird hangs accessing eds on startup" [High,Fix released] https://launchpad.net/bugs/1040839
<didrocks> smagoun: the hanging was because the protocols don't match, so it's either updating the API or removing the component (that is not supported)
<didrocks> smagoun: more a semantic discussion, if you prefer to set it won't fix, please do :)
<smagoun> didrocks: right. Have either of those changes happened in Q? If not, the fix is not released
<smagoun> It's a pretty bad bug....IMHO we at least need to remove thunderbird-couchdb
<didrocks> smagoun: that's what I did and hence I changed the status
<ogra_> cant you just add a Breaks: <= libedataserver-1.2-15 to thunderbird-couchdb ?
<ogra_> so that they cant be installed together
<didrocks> ogra_: well, there is no more upstream for it, nobody will maintain it and port to the new API
<didrocks> (which is quite an extensive change)
<ogra_> oh, you mean tb-couchdb
<didrocks> yep
<smagoun> didrocks: So thunderbird-couchdb will be removed during an upgrade from 12.04-12.10? That is good. It wasn't clear from your comment that you made that change
<ogra_> ah
<chrisccoulson> will removing it from the archive guarantee that it's removed on upgrade?
<didrocks> smagoun: yeah, sorry, it will when people choose "remove obsolete packages" as part of the update-manager process
<chrisccoulson> didrocks, hmmm, we probably want to guarantee that it gets removed
<didrocks> chrisccoulson: you can add a breaks to ensure people using apt-get dist-upgrade to have that done
<didrocks> s/to//
<chrisccoulson> yeah, i don't mind
<didrocks> I think it will be best :)
<smagoun> +1 for guaranteeing removal
<smartboyhw> Can someone tell me which channel is/are the best on fixing bugs, I need it to write Ubuntu Accomplishments
<mr_pouit> mterry: lightdm-set-defaults doesn't work as expected with your patch: show_remote_login is TRUE in lightdm by default but FALSE in lightdm-set-defaults
<mterry> mr_pouit, ah, so it sets remote to false too easily?
<mr_pouit> mterry: also, lightdm-set-defaults --keep-old --show_remote_login=false/true doesn't do anything
<mterry> mr_pouit, regarding the false-by-default in set-defaults, I thought set-defaults doesn't set anything unless it's specified by user?
<mr_pouit> mterry: yeah, my first statement is probably wrong because of the second one: --keep-old and --remove don't do anything with --show-remote-login (lightdm.cinf is never updated)
<mterry> mr_pouit, is it broken with manual-login too?  (I cargo-culted the manual login treatment, so I'm curious if this is a general error or something I did)
<tsdgeos> can someone make https://bugs.launchpad.net/bugs/1026164 public?
<ubottu> Error: malone bug 1026164 not found
<tsdgeos> i just got thrown there when trying to report a bg
<mdeslaur> tedg: please get someone to fix LP: #1049849
<mdeslaur> bug 1049849
<ubottu> Launchpad bug 1049849 in lightdm (Ubuntu) ""Remote Login" account not confined by guest AppArmor profile" [Undecided,New] https://launchpad.net/bugs/1049849
<tedg> mdeslaur, Okay, how do I test that?
<mdeslaur> tedg: hold on, I'll add steps to reproduce in the bug
<tedg> mdeslaur, Thanks!
<mdeslaur> tedg: ok, steps added. thanks!
<mr_pouit> mterry: it's a general error for booleans apparently (update_boolean() doesn't do what's needed compared to update_string())
<mterry> mr_pouit, yeah, good point.  It's noticably not caring whether an existing value is there
<dholbach> thanks xnox for replying to that tweet
<xnox> dholbach: your welcome. It's not "true" LDAP integration, but it does at least work these days.
<dholbach> great
<dholbach> thanks
<smoser> anyone aware of this: http://paste.ubuntu.com/1200691/
<smoser> python-twisted is currently uninstallable
<smoser> doko, you apparently copied that from debian recently?
<doko> smoser, working on it
<smoser> thank you.
<micahg> slangasek: Bug #1049840 is broke since precise-updates is higher than quantal for nspr
<ubottu> Launchpad bug 1049840 in ia32-libs (Ubuntu Quantal) "ia32-libs-multiarch wrong dependancies on quantal 64bit" [Undecided,Incomplete] https://launchpad.net/bugs/1049840
<slangasek> micahg: should that be a pocket copy?
<micahg> idk, I haven't reviewed the changes
<micahg> either a pocket copy or a no change rebuild if the changes don't apply
<micahg> hrm, either way it should probably be rebuilt on quantal though
<micahg> slangasek: looks like no change rebuild is the way to go, are you already doing it, or should I?
<slangasek> micahg: I'm uploading
<micahg> ok, thanks
<infinity> tjaalton: *poke*
<tjaalton> infinity: *dodge*
<infinity> tjaalton: Feel an urge to limit intel-gpu-tools to "amd64 i386"?
<tjaalton> infinity: probably makes sense
<infinity> (I was about to do that for the Ubuntu package, and noticed you're just releasing from Debian git anyway)
<infinity> tjaalton: "any-amd64 any-i386" might also make sense, except that it doesn't appear to love non-linux arches anyway, from what the Debian build logs are showing me.
<infinity> tjaalton: So, yeah, "amd64 i386" is probably right.
<tjaalton> yeah I'll add just those
<infinity> tjaalton: Danke.
<tjaalton> infinity: dunno if you saw, but the hotkey issue was with acpi-support. bug 804109 has the details
<ubottu> Launchpad bug 804109 in acpi-support (Ubuntu) "remove/edit racy /etc/acpi/asus-touchpad.sh" [Medium,Triaged] https://launchpad.net/bugs/804109
<infinity> tjaalton: Fun, fun.
<tjaalton> it shouldn't do anything for synaptics devices, ok to keep the hack for evdev using touchpads until g-s-d handles them
<infinity> tjaalton: Maybe I'll fix it (the intel-gpu-tools thing) in Ubuntu right now for my own sanity on the FTBFS/dep-wait list, and you can just commit to Debian git later.
<tjaalton> I've done the commit already
<tjaalton> and merge
<smoser> slangasek, ping
<tjaalton> uploaded too :)
<infinity> tjaalton: Oh, shiny.  Thanks.
<jamespage> slangasek, ever have one of those days with a package?  I can't seem to get samba right
<jamespage> so --upstart-only should only be used when the upstart configuration is NOT replacing a init script with the same name?
<jamespage> I did not get that from the man page
<slangasek> smoser: hey there
<slangasek> jamespage: correct - sorry for the bad documentation :)
<smoser> slangasek, i'll get you access to a system to poke around if you dont mind
<smoser> for bug 1031065
<ubottu> Launchpad bug 1031065 in cloud-init (Ubuntu) "cloud-init-nonet runs 'start networking' explicitly" [Medium,Triaged] https://launchpad.net/bugs/1031065
 * jamespage goes todo another samba upload
<slangasek> jamespage: in a cycle or two it'll be obsolete anyway
<slangasek> smoser: I have very little time to look at it right now due to the management sprint, but if you can give me a system that'll be up for a few days that I can poke at when I get a chance, that'd be great
<smoser> sure
<smoser> i'll send you info
<jamespage> well actually that will be tomorrow now...
<tjaalton> hit bug 983543 while trying to dist-upgrade to quantal
<ubottu> Launchpad bug 983543 in eglibc (Ubuntu) "Internal Error, No file name for libc6" [Undecided,Confirmed] https://launchpad.net/bugs/983543
<ev> mpt, bdmurray: so we don't have a "link to an existing bug" link
<ev> as bdmurray has noticed
<ev> I'm wondering if we can get away with just telling people to dup whatever they've done to the errors created bug
<infinity> tjaalton: Hrm.  I've seen that once (thought it was libstdc++, not libc) on an aborted upgrade.  Rest of the system was fine, apt was in a tizzy.  Not entirely sure where to reassign it, or even how to reproduce it (and almost certain it's not glibc's fault).
<infinity> tjaalton: If you have any meaningful way to actually make it happen reliably, I'd love a reproducer.
<ev> or if we need to provide a pair of "create / link to existing" links
<tjaalton> infinity:  yeah it's misfiled
<mpt> ev, I can suggest how to present either of those, but which one of them to do is out of my ambit
<xnox> ev: well we need a link that takes it to ~ page as apport does where you can search or file new.
<xnox> ev: that doesn't help with linking up though =(
<mpt> ev, because I don't know how noisy auto-generated bug reports would be.
<mpt> (And therefore how good an idea it is to auto-generate them.)
<bdmurray> ev: there is also the issue regarding traceback and line numbers for source code changing.  so there may already be an existing bug in launchpad just with different line numbers that is already triaged / assigned/ fixed.
<ev> xnox: please rephrase - I don't follow
<ev> mpt: you indirectly raise an interesting point
<bdmurray> and marking that as a duplicate of the errors created bug seems less efficient
<ev> we're going to be autogenerating bugs for the top X crashes
<cjwatson> I've never really understood how I'm supposed to take an existing errors report and arrange for there to be a bug for it, if I'm not actually encountering it myself
<ev> so how does that play in? Are they just forced to dup when one exists, but provided with a "create / link" links otherwise?
<cjwatson> I don't know about the linking bit, but I would find a creation-on-request facility extremely helpful
<ev> cjwatson: that just landed - there are "create" links in the bug columns
<ev> as of today
<ev> it wont show up for failed to retrace bugs - marked with "failed:" on the front of the signature
<cjwatson> Ah
<cjwatson> There are no create links in the page I have loaded
<cjwatson> But trying to write 40GB to USB means my entire system is rather slow so it's hard to chec
<cjwatson> k
<cjwatson> Oh yes, I see them now, thanks
<bdmurray> ev: I'm talking about bug 1048830
<ubottu> Launchpad bug 1048830 in Errors "error report without a bug link" [Undecided,New] https://launchpad.net/bugs/1048830
<cjwatson> So I'm interested in the logic of not presenting that for failed-to-retrace bugs
<cjwatson> Because that implies you (consciously or otherwise) think developers can't do anything about them
<ev> cjwatson: I do
<mpt> ev, I don't see the "create" links -- is that because I'm not in the appropriate team?
<cjwatson> Which raises the question of why we're bothering to show them
<mpt> (not that I want to be)
<ev> cjwatson: to raise awareness of how much we need to fix ddebs
<cjwatson> ev: But that isn't true, I've certainly fixed failed-to-retrace bugs in the past because the problem was obvious from the top of the stacktrace
<ev> and how much I need to feed things back through the retracer
<cjwatson> This is an invalid assumption
<ev> cjwatson: fair enough
<ev> it's somewhat complex to fix
<cjwatson> Now admittedly it's a hell of a lot easier with a stacktrace, but ...
<ev> as if we do work out a process to feed things back through the retracer
<ev> we'll need to clean up the bug links too
<cjwatson> Yes, true
<ev> and we might have multiple stacktrace address signatures with "failed:" on the front
<ev> that map to a single crash signature
<ev> and need some way of determining which bug is the master - or just dup them all to it
 * ev digs up the bug number for this re-retracing
<cjwatson> I'm certainly *aware* of how much we need to fix ddebs, but realistically I think the answer is more LP development time in UE
<ev> cjwatson: https://bugs.launchpad.net/daisy/+bug/1044418
<cjwatson> Yeah, I know what you mean
<ev> cjwatson: oh absolutely
<ubottu> Launchpad bug 1044418 in Daisy "Reprocess failed retraces" [Undecided,New]
<ev> and it's as much to remind me as anything else
<ev> I have no doubt that I'll have to play a role in fixing it
<ev> I just want to make sure I'm reminded of the importance of this vs starting up other subprojects on errors
<ev> if we can't see the failed to retrace crashes, then the problem might as well not exist to me
<ev> (it actually used to be this way)
<ev> but I grew worried that it wasn't clear that this was not the entire picture
<ev> at the very least I need to better tag them as such
<ev> as people easily miss "failed:" in the signature
<ev> and I don't mean by putting more text in that line
<cjwatson> Numbers on Ubuntu-specific vs. not in the last day of 12.10 error reports: about 70% Ubuntu-specific vs. 30% not
<ev> hmm?
<cjwatson> Of course that probably needs to be compared with usage to be meaningful
<cjwatson> Sorry, I mean on Ubuntu-specific packages
<ev> oh, vs debian?
<ev> mpt: you're not signed in
<cjwatson> No, as in 70% of reports from the top 100 were in packages developed specifically for Ubuntu
<ev> mpt: you need to click off to a problem page first
<ev> mpt: feel free to provide UI for a login link or a better approach for this
<ev> ahhh
<ev> go us
<xnox> ev: go us.... *sigh*
<ev> cjwatson: I'm entirely happy with being proven wrong on all my points, so long as it's done using data as you've done here :)
<cjwatson> This was roughly my point in the meeting - it suggests that fixing our own problems should be the priority, not worrying about the long tail which is basically absent from errors
<ev> cjwatson: indeed
<ev> that whole thing went off the rails
<ev> I just want us to focus on QA in the immediate moment
<cjwatson> It's probably a bit different for different time periods, but it's unfortunately laborious to count
<ev> not go, "oh, well we're not at feature freeze yet, we can fix this later"
<ev> and never do
<ev> because it's not a LTS
<cjwatson> I don't think that's really what people were saying as such, but anyway
<ev> cjwatson: we do have an API for this...
<cjwatson> ev: Not for "was this package developed specifically for Ubuntu?"
<ev> oh indeed not
<ev> sorry about that
<ev> so before we get too sidetracked
<ev> bug links
<ev> we currently provide create bug links
<ev> do we also provide the ability to manually enter a number
<ev> rather than one being autocreated
<ev> err in addition to
<ev> if one is not already set, that is
<ev> or
<ev> do we rely on duping to the errors created bug
<bdmurray> I say yes and provide bug 1048830 as a reason why
<ubottu> Launchpad bug 1048830 in Errors "error report without a bug link" [Undecided,New] https://launchpad.net/bugs/1048830
<bdmurray> and https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fshare%2Fapport%2Fapport-gtk%3Aconfigparser.DuplicateOptionError%3A%3Cmodule%3E%3Arun_argv%3Arun_crashes%3Arun_crash%3Aui_present_report_details%3Aget_desktop_entry%3Aread%3A_read which should be linked to bug 1048834
<ubottu> Launchpad bug 1048834 in indicator-datetime (Ubuntu Quantal) "configparser crash with indicator-datetime-preferences.desktop" [Medium,Fix released] https://launchpad.net/bugs/1048834
<bdmurray> both of the bugs that I would linke to are already fixed or have lots of work done on them
<bdmurray> and duping those bugs to one created by errors seems silly
<ev> so are these generating different signatures?
<cjwatson> barry: Any progress on bug 1035869?  I noticed it showing up on errors
<ubottu> Launchpad bug 1035869 in computer-janitor (Ubuntu) "computer-janitor crashed with ImportError in /usr/share/computerjanitor/computerjanitord/errors.py: No module named computerjanitor" [High,Triaged] https://launchpad.net/bugs/1035869
<bdmurray> ev: the tracebacks for the software-properties-gtk bug have different signatures yes because the line number in the source code changed
<ev> bdmurray: I'm really weary of moving to launchpad bugs to manage the linkage between problems
<ev> so I'm wondering if we should instead make it possible to merge problems together in the database
<ev> or maybe a combination of the two
<mpt> People still use computer-janitor? Wow.
<ev> that's unfortunate for them
<ev> bdmurray: sorry - I know that's really vague
<ev> my brain is somewhat melted after the meeting
<ev> but suddenly keying the problems we're seeing on something other than the crash signature would be a massive change
<ev> and indeed, something external to the database
<bdmurray> but now we have errors listed that are fixed and don't require more work
<ev> well they're not fixed
<ev> if they were fixed they wouldn't be appearing
<cjwatson> Or they're multiple bugs with the same signature
<ev> I kind of think this goes into the server-side hooks
<ev> we should be able to write code that says, when encountering a signature with data in the report that matches this pattern, put it in this bucket instead
<ev> rather than just into a bucket IDed by the regular crash signature
<micahg> like bugpatterns but for errors.u.c
<ev> micahg: right, we're moving all that server side
<ev> https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-bucketing-improvements
<ev> I don't think that sort of thing should be pushed via apt or include lots of silly "choose a door for punishment" dialogs
<xnox> mpt: thanks to askubuntu.com I now can have rounded corners & joined up buttons with transparent background http://askubuntu.com/questions/185284/how-to-get-rid-of-the-background-gradient-of-the-inline-gtktoolbar/187039#187039
<mpt> win
<xnox> mpt: I had to spend 500 askubuntu reputation points, as only the bounty attracted answers....
<SpamapS> pitti: can you explain the giant upload of translations into the precise-proposed queue? Are we just supposed to wave those through?
<SpamapS> slangasek: ^^
<SpamapS> cjwatson: ^^
 * SpamapS hoping one of those 3 minds will have the answer
 * SpamapS also hoping to clear it up on https://wiki.ubuntu.com/ArchiveAdministration once he knows
<infinity> SpamapS: I was about to mass-accept them.
 * xnox wonders if SpamapS has to click tickboxes 400 times
 * SpamapS will pay $0.01/click .. ;)
<infinity> SpamapS: (accepting now)
<cjwatson> Anyone here happen to be an expert in dmraid?
<cjwatson> I'm trying to re-create Robert's setup in bug 803658 in a VM, using dmraid -C
<ubottu> Launchpad bug 803658 in grub2 (Ubuntu) "grub-install /dev/mapper/isw_$UUID_$NAME0 failing with ICH10R raid 1+0" [High,Fix released] https://launchpad.net/bugs/803658
<barry> cjwatson: not yet, but i have a browser tab open on it :/
<cjwatson> I'm using variations on 'dmraid -f isw -C ARRAY0 --type 01 --disk /dev/sda,/dev/sdb,/dev/sdc,/dev/sdd'
<cjwatson> This ostensibly succeeds, and indeed (reasonably) complains if I give it fewer than four disks
<cjwatson> However, it's evidently written garbage, because 'dmraid -ay' says 'ERROR: isw: wrong number of devices in RAID set "isw_cjehcgig_ARRAY0-1" [4/2] on /dev/sda' (and so on for the other three disks)
<SpamapS> infinity: ok, thanks. So to confirm, thats always just a wave-through?
<infinity> SpamapS: To -proposed, yes.  There's some level of verification that happens before they get to migrate.
<smoser> hallyn, maybe this is expected.
<smoser> but i do an lxc-clone -o source -n new
<smoser> and new has in its config a reference to source's fstab
<hallyn> smoser: no that's a bug
<tjaalton> after dist-upgrade, dnsmasq was listening on 127.0.1.1 but resolv.conf points to 127.0.0.1
<SpamapS> barry: reading through the discussion on http://bugs.python.org/issue15906 ... oh what fun!
<iamfuzz> cjohnston, Hi Colin, what version of live-build do you use for precise/quantal builds?  I'e been fiddling with it and run into issues even with a vanilla build
<cjohnston> :-(
<hallyn> smoser: well, actually, i'm not 100% sure
<infinity> iamfuzz: You wanted cjwatson. ;)
<hallyn> smoser: i think it was left like that for now bc there's a limit to what we can do
<infinity> iamfuzz: And we use the version that's in the archive for each release.
<iamfuzz> tab failure ftw
<smoser> cyphermox, ^ i think you helped me with issues like tjaalton has
<smoser> hallyn, really?
<iamfuzz> infinity, interesting, I had to patch the one in precise just to get it to build anything
<infinity> live-build | 3.0~a24-1ubuntu32.5 | precise-updates | source, all
<infinity> live-build | 3.0~a57-1ubuntu4 |       quantal | source, all
<hallyn> i.e. if we copy over the fstab, then do we also process it?  but if we do that, then we may have to copy over the direcotires mounted in the fstab
<iamfuzz> trying quantal now
<infinity> iamfuzz: It might help to realise that we use the auto/{config,build} scripts from livecd-rootfs (also from the appropriate release).
<hallyn> smoser: i'd almost want to say 'if anything is in there other than proc and sys, refuse'
<iamfuzz> infinity, many thanks, I'll take a look at that, I had been generating mine with lb config
<hallyn> stgraber: ^ did you ahve thoughts on handling of /var/lib/lxc/c1/fstab when it's being cloned?
<smoser> hallyn, sorry
<smoser> bad explanation
<smoser> $ grep $SRCNAME /var/lib/lxc/xm/config
<smoser> lxc.mount  = /var/lib/lxc/source-quantal-amd64/fstab
<smoser> err..
<smoser> well, i didn't mean to paste that
<barry> SpamapS: indeed!  i think we've converged on a plan though, and i'll be landing a followup patch in 2.7, 3.2, and 3.3.1 (won't affect 3.3.0) as soon as the test suites finish
<smoser> but, that is what i opened a bug about
<smoser> https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1049987
<ubottu> Launchpad bug 1049987 in lxc (Ubuntu) "lxc-cloned container breaks if source is later destroyed" [Undecided,New]
<stgraber> hallyn: well, we surely don't want to reference the source container, so we should probably be using the same code I wrote for lxc-start-ephemeral (or rather that I ported to python)
<hallyn> stgraber: in fact, rewrite it in python :)
<hallyn> all right - we have a bug thanks to smoser to address it in
<stgraber> hallyn: that code basically checks for lxc.mount, if it exists and points to a valid file, it's going to create a fstab file in the target and copy the content, replacing any occurence of the source container path by destination container path
<hallyn> stgraber: my fear is, then ppl will have /dev/lxc/container1_p3 being mounted in that fstab, will clone the container, and expect taht to get copied and the copy used
<stgraber> hallyn: well, I suppose I could actually move that logic out of lxc-start-ephemeral and move it to the python overlay by making clone() in python do that by default and add a copy_rootfs=False argument to that function to cover the ephemeral case
<hallyn> i.e. we need to draw a clear, simple line of what we do and don't do
<hallyn> maybe your line works
<hallyn> long as we document it
<hallyn> somewhere
<stgraber> hallyn: yeah... I think copying the fstab makes sense, I'm not a big fan of altering it though. I only did it because that's what lxc-start-ephemeral used to do
<stgraber> hallyn: it was making a lot of sense when we didn't have relative mounts in the fstab, but that's been fixed for more than 6 months now
<stgraber> so maybe we can get away with just copying the fstab as a whole and not actually touch it, which would simplify the code a lot
<stgraber> any special case should then be dealt with using pre-mount hooks
<stgraber> (so if someone really wants some magic to determine what lvm to use, they can do that)
<hallyn> right - the most important thing is to make sure this is documented.  oh hey.  there's no lxc-clone man page
<hallyn> lunch, bbl
<stgraber> hallyn: I also think we really need to spend some time upstream splitting all the storage code into separate scripts that we can simply call from templates, tools, ...
<stgraber> hallyn: having to re-implement btrfs/lvm/... over and over again is really painful at the moment and the source of a lot of bugs
<stgraber> ideally templates should really only care about building a rootfs, they shouldn't do all the storage setup or all the config themselves
<smoser> hallyn, you should just put a macro of some sort in the fstab
<smoser> and let that reference ROOT_DIR or the like
<stgraber> I might start working on clone() in python upstream soon-ish and will make sure we look into the storage backend mess for 13.04
<smoser> then only replace ROOT_DIR
<smoser> and not replace the rendered version
<stgraber> smoser: no need for that, as I said, we support relative mounts
<smoser> ah.ok. thnen yes.
<stgraber> "/tmp/.X11-unix tmp/.X11-unix none bind"
<smoser> and that is much preferred over full paths.
<stgraber> that means, mount /tmp/.X11-unix to /var/lib/lxc/<container>/rootfs/tmp.X11-unix as a bind mount
<stgraber> yep, we just need to make sure everyone uses that :)
<smoser> well, you have an issue there.
 * xnox reads lvm highlights backlog
<smoser> hm.. maybe not.
 * xnox nothing that interested me much....
<hallyn> stgraber: agreed
<arges> infinity, hey you still have time today to chat about the eglibc fma4/avx patches?
<slangasek> smoser: bug #1031065> ok, so you have a network interface but you're not getting a udev event for it.  This is all in lxc, right?
<ubottu> Launchpad bug 1031065 in cloud-init (Ubuntu) "cloud-init-nonet runs 'start networking' explicitly" [Medium,Triaged] https://launchpad.net/bugs/1031065
<slangasek> smoser, hallyn: should we *expect* udev events for network interfaces within a containeR?
<infinity> arges: Yep.
<arges> infinity, cool
 * arges pulls up https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/979003
<ubottu> Launchpad bug 979003 in eglibc (Ubuntu Precise) "libc incorrectly detects AVX support" [High,In progress]
<infinity> arges: So, the first order of business would be to make sure we can drum up hardware and reproducers.
<stgraber> slangasek: we'd like to but it's not the case at the moment. Containers do get udev events once udev is spawned in the container but we don't call udevadm trigger so you wouldn't get event for stuff that happened before udev started.
<infinity> arges: It should be fixed in quantal, and it's fixed in the precise queue (really need to get that reviewed at some point), but I still suspect we can get away with less nasty backports for older releases.
<stgraber> slangasek: rationale for not running udevadm trigger being that as we don't have a device namespace yet, doing so would essentially flood the host and all other containers with udev event for all devices (not only these tied to that specific container)
<arges> infinity I can look into getting hardware
<infinity> arges: But it's hard to say that for sure without being able to test a more limited fix.
<slangasek> smoser: ^^ right, so that's the reason you're getting the delay
<infinity> arges: (Basically, I think we can take the sketchy patch that Debian used and that you attached to the bug for older releases, but only if the FMA4 portion of the bug doesn't exist on << precise)
<arges> infinity, so the goal would be to do a full backport of the precise/quantal patch into lucid to see if it works initally? then go for the do-no-harm fix?
<stgraber> slangasek: that's why we had to introduce /etc/init/network-interface-container.conf to workaround that for the loopback device. For the others we rely on networking.conf doing the right thing.
<stgraber> smoser: ^
<arges> infinity, ok
<arges> infinity, so sounds like... we need to get a chip with the FMA4 extension... I did build a test package of the do-no-harm fix to have that verified in the bug
<arges> but not response yet
<infinity> arges: Fully backporting the 2.16 fix to lucid is impossible, it touches code that didn't exist in older releases of glibc.  This is why I *suspect* that the less complete fix (that you attached) might be good enough for 2.11 and 2.13, but we need to test.
<arges> infinity, ok.
<infinity> arges: Pretty much as soon as I can get some sort of confirmation that this won't need fixing on AMD hardware two minutes after we fix it on Intel hardware, I'm happy to push the lucid and oneiric uploads.
<infinity> arges: I don't particularly feel like fixing it twice. :P
<arges> infinity, true. Ok I'll work on getting the AMD hardware
<infinity> arges: For reference, the AMD version of the bug is https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/956051
<ubottu> Launchpad bug 956051 in eglibc (Ubuntu Precise) "libc6 crash while running 'xm'" [High,Confirmed]
<infinity> arges: Which, for now, only has a precise task, as I *believe* it doesn't affect older releases.
<arges> infinity, so looks like there is a patch for that too in the bug... does the overall avx/fma4 patch cover that? or is the patch in the bug another workaround?
<arges> in 956051 that is
<infinity> arges: That's the 2.16 commit (well, some of them, our final patch ended up being bigger still)
<infinity> arges: And that's in quantal and precise.
<infinity> arges: (In the precise upload queue, that is...)
<arges> infinity, so can we point the people affected in 956051 to those packages and have htem verify?
<slangasek> stgraber: do we need/want to bring up an interface config within the container, then?
<infinity> arges: It's already been verified fixed in quantal.  Can't point anyone at anything in precise until it's accepted into -proposed and built. :/
<infinity> arges: But it's the identical patchset, so it should DTRT.
<arges> infinity, so would it make sense to target 956051 to quantal and mark it 'fix released' to indicate that it has been fixed in that package
<arges> or
<arges> oh
<arges> i see the larger task already is marked fix released
<infinity> Yeah, no need to target the development release.
<stgraber> slangasek: not sure I understand the question. What do you mean by "interface config"?
<infinity> arges: I'll try to chase up some people who aren't me to finish reviewing the precise upload and get it accepted.
<slangasek> stgraber: why do we need an interface setup inside the container?  it's having this config that causes the network to come up
<arges> infinity, ok
<slangasek> stgraber: er, causes the network to be delayed
<arges> infinity, i'll try to drum up some hardware and do some testing.
<infinity> arges: Best thing for you to do would be to sort out the right set of Intel and AMD (kinda want both) hardware for us to both reproduce and verify the state of lucid and oneiric, so we can push those ASAP.
<arges> infinity, ack
<infinity> arges: Carlos had a whole set of testing kit that we used to do the 2.16 fixes upstream, but he had to return most of it. :/
<stgraber> slangasek: still not sure I understand. Containers have a loopback device and an ethernet device (eth0) just like regular systems, both of which have configuration defined in /etc/network/interfaces and get configured by ifupdown at boot time.
<smoser> stgraber, is it ok if i/you upload isc-dhcp ?
<SpamapS> hrm, so, Unity doesn't have a micro release exception, right?
 * SpamapS looks at the 21 bugs fixed in latest unity precise-proposed upload and wonders
<infinity> SpamapS: No, but if it's a bugfix-only release with all the bugs documented, the version number is meaningless.
<infinity> As long as it's all auditable and such.
<SpamapS> It is
<SpamapS> its just.. a big audit ;)
<infinity> Yeah.  That's why I left it for you after I did the really easy nux and unity-2d! ;)
<SpamapS> infinity: and I would have gotten away with it if it weren't for you darn kids!
 * SpamapS shakes fist
<maco> meddling
<SpamapS> man some of these are really big code changes too
<stgraber> smoser: I'm still working on a last fix for it, so unless you need it urgently, I'm planning on uploading it probably later today
<stgraber> smoser: (I'm fixing the case where dhclient dies after a lease expires when called with -1)
<smoser> ok. later today is fine.
<bdmurray> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #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
<barry> doko: upstream hg should be good to go for bug 1048710
<ubottu> Launchpad bug 1048710 in python3.2 (Ubuntu) "Regression in argparse for Python 2.7, 3.2 and 3.3" [Critical,Confirmed] https://launchpad.net/bugs/1048710
<SpamapS> \o/
<wds> hi, may I ask a support question here? (no response in main forum)
<bdmurray> Can somebody mark https://code.launchpad.net/~bkerensa/ubuntu/precise/hellanzb/fix-for-957323/+merge/123358 as merged?
<slangasek> stgraber: ok, that answers my question, thanks.  so that means that smoser's problem comes down to containers relying on /e/i/networking.conf to bring up interfaces, plus /e/i/networking.conf blocking on local-filesystems, plus cloud-init deliberately blocking the local-filesystems event
<slangasek> stgraber: how can we solve this circular dependency?
<slangasek> smoser: ^^
<stgraber> slangasek: I'm not familiar with cloud-init, can you paste that upstart job?
<stgraber> slangasek: depending on what it actually needs, it might be as simple as using a "or container", but that depends on whether that'd introduce a race or not...
<slangasek> stgraber: the job is specifically designed to block the rest of the boot, but wait for the network to come up, so that it can pull config over the network
<smoser> slangasek, http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/files/head:/upstart/
<slangasek> stgraber: ^^ the jobs
<smoser> cloud-init.conf is the job that depends on networking
<smoser> and it blocks on cloud-init-nonet.conf (which ensures that cloud-init is up)
<smoser> s/ensures that cloud-init is up/ensures that network is up/
<stgraber> smoser: so it looks like this code would be failing on any machine where one or more interface needs to be brought up by networking.conf, no?
<stgraber> for example, adding the following to /etc/network/interfaces in a cloud instance should trigger the same thing:
<stgraber> auto br0
<stgraber> iface br0 inet manual
<stgraber>     bridge-ports none
<stgraber> as it's going to be required to get static-network-up and won't be automatically setup by udev events (as it's not tied to any physical interface)
<slangasek> stgraber: yes, but why would you install the cloud tools on such a machine?
<slangasek> this is for cloud guests
<stgraber> slangasek: lxc containers would be one use case for having a bridge interface that's not bridged to a physical device
<stgraber> slangasek: another one would be using a gre/sit/... tunnel
<smoser> so. yeah, its limited to "simplistic" networking. for some definition of "simplistic"
<smoser> but thats ok.
<smoser> cloud-init is also limited to /usr being on / (it uses python early in boot).  thats not ideal, but also ok.
<slangasek> going forward that's going to be a constraint anyway
<slangasek> (not this cycle, but next)
<stgraber> slangasek: actually, there's something I'm not sure about, why do we only wait for virtual-filesystems for network-interface.conf but wait for local-filesystems for networking.conf?
<stgraber> (network-interface depends on getting a udev event which itself depends on virtual-filesystems, somewhat indirect, but still)
<slangasek> stgraber: because networking.conf is designed to sit at the same place in the boot sequence as the classical /etc/init.d/networking
<smoser> i have to run. i'll be aback and read backscroll.
<slangasek> we could revisit whether this is still reasonable, but making it happen sooner does increase the risk of it happening too early
<smoser> slangasek, you can give stgraber access to that instance if its at all helpful, but the reproduce case is easiliy described and demonstrated.
<smoser> thanks to both of you.
<stgraber> well, if we think that we need to wait for local-filesystems for networking jobs to run at the same time as the sysvinit job in Debian, then we probably should also make network-interface.conf depend on local-filesystems
<stgraber> (which would completely break cloud-init for everyone then)
<slangasek> stgraber: not at all, I don't think we want network interfaces to wait for local-filesystems before they come up
<slangasek> I'm just saying that the reason we're doing that is because /historically/, it was envisioned as a catch-all
<slangasek> that may or may not be something we still care about
<stgraber> yeah, might revisit that next cycle, not sure I want to deal with the potential side effects of changing that for 12.10 ;)
<stgraber> so, one thing that cloud-init could do but would be really quite ugly is to do "initctl emit --no-wait net-device-added INTERFACE=eth0 || true" if it's in a container. Ideally without hardcoding eth0. But that's quite ugly and wrong...
<barry> slangasek: can you comment on #3 of bug 1035869 ?
<ubottu> Launchpad bug 1035869 in computer-janitor (Ubuntu) "computer-janitor crashed with ImportError in /usr/share/computerjanitor/computerjanitord/errors.py: No module named computerjanitor" [High,Triaged] https://launchpad.net/bugs/1035869
<xnox> barry: see my comment about the janitor.....
<xnox> barry: for some reason it is only seeded on ubuntu-server.....
 * xnox ponders if you can make computer-janitor to remove itself as obsolete software....
<barry> xnox: i agree with you!  we should just kill it and remove it from the archive.  is that too late for quantal?  think we'll piss too many people off?
<barry> xnox: brilliant! :-D
<xnox> barry: i think it's something like two pints to Laney and micahg and you can get it removed from quantal
 * Daviey unseeds it
<Laney> erm
<stgraber> Daviey: you should probably wait for a FFe...
<Laney> yes indeed
<barry> i don't care if it's just moved to universe.  i just don't personally ever want to hack on it again :)
<Laney> what good is moving it to universe?
<Daviey> stgraber: barry raised one right there, FFe granted.
<Laney> it's not supposed to be where you shove crap you don't want to look at
<barry> Laney: honestly, none
<Laney> this haste concerns me a bit
<barry> Laney: would you feel better if i filed a official ffe for removal?
<stgraber> barry: having a FFe would help so it can be properly documented that it's dropped and can be used as a tracking bug for archive removal too
<Laney> I want to consider what use cases it has and if we can/should serve them elsewhere
<Daviey> right, yes.. a bug for removal should exist.
<stgraber> having to refer to irc logs when someone asks why something was removed from the media or the archive is suboptimal
<xnox> barry: does update-manager use any of computer-janitor? e.g. do we need to keep computer-janitor, but can kill computer-janitor-gtk for example?
<Daviey> I just disagree that shipping a package on the server on cd pool requires an FFe.
<Daviey> There is paperwork for the sake of it, and required paperwork.. Removal from the archive sure does require paperwork.. Dropping from server-ship, no thanks.
<xnox> if ubuntu-server drops computer-janitor, then computer-janitor will move into component missmatches (surely)
<infinity> Yes, and it will drop to universe.
<barry> xnox: i would not change the vestiges of janitor in u-m, at least this cycle
<infinity> That's entirely unrelated to people talking about removing it from the archive.
<xnox> ok.
<barry> xnox: but the c-j package itself has the dbus service, gtk, cli.  all those must die
<stgraber> Daviey: I disagree but don't feel like arguing about it now (and don't particularly care for this specific one).
<xnox> barry: hmm... binary packages, not source please: is the above crash in the gtk app? then we can drop computer-janitor-gtk (bin) but leave the computer-janitor (bin)
<infinity> xnox: And how does that help anyone?  The source is buggy regardless. :P
<xnox> regardless computer-janitor (src) will stay in main cause u-m build-deps on computer-janitor (bin)
 * xnox should re-read the bug report again =)))))
<infinity> (And u-m build-deps on c-j?  reverse-depends(1) doesn't think so)
<barry> xnox: i don't think u-m depends on c-j.  it has a breaks, but that's it afaict
<barry> c-j depends on u-m because if its incestuous relationship
<xnox> .... it also fails to build from source?!
<infinity> Nothing reverse depends or build-depends on c-j.
<xnox> barry: ok.
 * barry files the ffe
<xnox> how is it an "remove from the archive & FFe" or "just remove from the archive"?
<xnox> I thought FFE is for including stuff, not dropping.
<Daviey> removing a feature, is still a feature :)
<stgraber> xnox: FFe is for any feature change to the archive, removing something from a product or removing something from the archive are both changes
<xnox> ah... so FFe for feature deltas ;-)
<infinity> Indeed.
<infinity> Otherwise, we could remove all installation images, drop all desktop tasks, and leave people with di netboot images, and that would totally not violate feature freeze.
 * infinity runs off to do that and giggles madly.
 * Daviey realises that rdepends seems to think Breaks: is a depends?
<infinity> Daviey: apt-cache rdepends just shows "relationships".
<infinity> Daviey: It's badly named.
<infinity> Daviey: Use reverse-depends(1) instead.
<Daviey> yeah.. i was just poking it.
<Laney> so what does c-j do that's good?
<Laney> ISTR that it removes old kernels?
<xnox> Laney: it removes obsolete packages. Ideally it should do $ sudo apt-get autoremove; remove old kernels; remove dummy packages;
<stgraber> smoser: isc-dhcp uploaded
<infinity> Removing old kernels will be done more sanely in R (fixing that here, but not fussed about getting an FFe for Q)
<barry> Daviey, Laney, xnox, infinity https://bugs.launchpad.net/ubuntu/+source/computer-janitor/+bug/1050071
<ubottu> Launchpad bug 1050071 in computer-janitor (Ubuntu) "[FFe] Remove Computer Janitor from the archive" [Undecided,New]
<infinity> Removing dummy packages could totally be built into apt-get autoremove.
<barry> and i am going to mark bug 1035869 wont fix
<ubottu> Launchpad bug 1035869 in computer-janitor (Ubuntu) "computer-janitor crashed with ImportError in /usr/share/computerjanitor/computerjanitord/errors.py: No module named computerjanitor" [High,Triaged] https://launchpad.net/bugs/1035869
<Laney> so while I agree it should be done, I just want to help good ideas not get lost
<xnox> infinity: except sometimes c-j would get it wrong, e.g. look at the oldlibs section which at one point had "old" linux-standard compat libs
<infinity> To be fair, I'm not sure *what* c-j actually cleans.
<Daviey> Laney: there is a separate kernel team effort to remove old kernels, but ogasawara mentioned today that it will most likely be postponed to R
<Laney> I remember that session at UDS
<xnox> infinity: then it would remove those and $half of your $apps
<infinity> Daviey: By "kernel team", you mean "Adam"?
<barry> iirc, c-j does not clean old kernels anyway
<xnox> maybe it stopped... it did at one point... until it got it wrong....
<Laney> well, what does it do?
<Laney> autoremove, oldlibs?
<ogasawara> infinity: indeed, I'd assumed you owned the clean old kernels bit
<Daviey> infinity: Seems so.. https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-clean-old-kernels
<barry> Laney: it's got a bunch of plugins which kind of try to figure out what is no longer needed.  problems with this include bug #458872
<ubottu> Launchpad bug 458872 in computer-janitor (Ubuntu) "Don't mark for removal manually installed packages" [Wishlist,Triaged] https://launchpad.net/bugs/458872
<barry> Laney: https://bugs.launchpad.net/ubuntu/+source/computer-janitor/+bug/458872/comments/3
<barry> :)
<infinity> ogasawara: I do, and it'll get done before R, and I'll land it when we open the archive.
<infinity> ogasawara: I see no point in pushing feature freeze for it, when it's the sort of thing that should have testing anyway. ;)
<ogasawara> infinity: Oooo sweet
<ogasawara> infinity: agreed, I see no hurry to land it for Q
<Laney> barry: hah
<Laney> update-manager should consider taking on some desirable features
<xnox> Laney: buggy, unused, RoM, feature-less ......
<barry> Laney: yes or sc.  mvo and i have discussed this in the past.
<Laney> well I don't think it's unused or feature-less
<Laney> as the bugs do come in
<SpamapS> I know I asked this like, 3 weeks ago.. but.. are we any closer to having nvidia binary drivers for quantal?
 * SpamapS has not dist-upgraded in a while
<ajmitch> SpamapS: they wfm on quantal
<SpamapS> ah so perhaps they just quietly arrived?
<SpamapS> I was still under the spell of "DONT DIST UPGRADE THERE IS A NEW X"
<ajmitch> yeah, 304.43 was uploaded on the 28th, supports new X ABI
<SpamapS> sweet
<slangasek> barry: seems like my opinion has already been superseded by the discussion? :)
<slangasek> barry: and I don't think you need a FFe for removal of a package
<stgraber> slangasek: even when that involves unseeding from a supported media and altering rdepends (update-manager) so it can be dropped from the archive?
<doko> infinity, can we give back packages on all archs before the test rebuild?
<infinity> doko: Yeah, we can.  I was waiting for powerpc to catch up.
<stgraber> slangasek: oh, nevermind, got confused by the discussion earlier, nothing actually depends on it (or build-depends), so yeah, it's just a seed modification + removal from the archive
<infinity> doko: I also kinda wanted to wait for RT#51115 to be done. :/
<slangasek> stgraber: exactly
<bkerensa> bdmurray: sure
<bkerensa> :D
<barry> slangasek: thanks.  i think it's not a bad idea to have the decision to remove officially recorded in a bug tho
<slangasek> barry: quite, that's definitely preferred from the archive admin side
<slangasek> barry: bug against the package, assign to ubuntu-archive
<barry> slangasek: i will be *so* happy to never have to look at that code again :)
<xnox> barry: oh the irony of spending all that time =)
<barry> xnox: s'ok.  i've wasted more time on stupider things :)
<Kardos> hey all
<SpamapS> silly question.. why is rmadison so darn slow?
<smoser> slangasek, you have any ideas ? the emit of the net-device-added is not un-like the hack i am quite likely to need to do to get precise functional (potentially emitting virtual-filesystems there).
<xnox> SpamapS: isn't it a call to a cgi script which is well slow? maybe something similar can be redone in python and call it lpmadison and add it to ubuntu-dev-tools?!
<cjwatson> SpamapS: Because it's at least four years since I put any effort into optimising madison-lite
<cjwatson> xnox: oh FFS don't rewrite stuff for the sake of it
<cjwatson> optimise it instead
<cjwatson> now I know perl isn't the prevailing religion but it'll probably be faster than python for the lots of text processing involved here
<xnox> cjwatson: is rmadison always up to date? I can't remember but I think I did see it to be behind launchpad. Especially with respect to unapproved uploads... unless I am wrong
<cjwatson> and I will happily take patches to madison-lite
<xnox> cjwatson: I'm about the canonical datasource, rather than choice of language here. If it works, don't touch it.
<cjwatson> xnox: it uses /srv/archive.ubuntu.com/ubuntu on lillypilly
<SpamapS> cjwatson: so its just a ton of data that it has to churn through?
<SpamapS> I notice some packages come back very quickly while others just spin
<cjwatson> SpamapS: Yeah, it has to recache each time the archive changs
<cjwatson> If you're the first hit after an archive refresh, it'll take a while
<cjwatson> I wouldn't expect it to be package-specific
<SpamapS> ah so it leans heavily on the cache crutch :)
<SpamapS> if you've already turned to that.. probably not a ton that can be done to optimize
<cjwatson> It's possible that the cache is a pessimisation these days
<cjwatson> It's years since I checked how the I/O works out
<SpamapS> I can't imagine it would be overloaded
<SpamapS> the server I mean
<cjwatson> lillypilly has a bunch of stuff on it
<SpamapS> true
<cjwatson> load average: 4.22, 6.45, 7.96
<SpamapS> how many CPU's/spindles in that?
<cjwatson> Admittedly 8 CPUs (well, might be HT going on)
<cjwatson> I suspect it just needs a straightforward look at the algorithms before worrying about any of that
<cjwatson> Remind me after 12.10 releases? :-)
<SpamapS> cjwatson: bzr branch?
<SpamapS> I once fancied myself a perl programmer
<cjwatson> http://anonscm.debian.org/bzr/users/cjwatson/madison-lite/trunk
<cjwatson> The cache is fairly noddy because it's trying to be as light on dependencies as possible
<cjwatson> It could be that sqlite or something would be better
<SpamapS> cjwatson: some pretty deep regex-fu in there too
<xnox> well... non scientific benchmarking: debian and udd URLs are much faster than ubuntu URL queries
<xnox> for test package after multiple runs.
<xnox> no clue what debian & udd have deployed though
<bdmurray> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #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:
<ajmitch> the debian udd instance is on a new machine now, it's a postgres db
<xnox> plus debian/udd output is formatted nicer
<cjwatson> The Debian one is talking to the dak database directly
<cjwatson> So it never has to recache or anything
<SpamapS> cjwatson: any reason we don't redo this to just poke launchpad directly?
<cjwatson> Haha, you think the API will be faster
<SpamapS> s/think/hope/
<cjwatson> The API is particularly weak on things like binary<->source mappings
<SpamapS> ah yeah
<SpamapS> too many joins
<SpamapS> and it has to hit that whole version ordering thing
<SpamapS> IIRC there is python being run for every row when that is used
<SpamapS> as in, python inside pgsql
<cjwatson> madison-lite might be optimised by shelling out to grep-dctrl for the hard work of parsing
<cjwatson> That'll probably be faster than line-by-lining in perl
<cjwatson> That would make the cache update faster, then either it wouldn't require a cache, or convert the cache to sqlite, based on profiling
<SpamapS> well thats easy enough to strawman
<cjwatson> That'd be my suggestion anyway
<cjwatson> And it's easy enough to run locally to try
<SpamapS> I'm looking at all the regexes right now..
<cjwatson> Yeah, I never profiled those, although to be fair I'm not sure how to avoid them and retain correctness given the interface
<SpamapS> and they're really not that heavy on what usually drags regex perf down.. not lots of backrefs and such
<cjwatson> No, I knew enough to avoid those
<slangasek> smoser: to get precise functional> I was planning to SRU these mountall fixes after bake-in
<smoser> slangasek, hm..
<smoser> ok then.
<slangasek> smoser: as for emitting net-device-added, well, one hack is as good as another as far as I'm concerned ;)
<smoser> i was planning on the cloud-init 'start on starting mountall' fixup
<cjwatson> SpamapS: Oh, also, having a tool which produces this report based on Packages/Sources has been helpful to me on innumerable occasions in the past, when I suspect that other things are lying to me
<slangasek> smoser: I don't see any problems specifically with faking net-device-added.  I would like to fix this properly for the future
<cjwatson> SpamapS: So I wouldn't like to end up maintaining two tools in order to keep that facility
<smoser> slangasek, yeah. so you have an idea on how i could not emit that twice ?
<slangasek> smoser: starting mountall> well, depends on your timeline I guess; I do think we want the SRU anyway because it fixes various NFS-at-boot issues
<smoser> i could have a job that got the event and wrote a /run marker.
<smoser> but that would seem racy
<slangasek> smoser: nah, create a separate job in cloud-init that's 'start on container' and emits it
<smoser> cloud-init has way to many upstart jobs :)
<smoser> but sure, one more
<smoser> thanks for your help. i'll poke more
<SpamapS> cjwatson: indeed.. thats why Holmes has Watson. ;)
<SpamapS> well and to watch his back
 * cjwatson decided not to bother getting a doctorate just in order to be Dr Watson
<xnox> cjwatson: you probably can get an honorary degree
<cjwatson> xnox: I'm not sure what the official stance is in the UK (and wp is vague on it) but I would not generally be inclined to use prenominal Dr for a holder of an honorary doctorate
#ubuntu-devel 2012-09-13
<cjwatson> Varies from country to country I believe
 * xnox was reading WP about all of that as well
 * xnox adds a TODO item to create a wiki page for cjwatson, if scott has one with out of date picture so can cjwatson ;-) 
<cjwatson> I think you should beware WP:COI.  I wouldn't encourage anyone I worked with closely to write an article about me
<SpamapS> cjwatson: the packages cache generation is really really fast, don't think it has much fruit for optimization
<slangasek> since you wouldn't encourage it, there's no conflict of interest ;-)
<SpamapS> user	0m0.056s
<SpamapS> cjwatson: 163926 packages in 0.056s .. ;)
<cjwatson> And of course WP:BIO
<cjwatson> SpamapS: Huh, so why do I notice occasional ridiculous slowdown
<cjwatson> Maybe the cache directory layout (such as it isn't) is poorly designed
<SpamapS> cjwatson: the source cache does a sort.. testing that now
<cjwatson> Mm, no custom sort functions though
<cjwatson> s/functions/comparators/
<SpamapS> yeah its blazing fast too
<cjwatson> and yet
<cjwatson> $ time HOME=/home/ubuntu-archive/www-data madison-lite --nocache man-db
<cjwatson> real    0m52.245s
<cjwatson> that's fairly ridiculous
<SpamapS> hm
<cjwatson> (also no output, there's evidently a correctness problem as well :-/)
<cjwatson> well, I should be doing a couple of other things before going to bed.  let me know if you come up with anything
<SpamapS> cjwatson: will do :)
<cjwatson> lifeless: I've reproduced your GRUB regression in a horrendously hacked-up VM, so I should be able to sort it out from here
<lifeless> cjwatson: \o/
<cjwatson> lifeless: Ended up simulating all the dmraid stuff with manual dmsetup commands, which isn't good enough to allow dmraid -ay to work but it is enough to brainwash GRUB
<lifeless> cjwatson: let me know when you think its good and I'll get you a positive confirmation :)
<cjwatson> Righto
<cjwatson> lifeless: All right, fix (hopefully) uploaded - I'll check back tomorrow morning and let you know if it's built
<lifeless> okeydoky
<cjwatson> Fix was dropping a bit of the patch :)
<queency> hello all i'm using ubuntu9/04 can someone direct me to install power save to my machine
<tjaalton> queency: that release was EOL'd almost two years ago..
<queency> tjaalton: yes so ? why everybody keeps bugging me to upgrade ? everything works fine!
<tjaalton> queency: don't expect to get any sort of support for it
<tjaalton> like, security updates
<tjaalton> or guidance
<queency> tjaalton: security i'm behind a firewall i.e i don't afraid , guidance whats wrong with small tips here and then ?
<tjaalton> queency: power management is built in. if your machine doesn't have it, it could be better in a more recent release. so my free tip is: please upgrade
<queency> tjaalton: btw i don't run services in my private lab ubuntu 9.04 and i'm monitor my net steadily : i just don't familier with all the task yet !
<queency> tjaalton: tnx but no tnx
<queency> tjaalton: is the power save manipulated by the kernel ?
<tjaalton> queency: i've nothing to add
<queency> tjaalton:ok tnx for your time , i'm sorry but i like my system to be intact and upgrading however solve things but brake others.
<tjaalton> use an lts release like 10.04/12.04
<queency> tjaalton: even my monitor driver was patched by me manually from 2 years ago : upgrading will screw it up !
<tjaalton> sure about it?
<queency> tjaalton: don't want to check if i right
<tjaalton> there are livecd's for that
<queency> tjaalton: i don't say live cd won't work i just say i don't know what happened with upgrading my old system ; not installing a new one
<RAOF> Is it still possible to upgrade from 9.04?
<tjaalton> dunno
<ajmitch> perhaps with dist-upgrade & adding old-releases.u.c into sources.list
<tjaalton> yeah
<RAOF> Anyone feel like sponsoring a colord upload to sid?
<didrocks> slangasek: tjaalton: hey, you have a WI on https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-xorg-lts-updates to review the rename script, do you think you will get a chance to deal with it?
<tjaalton> didrocks: sure
<tjaalton> now that it seems to be working fine, might just mark it DONE
<RAOF> pitti: feel like sponsoring a colord upload to sid?
<didrocks> tjaalton: great! :)
<didrocks> thank
<didrocks> thanks*
<dholbach> good morning
<pitti> Good morning
<pitti> SpamapS: I guess dpm uploaded them; we do that in regular intervals, and yes, they should just be waved through (there's a whole testing process behind that)
<pitti> RAOF: yep, can do
<RAOF> pitti: Ta. It's in collab-maint git; you're looking for the debian/0.1.21-2 tag.
<darkxst> anyone know how to install a mainline kernel into a livecd chroot?
<pitti> SpamapS, infinity: hm, I've got mail from dpm that he didn't upload these either
<pitti> infinity: do you remember, were these proper uploads or copies from a PPA?
<jibel> pitti, I enabled quantal-proposed for autopkgtest. There are now 2 sets of tests: one with packages in the release pocket, the other with proposed
<jibel> tests in proposed are triggered when a newer version of a package is uploaded to proposed
<pitti> jibel: niiice!
<jibel> or a newer version of a dependency of a package in release is uploaded to proposed
<jibel> or a newer version of a dependency is uploaded to release and the package is in proposed
<jibel> pitti, sound good ? or I missed other rules ?
<pitti> jibel: does that include build dependencies?
<pitti> (this also applies to -release)
<pitti> jibel: I don't see those yet, is that because there just are no packages in -proposed at the moment?
<jibel> pitti, no, binary deps, should I include build deps ?
<jibel> pitti, right, packages autodiscovered have been added to the private instance and will be published on first run
<pitti> jibel: hm, do we have tests with "build-needed"? for those I think we should
<infinity> pitti: They were direct uploads.
<pitti> infinity: thanks; strange then, it seems nobody did those then
<infinity> pitti: That's a bit disconcerting.  Surely, SOMEONE must have. :P
<pitti> infinity: theres' a cronjob on macquarie which auto-uploads to the PPA for stable releases, and to the archive for the devel release; that hasn't changed in years, though
<pitti> I'll take a closer look
<jibel> pitti, there is no test with a restriction "build-needed" for the moment, but that's a good point. I'll add support to run on build deps change if packages have such restriction.
<roseoff> hello !
<roseoff> sudo apt-get install fglrx fglrx-amdcccle
<roseoff> The following packages have unmet dependencies:
<roseoff>  fglrx : Depends: xorg-video-abi-11 but it is not installable
<roseoff> E: Unable to correct problems, you have held broken packages.
<roseoff> ?
<roseoff> HELP !
<roseoff> ubuntu 12.10
<mlankhorst> yes
<roseoff> mlankhorst,
<pitti> roseoff: not much you can do -- just wait until a working driver is available, and use the free one until then
<mlankhorst> pitti: I was hoping he would try to google the error :(
<pitti> jibel: thanks for the aptdaemon autopkgtest-ification!
<pitti> jibel: did you already check this in a minimal VM, or want me to? (I have my test VM here)
<jibel> pitti, yw, I used it to write a small doc that explains how to add dep8 support to a package
<jibel> pitti, I tested it in a minimal VM from the source tree
<pitti> jibel: cool, thanks; I'll upload this now
<jibel> pitti, 68 tests passed, 4 skipped, there are dbus message to investigate
<Laney> http://paste.debian.net/189671/ how do I make apt want to remove ubuntu-default-settings and install ubuntu-settings instead of holding back ubuntu-desktop?
<Laney> u-s B/R (versioned appropriately) on u-d-s
<tumbleweed> you need a transitional package
<Laney> that is exactly what I want to avoid
<tumbleweed> you can't
<tumbleweed> http://wiki.debian.org/Renaming_a_Package btw
<Laney> that package name is already being used as a virtual package
<Laney> I know
<xnox> Laney: breaks/replaces/provides + higher version number?!
<xnox> Laney: it's the case of "multiple mta's, yet only one mta at the same time"
<tumbleweed> provides are versionless (you should remember that from NM)
<cjwatson> Well, no, it shouldn't be like the MTA case
<cjwatson> This might improve once ubuntu-default-settings is no longer in the archive
<Laney> you think?
<cjwatson> They're exactly balanced in score - I think one no longer being available would tip the balance
<cjwatson> I think
<cjwatson> It should lose the one-point "installed package that isn't obsolete" bonus
<Laney> yeah, that seems to be correct (hacked it out of the list manually to test)
<Laney> who know? (you)
<tumbleweed> Laney: you could mention this on that wiki page for future people to know
<cjwatson> apt-pkg/algorithms.cc if you want to stare aimlessly
<BenC> Did someone do a bunch of give-backs or is powerpc really doing that awesome this morning on ftbfs page?
<xnox> BenC: i heard doko & infinity were planning give-backs before archive rebuild =/ or something like that
<cjwatson> I noticed the output of a load of give-backs in my inbox
<cjwatson> The hint is probably that powerpc is 33 hours behind :-/
<doko> yes, builds were given back yesterday evening
<ogra_> did anyone ever try to use qemu-ppc-static for this ?
<ogra_> i bet its faster :)
<cjwatson> lifeless: https://launchpad.net/~cjwatson/+archive/grub/+packages has an update ready for you to test now
<hallyn> smoser: well, could be.  like i say i thought i'd fixed those.  but more likely i missed it, and it's a regression by the templates adding the second space
<smoser> ah.
<smoser> well glad it will work. thank you.
<hallyn> smoser: btw, i went ahead and changed --new to --name in lxc-clone, but it occurred to me last night that --new is what i really intended :)
<hallyn> and nowhere is '--new' actually spelled out, i don't think
<smoser> --name is better.
<smoser> its consistent with everything else.
<smoser> imo
<smoser> but either one working would have been "good enough"
<xclaesse> I'm testing Quantal's installer in a VM. I see encrypted LVM option exists now, but only for automatic partitioning?
<xclaesse> is it possible to manually define the size of the partitions inside the LVM ?
<xnox> xclaesse: not yet.
<xnox> xclaesse: you can do it post-install.
<xnox> xclaesse: by resizing your root partition & resizing logical volume.
<xclaesse> xnox, not yet means not for Quantal or will it still make it in time for Quantal ?
<xnox> xclaesse: in a way it is a limitation of the debian-installer's partitioning software partman, which ultimately requires something to take up all remaining space
<xnox> xclaesse: I am coding it, there is FeatureFreezeException for it, and it is targeted for Quantal.... so it should land soon.
<xclaesse> nice !
<xnox> xclaesse: taking the rest of the space for automatic partitioning that is. No such requirements for manual partitioning (kind of)
<xclaesse> xnox, while I'm at it: will it be possible to re-install without ripping all LVM volumes?
<xclaesse> IIRC that was not possible with alternat installer
<xclaesse> xnox, hmmm, automatic won't make /home in a different logical volume, will it?
<xnox> xclaesse: it can, but we do not offer that.
<xnox> xclaesse: it's easy to fix that up / migrate to separate home post-install.
<xclaesse> yeah, so manually creating the volumes would still be nicer IMO
<xnox> i know
<xclaesse> I totally agree that's not something you want for "normal" users, but having the choice somewhere would still be good :)
<xclaesse> xnox, so manual LVM is not planned for quantal?
<xnox> xclaesse: i told you, i am working on it.
<xnox> xclaesse: automatic will stay as it is, but manual crypt/lvm will land in one form or another
<xclaesse> ah ok, miss understood
<xclaesse> good :)
<smoser> cjwatson where would i find TFM to read about what kernel parameters d-i reads?
<cjwatson> smoser: https://help.ubuntu.com/12.04/installation-guide/
<ScottK> pitti: In case no one else told you, you got mentioned here: http://www.linuxuser.co.uk/interviews/whats-going-on-with-gnome/
<smoser> cjwatson, so can you confirm for me that 'release=<something>' is ignored?
<smoser> or rather is not expected to do anything ? i have something that is writing it, but it didn't seem like it should have to, and i dont see it at (https://help.ubuntu.com/12.04/installation-guide/i386/boot-parms.html)
<cjwatson> smoser: I've never heard of that
<smoser> cjwatson, thanks. it was probably copied along.
<slangasek> didrocks: hmm, I think the script in question has by now iterated to the point that my review would no longer add anything
<didrocks> slangasek: ok, put it in DONE and drop it please :)
 * didrocks was in blueprint cleanage day
<SpamapS> cjwatson: I think you may be right that the caching needs optimization in madison-lite
<SpamapS> %Time ExclSec CumulS #Calls sec/call Csec/c  Name
<SpamapS>  83.2   0.990  0.990     13   0.0762 0.0761  main::cache_list_file
<SpamapS> thats without a cache
<SpamapS> and with a cache..
<SpamapS>  80.3   0.160  0.160     13   0.0123 0.0123  main::search_cache
<SpamapS> tho.. main::cache_list_file is basically "the whole thing" .. so need to break it up to get more from dprof
<slangasek> didrocks: ok, done :)
<didrocks> thanks slangasek :)
<didrocks> ogra_: did the XDG_RUNTIME_DIR landed?
<slangasek> didrocks: no... working on it still
<didrocks> slangasek: ok, ETA is beta2 freeze I guess?
<slangasek> didrocks: i.e., I'm working on it, not ogra
<slangasek> didrocks: yes
<didrocks> slangasek: ah ok, I saw that in the release meeting report, hence the question :)
<didrocks> slangasek: thanks ;)
<slangasek> yeah... :)
<tjaalton> let's try here: anyone here with an intel i915/i945 machine willing to bisect mesa? I'll build the packages
<pitti> ScottK: argh, with the one thing I don't really want to do (CK :) )
<pitti> ScottK: thanks for the pointer
<ScottK> So now you know you just need to line up some BSD hackers to help you out.
<smoser> cjwatson, around ? i'm looking at changes i believe were yours to /etc/init/iscsi-network-interface.conf under https://bugs.launchpad.net/ubuntu/+source/partman-iscsi/+bug/457767
<ubottu> Launchpad bug 457767 in partman-iscsi (Ubuntu Karmic) "karmic: iSCSI root: boot hangs on starting iscsid" [High,Fix released]
<smoser> quantal has regressed and is no longer writing /run/initramfs/open-iscsi.interface . but my iscsi root seemed to not suffer any negative from that
<smoser> ie, i would have thought that that would cause my network interface to bounce and probably generally screw things up.
<xnox> stgraber: ^^^^
<cjwatson> smoser: honestly, it's been so long since I touched that that I don't think I'll be of any more help than reading the code from scratch
<cjwatson> you might have got lucky I guess; regardless, we should be making sure that the interface we're doing iSCSI root over is never torn down ...
<smoser> cjwatson, ok. i'll get that code added back in.
<stgraber> smoser: did you see my comment in #ubuntu-server yesterday about just checking for /run/net-* from the upstart job rather than having another piece of code in initramfs?
<smoser> stgraber, i did not.
<smoser> and i considered that
<smoser> but at the moment there could be 3 /run/net-* entries
<smoser> (or 'N' of them)
<smoser> and you wouldnt know which exact interface was the root
<smoser> the initramfs [potentially] has that knowledge and was storing it for later consumption
<Daviey> smoser: erm.. we add ipappend 2, which adds BOOTIF=01-mac-address of booting device to kernel cmd line
<Daviey> so we know the boot device
<smoser> Daviey, yeah, but that isn't known in all cases.
<Daviey> smoser: sure?
<smoser> and BOOTIF= is actually not necessarily the device that provides the link to the iscsi root
<smoser> ip=:::::eth1 BOOTIF=01-mac-adddress
<smoser> would bring up eth1 as dhcp
<slangasek> so there's certainly enough information in the system that you can walk it to discover the correct device post-initramfs
<slangasek> but surely it's simpler to just have the initramfs bit record it
<smoser> right.
<smoser> that is what i was about to argue.
<smoser> just opened bug 1050480
<ubottu> Launchpad bug 1050480 in open-iscsi (Ubuntu) "iscsi-network-interface.conf broken after upstream merge" [Undecided,New] https://launchpad.net/bugs/1050480
<smoser> anyone else want to think about resolv.conf in this case?
<smoser> i'm thinking i need to add code to iscsi-network-interface.conf that reads /run/net-*.conf and adds the dns servers
<smoser> at lesat for resolvconf.
<slangasek> smoser: I thought that what we discussed on this previously was sound
<smoser> but in non-resolvconf world, that would have been updated by dhclient and its not going to get done.
<slangasek> there is no non-resolvconf world
<slangasek> it's unsupported, EOD
<smoser> is that acceptable ?
<slangasek> yes, ubuntu-minimal depends on resolvconf
<smoser> ok then. much easier.
<smoser> thanks.
<slangasek> smoser: to be clear, a driving factor for putting resolvconf into ubuntu-minimal was to no longer have to worry about the 50 different ways to manage dns ;)
<slangasek> so yeah, anybody who goes out of their way to disable resolvconf is on their ownw
<smoser> thank you
<smoser> someone tell me what i'm missing
<smoser> http://paste.ubuntu.com/1202917/
<smoser> lines 23-25. why is that path taken if /run/initramfs/open-iscsi.interface did not exist
<smoser> it seems to me that will call /etc/network/if-up.d/upstart with IFACE=''
<stgraber> smoser: looks like that part should be under the other diff
<stgraber> s/diff/if/
<smoser> thats what i thought
<smoser> thanks.
<slangasek> smoser: looks like a bug for this to not be inside the previous if block
<slangasek> right, what stgraber said :)
<smoser> hm..
<smoser> does that job have access to INTERFACE ?
<smoser> that is provided to the 'network-interface' job that it is 'start on' and 'stop on'
<smoser> but will it have access to that?
<smoser> shoot. now i'm reading that same pastebin (http://paste.ubuntu.com/1202917/)
<smoser> wont the post-stop run the first time a network-interface is taken down?
<smoser> i guess i can't think of a failure path there, but it'd be better if it only removed that on down of the specific $iface
<mterry> dpm, do all Ubuntu translations specify utf8 encoding in the po file?
<dpm> mterry, I believe yes
<mterry> dpm, cool
<doko> jamespage, do we have the no-jars-in-package fun in quantal too?
<jamespage> doko, http://paste.ubuntu.com/1203022/
<jamespage> yep
<jamespage> more potential rather than actual at this point in time just like bytecode compat
<doko> can we revert this change before a test rebuild?
<jamespage> yep
<xnox> cjwatson: is there a good test to see if the livecd booted in efi or bios mode?
<smoser> slangasek, or stgraber do you have thoughts on the above?
<smoser> it really seems like the current code basically telling ifupdown that the iscsi interface is down as soon as *any* network interface goes down.
<cjwatson> xnox: [ -d /sys/firmware/efi ]
<xnox> cjwatson: thanks
<xnox> cjwatson: any tips on migrating existing system to efi ? i do have separate /boot do I need to convert it to "efi" partition?
<xnox> aka split it into two?
<dobey> Is there any way to tell lintian to ignore an error/warning from a binary package, via some extra field in the control perhaps?
<cjwatson> xnox: /boot and /efi are different categories of things
<cjwatson> You must have an EFI System Partition
<xnox> ok. will make one.
<cjwatson> I don't have documentation on doing a conversion to hand
<infinity>        For binary packages, Lintian looks for overrides in a file named
<infinity>        usr/share/lintian/overrides/<package> inside the binary package, where <package> is the
<infinity>        name of the binary package.
<infinity> dobey: ^
<xnox> cjwatson: ok.
<dobey> infinity: ah, interesting. what doc is that in?
<infinity> dobey: The lintian manpage.
<dobey> ah it's in the man page. but the syntax of course isn't. luckily first link i clicked on from duckduckgo seems to have it :)
<dobey> infinity: thanks
<fbond> mdz: Hope this is an okay place to contact you. Saw https://launchpad.net/cfontz but there is no code there. Any place I can find it?
<SpamapS> cjwatson: playing a bit more w/ madison-lite here and there... its hard to see how slow it is until you actually put all of the archive files in... each Packages.gz processes "fast".. but there are .. well.. quite a few. ;)
<bdmurray> cjwatson: what networking drivers would be on the mini cd?  bug 1047092
<ubottu> Launchpad bug 1047092 in linux (Ubuntu) "Mini.iso doesn't load wireless drivers" [Medium,Confirmed] https://launchpad.net/bugs/1047092
<xnox> cjwatson: grub2 from ppa works fine in bios mode with lvm/luks. my laptop refuses to boot in uefi mode =(
<infinity> cjwatson: grub2 no workie on powerpc.
<SpamapS> cjwatson: just going through the cache files is still very expensive unfortunately
<SpamapS> cjwatson: mostly because there are so many to go through
<SpamapS>   1295992   0.57777   7.09000   525: my ($key, $value, $is_all) = split;
<SpamapS> cjwatson: as you suspected, sqlite's indexes will probably blow the doors off that. )
<lifeless> SpamapS: ?
<SpamapS> lifeless: I'm taking a few moments to speed up rmadison
<lifeless> SpamapS: oh cool
<SpamapS> which I use quite heavily during SRU processing, and which is incredibly slow
<lifeless> SpamapS: move it into LP ?
<SpamapS> lifeless: thats what I thought actually :)
<SpamapS> lifeless: but cjwatson is wary of the performance of versions+packages+sources in the API
<lifeless> you'd want a new API entry point
<lifeless> no freaking way you want to use the object programming model, it would die from round trips.
<lifeless> -but-
<SpamapS> Its asking "this random string, what packages/sources and versions and architectures are the highest published?"
<lifeless> LP should be able to answer it in about 5 queries, bundle it into json and ship you a single result.
<lifeless> where string can be a source package name or binary package name, right ?
<SpamapS> lifeless: the other reason is, sometimes its nice to have a simple thing parsing the actual Packages/Sources lists
<SpamapS> lifeless: right
 * xnox was expecting to fetch binary publishing history & source publishing history where status is published for active series + some string formatting
<xnox> to make an lpmadison
<lifeless> so yeah, internally thats 1) identify the archives, 2) the series 3) find any matching binary package names, 4) find any published binaries for those names and get the source package names - add to the inputs, 5) find any source package names 6) find the highest published version per series. Done.
<infinity> lifeless: Even if it all could be done quickly in LP, the results are still "wrong", in that people aren't interested in LP's publishing state, but in what's actually on-disk.
<lifeless> That should be well under 100ms
<lifeless> infinity: LP knows whats on-disk.
<infinity> It sure doesn't.
<infinity> It's about 30 minutes early on that.
<lifeless> depending on which mirror they use, it can be hours early.
<infinity> (Which is fine, but not helpful for madison use)
<infinity> Also, your above is missing the source->binary mapping, including out-of-date binaries.
<infinity> It gets more complicated.
<xnox> but for SRU you want what's lp view of things is, even if that's what's only going to happen in the future 30 minutes.....
<lifeless> ok
<infinity> xnox: For SRU processing, you don't even want published, you also want accepted and unapproved, which isn't really what madison's for.
<xnox> true
<infinity> (In other words, you want to know everything that's about to happen, not everything that has happened)
<SpamapS> true
<SpamapS> for SRU I would like LP's view
<infinity> Extending rmadison to have a "show me what LP thinks is published" and a "show me what's in accepted/new/unapproved too" option would be neat, but speeding up the current "show me what's on-disk" view is a nice start.
<bryceh> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #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: bryceh
<mdz> fbond: I would be happy to send you the code but you left :-(
<tedg> slangasek, Which Chinese is "Simplified"?  I've got zh_CN, zh_HK and zh_TW.  Though, none of them show the bug :-9
<tedg> :-(
<Daviey> bryceh: err, 'weston'.. Odd choice of sponsorships.
<stgraber> tedg: zh_CN
<Daviey> bryceh: The debian/changelog suggests it's a really useless upload.. but infact misses out that it drops a patch?
<Daviey> bryceh: http://pb.daviey.com/FNu4/
<tedg> stgraber, Thanks!
<bryceh> Daviey, hmm
<bryceh> no reference to the patch in the changelog
<bryceh> nor does the patch exist in the git tree
<Daviey> bryceh: and xgrep?  These seem like uploads not worth the buildd time.
<Daviey> why didn't dholbach upload that himself?
<bryceh> Daviey, dude, just trying to work through the pilot queue, why so critical?  topic says the archive's open
<Daviey> bryceh: Sure, ok.
<Daviey> Sorry if i seemed to pick, wasn't meaning to.
<SpamapS> doko: any word on bug 1048710 ? New upload in progress?
<ubottu> Launchpad bug 1048710 in python3.2 (Ubuntu) "Regression in argparse for Python 2.7, 3.2 and 3.3" [Critical,Confirmed] https://launchpad.net/bugs/1048710
<bryceh> tjaalton, looks like the git.diff came from your 0.95.0-0ubuntu1 upload; was that just build tree cruft or is that supposed to be there?
<doko> SpamapS, Fri, sorry, was distracted by other issues
<SpamapS> doko: sounds good, thanks.
<tjaalton> bryceh: yeah, source format 3.0 playing tricks
<tjaalton> bryceh: also, those changes should go to debian
<bryceh> tjaalton, yeah, and I told the author so.  But isn't that why we put this junk on alioth to begin with rather than in bzr?  ;-)
<tjaalton> bryceh: yes, but in debian branches and then merge ;)
<tjaalton> not a big deal, will get sorted out at some point
<slangasek> tedg: simplified chinese is the one used in the PRC (so zh_CN)
<bryceh> tjaalton, *shrug*  there was already a 0ubuntu1 version and the changes are minor, they can wait
<slangasek> tedg: Taiwan uses the traditional because they were too busy fighting a war on their rear guard to worry about changing their alphabet
<tjaalton> bryceh: exactly
<tedg> slangasek, Heh
<tedg> slangasek, Thanks!
<tedg> Still seemingly can't change my time format, not sure why.
 * bryceh waves to tedg
<tedg> Howdy bryceh!
<slangasek> tedg: what bug are we talking about, anyway? :)
<tedg> slangasek, bug 1028866 -- trying to recreate.
<ubottu> Launchpad bug 1028866 in indicator-datetime (Ubuntu Quantal) "the date is not displayed correctly in the "date and time setting" window" [High,Confirmed] https://launchpad.net/bugs/1028866
<tedg> slangasek, Not sure why LC_TIME=zh_CN LANGUAGE=zh_CN gnome-control-center isn't working.  Get a locale not supported error.
<tedg> Ah, there we go.  Needed a ".UTF-8"
<tedg> Hmm, bug looks fixed :-)
<tedg> The box really should resize for the last character though.
<slangasek> tedg: fixed> ××× ×××
<c_clapham> Hi, I want to get involved with helping to develop ubuntu but don't know where to start. Can anyone point me in the right direction? Thanks.
<bryceh> c_clapham, depends on what you are interested in, and what you hope to get out of it, mind elaborating on your interests?
<smoser> anyone else have old school (ie 2005) fonts after upgrade today?
<dobey> infinity: can you go ahead and reject ubuntuone-client-data please? (sorry)
<infinity> dobey: I would if I'd gotten around to uploading it for you.
<infinity> dobey: Since I didn't, you're set!
<dobey> infinity: ah, ok. then don't upload it :)
<infinity> dobey: Done.  I'm good at doing things that amount to not doing anything.
<infinity> dobey: I might even not do it twice.
<dobey> heh
<dobey> infinity: thanks for nothin'! :)
<smoser> slangasek, are you going to upload mountall ?
<smoser> i have a fix for cloud-init 'start networking' (replacing it with the emit net-device-added) but it doens't fix my problem entirely
<smoser> https://launchpadlibrarian.net/115772437/cloud-init_0.7.0%7Ebzr644-0ubuntu1_0.7.0%7Ebzr644-0ubuntu2%7Eppa0.diff.gz
<slangasek> smoser: not this week, since I'm not in a position to deal with any regressions and haven't yet tested it to my own satisfaction
<slangasek> smoser: but yes, I am going to upload
<SpamapS> smoser: my 30 second skim over that tells me its good :)
<bryceh> meh.
<bryceh> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #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> bryceh: requestsync -h when sponsoring
<micahg> gah
<micahg> requestsync -s
<micahg> gah
<micahg> I mean syncpackage -s
<bryceh> micahg, ok, didn't realize that was required.  It can't figure that out?  It did prompt me to login to LP.
<micahg> bryceh: it shows the sync requester on the -changes list
<lamont> this wonderful thing where unity decides that I want a full screen window because I moved it and it bumped into the top... how do I make it stop trying to help me that way?
<bryceh> micahg, ok.  Is that really all that important?
<micahg> bryceh: it shows up on the requester's +synchronised-packages page and will show up when we look for previous uploads if someone applies for dev membership
<micahg> it makes it like any other sponsored upload basically
<micahg> bryceh: there's also a -b flag for closing the sync bug
<bryceh> ah, I was looking for that
<micahg> (which happens to include whether or not it's sponsored)
<bryceh> *sigh* @ piloting.  bleah.
 * micahg hugs bryceh
<Laney> you don't feel happy with it?
<ogra_> lamont, that will immediately start working magically after you convinced it to have sane alt-tab behavior :P
<lamont> ogra_: I don't believe you
<ogra_> heh
 * ogra_ doesnt think either is easily changeable 
<lamont> ogra_: more seriously, in the way before time, I smashed unity-3d in the face about buttons in the title bar (moved them to the right), the moved to 2d because the rendering speed made things unusable, and well, I'd like to move the buttons back to the left now without reinstalling the machine... got any magic sause for me?
<ogra_> lamont, unity --reset
<ogra_> that should reset to defaults
<lamont> ah, but I still want focus follows *()^& mouse, even if that isn't quite as strict as I'd like it to be
<bryceh> Laney, was that Q for me?
<Laney> bryceh: yeah
<ogra_> lamont, https://launchpad.net/unsettings
<ogra_> lamont, thats what i used to switch back to FFM
<lamont> ta
<ogra_> (and for changing font settings etc)
 * lamont runs to fetch a kid
<infinity> ogra_: unity --reset is removed in Quantal.
<infinity> ogra_: But there's some gsettings invocation that will do vaguely the same thing.
<ogra_> sadly the utterly unusable alt-tab behavior is not fixable at all :(
<ogra_> i really wonder who thought its a good idea to make it app based vs window based
<infinity> lamont: The edge->max/tile behaviour is in the "Grid" plugin in ccsm.
<lamont> oh, ogra_ btw, unity --reset?  they dropped that
<infinity> lamont: Edge -> Resize Actions.
<ogra_> lamont, yeah, infinity said so too
<lamont> infinity: thanks
<lamont> anyway, afk
<ogra_> if ther is an equivalent unity --reset should really trigger it
<bryceh> Laney, ah, yeah just frustrating.  sometimes piloting gets a bit drudgery, lots of little details to tend to
<bryceh> but... a nice break from fixing graphics I guess ;-)
<micahg> Laney: you should try piloting some time :)
<Laney> yeah, I probably should
<smoser> hm...
<smoser> so i have one thought about my cloud-init fix https://launchpadlibrarian.net/115772437/cloud-init_0.7.0%7Ebzr644-0ubuntu1_0.7.0%7Ebzr644-0ubuntu2%7Eppa0.diff.gz
<smoser> if an entry is listed in /etc/network/interfaces
<smoser> but is not present
<smoser> then i'' emit a 'added' event for it.
<Presonus_Probs> Hi roomies :) first time user here, sorry if im in the wrong channel
<smoser> i could check for an entry in /sys/class/net/ but i'm not guaranteed for /sys to be mounted at that point.
<Presonus_Probs> Has anyone had any experience with Presonus Mixing desks and UbuntuStudio? Im having a few problems
<Presonus_Probs> already asked #UbuntuStudio, thought I'd throw it in here just incase
<TheMuso`> Presonus_Probs: I suggest you ask in #ubuntustudio.
<TheMuso`> oh sorry missed your second comment.
<Presonus_Probs> Thanks TheMuso
<Presonus_Probs> :) thought id chuck it in here just incase it was a common problem devs would know about
<TheMuso`> I don't think many, if any people in here work with firewire audio gear. Have you asked in any of the Linux audio IRC channels?
<TheMuso`> Presonus_Probs: Try #lad as well.
#ubuntu-devel 2012-09-14
<Presonus_Probs> nope! First time ever in Ubuntu and  xchat, though I used to use mIRC in high school.. can you poss recommend channels / servers to check on? Thx for your help
<TheMuso`> Yeah #lad is the only other channel I can think of.
<Presonus_Probs> will check it cheers :D Is there a reason noone uses firewire ie is it known to be a pain?
<TheMuso`> I don't think its that so much as this is a general Ubuntu development channel, and firewire audio is generally in the domain of those who are doing audio production.
<TheMuso`> Hense more specific to Ubuntu Tudio.
<Presonus_Probs> Thanks for your time :)
<malkauns> in 12.04 how do i change the color of the top horizontal panel?
<mbutubuntu> malkauns, this is a development channel, for support question use #ubuntu
<pitti> Good morning
<infinity> pitti: Hey, I'm just heading out, but sru-report was your code, right?
<pitti> infinity: right
<infinity> pitti: Can you run it on lillypilly and decipher the backtrace and decide if it's IS's fault or something and whine at the right people (or fix it)? :P
<infinity> pitti: It works locally, so I'm guessing firewall rules or some weird proxying or something, but I didn't have the urge to understand what was failing.
<infinity> (See above about heading out)
<pitti> infinity: I just deleted the launchpad cache dir, hoping that it will work again now
<pitti> it spammed me over night with the cron mails
<pitti> it seems deleting the LP cache works for a lot of similar problems
<pitti> infinity: I'll keep an eye on it over the day
<infinity> pitti: Oh, I didn't even think of a cache issue, since the trace sounded like an XMLRPC response issue, but if the cache just caches JSON objects, that would make sense.
<infinity> pitti: Thanks.
<pitti> infinity: it's at least running now for > 2 minutes
<pitti> infinity: FYI, I'll remove all langpacks from precise-proposed; dpm said they were unplanned and there are no current testing resources for them
<ScottK> infinity: In your copious free time, would you please accept libksane into precise-proposed when it appears in the queue.  I'd like to get it in and tested and released with the rest of KDE 4.8.5.
<ScottK> Actually it should be there now.
<ScottK> That's one I found over the weekend when I was upgrading my wife's computer.
<lifeless> slangasek: hi
<lifeless> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=330500
<ubottu> Debian bug 330500 in libpam-modules "default locale ignored, all locales are set to "POSIX"" [Important,Fixed]
<lifeless> I seem to be affected by this (and the fourth me-too on it reports it happening post-upload-that-should-fix-it)
<lifeless> slangasek: wondering whether you want diagnostics a login, etc
<dholbach> good morning
<darkxst> is apport-retrace known to be broken on quantal?
<darkxst> I always just get "ERROR: report file does not contain one of the required fields: CoreDump DistroRelease Package ExecutablePath"
<pitti> darkxst: you need to let the UI collect information first
<pitti> darkxst: or call apport-retrace with -R, if you are sure that packages didn't change since the crash
<darkxst> pitti, ok, I see, thanks
<darkxst> I have a huge stack of errors, hiding in the g-s message try, oops ;)
<cjwatson> lifeless: I specifically don't want lpmadison (though I don't object if somebody else wants to create it).  I need madison-lite/rmadison's particular behaviour anyway for all kinds of reasons, and I want it to be fast.  So yes, I know this comes up, and I know why you're suggesting it, but it isn't IMO a sufficient solution to the problem at hand.
<cjwatson> xnox: grub2/bios/lvm/luks> thanks
<cjwatson> infinity: grub2/powerpc> yeah, I saw in mail, will look
<cjwatson> SpamapS: I wonder if just consolidating the cache files would help; makes it more expensive to update but perhaps quicker to query.  But as you say maybe it should just be a vaguely proper DB.
<lifeless> cjwatson: k
<cjwatson> bdmurray: I've analysed bug 1047092 and reassigned to the proper place
<ubottu> Launchpad bug 1047092 in linux-firmware (Ubuntu) "Mini.iso doesn't load wireless drivers" [Medium,Triaged] https://launchpad.net/bugs/1047092
<cjwatson> ogasawara: ^- easy kernel fix, will help with the "no more alternate CD" project
<zyga> pitti, ping
<zyga> pitti, I'm working on the UDisks2 migration of checkbox, as you know, while testing the code I've noticed that the UDisks1 code has a few problems. In particular the 'dectect device removal' parts, current checkbox code monitors org.freedesktop.UDisks.DeviceRemoved (http://hal.freedesktop.org/docs/udisks/UDisks.html#UDisks::DeviceRemoved) yet watching dbus-monitor --system and trying various SD cards and thumb drives I can never see this signal being sent.
<zyga> I only see DeviceChanged signals. Could you shed some light on this please?
<zyga> pitti, to be precise, DeviceChanged gets sent for my SD card readers, DeviceRemoved gets sent, but for things like USB-HDDs
<ogra_> USB SD card reader ?
<ogra_> they often are providing a permament device and only emit a media changed signal
<ogra_> (like a CD rom)
<ogra_> i have only seen native SD readers that actually treat them as actual devices (vs USB media) (dev/mmcYXZ vs /dev/sdX)
<xnox> zyga: does UDisks1 run on quantal?! I can't seem to run usb-creator at all anymore.... failure to communicate with dbus.... which is pain because I cannot test / compare with UDisks2 back-end
<zyga> xnox, it's still installed as it's pulled by usb-creator
<zyga> xnox, usb-creator may just get confused as it may expect additional signals that no longer get sent
<zyga> xnox, (they get sent by udisks2 now)
<zyga> ogra_, yes USB
<zyga> ogra_, yeah, it seems to be the case
<zyga> ogra_, thanks
<xnox> zyga: hmm... well usb-creator-gtk fails to launch =(
<ogra_> :)
<zyga> xnox, are you rewriting it to udisks2?
 * ogra_ just ported usb-imagewriter to udisks and had the same issues :)
<ogra_> thogh i jumped from hal to udisks2 directly ... less pain :)
<zyga> heh :)
<zyga> usb-imagewriter? what is that?
<xnox> zyga: yeah... but I want to test it against both. Cause usb-creator has concepts of backends & I am adding UDisks2 backend to the UDisks1, well i did a few days ago.
<zyga> some low level friend of usb-creator-gtK?
<ogra_> a GUI frontend to dd
<zyga> ogra_, oh, cool!
<xnox> usb-imagewriter is usb-creators evil twin
<zyga> ogra_, doesn't gnome disks have that? (palimpset?)
<xnox> zyga: s/palimpset/gnome-disks/
<ogra_> it happened to me a few times that i accidentially used of=/dev/sda1 in dd
<xnox> =))))) lolz
<ogra_> which isnt so cool if thats your rootfs device
<ogra_> so i wrote usb-imagewriter that only shows removable devices
<zyga> ogra_, cool thing
<ogra_> to prevent me from such errors
<xnox> ogra_: do you have a trap for that now?!
<xnox> =)
<zyga> ogra_, push that to linaro please
<ogra_> its in universe :)
<ogra_> (not the final version with udisks yet but it will land before release since i want to refer to it on the arm install pages)
<alexbligh1> Naive library question: I have a library (libfreerdp1) which I am trying to update (for a PPA initially). It all builds, but dpkg-gensymbols complains that the symbol table is (very) different from the previous version. I know I could just replace the libfreerdp1.symbols files, but if the library is not binary compatible, should I be doing something else?
<ogra_> xnox, https://launchpad.net/usb-imagewriter the 1.99 tarball has a find_devices python script (pretty trivial and not 100% done yet) that shoud do it
<ogra_> hmm, didnt i also push that to a bzr tree ...
<xnox> alexbligh1: is it actually binary incompatible? is it C or C++? Is it only symbol additions or removals as well?
<xnox> alexbligh1: is it symbols that are now hidden by gcc4.7 and thus are private and should be marked optional?
<alexbligh1> xnox, I don't know, but it's failing a -c4 test which according to the manpage means 'new libraries'. It's C.
<xnox> alexbligh1: did you run abi checker (there are two good tools in the wild) and do they confirm that ABI is broken?
<ogra_> http://bazaar.launchpad.net/~ogra/usb-imagewriter/trunk/revision/20
<ogra_> there we go
<alexbligh1> xnox, nope.
<xnox> =/
<alexbligh1> xnox, what I'm trying to establish is what I need to do if the ABI /is/ broken. Right now I can no doubt get it to compile with dpkg-gensymbols -p (from memory).
<alexbligh1> (I presume)
<xnox> alexbligh1: make a new build (remove dpkg-gensymbols), take both debs (old & new) unpack in two parallel trees
<xnox> alexbligh1: install abi-compliance-checker write simple xml config file (paths to both  unpacked trees & extra -L and -I stanzas)
<xnox> alexbligh1: run it get html it will tell you if they are compatible
<alexbligh1> xnox, what do I need to override to remove the call to dpkg-gensymbols? The rules file is pretty bare at the moment
<cjwatson> Not remove but you could pass -c0 so that it doesn't fail
<cjwatson> override_dh_makeshlibs:
<cjwatson>         dh_makeshlibs -- -c0
<cjwatson> assuming dh7
<alexbligh1> cjwatson, thanks
<xnox> ;-)
<mpt> ev, <https://blueprints.launchpad.net/ubuntu/+spec/other-q-defects-dashboard> includes this line: "Split errors.ubuntu.com crashes per pockets (-updates, -proposed, etc)"
<mpt> Is that doable with the Launchpad API?
<mpt> I'm thinking items in the "all packages" menu ("-updates packages", "-proposed packages", etc)
<ev> hmm
<ev> mpt: I suspect we can start adding this information in with the report
<ev> using the origins data from apt
<mpt> ev, want a bug report for it?
<ev> please
<mpt> whoopsie?
<ev> and apport
<mpt> k
<ev> both will need changes
<ev> and daisy and errors
<ev> yay multiple bug targets
<ev> apport will need to include it, whoopsie will need to add it to the list of fields it sends, daisy will need to increment counters based on it, and errors will have to be adapted to show that
<ev> at least that's how its working in my head right now
<ev> I don't think getting the data from the launchpad API after we have the crashes works. There's no way to tell if a version came from -proposed or -updates (once it's there)
<ev> but maybe once it's in -updates we just assume viewers care about that?
<ev> hm
<mpt> reported bug 1050853
<ubottu> Launchpad bug 1050853 in Whoopsie "Not recorded whether an error is in a -proposed or -updates package" [Undecided,New] https://launchpad.net/bugs/1050853
<ogra_> ev, is https://rt.admin.canonical.com/Ticket/Display.html?id=55322 solved (working on the release team weekly report atm and i listed it as a blocker last week)
<pitti> zyga: hm, I'm not sure why udisks 1 wouldn't relay the device removed signals; can you run it in foreground/debugging mode and see whether it reacts to the uevents?
<pitti> zyga: if you see them in udisks2, you should also see them in u 1
<zyga> pitti, I suspect it never really removes the device, but sure
<zyga> pitti, udisks sees partitions going away
<zyga> (udisks2)
<pitti> zyga: that may be, but it shouldn't differ
<zyga> let me see
<pitti> zyga: perhaps there's something broken in udisks1, and nobody noticed because we don't really use it any more
<ev> ogra_: it is, yes
<ogra_> thx
<zyga> http://pastebin.ubuntu.com/1204518/
<pitti> zyga: you can run sudo /usr/lib/udisks/udisks-daemon --replace, and watch its output
<zyga> pitti, that's the removal with udisks --monitor
<zyga> oh, cool
<pitti> zyga: I'm mostly offline over the afternoon, working in a train; just spot-checking IRC
<zyga> http://pastebin.ubuntu.com/1204521/
<zyga> pitti, removed SD card with two partitions
<pitti> zyga: perhaps it just doesn't report the removals properly? the force-unmounting etc. seems to work fine
<zyga> pitti, the card reader?
<pitti> no, udisks1
<pitti> you can see the actual kernel events with udevadm monitor -e --udev
<zyga> pitti, udisks2 reported objects being removed (InterfacesRemoved IIRC) on each partition
<pitti> you shold see the removals there, and they ought to correlate with the udisks[12] daemon output
<zyga> ok, trying
<pitti> zyga: yeah, that's what I meant -- seems udisks1 is not reporting those; but do you need them?
<zyga> pitti, well the code was written to expect them and they do get reported, for example, when I remove a thumb drive
<zyga> pitti, no removal in udev
<zyga> http://pastebin.ubuntu.com/1204529/
<pitti> zyga: then I suppose you only removed the media, not the actual card reader?
<zyga> yes!
<zyga> :-)
<zyga> sorry if that was not evident
<zyga> but, some readers report the reader to go away as well
<pitti> weird, the kernel should at least send removal events for sdd1 and sdd2
<zyga> it's somewhat messy
<pitti> depends if you eject or "safe removal", too
<zyga> I just yank the card
<pitti> the latter powers down the reader (if it's on USB)
<zyga> but you are right
<zyga> if I do this it will permanently disable the reader (it's internal USB)
<pitti> zyga: then it seems there's something wrong with the media polling
<pitti> sd card readers are a bit of a nuisance and expose interesting corner cases
<pitti> perhaps you shold try this with an usb stick
<pitti> and we can debug the sd card reader on Monday
<pitti> (the polling)
<zyga> ok
<zyga> just quick question
<zyga> where is the polling implemented? udisks?
<pitti> so that you don't need to block on this
<pitti> no, the kernel does it these days
<zyga> ah
<zyga> pitti, http://pastebin.ubuntu.com/1204533/
<pitti> with the help of some udev rules to enable it
<zyga> pitti, adds are properly reported though
<zyga> ok
<zyga> thanks a lot :)
<pitti> yeah
<pitti> sd card readers and cd-roms just don't bother to report ejected media
<pitti> so something needs to poll them (yay hardware)
<zyga> well they report something, I get a changed event and udisks force-unmounts stuff
<pitti> yes, that's due to the polling
<zyga> DISK_MEDIA_CHANGE=1
<zyga> ah
<pitti> ah, so that works
<zyga> so a kernel bug on partitions?
 * zyga checks if they are still around
<zyga> YES
<zyga> both /dev/sdd{1,2} exist
<zyga> funny
<ev> mpt: replied to bug 1050853 and asked you, bdmurray, skaet, and pitti for your follow up thoughts.
<pitti> so, no idea why it doesn't remove /dev/sdd[12] then
<pitti> but that seems to be a bug at the kernel/driver level
<ubottu> Launchpad bug 1050853 in Whoopsie "Not recorded whether an error is in a -proposed or -updates package" [Undecided,New] https://launchpad.net/bugs/1050853
<zyga> ok, let's trace this next week
<pitti> zyga: usb sticks should behave more sensibly
<pitti> so, /me -> offline again, bbl
<jamespage> doko, when is the rebuild test scheduled for?  I can fixup maven-debian-helper (know the codebase a bit...)
<jamespage> I did suggest making it a little more intelligent - i.e. if its building jars for a libXXX-java to assume --java-lib even if not specified
<doko> jamespage, would like to understand the kernel/binutils issue first. but planning to start it tomorrow
<georgelappies> hi all, I am second year CS student and I am learning all these cool things like data structures and class templates STL etc in c++. I am looking for a c++ project where I can get my feet wet. Nothing as involved as chromium for instance at the moment. How can I see which apps are written in what language for ubuntu?
<cjwatson> 'apt-cache show PACKAGENAME' will show you its dependencies - just about anything written in C++ will depend on libstdc++6
<georgelappies> cjwatson, thanks :)
<cjwatson> although I would say that real-world programs use nowhere near the astonishing array of data structures that you learn in CS class, except in a tiny minority of cases
<cjwatson> for most things it turns out that a fairly small number of standard facilities are enough
<georgelappies> cool, yeah I must admit the course material is very generic.
<georgelappies> but nothing beats the feeling of trying to get your program to compile and run bug free :)
<georgelappies> but it seems like nearly everything in ubuntu is c and not c++
<georgelappies> does ubuntu ship with the qt library? I have qtcreator installed so I cannot check it on my system.
<SpamapS> georgelappies: Drizzle is a great one to take a look at
<georgelappies> SpamapS, thanks will check it out right away ;)
<SpamapS> georgelappies: its a fork of MySQL that has been refactored to take more advantage of the STL and do things in a more C++ way
<SpamapS> georgelappies: drizzle.org
<georgelappies> SpamapS, I am busy creating vm for ubuntu-server 12.04 to install drizzle in, should I go for the debs in the repo or should I try to get the latest code? If so where do I begin with that?
<SpamapS> georgelappies: if you're going to hack on the code, you want the trunk, 'bzr branch lp:drizzle'
<georgelappies> SpamapS, ok cool thanks I can just run that out of for instance ~/src on my main machine? sorry if these questions seem trivial but I complete noob atm.
<SpamapS> georgelappies: no worries. yes thats exactly what I do
<SpamapS> georgelappies: #drizzle is quiet, btw, but the devs do occasionally answer questions (myself included)
<SpamapS> doko: status on bug 1048710 ? Juju is dead in the water without a fix. :-/
<ubottu> Launchpad bug 1048710 in python3.2 (Ubuntu) "Regression in argparse for Python 2.7, 3.2 and 3.3" [Critical,Confirmed] https://launchpad.net/bugs/1048710
<doko> SpamapS, on my list
<SpamapS> doko: ok cool. Its worth noting that juju being broken also means all of the openstack QA for quantal is broken too. :-P
<georgelappies> SpamapS, roughly how much will bzr download the first time when checking out drizzle?
<SpamapS> georgelappies: oh.. heh.. a ridiculous amount..
<SpamapS> georgelappies: 267M	.bzr
<georgelappies> lol, ok cool :)
<jamespage> > samba < openjdk-7
<jamespage> gotta love big branches....
<SpamapS> georgelappies: the code is not small.. :)
<georgelappies> SpamapS, thank you
<georgelappies> SpamapS, ok while it is downloading some more noob questions: I first just want to confirm that it is not possible for me to corrupt or damage the bzr code. Will all the changes I make only effect my local code? how then many moons from now when I get to a situation where I may want to submit something will it get updated / reviewed?
<mpt> Can anyone tell me what <http://people.canonical.com/~ubuntu-archive/NBS/> (linked to from <http://reports.qa.ubuntu.com/reports/ogasawara/weatherreport.html>) is for?
<SpamapS> georgelappies: right, you can't hurt anything. You have to be in the drizzle developers team to commit code to the main trunk
<SpamapS> georgelappies: what you can do right away is make a change, commit it (locally), push it to launchpad, and then propose it for merging
<SpamapS> mpt: NBS == Not Built from Source
<SpamapS> mpt: means they are binaries whose Source: does not exist
<mpt> SpamapS, interesting. How was the binary built, then?
<SpamapS> mpt: previously, when the source existed
<mpt> SpamapS, so why would the source have disappeared?
<georgelappies> SpamapS, thanks for your detailed assistance it much appreciated.
<SpamapS> mpt: archive maintenance presumably
<SpamapS> mpt: forgive me, I misspoke. The source: is still there, but no longer builds that particular binary
<mpt> SpamapS, so there is source for a newer version that hasn't built yet, and the source for the built version has been deleted?
<SpamapS> mpt: even if the newer version has been built, the old binaries aren't removed on publish
<SpamapS> mpt: because of the reverse deps on them, that would break the archive
<mpt> SpamapS, ah, so that's why the individual files in that directory are lists of dependencies
<SpamapS> mpt: for the libs, the rdeps just need a rebuild most likely
<cjwatson> mpt: Also, the more usual thing we look at nowadays is http://people.canonical.com/~ubuntu-archive/nbs.html
<cjwatson> Same data but more helpfully formatted
<mpt> splendid
<SpamapS> yeah that one is much better :)
<cjwatson> mpt: This is essentially a to-do list for the +1 maintenance team
<mpt> thanks cjwatson, thanks SpamapS
<cjwatson> ogasawara: ^- you might like to update the weather report to point to the new NBS location
<cjwatson> Though maybe just the link, as I suspect the location you're pointing to at the moment is easier to count automatically
<ogasawara> cjwatson: ack, will do.  also I'll get that fix for 1047092 uploaded shortly.
<cjwatson> (And, indeed, +1 maint has been making good progress on that list lately ...)
<cjwatson> ogasawara: Thanks
<mlankhorst> hey
<mpt> cjwatson, one final question: Who is the "+1 maintenance team"? I don't see them searching for "maintenance" on LP
<cjwatson> mpt: It's a frequently rotating team, so not expressed in LP.  https://wiki.ubuntu.com/PlusOneMaintenanceTeam
<mpt> thanks
<cjwatson> Currently Matthias and Didier according to that schedule
<slangasek> lifeless: er, considering that bug has been fixed since 2005, you probably have a different bug?
<slangasek> lifeless: yes there is a metoo on the bug that's after the upload, but if this were a pam problem a lot more people would've reported it over the past 7 years :)
<akheron> I'm unable to install quantal from usb stick
<akheron> bug 1050590
<ubottu> Launchpad bug 1050590 in grub-installer (Ubuntu) "failed install of quantal beta: grub efi package failed" [Undecided,Confirmed] https://launchpad.net/bugs/1050590
<akheron> this isn't reported by me but seems to be exactly the same bug
<akheron> according to syslog, apt-install grub-efi cannot download the package for some reason
<akheron> any workarounds?
<cjwatson> akheron: I'm currently waiting to pick up a hire car; I'll have a look at your problem when I get home
<cjwatson> since I expect it's related to GRUB 2.00
<akheron> cjwatson: ok, thanks
<akheron> I'll be actually leaving work right now, and the hardware is left here
<akheron> but I'll be back on monday
<akheron> I'll read irc, though, if you have suggestions
<cjwatson> I expect I'll just fix it rather than offering suggestions
<cjwatson> If the hire co's computer systems ever come back up
<cjwatson> (If it takes too long, then I won't be able to fix anything until Monday)
<ogra_> sell them ubuntu support contracts while you're there waiting ;)
<cjwatson> It is tempting, but there are issues with revealing one's knowledge of computers in this kind of situation
<rickspencer3> lol
<ogra_> lol, i know exactly wht you meana
<ogra_> *mean
<infinity> ScottK: Do you care that the changelog for libksane is wrong (the actual change to debian/control appears correct)
<cjwatson> akheron: Oh.  This has nothing to do with GRUB 2.00, from that other user's log.  Either the nameserver fell over at a suspiciously inconvenient time (unlikely with multiple reports, though still possible), or the resolver configuration was broken mid-install.  (It's also a bit odd that grub-efi-amd64 apparently wasn't available locally, without going to the network.)
<cjwatson> akheron: I'll have to look at this in more depth on Monday.
<infinity> pitti: So, uhm, did the same weird accident happen five hours ago for lucid?
<infinity> pitti: Or were those 300+ langpacks intentional?
<ScottK> infinity: Not really.
<mitya57> ScottK: Hi, can you please look at lp:~mitya57/+junk/python3-defaults, especially r170?
<mitya57> ScottK: (POX doesn't respond, and the bug is quite important)
<ScottK> mitya57: What bug?
<mitya57> ScottK: http://bugs.debian.org/685167
<ubottu> Debian bug 685167 in python3 "py3clean removes *.pyc of foreign packages" [Important,Open]
<ScottK> If it's urgent, I'd ask barry.  I'm unlikely to have any time to look at it before the middle of next week.
<mitya57> ScottK: does barry have push access to pkg-python bzr?
<ScottK> I think so, if not, I'll push it after he reviews/tests.
<infinity> ScottK: Accepted, then.
<ScottK> infinity: Thanks.
 * mitya57 hopes barry will read this eventually
<alkisg> stgraber: sshfs-fuse has a bug that results in fat clients offering to "execute / open" text files instead of just opening them. The upstream dev posted a patch in a mailing list, I was planning to upload a fixed sshfs package in the greek PPA, but maybe it's worth it to SRU it instead?
<alkisg> LP bug #1017870
<ubottu> Launchpad bug 1017870 in Nautilus "Nautilus prompts to execute plain text files on sshfs mounts" [Medium,In progress] https://launchpad.net/bugs/1017870
<mitya57> That can't be SRUed until it's fixed in quantal...
<stgraber> alkisg: oh, that's an actual sshfs bug, not nautilus as the bug seems to indicate?
<stgraber> alkisg: anyway, yeah, it's a bug so if the patch is of a reasonable size, I'd go with pushing to quantal + SRU to precise
<alkisg> stgraber: yes, the nautilus devs pointed me that it might be an sshfs bug, and I posted in the sshfs mailing list and the dev there proposed a fix
<alkisg> The diff is there, pretty small: http://sourceforge.net/mailarchive/forum.php?thread_name=87y5keushb.fsf%40tucsk.pomaz.szeredi.hu&forum_name=fuse-sshfs
<alkisg> I'll attach the patch to the bug report and target quantal, hope someone uploads it
<micahg> alkisg: you'll have more luck if you attach a debdiff and subscribe ubuntu-sponsors
<micahg> and fill out the SRU paperwork
<alkisg> debdiff it is, thank you
 * alkisg hates paperwork but it's the right thing to do... :(
<micahg> alkisg: so, 2 debdiff, 1 for quantal, and 1 for precise, I"ll give you a bug task for precise
<stgraber> alkisg: let me know once you have the diffs on the bug (ideally debdiffs) and I'll review + upload to quantal and precise
<alkisg> OK, doing so...
<cking> is anyone seeing issues with libreoffice since the last load of updates?  The global menu for it sometimes does not appear and I'm getting segfaults when inserting graphs from my data sets
<micahg> bug 1044657?
<ubottu> Launchpad bug 1044657 in libreoffice (Ubuntu Quantal) "[regression] Missing LO menus when not run in Unity" [High,Fix committed] https://launchpad.net/bugs/1044657
<cking> hrm, well I am running unity with the global menus disabled (cough)
<cking> so,yes, looks possible
<cking> ah, actually, I've just double checked on my test box and I get the same issue with unit + global menus
<cking> bah, now it's segfaulted again, /me files a bug
<alkisg> sshfs-fuse version number is 2.4-1, would the fixed package version be 2.4-1ubuntu1 or 2.4-1-0ubuntu1 ?
<micahg> alkisg: for quantal 1ubuntu1
<alkisg> Ty
<slangasek> cjwatson: not sure if I'm looking at a grub bug or an aptdaemon/u-m bug, but grub-pc has hung for me at a ucf prompt that I'm not seeing
<stgraber> alkisg: 2.4-1ubuntu1 for quantal and 2.4-1ubuntu0.1 for precise
<alkisg> stgraber: does this look ok to propose for merging? https://code.launchpad.net/~alkisg/ubuntu/quantal/sshfs-fuse/sshfs-fuse-lp1017870/
 * alkisg followed https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff ...
<stgraber> alkisg: precise => quantal in the changelog
<alkisg> Ouch, fixing...
<stgraber> alkisg: the change should also be properly registered in debian/patches. If you're using bzr-builddeb you can do that by running "bzr bd -e && dpkg-source --commit", then enter a name for the patch (bug number should do) and enter a short description in the editor that will open
<alkisg> Fixed the changelog...
<infinity> doko: By the way, all the Pandas are (finally) running precise, so I'd say we're good to go for test rebuilds.
<stgraber> once the patch created by dpkg-source --commit, add all the new files created by it and commit that and you should be good
<barry> ScottK: i'll take a look
<ScottK> Thanks.
<alkisg> stgraber: could you have another look? http://bazaar.launchpad.net/~alkisg/ubuntu/quantal/sshfs-fuse/sshfs-fuse-lp1017870/revision/15
<stgraber> alkisg: sure
<stgraber> alkisg: looks good!
<alkisg> OK, should I propose it for merging, and do the same for precise?
<stgraber> alkisg: just give me a similar branch for precise, I'll take care of merging and uploading
<alkisg> Thanks :)
<stgraber> alkisg: but yeah, when you don't already have someone taking care of this for you, the usual process is to propose for merging on Launchpad so it shows up on the sponsoring report
<alkisg> Gotcha
<stgraber> alkisg: oh, for the precise one, can you also run update-maintainer? I just noticed that was missing in the quantal one and did it for you
<alkisg> (08:54:50 Î¼Î¼) stgraber: alkisg: 2.4-1ubuntu1 for quantal and 2.4-1ubuntu0.1 for precise ==> precise has 2.3-1, so would it be 2.3-1ubuntu1 instead ?
<alkisg> Sure
<stgraber> alkisg: oh, for some reason I thought they had the same version. So use 2.3-1ubuntu0.1 for precise
<alkisg> Ty
<stgraber> alkisg: quantal one uploaded
<alkisg> stgraber: https://code.launchpad.net/~alkisg/ubuntu/precise/sshfs-fuse/sshfs-fuse-lp1017870/
<alkisg> stgraber: ignore that
<alkisg> Forgot bzr add, reuploading...
<alkisg> stgraber: ok, done
<stgraber> alkisg: thanks
<stgraber> alkisg: finishing something else, will merge and upload in a few minutes
<lifeless> slangasek: probably yes.
<lifeless> slangasek: anyhow, I have the symptoms :)
<mterry> ev, how do I associate a bug with a line in errors.ubuntu.com?
<stgraber> alkisg: looking now
<alkisg> ty
<geofft> Is there a particularly good way for me to recompile one kernel module with different Kconfig options?
<geofft> Preferably without recompiling the whole kernel, and preferably getting a .deb out of it, but that might be hard
<stgraber> alkisg: uploaded to precise-proposed
<dobey> geofft: #ubuntu-kernel might be more help
<alkisg> stgraber: thanks man
<slangasek> lifeless: right, so, what symptoms do you have specifically?  'dpkg-reconfigure locales' is a no-op on Ubuntu
<slangasek> lifeless: in what pam service context do you see the problem, what are the contents of /etc/default/locale, what are the env vars that are or aren't set
<lifeless> slangasek: I ssh into an lxc container I have
<lifeless> slangasek: /etc/environment and /etc/defaulte/locale have en_US set, locale-gen has create en_US (utf8 in both cases)
<lifeless> after login LANG and LANGUAGE and LC_ALL are empty, and the other LC variables are set to POSIX
<lifeless> setting my LANG and LANGUAGE in my outer session to various values seems to have no effect.
<lifeless> the lxc container is lucid, with no changes made to the ssh config, postgresql installed and thats about it.
<lifeless> oh, rabbitmq as well
<lifeless> slangasek: I'm not familiar enough with where the locales are setup to be very effective debugging atm :(
<slangasek> lifeless: /etc/pam.d/sshd unmodified?  (should have 'auth       required     pam_env.so envfile=/etc/default/locale')
<lifeless> slangasek: checking
<lifeless> auth       required     pam_env.so envfile=/etc/default/locale
<lifeless> /etc/default$ cat locale
<lifeless> LANG="en_US.UTF-8"
<lifeless> LANGUAGE="en_US"
<slangasek> lifeless: not that this would impact the variables being set or not, but I think LANGUAGE should be set to en rather than en_US, no?
<lifeless> slangasek: AIUI you can say LANGUAGE="en_AU:en_US:tlh_UK:en" to do fallbacks
<lifeless> slangasek: however I tried a few things, happy to fiddle.
<lifeless> slangasek: the odd thing is that LANGUAGE and LANG are empty in the output of locales in the container
<slangasek> right
<slangasek> do you have syslog capabilities within the container?  might want to crank up the debugging in both ssh and pam_env (which takes a 'debug' argument)
<lifeless> I imagine so
<lifeless> yes, it has a syslog
<stgraber> lifeless: I usually install language-pack-en in the container to fix that kind of issue, though generating the locale with locale-gen should work just as well (and it doesn't explain the empty environment)
<lifeless> so, the pam.d/sshd file is the one to change for pam_env? What would it look like ?
<lifeless> stgraber: its installed
<lifeless> ii  language-pack-en                                      1:10.04+20110931
<lifeless> stgraber: first thing I checked.
<lifeless> OK WTF
<lifeless> its now working.
<slangasek> heh
<lifeless> I spent an hour this yesterday.
<lifeless> I  bet I can reproduce, and that something is only evaluated at container startup.
<lifeless> because thats the one thing I didn't do at all.
<stgraber> lifeless: for a while we had an apparmor/kernel bug that was preventing writes to /usr/lib/locale/locale-archive and that'd have caused similar symptoms, but that's been fixed in the first kernel sru after the 12.04 release
<lifeless> stgraber: I have no /usr/lib/locale/locale-archive
<lifeless> stgraber: the container is lucid
<lifeless> lsb_release -a
<lifeless> No LSB modules are available.
<lifeless> Distributor ID: Ubuntu
<lifeless> Description:    Ubuntu 10.04.4 LTS
<lifeless> slangasek: stgraber: thanks for your attention on this. :/
<achiang> anyone around familiar with gnome-power-manager? i just grabbed the source thinking there might be power policy in there, but a quick glance looks like "not really"
<mdeslaur> achiang: I believe you're looking for gnome-settings-daemon
<achiang> mdeslaur: ah, thanks for the hint
<mdeslaur> achiang: look in plugins/power
<achiang> mdeslaur: thanks. that's... not so intuitive. :)
<mdeslaur> achiang: +1
<slangasek> yes, gnome-power-manager should be renamed to gnome-power-observer
#ubuntu-devel 2012-09-15
<akheron> cjohnston: ok, thanks
<akheron> erm
<akheron> cjwatson: ok, thanks
<akheron> cjwatson: I tried three times, the last time without checking the "download updates while installing" box
<akheron> every time I got the same error, and tried to ping the apt server right after the error, and it resolved just correctly
<alkisg> Hi, could someone check LP bug #978654 to verify if I correctly did a branch merge proposal?
<ubottu> Launchpad bug 978654 in aptdaemon (Ubuntu) "<type 'exceptions.UnicodeDecodeError'>: 'ascii' codec can't decode byte 0xc3 in position 24: ordinal not in range(128)" [Medium,In progress] https://launchpad.net/bugs/978654
<ogra_> hmm, hasnt aptdaemon been ported to py3 yet ?
<ogra_> oh, pkcompat.py defaults to /usr/bin/env python in the shebang
<ogra_> alkisg, is python 2.7 installed alongside py3 on that system ?
<ogra_> (python3 should actually handle strings in utf-8 without having to decode them, the issue looks more like a python version issue)
<alkisg> ogra_: default precise system
<alkisg> When is python3 becoming the default? In 12.10?
<ogra_> oh, precise, yeah, ignore me then :)
<alkisg> ogra_: dbus.String('ÎÎµÎ¹Î±') fails in Quantal as well
<ogra_> right py3 should eb the default in 12.10
<alkisg> python -c 'import dbus; dbus.String('ÎÎµÎ¹Î±');'
<alkisg> ==> traceback etc etc
<ogra_> python3 -c ....
<ogra_> the binary has a version suffix
<alkisg> But aptdaemon doesn't have #!python3 in its headers...
<alkisg> *shebang
<ogra_> ogra@horus:~/devel/packages/aptdaemon-0.45+bzr861$ grep -r python3 *|wc -l
<ogra_> 73
<ogra_> ogra@horus:~/devel/packages/aptdaemon-0.45+bzr861$
<ogra_> ogra@horus:~/devel/packages/aptdaemon-0.45+bzr861$ grep -r bin/python3 *|wc -l
<ogra_> 4
<alkisg> head -n 1 pkcompat.py => #!/usr/bin/env python
<ogra_> thats what i meant :)
<ogra_> aptd and aptcon are py3 already
<ogra_> pkcompat.py isnt
<ogra_> for precise your fix is fine
<alkisg> While for quantal they're going to port pycompat.py to python3 after ff?
<ogra_> from quantal on the proper fix would be to port pkcompat
<ogra_> not sure anyone is on it atm though
<alkisg> Also I'm wondering what happens when a python2 module imports a python3 module
<ogra_> given its nearly 3000 line i doubt we'll see a port in time
<alkisg> So, if pkcompat.py is python3, and it's imported from a python2 script...
<ogra_> there are compatibility layers for imports
<alkisg> Ah, nice then
<ogra_> i dont have the links to the porting guide here but google should help if yu want to look
<alkisg> Nah, we have major bugs to work on, this is just so that we don't have to disable apport completely
<ogra_> in any case you should try to get a signoff from glazor ...
<alkisg> (it's annoying to have all students complain about crashes they see all the time)
<alkisg> How do I do that?
<ogra_> hope that he comes around on IRC or mail him
<alkisg> OK
<ogra_> (sebastian heinlein, his name and address is all over the code )
<alkisg> The most pressing bug we need to solve is the keyboard layout problem... I wonder why it remains broken for so much time, even before 12.04...
<ogra_> well, does it occurn in non ltsp setups ?
<alkisg> Yeah
<alkisg> In all default multilingual setups
<ogra_> oh, i thought it was just ltsp
<alkisg> So, maybe in half of the ubuntu installations
<ogra_> did you talk to colin about it yet ?
<alkisg> No, I didn't know who to ping, I asked here a couple of times but got no response
<ogra_> well, it often helps to look at the changelog and ping the person that did the most uploads there ;)
<alkisg> Btw the bug does _not_ occur in LTSP ;)
<ogra_> ah :)
<alkisg> Only in the server, which doesn't use LDM
<ogra_> so we should just convert all ubuntu installs to localhost ltsp loopback sessions ;)
<alkisg> Haha, or replace lightdm with ldm :D
<ogra_> yeah, easy fix
<ogra_> :)
<ogra_> people wouldnt even notice you replaced the DM ... their names are so close ;)
<alkisg> pitti: hello... since you were the one to help us (=greeks, russians etc) with gdm and LP bug #460328, I wonder, could you do the same for lightdm and LP bug #1051288? Same bug, different DM... :(
<ubottu> Launchpad bug 460328 in gdm "Wrong keyboard settings when console-settings has multiple layouts" [Medium,New] https://launchpad.net/bugs/460328
<ubottu> Launchpad bug 1051288 in lightdm (Ubuntu) "LightDM assumes there's only ONE system default layout" [High,Confirmed] https://launchpad.net/bugs/1051288
 * penguin42 just wonders whether bug 1040557 has been discussed with Samsung
<ubottu> Launchpad bug 1040557 in Ubuntu CD Images "UEFI boot live-usb bricks SAMSUNG 530U3C laptop" [Critical,Confirmed] https://launchpad.net/bugs/1040557
#ubuntu-devel 2012-09-16
<KRF> debfx: related to https://bugs.launchpad.net/ubuntu/+source/zsh/+bug/1029337 - could request another merge for 5.0.0-2,  i am especially looking for the patch "[0b3b271c] Do not use echoti {smkx,rmkx} unconditionally".
<ubottu> Launchpad bug 1029337 in zsh (Ubuntu) "Merge zsh 5.0.0-1 (main) from Debian experimental (main)" [Undecided,Fix released]
<KRF> see http://packages.debian.org/changelogs/pool/main/z/zsh/zsh_5.0.0-2/changelog
<infinity> KRF: Done.
<infinity> debfx: I grabbed that zsh merge for you.
<KRF> nice one!
<KRF> thanks
<pabs3> with the email interface on launchpad, is it possible to link a bug to a Debian bug? how would I do that?
<Laney> I don't see (from the documentation) that you can do that :(
<tumbleweed> you can add a task through the e-mail interface, and add a bug watch, by linking to the debian bug, but can't associate the task with the watch (that I can see)
<tumbleweed> in fact, bug 244630
<ubottu> Launchpad bug 244630 in Launchpad itself "Ability to link to bugs in other bug trackers from the email interface" [Low,Triaged] https://launchpad.net/bugs/244630
<pabs3> thanks tumbleweed
<alexbligh1> If I have package foo and package bar, and foo depends on a ppa version of bar (with a patch in), who do I specify that in a Depends: line in foo's debian/control?
<pabs3> Depends: bar (>= 1.2.3.4...)
<alexbligh1> pabs3 but if I have bar_1.0.1-1ubuntu2alex1_amd64.deb which is a patched version of bar_1.0.1-1ubuntu2_amd64.deb, and the repo publishes a bar_1.0.2-1ubuntu2_amd64.deb, I want my package foo to ensure that bar does not get upgraded because it's (somehow) dependent on the local 'alex' version.
<infinity> alexbligh1: Then make it an exact relationship (= 1.2.3)
<infinity> alexbligh1: Not ideal, and makes upgrade ordering a bit of a pain.
<infinity> alexbligh1: The real answer is "teach your users how to use apt pinning to prefer packages from your repository".
<alexbligh1> So can I do bar (=1.0.1-1ubuntu2alex1)?
<infinity> alexbligh1: Alternately, "if your patches are suitable for upstream or Ubuntu, submit them".
<alexbligh1> Oh the patch is already upstream, in fact it's a backport of a patch which is upstream (and did not make Precise). I just don't want a security upgrade to wipe out the patch.
<infinity> If it's suitable for an SRU, you could still submit a patch for precise.
<ogra_> you could just ask for an SRU if the patch isnt to intrusive
<alexbligh1> nah it's a feature upgrade.
<infinity> Fair enough.
<infinity> Then yeah, either apt pinning, or use exact depdendencies.
<infinity> dependencies, too.
<ogra_> or ask for a backport ;)
<alexbligh1> Well, the patch concerned is a patch to libfreerdp to access hyper-v VMs. Would you take that as an SRU? I'm guessing not.
<infinity> It's possible.  We did a lot of last-minute work for precise on hyperv in other areas.
 * infinity decides to go have a birthday nap.
<Laney> rock and roll
<alexbligh1> Hmm, interesting. I thought SRU was pretty much strictly only for bugfixes and security issues? I can't just use a newer libfreerdp as they appear to have done 'interesting things' to the ABI in the mean time.
<alexbligh1> In fact 'interesting things' to the API as well.
<penguin42> infinity: Happy birthday!
#ubuntu-devel 2013-09-09
<Caesar> I've forgotten how to mark a bug as applicable to multiple releases of Ubuntu, can someone help jog my memory?
<RAOF> Caesar: Also affects series
<RAOF> Hm. IIRC.
<Caesar> RAOF: Is the UI for that access restricted?
<RAOF> Caesar: It's âNominate for seriesâ, and the nomination is not restricted (AFAIK), but acceptance of the nomination is restricted.
<Caesar> Aha. https://answers.launchpad.net/launchpad/+question/152525
<Caesar> I'm not a bug supervisor
<dholbach> good morning
<pitti> Good morning
<ivebeenlinuxed> Hi, does anyone know when the netboot image for Ubuntu 13.10 is going to be built?
<cjwatson> ivebeenlinuxed: The final one will only be days before final release, but you can always use the development one
<cjwatson> ivebeenlinuxed: Oh, I see that http://cdimage.ubuntu.com/netboot/ doesn't link to it yet - is that what confused you into thinking it was unavailable?
<ivebeenlinuxed> Yeah - even going to a logical direct link (netbook/saucy) doesn't give anything either
<cjwatson> ivebeenlinuxed: I've updated that page now
<cjwatson> ivebeenlinuxed: You will have to make sure to update any images you download frequently though, as they'll get out of sync with newer kernels uploaded to saucy
<ivebeenlinuxed> Awesome! I'm just interested to see how Mir/XMir is coming along (without burning the CD, as I have a TFTP server already set up for development). In another note, I am interested in getting into Ubuntu development, but need to find a good way of starting...
<infinity> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 1 released | Archive: Open, FF | 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: infinity
<infinity> FYI: I'm at a sprint right now, so my patch piloting will be spotty, but if anyone needs something specifically from me, nick highlight me.
<jbicha> rsalveti: what should be done about the 'elementary' package since enna and intone ftbfs against the new version?
<rsalveti> jbicha: hm, let me take a look
<rsalveti> jbicha: yeah, would need some porting, and upstream for both seems to be dead, and not following the latest efl changes
<rsalveti> will give it a try later today
<jbicha> rsalveti: ok, otherwise we can remove it from saucy-proposed since it's only in Debian experimental
<rsalveti> jbicha: yeah
<zul> what does "xxx has no binaries on any arch " mean?
<Laney> probably that it failed to build
<slangasek> mlankhorst: hi, can you have a look at bug #982889 and tell me what needs to happen?  According to Franz, this bug still affects the quantal X stack in precise.  I guess we need a quantal SRU followed by an enablement stack update?  Not sure if the 12.04.0 X also needs an update
<ubottu> bug 982889 in xorg-server-lts-quantal (Ubuntu Saucy) "X trying to start before plymouth has finished using the drm driver" [Undecided,New] https://launchpad.net/bugs/982889
<cjwatson> barry: did you notice the tox build failure?
<barry> cjwatson: i didn't.  looking now
<barry> cjwatson: looks like we'll need to syncpackage python-pip 1.4.1 to fix the tox ftbfs
<sarnold> seb128: hey, I think the retraces are busted agaiun
<seb128> sarnold, we need to get you access to those ;-)
<seb128> sarnold, yeah, the amd64 one is down for a week :/
<seb128> they are down more often than running nowadays
<seb128> slangasek, pitti, I wonder if we should just skip over bugs rather than stop the retracers until somebody goes to look at the log/remove the lock
<slangasek> seb128: that sounds like it might help... but then, I'm still not getting emails about it when there are locks
<slangasek> so our monitoring should apparently be fixed
<slangasek> seb128: where exactly to the locks show up?  Maybe we should set up another cronjob to notify when there's a deadlock
<seb128> slangasek, right, I've no idea about that, the crontab has MAILTO properly filed from what I can tell
<seb128> slangasek, ~ubuntu-archive/lock.<arch> ... but how do you tell a valid lock apart from a leftover?
<slangasek> seb128: check for a running process?  (Does the lockfile contain a pid?)
<seb128> slangasek, no, it's an empty file
<slangasek> hmm, how indeed then
<seb128> well, that's open source, you can submit a patch to apport to make it write the pid in the lock :p
<sarnold> seb128: down for a week, ouch.. they do a lot of awesome magic in the background when they just work..
<pitti> seb128, slangasek: the main idea about stopping the retracer was to avoid untagging five hundred crashes and failing on them
<seb128> sarnold, yeah, they do, and I expect there are not so many problems but they keeping hitting the same ones
<slangasek> seb128: or maybe it holds the lock open while running?  either way would be reasonable
<pitti> seb128, slangasek: but we can certainly grep out the failures from the logs and re-tag them
<seb128> pitti, do we need to untag on failures?
<seb128> pitti, or said differently "why does it untag if the retracing doesn't success"?
<seb128> it should be the last thing in the process
<seb128> before going to next one in the queue
<pitti> (in discussion, just reading with half an eye)
<pitti> seb128: if you don't, you need additional smarts to not re-process them over and over again
<pitti> infinite loop
<pitti> in fact, if the cron mail was working reliably, this wouldn't be such a problem
<seb128> pitti, seems like we could change the tag rather than remove it
<pitti> seb128: yes, we could
<seb128> pitti, http://paste.ubuntu.com/6084644/ is the current log ... it's not really verbose on the issue :/
<pitti> but still, the "stop at exception" was still from times when LP changed every other day, and the apport retracing itself was being developed
<seb128> pitti, the recent failures are mostly like that
<pitti> presumably these days the errors that we'll see are mostly not systematic any more, but glitches in LP/network
<seb128> right
<seb128> recently I just remove the lock
<seb128> and it's going through again for a few days
<seb128> it's not like it was hitting bugs on specific bugs
<pitti> yeah, then we could just change it to not stop at an error, but just log it instead
<seb128> +1
<pitti> but we need to ensure it doesn't loop on a particular bug
<seb128> I would still like to figure why emailing is not working
<seb128> pitti, slangasek: did you try to ask IS if emails where going through from that box?
<pitti> seb128: no, not yet
<slangasek> no, was going to send test mails first
<pitti> seb128: sometimes I do get mail, but it seems most often I don't
<seb128> pitti, I would rather change the tag, e.g put it retrace-need-review or something
<pitti> seb128: there's an apport-retrace-failed tag already
<seb128> slangasek, ok, I'm going to let you do that then
<pitti> but we use that mostly for "gdb didn't figure out a good stack trace'
<seb128> pitti, right
<seb128> pitti, we might want to tag bugs differently because those might be apport issues
<seb128> bugs in the retracing
<pitti> seb128: right
<seb128> e.g that list is worth reviewing
<pitti> like, in the LP/launchpadlib/network chain
<seb128> pitti, should I open a wishlist about it?
<pitti> sure
<slangasek> osageorange log shows mail being relayed, but it hasn't been delivered to me
<slangasek> oh, there it is now
<slangasek> so cron mail delivery seems to be ok
<pitti> From ubuntu-archive@osageorange.canonical.com  Mon Sep  9 20:45:03 2013
<pitti>  Subject: Cron <ubuntu-archive@osageorange> echo "testing cron mail" >&2
<pitti> this one?
<slangasek> yep
<pitti> slangasek: yes, as I said I do get the cron fail mail sometimes, but not reliably
<slangasek> well, but maybe that's because apport isn't reliably generating any output on failure?
<pitti> well, exceptions are being shown in the log, so the exit status ought to be non-zero
<slangasek> does that generate a mail from cron?  I thought the trigger for mail was output on std{err,out}
<pitti> oh, I see how the i386 one would do that
<pitti> as after crash-digger it runs the duplicate db without saving the exit stauts
<pitti> but the amd64 retracer only calls crash-digger
<seb128> pitti, https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1222978
<ubottu> Launchpad bug 1222978 in apport (Ubuntu) "Should tag retracing problems rather than stop on them" [Undecided,New]
<pitti> From ubuntu-archive@osageorange.canonical.com  Wed Sep  4 20:48:05 2013
<pitti>  Subject: Cron <ubuntu-archive@osageorange> schroot -q -c quantal-amd64 -- sh -
<pitti> that's the last one which I got
<pitti> seb128: merci
<seb128> pitti, de rien ;-)
<seb128> pitti, same for me, most recent was sep 4 20:48
<seb128> pitti, the content of that email doesn't even really makes sense to me
<seb128> oh, it's from the dup checking job
<barry> cjwatson: s/pip/virtualenv/ but i still think we need to sync pip too.  sign.  ffe's coming
<smoser> infinity, you're sru teaming today, could you please look at https://bugs.launchpad.net/ubuntu/+source/ubuntu-cloudimage-keyring/+bug/1218963 ?
<ubottu> Launchpad bug 1218963 in ubuntu-cloudimage-keyring (Ubuntu Raring) "SRU ubuntu-cloudimage-keyring into archive" [Medium,In progress]
<pitti> seb128: ah, the sep 4 one was dupcheck?
<seb128> pitti, yes
<seb128> pitti, in fact it seems I receive only dupchecks emails
<pitti> hm, that also redirects output and stderr to a log file
<pitti> it's not structurally different to the amd64 one
<pitti> so I wonder why one is sending mails, but not the other
<seb128> pitti, that box goes back to 30/04/2013 here and I only got dupcheck emails
<seb128> so we never receive retracing emails anymore
<pitti> but it's certainly more likely that the cron jobs are wrongly defined than mails only being sent sometimes
<pitti> it seems that cron doesn't actually care about the exit status?
<slangasek> pitti: right, I believe that's correct
<pitti> so that's probably it
<slangasek> it only mails you when there's output
<slangasek> so since all the output is redirected... :)
<pitti> we probably need something like crash-digger || tail -n 10 logfile ?
<slangasek> yeah, that should do the job
<pitti> curious why I sometimes do get mail then
<seb128> how did it use to work?
<seb128> pitti, you get emails from the dupchecker
<pitti> right, but that's also doing >> log/dupcheck.log 2>&1
<slangasek> right, I haven't gotten any mails about these locks at all since being added to the crontab
<seb128> pitti, hum, indeed
<seb128> weird
<slangasek> pitti: https://code.launchpad.net/~vorlon/apport/crashdigger-proper-lockfile/+merge/184660
<pitti> changed the crontabs
<pitti> with the || tail approach
<pitti> so it now ought to send cron mail
<pitti> slangasek: I think os.write is expecting bytes, not str
<slangasek> pitti: the whole program is currently python2... would you like me to fix that? :)
<pitti> slangasek: ah, it's python3 in the saucy branch
<slangasek> ah
<pitti> but we use a trunk checkout
<slangasek> indeed
<pitti> slangasek: still from the days when we used older chroots for retracing; at this point we can probably switch trunk to py3, thanks for reminding
<pitti> slangasek: see setup.py, it fixes the shebangs during install, depending on which py version you called setup.py installwith
<pitti> "install with"
<mlankhorst> slangasek: honestly I need a way to reproduce it :s
<mlankhorst> slangasek: and no the bugfix won't help
<slangasek> pitti: aha, ok, so the code is actually bilingual on trunk - will fix
<pitti> slangasek: yeah, for releasing I run the test suite for both py2 and py3
<pitti> slangasek: probably easiest to just append an .encode()
<pitti> brb
<slangasek> right, encode, sigh
<seb128> slangasek, pitti: \o/ emails work (ignore the email, I just stopped it manually to test)
<pitti> seb128: yay
<pitti> slangasek: cheers, merged (with NEWS) and rolled out
<SuperLag> Just curious, why were the alternative install images removed as an option?
<infinity> smoser: Maaaaybe.
<slangasek> SuperLag: because two images take more effort to maintain than 1, and the desktop images now supported all our major use cases
<infinity> And any usecases the desktop images don't cover is still covered by the d-i netboot images.
<pkern> Are they supported?
<infinity> They're not not supported.
<pkern> infinity: Because you want to avoid an unconditional Â»yesÂ«? :P
<infinity> Or, to put it differently, we have some very large commercial customers who depend on the d-i images working correctly, so if someone tells you they're not "supported", that's a bit of a lie. :P
<pkern> I have a specific commercial customer in mind, which is why I ask.
<slangasek> pkern: subtle
<pkern> slangasek: He brought it up.
<slangasek> :)
<slangasek> it's ok, your secret is safe with me
<pkern> Pah
<infinity> Heh.
<pkern> I wonder if that means that d-i QA remains in place or if commercial customers could still file issues if they're broken. Which seem to be two different things. ;)
<infinity> We do some d-i QA for sure, plus rely on it heavily internally, plus are happy to address bugs filed.
<infinity> So, it's fairly supported, it's just not as heavily focused on as the live images by certain people.
<infinity> It also breaks less spectacularly and less often, mind you. :P
<pkern> Apparently beating d-i into shape for a realease can also be some significant effort. :)
<pkern> *release
<infinity> smoser: Is ubuntu-cloudimage-keyring meant to live in universe, or will that be changing?
<infinity> pkern: We put remarkably little effort into it, actually, except when introducing new targets (which I'm doing this afternoon...)
<slangasek> pkern: generally not when one only has 4-5 archs to support :)
<seb128> qengho, seems like you moved files between binaries and forgot a Replaces: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1222488
<ubottu> Launchpad bug 1222488 in chromium-browser (Ubuntu) "package chromium-browser-l10n 28.0.1500.71-0ubuntu3 failed to install/upgrade: trying to overwrite '/usr/lib/chromium-browser/remoting_locales/th.pak', which is also in package chromium-browser 28.0.1500.71-0ubuntu3" [Undecided,Confirmed]
<seb128> qengho, (it just happened there as well)
<smoser> infinity, ideally main. i probably should file MIR bug for that.
<smoser> (i can do that RSN)
<infinity> pkern: And I don't mean "we put little effort in, therefor it's buggy", I mean it mostly Just Works.  Except when doing new features.
<infinity> smoser: Well, given its contents, I'd happily just NEW it to main in the 3 SRUs, and approve your saucy SRU.  File it now.  And seed it to supported.
<infinity> smoser: s/saucy SRU/saucy MIR/
<smoser> ok. i'll file MIR.
<infinity> smoser: Cool.  I'll go have a smoke while you do that.
<smoser> it will be a depends of MAAS but currently is not.
<smoser> infinity, bug 1222997.
<ubottu> bug 1222997 in ubuntu-cloudimage-keyring (Ubuntu) "[MIR] ubuntu-cloudimage-keyring" [Undecided,New] https://launchpad.net/bugs/1222997
<mterry> barry, heyo.  I assume that python-oauthlib still doesn't have the server OAuth bits that a package like keystone would need?
<mterry> barry, keystone wants to be in main and it wants to pull in python-oauth2...
<mterry> zul, ^
<barry> mterry: hi.  zul just pvtmsg'd me about it :)
<barry> mterry: a couple of things: idk if oauthlib has grown much server side support (or the support you need).  our oauthlib is way behind debian, so i need to file an ffe to get that updated/sync'd (i'm working on a stack of python packages today, so i'll add that to the list).  it's a bummer that python-oauth2 doesn't have py3 support afaict
<infinity> smoser: MIR approved, promoted in saucy, and accepted in p/q/r.
<smoser> gracias.
<mterry> barry, not that server cares yet about py3, but I feel ya
<barry> mterry: yeah ;)
<mterry> zul, are you in a position to determine if the latest python-oauthlib from Debian has enough/any server OAuth support?
<barry> mterry, zul: very high level, but https://github.com/idan/oauthlib/blob/master/README.rst#changelog
<mterry> barry, zul: sounds like they have *some* provider (server) support
<barry> mterry: right, that's what it looks like.  is it enough for you?
 * mterry shrugs
<infinity> smoser: And shuffled through binary NEW as well now.
<zul> mterry/barry: im not sure yet ill poke at it tonight
<barry> zul: np.  if expediency requires continued use of python-oauth2, i think that'll be fine for saucy, but please put a bug on the radar for porting to oauthlib for treading tiger
<zul> barry:  https://bugs.launchpad.net/ubuntu/+source/keystone/+bug/1223010
<ubottu> Launchpad bug 1223010 in keystone (Ubuntu) "Use oauthlib rather than oauth." [Undecided,New]
<cjwatson> barry: OK, I'll leave the fix up to you if you're on it :)
<pitti> xnox: jibel and I just debugged a 5 s boot hang, and it's the ancient "/etc/initramfs-tools/conf.d/resume has wrong UUID" problem again
<pitti> this is still bug 50437
<ubottu> bug 50437 in initramfs-tools (Ubuntu) "Resume from hibernation may fail because swap partition UUID does not match /etc/initramfs-tools/conf.d/resume" [Medium,Triaged] https://launchpad.net/bugs/50437
<pitti> xnox: could it be that ubiquity is calling mkswap after ./scripts/plugininstall.py (where it detects the UUID)?
<pitti> xnox: but perhaps we should fix initramfs-tools to update the UUID at update-initramfs time, so that it will also survive changes to swap partitions?
<barry> zul, mterry: LP: #1223004
<ubottu> Launchpad bug 1223004 in python-oauthlib (Ubuntu) "[FFe] sync with debian which has 0.5.1" [Undecided,New] https://launchpad.net/bugs/1223004
<ogra_> pitti, does logind have an equivalent to ck-list-sessions ?
<pitti> ogra_: yes, "loginctl"
<ogra_> mterry, ^^^
<pitti> ogra_: or "loginctl show-session c1" (or another session name)
<mterry> pitti, thanks
<darkxst> oh what happened with Bug #1189309? It seemed to be uploaded to raring-proposed instead of saucy?
<ubottu> bug 1189309 in libappindicator "nm-applet crashed with SIGSEGV in gtk_status_icon_set_visible()" [High,Confirmed] https://launchpad.net/bugs/1189309
<darkxst> pitti, hi
<darkxst> pitti, https://bugzilla.gnome.org/707769, we inhibit the lid switch, which stops the screen from locking
<ubottu> Gnome bug 707769 in power "Lid close doesn't lock screen if lid-close-action not set to suspend" [Major,Unconfirmed]
<darkxst> pitti, seems like we should instead take a suspend inhibitor from do_lid_closed_action()? does that sound right?
<darkxst> pitti, nm, was just a silly bug
<darkxst> infinity, can you take a look at Bug #1189309? It seemed to be uploaded to raring-proposed instead of saucy?
<ubottu> bug 1189309 in libappindicator "nm-applet crashed with SIGSEGV in gtk_status_icon_set_visible()" [High,Confirmed] https://launchpad.net/bugs/1189309
<infinity> darkxst: Want that rejected from raring-proposed and reuploaded to saucy?
<infinity> darkxst: I assume the bug should also move from libappindicator to network-manager-applet?
#ubuntu-devel 2013-09-10
<darkxst> infinity, yes on both those
<infinity> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 1 released | Archive: Open, FF | 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:
<infinity> darkxst: Done.
<darkxst> infinity, thanks
<ghena1986> http://bit.ly/183GBEv
<smb> infinity, In the unlikely event you are still around, could you accept xen in raring?
<dholbach> good morning
<JackYu> dholbach, morning:)
<dholbach> hi JackYu
<seb128> is anyone working on getting the kernel that fixes aufs out of proposed?
<seb128> apw, ^ do you know?
<seb128> the autolanders are still screwed since today's iso still has the buggy kernel :/
<apw> seb128, that is waiting for d-i
<seb128> apw, is anyone working on getting d-i updated?
<apw> seb128, i do not know if anyone is no, normally they are pretty snappy at doing it, but it has some seed complexity so we arn't yet able to do it
<apw> and some of the keener members are sprinting
<seb128> apw, who is "they", cjwatson?
<seb128> right :/
<apw> and infinity
<seb128> I fear it's going to be one of those days where CI is going to be screwed until Lexington people are in the office
<seb128> apw, thanks
<apw> seb128, i suspect that tells one that CI has a fundamental need to be able to select older things, like here the kernel boots, yuo could downgrade it and do the tests no problem
<apw> so although the kernel is holding CI, if it holds CI, CI is broken
<seb128> apw, I suspect they can downgrade the kernel or boot an old one, the issue is that "they" are all in Lexington this week :/
<apw> seb128, then that is more of a problem for velocity ...
<seb128> right
<seb128> apw, btw is there any way we could have an autopkgtest or something that make sure aufs loads/work on kernel updates in the futur?
<apw> seb128, perhaps, aufs has never been a gating feature before however, as union mounts have only been 'consumed' by CDs and if one of overlayfs or aufs work enough for that we are 'good' to go
<seb128> we, seems our CI/daily landing rely on it nowadays
<apw> seb128, heh, well it is always good to see communication working so well
 * apw is tempted to revert the fix for a bit to focus the mind
<seb128> shrug
<seb128> let's just try to get d-i uploaded today and move on
 * seb128 just wants fixes to land to saucy
<seb128> (fixes for unity/touch components)
<apw> seb128, this is one case where no manual override for CI is a fail
<apw> seb128, can't you just upload it, like one would have to do in a fail scenario
<apw> seb128, it would be a good test for the recovery process
<seb128> apw, well, we still have direct upload available
<seb128> but then we need to get the diffs merged back
<seb128> so it's double work
<apw> seb128, so test it on your laptop, with the fixed kernel and upload, win
<seb128> I guess I could do that
<seb128> anyway
<seb128> apw, thanks for the replies, I've annoyed you enough about the topic, moving on to get stuff uploaded ;-)
<apw> heh ... it is always good to test these paths :)
<Chipaca> since yesterday's update, my chromium has no chrome :-(
<Chipaca> i had forgotten how clunky firefox was :)
<seb128> Chipaca, yeah, seems like something is wrong with the update :/
<seb128> qengho is not around at this time though
<seb128> Laney, that's going to teach us to override tests :p
 * Laney glares
<seb128> Chipaca, can you open a bug? https://launchpad.net/ubuntu/+source/chromium-browser/+filebug
<Chipaca> also, just started a guest session to check whether it was my account or my machine, and the guest session started on the same vt
<Chipaca> keyboard and mouse was still in the old vt
<Laney> chromium has an apport hook
<Laney> probably better to use ubuntu-bug chromium-browser
<Chipaca> switched to a console to kill the guest user, and everything i typed also went to the terminal i had open in my xmir session
<Laney> that's the bug mjg59 has been on about
<seb128> seems like more mir and vt fun
<Laney> at least the second part is
<Chipaca> i thought it'd been fixed before we were told to use it
<seb128> I though they got it fixed
<Chipaca> holy boogers :-(
<Laney> https://bugs.launchpad.net/xmir/+bug/1192843
<ubottu> Launchpad bug 1192843 in XMir "XMir receives input from other VTs" [Critical,In progress]
<seb128> Chipaca, can you ubuntu-bug chromium-browser?
<Chipaca> seb128: am on it already :)
<seb128> Chipaca, thanks
<Laney> HAHA
<Laney> I just did my daily dist-upgrade and got a file conflict on chromium :D
<seb128> Laney, that's bug #1222488
<ubottu> bug 1222488 in chromium-browser (Ubuntu) "package chromium-browser-l10n 28.0.1500.71-0ubuntu3 failed to install/upgrade: trying to overwrite '/usr/lib/chromium-browser/remoting_locales/th.pak', which is also in package chromium-browser 28.0.1500.71-0ubuntu3" [High,Confirmed] https://launchpad.net/bugs/1222488
<Laney> yes
<Chipaca> yesterday my session crashed in the middle of the upgrade so i missed that (hence why i needed to confirm if it was me or everybody affected)
<seb128> I ran into it yesterday and pinged qengho about it
<Laney> ho hum
<cjwatson> apw: I'll sort that out nowish then
<cjwatson> seb128: ^-
<Chipaca> bug #1223251
<ubottu> bug 1223251 in chromium-browser (Ubuntu) "latest chromium update is a bucket of unquantifiable fail" [Undecided,New] https://launchpad.net/bugs/1223251
<Chipaca> seb128: ^
<Laney> it does have chrome for me, fwiw
<Chipaca> *now* you tell me :)
 * Laney shrugs
<Laney> still a bug
<Chipaca> next you'll tell me ctrl+t still opens tabs for you
<Laney> I'm sure there's a more constructive bug title you could have used :(
<Chipaca> ooohhh. ctrl+n opens a window with all the chrome on it
<Chipaca> Laney: where's the fun in that?
<Laney> Thinking of poor old qengho reading that in his bug mail
<apw> cjwatson, hey thanks, you are a star as always
<Chipaca> well... it seemed better than "broken in a number of different ways", in that you'd get a chuckle out of it
<cjwatson> debfx: Do you think you could merge cdbs from Debian?  It doesn't look like too unreasonable a set of changes (at least from the changelog), and it's blocking liblwp-protocol-psgi-perl in -proposed.
<cjwatson> And libtest-checkdeps-perl.  Maybe others.
<debfx> oh no, did I make the mistake of touching cdbs?
<lool> pitti: Q on unattended-upgrades: why run the testsuite or specifically things like pep8/pyflakes in autopkgtests rather than at build time?
<tseliot> ScottK: I hope my comment answered your question on bug 1095751
<lool> (I can imagine /some/ tests require doing upgrades and what not, but pyflakes / pep8 are safe to run at build time?)
<ubottu> bug 1095751 in bcmwl (Ubuntu Precise) "bcmwl fails to build with 3.8 kernels [error: âstruct cfg80211_ibss_paramsâ has no member named âchannelâ]" [High,In progress] https://launchpad.net/bugs/1095751
<pitti> good morning
<pitti> darkxst: all good now?
<pitti> lool: unattended-upgrades> it just runs the whole testsuite during autopkgtest; pep8 in autopkgtest admittedly doesn't make much sense, so ideally we could filter out that one test
<lool> pitti: I looked at upstreaming this, but the debian version has quite a lot of pep8 errors; FYI the current pep8 test is only on test/*.py rather than on the whole source tree; I'll try to fix these issues in the next hour or so
<pitti> lool: ah, thanks; I did an upload yesterday to at least make the autopkgtest fix again, but more refinements are certainly appreciated
<pitti> lool: after mvo left that whole update-manager/unattended-upgrades/etc. stack is a bit of an orphan
<lool> pitti: ack
<spot_> new ubuntu does not work out of the box
<GSport> HDMI sound isnt working
<infinity> GSport: raring?  If so, you need to dist-upgrade to the latest kernel.  The shipped one on the CD image had an HDMI sound bug.
<GSport> nice try but i got the daily build
<infinity> GSport: Well, you said "new Ubuntu", which was pretty non-specific.
<infinity> GSport: Please file a bug, then.  "ubuntu-bug linux".  This isn't a support channel.
<GSport> sorry i meant the newest build
<GSport> yes something crash after login
<GSport> but you seem to need to register
<GSport> to post the auto bug thing
<infinity> You do, yes.  But asking random people on IRC to debug something *right now* won't work, hence the request to file a bug.
<GSport> nice way to keep the bug reports manegable
<GSport> and nice way to mine email adresses
<infinity> You can use a throwaway email address.  *shrug*
<GSport> you got one to hand me?
<infinity> A design decision we made in our bug tracker a decade ago probably isn't going to change based on someone's complaint today.  And we're hardly the only people who require you to log in to file a bug.
<GSport> because i hate filling form
<GSport> s
<GSport> like im asking you to change anything
<GSport> keep it the way you always have
<GSport> if its working out for you
<GSport> never mind the users
<GSport> im just realizing that linux only seem to work fine on the deves boxes
<GSport> besids the xchat app goes to a debian channel
<GSport> by default
<GSport> on OFTC irc network
<GSport> being so well funded seem like ubuntu is pretty amatorish
<cjwatson> we've had over a million bugs filed, if an account requirement is to "keep the bug reports manageable" then it isn't doing a very good job :-)
<GSport> a million is alot more managable that 10 million
<GSport> even on windows that sia colse enviroment you dont need to register to upload bug reports
<GSport> i cant see the use of email after they invented IM
<GSport> must be a nix preform
<ogra_> you would want to use IM for say a 5 page document that discusses a complex code fix with a group ?
<GSport> google groups?
<ogra_> erm
<ogra_> didnt youo just complain you need to register with a mail address ? how would using google groups prevent that ?
<GSport> news gtoups?
<ogra_> and thats the future ?
<GSport> news groups is newer that email
<ogra_> what ?!?!
<GSport> news groups need no registration
<ogra_> GSport, http://en.wikipedia.org/wiki/Usenet#History
<ogra_> (though technically you might be right, mail is likely a few months older)
<GSport> im sorry i want around when they invented it
<GSport> wasnt*
<GSport> the volume icon didnt even worked
<slangasek> GSport: that's all well and good, but to get actionable bug reports requires a reliable feedback channel to the submitter.  That means email.  We've taken deliberate steps to not require accounts and email addresses for crash reports because those can operate at scale and give us the information we need without having to ask users for details, but for what you're talking about there needs to be a dialog between the developer and the user
<slangasek> ... dialog happens by email
<slangasek> so if you want someone to take a look at this issue for you, you're going to have to submit a bug report
<GSport> email isnt a dialog
<GSport> IM is a dialog
<GSport> like irc
<slangasek> this isn't something that arguing with us about is going to change
<GSport> i couldnt care less
<GSport> i never going to use this crap anymore ever
<GSport> i dont have money to buy a new computer if this one breaksdown
<GSport> probablly you are in the buisness of breaking pcs so that people buy macs
<cjwatson> Please take this elsewhere; if you don't like Ubuntu that's fine but we're not here to be abused
<arnoldk__> Darn, I missed out on the troll?
<cjwatson> pitti: postgresql-9.1 in -proposed dropped the libraries on the grounds that -9.3 would be providing them instead, but -9.3 isn't in saucy(-proposed).  Is that a forgotten sync, a missing FFe, ...?
<slangasek> cjwatson: I guess the export should be in the memdisk config, right?
<cjwatson> slangasek: I think so
<slangasek> cjwatson: er, I mean in the embedded config
<slangasek> well, you tell me which I mean ;)
<cjwatson> slangasek: No, I think it wants to be at the same level as where you set root=tftp
<slangasek> ok
<cjwatson> The main menu execution should be a child of that execution context
<cjwatson> slangasek: This is all based on the hypothesis that what you meant by your comment in the MP was that when you got to the real menu all the tftp-set env vars had gone away
<cjwatson> Or similar
<slangasek> cjwatson: hmmm unfortunately the net_* variables include some net-device-specific ones
<slangasek> net_efinet8_ip=10.98.5.66
<cjwatson> slangasek: Yeah, that was why I said we could come up with something neater
<cjwatson> slangasek: If this is actually the problem then we could make those be automatically exported, say
<slangasek> oh, so just do this to see if it works, got it
<cjwatson> Right
<cjwatson> pitti: Also, what's the best way to set things up so that I can get useful retraces of parted crashes?  parted ships -dbg packages which are a separate build pass (because they turn on extra malloc debugging), so I want real dbgsyms rather than dummy ones; should I just add it as a special case in pkg-create-dbgsym alongside python?
<cjwatson> Doesn't really seem ideal since it might change
<slangasek> do you mean the crash was generated using the -dbg packages, and now you need the corresponding backtrace?
<cjwatson> No, I mean the crash was generated using the non-dbg packages, and I can't get a backtrace because (a) -dbg is from a different build pass (b) pkg-create-dbgsym thinks it only needs to generate dummy -dbgsym packages because -dbg exists
<slangasek> ah
<cjwatson> Maybe I should just turn the -dbg packages into plain separated-debug-symbol packages in Debian.  mtrace is supposed to have no effect if MALLOC_TRACE is unset in the environment anyway
<slangasek> I didn't realize pkg-create-dbgsym skipped when there was a -dbg package; I'm skeptical that this is actually sensible
<cjwatson> parted is probably just Doing It Wrong, now that I look at it, but I'm sure we have the same problem elsewhere
<cjwatson> This makes it irritatingly hard to attack bug 1215458 though
<ubottu> bug 1215458 in The Dell-poweredge project "Auto-partitioning with LVM on Advanced Format Disks causes parted_server segfault" [High,In progress] https://launchpad.net/bugs/1215458
<GSport> why has ubnutu satanic edition stoped being developed?
<pitti> cjwatson: p-9.1> ah, got to fix that to build the libs on saucy, will do; thanks for the poke
<pitti> cjwatson: I think if we special-case the dbg generation in parted, then we need to do a corresponding special-case in p-create-dbgsym
<pitti> cjwatson: if that happens in more cases, we could try to come up with some way how pkg_create_dbgsym could see that the -dbg package is not a real -dbg package
<Riddell> jbicha: I plan to update libdvdread with this http://starsky.19inch.net/~jr/tmp/install-css.sh
<pitti> slangasek: infinity asked for this to lessen the impact of -dbgsym packages in the librarian, as they essentially just duplicate the same bits that are already in -dbg
<cjwatson> pitti: Yeah, as I say I think the parted case is moot, I'm going to reorganise its handling
<Riddell> jbicha: medibuntu is going away and videolan will replace it
<slangasek> pitti: right; but the proper fix for this is actually to make Debian get ddebs done and get maintainers to stop adding -dbg packages by hand :)
<pitti> slangasek: fully agree; just that the past two attemps of doing that stopped/failed :(
<smoser> anyone able to get meegingology in #ubuntu-meeting ?
<smoser> it seems to have gone elsewhere.
<Laney> smoser: try #ubuntu-bots
<smoser> Laney, what is its name ?
<Laney> I think AlanBell is the guy, maybe
<dobey> GSport: doesn't sound like an official ubuntu derivitive. you should ask whoever was making it.
<dobey> GSport: likely it would have to be renamed, due to invalid use of the ubuntu trademark
<cody-somerville> cyphermox: Any chance you'll do an SRU for quantul for lp #1011073?
<ubottu> Launchpad bug 1011073 in libdbusmenu (Ubuntu Quantal) "NetworkManager submenus sometimes unpopulated" [High,Triaged] https://launchpad.net/bugs/1011073
<cyphermox> cody-somerville: yes, let's
<cyphermox> I'll look at this tonight
<mterry> adam_g, heyo!  I'm looking at your python-troveclient package.  During the test run when building, I see a lot of errors like "run.py: error: no such option: -t"
<cody-somerville> cyphermox: thanks! :) much appreciated.
<cody-somerville> cyphermox: I think the problem might also affect LibreOffice so am looking forward to getting that fix. :)
<adam_g> mterry, thanks for looking. hmm. let me check on that.
<mterry> adam_g, it doesn't stop the build...  but it seems like maybe it isn't running all the tests (and I'm curious why it wouldn't fail the build  :))
<pitti> cjwatson: uploaded p-9.1 fix to unstable, I'll sync it in a few hours when it's imported
<cyphermox> cody-somerville: aye
<pitti> cjwatson: I understand it's not immediately urgent as the current broken version is just held back in -proposed, right?
<cody-somerville> cyphermox: Once you get it in proposed, I'll test it out. I think it might allow us to close lp #1045353 and lp #1085169
<ubottu> Launchpad bug 1045353 in hud (Ubuntu) "LibreOffice commands are not displayed in the HUD" [Undecided,Confirmed] https://launchpad.net/bugs/1045353
<ubottu> Launchpad bug 1085169 in indicator-appmenu (Ubuntu) "LibreOffice Menus Stop Working even with libreoffice>=1:3.6.2~rc2-0ubuntu4 and indicator-appmenu>=12.10.3-0ubuntu2.1" [Undecided,Confirmed] https://launchpad.net/bugs/1085169
<pitti> zul: neutron autopkgtests> NB you can (and should) just add test deps to debian/tests/control's Depends:, instead of calling apt-get install
<pitti> that'll create easier to read output if the test fails (as it does right now as python-jsonrpclib doesn't exist)
<adam_g> mterry, looks like a general issue with the projects test suite / its use of testrepository https://jenkins.openstack.org/view/All/job/gate-python-troveclient-python27/52/console
<mterry> adam_g, where does run.py even live?  Is it just a testr thing?  Could we run the tests a different way that would work better?
<adam_g> mterry, /usr/share/pyshared/testrepository/commands/run.py
<adam_g> mterry, nosetests works fine, but Ran 162 tests (nose) vs Ran 324 (+162) (testr)   /me doesn't know enough about testr to interpret that
<lifeless> adam_g: there is a bugin testr at the moment, off-by-x2 reported count
<adam_g> lifeless, so we're not missing much using nose instead?
<lifeless> adam_g: in what context?
<lifeless> adam_g: I haven't read all the backlog
<adam_g> lifeless, just some seemingly non-fatal errors form test suite during build of python-troveclient https://bugs.launchpad.net/ubuntu/+source/python-troveclient/+bug/1223097
<ubottu> Launchpad bug 1223097 in python-troveclient (Ubuntu) "[MIR] python-troveclient" [Critical,Incomplete]
<lifeless> adam_g: but in terms of tests that are run, those counts seem fine; nose is an intruisive little beast though so I can't comment on much else
<lifeless> you're talking about the
<lifeless> 2013-08-06 04:27:54.432 | Usage: run.py [options] <cmd> <action> <args>
<lifeless> 2013-08-06 04:27:54.432 |
<lifeless> 2013-08-06 04:27:54.433 | run.py: error: no such option: -t
<lifeless> stuff ?
<adam_g> lifeless, yup
<lifeless> I thought they fixed that ages back
<lifeless> -> #openstack-trove
<lifeless> adam_g: ok so thats an upstream problem, and it's cosmetic: there are unit tests running the cli code that aren't isolating their test environment correctly.
<lifeless> adam_g: you can ignore it and run with testr just fine.
<adam_g> lifeless, ill make a note in the bug. thanks for your input
<lifeless> adam_g: I've reported the issue upstream, hub_cap and I had discussed this in the past
<lifeless> adam_g: they thought it was fixed :)
<cjwatson> pitti: right - thanks
<pitti> zul: "apt-get intall" failed :/
 * pitti throws zul an "s" :)
<pitti> zul: but with the 2>&1 >/dev/null this would really be better as a test depends:, to see errors from package installation
<zul> pitti:  *sigh*
<darkxst> pitti, yeh all fixed now, had nothing to do with inhibitors ;)
<pitti> zul: FYI, you can test that locally with run-adt-test -s -S file://`pwd` (in the unpacked source tree)
<pitti> http://developer.ubuntu.com/packaging/html/auto-pkg-test.html
<zul> pitti:  cool thanks
<Noskcaj> stgraber, Do you ming if i merge installation-report ? It's a translation only upload
<cjwatson> uh, that needs to be done in bzr or you screw us up
<stgraber> Noskcaj: I'd rather do it myself quickly than have to fix the bzr branches after you cowboy it.
<stgraber> Noskcaj: debian-installer packages are special
<Noskcaj> stgraber, ok
 * Noskcaj should probably find something better to do than looking for bugfix releases on MoM
<cjwatson> it's kind of the wrong time of the cycle for that, really
<Noskcaj> cjwatson, i know
<Noskcaj> my internet speed and lack of coding ability stop me from doing anything else
<cjwatson> incidentally, while it isn't the case here, translation-only merges of d-i packages can be less trivial than they look sometimes; a number of those packages have branding changes and those require considerable care with translations to avoid causing other people work retranslating things that only differ by Debian/Ubuntu
<Noskcaj> thanks for the tip cjwatson
<cjwatson> (for example anna, which I'm doing now)
#ubuntu-devel 2013-09-11
<bjv> how much space should be available for /boot fs in saucy? i have 175MiB
<bjv> but i'm getting http://askubuntu.com/questions/298487/not-enough-free-disk-space  .. and ihave only 1 kernel installed
<sarnold> bjv: my /boot currently occupies 207 megabytes, but you might do a better job cleaning out old kernels than I do.
<Noskcaj_> debfx: Do you want me to (attampt) to merge cdbs or are you going to do that?
<jbicha> Noskcaj_: is there a bugfix in cdbs that you need? otherwise it's kinda late in the release cycle for that
<Noskcaj_> jbicha: It's blocking things in -proposed.
<Noskcaj_> last night cjwatson asked debfx to merge it, i've got nothing to do so i was going to try and help with it
<jbicha> oh ok
<TheMuso> c
<zul> can someone on the release team have a look at https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/1223342 please
<ubottu> Launchpad bug 1223342 in neutron (Ubuntu) "[FFE] neutron-vpn-agent and neutron-metering-agent" [Undecided,New]
<crass> I just submitted some patches to the distro specific scripts in cryptsetup.  It appears as though these are mostly maintained by debian, with perhaps a few modifications by ubuntu.  What's the best way to get the patches accepted?  Through debian or ubuntu?
<infinity> crass: If your fixes aren't Ubuntu-specific, a bug filed in Debian is more generally helpful to all.
<asac> infinity: hey
<asac> infinity: could it be that proposed is off?
<asac> for maintenance work?
 * asac impatient and scared :)
<infinity> asac: We're adding arm64 to the archive, everything's temporarily off.
<infinity> asac: Shouldn't be much longer at all.
<asac> infinity: what does it mean?
<asac> in time?
<infinity> asac: About 30 seconds.
<asac> nice!!
<asac> 30
<asac> 29
<asac> :)
<asac> infinity: i will check in 3 minutes ... let meknow if there are any problems
<infinity> Well, the next publisher run triggers at 10:18, but close enough.  We're re-enabling the world now.
 * asac happy
<asac> we just managed to get unity and stuf fin shape
<asac> were eagerly reloading exuses :)
 * asac goes for a smoke :
<asac> infinity: all going well?
<infinity> asac: iz doing publishy tings.
<asac> sounds like its doing the right thing to me
<infinity> You just like French accents.
<didrocks> speaking of Frenchâ¦ ;)
<didrocks> infinity: https://launchpad.net/ubuntu/+source/unity-system-compositor/0.0.1+13.10.20130903-0ubuntu2, I'm surprised this one is building while https://launchpad.net/ubuntu/+source/unity8 isn't even in proposed. Source publishing (or whatever it is) is working differently?
<infinity> didrocks: We don't need to publish source to build.
<infinity> didrocks: Builds begin as soon as a package is uploaded.
<didrocks> ah ok, and so binary copy just need a "publish" to appear in proposed I guess
<infinity> Indeed.
<didrocks> great, unity8 now in
<didrocks> seems like pinging infinity gives hint to the publisher, I should try that more often :)
<infinity> *smirk*
<infinity> Well, we don't shut off the world and add new architectures very often.
<didrocks> yeah, it's just that murphy's law loves us ;)
<infinity> Nah, this isn't murphy, it's just a group of people who are always impatient. :)
<didrocks> speaking of being impatientâ¦
<didrocks> any way to bump priority on https://launchpad.net/ubuntu/+source/unity-system-compositor/0.0.1+13.10.20130903-0ubuntu2/+build/4953829 if possible?
<infinity> didrocks: That high enough for you?
<didrocks> infinity: as long as we don't have buffer overflow, it's high enough to me ;) thanks!
<asac> 5 i386 builders sounds pretty low
<StevenK> asac: 5 i386 distro buildds, yes.
<StevenK> There's a whole bunch more for PPAs
<asac> StevenK: are those 5 bare metal machines?
<asac> or 5 VMs on 2 machines?
<StevenK> asac: Yes
<StevenK> asac: All of the distro buildds are bare-metal
<asac> StevenK: how are we doing sizing of the builder pool?
<asac> e.g. how do we get to the number of 5?
<StevenK> I'm not sure how that number was arrived at
<asac> infinity: any idea why mir is a valida candidate and is not going in since 6 days?
<asac> on excuses?
<infinity> asac: You want _output
<infinity> Trying easy from autohinter: mir/0.0.10+13.10.20130904-0ubuntu1 unity-mir/0.1+13.10.20130904.1-0ubuntu1 platform-api/0.18.3+13.10.20130904-0ubuntu1
<infinity> leading: mir,unity-mir,platform-api
<infinity> start: 181+0: i-86:a-32:a-29:p-34
<infinity> orig: 181+0: i-86:a-32:a-29:p-34
<infinity> easy: 184+0: i-87:a-33:a-30:p-34
<infinity>     * i386: unity-system-compositor, unity-system-compositor-autopilot
<infinity>     * amd64: unity-system-compositor
<infinity>     * armhf: unity-system-compositor
<infinity> ie: updating that package set makes unity-system-compositor and unity-system-compositor-autopilot uninstallible.
<didrocks> hence my recent upload
<asac> infinity: ok, guess a feature missing that excuses cannot give human readable reasons for all cases yet?
<infinity> asac: No, excuses and output are two phases in the process.
<infinity> Poorly named, perhaps, blame ajt, but they represent two distinct sets of steps.
<asac> output is not really easy to parse
<asac> but ok
<infinity> It's not terribly human-friendly.  That could be improved by someone who likes writing pretty frontends.
<infinity> I'd be happy to teach them how to read it if they wanted to.
<asac> hmm. think having one page that has all the exceuses and reasons that make stuff stuck would be awesome
<asac> but later
<asac> thanks
<infinity> I think having one page that's essentially packages.qa.debian.org with little portlets and some friendly info would be nice.
<infinity> But, yes, not tonight. :)
<asac> :)
<asac> the night is long :)
<infinity> It's been long enough.
<infinity> And I'm still working. :P
<infinity> So.  Nah, the night can suck it.
<asac> infinity: are you in the room?
<infinity> asac: Yeah, I'm upstairs.
<asac> we are in the breakfast area if you want fun :)
<asac> lol
<infinity> Define "fun".
<infinity> Does it involve alcohol?
<cyphermox> infinity: we have plenty
<asac> infinity: yeah... i can allocate more :)
<infinity> Cause if this is a way to sucker me into working even more tonight, I'm not biting.
<cyphermox> 5 bottles ready
<asac> infinity: no we just wait for the stuff to enter archive so we can kick image and punch dashboard to green or red for the unity folks
<asac> and have fun :)
 * didrocks refreshes update_excuses to desperatly wait for unity8, unity-mir (latest), unity-api and unity-system-compositor to show
<asac> infinity: i cant guarantee, because ogra_'s keycard is very flalki
<asac> i have to try if i get in his room agian where my beer is
<asac> last time it took 10 attempts
<asac> so let me try that first
<infinity> didrocks: This publisher run is a bit longer than usual, we may have upset some postgres index caches a little bit or some such.  It's moving along.
<asac> infinity: there is also some pizza here :)
<didrocks> ok, I hope we won't discover a bad situation and everything will move along ;)
<infinity> I already ate.  But the beer's appealing.
<didrocks> seems asac is a good salesman ;)
<dholbach> good morning
<xnox> pitti: re:swap, swap is created and activated during partitioning, whilst plugininstall.py is called much later by ubiquity. Automatically updating UUID in "resume" is probably something we ought to do. From /etc/fstab or by parsing /proc/swaps ?
<mlankhorst> ok lts-saucy copied to ppa:ubuntu-x-swat/s-lts-backport -- enjoy!
<Laney> what does yellow mean on jenkins?
<Laney> I've seen blue and red, but not yellow...
<xnox> Laney: unstable
<xnox> (either unknown if passed/failed, or uncertain, or flapping)
<Laney> https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-firefox/
<darkxst> xnox, did you see my latest batch of ubiquity changes? are you ok with these?
<smb> slangasek, latest mountall caused a regression for me (bug 1223745)
<ubottu> bug 1223745 in mountall (Ubuntu) "Dependency resolver causes hang on boot" [Undecided,New] https://launchpad.net/bugs/1223745
<smb> apw, FYI, did file it ^
<cjwatson> xnox: I thought we *did* update the UUID in initramfs-tools resume configuration ...
<xnox> cjwatson: i just reformatted my swap, such that it has new UUID and I had to manually edit /etc/initramfs-tools/conf.d/resume. After I did that, updated initramfs, it then got new UUID in conf/conf.d/resume.
<xnox> cjwatson: so the /etc/initramfs-tools/conf.d/resume file is not auto-magically-updated.
<xnox> hence pitti pointing at bug 50437
<ubottu> bug 50437 in initramfs-tools (Ubuntu) "Resume from hibernation may fail because swap partition UUID does not match /etc/initramfs-tools/conf.d/resume" [Medium,Triaged] https://launchpad.net/bugs/50437
<cjwatson> xnox: I'm not claiming it works, but I'm fairly sure there's code for it :)
<cjwatson> xnox: Oh, in the installer, I mean.  Not if you fiddle with things live, sure.
<cjwatson> Hardish problem ...
<xnox> cjwatson: well... so after reformatting swap i need to: edit /etc/fstab, edit /etc/initramfs-tools/conf.d/resume, update-initramfs. Not sure why one should repeat oneself with a common case of a single swap partition/file.
<jtaylor> zul: can you please forward your changes to debian ...
<jtaylor> or at least stop messing with packages I care about ._.
<jtaylor> d2to1 this time
<cjwatson> xnox: Sure, it certainly isn't ideal
<apw> xnox, i wonder if we should be recommending setting a UUID when changing swap to simplify things (with --uid <olduuid>)
 * apw notes he is getting a chromium-browser against chromium-browser-l10n file collision on remoting_locales/th.pak ... known ?
<apw> (on upgrade on saucy)
<cjwatson> apw: bug 1223696
<ubottu> bug 1223696 in chromium-browser (Ubuntu) "package chromium-browser-l10n 29.0.1547.65-0ubuntu1 failed to install/upgrade: tentata sovrascrittura di "/usr/lib/chromium-browser/remoting_locales/th.pak" presente anche nel pacchetto chromium-browser 28.0.1500.71-0ubuntu3" [Undecided,New] https://launchpad.net/bugs/1223696
<apw> cjwatson, thanks
<seb128> cjwatson, apw: bug #1222488, qengho said he would have an update ready yesterday but I didn't see it :/ (the current version is quite buggy, it's missing most for the UI components for some users)
<ubottu> bug 1222488 in chromium-browser (Ubuntu) "package chromium-browser-l10n 28.0.1500.71-0ubuntu3 failed to install/upgrade: trying to overwrite '/usr/lib/chromium-browser/remoting_locales/th.pak', which is also in package chromium-browser 28.0.1500.71-0ubuntu3" [High,Triaged] https://launchpad.net/bugs/1222488
<apw> seb128, thanks, one of those two are a dup
<seb128> apw, I dupped the new one, since the other one was already assigned/used for tracking
 * xnox uses google-chrome
<seb128> xnox, freedom hater
<xnox> seb128: security cautious
<pitti> xnox: hm, I wonder why the config file is wrong in so many cases then
<xnox> pitti: yeah, strange.... it parses /proc/swaps, maybe we fail to activate the just formatted swap?
<xnox> dunno, nonetheless it would be nicer to not have to hard-code the one and only swap partition in two places (/etc/fstab & conf.d/resume)
<pitti> xnox: I think the least we should do is to have update-initramfs hook check whether that UUID actually exist, and only if it does copy it into the initramfs
<pitti> that would still not unbreak hibernation, but at least fix the boot speed delay
<xnox> ack. Yeah, a simple test [ -e /dev/disk/by-uuid/...... ] should do it.
<pitti> xnox: ah, seems the Debian maintainer already cared about the first step
<xnox> pitti: we just need to "merge" initramfs-tools right..... (we have a cherry-pick Frankenstein at the moment)
<xnox> .... or cherry-pick again =)
<pitti> oooooh
<pitti> xnox: initramfs-tools preinst -> that sounds like it would put the buildd's swap UUID into "resume"?
<pitti> that might explain where that mysterious UUID comes from
<xnox> that would be sad, let me unpack the cd.
 * pitti reads the last three commits in http://anonscm.debian.org/gitweb/?p=kernel/initramfs-tools.git;a=shortlog;h=refs/heads/maks/swap
<pitti> /var/lib/dpkg/info/initramfs-tools.preinst does that if not in a chroot; but maybe that logic fails there
<xnox> pitti: there is no conf.d/resume on the images.
<cjwatson> as I said I'm fairly sure that we nuke conf.d/resume in the installer, and possibly also in livefs building
<cjwatson> ubiquity/scripts/plugininstall.py:Install.configure_hardware for instance
<cjwatson> similar thing in base-installer for d-i
<xnox> pitti: in the new commits: if resume file not there, or bogus UUID is specified, then it goes to regenerate the file using the first swap available. So this means one cannot disable resume partition, unless in a chroot.
<xnox> not sure if that actually matters at all, tbh.
<pitti> xnox: ah, good point; mentioned in my bug reply
<pitti> xnox: still, I don't believe that jibel messed with his swap partition manually; I can understand the mismatch on my system as I'm using cryptswap (I guess that's regenerated on every boot or so?), but he doesn't even have that
<pitti> I'll do a test install later on when I'm in the office; need to disappear for a bit for breakfast and bus, bbl
<pitti> xnox: thanks!
<xnox> pitti: yeap cryptswap is random initialised. But normal full-disk encrypt should still work (as swap is static/same, on lvm volume part of the encrypted VG)
<smartboyhw> cjwatson, thanks for merging
<seb128> infinity, hey
<infinity> seb128: 'sup?
<seb128> infinity, do you know if/how we can get https://bugs.launchpad.net/langpack-o-matic/+bug/1201485 on the priority list of somebody? (needs a bit of launchpad work)
<ubottu> Launchpad bug 1201485 in Ubuntu Translations "Need to import translations for the unity daily builds" [High,Triaged]
<infinity> seb128: Oh hey, I even have an open firefox tab for that.
<infinity> wgrant: ^
<seb128> infinity, without it we are increasing our untranslated strings in all the components in daily landing (e.g unity, indicators, touch)
<infinity> wgrant: Any bright ideas?
<infinity> wgrant: If we're losing and/or failing to import translations tarballs from copies, that seems suboptimal.
<infinity> wgrant: (Or, I guess, throwing them away for PPA builds, thus not having them available on copy)
<seb128> infinity, http://irclogs.ubuntu.com/2013/09/02/%23ubuntu-devel.html#t09:25
<seb128> infinity, that was discussed a bit there by wgrant/cjwatson
<smoser> hey. i'm looking at generating a list of packages that are needed for build and runtime depends of a cloud image.
<seb128> infinity, I've added that link to the bug report for reference
<smoser> as cloud-image is a seed, that seems to make sense getting data from
<smoser> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.saucy/
<smoser> but the lists produced there are not complete. (when compared to the actual contents http://cloud-images.ubuntu.com/saucy/current/saucy-server-cloudimg-amd64.manifest).
<smoser> i know that some things are done in the build process (installing kernel for example).
<infinity> smoser: They'd be complete if you add up all the seed outputs for everything that cloud depends on in STRUCTURE.  One would hope.
<smoser> i think thats what i was missing.
<smoser> i didn't know how cloud-image depended on anything.
<infinity> seb128: I'll see if we can find some time for it.  Not sure yet what sort of timeline we can guarantee until I've talked it over with William/Steven.
<smoser> sturcutre is hand maintained ? where does that come from ?
<infinity> smoser: It's in the seed bzr repo.
<seb128> infinity, thanks
<smoser> ah. i see. in the seeds yeah.
<smoser> thanks.
<seb128> infinity, our plan B/workaround is to manually checkout those component, update the template manually and upload to launchpad
<seb128> infinity, but playing catching with any string change at this game on an hundred components is a bit of madness
<infinity> smoser: Gets even more fun when you realise there are seed cross-deps, so that "standard" dep is coming from platform.saucy.
<infinity> seb128: That might be your best short-term workaround, but clearly not the ideal going forward, I agree.
<seb128> infinity, right, I know, I've been doing that since raring :p
<infinity> seb128: If something's wildly out of sync with reality right now, though, that's probably worth a one-shot upload of a few bits. :/
<seb128> infinity, I'm fine doing it again before saucy, but please get it fixed ;-)
<infinity> seb128: Yeahp, it's a fundamental flaw, IMO, if we're not copying *all* custom uploads on PPA->PRIMARY copies.
<seb128> infinity, well, no need of uploads, you can upload a pot manually to launchpad, I've been doing that for unity/indicators when I see missing strings
<infinity> seb128: Translations should just fall out from making sure that's true.
<seb128> right
<smoser> infinity, is there something that can parse that for me? or i just do it myself.
<infinity> smoser: germinate
<smoser> :)
<smoser> thanks
<cjwatson> infinity: As I said earlier, it should be fairly easy to do in the custom upload copier.
<infinity> cjwatson: Sure, assuming we actually still have those custom uploads in the PPAs (I hope the answer is yes?)
<cjwatson> smoser: You can use the Python germinate.seeds module
<cjwatson> If you don't want to run the whole thing
<smoser> cjwatson, thanks. mainly i just wanted to use what output there was, but resolve all the deps of cloud-image.
<cjwatson> infinity: It should still be attached to the PackageUpload
<cjwatson> I can't imagine we're going through and deleting those.  Would be very unLaunchpaddish.
<infinity> cjwatson: That's what I was hoping.  So, yeah, one would think this shouldn't be hard to fix at all.  And should just be fixed for all custom uploads.
<cjwatson> infinity: It's already fixed for all custom uploads apart from translations.
<cjwatson> Because translations were already weird.
<infinity> cjwatson: Certainly works correctly already for EFI (as proven by the kernel SRU process).
<infinity> cjwatson: Ahh.  Yay, weird.
<cjwatson> infinity: I'd suggest moving PackageUploadCustom.publishRosettaTranslations into a module in lp.archivepublisher (see the way it works for most of the other custom upload types), flipping the switch in CustomUploadsCopier.copyable_types, and then doing whatever other minor tweaks are necessary as revealed by tests.
 * infinity dumps that in the bug.
<cjwatson> (Moving most of the contents of that method, I mean, not the method itself.)
<cjwatson> As it stands it'd wind up doing a bit of unnecessary work to write the translations LFA out to disk.  But that'd be easy enough to fix with an extra kwarg to _publishCustom.
<cjwatson> infinity: Are you volunteering? :-)
<infinity> cjwatson: Not necessarily, just trying to scope it currently.
<pitti> seb128: ooh, I got a proper retracer failure mail now
 * pitti looks and fixes
<seb128> pitti, \o/
<pitti> hm, the usual "HTTP Error 503: Service Unavailable" again
<pitti> but with notifications working we at least won't have long downtimes any more
<seb128> right
<seb128> pitti, I wonder if we could just catch the error for those and not stop the retracers
<pitti> seb128: it's actually supposed to doing that in many cases ("transient error")
<seb128> it doesn't do it for that 503 though?
<smoser> cjwatson, hey. before i go and try to do this, is there a way to "flatten" cloud-image.* at http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.saucy/ ?
<smoser> by flatten i just mean resolve all task dependencies. for build-depends, build-sources, .depends
<cjwatson> smoser: Well, you could look at what Launchpad does
<cjwatson> smoser: lib/lp/archivepublisher/scripts/generate_extra_overrides.py
<cjwatson> There's nothing canned
<cjwatson> smoser: But, er, isn't cloud-image already a task?  You can get the runtime deps out of the Packages file
<smoser> well, not flattened. right?
<smoser> and i also want build deps
<smoser> where is lib/lp/archivepublisher/scripts/generate_extra_overrides.py ? what branch/package?
<cjwatson> How do you mean, not flattened?  Fully expanded?
<cjwatson> lp:launchpad
<cjwatson> And fully expanded with respect to what?  You generally don't want to do a *full* expansion, only up to some interior seed.
<cjwatson> It would help if I had some idea of what you were actually trying to do.
<cjwatson> (But briefly!)
<smoser> i want a list of all packages required to build cloud-image seed.
<smoser> and all packages that are installed by cloud-image seed.
<smoser> and why would i not want to do a "full expansion"?
<cjwatson> smoser: Because most things that actually do this in practice are installing them on top of a debootstrapped image and thus only want to expand relative to minimal (say)
<cjwatson> Also because a full expansion is ridiculously enormous
<cjwatson> Even just the recursive (build-)depends expansion of required pulls in chunks of GNOME, KDE, Mono, ...
<cjwatson> We need to know this to keep main self-contained, but it isn't useful for most other practical purposes
<smoser> cjwatson, i'm clearly missing something.
<smoser> the end goal is to get a list of packages that have to build in order to produce a given seed ('cloud-image').
<cjwatson> Well you can do that but I have no idea why.
<cjwatson> That's not so much a reason as a deliverable.
<smoser> well if i want to produce alist of what is necessary to reach said deliverable.
<cjwatson> But why?
<cjwatson> </four-year-old>
<cjwatson> I mean, practically all of it is already done, unless this is for a new architecture
<cjwatson> (In which case perhaps you could say so)
<smoser> :)
<smoser> that is exactly it. and i was typing 'architecture' as you hit return.
<cjwatson> So you can cat all the files together if you like.  I wouldn't bother building a tool for it if I were you.
<cjwatson> Just extract the seed list and pick out whichever field you want from all the files ... it's not something that's needed very often at all
<slangasek> smoser: hrm, infinity didn't already do this analysis?
<cjwatson> That said, this is basically a textbook example of useless data generated to satisfy a statement of work
<cjwatson> Very little of the output is actually going to be required to reach the goal, and the data doesn't necessarily continue to represent what needs to be done
<cjwatson> Since the dependency expansions might change between now and completion
<smoser> agreed that a one time static list isn't terribly useful.
<cjwatson> So it's pointless work - the goal is "get to the cloud-image seed", not "build all these packages which might not all end up being necessary for that"
<cjwatson> Far easier to just build everything that will autobuild and then worry about what's left
<smoser> i dont undersand "which might not all end up being necessary for that"
<smoser> of course they're necessary or they would not be build-depends
<cjwatson> They might not REMAIN build-depends
<cjwatson> They're necessary NOW
<cjwatson> But they might be removable without compromising the goal
<cjwatson> Anyway, if you need to do it because of $commercials, that's fine, I just wouldn't care that much about how elegant the tool you use to get there is
<cjwatson> Just scrape it all out of the obvious places and move on :)
<cjwatson> But what I want to avoid is a customer saying that you haven't met your goal because you didn't build one of those intermediate packages, that ended up being removed because it was avoidable
<cjwatson> So just be careful about how you present full expansions like that
<smoser> "i want seed X" is the end goal.  the intermediate "well, you'll need this list of packages to get there" is what i'm after.
<xnox> smoser: right and the full expansion will be very arch specific and many packages are different across i386/amd64/armhf etc. Thus you do want something like - equivalent of ubuntu-core, kernel, bootloader, and the rest of the expansion.
<xnox> (excluding the previously mentioned items)
<cjwatson> For a new architecture you just have to pick the most similar architecture and cat together the relevant bits of all the output files in the expansion of whichever seed you want in the structure file.  As I say it's doable in a shell pipeline and I don't think it's worth a tool, given that it comes up rarely and there are generally slight variations each time it does come up.
<slangasek> smb: followed up to the bug; would like some more info from your system before I start trying to assemble a reproducer locally
<dupondje> hm
<dupondje> grub2 broke?: grub-probe: error: failed to get canonical path of .
<dupondje> cjwatson: ^^
<cjwatson> dupondje: don't run -proposed
<slangasek> hmm, haven't we said this before ;)
<infinity> A few times.
<cjwatson> dupondje: I blocked it in -proposed quite deliberately and am currently fixing that bug.  You only encountered it because you went against recommendations and used -proposed :)
<slangasek> infinity: I meant to dupondje specifically :)
<dupondje> I know :) Just wanted to let it know :)
<slangasek> seb128, pitti: hurray, failure emails!
<cjwatson> I'd noticed myself already but thanks
<seb128> slangasek, ;-)
<pitti> slangasek: indeed; I restarted them timely now
<slangasek> jodh: hey, so test-quiesce-cleanup
<slangasek> jodh: I still haven't had a chance to look at the code and piece my argument together fully, but the rough strokes are this: you're modifying the test code to opportunistically kill() a dangling process, and you should never need to do that in the test suite, because the tests should be *deterministic* about whether there are processes left over
<jodh> slangasek: see my latest comments - I changed the branch to do it deterministically.
<slangasek> jodh: either the shutdown is done in the right order, modeling our normal user session shutdown process, and everything gets cleaned up and there's nothing to kill, in which case it should be an error for the process to be left at the end; or you're modeling an out-of-order shutdown where the session init is being hard-killed from the outside, in which case we know the process should be left behind, and the test should consider it a fail
<slangasek> ... process *isn't* there
<slangasek> jodh: oh, hadn't noticed that the branch itself was updated
<slangasek> let me look things over today then :)
<jodh> slangasek: yeah - I've also added in big comments in the test code to explain what we're doing :)
<slangasek> xnox: so did the cmake cross-compiling you did sidestep the question of qmake upstream divergence?
<xnox> slangasek: not really, no. moc / qtchooser are still brain dead and claim that "No Qt installation found". It stopped being on the critical path, but we do need to solve co-installability.
<slangasek> xnox: for which case is co-installability needed?
<xnox> slangasek: e.g. qtbase5-dev is still not co-installable, and neither ubuntu-sdk. E.g. to be able to compile for multiple architectures on your host machine, without using chroots. Or e.g. have one chroot that can compile to i386/amd64/armhf/arm64....
<xnox> slangasek: e.g. iphone 5S is ARM64 are we gonna hook them up as buildds? =)
<slangasek> blink
<slangasek> it's arm64?
<cjwatson> xnox: That isn't a blocker, though; I plan to just have one-per-arch chroot management
<slangasek> but yeah, we can get by for now with one chroot per target arch
<slangasek> it's not ideal, but it works
<slangasek> I just wanted to make sure we weren't blocked because we need both native *and* foreign copies of the package installed for cross-building
<xnox> slangasek: cjwatson: right. so one-per-arch chroot would work with cmake.
<xnox> slangasek: but we do really really want your bugfix debian #722045 applied as e.g. some qt sdk packages depend on python somewhere down the line for scripts et. al.
<ubottu> Debian bug 722045 in dh-python "Please support python:any dependencies for multiarch compatibility" [Normal,Open] http://bugs.debian.org/722045
<slangasek> xnox: yep
<xnox> 350494
<slangasek> achievement unlocked: two-factor auth IRC
<xnox> i was unpluggin it =)
<cjwatson> Sigh, four bugs about grub2 2.00-18ubuntu2 already
<cjwatson> Actually five
 * cjwatson drops a little lecture about it being counterproductive to run saucy-proposed into the bug
<directhex> <slangasek> it's arm64? <-- yep, apparently apple have crammed it into their "a7" chip.
<dobey> hi all. can i get someone to ack the ubuntuone-client 3.0.2-0ubuntu2 upload to precise-proposed? would like to get that SRU out quickly if possible as it fixes a rather annoying bug :)
<pitti> cjwatson: did you freeze saucy until grub2 lands?
<pitti> cjwatson: since the grub2 amd64 build is now trapped in "unapproved", I can't make much sense of this
<pitti> cjwatson: it's not frozen in LP
<pitti> cjwatson: the i386 made it through; I guess we can just approve it from https://launchpad.net/ubuntu/saucy/+queue?queue_state=1 ?
<pitti> jibel: ^ FYI
<pitti> cjwatson, jibel: the powerpc build got auto-accepted, and there is a propagation block on it, so I took the liberty to accept the amd64 build from unapproved, so that the mayhem in the autopkgtests stop
<pitti> (however it ended up in unapproved in the first place)
<infinity> pitti: Anything with signed bits lands in unapproved.
<pitti> infinity: ah, that's because i386 isn't signed?
<infinity> pitti: Only amd64 produces an efi tarball, yes.
<infinity> You're meant to take that opportunity to verify the build matches the upload and the upload doesn't contain something that's going to trojan the world.
<infinity> I'm sure you did that, right? :)
<pitti> I personally identified every single bit
<pitti> infinity: more seriously, how is that being done? if we don't trust our buildds, what makes grub special?
<pitti> I doubt that anyone can verify the binary results, even a genius like cjwatson?
<infinity> pitti: Oh, I verify the trust path from the archive to the buildds.
<infinity> pitti: But not from random core-devs uploading to pushing an efi blob signed by Canonical's key.
<infinity> pitti: Hence checking the diff to make sure it was sane (or trusted).
<infinity> pitti: In this case, it being a Colin upload, the "trust" part probably works.
<pitti> infinity: ah; well, I did check the diff, yes
<infinity> pitti: This was the compromise between not completely locking down upload rights for the kernel and grub, and still being paranoid about our EFI key so Microsoft doesn't go and revoke us tomorrow.
<pitti> infinity: thanks for the heads-up
 * infinity realized this was probably never well communicated to all archive admins.
<infinity> s/realized/realizes/
<pitti> infinity: at least my mind now changed from "huh!?!?" to "yes, that makes sense"
<infinity> pitti: I'm not sure how much sense it makes to me, but I'm glad it makes sense to someone. ;)
<ScottK> pitti: Could you or someone have a look at the pyparsing autopkgtest failure?
<ScottK> Seems like an ADT issue according to jtaylor.
<pitti> ScottK: don't worry about them
<pitti> ScottK: all tests fail right now due to grub2
<ScottK> OK.
<pitti> cf. me being anxious go get above fix in ASAP :)
<pitti> ScottK: we'll retry all failed tests after ubuntu3 is in the archive
<infinity> pitti: Wait, new bootloader uploads to proposed completely break your test infrastructure?
<infinity> pitti: This seems suboptimal. :)
<pitti> infinity: no, base packages failing to upgrade do
<pitti> infinity: well, in a way that's good
<infinity> pitti: Oh, the update-grub failure.  Check.
<pitti> infinity: we do not *ever* want this near saucy, so any possibility of failing the gating is good
<infinity> pitti: I forgot that it was actually *broken*.  That was, like, an hour ago.
<pitti> of course in this case the tests wouldn't actually have held back grub ubuntu2, that was cjwatson's manual block
<infinity> grub2 gets held back until someone upload grub2-signed anyway.
<pitti> but it worked for cloud-init and other upgrade failures, I think
<infinity> (Though, I'm about to do that, since Colin's block will still keep it all out)
<infinity> s/upload/uploads/
<pitti> grub2-common | 2.00-18ubuntu3 | saucy-proposed | amd64, i386, powerpc
<pitti> jibel: ^ I think we can retry the failures now
<jibel> pitti, done
<pitti> jibel: I've kicked python-apt, let's make double-sure that works, and then nudge the rest?
<pitti> jibel: ah, thanks
<pitti> jibel: ah, you were using your new magic script?
<jibel> ubiqutiy failed but for a missing dep
<jibel> pitti, it is just a very basic script that triggers jobs remotely :)
<jibel> at least it saves me a few clicks
<slangasek> pitti, infinity: the point of the efi unapproved queue isn't for you to verify the builder output, but for someone to verify that the source hasn't changed in an inappropriate way - i.e., that the upload wasn't from I. Justgotmotuandnowiownyouall making inappropriate changes to grub
<slangasek> so yeah, if Colin signed it, it should be good ;)
<pitti> slangasek: ack; I did review the debdiff, verifying the binary integrity would be out of scope
<slangasek> righto
<pitti> slangasek: ok, so we're all on the same page
<infinity> slangasek: That's what I said. :P
<slangasek> infinity: ok good :)
<infinity> 13:06 < infinity> pitti: Oh, I verify the trust path from the archive to the buildds.
<infinity> 13:07 < infinity> pitti: But not from random core-devs uploading to pushing an efi blob signed by Canonical's key.
<infinity> 13:07 < infinity> pitti: Hence checking the diff to make sure it was sane (or trusted).
<slangasek> tarpman: hi there
<tarpman> slangasek: hi!
<slangasek> tarpman: hey, so I'm wondering how you go about setting up one of these nfsroot VMs in virt-manager
<slangasek> tarpman: would I choose "PXE" even though I'm passing the kernel+initramfs from disk?
<tarpman> slangasek: that's what I did, easiest way to skip choosing install media
<slangasek> ok
<dobey> hi infinity! :)
<infinity> dobey: What did I do now?
<dobey> infinity: would you be so kind as to accept ubuntuone-client in precise-proposed?
<infinity> dobey: Have you ever known me to be kind?
<slangasek> tarpman: hmm, so virt-manager isn't saving my changes when I try to edit the boot device order
<slangasek> oh, now it is
<slangasek> works better when the guest isn't running
<infinity> dobey: (looking)
<infinity> dobey: There seems to be no particular explanation as to why removal of zeitgesist is the fix for this bug...
<slangasek> tarpman: so in this configuration, /etc/fstab is empty; I don't imagine that helps mountall figure out how to mount the rootfs
<dobey> infinity: hmm. should i copy/paste the zeitgeist related error from the attached log on the bug, into the description? the zeitgeist logging stuff was never actually used, and we aren't going to add a feature to use it, so it was easier to just backport its removal (as it's already gone in newer versions)
<tarpman> slangasek: looking at the stdout of mountall, it seems to be ok with deducing it from mountinfo
<tarpman> slangasek: when I was trying with nolock I wrote an fstab like '10.0.2.1:/srv/nfsroot/raring / nfs rw,nolock 0 1' and it didn't change much
<infinity> dobey: Just explaining in the SRU justification why zeitgeist is being removed would help.
<infinity> dobey: Right now, the justification sort of reads like "there's a bug, so we should fix it," without discussion of what and how.
<infinity> dobey: A bit opaque to someone looking back through history (or to me reviewing blind)
<dobey> infinity: you mean the "impact" section?
<dobey> or in the test case?
<slangasek> tarpman: ok.  so at the moment, it looks like mountall has succeeded in mounting all the virtual filesystems, but then gets stuck, I currently have no idea why - but I can reproduce the failure, so should be able to make progress from here, thanks
<tarpman> slangasek: great! thanks for working on this, let me know if I can help any more
<slangasek> oh that's not cool, I get different behavior when booting with --debug vs. --verbose. :P
<infinity> dobey: The impact/justification section, whatever you want to call it.  The description. :P
<infinity> dobey: Or even just in a bug comment.
<infinity> dobey: I'm less picky about formatting and more about there just being some reasoning given for the change at hand, since it's not something simple like "The string 'foo' should say 'bar'" which is easy to unwind and review.
<alberts> Hi! Can someone look at this (https://code.launchpad.net/~albertsmuktupavels/nautilus/white-screen-fix/+merge/180231) branch proposal?
<jono> who maintains Chromium?
<jono> all the toolbars are broken in 13.10
<tarpman> slangasek: oh, my favourite type of bug :)
<seb128> jono, qengho, and it seems to be due to webapps and should be fixed with the upload from today (which is is build/in proposed still)
<slangasek> tarpman: but on review, I think the issue is simply that the logfile is not being flushed :)
<jono> seb128, ahhh cool, thanks!
<seb128> jono, yw
<dobey> infinity: updated description with a [Fix] section. :)
<infinity> dobey: Perfect, that tells me what I need to know to be less scared. :)
<infinity> dobey: And to be clear, removing the zeitgeist-core recommends is just the Right Thing To Do because it no longer has the integration, but having it installed (which it will be on upgrade) will not cause any harm?
<dobey> infinity: right. zeitgeist being installed won't cause any issue with u1. we just don't depend on it any more. it will be installed by default anyway, as unity and stuff depend on it
 * infinity nods.
<infinity> dobey: Acceptificated.
<dobey> thanks
<slangasek> xnox: so if I have a livefs written to a USB stick, and I want it to be UEFI bootable but I want to add extra partitions to make use of the extra space on the stick (for e.g., persistence data, or something else), what's the right way to do that?  Last I checked, usb-creator didn't quite get this right... and trying to change things by hand with gdisk or parted doesn't help either, because they both want to start the first partition at s
<slangasek> ... not at sector 0 where the isofs starts
<slangasek> and casper is perfectly happy to mount /dev/sdb rather than /dev/sdb1, but then the kernel isn't happy letting me mount the other partitions :)
<stgraber> slangasek: I guess in such case, you'd be better off making a clean EFI bootable USB stick without the weird partition table. So create a GPT pasrtition table with the first partition being vfat containing the content of the iso image, then whatever partition you want after that.
<slangasek> stgraber: why vfat, instead of just blatting the ISOfs to the partition?
<stgraber> slangasek: because the iso image contains a gpt/fat/whatever partition table to try and get everything to boot it
<stgraber> which likely confuses the kernel a fair bit
<slangasek> stgraber: if it's all inside partition1, that wouldn't matter
<slangasek> the kernel isn't going to recursively look for partition tables :)
<slangasek> but yeah, in general moving the ISO contents to a partition seems to be the sanest way
<stgraber> hmm, true, not sure what the firmware will think of that partition (since you'd have a clean GPT with the first partition containing a gpt+vfat+hfs+iso header)
<slangasek> stgraber: hopefully it will think the same, or the firmware is quite buggy too :)
<robert_ancell> asac, hey
<slangasek> tarpman: ok, so the root mount is being blocked by two separate -mounting jobs - statd and idmapd.  If I move them both to virtual-filesystems instead of local-filesystems, the nfsroot instance starts up without hangs
<slangasek> tarpman: for statd, moving this to start on virtual-filesystems looks correct.  For idmapd, because it's located on /usr which may be a separate partition, I don't see an obvious way to fix this generically until we start handling /usr mounting from the initramfs
<tarpman> slangasek: theoretically idmapd shouldn't be necessary for an nfsroot since it can't be on nfsv4. but i'm not sure how one might explain that to upstart...
<slangasek> tarpman: why can't it be on nfsv4?
<tarpman> slangasek: (and, well, /usr could be nfsv4 even if / isn't)
<tarpman> slangasek: uh, [citation needed]. one sec
<slangasek> it can't be on nfsv4 with gss auth, to be sure; but there's non-gss nfsv4
<slangasek> and the kernel tries v4 by default now when you ask it for nfs
<slangasek> but I dunno about nfsroot
<slangasek> tarpman: so if we *could* say "idmapd can't possibly be used for nfsroot", then I can adjust the idmapd-mounting job to exclude MOUNTPOINT=/
<slangasek> actually, even if we can't say that, I could still do the above to get things working for people :)
<tarpman> I really thought I read a mailing list post not so long ago saying that the kernel nfsroot code didn't understand v4 yet, but of course I can't find it now. stupd selective memory
<tarpman> don't take my word for it, anyway
<slangasek> ok
<slangasek> so in any event, I at least have a fix that will let all NFSv3 nfsroot users boot, not regress anything for users who aren't using nfsroot, and continue to not support NFSv4 root
<tarpman> sounds like a net win
<tarpman> slangasek: looks like it's actually klibc (nfsmount), and so initramfs-tools, that doesn't speak nfsv4 -- apparently dracut is able to do it... haven't tried myself
<slangasek> tarpman: ok.  In the meantime, I've just uploaded nfs-utils to saucy
<tarpman> slangasek: and saucy boots with that, great! :)
<slangasek> tarpman: huzzah, at last
<achiang> slangasek: do you know who might be the right person to take a look at LP: #1224193 ? it's a somewhat minor thing, but it *is* a papercut in an openstack environment
<ubottu> Launchpad bug 1224193 in update-manager (Ubuntu) "The helpful suggestions in do-release-upgrade give no love to OpenStack" [Undecided,New] https://launchpad.net/bugs/1224193
<slangasek> achiang: I would say someone from the server team who knows the details of openstack and can propose us some text?
<achiang> slangasek: that was my thought... i was really trying to ask, who fits those requirements? ;)
<slangasek> achiang: oh.  Um, smoser or utlemming? :)
<achiang> slangasek: great, i'll ping them if there's no activity on the bug for a day or so. thanks!
 * utlemming looks
<utlemming> achiang: responded....its a good idea, just a hard problem to solve. Openstack isn't the only one that is affects -- EC2, Windows Azure, VPS, etc, etc, all have this problem too
<achiang> utlemming: it's a fair response, thanks!
<cjwatson> ScottK: I think you can drop your force-skiptest pyparsing/2.0.1+dfsg1-1 now; https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-pyparsing/ is passing again.
<cjwatson> pitti: Sorry for the disruption.  Last-minute "looks good to me" changes FTL.
<slangasek> xnox: madness: http://package-import.ubuntu.com/status/ifupdown.html#2013-08-29%2019:33:34.918620
#ubuntu-devel 2013-09-12
<jbicha> micahg: is this ok for ubuntu-restricted-addons? http://paste.debian.net/38606/
<micahg> jbicha: I don't see the point of pulling in chromium codecs everywhere
<jbicha> because chromium is widely used and we can't have anything else recommend the codecs
<micahg> jbicha: I don't see the need to have that in Xubuntu, if Ubuntu wants that, I guess that's fine for them
<jbicha> I think people install u-restricted-extras thinking that it will get them all the codecs they'll ever need
<micahg> its purpose isn't one-off codecs, but ones that work in many applications
<micahg> also, what happened to -plugins-ugly?
<jbicha> it's still there, it just didn't show in the diff http://paste.debian.net/38624/
<micahg> jbicha: also, adding that codec will pull in chromium on everyone's system
<jbicha> no, we fixed that today :)
<micahg> I think that's wrong
<micahg> the codecs do depend on chromium specifically to work
<jbicha> it was bug 1208518 otherwise things wouldn't be right for Lubuntu
<ubottu> bug 1208518 in chromium-browser (Ubuntu) "Don't have the codecs depend on chromium-browser" [Undecided,Fix released] https://launchpad.net/bugs/1208518
<micahg> that's wrong, the codecs should depend on chromium and the restricted package shouldn't
<sarnold> a pal is getting package authentication errors, http://pastebin.com/jgms472S  -- I can't replicate with my 12.04 VM.. any ideas?
<micahg> restricted extras is for system wide codecs
<jbicha> Riddell: is it fine if kubuntu-restricted-addons recommends the chromium extra codecs?
<micahg> sarnold: I think that can happen if the user and mirror are updating at just the right time
<sarnold> micahg: ah :)
<micahg> but I"ll let someone else verify
<sarnold> micahg: so, something like the Releases is updated but the Releases.gpg isn't?
<micahg> I would think if those files were updated before the new debs were or vice versa
<micahg> hrm, that's not right
<micahg> sorry, don't remember exactly why ATM, just recall it being transient for me on occasion
<sarnold> micahg: funny you say transient, that's what he's reporting -- it works correctly now for him. go figure.
<sarnold> micahg: thanks :)
<jbicha> overly strict dependencies cause problems for Ubuntu flavors, like bug 1191522 and bug 1222155
<ubottu> bug 1191522 in libsignon-glib (Ubuntu) "Don't have libsignon-glib1 depend on signond" [Undecided,Fix released] https://launchpad.net/bugs/1191522
<ubottu> bug 1222155 in lightdm (Ubuntu) "Installing gnome-session-flashback also installs Unity" [Undecided,Fix released] https://launchpad.net/bugs/1222155
<jbicha> and I really don't think people that install *buntu-restricted-extras care if they have an extra 700ish KB installed on their computer
<micahg> jbicha: libraries depending on programs is usually wrong, since they can be consumed by many things, in this case, this codec can only be used by chromium
<micahg> s/by/with/
<micahg> that seemed to be the sane fix in both the cases above
<micahg> actually, the codecs package should enhance: chromium-browser, not depend TBH
<micahg> so, bottom line is that I think it violates the spirit of the package, if the Ubuntu desktop team and other flavors want it, fine, I don't think I want it for Xubuntu
<jbicha> ok, I'll keep xubuntu separate for now and add the gstreamer 1.0 codecs to the xubuntu package
<micahg> jbicha: thanks
<micahg> I'll file a bug to add Enhances: chromium-browser on the codec packages
<ScottK> cjwatson: Thanks.
<dendrobates> is your driver not coming until 9:30?
<dendrobates> Tower 8 7b
<dendrobates> lol, wrong channel
<stgraber> pitti, hallyn: so https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=65aafb1e7484b7434a0c1d4c593191ebe5776a2f finally got merged into Linus' branch. A bit late for 13.10 but for 14.04 we'll have apport working properly with containers (the kernel will send the crash to apport within the container).
<slangasek> 3
<dholbach> good morning
<mlankhorst>  g'day
<mlankhorst> oh btw i think the lts-s repo is complete, so feel free to test and find any bugs :P
<tjaalton> cool
<smb> slangasek, Got the mountall bug updated. Sorry, I was gone already yesterday when you asked about stuff.
<xnox> slangasek: re: ifupdown, reblasted - wait and see what happens.
<xnox> slangasek: re: blasting livefs to usb - kpartx -a setup loopmounts of the cd and blast just the contents (first iso partition) of the cd onto the usb partition you want and then copy across the EFI folder from the other one, that should just work.
<xnox> doko_: debian #688251 is interesting
<ubottu> Debian bug 688251 in debian-policy "Built-Using description too aggressive" [Normal,Open] http://bugs.debian.org/688251
<cjwatson> chrisccoulson: firefox-testsuite needs to be updated to depend on fonts-liberation, not ttf-liberation - I think I have commit access but which branch(es) do I need to commit to?
<pitti> Good morning
<pitti> stgraber: oh, great! that's a trivial patch, too late to cherrypick?
<pitti> stgraber: but anyway, not that urgent I guess; nice to have it for the LTS
<hallyn_> stgraber: yeah i saw akpm forwarded that yesterday
<hallyn_> \o/
<stgraber> cjwatson: hey, so I just updated my laptop, got a new grub and I'm now booting to a grub prompt
<stgraber> cjwatson: any known issue there before I go dig into what happened?
<stgraber> cjwatson: hmm, so nothing obvious, /boot/efi/EFI/ubuntu/grub.cfg points to the right UUID, grub.cfg exists and appears correct, so I'm not sure why it didn't get loaded...
<stgraber> cjwatson: grub itself works fine besides the fact it didn't load the config as I could boot my machine by giving it the location of the kernel and initrd just fine
<xnox> ... and you are not using saucy-proposed?
 * stgraber reboots to run /boot/efi/EFI/ubuntu/grub.cfg by hand, see if that's enough
<stgraber> xnox: I'm definitely not
<Laney> it migrated
<xnox> Laney: oh, ok.
<stgraber> I know we had a broken grub in proposed but I hope that's not what we let through to saucy...
 * stgraber reboots
<stgraber> cjwatson: so calling "configfile /EFI/ubuntu/grub.cfg" makes it work just fine
<stgraber> cjwatson: so it looks like it's the builtin logic to find the grub.cfg on the EFI partition that's broken
<cjwatson> stgraber: Huh, that did change but it worked fine for me
<cjwatson> No doubt r2344 but how ...
<cjwatson> stgraber: What's $prefix?
<stgraber> cjwatson: http://paste.ubuntu.com/6097168/
<cjwatson> stgraber: Also, grub.cfg should not be in /EFI/ubuntu/
<cjwatson> It's meant to be read directly from /boot/grub/ - no?
<stgraber> cjwatson: my understanding was that grub2-signed would load a minimal grub.cfg next to it on EFI which tells it where to look for the real grub.cfg in /boot/grub on the root partition
<stgraber> anyway, that's how things got automatically setup on this machine
<cjwatson> Oh, blah, I missed a bit in grub-install
<OvenWerks> Bug #1220894 (found in beta1 testing) has been fixed and commited. Can we get lp:ubuntustudio-default-settings rereleased/uploaded?
<ubottu> bug 1220894 in ubuntustudio-default-settings (Ubuntu) "ubuntustudio-default-settings does not make sure a grub rebuild is called after install." [Undecided,Fix committed] https://launchpad.net/bugs/1220894
<cjwatson> This must have always been sort of broken - I don't see how this ever worked in the case of, say, SB with /boot on LVM
<cjwatson> Because then AFAICS there wouldn't be a /boot/efi/EFI/ubuntu/grub.cfg
<hallyn_> arges: check out qemu-kvm -ppa2 version for precise in ppa:serge-hallyn/lucid-kvm-test.  Our qcow2 code is just getting scarier and scarier
<arges> hallyn_: what changed?
<cjwatson> stgraber: When you're at the GRUB prompt, can you tell me what prefix is set to?
<stgraber> cjwatson: thankfully I don't have /boot on LVM on that box (I do on a UEFI precise box where I found that d-i bug which would install grub-pc instead of grub-efi in such case :))
<stgraber> cjwatson: sure, rebooting quickly
<hallyn_> arges: somebody was getting kvm corruption with heavy load on qcow2
<hallyn_> the commit in rhel5 to fix it has (as usual) 10-20 patches it needs before it
<arges> hallyn_: ouch. is there a bug # to track?
<hallyn_> arges: bug #12239071223907
<ubottu> Error: Launchpad bug 12239071223907 could not be found
<hallyn_> feh
<hallyn_> bug #1223907
<ubottu> bug 1223907 in qemu-kvm (Ubuntu Precise) "qemu-kvm crashes in qcow2 code" [High,Confirmed] https://launchpad.net/bugs/1223907
<arges> wow : )
<stgraber> cjwatson: (hd0,gpt1)/boot/grub
<cjwatson> stgraber: ok, and what's GRUB's name for the EFI system partition?
<cjwatson> (hd0,gpt1) or something else?
<stgraber> (hd0,gpt1) is indeed the EFI boot partition
<stgraber> but /boot/grub doesn't exist on it as that's a SecureBoot system
<cjwatson> It wouldn't anyway
<stgraber> ah right, the modules are in /grub when booting an unsigned grub, not /boot/grub (if my memory is vaguely correct, only have one UEFI non-SB system around)
<cjwatson> The modules are still in /boot/grub unless you have a separate /boot partition - but they're not on the EFI System Partition
<arges> hallyn_: so if we have a definitive test (we could use the same one in bug 1189926), we could try to bisect again
<ubottu> bug 1189926 in qemu-kvm (Ubuntu Quantal) "data corruption in storage attached to VM using KVM" [High,Fix released] https://launchpad.net/bugs/1189926
<arges> hallyn_: or are you planning on backporting those 10 or so patches?
<hallyn_> arges: no, for right now i just hand-applied the spirit of the patch that fixed it in rhel
<hallyn_> as you'll recall we tried backporting all those patches before
<hallyn_> we just end up at a newer release altogether (or with broken patch hunks)
<arges> yeaa
<hallyn_> thing is my impression has alwasy been that upstream felt qcow2 was fragile.
<hallyn_> too bad it has such great features so ppl keep using it :)
<hallyn_> i wonder if we can push ppl onto qed using the cloud archive
<arges> which is good, hopefully more bugs get ironed out by people using it
<hallyn_> well let's see if this fixes it for that guy.  some of the other patches which i didn't backport sounded frivolous, but some didn't
<jmleddy> arges: have you seen those compiz patches from nvidia at all?
<jmleddy> arges: I know you're not assigned to the case anymore
<cjwatson> stgraber: I'll just revert the bit that broke you for now, and figure out the rest later
<stgraber> cjwatson: ok, thanks
<arges> hallyn_: fyi. also working on the qemu-kvm perf issues after migration. I think i have a patch and I can reproduce it. so hopefully this is a fix for that
<hallyn_> arges: I'm confused.  which "this" and which "that"?
<arges> jmleddy: so I've actually tested teh latest saucy and the corruption with powermizer at teh lower setting seems to be gone
<jmleddy> arges: oh, great news
<arges> jmleddy: so we think something was fixed between 0.9.9 and 0.9.10
<hallyn_> arges: you've also been following http://lists.gnu.org/archive/html/qemu-devel/2013-07/msg01856.html ?
<jmleddy> arges: of compiz?
<arges> jmleddy: yea compiz.
<hallyn_> (i thought you'd been involved in it, but i don't see you in the thread list)
<arges> hallyn_: yea that's where i foudn the patch
<jmleddy> okay, that much is mark's problem ;)
<arges> hallyn_: somebody identified a patch that seemed to fix perf for him
<hallyn_> arges: ok :)
<jmleddy> but I'll report that later compiz fixes the problems to Nvidia
<arges> jmleddy: cool thanks
<cjwatson> stgraber: uploaded, thanks for the heads-up
<stgraber> cjwatson: np, thanks for the quick fix. I'll review the upload in Unapproved as soon as it gets in there.
<alberts> Hi! Can someone look at this bug - https://bugs.launchpad.net/nautilus/+bug/885989. Why nobody wants to approve working patch to fix this bug?
<ubottu> Launchpad bug 885989 in nautilus (Ubuntu Precise) "white screen on second monitor when using two xsessions" [Low,Triaged]
<ChickenCutlass> cjwatson, hi,  just installing 13.10 onto a new MacbookAir and after install and reboot we get dropped to a grub prompt.  Any ideas how to fix
<ChickenCutlass> cjwatson, we are using grub-efi
<cjwatson> ChickenCutlass: see conversation above with stgraber
<cjwatson> probably the same thing
<stgraber> ChickenCutlass: for now, run "configfile /EFI/boot/grub.cfg" that should make it boot until you update to the fixed package (should be available in ~1h)
<ChickenCutlass> stgraber, ah ok
<cjwatson> stgraber: bit more, it'll need a matching grub2-signed in order to migrate
<stgraber> ChickenCutlass: hmm, that's wrong
<stgraber> ChickenCutlass: "configfile /EFI/ubuntu/grub.cfg"
<ChickenCutlass> stgraber, trying now
<ChickenCutlass> stgraber, that worked
<stgraber> cjwatson: yeah, I assumed as much (grub2-signed) but didn't check how long grub2 takes to build so that's why my estimate is a bit off
<slangasek> xnox: so I've noticed recently that some of these give-backs are resulting in existing branches getting tags moved; do you know the story behind that?
<slangasek> xnox: kpartx -a> check.  That's roughly what I wound up doing, though I rather wish there were a nicer way to edit in-place :)
<xnox> slangasek: define "in-place" - as in somehow dd the iso onto the usb stick, yet still have a partition table and partitions that one can edit?
<xnox> slangasek: about tags getting moved, no idea how or why.
<slangasek> xnox: yeah, dd iso to the usb stick, then edit the partition table... doesn't work because none of the tools are happy with overlapping partitions
<xnox> slangasek: quite, e.g. everything complains that it's a broken GPT table and doesn't let to do anything with them. =/ i typically have to dd from dev/zero to get usb back into partitionable condition.
<slangasek> oh, it doesn't seem that bad here :)
<xnox> slangasek: well - Disks gui, parted, gparted, fdisk all don't like amd64 iso dd'ed onto the usb stick =/
<xnox> am I doing something very odd?!
<slangasek> xnox: ah; sure, I used the commandline tools and they complained about it, but I was able to bypass the warnings
<xnox> gotcha. I don't like those warnings
<cjwatson> YokoZar: Do you care about keeping dssi-vst in the archive?  It's been removed from Debian and seems to have no rdeps in Ubuntu.
<smoser> cjwatson, i kind of feel like i have ot tell you, after reading and understanding germinate more, germinate is really cool and helpful.
<smoser> made it easy to figure out "what if i add this package, what does that pull in"
<cjwatson> smoser: Cool.  It can be a bit obscure :-)
<smoser> i guess the one comment i'd have is in pretty table output.
<smoser> is nice for humans.
<cjwatson> Yeah, I've been meaning to do a machine-readable output format for some time.
<smoser> yeah.
<smoser> if there was a prettytable reader
<smoser> (which surely someone has done)
<cjwatson> One of these days ...  Nowadays LP just uses the underlying libraries directly
<smoser> then it'd be ok. but the totals at the end would make it at least tricky
<cjwatson> Though partly that's because it's significantly faster for its needs to do it that way
<cjwatson> (Not because the table formatting is expensive or anything, but because it was duplicating a lot of work in the multiple runs it used to do)
<smoser> oh. its was quite reasonably performant for me. ran on a caonnistack instance (so fast mirror access) but the whole run would only take maybe 30 seconds.
<cjwatson> yeah, for only one run it's fine
<cjwatson> LP does <number of architectures> * <number of flavours>
<asac> ogra_: can you do something like image stats
<asac> ogra_: thta just shows the diff from /current to /current ?
<ogra_> asac, which kind of image stats ?
<asac> ogra_: QA would like to do that
<ogra_> sure
<asac> cjwatson: didrocks and ricmm seem to had delays in publishing to proposed
<ogra_> my script can take any version number you want
<ogra_> (as long as it exists)
<asac> cjwatson: not sure if they talked to you ... just want to ensure that no infraa parts art down etc.
<didrocks> asac: done now
<asac> ogra_: http://people.canonical.com/~ogra/touch-image-stats/
<ogra_> yeah
<didrocks> asac: hence the no ping, while we speak, it happened
<asac> ogra_: you called it image stats :)
<asac> ogra_: i want the same for current (not proposed)
<didrocks> asac: monitoring the migration to release now
<asac> ogra_: that will help QA to do focussed efforts
<ogra_> asac, they should just grab the script and call it with the two image stamps they want to compare
<asac> didrocks: allright
<asac> cjwatson: ignore
<asac> ogra_: can you set it up so it automatically happens?
<ogra_> as long as there is a manifest it will show the diff
<asac> ogra_: i know tey can do it, but i want to have a reusable link
<asac> that we can share and everyone sees the same
<ogra_> asac, tricky, since i dont have a history about which image was when /current
<ogra_> we would have to store that somewhere
<asac> ogra_: ok ... give the script to jfunk please
<asac> in a bzr branch (not a paste)
<asac> :)
<asac> ogra_: or give it to jfunk and pitti :)
<ogra_> pfft ... it is in the dir :)
<asac> then i feel its understood
<asac> no idea
<asac> just tell jfunk and pitti so they can sort it :)
<ogra_> pitti, jfunk,  http://people.canonical.com/~ogra/touch-image-stats/ see the README and the compare-manifests script
<cjwatson> FWIW I see nothing particularly untoward in publisher runtimes or anything recently
<ogra_> cjwatson, does mark-current long its actiona anywhere ?
<ogra_> *log
<rbasak> kees: please could you review https://code.launchpad.net/~dannf/cpu-checker/arm-cortex-a15/+merge/171667? Looks like dannf has updated his MP following your review. Could you check/merge if appropriate, please?
<ogra_> so that i could have an overview which images were /current
<ogra_> *actions ... sigh
<cjwatson> ogra_: cdimage/log/mark-current.log
 * ogra_ hugs cjwatson 
<ogra_> thanks !
<OvenWerks> cjwatson: Re: dssi-vst. It is hard to make it a dep or include on an ISO because it is effectively 32 bit only. So to use it on a 64 bit machine it has to be installed after the ISO is installed and then of coarse it pulls in all the required 32 bit libs (and wine I think)... windows :P
<OvenWerks> cjwatson: That of course says nothing about if it should be kept or not. Hopefully falktx's stuff will get put in debian and replace it.
<cjwatson> OvenWerks: I'll keep it for now, but if you folks decide you want to keep it in Ubuntu, it'd be nice if somebody could take up maintenance in Debian too
<cjwatson> Since I think it was just removed due to build failures that we'd fixed ...
<OvenWerks> Ah, good to know. I don't know if anyone uses it to be honest.
<bdmurray> slangasek: I think the pycompile patch in ubuntu-release-upgrader (for bug 689615) could also be dropped.  agreed?
<ubottu> bug 689615 in python-defaults (Ubuntu Maverick) "pycompile fixes needed for maverick" [High,Fix released] https://launchpad.net/bugs/689615
<slangasek> bdmurray: yes, since precise is the oldest version this upgrader will be used from, that can be dropped.  I was being conservative in dropping fixes for upgrades from releases that you could *theoretically* still use this upgrader for; but if you want to be more aggressive, we should draw the line at anything older than precise
<bdmurray> slangasek: okay, I'll keep that in mind thanks
<pitti> barry, ScottK: Do you know how important it is to ship foo.egg-info/ bits in python* packages?
<pitti> I just noticed that the python-autopilot doesn't have it, and nothing is blowing up apparently
<barry> pitti: in practice (as you saw) it's probably not that important, unless you have entry_points (e.g. console_scripts) or other things that the runtime might want to introspect
<pitti> barry: ok, thanks
<roadmr> Hello! I'm about to dput a new checkbox package for Ubuntu, it contains only bug fixes. Is this OK since we're past FF? (just wanted to double-check before messing things up)
<pitti> roadmr: unless you consider things like "change the UI" and "we are missing this feature" as bugs, then yes
<roadmr> pitti: heheh :) I do have one minor string change, my rationale is that it's OK since we're not past UI Freeze yet
<pitti> roadmr: ah, yes
<roadmr> pitti: other than that, I'm sure there are no new features or UI/behavior changes
<pitti> roadmr: that's fine then
<roadmr> pitti: thanks, I'll proceed with the upload then!
<bdmurray> slangasek: do you know how the verification for bug 1179781 may have happened before your comment regarding uploading it to precise?
<ubottu> bug 1179781 in curl (Ubuntu Raring) "If-Modfied-Since undhandled case causes apt lists corruption with https repositories" [Medium,Fix committed] https://launchpad.net/bugs/1179781
<cyphermox> sil2100: please don't touch the saucy platform, misc, or unity8 stacks for now, I'll handle them
<cyphermox> we did some changes that will majorly break stuff if it's touched
<sil2100> cyphermox: ACK, doing now packaging and coding anyway
<Noskcaj> kirkland, roaksoax: Do either of you have some time to talk about testdrive
<ChickenCutlass_> stgraber, I just built my own kernel -- how do I sign it to get the efi.signed version?
<stgraber> ChickenCutlass: you can't
<stgraber> ChickenCutlass: you'd have to sign it with the Ubuntu SecureBoot key which you obviously don't have access to
<stgraber> ChickenCutlass: but grub2 will be happy to boot an unsigned kernel, so just do that
<ChickenCutlass> stgraber, ok, right - that is what I am doing
<ChickenCutlass> stgraber, what file do I edit to make grub used the non signed kernel permanently
<ChickenCutlass> stgraber, so I don't have to edit each boot
<stgraber> ChickenCutlass: depends how you made your kernel. If it's a .deb that you installed, I'd expect grub to just do the right thing.
<infinity> ChickenCutlass: You mean your kernel is a lower version than others, and thus isn't "entry 0" on the list?
<stgraber> ChickenCutlass: I had a quick look at the code and it'll only use .efi.signed if the file exists, otherwise it'll use the standard vmlinuz-... name
<infinity> ChickenCutlass: If update-grub put it elsewhere than 0, you can edit /etc/default/grub and change GRUB_DEFAULT=0
<ChickenCutlass> stgraber, so I built my own kernel deb -- installed it. but grub.cfg still points to the .signed
<ChickenCutlass> stgraber, ah
<infinity> Oh, if there's a .signed that matches your kernel version but isn't your kernel, that would be a problem. :P
<ChickenCutlass> stgraber, so just delete the signed
<slangasek> bdmurray: 1179781> looks like the verification tag was added in error
<infinity> ogra_: Wait, I was only half-listening.  Uploaded "just now" to where?  The archive?
<bdmurray> slangasek: okay, that was my thought too
<ogra_> but you had at least a funny expression on your face :P
<josepht> ogra_: he's been like that all day :)
<infinity> I've been arguing with computers and attempting to listen to meetings at the same time.  It's hard work.
<ogra_> infinity, unity-mir just finished building, livecd-rootfs , lxc-android-config and ubuntu-session-touch were just uploaded right now
<infinity> ogra_: Oh, I thought you mentioned something abot upstart-app-launch, which is what I was looking for.
<ogra_> infinity, i said, that it might not make sense if you wait that long
<infinity> And ubuntu-session-touch doesn't exist. :P
<ogra_> upstart-app-launch will be pocket copied from the daily-next PPA
<ogra_> then re-order :P
<ogra_> ubuntu-touch-session :P
 * infinity goes back to arguing with arm64 buildds instead.
 * ogra_ always has a hard time remembering the package names he made up when drunk :P
<slangasek> jbicha: the debian/copyright for gnome-weather is incomplete; it's missing license/copyright info for all of data/*.  It also doesn't cover libgd/*, but I'm hoping you're not using that embedded copy at build-time...
<jbicha> slangasek: libgd is included in GTK 3.9; projects like gnome-weather and gnome-documents bundled the library before then as it was still under heavy development (it's not designed to be packaged separately by distros)
<jbicha> gnome-weather was rejected in Debian new because the images it uses several CC-BY 2.0 and CC-BY-SA 2.0 images
<jbicha> since CC-BY is generally *more* permissive than CC-BY-SA I would think Debian should accept art with that license but I never braved debian-legal to try to get that official
<YokoZar> Can tests have cross-arch dependencies?
#ubuntu-devel 2013-09-13
<YokoZar> Or is it just like package build-deps and that they must all be satisfied within-arch
<mwhudson> i have a php5 build that's exploding because mysql can't create a database to run tests in or something
<mwhudson> does this ring any bells with anyone?
<sarnold> mwhudson: there's some funny magic in the mysql upstart to ensure an apparmor profile is loaded; I wonder if (a) your apparmor fails to load thus the database fails to load (b) the profile does load, but forbids the testing location?
<mwhudson> sarnold: this sounds plausible
<mwhudson> do the buildds have especially crippled apparmor?
<mwhudson> and is there some way i can turn it off to verify?
<mwhudson> well apt-get install apparmor-profiles sure complained a lot
<mwhudson> yes ok
<mwhudson> Sep 12 20:51:00 h9a kernel: [3212473.992787] type=1400 audit(1379033460.123:64): apparmor="DENIED" operation="mknod" parent=26437 profile="/usr/sbin/mysqld" name="/home/ubuntu/php5-5.4.9/mysql_db/h9a.lower-test" pid=26458 comm="mysqld" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
<mwhudson> sarnold: how can i tell apparmor to FOAD?
<sarnold> mwhudson: good question, I've never poked at the php5 build before :/
<mwhudson> maybe i can just put my build directory in /tmp :)
<rbasak> That's odd. I've had issues building php5 locally, but not seen that particular issue. Are you using sbuild, or something else? And which version?
<mwhudson> rbasak: just running debuild
<mwhudson> and it's php5_5.4.9-4ubuntu2.3 + a couple of patches
<rbasak> mwhudson: are you using -rfakeroot?
<mwhudson> ubuntu@h9a:/tmp/php5-5.4.9$ debuild
<mwhudson>  dpkg-buildpackage -rfakeroot -D -us -uc
<mwhudson> dpkg-buildpackage: source package php5
<mwhudson> ...
<mwhudson> rbasak: looks like it?
<rbasak> Yeah I guess so.
<rbasak> I'm a bit confused. Why does apparmor see an mknod call at all?
<sarnold> hrm, this page suggests that the <name>.lower-test file write isn't serious and can be ignored http://dev.mysql.com/doc/refman/5.0/en/cannot-create.html
<mwhudson> well
<mwhudson> the process that produces that error then falls over in a heap and exits with code 1
<mwhudson> i make no claims as to know what's going on :)
 * mwhudson is running the build in /tmp now....
<rbasak> Do you need to run the test suite? You could disable it with nocheck.
<mwhudson> well
<rbasak> (assuming the packaging supports that)
<mwhudson> i would _like_ to run the test suite
<rbasak> :)
<mwhudson> but it's not essential for this i guess
<mwhudson> it appears the package does support nocheck so i'll try that next
 * mwhudson goes for a walk
<infinity> pitti: Does germanium need to learn about arm64, or will it just pick it up magically?
<slangasek> jbicha: erm, I thought CC-BY{,-SA}-2.0 were allowed in Debian... I've not heard of packages being rejected from main as a result of either of these.  But in any case, the license wasn't listed in debian/copyright, which is certainly an ftp reject reason
<slangasek> hmm, not actually here
<DktrKranz> slangasek: CC-BY-*-2.0 is not allowed in Debian main
<slangasek> DktrKranz: ah, ok.  I always get confused about which versions were the "good" ones
<DktrKranz> at the moment, CC-BY-SA-3.0 is fine
<DktrKranz> (we should really complete http://ftp-master.debian.org/licenses/)
<slangasek> might be useful, yes :)
<dholbach> good morning
<dholbach> can somebody please reject https://code.launchpad.net/~xnox/ubuntu-seeds/ubuntu-touch.remove-webapps-demo/+merge/185092?
<dholbach> (based on the comment)
<xnox> dholbach: done.
<dholbach> thanks xnox
<xnox> YokoZar: at the moment we don't have cross-arch dependencies, but, if multi-arch is enabled, you can depend on a package which only present on that arch to get a similar effect.
<xnox> YokoZar: see wine on amd64 for example.
<YokoZar> xnox: I was asking because I wanted to add winetest to wine's amd64 package, but it depends on wine's 32 bit as well ;)
 * mlankhorst pokes YokoZar 
<cjwatson> mdeslaur: Mind if I merge libxcb?  It fails to build in saucy because it's out of sync with xcb-proto; the new upstream fixes that.
<cjwatson> mdeslaur: (this is a blocker for the arm64 bootstrap)
<rbasak> kirkland: hey! Could you please see if https://code.launchpad.net/~dannf/cpu-checker/arm-cortex-a15/+merge/171667 is OK to land? I asked kees but I guess he's busy. It looks like you are in ~cpu-checker-dev too?
<cjwatson> mdeslaur: It does have your security fix
<brendand> rbasak, is there an armhf build of cpu-checker available yet?
<rbasak> brendand: not that I'm aware of, although AIUI dannf's patch is all that is needed. I'll propose a distro patch if we can't get his patched merged upstream soon.
<mdeslaur> cjwatson: not at all, go right ahead
<cjwatson> mdeslaur: thanks, done
<tkamppeter> cjwatson, hi
<mdeslaur> dholbach: can I please push my patch piloting to monday?
<dholbach> mdeslaur, sure, whenever you like it best - just move it in the calendar
<dholbach> mdeslaur, the schedule I set up is more just a reminder
<cjwatson> tkamppeter: yes?
<tkamppeter> cjwatson, I have a problem with PackageKit, called from a Python program, /usr/bin/install-printerdriver.
<tkamppeter> cjwatson, http://paste.ubuntu.com/6101343/
<cjwatson> tkamppeter: I only started learning about PackageKit a couple of months ago, and I only know as much about it as I've needed for click; this isn't a corner of it I know, I'm afraid
<tkamppeter> cjwatson, who could I ask?
<cjwatson> tkamppeter: I'm not sure.  Sebastian Heinlein, maybe, if you can track him down
<tkamppeter> cjwatson, thank you.
<mdeslaur> dholbach: cool, thanks
<mdeslaur> dholbach: google calendar won't save the changes, sorry
<juliank> tkamppeter: You could ask ximion for help on the PackageKit problem (if it's really related to PackageKit, and not something in aptdaemon's pkcompat stuff, but it seems to be in the PackageKit client bindings) once he's back; although I don't know when he'll be online again.
<juliank> If this is also PackageKit on the server side (that is, aptdaemon's pkcompat is not involved) you can also ask in #PackageKit, although no Debian or Ubuntu people seem to be there at the moment except for me.
<tkamppeter> juliank, I have installed the Saucy package of system-config-printer on Raring now and there it works, so it seems to be a PackageKit or aptdaemon regression in Saucy.
<tkamppeter> juliank, thanks, if I do not find them I will report a bug.
<dholbach> mdeslaur, no worries
<pitti> Good morning
<pitti> infinity: nope, no magic; I'll tell it about it
<pitti> infinity: hm, I added arm64 for saucy and re-pulled the last 7 days of ddebs, but it seems it didn't pick up a single arm64 binary; did we actually have any yet?
<cjwatson> pitti: We have a small handful
<cjwatson> Still working on the bootstrap
<pitti> hmm, /me looks closer
<pitti> oha: The requested URL /~buildd/ddebs/ was not found on this server.
<pitti> that's http://birch.buildd/~buildd/ddebs/
<cjwatson> pitti: Note that they've been going into saucy (release) rather than saucy-proposed, if that makes a difference
<pitti> infinity: so it seems these buildds aren't apache-ified yet?
<cjwatson> That's an error message from Apache, surely?
<pitti> yes, sorry; I meant the buildd hack hasn't been applied there?
<pitti> neither on magic nor kijo01
<GuidoPallemans> Hey guys, I have a problem installing my own click package on my computer, should I be worried?
<GuidoPallemans> in the ubuntu software center i get an error <filename>_1.0_all.clickâ could not be opened.
<cjwatson> GuidoPallemans: Installing click packages on the desktop is kind of possible with some hackery, but it's not supported yet and certainly not via Software Center.
<cjwatson> GuidoPallemans: For 13.10 they're just for touch devices.
<GuidoPallemans> oh ok.
<GuidoPallemans> thanks!
<GuidoPallemans> but how can I test them then?
<cjwatson> GuidoPallemans: You'll need a touch device ...
<GuidoPallemans> dang
<cjwatson> (There's work in progress on an emulator)
<OvenWerks> cjwatson: I asked aboout dssi-vst on our ML and I am told falktx has talken it over as maitainer and will be reintroducing it to debian. Not sure of time frame. His builds both 32/64bit.
<diwic> slangasek, do you have time to explain how to fix a multi-arch related bug to me?
<OvenWerks> cjwatson: (the building in 64bit doesn't stop it from needing wine)
<cjwatson> OvenWerks: OK, thanks
<GSport> everything i say is copyrighted
<infinity> pitti: I see ddebs directories on all but kijo01 (that host isn't being used).
<infinity> Oh, maybe mod_userdir isn't enabled.
<infinity> pitti: Okay, fixed.  Should be ddebs to fetch now.
<SuperLag> Thank you guys for your work on the distro. It rocks. You guys rock. :)
<SuperLag> Has there been any official decision made on whether Ubuntu is going to move to a rolling release model, or not? or is that still up in the air?
<stgraber> SuperLag: there has been an official decision that it wouldn't (at least for now). Though a few changes were done to reduce the support length of non-LTS releases and make it easier for people to track the development release.
<stgraber> SuperLag: http://fridge.ubuntu.com/2013/03/19/changes-in-ubuntu-releases-decided-by-the-ubuntu-technical-board/ for the summary I wrote of the relevant Technical Board meeting
<stgraber> SuperLag: https://lists.ubuntu.com/archives/technical-board/2013-March/thread.html has some more details of the discussions too
<jbicha> why does ibus-xkbc's excuses say 'unsatisfiable Depends: python:any (>= 2.7.1-0ubuntu2)'
<cjwatson> jbicha: Because proposed-migration doesn't understand :any yet - I have most of a patch to fix this and will land it before saucy
<cjwatson> Did it towards the end of Debconf and then got distracted by vacation and forgot about it :)
<jbicha> cjwatson: ok, thanks
<slangasek> cjwatson: oh, did I jump the gun by getting dh-python :any-fied? :)
<cjwatson> slangasek: I may have forgotten to mention this, largely because I'd forgotten that I hadn't finished this ...
<cjwatson> slangasek: Will get it done early next week, my head is full of the cold right now
<slangasek> cjwatson: ok.  note that this means an awful lot of packages that depend on python are going to be coming through with python:any deps; I probably should've done a proper FFe request for this change...
<slangasek> cjwatson: do you think I should back it out until you have a chance to work on p-m?
<cjwatson> slangasek: Nah, I have most of it done and this gives me an excellent test case
<cjwatson> It's just that I didn't feel like merging http://paste.ubuntu.com/6102117/ without testing its behaviour rather closely
<cjwatson> (Also the patch is unfinished, as you'll see from the mismatched parens in lib/dpkg.c)
<ev> pitti: rickspencer3 is seeing apport consume 100% CPU on his phone. Perhaps in this new world of mobile devices we should use a cgroup to minimise the CPU time it can use?
<rickspencer3> arg ....
<ev> on second thought this is probably better handled with nice
<rickspencer3> ev additionally, the update did not apply or something
<ev> rickspencer3: *nods*
<rickspencer3> let me reboot and try again
<slangasek> ev: nice vs. cgroups, depends on the goal... if it's, say, the shell that's dead, you want apport to be greedy with the CPU because the whole thing is dead in the water until it finishes anyway, and apport won't actually be competing with other processes for resources, so a nice level is probably most logical there
<slangasek> but in some cases it'll still be using 100% CPU because it *should*
<ev> slangasek: yes, that was my thinking. I didn't want to restrict apport when it's not competing with anything else
 * slangasek nods
<slangasek> rickspencer3: did you get to see what apport was chewing on before you rebooted?
<rickspencer3> slangasek, no, sorry
<rickspencer3> I assumed it was related to failing to download the update
<rickspencer3> arg
<slangasek> rickspencer3: it was probably processing the core file for whatever crashed... so rebooting before it's done means we get no crash report from it
<rickspencer3> slangasek, sorry
<rickspencer3> slangasek, I did wait until it was not showing up in top
<rickspencer3> so I think it finished
<slangasek> rickspencer3: ah, yeah, probably then
<rickspencer3> I just didn't look at what it was
<slangasek> in that case whoopsie should take it from there :)
<rickspencer3> slangasek, that's what I expect, yes
<ev> slangasek: while we're on the subject, lool pointed out that we probably want to handle resumable uploads for error reports on touch
<ev> eventually
<slangasek> ev: resumable, not just retries?
<ev> yes, we already retry
<ev> "an awful scenario would be that I'm on shitty internet, this large crash file never gets uploaded, but the crash happens from time to time and we never know about it and it keeps eating bandwidth on people's systems"
<SuperLag> cjwatson: whiskey. Drink some. It'll burn out all those cold germs. :)
<SuperLag> stgraber: thank you for the info
<slangasek> ev: yeah, that's a good point.  is this captured in a blueprint / bug report so we don't forget?
 * mdeslaur needs some cold germs too
<ev> slangasek: on it
<hallyn_> mdeslaur: you can drink the whiskey without first getting the cold germs
<mdeslaur> hallyn_: can I still claim it's medicinal?
<SuperLag> haha
<hallyn_> mdeslaur: yeah, just say you drank some LA well water, I hear it has some brain fungus
<mdeslaur> hehe
<ev> slangasek: https://blueprints.launchpad.net/ubuntu/+spec/foundations-1308-touch-error-reporting
<pitti> infinity: confirmed, w3m works now; re-fetching
<pitti> ev, rickspencer3: like, 100% forever, or just while it actually is writing the file and processing the core dump?
<rickspencer3> pitti, it seemed like it was just working normally
<rickspencer3> except that it pegged my CPU while it was doing it's thing
<pitti> in general it's better to let a process run at 100% in x seconds than at 50% in 2x seconds (power-wise)
<pitti> of course it should be niced so that it does'nt slow down foreground apps
<pitti> rickspencer3: yeah, kind of unavoidable I'm afraid; core dumps are big, we have to compress them; we can think about using less aggressive compression maybe, but it's already only using gzip
<pitti> thomi, didrocks: forgot to set a commit message before the tests ran in https://code.launchpad.net/~pitti/autopilot/bamf-dep/+merge/185497; I did that now, do we need to re-run the tests, or will the PS Jenkins bot pick up that I added it now and approve?
<thomi> pitti: it gets picked up
<pitti> cheers
<pitti> infinity: look, arm64 ddebs!
<pitti> infinity: no indexes yet, but they'll be built later in the day
<infinity> pitti: Shiny.  Indexes aren't critical, it's not like we have enough packages to retrace.  Just wanted to make sure we didn't lose any ddebs before cleaning crons kick in.
<pitti> actually, they are:
<pitti> http://ddebs.ubuntu.com/dists/saucy/main/binary-arm64/Packageshttp://ddebs.ubuntu.com/dists/saucy/main/binary-arm64/Packages
 * pitti draws a +5 pasting skills card
<infinity> pitti: William and I need to put our heads together and figure out a way to gina all your ddebs into the librarian some time.  It'll offend me if arm64 is 99% complete in soyuz, and has 1% of its ddebs in the legacy archive. :P
<didrocks> pitti: the build test ran as expected
<didrocks> pitti: so, once someone set to approved, everything's will be fine, not having a commit message isn't an issue before you set to approve
<pitti> didrocks: d'accord, merci
<didrocks> pitti: mais de rien!
<slangasek> smb: good news!  I still can't reproduce the bug in a VM, but I can reproduce it on my laptop ;)
<cjohnston> pitti: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1225113/comments/2
<ubottu> Launchpad bug 1225113 in apport (Ubuntu) "ubuntu-bug should report touch image information" [Undecided,Incomplete]
<pitti> cjohnston: ah, I hope that system-image-cli won't actually need root
<pitti> cjohnston: thanks, I'll play with this
<cjohnston> barry: ^
<cjohnston> I don't know if it does or not
<barry> pitti: system-image-cli needs root to do updates, but should not need it for --info
<barry> (i'd say it would be a bug if that were the case ;)
<barry> --info/--help/--version that sort of thing
<barry> (basically, if it doesn't need to download anything, it shouldn't need root)
<cjohnston> cool.. thanks barry
<barry> pitti: btw, i'm playing with py-dbusmock.  looks quite nice.  i gather by adding a template, i can make mocks "do things" in response to methods, right?  e.g. wait 3 seconds then send signal foo
<slangasek> smb: and reproduced in a vm now too, so progress
<pitti> barry: yes; you can do anything templates can do in your normal test cases, but it makes sense to write templates for common services (such as NM or logind)
<barry> pitti: i'm actually trying to mock the new ubuntu-download-service so i can continue to make progress while the real service is fixing some critical bugs.  it might make sense to keep the mock anyway later.  but anyway, thanks for this useful package.  i filed a bug and may push some mps as i go.
<pitti> barry: right, that's the idea -- as soon as you encounter the second place that needs that mock, generalize and put into p-dbusmock
<barry> pitti: +1
<cyphermox> stgraber: poke
<cyphermox> stgraber: know anything specific about /sys/fs/cgroup/memory/lxc/memory.use_hierarchy ?
<YokoZar> So, I've noticed over the years that a lot of Wine games don't work because of performance reasons, and in turn I've discovered that a lot of those performance problems are solved if you force the CPU to run at 100% through a tool like cpufreq  --  this even happens on desktop systems and laptops with 100% battery on AC power.
<YokoZar> I'm wondering what sort of rabbit hole I'll climb into if I try to get a handle on power management configuration, and more specifically how much of this is distro-specific.
<YokoZar> It strikes me as a serious bug that the cpu isn't upscaling to 100% when a cpu-bound app is run in Wine, but I'm not 100% sure what to file the bug against
<stgraber> YokoZar: you'll likely end up crying once you figure out that it's mostly caused by broken firmware
<ChogyDan> YokoZar: that is part of the kernel, cpu frequency governers.  And I think you would file upstream
<stgraber> YokoZar: most of my machines here are reasonable, the kernel defaults to ondemand and the scaling happens as you'd expect with the policy changing when switching between AC and battery
<sarnold> YokoZar: a few thoughts: (a) I've seen something like gnome-cpu-indicators (or whatever) actually dicking around with the CPU -- make sure you're not also running something stupid like that (b) what governor are you using? performance vs powersave, it'd make a difference. again I think some "power management" contraptions might try to manage those for you.
<stgraber> YokoZar: but you need a machine with an ACPI that's not completely messed up for that :)
<YokoZar> sarnold: I've seen it on a wide variety of machines, even "supported" stuff like System76 laptops.  Or AWS nodes!  In trying to mitigate it by manually forcing everything to 100% I have discovered some conflicting stuff, but it isn't quite default.
<stgraber> example, all my cores are currently at 1.2Ghz, if I start "yes | sha1sum", one of the core (two threads) instantly go to 2.9Ghz
<barry> pitti: if you're still around.  does running dbusmock on a system bus require sudo?  http://paste.ubuntu.com/6103403/
<stgraber> and that's default saucy, no config whatsoever
<YokoZar> stgraber: Yeah that sounds like how it should work.  But nevertheless when I do something like install indicator-cpufreq and force it to "performance" my game goes from 12 fps to 40 fps
<stgraber> so it may be interesting to get some stats, what subset of machines don't default to ondemand and why, then for those that use ondemand, figure out why some don't scale as quickly as they should
<YokoZar> (on a few different systems)
<YokoZar> I feel like we don't test this case at all really
<ChogyDan> YokoZar: I had issues with ondemand.  I lost about %30 performance for cpu bound applications
<ChogyDan> anyway, this is better for offtopic
<stgraber> YokoZar: I guess letting the user tweak some of those in the settings may be interesting, though I doubt we can simply do things like force performance when on AC
<stgraber> YokoZar: as quite a few new systems overclock in such cases and can't sustain it indefinitely (well, they should, but there again, firmware usually sucks, so you'll probably reach the trippoint and your machine will just shutdown)
<sarnold> ouch
<YokoZar> stgraber: There is firmware that does that.  I remember having a demo set up and discovering that if we unplugged/replugged the laptop it would forever lose its performance mode until manually reset
<stgraber> YokoZar: yeah, you can decompile your DSDT table to figure out exactly what those triggers are and if you feel like it, fix some of those.
<stgraber> I suspect they just ship fixed/tweaked tables as part of their drivers on Windows and just swap them so they don't get the same problems there (since people are usually bad at updating their firmware...)
<ChogyDan> YokoZar: Im curious, could you try fiddling with sampling_down_factor, and see if that changes things for you?
<YokoZar> ChogyDan: when I set it to 3 instead of 1 (while on ondemand governor) I did see more consistent "max" fps -- with it on 1 it would occasionally drop down for a second or two.  I've seen wildly different performance on this machine (including on default settings), I'm beginning to get a sense this is a much bigger real world problem
<ChogyDan> YokoZar: try 200.  1 is just disabled, 3 is barely anything
<ChogyDan> YokoZar: basically, it is a time based factor that delays ondemand's scaling the frequency back down.  So *1 is default behaviour.  * other numbers, it increases the max freq time exponentially I believe,
<sarnold> hrm, the archlinux wiki page suggests that changes how often checks are made
<sarnold> if the cpu -could- be scaled down at a given check, it'd keep it down for a while
<ChogyDan> sarnold: I dunno, the idea was about keeping it up I thought
<sarnold> ChogyDan: going entirely by this one wikipage, it looks to me like it's about reducing the overhead of the checks..
<sarnold> ChogyDan: ohhhhh, maybe i'm wrong, "This tunable has no effect on behavior at lower CPU frequencies/loads. "
<ChogyDan> sarnold: well, it does do that, since it delays ondemand from checking so often
<ChogyDan> sarnold: this is probably the one thing of linux that I'm aware of beyond the reading documentation.  I've filed a single bug upstream, and it was about the poor performance of ondemand.  The sampling_down_factor patch was proposed as a possible performance boost and solving of my issue.  So I read through the patch, but since I'm bad at compiling kernels, I haven't actually tested it much
<OvenWerks> YokoZar: I don't know if this would help, but I found I got better performance (latency wise) with freq set to user and forced to half speed than with on demand. It seems even though the cpu speed switch is very quick I was getting audio under runs at ondemand speed switching. It might interesting to try other speeds than just performance. Also, The application may be settings its max frame rate bassed on idle performance before the higher speed kicks 
<YokoZar> OvenWerks: Yeah, it's entirely possible the game is too smart in a lot of cases
<OvenWerks> Running a high cpu use do nothing app when startiing the game up? :P
<stgraber> hallyn_: cyphermox reported:
<stgraber> root@castiana:~# echo 1 > /sys/fs/cgroup/memory/memory.use_hierarchy
<stgraber> bash: echo: write error: Device or resource busy
<stgraber> hallyn_: isn't that supposed to work? :)
<hallyn_> stgraber: it doesn't work once there is already a subdir
<stgraber> hallyn_: haha, that explains it, thanks
<stgraber> cyphermox: ^
<hallyn_> yup.  it's actually one reason to stick with /lxc/%n as cgroup_pattern, i guess
<cyphermox> ok, so it means we don't need to rerun it or what?
<hallyn_> what is it set to
<stgraber> cyphermox: if you have a script doing the echo, just do it at boot time, before LXC in /sys/fs/cgroup/memory/memory.use_hierarchy
<stgraber> cyphermox: I assume that this should then get inherited by everything that gets created after that point
<stgraber> cyphermox: (and I just confirmed it)
<cyphermox> cool, sure
<cyphermox>  thanks
<stgraber> np
<cyphermox> that happens before we start the container
<sarnold> ChogyDan: funny enough I did wonder if the code would be easier to understand.. :)
<didrocks> stgraber: is this new?
<didrocks> stgraber: we run it during the pre-mount
<didrocks> for months
<stgraber> didrocks: it probably changed behaviour at some point in 3.11
<didrocks> ok
<didrocks> stgraber: actually, we do that in prestart
#ubuntu-devel 2013-09-14
<stgraber> anyone desktopy around who would be kind enough to fix indicator-power to stop bringing all of click, click-apparmor, ... on all Ubuntu desktop installs?
<stgraber> (that's before I just go and revert the package by hand breaking the daily release stuff in the process)
<stgraber> I'll upload the revert in 15min.
<cyphermox> stgraber: still around?
<cyphermox> mountall: mount /sys/fs/pstore [338] terminated with status 32
<cyphermox> mountall: Filesystem could not be mounted: /sys/fs/pstore
<cyphermox> do you know what this is? ^^^
<cyphermox> stgraber: please hold off if it's not too late
<cyphermox> (re indicator-power
<didrocks> stgraber: what are you trying to fix exactly?
<didrocks> does it impact the dashboard/user experience?
<didrocks> we have click in main, so it's not an issue with main/universe
<didrocks> the next iso should build successfully, right?
<didrocks> even if click isn't that useful yet on the desktop
<Noskcaj> roaksoax, kirkland: Perhaps we should make testdrive community run rather than canonical run, since it's not canonical maintained or in "main"
<Noskcaj> Plus i've found a guy who's willing to convert it to gtk3
<jbicha> testdrive is not run by canonical
<roaksoax> Noskcaj: it is community run nobody pays us to work on it
<roaksoax> i did it on my own free time
<Noskcaj> roaksoax, sorry, remove the canonical copyright
<cyphermox> stgraber: ignore my question about pstore, I just saw your lxc upload
<roaksoax> Noskcaj: the canonical copytight belongs there cause yhe projrct was modified aftrr i started at canonical
<jbicha> and if you're interested in gtk3, see https://code.launchpad.net/~jbicha/testdrive/port-to-gtk3/+merge/72369
<roaksoax> hence the copyright
<jbicha> I won't have time to work on it any more
<Noskcaj> jbicha, DanChapman has nearly finished the gtk3 port, he said it should be done this week
<stgraber> didrocks: we're after feature freeze and that change pulls a dozen new packages on my system
<stgraber> cyphermox: I was just about to point it out :) unfortunately you'll need to manually apply the fix to your existing containers
<didrocks> stgraber: I think we should try to check if this shouldn't be considered as a noop
<cyphermox> right, and to the template used to create the containers
<didrocks> it's safe
<didrocks> it doesn't impact user experience
<didrocks> basically, we're just doing more work for nothing
<didrocks> and bringing pain to touch people
<stgraber> didrocks: well, I don't think it's a good idea to install extra packages offering extra APIs when we don't need to, it's making our images bigger and opening some new doors for potential security issues
<didrocks> stgraber: we should see one converged world IMHO, but I'm surprized that slept in
<didrocks> is this a direct dep?
<didrocks> I'm seeing in debian/control:
<didrocks> + liburl-dispatcher1-dev
<didrocks> nothing click*able
<stgraber> didrocks: indicator-power directly depends on some liburl stuff which brings in click indirectly
<didrocks> ah ok, so that one
<cyphermox> didrocks: https://code.launchpad.net/~mathieu-tl/otto/fix-mountall-pstore-hang/+merge/185612
<didrocks> I just checked it's in main
<didrocks> do you feel it's that important to fix?
<didrocks> how critical is it in your opinion?
<didrocks> if you can test this indicator-power on the phone without this dep and it doesn't regress anything, this will be helpful
<stgraber> it's: indicator-power DEPENDS on liburl-dispatcher1-dev DEPENDS on liburl-dispatcher1 RECOMMENDS url-dispatcher DEPENDS on upstart-app-launch DEPENDS on click
<didrocks> so if it's the case, please upload the revert and bring that to the Vcs if possible
<didrocks> yeah, long chain of deps ;)
<stgraber> well, my position is, it's a change that brings an extra 10 packages on our default install without a freeze-exception (not that I'd grant one anyway), so it's a violation of the freeze and should be reverted.
<stgraber> also those packages currently have a standing FFe because they're touch-only
<didrocks> stgraber: can we think in term of user impact?
<stgraber> bringing them on the desktop would mean no more feature changes to any of them without a separate FFe
<didrocks> stgraber: didn't slacker_nl and lukasz discussed during vUDS about those common components?
<stgraber> didrocks: I don't see the user impact if the work had been done properly so that the indicator only integrates with touch stuff when it's actually running on touch
<didrocks> stgraber: can you test that?
<didrocks> before reverting
<didrocks> so that we don't break the baseline
<stgraber> didrocks: I'm sure that the revert will make it work no worse than it did this morning and the image was promoted back then, we'll just get back to having one non-working menu entry in the indicator
<didrocks> stgraber: but we're still regressing if that's the case
<didrocks> so we can put that on the list of things to look at
<didrocks> ensuring that it's working without it
<didrocks> and then, doing the revert
<didrocks> it sounds more sensible to me
<didrocks> than breaking for non critical issues compared to all other breakages we have
<didrocks> (as this one is a noop)
<stgraber> to be honnest, I care a whole lot more about us pushing extra unwanted packages on everyone's machine past feature freeze than breaking a single entry in our experimental images which didn't work in this morning's image anyway and hasn't been pushed to any actual user yet
<didrocks> stgraber: I think we should all work to be successful on the phone rather than trying to break something without testing
<didrocks> but anyway, your pick
<stgraber> which is why I'll upload the revert, if you disagree with that, I'll be happy to have a discussion with the rest of the release team about it
<didrocks> stgraber: can you at least please merge that back upstream?
<stgraber> I know exactly what I'll "break" on the phone, since I have a device next to me currently running the binary I'm about to revert the archive to
<stgraber> didrocks: and how do I do that? I suspect it's going to be much more complicated than my patch -p1 -R, won't it?
<didrocks> stgraber: you can still upload directly
<didrocks> stgraber: but please apply your patch to a branch that you propose upstream
<stgraber> ok, uploaded (that uploaded is very simply a patch -p1 -R of the previous one, except for debian/changelog)
<didrocks> stgraber: can you please paste the branch so that I can approve it?
<stgraber> didrocks: hmm, the VCS branch for that source is wrong... well, I guess /13.04/13.10/ will do the trick
<didrocks> stgraber: bzr branch lp:indicator-power?
 * didrocks checks
<didrocks> stgraber: lp:indicator-power seems to contain the latest: indicator-power (12.10.6+13.10.20130913-0ubuntu1) saucy; urgency=low
<didrocks> right?
<stgraber> yeah, it's just the Vcs field that's wrong
<stgraber> the project trunk is right at least
<didrocks> stgraber: oh, feel free to fix it ;)
<didrocks> bonus point to bump the Standards-Version, I guess upstream won't ever do it :)
<stgraber> sorry, I don't care nearly enough to make a second commit
<stgraber> https://code.launchpad.net/~stgraber/indicator-power/revert-20130913/+merge/185613
<didrocks> stgraber: approved, thanks
<ari-tczew> hello. I've got a problem with DSO linking. FTBFS log: http://paste.ubuntu.com/6105990/ (../src/libudt.so: undefined reference to `pthread*) ../src/Makefile: http://paste.ubuntu.com/6105984/ I was trying to move -lpthread in another place in line 29, but still doesn't work. can anyone help me?
<ari-tczew> err, above is mentioned ../app/Makefile
<infinity> ari-tczew: See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=722958 for both my patch, and an educational discussion about the two ways you could have fixed it (you may find the latter useful for future similar bugs).
<ubottu> Debian bug 722958 in udt "udt: Fails to build with --as-needed linker option (patch)" [Important,Open]
 * cjwelborn is bored
 * cjwelborn is bored
<ari-tczew> infinity: so you mean to replace -lpthread with -pthread?
<infinity> ari-tczew: As I pointed out in the bug, there are two ways to fix it.  I went with -pthread when I uploaded to Ubuntu though, yes.
<infinity> ari-tczew: (Obviously nothing for you to do here, since I already fixed it, just thought I'd point it out for educational reasons)
<susy41y> hello everyone
<susy41y> can ask what is the topic room?
<susy41y> hello
<ari-tczew> infinity: got it, thank you
<GuidoPallemans> anyone from the site can explain why I get this error? http://imgur.com/9t8ZdMD
<GuidoPallemans> Hey guys, I'm still getting an error trying to upload an app: http://imgur.com/9t8ZdMD
#ubuntu-devel 2014-09-08
<pitti> Good morning
<pitti> slangasek: mind pushing your systemd-shim update to bzr?
<slangasek> pitti: done
<pitti> slangasek: thanks
<doko> pitti, had you a look at the failing pythonx.y test with the proxy set?
<pitti> doko: yes, I mailed you about the result?
<doko> pitti, no, you mailed a workaround, not a fix
<pitti> doko: I mean I also mailed you the results with the option dropped that you suggested
<pitti> "-network"
<pitti> that still doesn't work, so I kept the "unset proxy" for now
<doko> pitti, does the proxy handle ftp?
<pitti> doko: there's no $ftp_proxy set right now; trying
<pitti> doko: no, I'm afraid not
<pitti> i. e. our squid.internal doesn't handle ftp
<doko> pitti, and smtp?
<pitti> doko: smtp is certainly not something that's being handled through a proxy; but if you mean "can I send mail from that machine", there's no local MTA
<pitti> (but a test hopefully doesn't try that :) )
<doko> pitti, no, looking at the test_smtplib test
<dholbach> good morning
<kdeuser56> caribou: how would I setup kdump with an encrypted root? I'd like to dump to the boot partition, but I could not get it to work
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
<seb128> dholbach, hey, enjoy the piloting ;-)
<dholbach> thanks seb128
<caribou> kdeuser56: ouch, never thought of that
<caribou> kdeuser56: which version ?
<kdeuser56> caribou: I am on latest utopic
<kdeuser56> caribou: there are a few bug reports against fedora/red hat and according to them it has been fixed there ...
<kdeuser56> caribou: https://bugzilla.redhat.com/show_bug.cgi?id=1053045
<ubottu> bugzilla.redhat.com bug 1053045 in kexec-tools "kdump.service complains about using encrypted rootfs as dump target even when crash ramdisk is capable of unlocking LUKS partitions" [High,Closed: currentrelease]
<caribou> kdeuser56: they use a totally different codebase
<kdeuser56> and https://bugzilla.redhat.com/show_bug.cgi?id=1028397
<ubottu> bugzilla.redhat.com bug 1028397 in kexec-tools "kdump asks for luks password, when encrypted fs mountable" [Low,New]
<caribou> kdeuser56: & changing KDUMP_COREDIR in /etc/default/kdump-tools didn't work ?
<kdeuser56> oh ...
<kdeuser56> caribou: I simply changed to /boot ... did not work
<kdeuser56> caribou: can I somehow specify a partition?
<caribou> kdeuser56: that's what it should do but it must already be able to mount / first. I don't know how it behaves when it is encrypted
<caribou> I mean the kexec part of things
<kdeuser56> caribou: hm ... can we somehow make it not mount root?
<kdeuser56> caribou: mounting root will be problematic, since the screen will be frozen during panic and I can't see the password prompt
<caribou> kdeuser56: no as the whole sequence implies a normal reboot up to the point where kdump kicks in
<kdeuser56> caribou: hm... the fedora guys somehow managed to not mount root, if I got that right
<caribou> kdeuser56: because of the fact that the initial boot sequence on Fedora is different
<kdeuser56> caribou: so impossible on ubuntu? :-(
<caribou> kdeuser56: I would not say *impossible* upfront, but it requires some investigation
<kdeuser56> caribou: I'd be happy to provide as much information as needed
<caribou> kdeuser56: I would suggest to open a bug o kdump-tools(ubuntu) on the matter
<caribou> kdeuser56: the problem might be similar on Debian as well, but I maintain both so if needed I'll create a bug ther
<kdeuser56> caribou: what information would you need there apart form how my partitions look like?
<caribou> kdeuser56: maybe the kind of error message you get when changing KDUMP_COREDIR to /boot
<kdeuser56> caribou: where can I find those error messages?
<kdeuser56> caribou: I can't see any on the screen, because it simply hangs forever and wont reboot
<caribou> kdeuser56: anything you see on the screen if any otherwise don't bother
<caribou> then just mention that fact
<kdeuser56> caribou: Okay I have to be somewhere soon, I'll open the bug report later, may I ping you again for further communication?
<caribou> kdeuser56: sure no problem
<caribou> kdeuser56: I'm here all the time
<kdeuser56> caribou: thank you very much
<doko> Logan_, online?
<Mirv> mitya57: hi! the qtxmlpatterns upload is hitting us because of the versio checks done by Qt.. https://launchpadlibrarian.net/184302130/buildlog_ubuntu-utopic-amd64.libusermetrics_1.1.1%2B14.10.20140908-0ubuntu1_FAILEDTOBUILD.txt.gz
<Mirv> mitya57: it'd either need manual forcing of the version number to 5.3.0 in qmake.conf or alternatively a revert
<pete-woods> ogra_: hi, not sure if you're the right person to bug about this, but basically when developing (click packaged) scopes we need a bunch of stuff to be present both on the phone image, and devel packages in the SDK
<pete-woods> so I have this MR: https://code.launchpad.net/~unity-api-team/ubuntu-seeds/scope-facing-apis/+merge/233535
<pete-woods> as at the minute, it's just luck that makes those libraries available at runtime on the phone image
<pete-woods> and some of them simply aren't present in on the "devel" side
<ogra_> pete-woods, we are pretty must at the very edge if it comes to available space on the image, do these three libs add anything ? also if you seed in sdk-libs they need to be part of the ofiicial framework and we commit to maintain them for the lifecycle of the device
<ogra_> s/must/much/
<pete-woods> ogra_: they are already present on the device afaik
<ogra_> good
<ogra_> what about the framework ?
<pete-woods> ogra_: well we better had commit to maintaining them, as our example scopes in the SDK all use them :)
<ogra_> (we can just seed them in touch or touch-core otherwise)
<ogra_> ok
<ogra_> i'll try to get to merge it later today then :)
<pete-woods> ogra_: they are mostly tvoss libraries (except the json one)
 * ogra_ puts a "tvoss will maintain it" sticker on them 
<ogra_> :)
<tvoss> ogra_, that sticker is already there :)
<ogra_> haha
<tvoss> ogra_, but thanks, I like badges ;)
<lfaraone> so, I can technically just commit these (barring FeatureFreeze), but do bug 1366718 and bug 1366723 look like reasonable feature requests? I sort of want to sanity-check a bit :)
<ubottu> bug 1366718 in sbuild (Ubuntu) "sbuild-createchroot does not honour --keyring=""" [Medium,Triaged] https://launchpad.net/bugs/1366718
<ubottu> bug 1366723 in ubuntu-dev-tools (Ubuntu) "mk-sbuild: add --debootstrap-args option" [Wishlist,Triaged] https://launchpad.net/bugs/1366723
<lfaraone> sorry, first bugnumb should be bug 1366721
<ubottu> bug 1366721 in ubuntu-dev-tools (Ubuntu) "mk-sbuild: add --skip-security option" [Wishlist,Triaged] https://launchpad.net/bugs/1366721
 * lfaraone waves at dholbach
<dholbach> hi lfaraone
<lfaraone> how's lyfe?
<dholbach> good good - how about you?
<lfaraone> not bad. Just making sbuild do evil things, because of layer 9 reasons.
<dholbach> lfaraone, if you're adding new options, it might make sense (my opinion) to have a chat with folks who put some work into mk-sbuild, for example kees or tumbleweed
<dholbach> (I just ran 'bzr blame' on the script to get an idea)
<lfaraone> thanks!
<dholbach> smb, happy birthday!
<ogra_> smb, yeah ... happy b-day !
<cjwatson> ~>
<cjwatson> sorry
<ogra_> snakes !
<kdeuser56> caribou: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1366754
<ubottu> Launchpad bug 1366754 in makedumpfile (Ubuntu) "kdump does not work with encrypted root partition" [Undecided,New]
<caribou> kdeuser56: got it
<kdeuser56> caribou: thanks, for any additional info, experimts etc. just ask
<davmor2> ogra_: oh ascii snakes that is definitely what the phone needs you should file a bug instantly ;)
<ogra_> davmor2, well, colin developed it already it seems, we just need to merge it ;)
<davmor2> ogra_: hahaha
<caribou> kdeuser56: sure
<pete-woods> Mirv: sorry to nag. but do you have any update on the broken qtxmlpatterns-opensource-src package? are we reverting? / (what page should I repeatedly hit F5 on?)
<Mirv> pete-woods: I was hoping to get a reply from mitya57, but I guess I need to upload on my own soon(ish). it's when there's something new in release pocket at https://launchpad.net/ubuntu/+source/qtxmlpatterns-opensource-src/
<Mirv> to not revert the changes in that upload, I'll try that forcing of module version (that I've successfully used in the past) as a workaround, and I'll use your silo as testing grounds :)
<pete-woods> Mirv: that sounds like a pragmatic solution
<pete-woods> (furiously hitting F5) :)
<rbasak> infinity: possible MySQL ABI breakage: http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2014-September/007015.html
<rbasak> infinity: thank you for getting me to check!
<Mirv> mitya57: hey, it seems you just did an ubuntu2 upload! I just finished testing that this is what would work, if you don't mind doing ubuntu3 as well as yours failed to build: http://pastebin.ubuntu.com/8290061/
<Mirv> it's a trick I learned when testing single module updates earlier
<dholbach> @pilot off
<udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<cjwatson> Mirv: (should be "mkdir -p .git" there for idempotency)
<Mirv> ack
<Mirv> mitya57: thanks! and right, that works too.
<Mirv> pete-woods: your F5 must have worn out by now, but during the last 800 refreshes you've seen that "ubuntu3" in proposed, so once that hits release pocket your build will start working shortly
<janimo`> jamespage, hi, do you know what the status of golang 1.3 in utopic is?
<jamespage> janimo`, I think its not in yet
<janimo`> jamespage, by status I meant plans and ETA :)
<janimo`> sorry if I was not clear
<janimo`> jamespage, any blocker for just syncing it?
<jamespage> janimo`, yes - you'll need to merge it to preserve the alternatives stuff
<janimo`> jamespage, but no crashers or regressions on packages using it?
<jamespage> janimo`, I have no idea
<jamespage> janimo`, sorry - I've not tested anything related to the 1.3 upgrade
<janimo`> jamespage, is anyone 'owning' golang packages in Ubuntu?
<jamespage> janimo`, I heard rumor that the next docker.io update was blocked due to the 1.3.x release
<jamespage> janimo`, was there a specific reason you wanted to upgrade to 1.3.1?
<janimo`> jamespage, trying to build some nonpackaged apps from github which already rely on 1.3
<janimo`> I can build Go from sources but since we'd want 1.3 anyway soon I thought I'd ask
<jamespage> janimo`, I'd not stand in the way of a golang 1.3 bump but I lack to time capacity to reverse build and test everything in the archive; as golang statically links rebuilds are required.
<doko> directhex, didrocks, Laney, seb128: not sure who of you disabled pch for armhf and arm64 ... this seems to work with 4.9. so please re-enable this when you see it in merges /update etc ...
<janimo`> jamespage, so landing is not happening until those tests happen? I do not know the current landing process well
<seb128> doko, what is "pch"?
<directhex> snuh?
<janimo`> jamespage, we don;t just upload and then fix anything that is reported broken :) ?
<doko> precompiled header files
<seb128> doko, I lack context to understand what you are asking, is that about a specific package,
<seb128> ?
<jamespage> janimo`, I'm not sure the release team (or I) would signoff on that approach
<jamespage> we're past feature freeze so this would need a release team signoff, and they should ask for testing evidence
 * janimo` is longing for the good old times when development releases of ubuntu were development releases :)
<doko> seb128, no, but afaicr the desktop team disabled that for a few packages
<ogra_> janimo`, we had a release schedule back then as well :P
<ogra_> freeze is freeze
<janimo`> ogra_, right, I just thought someone was responsible for Go if we're using it seriously or I'd have brought this up when 1.3 released, months ago :)
<ogra_> we only use it semi seriously except in juju i think
<ogra_> (which doesnt live in the archive afaik)
<pete-woods> Mirv: thanks! I had noticed you put the new package in the silo :)
<seb128> doko, do you have an example?
<doko> seb128, opencv
<hallyn> desrt: then again, after writing the code, i'm a bit worried about giving all unpriv users the ability to take O(nlogn) of cgmanager's time with a single call where n is npids (i.e. trivial to bump)
<hallyn> now that's only bc i was supporting gettasksrecursive(all, cgroup) so you wouldn't have to call it separately for all controllers,
<desrt> hallyn: ya... i was realising as i was writing this code that this could get annoying with large numbers of cgroups
<hallyn> but that sort of seemed necessary
<desrt> but only privileged users can make these requests...
<hallyn> no,
<desrt> at least via systemd-shim...
<hallyn> any unpriv user can create a container where they can start their own systemd-shim
<desrt> true
<desrt> but then they can do anything at all....
<desrt> i should not be concerned that the user has the ability to cause their own copy of systemd-shim to burn cpu cycles...
<hallyn> i suppose this just means i (o rsomeone :) will have to add accounting of time used per uid and report outrageous usage
<desrt> because they could just as easily replace systemd-shim with a forkbomb -- it's their container, after all :p
<hallyn> desrt: it's not their copy of system-dshim,
<hallyn> it's the global cgmangaer
<hallyn> whic his not threaded
<hallyn> that's what i'm worried about
<hallyn> i'm suggesting making systemd-shim do more work so cgmanger doesn't have to :)
<desrt> meh.
<desrt> i've already coded the necessary loops in systemd-shim
<hallyn> yeah, i'm undecided
<desrt> i took a bit of a different approach
<hallyn> oh?
<desrt> it's non-recursive now
<desrt> i'm still working on the patch... it ended up being my sister's birthday yesterday so i couldn't ditch her just to hack on systemd-shim :p
<desrt> i'm figuring out the subtree stuff just now
<hallyn> so you don't need the recursive (non-kill) remove?
<desrt> well
<desrt> it would be nice :D
<desrt> but no -- the code would be fine as it is
<hallyn> hm.
<desrt> i also added a retry mechanism
<desrt> we try to kill off all processes 5 times
<desrt> of course, we could have a D-state process that won't receive even SIGKILL
<desrt> so we can't retry forever...
<hallyn> right. seems to make sense to just go until there were no new tasks
<hallyn> whatever happened to the 'kill' cgroup
<hallyn> now on a well-setup systemd you should be able to freezer the freezer cgroup to prevent forks
<desrt> there is no cgroup-kill
<desrt> and apparently it was never planned
<desrt> which is kinda bogus.... seems like this would be the most useful feature of all
<desrt> "remove this cgroup... and its contents"
<desrt> anyway... gonna go back to hacking the shim now... should be done EOD
<desrt> having a hard time testing it, tho :/
<hallyn> desrt: no, cgroup-kill was discussed several times, think there was even code.  oh well.
<hallyn> desrt: timing sucks here.  but i can push a pkg with Prune and GetTasks Recursive today if it helps, but that seems to complicate things.
<hallyn> (but then again if i don't i did this for nothing :)  - nothing new there)
<desrt> so let me tell you what i'm doing
<desrt> or let me paste it :)
<desrt> http://paste.fedoraproject.org/131785/41018327
<desrt> http://paste.fedoraproject.org/131786/83298141/
<desrt> so basically, when i want to do an operation (Abandon, for example) on an existing scope ('session-1.scope' for example)
<desrt> i get cgmanager to enumerate the existing cgroups to me, under a particular path
<desrt> i now have a list of strings of cgroup paths
<desrt> i do this 'match' operation to find out which i should care about
<desrt> so for example /user.slice/user-1000.slice/session-1.scope and /user.slice/user-1000.slice/session-1.scope/other match "session-1.scope"
<desrt> so those go on my kill-list
<desrt> and i just iterate over this list, killing and removing
<desrt> until all such kills/removes are successful
<desrt> (or 5...)
<desrt> the 'enumerate' algorithm is sufficiently simple... make an array, add the root node, initialise an index to 0
<desrt> then as long as the index is less than the number of items in the array, enumerate the children of the item at the index and append them
<desrt> look ma... no recursion
<desrt> this is the one thing that it would truly help to have in cgmanager
<desrt> "list me off, recursively, all cgroup paths below X"  (where X is probably, for example, "user.slice")
<desrt> but again, i'm getting by OK without it
<hallyn> desrt: so in shim you only care about name=systemd.  that little nugget had escaped me.
<desrt> hallyn: ya... we've been using "all" in some places
<desrt> i honestly don't know enough about this stuff to know what is the right thing to say, so i mostly copied you :)
<hallyn> well you do want to delete the other cgroups 9and creat them),
<hallyn> stgraber: good morning - are you around?
<stgraber> hallyn: I am
<hallyn> stgraber: the methods i was adding to cgmanager over the weekend are now probably not going to be used by the shim.  So my q is whether you might need any of them, or if i shoul ddrop them.
<hallyn> 1. Prune - does a removeonempty followed by remove recursively,
<hallyn> 2. GetTasksRecursive - return a lis tof pids (for one, a set, or all controllers) for a cgroup and all its children
<hallyn> so 2. is my attempt tomake up for the fact that i can't safely do kill
<hallyn> though as i was saying earlyer this morning i'm a bit worried about giving all unpriv users one cgmanager call that will take o(nlogn) of cgmanager's time on number of pids they create
<hallyn> but it's probably ok
<cyphermox> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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: cyphermox
<hallyn> well i guess if sytemd-shim doesn't need it then i can take more time testing it and tweaking it
<desrt> hallyn: fwiw, the prune (with kill?) thing would be really great
<desrt> although it would only be truly useful if we had a way to tell it to do the matching of cgroup names for us
<desrt> like if we could tell it to kill all in .../session-1.scope/.../*
<desrt> because otherwise we need to enumerate the list of cgroups to _find_ the proper path for session-1.scope anyway
<desrt> so it doesn't save us much to not have to do that enumeration at the time of the kill
<desrt> since we already just did it...
<desrt> as it is, though, we get into some stupid territory with containers
<hallyn> desrt: i cannot do 'with kill' because it would provide a way for users to get aorund LSM kill restrictions (like yama)
<desrt> since we'll have to bounce all the way between the shim plus nested cgroup managers..
<desrt> preventing containers from killing their own children?
<hallyn> maybe i'm missing what you mean - but shim shouldn't care that it's in a container
<desrt> even as root?
<desrt> but when shim calls cgmanager inside the container, cgmanager will communicate with the cgmanager outside, no?
<hallyn> right,
<desrt> so we're jumping through a bunch of different levels...
<hallyn> (well, cgproxy)
<hallyn> right, but shim doesn't deal with those levels
<desrt> i know
<hallyn> ok
<desrt> but that doesn't change the fact that performance could be bad...
<desrt> anyway... not critical
<hallyn> desrt: well the performance of the chained dbus calls is already a hit, sadly
<hallyn> yeah i think for 15.04, unless we can do away with cgmanager,
<desrt> i sent an email to msm asking if i could be readded to the plumbers list...
<hallyn> i'll want to go back to tuning performance, and add some auditing for abuse (like one container taking too much cgmanager time)
<hallyn> cool
 * desrt should have just sucked it up in the first place
<stgraber> hallyn: nope, I don't think I need those for cgmanagerfs
<desrt> stgraber: i hope you're not spending too much time working on this :(
<stgraber> desrt: nope, so far I spent about 30min on the python prototype :)
<desrt> good
<desrt> hopefully we can kill it during plumbers :)
<stgraber> desrt: so there are a bunch of things which should make it possible to kill it, but they are rather complex kernel features (cgroup namespace + unprivileged mount of cgroupfs) and we'll need backward compatibility for a few years so regardless of what will happen in the next 3-4 kernel releases, we'll need cgmanagerfs for a few years
<hallyn> sigh.  and the gettasksrecursive worked out so nicely last night :)
<desrt> hallyn: add it anyway?
<stgraber> and the part of cgmanagerfs which provides meminfo, cpuinfo and stat will likely stay relevant for a while as the kernel folks made it pretty clear they don't want to make those files cgroup-aware...
<desrt> is there a way to get change notification from cgmanager?
<desrt> on creation/remove of cgroups?
<hallyn> desrt: it's either in the latest kernels, or on its way
<hallyn> not creation, i think just removal
<desrt> pah
<hallyn> (and when it's in the kernels, cgmanager will export an epoll interface for it)
<hallyn> yeah
<desrt> cgmanager is being unkind to me.
 * desrt tries upgrading
<desrt> so i keep getting "invalid request" in response to ListChildren
<desrt> any idea?
<desrt> disregard.  reboot fixed it.
 * desrt had old names in his cgroup tree
<mitya57> Mirv: sorry, I was not on IRC and read all your messages only now :P
<pitti> Riddell, doko: hmm, so what caused all these KDE autopkgtests to suddenly fail?
<doko> pitti, ?
<pitti> doko: that was more of a CC:, as they block the gcc upload
<pitti> I got 7 new "jenkins failed" regressions for ark, kfilemetadata, klettres, kcalc, etc., whose tests now all fail completely
<pitti> Could not find executable /tmp/adt-run.GXmatc/build.C6j/kcalc-4.14.0/obj-i686-linux-gnu/knumber/tests/knumbertest.shell
<pitti> did something recently changed in some common KDE build system tools?
<Mirv> mitya57: heh, I thought there was async communications going on ;) no problem, all resolved now.
<pitti> Could not find executable /tmp/adt-run.nVaQc4/build.b07/okteta-4.14.0/obj-i686-linux-gnu/kasten/controllers/customtostringtest.shell
<pitti> Riddell: all the failures look fairly similar, like that ^ like the test isn't being built any more
<doko> yep, always some "shell" which is missing
<doko> pitti, afaics the autopkg tests don't build, only run the test (at least ark)
<pitti> doko: hm, I wonder how they previously passed then?
<pitti> ark has a fairly spotless record until now (https://jenkins.qa.ubuntu.com/job/utopic-adt-ark/)
<pitti> and the log also shows that it builds the entire package
<pitti> I think pretty much all KDE packages do that (first build, then run the built tests)
<slangasek> pitti: so why did daily boot testing with upstart fall off the core-1403-systemd-transition workitems?  Wasn't the intention here to make sure both were tested so that a) we could ensure we weren't regressing upstart boot during the transition to systemd, and b) we could tell if a boot regression is init-specific or not?
<pitti> slangasek: ah, I removed it as the desktop/server ones on http://ci.ubuntu.com/smokeng/utopic/ already do that
<pitti> slangasek: or http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/Smoke%20Testing/ (ci.u.c. is a little slow today, at least for me)
<slangasek> ah, ok
<pitti> slangasek: so we've always had daily testing with upstart already
<slangasek> so this is "done" rather than "dropped" :)
<pitti> slangasek: well, "retroactively done" if you will
<pitti> slangasek: I first tried to add systemd tests to our daily image smoketesting, but that opened a can of worms
<pitti> slangasek: and as UTAH is going away, I don't think we should spend much time trying to fix that; ev rather suggested to run those in autopkgtest
<pitti> doko: hm, I wonder how they previously passed then?https://jenkins.qa.ubuntu.com/job/utopic-adt-systemd/126/ARCH=amd64,label=adt/
<ev> +1
<pitti> err, X clipboard, don't mess with me
<pitti> slangasek: so here they are: https://jenkins.qa.ubuntu.com/job/utopic-adt-systemd/126/ARCH=amd64,label=adt/
 * ev is in favour of anything that brings consistency to the way we drive tests
<pitti> doko: sorry, paste error
<ev> the fewer ways we have to run tests, the more tests we can run
<pitti> the new "boot_and_services" reboots with systemd, and ensures that lightdm, NM, etc. all start
<pitti> there's a lot more which I want to add there, but those are the most basic things
<tedg> hallyn, desrt, curious what the status of the cgroups systemd-shim patch is
<desrt> tedg: testing out a few issues still
<desrt> but it's mostly there
<tedg> Cool, great.
<tedg> A today thing?
<desrt> a by-tomorrow-morning thing, certainly
<desrt> abandon (which is the default) is working at least
<desrt> but i'm having some issues with the kill-all-the-things stuff
<tedg> Okay, I'll plan on testing/trying to land the UAL tomorrow afternoon then. Give that a change to move through the phases of packaging/etc.
<slangasek> pitti: ah, so these are autopkgtests now, does that mean we have nested KVM working reliably for adt?
<pitti> slangasek: no, I haven't touched that since I played around with that, nested KVM was a disaster back then
<pitti> that was mid-trusty, perhaps it got a lot better since then
<pitti> but as clouds usually don't have the very latest kernel/qemu, I think it'll still be a while since we can do that
<pitti> slangasek: we run autopkgtests in temporary VMs on bare metal right now
<pitti> slangasek: and in the new airline we'll create temp cloud instances and run the tests in them directly, then tear them down again
<slangasek> hmm
<slangasek> so do you get console off of the VM via cloud APIs?
<pitti> slangasek: ah, no; the current test is modifying the grub config to append init= and then reboots
<slangasek> ah, ick
<pitti> slangasek: as soon as we land the last bits from bug 1351306 I'll switch that to systemd-sysv
<ubottu> bug 1351306 in ubuntu-app-launch (Ubuntu) "Cannot uninstall upstart and install systemd-sysv" [Undecided,In progress] https://launchpad.net/bugs/1351306
<slangasek> so you aren't booting under a test harness
<pitti> slangasek: well, the entire VM is the test harness
<pitti> slangasek: in teh CI airline we should eventually run those under a full desktop install, not a minimal VM
<slangasek> yes, and you just said you're rebooting that VM
<pitti> right
<slangasek> so, ick :)
<pitti> slangasek: and relying on autopkgtest's timeouts
<pitti> slangasek: and yes, ick :)
<slangasek> better than nothing, but a long way from where I think we should be
<pitti> we don't have a better deployment of testbeds yet unfortunately
<pitti> slangasek: long way> oh yes
<pitti> slangasek: well, at least we stopped running the test controller inside the VM long ago
<pitti> which helps quite a bit to reduce assumptions and increase test stability
<pitti> so the main issue is that the VM doesn't reboot enough, and thus adt-run will time out
<pitti> s/that/if/
<pitti> slangasek: but even if the UTAH based tests would get along with reboots, it would essentially be the same? they also just fire off a VM and wait for it to come back
<slangasek> pitti: nothing I've said should be interpreted as an endorsement of UTAH
<slangasek> pitti: I've been asking ev for proper boot-under-test for over a year ;)
<pitti> slangasek: how would that look like in a cloudy env?
<pitti> slangasek: getting serial consoles, something of that sort?
<pitti> ssh is arguably quite a strong assumption; we don't need it in the current adt runners (only a ttyS1 shell), but we will need it with the CI airline (at least right now)
<pitti> as that uses cloud VMs whose primary (and only?) interface is ssh
<slangasek> pitti: it would require full console output from the VM, /not/ ssh
<pitti> slangasek: yeah, cloudy ttyS0 would rock
<desrt> hallyn: hey.. having some trouble with RemoveOnEmpty
<hallyn> desrt: how so?
<desrt>     member -> 'RemoveOnEmpty'
<desrt>     signature -> signature 'ss'
<desrt>   Body: ('all', 'user.slice/user-1000.slice/session-29.scope')
<desrt>   UNIX File Descriptors:
<desrt> returns OK
<desrt> but now i see
<desrt> root@velocity:~# cat /sys/fs/cgroup/systemd/user.slice/user-1000.slice/session-29.scope/tasks  | wc -l
<desrt> 0
<desrt> ie: RemoveOnEmpty was called, and there are no tasks, but the group is still here
<desrt> other than that, everything actually seems to be working fairly nicely
<ev> pitti: cloudy tty0, `nova console-log`?
<hallyn> desrt: that's what i was saying last week to explain my shim code.  removeonempty sets it so it'll be reomved the next time it *becomes* empty
<desrt> curious.
<desrt> Abandon should still be called while there's something in there, though, no?
<desrt> i guess not...
<desrt> so after i set RemoveOnEmpty, try a remove, i guess?
<hallyn> desrt: sure
<hallyn> yup
<desrt> this is a bit crap :(
<hallyn> what Prune does is removeonempty, then work on all the child subdirs, then remove
<hallyn> it may be too closely tied to the way the kernel does it,
<desrt> might be nice if cgmanager took care of this little detail
<hallyn> but since the kernel will be changing soon, i prefer that to adding too much magic
<hallyn> it will, with prune
<desrt> well, let's get this working first...
<desrt> it's pretty much there now
<hallyn> desrt: no, consider the way shim's been using removeonempty until now
<pitti> ev: oh, that's just that? trÃ¨s awesome :)
<hallyn> it creates, calls removeonempty, then moves takss into there
<hallyn> if it immediately removed that wouldn't work :)
<desrt> hallyn: true :)
<pitti> ev: I figure that's read-only, but it's mostly for getting early debug logs on failure anyway, which is sufficient
<ev> yeah, it is read-only
<ev> cool
<smoser> hey. wonder if someone could give some thought to
<smoser>  f. write updated ata to /var/lib/cloud/data/status.json
<smoser>  e.
<smoser> bah.
<smoser>  https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1366893
<ubottu> Launchpad bug 1366893 in cloud-init (Ubuntu) "cloud-init --local needs mounted /run but not guaranteed by upstart job" [Undecided,New]
<smoser> my current thinking is just this:
<smoser>  http://paste.ubuntu.com/8292135/
<smoser> but i dont know if that could cause some issues.  in a initramfs boot, /run is aleady mounted (but that seems ok in testing). in lxc container, it seems that should ensure it.
<smoser> jodh, i wonder if you're around and have thoughts.
<desrt> hallyn: i've pushed a new branch called wip/abandon
<desrt> contains 10 patches
<desrt> https://github.com/desrt/systemd-shim/commits/wip/abandon
<desrt> it seems to work, more or less
<desrt> i've even tested manually calling StopUnit on some session scopes to verify that the session gets killed off
<hallyn> desrt: cool, fetched the tree, will take a look after lunch during slow bisect runs
<desrt> the first 5 or so are really trivial
<desrt> the next few are more complicated changes to support the coming work
<desrt> and the last one is the big one, but because of the ones before, is almost purely additive
<Mirv> is it just me or sudo apt update claiming all public keys are missing? (on utopic)
<bdmurray> slangasek: do you know if the test case for bug 1274466 is different for Trusty?
<ubottu> bug 1274466 in apt (Ubuntu Trusty) "apt-ftparchive on-disk cache format changed between lucid and precise, results in Packages files with silently corrupted checksums fields" [High,Fix committed] https://launchpad.net/bugs/1274466
<slangasek> bdmurray: hmm, should be the same test case but with s/precise/trusty/
<bdmurray> slangasek: so with one generated from lucid?
<kdub> is there a list of currently uninstallable packages somewhere?
<smoser> slangasek, ^ do you think it seems reasonable to do http://paste.ubuntu.com/8292135/ (bug 1366893 above)
<ubottu> bug 1366893 in cloud-init (Ubuntu) "cloud-init --local needs mounted /run but not guaranteed by upstart job" [Undecided,Confirmed] https://launchpad.net/bugs/1366893
<slangasek> bdmurray: yes, still needs to use lucid as the baseline
<slangasek> smoser: looking
<slangasek> smoser: have you tested this?  If memory serves, the 'mounted' events are serialized within mountall, and you won't see a second mounted event until the first one clears... which would mean this deadlocks
<smoser> slangasek, hm.. well it works in kvm , where an initramfs loaded /, so /run is mounted already.
<smoser> and it worked at least in my tests on lxc
<smoser> but that could just be lucky
<smoser> and i dont want to rely on /run being mounted out of initramfs
<slangasek> ok
<smoser> you have other suggestions ?
<slangasek> it's strange that we would ever see the mounted event for / before the one for /run fwiw
<smoser> it almost always happens.
<slangasek> I thought the ordering of the events was guaranteed
<smoser> 9/10 times in lxc.
<smoser> ish
<slangasek> hmm
<slangasek> so what does it need / mounted for?
<slangasek> should it be *just* 'on mounted MOUNTPOINT=/run'?
<slangasek> or is this the component that does things like installing extra packages?
<slangasek> oh... no, now I remember, 'mounted' events can happen in parallel, but the class-based events (e.g. 'local-filesystems') won't be emitted until the 'mounted' events finish
<slangasek> smoser: so I think this is ok
<smoser> oh yeah, we fixed it
<smoser> you did
<smoser> so that events could happen in parallel
<smoser> slangasek, https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/643289 i think that was it.
<ubottu> Launchpad bug 643289 in nfs-utils (Ubuntu Precise) "idmapd does not starts to work after system reboot" [High,Triaged]
<bdmurray> slangasek: hmm, the command in the test case isn't doing anything for me...
<slangasek> bdmurray: ok; I don't think I've validated the correctness of the test case
<bdmurray> slangasek: okay, I'll email mvo
<alex-foo> LLVM 3.5 now requires you use C++11 when linking against it. due to STL incompat between C++11 and C++98 (e.g. std::pair layout changed), it's not safe to mix code that uses C++11 and C++98. does anyone know how distro maintainers plan to work with this? will everything C++ have to be compiled with -std=c++11 now?
<slangasek> alex-foo: I'm not sure what the issue is you're concerned about; we don't build the distro with LLVM
<xnox> alex-foo: we are not switching to c++11 standard by default, but some packages use c++11 ABI already, but they are careful enough to use that for other dependencies as well.
<alex-foo> slangasek: any package in the archives that links against LLVM 3.5 or newer (even if it builds with GCC) will need to be built with -std=(gnu|c)++11
<alex-foo> xnox: i don't see how that will work -- will we parallel install C++11 and C++98 builds of every dependency? like 32 vs. 64 bit parallel installation?
<slangasek> $ reverse-depends -b llvm-3.5
<slangasek> No reverse dependencies found
<slangasek> $ reverse-depends -b llvm-3.6
<slangasek> No reverse dependencies found
<alex-foo> 3.5 was released last week
<slangasek> so "any package in the archive" == "no packages in the archive", currently
<alex-foo> try 3.4 or 3.2
<xnox> alex-foo: 3.4 is our current default. No we do not ship both 98 & 11 variants.
<xnox> alex-foo: we have some libraries that have been using unstable 11 abi, but they are build with gcc and have bumped their soname when moving between abi incompatibilities in e.g. gcc 4.8 and 4.9.
<alex-foo> GCC 4.8 and 4.9 had ABI incompat?
<slangasek> yes; the C++11 ABI is still marked experimental in gcc
<alex-foo> ah of course, sorry i thought you were talking about the ABI in general, not the C++11 one.
<alex-foo> so what reverse-depends llvm-3.4?
<slangasek> AFAICS, only ghc
<slangasek> oh, and yrmcds
<xnox> alex-foo: there is no abi incompat with llvm-3.4.... for things that compile with 98 standard, when things move to 11 standard, or llvm-3.5 they'd need to bump their soname.
<alex-foo> but in general, this will be a problem for any library that requires C++11 going forward
<kdub> I can't seem to install crossbuild-essential-armhf on utopic, is this something that should have a bug?
<xnox> slangasek: $ reverse-depends -b src:llvm-defaults; $ reverse-depends -b src:llvm-toolchain-3.4
<slangasek> xnox: so the clang revdeps are also relevant?
<xnox> slangasek: yes, (abuse) of transitive dep
<slangasek> ok
<slangasek> in that case, there are a few for 3.5 also (creduce, feel++)
<xnox> kdub: (a) do you have armhf arch enabled in dpkg? (b) do you have armhf ports archive enabled in apt sources ? (c) do you have proposed disabled?
<alex-foo> e.g. Qt now builds with C++11 by default since 5.x IIRC, at some point in the future it will lose C++98 support
<kdub> xnox, i haven't /enabled/ proposed if thats something you have to do
<xnox> kdub: i'd like you to check and verify all three things. if all three are good, then I'd start looking if there is something worse going on.
<kdub> xnox, ack, thanks
<xnox> alex-foo: honestly, not a problem... note we are not moving to c++11 by default in utopic, nor are we moving to 3.5, and we are aware of the issue and have mitigated it successfully and our stable releases are abi consistent for given sets of packages.
<xnox> alex-foo: if you have a developer / user queries you might find #ubuntu-appdev and or #ubuntu support channels for those. There is also askubuntu and ubuntu-devel-discuss mailing list.
<alex-foo> xnox: you have mitigated all of this? and are confident about the situation? https://gcc.gnu.org/wiki/Cxx11AbiCompatibility
<xnox> alex-foo: if there is any particular packages that are broken as build in ubuntu, please open a bug demonstrating e.g. a crash against those individual packages. I assert that packages in ubuntu both development and stable releases are fine. If there are any that regressed in this sense, it's a bug.
<xnox> alex-foo: have you found a buggy package / miss-built?
<alex-foo> xnox: no but it's straightforward to construct
<alex-foo> xnox: i don't actually use ubuntu, i'm just interested in how packaging systems are addressing (or not addressing) this issue
<xnox> alex-foo: yes, one can construct broken binaries that's easy - i'm asking if you found broken binaries as shipped by ubuntu.
<xnox> alex-foo: on packaging we are addressing it with automated as installed testing, abi versioning our library packages, and staying on 98 abi by default for now and only careful test and investigate 11 abi usage where required.
<xnox> alex-foo: btw, that was not the question you originally asked. In essence, standard ubuntu & debian development practices are used to track this ABI break just like any other one we had.
<alex-foo> what other ABI break is this comparable to?
<hallyn> desrt: so your g_ptr_array_foo wizardry is beyond me :)  but it seems to me you don't want to do enumerate_paths() on user.slice.  if two users are logged in with lots of nested containers you'll collect the others' paths just to discard them.  is there any reason not to just enumerate_paths() on user.slice/user-$uid.slice?  oh right, you didnt' have a good way to find the second part of that did you...
<hallyn> certainly better than nothing though, a fine way to get it out the door.
<hallyn> i'm tempted to say i'll release 0.32 with prune and gettasksrecursive so you can use those, but debian uploads tend to take a week
<hallyn> (mainly bc i suck)
<desrt> hallyn: i also had another consideration...
<desrt> there is nothing to stop the other user from creating scopes with names like session-nn.scope, right?
<desrt> we might find those...
<desrt> and we have no real good way of knowing which scope is the one we created
<desrt> i start to think that this idea about having a file in /run is the best one after all
<hallyn> true
<desrt> what we have now will certainly work though
<hallyn> well, not relaly,
<desrt> unless users start doing 'interesting' things
<hallyn> the user cannot create cgroups under user.slice/user-1000.slice himself?
<hallyn> yeah he can, nm
<desrt> did the current set of patches work for you, in any case?
<hallyn> i only looked at them, didn't test them.
<hallyn> i'm pushing cgmanager 0.32 to debian in af ew mins, just building a new symbols list
<desrt> sure thing, knuth :)
<hallyn> sorry i didn't think you were at a ready-to-test point, i can build in a few mins though
<desrt> i think i'm going to try my hand at the run thing next...
<desrt> i guess i didn't appreciate the extent to which you wanted unpriv'd containers to be able to whip up arbitrary cgroups
<hallyn> yeah we're mad-men
<hallyn> hm, just madmen
<hallyn> ok, pushing 0.32-1 to mentors.debian.net and 0.32-1~testing1 to ppa:serge-hallyn/virt
<hallyn> make that 0.32-1~ubuntu1
<desrt> about to step out for dinner
<desrt> i'll see if i feel like looking at the /run file thing when i come home
<desrt> otherwise, i'll poke it tomorrow morning
<hallyn> desrt: ok.  maybe i'll see if i can convert your code to using the new cgmangaer methods just for my own education (and *maybe* to be useful later)
<desrt> :)
<desrt> i agree that it would be nice to get rid of that "give me ALL the things!" approach i have now
<hallyn> xnox: would you have time for a debian cgmanager package upload review/sponsor?
<hallyn> (i understand if not :) - thx for the previous help)
<hallyn> desrt: should also help me ifnd any bugs which my testcaseds missed :)
 * alex-weej waves at desrt
<desrt> alex-weej: hey... long time no see :)
<desrt> what're you up to these days?
<alex-weej> C++ and Qt. I know, right.
<desrt> i've heard this story before ;)
<xnox> hallyn: yeah.
<hallyn> desrt: good news, scopes are going away :)
<desrt> in systemd?
<desrt> oh
<hallyn> oh wait, i should reboot
<desrt> you mean on your system :)
<hallyn> yeah i forgot my session is already removeonempty
<desrt> i thought you meant that scopes were going to stop being a thing :p
<desrt> anyway... i gotta run
<hallyn> oh - lol :)
<desrt> let me know what you find
<hallyn> will do - ttyl
<hallyn> still working
<hallyn> xnox: hm, there's a bug in cgmanager.Prune, so not sure if 'yeah' meant yeah you have time to review or yeah you're to busy, but i guess it's not ready yet :(
<hallyn> unless i'm using the wrong code, hm
<jtaylor> someone fancy helping me with some grub debugging?
<cjwatson> jtaylor: depends how complex it is (working around children's bedtime)
<jtaylor> grub is complaining the gpt partition contains no bios boot partition, it works fine from 14.04 but not 14.10
<hallyn> xnox: oh, disgregard, it was my systemd-shim patch that was wrong
<jtaylor> if you don't know the answer right now don't bother, I can work around it and try again later
<cjwatson> jtaylor: copy and paste the error message please?
<jtaylor> this gpt partition label contains no bios boot partition; embedding won't be possible
<jtaylor> but this is required for raid and lvm install
<TJ-> jtaylor: Does the GPT have an EF02 type partition?
<cjwatson> jtaylor: what does parted say?
<cjwatson> EF02 isn't a GPT type
<cjwatson> GPT partition types are GUIDs
<cjwatson> EF02 is a gdiskism
<hallyn> desrt: so github.com/hallyn/systemd-shim #serge/abandon3 adds a bone-stupid per-scope /run-file and uses cgmanager:Prune for Scope.Abandon
<jtaylor> parted say about what?
<TJ-> jtaylor: "sudo parted /dev/sda print" - does it list a "BIOS boot partition", or does "sudo gdisk -l /dev/sda" show a "Code" EF02 partition?
<jtaylor> no bios no EF02
<jtaylor> cde 8300
<jtaylor> urg I thought it would work from 14.04 but that now fails too
<jtaylor> weird
<TJ-> jtaylor: That's the problem then; system is booted in EFI mode but the GPT has no BIOS boot partition. Previously the system must have been booting in CSM/Legacy mode
<jtaylor> so its due to the way the installer booted?
<jtaylor> hm installed grub on a partition with msdos partition table that worked
<jtaylor> doesn't find 14.10 though, I'll figure it out mysef, thanks
<infinity> pitti: Around?
<hallyn> desrt: and another patch pushed to github.com/hallyn/systemd-shim #serge/abandon3 to do stopunit using cgmanager:GetTasksRecursive - with the warning that there's a segv in that cgmangaer that i need to fix
<shadeslayer> doko: poke
<shadeslayer> doko: what can we do about https://bugs.launchpad.net/sqlite/+bug/1317449
<ubottu> Launchpad bug 1317449 in sqlite3 (Ubuntu) "sqlite3 version 3.8.2 breaks digikam" [Undecided,Confirmed]
<infinity> shadeslayer: If 3.8.2 is broken and 3.8.4 fixed the issue, can we hunt down the commit(s) that fixed it via bisection or similar and do a targetted cherry-pick SRU?
<infinity> shadeslayer: I'm not keen on the idea of just updating sqlite wholesale to a new upstream version because people say that's the fix.
<shadeslayer> infinity: me neither, but I'm not exactly a expert at sqllite, someone who's a bit more knowledgable in this area needs to look at this
<infinity> shadeslayer: Well, the beauty of bisection is that one doesn't generally need to be an expert.
<infinity> shadeslayer: It's just build, test, build, test, until you find the commit that fixed it.  Cherry-pick that (and dependencies, if needed), test again, and done.
<infinity> This is all assuming sqlite is in a VCS that isn't from 1991.
<infinity> Or a VCS at all.
<infinity> Maintained in Fossil... That's a new one to me.
<hallyn> desrt: i didn't even bother getting indentation right so assume yo'ull be re-writing it, but both Stop and Abandon seem to be working with my branches.  back to libvirt
<cjwatson> It's a VCS not from 1991, just from a parallel universe instead
<cjwatson> Stores content in SQLite, so guess why SQLite uses it ;-)
 * sarnold *boggle&
<infinity> shadeslayer: I suppose a good place to start would be to see if the handful of post-release commits on the 3.8.2 branch (well, the non-win32 ones) relate:
<infinity> http://www.sqlite.org/cgi/src/timeline?r=branch-3.8.2
<infinity> shadeslayer: A good reproducer for someone who's never used digikam wouldn't go amiss either, in case someone wanted to jump in and be helpful with the bisection/fixing, but has no idea how to make it crash in the first place. :P
<infinity> cjwatson: I guess one could choose a worse disk format, though I can't fathom why anyone would want to interact with their VCS via SQL as an interface.
<bigon> hey guys, I've a question about apport, under ubuntu how is apport-gtk called when a program segfault?
<bigon> I understand that apport itself is called and generate a report in /var/crash
<infinity> cjwatson: I suppose I could see it leading to clever third-party shortcuts where one can easily write web UIs and such without the VCS tool, just directly abusing the data.
<infinity> Either way, weird.
<bigon> but how is the gui called for the user?
<infinity> bigon: Via update-notifier, I believe.
<infinity> bigon: And a quick perusal of the code confirms my suspicion.
<cjwatson> infinity: Does it actually expose the SQLiness, or is it just a backend format?
<bigon> thx
<infinity> cjwatson: Well, libsqlite would expose SQLness, if you chose to use it to look at the Fossil data store, which is where it would become interesting, I guess, cause you could skip Fossil entirely to interact with it.
<cjwatson> infinity: Well, yeah, I just mean that if it's not in the UI then it's just a choice to avoid having to write all your own data store.
<infinity> cjwatson: Unlike, say, git, where people have had to write third-party libgit implementations to avoid the git CLI.
<cjwatson> Yeah, true.
<jtaylor> hmm cpu scaling is kernel buisness or?
<jtaylor> 14.10 is running my cpu at 800 mhz under full load ._.
<sarnold> jtaylor: "it's complicated" -- there's multiple kernel cpu scheduling governors and then there's multiple thermal management things interacting. it's far more complicated and involved than it used to be
<infinity> jtaylor: /proc/cpuinfo also doesn't give the whole story terribly well, since the scaling is up and down far more often than you poll.
<jtaylor> cpufreq stats: 3.20 GHz:7.18%, 2.50 GHz:4.95%, 2.10 GHz:5.61%, 800 MHz:82.26%
<jtaylor> and its noticable, as soon as I start 4 yes the UI gets terribly slow
<infinity> jtaylor: Using ondemand or intel_pstate?
<infinity> jtaylor: If ondemand, you might want to try installing thermald and booting with 'intel_pstate=enable' on your cmdline and see if that happies it up any.
<jtaylor> its an amd
<infinity> Oh.
<infinity> Then nevermind. :P
<jtaylor> it seems to be ondemand, didn't change anything, fresh install
<jtaylor> I guess some kernel bisecting can't harm, tomorrow
<infinity> Right, ondemand should be the right thing on an AMD CPU.  It's possible some thresholds could be tweaked a bit to back off less aggressively and favour speed over power.
<jtaylor> mh /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq being 800mhz can't be right?
<sarnold> heh
<sarnold> reminds me of m old g3 laptop... 800 was 'fast', 300 was power saving :)
<slangasek> desrt: any news on systemd1.Scope/Abandon?
<infinity> sarnold: 800 *was* fast!
<infinity> jtaylor: Seems a bit wrong to me.
<infinity> jtaylor: But also doesn't add up with "cpufreq stats: 3.20 GHz:7.18%"
#ubuntu-devel 2014-09-09
<jtaylor> its weird
<jtaylor> the system works alright until I fully load it, as if it does the opposite of what it should
<sarnold> infinity: oh yeah, definitely, the first one I had was 700 mhz, but several cracked motherboards later, I got the 800 mhz version :) woohoo, speed demon
<infinity> sarnold: I have a 1GHz G3-class (IBM PPC750) that's still a speed demon, really.
<infinity> sarnold: And that CPU is now 15y old or something...
<sarnold> infinity: hehe, older server gear is still impressive :)
<infinity> sarnold: It's not server gear, it's a Beige Apple G3 tower with a (seriously) upgraded CPU. :P
<sarnold> infinity: really??
<infinity> sarnold: And the CPU itself is actually the low power embedded version of the PPC750, so despite being 15y old, it's pretty efficient.
<infinity> sarnold: Can't say the same for the ancient hard drive in it, though, should probably replace that.
<sarnold> infinity: heh, 80-conductor pata? or 40 conductor? :)
<sarnold> oh wait, were they still in their scsi stage then?
<infinity> sarnold: The drive is 80-conductor era, just barely.  1st gen 66 or 133, don't recall now.
<infinity> sarnold: The part where the label says "Quantum" probably says something.
<infinity> I miss Quantum. :(
<infinity> I'm not sure I'll ever forgive Maxtor for that buyout.
<infinity> sarnold: I'm not sure if it was Maxtor buying out Quantum, or Compaq buying DEC, but somewhere in that area, I gave up on the idea that "server kit" would ever be anything more than whitebox PC junk with a pretty case and a longer warranty.
<infinity> ... and here we are today.
<sarnold> infinity: *sniff* quantum
<sarnold> infinity: but there's still something to be said for ecc ram, hehe
<infinity> sarnold: Back in my day, we didn't need ECC RAM, we just made computer cases out of lead.
<sarnold> infinity: muahahaha
<jtaylor> seems to be thermald messing around, my temperaturs are fine ._.
<infinity> jtaylor: thermald shouldn't do anything at all on non-Intel kit.
<jtaylor> too bad its logfile is not really readable
<jtaylor> I'll have a deeper look tomorrow, bye
<doko> Riddell, ScottK, pitti: was there any idea about the recent KDE autopkg test failures?
<ScottK> doko: Taking a quick look at ark, the current version passed previously and now it complains about not being able to find executables.  That smells of a linker change somewhere.
<doko> ScottK, but according to the autopkg test log, the package builds sucessfully ...
<doko> I'm fine to search things, but I can't see where I should look
<doko> barry, I'm not ok with tox and pip in main.
<barry> doko: suggestions welcome, but i'm not removing the build-dep on tox
<doko> barry, keep it in universe
<barry> doko: isn't that a problem for seeding system-image?
<doko> barry, then we don't see it
<doko> seed it
<barry> doko: right now it's only needed for touch.  maybe someday it will be needed for server or desktop
<doko> barry, you have to explain why tox is needed to test
<doko> the test environment is clearly defined by build dependencies or autopkg test dependencies. so there is no need to use a virtual env
<barry> doko: why no tox or pip in main?
<doko> barry, I don't care about tox, if you remove pip as a dependency. and I answered that in a bug report already. upstream systems like this are a pain to maintain. we see this with rails, and we keep maven in universe for a reason
<barry> doko: well, i'll sleep on it
<desrt> slangasek: it's done as far as i'm concerned
<desrt> slangasek: although it looks like hallyn has pushed some extra patches to improve efficiency by making use of new cgmanager features
<tedg> pitti, The adt test for dbus-test-runner failed. I'm not quite sure why.
<tedg> pitti, There seems to be some PID giving a signal 15.
<tedg> pitti, How do I recreate that?
<tedg> I don't think I have any autopkg tests.
<pitti> Good morning
<pitti> infinity: I am now
<pitti> bigon_: some user session upstart job calls /usr/share/apport/apport-gtk (without args) when there's new files in /var/crash
<pitti> doko: I haven't heard back about the KDE failure galore
<pitti> tedg: "some pid" getting sig 15 is certainly QEMU when adt-run shuts it down, that's perfectly normal
<pitti> tedg: "ERROR: testbed failed: timed out"
<pitti> tedg: so apparently something hung forever in the test; I'll try and rerun it, if that doesn't help it needs to be debugged more thoroughly
<pitti> tedg: you can run locally with http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test
<Unit193> pitti: I don't suppose I could interest you in a very simple upload to Debian (small bugfix) and sync to Ubuntu could I? :)
<pitti> Unit193: if it's a package I can upload (i. e. sponsor or I'm a maintainer), sure
<Unit193> pitti: Yeah, it's a QA upload, I put unversioned breaks in a transitional package by mistake: http://mentors.debian.net/package/samdump2
<ScottK> pitti: For the KDE stuff, what I checked had previously passed without being changed.  Most of the Kubuntu people are at Akademy (annual KDE conference) this week, so less likely than usual to be responsive.
<ScottK> Somehow, I think it's not our fault though.  No idea where to start though.
<pitti> mvo_, cjwatson: FYI, recent click regressed its autopkgtest and is stuck (anonymous upload notification forward :) )
<pitti> tedg: re-run still hangs
<bigon_> pitti: ok thank, update notifier has some code for it too
<pitti> Unit193: "Bug #760723 does not belong to this package" -> needs some reassignment?
<ubottu> bug 634680 in software-center (Ubuntu) "duplicate for #760723 update-software-center crashed with EOFError in <module>()" [High,Invalid] https://launchpad.net/bugs/634680
<Unit193> pitti: There used to be a source package of the same name, but that's against the binary package of samdump2.
<pitti> Unit193: ah, ok; uploading
<Unit193> pitti: Thank you very much!
<pitti> no worries, thanks for the fix
<mvo_> pitti: thanks, I have a look
<darkxst> pitti, is the current adt cloud image broken? I can't run any autopkgtests locally atm. http://pastebin.com/3Eq8WNYU
<pitti> darkxst: I had that a few days ago (some uninstallability problems), but works again with recent images
<didrocks> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: cyphermox, didrocks
<darkxst> pitti, I am getting it with todays image
<dholbach> good morning
<didrocks> morning dholbach
<dholbach> salut didrocks
<dholbach> comment Ã§a va?
<didrocks> Ã§a va plutÃ´t bien, il fait chaud ! et toi ? :)
<dholbach> trÃ¨s bien aussi :)
<mvo_> pitti: when I try to reproduce the failure in the autopkgtest for click I run into http://paste.ubuntu.com/8297301/
<mvo_> pitti: is that a known issue?
<pitti> lxc-clone: unrecognized option '--name'
<pitti> Error: container adt-utopic is not defined
<pitti> mvo_: silly question, but do you actually have an adt-utopic container?
<pitti> mvo_: also, did you run with "lxc -es"?
<pitti> the pastebin doesn't show your command
<mvo_> pitti: lxc-ls tells me I have adt-utopic
<pitti> mvo_: so the next common error is to forget the -s, so that it runs lxc as user (and thus expects user containers, not system containers)
<mvo_> pitti: thanks! the warning about --name is still there, but now it seems to work, thanks a bunch. would you mind me doing a patch that warns if uid != 0 and no -s ?
<mvo_> pitti: so that the clueless^Wfogetfull^Wpeople get a hint :) ?
<pitti> mvo_: that and "there is no user-level container of that name"
<pitti> mvo_: not sure about the --name warning; that looks like an lxc buglet
<pitti> mvo_: you can have per-user containers in utopic, so it should not warn about those
<mvo_> pitti: *nod*
<jtaylor_> hm how do I disable a daemon from starting in upstart? I'd googe it but a modern browser is no fun  to use with the cpu set to 800mhz :(
<jodh> jtaylor: echo manual >> /etc/init/$job.override
<jtaylor> thanks
<jtaylor> ah sweet performance bliss :D
<mvo_> pitti: so my adt-lxc gives me a very different error, is the lab using adt with the kvm backend? whats the best way to recreate this backend?
<mvo_> pitti: and sorry for my silly question, I feel like I asked them before :/
<pitti> mvo_: yes, we use qemu in the lab -- but that shoudn't matter for something like click?
<pitti> mvo_: http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test is what we use in teh lab
<pitti> mvo_: can you put the log into a pastebin?
<mvo_> pitti: it shouldn't no, but - the lab test fails with "ImportError: Start directory is not importable: 'click.tests.integration'" before it even runs the tests - but let me see, I have some ideas
<pitti> mvo_: what exactly did you run?
<mvo_> pitti: thanks for the link I will bookmark it
<pitti> mvo_: i. e. did you actually test the proposed package?
<mvo_> pitti: yeah, I think that is the problem, I was running against the bzr tree
<pitti> adt-run click -U --apt-pocket=proposed --- lxc -es adt-utopic
<pitti> mvo_: that ought to reproduce it
<pitti> mvo_: you can also add a -s (--shell-on-failure) to examine
<mvo_> pitti: thanks a lot!
<mvo_> pitti: that is super helpful
<pitti> mvo_: https://people.debian.org/~mpitt/autopkgtest/README.running-tests.html FYI :)
<pitti> mvo_: these are also in /usr/share/doc/autopkgtest/
<mvo_> pitti: nice, thanks, I will remember that
<Saviq> dbarth, hey, can you come to #ubuntu-release please
<infinity> pitti: Hey, was wondering if you had any insight into the two autopkgtests that are preventing unity8's migration.  Both of them install a bunch of deps, and then say "dep installation failed", with no real meaningful debug output.
<infinity> pitti: And, of course, I can't reproduce anything that looks like a "failure" locally.
<pitti> infinity: (in meeting, coming back to you in a bit)
<infinity> pitti: S'ok, I'm going to bed, I just wanted to hand it off to someone who knows adt and the infra and might be able to sort out WTF. :P
<darkxst> infinity, I am getting similar failures locally (on different packages), that don't seem to be reproducing on jenkins ;(
<pitti> infinity: tehre were some uninstallable packages for some tests (see the apt problem resolver output)
<didrocks> dholbach: hey, do you know why https://code.launchpad.net/~canonical-platform-qa/dialer-app/qmltests1/+merge/233130 is on the sponsoring list? Seems a pure upstream dialer-app thing
<seb128> didrocks, because ubuntu-core-dev is in the reviewers list
<seb128> didrocks, it's there because they are packaging changes and that's what the CI documentation recommends doing, "get review from somebody with upload rights"
<didrocks> seb128: yeah, we traditionally don't add core-dev for that, we have the LT with people having upload rights for it, but let's do the review
<seb128> didrocks, right, I'm just explaining why it's there (I asked them before iirc)
<didrocks> seb128: weird that it starts to count as sponsoring, as when I was reviewing almost all packaging change for touch, those wouldn't count at all as a patch pilot shift :)
<seb128> didrocks, I don't think it "starts to count"
<seb128> didrocks, it's just that $somebody didn't know how to get a review and subscribe core dev
<seb128> subscribed
<didrocks> yeah, probably
<seb128> didrocks, I'm not sure it's an official/recommended workflow
<GunnarHj> didrocks: Hi Didier!
<GunnarHj> cyphermox_: ping?
<ScottK> barry: Please see some of the later comments on Bug 1290847.  You are going to do this for Trusty, right?
<ubottu> bug 1290847 in python3.4 (Ubuntu) "pyvenv fails due to mising ensurepip module" [Undecided,Fix released] https://launchpad.net/bugs/1290847
<didrocks> GunnarHj: hey, what's up? :)
<GunnarHj> didrocks: See that you are piloting. Any chance that you can give these, involving trusty SRUs, some attention:
<GunnarHj> https://code.launchpad.net/~gunnarhj/ubuntu/utopic/fonts-android/droid-sans-fallback-fix/+merge/229432
<GunnarHj> https://launchpad.net/bugs/1308771
<ubottu> Launchpad bug 1308771 in libreoffice-dictionaries (Ubuntu) "Update Swedish spellcheck and hyphenation dictionaries" [Medium,In progress]
<didrocks> GunnarHj: I'll have a look
<didrocks> GunnarHj: but you nominated laney for the review, he's back next week and probably know better the matter, wdyt?
<didrocks> I know he had it on his radar
<didrocks> I can remind him once he's back :)
<GunnarHj> didrocks: Ok, let's wait with that one. How about the other?
<didrocks> GunnarHj: I'll poke bjoern at today's meeting, ensuring he's looking at it quickly
<GunnarHj> didrocks: TIA
<didrocks> GunnarHj: yw ;)
<didrocks> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: cyphermox
<tedg> pitti, Okay, I'll give that a try. Odd that the tests run on package build without issue, but not with autopkg.
<cyphermox_> GunnarHj: hi
<cyphermox_> oh, oops.
<cyphermox_> @pilot out
* cyphermox_ changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<desrt> hallyn: awake yet?
<desrt> hallyn: should be be bumbing the version depend in cgmanager.c?
<desrt> *bumping
<hallyn> desrt: sigh, i don't know.  we'd need to get cgmanager into the archive first to do that.  i.e. ask slangasek to take a quick look at the package i have in mentors
<desrt> i'm more or less done with my rewrite of your rewrite of my rewrite of your code ;)
<hallyn> jodh: did you have a chance to look at latest cgmanager github changes?
<hallyn> desrt: cool :)
<hallyn> desrt: i wasn't sure what 'proper' file i/o looks like in glib, but also i simply cannot figure out how to do that gnome indenting style
<hallyn> it's not always 2 spaces,
<hallyn> 4 spaces for a while() block?
<desrt> while (xxx)
<desrt>   {
<desrt>     do_stuff ();
<desrt>   }
<desrt> it's standard GNU style
<hallyn> oh so always 2
<hallyn> gotcha
<hallyn> heh so maybe i should just fire up emacs next time
<desrt> :)
<desrt> there are a couple of things we do differently: always use soft spaces, never hard tabs
<hallyn> i was a die-hard emacs user for a year or two around 1993
<desrt> and we line up the parameters at the top of the function in that funky way...
<desrt> but otherwise it's more or less stock GNU
<desrt> fwiw, we have g_file_set_contents()
<desrt> this is almost always better than using fopen, etc.
<desrt> also, functions like g_remove, g_open(), etc. are only meant to be used on programs wanting ot be portable to windows
<desrt> since otherwise they're just macros for the normal thing
<hallyn> ok.  yeah i'd used g_file_get_contents(), i'm not sure why i didn't think to look for set_contents.  (it occurred to me last night in bed :)
<desrt> (on windows, they do character-set conversion of the filename)
<desrt> fwiw, i replaced that stuff anyway
<desrt> with a single keyfile
<hallyn> ok
<desrt> it's easier to list out the groups in that case
<hallyn> which is like a dictionary?
<desrt> for the introspection
<desrt> ya...
<hallyn> cool
<desrt> will look like
<desrt> [session-1.scope]
<desrt> path=/user-slice/blah
<desrt> [session-2.scope]
<desrt> path=etc.
<desrt> i figure we can easily expand this if we want to get stateful about other unit types in the future
<slangasek> hallyn: "cgmanager into the archive first" - i.e. there's a dependency chain here for getting the fix into the archive?  If so, please point me at it ASAP :)
<slangasek> desrt: so "done" means "in upstream git"?
<desrt> slangasek: no.  testing it first.
<slangasek> ok
<desrt> btw: what is the actual command that cgmanager uses to remove cgroups?  is it writing something to some file in sysfs or is there a proper syscall?
 * desrt wants to clean up a bit...
<slangasek> hallyn: ^^
<desrt> also: how can i install the new cgmanager for testing?
<desrt> fwiw: https://github.com/desrt/systemd-shim/commits/wip/abandon4
<desrt> if someone else wants to test...
<desrt> assuming nothing is wrong (and it looks fine to me from what i can test without the new cgmanager) then the only change that is needed is to bump the cgmanager dependency version to [whatever is correct] and push to master
<jodh> hallyn: still on the list for today! :)
<hallyn> slangasek: http://mentors.debian.net/debian/pool/main/c/cgmanager/cgmanager_0.32-1.dsc
<hallyn> desrt: cgmanager does rmdir
<desrt> oh.  interesting.
<desrt> it can do that even when there are files in there?
<hallyn> desrt: i won't be able to test for the next 30 mins, morning commotion
<hallyn> yes, but not with subdirs
<hallyn> the files are ignored
<desrt> tasks are not
<desrt> this is actually quite utterly sane...
<desrt> omg how lovely
<desrt> look ma!  i'm creating cgroups!
<desrt> i suppose i move pids by echoing them into the tasks file?
<hallyn> yup
<desrt> this is awesome :)
<hallyn> you can also use 'cgm', which is what i usually do for these tests
<hallyn> cgm create all xxx/y
<hallyn> sleep 20 0&
<hallyn> cgm movepid all xx/y $!
<desrt> what's with the 0?
<hallyn> it's a misplaced space :)
<hallyn> sleep 200 &
<desrt> :)
 * hallyn biab
<desrt> TIL: you can give multiple arguments to sleep(1) and it will handle each one in turn
<desrt> sleep 10 5 == sleep 15
<rbasak> How does one do a dep5 file that involves a BSD-3-clause, but where the ORGANIZATION placeholder has been replaced by different organisations in different files?
<rbasak> I can't collapse the License text to a single stanza easily, since then I'll have failed to preserve the text as required.
<rbasak> Unless I name them differently, in which case I've failed to use the recommended common name.
<cjwatson> You don't have to have a separate stanza for the License text; you can put it in a Files stanza
<rbasak> I want to though, since I'm using many Files stanza which _do_ have a common license text.
<bigon> doko: hey do you have any plans regarding https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720545 ?
<ubottu> Debian bug 720545 in src:bash "bash: Please consider removing privmode.diff" [Important,Open]
<cjwatson> I think that's probably the best you can do.
<rbasak> Would it be acceptable to use my own names? Eg. BSD-3-clause+Google, with the full text at the bottom? This detracts from the common names.
<cjwatson> You should be able to coalesce the identical ones, since the Files field takes a whitespace-separated list.
<rbasak> But this is an incredibly complicated dep5 file, since juju embeds upstream sources.
<cjwatson> Unless they have different Copyright, I suppose.
<cjwatson> But the definition of Copyright does say "Not all copyright notices may apply to every individual file".
<rbasak> I'm trying to avoid collapsing Files fields that come from separate upstream projects, to try and help make it easier to update the file in the future.
<rbasak> Then I only have to review the section of the file that has changed.
<rbasak> But I have bundled all the license texts at the bottom, since they're very common (eg. standard Google golang 3-clause with Google, Inc. organisation)
<cjwatson> I think at this point I'd recommend asking debian-policy or similar for advice ...
<rbasak> I wondered where I should ask the question. Though Juju isn't currently packaged for Debian.
<cjwatson> Or, slangasek is listed as the driver :)
<cjwatson> But it's been incorporated into debian-policy, so I think that's the right contact address
<rbasak> I think I'll just fail to use the common name in this case, and explain why in a comment at the top. AFAICT, that doesn't violate the spec.
<rbasak> I'm using names like "BSD-3-clause+Google" instead, which I hope is clear.
<cjwatson> I don't think it violates the spec, no.  It's a trade-off of less-desirable options is all.
<rbasak> Yeah.
<cjwatson> It would be nice if people who had to do this were using a consistent syntax to denote the variant names though.
<rbasak> It's 256 lines long without any license texts :-/
<rbasak> That's ~30 embedded upstream projects.
<rbasak> I guess the core issue is that there are two things trying to fit into the licence name field. 1) a ref for Files stanzas to refer to; and 2) a reference to an outside standard.
<rbasak> Except that the licence text is permitted to vary, still meets the outside standard, but I need separate refs.
<rbasak> Anyway
 * rbasak JFDI
<rbasak> Thank you for the discussion. At least I know I'm not missing something and there isn't a better answer.
<davmor2> rbasak: just 1 small line off a JEDI then so close
<rbasak> :)
<desrt> hallyn: sup?
<hallyn> desrt: you're asking if i've tested your wip/abandon4, or if i've heard from slangasek  about the cgmanager package?
<hallyn> zul: pushing one last candidate of libvirt to ppa, will run tests, then push to utopic
<desrt> if you've done the first one then i don't care about the second :)
<zul> hallyn: cool
<hallyn> desrt: not yet, lemme spin up the vm
<hallyn> zul: libvirt_1.2.8-0ubuntu1~ppa2_source.changes pushed to ppa:serge-hallyn/virt.  now wait, do we need ffe for this, or did you already get that?
<zul> hallyn: not yet
<hallyn> do you mind filing it?
<hallyn> desrt: so the one change that helped for me was to add a cgmanager_prune (path); to the top of ccgroup_unit_stop()
<hallyn> desrt: not sure if there is a race otherwise or what, but the cgroup doesn't always get removed
<desrt> weird....
<desrt> maybe the kill is slow
<desrt> like the kernel doesn't have time to properly kill off the processes
<desrt> or maybe they don't get reaped or something
<desrt> so the remove fails...
<desrt> makes sense, though.  i'm happy to change that.
<hallyn> yo'ud think the n retries would work around that :(
<desrt> not if it happens so quickly
<hallyn> but then there have been a few problems with cgroups in the last few kernels where rmdir goes slowly etc
<desrt> if we don't get scheduled out....
<desrt> we're running a pretty tight loop there, without even a sched_yield() or so
<hallyn> dbus calls though?
<desrt> true...
<desrt> *shrug*
<hallyn> yeah
<desrt> we could add sched_yield and i bet this would help
<desrt> but.............
<hallyn> otherwise looking good - thanks
<desrt> any bug that sched_yield fixes is not truly fixed
<desrt> so i think your solution is better :)
<desrt> hallyn: i need to know the new version number for cgmanager...
<desrt> then i'll push
<hallyn> desrt: 0.32-1
<desrt> what protocol version, i mean
<desrt> for the check at connection time
<desrt> we have 6 now...
<desrt> 7? 8?
<hallyn> oh, 8
<hallyn> desrt: ^
<desrt> thanks.
<desrt> will push after our desktop meeting
<hallyn> thx, ttyl
<desrt> i guess a release is due now, too.
<desrt> any other patches you guys are carrying around?
<desrt> slangasek: ^ ?
<hallyn> you mean for systemd-shim itself?
<desrt> yes
<desrt> ie: any vendor patches that i can take upstream
<hallyn> not from me
<slangasek> desrt: the only systemd-shim patches are cherry-picks
<desrt> cool.  thanks for the info.
<hallyn> slangasek: d'oh, there's an open debian bug which i should fix in that cgmanager pkg (badness in sysvinti job)
<slangasek> hallyn: ok; shall I wait for a reupload to mentors?
<hallyn> slangasek: yes please, should be up in 5 mins
<hallyn> just trying ot make sure i'm not missing some sysvinit-ism tha tmakes the bug report wrong
<slangasek> hallyn: well, I would recommend using do_start / do_stop as the function names, rather than using function names that are the same as upstart commands
<slangasek> hallyn: but I can confirm that this is a real bug
<hallyn> slangasek: i'd feel more comfortable doing that change (back to ->do-start) in a later relase with more testing
<slangasek> oh?
<hallyn> no?  well i can do it now i guess :)
<slangasek> why?  this is purely a shell name mismatch problem
<slangasek> so looking at the change to debian/cgmanager.cgmanager.upstart
<slangasek> what are you expecting this to do?
<slangasek> +start on mounted MOUNTPOINT=/sys/fs/cgroup or virtual-filesystems or starting dbus
<slangasek> that will not block the start-up of dbus
<slangasek> in fact, it will 100% never trigger on 'starting dbus', because virtual-filesystems is always emitted before local-filesystems and dbus starts on local-filesystems
<hallyn> slangasek: that is what fixed the previous phone problem (i didn't come up with that fix)
<hallyn> apparently ther ewere jobs which were start on started dbus which started before cgmanager was ready
<hallyn> ok, pushing new cgmanager to mentors now
<slangasek> hallyn: which phone problem was fixed by this?  because that change is nonsensical with the standard dbus job, and if the phone is overriding the start condition for dbus, then cgmanager's startup condition needs to also be overridden there, not as part of the job in the cgmanager package
<hallyn> pitti: ^
<hallyn> I guess tedg had originally proposed it
<hallyn> slangasek: i suppose we could keep it out of the debian pkg and keep it as ubuntu delta until we're sure whether and why we need it (and maybe have better fix)
<desrt> slangasek: okay.  systemd-shim-8 is released
<desrt> slangasek: i moved the tarball dir from ~desrt/ to ~desrt/systemd-shim
<desrt> 451357c32ada3d68fec56f508990739edee19e9088509adfabf0648068015bcf  systemd-shim-8.tar.xz
<slangasek> hallyn: so I'll sponsor this cgmanager package as-is; the upstart job change looks wrong because it's ineffective, not because it's harmful
<hallyn> slangasek: ok, thx
<arges> hallyn: would you like me to get the qemu SRU debdiff ready for bug 1366868? i could also do the combination with bug 1324174 if you want
<ubottu> bug 1366868 in qemu (Ubuntu Trusty) "kvm: dompmwakeup fails if domain becomes pmsuspended" [Medium,In progress] https://launchpad.net/bugs/1366868
<ubottu> bug 1324174 in qemu (Ubuntu Trusty) "qemu should attempt to re-load kvm_intel to enable nesting at first install" [Medium,Confirmed] https://launchpad.net/bugs/1324174
<hallyn> arges: sure - i was planning on doing this afternoon, but i'll move on to qemu merge for utopic in that case
<hallyn> arges: thanks!
<arges> hallyn: np
<hallyn> slangasek: so, 'or starting dbus' wont' make cgmanager start earlier, but can't it delay dbus starting?  that's how i thought it fixed the problem we wer ehaving on krilin
<slangasek> hallyn: no, it doesn't delay dbus starting
<arges> hallyn: so the patch that fixes the issue for me actually updated the pc-bios/*bin files, which I believe we don't put into our source package; so maybe I need to patch seabios...
<slangasek> hallyn: because cgmanager is already starting when 'virtual-filesystems' triggers, and upstart won't block starting dbus for this
<hallyn> slangasek: my undestanding was always that y having  'start on starting x' meant that when x starts, y will first start, then x will start
<hallyn> arges: oh.  yeah.
<slangasek> that's what 'start on starting x' means
<slangasek> that's not what 'start on foo or starting x' means
<hallyn> ah
<arges> hallyn: so i'll have to track that one down... if you wan to go ahead with the other SRU go for it
<hallyn> arges: what's the git commit id again?
<arges> hallyn: well db76ec6291df8a03c2cc82ea1249049383cca392 in qemu. but they just bumped their seabios version. so I need to track down the actual seabios commit
<hallyn> arges: espeak love sspitting out commit ids :)
<arges> heh, i'm glad i don't have that turned on
<hallyn> arges: ok, thanks, i'll do the other one then :)
<arges> great
<mterry> barry, I never heard of nose2 before.  Was there some fork?  Why not make nose better?
<barry> mterry: nose is eol'd. nose2 is much better and the official next version.  all new development is happening on nose2
<barry> so i guess the answer is kind of and time machine :)
<mterry> barry, huh...  should we as a project try to get nose into universe?  Probably not a whole lot of maintenance work, but I'm curious how much of a push there is to get projects to switch
<barry> mterry: there's hasn't been a concerted effort.  the api's are different, but nose2 is much better.  i tell people to switch, but yes, i'd like to see migrations from nose to nose2
<tedg> slangasek, The though there was that systemd-shim was getting dbus activated even before the android container started.
<tedg> thought
<slangasek> tedg: none of these start conditions are related to the android container
<tedg> slangasek, No, but I thought that's why you were saying it is ineffective.
<tedg> slangasek, Why do you think it's ineffective.
<slangasek> tedg: what problem was this change supposed to solve?
<ogra_> doesnt systemd-shim (and the session bus) get started by lighdm ?
<ogra_> thats definitely guaranteed to start after the container
<slangasek> the start condition does not cause cgmanager start-up to block dbus start-up
<ogra_> (due to lightdm.override with differnt start conditions)
<tedg> slangasek, jodh had found some cases where cgroups manager was starting after systemd-shim, and systemd-shim wasn't detecting it starting, so thought it didn't have cgmanager support.
<tedg> slangasek, We can't (grumble, dbus activation) ensure that we start before it, so the goal was to make it better.
<slangasek> tedg: my reading of the change to the job config is that it's a complete no-op
<slangasek> tedg: the conditions are still the same: cgmanager will be started "before" dbus but not in a blocking manner
<tedg> slangasek, Yes, not blocking, it can't block dbus starting (I forget why now). So not a guarantee, correct.
<slangasek> tedg: so the 'or starting dbus' is *never hit*
<slangasek> unless someone has totally bodged all the start ordering on the phone, which is possible
 * tedg doesn't comment
<ogra_> not that badly :P
<tedg> slangasek, The thought was that initrd might be mounting some of the filesystem triggers already, so they weren't happening.
<ogra_> http://people.canonical.com/~ogra/touch-bootcharts/ubuntu-phablet-utopic-111.png ... quite old, but i dont think the order changed much since
<slangasek> tedg: the filesystem events should still happen, and in order; virtual-filesystems should be emitted before local-filesystems, or else I'm wrong about how mountall works
<tedg> slangasek, Ah, okay. To be clear, I'm just the messenger here :-)
<tedg> Someone was busy planning debconf ;-)
<hallyn> should be easy enough to test with a test pkg removing that bit
<Triniboi00> does the os ubuntu support long term scehduling?
<sarnold> Triniboi00: what's that?
<Triniboi00> Long term scheduling: which determines which programs are admitted to the system for execution and when, and which ones should be exited.
<Triniboi00> does ubuntu support this?(school project looking for guidance)
<sarnold> Triniboi00: the linux kernel has one, non-pluggable, scheduler. whichever tasks are selected for running are selected based on the details of the one scheduler without much in the way of deadlines or goals
<sarnold> Triniboi00: the cgroup system can modify the parameters somewhat, as can the nice levels
<sarnold> .. as well as the SCHED_RR, SCHED_FIFO, SCHED_BATCH, etc. scheduling priorities..
<sarnold> Triniboi00: it sounds a lot like what you're looking for is a cluster-level job scheduler to schedule jobs on specific machines?
<Triniboi00> no
<Triniboi00> http://www.cim.mcgill.ca/~franco/OpSys-304-427/lecture-notes/node38.html
<Triniboi00> these are the type of scheduling i just want to know which does unbutu support?
<sarnold> Triniboi00: ah! some kind of crazy professor definition :)
<sarnold> Triniboi00: see the 'nproc' rlimit in setrlimit(3) and /proc/sys/kernel/pid_max and /proc/sys/kernel/threads-max in proc(5)
<Triniboi00> ETMLI5
<Triniboi00> 8.	Does the OS support long term scheduling?  9.	Does the OS support medium term scheduling (swapping)?   10.	Describe the short term (CPU) scheduling algorithms implemented in the OS :
<sarnold> yeah, no OS has done _swapping_ in decades
<Triniboi00> these are the questions i have to answer for unbuntu
<sarnold> paging is the new hotness
<sarnold> for the last 25 years or so
<Triniboi00> so the answers are no to all?
<sarnold> Triniboi00: no, the answers require some nuance :)
<Triniboi00> there yes or no questions whats up?
<dobey> do your own homework
<dobey> also, they're
<Triniboi00> lol i do my own hw
<Triniboi00> these are 3 questions out of 22 that i cant find ...linux has a completley fair scheduler
<Triniboi00> but i cant find if its supports long term or not i am not well versed in the subject
<cjwatson> Long-term scheduling sounds like a concept from batch-processing systems that doesn't really apply.  There are resource limit controls that can cause fork to fail, and things like the OOM killer that will sometimes forcibly kill processes in exceptional situations, but those aren't really part of what I'd characterise as core scheduler behaviour.
<sarnold> Triniboi00: a few minutes with the setrlimit and proc manpages ought to help a little.
<cjwatson> I suppose you might also look into process priorities and control groups and such things.  The approach in all Unix systems I'm aware of though tends to be to accept the process (except for some exceptional situations like running over resource limits, but as I say those don't really come up much in normal operation) and then whether the scheduler actually ever gives it any timeslices later is up to it ...
<Triniboi00> ah ok so i see ubuntu does not use the LTS because its first come first serve
<Triniboi00> long term scheduling is a no
<cjwatson> That would be an overly simplistic characterisation.  Linux's scheduling certainly isn't first-come-first-served.
<cjwatson> I suppose that's sort of true of process admission but I think putting it that way is confusing.
<sarnold> cjwatson: you've got to see the crazy page from the professor to understand the meaning of "first come first served" in the context "long term scheduler".. they're like lecture notes that havent been updated in 30 years...
<sarnold> despite clearly being written in html :)
<cjwatson> Yeah, I skimmed it
<cjwatson> In general I think you'll do better in your research if you note that for this purpose the distinctions between Ubuntu and other distributions are not desperately relevant; you'll get more interesting research hits by just looking for commentary on the behaviour of Linux.
<Triniboi00> yea  i have seen that
<cjwatson> Practically all of this is up to the Linux kernel; while that is modified and built by Ubuntu, you aren't going to find core differences at the sort of level that's relevant to this kind of work.
<Triniboi00> thanks for the help i think i understand what to do
<sarnold> have fun :)
<Triniboi00> will do :D
<Triniboi00> what is this btw are you developers?
<Triniboi00> or this is just a social thing
<sarnold> I do mostly security work; not so much development on my own as picking nits with other people's development work
<cjwatson> Lots of developers are here, but not necessarily kernel developers.
<Triniboi00> ah i do security work as well
<Triniboi00> for ibm
<sarnold> nice :)
<hallyn> process question - if there is a new debian qemu release that fixes a (9p readdir d_type) flag.  should i simply push it right now as it's a bugfix even without an open ubuntu bug, or should i open a bug just to close it?
<RoyK> anyone had a look at this https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1364091
<ubottu> Launchpad bug 1364091 in mdadm (Ubuntu) "Possible RAID-6 corruption" [Undecided,New]
<hallyn> (anyway, i'll test+push i guess)
#ubuntu-devel 2014-09-10
<sexyboy> sup, why ubuntu full live images can't contain both graphical and alternate intallers?
<infinity> sexyboy: Because they'd be twice the size.
<sexyboy> i doubt, debian used to (or still does) contain both graphical and text installer
<sexyboy> they just install packages from one pool
<infinity> You may doubt all you want, but our installer isn't the same as theirs.
<infinity> Our live installer doesn't install from packages, it just blats out the contents of the livefs, and does some post-copy twiddling.
<infinity> Which is why it's so fast.
<infinity> But also means it's awful for a highly customizable experience like d-i (the "alternate" installer)
<sexyboy> i see
<infinity> We do have a d-i that installs from live images too (we use it for the server CD), but to use that on the desktop CD, you'd either (A) end up with something identical to what ubiquity did, so who cares, or (B) have to remove hundreds of packages post-install.
<sexyboy> infinity: how about this then: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1367487
<ubottu> Launchpad bug 1367487 in ubiquity (Ubuntu) "Wishlist: ubiquity proper manual dm-crypt+lvm partitioning wanted" [Undecided,New]
<infinity> sexyboy: Really, if you want to install (and mass install) from d-i, I'd recommend a netboot option.  Either the mini.iso for one-off installs or a PXE setup for mass installs.
<sexyboy> yeah i know that mini uses it
<sexyboy> but the issue with mini is lack of proper wlan support
<infinity> sexyboy: And yes, it's known that ubiquity still doesn't have 100% feature parity with d-i (and, in some cases, may never have all the features)
<infinity> But, as you point out, ubiquity has some fancy features d-i doesn't (like better wireless support).
<infinity> Anyhow, merging the two can't really be done, so it's not worth exploring.
<infinity> Hacking on one installer or the other to add features you want is more productive.
<sexyboy> so how about improving ubiquity to make it more rich in features?
<sexyboy> s/more rich/richer
<sexyboy> well, the issue that troubles me the most is described in the launchpad ticket
<infinity> Patches always welcome. ;)
<sexyboy> heeh
<sexyboy> freaking hell, ubi-partman.py has 141K of lines... this gonna take a while
<sexyboy> ah no, just over 3k
<sexyboy> mc misslead me
<sexyboy> i hope some of you will assist me in this
<ScottK> pitti: Is "Could not find executable /tmp/adt-run.fS2Wfy/build.00G/ark-4.14.0/obj-i686-linux-gnu/kerfuffle/tests/jobstest.shell" an indication of a package problem or the ADT environment?
<pitti> Good morning
<sexyboy> morning
<pitti> slangasek: you mean the "on starting dbus"? That waas supposed to ensure that cgmanager is always started when lightdm starts; but we didn't want to add a cgmanager dep to lightdm
<pitti> ScottK: apparently something in the shared kde packaging tools changed recently to stop building these .shell files? I haven't checked the reason; they still all succeeded until not too long ago, one could probably limit the time of breakage with the history
<ScottK> Thanks.
<pitti> ScottK: one thing to try would be if it also happens in utopic, or whether it's something in -proposed
 * pitti tries ark in both
<ScottK> The same versions had passed previously.
<pitti> yes, it affects pretty much all kde packages in the same way, it's obviously not a change in the leaf packages
<ScottK> Riddell: Maybe it's apachelogger's fault^^^
<pitti> desrt: wow, nice work on shim! I assume we want to get this packaged ASAP; slangasek, are you on it or want me to?
<pitti> ScottK, Riddell: ah, I think I found it
<ScottK> Oh?
 * pitti does last re-run to confirm
<pitti> Test project /tmp/adt-run.936IOo/ark-4.14.0/obj-i686-linux-gnu
<pitti> /tmp/adt-run.YPh6KC/build.6NC/ark-4.14.0/obj-i686-linux-gnu/plugins/clirarplugin/tests/clirartest.shell
<pitti> note the different tmpdir
<pitti> that was a bug that I fixed recently in autopkgtest, it copied the previously built tree into the previous instead of current temp dir
<pitti> after a reboot/reset
<pitti> so apparently this is necessary as in this case the tests hardcode the full absolute path somewhere
<pitti> so after a testbed reset I guess we need to copy it to the same name and live with the naming race condition (no big deal)
<pitti> I'll get to that ASAP
<ScottK> Great.  Thanks for your detective work.
<ScottK> doko_: ^^^
<sexyboy> so i'm thinking about modifying ubiquity to make lvm partitioning available
<sexyboy> i know it uses d-i as a backend
<sexyboy> and i'm not a coding guru so any hints on what should i start with would be helpfull
<sexyboy> i'm looking at the ubi-partman.py plugin code
<sexyboy> not sure which functions are responsible for calling d-i
<sexyboy> ehm
<sexyboy> anyone?
<sexyboy> eh i'd need to remind some python basics
<slangasek> pitti: for the reasons described, the 'on starting dbus' doesn't do anything to ensure ordering
<slangasek> pitti: systemd-shim - I'll have a look at it tomorrow
<pitti> slangasek: hm, that's not how I understand starting(7)
<pitti> when a job A has "start on starting B", then I expect B's startup to be delayed until A has fully started
<pitti> like a reverse dep
<dholbach> good morning
<pitti> "init(8) will wait for all services started by this  event  to  be  running, [...] before allowing the job to continue starting."
<pitti> slangasek: ^ so is that not true/misleading, and A and B start in parallel?}
<pitti> so cgmanager "start on starting dbus" should ensure that cgmanager starts before dbus (and thus lightdm), or on systems without cgmanager it wouldn't change anything (we wanted to support the latter and thus avoid changing lightdm to append "and started cgmanager")
<slangasek> pitti: job A is not 'start on starting dbus', it's 'start on virtual-filesystems or mounted [...] or starting dbus'
<pitti> slangasek: right, but wouldn't the other two at most make it start even earlier?
<slangasek> pitti: 'start on A or B' means that when A is emitted, the job is started and *only* A is blocked
<pitti> hm, so if that doesn't work, how else could this be declared?
<slangasek> using wait-for-state
<pitti> so a pre-start script in dbus.init that checks if cgmanager is installed, and if so, waits for it to be started
<slangasek> or a separate job that's part of the cgmanager package which is 'start on starting dbus' + wait-for-state
<pitti> slangasek: why would the latter need wait-for-state then? dbus would block on that new job with that, wouldn't it?
<slangasek> the new job is just the glue
<slangasek> you need to tell it how to wait for cgmanager to be started
<slangasek> so 'start on starting dbus' / 'exec start wait-for-state WAITER=cgmanager-dbus WAIT_FOR=cgmanager'
<pitti> slangasek: /e/i/wait-for-state.init has env TARGET_GOAL="start"; does that mean it defaults to "started" or "starting" (or any) when not given?
<slangasek> those are states, not goals
<slangasek> by default it expects start/started
<slangasek> (goal/state)
<pitti> ah, it's grepping status, I see
<doko> pitti, please restart the python2.7 i386 autopkg test
<pitti> doko: done
<Mirv> could I get a packaging ack from a core dev for unity SRU microversion bump, visible at: https://ci-train.ubuntu.com/job/ubuntu-landing-005-2-publish/lastSuccessfulBuild/artifact/packaging_changes_unity_7.2.3+14.04.20140826-0ubuntu1.diff ? (there's also a patch removal for a fix that was now included properly)
<pitti> Mirv: LGTM, it's just a bit weird that it's two changelog records?
<Mirv> pitti: thanks. and yes. the last published version matches current trusty correctly, but their merge requests combined with CI Train "logic" came up with such solution unfortunately.
<rbasak> infinity: http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2014-September/007015.html
<rbasak> infinity: thank you for getting me to check.
<rbasak> (did I say this already?)
<rbasak> infinity: do you have any suggestions for what to do to get out of this mess?
<zbenjamin> jdstrand: ping
<zbenjamin> jdstrand: the test is working fine now ;),   For the location of the files i need to create, could i use TMPDIR? or XDG_RUNTIME_DIR?
<zbenjamin> jdstrand: i 'm wondering if that would not the more correct location because those files should not be permanent
<mlankhorst> is there an archive admin to accept fglrx to -proposed?
<mlankhorst> it's blocking my xorg-server upload :-)
<pitti> ScottK, Riddell, doko: ok, KDE autopkgtest failures sorted out now
<Riddell> yay thanks pitti, sorry I've not been around, busy at akademy
<Riddell> pitti: what was up?
<mlankhorst> ScottK: did you get around to testing mesa?
<pitti> Riddell: ah, have fun at akademy! (I saw your blog posts)
<pitti> Riddell: apparently the built tests contain absolute file names to a temporary build dir; there was a bug with copying back the previously built directory into the new testbed after reset, but I added a hack for that now
<doko> pitti, Riddell, ScottK: kopete still fails. should it be overridden?
<pitti> doko: no, it just succeeded
<pitti> it just took very long (finished a few mins ago), so britney didn't pick it up yet
<pitti> doko: sorry that gcc is always the scapegoat for finding bugs in pretty much any test; fortunately delaying propagation for a bit doesn't matter much
<doko> pitti: thanks. and I just see that the debci build ftbfs
<pitti> yep, that's on my list; if it's blocking anything, I'm fine with removing it from -proposed, too
<pitti> (but it doesn't AFAIK)
<mlankhorst> doko: ping?
<doko> mlankhorst, you see that I'm here ...
<mlankhorst> doko: I want to reduce the delta with debian-unstable's xorg-server, is the patch debian uses sufficient for our needs too?
<mlankhorst> they only export xserver_confflags
<doko> mlankhorst, what do I else?
<mlankhorst> xserver_confflags_main / udeb / xserver_vars
<mlankhorst> but their xserver_confflags also contains the contents of _main
<pete-woods> cjwatson: hi. do you have time to do another check of https://code.launchpad.net/~unity-api-team/click/scope-facing-apis/+merge/233974
<pete-woods> I've done the resubmit now
<cjwatson> pete-woods: approved.  tarmac should get round to landing it in a bit
<pete-woods> cjwatson: awesome. thanks!
<mlankhorst> so if I can get some confirmation that change is fine with vnc (should be) then I can upload a new xorg-server :-)
<doko> mlankhorst, just do it, tigervnc is still in NEW :-/
<mlankhorst> ok
<doko> neutron (1:2014.2~b2-0ubuntu1 to 1:2014.2~b3-0ubuntu1)
<doko> Maintainer: Ubuntu Developers
<doko> 0 days old
<doko> python-neutron/i386 unsatisfiable Depends: pthon-babel (>= 1.3)
<doko> python-neutron/i386 unsatisfiable Depends: python-oslo.rootwrap (>= 1.3.0~a1)
<doko> Not considered
<doko> zul, ^^^ "pthon-babel"
<zul> doko: crap ill fix it
<desrt> pitti: :)
<doko> zul, and a new version of python-oslo.rootwrap is needed
<zul> doko: ok
<doko> pitti: should init be kept in main?
<doko> seb128, Laney: firefox-globalmenu and thunderbird-globalmenu are considerd for demotion. is this intended?
<seb128> doko, that's a question for chrisccoulson but I think not
<doko> ok, asking
<pitti> doko: fine to go to universe for now; we haven't yet discussed what to do with that metapackage in ubunut
<doko> pitti: and cgroup-lite?
<pitti> I don't know about that one -- stgraber, hallyn ^ ?
<doko> jtaylor, I remember some request from you. what was this?
<Mirv> in case anyone is interested, my apt complaining about all signing keys missing was apparently about some resource limit in keyblock resource files /etc/apt/trusted.gpg.d/. I removed a few and ran sudo dpkg-reconfigure ubuntu-keyring
<Mirv> so apparently something like bug #1263540
<ubottu> bug 1263540 in apt (Ubuntu) "Apt-get reports NO_PUBKEY gpg error for keys that are present in trusted.gpg." [Undecided,Confirmed] https://launchpad.net/bugs/1263540
<infinity> doko: cgroup-lite probably wants to be removed completely, but stgraber would know for sure.
<jdstrand> zbenjamin: for click apps, TMPDIR is set to a subdirectory in XDG_RUNTIME_DIR. so, I recommend TMPDIR :)
<jdstrand> zbenjamin: you may want to fallback to /tmp if it isn't set though (to handle non-confined (or differently-confined) apps)
<flexiondotorg> cjwatson, I have word from Canonical IS that there is enough spaces to accommodate Ubuntu MATE. The Ubuntu Tech Board gave the project the green light.
<flexiondotorg> cjwatson, How should I proceed to get Ubuntu MATE integrated into the official build infrastructure?
<doko> mlankhorst, libepoxy promoted
<cjwatson> flexiondotorg: mail me with the location of your seeds and a pointer to your current ad-hoc build system for reference
<flexiondotorg> cjwatson, Will do.
<mlankhorst> thanks
<infinity> cjwatson: And pretty please made sure core-dev has write access to your seeds, in case we need to do some rapid fixes that can't handle an MP turnaround.
<infinity> Err.
<infinity> flexiondotorg: ^
<flexiondotorg> infinity, core-dev being who?
<infinity> flexiondotorg: 06:09 <infinity> Maybe tox just needs a tox-lite that doesn't have the pip/virtualenv bits turned
<infinity>                  on (and thus, hasn't the dependencies).
<infinity> 06:09 <infinity> Though, without archive reorg, that would still be a forked source package. :/
<infinity> 06:10 <infinity> Oh, unless it doesn't need them at build time, which I suppose it might not.
<infinity> Err.
<infinity> flexiondotorg: https://launchpad.net/~ubuntu-core-dev
<infinity> I can't paste today to save my life.
<infinity> Motor skills at 7am are not my thing. :/
<flexiondotorg> infinity, Do I do that by subscribing ubuntu-core-dev to the repository?
<infinity> flexiondotorg: The traditional way to do that seems to be for your seeds to be owned by a mate-developers (or similar) team, and then invite ubuntu-core-dev to join that team.
<flexiondotorg> infinity, Thanks.
<flexiondotorg> infinity, cjwatson I currently have some packages in a PPA that a required to "make" Ubuntu MATE. Will these need uploading to the official archive as prerequisite?
<flexiondotorg> I believe there are 2 sponsors who can/will upload packages on my behalf, until I have PPU rights.
<infinity> flexiondotorg: If it's not buildable without them, it's certainly a prereq for us being able to test things reasonably.
<flexiondotorg> infinity, Email sent to Colin. ubuntu-core-dev added the ubuntu-mate-dev team. I'll contact our sponsors and progress package uploads.
<desrt> pitti: looks like slangasek is not on it :)
<desrt> pitti: (due to sleeping)
<pitti> desrt: he said he'd get to it in his morning
<desrt> ah. nice.
 * desrt missed that
<pitti> I offered to do it, but I don't want to step on his toes
<flexiondotorg> pitti, Did you offer to act as sponsor for uploading Ubuntu MATE packages? Sorry, it wasn't clear if you are sponsoring or would find sponsors.
<doko> cjwatson, ok to demote libparted-i18n?
<doko> don't know about gfxboot-themes
<popey> flexiondotorg: dholbach also said he'd help â»
<popey> he owes me anyway ã
<dholbach> popey, how can I help?
<dholbach> flexiondotorg, ^
<pitti> flexiondotorg: I can do a few, yes (just not right now); but you're welcome to ping/email me with the requests
<mlankhorst> hm what was the magic command to test if my package is published to the archive already?
<pitti> mlankhorst: you mean rmadison?
<mlankhorst> ah probably
<mlankhorst> thanks
<dholbach> flexiondotorg, is it https://code.launchpad.net/~ubuntu-mate-dev/ubuntu/utopic/policykit-desktop-privileges/mate-fixes/+merge/230610?
<flexiondotorg> dholbach, Thanks. There are not many. I'll email you details. Thanks for helping.
<popey> dholbach: context is getting ubuntu mate packages in utopic. they are currently in a ppa. this is a step towards get ubuntu mate built on canonical infra
<flexiondotorg> Well, that would be good. But not just that.
<flexiondotorg> I have a few package for settings and themes.
<flexiondotorg> sec...
<dholbach> pitti, is the master of policykit, so I'd leave that one to him
<dholbach> I'm happy to review the other packages, if you give me the links
<flexiondotorg> https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-mate/ubuntu-mate-settings
<flexiondotorg> https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-mate/ubuntu-mate-artwork
<pitti> flexiondotorg, dholbach: will do pk-desktop-privs
 * popey hugs dholbach 
<flexiondotorg> https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-themes/ubuntu-mate-themes
<dholbach> rock on
<flexiondotorg> So, I have my own pkla file in ubuntu-mate-settings that will not be required when +merge/230610 is approved and integrated.
<mvo_> cjwatson: would it make sense to drop "minimal" from the STRUCTURE for the ubuntu-sdk-libs-dev seed? when we build the click chroot we do not install minimal currently (and we don't need to afaict) but we need python3 for autopilot so I was wondering if I can simply make it a explicit dep of ubuntu-sdk-libs-dev but the inherit of minimal prevents that right now
<pitti> dpm, wgrant: hm, what is the problem with https://translations.launchpad.net/ubuntu/utopic/+source/account-polld/+imports ?
<pitti> dpm, wgrant: i. e. is it normal that po files are "stuck" in the import queue, or is there something particularly wrong about this package/project?
<dpm> pitti, the .po files are only imported when the corresponding .pot file has been imported. However, I don't see any generic .pot file in the queue (I only see arch-specific ones) -> https://translations.launchpad.net/ubuntu/utopic/+source/account-polld/+imports?field.filter_status=NEEDS_REVIEW&field.filter_extension=pot
<pitti> dpm: ah, so if we reject those, the corresponding .po files will be discarded, too?
<pitti> dpm: https://translations.launchpad.net/ubuntu/utopic/+source/account-polld/+pots/account-polld looks fine, after all
<pitti> hm, there are no approved/imported POTs though
<barry> mterry: what does "Needs team bug subscriber" mean?
<pitti> dpm: ah, this is apparenlty a project which doesn't have a pot upstream, so I guess we can just pick any pot and use that
<dpm> pitti, yes, it seems the translations for the generic template have been imported already. It might be that the imported translations have already been removed from the queue. When was the upload done?
<infinity> barry: Means that the package needs a team subscribed to bugs that will take responsibility for them.
<pitti> dpm: not sure, but the files have been waiting for a month or so, so presumably a while ago
<dpm> pitti, POT-Creation-Date: 2014-08-11 15:35-0300
<pitti> dpm: so what I don't understand is why LP shows translations at all as it doens't seem to have any pot file?
<doko> zul, you are a bad lier, try harder next time ;-P #1367747  http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg might help
<dpm> so at that point the template was uploaded and imported, along with its .po files
<pitti> dpm: OTOH https://translations.launchpad.net/ubuntu/utopic/+source/dialer-app/+imports?field.filter_status=all&field.filter_extension=pot doesn't show anything either
<infinity> barry: For Foundations MIRs, that's ~foundations-bugs
<pitti> dpm: so I take it that LP just doesn't show already imported/approved POTs (<- wgrant)
<pitti> dpm: so I'm just going to reject these extra POTs, ok?
<mterry> barry, we try to avoid having packages in main that no one is caring for -- so at minimum, please find a team that is willing to look after the package in Ubuntu and subscribe to its Ubuntu bugs
<dpm> pitti, they don't appear in the queue as they were imported a month ago. It clears them from the queue a while after they've been imported
<zul> doko: pysnmp4?
<dpm> pitti, actually, that's something I wanted to talk about with you
<wgrant> pitti: lib/lp/translations/interfaces/translationimportqueue.py:    RosettaImportStatus.IMPORTED: timedelta(days=3),
<pitti> dpm: I'm just looking at bug 1356939 and will build new langpacks now
<ubottu> bug 1356939 in sync-monitor "List of authorized applications aren't localized" [Medium,Confirmed] https://launchpad.net/bugs/1356939
<wgrant> Imported queue entries will be deleted after three days.
<doko> zul "Dependencies: All in main."
<pitti> wgrant: ah ok, so that's normal; thanks!
<dpm> pitti, http://pastebin.ubuntu.com/8309319/
<zul> doko: uh i didnt write the MIR for that
<barry> mterry, infinity for a while i've thought ubuntu could use a python team like debian, but for now, foundations-bugs would work.  i'll subscribe that team to nose2 (i am primary maintainer in debian so it seems reasonable)
<wgrant> pitti: However, it seems like pkgstriptranslations is being a bit overzealous in some cases. On at least several packages we're seeing POTs and POs imported from both the source dir and the arch-specific build dir.
<mterry> barry, OK cool
<dpm> pitti, so in a nutshell, is there something we can do not to generate a .pot file for each architecture? It clutters the imports queue 3x more than necessary
<pitti> wgrant: yeah, I guess we need to pick just one of those then; there are some (many?) packages which don't have a POT in the upstream source, or it's out of date, so it gets generated during package build
<dpm> and the queue is just horrible as it is without duplicate arch-dependent .pots :)
<barry> mterry: done.  should i toggle the nose2 mir back to new?
<doko> zul, https://bugs.launchpad.net/ubuntu/+source/python-oslo.utils/+bug/1367747 thinks otherwise ...
<wgrant> pitti: Right. Perhaps the build systems should be fixed to use a prefix not including the architecture.
<ubottu> Launchpad bug 1367747 in python-oslo.utils (Ubuntu) "[MIR] python-oslo.utils" [High,New]
<pitti> dpm: not easy, due to the problem above; we could stop importing translations from anything but i386 perhaps
<pitti> wgrant: yeah, that's a cmake-ish thing, but I doubt we can/should fix it downstream
<wgrant> Ah, that makes sense.
<zul> doko: we were talking about snmp4 werent we? if not ill fix oslo.utils
<pitti> but perhaps building translation tarballs only for i386 and arch: all would suffice
<wgrant> Right, it's always seemed a bit weird.
<infinity> pitti: And that would lose translations on anything that doesn't build on i386.
<wgrant> We coalesce entries with the same paths.
<dpm> wgrant, we have some filtering in the imports queue already, IIRC. Would it be possible to filter out anything that looks arch-dependent?
<pitti> infinity: right; question is, would that actually affect pacakges with translations
<wgrant> dpm: That's pretty difficult to judge.
<pitti> yeah, same ^ for pkgbinarymangler
<pitti> it doesn't know what happens on other arches
<infinity> pitti: It might.  I'd rather not introduce the obvious bug.
<mterry> barry, yeah just comment on the bug is fine, that's enough so that I'll notice and look at it again
<dpm> wgrant, all of them seem to start with "obj-x86_64-linux-gnu/src/launchpad.net/" or rather "$ARCH/src/launchpad.net/"
<barry> mterry: ack
<pitti> infinity, wgrant, dpm: it seems to me that the most robust place to filter this would be to ignore/unify multiple pots with the same name
<wgrant> dpm: The pattern is usually rather obj-$TUPLE/$PATH
<wgrant> But I'm reluctant to hardcode a list of tuples :)
<pitti> it should be ok to take any pot in that list
<pitti> wgrant: yeah, please let's not do that
<wgrant> pitti: I don't think that's safe.
<wgrant> But I'd need to check
<wgrant> eg. it's very plausible to have src/foo.pot and doc/foo.pot
<pitti> wgrant: no, that'd be utterly wrong
<pitti> a POT file name must be called like the translation domain
<dpm> indeed, that'd rather be src/foo.pot and doc/foobar.pot
<zul> doko: python-oslo.i18n is in main, but python3-oslo.i18n is in universe
<wgrant> Perhaps.
<wgrant> It then becomes unclear how to autoapprove the POs.
<wgrant> The POT filenames may be the same, but we rely on the template path to work out where various translation paths belong.
<pitti> ah, that's right
<doko> zul, hmm, no, it is in main, but still wants to demote ...
<zul> doko: i can disable snmp4 in ceilometer its not a hard dependency
<zbenjamin> jdstrand: ok, and for scopes? for them no TMPDIR is set
<jdstrand> zbenjamin: you have a choice: @{HOME}/.local/share/unity-scopes/leaf-net/@{APP_PKGNAME}/ or /run/user/[0-9]*/scopes/leaf-net/@{APP_PKGNAME}_@{APP_APPNAME}/
<jdstrand> APP_PKGNAME is the "name" field in the click manifest. APP_APPNAME is the key in the hooks database
<zbenjamin> jdstrand: ok, atm i derive those values from the appid in confinement. Is there a better way?
<jdstrand> zbenjamin: note, we wanted TMPDIR set for scopes (see bug 1327426) but the scopes team disagreed
<ubottu> bug 1327426 in unity-scopes-api "scopes runner should set various confinement variables" [High,Fix released] https://launchpad.net/bugs/1327426
<jdstrand> zbenjamin: just chop of _$version
<jdstrand> off*
<jdstrand> APP_ID is ${APP_PKGNAME}_${APP_APPNAME}_${APP_VERSION}
<zbenjamin> jdstrand: yeah thats what i do,  for scopes _$version is not defined
<zbenjamin> jdstrand: also not APP_ID btw ;)
<zbenjamin> i had to pass it as a argument to the script
<jdstrand> right, they are for some reason fundamentally opposed to env variables
<zbenjamin> jdstrand: yeah afaik they derive the appid from the ini file name
<doko> zul, it's not oslo.config, but oslo.utils
<jdstrand> and they have an api for writable dirs that scopes use
<doko> new b-d of heat
<doko> no, keystone. heat needs python-saharaclient
<zul> doko: ah ok
<nik90> stgraber: ping (lxc)
<zul> doko: can you open up a bug ill get to that today
<doko> zul: the pysnmp4 MIR's are assigned to jdstrand. so maybe make up your mind before he starts working on these
<zul> doko: yeah
<zbenjamin> jdstrand: btw how is fat packaging supposed to work for scopes? they don't use the gnutriplet in the path to their libs afaik
<jdstrand> zbenjamin: I thought the agreed to updating LD_LIBRARY_PATH. you might ask michi
<jdstrand> they*
<zbenjamin> jdstrand: hm thats how the current template for scopes creates the click package tree http://pastebin.ubuntu.com/8309447/
<jdstrand> they may not suppot fat packages
 * jdstrand doesn't know
<hallyn> pitti: doko: it might be best to keep cgroup-lite in main for now.  i don't know how heavily libvirt's cgmanager patch (which is out-of-tree) has been tested.  i use it here with no problems, but ...
<infinity> doko: Oh, you were pinging people about firefox on arm64/ppc64el last night, so I got grumpy and fixed it.
<jdstrand> I filed that bug in an effort to get various env vars set for developers, etc
<pitti> hallyn: so apparently it doesn't depend on/recommend cgroup-lite then?
<tedg> slangasek, i can haz systemd-shim 8 ?
<zbenjamin> jdstrand: ok thx for the infos :)
<LocutusOfBorg1> can anybody please move insighttoolkit4 to release? needs a couple of rebuilds
<pitti> skipped: insighttoolkit4 (0 <- 24)
<pitti>     got: 58+0: i-58
<pitti>     * i386: nifti2dicom, plastimatch, qnifti2dicom
<pitti> LocutusOfBorg1: ^
<pitti> LocutusOfBorg1: we can't (well, "won't") manually move it to release, the transition needs to be finished in -proposed first (then it'll go in automatically)
<LocutusOfBorg1> isn't this what I asked? :)
<hallyn> pitti: libvirt-bin should depend on cgmanager | cgroup-lite
<LocutusOfBorg1> I meant a couple of rebuilds in proposed and than will move automagically to release, or not?
<pitti> hallyn: ah, and since cgmanager is in main and the prefrerred dep, it would never actually install cgroup-lite
<hallyn> docker depends on cgroup-lite, but it's in universe.  so technically cgroup-lite can be pulled out of main
<hallyn> right
<mlankhorst> is it ok to start uploading other packages depending on the new xorg-server with forced dep-wait?
<mlankhorst> going to be a lot of packages
<doko> hallyn, can you seed it please?
<hallyn> doko: assuming i have the perms, i can look into it.  (i think i've got notes from 2 years ago sitting around)  you mean pull cgroup-lite out of the server seed?
<doko> pitti, Riddell, ScottK: please could you have a look at the phonon autopkg test failures. this looks "shellish" too ...
<doko> hallyn, not out of, but maybe into?
<pitti> doko: phonon doesn't seem to have any tests in the first place?
<pitti> doko: oh, you mean its rdeps
<doko> pitti: but it triggers ...
<hallyn> hmm
<pitti> kscd succeeded this morning, now fails again on real test failures (not the ".shell not found)
<pitti> I'll retry that one
<pitti> eh, WTH
<hallyn> doko: thinking a bit, i think it's better it be dropped
<doko> hallyn, ok, done
<pitti> doko: yes, putting on my list
<mlankhorst> ok inc :-)
<stgraber> nik90: pong
<hallyn> doko: thanks
<nik90> stgraber: hey I just created my first unpriveldges container after following your tutorial. When I run lxc-ls -f it shows the ip4 address which in your blog post is unknown
<nik90> stgraber: is my container still running as unpriveldged?
<nik90> I am not running lxc-create as root,
<stgraber> nik90: yes, it took us a while to get IP addresses from unprivileged containers but LXC 1.0 does support it and so it's normal you see it now
<nik90> stgraber: when running unprivileged, would my container still be able to access a nexus 4 device that I attach to the host?
<stgraber> if you want to make sure your container is unprivileged, you can confirm with something like "ps u $(lxc-info -n container-name -p -H)" which will show you the uid your container is running as in the first column
<nik90> stgraber: my goal here is run qtcreator (for ubuntu touch apps development) and use the lxc container to avoid overhead of a vm
<nik90> ah ok
<stgraber> nik90: it's certainly possible to make it work but it will need some creative configuration I suspect
<nik90> stgraber: the n4 device part will be tricky? or just running qtcreator itself?
<nik90> stgraber: I will follow your approach that you mentioned for running skype and see if that also works for qtc since both are qt based apps
<nik90> stgraber: and see where I get from there
<stgraber> nik90: so if you run qtcreator as your own user (with a straight uid/gid mapping for that one as I do in my chrome blog post) then all you should need is "lxc.mount.entry = /dev/usb dev/usb none bind,create=dir" in your container config
<stgraber> so if uid 1000 in the container == uid 1000 outside of it (through the special mapping), then the user running qtcreator in the container will also have access to the /dev/usb/ entry for the adb device and will be allowed to connect just fine
<nik90> stgraber: ah cool
<nik90> stgraber: Does the uid of the host user change on reboot or something?
<nik90> stgraber: I just checked that my user uid, gid is 1000
<nik90> if it doesn't change, then this should all be a one-time configuration
<stgraber> nik90: nope, it's constant, otherwise file ownership would be a mess :)
<stgraber> nik90: the only case you'd care about doing something a bit more generic is if you plan on sharing this with other people as if they have multiple users on their system, their own user may be 1001 or something
<nik90> stgraber: sry, all I am doing atm is following your blog post commands while trying to understand bits of this. ;)
<nik90> stgraber: understood
<mterry> barry, you broke my nose2 page...  The LP page for nose2 now gives me timeouts ever since you added a team!
<barry> mterry: sweet!
<mterry> barry, so while I can't verify what you did, I'll trust that you did it
<barry> :)
<cjwatson> doko: libparted-i18n, gfxboot-themes> fine
<cjwatson> mvo: hm, maybe s/minimal/required/ for that then
<doko> denoted
<mvo> cjwatson: thanks for the hint, let me try that
<cjwatson> mvo: or actually, how about s/minimal/build-essential/ ?
<mvo> cjwatson: !!!
<cjwatson> mvo: feels like a slightly better fit given that we have --variant=buildd
<mvo> cjwatson: yeah, it will simplify the chroot generation code even further
<mvo> cjwatson: I test the changes now :)
<zbenjamin> jdstrand: quick question, can a confined app conntect to any session dbus interface?
<jdstrand> zbenjamin: it can connect to the session bus. it may or may not be able to talk to services on the session bus (depending on the service)
<zbenjamin> jdstrand: lets say i export a interface from the launcher (it would make it more reliable to get the configuration into the helper script)
<jdstrand> that would not be allowed
<zul> doko: ping
<zbenjamin> jdstrand: ok thanks
<jdstrand> that interface could be added to the debug policygroup
<jdstrand> zbenjamin: ^
<doko> zul, just jump on
<zul> doko: there was an MIR for python-oslo.i18n already LP: #1349497
<ubottu> Launchpad bug 1349497 in python-oslo.i18n (Ubuntu) "[MIR] python-oslo.i18n" [High,Fix released] https://launchpad.net/bugs/1349497
<zbenjamin> jdstrand: nah, it seems to work fine now, as long as my confinement tests don't return different values in the 2 scripts it should be fine.
<cjwatson> doko: python-oslo.i18n - you did change-override wrong, you overrode just the binaries and not the source
<cjwatson> doko: -S when processing MIRs, please
<doko> cjwatson, oops
<doko> cjwatson, did you fix, or should I?
<cjwatson> doko: I did not
<doko> ok, will do
<zul> doko: can you double check python-osprofiler and python-rfc6839 while you are at it
<doko> zul: have a look at the commit message
<doko> they are in main
<zul> doko: cool thanks
<mvo> cjwatson: one more question - right now we install ubuntu-ui-toolkit-doc in the click chroot, is that something we want to do or could we drop it, it feels a bit out of place
<hallyn> slangasek: regarding bug 1355966, should i mark it as also afecting cgmanager, or file a new FFE for cgmanager?
<ubottu> bug 1355966 in systemd-shim (Ubuntu) "[FFE] Implement AbandonScope (etc)" [High,Triaged] https://launchpad.net/bugs/1355966
<cjwatson> mvo: bzoltan explicitly asked for that, I think so that the SDK can show matching docs
<hallyn> since FFE was granted for systemd-shim i'd feel guilty usurping that for cgmanager, but as systemd-shim will block on cgmanager...
<mvo> cjwatson: ok, thanks! does it feel cleaner to you to add it to the ubuntu-sdk-libs-dev or have it as a special case in chroot.py - I lean toward the later
<cjwatson> mvo: marginally prefer the former but your call
<mvo> cjwatson: heh :) totally fine as I did it this way but had second thoughts :)
<roaksoax> is it safe to put stuff like "find /var/log/maas -not -user syslog -print0" in postinst scripts?
<slangasek> hallyn: did you want to merge cgmanager into utopic or should I?  And does system-shim 8 need a versioned dependency on cgmanager 0.32 for any reason?
<hallyn> systemd-shim needs a versioned dep, yes.
<hallyn> the binary will refuse to run without cgmanager api version 8 anyway
<slangasek> hallyn: bug #1355966> feel free to mark it as also affecting cgmanager
<desrt> slangasek: we're using the new Prune and GetTasksRecursive APIs
<ubottu> bug 1355966 in systemd-shim (Ubuntu) "[FFE] Implement AbandonScope (etc)" [High,Triaged] https://launchpad.net/bugs/1355966
<slangasek> ack
<zul> doko,  python-oslo.utils should be ok now correct?
<desrt> should have pointed that out louder in the NEWS -- sorry
<zul> doko: also just subscribed server team to python-oslo.utils\
<hallyn> slangasek: ok, marked it affecting cgmanager;  all the ubuntu delta is obsolete so a straight syncpackage is fine
<slangasek> hallyn: ok; are you doing that sync?
<hallyn> sure, doing it now
<slangasek> cheesr
<doko> zul, afk now.
<doko> zul, stevedore: unsatisfied dependencies, please drop the python*-argparse deps
<zul> doko: k
<slangasek> desrt, hallyn: systemd-shim 8-1 accepted into Debian unstable
<desrt> nice!
<desrt> i tried extra hard to make sure this one doesn't have any root exploits
<hallyn> warm fuzzies - they elude me
<slangasek> did that trying include asking the security team for review? :)
<desrt> slangasek: yes.  precisely.
<slangasek> ok
<desrt> policy says that systemd-shim only takes messages from already-root users anyway though, right?
<slangasek> pitti: do you understand this adt failure?  it seems to be having parsing problems with files that haven't changed: https://jenkins.qa.ubuntu.com/job/utopic-adt-systemd-shim/28/ARCH=amd64,label=adt/console
<Noskcaj> Laney, Could you please refresh lp:~laney/ubuntu-system-settings/upower0.99
<hallyn> slangasek: i've got a bit of a bugfix for cgmangaer for debian to queue up :(  not must-be-tonight urgent, but anyone using gettaskrecursive (which systemd-shim now uses) inside a container will cause cgmanager to restart
<hallyn> (sigh) i'd say i'll push it in 2 minutes, but my downloads from archive.* seem to be constantly hanging today.  some net neutrality thing?
<hallyn> hm, is it ipv6 messing me up?
<hallyn> slangasek: cgmanager_0.32-2_source.changes pushed to mentors
<hallyn> d'oh, another one
<slangasek> another?
<slangasek> hallyn: as in, another upload pending?
<hallyn> slangasek: yeah, fraid so.  i will push in 2 hours
<slangasek> ok
<slangasek> so shall I hold off?
<hallyn> slangasek: the other one won't break anything, so pushing now might be ok
<hallyn> but holding off should be fine too, i dont' expect anyone to hit this.
<hallyn> (sorry, being pulled away - bbl)
#ubuntu-devel 2014-09-11
<andrewrk> is the fix for the fact that GtkStatusIcon does not work with Unity included in Utopic?
<slangasek> desrt: so mbiebl_ has reopened Debian bug #756076, saying that systemd-shim 8-1 doesn't actually work with logind
<ubottu> Debian bug 756076 in systemd-shim "does not cleanup sessions when user logs out: No such interface 'org.freedesktop.systemd1.Scope'" [Important,Open] http://bugs.debian.org/756076
<slangasek> hallyn: cgmanager 0.32-2 uploaded
<ScottK> So is phone a long term fork of the regular distro now?
<ScottK> (trying to figure out how Oli's email relates to other stuff)
<slangasek> no
<slangasek> the exact release cycle alignment is TBD
<slangasek> this merely stipulates the cycle by which updates are made available to phone end users
<ScottK> OK.  Given the content of the updates, I don't see alignment with distro release/updates.
<ScottK> Maybe someone that understands both could propose how they might relate.
<hallyn> slangasek: thanks.  (the other bug is just the recursive proxy fn calling the on-recursive main fn)
<hallyn> slangasek: 0.32-3 pushed to mentors, but if you want to wait on that that should be fine.  it can probably wait until 0.33 for that matter
<hallyn> (which should have the listkeys method stgraber needs)
<slangasek> hallyn: uploaded
<hallyn> slangasek: thanks!
<hallyn> will sync into utopic tomorrow.
<hallyn> that's where i expect some bug reports through systemd-shim in containers
<Mirv> if there's a core-dev around wanting to help, there'd be a packaging ack to ack or nack which changes a funny build-dep to a useful build-dep now that they apparently use it https://ci-train.ubuntu.com/job/ubuntu-landing-010-2-publish/19/artifact/packaging_changes_ubuntu-ui-toolkit_1.1.1239+14.10.20140908-0ubuntu1.diff
<pitti> Good morning
<pitti> slangasek: yes, I understand it (bit of a long story); I added an ugly workaround last night and will now fix that properly
<pitti> slangasek: can you please push systemd-shim to bzr? I'll do an 8-1exp1 upload now to rebuild against 215
<slangasek> pitti: yep, pushed
<pitti> slangasek: cheers; mbiebl wants to upload 215 to unstable RSN, so that double-upload won't be necessary any more
<slangasek> Mirv: looking at this diff, I'm more concerned about the dropping of qml files from a package that's part of the SDK - are we sure this isn't an API break?
<Mirv> bzoltan: http://pastebin.ubuntu.com/8315784/
<Mirv> bzoltan: so that's regarding the Colors/*.qml
<Mirv> bzoltan: what about apps that use them?
<bzoltan> Mirv:  none of the System and Core apps are using that, but let m check
<bzoltan> Mirv: slangasek: the Colors/*.qml is not the part of the API offering. No apps should directly use those files.
<slangasek> Mirv, bzoltan: ok, packaging changes acked
<bzoltan> slangasek:  thank you :) and thanks for being alert
<Mirv> thanks!
<mvo_> jamespage, jamespage_: is  lp:~james-page/software-properties/juno-support  stillrelevant? if so, I have a look now
<dholbach> good morning
<doko> stgraber, zul: looking at the python-lxc package in NEW. is there a reason that you don't build a python3-lxc package?
<doko> pitti, jibel: please give back the python3.4 autopkg test on i386
<pitti> doko: already done
<doko> thanks
<doko> NBS empty \o/
<pitti> hooray! and so much before release!
<pitti> s/much/long/
<nik90> stgraber: hey, so I was able to open qtcreator running in the lxc :) I used pretty much the same config you used for google chrome.
<nik90> stgraber: I am running into 2 issues which I couldn't fix, the first being able to detect a connected N4 phone (/dev/usb doesn't seem to exist) and second being able to create a schroot inside qtcreator.
<nik90> stgraber: On trying to create a schroot, I get the following message http://paste.ubuntu.com/8317272/
<nik90> stgraber: in particular the line "E: Cannot install into target '/var/lib/schroot/chroots/click-ubuntu-sdk-14.10-armhf' mounted with noexec or nodev" seems interesting. I don't see any lxc.mount statement which does this. Anyway I can change that to allow creating a schroot
<nik90> stgraber: sry, I meant can I change that to allow creating a schroot?
<doko> robru, dbus-test-runner autopkg tests fail after your recent upload
<doko> glance (1:2014.2~b2-0ubuntu2 to 1:2014.2~b3-0ubuntu1)
<doko> Maintainer: Ubuntu OpenStack
<doko> 4 days old
<doko> python-glance/i386 unsatisfiable Depends: pyhton-osprofiler
<doko> python-glance/i386 unsatisfiable Depends: python-ordereddict
<doko> Not considered
<doko> zul, jamespage: just another typo, don't know about python-ordereddict
<shadeslayer_> mvo_: poke
<victorp> popey, ping
<popey> hello victorp
<mvo_> hey shadeslayer_ - I'm about to leave for lunch, but I will read scrollback and can answer when I'm back
<mvo_> shadeslayer_: unless its quick in which case I can answer right away :)
<shadeslayer_> mvo_: any ideas if appstream in lp is something you will be working on?
<mvo_> shadeslayer_: I plan to work on client side support in apt to make the content fetching a (optional) part of apt-get update. but nothing more is planed on my part right now
<shadeslayer_> mvo_: right, but how would content generation work ?
<shadeslayer_> I.e. extract appstream data from packages
<doko> pitti, infinity: is the glibc/langpack merge still scheduled for 14.10?
<cjwatson> doko,stgraber,zul: there's already a python3-lxc in the archive, built from separate source
<doko> ahh, ok
<doko> then I'll accept the one in NEW
<doko> jamespage, zul: python-oslo.utils MIR is incomplete
<Mirv> doko: I got datetime - module not found with python 2.7 on utopic. downgrading to 2.7.8-6ubuntu1 fixed my issue.
<Mirv> running lp:click-toolbelt
<doko> Mirv, works here
<doko> Mirv, so please be more specific
<doko> there was a change, it is now a builtin instead of an extension
<Mirv> doko: yes, I filed bug #1368144 about it now. maybe I'd need to recompile it or something, but at least that's what happens when executing the old ./click-toolbelt with new python. I must admit that click-toolbelt is a bit confusing beast to build for me, so I've tended to use the existing one when possible.
<ubottu> bug 1368144 in python2.7 (Ubuntu) "ImportError: No module named datetime with lp:click-toolbelt" [Undecided,New] https://launchpad.net/bugs/1368144
<Mirv> I know that simple import datetime still works
<cjwatson> python-saharaclient needs an MIR from somebody who cares about python-heat
<doko> Mirv, is there a virtualenv involved?
<Mirv> doko: yes. so, if this is expected, feel free to mark as invalid. just reporting the oddity.
<jamespage> doko, ack - will followup with zul when he starts
<jamespage> looking at oslo.utils now
<doko> Mirv, I guess the python executable is copied into it, but not the standard extensions.
<doko> jamespage, just fyi, https://launchpad.net/ubuntu/+source/tuskar/0.4.2-2/+build/6072038, requires new nova
<cjwatson> shadeslayer_,Riddell: somebody needs to refresh the kubuntu-plasma5 PPA for the libav11 transition, it seems
<cjwatson>  libkf5filemetadata-bin : Depends: libavformat55 (>= 6:10~beta1~) but it is not installable
<cjwatson>                           Depends: libavutil53 (>= 6:10~beta1~) but it is not installable
<cjwatson> that's the root of the current image build failure
<shadeslayer_> cjwatson: we're all at Akademy, with shit internet
<shadeslayer_> so it's going to be hard to get to it before Monday
<cjwatson> looks like just that one package
<shadeslayer_> I'll try
<cjwatson> it's probably just a straight rebuild of kfilemetadata-kf5
<cjwatson> shadeslayer_: oh wait, I apparently have upload privileges
<shadeslayer_> ack
<shadeslayer_> cjwatson: oh awesome :D
<cjwatson> things I did not know.  I'll sort it out then
<cjwatson> and I'll not bother with next-staging since it's uninstallable right now anyway ...
<jamespage> doko, ack
<doko> mlankhorst, are there still some xserver binaries to remove?
<doko> mlankhorst, should x11-xfs-utils really be demoted?
<zul> doko/jamespage: ack
<sil2100> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sil2100
<pitti> cjwatson: what was the trick again to tell "apt-get -o Dir::Etc::sourcelist=/dev/null" to not remove already downloaded indexes again from /var/lib/apt/lists?
<pitti> or mvo_ ^
<cjwatson> pitti: --no-list-cleanup
<pitti> I'd like to only download the indexes from one added source (a local file:// or a PPA), for efficiency
<pitti> cjwatson: ah, cheers!
<mvo_> pitti: APT::Get::List-Cleanup=false
<mvo_> aha, or the other one :)
<cjwatson> but I'm not sure whether that still forgets that the packages from the other sources exist
<pitti> mvo_: ah thanks, "apt-config dump|grep -i clean" (or "grep -i list") didn't give anything, but it's indeed in the manpage
<pitti> cjwatson: at least apt-cache policy seems happy
<cjwatson> cool
<pitti> sudo apt-get --no-list-cleanup -o Dir::Etc::sourcelist=/etc/apt/sources.list.d/canonical-x-x-staging-utopic.list -o Dir::Etc::sourceparts=/dev/null update
<pitti> that seems to by and large do what I want
<pitti> and like 50 times faster :)
<mvo_> pitti: great
 * pitti puts that into autopkgtest and checks whether all the tests are still happy
<sil2100> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
 * sil2100 lunch o/
 * dholbach hugs sil2100
 * sil2100 hugs dholbach back
<dholbach> :)
<pitti> dpm: could you please add http://people.canonical.com/~dpm/data/ubuntu-l10n/ for 14.09 (ubuntu-rtm)?
<sil2100> ;)
<dpm> pitti, yes, I'll have to talk to wgrant on how to do it. It requires setting up a cron job for an exporter script in LP, and I'm assuming we can do it for ubuntu-rtm/14.09 in the same way we can do it for ubuntu series
<pitti> yeah, it's pretty well the same
<pitti> wgrant: I just filed bug 1368209, I can't explain that myself
<ubottu> bug 1368209 in Launchpad itself "RTM langpack export is missing some domains" [Undecided,New] https://launchpad.net/bugs/1368209
<pitti> dpm: I added a WI to https://blueprints.launchpad.net/ubuntu/+spec/qa-u-spanish-translations FYI
<dpm> thanks pitti, I'm on it
<pitti> dpm: cheers
<pitti> (just for tracking stuff)
<dpm> pitti, replied to that bug
<pitti> dpm: yes, unity8's domain is indeed "unity8"; I just diffed our current langpacks with some extra "directly from trunk" imports, I wondered about that too
<dpm> pitti, yeah, I was surprised that we pull unity as well
<dpm> along unity8, I mean
<sil2100> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sil2100
<pitti> dpm: yeah, it's in the package list, apparenlty something still keeps it in the seeds
<pitti> dpm: but yeah, that one can probably go
<pitti> dpm, wgrant: closed bug then, thanks!
<dpm> pitti, sent the RT, updated BP
<pitti> dpm: it's great to have you back :)
<dpm> pitti, thanks, it's great to have you, and I expect it to be for 10 more years at least! ;)
<wgrant> Oh
<wgrant> I was just going through them all to work out why you were wrong :P
<pitti> wgrant: I expected that I was, but I wanted to understand why :)
<flexiondotorg> cjwatson, dholbach is helping get some of the Ubuntu MATE package cleaned up.
<flexiondotorg> cjwatson, I am also wondering what format I should provide Ubuntu MATE SYSLINUX themes in? I have theme, just not sure if they should be packaged as debs?
<desrt> hallyn: looks like we have troubles :(
<dpm> seb128, quick question: the translations for indicator-transfer for the RTM distro don't seem to be enabled, and I don't see any templates in its import queue: https://translations.launchpad.net/ubuntu-rtm/14.09/+source/indicator-transfer/, whereas you showed me that the ones on ubuntu/utopic are: https://translations.launchpad.net/ubuntu/utopic/+source/indicator-transfer/ - any ideas why? I'm not quite sure how the upload workflow works between the two
<dpm>  distros
<seb128> dpm, hey, no idea how those imports work with pocket copies
<dpm> pitti, perhaps you know? ^
<seb128> dpm, pitti, oh
<seb128> it seems like that version just didn't get uploaded to rtm
<seb128> https://launchpad.net/ubuntu-rtm/+source/indicator-transfer
<seb128> dpm, let me file a sync request for it
<dpm> ah, that'd explain it, thanks seb128
<pitti> dpm, seb128: ATM I'm still syncing ubuntu langpacks to RTM
<pitti> as ubuntu-rtm langpacks are still blocked by some small things
<seb128> pitti, blocked?
<pitti> seb128: main thing for now is getting dpm's translation stats for RTM
<pitti> I think everything else is sorted out, I did some import queue approvals etc.
<seb128> pitti, how are stats blocking package copies?
<pitti> seb128: oh, they don't
<pitti> seb128: I mean RTM specific langpack builds
<seb128> oh, ok
<pitti> seb128: right now I do package copies as we haven't diverted too much
<seb128> right
<stgraber> doko, cjwatson: correct, we ship a python3-only binding as part of the upstream source and don't want to be backward compatible to python2 there. However openstack and some other distros (RHEL) don't ship or don't support python3 quite completely yet so we have that separate source tree with a python2 part of our binding. The main reason for the separation is that we support the python3 binding for 5 years whereas we have absolutely no inte
<stgraber> nik90: so schroot is going to be tricky I suspect. The reason is that this is an unprivileged container so it's restricted in what it can do since it's not real root. One thing it can't do is create device nodes and that may be what's upsettin schroot.
<stgraber> nik90: try adding lxc.aa_profile = unconfined to your config and see if that does the trick for schroot, but I doubt that'll be enough :(
<stgraber> nik90: as for /dev/usb, you did put "lxc.mount.entry = /dev/usb dev/usb none bind,create=dir" in your container's config right?
<sil2100> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<cjwatson> flexiondotorg: just send the updated images, in formats that match the Ubuntu ones
<flexiondotorg> cjwatson, So for Ubiquity I should submit a merge proposal to ubquity-slideshow.
<flexiondotorg> cjwatson, Where do I "send" the SYSLINUX theme too?
<nik90> stgraber: I tried  "lxc.mount.entry = /dev/usb dev/usb none bind,create=dir" but the container does not start anymore since /dev/usb doesnt exist
<nik90> stgraber: may be I should instead create a container as root
<nik90> stgraber: although everytime I open the gui app, it will ask for sudo priviledges I suppose
<cjwatson> flexiondotorg: ideally, a merge proposal against lp:~ubuntu-cdimage/debian-cd/ubuntu - the files go in data/utopic/
<cjwatson> you should see the layout there, such as it is
<flexiondotorg> cjwatson, Perfect. Thanks.
<stgraber> nik90: hmm, the point of create=dir is that it should be creating it... anyway, you can just mkdir /dev/usb and try again, that should work
<nik90> stgraber: ok
<hallyn> desrt: i don't see any bug reports
<doko> zul: just drop argparse everywhere. it's included in 2.7 and 3.4
<doko> mlankhorst, xorg-server ping
<desrt> hallyn: slangasek said that we got the original report reopen
<desrt> http://bugs.debian.org/756076
<ubottu> Debian bug 756076 in systemd-shim "does not cleanup sessions when user logs out: No such interface 'org.freedesktop.systemd1.Scope'" [Important,Open]
<hallyn> hm.  is there some 'we're done with this method' signal shim needs to send?
<desrt> ya.  the method return message :p
 * hallyn starts to suspect that comcast is anti-net-neutrality-ing the ubuntu archive
<hallyn> hm, no, i guess it is ipv6  70% [Connecting to us.archive.ubuntu.com (2001:67c:1562::15)] [Connecting to se
<hallyn> desrt: i'm trying ot update my system so i can test here
<desrt> me too
<hallyn> there we go, disalbed ipv6 in sysctl and now it works
<hallyn> maybe it's comcast.  i hope it's comcast
<hallyn> stgraber: ^ any known ipv6 bugs in the utopic kenrel right now?
<zul> stgraber: has the openvsiwtch support made it to utopic yet for lxc?
<stgraber> hallyn: nothing that I've noticed
<stgraber> zul: no
<zul> stgraber: is it?
<hallyn> stgraber: when will you be merging lxc into utopic?
<hallyn> stgraber: and ok, thx, i assume comcast is messing around then
<flexiondotorg> cjwatson, I'm looking for where I should inject the Ubuntu MATE gfxboot.cfg settings. Looks like in tools/boot/utopic/boot-*. Correct?
<stgraber> hallyn: once we're done getting the regressions out of master so I can finally tag alpha2
<hallyn> regressions?  pshaw
<cjwatson> flexiondotorg: yes
<slangasek> hallyn, desrt: note specifically that mbiebl says this problem was with logind from 215 after a rebuild of systemd-shim
<desrt> slangasek: not sure i understand why that would make a difference..
<slangasek> desrt: I'm merely pointing out the difference, in case anyone has difficulty reproducing it
<desrt> i just installed the update and am now rebooting...
<desrt> hmm... i have 208 here
<desrt> so he's right
<desrt> the cgroup gets cleaned up, but logind doesn't know about it
<desrt> i'll take a look
<desrt> maybe there should be a signal or something, indeed
<doko> zul: python-cliff has the same argparse problem
<zul> doko: ack
<flexiondotorg> cjwatson, Please could you cast an eye over my changes? If all looks good to you I'll submit a merge proposal - http://bazaar.launchpad.net/~ubuntu-mate-dev/ubuntu-cdimage/ubuntu-mate/revision/1898
<cjwatson> flexiondotorg: it's much easier for me to review after you submit a merge proposal - that's what they're for
<flexiondotorg> cjwatson, OK.
<cjwatson> you can always commit fixes on top after review (you don't need to resubmit the MP or anything)
<cjwatson> well, assuming you branched from the right place
<cjwatson> but looks like you did
<flexiondotorg> cjwatson, Merge proposal submitted. Thanks for your help.
<mlankhorst> doko: pong?
<doko> mlankhorst, are there still some xserver binaries to remove?
<mlankhorst> nvidia-173, glamor-egl, xserver-xorg-video-sis xserver-xorg-video-msm need to be gone
<mlankhorst> I've asked on #ubuntu-release, no reply yet afaik
<flexiondotorg> cjwatson, OK, that Merge proposal looks awfully wrong.
<flexiondotorg> cjwatson, I've submitted it against the wrong branch. I'll resubmit.
<mlankhorst> oops, xf86-video-msm (source package)
<mlankhorst> but after that it should migrate
<flexiondotorg> cjwatson, I don't appear to be able to submit a merge prospal against lp:~ubuntu-cdimage/debian-cd/ubuntu
<mlankhorst> doko: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt (near the bottom)
<cjwatson> flexiondotorg: just mail me the URL then, I'm firefighting something else and can't look now.
<flexiondotorg> cjwatson, Will do. Thanks.
<doko> mlankhorst, please can you file a bug and add ubuntu-archive to the subscribers
<mlankhorst> ok
<mlankhorst> actually that's going to be a bit hard from here... don't have sso access and won't work until monday
<mlankhorst> lets see..
<Elv1313> Is it possible to enable ppc and ppc64 build for PPAs? It doesn't seem so ( https://help.launchpad.net/Packaging/PPA#Supported_architectures ), but we got a bug report that the official package doesn't build for it and would like to add ppc to our PPA repository
<doko> no
<cjwatson> Elv1313: we may do so in future once we have virtualisation working, but it's not available yet
<Elv1313> ok thanks
<Elv1313> arm64 would also be nice
<cjwatson> arm64 is possible now, file a ticket on answers.launchpad.net/launchpad
<cjwatson> although it'll have to build through qemu
<Elv1313> (but we already have hardware to test that)
<cjwatson> qemu-user-static that is
<Elv1313> or cross compile
<dobey> PPAs don't do cross compiling
 * Elv1313 would not want to be the one setuping that
<cjwatson> dobey: (yet; I have been thinking about how to do that ...)
<Elv1313> Another question, is it totally too late to get an upgraded package into 14.10? We (sflphone) have made a release in July that fix all issues reported by errors.ubuntu.com and then some. The changes are too large to be considered a stable update. We have enough PPA users to have confirmation that this version is much more stable then the one currently in 14.10
<doko> mlankhorst, there are still reverse dependencies
<dobey> Elv1313: is it in main or universe?
<Elv1313> dobey: https://launchpad.net/ubuntu/utopic/+package/sflphone-daemon
<dobey> Elv1313: it's in universe, so it should be pretty easy to get a newer version in.
<cjwatson> it would be very helpful to get the new version into Debian first
<cjwatson> much easier then for us to just merge, and it helps more people that way
<Elv1313> dobey: Ok, thanks. If there any protocol to follow? I only pushed stable updates before, never totally new versions
<dobey> indeed. especially if it's already there, and the new version can drop the ubuntu-specific changes
<Elv1313> so email debian guys first?
<dobey> whoever maintains it in debian, yeah
<Elv1313> then, ask again or #ubuntu-devel or fill a launchpad bug?
<cjwatson> LP + here
<Elv1313> ok thanks
<RoyK> https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1364091 is this being worked on?
<ubottu> Launchpad bug 1364091 in mdadm (Ubuntu) "Possible RAID-6 corruption" [Undecided,New]
<smoser> hey.
<smoser> i have a upstart quesiton
<smoser> it seems from experimenting that a pre-start script does not get a kill on 'stop'. is that right ?
<slangasek> smoser: that doesn't sound "right", but perhaps there's a bug.  Maybe check the open bug list to see if it's a known issue?
<mlankhorst> doko: nvidia-173 still seems to be a possible fullfilment as dependency for boinc-nvidia-cuda in debian
<mlankhorst> but it works fine without
<mlankhorst> and -ati was fixed in -proposed to not need glamor-egl
<desrt> slangasek: i think this might actually be vaguely something like a logind bug
<desrt> slangasek: but it's a bug that wouldn't be a problem in normal circumstances, so that makes it our bug again....
<slangasek> desrt: bug-for-bug compatibility
<slangasek> welcome to Windows
<desrt> the problem is that we never properly signal the _start_ of the session, which leaves a stale job in the 'scope_job' field of the session in logind
<desrt> at logout time, logind sees this and assumes that it's the _stop_ job still in progress
<desrt> whereas abandon doesn't signal completion
<desrt> logind for this reason doesn't properly clear the scope_job field when issuing Abandon
<desrt> should have a test to fix soon...
<desrt> er... a fix to test :)
<slangasek> oh, I assumed you were being TDD ;)
<desrt> tests?  in systemd-shim?  surely you kid :p
<smoser> slangasek, http://paste.ubuntu.com/8321182/
<smoser> i think that illustrates my point.
<smoser> and now i'll bother you with what i was trying to do
<smoser> i was trying to block bringing up of network interfaces until some event had occurred.
<slangasek> smoser: are you expecting upstart to kill the sleep process?  that's not the main process of the job; the main process of the job is the shell
<smoser> it kills neither
<slangasek> so I would expect one of two things: 1) upstart kills the script, making it the shell's job to clean up the child process; or 2) upstart kills all related processes via cgroupy magic, and the shell doesn't get a chance to tell you what happened
<smoser> well, its neither :)
<slangasek> sure, understood
<slangasek> I just don't think your script here illustrates that particularly well :)
<smoser> i would have expected it to send SIGTERM to the script
<smoser> well, i avoided the handling of traps to simplify
<smoser> http://paste.ubuntu.com/8321199/
<slangasek> smoser: anyway, perhaps compare with wait-for-state, which does exactly this sort of thing with a main script instead of a pre-start script - I don't see that a pre-start gives you anything here (except, apparently, some bugs)
<smoser> ^ that one is what i was actually trying to do.
<smoser> pre-start allows you to block starting
<smoser> i dont think starting does
<smoser> er.. i dont think main script does
<slangasek> it does if you mark the job 'task'
<smoser> at least per comments in /etc/init/network-interface-security.conf
<slangasek> IIRC
<smoser> # Since we need these profiles to be loaded before any of the above services
<smoser> # begin running, this service must be a pre-start so that its pre-start
<smoser> # script finishes before the above services' start scripts begin.
<slangasek> smoser: see documentation of 'task' in init(5), which agrees
<smoser> that may be out of date.
<slangasek> or it may have never been true ;)
<slangasek> well, for the specific case of n-i-security, it applies because we care about those jobs ending in a 'started' state
<slangasek> you may care about that here also, in which case yeah, you can't 'task' it to work around a bug in pre-start handling
<smoser> where do you see information about task that you're pointing me at ?
<slangasek> I would say that at that point, the only workaround would be polling (ick)
<slangasek> smoser: the init(5) manpage?
<slangasek>       task   This stanza may be used to  specify  that  the  job  is  a  task
<slangasek>               instead.   This  means  that  the act of starting the job is not
<smoser> right.
<slangasek>               considered to be finished until the job itself has been run  and
<slangasek>               stopped  again,  but  that exiting with a zero exit status means
<slangasek>               the task has completed successfully and will not be respawned.
<smoser> i didn't understand that to mean exactly what you said.
<smoser> i'll try that.
<slangasek> implied is that, until the task is 'started', it doesn't release the starting event
<smoser> you're aying make my job a task
<slangasek> yes
<smoser> and make it 'script' instead of 'pre-script'
 * slangasek nods
<slangasek> and if you /still/ aren't getting signalled, then... ick
<smoser> hm..
<desrt> urg... every further step i take requires me to take one more
<smoser> slangasek, http://paste.ubuntu.com/8321639/
<smoser> thats my cloud-init-blocknet.conf .
<smoser> does not seem to block networking.
<smoser> as i can ssh in, and see a blocker running (cloud-init-blocknet (network-interface/eth0) start/running, process 465)
<slangasek> smoser: er, of course it doesn't block it, where's the word 'task'? :)
<smoser> bah
<smoser> ok.
<smoser> well that fixed that... now to figure out why it wasn't getting stopped.
<hallyn> jdstrand: oh hurray!  i've got apparmor-confined libvirt-lxc containers.
<jdstrand> hallyn: oh nice!
<hallyn> now, do we want to make these default?  i think we do, but maybe we'll break someone?
<jdstrand> I would say 'yes'
<hallyn> ok.  i'm going to add this to the libvirt 1.2.8 proposed package, then ping here on the FFE we're waiting on to push 1.2.8
<hallyn> jdstrand: one more thing, i notice that upstream libvirt-qemu abstraction has a sub-policy for running qemu-bridge-helper.  i'll add that to ours (in debian/apparmor/lbivirt-qemu) unless you say that's a bad idea
<jdstrand> no, that's good
<jdstrand> I think I reviewed it
<hallyn> cool
<blkperl> hi, I'm running into bug 1124250, would someone be able to push this bug forward?
<ubottu> bug 1124250 in nfs-utils (Ubuntu) "Partially incorrect uid mapping with nfs4/idmapd/ldap-auth" [Undecided,Confirmed] https://launchpad.net/bugs/1124250
<slangasek> blkperl: it doesn't appear that a fix is known, right?  does changing the settings in /proc/sys/kernel/keys, as discussed in the linked RH bug, have any effect?
<blkperl> slangasek: ok ill try that
<hallyn> jdstrand: apparmor policy will need a few tweaks though to let an ubuntu container run. :(
<jdstrand> hallyn: that's ok. that is thankfully not difficult
<hallyn> jdstrand: yeah but i suppose i ought to do it before uploading 1.2.8 (with default=on :)
<jdstrand> heh, yes :)
<jdstrand> pretty
<jdstrand> peer_addr="@/tmp/.X11-unix/X0ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Ø¹g#" peer="unconfined"
<sarnold> ooo
<jdstrand> jjohansen: fyi, it happens with peer_addr to (not surprising with shared code)
<jdstrand> jjohansen: this is what lsof gives me: http://paste.ubuntu.com/8322328/
<jdstrand> jjohansen: with my policy updates: http://paste.ubuntu.com/8322337/
<jdstrand> ok, wandering off for quite a while
<jdstrand> jjohansen: oh, hah, didn't mean to past that here
<jdstrand> paste
<hallyn> all right think i've got it
<hallyn> now who to ping about the FFE
<hallyn> oh.  i was wrong.  still hanging at /dev populating
<hallyn> sarnold: hey, so i'm getting this denial message:
<hallyn> type=1400 audit(1410473999.866:25): apparmor="DENIED" operation="mount" info="failed type match" error=-13 profile="libvirt-4b477da6-28c4-4497-87f1-bafeb853f90b" name="/sys/" pid=1711 comm="mount" flags="rw, nosuid, nodev, noexec, remount"
<hallyn> my policy does have 'mount fstype=sysfs -> /sys/',
<hallyn> what am i missing?  i need a separate remount rule?
<sarnold> hallyn: maybe? (at this point you've used the mount rules far more than I have.. :)
<hallyn> heh, yeah but at such long intervals tha ti don't remember anything from one instnace to the next :)
<hallyn> just allowing 'mount,' allows full container boot, so it's something lik ehtat...
<sarnold> hallyn: ah! this might explain it, "Specifically fstype matching currently only works when creating a new mount and not remount, bind, etc."
<sarnold> hallyn: hehe
<hallyn> oh, hm, then maybe th eproblem is our rule ot avoid remounting / ro ?
<hallyn> drat,
<hallyn> well i may just allow 'mount,' right now just to get this out the door
<hallyn> bc as it stands you can't stop a container once you start one :)
<hallyn> (bc of dnsmasq policy)
<sarnold> haha
<sarnold> that's .. awesome :)
<sarnold> watch out oracle, we've got our own "unstoppable linux"  :)
<hallyn> well that was my concern with the way the new unix class was written
<hallyn> it'll have the same sort of implications, but worse
<sarnold> hallyn: can you get away with a 'remount /sys/ -> /sys/,  rule?
<hallyn> (bc any confined daemon will have to be given the right to talk to another daemon over unix sock, aiui)
<hallyn> i'll try!
<hallyn> sarnold: holy schnickities.  that inexplicably makes the container instantly crash
<sarnold> hallyn: yikes
<hallyn> oh, i guess it doesn't like the rule,
<hallyn> 2014-09-11 22:28:58.685+0000: 1: error : AppArmorSetSecurityProcessLabel:617 : internal error: error calling aa_change_profile()
<sarnold> :(
<sarnold> sorry, I thoght that would work
<hallyn> uh oh, compiz is at 2.5G, probably time for a 'kill compiz from console after all windows freeze' soon
<hallyn> sarnold: hah, np, thanks for trying.  i guess i'll just try with all the remount flags it gives in the denied msg
<hallyn> all right now mountall is just being annoying
<hallyn> sarnold: got past the sys remount one, now mountall wants to remounta ll th eothers
<hallyn> drama queen
<sarnold> remount ALL the things!
<hallyn> yeah, and all separately.  so i need a remount options=(remount rw) -> /sys/fs/pstore as well as a remount options=(remount ro) -> /sys/fs/pstore,
<hallyn> but!  it works.
<hallyn> this is better than good enough for gov work.  ship it!
<hallyn> sarnold: thanks for the moral support :)
<sarnold> hallyn: oh man :/ you may be able to use remount options in (remount rw) ... options in (remount ro) ...   rules
<hallyn> sarnold: heh, that would be nice.  lemme try
<Logan_> xnox: naughty
<hallyn> sarnold: eh, i must not be getting the syntax right - but actually i think separately may be easier to read
#ubuntu-devel 2014-09-12
<pitti> Good morning
<Saviq> cjwatson, hey, do you have pointers on how to mk-sbuild for rtm?
<dholbach> good morning
<sil2100> pitti: hello! Could we ask you to re-run the i386 autopkgtest for network-manager?
<sil2100> pitti: the amd64 one seems to have passed
<sil2100> pitti: ah, ok, just learned it's a real regression, nvm!
<pitti> sil2100: right, already discussed that with cyphermox_ yesterday
<cjwatson> Saviq: no
<cjwatson> Saviq: it's awkward because debootstrap requires non-trivial fiddling to work for ubuntu-rtm.  You're possibly best off downloading the Launchpad buildd chroots from https://api.launchpad.net/devel/ubuntu-rtm/14.09/amd64 etc.
<doko> Laney, replied to #1368094
<Laney> ty
<xnox> Logan_: what's up?
<xnox> but 1368094
<xnox> bug 1368094
<ubottu> bug 1368094 in trusty-backports "Please backport openjdk-8 8u40~b04-2 (universe) from utopic" [Undecided,New] https://launchpad.net/bugs/1368094
<Laney> pad.lv/ :P
<jibel> jodh, I've two desktop machines running utopic that hangs on shutdown. It seems to stop on unmountfs. Any idea how I can debug that?
<jodh> jibel: have you recently added some remote filesystems to fstab? I'd remove splash and quiet from the boot options, add '--debug' (which will put both upstart+mountall in debug mode). You may want to create mountall.override containing 'console output'. Also https://code.launchpad.net/~jamesodhunt/ubuntu/trusty/sysvinit/log-open-files-on-shutdown/+merge/196141 could be useful (never made it into the
<jodh> distro alas)
<jibel> jodh, my fstab is rather basic http://paste.ubuntu.com/8326868/ , I already removed quiet and splash, that's how I found it stopped on unmounting filesystems. I'll add --debug and have a look at your patch.
<zul> doko: thanks for promoting python-oslo.utils, however launchpad says its in main but the archive thinks otherwise
<doko> zul: launchpad says "1 hour ago"
<doko> just wait
<zul> ok
<doko> glance (1:2014.2~b3-0ubuntu3) utopic; urgency=medium
<doko>   * debian/control: Fix typos.
<doko>   * debian/pydist-overrides; Add orderdict to overides.
<doko> zul: looking at the changelog I can't believe that you actually fixed typos ;)
<zul> doko: gee thanks
<dholbach> hey mlankhorst, how are you doing?
<dholbach> mlankhorst, do you think you'd need some more information for bug 1368784?
<ubottu> bug 1368784 in xorg (Ubuntu) "Utopic Virtualbox guest gets only up to resolution of 640x480" [Undecided,New] https://launchpad.net/bugs/1368784
<doko> pitti, just in case you are bored ... libcitygml seems to have some issues with the pkgbinarymangler
<pitti> I'm still trying to get out of IRC/meetings/backlog swamp; at this point I need to ask to send bug reports
<mdeslaur> slangasek: could someone from foundations please take over bug 1271591, it's really annoying on trusty
<ubottu> bug 1271591 in gnome-keyring (Ubuntu) "upstart job race prevents gnome-keyring from being ssh agent" [High,In progress] https://launchpad.net/bugs/1271591
<slangasek> jodh: ^^ can you have a look at this?
<jodh> slangasek: ack
<mdeslaur> slangasek, jodh: thanks
<smoser> slangasek, when you have a  minute, i'd appreciate some thoughts on http://paste.ubuntu.com/8327941/ . which is attempt block networking coming up until cloud-init-local has run (as it might write networking).
<Laney> whoops, had utopic-proposed on
<Laney> wonder how much crack I've got
<ogra_> the good stuff
<Laney> you install ogra's upload, very nice
<slangasek> pitti: hi, so bfiller has pointed out that libthumbnailer0 1.2+14.10.20140814-0ubuntu1 in ubuntu-rtm/14.09 is missing the corresponding ddeb.  Any idea?
<smoser> hallyn, can i ask lxc: what is the real/outside pid of pid X inside container named foo
<hallyn> smoser: no.  the kernel doesn't tell you that yet
<hallyn> there is a guy on lkml trying to push a patchset that would let us figure that out
<hallyn> but right now that info is simply not available
<hallyn> smoser: unless you can have a process inside the container send a ucred as SCM_CREDNETIAL to the outside task
<hallyn> the kernel will translate the pid for the receipient
<hallyn> that's how cgmanager=-proxy works
<smoser> but if i'm outside the container ?
<smoser> ie, i'm on outside. i want to figure out "whats the real pid of the container's pid 1"
<hallyn> well you could still write a program that setns's into the container's pidna and sends you a ucred
<hallyn> maybe i should write that
<smoser> how does 'lxc-stop' do it ?
<hallyn> it gets the pid from the lxc monitor
<hallyn> when a container starts, it starts a 'monitor' that respones to some commands over a unix sock
<hallyn> includidng "wha tis your pid" and "what is your cgroup"
<hallyn> and "stop"
<hallyn> so if you jus twant it fo ra container, you can do 'lxc-info -p -H -n $containername"
<hallyn> sorry, if that's all you wanted, i was overcomplicating :)
<hallyn> unheard of from me :)
<hallyn> smoser: is that all you needed?
<hallyn> i still may write that utility though
<smoser> actually, yeah. i think that is.
<smoser> so is there any difference then between:
<smoser>  pid=$(lxc-info -p -H -n "$name")
<smoser>  kill --signal=SIGQUIT $pid
<smoser> and
<smoser>  lxc-stop --name=$name
<hallyn> yeah, lxc-stop has some default behavior;
<hallyn> it'll send stopsignal first, or SIGKILL if that's not defined
<hallyn> oh no, first i'tll send SIGPOWER
<hallyn> which upstart will respond to kindly
<hallyn> then it'll send the quit signal
<stgraber> yeah, lxc-stop by default is SIGPWR + 30s wait + SIGKILL, that's all configurable though. So the equivalent to smoser's command would be to have the container starting with stopsignal=SIGQUIT and then running lxc-stop -n container --nokill which would send SIGQUIT but never SIGKILL
<stgraber> any container created by lxc should have a proper stopsignal set, either responding to the default SIGPWR or have the default config for the distro specify the right signal. Which means that lxc-stop -n blah is always the right way to cleanly stop a container and lxc-stop -n blah -k is always the right way to kill it immediately.
<smoser> thanks
<hallyn> think i'll write that pidtranslate tool tonight, maybe that'll obviate the need for a kernel patch
<hallyn> done, that wasn't too bad.  though making it not hang on bad info would take a bit more work
#ubuntu-devel 2014-09-13
<Mirv> if a core-dev or MOTU is around, please ack (approve) these quite simple build dependency (and make option) changes (the debian/* parts): https://ci-train.ubuntu.com/job/ubuntu-landing-008-2-publish/lastSuccessfulBuild/artifact/packaging_changes_dialer-app_0.1+14.10.20140912-0ubuntu1.diff + https://ci-train.ubuntu.com/job/ubuntu-landing-008-2-publish/lastSuccessfulBuild/artifact/packaging_changes_history-service_0.1+14.10.20140912-0ubuntu1.diff
<cjwatson> Mirv: ack both
<Mirv> thanks colin
<blkperl> slangasek: the workaround in the RH ticket does not seem to work
<slangasek> blkperl: doh.  You may want to follow up to the bug report with that info
<slangasek> (the Ubuntu bug report, not the RH one)
<blkperl> slangasek: yeah i updated the bug report
<blkperl> slangasek: can the importance be set to something, probably high or critical?
<slangasek> blkperl: so looking more closely, I'm not sure yours is the same bug, anyway.  this bug report is about a partially-incorrect uid mapping... but you have files in a directory which are all owned by the same user, some of which are shown correctly and some not, so it's not a truncated uid map problem?
<blkperl> slangasek:  the bug reporter has files owned by nfsnobody in the comments though
<slangasek> blkperl: yes, but it's not a case of some files showing correctly and some not when owned by the same user; the breakdown is along uid
<blkperl> slangasek: ok
<blkperl> yeah so I guess my bug is the same uid and gid are showing up as nfsnobody
<blkperl> slangasek: thats interesting, /run/rpc_pipefs/nfs is missing on a broken client
<blkperl> wait nvm that was because i turned off idmap
<blkperl> slangasek: sounds like this bug maybe, https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/976632
<ubottu> Launchpad bug 976632 in nfs-utils (Ubuntu) "nfs4 mounts are not mapping userids, uses nobody/nogroup" [Medium,Confirmed]
<blkperl> well maybe not
<slangasek> smoser: sorry for not getting back to you yesterday on http://paste.ubuntu.com/8327941/ - so all of the /run/cloud-init/local-finished stuff, is that a workaround for something?
#ubuntu-devel 2014-09-14
<bluesabre_> Hi Laney, if you're about, can you review https://lists.ubuntu.com/archives/devel-permissions/2014-September/000717.html ?
<smoser> slangasek, the local-finished is just to say "cloud-init-local already ran". which it could have run to completion before cloud-init-blocknet started.
<smoser> i'm out til monday, just figured i'd respond.
<smoser> later all.
<derek-g> What do you guys think about new Poettering idea about changing the way OS is being packaged: http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html
<ihashacks> derek-g: vommit on that and anything systemd related
<Laney> bluesabre_: should get to it tomorrow
<Laney> sorry nobody else did
<ScottK> mitya57: How come you didn't just sync pyqt5?
<camtron> Is it possible to write Unity lenses in C? (instead of C++ or Python)
<slangasek> smoser`: ah.  so the idiomatic way of doing that with wait-for-state would be to make sure cloud-init-local is in state 'started' once it finishes running, so that dependent jobs can key on the state
<mapreri> umh.. I'm unable to find any documentation about the differences between the amd64 and am64+mac isos. Any hint?
<Logan_> mapreri: http://askubuntu.com/a/40480
<mapreri> Logan_: thanks
<Logan_> np
<ubuntourist> I'm a newbie following the Ubuntu packaging guide and got the following error message:
<ubuntourist> dpkg-genchanges: error: badly formed line in files list file, line 1
<ubuntourist> The git repository I started with compiled and installed w/o incident.  All I'm trying to do is wrap it in Debian frosting.
<ubuntourist> (Specifically, I'm following http://packaging.ubuntu.com/html/packaging-new-software.html)
<maxb> That sounds like the "debian/files" file (which is supposed to be autogenerated) has somehow had bad data written to it
<ubuntourist> maxb: I forgot to mention, upon receiving the error I did "find . -name "*files*" and got no hits (other than two files in the source repository: files.html and files.js)
<maxb> Well that's odd.
<maxb> Is your packaging already in a git repository somewhere that I could clone and look at?
<ubuntourist> maxb: https://github.com/w3c/tidy-html5
<maxb> I don't see a debian/ directory in there
<ubuntourist> max: according to the documentation "bzr dh-make" should generate it, and it did. I don't use pastebin often. Is it just http://pastebin.com/ or is there a preferred other pastebin?  I can paste the console log/
<ubuntourist> .
<ubuntourist> maxb: according to the documentation "bzr dh-make" should generate it, and it did. I don't use pastebin often. Is it just http://pastebin.com/ or is there a preferred other pastebin?  I can paste the console log.
<maxb> pastebin.com is pretty heavy with ads
<maxb> paste.ubuntu.com is less so
<ubuntourist> http://paste.ubuntu.com/8346124/
<maxb> The thing you really need to bear in mind about dh-make is it just generates a starting point which will have *way* too much distracting boilerplate
<maxb> Expect to need to delete lots
<maxb> From all that "warning: ignoring deletion" stuff, I infer you've ended up with an .orig.tar.gz which contains the results of a previous build
<maxb> It would be a good idea to clean that up
<ubuntourist> maxb: Ah. The documentation only mentioned getting rid of the *.ex and *.EX example files.
<maxb> That's certainly part of it. A good principle to follow is the end result shouldn't contain anything you don't understand what it's there for :-)
<ubuntourist> maxb: That would leave me with an empty directory. ;-) I will pursue the purging.
<maxb> I am still somewhat confused by the ultimate error - I can't see what would be causing that
<maxb> There are four files in debian/ which are truly core: changelog, compat, control and rules
<maxb> You'll probably also have one named install by the time you're done.
<maxb> But limiting yourself to that subset to start with should help you cut through the distractions whilst you work on initial packaging
<ubuntourist> I have copyright, which was boilerplate but I copied the text of the distributed git into it.
<maxb> copyright is certainly required if you're aiming for official Debian/Ubuntu eventually, but doesn't have any functional influence on the package build
<ubuntourist> maxb: I'll get rid of the docs, README.*, source/format (and source/) and try again.
<ubuntourist> maxb: Other than those, everything else is in your list of core files.
<maxb> This package has a really quite weird Makefile install target
<maxb> ubuntourist: https://github.com/maxb/tidy-html5/commit/2ce2511c25a0dc6e017fca389654df4ff060f7b9
<ubuntourist> maxb: Thanks. I'll have a look and compare to what I've ended up with, to learn.
<maxb> I still don't understand how the "files list" error you had would have been caused - so all I can do is tell you that that commit results in a reasonable looking .deb for me
#ubuntu-devel 2015-09-07
<pitti> Good morning
<pitti> Unit193, sarnold: apport> that's controlled by /etc/apport/crashdb.conf; we  disable LP bugs for the final release, and only enable it around alpha-1 or so
<Mirv> mitya57: ok, great!
<diwic> hi, is it possible to use git branches in bzr-builder recipes?
<dholbach> good morning
<pitti> diwic: you can set up a bzr import of a git branch in LP
<pitti> diwic: I think that's the official workaround for now (I use it myself)
<pitti> hey dholbach, guten Morgen!
<dholbach> hey pitti
<diwic> pitti, ok, thanks - I tried that a few years ago and the importer wasn't good enough to deal with kernel trees (including merge commits), but maybe that has improved by now
<slangase`> @pilot out
<slangasek> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> diwic: ah, I don't know that; that might still be the case
<pitti> diwic: that'll probably also run for ages
<diwic> pitti, yeah
<pitti> diwic: you might be better off with a cron job on a canonistack instance?
<pitti> (which just uses the git checkout)
<diwic> pitti, that's what I'm doing now, but I figured I might be able to optimise the workflow by skipping that canonistack instance altogether
<pitti> diwic: for systemd (upstream) we use https://semaphoreci.com/, which is also quite nice
<pitti> diwic: that's triggered by github PRs, e. g. https://semaphoreci.com/systemd/systemd/branches/pull-request-1182/builds/1
<diwic> pitti, interesting
<doko> jamespage, fyi, https://launchpad.net/ubuntu/+source/python-pyeclib/1.0.8-2/+build/7767523
<jamespage> doko, aware - on my list as that dep chain for swift is all abit crappy right now
<doko> zyga, plainbox-provider-resource-generic (0.17-1 to 0.19-1)
<doko> Maintainer: Checkbox Developers
<doko> 45 days old
<doko> plainbox-provider-resource-generic/powerpc unsatisfiable Depends: dmidecode
<doko> plainbox-provider-resource-generic/ppc64el unsatisfiable Depends: dmidecode
<doko> Not considered
<didrocks> ogra_: when I download the raspberry pi 2 image, does it have ssh enabled by default?
<zyga> doko: ack, I know about this
<zyga> doko: thanks, I'll have someone look into it
<ogra_> didrocks, yep
<didrocks> ogra_: hum, weird, I think I have to plug a keyboard + monitor thenâ¦
<ogra_> why is that ?
<didrocks> ogra_: I did plug and setup nm as a local bridge
<didrocks> ogra_: but can't ssh to the raspy
<didrocks> I downloaded the pre-built image
<ogra_> you mean you set up a peer to peer connection via ethernet with NM ?
<didrocks> right
<ogra_> well, the RPi tries to obtain an IP via DHCP, make sure you have that bit enabled on the host
<didrocks> ogra_: perfect, connected now that I have the IPâ¦
<ogra_> ah :)
<didrocks> ogra_: yeah, the issue is NM not showing the IP of clients in the journal?
 * didrocks now greps the journal for the IP
<didrocks> ah, this time, I got the DHCPOFFER when replugging it
<didrocks> ok, all good, thanks ogra_ :)
<ogra_> awesome :)
<rbasak> pitti: I wonder if you have any comment on https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1423626? Seems like it should be consistent with your ifnames work.
<ubottu> Launchpad bug 1423626 in juju-core "Inconsistent device naming depending on install method - biosdevname/no biosdevname" [Medium,Triaged]
<pitti> rbasak: oh, do we still install biosdevname for server?
<pitti> rbasak: indeed it seems we should stop that
<rbasak> pitti: I don't really understand the current situation. It seems quite complicated.
<pitti> rbasak: we used to install biosdevname for server installs, but nowhere else; now we use the not-so-new-any-more ifnames schema everywhere, but if you install biosdevname this will still win over that
<pitti> rbasak: https://lists.ubuntu.com/archives/ubuntu-devel/2015-May/038761.html has the details
<doko> rbasak, https://bugs.launchpad.net/ubuntu/+source/pyjwt/+bug/1427852  this is a dep of python-oauthlib (subscribed by the server team). please could you subscribe to pyjwt too?
<ubottu> Launchpad bug 1427852 in pyjwt (Ubuntu) "[MIR] pyjwt (b-d of python-oauthlib)" [Undecided,Confirmed]
<tjaalton> hum, dist-upgrade vivid->wily shut my system down
<ogra_> bitten by the werewolf :)
<tjaalton> indeed
<tjaalton> mid-upgrade too, and default kernel panicked because there was no initramfs yet
<ginggs> doko: hi, are you aware of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65974 ? According to https://lists.launchpad.net/kicad-developers/msg19960.html it is at least one of the things causing kicad to ftbfs.
<ubottu> gcc.gnu.org bug 65974 in c++ "[5/6 Regression] Bogus deprecated-declarations warnings for inline definitions of deprecated virtual methods" [Normal,Resolved: fixed]
<didrocks> ogra_: where is the branch for things shipped in /usr/local/bin in snappy? I just want to do a small change
<ogra_> didrocks, /usr/local/bin ??
<ogra_> oh, there is something in there, i see
<ogra_> mvo, ^^
<ogra_> didrocks, note that this wont stay... most likely we'll actually rip out all remaining apt related bits
<doko> ginggs, no, that's not the reason:
<doko>  /usr/include/c++/5/bits/stl_list.h:1807:22: error: reference to 'list' is ambiguous
<doko>      operator==(const list<_Tp, _Alloc>& __x, const list<_Tp, _Alloc>& __y)
<didrocks> ogra_: ah ok, but as there is nothing that stays more than temporary solution, I can just propose a small modification :p
<ginggs> doko: thanks.  i'll look at pulling a newer upstream revision
<didrocks> ogra_: oh, snappy-tools is not in wily, neither available in the ppa for wily
<ogra_> didrocks, snappy is though
<ogra_> from ubuntu-snappy i think
<didrocks> ogra_: yeah, it's not what the guide says :p
<didrocks> and you were complaining about ubuntu make ppa, dude! :)
 * didrocks looks at what the snappy-tools are and download vivid version
<ogra_> hmm, does LP have issues ?
 * ogra_ gets a lot of:
<ogra_> Uh oh!
<ogra_> Something has gone wrong. We're sorry!
<sergiusens> ogra_ didrocks, is that the apt script? We have a bug to add a proper package override from slangasek
<ogra_> sergiusens, yup
 * sergiusens not sure about the bug, but does recalled being bugged by slangasek ;-)
<sergiusens> -ed
<ogra_> not sure we catually need a package override
<sergiusens> ogra_, livecd-roots dirtiness?
 * sergiusens can't type today
<ogra_> a simple rm before tarring up the rootfs would suit as well
<didrocks> sergiusens: yeah, that's the apt script
<mvo> didrocks: livecd-rootfs
<didrocks> mvo: thanks!
<mvo> didrocks: what do you want to change?
<didrocks> mvo: just echo `basename $0` instead of the harcoded "apt-get" (annoying when I'm typing apt or apt-cache :p)
<mvo> didrocks: aha, nice
<ogra_> well, instead of changing it we should just finally do the actual drop
<didrocks> ogra_: if you are going to handle the drop today, yeahâ¦
<ogra_> hmm, not today ... why do you need that today ?
<didrocks> ogra_: I prefer then to propose the small change, at least, I know it will get in
<mvo> we don't actually ship apt in snappy anymore
<didrocks> (remember temporary things? like CI Train for 2 month)
<mvo> still its nice to give people a clue what to use instead
<ogra_> mvo, ah, i thought we only made it inexecutable
<ogra_> didrocks, 2 months ? i think you got your scale wrong :P
<ogra_> that was more like 2 years (felt at least :) )
<mvo> ogra_: I think we killed it
<ogra_> cool
<didrocks> ogra_: that was the initial ETA of some teams writing the Airline :p
<mvo> (only on rolling)
<ogra_> didrocks, yeah :)
<didrocks> ogra_: just pushed rev 1198 after testing that all is fine with the no-apt symlink
<ogra_> +1
<didrocks> thx ;)
<sergiusens> mvo, ogra_ didrocks we did not drop it from 15.04, only rolling fwiw
<didrocks> sergiusens: I don't think that ogra_ knows anything else than rolling :p
<didrocks> (well, apart for his desktop when he's dangerously behind! ;))
<rbasak> jamespage: see doko's message to me above. Can you subscribe ~ubuntu-server (and presumably the new openstack group) to pyjwt?
<ogra_> didrocks, i'm on the latest production release :P
<jamespage> rbasak, done
<fredw> chrisccoulson: can you please take a look at https://code.launchpad.net/~fred-wang/firefox/wily-bug-1473552/+merge/270253 ? This is my first patch to Ubuntu, so I'm not sure I've done everything correctly...
<rbasak> jamespage: thank you! doko: ^
<jamespage> rbasak, np
<Riddell> mvo: ping? will you be able to update packagekit this week?  will you update app-install-data for this cycle?
<mvo> Riddell: uh, no packagekit, no, sorry. but I can do app-install-data
<xnox> jamespage: is there go 1.5 for all ubuntu releases?
 * jamespage defers that question to rbasak
<jamespage> xnox, I would suspect only wily right now but there might be  a backport plan
<rbasak> xnox: not currently, but there has been talk about backporting it. slangasek?
<xnox> and it's labour day, so slangasek will probably not respond.
<xnox> jamespage: rbasak: how about packaging standalone golang1.4 such that it's always available for bootstraps and things?
<cjwatson> ogra_: LP> sorry about that, there was a temporary firewall configuration error, quickly fixed
<ogra_> cjwatson, yep, i noticed it was really quick :)
<ogra_> two reloads later it worked again
<hallyn> slangasek: hi, if you get a chance, could you take a look at http://mentors.debian.net/debian/pool/main/c/cgmanager/cgmanager_0.39-1.dsc ?
#ubuntu-devel 2015-09-08
<TheMuso> Either I can't remember, or haven't had to do this before... Is there a way for me to get a log of all revisions of files from a tag and earlier in bzr?
<TheMuso> i.e I can do this in git: git log tag files/*
<TheMuso> And I
<TheMuso> And I will get all commits of files/* with the tag as the last commit of those files...
<TheMuso> Using a bzr command in a similar way, i.e bzr log -r tag files/* doesn't necessarily show me any commits, or if it does, only that commit associated with the tag...
<TheMuso> Ok, seems bzr log -r 1..tag files/* does what I want.
<slangasek> hallyn: uploaded
<pitti> Good morning
<dholbach> good morning
<dholbach> smb, happy birthday! :)
<pitti> apw: http://autopkgtest.ubuntu.com/packages/l/linux/ \o/
<pitti> impeccable!
<zyga> doko: hey, spineau made a patch for checkbox to build on wily
<zyga> doko: it's a bit lintian unclean but I wonder if that's something you'd like to see fixed, we'll remove checkbox first thing after w+1 opens
<zyga> doko: the debdiff is at https://bugs.launchpad.net/ubuntu/+source/checkbox/+bug/1491590
<ubottu> Launchpad bug 1491590 in checkbox (Ubuntu) "FTBFS with Python 3.5 in wily" [High,In progress]
<apw> pitti, heh amazing!
<doko> zyga, is this https://launchpad.net/ubuntu/+source/checkbox-support/0.20-2 ?
<zyga> doko: checkbox-support is a separate package, checkbox is different
<zyga> doko: checkbox is really dead but we promised to fix the build issues before we remove it for w+1
<doko> zyga, https://launchpad.net/ubuntu/+source/checkbox/0.18-0ubuntu3
<zyga> doko, spineau: thank you both!
<spineau> great, thank you doko
<cjwatson> ginggs: Isn't paraview going to need to have the previous Ubuntu delta reapplied to it?  https://launchpad.net/ubuntu/+source/paraview/4.1.0+dfsg+1-1ubuntu1
<GunnarHj> cyphermox: Hi Matieu, is there a plan to make another release of ubiquity-slideshow-ubuntu before UI-freeze the day after tomorrow? There are a few additional revisions in trunk.
<ginggs> cjwatson: vtk6 now builds on arm
<cjwatson> ginggs: oh does it now
<cjwatson> ginggs: excellent, objection withdrawn then
<caribou> has anyone noticed frequent Xorg crashed on wily recently ?
<Laney> caribou: intel?
<caribou> Laney: yep
<caribou> Laney: apparently segfaulting from what I could see in the apport-report
<didrocks> caribou: tjaalton uploaded a fix in xorg-server today
<didrocks> caribou: after my last crash, it didn't crash 2h30 here now
<didrocks> for*
<didrocks> so, there is hope :)
<didrocks> caribou: bug #1484380 FYI
<ubottu> bug 1484380 in xorg-server (Ubuntu) "Xorg regular crash on wily" [High,Fix released] https://launchpad.net/bugs/1484380
<caribou> didrocks: thanks
<caribou> didrocks: I'll upgrade & see if it stops
<cyphermox> GunnarHj: there aren't plans, but I can take a look now
<GunnarHj> cyphermox: It would be great, thanks!
<dupondje> Hi dev's :) Some small question(s). I would like to update network-manager-strongswan plugin on wily (still possible?)
<dupondje> This as the new version (1.3.1) has support for PSK again (which is asked for in bug https://bugs.launchpad.net/ubuntu/+source/network-manager-strongswan/+bug/1457078 for example)
<ubottu> Launchpad bug 1457078 in network-manager-strongswan (Ubuntu) "L2TP client support for PSK removed from 15.04" [Undecided,Confirmed]
<dupondje> if its allowed, how to post a patch again for it? Created a new package (network-manager-strongswan_1.3.1-0ubuntu1.dsc)
<dupondje> I just post a debdiff of network-manager-strongswan_1.3.1-0ubuntu1.dsc vs network-manager-strongswan_1.3.0-2.dsc (current version) ?
<dupondje> its been a while :) forgot some things :D
<doko> Laney, norwegian rdep ping
<doko> Laney, also Sweetshark asked for a LO freeze exception ...
<Laney> already approved, no?
<doko> no, but you are rm ...
<Laney> yes it is
<Laney> what is a norwegian rdep?
<dupondje> anyone? :)
<tdaitx> dupondje, the package update process you describe is correct, you should also set the patch tag after attaching the debdiff and remember to subscribe ubuntu-sponsors, remember to include LP: and Closes: in the changelog... what I don't know is whether an update would be accepted at this time
<tdaitx> dupondje, I also recommend you to submit it to debian, there is an openbug there: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578595
<ubottu> Debian bug 578595 in network-manager-strongswan "network-manager-strongswan: PSK support" [Wishlist,Open]
<sarnold> pitti: re, /etc/apport/crashdb.conf, thanks :)
<dupondje> https://bugs.launchpad.net/ubuntu/+source/network-manager-strongswan/+bug/1487183
<ubottu> Launchpad bug 1487183 in network-manager-strongswan (Ubuntu) "Upgrade nm-strongswan to latest 1.3.1 with psk support" [Undecided,New]
<dupondje> there :) patch uploaded and subscribed ubuntu-sponsors :)
<GunnarHj> cyphermox: Maybe you already know, but Harald Sitter uploaded ubiquity-slideshow-ubuntu about an hour ago.
<cyphermox> GunnarHj: ok, thanks
<sitter> doing all the thing \o/
 * sitter is most outraged that the ubiquity kde ui is still qt4 though -.-
<tjaalton> hum, I'm seeing bug 1342083 on wily
<ubottu> bug 1342083 in libvirt (Ubuntu Trusty) ""Failed to create chardev" due to apparmor DENIED execute of "/usr/lib/pt_chown"" [Undecided,Fix committed] https://launchpad.net/bugs/1342083
<tjaalton> arges: ^ this shouldn't be possible on wily anymore, right?
<tjaalton> [111610.183413] audit: type=1400 audit(1441742633.331:91): apparmor="DENIED" operation="capable" profile="libvirt-0e2e5090-99bb-44a4-93f7-040e88621faa" pid=18543 comm="pt_chown" capability=3  capname="fowner"
<TJ-> tjaalton: I sure hope not, that was very annoying!
<arges> looking
<arges> not sure
#ubuntu-devel 2015-09-09
<jcjordyn120> i have a idea on the ubiquitty installer, I would like to be able to specify multible mount points on the custom partition screen
<pitti> Good morning
<spineau> doko: hello, I've proposed a patch to solve the update issues with plainbox-provider-resource-generic (https://bugs.launchpad.net/ubuntu/+source/plainbox-provider-resource-generic/+bug/1493356) that with have on some arch.
<ubottu> Launchpad bug 1493356 in plainbox-provider-resource-generic (Ubuntu) "plainbox-provider-resource-generic fails to update to 0.19-1 on some architectures" [Undecided,In progress]
<dholbach> good morning
<zzarr> hello! I installed ubuntu-lxc on a computer running Wily today, but it hangs on login, it seams to be a common problem, is there a solution?
<zzarr> ohh, my bad, the package is called unity8-lxc
<pitti> Laney, slangasek: do you understand dracut on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt ?
<pitti> Laney, slangasek: we fixed kbd and console-setup yesterday, and now in a wily-proposed chroot "apt-get install dracut-config-generic dracut dracut-config-rescue" works
<pitti> The following packages will be REMOVED:
<pitti>   initramfs-tools mountall plymouth upstart
<pitti> is it somehow complaining about that?
<pitti> doko: ^ FYI
<pitti> or does this need some hinting?
<Laney> pitti: seems to be http://pastebin.ubuntu.com/12319635/
<Laney> is there a matchin upload
<Laney> matching upload* of initramfs-tools or something?
<pitti> Laney: no, we are actually ahead of debian
<pitti> Laney: yes, dracut does conflict to initramfs-tools, you can only have one provider of it
<pitti> "it" == linux-initramfs-tool
<pitti> Laney: i-t is Priority: important, is it due to that?
<Laney> so it's a chain from those packages I listed in the intstall line
<pitti> Laney: hm, console-setup and kbd got fixed already
<pitti> to depend on i-t | l-i-t
<pitti> Laney: ah, kbd hasn't made it yet: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kbd
<pitti> boot test stuck since yesterday, argh -- /me pokes
<pitti> Laney: so I guess that's why
<Laney> yes, it's kbd
<Laney> If the autohinter doesn't figure this out you can add an easy hint for it
<pitti> Laney: I cancelled the boottest (running for 21h), I give it another chance, and if it hangs again I'll force kbd
<pitti> then let's see whether that suffices
<pitti> Laney: thansk!
<doko> jamespage, there are test failures for python-pyeclib on powerpc
<Laney> pitti: I wrote https://code.launchpad.net/~laney/ubuntu-archive-tools/update-output-helper/+merge/267970 a few weeks ago to make it a bit easier to debug these things btw
<Laney> might be useful to have around
<jamespage> doko, yes I know - and I am trying to resolve them
<Laney> its current interface needs work but it's still helpful
<doko> Laney, norwegian dep-wait (desktop)
<Laney> what are you talking about?
<doko> https://launchpad.net/ubuntu/+source/norwegian/2.0.10-7
<darkxst> hey Laney pitti
<pitti> sitter, Riddell: FYI, kwin tests regressed, so yesterday's KDE updates are stuck
<Riddell> uh oh
<Riddell> pitti: upstream says he knows and is working on how to fix the test rather than the code so I'll set it to ignore, do you know if I should use force-badtest or force-skiptest or both?
<pitti> Riddell: I'd use force-badtest on that specific kwin version here
<pitti> Riddell: that will unblock the packages that fail on the kwin reverse dependency too
<pitti> Riddell: skiptest> unblock only that very package, regardless of hwo many test failures it triggered
<pitti> Riddell: badtest> skip that particular test result, for any proposed package that triggers it
<Laney> doko: it's going to fail to build anyway: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794152
<ubottu> Debian bug 794152 in ispell "ispell: munchlist error detection is overly aggressive" [Important,Open]
<Riddell> pitti: thanks
<Laney> let's just leave it
<Laney> hey darkxst
<doko> Laney, then I ftbfs issue would at least document it
<Mirv> powerpc chroot problem on fisher01 https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-012/+build/7889605
<doko> given back
<Riddell> pitti: do you know what's up here? http://autopkgtest.ubuntu.com/packages/d/debconf-kde/wily/ppc64el/
<Laney> doko: component mismatch too
<Laney> no point sorting that out if it won't work anyway
<pitti> Riddell: "Temporary failure resolving 'ports.ubuntu.com'
<pitti> Riddell: I'll retry
<pitti> Riddell: i. e. that was already my retry from this morning's combing of excuses.html, apparently it needs retrying harder :)
<Laney> I've seen a fair few of those lately
<pitti> yeah, not sure what's up with those wolfe boxes
<pitti> cjwatson: ^ wrt that, your last LP status report (thanks for that!) made me hopeful that ppc64el in scalingstack might be a thing RSN?
<cjwatson> pitti: It's in the production testing phase, and needs some bits redeployed cleanly, but otherwise almost there
<pitti> yay!
<pitti> Riddell: http://autopkgtest.ubuntu.com/packages/d/debconf-kde/wily/ppc64el/ green again
<Riddell> pitti: lovely
<jamespage> doko, pyeclib fixed....
<mdeslaur> slangasek: still no new edk2 in unstable?
<morphis> mterry: ping
<mterry> morphis, hello
<mterry> I mean pong  :)
<morphis> mterry: hey!
<morphis> regarding https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1492441
<ubottu> Launchpad bug 1492441 in bluez (Ubuntu) "Cannot connect to 1byone bluetooth keyboard (after successfully pairing)" [Undecided,New]
<morphis> can you check if you have the hidp kernel module loaded?
<mterry> morphis, ok
<mterry> $ lsmod | grep hidp
<mterry> hidp                   24576  0
<mterry> hid                   118784  1 hidp
<mterry> bluetooth             507904  30 bnep,hidp,btbcm,btrtl,btusb,rfcomm,btintel
<mterry> morphis, ^
<morphis> ok
<mterry> doko, man you're killing me with bug 1493037.  like 40 packages
<ubottu> bug 1493037 in Ubuntu "lib*-perl dependencies of dh-golang and libtype-tiny-perl" [Undecided,New] https://launchpad.net/bugs/1493037
<doko> mterry, that's why I'm filing it myself ;-P
<mterry> heh
<hallyn> gah.  it's a FAIL any time a dist-upgrade resets my xmodmap
<morphis> bdmurray_: thanks!
<bdmurray> morphis: no problem
<doko> jamespage, python-oslo.service b-d's on routes, which is missing a MIR
<jamespage> doko, should be just a binary only promotion I think
<jamespage> routs is in main
<doko> ok, done
<jamespage> doko, ta
<Teduardo> Howdy, does anyone know when Ubuntu will release a sendmail package that allows you to mitigate the logjam issue?
<mdeslaur> Teduardo: do the instructions here not work? https://weakdh.org/sysadmin.html
<slangasek> mdeslaur: no, edk2 still stuck in the Debian NEW queue
<Teduardo> is there any way to contact a packager for a ubuntu package?
<rbasak> Teduardo: packages in Ubuntu are team maintained. Try the ubuntu-devel-discuss@lists.ubuntu.com mailing list, or file a bug if it's an actionable item.
<jpds> Teduardo: Also, postfix and exim4 seem to be the MTAs in main
<jrwren> I wish there were links from packages.ubuntu.com to the source on lp
<jrwren> oh, the bug reports link is close enough, nevermind me.
<sarnold> jrwren: it's nice to have an lpsrc keyword search in firefox: "https://launchpad.net/ubuntu/+source/%s"
<sarnold> jrwren: then you just open e.g. lpsrc apparmor to get right to the apparmor package
<tarpman> I like pad.lv. â http://pad.lv/u/firefox
<jrwren> sarnold: I need that, for sure.
<jrwren> sarnold: i just learned duckduckgo has !lp search for launchpad. so close!
<sladen> and yet, 10 years on  bugs.launchpad.net/NNNN  still doesn't work
<sarnold> jrwren: hah! nice. with a ddg search provider for firefox then that'd just be ddg !lp foo   :)
<sarnold> jrwren: I've got a 'ubug' for that, too, http://launchpad.net/bugs/%s
<sarnold> jrwren: it's a nice complement to 'dbug' http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%s
<tarpman> sarnold: bugs.debian.org/%s ;)
<sarnold> tarpman: if only changing firefox search keywords wasn't a pain in the ass...
<slangasek> mdeslaur: edk2 unblocked in Debian NEW, so should be syncable to wily shortly
<slangasek> ("shortly" == "next 24 hours")
<mdeslaur> slangasek: ah, great, thanks
<ScottK> sladen: pad.lv/NNNNNN does work.
<sladen> ScottK: yes.  I was not questioning that ;-)
<ScottK> K.
<lifeless> barry: https://bugs.launchpad.net/testtools/+bug/1488710 <- see my comment please
<ubottu> Launchpad bug 1488710 in testtools "testtools is incompatible with newer versions of Twisted" [High,Triaged]
<barry> lifeless: not sure what you mean by "namespaced"
<lifeless> barry: ubuntu-ftbfs or something
<lifeless> barry: since its not a ftbfs for anyone else atm
<barry> too bad you can't tag bugtasks
<lifeless> barry: yes, the its-not-quite-federated data model is a significant limiter here
<barry> lifeless: i just removed the tags.  cjwatson's fix gets me almost all the way there.  still two failures; one i have fixed the other not so much yet
<lifeless> barry: oh?
<barry> lifeless: yep.  the odd one is test_run_list_failed_import
<barry> it doesn't raise SystemExit
<lifeless> barry: have you put a patch up for the other ?
<barry> lifeless: not yet, i want to get it passing first and then i'll comment and/or submit a patch
<barry> lifeless: i think i also need to dup #150 to #149
<lifeless> done
<barry> thx
<barry> lifeless: in the meantime, this is the other patch i needed: http://paste.ubuntu.com/12324069/
<barry> lifeless: and the last one i'm hunting: http://paste.ubuntu.com/12324090/
<lifeless> we're getting a valueerror there?!
<lifeless> I'd want to see where thats coming from - it may indicate a deeper problem
<barry> lifeless: yes
<barry> lifeless: but right now testtools is blocking several other packages so i'm just trying on bandaids that aren't too ugly
<lifeless> barry: hang on, what version of testtools is this?
<lifeless> that pastebin patches a test tht we don't have in that file...
<barry> lifeless: ha.  1.4.0.  i guess that's old.
<lifeless> barry: ahahahahahahahahahahahaahhaa]
<lifeless> barry: yes. 1.8.0 is current
<barry> lifeless: yay for ubuntu deltas :(
<lifeless> barry: its not that old - nov last year
<barry> and 1.8.0 is in experimental only right now
<barry> lifeless: so maybe bandaiding isn't horrible for wily.  we'll definitely sync up again in x.  or should i push through an ffe and try to get 1.8.0 in from experimental?
<lifeless> https://github.com/testing-cabal/testtools/compare/testtools-1.4.0...1.8.0
<lifeless> so 1.6.0 is when we fixed up all the cruft and started depending on unittest2
<lifeless> honestly, nothing is super critical
<lifeless> devs are going to pip install anyhow
<lifeless> so if 1.4.0 is whats needed for other things packaged in Ubuntu, thats fine
<lifeless> there's no security issues that I can see
<barry> lifeless: yeah, it's just a matter of bureaucracy ;/
<barry> well, i think i'll spend a little more time trying to fix this, and if i get lucky, i'll just upload fixes to ubuntu to unblock everything else.  maybe by the time we sync for x, upstream will release a fixed version
<lifeless> barry: heh, upstream works fine on 3.5 and 3.6 already
<barry> lifeless: excellent
<lifeless> barry: the only issue upstream has is the twisted version
<lifeless> barry: and that cjwatson's patch will fix - its in fine tuning mode atm
<barry> lifeless: ack
<barry> lifeless: can you tell me what that test is supposed to do?
<lifeless> barry: the one in your pastebin ?
<barry> lifeless: yeah, the one that's still failing.  i *think* i know but it's very difficult to debug why it's not failing in the expected way
<lifeless> barry: so prior to 1.6.0 we had code to handle python2's broken handling of non-text .py files
<lifeless> barry: that test tests that such a file errors as either a TypeError or SyntaxError. I'm not sure why TypeError is considered valid
<lifeless> barry: the test (and the code) is gone in 1.6, because we now use the rolling backport of linecache, which includes patches for tokenize, so it all just works
<lifeless> barry: and we have text strings in the line cache, or None, consistently
<lifeless> (git diff testtools-1.5.0 testtools-1.6.0 in the source tree will let you see this)
<barry> lifeless: is it possible that py 2.7.10 may have changed in a way that causes this test to not error?
<barry> lifeless: since i'm guess you never ran 1.4.0 against 2.7.10
<lifeless> barry: hmm, I can't see anything trawling through hg
<lifeless> barry: though I'm not happy with the issue 23838 patch :)
<lifeless> but thats entirely different :>
<barry> lifeless: yeah me neither going thru Misc/NEWS
<barry> :)
<barry> lifeless: since this test goes away in 1.8.0 would i make you puke on your keyboard if i just disabled it in 1.4.0 in wily?
<barry> though i'm willing to do a bit more debugging, i want to unblock the other packages.  i know it's horrible
<lifeless> barry: I think disabling it is probably fine, I very much doubt that other folk deliberately test with broken binary .py files in their tree
<lifeless> we had the test because someone somewhere had that happen to them and testtools blew up
<lifeless> so we wanted to blow up in a way that exposed the issue they had, not our innards
<barry> lifeless: ack and thanks.  if i can't figure it out by the dinner bell, that's probably what i'll do
<lifeless> it would be better to migrate to 1.6.0+, but I appreciate your position
<lifeless> (and won't give you grief about it :))
<cjwatson> lifeless: sorry, I had to sidetrack into other things, I shall get back to that branch before the end of the week
<cjwatson> lifeless: I think I would appreciate it if a testtools developer could file the bug against twisted though, because otherwise I can foresee myself getting into playing telephone-game between two sets of developers and that seems less than ideally productive
<lifeless> cjwatson: yup, I shall do that. That comment was mainly what-do-people-thing
<lifeless> think
<cjwatson> Thanks.  Since they seem to be trending away from exposing what testtools needs, probably good to let them know that somebody cares
<lifeless> what I should do
<lifeless> is submit a patch to their CI system to cross-test
<lifeless> :)
<cjwatson> lifeless: PR up to date now I think
<cjwatson> Disentangling stuff in LP so that we can upgrade is still an open project :-/
<lifeless> thank you
#ubuntu-devel 2015-09-10
<infinity> win 19
<Unit193> infinity: Pokepoke!  Seen these https://code.launchpad.net/~unit193/ubuntu-cdimage/xubuntu-core/+merge/268167 ? (And of course all the ones linked in there.)
<pitti> Good morning
<sitter> pitti: update_excuses says ubiquity armhf test is in progress for >12 hours while in fact it finished quite a while ago :/
<pitti> sitter: will look in a minute
<pitti> sitter: they actually didn't -- there is no result for 2.21.29 on http://autopkgtest.ubuntu.com/packages/u/ubiquity/wily/armhf/
<pitti> oops, the pre-last one
<pitti> sitter: incidentally, this is a transient bug which I'm currently working on
<sitter> ah
<sitter> pitti: ok thanks :)
<flexiondotorg> I have a dump in /var/crash created when Caja encountered a segfault.
<flexiondotorg> approt-gtk simply didn't upload anything when it detected the crash.
<flexiondotorg> I've create a bug report and would like to submit the crash report, manually invoking apport-gtk had the same issue. It just silenty closed when I tried to submit the report.
<flexiondotorg> Can anyone help me get the crash report submitted?
<pitti> flexiondotorg: sounds like it reported it to errors.u.c. only?
<Laney> did we leave LP reporting off this cycle?
<pitti> oops, it seems we never actually enabled it
<flexiondotorg> Ah!
<Laney> ha
<flexiondotorg> :-)
<Laney> add that to NRCP or so?
<flexiondotorg> So, does that mean there might be an entry in errros.ubuntu.com?
<pitti> Laney: we don't actually want to enable it that early, usually around alpha-2
<pitti> flexiondotorg: there should, yes
<pitti> I'll finish something else first, and then do a new apport upload
 * flexiondotorg goes searching.
<Laney> pitti: I don't have the impression that early release is that wild-westy any more
<pitti> true that
<Laney> but if you can think of a good process checkpoint later on
<flexiondotorg> Can I just understand why it was disabled?
<pitti> we don't want users of stable releases report to LP, just to errors.u.c.
<pitti> so we disable that right before release, and re-enable it at some (not well-defined) appropriate point in time after opening the new devel series
<flexiondotorg> pitti, OK.
<pitti> apw: hm, and now linux regressed again -- were the two successful runs just good luck, or did 9.9 actually break something again?
<pitti> oh, curiously they pass the regression suite, but fail "rebuild", wut?
<apw> pitti, bah ... hate
<pitti> dpkg-checkbuilddeps: Unmet build dependencies: makedumpfile libelf-dev libnewt-dev libiberty-dev libdw-dev libpci-dev pkg-config flex bison libunwind8-dev libaudit-dev bc python-dev libudev-dev autoconf automake libtool xmlto docbook-utils ghostscript transfig sharutils asciidoc
<apw> pitti, erm ... how is that possible even ... wtf ?
<pitti> apw: did that lose the Depends: @builddeps@ or so?
<apw> Tests: rebuild
<apw> Depends: @builddeps@, fakeroot
<apw> Restrictions: allow-stderr
<apw> looks ok ...
<apw> pitti, OH do you use a profile ?
<pitti> no, I don't think so
<pitti> apw: no, I don't
<apw> do you parse debian/control directly, could you be being confused by the new use of profiles
<pitti> apw: I use libdpkg-perl, but I fixed autopkgtest to get along with profiles a fair while ago
<pitti> apw: ah, but trusty's libdpkg-perl might not
<pitti> apw: so all these missing ones have a build profile now? how do they look? (to spare me apt-get source linux)
<pitti> <!stage1> or something?
<apw> http://paste.ubuntu.com/12327328/
<apw> pitti, i'd say for an instant fix you could just rip them ... as we only use them to pare down deps for bootstrapping
<pitti> apw: thanks; let me look into this
<apw> pitti, thanks as always
<pitti> test_build_deps_profiles (__main__.ChrootRunner)
<pitti> test depends on build dependencies with build profiles ... FAIL
<pitti> bingo
<apw> :)
<pitti> apw: ^ this is the test suite running on the production box (trusty)
<apw> pitti, makes sense
<pitti> apw: I'll see to adding a fallback, like just blatantly ignoring them
<pitti> I don't think it's practical to backport a newer dpkg to trusty
<apw> pitti, yeah i recon just rip them on average, clearly they arn't used much else other people would be moaning
<apw> pitti, and i assume if we can't figure it out, we can enumerate @buildeps@ by hand and be happy
<pitti> apw: nah, this needs to work
<pitti> please don't change the kernel for this, othe rpackages use profiles too now
<pitti> and this likely causes some other failure
<apw> pitti, i meant if we were doing something that "just ripping them" doesn't fix ...
<pitti> ah
<apw> which we arn't
<apw> pitti, what happened to the results for -8.8 i wonder
<pitti> apw: there is no such thing, at least not in ubuntu
<pitti> https://launchpad.net/ubuntu/+source/linux/+changelog
<pitti> apw: apparently it never got copied?
<apw> wierd ...
<apw> yeah must be ... i wil beat tim to find out what occured later then :)
<apw> pitti, and when you get bored you can try and explain how the one below ever occured, it looks like one binary package from linux-meta is published but not the others, which makes my head hurt:
<apw> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/amd64/l/linux/20150909_203426@/log.gz
<pitti> flexiondotorg: apport uploaded; if you want, you can apply the simple config change locally: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/wily/apport/ubuntu/revision/2453
<pitti> apw: we got tons of such failures over night
<pitti> apw: as linux and linux-signed were stuck in binNEW; I NEWed them, and then retried all temp failures
<apw> pitti, ahh i guess htat if i asked it to install the second one listed, it would blame something deeper ... ok its just confusng me
<pitti> apw: this was again the case of linux-meta being updated with its dependencies not being installable
<apw> pitti, yeah, i see that now, the reported error had me confused, but its just being lazy and telling me the top not the real missing package
<apw> pitti, is htere something wrong with ppc64el/armhf testing atm ?  i seem to have no results for dkms packages for wily for -9.9 on those
<pitti> apw: ok, fixed in http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=69561dae , rolled out, and linux retried on i386/amd64
<pitti> apw: nothing wrong that I'm aware of
<pitti> apw: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#linux-meta is full of bling?
<pitti> apw: well, pretty much all the dkms packages fail on armhf/ppc64el for sure
<pitti> apw: we can't actually install newer kernels in LXC
<pitti> but at least formally they get triggered
<apw> pitti, of course, they are run they just don't mean anything ... doh
<pitti> apw: I hear ppc64el scalingstack support is coming RSN, then these will work
<pitti> apw: yeah, I don't bother adding some special cases for those -- they fail fast enough
<apw> pitti, we're going to need that "report kernel" i guess before we get lts backports to work anyhow, but that likely should tell you if it is a host kernel or not
<pitti> apw: yep, working on that now
<pitti> apw: ok, it's past build dep installation, that worked now
 * pitti now lets it do its three-hour thing
<apw> reat ...
<apw> great
<pitti> apw: so for bug 1491865 -- 1) just means you want to see it in the log, right?
<ubottu> bug 1491865 in autopkgtest (Ubuntu) "report and record the actual booted kernel with test results" [High,In progress] https://launchpad.net/bugs/1491865
<pitti> apw: which is hard for machine parsing, but for humans
<pitti> apw: and 2) is to add this to result.tar
<apw> yeah i think when a human reads the log and they see a reboot, each and every reboot should report the kernel as it comes up
<pitti> right, that's trivial
<apw> and in a perfect world the computer would check that it was concistent throughout the run (but ...)
<pitti> and for 2) I think it would be the kernel version that the test bed has after the initial setup
<pitti> well, a test might actually go and install a different kernel
<apw> right after you "update everything and reboot if /boot changed" phase
<pitti> right, that's the point I meant
<pitti> alrighty
<pitti> something to do after lunch
<apw> do we expect that, or do you handle lts-XXX outside, i think you will ?
<apw> pitti, or ... you could make that a list of kernels
<apw> and record after any reboot
<pitti> apw: we already have a list of kernels, I thought the point was to know which kernel actually ran?
<apw> not a list of installed kernels, but a list of "each kernel in each reboot"
<apw> so if the test installs and reboots it owuld like say
<apw> [ V1, V2 ]
<pitti> apw: not sure yet about lts-XXX -- either it'll become part of what the dkms autopkgtest script does, but that's impractical for some reasons
<pitti> apw: I think I'd rather special-case it in the autopkgtest cloud worker, and install that kernel when it is the test trigger
<pitti> (as part of setup-commands)
<apw> yep i can see how that makes sense
<apw> anyhow, i thnk i'd say make the kernel thing a list of an entry after each reboot if that is doable
<apw> in the main it will be just one anyhow
<pitti> it's less obvious for reproducing locally, but avoids SRUing the dkms-autopkgtset script all over again, and instaslling yet another kernel into the testbeds and another reboot
<apw> heh
<apw> at least if every consumer is keying off the kernel listed in the test results we don't care how it gets made
<pitti> apw: a list would only make sense if you expect tests to isntall/reboot into different kernels
<pitti> do you want to do that actually?
<apw> pitti, well i don't think i do, but its more about whether something will reboot more than once
<apw> pitti, if it does, then recording what you booted each time catches bugs in the test
<apw> pitti, we can see tht it should be X each time and it went X, Y, Y or whatever
<pitti> apw: okay
<apw> its as much about being able to tell a result is right as anything
<apw> for my purposes i will check it is consistant throughout or bin the result
<pitti> apw: so this would be a testname â reboot ID â kernel version map
<pitti> apw: where "reboot ID" is the string the test passes to /tmp/autopkgtest-reboot <ID>
<pitti> hm, but most tests don't do that
<apw> what is the first one called, the one you do after /boot
<pitti> so perhaps "testname â initial -> kernel version" for those?
<pitti> apw: it doesn't have one, as that's not triggerd by the test
<pitti> but for the yaml we need to make up something
<apw> so you are saying i'd have for each testname what kernel version it had underneath? and if it reboots it would have initial -> v and ID -> w
<apw> sort of thing
<pitti> actually, we don't even need the per-test initial thing, it's always the same
<pitti> apw: so perhaps:
<apw> always the same ?
<pitti> kernel_version: <initial kernel after test bed init/upgrade>
<pitti> and *if* a test installs a different one,
<pitti> test_kernel_versions: testname -> ID -> version
<pitti> (and we usually don't expect the latter at all)
<apw> is testname ID there is that like testname: [(id, version), ...]
<pitti> apw: "testname" -> name in Tests: in d/t/control
<pitti> apw: I mean the reboot ID, as explained above (autopkgtest-reboot ID)
<pitti> test_kernel_versions:
<pitti>     test_with_utopic_lts:
<pitti>      reboot_new_kernel:   # (from claling autopkgtest-reboot reboot_new_kernel)
<pitti>      3.14.0-blah
<pitti> (imagine some more indentation in the last line)
<apw> i guess it depends if we care to look them up by test name ...
<pitti> from Tests: test_with_utopic_lts
<apw> in my mind i was seeing more: (python form) kernel_version: [ ('setup', None, V), (testname1, ID1, V2), ... ]
<pitti> apw: well, otherwise you wouldn't really know what/when it happened?
<apw> or even kernel_version: [ (None, None, V), (testname1, ID1, V2) ]
<pitti> apw: isn't that mostly the same, except a list insted of a testname -> bootid map?
<apw> well i have ordering information that way
<pitti> ah, ok
<apw> though i'd almost wonder if you have test1 test2 test3 in your control
<pitti> apw: not sure that None can be represented adequately in yaml
<pitti> apw: I was thinking of only adding entries to that complicated structure which actually differ from the default version, as we almost always expect tests to use one and the same
<apw> that it would be " [ ('setup', '', V), (test1, '', V), (test2, '', V), (test2, 'ID', V2), (test3, '', V2) ]
<pitti> and put the initial version into a different field, so that it's much easier to parse
<apw> yeah that simlpification is fine indeed
<apw> i am looking to be able to trivaily know for any test what kernel was it run under
<apw> so knowing when the tests run relative to the reboots if any
<apw> (this is something we found valuable when doing testing in a previous life, allowing validation of test results)
<pitti> apw: btw, would you terribly mind json insted of yaml? json is built into python, yaml is a separate module; I'd like to avoid new deps if I can
<apw> pitti, i care not at all what the format indeed, use what you find most convienient
<pitti> apw: we usually reset the testbed in between tests; should that be reflected in your list?
<apw> as long as python can parse it later
<pitti> [ ('setup', '', V), (test1, '', V),  ('setup', '', V), (test2, '', V) ...]
<apw> so it is a phase list not a test list, that seems ok
<apw> can we use that somehow to make it an event
<pitti> (still not entirely sure what the goal of this is, so you tell me :) )
<pitti> but the above seems both highly redundant to me and not that useful
<pitti> in 99% of cases all the Vs are the same
<apw> ultimatly i want to know what tests ran under what kernels and preferably to know the order, but i guess i can tell that from teh control file
<apw> so i can tell if a reboot failed and we got the wrong kernel, like a grub bug picking the wong kernel on reboot
<pitti> apw: ah, so no ('setup') at all then? as the initial one would already be in ('test1', '', V)
<pitti> apw: i. e. I don't understand the difference between (setup, '') and (test1, '')
<apw> that is essentially (test1, setup, V) yes
<pitti> ah, ok
<cjwatson> pitti: for LP we mostly take the approach of just stripping off build profiles, although you have to be quite careful with that because obviously < and > have other meanings too.  There's a giant regex in modern libdpkg-perl that can sensibly be appropriated for the purpose.
<pitti> so, [ (test1, '', V), (test2, '', V), (test2, 'reboot_id', V2), ...]
<pitti> apw: ^
<apw> pitti, that seems more than enough indeed ... i hope we anr't overdoing it
<pitti> cjwatson: ack, thanks
<apw> pitti, and would you have kernel_version: as the "after update" one for the common case ?
<pitti> apw: "after test bed setup" would be the first entry with the special reboot ID ''
<apw> ie at the start of the first test, so always the first entry in fact
<pitti> right, and it's a list, thus ordered
<pitti> apw: with that we only need exactly one kernel_versions: with that list of triples
<apw> well that works for my use case :)
<apw> ironically i will just run the list and make sure V does not change, and use it
<pitti> apw: http://paste.ubuntu.com/12327750/
<pitti> apw: (no tuples in json, they become lists, but *shrug*)
<apw> that looks good to my eye, over engineered to hell and back i am sure, but yes
<apw> pitti, is this going to be like a systeminfo file with other things later ?
<pitti> apw: so that's one option; the other is http://paste.ubuntu.com/12327760/
<pitti> apw: yeah, hence the top-level dict
<pitti> apw: I don't want to add yet another file in the future for similar system state info
<pitti> apw: and in fact I'd like to merge testbed-packages into this one
<apw> pitti, the second one is simpler for the normal case, and provides the same info as long we include any test which runs != 1.2 in the bottom
<pitti> apw: a file like this sounds interesting if/once we run tests on real iron
<apw> ie if there was test3 which didn't reboot after test2
<pitti> apw: it's a reduced list, so if there is a test3 which doesn't reboot, it'd just use teh default kernel
<apw> pitti, but we rebooted in test2 and are on that kernel now no ?
<pitti> well, I suppose you can construct a package test which runs test3 without reinitializing the testbed
<pitti> apw: but it would appear in the list then
<pitti> apw: i. e. the idea was to not show anything in the list which has (_, _, default_kernel_version)
<pitti> apw: so that your check reduces to "this list must be empty"
<apw> right, if thats what it is doing, that works too
<pitti> apw: but I don't care much either way, pick your poison :)
<apw> well the second is much shorter in the common case where theer is no reboot
<apw> so ... making it harder for those who care is fine with me :)
<apw> pitti, so i think i am voting for kernel_version + test_kernel_versions form
<pitti> apw: ack; I sent a summary to the bug
<pitti> and now, lunch for realz
<apw> perhaps kernel_version_changes: to get them to sit by each other in the json
<apw> as it is a delta list effectivly
<pitti> noted in the bug, good call
<apw> pitti, you should record the trigger in there too
<apw> just becasue, and name the file such that it can :)
<pitti> apw: *nod*
<teward> at what point did we switch to predictable interface names?  Is that a recent thing?  (First proposal email I can find is May 2015...)
<ogra_> heh ... i still cant stop laughing about that naming :)
<ogra_> teward, i think in wily at some point
<teward> ogra_: what about retroactive changes?  Trusty (all variants) still on the older system?
<ogra_> pitti might have the exact date
<ogra_> yeah, trusty still uses properly guessable names
<pitti> teward: https://lists.ubuntu.com/archives/ubuntu-devel/2015-June/038786.html
<pitti> on June 17
<ogra_> such an insane move
<teward> pitti: and that was never implemented retroactively, or for the latest trusty point releases?
<pitti> teward: heck, no -- that's a rather intrusive change, it's really not backportable
<ogra_> haha, yeah
<teward> pitti: tell that to dschatz_ in -server
<pitti> well, "able" yes, but we so much won't
<teward> right, i knew it was being enabled in Wily, heck I even discovered the server installer iso bug where it was still using the older system and not the one it should be (the 'installer installs eth# which means networking doesn't load after reboot' problem)
<teward> which was fixed same-day xD
<ogra_> well, but that shows pretty good why backporting would be insane :)
<teward> and i'm fairly familiar with "Yeah not backporting sorry" things, from all the 'security' changes from the SSL vulns and such that prompted default-config changes in http server packages and such that didn't get backported to other ubuntu releases, but meh.  was fairly certain that was the case.
<teward> ogra_: indeed
<ogra_> lots of scripts to change etc etc
<teward> mhm
<teward> oop that reminds me.  Note to self: update wily VM >.<
<pitti> apw: http://autopkgtest.ubuntu.com/packages/l/linux/ \o/
<apw> pitti, sweet ... thanks for that
#ubuntu-devel 2015-09-11
<pitti> Good morning
<Laney> doko: mitya57: sphinx-rtd-theme-common -> libjs-modernizr (universe), missing MIR it seems
<Laney> although this BDs on node stuff so that might be a problem
<doko> Laney, right, I may just try to build without that theme
<Laney> could maybe replace the minifier in modernizr if we have another one in main
<LocutusOfBorg1> ginggs, known problem the local build failure
<LocutusOfBorg1> I didn't investigate it yet
<LocutusOfBorg1> but on builders everything is fine
<Unit193> LocutusOfBorg1: Any chance virtualbox will grow the 'vboxweb-service' of virtualbox-* from Oracle?
<ginggs> LocutusOfBorg1: hi - i suspect your arch all target needs net access, but trying a binary-only local build now
<LocutusOfBorg1> Unit193, I don't know what are you talking about :)
<jamespage> Logan, hey - I need to steal your python-ldap3 merge to resolve some FTBFS in tldap - hope thats OK :)
<ginggs> LocutusOfBorg1: problem with virtualbox local build failing seems to be if xmllint is found, but PPA build was OK, so I'll sponsor now
<LocutusOfBorg1> ginggs, true, I might try to find and patch it
<LocutusOfBorg1> thanks!
<ginggs> yw
<LocutusOfBorg1> Unit193, please remember to test the ext-pack
<caribou> isn't kind of silly to send /etc/dput.cf with a default to upload to ubuntu ?
<caribou> I just accidentally sent a bunch of test grub2 packages by mistake. Good thing I don't have upload rights
<LocutusOfBorg1> ginggs, I'm going to fix the bug right now
<LocutusOfBorg1> I already have a fix, but I'm testing it
<LocutusOfBorg1> unfortunately I don't think it is worth an upload, but let me know if otherwise
<ginggs> i agree it's not worth an upload on its own
<sladen> caribou: dput from an Ubuntu machine?
<caribou> sladen: yes
<sladen> caribou: it normally is updated to default to the beta release
<caribou> sladen: I had changed my laptop setup but forgot to change my test server
<highvoltage> caribou: I changed my default dput.cf as invalid so I always have to be explicit with uploads
<sladen> ie. to "do the right thing" for the most frequent users of dput on ubuntu systems
<caribou> highvoltage: yeah, did that on my laptop but I'm building on a separate server these days
<highvoltage> ah
<caribou> highvoltage: no big deal as they're trusty pkg so they wouldn't go very far
<sladen> however it's fair point, and perhaps the [DEFAULT] should be disabled
<caribou> sladen: it also contains a local target, so maybe default to local
<sladen> caribou: not with a path that probably won't exist for most people
<sladen> caribou: at the moment it /does the right thing/ for those with credentials
<sladen> caribou: that is different from /doing the wrong thing/ for everyone
<caribou> sladen: true
<caribou> sladen: I suppose that it's only rejected by the AA scripts anyway
<mitya57> Laney, I was going to take care of both after wily release, but as doko moved sphinx-rtd-theme to main, I will look at modernizr today.
<doko> mitya57, yeah, was re-enabling the pypy packages, sorry about that
<mitya57> No problem, it still needed to be done at some point
<ginggs> doko: hi, is it worth keeping the delta on julia ( https://launchpad.net/ubuntu/+source/julia/0.3.2-1ubuntu1 )?  I'd like to sync bug fix release 0.3.11, but can merge if you prefer.
<Teduardo> is anybody maintaining ubuntu still?
<doko> ginggs, well, openlibm would need building on all archs too, let me have a look
<ginggs> doko, i can apply a smilar 'build everywhere' patch to openlibm and see what happens, but there are still issues with patchelf
<ogra_> Teduardo, how do you mean ?
<Teduardo> well logjam still hasn't been fixed in sendmail on ubuntu
<Teduardo> the DH key is still too small and it cant send emails to like 80% of the internet
<ogra_> feel free to send a patch to the universe maintainers then
<ogra_> sendmail is in universe ...
<doko> ginggs, https://launchpad.net/ubuntu/+source/openlibm/0.4.1+dfsg-1build1
<ogra_> comes unmodified from debian
<Teduardo> ugh
<cjwatson> caribou: in practice this doesn't cause much of a problem really
<ginggs> doko, thanks. meh, so much for "openlibm - High quality system independent, *portable*, open source libm implementation"
<doko> ginggs, at least on armhf it built, but:
<doko> Test suite completed:
<doko>   1131 test cases plus 953 tests for exception flags executed.
<doko>   882 errors occurred.
<Odd_Bloke> cjwatson: Thanks for that openssh fix. <3
<cjwatson> np
<cjwatson> Odd_Bloke: oh, since you're here, what's the word on powerpc cloud images?
<cjwatson> have been meaning to catch you ...
<Odd_Bloke> cjwatson: I'm going to spend the next couple of weeks moving all of our image building in to Launchpad (currently we have some post-build bits that we do, which means that we need to run kvm for the arch, which means a ppc64el and/or powerpc host to do it on).
<cjwatson> Odd_Bloke: Oh, I thought it already was in Launchpad
<cjwatson> Odd_Bloke: You build ppc64el images today, don't you?
<Odd_Bloke> cjwatson: Yeah, but we're building those on a POWER7 host which is going to be problematic post-wily.
<cjwatson> Odd_Bloke: Sure; but a ppc64el host can run kvm for powerpc guests
<cjwatson> Odd_Bloke: So this shouldn't be a blocker for doing powerpc images
<doko> ginggs, so feel free what to do. I usually like to see the ftbfs explicitly, not just be hidden. but it's your call
<Odd_Bloke> cjwatson: Right, we could do that, but we'd undo it all and put it on to Launchpad in the near future anyway.
<ginggs> doko, yeah in julia 0.4 they 'use system libm' and 'use system patchelf' and I was able to build it on armhf.  I'd like to look trying the same for other archs.  So I'll merge 3.11 for now
<ricotz> doko, hi, I assume librevenge misses the version for conflicts/replaces against *v5
<Odd_Bloke> And the ppc64el stuff is very hacky, so changing it to support powerpc is high risk.
<cjwatson> Odd_Bloke: All right.  Please let me know if there's anything we can do to help, as this will be a major part of moving powerpc into scalingstack.
<Odd_Bloke> So the plan of attack is: (a) move all wily building in to Launchpad (via livecd-rootfs/live-build changes), (b) backport those changes to older versions.
<cjwatson> Odd_Bloke: I'm assuming you can lift a bunch of the control logic from cdimage
<doko> ricotz, why?
<Odd_Bloke> cjwatson: I haven't dug in to it yet; I'm tying up loose ends this week so I can focus on it properly next week.
<cjwatson> OK
<Odd_Bloke> cjwatson: But getting this done is good on many, many levels, so it is definitely going to get done.
<ricotz> doko, ah sorry, I meant libetonyek
<doko> ricotz, version?
<ricotz> Conflicts: libetonyek-0.1-1v5 (<< 0.1.3-1ubuntu3)
<ricotz> (no need to provide a transitional package otherwise)
<ricotz> like you already did with the other libs like wps
<doko> wps has a transitional package
<ogra_> cjwatson, i got this ugly resize script (the go_gpt() is to be dropped once bug 1490608 is fixed) ... do you know if i actually need the "blockdev --rereadpt" call if parted just created a new GPT or can i rely on the kernel to update properly
<ubottu> bug 1490608 in parted (Ubuntu) "parted allows to fix broken GPT only interactively" [Undecided,New] https://launchpad.net/bugs/1490608
<ogra_> cjwatson, err http://paste.ubuntu.com/12337129/
<ricotz> doko, yes, i know, and in libetonyek you forget the versions, try to install calligra-libs
<cjwatson> ogra_: parted does that itself; you shouldn't need to.
<ogra_> cool
<ogra_> thanks
<doko> <doko> ricotz, version?
<ricotz> doko, what do you want to know? you uploaded this 2 hours ago
<doko> ricotz, the version of libetonyek
<ricotz> https://launchpad.net/ubuntu/+source/libetonyek/0.1.3-1ubuntu3
<infinity> pitti: wolfe-02 is a bit segfaulty.
<ricotz> doko, https://paste.debian.net/plain/311309
<doko> ricotz, fix uploaded
<pitti> infinity: oh? I don't seen anything unusual in dmesg
<infinity> pitti: Well, the segv in the kernel test was definitely not a problem with the binary that segfaulted.
<infinity> (I've retried it, hoping for another slave)
<pitti> infinity: oh, for linux? I already retried that, but *shrug*
<pitti> infinity: you figure rebooting the VM might help?
<infinity> pitti: Yeah.
<pitti> it's currently running linux-lts-utopic and ruby-libxml
<pitti> I'll let at least the latter finish
<pitti> fginther, apw, elopio: do you actually use autopkgtest's "summary" file for anything? i. e. could I change that to summary.json and enrich it with some extra info (kernel versions, adt backend, etc.)?
<doko> hmm, the libxml2 fix introduce some failures. maybe better revert back to 2.9.1 like Debian?
<pitti> doko: that error is in tracker's build log now (during the test), but the actual failure is "ERROR: tracker-sparql - missing test plan" -- seems unrelated?
<doko> ginggs, julia still has the b-d on openlibm?
<doko> pitti, glib2.0 on ppc64el failed too after the upload
<doko> otoh, publican now built
<ginggs> doko, for now yes
<pitti> doko: already retried, that looked like another race ("ERROR:/build/glib2.0-7SKaCg/glib2.0-2.45.7/./glib/tests/testing.c:127:test_fork_fail: code should not be reached")
<doko> ok
<pitti> will just take an hour or so to catch up, there's some queue
<apw> pitti, erm i use .. err ... is that in the result.tar ... if so no
<pitti> apw: no, it's not, it's in artifacts.tar.gz
<apw> pitti, oh so this won't be in results this new info ?
<apw> result.tar
<pitti> apw: it will
<apw> anyhow no i do not use artifacts at all
<pitti> apw: 'cause you want/need it
<pitti> and it's small
<doko> jamespage, that's an interesting distribution format ;-P http://web.eecs.utk.edu/~plank/plank/papers/GF-Complete-Archive.pdf
<jamespage> doko, indeed
<jamespage> doko, it does have a new home - http://jerasure.org/
<doko> jamespage, why not ship the current version?
<doko> there is a 2.0 release
<jamespage> doko, so you ping made my observer - let me take a look
<doko> and add a watch file =)
<elopio> pitti: sounds like a good idea.
<elopio> we don't use it at all. I sometimes look at it.
<mitya57> doko: looks like modernizr isn't really used by sphinx-rtd-theme, I filed https://github.com/snide/sphinx_rtd_theme/issues/245 and want to wait for upstream confirmation.
<doko> mitya57, ta
<LocutusOfBorg1> ginggs, http://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/commit/?id=b3d9373289eab93f8ddf530549ee296003de8342
<LocutusOfBorg1> :)
<LocutusOfBorg1> thanks
<ginggs> LocutusOfBorg1: no worries, but your changelog entry doesn't describe what you actually did
<jamespage> doko, I need to look at this properly, but my inkling is that all of the testing both in debian/ubuntu and upstream has currently been done against the current packaged version, not the newer one
<jamespage> upstream in swift/liberasurecode that is
<doko> jamespage, python-pyeclib looks ok, but the three library package could need some cleanup
<jamespage> doko, ack
<jamespage> doko, what about liberasurecode? I have done work directly on that package to knock it into shape
<doko> liberasurecode:
<doko>  - liberasurecode1 has a hard-coded dependency on a shared library, please remove
<doko>  - there is a newer 1.0.9 release, update?
<doko> please also fix:
<doko>  - enable parallel build
<doko>  - add Multi-Arch: same attributes
<doko>  - library is underlinked, -ldl missing
<doko> so minimum is to remove the hard coded library
<jamespage> doko, its hard coded as its loaded as a plugin, not as a linked library
<jamespage> (libjerasure2 I'm assuming)
<doko> ohh
<LocutusOfBorg1> ginggs, true
<LocutusOfBorg1> updated
<doko> jamespage, ok, makes sense
<infinity> pitti: Wat?
<infinity> autopkgtest for keystone 2:8.0.0~b2-0ubuntu2: armhf: Test in progress
<infinity> pitti: Why did python-passlib only trigger keystone on armhf and no other arches?
<pitti> infinity: you know, you have sooo many questions!
<infinity> pitti: I KNOW!
<pitti> infinity: filed as bug 1494786, for my Monday enjoyment
<ubottu> bug 1494786 in Auto Package Testing "sometimes triggers tests for one architecture only" [Undecided,New] https://launchpad.net/bugs/1494786
<infinity> pitti: Oh, it might relate to there also being a new keystone.
<infinity> pitti: Could just be a bit racy on the version mismatch?
<pitti> yeah, I guess something like that
<pitti> infinity: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#sqlalchemy is just fine, but that already ran 6 days ago
<pitti> so it's not about keystone in particular I think
<ginggs> LocutusOfBorg1: looks good :)
<LocutusOfBorg1> thanks ^2
<Riddell> mvo: can I update packagekit to 0.9.5 and packagekit-qt to 0.9.5? that seems to give me what I want to work
<mvo> Riddell: I can not thing of a reason why not, but I have not really followed that development that much recently
<mvo> Riddell: I did the app-install-data update too
<Riddell> mvo: yeah saw that thanks
<mvo> yw
<Riddell> mvo: I've got the updated packages here and it works for packagekit-qt, anything else I should test it with?
<mvo> Riddell: not from my side
<mvo> Riddell: maybe worth checking with Laney
<Riddell> Laney: ping :)
<Laney> Riddell: dunno, look at rdeps :)
<infinity> mvo: Oh hey, you're around.
<infinity> mvo: It came up yesterday in the LP meeting, wrt hashed Packages, is apt 1.1 targetted for 16.04 (and, if not, how can we make it be?)
<mvo> infinity: yes, early wily+1
<mvo> infinity: it will go to unstable once there are less transitions
<infinity> mvo: Excellent.  The sooner, the better, IMO.
<mvo> yes!
<fginther> pitti, nothing I look after uses summary
<fginther> (which is just boottest)
<alexbligh1> I'm trying to help someone who using using debconf to produce an installer for a package. He's using the example given within http://manpages.ubuntu.com/manpages/utopic/man7/debconf-devel.7.html - in essence 'go back' from step 2 to step 1 works fine in the curses installer, but not in the CD-ROM installer. Is there a known example where 'go back' is implemented in a shell script and works for the CD-ROM instal
<alexbligh1> ler? Or any clues on how to debug it?
<alexbligh1> (for bonus points, it worked on 10.04 allegedly, but not 14.04)
<cjwatson> should work the same way, I suggest getting DEBCONF_DEBUG=developer traces from both and comparing
<cjwatson> generally the first step with any debconf problem
<alexbligh1> cjwatson, thanks. What actually implements db_go? (as you can tell I know nothing about this!)
<alexbligh1> (I mean on the CDROM installer)
<cjwatson> alexbligh1: /usr/share/debconf/confmodule in either case
<cjwatson> alexbligh1: but it gets sent to whatever implements the server end of the debconf protocol; cdebconf in the case of d-i (which I'm guessing is what you mean by the "curses installer", btw it only looks a bit like curses it isn't actually curses), debconf in the case of ubiquity (which I'm guessing is what you mean by the "CD-ROM installer")
<cjwatson> alexbligh1: in the case of ubiquity, ubiquity intercepts the debconf protocol and fiddles with it in some cases
<cjwatson> so um it depends
<cjwatson> but DEBCONF_DEBUG=developer is absolutely the first step, it may well just be a simple bug at the client end
<alexbligh1> cjwatson, um, I mean whatever the thing is with the blue background at the normal command line on ubuntu-server once installed in the first case, and whatever you get on a normal ubuntu server CD-ROM install on the other. No graphical fanciness I don't think.
<alexbligh1> cjwatson, thanks. I'm wondering if something is fiddling with the return values somehow. It's as if db_go is always returning 0 (i.e. 'next').
<cjwatson> alexbligh1: oh, that wasn't at all how I interpreted what you meant ...
<cjwatson> alexbligh1: debconf in the former case, cdebconf in the latter, then
<cjwatson> alexbligh1: that sounds like the backup capb isn't set
<alexbligh1> cjwatson, how does one set the backup capability (assuming I'm translating that right)?
<cjwatson> alexbligh1: db_capb backup
<alexbligh1> cjwatson, (the button appears, it just doesn't work)
<cjwatson> alexbligh1: ok, if the button appears, the capb is likely set
<alexbligh1> cjwatson, that's right at the top of the example in the man page so I'm pretty sure he used that - let me check the source ....
<cjwatson> alexbligh1: so let's see a debug trace
<cjwatson> much quicker than guessing
<alexbligh1> cjwatson, yeah it starts "db_version 2.0" then "db_capb backup". I'll get him to produce a debug trace. I think he's gone home now (slacker).
<alexbligh1> cjwatson, thanks anyway
<cjwatson> alexbligh1: go back definitely works in d-i, we use it in many places
<cjwatson> inc. from shell, not that it makes a difference, same protocol either way
<alexbligh1> cjwatson, yeah, though he couldn't find an instance of it working from the CD-ROM, save for Postfix which is allegedly written in perl.
<cjwatson> alexbligh1: localechooser for instance, very first stage of the installer, written in shell
<alexbligh1> cjwatson, apparently it only breaks if you ask more than one question in each stage or something. Debug trace needed anyway.
<alexbligh1> cjwatson, ok, I will point him at that.
<alexbligh1> cjwatson, thanks
<cjwatson> alexbligh1: cdebconf doesn't support grouping, perhaps that's the problem.  you must ask one question per stage
<alexbligh1> cjwatson, AAAAAHHHH! well that would be exactly the issue.
<cjwatson> the beginblock/endblock stuff will not work with cdebconf
<alexbligh1> cjwatson, right. Well that explains everything. Thanks a million. Looks like we'll need to split it out into one stage per question (which is easy enough).
<cjwatson> (it's only a stub with debconf too; but perhaps the fallback mode is different)
<cjwatson> yeah
<cjwatson> np
<mterry> doko!
<mterry> knock it off with these perl pkgs  :)
<doko> ;)
<mterry> I'll get this one, no prob
<doko> should be the last ones for this cycle, promised!
#ubuntu-devel 2015-09-12
<hjd> Hi all. The new version of Jruby has failed to build on Ubuntu Wily (see bug 1491526). I believe this issue has been resolved now, since I was able to build the package on a local Wily vm. Could someone trigger a rebuild for this package to see whether we could get the newer version into the archives?
<ubottu> bug 1491526 in jruby (Ubuntu) "jruby FTBFS when running mspec tests" [Undecided,New] https://launchpad.net/bugs/1491526
<cjwatson> hjd: I've pushed retry
<cjwatson> hjd: seems reasonable for you to close that bug if the build succeeds:
<cjwatson> https://launchpad.net/ubuntu/+source/jruby/1.7.21-2ubuntu4/+build/7851239
<hjd> cjwatson: Will do. Thank you. :)
<cjwatson> hjd: Looks like it still fails (maybe differently?  I haven't checked)
<hjd> cjwatson: Hm... didn't get that locally. Though I didn't upgrade my existing packages after enabling -proposed so might have some slight difference there (?). There's fewer test failures, so looks like it's heading in the right direction at least. I'll update the bug report.
<Muyfret> I have used ubuntu-like technology to develop a form of Ai. it is not complete. but i find it very interesting
<teward> anyone able to answer a question about the debian/copyright format?
<TJ-> teward: try asking :)
<teward> :p
<teward> How would one put 'Portions copyright ABC Corporation' as a secondary copyright entry for a specific Files: section in debian/copyright?
<teward> i know that there's the format of 'year-a person-a; year-b person-b' (the ; is a line separator in that quoted area), but not sure how to specifically achieve the 'portions' part...
<TJ-> Multiple Copyright lines:  https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#copyright-field
<teward> TJ-: that's what I assumed.  Thanks for confirming.
#ubuntu-devel 2016-09-12
<pitti> Good morning
<Unit193> Howdy.
<Unit193> pitti: You seen LP 1617063?
<ubottu> Launchpad bug 1617063 in network-manager (Ubuntu) "from alternate lubuntu installs network manager does not manage devices or give network info" [Undecided,Confirmed] https://launchpad.net/bugs/1617063
<pitti> Unit193: should have been fixed by https://launchpad.net/ubuntu/+source/netcfg/1.138ubuntu2
 * pitti dupes
<Unit193> So should be fixed if one has ubiquity 16.10.10, and if it isn't?
<Unit193> pitti: What's supposed to be doing that on a live system, btw?
<pitti> Unit193: livecd-rootfs creates that netplan conf file
<pitti> Unit193: this only affected d-i installs (alternate, netboot)
<Unit193> Niiiiice. >_<
<cpaelzer> good morning
<pitti> xnox: http://autopkgtest.ubuntu.com//packages/s/software-properties/yakkety/amd64 looks like fallout from gnugp2?
<jbicha> xnox: but please look into https://code.launchpad.net/~jbicha/software-properties/use-gi-require_version/+merge/304193 before doing another software-properties upload, I've already rebased twice
<flexiondotorg> Anyone here who can add an additional package to my PPU package set please?
<flexiondotorg> I uploaded all of MATE 1.15 to the Yakkety archive on Friday.
<flexiondotorg> But libmatemixer is not in my package set, so was rejected.
<flexiondotorg> Now I have broken MATE in Yakkety, because several core components are missing a required package :-(
<flexiondotorg> rbasak, Can you help with the above?
<rbasak> flexiondotorg: looking
<flexiondotorg> rbasak, Many thanks.
<pitti> smoser: new c-i works well here (in y); I created a xenial image template with the y cloud-init plus the new invoke-rc.d/service, and now everything is smooth as silk
<pitti> smoser: I uploaded the i-s-h SRU and updated bug 1576692, I think everything is done on my end now; anything missing still? (aside from bug 1620780 which is now merely a nuisance rather than a breaker)
<ubottu> bug 1576692 in init-system-helpers (Ubuntu Xenial) "fully support package installation in systemd" [High,In progress] https://launchpad.net/bugs/1576692
<ubottu> bug 1620780 in systemd (Ubuntu) "dev-sda2.device job running and times out" [Undecided,Triaged] https://launchpad.net/bugs/1620780
<mapreri> pitti: could you render the Date in browse-results something more human-readable?  I was looking to write a patch it, but it seems like the date is saved as text in the db, so I can't like strftime() it (at least, not without strptime() it beforeâ¦).
<pitti> mapreri: the run IDs always looked like that, but indeed in debci I massaged it a bit
<pitti>       status.date =
<pitti>         begin
<pitti>           Time.parse(data.fetch('date', 'unknown') + ' UTC')
<pitti> that was the ruby equivalent
<pitti> err, no, not that
<pitti> mapreri: strptime/strftime seems right
<mapreri> sec..
<pitti> or just re.match() and reformatting it
<pitti> mapreri: be prepared for suffixes, though
<mapreri> pitti: mean?
<pitti> mapreri: e. g. I'll soon add a 20160902_110956.workername
<mapreri> arg.
<pitti> as sometimes we have test results that finish at the exact same second
<mapreri> pitti: in the code you do a .rstrip('@'), is that something related?
<pitti> mapreri: so, just taking the first YYYYMMDD_HHMMSS and ignoring everything  else will DTRT
<pitti> mapreri: yes, the run ID always ends with @ for technical reasons
<mapreri> sounds awful
<pitti> (so that you can efficiently query all results in swift without having to list all the individual files)
<pitti> mapreri: so by just taking the date/time prefix and ignoring the rest, the @ will automatically be ignored too
<pitti> mapreri: and that  format is guaranteed
<mapreri> pitti: I could lsplit('@', 1)[0] ?
<mapreri> no, wait, @ is always at the end, you said
<pitti> mapreri: yes, rstrip is more efficient
<pitti> mapreri: but just taking/parsing the date/time prefix is more generic
<pitti> >>> time.strptime('20160902_110956.workername@', '%Y%m%d_%H%M%S')
<pitti> ValueError: unconverted data remains: .workername@
<pitti> me
<pitti> meh
<mapreri> yeahâ¦
<pitti> time.strptime('20160902_110956.workername@'[:15], '%Y%m%d_%H%M%S')
<pitti> that works fine
<mapreri> umh, i don't particularly like it, though
<pitti> >>> time.strftime('%Y-%m-%d %H:%M:%S UTC', time.strptime('20160902_110956.workername@'[:15], '%Y%m%d_%H%M%S'))
<pitti> '2016-09-02 11:09:56 UTC'
<pitti> ?
<mapreri> pitti: https://paste.debian.net/818514/ ?
<mapreri> though I obviously can't really test it
<pitti> >>> re.sub(r'(\d\d\d\d)(\d\d)(\d\d)_(\d\d)(\d\d)(\d\d).*', r'\1-\2-\3 \4:\5:\6', '20160902_110956.workername')
<pitti> '2016-09-02 11:09:56'
<mapreri> wellâ¦
<pitti> that's more direct, avoids the slicing, and converting back and forth
<rbasak> flexiondotorg: done. Sorry it took so long. germinate takes a while to run.
 * mapreri prefers readability, but feel free to do it the way you prefer :)
<mapreri> also, I should be doing something else, alas
<pitti> mapreri: done (check the web pages, rolled out)
<pitti> mapreri: https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/commit/?id=25eef3a
<mapreri> look cool, thanks! :)
<pitti> mapreri: I prefer that as it will just transparently fall back to the raw run_id if the format is unexpected/different for some reasons
<mapreri> ok
<flexiondotorg> rbasak, Brilliant. Thank you.
<flexiondotorg> rbasak, Upload accepted :-)
<xnox> pitti, there is fallout indeed, digging deeper into it, there is more than just add-apt-repository failure.
<jamespage> ok - can someone explain to me why http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#python-oslo.messaging is complaining that python-oslo-messaging is no longer build
<jamespage> python-oslo-messaging was a transitional package for xenial; the archive is switched to python-oslo.messaging, so its ok to drop I think
<LocutusOfBorg> jamespage, maybe some archive-admin needs to remove it?
<LocutusOfBorg> slangasek, ^^ :)
<jamespage> LocutusOfBorg, yeah - I thought so but they are normally awesome at doing that without asking :-)
<LocutusOfBorg> AFAIR the process is semi automatic
<LocutusOfBorg> not sure what it does exactly mean :)
<LocutusOfBorg> you can add it to my bug report https://bugs.launchpad.net/ubuntu/+source/libpng/+bug/1595485
<ubottu> Launchpad bug 1595485 in ldc (Ubuntu) "packages to remove from yakkety" [Undecided,New]
<jamespage> maybe I could impose on doko_ if hes around ^^ ?
<jamespage> pretty please :-)
<pitti> stgraber, xnox: I think lxc's tests also got broken by the move -- "ERROR: Unable to fetch GPG key from keyserver" sounds like that?
<xnox> missing dirmngr dependency
<pitti> oh, depends vs. recommends?
<xnox> as that one is only a recommends, yet is now required for --recv-keys to work
 * xnox is not sure if dirmngr should become depends now.
<pitti> ah, great that you know about it already -- so should apt depend on that now, perhaps?
<xnox> pitti, is that lxd or lxc package?
<pitti> xnox: lxc so far (http://autopkgtest.ubuntu.com/packages/l/lxc/yakkety/amd64) - first run after the switch
<pitti> http://autopkgtest.ubuntu.com/packages/l/lxd/yakkety/amd64 ran on Friday, that was after the switch (and passed)
<xnox> yeap, lxc-templates does --recv-keys
 * xnox running tests locally to see if dependencies will fix it.
<cpaelzer> is a ppa in status "Pending publication" already fulfilling dependencies for other sources uploaded to the same ppa?
<mapreri> pitti: btw, looking at http://autopkgtest.ubuntu.com/packages/d/diffoscope/yakkety/amd64 (but also other (I'd expect faster) architectures.  That run time is incredibly high.  In my local machines the tests run in 3-4 minutes, so does in debian's debci.  Are maybe the workers overloaded or something?
<cjwatson> cpaelzer: no
<xnox> pitti, for lxc adt tests started https://requests.ci-train.ubuntu.com/#/ticket/1934
<pitti> xnox: wow, lxc is being landed through the CI train??
<pitti> gpg: keyserver receive failed: No dirmngr
<pitti> xnox: ^ apport seems to suffer from the same, but the dirmngr package is installed already; does this require any further deps?
<pitti> gpg: connecting dirmngr at '/run/user/1000/gnupg/S.dirmngr' failed: No such file or directory
<pitti> oh, maybe that
<pitti> there's no reason why this would be running
<xnox> pitti, so i believe that gnupg2 is wrong in the sense that when $GNUPGHOME doesn't exist, and it tries to use dirmngr, it doesn't create $GNUPGHOME first.
<xnox> in a few places e.g. a dummy $ gpg -k >/dev/null 2>&1 => is executed just to create the $GNUPGHOME with the correct permissions.
 * xnox ponders where to file the bug report
<pitti> oh, I actually do have a /run/user/1000/gnupg/ in my testbed VM
<pitti> and about 15 instances like dirmngr --daemon --homedir /tmp/tmp.h4znVNEFQG
<pitti> just nothing in the /run/user/1000/gnupg/ dir
<xnox> lol
<xnox> well, homedir must be used consistently....
<xnox> apport you say?
 * xnox looks
<pitti> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/a/apport/20160912_102515@/log.gz
<pitti> I reproduced in a local VM, currently looking at it
<pitti> xnox: indeed I set a temporary $HOME for the tests, to avoid them destroying your real $HOME
<pitti> xnox: so you say this might not get exported to some GPG processes then?
<xnox> but that doesn't quite get through everywhere, becase - gpg: connecting dirmngr at '/root/.gnupg/S.dirmngr' failed: No such file or directory
<pitti> right, that's XDG_RUNTIME_DIR
<xnox> gpg --keyring /tmp/foo.gpg --recv-keys => is not enough anymore, as that implies ${GNUPGHOME:$HOME/.gnupg}/S.dirmngr
<pitti> and I suppose if neither GNUPGNOME nor HOME exist, it uses $XDG_RUNTIME_DIR?
<pitti> or does dirmngr always use that, but runs under a different $HOME?
<xnox> i don't believe it ever uses XDG_RUNTIME_DIR
<xnox> it uses --homedir, env[GNUPGHOME], env[HOME]
<pitti> when I run the test as user, it looks in /run/user/1000/gnupg/S.dirmngr
<pitti> which is XDG_RUNTIME_DIR
<pitti> actually, I don't change $HOME anywhere in these tests, hmm
<xnox>   /* It has been suggested to first check XDG_RUNTIME_DIR envvar.
<xnox>    * However, the specs state that the lifetime of the directory MUST
<xnox>    * be bound to the user being logged in.  Now GnuPG may also be run
<xnox>    * as a background process with no (desktop) user logged in.  Thus
<xnox>    * we better don't do that.  */
<xnox>   for (i=0; bases[i]; i++)
<xnox>     {
<xnox>       snprintf (prefix, sizeof prefix, "%s/user/%u",
<xnox>                 bases[i], (unsigned int)getuid ());
<xnox>       if (!stat (prefix, &sb) && S_ISDIR(sb.st_mode))
<xnox>         break;
<xnox>     }
<xnox> totally does
<xnox> but doesn't create the directory first.
<xnox> horum, i should stop pasting code
<xnox> there clearly is code to create /run/user/$id/gnupg.... if /run/user/$id exists.
<pitti> I don't change $HOME anywhere actually, so no idea where that "dirmngr --daemon --homedir /tmp/tmp.Ulx980iySm" comes frmo
<pitti> anyway, I'll try to create ~/.gnupg
<pitti> gpg: WARNING: unsafe permissions on homedir '/home/ubuntu/.gnupg'
 * pitti tries that harder :)
<smoser> pitti, your assessment above is right.
<smoser> and i will upload an SRU of cloud-init to xenial "right now".
<pitti> smoser: good morning
<pitti> smoser: yay
<pitti> still waiting on LP to import the new init-system-helpers for syncing
<pitti> oh, there it is, syncing
<pitti> nice, that used to take a lot longer a few weeks ago, so kudos to whoever sped up the imports again
 * pitti thanks cjwatson and wgrant
<pitti> (and if you didn't do it -- thanks anyway for your great work! âº )
<pitti> xnox: ok, creating ~/.gnupg helped a lot -- two failures gone, one remaining one that complains about a missing pubkey, but I think that's my fault/new apt
<xnox> pitti,  i use $ gpg -k -> to create ~/.gnupg with the right permissions =) (and redirect stdout/err)
<cjwatson> pitti: We didn't do anything in particular.  Probably happened to hit more favourable dinstall/mirror timing)
<rbasak> balloons: about your proposal to remove other juju arches from the archive, what makes Juju different from every other packaged upstream that doesn't officially support a particular arch but for which we do build on those arches?
<balloons> rbasak, my primary reason for removing arches is we are prevented from landing fixes into the archive should one of the 32-bit arches fail to build
<balloons> rbasak, until now these arches have been building, but unsupported.
<rbasak> balloons: that doesn't answer my question.
<balloons> rbasak, juju has to support what the providers support. They are 64-bit only
<rbasak> balloons: what about MAAS? Is that 64-bit only?
<pitti> the bit that I don't understand yet is why azure support cannot be removed on 32 bit, if it was just added recently
<rbasak> Or how about the local provider?
<wgrant> Or architectures that aren't 64-bit.
<wgrant> eg. powerpc, i386 and armhf
<pitti> (which AFAIUI is the only provider that doesn't support 32 bit)
<balloons> rbasak, the trouble I feel is doing "best-effort" on primary arch like i386 doesn't make sense
<wgrant> It's really useful to be able to use our key deployment technology in parts of the Launchpad build farm, for example.
<balloons> local provider is lxd, so yes, it would support 32-bit. MAAS also. The clouds themselves however are 64-bit
<rbasak> balloons: I understand your concern, but I don't see why Juju should be special here. The issues you raise apply equally to every other package, no?
<pitti> it's not too difficult to drop teh 32 bit builds on yakkety; but impossible on xenial, so we need some transition there, like empty transitional packages with a debconf nor or NEWS at lesat
<balloons> rbasak, I am concerned about unsupported builds, but I'm ok with it. As you say, it's not the only package like this. My concern comes in when we are blocked on delivering SRU's because of failing builds on things we don't support
<rbasak> balloons: given that we don't do this for other packages, I think we should either identify Juju as special, or do the same for every package.
<balloons> in the past if it was something like armhf, we could overlook it and land
<balloons> but i386 is so primary.. Anyways, I am certainly open to a solution that makes sure we can land fixes and updates as needed
<rbasak> I think that's worth exploring.
<balloons> pitti, azure support has been included for some time, but the upstream changed their SDK, which is the reason for the current breakage
<pitti> balloons: and the SDK that we have in xenial doesn't work any more?
<pitti> or, I figure it's bundled in the juju source
<balloons> pitti, I believe it will stop working sometime this year as they deprecate support for it. Obviously the cloud provider has the control around that
<balloons> rbasak, so what did you have in mind?
<pitti> right, so keeping the old SDK is not an option; disabling azure support sounds better then
<pitti> or empty transitinoal packages for xenial, and dropping the arches on y as a last resort
<rbasak> balloons: I don't know. I'd want to understand more about the problem first - for example why exactly this problem crops up in the first place - because nobody should be regressing a stable release in an SRU, but an FTBFS where it previously succeeded suggests such a regression. But I'm not on the release team or TB, so I'm just an observer here.
<rbasak> balloons: I'm only bothered that your ML post had no replies. I'd prefer to see such a change to have at least a +1 from a release team member before upload, because it feels quite invasive. You did the right thing by bringing it up - thanks.
<cjwatson> Dropping powerpc on xenial would definitely be disruptive to our plans for converting remaining builders to scalingstack, as wgrant suggests.
<cjwatson> On other architectures we can avoid the problem because there's a 64-bit partner architecture we can run 32-bit code on in compatibility mode, but that isn't the case for powerpc because of the endian difference.
<pitti> cjwatson: oh, you run the juju controller in scalingstack?
<balloons> rbasak, I also have big concerns over xenial. But given the provider plans to get rid of the old SDK, we're stuck no matter what. Xenial will lose support
<balloons> cjwatson, I had no idea launchpad was a 32-bit client consumer
<pitti> oh right, this would affect the client as well
<balloons> pitti, right remember -- client/agent is really the same
<cjwatson> pitti: At the moment they run in privileged containers, but there's a refactoring in progress to make them less privileged so that they're easier to debug and so that it's possible to do things like powerpc in them.
<pitti> so how hard is it to build with --disable-azure on 32 bit?
<rbasak> balloons: I think you're conflating provider support with architecture support there. If a provider drops support or changes things, I think we already accept that an SRU that deals with that specific change is fine.
<cjwatson> balloons: It's not yet, but we had plans for it to be in order to get powerpc builders off bare metal, and avoiding juju in that plan is quite complicated.
<cjwatson> balloons: We have no interest in the Azure provider specifically though.
<wgrant> pitti: jujud must also run on all the machines that run the charms; this isn't just the controller or client, unfortunately.
<wgrant> (I have to wonder how one makes a webservice SDK only work on 64-bit architectures, however!)
<pitti> well, not too surprising for a windows-oriented cloud?
<wgrant> Unless webservice clients have their own tagged pointer implementations nowadays.
<wgrant> Not surprising that they don't use 32-bit themselves, but I'm wondering how one actually goes about breaking 32-bit without doing it deliberately.
<pitti> balloons: how hard is it to build with --disable-azure on 32 bit?
<balloons> pitti, I think we could quilt patch that
<balloons> it would have to be a source modification I believe
<balloons> pitti, is there a better way to provide a source modification at build time for a specific arch? And rbasak, if we pursued this idea of netuered packages, is that more palatable to you?
<pitti> balloons: easier to make it configurable upstream, or implicitly disable azure support on unsupported arches
<pitti> we know upstream, after all :)
<pitti> no need for hackpatchery
<rbasak> balloons: there are some examples of arch-specific patches being added. You can do it in debian/rules, and keep arch-specific patches somewhere in debian/. And yeah, what pitti said.
<balloons> pitti, the issue is go doesn't support build-time config options afaik
<pitti> we want to have the upstream CI on those arches too, and with downstream patches these couldn't run
<rbasak> balloons: dropping support gracefully in an SRU when a provider changes something that breaks a stable release is fine I think. I don't know if that is what you're seeking here or not.
<balloons> hence the patch suggestion if we want this route
<rbasak> balloons: but only use of that provider should be affected.
<pitti> beisner: well, aside from that the go build system sucks then :), it doesn't need to be explicit -- just build it if it's available/supported and otherwise not?
<rbasak> balloons: no other use case should not regress.
<rbasak> balloons: no other use case should regress I mean.
<pitti> beisner: sorry, tab failure
<cjwatson> balloons: I don't know if it's idiomatic, but you should be able to do it with build tags.
<balloons> ok, it sounds like we're getting concensus on just removing problematic providers for arches that don't support them
<balloons> and yes, perhaps the core team can figure out a way to upstream it so I don't have to patch, but it sounds like either way it should be doable
<rbasak> balloons: I don't understand how this fits in with your original FTBFS argument. How does Azure changing something cause an FTBFS in a stable release?
<balloons> rbasak, the proposed SRU contains new provider code
<rbasak> balloons: ah, so it's not Azure's action that causes the regression, but your own?
<rbasak> Then I have doubts.
<wgrant> Code for a new provider, or an updated version of an existing embedded code copy?
<rbasak> AFAICS, that's a regression the current SRU policy does not permit, so you need a TB exception.
<balloons> rbasak, no azure changed there SDK. So we now depend on it / build with it. So yes, we changed our code as well, but only to support there new SDK which we have to migrate to
<rbasak> The point of a stable release is to insulate users from upstream changes like this.
<balloons> rbasak, right. That was my point of xenial users are kind of stuck. Even if we kept the old code and old SDK, it would stop working (though it would build)
<rbasak> You only get a free pass if Azure break compatiblity with their old SDK.
<balloons> rbasak, so yes azure sdk broke compatibility and the ability to build on 32-bit. Are you comfortable with an SRU?
<rbasak> balloons: so Juju with Azure on Xenial no longer works at all on any architecture?
<balloons> cjwatson, wgrant I would encourage you to talk with the core team about your needs / plans of adopting juju on powerpc
<balloons> rbasak, it still does currently, but will stop working soon. I don't know the exact date. It also has some real usability issues that have come about because of provider changes -- we monitor command timings for instance
<balloons> it was to be December, but again, that's up to azure
<rbasak> balloons: if "stop working soon" is published by Azure in a public statement, then I have no objection to dropping support for those bits in an SRU then, though I note again that I am not on the SRU team, release team or TB.
<rbasak> It does make sense to handle things in advance for the architectures that will continue to be supported, so users don't face an interruption in functionality. It doesn't make sense to break other archtectures needlessly early, especially if Azure push the breakage date back (presumably due to feedback).
<cjwatson> I do think that users shouldn't have to beg for their stuff to continue working over the course of an LTS cycle.
<cjwatson> (I'm not close enough to this project from our side to talk to the core team myself; hopefully wgrant can)
<balloons> wgrant, please do discuss with the team. I want to make sure they are aware of what you intend to do and how they can / will support it. Let me know if I can help facilitate
<balloons> cjwatson, rbasak, re: LTS users. Just remember this is one of the reason I wanted to drop the package. I don't want users to think they are getting juju on 32-bit when they really aren't
<cjwatson> balloons: Except apparently they are, just not some providers?
<balloons> cjwatson, is it better to not have a package, or have a package in which they lose most functionality over the course of the LTS?
<cjwatson> balloons: That depends how much functionality is at risk in reality.
<cjwatson> s/at risk/actually going to be removed/
<rbasak> balloons: if users are getting juju on 32-bit today, then *they really are*, and we shouldn't break them.
<balloons> we can only speculate of course what will happen in 5 years, but it seems my fears are already being realized, and it's still quite early in the cycle
<cjwatson> It seems to me that you're using a bit of a rhetorical trick here.
<cjwatson> Azure dropping support doesn't really have much bearing on whether Openstack will.
<balloons> I don't mean to be tricky; I have the same concerns at heart you do. I just want to make sure we all think through what could happen over the course of the LTS
<rbasak> Stuff outside what we ship, such as how Azure or any other public cloud provider behaves, is somewhat out of scope. We are subject to their whims, and users understand that. If they act to break something, then that's a breakage we could not have prevented in a stable release.
<cjwatson> If we lose support for the things that are currently available in the future, then we can have that debate then; in the meantime I think we should be able to use the things that currently work.
<rbasak> However, stuff like MAAS and Openstack ship *inside* our release. We have control there, and an SRU policy, and we should stick to that.
<balloons> I can see losing all external providers, and having just openstack and local provider.
<rbasak> So fix them in SRUs. Without breaking other users.
<cjwatson> Which would actually be totally fine for our uses.
<balloons> If that's an "ok" scenario (while not ideal at all), then sure, I'm aligned with the idea of leaving it in
<cjwatson> (I can't speak for other users, obviously, just Launchpad's fairly constrained use case)
<balloons> you have to understand though, juju itself may also break on 32-bit. And upstream won't ensure that it won't. So similar to other packages, it may be on distro to ensure builds, or may have to be removed in the worst case
<cjwatson> We can cross that bridge if and when we come to it.
<balloons> right, I'm giving some worst case scenarios, just to ensure we think about it
<balloons> Likely we'll end up somewhere in the middle of the easy and hard paths
<cjwatson> 32-bit users are already familiar with those worst-case scenarios, really.  Most of the time it winds up not being a problem, and most of the rest of the time it's not too hard to fix.
<balloons> I appreciate everyone's thoughts on this. Thanks for the discussion!
<cjwatson> It helps if upstream aren't aggressively making stuff break, though even then it wouldn't be the first time we've managed to cope anyway :-)
<semiosis> slangasek: whats the next step for getting the livecd-rootfs changes for vagrant into xenial-updates?
<cjwatson> Usually upstream sit in a position that's more like what I think you're describing: they won't test stuff themselves, but they'll take reasonable patches and such
<balloons> cjwatson, yes I think that's where this will land. For instance, powerpc will likely break again and will need a reasonable patch to fix that upstream will take
<balloons> there's no active vendetta
<balloons> cjwatson, wgrant while I have you actually, I have two questions on building snaps via launchpad. The first is I'd like to have multiple branches for a single snap package. One should build to edge; the other to the more stable channels. Is this possible? The second is I would like to build s390. Is this possible?
<cjwatson> balloons: (1) Yes, you can create two different snap objects in LP for that; they need to have different names in LP, but they can share a "Registered store package name", and have different channels.
<cjwatson> balloons: (2) That's limited to Canonical staff because we don't yet have sufficient build sandboxing on s390x (just like devirtualised PPAs), but it can be set up for such people on request.
<kenvandine> doko_, btw the libphonenumber silo is pending for QA now
<balloons> cjwatson, (1) I will try again now and ping you if I can't get it to work again. (2) How should I make a request for the juju snap in particular?
<cjwatson> balloons: https://answers.launchpad.net/launchpad/+addquestion is usually best, with a URL to the snap you want reconfigured
<xnox> pitti, at https://requests.ci-train.ubuntu.com/static/britney/landing-1931/yakkety/excuses.html it says that "systemd" and "lava-server" tests are running, but i don't see them in the queue nor any results. Have they been lost somewhere?
<xnox> i think i will release the new qemu, but it is weird that tests gone MIA
<jgrimm> xnox, what's the new qemu?
<jgrimm> ah, 2.6.1. nvm
<nacc> xnox: is that for yakkety, i assume?
<xnox> jgrimm, drop most patches, and upload "2.6.1" tarball. The net delta is just a few patches that were not cherrypicked.
<xnox> nacc, yeah.
<jgrimm> xnox, cool cool. thanks.  asking as i have a FFe open for set of patches that are ppc64 specific.
<nacc> xnox: ack, i think there was one bug that'd get closed by that, let me see if i can find it -- LP: #1617055
<ubottu> Error: Could not gather data from Launchpad for bug #1617055 (https://launchpad.net/bugs/1617055). The error has been logged
<nacc> heh, i see you already responded there, nm!
<nacc> xnox: thanks for doing that -- i had talked with hallyn about it, and he suggested to me we should follow debian for qemu updates, hence my initial reply
<xnox> yeah, but the diff between 2.6.1 final and all-patches-applied is minimal, especially after the CVE uploads from security team.
<xnox> pitti, where abouts is the new autopkgtest? i think we want to expand the stats page to show things per-arch & per-release, rather than just per-release.
<nacc> xnox: sure, make sense, thanks!
<nacc> rbasak: you don't happen to still be around?
<rbasak> nacc: yes
<nacc> rbasak: hey! have a few minutes? importer questions for you
<nacc> rbasak: not high priority, so it can wait, of course
<hallyn> xnox: nacc: if you haven't already done so, i recomment pushing the new branch to http://anonscm.debian.org/cgit/pkg-qemu/qemu.git #ubuntu-dev
<hallyn> then perhaps telling mjt on #debian-qemu about it, maybe he can git merge
<rbasak> nacc: please ask. I have a DMB meeting in half an hour so I'm roughly around.
<xnox> hallyn, i'm still working out what to revert, because a CVE patch regresses things
<nacc> hallyn: ack, thanks for that info!
<nacc> rbasak: sure, sorry, i went afk myself for a bit
<nacc> rbasak: LP: #1618898, i'm not sure what our solution would be to that case
<ubottu> Launchpad bug 1618898 in usd-importer "stack trace failure on import of apt" [Medium,Confirmed] https://launchpad.net/bugs/1618898
<nacc> rbasak: and re: the isc-dhcp import issues, i'm not sure if we ever came up with a good solution? (specifically the fact that version/series/pocket does not uniquely identify an upload)
<elbrus> has anybody experience with libreoffice timing out during build?
<elbrus> winff builds fine in Debian, but not in Ubuntu
<elbrus> it seems to time out during pdf creation
<rbasak> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping.
<elbrus> https://launchpadlibrarian.net/283037524/buildlog_ubuntu-yakkety-amd64.winff_1.5.3-7_BUILDING.txt.gz
<elbrus> (has been retried at least twice)
<jbicha> elbrus: I suggest asking Sweet5hark in #ubuntu-desktop (but he might be gone for the day)
<elbrus> jbicha: thanks, will try
<sarnold> doko_: jfyi, in the hopes that this may save you some time and hassle some day :) http://www.mono-project.com/news/2016/09/12/arm64-icache/
<nacc> rbasak: also, i think I realized today that I didnt' change the state on MR: #297709
<nacc> rbasak: are you ok with me uploading the fixes for the existing openipmi bugs to yakkety and then doing SRUs to xenial; or do you think it's worth pursuing the merge and FFe?
<nacc> rbasak: i think it'd be fine to do an updated merge once z opens up, but i'd like your feedback
#ubuntu-devel 2016-09-13
<slangasek> semiosis: if you could get Odd_Bloke to build an "official" vagrant test image against xenial-proposed, and then validate that test image, that would be best
<slangasek> jamespage, LocutusOfBorg: fwiw the deal with python-oslo is that there was a never-migrated version of python-oslo in yakkety-proposed that still had python-oslo-messaging, then a later version of the package that dropped python-oslo-messaging; this plays havoc with our autoremoval detection and requires manual escalation just like this
<slangasek> jamespage, LocutusOfBorg: (binaries removed)
<pitti> Good morning
<pitti> xnox: landing-1931> systemd is done, lava-server apparently got lost, I check the logs
<pitti> xnox: stats page is https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/tree/webcontrol/browse.cgi (sql query and preparing the data struct) and https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/tree/webcontrol/templates/browse-statistics.html (HTML jinja2 template)
<pitti> xnox: indeed, it's rather basic for now, we can/should expand it to what we want to know
<pitti> xnox: ah, lava-server hit a quota limit which somehow failed to get treated as temporary failure
<pitti> xnox: oops, no, it's something weirder: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety-ci-train-ppa-service-landing-1931/yakkety/i386/l/lava-server/20160912_113959@/log.gz
<pitti> xnox: lava-server got demoted to -proposed, I suppose that's related; looking closer
<pitti> xnox: created bug 1622846, tracking there
<ubottu> bug 1622846 in Auto Package Testing "packages that are only in -proposed cause stalled "in progress" tests" [Undecided,New] https://launchpad.net/bugs/1622846
<pitti> robru: does bileto pull britney git before running it on every iteration, or does that require a webops request?
<robru> pitti: it pulls every 20 minutes, not before every run
<pitti> robru: ok, great
<pitti> xnox: fix pushed, so the next britney run for that silo should drop these two lava packages and make it green
<pitti> robru: hmm -- do bileto britney runs include proposed in the "testing" indexes?
<robru> pitti: yes
<pitti> ah, that explains it -- then https://requests.ci-train.ubuntu.com/static/britney/landing-1931/yakkety/excuses.html will not be able to test lava-server
<pitti> -proposed does not really belong into "testing"
<robru> pitti: this is how we decided to do it originally... We're considering promoting packages to proposed, proposed is the destination archive
<pitti> hmm; we don't want to run tests against the entirety of -proposed
<doko_> sarnold: that reminds me very much to a talk given at fosdem, debugging the hotspot jit on arm64 ....
<caribou> pitti: any reason why you reverted slangasek's verif-done on LP: #1535898 ?
<ubottu> Launchpad bug 1535898 in multipath-tools (Ubuntu Precise) "Trusty & Vivid multipath-tools (multipathd) seg-fault core dump" [High,In progress] https://launchpad.net/bugs/1535898
<pitti> caribou: yes, there was *still* no explanation of what actually has been tested
<cpaelzer> interesting .. I just came by looking at landing 1931 as well, since I wanted to look at qemu - to double check since I'd do that the first time, can I edit and add my IRC nick to landers on the ticket without causing an unwanted side effect?
<seb128> dpm, pitti, hey, now that launchpad translations are enabled for yakkety could we get langpacks built?
<seb128> dear launchpad, please stop timing out on edit
<dpm> hey seb128
<seb128> dpm, hey :-)
<dpm> wgrant, cjwatson, did you update the launchpad translations export cron jobs when opening yakketty translations?
<dpm> seb128, afaik, that's all it's needed for langpack-o-matic to pick up the exports and start creating the language packs
<seb128> k, thanks
<wgrant> dpm: Ah no, haven't done that yet.
<wgrant> dpm: Do you have a suggested alteration to the existing schedule?
<wgrant> seb128: What sort of edit operation was timing out?
<dpm> wgrant, I can have a look, but I always have to look for the crontab in the LP code. Do you happen to have a link?
<seb128> wgrant, editing tag and adding comment but it's back now...
<wgrant> dpm: Isn't the schedule on a wiki page somewhere?
<wgrant> Which I can never remember.
<seb128> wgrant, was there a rollout/update at 9utc maybe?
<wgrant> seb128: No, possibly just the mysterious postgres issue that happens occasionally. All bug edits time out for 1-10 minutes, and we're not quite sure why...
<dpm> wgrant, I think the wiki page is not up to date. At least the last times I've looked at the cron tab directly. Let me find that
<seb128> I guess I might have hit the time of the day where launchpad is acting up because of daily $whatever
<seb128> wgrant, k, that might be it, at least sounds similar
<dpm> wgrant, https://dev.launchpad.net/Translations/LanguagePackSchedule
<dpm> the notes say where the crontab lives, but I'm not sure if it's current
<pitti> seb128: oh nice, will set this up!
<wgrant> That's accurate, but I can do all that.
<pitti> ... or not, https://translations.launchpad.net/ubuntu/yakkety/+language-packs is empty
 * pitti reads backscroll
<pitti> wgrant: so wily can certainly go
<pitti> I suppose that wiki page is out of date anyway, as we most definitively exported xenial
<wgrant> Ah
<wgrant> The wiki page is up to date except that xenial is on Sunday.
<pitti> wgrant: hm, not https://dev.launchpad.net/Translations/LanguagePackSchedule, do you mean another one?
<wgrant> pitti: That's the one.
<wgrant> The total diff for adding xenial was adding a new xenial job on Sunday.
<wgrant> Nothing was dropped.
<pitti> oh, ok -- so we still even export wily? I thought we only needed rtm-15.04 now
<wgrant> pitti: When's your side of xenial?
<pitti> wgrant: Monday morning, so that matches
<wgrant> pitti: I've updated the wiki page, and that reflects currently reality at least on the LP side.
<wgrant> I'm tempted to just s/wily/yakkety/ across the board.
<pitti> wgrant: ack, thanks; I think you can safely kill vivid (unless that means rtm-15.04) and wily
<cjwatson> wgrant: It doesn't quite; we still export 15.04 on Friday as well.
<pitti> wgrant: s/wily/yakkety/ WFM
<wgrant> Oh so we do.
<wgrant> pitti: Done on the wiki page, will get our crontab updated.
<wgrant> cjwatson: I suppose it's so quick that it doesn't really matter, but hm.
<pitti> I build 15.04 on Friday late evening (22:30 UTC)
<pitti> RTM-15.04 I mean
<wgrant> added that to the wiki page
<wgrant> pitti, dpm, seb128: LP crontab update
<wgrant> d
<pitti> wgrant: cheers!
<dpm> thanks!
<seb128> wgrant, dpm, pitti, thanks!
<dpm> nice one seb128
<jamespage> slangasek, thankyou
<xnox> pitti, could you please tell me where the source code for http://autopkgtest.ubuntu.com/ is ? I'd like to add a few tricks.
<pitti> xnox: you didn't see my response in scrollback about statistics?
 * xnox looks back
<pitti> xnox: https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/tree/webcontrol/browse.cgi is the flask app which does the sql queries and call the renderer, and https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/tree/webcontrol/templates are the html templates
<xnox> pitti, aha, gotcha =) will tinker with that, thanks!
 * xnox never used flask, but should be easy enough to figure out how to expand existing template
<pitti> xnox: yeah, it's quite straightforward; the entire app is just 300 lines or so; look at the existing statistics query and template to get an idea
<pitti> xnox: you can also just toss me the SQL queries you are interested in, and I'll turn them into code
<pitti> doko_: oh noes .. things calling blocking getrandom() during early boot, rings a bell?
<pitti> doko_: now it's not python (that got fixed), but latest gnutls28 :(
<pitti> bug 1622893
<ubottu> bug 1622893 in gnutls28 (Ubuntu) "NetworkManager takes very log to start, or times out, blocked on RNG" [Undecided,Triaged] https://launchpad.net/bugs/1622893
<doko_> xnox, pfff ... "that package uses really archaic ways of doing things"
<ginggs> hi pitti, could we mark cacti autopkgtests on armhf 'aways failed' please? http://autopkgtest.ubuntu.com/packages/c/cacti/yakkety/armhf
<semiosis> Odd_Bloke: can you help out with this? ... [22:12:44]  <slangasek> semiosis: if you could get Odd_Bloke to build an "official" vagrant test image against xenial-proposed, and then validate that test image, that would be best
<semiosis> this is in re: bug 1621393
<ubottu> bug 1621393 in cloud-images "xenial64 image (20160907.1.0) has a broken (empty) /etc/resolv.conf" [Undecided,New] https://launchpad.net/bugs/1621393
<Odd_Bloke> semiosis: Sure thing.
<semiosis> thank you!
<xnox> doko_, should i have said prehistoric? =)
<xnox> doko_, rumors have it it's for DB2, but i don't buy that.
<Odd_Bloke> semiosis: I've kicked one off, but foolishly did it in a private livefs so I can't give you a link to track.
<Odd_Bloke> semiosis: I'll keep an eye on it and point you at it once it's done. :)
<semiosis> thanks i'll be here
<LocutusOfBorg> any core dev willing to merge vim for yakkety? 8.0 is out!
<LocutusOfBorg> slangasek, ^^ :)
<LocutusOfBorg> ops infinity ^^ you are the last uploader ;)
<Odd_Bloke> semiosis: Can you access https://i284108973.restricted.launchpadlibrarian.net/284108973/livecd.ubuntu-cpc.vagrant.box?token=K7Pp7BgzNCZ0b0BbvC3q3Vgc3LkJpwW0 ?
<semiosis> Odd_Bloke: downloading now
<Odd_Bloke> Cool, that was built with livecd-rootfs <something>.4 from -proposed, so hopefully that'll work.
<petersaints> j#ubuntu-gnome
<notarobot> Anyone here familiar with LXR, who can help me set it up? I'm not sure what to do the the swish-e database question in the config file
<semiosis> Odd_Bloke: looks good to me!
<semiosis> slangasek: tested Odd_Bloke's build and it looks good
<slangasek> semiosis: excellent - do me a favor and note that on the bug report, please
<semiosis> slangasek: will do
<slangasek> stgraber, mdeslaur, infinity, kees: TB meeting in 10
<mdeslaur> ack
<slangasek> rbasak: first stumbling block, I don't see anywhere in edit-acl to set a packageset description :)
<rbasak> :-/
<bipul> I would be thankful if someone help me to understand the back end process of how temporary vg is creating and data is being migrated from /dev/sda1 PV to /dev/sda3 PV http://paste.ubuntu.net/23174271/
<rbasak> slangasek: looking at the code, it looks like it'll prompt you.
<bipul> Sorry wrong channel.
<rbasak> I presume the owner (--person) should be developer-membership-board.
<slangasek> rbasak: oh ok
<seb128> cyphermox, kenvandine, was the lintian warning in bug #1597453 a blocker?
<ubottu> bug 1597453 in content-hub (Ubuntu) "[MIR] content-hub" [Undecided,New] https://launchpad.net/bugs/1597453
<cyphermox> seb128: hardening should be enabled, unless it really has a good reason not to be, so yes
<seb128> kenvandine, ^
<seb128> cyphermox, thanks
<pitti> ginggs: done now when I was looking over excuses; sorry, missed your ping earlier
<ginggs> pitti: danke!
<slangasek> rbasak: personal-gunnarhj packageset created for yakkety and gunnarhj added to it
<slangasek> rbasak: I don't see how to use edit-acl to set PPU rights either
 * rbasak looks it up
<rbasak> slangasek: echo mariadb-10.0 mariadb-client-lgpl galera-3|xargs -n1 edit-acl -p otto -t upload add -s  # I think
<slangasek> rbasak: oh, 'source'; hurray for option consistency
<slangasek> rbasak: thanks :)
<slangasek> rbasak: done
<rbasak> slangasek: thank you!
<nacc> rbasak: https://code.launchpad.net/~nacc/ubuntu/+source/openipmi/+git/openipmi/+merge/297709
<xnox> pitti, you have patch in your mailbox =)
<xnox> autopkgtest-cloud is not a project, so cannot do merge proposals against it.
<pitti> xnox: nice! will test and apply in about two hours when I'm back (for real)
<kenvandine> seb128, cyphermox i'll look at it
<seb128> kenvandine, thanks
<pitti> robru: sorry, n00b question (first time I use bileto since $verylong ago): how do I get from https://requests.ci-train.ubuntu.com/#/ticket/1941 to excuses.html to see what the tests are doing?
<robru> pitti: first, you have to wait for britney to actually run. there are no excuses.html yet because britney status is just "queued".
<robru> pitti: once it has run the excuses.html will show up on that page
<pitti> robru: ah, makes sense (I ticked the box maybe an hour ago, is it normal to take that long?)
<robru> pitti: yes it often takes an hour for britney to get through all tickets.
<pitti> ok, thanks!
<robru> pitti: if you want to watch the log in real time, visit https://requests.ci-train.ubuntu.com/static/index.html and grep for the latest log_*, you can see which ticket it's currently working through. I wouldn't worry unless it's been 2 hours though
<pitti> robru: this one: https://requests.ci-train.ubuntu.com/#/ticket/1839 was already published, so that should have a link; still too blind to see it?
<pitti> and indeed https://requests.ci-train.ubuntu.com/static/britney/ticket-1839/landing-093-yakkety/excuses.html does exist
<robru> pitti: again, "queued" means britney never ran. whoever published that likely just did it without waiting for britney
<pitti> robru: well, it did run
<robru> pitti: well maybe it ran then they rebuilt it, which cleared it. anyway since the most recent build britney never ran on that ticket
<pitti> 2016-09-06 21:48:57 +0200 (britney-bot) britney_signoff: Approved
<pitti> robru: ah right, there was another build after that
<pitti> robru: ok, thanks for the explanation!
<robru> pitti: you're welcome!
<robru> bbl
<pitti> robru: aside from my whining, it's a really nice workflow now!
<pitti> robru: hah, and there it is
<pitti> robru: now https://requests.ci-train.ubuntu.com/log/1941/publish/latest/ says "ERROR Needs review: ~pitti unity-gtk-module env-race +merge 305613
<pitti> robru: tedg did review and ack https://code.launchpad.net/~pitti/unity-gtk-module/env-race/+merge/305613 , what does that mean?
<pitti> does it need top-approval?
<pitti> tedg: ^ do you know? If so, could you top-approve it please?
<tedg> pitti: done
<pitti> tedg: I guess that was it, thanks!
<robru> pitti: thanks
<jbicha> doko_: librevenge does some unusual things to its dbgsym pkg and I guess LP doesn't like it https://launchpad.net/ubuntu/+source/librevenge/0.0.4-6/+build/10747974
<doko_> jbicha: how do you do your syncs, are you using some helper scripts?
<jbicha> just syncpackage
<Unit193> hloeung: Nice rDNS.
<hloeung> heh thanks
#ubuntu-devel 2016-09-14
<spotter> is pepper flash plugin not working in yakkety correctly?  chromium lists it in about://plugins but eveyr site that tries to do flash shows an error of "couldn't load plugin"
<Unit193> spotter: That's a support question thus should be asked in a support channel such as #ubuntu.  Chromium may have click-to-play, but visit http://www.adobe.com/software/flash/about/ and see if it tells you what version you have.
<spotter> asked here as its a yakkety issue, but can ask there too, but that page shows same error, "Couldn't load plugin"
<Unit193> Oooh, sorry yeah. #ubuntu+1.  My bad.
<mwhudson> xnox: re https://launchpad.net/ubuntu/+source/software-properties/0.96.24.6, gnupg1 is in universe, what's the plan there?
<pitti> Good morning
<cpaelzer> Good morning
<pitti> xnox: http://autopkgtest.ubuntu.com/packages/m/mercurial/yakkety/amd64 is another (test-only) regression from gnupg2; do you track these somewhere with bug tags or so?
<pitti> Mirv must have gotten up, autopkgtest infra is getting Qt'ed again :-P
<andrewsh> pitti: could you please have a look at #835648?
<ginggs> andrewsh: LP or BTS ?
<Unit193> That number is BTS.
<Unit193> Debian #835648
<ubottu> Debian bug 835648 in wpasupplicant "wpasupplicant: suspend takes very long due to problematic system-sleep hook" [Normal,Open] http://bugs.debian.org/835648
<ginggs> Unit193: thanks
<Unit193> Sure.
<Mirv> pitti: mornings! :)
<Mirv> or lunch time actually
<andrewsh> ginggs, pitti: yes, I meant BTS, sorry for the confusion
<Unit193> andrewsh: Well pretty sure you weren't talking about a bug in tomboy about 'Ubuntu One'
<andrewsh> :)
<pitti> andrewsh: so calling wpa_cli suspend takes 10s??
<andrewsh> according to the reporter
<pitti> andrewsh: it's been a while, but we've had the pre/post suspend hooks basically forever (in upstart/pm-utils time it was through /usr/lib/pm-utils/sleep.d/60_wpa_supplicant)
<andrewsh> I see this in my journal too:
<andrewsh> Sep 13 18:27:07 nuevo systemd-sleep[29472]: Suspending system...
<andrewsh> Sep 13 21:21:55 nuevo systemd-sleep[29472]: Failed to connect to non-global ctrl_ifname: (nil)  error: No such file or directory
<andrewsh> Sep 13 21:21:55 nuevo systemd-sleep[29472]: System resumed.
<pitti> so obviously this is a workaround, but so far it seemed it helps more people than it hurts
<andrewsh> (that's on Ubuntu)
<andrewsh> Sep 13 21:21:55 nuevo systemd-sleep[29642]: /lib/systemd/system-sleep/wpasupplicant failed with error code 255.
<andrewsh> adding & to background it sort of helped:
<andrewsh> Sep 14 10:18:43 nuevo systemd-sleep[30309]: Suspending system...
<andrewsh> Sep 14 10:18:43 nuevo systemd-sleep[30309]: Failed to connect to non-global ctrl_ifname: (nil)  error: No such file or directory
<andrewsh> Sep 14 10:18:48 nuevo systemd-sleep[30309]: Failed to connect to non-global ctrl_ifname: (nil)  error: No such file or directory
<andrewsh> Sep 14 10:18:48 nuevo systemd-sleep[30309]: System resumed.
<andrewsh> (no error message)
<andrewsh> (so probably no waiting)
<pitti> right, but with & it might not actually finish before the suspend happens, so that's a bit pointless
<pitti> and even detrimental -- you DON'T want wpa_cli suspend to run after resuming
<andrewsh> yep
<andrewsh> though if followed by resume it shouldn't hurt
<andrewsh> this makes me think it somehow connects to a wrong socket
<andrewsh> as it says No such file or directory
<andrewsh> pitti: for some strange reason, at the moment systemd-sleep runs, /run/wpa_supplicant is already gone
<pitti> andrewsh: so maybe a simple check would just be to guard this call with if [ -d /run/wpa_supplicant ] ?
<andrewsh> pitti: maybe
<andrewsh> I don't understand the reason though
<andrewsh> wpa_supplicant is still running
<Odd_Bloke> If there's a core dev with a few minutes, a review and merge of this livecd-rootfs change would be much appreciated: https://code.launchpad.net/~daniel-thewatkins/livecd-rootfs/label-function/+merge/304767
<doko_> kenvandine: please could you prepare your MIR's on yakkety? it's not that we wouldn't have work enough already
<xnox> mwhudson, good point.
<xnox> pitti, no not tracking things yet. But i guess i should be.
<xnox> https://bugs.launchpad.net/ubuntu/+source/mercurial/+bug/1623423
<ubottu> Launchpad bug 1623423 in mercurial (Ubuntu) "gnupg2 autopkgtest regression" [Undecided,New]
<xnox> https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1623424
<ubottu> Launchpad bug 1623424 in lxc (Ubuntu) "lxc autopkgtest regression" [Undecided,New]
<pitti> https://bugs.launchpad.net/ubuntu/+bugs?field.tag=gnupg2
<pitti> thanks
<doko_> pitti: about #1622893, I don't think downgrading the gnutls is an option
<pitti> doko_: right, I wasn't suggesting that; I have a workaround for our test VMs, but it still affects real installs
<pitti> not a blocker though, I mostly pinged you for the lols
<pitti> the new version moved from reading /dev/urandom to calling getrandom() which is a good thing from gnutls' POV I suppose; maybe NM just calls something too early and it can be fixed in NM
<cpaelzer> was there a reasonable local workaround to bug 1621269 until xenial gets an SRU for it?
<ubottu> bug 1621269 in sbuild (Ubuntu Xenial) "not possible to build yakkety packages because of gpg changes" [High,Triaged] https://launchpad.net/bugs/1621269
<cpaelzer> I remember there was quite some discussion about it, but searching the logfile of the chan wasn't as successful as i'd have hoped
<cpaelzer> trying to move the sbuild apt keys away as suggsted in the debian linked debian bug
<cpaelzer> passing the initial sign of the dummy repo, although I'm not sure this won't cause other pain later on - we will see
<Unit193> xnox: Also on that note, LP should upgrade them and use the new-ish Signed-By field! :P
<xnox> Unit193, is there an LP bug open about that?
<Unit193> xnox: I presume other than 1331914?
<directhex> who's in charge of the ppc64le port, nominally? presumably there's someone at IBM spearheading that?
<doko_> cyphermox, mwhudson, slangasek: accepted subquity. are the hardcoded python2 dependencies in subiquity-tools really intended?
<mwhudson> doko_: seems unlikely to me
<doko_> mwhudson: https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1623448
<ubottu> Launchpad bug 1623448 in subiquity (Ubuntu) "subiquity-tools has a lot of hard-coded Python2 dependencies" [Undecided,New]
<mwhudson> doko_: thanks
<doko_> xnox: gnupg1 is in component-mismatches now. promote it?
<xnox> doko_, for now yes, ideally i want to drop it from software-properties.
<xnox> but i'm not sure how yet.
<doko_> xnox: subscribed foundations and promoted
<pitti> arges: there was a previously existing isc-dhcp in x-proposed (verified, just reached 7 days today, but causes test regressions); was accepting another one on top of that intended?
<pitti> (AFAICS this fixes something unrelated)
<arges> pitti: hmm... usually sru-review warns me when that's the case
<arges> pitti: the SRU I accepted was for the same bug
<pitti> ah, so follow-up fix then?
<pitti> thanks
<arges> pitti: checking on this now
<arges> pitti: also I think the network-manager autopkgtest regression is a false negative.
<arges> pitti: and last, i accepted the isc-dhcp into p/t-proposed, not x-proposed.
<pitti> arges: ah, ok
<arges> : )
<arges> pitti: oh are you going through the queue too?
<pitti> arges: no, I just did some releases some 30 mins ago
<arges> pitti: ok
<Odd_Bloke> smoser: pitti: Are "Transaction order is cyclic" messages from systemd in cloud-init package installation a sign that I don't have a recent enough cloud-init?
<Odd_Bloke> (This is in yakkety.)
<smoser> Odd_Bloke, hm..
<smoser> what package installation ?
<Odd_Bloke> smoser: This is happening when we take an old cloud image and upgrade on boot; I'm freshening the image we use to see if the problem goes away.
<smoser> Odd_Bloke, ok. let me look some.
<pitti> Odd_Bloke: oh, could be that init-system-helpers gets upgraded too early/too late or so; I haven't seen dependency loops in fresh installs, but I haven't tried a lot of upgrade scenarios
<pitti> Odd_Bloke: do you mind posting the logs to bug 1576692?
<ubottu> bug 1576692 in init-system-helpers (Ubuntu Xenial) "fully support package installation in systemd" [High,Fix committed] https://launchpad.net/bugs/1576692
<pitti> Odd_Bloke: (assuming that this also happens on upgrading xenial to xenial-proposed, the changes are pretty well identical)
<smoser> pitti: http://paste.ubuntu.com/23177905/
<pitti> smoser: ah, that reproduces it?
<smoser> yeah
<smoser> having old images easily available is nice.
<brendand> is launchpad in a bad mood or something?
<pitti> I tried an upgrade with both .services having After=multi-user.target and didn't get into trouble, but different unpack orders can also make this hard to repro
<pitti> brendand: at least on my end it seems to have a fit pretty well every day for some minutes (feels like an expensive cron job or so)
<smoser> full log http://paste.ubuntu.com/23177914/
<pitti> journal would be good to see too
<smoser> pitti, well, you can ask me , or you can try it :)
<smoser> i can get it to you.
<smoser> i was just checking..
<smoser> the latest xenial daily + proposed + package_upgrade=true does not shwo the issue.
<smoser> trying now with release imae
<smoser> image
<smoser> released image seems fine too
<smoser> actually, pitti...
<smoser> i think its just that package upgrade with the version of cloud-init that is in the image doens't work.
<smoser> as is known by that bug.
<smoser> and we've (i think) fixed the bug.
<smoser> but that doesnt fix the image
<smoser> Odd_Bloke, does that make sense ?
<smoser> you're hitting a bug that we've fixed.
<Odd_Bloke> smoser: Yep, that definitely makes sense; newer image as the base works fine. :)
<smoser> yeah, but its more than just "its fixed because there are no upgrades to do"
<smoser> package_upgrade and package install was broken, this update to cloud-init fixes it, but you can't have the old cloud-init apply this update due to that bug :)
<Odd_Bloke> smoser: Yep, understood; we're still installing a bunch of packages and we've stopped seeing failures.
<pitti> smoser: oooh! yes, that makes perfect sense
<pitti> (sorry, was OTP for a long time)
<pitti> smoser, Odd_Bloke: so that means people upgrading from xenial after that SRU lands should *not* run into this
<pitti> and people upgrading from intra-yakkety, well, yeah, tough luck :)
<semiosis> Odd_Bloke: are you aware of a reason why the livecd-rootfs hasn't been updated to 2.408.4 in xenial-updates yet?  I marked the bug verification-done about two days ago
<semiosis> bug 1621393
<ubottu> bug 1621393 in cloud-images "xenial64 image (20160907.1.0) has a broken (empty) /etc/resolv.conf" [Undecided,New] https://launchpad.net/bugs/1621393
<nacc> semiosis: iirc, 7 days for srus
<nacc> typically
<nacc> not hard and fast
<bipul> Yes, but that's how we can resize our lvm
<semiosis> nacc: ah ok, thanks
<Odd_Bloke> Though also: "Not touching package due to block request by freeze (contact #ubuntu-release if update is needed)" from https://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html
<bipul> sorry Shrinking the logical volume.
<bipul> To reduce the size of a logical volume, first unmount the file system. You can then use the lvreduce command to shrink the volume. After shrinking the volume, remount the file system.
<nacc> Odd_Bloke: iirc, i saw that too and once it's release that page is not necessary accurate
<bipul> That's what i did
<Odd_Bloke> nacc: Ahh, OK.
<nacc> bipul: wrong channel?
<bipul> oh yes, sorry
<semiosis> nacc: Odd_Bloke: so we wait a few more days?
<nacc> semiosis: that would be my recommendation :)
<nacc> semiosis: it should trickle in just fine
<rbasak> semiosis: it gives other users a chance to flag regressions.
<semiosis> ok, then in that case, Odd_Bloke, I would like to post the link to your test build image in the bug.  that sound good to you?
<semiosis> will the download link expire?
<Odd_Bloke> semiosis: I'm not sure what the expiry is; I'd just check if it's working still.
<Odd_Bloke> semiosis: If it is, it'll probably be good for a while.
<semiosis> it is working right now
<Odd_Bloke> Then go for it. :)
<semiosis> done.  thanks!
<nacc> rbasak: i'm starting to think that using git-python may have been a mistake. In that, really, I think we can leverage just normal subprocess/`git commands` for most everything and it will be quite a bit faster. Especially for eventual cron usage
<nacc> rbasak: i'll play with that on the side, might just need a little wrapper class for the various commands we need
<rbasak> nacc: OK. I think we needed the hindsight to have known. I'd be happy with such a switch.
<rbasak> nacc: I wonder if it's worth seeing if pypy or similar can speed things up, if that's easy and works? Might save you the effort in switching over.
<nacc> rbasak: yep, absolutely -- not an error on our part, we're just not really needing the convenience of git-internals that python-git affords, really
<nacc> rbasak: i'll take a look!
<rbasak> Is speed the only issue?
<arges> mwhudson: hey can you give bug 1602243 an SRU template? thanks
<ubottu> bug 1602243 in Ubuntu on IBM z Systems "[16.10 FEAT] Upgrade Docker to newest version 1.12" [Medium,In progress] https://launchpad.net/bugs/1602243
<nacc> rbasak: pretty much, as the initial load of an existing repository can take hours
<rbasak> Wow
<nacc> rbasak: as it verifies every object in the git database
<nacc> rbasak: as it's creating an internal reference, i think
<nacc> rbasak: not sure, exactly, but it's very slow
<nacc> and will only get worse as the repos grow
<rbasak> Sounds like we should either fix the library or move away from it.
<nacc> rbasak: yeah, i think the 'fix' is really just a usage thing. I'm not sure if it could be parallelized more
<nacc> rbasak: in that it has does that `git cat-file --batch-check` and `git cat-file --batch` on the repository
<nacc> rbasak: i'll dig into it later
<rbasak> ack
<cjwatson> nacc: did you consider python-pygit2?
<cjwatson> nacc: that's what the git.launchpad.net backend uses
<nacc> cjwatson: interesting, i'll take a look -- i was trying to use python3 :)
<cjwatson> nacc: python3-pygit2, then :)
<nacc> cjwatson: ah yes, thanks!
<nacc> cjwatson: i'll take a look!
<cjwatson> (we're still on python2 for this because of some details of Twisted, but the library in question supports either)
<nacc> great, i'll see if that's any different performance wise for our case
<cjwatson> there are ways to make it hit pathological behaviour, but we certainly haven't noticed anything like what you suggest in general
<cjwatson> and we would
<nacc> cjwatson: yep, absolutely
<nacc> cjwatson: thanks again!
<cjwatson> npo
<cjwatson> er, np
<nacc> no problem, ole!
<rbasak> A perfect example of why using public channels is good. Thanks cjwatson :)
<nacc> rbasak: i think i have the patch bits implemented too, fyi -- testing it now
<cjwatson> :)
<cjwatson> https://git.launchpad.net/turnip if you need usage examples
<smoser> pitti, i assume you are gone
<smoser> but .. https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1623570
<smoser> fun.
<ubottu> Launchpad bug 1623570 in cloud-init (Ubuntu Xenial) "Azure: cannot start walinux agent (Transaction order is cyclic.)" [High,Confirmed]
<smoser> i think i have it in hand.
<andrewsh> pitti: and now I see the following: I did suspend, wpa_cli suspend did *not* run; I resume â it does *not* run, and no wifi connection either
<andrewsh> I manually run wpa_cli resume â wpa_supplicant wakes up and reconnects
<andrewsh> I see this in the logs before I ran wpa_cli resume:
<andrewsh> Sep 14 18:21:18 nuevo NetworkManager[2944]: <info>  [1473870078.9817] device (wlan0): supplicant interface state: starting -> ready
<andrewsh> Sep 14 18:21:18 nuevo NetworkManager[2944]: <info>  [1473870078.9818] device (wlan0): state change: unavailable -> disconnected (reason 'supplicant-available') [20 30 42]
<nacc> Pharaoh_Atem: ping
<Pharaoh_Atem> nacc: pong
<nacc> Pharaoh_Atem: hey, looking at LP: #1623540
<ubottu> Launchpad bug 1623540 in php7.0 (Ubuntu Xenial) "If php.ini is incorrect, php-frm starts without warning with default values" [Medium,Triaged] https://launchpad.net/bugs/1623540
<nacc> Pharaoh_Atem: seems like debian dropped the hlper script, so it affects 16.10 too
<nacc> Pharaoh_Atem: do you have any suggestions?
<Pharaoh_Atem> isn't fpm supposed to just fail anyway?
<Pharaoh_Atem> I'm not sure how to fix it if it's not working
<nacc> Pharaoh_Atem: well, i would have expected fpm to fail, but it doesn't :)
<Pharaoh_Atem> :S
 * Pharaoh_Atem grumbles about php
<nacc> Pharaoh_Atem: -t definitely says a line like '# abcd (' is a 'syntax error', but the service still runs
<nacc> Pharaoh_Atem: if you have any ideas, i'd appreciate it, i guess the helper script (which can make this work in 16.04, where it's still present) was dropped because "php-fpm often ends with zend_mm_heap corrupted that prevents th service to be (re)started" with no reference to bugs, etc so not sure how common that is
<Pharaoh_Atem> nacc: I could have sworn that php-fpm has it's own method for checking these things
<nacc> Pharaoh_Atem: yeah, i mean '-t' does it
<nacc> Pharaoh_Atem: but it's not used currently, perhaps?
<Pharaoh_Atem> I think that's it
<Pharaoh_Atem> it's not used by default, I think
<Pharaoh_Atem> though, that's completely brain-dead
<nacc> Pharaoh_Atem: so i wonder if the systemd script should be using that as a pre-exec
<nacc> or whatever
<Pharaoh_Atem> it probably should
<nacc> but i mean, that's what the wrapper script basically did (incorrectly, though)
<Pharaoh_Atem> well, the wrapper script is basically unnecessary, right?
<nacc> Pharaoh_Atem: unclear :)
<nacc> Pharaoh_Atem: i guess so
<nacc> let me see what else it does
<nacc> Pharaoh_Atem: it also did something with tmpfiles?
<nacc>  /usr/lib/tmpfiles.d/php7.0-fpm.conf
 * Pharaoh_Atem shrugged
<Pharaoh_Atem> why not define tmpfiles in the service file?
<Pharaoh_Atem> it supports that
<nacc> i have no idea
<nacc> ok, i'll play with adding a call to php7.0-fpm -t in the ExecStartPre
<Pharaoh_Atem> does invocation with -t lead to a running interpreter?
<Pharaoh_Atem> or does it exit after the check?
<nacc> it always exits, afaict
<nacc> sigh, but it exits successfully even if the syntax error occurs :)
<Pharaoh_Atem> I repeat: php is brain-dead
<Pharaoh_Atem> :)
<tumbleweed> win 33
<pitti> smoser: sorry, was just gone for dinner and basketball, looking
<smoser> pitti, you are allowed to walk away from the computer
<smoser> just not for more than 6 minutes
<smoser> please take a look at http://pad.lv/1623570 . i've uploaded to both yakkety and xenial
<ubottu> Launchpad bug 1623570 in walinuxagent (Ubuntu) "Azure: cannot start walinux agent (Transaction order is cyclic.)" [High,In progress]
<smoser> but would like your thoughts, and can nack it and replace it if needed.
<pitti> smoser: 6 minutes? *now* I know what "fast food" means!
<mwhudson> arges: done
<nacc> Pharaoh_Atem: well, i figured out *why* php7.0-fpm starts successfully even with the -t check. the -t check only applies to parsing of php-fpm.conf, not php.ini
<nacc> Pharaoh_Atem: as the php.ini parsing happens at a top-php-level across all sapis
#ubuntu-devel 2016-09-15
<pitti> Good morning
<gilbahat> Hi, quick question if anybody knows: what happens to âproposedâ yakkety packages? I think they canât make it by now, but will they stay in some other compliant repo or something?
<RAOF> gilbahat: No, everything goes through yakkety-proposed.
<RAOF> gilbahat: Everything in yakkety-proposed is expected to migrate to yakkety before release.
<cpaelzer> good Morning
<gilbahat> RAOF: ah, really? thatâs cool. I thought the current freeze state meant that by now anything that didnât make it to main by now wonât make it in after all.
<RAOF> No. We're currently in feature-freeze, but expect plenty more bugfix uploads before release.
<RAOF> And *all* uploads go through yakkety-proposed.
<gilbahat> itâs not a bugfix release, itâs a major upstream release (syslog-ng 3.5.6 vs 3.7.3). itâs already in proposed now and I hope it will get released with 3.7.3
<pitti> RAOF: not actually true -- stuff that gets stuck in y-proposed just gets moved to z-proposed after y's release
<RAOF> pitti: But we don't *expect* things to be stuck in y-proposed; that indicates that someone has failed, right?
<pitti> there's usually two metric tons of that
<RAOF> Heh, OK.
<pitti> RAOF: right, of course
<pitti> there's still a lot of autosyncs which regressed, and nobody feels particularly attached to them
<pitti> and half-finished library transitions
<RAOF> gilbahat: If it was in -proposed before the freeze was announced, it should go in without further effort. If it was uploaded post feature-freeze, someone will need to explicitly request a freeze exception.
<pitti> so indeed the intention is to clear it all up, it's just a lot of work
<gilbahat> RAOF: any place I can check that somehow?
<gilbahat> pitti: is it going to also stay in some -extra repo or something perhaps?
<pitti> gilbahat: well, devel-proposed :)
<pitti> i. e. we release y, open z, and move the remaining y-proposed packages into z-proposed
<gilbahat> pitti: from launchpad.net I see itâs been uploaded at 16th of July. thatâs over a month before the feature freeze if Iâm reading it correctly.
<pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#syslog-ng this one?
<pitti> looks like a library transition
<pitti> trying: syslog-ng
<pitti> skipped: syslog-ng (0, 3, 17)
<pitti>     got: 147+0: a-32:a-15:a-15:i-20:p-16:p-15:s-34
<pitti>     * amd64: syslog-ng-mod-basicfuncs-plus, syslog-ng-mod-lua, syslog-ng-mod-perl, syslog-ng-mod-rss, syslog-ng-mod-trigger
<pitti> I guess syslog-ng-incubator needs to be updated as well
<pitti> or at least rebuilt against the new version, as it has strict deps like syslog-ng-core (>= 3.5.6~), syslog-ng-core (<< 3.5.7~)
<pitti> https://tracker.debian.org/news/785441 looks like it fits
 * pitti syncs that
<pitti> oh, it's already in -proposed, just FTBFS on s390x
<pitti> gilbahat: so this is the problem: https://launchpadlibrarian.net/281969183/buildlog_ubuntu-yakkety-s390x.syslog-ng-incubator_0.5.0-1_BUILDING.txt.gz
<pitti> FAIL modules/grok/tests/test_grok (exit status: 139) sounds like a segfault (signal 11)
<sarnold> I suspect it's related to the warning about incorrect fprintf types mentioned right next to the test_grok build...
<sarnold> (they may just be mixed in due to make -j .. but it's plausible anyway)
<gilbahat> sarnold: but test_date passes. so itâs probably not it. but I canât help unless I get an s390 machine and I have no idea how on earth to get access to oneâ¦ or else report this to balabit and hope they have access to one. it could be an upstream bug as well.
<pitti> the build log is a real joy of incompatible pointer types indeed
<sarnold> loads of em
<sarnold> glebihan: hercules may work for this
<sarnold> I haven't used it myself :(
<gilbahat> sarnold: thereâs also support in qemu it seems.
<gilbahat> but itâs weird, 3.7.3-1 is in sid, it builds correctly for s390x, but the build log doesnât mention test_grok at all
<gilbahat> or grok for that matter
<gilbahat> https://buildd.debian.org/status/fetch.php?pkg=syslog-ng-incubator&arch=s390x&ver=0.5.0-1&stamp=1468967484
<sarnold> very interesting
<gilbahat> are builds attempted again to account for possible transient errors (as rare as they may be)?
<sarnold> 1.20110708.1-4.1ubuntu1 vs 1.20110708.1-4.1
<sarnold> libgrok-dev versions changed between the two builds, anyway
<gilbahat> that looks like a very ancient and unmaintained library. or maybe solid enough not to need any changesâ¦
<sarnold> heh at least it's 2011 not 2001 :)
<gilbahat> ok, so ancient not very ancient :P
<gilbahat> so now I need to hunt down what patches did ubuntu1 have over vanilla
<sarnold> gilbahat: https://patches.ubuntu.com/g/grok/
<gilbahat> thanks! but that brings me back to square 1 because it looks like itâs unrelated. this change would have broken the build and not the test, or cause test_grok to miss symbols and not segfault
<gilbahat> ok, iâve emailed balabit, I hope they can help, in the interim iâll have to use the packages from proposed or keep a copy of them aside for my needs.
<pitti> gilbahat: FTR, I retried the build earlier, and it still fails
<gilbahat> pitti: thanks, thatâs so weird. I hope someone would be able to make sense out of it.
<Saviq> pitti, hey, we're down to 1h20m for a green unity8 run, so you can pop it from the list of long-running tests \o/ we've uncovered one more flaky test though... we're on it, but can you please recycle https://requests.ci-train.ubuntu.com/static/britney/landing-078/yakkety/excuses.html in the mean time? thanks
<Saviq> also not sure if all the "In Progress" ones are actually running, there's been so many...
<pitti> Saviq: very nice, good work! done
<pitti> Saviq: yeah, queues still feel the backlog of yesterday's Qt double landing
<pitti> Saviq: s390x broke yesterday (just fixed, catching up), and armhf is just, well, armhf :)
<pitti> retried the two unity8 failures
<Saviq> yeah, we mostly care about i386 and amd64 still - getting the tests to pass on arm* will be another feat...
<Saviq> thanks!
<pitti> Saviq: err, isn't unity8 what's running on the phone?
<Saviq> pitti, yes, but the phone's much faster than the armhf testers, all the failures (there's only 2% afaict anyway) stem from timing issues in the tests - people have more patience than the test :)
<Saviq> part of it is we're doing GL in software, so without a GPU the CPU requirements are much higher
<pitti> Saviq: ah, understood -- so we do care about unity8 on armhf, just not on *these* armhf boxes :)
<Saviq> pitti, yeah, correct
<Saviq> I looked through the failures and there's only 20-30 fails (and then a timeout after 2h50m...), out of a 1.3k+ test suite
<Saviq> so it could be worse
<Saviq> we might even make it work at some point
<Saviq> pitti, it looks like some runs got lost for our silo, at least "running" doesn't show them - apart from the regressions you restarted earlier the only pending results for silo 078 are for armhf and s390x - do you have a way to queue the missing ones or shall I list them for you?
<pitti> Saviq: I have a script for it
<pitti> Saviq: what's the excuses URL?
<Saviq> pitti, https://requests.ci-train.ubuntu.com/static/britney/landing-078/vivid/excuses.html https://requests.ci-train.ubuntu.com/static/britney/landing-078/xenial/excuses.html https://requests.ci-train.ubuntu.com/static/britney/landing-078/yakkety/excuses.html
<pitti> Saviq: http://autopkgtest.ubuntu.com/running#pkg-unity8 still has a metric ton of running tests
<Saviq> pitti, all armhf ones
<pitti> vivid/i386 too
<Saviq> (for that ppa)
<pitti> and y/amd64
<pitti> oh, these are 73
<Saviq> pitti, not for landing-078
<Saviq> yup
<pitti> there are more queued for 078
<Saviq> only s390x and armhf, too
<pitti> y/i386 has two
<Saviq> with the exception of the two i386 ones you restarted earlier :)
<pitti> and armhf/s390x is all that  is missing from https://requests.ci-train.ubuntu.com/static/britney/landing-078/yakkety/excuses.html
<Saviq> pitti, yes, yakkety looks good
<Saviq> on v it's amd64 with trigger ubuntu-settings-components
<Saviq> and unity-scope-click/i386 and unity8/amd64 with trigger unity8
<Saviq> on x it's unity-scopes-api/i386 with trigger unity-api and qtcreator-plugin-ubuntu/i386 with trigger unity8
<Saviq> pitti, those five are missing afaict â
<cpaelzer> xnox: fyi we got no highlight for it by bileto yet but I've seen that the dependent autopkgtests for 1950 fail for systemd-fsck
<pitti> Saviq: also, the queue view is often missing some queued items (trying to find out why); I'll let the dust settle and restart bits as necessary
<Saviq> pitti, ok, wfm
<pitti> smoser: found bug 1623868; do you agree to the solution?
<ubottu> bug 1623868 in cloud-init (Ubuntu) "cloud-final.service does not run due to dependency cycle" [High,Confirmed] https://launchpad.net/bugs/1623868
<ogra_> (classic)ogra@localhost:~$ sudo apt-get install vim libpython3.5 libpython3.5-stdlib
<ogra_> ...
<ogra_> The following packages have unmet dependencies:
<ogra_>  libpython3.5 : Depends: libpython3.5-stdlib (= 3.5.2-2~16.01) but 3.5.2-2~16.04 is to be installed
<ogra_> E: Unable to correct problems, you have held broken packages.
<ogra_> (classic)ogra@localhost:~$
<ogra_> hmm
<pitti> libpython3.5-stdlib | 3.5.2-2~16.01  | xenial-updates  | amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
<pitti> LGTM?
<ogra_> did something slip out of -proposed ?
<acheronuk> Do I understand correctly that a bug for a feature freeze exception can be submitted during and beyond the start of beta freeze? It's just that it won't be acted on during?
<ogra_> oooh !
<pitti> apt-cache policy?
<cjwatson> acheronuk: no reason to delay submitting bugs, in general
<ogra_> well, the ubuntu-core snap in the edge channel (which i use here as rootfs) gets built against -proposed
<pitti> acheronuk: reviewing freeze exception bugs is not by itself bound by freezes
<ogra_> but the classic cheoor only gets -updates in its sources.list
<ogra_> *chroot
<ogra_> hmm
<ogra_> but i use the rootfs sources.list as base ... i wonder why builds with PROPOSED=1 do not have -proposed in there then ...
<acheronuk> cjwatson: I'm just asking in case the people who would not submit a FFE are not around. There are issues with their availability, so I just wanted to know if next weeks beata freeze was a hard deadline or not. I understood that it was not, but if I or someone else elnd up having to do it I want to be sure of how much time there is.
<acheronuk> *would normally submit
<Mirv> pitti: does it work if I construct autopkgtest request url to retry a test that is in limbo ("in progress" but not really completed, queued or running)? I think I constructed the url right http://pastebin.ubuntu.com/23181731/ but I don't get the stuck one from http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#ubuntu-ui-toolkit visible on the running page
<pitti> Mirv: yes, you can do that; it's also easier to use http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/view/head:/retry-autopkgtest-regressions with --state=RUNNING
<Mirv> pitti: now if only I'd find run-autopkgtest from somewhere?
<pitti> Mirv: oh right, sorry; nevermind
<pitti> Mirv: currently needs shell access; I wanted to move it to request.cgi at some point, but didn't yet
<Mirv> yes, so I've heard, I thought this might be something new :)
<Mirv> anyway, it seems now it's running when I refreshed my request page, weird that I didn't get it running on first try (or so it seemed)
<pitti> Mirv: the /running page is no miracle, take it with a grain of salt
<Mirv> pitti: ok, I do query the completed results directly from the API to know if a "running" test is truly disappeared or not.
<pitti> Mirv: the web UI has a latency of â¤ 5 mins now, btw
<Mirv> oh, ok
<doko_> sil2100: robru: please could you chase down the thumbnailer uploaders to have the ftbfs fixed?
<xnox> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html is stuck?
<cpaelzer> xnox: you mean the update on the page itself?
<xnox> Generated: 2016.09.15 10:15:33 +0000 -> it is 11:41 zulu time...
<xnox> horum, it is still running.... http://people.canonical.com/~ubuntu-archive/proposed-migration/log/yakkety/2016-09-15/10:37:59.log
<Mirv> xnox: yeah looks like stuck
<Mirv> or whatever is happening with that run that now has a size of 8 times the 30 earlier runs
<Mirv> log size
<xnox> pitti, i think autopkgtest is dead =(
<xnox> http://autopkgtest.ubuntu.com/statistics -> A server error occurred.  Please contact the administrator.
<xnox> and i guess that britney is stuck DDoS-ing autopkgtest.ubuntu.com
<pitti> xnox: oh, I have some idea about /statistics
<pitti> xnox: I added test IDs for vivid without any result, to make vivid queues appear on /running
<pitti> xnox: smells like division by zero,checking
<xnox>  /o\
<xnox> we do divide by total without a check in the template
<xnox> could return float('NaN')
<pitti> xnox: WDYM about britney being stuck DDoSing?
<xnox> well, 10:37:59 run generated 9.3M log file, instead of a usual 1.3M
<xnox> http://people.canonical.com/~ubuntu-archive/proposed-migration/log/yakkety/2016-09-15/?C=M;O=D
<xnox> and took like 1h22min
<pitti> jinja2.exceptions.UndefinedError: 'dict object' has no attribute 'vivid'
<xnox> horum.
<pitti> xnox: ah yes, I needed to delete the cache as doko wanted some results lobotomized; next run should be fine again
<xnox> should do a get, and skip a column i guess, or return zeros.
<pitti> xnox: I'll look into it, should be simple
<Mirv> http://people.canonical.com/~ubuntu-archive/proposed-migration/log/yakkety/2016-09-15/12:09:35.log ended in KeyError: 'lava-server'
<xnox> charming
<pitti> Saviq: I retried the two lost ones, the others arrived now
<Mirv> same error for the 12:17:40
<Saviq> pitti, ack thanks
<Saviq> pitti, there's four missing in total, no? https://requests.ci-train.ubuntu.com/static/britney/landing-078/vivid/excuses.html https://requests.ci-train.ubuntu.com/static/britney/landing-078/xenial/excuses.html
<pitti> Saviq: unity8 runs for two different triggers
<Saviq> pitti, yeah, but there's also one vivid/unity-scope-click and xenial/qtcreator-plugin-ubuntu each
<Saviq> under unity8 and ubuntu-settings-components, respectively
<Saviq> ah no, both under unity8 trigger
<smoser> pitti, :-(
<Saviq> I just mean they're not unity8 runs, but triggered by it
<smoser> how would that be transient
<pitti> Saviq: WDYM? https://requests.ci-train.ubuntu.com/static/britney/landing-078/xenial/excuses.html has one qtcreator run, https://requests.ci-train.ubuntu.com/static/britney/landing-078/vivid/excuses.html has one unity8 (for two triggers) and one unity-scope-click; three in total
<pitti> smoser: not transient, just depends on where the cycle gets broken -- at cloud-init.target or cloud-final.target (and that's not stable indeed)
<Saviq> pitti, yes, four missing across the two releases
<Saviq> if those four are queued now, we should be good
<smoser> pitti, http://paste.ubuntu.com/23181973/
<smoser> right ?
<pitti> smoser: I'd put it below Description=, but yes
<smoser> i just dont understand how we didn't see this before
<smoser> when devbugging this, you and i both did dozens of lxc boots
<pitti> smoser: nothing depends on cloud-init.target, so it wasn't obvious that it's not active?
<smoser> possibly. but you're seeing cloud-final.service
<smoser> which is explicitly what we were testing, for package installation
<smoser> well, i see the cloud-init.target issue for sure.
<smoser> pitti, i think you're saying that systemd will break the cycle that it finds and sometimes kill cloud-final.service, and sometimes kill cloud-init.target
<smoser> is that right
<pitti> right
<smoser> cpaelzer, ^
<cpaelzer> I can repro with uvtool as well
<smoser> yeah, i see too.
<cpaelzer> sorry already hit submit on the bug update, you might already be further in the debugging
<cpaelzer> reading backlog here
<smoser> somewhat obnoxious that systemd does kill(random(set-of-tasks-that-have-loop))
<smoser> cpaelzer, i'd like to see your journal in the one where it killed cloud-final.service
<smoser> heres one without cloud-init.target
<smoser>  http://paste.ubuntu.com/23182002/
<smoser> line 464-ish
<cpaelzer> smoser: well the dependency resolution kills cloud-init.target/start sa well for me
<cpaelzer> smoser: I just found it not to create the   /var/lib/cloud/instance/boot-finished file
<cpaelzer> smoser: for what its worth http://paste.ubuntu.com/23182006/
<smoser> cpaelzer, in that vm you dont have the boot-finished ?
<cpaelzer> smoser: yes
<pitti> I got it in some scalingstack instances
<smoser> pastebin /var/log/cloud-init.log ?
<pitti> hard to reproduce, but I was wondering why some of them time out
<cpaelzer> smoser: the file is missing - that just crossed my mind as uvt-kvm wait polls for it
<pitti> (sorry, these are gone)
<cpaelzer> smoser: http://paste.ubuntu.com/23182012/ /var/log/cloud-init.log
<smoser> cpaelzer, line 587
<smoser> so i'm really confused
 * cpaelzer is spawning another vm
<cpaelzer> of course after 4 times breaking this time it had to work :-/
<cpaelzer> retrying a few more
<smoser> what pitti describes seems reasonable, that systemd just decided to drop cloud-final.
<smoser> i'd just like to see it actually happen
<smoser> s/reasonable/possible/
<cpaelzer> 4 further tests completed behaving the same way with the file being around correctly
<cpaelzer> mabye some of my background load changed ...
<cpaelzer> yeah sbuild is over
 * cpaelzer is burning down some cpu to chck if that can reproduce it once more
<cpaelzer> smoser: no it is only deleting cloud-init.target/start now whatever the difference was
 * cpaelzer is looking if any of the old guests is still around
<smoser> cpaelzer, i got it.
<smoser> launched 5 uvt kvm at once
<smoser> 5th failed on digglet
<smoser> http://paste.ubuntu.com/23182035/
<cpaelzer> so it is load dependent
<cpaelzer> or otherwise random
<smoser> right. its always good to fail randomly.
<smoser> that way its harder to diagnose problem.s
<cpaelzer> consitently random :-)
<cpaelzer> well it serves the "have you tried turning it off and on again?"
<smoser> pitti, thank you.
<smoser> i'll upload to ubuntu
<pitti> xnox: fixed
<pitti> Mirv: yes, seems stuck, looking
<smoser> that is really obnoxious
<smoser> journalctl | pastebinit
<smoser> is *different*
<smoser> than
<smoser> journalctl > out
<smoser> pastebinit out
<smoser> http://paste.ubuntu.com/23182060/ : journalctl | pastebinit
<smoser> http://paste.ubuntu.com/23182061/ : journalctl > out ; pastebinit out
<smoser> hm.
<smoser> maybe not. mabye user error
<smoser> must be
 * pitti can't  see an obvious difference
<pitti> there is a difference if stdout is a tty (colors, pager, etc)
<pitti> but above in both cases it's just a pipe
<smoser> yeah, but i was seeing it not have 'Breaks' when i grepped
<smoser> which is wierd
<smoser> er.. Break
<pitti> "breaking"?
<smoser> anywahy
<smoser> i think it must have been user error
<pitti> Mirv: Fixed, I think; will watch the next run
<smoser> pitti, http://paste.ubuntu.com/23182131/
<smoser> that look right ?
<rharper> smoser: re your paste ^^,   have you find the right incantations of systemd list-dependencies to that would show it out-of-order now (without that patch) ?
<Mirv> thank you pitt_i
<smoser> rharper, ? you're saying i should have been able to ask systemd about this ?
<rharper> smoser: I'd really *like* to
<rharper> it's a common issue for me when I'm trying to add/modify or change execution order
<rharper> so I'm just asking around for any tips/pointers on finding out *before* we execut it
<rharper> I really dislike that, change, reboot, look at journctl to find out what happened
<rharper> rather than asking systemd to say, please tell me what you're going to do
<smoser> rharper, well, systemd doesn't know what its going to do.
<smoser> it decides to do one thing in one situation and another in another situation
<rharper> I'm not sure if you're being cheeky or not
<smoser> well, there cheeky, but truthful
<rharper> evidently
<smoser> same situation, it does one thing,a nd then does another.
<rharper> except it has rules
<rharper> like before/after/requires/wants
<rharper> it *does* apply dependency resolution somehow
<smoser> and it *should* be able to tell you "i'm going to have to break *something*"
<smoser> but exactly which something.... i'll save that for later.
<rharper> seems fitting to ask it to do that as a dry-run
<tdaitx> I'm trying to collect reverse dependencies of a package in order to request it to be removed from the archive, but reverse-depends (ubuntu-dev-tools) relies on ubuntuwire which seems to be offline, is there an alternative?
<rbasak> chdist and apt-cache rdepends perhaps?
<dobey> pitti: if a segfault happens during autopkgtests, does that get uploaded to errors.u.c?
<pitti> Mirv: there, shiny new excuses
<pitti> smoser: LGTM, thanks! (I initially was going to upload myself, but then I realized I can't push to the packaging git -- and peer review is better anyway)
<pitti> dobey: no, it doesn't right now; but we could think about adding those to artifacts.tar.gz at least
<pitti> smoser, rharper: systemctl isolate multi-user.target might help (but not sure to what degree); that basically "re-starts" a target
<smoser> pitti, i've uploaded, and am now uploading to xenial
<smoser> if you coudl let it into -proposed...
<smoser> hopefully this is the one.
<rharper> pitti: ignoring deps IIUC (isolate)
<tdaitx> rbasak, thanks for the tip... does that cover all archs? what about reverse build dependencies?
<tdaitx> it seems I would need to run chdist for all archs I'm interested into
<Saviq> pitti, should I be seeing the restarted runs for silo 078 in http://autopkgtest.ubuntu.com/running ? BTW - you can interrupt/restart the unity8 run for silo 73 - it's stuck - we'll have to dive into where it may be getting that way (we know which test suite, now need to find out which test and why)
<pitti> Saviq: interrupted/restarted
<pitti> Saviq: yes, unless they already finished
<rbasak> tdaitx: right - it'd be quite manual and tedius I think.
<rbasak> I'm not sure about build dependencies.
<tdaitx> rbasak, what about ubuntuwire, is it off permanently or just goes out sometimes? I don't usually run reverse-depends, so I can't tell
<tdaitx> couldn't find any info on it being out permanently
<rbasak> I don't know, sorry. I presume it's a short term outtage.
<pitti> tdaitx: still worked a few days ago, so it only broke recently (and I hope it'll come back)
<tdaitx> k, that is ok then, I will wait for it to come back ;-)
<rbasak> If it's a long term issue I'm sure we could replace it.
<rbasak> (or fix reverse-depends or whatever)
<tdaitx> pitti, k, thanks for the info
<tdaitx> rbasak, thanks for the help
<rbasak> You're welcome!
<Saviq> pitti, hmm it's almost two hours since you ran them and none of the results popped up in excuses https://requests.ci-train.ubuntu.com/static/britney/landing-078/vivid/excuses.html https://requests.ci-train.ubuntu.com/static/britney/landing-078/xenial/excuses.html - I have not seen them running at any point... oh well, hoping they're en route to bileto
<dupondje> rharper: any chance on updating strongswan? :)
<rharper> dupondje: it's possible, but we're past feature-freeze;  is there a specific feature in newer strongswan you'd like to see in yakkety ?
<dupondje> rharper: nothing really special, but 2 patches need to be integrated, so it might be nice to update to newer version directly :)
<dupondje> https://git.strongswan.org/?p=strongswan.git;a=patch;h=9e74a0952e27e3ac0055b0831919aaddfef1e1b5 & https://git.strongswan.org/?p=strongswan.git;a=patch;h=f201d86debb12731b634625a0278e289e3e05e10
<rharper> dupondje: if there are open bugs, those can be fixed for yakkety with no FFE, outside of that, we'd need a FFE for specific features
<rharper> dupondje: are their ubuntu bugs for those yet ?
<dupondje> https://bugs.launchpad.net/ubuntu/+source/network-manager-strongswan/+bug/1578193 :)
<ubottu> Launchpad bug 1578193 in network-manager-strongswan (Ubuntu) "cannot load legacy-only plugin" [Undecided,Confirmed]
<dupondje> network-manager-strongswan needs to get updated to 1.4.0
<dupondje> and that requires both patches to be in strongswan :)
<dupondje> cause nm-strongswan is broken since xenial
<rharper> dupondje: ok, thanks.
<dupondje> see https://www.strongswan.org/download.html
<LocutusOfBorg> doko, FYI, I'm trying to fix gitlab, and I would like to see it migrating
<LocutusOfBorg> don't shoot at me, since I don't know the ruby-devise-async issue :) and I don't talk ruby
<LocutusOfBorg> :)
<dupondje> rharper: btw, I just uploaded a debdiff to that bug for the network-manager-strongswan 1.4.0 update
<dupondje> which is really a requirement for yakkety, as the current version is just broken
<rharper> dupondje: great, I'll take a look
<rharper> dupondje: IIRC, you need two things.  update to the plugin, and patches to strongswan itself, right ?
<dupondje> I tested the debdiff on Xenial, and the GUI works again, so might want to test it on Yakkety :)
<dupondje> rharper: indeed, the plugin needs update to 1.4.0, and those 2 patches needs to be added to strongswan
<dupondje> rharper: dunno why all plugins are in a separate package also, better keep a bit the same like debian imo :)
<rharper> dupondje: we certainly are attempting to reduce the delta between debian and ubuntu w.r.t packages; we reduced the number of subpackages significanty in the xenial release, but there remains some ubuntu use-cases which enabled some features not enabled in debian;  we do have a TODO of seeing if debian would accept those changes.
<pitti> Saviq: sorry, meetings back to back, will look later
<Saviq> pitti, nw, thanks
<coreycb> arges, hello, the packages in sru bug 1614131 are ready to promote to xenial-updates if you have a moment
<ubottu> bug 1614131 in Ubuntu Cloud Archive mitaka "[SRU] OpenStack Mitaka point releases" [Undecided,New] https://launchpad.net/bugs/1614131
<arges> coreycb: k
<semiosis> Odd_Bloke: livecd-rootfs 2.408.4 landed in xenial-updates.  can you do your thing to update the build server?
<coreycb> arges, thanks
<arges> coreycb: np
 * [gnubie] waves
<[gnubie]> anyone here can help me on my debootstrap issue? kindly take a look at http://paste.ubuntu.com/23182607/
<[gnubie]> i am wondering why i am always failing right after extracting zlib1g package.. the next step should be the installing of core packages..
<[gnubie]> anyone?
<ricotz> yofel, hi, are there issues with pkg-kde-tools on yakkety ppa builder currently?
 * [gnubie] is waiting and crossing fingersâ¦
<bdmurray> Is there anybody about with a good understanding of apt's problem resolver?  bug 1610756
<ubottu> bug 1610756 in ubuntu-release-upgrader (Ubuntu) "upgrade to 16.04 failed to calculate due to backuppc" [Medium,Triaged] https://launchpad.net/bugs/1610756
<bdmurray> I think its an issue with libcgi-pm-perl and libparse-debianchangelog-perl and backuppc, but I'm not certain how to fix it.
<ricotz> yofel, nevermind, my fault
<bdmurray> mvo: Are you about?
<mvo> bdmurray: not much, a bit late, but I can reply async
<bdmurray> mvo: I'm uncertain on to fix the upgrade issue in bug 1610756
<ubottu> bug 1610756 in ubuntu-release-upgrader (Ubuntu) "upgrade to 16.04 failed to calculate due to backuppc" [Medium,Triaged] https://launchpad.net/bugs/1610756
<mvo> bdmurray: I have no investigated in great detail but it looks like libparse-debianchangelog-perl, libcgi-pm-perl  are the root of the issue
<mvo> bdmurray: I need a bit more time
<bdmurray> mvo: Yes, that was what I discovered too.  Its the how to fix it bit, I'm not sure about.
<mvo> bdmurray: updated the bugreport
<pitti> Saviq: I saw the tests running, but https://requests.ci-train.ubuntu.com/static/britney/landing-078/vivid/excuses.html hasn't updated for several hours
<Saviq> pitti, it's been accepted by QA nevertheless since, so excuses don't get updated after that
<Saviq> robru, think we could do something about that â? is it too expensive to update all lander-approved non-landed non-auto-signedoff tickets?
<robru> Saviq: I specifically stopped running britney on QA -approved tickets precisely because britney runs were taking too long and I saw no point doing automated testing on something already approved by humans
<robru> pitti:  ^
<Saviq> robru, I'm not saying trigger any, but could we at least pick up results from the ones that did run?
<robru> Saviq: no, there's no such thing as "pick up results" I either run britney or I don't
<Saviq> robru, oh so if something didn't run yet it would get triggered?
<Saviq> well, ok
<robru> Saviq: what? Bileto runs britney and British runs autopkgtest.
<jbicha> could we ignore autopkgtests for ruby-devise-async/0.9.0-1 ? it will be removed from Debian & Ubuntu soon-ish https://bugs.debian.org/837644
<ubottu> Debian bug 837644 in ruby-devise-async "ruby-devise-async is not compatible with devise >= 4.0" [Serious,Open]
<Saviq> robru, in the scenario where: Lander approves â Bileto queues tests up â QA approves before tests finish
<Saviq> robru, the only step missing is â Bileto gets results for the previously ran tests
<Saviq> I'm not sure how this works behind the scenes, so it may be impossible
<Saviq> but doesn't bileto queue them up basically as soon as lander approves? so there's nary a case where all the tests wouldn't run anyway?
<Saviq> anyway, that's just icing on the cake
<Saviq> might file a bug to track it
<robru> Saviq: QA isn't supposed to be approving things before autopkgtests finish, that should be very exceptional
<Saviq> robru, sure, except it happens, for different reasons :)
<Saviq> robru, also, this isn't "QA approved", but rather "QA ready"
<Saviq> and it just feels a waste that we don't get results for the tests that did run anyway
<Saviq> I think if we expected things to be green, it would still be good to get a confirmation - and even more important - info about any regressions
<robru> Saviq: Bileto does not start autopkgtests and it does not inspect results either. Bileto triggers britney and britney does all that. To see the results I would have to run britney again which slows down all other tickets
<Saviq> that's why I asked about about the reasoning - didn't pitti recently blog/post about an order of magnitude of speed improvements in britney btw? :)
<robru> Saviq: it seems to me that if you care about the autopkgtest results you should not override the QA status
<doko> crap, updating to yakkety was not a good idea ... https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1624086
<ubottu> Launchpad bug 1624086 in unity (Ubuntu) "unity desktop broken after upgrade to yakkety (release pocket only)" [High,New]
<Saviq> robru, except that means waiting ;)
<Saviq> robru, I get you, no worries
<robru> Saviq: britney takes 2 minutes per series per PPA, this hasn't changed since I started running it in bileto and its not parallelizable due to memory consumption. I've seen OOM just running 2 at once
<Saviq> robru, ouchie
<mwhudson> http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html is days old, is that normal?
#ubuntu-devel 2016-09-16
<cpaelzer> good Morning
<pitti> Good morning
<pitti> robru, Saviq: ah, makes sense
<pitti> mwhudson: it's not, looking
<pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/log/xenial/2016-09-16/06:46:39.log
<mwhudson> pitti: awesome
<pitti> so xenial/Packages_arm64 has *two* Package: entries for liboxideqt-qmlplugin
<pitti> the regular one and some "faux" thingy: http://paste.ubuntu.com/23185246/
<pitti> (not on any other arch)
<pitti> so the breakage matches the time of publishing https://launchpad.net/ubuntu/+source/oxide-qt/1.17.7-0ubuntu0.16.04.1
<pitti> cjwatson, infinity: ^ do you happen to have an idea what these "faux" packages are?
<pitti> find -name faux-packages â nothing
<pitti> actually, britney2 does not write the Packages_*, so that must be britney1 already
<pitti> aah!
<pitti> http://bazaar.launchpad.net/~ubuntu-release/britney/britney1-ubuntu/revision/264
<pitti> so the difference is that the previous https://launchpad.net/ubuntu/+source/oxide-qt/1.16.5-0ubuntu0.16.04.1 just didn't build on arm64 yet, and we have these crutches
<pitti> but 1.17.7 was pushed to xenial only, *not* to yakkety yet
<pitti> chrisccoulson: ^ fail :(
<pitti> so I remove the fauxpkg entry as it actually should build on yakkety now, to unbreak xenial britney runs
<pitti> it might block some yakkety progressions, but the new oxide must land in yakkety ASAP anyway to unbreak  upgrades
<pitti> mwhudson: ok, britney 1 fauxpkg list update pushed
<pitti> thanks for pointing out
<mwhudson> pitti: fun times, thanks for fixing
<pitti> mwhudson: hah, and there it goes: http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html
<chrisccoulson> pitti, oh, I did ping tyhicks about sponsoring that
<chrisccoulson> I can't upload my own package to y, despite being able to copy it to security everywhere else
<pitti> chrisccoulson: oh, oops :) I can upload as well
<chrisccoulson> pitti, that would be great. It's currently sat on in https://private-fileshare.canonical.com/~chrisccoulson/
<chrisccoulson> (sorry for breaking things)
<pitti> chrisccoulson: no worries, the fauxpkg thing was not your fault :)
<pitti> urgh, 485 MB orig.tar
<chrisccoulson> oh, that seems smaller than usual
<pitti> I guess I better check/sign/verify this in the data center :)
<chrisccoulson> The last one was nearly 600MB. I guess some stuff got removed from the chromium tree
<pitti> chrisccoulson: meh, can't dput from private-fileshare
<chrisccoulson> pitti, I don't mind uploading it from somewhere else
<pitti> chrisccoulson: nevermind, I'll just suck it up and let it upload for half an hour
<pitti> easier than wasting human time on this :)
<chrisccoulson> it only takes a few minutes for me to upload. I can push it to a machine that you can dput from :)
<pitti> nah, it's fine
<pitti> chrisccoulson: I don't actually need to upload the orig, it's already in the archive
<pitti> so -sd is enough
<chrisccoulson> ah yes
<chrisccoulson> pitti, thanks for doing that
<pitti> chrisccoulson: no problem!
<mwhudson> how tasteless is it to debug autopkgtest problems by uploading to the archive over and over again? :)
<mwhudson> pitti: actually iirc there's a way you can run an autopkgtest so that i can log into the system as it runs?
<pitti> mwhudson: yes, start it with --shell
<mwhudson> pitti: i mean on production infra
<pitti> then you'll get a shell (or instructions how to log in) after it  fails
<mwhudson> pitti: it works here :-)
<mwhudson> (it's a proxy problem)
<pitti> mwhudson: ah yes, can do that
<mwhudson> pitti: alternatively do you know a way to mimic the proxy set up locally?
<mwhudson> pitti: cool, i'll ping you next week then :)
<mwhudson> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/d/docker.io/20160916_091453@/log.gz <- so close!
<pitti> mwhudson: in principle, install squid on the host and set the firewall in the VM to only allow talking to 10.0.2.2, not anywhere else; but I haven't actually done that in pracice yet
<mwhudson> oh yeah, firewall in the VM makes sense
<mwhudson> anyway time to log off  :)
<otto> I have "patches" for https://bugs.launchpad.net/ubuntu/+source/mariadb-10.0/+bug/1605493 - on what IRC channel should I poke security-sponsors for upload?
<ubottu> Launchpad bug 1605493 in mariadb-5.5 (Ubuntu) "USN-3040-1: MySQL vulnerabilities partially applies to MariaDB too" [Medium,Incomplete]
<rbasak> otto: #ubuntu-hardened
<ricotz> chrisccoulson, hi, could you trigger another trunk and aurora snapshot of firefox?
<otto> rbasak: thanks
<attente> https://www.irccloud.com/pastebin/mOwaQ8md/
<attente> hi, i'm having trouble switching VTs. just getting a black screen
<attente> Xorg.0.log just has that ^: https://www.irccloud.com/pastebin/mOwaQ8md/
<attente> when switching between VT 0 and 7
<attente> any advice for how to debug this?
<Mirv> sorry for hijacking autopkgtest infra again
<pitti> Mirv: heh, I just wish the KDE packages wouldn't all need an entire build..
 * apw looks grumpily at Mirv, twice in two days
 * pitti counters with uploading a few hundred langpacks! Mirv, your move :)
<pitti> (our first-ever yakkety ones, how embarrassing..)
<Unit193> Bah, who cares about !English!?
<pitti> Unit193: on parle franÃ§ais dans l'Ã©quipe du bureau, par example :)
<pitti> oh, no seb128 today..
<semiosis> Odd_Bloke: I just tested the latest xenial vagrant box from 2016-09-14 and it still does not have the resolv.conf fix.  Can you update livecd-rootfs on the build servers to 2.408.4?  thanks!
<Mirv> apw: one problem is that for each qt module update the autopkgtests are run three times. two times when I click "Approved" in a silo (for xenial overlay and yakkety), and the third time when it's in yakkety-proposed (assuming no new fixes were needed). the "two times" for the currenty yakkety-proposed version were done last weekend, and I actually _skipped_ running the two times again after I removed a
<Mirv> couple of patches causing problems since the regressions I saw from Mon-Tue tests were limited to those patches. if I'd have clicked "Approve" again, it's be the sixth time now in two days of running the thousand+ autopkgtests.
<Mirv> pitti: I'm ready to publish qtdeclarative to proposed!
<pitti> Mirv: hm, I'll look for a typo fix in glibc
<Mirv> :)
<dobey> Mirv: well, since silo autopkgtests don't run against proposed, they're actually different autopkgtests anyway
<pitti> dobey: ubuntu autopkgtest don't run against -proposed either
<pitti> well, not against *all* of proposed anyway
<rharper> dupondje: your debdiff, was that against network-manager-strongswan from yakkety ?  it's not applying cleanly for me
<kenvandine> doko, now that the libphonenumber sync has landed, can you please look at MIR bug 1618178 again?
<ubottu> bug 1618178 in libphonenumber (Ubuntu) "[MIR] libphonenumber" [Undecided,New] https://launchpad.net/bugs/1618178
<nacc> smoser: do you have an example time for an import? I saw you were using that -- want to compare the new binding library's performance
<smoser> i dont. no. sorry.
<andrewsh> guys, any idea why http://bazaar.launchpad.net/~helen-fornazier/shim/trunk/revision/108 the patches a GPLv2-ed when the package is BSD-2+OpenSSL?
<nacc> smoser: np -- i will just run an old version and new
<nacc> smoser: i've got the conversion mostly done, just need to check that it produces identical trees in all existing cases
<andrewsh> cyphermox: ââ
<sforshee> pitti: I've got a machine running yakkety which sometimes boots fine, other times it hangs for a while then drops to maitenance mode. When that happens it seems to be because udev isn't adding the "systemd" tag to devices. Any ideas why that might be happening?
<cyphermox> andrewsh: might just be an oversight
<andrewsh> cyphermox: could you please correct it?
<andrewsh> Helen is trying to push that package in Debian, and it's been REJECTed at least once already
<andrewsh> s/in/into/
<doko> kenvandine: will do, but there no component mismatch yet. can you re-enabled the java package?
<cyphermox> andrewsh: sorry, that won't work. if we update that package it will have to be signed again by Microsoft
<cyphermox> andrewsh: it should be fine for you to do the fix in Debian directly prior to uploading
<cyphermox> I'll keep note that it needs to be fixed, but that will wait until we next do a round of signing (which may be soonish anyway)
<cjwatson> (it doesn't build reproducibly?)
<cjwatson> I guess toolchain changes
<andrewsh> cyphermox: could you email Helen some sort of an explicit statement it was a mistake so that she can refer it to the FTP masters
<andrewsh> ?
<andrewsh> cyphermox: also, why not just commit a change to the VCS?
<andrewsh> (bzr or git or whatever you're using)
<cyphermox> cjwatson: afaik it's not quite there yet, I'd have to check
<andrewsh> cyphermox: so, what should we do?
<nacc> powersj: rbasak: ~ubuntu-core-dev/ubuntu-seeds/ubuntu.yakkety has a 'blacklist' file
<nacc> but i guess that would affect more than just server
<powersj> nacc how about the server-ship file
<powersj> http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.yakkety/view/head:/server-ship
<nacc> * !libavcodec*
<nacc> would appear to be the syntax?
<nacc> so i think you'd add it to that blacklist, maybe?
<nacc> might be worth an e-mail to ubuntu-devel too
<nacc> i don't know if you also need to modify the print-server task
<nacc> task/file
<powersj> for folks fyi: server ISOs jumped in size by 80mb last night due to "fonts-noto-cjk" being pulled in
<powersj> nacc, so I guess I am hung up on the fact that xenial/yakkety don't have a print-server tasksel anymore
<powersj> so why are we carrying print related things in the first place
<rbasak> powersj: what makes you say that?
<powersj> tasksel --list | grep -i print
<powersj> in-target: debconf (developer): <-- SUBST tasksel/first CHOICES_C manual, cloud-image, dns-server, lamp-server, mail-server, postgresql-server, samba-server, standard, virt-host, openssh-server, server
<powersj> those are the choices in an install
<rbasak> powersj: I'm not sure why it's in that list
<rbasak> Why it's not in that list
<nacc> yeah, that's a bit odd, it's in the seeds (it seems like)
<rbasak> But on my Xenial system, for example, print-server does appear in /usr/share/tasksel/descs/ubuntu-tasks.desc
<nacc> same on yakkety
<rbasak> And yes, it's in the seeds.
<nacc> heh
<nacc>   /usr/share/tasksel/*.desc and /usr/local/share/tasksel/*.desc are used
<nacc>        to define tasks.
<nacc> is it possible tasksel needs to be taught /usr/share/tasksel/descs/ ?
<rbasak> It might be worth looking into tasksel to understand why it's not listing that one.
<rbasak> (as it lists others)
<rbasak> I see it in debian-tasks.desc too. I wonder if that has anything to do with it.
<koike> andrewsh, cyphermox, could this be corrected in the bzr? So we can fetch the corrected version to build the shim-signed package for debian?
<koike> cyphermox, I sent a merge proposal to the ~ubuntu-core-dev/shim/trunk branch adding the openssl license, I can also change the gpl-2 to bsd if you are ok with this
<cjwatson> nacc: the only purpose of blacklist seed entries is to cause builds to fail hard if a package shows up
<cjwatson> nacc: it's very rarely a good idea to use them (in ten years I think libavcodec has been the only legitimate example)
<nacc> cjwatson: ah ok!
<powersj> good to know
<nacc> powersj: regardless of anything else, it does seem like you found a bug in tasksel :)
<rbasak> If the installer has not been presenting print-server in Xenial and nobody has noticed, then perhaps we should just drop the task anyway.
<rbasak> (to fix the size problem)
<powersj> yeah... I thought that it was gone because demand had gone down, not because of a bug lol
<nacc> rbasak: good point
<powersj> rbasak, do I file a bug about the oversized ISO then? and if so against what?
<jbicha> powersj: https://launchpad.net/ubuntu/+source/ghostscript/9.19~dfsg+1-0ubuntu3
<powersj> jbicha, thanks, rbasak has already updated bug 1621210 with our discovery
<ubottu> bug 1621210 in ghostscript (Ubuntu) "libgs9-common recommends fonts-droid-fallback, which isn't in main" [Medium,Fix released] https://launchpad.net/bugs/1621210
<kenvandine> doko, i did, libphonenumber7-java is in yakkety
<doko> ta, didn't see it yet
<rharper> dupondje: ok, I've updated the bug (https://bugs.launchpad.net/ubuntu/+source/network-manager-strongswan/+bug/1578193);  I've a build of strongswan with the specified patches, and the plugin 1.4.0 together;  please give those packages a test to see if we need anything else.
<ubottu> Launchpad bug 1578193 in network-manager-strongswan (Ubuntu) "cannot load legacy-only plugin" [Undecided,Confirmed]
<nacc> rbasak: just fyi, your solution for the apt import is working -- having to do some careful tree munging, but it overall seems to be working well (had to transition to pygit2 at the same time for my own sanity, so it's taken me longer to implement than i had planned)
<rbasak> \o/
<nacc> tjaalton: x question for you -- i normally run with 2 external monitors and my internal LCD on my laptop at home. But with 16.10, it seems like xrandr is saying the maximum screen size is 8192x8192 (while my actual maximum screen size is 8960x2160). Is this something that might have changed recently? This used to work with 16.04 (all three displays at their maximum resolutions)
<nacc> tjaalton: absolutely not urgent, so respond if/when you can
<tjaalton> nacc: probably modesetting_drv.so being more strict about what modes are available
<nacc> tjaalton: interesting -- it seems like all the individual display modes are allowed still. And if i turn off my lowest res monitor, i can max out the other two. It's just the virtual screen limit i am hitting?
#ubuntu-devel 2016-09-17
<doko> jamespage, coreycb, zul_: https://bugs.launchpad.net/ubuntu/+source/python-wsgi-intercept/+bug/1624585
<ubottu> Launchpad bug 1624585 in python-wsgi-intercept (Ubuntu) "[MIR] python-wsgi-intercept (needed by nova)" [Undecided,Incomplete]
<gopalindians> Â°Â¯R
<vooze> Hi, I need some help with my PPA, I have uploaded a package of pulseaudio with some patches removed to fix a bug, like this: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1574324 -- But when I try to add my own PPA, it says: E: The repository 'http://ppa.launchpad.net/vooze/pulseaudio-fix/ubuntu xenial Release' does not have a Release file. - How do I create a release file?
<ubottu> Launchpad bug 1574324 in pulseaudio (Ubuntu) "pulseaudio crashes when connecting to bluetooth headphones (due to ubuntu changes?)" [High,In progress]
<vooze> okay nevermind. Seems it has been resolved after some time :)
<Unit193> I would randomly guess Debian 837036 affects yakkety.
<ubottu> Debian bug 837036 in gitolite3 "gitolite3: uninstallable without . in @INC" [Serious,Fixed] http://bugs.debian.org/837036
#ubuntu-devel 2016-09-18
<tsimonq2> pitti: hello
<tsimonq2> pitti: when using both of your scripts on https://wiki.ubuntu.com/ProposedMigration/LocalSetup , I've experienced a problem where your script doesn't automatically gunzip the Packages files. I've been using the following one-liner in the data/yakkety and data/yakkety-proposed to get it decrypted:
<tsimonq2> pitti: for arch in amd64 arm64 armhf i386 powerpc ppc64el; do mv Packages_$arch{,.gz}; gunzip Packages_$arch; done
<tsimonq2> pitti: also, I'd like to deploy britney2 in a setup with multiple PPAs, if you have a minute, it would be awesome if you could tweak your script to allow for multiple PPAs to be under the sudo yakkety-proposed
<tsimonq2> pitti: thanks for the scripts :)
<tsimonq2> pitti: (s/decrypted/unzipped/)
<tsimonq2> pitti: in addition, I've been getting FileNotFoundError: [Errno 2] No such file or directory: 'data/yakkety/state/age-policy-dates' which could be fixed by creating an empty file at that location. also something to consider adding to both of the scripts. :)
<tsimonq2> pitti: (it could be really helpful to get the scripts either into the Ubuntu or Debian britney2 code so people can make these sort of changes)
<tsimonq2> pitti: there's a couple other files that could be created with your script, if you run it fresh locally it's obvious ;)
<tsimonq2> pitti: fwiw I filed something on GitHub: https://github.com/Debian/britney2/issues/13
<tsimonq2> pitti: here, I implemented some of these things. Take a look: https://git.launchpad.net/~kubuntu-packagers/+git/kubuntu-britney2/plain/britney-indexes-ppa
<Mirv> ok this time I'll grab the autopkgtest infra on Sunday, hopefully it's slightly more friendly...
<Mirv> people would be otherwise mad at me for slowing down their Final Beta Freeze rush uploads tomorrow :)
<Mirv> plus, luckily the previous qtbase upload's autopkgtests finally passed for good, so it migrated to release pocket
<Saviq> RAOF, when you get up, will you please click â» on the two regressions in https://requests.ci-train.ubuntu.com/static/britney/landing-078/yakkety/excuses.html ? thanks!
<RAOF> Saviq: I presume someone else has, because I don't see any regressions on that page.
#ubuntu-devel 2017-09-11
<pitti> doko: hey, wie gehts?
<LocutusOfBorg> maxb, #ubuntu-release seems more appropriate
<zyga-ubuntu> cyphermox: hey, remember my network-manager/modem-manager issue? I updated this bug report with some more details: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1716034
<ubottu> Launchpad bug 1716034 in network-manager (Ubuntu) "Network manager stops managing Ethernet links after upgrade" [Undecided,Confirmed]
<zyga-ubuntu> pitti: hey, since you wrote netplan initially, can you perhaps have a look as well?
<zyga-ubuntu> pitti: tl;dr; version is that xenial -> zesty breaks networking because of a debian patch you made there
<zyga-ubuntu> pitti: and perhaps you know how this was supposed to be changed on updates
<juliank> xnox: Not sure if you noticed, but apt-helper wait-online (a dumb version just running nm-online/systemd-networkd-wait-online when their services are active) landed in artful. Catching up with automatic updates should be more reliable at resume now. SRUs will come in a few weeks if that works out well :)
<juliank> the timeout is 30 seconds right now, we can still change that if we want to wait longer for network
<juliank> (if you use multiple network management services, the time outs add up, though)
<juliank> We might want to patch network manager or docker.io to make this reliable on systems with docker, as described in https://bugzilla.gnome.org/show_bug.cgi?id=787487
<ubottu> Gnome bug 787487 in general "Please add "docker[0-9]*" to 85-nm-unmanaged.rules" [Normal,New]
<juliank> * more reliable
<xnox> juliank, do you really need multiple wait onlines? as the networked-wait-online currently waits for any one interface to become routable.
<xnox> juliank, however i think that this thus may be buggy
<xnox> juliank, and there are bug reports in artful now that wait-online stuff causes boot hangs and delays as if it is not working correctly.
<juliank> xnox: need is a strong word, I just figured it's the best choice.  I also moved the network-online dep from the timer to the target, that might improve boot performance.
<juliank> * to the service
<juliank> this way basic.target does not pull it in anymore
<juliank> And we only run systemd-networkd-wait-online if networkd is running; or nm-online if NetworkManager is running
<juliank> because it just hung before
<juliank> s/before/without the service running/
<juliank> in theory it should already not be impacting boot performance, as basic.target has a mere Wants on timers.target, and no After=
<juliank> But if it did for some reason, it should be better now
<pitti> zyga-ubuntu: so that's different to bug 1690992 ? I thought that already avoided the disabling on all upgrades
<ubottu> bug 1690992 in network-manager (Ubuntu Zesty) "fix for bug #1569649 left NetworkManager-wait-online disabled on some systems" [Undecided,Fix released] https://launchpad.net/bugs/1690992
<zyga-ubuntu> pitti: that feels different
<zyga-ubuntu> pitti: essentially N-M was igoring all but wifi
<zyga-ubuntu> pitti: ethernet was disabled
<zyga-ubuntu> pitti: as was my wwan (called "gsm" here) connection
<zyga-ubuntu> pitti: this also affects my desktop running artful
<zyga-ubuntu> pitti: (both are upgrades from xenial)
<pitti> zyga-ubuntu: right, sorry, mistyped the bug #; I followed up with the right one in your's
<pitti> zyga-ubuntu: I mean bug 1676547
<ubottu> bug 1676547 in network-manager (Ubuntu) "No network connectivity after upgrade from 16.04 to 16.10" [Critical,In progress] https://launchpad.net/bugs/1676547
<zyga-ubuntu> pitti: aha
<zyga-ubuntu> pitti: how was it supposed to work?
<zyga-ubuntu> pitti: the crippling file is in /usr/lib by default
<zyga-ubuntu> pitti: what was to ensure that the counterweight is in /etc on non-server systems?
<pitti> zyga-ubuntu: NM should continue to work as-is on updates, and not manage eth on new installs
<pitti> zyga-ubuntu: the empty conf file (shadowing the one in /usr) was supposed to be created by the postinst
<pitti> but apparently there was some logic error
<zyga-ubuntu> pitti: why should NM not manage ethernet?
<zyga-ubuntu> pitti: note *on desktops*
<zyga-ubuntu> pitti: I don't mind servers
<pitti> zyga-ubuntu: because on new installs netplan will do that
<pitti> oh, on desktops it should manage everything, yes
<pitti> but that's done by a netplan conf snippet which (re-)enables eth for NM
<Unit193> But amusingly, to remove nplan which is unused, you remove ubuntu-standard too. :P
<zyga-ubuntu> pitti: but on desktop netplan is not doing anything for me
<zyga-ubuntu> pitti: no default config or anything, how was it supposed to be triggered?
<pitti> there should be a default config
<zyga-ubuntu> where?
<zyga-ubuntu> I don't see one in the package
<pitti> the installer should plant an /etc/netplan/ snippet which assingns all ethernets to NM
<zyga-ubuntu> /etc/netplan
<zyga-ubuntu> pitti: that's on new installs, what about updates?
<pitti> mind you, if that is an upgrade, none of this will/should happen
<zyga-ubuntu> pitti: is this just a lot of people doing dist-upgrade the old way?
<zyga-ubuntu> and then running into a problem?
<pitti> on upgrades, NM is simply meant to create the empty "shadowing" of the /usr/lib/ NM config file via postinst
<pitti> dist-upgrade should be fine, the logic is in postinst, not update-manager
<pitti> the postinst logic was simply not sufficient
<zyga-ubuntu> aha
<zyga-ubuntu> I see, thank you
<zyga-ubuntu> are you still interested in fixing this or ENOTIME anymore?
<juliank> I thought netplan was just generating NM config files?
<pitti> zyga-ubuntu: cyphermox has already fixed this, or is at it
<pitti> juliank: yes, that or networkd config files, depending on the config
<zyga-ubuntu> pitti: I see, thank you!
<zyga-ubuntu>     if dpkg --compare-versions "$2" le-nl "1.2.2-0ubuntu4"; then
<zyga-ubuntu>         mkdir -p /etc/NetworkManager/conf.d || true
<zyga-ubuntu>         # for old versions, override the global config with a null config
<zyga-ubuntu>         touch /etc/NetworkManager/conf.d/10-globally-managed-devices.conf
<zyga-ubuntu>     fi
<Unit193> juliank: It's kind of backwards though, network-manager ships the config file that disables nm by default, whereas that snippet really should be in nplan package. :P
<pitti> yeah, that would work, too - feel free to toss it around :)
<Unit193> I did, the bug was closed.
<zyga-ubuntu> pitti: that's in the postins file, for whatever reason it didn't run
<zyga-ubuntu> pitti: thank you again!
<pitti> zyga-ubuntu: the reason is that 1.2.6 was uploaded to xenial-updates
<pitti> zyga-ubuntu: so the version comparison did not match any more
<pitti> so I think it should just be bumped to the version that introduces the file
<juliank> xnox: I think boot speed might have improved with apt 1.5~rc2 indeed. The past time it always spent 10s in userspace now it's at 5 seconds
<juliank> curiously, total time went from 35s down to 20s
<juliank> despite the other times being the same
<juliank> A: Startup finished in 1.138s (kernel) + 9.957s (initrd) + 10.063s (userspace) = 35.269s
<juliank> B: Startup finished in 1.156s (kernel) + 8.399s (initrd) + 4.632s (userspace) = 20.473s.
<juliank> Although I must say that the timer or the service never was in the critical chain
<juliank> Let's downgrade and reboot
<juliank> and yup, it's back at 10s
<juliank> But that's mostly a reporting problem I guess
<juliank> If the timer depends on network-online, the boot is not considered complete.
<juliank> If you move the dep to the service, the boot is considered complete earlier
<juliank> But well, perception matters to
<juliank> o
<juliank> boot plots: https://people.debian.org/~jak/boot-rc1.svg  https://people.debian.org/~jak/boot-rc2.svg
<juliank> I mean, unless the timer has elapsed we don't even pull in wait-online stuff during boot anymore
<sil2100> jbicha: hey! I see
<sil2100> Argh, copy-paste error
<sil2100> jbicha: hey! I see the evolution-data-server you recently uploaded enables the installed-tests autopkgtests, but those seem to be horribly flaky
<sil2100> jbicha: they were disabled with the previous versions, now they seem to be failing in artful-proposed for some archs
<sil2100> When running on my chroot I see they're indeed very unreliable, getting different failures with every run
<sil2100> jbicha: maybe we should disable them again?
<LocutusOfBorg> doko, I tried to debug potemkin-clojure failure, and I failed, do you have some debug/progress to share?
<doko> no
<LocutusOfBorg> maybe I'll ask to debian-java if you didn't already
<LocutusOfBorg> doko, could you please include https://launchpad.net/ubuntu/+source/automake-1.15/1:1.15.1-2.1ubuntu1 if you have chances to do a new test rebuild?
<juliank> So, how do the servers boot with networking? I'm currently dropping the Wants=network-online.target from apt as that has weird implications (and we have our own wait-online helper for network-manager, systemd-networkd, and connman). We still have an After=network.target, so stuff like ifupdown will still run before the service.
<juliank> The question is if that's enough, or if there is something else to look out for
<juliank> xenial, zesty, and artful
<juliank> Well I guess it seems fine
<juliank> I'm currently waiting 30s per service, so if someone has connman, NM, and systemd-networkd active, but no connection, it would wait 90s.
<juliank> kind of weird
<juliank> (but easy)
<doko> LocutusOfBorg: the next test rebuild will be the one once glibc migrates
<LocutusOfBorg> so will you include that upload?
<seb128> juliank, that might be a question for xnox
<LocutusOfBorg> it is not part of artful
<LocutusOfBorg> jbicha, are you located in florida?
<xnox> juliank, servers default to networkd in artful and up
<xnox> juliank, prior to that they defaulted to ifupdown
<juliank> Right
<juliank> The question was mostly solved anyway because ifupdown's wait-online helper did not exist back then
<doko> cyphermox: ping nplan failures
<doko> jamespage: please could you have a look at http://autopkgtest.ubuntu.com/packages/o/openvswitch/artful/i386 ?
<doko> or is this temporary?
<xnox> doko, unping cyphermox
<xnox> doko, nplan fails due to bad base cloud-image
<doko> ahh, ok
<xnox> doko, and we need to get a new cloud-image which is currently broken due to multiple reasons, all of which are in various stages of being fixed.
<jamespage> doko: that looks like the transient issues with had some some architectures when I did some previous uploads - the tests just timeout
<doko> ok, retrying
<Laney> doko: Earlier today I retried everything; openvswitch is currently running
<doko> ohh, ok. so better continue tomorrow with the analysis
<Laney> as you wish - some results will be in already - but I wouldn't retry things again
<slangasek> colord looks crazy
<slangasek> valgrind in an autopkgtest?
<slangasek> ... which fails because of stderr output
<nacc> heh
<doko> fitspng is caused by https://sourceware.org/bugzilla/show_bug.cgi?id=16640
<ubottu> sourceware.org bug 16640 in string "string/strtok.c: undefined behaviour inconsistent between x86 and other generic code" [Minor,Resolved: fixed]
<powersj> cyphermox: https://paste.ubuntu.com/25515376/ looks like the ISO tests are still getting asked for the keyboard-config, can you take another look?
<doko> tyhicks: please could you have a look at the autopkg test failures triggered by file?
<tyhicks> doko: I saw the emails come in over the weekend but haven't had a chance to look yet this morning
<tyhicks> sbeattie: ^
<tyhicks> sbeattie: fyi, I restarted a test that was preventing bzr from migrating and now it looks to be ready to migrate
<doko> chrisccoulson: what is our firefox story? I noticed that there were no artful uploads at all
<doko> ricotz: ^^^
<sbeattie> doko, tyhicks: yeah, I was looking at the file one, debian has a newer version of diffoscope, but I haven't confirmed it addresses the failure.
<sarnold> doko: I understand that artful firefox is blocked behind N different rustc update failures, a different one for each arch
<doko> sarnold: https://launchpad.net/ubuntu/+source/rustc/1.18.0+dfsg1-4ubuntu1 looks fine
<sarnold> it kinda sucks that we care about firefox on more platforms than are tier1 platforms for the rustc team
<sarnold> doko: that's two releases too old
<doko> ahh, ok
<ricotz> sarnold, no, it is enough
<ricotz> doko, hi
<sarnold> ricotz: oh? I understood 1.19 was needed for the newest firefox, and 1.20 will be needed right quick..
<doko> anyway, you need to fix the glibc-2.26 triggered build failures
<ricotz> sarnold, ff57 is a long way to go
<chrisccoulson> doko, I just need to upload it, but it doesn't work at all on arm at the moment
<ricotz> ff56 is good with 1.17.0
<ricotz> doko, yeah, confince infinity to let is pass from proposed despite the failure
<doko> ?
<doko> it ftbfs
<ricotz> because upstream only care about tier1 archs
<ricotz> e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1391126
<ubottu> Mozilla bug 1391126 in General "toolkit/components/backgroundhangmonitor/HangStack.cpp:2:10: fatal error: shared-libraries.h: No such file or directory" [Normal,New]
<chrisccoulson> that's not even the main problem. If you get it to build it doesn't run, because of what looks like a miscompilation
<ricotz> chrisccoulson, did you forward the rustc fix for llvm4.0 to artful?
<chrisccoulson> which fix?
<ricotz> add debian/patches/fix-computeKnownBits-for-ARMISD::CMOV.patch
<chrisccoulson> is that not there already?
<ricotz> I am asking you
<ricotz> doko, ^?
<chrisccoulson> oh, it's probably not. It's not in debian either
<doko> I just saw that it builds on debian s390x, but not on Ubuntu
<ricotz> chrisccoulson, same for llvm3.9, I guess
<ricotz> chrisccoulson, doko, also, could be that ff55 is not happy with gcc7
<chrisccoulson> doko, can I get https://github.com/llvm-mirror/llvm/commit/cdc303e5ed4d3110e6f70931775a70bb1de44ed6 in llvm-toolchain-4.0 in artful please? (it's required for rust)
<chrisccoulson> well, it's required for a future version of rust, that I'm in the process of preparing
<chrisccoulson> it's already in the 3.9 package
<xnox> doko, what package is that specifically that builds in debian, but not in ubuntu? i'm failing to get context from above
<doko> xnox: firefox
<xnox> phh
<ricotz> chrisccoulson, I don't think it is in llvm3.9/artful
<chrisccoulson> ricotz, it is
<doko> chrisccoulson: if you want to use 3.9, please fix the build. or use 4.0 / 5.0
<ricotz> chrisccoulson, ah ok, missed it
<xnox> doko, but debian/fedora/etc do not use piles of embedded libraries to do builds like we do. Hence it builds :-(
<ricotz> especialy nss/nspr
<doko> xnox: so maybe it's time to change that, at least for the architectures we are not interested in?
<xnox> doko, i'm not sure anybody cares though =/ cause firefox is out of scope on s390x
<doko> ohh, but then you can't build libreoffice
 * doko hides
<doko> can't you run libreoffice in server mode these days?
<xnox> doko, i'm sure you can boot to libreoffice, cause it embeds systemd =)
<cyphermox> powersj: I think that will be fixed in a couple of hours?
<powersj> cyphermox: ok thx, I'll sit tight and check results tomorrow morning
<cyphermox> powersj: or it could be that I never uploaded the fix, I got distracted, oops
<cyphermox> powersj: ok, the fix is in
<cyphermox> it's just waiting for the d-i build to finish
<powersj> ok thanks for checking!
<cyphermox> once it's done building I'll take the mini.iso to make sure things are good :)
<jbicha> LocutusOfBorg: yes (in FL) but I'm ok
<jbicha> sil2100: yes I intend to disable them again since they're still flaky even with a few changes
<sil2100> jbicha: thanks!
<xnox> cjwatson, yeah i couldn't get start-stop-daemon to do something sensible under systemd either. i think stuff interferes because there is init.d and systemd unit but i gave up. It should just work, but i'm not sure how wide spread the problem is. And I'm sure the real answer here is to do use "systemd-run" which is equivalent of "run a one-off managed service"
<xnox> hm, i wonder if start-stop-daemon should really actually use systemd-run on systemd machines.
<sarnold> oh god the abstractions upon abstractions ..
<xnox> sarnold, it's not over until one embeds src:linux src:systemd src:network-manager!
 * sarnold cries quietly in the corner
<xnox> sarnold, at least one no longer needs to embed openssl, as src:linux does that now.
<sarnold> hahahaha
#ubuntu-devel 2017-09-12
<kklimonda> is there a way to add a conditional dependency for package - I basically need something akin to a  custom ${supervisor:Depends} that will expand when supervisor files are added to the binary package.
<kklimonda> ah, that's just a gencontrol call
<Unit193> ...Something like https://anonscm.debian.org/cgit/collab-maint/deluge.git/commit/?id=9cfa3119e5fb90eaa1cbf8285eb85aa2b16ed700 ?
<sil2100> Hey! Who's administering ubottu ?
<sil2100> We have a new DMB member so we'd like to update the dmb-ping command
<cpaelzer> jbicha: cyphermox: congratulations
<Unit193> sil2100: Doesn't take an admin to do that.
<sil2100> Unit193: who can do that then?
<Unit193> sil2100: I can for one. :P
<sil2100> \o/
<sil2100> Unit193: could you swap infinity with jbicha then?
<sil2100> Thanks!
<Unit193> !dmb-ping is <sed> s/infinity/jbicha/
<ubottu> I'll remember that Unit193
<Unit193> sil2100: Has Mica been seen at all, btw?
<sil2100> Unit193: you mean, on the DMB meetings?
<Unit193> sil2100: Sure, though I was thinking anywhere at all.
<acheronuk> ooh. congratulations to new and returning DMB members
<sil2100> Unit193: he's frequent on every DMB meeting now, so yeah, he's around ;)
<Unit193> \o/
<cjwatson> xnox: start-stop-daemon isn't meant to involve init scripts at all; it's a layer down.  It should be pure process-handling mechanics.
<Unit193> LocutusOfBorg: Ah there you are.  Thanks!
<kklimonda> can I use debuild to generate .orig.tgz of a non-native package?
<cjwatson> the orig is an input to debuild, not an output from it
<cjwatson> (or should be, anyway)
<Unit193> Unless he's referring to it "missing" from the dsc, thus needing '-sa'
<cjwatson> dpkg-source does have some options to generate it for some source formats in some situations, but best to read "man dpkg-source" for those.  (debuild passes the relevant options through to dpkg-buildpackage which passes them through to dpkg-source)
<cjwatson> also debuild --source-option=...
<LocutusOfBorg> :) you are welcome
<cpaelzer> Typo "Ubunhtu" in the community council election makes it appear like phishing :-/
<cpaelzer> The mails are out, but is there a way to at least edit the poll on the site maybe?
<ginggs> doko: I see lapack and atlas syncs/merges, thanks.  I think openblas needs a sync as well; shall i do it?
<doko> ginggs: sure
<LocutusOfBorg> jbicha, congrats!
<doko> ginggs: why is openblas not built on s390x? it has optimizations there as well
<sil2100> cjwatson: hey! We have an AA-related question, I have approved the uefi binaries for an artful kernel from the UNAPPROVED queue but we can't seem to see those appearing in http://archive.ubuntu.com/ubuntu/dists/artful/main/uefi/linux-amd64/ yet
<sil2100> cjwatson: did I miss a step? I never did that for artful - probably shouldn't, but since I do this for stable series I thought I'd give it a try since Andy is away
<sil2100> Is it just the publisher being busy?
<sil2100> cjwatson: nvm! We see it in artful-proposed now, just took a bit longer I guess
<cjwatson> sil2100: Indeed, I was just going to say that I would expect it in artful-proposed and not in artful if it hasn't got past p-m yet.
<ddstreet> bdmurray can you review and sponsor the artful patch for lp #1657256
<ubottu> Launchpad bug 1657256 in percona-xtradb-cluster-5.6 (Ubuntu) "Percona crashes when doing a a 'larger' update" [Medium,In progress] https://launchpad.net/bugs/1657256
<ddstreet> rbasak was reviewing it, but he is out this week
<ddstreet> sil2100 or micahg could either of you ^
<coreycb> bdmurray: hi, can you take a look at promoting nova to zesty-updates?
<bdmurray> coreycb: sure
<bdmurray> ddstreet: that package seems more like a server team package. and what is your relationship with the patch?
<ddstreet> bdmurray i'm asking for niedbalski who is working on it and created the patch
<ddstreet> bdmurray would be great if you could review and sponsor since rbasak is out
<bdmurray> ddstreet: I'm not familiar with that package and think a server team member might be a better position to review it. Have you pinged any of them?
<ddstreet> bdmurray ok i'll find someone else to review it, thnx
<bdmurray> ddstreet: If you don't find anybody in a timely fashion let me know, I just think somebody else might be a more efficient choice.
<ginggs> doko: ah, well spotted!  debian bug #875618 filed
<ubottu> Debian bug 875618 in src:openblas "openblas: please enable build on s390x" [Wishlist,Open] http://bugs.debian.org/875618
<lamont> if I start with (artful) ubuntu-server install, and insatll ubuntu-desktop, presumably a login screen should come up?  or did I miss a step?
<slangasek> ok why does debuild now give me nonsense warnings about "Ubuntu merge policy"?
<juliank> slangasek: oh, what does it say?
<slangasek> WARNINGS generated by debuild:
<slangasek> Ubuntu merge policy: when merging Ubuntu packages with Debian, -v must be used
<slangasek> Ubuntu merge policy: when merging Ubuntu packages with Debian, changelog must describe the remaining Ubuntu changes
<slangasek> juliank: ^^ on an upload which is not a merge, it's an introduction of a new delta
<juliank> ah
<juliank> That's kind of a corner case I'd say
<juliank> lamont: It probably should, it depends on gdm3
<lamont> juliank: gdm3 says it's running, but nothing on tty7 or 8..  syslog cruft on tty1, and login screens otherwise.
<lamont> rather, systemctl status says gdm3 is running
<sarnold> lamont: I understand they moved the graphical screen. try all the ttys.
<lamont> sarnold: 1-6 are ttys, the rest are boringly not helpful
<sarnold> :(
<lamont> GeForce GTX 750 Ti -- fwiw, the early artful livecd loved it just fine
 * lamont purges the proprietary driver
<lamont> "Started Update UTMP about System Runlevel Changes."  and then crickets
<lamont> hilariously, gdm3 is running with a gdm-session-worker child, but no X server is running
<jibel> lamont, is the login screen running wayland?
<sarnold> lamont: do you bychance have multiple outputs on the card? I wonder if it's runnign on a non-existent monitor? that'd be a genuine linux experience :)
<lamont> jibel: stocck ubuntu-server install + apt-get install ubuntu-destkop.  no login sreen that i'm seeing at all
<lamont> sarnold: dual output (DVI & hdmi) which is happily mirroring the output
<lamont> the livecd happily went dual-screen
<lamont> having said that, there is a vga output
 * lamont digs up a vga cable
<lamont> jibel: gnome-session-wayland is not installed, fwiw
<lamont> sarnold: all 3 poutputs are showing the same output
<sarnold> lamont: :(
<sarnold> well, that's probably best. but still :(
<jibel> lamont, the livecd uses X while an artful installation uses wayland. and it doesn't work really well with nvidia
<jibel> lamont, cf bug 1705369 for example
<ubottu> bug 1705369 in gdm3 (Ubuntu) "Ubuntu 17.10 boots to black screen when using Nvidia drivers (on a desktop with an Intel GPU)" [High,Confirmed] https://launchpad.net/bugs/1705369
<lamont> jibel: that would be likely -- is it trivial to switch back"
<jibel> if it's your case, you can force X in gdm in /etc/gdm3/custom.conf
<jibel> lamont, in the section [daemon] set WaylandEnable=false
<lamont> uncommented, rebooted (because hey..), still no happy
<jibel> :/
<lamont> and  /var/log/dm3 is empty
<jibel> logs are in the journal, journalctl -u gdm
<jibel> the debug mode may give some hints too
<lamont> a couple glib assertion failures, otherwise bring
<lamont> "waiting for user manager otload before finding user 'gdm'"
 * lamont needs to run off for a bit
 * lamont goes down the "enable lightdm" path
<lamont> and that path provided happiness
<lamont> other than me wanting gdm
<bdmurray> andyrock: Do you have livepatch stuff needing sponsorship for SRUs?
<bdmurray> andyrock: I've lost track of the status of that work.
<andyrock> Hey
<andyrock> Not yet
<andyrock> I'm blocked on software-uodates
<andyrock> Waiting for some API to be ready
<bdmurray> andyrock: Okay, cool. I think I'm the best person to sponsor it given I reviewed the artful work so give me a ping when you have something.
<andyrock> Sure thing. Thank you!
#ubuntu-devel 2017-09-13
<kklimonda> are there any examples of using debian/[package].install.in and generating it on a fly?
<kklimonda> I've found only virtualbox so far
<LocutusOfBorg> kklimonda, there are many
<LocutusOfBorg> what is the question?
<kklimonda> LocutusOfBorg: I'm thinking on how to generate .install files from .install.in during build using snippet from https://wiki.debian.org/Multiarch/Implementation (multiarch is not related, but the way install files is generated seems pretty clean). I've assumed that some target (binary, binary-arch?) will have an implicit dependency on debian/*install files and call target that builds them automatically but that does not seem to be
<kklimonda> the case.
<LocutusOfBorg> look at llvm-toolchain-5.0
<cpaelzer> hmm, did anybody get a new bug number our of submit@bugs.debian.org yet?
<cpaelzer> I mean this morning like the last 3 hours or so
<cjwatson> kklimonda: Nowadays it's usually easier to use dh-exec, FWIW
<LocutusOfBorg> cjwatson, he is talking about something different that multiarch implementation, not sure if dh-exec does the job
<cjwatson> LocutusOfBorg: Sure.  But it's worth looking at.
<LocutusOfBorg> meh, it is already mentioned in that wiki, I presume he read it all already :)
<kklimonda> cjwatson: dh-exec requires debhelper > 9, and should work with trusty, right?
<tjaalton> doko: err, you removed dogtag & freeipa from release?
<tjaalton> actually, that's fine
<tjaalton> one less release to worry about
<tjaalton> it's not clear the port to tomcat8.5 is done before 18.04 is out
<cjwatson> kklimonda: haven't checked recently, but I'd expect so
<LocutusOfBorg> kklimonda, it should be
<LocutusOfBorg> does anybody have an answer for this systemd issue?
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/virtualbox-hwe/+bug/1708315
<ubottu> Launchpad bug 1708315 in virtualbox-hwe (Ubuntu) "package virtualbox-guest-utils-hwe 5.0.40-dfsg-0ubuntu1.16.04.1~16.04.3 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Incomplete]
<LocutusOfBorg> Setting up virtualbox-guest-utils-hwe (5.0.40-dfsg-0ubuntu1.16.04.1~16.04.3) ...
<LocutusOfBorg> insserv: script virtualbox-guest-utils-hwe: service vboxguest already provided!
<LocutusOfBorg> damn they conflict each others
<juliank> rbalint: What's that "apt_1.2.25-rbalint2" I just read about? There is no apt 1.2.25 yet. It will come in about 2 weeks, though, I'd say (not only the u-u fix, but also the "my boot is so slow" and "downloads don't work directly after resume" one). I guess I should push out a new apt 1.5~rc4 now with the final fix for the latter two, though
<juliank> My goal was to have the final apt 1.5 for the final beta, and then do 1.4.8 and 1.2.25 releases based on that
<juliank> But we could also do an earlier run with just the unattended-upgrade fix if needed
<juliank> All I wanted to say is: Don't play with upstream version numbers :D
<rbalint> juliank: it is in my ppa we used for testing fixes for LP: #1690980
<ubottu> Launchpad bug 1690980 in OEM Priority Project "unattended-upgrades does not block shutdown of system, as it is designed to" [Critical,Triaged] https://launchpad.net/bugs/1690980
<juliank> rbalint: I don't see it in your scratch PPAs, but it really should be 1.2.24<something>, not 1.2.25<something>
<juliank> increasing upstream version numbers is reserved to upstream :D
<juliank> Otherwise it gets confusing ;)
<rbalint> juliank: the actual version was 1.2.25~rbalint2 to ensure upgrade, but yes, i should have used 1.2.24<sg>
<juliank> There's some other great fixes in 1.5, like the one for bug 1701852, but I think we probably won't see this in xenial, it might be too invasive
<ubottu> bug 1701852 in apt (Ubuntu) "(xenial+) apt-cache fails to run if a single sources.list.d entry is not readable" [Low,Fix released] https://launchpad.net/bugs/1701852
<juliank> rbalint: In practice it's sort of OK as long as it's lower than ~rc (which land in the apt PPA occasionally)
<juliank> in case you want to test that :D
<juliank> rbalint: SRUs are currently mostly blocked because 1.4.6~17.04.1 is waiting in zesty-proposed waiting to be released. 1.4.7 is already released in stretch, and should probably be sinked, but we could also just pick the u-u fix on top of that and release that as 1.4.8 (and 1.2.25).
<juliank> See bug 1702326
<ubottu> bug 1702326 in apt (Ubuntu Zesty) "New microrelease 1.4.7 for zesty" [Medium,Triaged] https://launchpad.net/bugs/1702326
<juliank> I guess it mostly depends on how fast we want to push out the apt-daily timer changes
<juliank> xnox: Did you hear anything about the boot speed situation relaxing in artful now? For most boots (where we don't need to "catch up") it already should have, but with the next apt upload, all boots should be fixed.
<juliank> You mentioned reports about slow boots yesterday or the day before, but since there are no bugs about that in LP, I figured it's probably something internal
<xnox> juliank, there are bugs about it.
<xnox> juliank, they are all filed against src:systemd
<juliank> xnox: oh
<xnox> juliank, however i will not look into that this week =/ due to other things
<juliank> Oh well, I'm building 1.5~rc4 now, it should sync later today
<juliank> At least I will, if I find my smart card
<juliank> and if I can get gpg to work again
<juliank> It's like a wild loop of killing scdaemon and running gpg --card-status until it works
<Unit193> Check out in the car.
<juliank> so, the, like, 20th try seems to have worked :)
<rbalint> juliank: looking at apt 1.4.6~17.04.1's changelog i don't see an SRU LP bug where you could provide the verification feedbeck thus it may be stuck in https://wiki.ubuntu.com/StableReleaseUpdates#Procedure step 6.
<juliank> rbalint: I know there's no overall bug, but we have lots of tiny ones, and most of the changelog entries are actually just fixes up for one of them.
<juliank> rbalint: It was stuck until shortly because one bug was not verified, and yesterday sbuild needed to go in first to fix an autopkgtest regression.
<rbalint> juliank: ok, it was not clear why apt was stuck in -proposed
<juliank> And I think it's getting a bit close to weekend now to release an apt SRU of this impact
<juliank> So I was thinking I'd push hard again on Monday
<juliank> or rather s/push hard/ask/
<juliank> rbalint: The weird part is that the same changes are already in xenial-updates
<juliank> Because xenial is more important :D
<rbalint> juliank: maybe getting SRU Team's agreement in advance to release on Monday could work, too
<juliank> I mean, it's all verified, (almost?) all of it is in xenial, and I'm here to answer any remaining questions from 10:00 to 22:00 UTC every day
<juliank> slangasek did the sbuild stuff yesterday at least
<juliank> See, I'm not entirely sure about close-to-weekend SRUs. IIRC, something was up with Thursday.
<juliank> There's no written policy on days where no updates are released AFAIK
<juliank> or maybe it was just security updates?
<slangasek> the policy is that we don't release SRUs on Friday unless the person releasing is willing to come in on a Saturday
<slangasek> apt+unattended-upgrades can now be released
<juliank> yay!
<slangasek> (done)
<juliank> slangasek: thanks
<nacc> i thought that used to be on the SRU page itself, but I can't find it anymore
<rbalint> slangasek: thanks!
<rbalint> juliank, slangasek: the next round can be the stability fixes for u-u with apt's cooperation
<juliank> rbalint: I'd put them on top of the https://tracker.debian.org/news/856567 release, does that sound fair?
<juliank> It should have been in proposed a month ago basically
<rbalint> juliank: thanks, this is perfect
<nacc> is there a programmatic way to ask dpkg-buildpackage what files it will create, if successful (or have it clearly output what files it did create)?
<juliank> Should we pull in this too? https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=11417c1058e1b8441ee8f30f948e854b7a6ce89e - That's the entry to more changes affecting apt-daily ordering, it already solves most problems with stalled boots by just moving the dependencies from the timer to the service (which might not start during boot, hence not pull in the network-online.target which causes weird behaviour in rc.local)
<juliank> And probably bug 1613184
<ubottu> bug 1613184 in apt (Ubuntu) "method mirror broken at 1.3" [Medium,Fix released] https://launchpad.net/bugs/1613184
<juliank> mirror just segfaults...
<juliank> Let me go cherry-picking
<juliank> I don't have a LP bug for the ordering though, but I'm not sure what you'd want to verify there
<juliank> Oh I guess we should pull in bug 1697120 too
<ubottu> bug 1697120 in apt (Ubuntu) "artful's apt-file and aptitude complains about Ubuntu sources.list" [Medium,Fix released] https://launchpad.net/bugs/1697120
<juliank> It simply wraps the warning in a		if (T->find("legacy") == std::string::npos)
<juliank> So far against 1.4.7: https://anonscm.debian.org/cgit/apt/apt.git/diff/?h=1.4.y&id=1.4.y&id2=1.4.7
<nacc> cjwatson: I was re-reviewing LP: #1687059, I believe you originally pointed this out to rbasak and myself. But then I'm reading `man dpkg-buildpackage` (http://paste.ubuntu.com/25528503/) and I'm wondering if a) we don't need actuall need the b-d for clean? or b) if `man dpkg-buildpackage` is wrong?
<ubottu> Launchpad bug 1687059 in usd-importer ""git ubuntu build-source" does not run debian/clean" [High,Triaged] https://launchpad.net/bugs/1687059
<nacc> slangasek: --^ you might also have an opinion/relevant knowledge
<cjwatson> nacc: I'm not sure where that assertion comes from.  At a minimum, the clean target nearly always requires debhelper, which (regardless of one's opinion on whether it should be) is not build-essential, and it often also requires other build-dependencies for extra helpers.
<juliank> I guess we let xnox and slangasek decide whether to pull in the move of Wants,After=network-online.target from apt-daily.timer to apt-daily.service. As I wrote, this should solve a lot of the slow boot problems because network-online is not pulled in anymore unless we skipped an apt update while the machine was offline. Then we can let the more improved variant test in artful for some time.
<nacc> cjwatson: yeah that's what I figured too, based upon what I've seen
<nacc> cjwatson: thanks for the input!
<cjwatson> nacc: I think this is a slightly mangled version of the assertion that if you have a tree that hasn't been built then you can use dpkg-source to construct a source package *without* calling the clean target.  (There exist packages that use the clean target to generate files that have to be in the source package, but that wouldn't be a problem if the importer has taken a source package as its ...
<cjwatson> ... input.)
<nacc> cjwatson: right, I could see that
<cjwatson> Robie's suggestion there seems reasonable to me.
<nacc> cjwatson: yep, i think that's what we're going to end up doing (it's nice to have anyways)
<nacc> cjwatson: smoser has already heckled us for trying to do buildd locally basically :)
<cjwatson> I mean, I agree that it's awkward that clean is the way it is ...
<juliank> I'm just writing a bug to track the network-online move
<slangasek> juliank: oh, untangling apt-daily from boot in the common case sounds like a valuable improvement
<juliank> slangasek: Added https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1716973 for that
<ubottu> Launchpad bug 1716973 in apt (Ubuntu Zesty) "Don't pull in network-online.target in apt-daily.timer" [High,Triaged]
<slangasek> cool
<juliank> We can then take the more complete fix, which also makes stuff more reliable at resume, in a month
<rbalint> slangasek: we had a few discussions with mvo regarding unattended-upgrades. how would you feel about full backports of 0.96ubuntu1 to older releases instead of cherry-picking most of the fixes?
<rbalint> slangasek: this seems to me safer and easier to maintain in the long run
<powersj> cyphermox: looks like your fix went in, ISOs are green again, many thanks!
<jbicha> why is network-online required for getty and gdm?
<juliank> jbicha: It's not, rc-local.service is
<jbicha> what is rc-local and why does that need network-online?
<juliank> jbicha: But on debian & ubuntu, we have an override at the moment where rc-local.service specifies After=network-online.target
<slangasek> rbalint: I would have to look at specifics to give a definitive answer, but in principle I'm not opposed
<jbicha> (boot took several minutes yesterday when I didn't have a good network connection)
<juliank> jbicha: See https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1451797 for the discussion. pitti and mbiebl reached consensus to remove that with a warning in NEWS in #debian-system yesterday.
<ubottu> Launchpad bug 1451797 in systemd (Ubuntu) "rc.local should require network-online.target" [Low,Fix released]
<slangasek> rc-local is a legacy interface that lets users run miscellaneous code at end-of-boot.
<juliank> indeed.
<juliank> And if /etc/rc.local is present, the service is enabled and will be ordered after network-online.target if something else pulls it in.
<slangasek> if we stopped shipping /etc/rc.local by default, or made it non-executable by default, there would be no penalty
<slangasek> ConditionFileIsExecutable=/etc/rc.local
<juliank> Which unfortunately I did in apt's timer.
 * juliank does not have /etc/rc.local
<juliank> Same applies if you have a legacy init script using $network
<slangasek> maybe we no longer create rc.local and this only affects users who upgraded
<juliank> it might, who knows...
<juliank> On Debian, initscripts seems to create the file in postinst
<juliank> if that's not installed anymore, than there should be no file
<slangasek> yeah, I only have it on Ubuntu systems where initscripts is or has been installed
<jbicha> I believe I am using a fairly clean artful install from 2 weeks ago
<slangasek> we should consider cleaning that up on upgrade
<jbicha> initscripts is not installed here
<slangasek> jbicha: but if your system was a previous release and then upgraded, you did have initscripts installed before.
<slangasek> and /etc/rc.local is not (can't reasonably have been) a conffile
<jbicha> I don't have an /etc/rc.local ?
<juliank> slangasek: I'm afraid there is no way to clean this up? But when the rc-local drop-in unit is gone, this won't happen anymore anyway
<slangasek> jbicha: then rc-local.service shouldn't have slowed down your getty, because ConditionFileIsExecutable=/etc/rc.local
<slangasek> juliank: sure there is a way; we have ubuntu-release-upgrader for quirks
<juliank> slangasek: Yeah, well, but you have to check that it was not modified, whatever that means
<juliank> "Oh, I commented out my rc.local for the upgrade, but now it's gone"
<juliank> "there was important stuff in there"
<slangasek> checksum tools are great ;)
<slangasek> but also, I see rc-local to be 'After=network.target', which is NOT network-online
<slangasek> oh you said there was an override
<slangasek> ignore me
<slangasek> juliank: LP: #1716979
<ubottu> Launchpad bug 1716979 in ubuntu-release-upgrader (Ubuntu) "clean up unmodified /etc/rc.local on upgrade" [Undecided,New] https://launchpad.net/bugs/1716979
<juliank> yay
<slangasek> and I've subscribed xnox because I know his weakness for fixing such things
<slangasek> ;)
<juliank> lol
<xnox> slangasek, t...
<xnox> slangasek, true
<slangasek> :D
<slangasek> xnox: what's the systemd task on that bug?  are you thinking to have systemd remove /etc/rc.local instead of u-r-u?
<juliank> https://paste.ubuntu.com/25528880/
<juliank> ^ apt 1.4.7 to 1.4.8
<juliank> I'll now ask the RT over in Debian what they think
<juliank> It will hit zesty either way tomorrow :D
<xnox> slangasek, yes
<slangasek> xnox: ok; it should certainly be an either-or, so let's close the other task
<slangasek> (done)
<juliank> I guess something should remove initscripts too, or is that already handled?
<slangasek> nothing conflicts with it, but it may get autoremoved by u-r-u
<juliank> If someone wants to track the Debian 1.4.8 stretch update, here's the bug: https://bugs.debian.org/875695
<ubottu> Debian bug 875695 in release.debian.org "stretch-pu: package apt/1.4.8" [Normal,Open]
<juliank> slangasek: Hmm, does something break if changes has Distribution: zesty-updates? Apparently syncpackage --no-lp needs that, otherwise it packs all changes against the original 1.4?
<juliank> Although, I can just edit that
<cjwatson> It's either mapped to zesty-proposed or rejected, I forget which
<cjwatson> I'd probably edit it
<juliank> Yeah, I also had to edit Changed-By and the changelog anyway, it was picking up 1.4.6 again because well, we uploaded it as 1.4.6~17.04.1
<juliank> And Changed-By was root, because apparently my schroot is messed up
<bmw> rbasak: what's the status of getting the Certbot packages for Xenial into the proposed repo?
<slangasek> bmw: AIUI https://bugs.launchpad.net/ubuntu/xenial/+source/python-letsencrypt/+bug/1640978 shows they're all in -proposed and waiting for testing feedback
<ubottu> Launchpad bug 1640978 in python-certbot-nginx (Ubuntu Zesty) "[SRU] Backport letsencrypt 0.14.2" [Undecided,Fix committed]
<nacc> bmw: yeah, i think it's all pending on testing and baking long enough
<nacc> bmw: note rbasak is out all this week and some of next
<bmw> at least when using apt, I don't see any certbot or letsencrypt packages in the proposed repository
<bmw> I see python-acme, but not the main client and the Apache and Nginx packages
<nacc> !info python-certbot xenial-proposed
<ubottu> Package python-certbot does not exist in xenial-proposed
<nacc> bmw: hrm, rmadison says they are there
<nacc> oh wait
<nacc> only the source
<bmw> rbasak told me a couple weeks ago there a build failure for the old letsencrypt packages that he was going to look into
<bmw> that's probably what's going on
<nacc> ah they are still waitinng to be accepted
<nacc> https://launchpad.net/ubuntu/xenial/+queue
<nacc> slangasek: --^ i see a message from you that they were accepted though
<slangasek> ah, are the binaries still in NEW?
<slangasek> only for python-certbot
<slangasek> accepted
<nacc> slangasek: yeah, thankns
<Unit193> Oh, my backport of 0.11.1 is pretty old.
<cyphermox> powersj: thanks for the feedback
#ubuntu-devel 2017-09-14
<Unit193> 'Start in 12 hours'  Geez, who uploaded KDE again?  Thanks for the geoip-database sync.
<valorie> Unit193: KDE is the community, LOL
<valorie> what was re-uploaded?
<cjwatson> Unit193: Not so much KDE, more that we're in the middle of redeploying one of the builder clouds.
<cjwatson> I'm only noseyparkering it but it looks like it should be done soon.
<doko> xnox: how much do you care about gcc-arm-linux-androideabi ?
<doko> hmm, and we have u-boot-linaro depending on gcc-4.7
<xnox> doko, i thought it should be removed, once all the reverse deps are gone... no? cause it is ubuntu only package?
<doko> yes, I would like to see it removed
<xnox> doko, filed RM bug for android and gcc-arm-linux-androideabi -> https://bugs.launchpad.net/ubuntu/+source/gcc-arm-linux-androideabi/+bug/1717229
<ubottu> Launchpad bug 1717229 in android (Ubuntu) "RM: obsolete product" [High,Triaged]
<doko> do we know about u-boot-linaro?
<xnox> that one is from 2012, just u-boot is from 2016.03 in ubuntu, and it is 2017.09 in debian experimental
<xnox> (2017.07 in unstable)
<xnox> ppisati, would you at all know if we use u-boot-linaro anywhere in ubuntu still? or is our u-boot package good enough for everything / everything got upstreamed?
<xnox> opened RM bug for u-boot-linaro
<xnox> https://bugs.launchpad.net/ubuntu/+source/u-boot-linaro/+bug/1717232
<ubottu> Launchpad bug 1717232 in u-boot-linaro (Ubuntu) "RM: duplicate package" [High,Triaged]
<xnox> doko, is reverse-depends failing to parse deps, or does gcc-5-cross and gcc-6-cross really do build-depend on binary packages from gcc-4.7-armel-cross and gcc-4.7-armhf-cross
<doko> no, they should not
<doko> I think I never rebuilt these cross packages after introducing newer versions, so maybe the control file still has them?
<xnox> doko, i think that reverse-depends is simply confused.
<xnox> hm
<ppisati> xnox: uhm, as far as i know, we don't use u-boot-linaro anywhere
<ogra_> i think that came from the linaro mx5 images that we used to build in 12.04
<ogra_> long dead
<xnox> doko, both src:gcc-4.7-armel-cross and src:gcc-7-cross build libhfgcc1-armel-cross however for some reason $ reverse-depends picked the one with lower version number, rather than higher version.
<juliank>  rbalint: I believe unattended-upgrades.service should gain a Before=apt-daily.service, so that when shutting down, and apt-daily.service is already running, unattended-upgrades.service stops after it.
<juliank> um, apt-daily-upgrade.service too
<juliank> A Before=B essentially means that A is stopped after B
<juliank> slangasek: I noticed that if we ever do an apt security update, we also have to move unattended-upgrades to security, especially if we add a versioned dep on a u-u with --download-only support; otherwise the security update would not install automatically (as u-u would not pull in the new u-u from updates)
<juliank> for xenial / zesty
<juliank> Or well, let's hope it does not come to that in the near future, and build in a work around in apt
<rbalint> juliank: why do you believe that ordering is needed?
<rbalint> juliank: AFAIK recent apt-s do only downloads in apt-daily.service thus it can be killed without any consequence
<juliank> rbalint: See second line
<juliank> I actually meant apt-daily-upgrade.service
<juliank> It's unclear if it's needed, but it seems like a good idea. Locking is a bit racy in some parts still, and AFAIUI, apt-daily-upgrade does not run to completion, so if you have this set, you'd want u-u.service to run after it to complete the task?
<juliank> Otherwise, u-u.service might run while apt-daily-upgrade is running, and fail trying to get the lock, and won't run any remaining upgrades.
<juliank> It's relatively unlikely too happen, probably, but still seems like a good idea
<rbalint> juliank: depending on InstallOnShutdown = true or not u-u.service or apt.*service will perform the upgrade
<rbalint> juliank: there is no case when both can upgrade, thus there is no case for taking over
<juliank> Let's say you have 64 updates to install.
<juliank> apt-daily-upgrade.service is running, but you shut down. It exits after 16 updates.
<juliank> What happens to the remaining 48 ones?
<juliank> or do you say apt-daily-upgrade.service will not run at all when Unattended-Upgrade::InstallOnShutdown is set
<juliank> ?
<rbalint> u-u.service shuts down the upgrade and does not take over
<rbalint> juliank: the service will run, but u-u stops when calling from apt's service
<rbalint> juliank: https://github.com/mvo5/unattended-upgrades/blob/master/unattended-upgrade#L1535
<juliank> aye, then it's fine
<rbalint> juliank: https://github.com/mvo5/unattended-upgrades/blob/master/unattended-upgrade-shutdown#L134
<juliank> sorry about the confusion
<rbalint> juliank: no problem, this was not clear to me before diving into u-u code :-)
<juliank> There's still some other maintenance cleanup crap done in apt-daily-upgrade.service if the options are enabled
<rbalint> juliank: if you find something racy in u-u please report it, because i'd like to make it rock-solid
<juliank> Well, the other stuff we do is running clean and autoclean after u-u if the options are set. But then, if you use install on shutdown, they simply are not compatible.
<juliank> I should push guillem about the whole frontend lock to get any remaining lock race conditions fixed.
<rbalint> juliank: from not breaking the system POV they are safe https://anonscm.debian.org/git/apt/apt.git/tree/debian/apt.systemd.daily#n507
<juliank> indeed, that they are.
<juliank> But don't enable them together or there will be no packages left to install on shutdown :D
<juliank> or well, u-u will redownload them
<rbalint> juliank:yes, it will redownload
<rbalint> juliank: if there are still upgrade-able packages apt could keep the cache
<juliank> rbalint: Well, that's what happens if you only use autoclean :)
<juliank> Just don't set the option to run clean :D
 * juliank should drop that option probably
<juliank> Although maybe some people do really need an option to regularly delete all cached packages, who knows.
<juliank> (like, they have a fast local mirror and don't bother with caching)
<rbalint> juliank: by default InstallOnShutdown is false thus the default apt service works as expected with either clean or autoclean
<juliank> true, and they are off by default too. it was mostly just a funny remark
<doko> slangasek: your libhybris upload ftbfs
<doko>         * malloc/malloc.c (cfree): Turn into compat symbol.
<doko>         (__cfree): Remove alias.
<doko>         * stdlib/stdlib.h (cfree): Remove declaration.
<doko>         * malloc/malloc.h (cfree): Likewise.
<doko>         * manual/memory.texi (Freeing after Malloc): Remove cfree.
<doko> can't find the vwrite change ...
<slangasek> doko: yes, already discussed that libhybris ftbfs with infinity on #ubuntu-release last night; and wondered if morphis__ would want to care about this
<doko> slangasek: I stand corrected about the inclusion of -proposed. it's possible. but I think we don't want it
<slangasek> doko: fwiw in this case I disagree; in general we always build with -proposed enabled in the main archive, and we know that there's almost nothing of relevance in -proposed right now that is both a build dependency and not targeted for release
<doko> slangasek: sure, but we empy -proposed for the release
<slangasek> doko: yes, but it's already pretty empty right now, compared to past releases... and I've said that we should be trying to drive -proposed to zero throughout the cycle, not just emptying it at release... so the delta in terms of ftbfs false-positives/negatives should be small here
<doko> pretty empty? cough ...
<cjwatson> doko: we have graphs of this stuff :-)  http://people.canonical.com/~ubuntu-archive/proposed-migration/history.html
<cjwatson> ah, hmm, but that's only for this release
<cjwatson> not quite the proof I was looking for
<pitti> Laney: you restored the second cloud yesterday or today, right? are you aware of any configuration chagnes that could explain failures like https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-pitti-systemd-semaphore/xenial/amd64/s/systemd-upstream/20170914_160700_910ad@/log.gz ?
<pitti> Laney: exact same xenial cloud image as in a successful run from two days ago, same downstream packages, tests with that PR's debs work  locally
<pitti> Laney: ah, nevermind, got it reproduced
#ubuntu-devel 2017-09-15
<stgraber> xnox: https://bugs.launchpad.net/ubuntu/+source/nplan/+bug/1717404 FYI
<ubottu> Launchpad bug 1717404 in nplan (Ubuntu) "IPv6 support regresses with nplan transition" [High,New]
<stgraber> xnox: going to revert from nplan back to ifupdown in LXC upstream in a couple of days if we can't get this fixed quickly as that's breaking our tests and is inconsistent with all other Linux distros
<stgraber> cyphermox: ^
<mwhudson> stgraber: huh
<mwhudson> that doesn't match my understanding of what networkd would do :/
<mwhudson> presuming netplan doesn't write out any setting for IPv6AcceptRouterAdvertisements= anyway
<stgraber> mwhudson: yeah, I'm kinda surprised by that behavior too
<stgraber> mwhudson: netplan writes IPv6AcceptRA=no
<stgraber> mwhudson: so that explains it and confirms it's netplan's fault
<stgraber> mwhudson: commented in the bug with the generated networkd config
<mwhudson> stgraber: only if configured as a bridge or a bond?
<mwhudson> hm my checkout is probably stale
<mwhudson> stgraber: oh heh https://bugs.launchpad.net/maas/+bug/1655440
<ubottu> Launchpad bug 1655440 in nplan (Ubuntu Xenial) ""unconfigured" NIC can still get IPv6 addresses via RA" [High,In progress]
<mwhudson> you can't win...
<doko> LocutusOfBorg, ginggs: looks like beignet julia pocl still use llvm-3.8. If we can't fix that, we have to look at the test hangs on armhf
<Laney> pitti: phew!
<pitti> Laney: good morning!
<Laney> hey pitti, happy friday! how are you?
<pitti> Laney: bon vendredi Ã  toi aussi :) I'm great, thanks! yourself?
<pitti> finally, some sun again \o/
<Laney> pitti: very well also!
<Laney> not much sun here though - autumn is coming...
<Laney> pitti: oh, did you see that we think we found out why those meson hangs were happening?
<pitti> Laney: ooh! no, I didn't
<Laney> just noticed that your test still uses the branch with boot-smoke disabled
<Laney> xnox fixed it in master I think
<pitti> yes, it's been a while since I looked into that
<pitti> xnox: yay you! what was it, OOI?
 * Laney feeds hamsters to alioth
<Laney> https://anonscm.debian.org/git/pkg-systemd/systemd.git/commit/?id=6bd0dab41e720a297068a0600b121deb86ec5d1f
<pitti> Laney: I just threw ~ 10 test retries against the infra for cleaning up after the regression in master (what I pinged about yesterday); but once that dust settles, I'm happy to re-run a test on amd64 against master
<pitti> Laney: oh wow, *that* causes tempfails?
<Laney> some backgrounded process was being killed when we closed the SSH connection
<Laney> so the failure would have been specific to the ssh runner
<pitti> that explains why it was fine locally with qemu
<pitti> in retrospect it probably would have been better to just always make autopkgtest use ssh, and write the various virt backends as ssh setup scripts
<pitti> hm, doesn't work with null/chroot/schroot, though
<ginggs> doko, LocutusOfBorg: julia 0.5 and 0.6 upstream are still on llvm-3.9
<doko> ginggs: but we build using 3.8
<Laney> ah yes, this bit: https://anonscm.debian.org/git/autopkgtest/autopkgtest.git/tree/lib/VirtSubproc.py#n340
<ginggs> doko: yeah, we still have julia 0.4
<doko> ahh, ok
<ginggs> i mean i can't even quickly pull in a new upstream to jump to a new llvm
<ginggs> and there's some licensing issue with libgit2
<doko> ok, trying to build on a porter box
<pitti> Laney: thanks for https://code.launchpad.net/~pitti/autopkgtest-cloud/+git/fixes/+merge/330743 ! FYI, this is something that you use locally, not on the infra
<pitti> (wrt. "deployed")
<Laney> pitti: oh, hah
<Laney> I thought you were changing the error displayed on the web
 * Laney has never retried a github test
<LocutusOfBorg> doko, do you want to do ldc rebuilds? are you waiting for something else?
<doko> LocutusOfBorg: please do if you want. looking at the blas/atlas multiarch fun currently
<LocutusOfBorg> sure, thanks! I will do
<LocutusOfBorg> doko, ldc is broken https://github.com/ldc-developers/ldc/issues/2300
<doko> crap, why isn't tracked as a RC issue in Debian?
<doko> LocutusOfBorg: did all of your no-change upload fail?
<LocutusOfBorg> doko, that reason
<LocutusOfBorg> the maintainer opened the upstream issue :/
<LocutusOfBorg> why the hell a broken ldc migrated in the first place, with all the reverse-dependencies broken
<ginggs> doko: shark and python-scipy now ok, python-numpy still has an issue
<doko> ginggs: fixed in ubtunu4
<ginggs> doko: ah nice, thanks :)
<ginggs> i'll trigger the tests
<ginggs> (once it is published)
<linuxenko> Looking for maintainer >= xenial package of https://github.com/linuxenko/chkservice
<ginggs> linuxenko: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages but it would be better to file an RFP bug in Debian https://www.debian.org/devel/wnpp/ and an ITP bug is even better
<linuxenko> ginggs , thanks
<doko> LocutusOfBorg: why does llvm test x86 codegen on armhf? \o/
<ginggs> doko: python-numpy ok http://autopkgtest.ubuntu.com/packages/p/python-numpy/artful/ppc64el - tests are queued for the other arches
<doko> ginggs: \o/
<LocutusOfBorg> doko, I don't get what you mean :)
<doko> LocutusOfBorg: the llvm testsuite runs the x86 codegen changes on the armhf build
<LocutusOfBorg> don't really know...
<doko> ginggs: oops, removed the block-proposed from astroml too early ...
<cjwatson> slangasek: just out of interest have you folks started consuming ubuntu-image as a snap in livefs builds yet?  I know you wanted to
<ginggs> doko: and it looks like a loss of precision in python-scipy on i386 :(
<slangasek> cjwatson: not yet, no
<cjwatson> ok
<LocutusOfBorg> doko, FYI I'm fixing hhvm builds
<LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/13379719
<doko> already had
<cyphermox> stgraber: mwhudson: well, less damage in letting autoconf work alone, so I'm in favor of reverting
<cyphermox> stgraber: is there a way to integrate a test for this to the netplan autopkgtests so it doesn't happen again?
<stgraber> cyphermox: not sure how your autopkgtest works, but you should be able to fake an IPv6 router with radvd easily enough
<cyphermox> we already do, I'm meaning specifically integrated with lxd
<cyphermox> your use case in particular :)
<LocutusOfBorg> ok
<LocutusOfBorg> well, my patch was more upstreamable with one #ifndef LINUX or whatever
<LocutusOfBorg> but meh :)
<bmw> slangasek: it looks like there's one more Certbot related package that you said you approved waiting to be accepted
<bmw> https://launchpad.net/ubuntu/xenial/+queue
<ricotz> doko, hi, could gcc-mozilla in trusty moved to main? https://launchpad.net/ubuntu/+source/gcc-mozilla/4.9.4-0ubuntu1~14.04.1
<doko> ricotz: please ask the owner of the package
<doko> and the SRU team
<ricotz> doko, I was hoping this is no-brainer
<ricotz> chrisccoulson, hi, ^
<chrisccoulson> what's it needed for?
<ricotz> chrisccoulson, took me a while to notice this component mismatch, while building ff57 a "new" ppa
<chrisccoulson> you'll have the same issue with rust, which also isn't in main (and that's not in main anywhere)
<ricotz> hmm, right, while those still coming from ppas this issue doesnt present itself currently
<ricotz> what is the status of the rustc/cargo updates?
<chrisccoulson> it's not an issue in the archive after trusty either
<jbicha> shouldn't the ppa be set to allow universe build-depends?
<chrisccoulson> heh, rust
<chrisccoulson> the status with rust/cargo is that the rust tests still fail on ppc64, but work everywhere else. I just need to update cargo
<ricotz> jbicha, it was set to be restrictive on purpose, but yeah, I loosened it again
<ricotz> chrisccoulson, ok, cargo 0.20 is really needed
<chrisccoulson> yeah, I'm getting to it
<chrisccoulson> I'd be happy to never do another rust update again
<ricotz> chrisccoulson, https://launchpad.net/~ubuntu-mozilla-daily/+archive/ubuntu/firefox-aurora/+packages
<ricotz> I guess those rust updates will be required on a monthly basis :(
<doko> monthly rust releases?
<chrisccoulson> doko, yes, a new rust version is required for every firefox release
<chrisccoulson> it sucks
<doko> better start learning ...
<ricotz> fun: https://wiki.mozilla.org/Rust_Update_Policy_for_Firefox#Proposed_policy_update
<doko> chrisccoulson: you should bring up this topic at the ralley
<chrisccoulson> doko, yeah, I will ;)
<jbicha> ricotz: could you look into shipping a firefox-symbolic icon for vanilla GNOME? this is how Debian does it:
<jbicha> https://anonscm.debian.org/cgit/pkg-mozilla/iceweasel.git/tree/debian/rules?h=esr52/master#n365
<chrisccoulson> errr,  please don't touch anything branding related without first discussing it with me
<jbicha> and Fedora just ships its own .svg https://src.fedoraproject.org/rpms/firefox/tree/master
<jbicha> although it would be nice if someone would commit that directly to Mozillaâ¦
<jbicha> chrisccoulson: it's for the app icon in the GNOME Shell top bar. In the "Ubuntu" session, we are using full-color icons but upstream GNOME uses symbolic icons there
<ricotz> chrisccoulson, I guess I will leave that to you then?
<chrisccoulson> yeah, sure
<juliank> jbicha: In Debian, firefox seems to have no icon, or at least not a visible on (non-esr one)
<ricotz> chrisccoulson, this looks pretty self-explanatory https://paste.debian.net/plain/986259
<juliank> and all other apps have their normal colored icons
<juliank> (non-gnome apps)
<juliank> jbicha: Probably a bug, I see firefox-symbolic.svg but it is empty
<juliank> http://bugs.debian.org/867729 it seems
<ubottu> Debian bug 867729 in firefox "/usr/share/icons/hicolor/symbolic/apps/firefox-symbolic.svg: Symbolic icon file empty" [Normal,Open]
<jbicha> juliank: the firefox-esr icon looks fine to me in Debian Testing
<juliank> jbicha: ok, but it's definitely not working in the non-esr variant :D
#ubuntu-devel 2017-09-16
<LocutusOfBorg> xnox, interested in an ocaml transition?
<Unit193> Why and how is notification-daemon on every desktop?  Xubuntu doesn't want it.
<mitya57> Unit193, it is also a virtual package and xfce4-notifyd Provides: it.
<mitya57> So the ârealâ notification-daemon should not be pulled in.
<Unit193> Exactly...
<ahoneybun> has anyone seen this issue? gnome-software : Conflicts: sessioninstaller but 0.20+bzr150-0ubuntu4.1 is to be installed
<ahoneybun> running latest Artful
<TJ-> Is there a workaround for the USN-2639-1 (June 2015) change to openssl where it requires a minimum DH key size of 768 bits? This has broken access to several data-center appliances with embedded web servers using SSLv3/TLS1.0 where the firmware DH key size in the server key exchange is only 512 bits. There aren't any firmware upgrades for these aged devices.
<Faux> (Oh no.)
<cjwatson> If I were in that situation I'd consider installing a very restricted proxy or similar with a hacked version of openssl.
<est31> my general advice for situations like these is to a) create a sandboxed VM with outdated software that has no internet access, only to those appliances, b) use that appliance
<est31> also helps with "firefox dropped java npapi support" issues
<TJ-> cjwatson: I'm assembling an openssl patch that reads an alternative minimum dh_size from the environment; that'll give the flexibilty needed on a per-use/per-application basis without downgrading the entire package
<TJ-> est31: right - I'm already needing to use an old Netscape Navigator 9 instance to work correctly
<est31> wow its quite old then...
<TJ-> something along these lines: https://iam.tj/projects/ubuntu/0001-allow-alternative-minimum-dh_keysize.patch
<TJ-> est31: indeed; many of these devices are mid 2000s and just keep on plugging away. No reason to spend Â£Â£Â£s replacing them for something like this. It affects stuff like iLo as well. Not to mention all the firmware embedded self-signed expired X509 certificates too
<est31> TJ-: IMO its still better to have an isolated VM appliance to access these appliances
<est31> than to patch your copy of openssl
<est31> and make your general browsing insecure
<TJ-> est31: how does it make general browsing insecure?
<est31> at least curl uses openssl?
<est31> firefox and chrome I think ship their own libraries
<TJ-> it makes no changes to the default behaviour of libssl UNLESS an environment variable is defined with an alternative minimum DH keysize value
<est31> oh ok
 * est31 shrugs
<TJ-> So I can control when it is active and use the latest libssl packages, rebuilt with this patch applied
<TJ-> It's a minimal patch, does the job, and newer releases are unlikely to require much in the way of rebasing it, so it is maintainable long-term
<xnox> LocutusOfBorg, what ocaml transition?
<xnox> LocutusOfBorg, Feature Freeze was on August 24th.
#ubuntu-devel 2017-09-17
<LocutusOfBorg> xnox, I know, I was just making you aware, maybe this is worth a FFe bug :)
<LocutusOfBorg> for sure we will drop a lot of delta for 18.04
<cajhne> Hi. So just installed 17.10
<cajhne> There is still a long-running issue with boot time being too long with home folder encryption.
<cajhne> The fix that works is here: https://www.youtube.com/watch?v=VPRBkzHbN8g
<cajhne> recommend that fix is made the default.
<cajhne> It's a shame to let that bug go unfixed. It makes people think Ubuntu is too slow loading, and for no reason other than it's been broken.
<tomreyn> 17.10 is unreleased, it doesn't make (most) people think anything at this time.
<tomreyn> youtube is not a bug tracker
<cajhne> tomreyn: this is not a new issue. There is already a bug in the bugtracker.
<doko> cajhne: developers aren't looking at utube videos, so please file a bug report if there is one
<tomreyn> then you'd best reference that
<cajhne> I'm just pointing to the problem.
<doko> or propose a patch
<cajhne> https://askubuntu.com/questions/905031/ubuntu-desktop-17-04-64-bit-with-encrypted-home-slow-boot
<cajhne> there are lots of cryptsetup bugs in the tracker. I don't know which one to add information to.
<cajhne> But the problem and fix  is very well explained in that askubuntu link (and in the youtube video, for the truly lazy)
<cajhne> let me know if I can be of further help.
<cajhne> I can file a new bug if that's useful, but it's not a new problem.
<cajhne> AH, found it: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1670336
<ubottu> Launchpad bug 1670336 in ubiquity (Ubuntu) "Ubiquity problem with encrypted home option: system hangs because of ecryptfs-setup-swap not working with swapfiles" [Critical,Triaged]
<cajhne> That's the bug.
<cajhne> Just letting you know, it's still a problem in 17.10
<cajhne> Thanks for the work. :)
<tomreyn> cajhne: bug 1670336 indicates that the 17.10 release team  have it on their list, with importance critical, so there's a good chance this can get fixed for 17.10
<ubottu> bug 1670336 in ubiquity (Ubuntu) "Ubiquity problem with encrypted home option: system hangs because of ecryptfs-setup-swap not working with swapfiles" [Critical,Triaged] https://launchpad.net/bugs/1670336
<tomreyn> note the "Ubuntu ubuntu-17.10" milestone reference
<cajhne> tomreyn: With the release a few weeks away, I thought it good to squeak about it.
<cajhne> Esp because the fix seems like something easy.
<tomreyn> if you could try and report back on the existing patch that might help
<cajhne> tomreyn: Confirming that changing the cryptsetup line to: "cryptswap1 /swapfile /dev/urandom swap,offset=1024,cipher=aes-xts-plain64" solved the boot time."
<cajhne> That's also worked for me.
<tomreyn> the next step this bug needs to take is https://help.launchpad.net/Code/Review
<cajhne> tomreyn: unfortunately I'm not qualified to do code reviews.
<tomreyn> okay, you can still subscribe to it and help testing once a test build is ready
<cajhne> tomreyn: done
<LocutusOfBorg> doko, sigh, the llvm-5.0 sadness is now an ubuntu only thing? https://launchpad.net/ubuntu/+source/ldc/1:1.4.0-1~build1
<LocutusOfBorg> doko, http://sources.debian.net/src/llvm-toolchain-5.0/1:5.0~%2Brc2-1/lib/IR/Verifier.cpp/#L4681
<LocutusOfBorg> somewhat now llvm is broken?
#ubuntu-devel 2018-09-10
 * mwhudson looks at the scipy mess in -proposed
 * mwhudson gets angry again
<ejat> anyone facing slack & skype crashed on cosmic ?
<ejat> https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1790966
<ubottu> Launchpad bug 1790966 in glibc (Ubuntu) "Electron apps segfault on glibc 2.28 (cosmic)" [Undecided,Incomplete]
<mwhudson> doko: will it just take a few no-change rebuilds to migrate ldc & friends?
<mwhudson> ejat: well that looks fun :/
<jbicha> mwhudson: the ldc rebuilds were already done but didn't all work :|
<mwhudson> oh i see
<mwhudson>  Need an obsolete Phobos module? Here they are, back from the dead and
<mwhudson>  upgraded to work with the latest D.
<mwhudson> except, not actually, it seems :)
<mwhudson> seems it's libundead and gir-to-d that broke?
<mwhudson> still bit late in the day to be learning a new language
<doko> mwhudson: ask the person who synced that after import freeze :-/
<jbicha> ldc autosynced
<ejat> @mwhudson :)
<udevbot_> Error: "mwhudson" is not a valid command.
<dannf> hey bdmurray - would you mind rejecting the grub2/trusty upload from the sru queue? I've got another fix to add. (got a +1 from ivanhu via e-mail)
<bdmurray> dannf: and the grub2-signed as well?
<dannf> bdmurray: nah, that should be fine since i'll reupload w/ the same version
<bdmurray> dannf: okay
<dannf> bdmurray: thanks!
<ogra> sigh, why does git always make me cry ... is there really no way to clone a single subdir without a ton of scripting and hacking up sparse-checkout ?
<xnox> ogra, push to github; use svn client to clone
<xnox> ogra, although i think even with their svn bridge they require to clone the top-level dir =/
<ogra> hmm ... yeah, thats probably the most elegant ...
<xnox> ogra, cloning just a single commit works fine usually too, ie. shallow clone of depth one.... or use webui to browse things.....
<ogra> originally i was simply cloneing the whole tree and mv'ing the subdir where i needed it ... i just wanted something more elegant, but the sparse-checkout thing makes the mv nd rm lines actually look like a beauty
<ogra> the original tree is actually on GH so svn should be fine ...
<ogra> its just a shame that git cant do it with a one liner
<cousteau> Package flightgear installs two application launchers instead of one (both seem identical -- same command, only one has the description in more languages).  Is this normal, or should I report it as a bug?
<jbicha> cousteau: file a bug, could you report it to Debian too?
<cousteau> /usr/share/applications/flightgear.desktop + /usr/share/applications/org.flightgear.FlightGear.desktop
<cousteau> I'm not sure I have a Debian bug reporting account, but I'll try
<jbicha> it works via email, maybe https://wiki.ubuntu.com/Debian/Bugs will help
<cousteau> the long one seems to be in the github repository for flightgear; the short was possibly created independently
<cousteau> done!  I like how I attached the relevant info (distro and package version) only to have it being automatically attached again :|  well, better safe than sorry I guess
<cousteau> bug #1791843
<ubottu> bug 1791843 in flightgear (Ubuntu) "Duplicate launcher for flightgear (in bionic)" [Undecided,New] https://launchpad.net/bugs/1791843
<cousteau> it seems to affect this version only; artful's seems to have a single launcher
<cousteau> Not reporting to debian because from what I could see in packages.debian.org none of their versions are affected by this issue (according to the list of files at least)
<cousteau> ok that's all, thanks for the guidance jbicha!
<jbicha> cousteau: it affects Debian because it still affects cosmic
<cousteau> oh... well, I didn't see it affecting any of the versions I could see from packages.debian.org so I assumed.
<cousteau> anyway I think I'll do that later; it's too late now
#ubuntu-devel 2018-09-11
<dgadomski> hey cyphermox, do you know if fix for bug #1749289 is going to be backported to xenial?
<ubottu> bug 1749289 in ubiquity (Ubuntu Xenial) "Installer stops after pressing Cancel on Select a language screen during OEM install" [Undecided,Confirmed] https://launchpad.net/bugs/1749289
<xnox> dgadomski, the verification you did of the bionic image, would appear to be incomplete for me.
<xnox> dgadomski, before choosing to reboot the second time, did you enable proposed and upgrade all packages from proposed?
<xnox> dgadomski, cause the new ubiquity with fixes is only in bionic-proposed, and not bionic-updates yet
<dgadomski> xnox: nope, oem configuration seemed not to work at all for me for bionic (unlike xenial)
<dgadomski> I've reported a separate bug about it
<xnox> dgadomski, with alternate installer, you should be booting with apt-setup/proposed=true kernel cmdline option
<xnox> dgadomski, i am talking about the separate bug you filed
<xnox> dgadomski, can you please attach all of /var/log/installer logs from the https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1789920 case?
<ubottu> Launchpad bug 1789920 in ubiquity (Ubuntu Bionic) "Installation in OEM mode broken on bionic" [Undecided,New]
<dgadomski> xnox: ack, will try that
<xnox> dgadomski, https://wiki.ubuntu.com/Testing/EnableProposed#line-95 same applies to alternate installer
<didrocks> bdmurray: hey! So my theory for the apport regression is in https://code.launchpad.net/~didrocks/apport/handle-older-reports/+merge/354692. If you +1 on it, I'll upload to cosmic and reupload a bionic version
<rbasak> tsimonq2: why did you sync mysql-5.7?
<rbasak> tsimonq2: AFAICT it's now stuck due to https://bugs.launchpad.net/ubuntu/+source/mecab/+bug/1781529
<ubottu> Launchpad bug 1781529 in mecab (Ubuntu) "[MIR] mecab" [High,New]
<psusi> pitti: gnome-disks is failing to unmount for me.  It seems it has a race condition where it issues the unmount command to udisks, then looks to see if there are still any mount points left and tries to unmount them.  The property hasn't updated yet so it tries to unmount the same location a second time, which fails.
<psusi> pitti: is there a proper dbus way if you expect a property to change, to make sure you wait for it to do so?
<psusi> hrm... I found udisks_client_settle(), but it didn't seem to help...
<michael-vb> Hello there.  I have been seeing a minor quirk in the 18.04 dash/dock, where the icon for VirtualBox is not shown correctly until the screen locks and unlocks.  VirtualBox is an X11 application and I am running a Wayland session.  Who should I poke?
<cpaelzer> cjwatson: hi, since you do 99+% of openssh changes I wanted to ask if bug 1790963 is on your radar?
<ubottu> bug 1790963 in openssh (Ubuntu) "Unable to connect with openssh 7.8 client and certificates" [Undecided,Confirmed] https://launchpad.net/bugs/1790963
<cjwatson> cpaelzer: not really.  maybe it should be taken upstream
<cpaelzer> only affecting RSA certs I'm not even sure enough to triage the severity
<cpaelzer> cjwatson: I had the impression that "Scott Emmons" that updated the bug might be upstream - is that a name known to you?
<cjwatson> this sounds churlish, but I'm afraid I find Ubuntu openssh bugs increasingly hard to follow since there's always a support firewall that gets there before me
<cjwatson> not AFAIK; don't know where you got that idea
<cpaelzer> misinterpretation in between his lines :-)
<cjwatson> since it's affecting other distributions, I think it'll probably just be a matter of cherry-picking an upstream fix eventually
<cjwatson> hm, though on reading more it sounds like we need to backport a correction to the server-advertised key types list?
<cjwatson> have you checked whether the people reporting this have modified PubkeyAcceptedKeyTypes/HostbasedAcceptedKeyTypes in their sshd_config?
<cjwatson> or indeed in the ssh client config
<cpaelzer> cjwatson: no I have not
<cjwatson> worth checking both ends
<cpaelzer> I just have seen a few updates on the bug and desperately tried to reach someone with more experience on the matter => you :-)
<cpaelzer> I could tomorrow try a debian/ubuntu container test with differen setups to confirm the issue for us
<cpaelzer> since Debian is on 7.8 already that should be easy
<tsimonq2> rbasak: Ah, sorry :/ want me to revert the dep?
<rbasak> tsimonq2: yes please. I don't think the MIR will land any time soon. The security team have a rather large backlog of MIR reviews I believe, and mecab isn't a high priority.
<tsimonq2> rbasak: ack, will do this afternoon US time.
<rbasak> Thanks!
<tsimonq2> Thanks for letting me know.
<Skuggen> tsimonq2: I'll prepare an upload for it once we've finalized a fix for #1791010
<Skuggen> 5.7, I mean
<tsimonq2> Skuggen: ack, I'll be happy to sponsor if you can't upload.
<Skuggen> Great, thanks!
<Skuggen> I've started making a ppu application, but need some sponsors for that too :P
<slangasek> kees, stgraber: TB meeting?
#ubuntu-devel 2018-09-12
<alkisg> chrisccoulson: hi, with firefox 62.0+build2-0ubuntu0.18.04.3 I don't see a greek spell checker, while with by downgrading to 59.0.2+build1-0ubuntu1 which is still in bionic repositories I do see the greek spell checker.
<alkisg> I wonder if the ubuntu-specific packaging patch was dropped again, similar to https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/770719 ?
<ubottu> Launchpad bug 770719 in firefox (Ubuntu Natty) "Dutch localization doesn't include Firefox Dutch spell checker add-on" [High,Fix released]
<alkisg> "Look in /usr/share/hunspell for the system dictionaries on maverick Â Â Â Â and later, rather than /usr/share/myspell/dicts. This got droppedÂ Â Â Â somehow in natty"
<alkisg> Manually installing firefox deb = 61.0.1+build1-0ubuntu0.18.04.1 from bionic/launchpad also works...
<alkisg> So to sum up, 59 and 61 have both greek/english spell checkers, while 62 regressed and only has english spell checker.
<LocutusOfBorg> cpaelzer, do you have any plan for libvirt?
<LocutusOfBorg> there is a new bugfix release, I don't know if it is on your list or not...
<cpaelzer> LocutusOfBorg: there is a release every 4 weeks
<cpaelzer> this is not different to other ubuntu cycles
<cpaelzer> we usually pick the qemu we want/need and the libvirt at least one after that (as libvirt contains cleanups/handling of that qmeu then)
<cpaelzer> in some cases I stabilize the libvirt we have by selectively backporting from the newer releases in the following month
<cpaelzer> but we don't go forward to e.g. 4.7 in this case
<cpaelzer> as it would just as much introduce new issues/features
<cpaelzer> and the effort for the selective backport I usually only do for LTS releases
<cpaelzer> from there it depends on bug reports to backport one or the other fix as usual
<cpaelzer> LocutusOfBorg: or is there a 4.6.1 or such that I totally missed
<cpaelzer> hmm, no I only see 4.7 that I know
<LocutusOfBorg> cpaelzer, I was interested in the kernel fixes
<LocutusOfBorg> but as you wish, I get your point, better merge on next archive open?
<cpaelzer> LocutusOfBorg: I do so every cycle anyway with plenty of regression tests as we have so much things depending on it
<cpaelzer> LocutusOfBorg: if you have anything in particular open a bug and I can consider backporting the commit
<cpaelzer> LocutusOfBorg: now I'm curious anyway, what kernel fixes are you referring to?
<LocutusOfBorg> 4.18 fixes, but I see you probably have already backported them
<cpaelzer> hehe
<cpaelzer> I'm actually the upstream Author of them as well
<cpaelzer> so yeah, that is already in Cosmic and on its SRU way to Bionic (so that the HWE will not cause trouble)
<LocutusOfBorg> nice! thanks!
<cpaelzer> never a fix is so easy as those that are already done :-)
<cpaelzer> you are welcome
<chrisccoulson> alkisg, yes, I'm aware of that
<alkisg> chrisccoulson: thank you
<chrisccoulson> just another thing to add to the long list of disasters for this update :/
<alkisg> :D
<alkisg> Yeah schools started and I'm having 10 issues per hour :D
<cking> hi, the xenial version of zfsutils-linux for bug 1781364 was verified several weeks ago but the package is still in -proposed, can that be released sometime soon?
<ubottu> bug 1781364 in zfs-linux (Ubuntu Xenial) "Kernel error "task zfs:pid blocked for more than 120 seconds"" [Undecided,Confirmed] https://launchpad.net/bugs/1781364
<rbasak> Hmm. zfs-linux doesn't appear in http://people.canonical.com/~ubuntu-archive/pending-sru.html
<rbasak> cking: zfs-linux has nothing in xenial-propsed. xenial-updates shows 0.6.5.6-0ubuntu24 published on 2018-08-23. Is what you need already done with an incorrect status?
<cking> rbasak, I think I figured it out, I tested it against the kernel that was in -proposed and the zfsutils in my PPA, I forgot to upload it, stupid me
<rbasak> np
 * cking slaps himself
<Yimo_> hey there! I know this is not the right channel but I figured the devs of ubuntu can help me with my case. You see, I have two linux distros on dualboot. That is fine. However ubuntu's grub installation causes my other OS to have a kernel panic, while the other distro's os keeps both working fine for me. What I want to do is ignore/disable grub in ubuntu and make sure that it doesn't reinstall itself after an update of whatnot, 
<Yimo_> Does anyone know how I can do this? all my search only lead me to removing ubuntu itself and not this
<Yimo_> As I expected, silence :/
<Faux> Ask in #ubuntu. This is never the right channel.
<cjwatson> Geez, a five-minute delay isn't silence
<Yimo_> alright
<cjwatson> The preferred approach is to remove the GRUB packages that are defined as owning the system's boot process (normally grub-pc and grub-efi-amd64), but using dpkg-divert on grub-install would work too
<Yimo_> what is the difference between the two approaches?
<Yimo_> (trying the preferred method and hoping ubuntu won't reinstall grub)
<cjwatson> While I'd prefer the former, it's possible that it will cause some other packages (beyond grub-*) to be removed and that you might determine that this is unacceptable for you (try it and see); in that case dpkg-divert is a fairly general "I want to put my own thing in place of this system-provided file and have it persist across upgrades"
<cjwatson> I think the first approach should work though
<Yimo_> Ah I get what you mean
<Yimo_> generally any grub requiring package won't go too far beyond boot, I'm fine by first approach
<Yimo_> thanks for the clarification though
<cjwatson> np.  Faux is right that #ubuntu is really a better place for support, in general.  I just happened to be watching
<Yimo_> well, in general yeah. However sometimes in extreme cases though I prefer digging closer to devs
<Yimo_> thanks anyway and cya
<doko> tumbleweed, cyphermox: any idea about https://launchpad.net/ubuntu/+source/python-pkginfo/1.4.2-1 ?
<msalvatore> Hey, doko. Will you still have time today to take a peek at that armhf build failure? https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+build/15336959
<tumbleweed> doko: simple enough. I'll poke it
<doko> msalvatore: not a priority for me
<tumbleweed> doko: uploaded to unstable
<msalvatore> doko: ok. thanks anyway
<sil2100> rbasak: hey! Are you done with your SRU shift for today? Since I wanted to review ipxe from the bionic queue and don't want to step on your toes
<rbasak> sil2100: go ahead. I'm looking at gnome-software but won't look at any after that. Thank you for syncing.
<BenderRodriguez> so, who's the person here who proposed that it would be a good idea to advertise bit.ly links in motd banners for Ubuntu *Server*
<BenderRodriguez> like, what thought process went through to come to the conclusion that pushing this into a clearly enterprise centric version of the distro was a good idea
<BenderRodriguez> like seriously, who was it -- I am both astounded and intrigued by either the madness or genius of this person
<BenderRodriguez> any explainations?
<dpb1> nice tone
<dpb1> here's more info if you want it
<dpb1> https://meet.google.com/linkredirect?authuser=0&dest=https%3A%2F%2Fbugs.launchpad.net%2Fubuntu%2F%2Bsource%2Fbase-files%2F%2Bbug%2F1701068%2Fcomments%2F11
<dpb1> lol
<dpb1> here
<dpb1> https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1701068/comments/11
<ubottu> Launchpad bug 1701068 in base-files (Ubuntu) "motd.ubuntu.com currently shows media item (HBO's Silicon Valley using Ubuntu)" [Wishlist,Opinion]
<dpb1> (comment 11)
<nacc> BenderRodriguez: "cleary enterprise centric" version implies a rather large misundrestanding of the difference between server and desktop, IMO.
<BenderRodriguez> nacc: let's not divert from the issue here
<BenderRodriguez> call it what you please
<BenderRodriguez> but it doesn't belong on this variant of the distro
<nacc> BenderRodriguez: "doesn't belong" is an opinion.
<nacc> I don't defend it myself, but you sound rather FUD-y right now
<BenderRodriguez> nacc: so you think there's objective benefits in pushing potentially unwanted, potentially malicious, unknown links to operating systems that may be part of critical infrastructure?
<jbicha> BenderRodriguez: the LP bug comment explains how to disable it if you want for your enterprise
<jbicha> unknown to who? malicious how?
<BenderRodriguez> jbicha: oh I'm sure there are various way to thrwart the functionality, but it should never even be introduced for someone to have to work to disable it
<BenderRodriguez> jbicha: I don't know what theit bit.ly link is for
<BenderRodriguez> i don't know where it would take me
<BenderRodriguez> so i have to believe that there's a non-zero chance that it's a malicious link
<nacc> BenderRodriguez: ... "unwanted", "unknown", etc.
<nacc> BenderRodriguez: total FUD.
<nacc> BenderRodriguez: unknown to *you*
<BenderRodriguez> right
<BenderRodriguez> exactly
<BenderRodriguez> unknown to the user
<nacc> BenderRodriguez: also, critical infrastructure ... why is the motd relevant?
<nacc> BenderRodriguez: don't use the internet, btw, if you're worried about potential unwanted, malicious links
<jbicha> enterprises pay their sysadmins to disable unwanted functionality. Hire me if you want me to disable it for your enterprise
<BenderRodriguez> Again, there will be a scenario where the OS *has* to have internet connectivity
<nacc> BenderRodriguez: basically, you have an opinion, that's great. Your opinion wasn't shared by someone who works on the product. That's how it goes sometimes.
<nacc> BenderRodriguez: I'm saying, not about this specific case.
<nacc> BenderRodriguez: if you are worried about URLs, don't use the internet ever
<nacc> I'm pretty sure that's the only solution to your concern about them
<BenderRodriguez> nacc: but given the vocal outrage from the linux community, the only thing that should have been done was a well written apology and a patch swiftly distirbuted to excise this feature
<nacc> BenderRodriguez: "linux community"?
<nacc> BenderRodriguez: ubuntu != linux.
<BenderRodriguez> nacc: yes, you don't have to quote it
<BenderRodriguez> nacc: again, uneeded pendantry
<BenderRodriguez> the open source community, linux, GNU/Linux, Ubuntu, call it what you want -- people aren't happy about this
<nacc> BenderRodriguez: so you now speak for millions of people?
<nacc> BenderRodriguez: and all of those people are now unanimous in this opinion?
<BenderRodriguez> I speak based on a tally of the negative criticisms on the various launchpad bugs on this
<BenderRodriguez> so there is quantitative data to show that yes
<BenderRodriguez> people aren't happy
<nacc> BenderRodriguez: what's the count there, then?
<BenderRodriguez> nacc: you have access -- you wanted this info? then go look for it yourself
<nacc> BenderRodriguez: no, you are asserting there is some great outrage. Prove it to me.
<BenderRodriguez> nacc: look at all the closed/open launchpad bugs on this
<BenderRodriguez> there's your proof
<nacc> BenderRodriguez: that's 1) not proof that the entire "open source community, linux, GNU/linux, Ubuntu" care at all about this and 2) no, you seem unwilling to try and actually prove your point. I refer you back to FUD. And will now move on to something useful in my day.
<nacc> BenderRodriguez: again, I don't disagree with your sentiment. But I don't think it's the scary thing you are trying to make it out to be.
<BenderRodriguez> nacc: it is a major breach in trust and a potential security hazard
<BenderRodriguez> these aren't opinions
<BenderRodriguez> this is an objective statement
<nacc> BenderRodriguez: how is it either?
<BenderRodriguez> nacc: 1) This feature was implemented without ample warning or discussion with the community at large   2) This feature can easily be commandeered in various way to supply potentially malicious content
<nacc> BenderRodriguez: 1) I can understand that perspective. Canonical made a choice here. You trust Canonical, by using their software (IMO). As to 2) I don't see what obvious commandeering you are implying.
<StevenK> nacc: Set http_proxy to something that can rewrite bit.ly URLs, boom, malicious content
<nacc> StevenK: for the root user.
<nacc> StevenK: which implies your root user is compromised?
<StevenK> nacc: Setting environment variables does not require special privledges
<nacc> StevenK: setting environment variables that are read by the update-motd process would, though?
<StevenK> nacc: update-motd is not involved here, it's the process of *following* the links
<nacc> StevenK: err, sorry the systemd timer, i think
<nacc> StevenK: oh, you are saying, you as the user click on a link with a compromised http_proxy?
<nacc> StevenK: ... so the issue is you have a compromised system, and you are complaining about the MOTD?
<StevenK> nacc: I wasn't complaining, I was just pointing out how easy it is
<nacc> StevenK: how easy it is to have a compromised system? ... I don't see what having a URL in motd has to do with your system being compromised.
<nacc> StevenK: and it also means you shouldn't open *any* URLs on said system, not just MOTD.
<nacc> again, don't use the internet if you can't trust your system
<nacc> it seems like blatant FUD
<StevenK> How easy it is subvert bit.ly URLs, but I have more important things to do
<nacc> me too! :)
<BenderRodriguez> nacc: and if motd.ubuntu.com is compromised?
<nacc> BenderRodriguez: then probably a lot more of ubuntu.com is too
<BenderRodriguez> right but you see where I'm getting at right?
<nacc> BenderRodriguez: yes, you trust ubuntu.com to be what it is supposed to be.
<BenderRodriguez> it's an uncessary vector of attack being introduced
<nacc> BenderRodriguez: I don't see it as a breach of trust, to use that trust in a URL.
<BenderRodriguez> for a server operating system...
<nacc> whatever, I'm done talking about this
 * sladen tries to read the scrollback
<sladen> is there a bug report?
<nacc> sladen: LP: #1701068
<ubottu> Launchpad bug 1701068 in base-files (Ubuntu) "motd.ubuntu.com currently shows media item (HBO's Silicon Valley using Ubuntu)" [Wishlist,Opinion] https://launchpad.net/bugs/1701068
<nacc> sladen: and others, iirc
<sladen> nacc: this bug report is from over one year ago? (June 2017)  Is it still current?
<nacc> sladen: dunno :)
<hggdh> well, it is sort-of current. It has been set as Opinion, which is a terminal state (meaning somebody decided this will not be looked at further), but is basically a difference of opinions
<desti> https://bugs.launchpad.net/ubuntu/+source/libsdl2/+bug/1740517 anyone here responsible for libsdl2 can look at this?
<ubottu> Launchpad bug 1740517 in libsdl2 (Ubuntu) "SDL2 2.0.6 isn't compiled with Vulkan support" [Undecided,Confirmed]
<nacc> desti: is it still broken on 18.10? it will need to be fixed there before 18.04 can be SRU'd
<desti> i guess so
<nacc> desti: that's not exactly good enough, and is information that's needed in the bug. LocutusOfBorg, i think you TIL?
#ubuntu-devel 2018-09-13
<BenderRodriguez> sladen: yes, it's current
<BenderRodriguez> hggdh: it is not a difference of opinions
<jbicha> BenderRodriguez: the Opinion status is also used when Canonical has made a decision and isn't really very interested in changing their mind
<Unit193> Really should be set "won't fix"
<BenderRodriguez> This is ridiculous
<BenderRodriguez> but alright, I suppose there's no point in trying to voice opinions if it will be ignored
<hggdh> we, at the time, did not quite agree with having "opinion" but no "wontfix", but I, at least, was unable to change the decision
<Komzzpa> Hello!
<Komzzpa> I'm Darafei Praliaskouski from PostGIS team. Recently there was a release of GEOS 3.7.0 geospatial processing library that a soon-coming PostGIS 2.5 will depend on. It is packaged into Debian Unstable, but as I understand it's a bit after automatic sync deadline for Ubuntu Cosmic. May it be pulled into Ubuntu Cosmic?
<LocutusOfBorg> nacc, thanks,
<LocutusOfBorg> desti, if you want the bug fixed, start by providing a patch :)
<Komzzpa> I was sent here from #ubuntu-packaging, if it's not the right place to ask please show me the direction :)
<acheronuk> well, here is more likely....
<LocutusOfBorg> Komzzpa, the soname changed, so this mean a transition (even if it has only one reverse-dependency)
<acheronuk> Komzzpa: 3.7 in debian includes a shared library name bump
<LocutusOfBorg> ubuntu has 2.4 as postgis
<acheronuk> so ossim would need updating
<LocutusOfBorg> I would say no, unless you prove that the new library is only a bugfix release, with no new features, and nothing breaks
<LocutusOfBorg> Komzzpa, are you upstream?
<acheronuk> changes in 3.7.0 https://trac.osgeo.org/geos/browser/git/NEWS?rev=3.7.0
<LocutusOfBorg> acheronuk, what is your opinion?
<acheronuk> Komzzpa: we are in https://wiki.ubuntu.com/FeatureFreeze
<Komzzpa> LocutusOfBorg: I'm PostGIS upstream. I'm familiar with GEOS codebase and can bring someone properly-upstream if needed.
<LocutusOfBorg> Komzzpa, what are the "new features mentioned?" e.g. GEOSDistanceIndexed
<LocutusOfBorg> I mean, can you say something "hey they are new functions, and they don't clash so if nobody uses them, they are safe to go"
<LocutusOfBorg> or something like that
<Komzzpa> GEOSDistanceIndexed is a new distinct function not called by packages working with GEOS 3.6
<LocutusOfBorg> Komzzpa, can you please open a bug on the package, explaining changelog, and why you think it is worth a Feature Freeze Exception?
<acheronuk> LocutusOfBorg: I don't know enough background to form one really. looking at the non bumped libgeos-c1v5 lib, looks like some symbols got dropped and that has quite a few rdeps
<acheronuk> so that makes me a bit wary
<LocutusOfBorg> e.g. you can use this one as template https://bugs.launchpad.net/ubuntu/+source/octave/+bug/1791359
<ubottu> Launchpad bug 1791359 in octave (Ubuntu) "FFe: Sync octave 4.4.1-1 (universe) from Debian experimental (main)" [Wishlist,Fix released]
<LocutusOfBorg> of course against this package https://launchpad.net/ubuntu/+source/geos
<LocutusOfBorg> acheronuk, I see only ossim in Debian https://release.debian.org/transitions/html/auto-geos.html
<LocutusOfBorg> oh got it acheronuk
<LocutusOfBorg> the 1v5 library is the C library (and didn't change)
<LocutusOfBorg> only the C++ binding changed soname
<LocutusOfBorg> so, the situation is "better"
<LocutusOfBorg> Komzzpa, please mention also this, that only the c++ binding had an ABI change
<acheronuk> LocutusOfBorg: 1v5 lib name did not change. symbols did
<acheronuk> though may be ok
<Komzzpa> LocutusOfBorg: do I need to double check ossim working myself, or is there automated way?
<acheronuk> hmmm. one non optional dropped
<LocutusOfBorg> acheronuk, but not used... right?
<acheronuk> LocutusOfBorg: that is what I can't judge
<LocutusOfBorg> acheronuk, which symbol?
<acheronuk> LocutusOfBorg: https://salsa.debian.org/debian-gis-team/geos/commit/4c764977e873d6bbf0e7b46a7d8188d051429ada
<LocutusOfBorg> Komzzpa, you can check the package from here https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa
<acheronuk> _ZNK4geos4util13GEOSException4whatEv@Base 3.4.2
<LocutusOfBorg> geos::util::GEOSException::what() const
<LocutusOfBorg> oh... this symbol? https://sources.debian.org/src/osgearth/2.9.0+dfsg-3/src/osgEarthSymbology/Geometry.cpp/?hl=430#L430
<LocutusOfBorg> lets see if osgearth can compile now http://debomatic-amd64.debian.net/distribution#unstable/osgearth/2.9.0+dfsg-3build1/buildlog
<LocutusOfBorg> Komzzpa, Im building it in my ppa if you want to test https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+packages
<acheronuk> it's probably ok, but I'd not trust my C++ quite enough on it's own!
<LocutusOfBorg> osgearth builds ok...
<LocutusOfBorg> Komzzpa, please put the bug number once you have it, so we can do the required paperwork
<Komzzpa> LocutusOfBorg: Is this good enough? https://bugs.launchpad.net/ubuntu/+source/geos/+bug/1792342
<ubottu> Launchpad bug 1792342 in geos (Ubuntu) "Sync geos 3.7.0 from Debian unstable" [Undecided,New]
<Komzzpa> LocutusOfBorg: I rewrote changelog in non-geospatial terms, hope it is okay
<LocutusOfBorg> Komzzpa, I think we are good
<Komzzpa> LocutusOfBorg: thanks! :)
<LocutusOfBorg> Komzzpa, thank release team if they accept it :)
<doko> coreycb, cpaelzer: we should talk about percona in main at the sprint ...
<cpaelzer> jamespage: ^^
<cpaelzer> and since percona ~= mysql rbasak^^
<cpaelzer> it seems that becomes a reocurring sprint topic now
<doko> mvo, mwhudson: what is the status about https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1660550 ?
<ubottu> Launchpad bug 1660550 in snapd (Ubuntu) "[MIR] snapd in trusty" [Undecided,Fix committed]
<doko> jamespage: ping about https://bugs.launchpad.net/ubuntu/+source/python-pykmip/+bug/1543754
<ubottu> Launchpad bug 1543754 in python-pykmip (Ubuntu) "[MIR] barbican, python-pykmip" [Undecided,Incomplete]
<coreycb> doko: cpaelzer: sounds good. btw we do have an MIR open for it, but i know there's a lot more that goes into it. bug 1768119
<ubottu> bug 1768119 in percona-xtradb-cluster-5.7 (Ubuntu) "[MIR] percona-xtradb-cluster-5.7, percona-xtrabackup, libdbd-mysql-perl" [Undecided,New] https://launchpad.net/bugs/1768119
<seb128> cyphermox, hey, any chance that you do that modemmanager update from rc1 to 1.8 stable? ;)
<cyphermox> don't know, definitely not right now
<tkamppeter> doko, hi
<doko> tkamppeter: hi
<doko> one more cp* package to go =)
<tkamppeter> doko, the cpdb* packages need to get seeded because they do not have yet some package using them.
<tkamppeter> doko, the cpdb-libs is hanging on the autopkgtest for arm64 only (rest OK) and it was told me to test and debug on the porter boxes, rugby for arm64.
<tkamppeter> So I asked for being added to the porter box users and got links to instructions how to use (through our VPN). Set everything up, but https://portal.admin.canonical.com/C113885 is preventing me from using it (cannot install packages).
<tkamppeter> doko, I hope they will resolve this soon.
<tkamppeter> doko, or can we make an exception as arm64 never worked?
<tkamppeter> doko, checked rugby, still broken.
<doko> tkamppeter: will you be at the sprint next week?
<mwhudson> doko: no idea
#ubuntu-devel 2018-09-14
<joelkraehemann> hi all
<joelkraehemann> Is it possible to get bug-fixes into bionic for specific package?
<joelkraehemann> https://launchpad.net/ubuntu/+source/gsequencer
<joelkraehemann> ^^ Since I was busy for next major release 2.0.x didn't take care much about the issues
<joelkraehemann> Anyhow, I created a sync request
<joelkraehemann> but it was ignored
<joelkraehemann> I found additional bugs as revising every single file for the 2.0.x release
<joelkraehemann> At my opinion we should provide an updated 1.4.x version to fix the issues
<joelkraehemann> What do you need in order to update the package?
<RAOF> joelkraehemann: https://wiki.ubuntu.com/StableReleaseUpdates
<ricotz> stgraber, hi, is there some discussion which could have been followed for decisions like https://launchpad.net/ubuntu/+source/lxd/1:0.3
<tkamppeter> doko, I will be there.
<rbasak> ricotz: isn't that https://lists.ubuntu.com/archives/ubuntu-devel/2018-August/040455.html ?
<Unit193> ricotz: AFAIK, you can still use lxc.
<ricotz> rbasak, Unit193, yes and yes, although I fearing more packages moving without a deb alternative
<ricotz> e.g. same seems to be planned for chromium
<rbasak> I believe that's the way things are going for fast moving stuff.
<rbasak> If you're willing to put in the effort to maintain debs in parallel, perhaps take it up in ubuntu-devel@ on how to make that work technically?
<Unit193> ricotz: Oh dear, really?  I was going to say, depending on what it is then one can simply backport from Debian into a PPA.
<Unit193> Alternativly you can hold the last real version, but that's not generally the best to do in regards to security.
<ricotz> rbasak, I understand but I am not interested in having snapd running here, in case of chromium: having a software release every 2 month seems not fast moving imho
<rbasak> It becomes increasingly difficult to maintain for security in an LTS when upstreams add new dependencies etc.
<ricotz> Unit193, a sane backport seems hard with introduced epochs
<ricotz> rbasak, correct
<rbasak> I don't know about Chromium but that's what is happening with Firefox, why it's becoming increasingly painful for people maintaining this stuff (security team etc), and why snaps are created as a solution to that problem.
<Unit193> That is true, and pinnning for that doesn't seem ideal.
<rbasak> That's why those doing the maintenance are moving to snaps.
<Unit193> rbasak: Do you have a list of candidates?
<rbasak> Unit193: I don't. That's a good and reasonable question for the mailing list though I think.
<rbasak> Separately, if somebody wants to maintain eg. Firefox ESR in universe as a deb as an alternative, I don't think anyone would be opposed to that (provided it comes with a realistic commitment to maintain for security for LTS, etc). But that's a question for the ML too.
<jbicha> https://community.ubuntu.com/t/7978 < Chromium as snap replacing .deb
<tkamppeter> doko, hi
<michagogo> Question: would an SRU to enable a feature via a build flag be appropriate?
<michagogo> Specifically, the option to compile XRDP with support for vsock connections
<rbasak> There's a "For Long Term Support releases we sometimes want to introduce new features" exception noted in https://wiki.ubuntu.com/StableReleaseUpdates
<michagogo> The version in Bionic has it enabled (at Microsoftâs request, it was turned on in Debian, and then synced over)
<rbasak> With some requirements.
<michagogo> But Xenial doesnât, so if you want to enable Hyper-V Enhanced Sessions there you need to build from source and install it yourself
<rbasak> cking: see https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2018-September/018138.html and the next two emails. Was that you?
<rbasak> Am I right in thinking that this is from an accidental upload to Debian, which replied without checking the signature first? If so, maybe we can just ask for these all to be dropped from the ML?
<cking> rbasak, yeh, I was on stupidly strong pain killers that day, and messed up. can indeed these can be dropped from the ML
<rbasak> michagogo: that sounds like it might be acceptable to SRU in principle under a number of existing exceptions, platoform/HWE enablement included.
<rbasak> hggdh: ^
<michagogo> rbasak: Iâm not sure I understand the second and third sentences there
<michagogo> The feature is there in bionic, which is good
<rbasak> michagogo: I mean that from your description here it sounds like it's acceptable to SRU in principle under existing established exceptions.
<rbasak> I don't know the specifics though, and we still need to take care not to impact existing users by causing unexpected behaviour changes.
<michagogo> I meant the second and third sentences in that section of the SRU wiki page
<michagogo> âThey must not change the behaviour on existing installations (e. g. entirely new packages are usually fine). If existing software needs to be modified to make use of the new featureâ
<rbasak> Enabling a feature via a build flags falls under "existing software needs to be modified".
<rbasak> We need to make sure that doing so won't impact existing users.
<rbasak> (eg. some existing user using some function that now enables a protocol flag not supported on the user's server, causing something that previously worked to fail following the SRU)
<rbasak> That type of thing.
<doko> apw, xnox: I have a probembuilding the 4.18 cross kernel (includes)
<doko>   CC      kernel/bounds.s
<doko> gcc: warning: '-mcpu=' is deprecated; use '-mtune=' or '-march=' instead
<doko> gcc: warning: '-mcpu=' is deprecated; use '-mtune=' or '-march=' instead
<doko> gcc: error: unrecognized command line option '-mmultiple'; did you mean '-imultilib'?
<doko> make[5]: *** [Kbuild:21: kernel/bounds.s] Error 1
<doko> does this ring a bell?
<michagogo> rbasak: I see, I think. Maybe some time soon Iâll find time to look into it. Thanks!
<doko> that goes into linux-source-4.18.0/arch/powerpc/Makefile in the big endian config
<rbasak> tsimonq2, Skuggen, cpaelzer: mysql-5.7 5.7.23-2 uploaded to Debian. This should fix the ppc64el test issues. It will fail to migrate though due to component mismatch - we still need to upload a merge that drops the mecab b-d to undo the sync.
<rbasak> I believe that's being coordinated between Skuggen and tsimonq2.
<andrewsh> guys, is that a known issue that Unity is broken in the current cosmic?
<andrewsh> (at least on my laptop)
<andrewsh> or, better:
<andrewsh> any pointers how to debug compiz[19701]: WARN  2018-09-14 15:37:46 unity.iconloader IconLoader.cpp:264 Unable to load icon . GThemedIcon .%20GThemedIcon%20unity-online-accounts%20unity-online-accounts-symbolic .%20GThemedIcon%20unity-online-accounts%20unity-online-accounts at size 64
<Skuggen> rbasak: Right. I'll prepare an upload with the delta that drops the mecab dependency
<jbicha> andrewsh: that sounds like Debian bug 908705
<ubottu> Debian bug 908705 in libglib2.0-0 "g_icon_to_string output includes some garbage prefix" [Serious,Open] http://bugs.debian.org/908705
<andrewsh> hmm
<andrewsh> jbicha: should I try to revert glib?
<jbicha> andrewsh: no, that's not very practical at all
<andrewsh> I mean locally
<andrewsh> I wonder why this doesn't affect GNOME
<jbicha> andrewsh: what I suggest is building with this commit: https://gitlab.gnome.org/GNOME/glib/merge_requests/305
<andrewsh> hmm
<jbicha> Philip (who is upstream glib) did comment on the Debian bug so my instinct is to wait for him to review before pushing that patch to Debian/Ubuntu
<andrewsh> okay, let's build and test it locally
<andrewsh> oh noes, the OBS is busy rebuilding the world
<andrewsh> I should use a local sbuild then
<jbicha> I believe ppa's still work, the rebuild has low priority
<jbicha> I'm assuming you don't mean OpenSUSE?
<andrewsh> Open Build System
<andrewsh> our (Collabora's)
<jbicha> I assumed wrong then :)
<jbicha> andrewsh: see our rebuild the world: https://launchpad.net/builders/
<andrewsh> I don't think OBS distinguishes between first builds and rebuilds
<andrewsh> and I don't think there are multiple priorities
<andrewsh> Iâve started a rebuild of a Ubuntu-derived distro yesterday, and it's still on-goingâ¦
<teward> doko: before I go running additional tests, why are we demoting pcre3 in favor of pcre2?
<teward> seems to me like that'd be a backwards step
<teward> unless I
<teward> I've missed something*
<jbicha> teward: pcre3 is poorly named, pcre2 is newer
<teward> jbicha: that explains that one.  Can we update the bug to make a note of that so that we can clarify?  (Just for documentation purposes)
<jbicha> teward: please do :)
<teward> bug text updated.
<teward> running build tests for nginx now
<hggdh> rbasak: I understand, then,  that I can block emails from ftpmaster@ftp-master.d.o from being received by ubuntu-discuss. Correct?
<tsimonq2> rbasak: ack
<tsimonq2> Skuggen: If you don't have upload access though, I would prefer to sponsor your patch rather than Just Doing It.
<rbasak> hggdh: agreed
<hggdh> thank you, will do
<teward> jbicha: doko: NGINX is good to go for pcre2
<joelkraehemann> RAOF, thank you
<andrewsh> jbicha: running on that patch now, works fine here
<andrewsh> jbicha: uh-oh, compiz now broken too :/
<andrewsh> shadows etc
<andrewsh> hmm, Iâm told a related issue is already reported as https://bugs.launchpad.net/bugs/1725443 but it is private, apparently
<ubottu> Error: launchpad bug 1725443 not found
<jbicha> bug 1725443 is kinda old
<ubottu> bug 1725443 in compiz (Ubuntu) "compiz crashed with SIGSEGV in g_type_check_instance_is_fundamentally_a()" [Medium,Confirmed] https://launchpad.net/bugs/1725443
<andrewsh> so, in Appearance â Behaviour, I now have "Low" enabled instead of "High"
<andrewsh> if I toggle it back, the launcher renders incorrectly, and if I restart X, it never appears, presumably Unity crashes
<andrewsh> or rather compiz
<andrewsh> by incorrectly I mean missing or inverted colours, black background instead of transparency etc etc
<jbicha> sorry, I don't use compiz
<andrewsh> well, it's part of Unity, thatâs why I use it
#ubuntu-devel 2018-09-15
<lovepopsickle> you guys should have onion addresses for updating like debian does :)
<Skuggen> tsimonq2: Yeah, I'll ping you when it's ready :)
<est31> anyone else seeing that packages.ubuntu.com is rekt?
<est31> https://packages.ubuntu.com/xenial/gcc
<est31> gcc is certainly available in more versions of ubuntu than xenial and trusty
<est31> same for any other package
<est31> was just using gcc as an example
<est31> direct links dont work either
<est31> https://packages.ubuntu.com/cosmic/gcc
<est31> but it also applies for bionic
<est31> https://packages.ubuntu.com/bionic/gcc
<cjwatson> est31: There's a bug reporting link at the bottom of thepage.
<cjwatson> +<space>
<cjwatson> And an email contact address at the bottom of https://packages.ubuntu.com/about/
<michagogo> rbasak: dammit. note to self: next time, actually check first that the version in the older distribution does indeed have the feature in question available to be build-flagged on ð¤¦ð¼ââï¸
#ubuntu-devel 2018-09-16
<tarzeau> is artfwo here?
#ubuntu-devel 2019-09-09
<roaksoax>  /win 1
<LocutusOfBorg> cjwatson, we are not supporting officially all the init systems, but if an user wants to use a different one is able to do it, right?
<LocutusOfBorg> I admit I did a lot of work trying to get runit working on Debian...
<cjwatson> I'm not sure Ubuntu supports any other init systems at all; but I think we should minimise effort on removing them
<cjwatson> Just on the usual minimise-delta policy
<jamespage> doko: there was an issue with the maintainer scripts in python3-gabbi which will have caused a FTBFS for all reverse-build-depends
<jamespage> https://paste.ubuntu.com/p/dkDpckrrXn/
<jamespage> I've uploaded a fix but ^^ will all FTBFS at the moment
<LocutusOfBorg> cjwatson, so, its like "hey we don't drop them because we should patch half the archive, but if you want to pursue a different init system you are on your own"
<cjwatson> Correct
<cjwatson> LocutusOfBorg: I still don't understand why you thought it worth syncing openssh
<doko> jamespage: fix for which package?
<doko> ahh, -gabbi
<LocutusOfBorg> cjwatson, for some reasons, I would like to have runit working on ubuntu too
<LocutusOfBorg> I will fix it up
<LocutusOfBorg> not sure if with a dh_runit patch or something else...
<LocutusOfBorg> maybe conditional support on rules file in openssh?
<LocutusOfBorg> I have to do some haskell finishing and polishing work
<LocutusOfBorg> and then I'll focus on it
<cjwatson> LocutusOfBorg: MIRing runit-helper makes a lot more sense to me than adding conditional nonsense
<cjwatson> While we don't strictly need it for Ubuntu's use cases, it's also like 4416 bytes
<jamespage> doko: and likely the cause of FTBFS in
<jamespage> https://paste.ubuntu.com/p/ZPpVv2TWRZ/
<jamespage> and
<jamespage> https://paste.ubuntu.com/p/d2NYHFpVXD/
<jamespage> *-> {python3-}tempest -> python3-gabbi
<jamespage> anyway fix uploaded
<doko> jamespage: I'll give back these main packages once -gabbi reaches the release pocket
<jamespage> +1 thanks
<LocutusOfBorg> opened bug LP: #1843236
<ubottu> Launchpad bug 1843236 in dh-runit (Ubuntu) "[MIR] runit-helper" [Undecided,New] https://launchpad.net/bugs/1843236
<cjwatson> Thanks
<doko> rbasak, cpaelzer__, coreycb: not sure who cares about php, but php7.2 is still in main, and php7.3 is not migrating
<cpaelzer__> doko: bryyce is after that since a few days actually
<cpaelzer__> it should - as you'd expect - be just 7.3 in main and no 7.2 anymore
<rbasak> Right - Bryce is working on it.
<ahasenack> cpaelzer__: would it be ok upload our postfix, adding the ftbfs fix as delta, and later sync with debian again?
<ahasenack> the fix was merged in salsa, but I don't see a new upload yet
<cpaelzer__> sure
<cpaelzer> ahasenack: if such happens to me I just add a self-reminder to not forget syncing it in time
<cpaelzer> but othere than that I see nothing that would be bad fixing it as-is now
<ahasenack> I think the branch is at 3.4.6 already even
<ahasenack> the salsa master branch, I mean
<ahasenack> so a future sync would be not just that ftbfs fix
<doko> sforshee: is there a reason that you still use bz2 compression in the linux-5.x-source package instead of xz?
<doko> sforshee, apw: linux-oem-osp1 needs promotion
<doko> at least it show up in component mismatches
<apw> doko, hmmm, ta
<doko> sforshee, apw (and tseliot): nvidia-graphics-drivers-435 needs a bug subscriber (and then promotion)
<doko> or is desktop subscribed to these?
 * apw tries to remember what the kernel team for bugs is called
<doko> apw: at least nvidia-graphics-drivers-340 has desktop-packages as subscriber ...
<doko> seb128: ^^^
<doko> apw: and 390 has kernel-packages
<apw> doko, i'd say kernel-packages is fine
 * doko takes his foundations hat and runs away
<seb128> doko, should be kernel team, it's maintained by tseliot
<apw> doko, i believe i have added that to the kernel-packages subscription
<doko> ta, promoted to restricted
<doko> jamespage: updated https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20190906-eoan.html
<jamespage> doko: ta
<bryyce> vorlon, from lp #1842969 sounds like a versioned removal request is in order?  Shall I file it?
<ubottu> Launchpad bug 1842969 in python-django (Ubuntu) "python-django 2.2.4 not for eoan" [Undecided,Confirmed] https://launchpad.net/bugs/1842969
<cjwatson> note that if you're doing this then you need to do an Ubuntu-local reintroduction of python-tblib (the py2 binary package) as a build-dependency
<cjwatson> possibly some other stuff on https://people.canonical.com/~ubuntu-archive/nbs.html
<bryyce> cjwatson, ah thanks
<cjwatson> also I'm confused by why https://launchpad.net/bugs/1842969 has the alleged purpose of being a blocker bug, but doesn't have the block-proposed tag?
<ubottu> Launchpad bug 1842969 in python-django (Ubuntu) "python-django 2.2.4 not for eoan" [Undecided,Confirmed]
<bryyce> cjwatson, I can definitely add that tag, although think this may be a q for vorlon
<rbasak> tsimonq2: o/ what has the attendence been like at the Ubuntu Flavors meetings please?
<rbasak> I'm wondering if all flavours know of https://lists.ubuntu.com/archives/ubuntu-flavors/2019-July/000000.html - are they all on the list?
<cyphermox> Eickmeyer: ack, I'll try to get to that later tonight
<Eickmeyer> cyphermox: Thanks!
<Eickmeyer> rbasak: The August meeting didn't happen because tsimonq2 failed to set the date, afaik.
<rbasak> !dmb-ping
<ubottu> cyphermox, jbicha, micahg, rbasak, sil2100, slashd, tsimonq2: DMB ping.
<coreycb> doko: thanks for the heads up on those build failures. that exposed a few remaining packages we missed with py2 drops. most of them are fixed up now and we'll fix up the remaining few as we cut new snapshots this week. ceilometerclient is slated for removal hopefully soon, bug 1836142. jamespage fyi
<ubottu> bug 1836142 in python-ceilometerclient (Ubuntu) "[RM] python-ceilometerclient" [Medium,Incomplete] https://launchpad.net/bugs/1836142
#ubuntu-devel 2019-09-10
<LocutusOfBorg> stgraber, LP: #1843383 pleeeeeeeeeeease^
<ubottu> Launchpad bug 1843383 in lxc (Ubuntu) "lxc, please bump epoch to 1" [Undecided,New] https://launchpad.net/bugs/1843383
<LocutusOfBorg> vorlon, ^^
<seb128> could people stop doing retries on duplicity/ppc64el build? it's not going to work, the tests need to be fixed
<cpaelzer> shame on me, why must x86 assembly always be so hard - does anyone know if the segement registers FS/GS are adapting size if e.g. in .code64 mode - are they still only 16bit there or bigger?
<cpaelzer> there are all kind of uses of the regs https://codesearch.debian.net/search?q=pop%5Ba-z%5D%5Cs*%25fs&literal=0 but usually in .code16 or .code32
<cpaelzer> with the new gcc in eoan this particular one using quad words fails https://codesearch.debian.net/show?file=ipxe_1.0.0%2Bgit-20190125.36a4c85-1%2Fsrc%2Farch%2Fx86_64%2Fcore%2Fgdbidt.S&line=161
<cpaelzer> but it is in .code64 unlike most of the others
<cpaelzer> gcc seems to be happy with popw and I now wonder if this is a false positive by gcc on FS/GS being 16bit or if this really never changes size
<cpaelzer> what makes this more awkward in .code32 the pushl/popl (32bit) seem to be working
<rafaeldtinoco> cpaelzer: amd did something to fs/gs in amd64, abandoning its original purpose since nobody used segmentation anylonger
<rafaeldtinoco> im not sure what though
<cpaelzer> I know that it is reused
<cpaelzer> for cpu local storgae and such
<cpaelzer> but I need the size
<rafaeldtinoco> I see
<cpaelzer> I might find the size if I read the related kernel source thou ...
<rafaeldtinoco> cpaelzer: so... since you are here..
<rafaeldtinoco> have u ever seen a HW instruction that does not return
<cpaelzer> yet so far - always I see code doing 1. switch to 16bit then 2. use small push/pop
<rafaeldtinoco> and program counter stays in the same address
<rafaeldtinoco> over and over after preempted by sched
<cpaelzer> yes I have seen that
<rafaeldtinoco> and it goes back to that pc and stays there
<cpaelzer> which arch rafaeldtinoco?
<rafaeldtinoco> etc etc
<rafaeldtinoco> aarch64
<rafaeldtinoco> I think huawei microcode for cmpxchg is broken
<rafaeldtinoco> :o)
<cpaelzer> this is exactly the kind of instructions youd expect such a bug
<rafaeldtinoco> => 0x0000aaaaaabd4110 <+32>:    stlxr   w2, w1, [x0]
<cpaelzer> not on e.g. an add
<rafaeldtinoco> if I move by hand the program counter
<rafaeldtinoco> it moves and continues
<rafaeldtinoco> until there is another instruction
<rafaeldtinoco> of the same kind
<rafaeldtinoco> :o)
<rafaeldtinoco> i'll check w/ them in public bug
<cpaelzer> rafaeldtinoco: https://community.arm.com/developer/tools-software/oss-platforms/f/dev-platforms-forum/5316/issue-with-stxr-in-armv8
<rafaeldtinoco> cpaelzer: somehow I was expecting a timeout to instruction generating an exception, NMI like
<cpaelzer> there it only behaved that way when it was single stepping
<rafaeldtinoco> cpaelzer: yep, ive read that
<rafaeldtinoco> looks like STLXR has some peculiarities
<rafaeldtinoco> and undefined behavior under certain conditions
<rafaeldtinoco> but I was expecting some timeout/exception approach
<cpaelzer> ok, then a public bug with the manufacturer seems right
<rafaeldtinoco> yep, Ill read more about those peculiarities and ask them
<rafaeldtinoco> thx
<rafaeldtinoco>    0x0000aaaaaabd4108 <+24>:    ldaxr   w1, [x0]
<rafaeldtinoco>    0x0000aaaaaabd410c <+28>:    orr     w1, w1, #0x1
<rafaeldtinoco> => 0x0000aaaaaabd4110 <+32>:    stlxr   w2, w1, [x0]
<rafaeldtinoco> cpaelzer: does it look weird to you
<rafaeldtinoco> ORring w1 in between ldaxr and stlxr ?
<rafaeldtinoco> x0 is target address, w1 is the value to be written ..
<rafaeldtinoco> so nope
<rafaeldtinoco> its just a xor of the value read to be written
<rafaeldtinoco> nm
<rafaeldtinoco> and then a brunch if not success, got this
<rafaeldtinoco> omg, armv8 docs have ~4pages for unpredictable errors for ldxar<->stlxr combination
 * rafaeldtinoco goes for a coffee
<ahasenack> rbasak: hi, we have some php deps in universe again: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#php-defaults
<ahasenack> php7.2-dev is in main, for example
<rbasak> ahasenack: I think those binary packages are in mismatched components between src:php-defaults and src:php7.3
<ahasenack> rbasak: is this the report? https://people.canonical.com/~ubuntu-archive/component-mismatches
<rbasak> ahasenack: if they're moved to match Disco then I think that'll resolve it
<ahasenack> if yes, I don't understand its output: it just says "https://people.canonical.com/~ubuntu-archive/component-mismatches" for php7.3 (src)
<rbasak> ahasenack: https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed
<ahasenack> aha
 * ahasenack updates bookmark
<rbasak> Both are relevant, but as packages we want are stuck in proposed, the proposed one is needed to make sense of it
<ahasenack> looks like they are listed there
<cpaelzer> ahasenack: I work on the list of FTBFS sent by doko - do you mind if i grab squid as you usually work on it?
<ahasenack> cpaelzer: I have a branch for that already
<ahasenack> but maybe your fix is nicer? I'm just dropping that include file, it's not used anymore in that file that failed the build
<ahasenack> cpaelzer: https://code.launchpad.net/~ahasenack/ubuntu/+source/squid/+git/squid/+ref/eoan-squid-ftbfs-glibc-230 is my fix
<ahasenack> I wanted to wait a bit for an upstream comment
<ahasenack> ppa at https://launchpad.net/~ahasenack/+archive/ubuntu/squid-ftbfs-glibc-230
<cpaelzer> ahasenack: I haven't started on this one yet
<cpaelzer> so my branch can't be nicer
<cpaelzer> i have done dovecot-antispam (no issue), ipxe (fix in upstream review) and dnsmasq (MP is up for review)
<cpaelzer> ahasenack: your fix looks ok to me
<cpaelzer> waiting for upstream feedback seems right
<cpaelzer> looking for another one in this list then ...
<rafaeldtinoco> cpaelzer: i might need to 1:1 w/ you later today (after daily ?)
<rafaeldtinoco> want to check if out-of-order have caused this issue
<cpaelzer> before would be preferred
<rafaeldtinoco> before ?
<rafaeldtinoco> 30 min ?
<cpaelzer> yes
<cpaelzer> ok for me
<rafaeldtinoco> good, will ping u tks
<cpaelzer> in ~37 from now
<rafaeldtinoco> +1
<rafaeldtinoco> HA.. I think I found the issue
<rafaeldtinoco> #)
<rafaeldtinoco> \o/
<rafaeldtinoco> cpaelzer: nm on 1:1, ill let u free
<rafaeldtinoco> :o) I have to test a few things now
<rafaeldtinoco> by re-generating the pkgs so..
<cpaelzer> hehe
<rafaeldtinoco> wont bother u
<cpaelzer> ok
<rafaeldtinoco> https://bugs.launchpad.net/qemu/+bug/1805256/comments/14
<ubottu> Launchpad bug 1805256 in qemu (Ubuntu) "qemu-img hangs on high core count ARM system" [Medium,In progress]
<rafaeldtinoco> if you want to read and review findings
<rafaeldtinoco> if it makes sense etc
<rafaeldtinoco> but only if you have extra time what you might not
<rafaeldtinoco> i think we are missing "volatile" keyword
<rafaeldtinoco> for some local variables being read_once()
<rafaeldtinoco> :)
<rafaeldtinoco> optimization made XOR instruction 0x1 always
<rafaeldtinoco> when it might be 0x0
<rafaeldtinoco> changed by other thread
<enyc> Hrrrrrrrm,  anybody give me a $clue  why  ubuntu's  libgnutls28-dev   in 14/16/18.04 LTS   seems to WORK for modern TLS negotiation with 'tf5' package client built against  libgnutls-openssl-dev  ,  whereas debian's  similar libgnutls28-dev  doesn't work right ....   I may track down EVENUTALYL  but wondered if anybody was aware that ubuntu patched gnutls defaults for openssl-header apps or
<enyc> what-have-you! ....
<rafaeldtinoco> cpaelzer: does qemu build ok in arm64 ? (ask you because of s390 firmware cross compilation thing)
<rafaeldtinoco> how can I bypass the s390 stuff and still generate the builds ?
<cpaelzer> rafaeldtinoco: you only need the arch part and not the indep part
<cpaelzer> rafaeldtinoco: see the targets in d/rules
<rafaeldtinoco> #) alright
<rafaeldtinoco> yep yep
<rafaeldtinoco> tks
<cpaelzer> by design/chance indep today is run on x86 on LP and happens to work
<cpaelzer> this and a few other packages would break if that would be different
<cpaelzer> which is why the s390x bits use cross compile
<rafaeldtinoco> gotcha
<cpaelzer> the x86 bits of indep should use cross as well, then they would work everywhere
<ahasenack> slashd: hi, is https://bugs.launchpad.net/ubuntu/+source/net-snmp/+bug/1843032 a duplicate of https://bugs.launchpad.net/ubuntu/+source/net-snmp/+bug/1843036 ?
<ubottu> Launchpad bug 1843032 in net-snmp (Ubuntu) "Storage graph error" [Undecided,Incomplete]
<ubottu> Launchpad bug 1843036 in net-snmp (Ubuntu Disco) "[regression] SNMP missing disks in hrStorageTable" [High,Fix committed]
<slashd> ahasenack, yeah look like this bug is related to the regression I fixed (now found in -proposed)
<ahasenack> slashd: ok, I'll point the user that way
<slashd> ahasenack, tks
<bryce> vorlon, I gathered from lp #1842969 that the django version should be removed?  I filed #1843355, but wanted to get your confirmation on this course of action before proceeding.
<ubottu> Launchpad bug 1842969 in python-django (Ubuntu) "python-django 2.2.4 not for eoan" [Undecided,Confirmed] https://launchpad.net/bugs/1842969
<vorlon> bryce: the block-proposed bug was filed to make sure it didn't accidentally make it into the eoan release, but post-eoan we would want the package still be in -proposed so that it can be released once its revdeps are sorted, without there having to be a new version uploaded to unstable
<vorlon> ... in practice there has been a new version uploaded to unstable
<vorlon> so we could just remove it
<vorlon> and close the blocking bug
<bryce> vorlon, ok, what can I do to help with removing it?
<tpokorra> I am trying to request a sync of mono-complete from Debian unstable to Ubuntu. Now it seems that mono-complete lives from eaon in Universe, but I don't know how to specify that in the requestsync command. I tried: requestsync -d sid mono-complete "eoan universe"
<cjwatson> tpokorra: you don't need to specify universe
<tpokorra> cjwatson, but it tells me it is a new package then
<tpokorra> https://packages.ubuntu.com/de/eoan/mono-complete says it is in universe
<cjwatson> shouldn't - what's the full output?
<cjwatson> oh, that's a binary package name
<cjwatson> requestsync works on source package names
<cjwatson> the source package name is 'mono'
<cjwatson> tpokorra: ^-
<cjwatson> also see https://bugs.launchpad.net/ubuntu/+source/mono/+bug/1841784
<ubottu> Launchpad bug 1841784 in mono (Ubuntu) "Update to 6.0.0.319 not this cycle" [Wishlist,Triaged]
<cjwatson> ah, though that's for a newer version than is in unstable
<tpokorra> cjwatson, yes. your hint with the package name solves my issue
<tpokorra> yes I would like to get the latest version from unstable, with a little patch, into Ubuntu
<cjwatson> looks like a reasonable set of changes to me
<cjwatson> request the sync and I'll ack it
<tpokorra> cjwatson, that would be great. somehow it is missing the dfsg-5.changelog, but there is only dfsg-4 in unstable
<tpokorra> perhaps I need to wait, it is only since yesterday
<cjwatson> tpokorra: it's recent enough that you'll have to wait a bit, yes
<tpokorra> ok. I will come back soon :)
<tpokorra> thanks you very much for your help, cjwatson!
<cjwatson> will work as soon as https://launchpad.net/debian/+source/mono shows -5
<tpokorra> cjwatson, it seems that dsfg-4 has already been submitted to branch eoan-proposed. https://code.launchpad.net/~usd-import-team/ubuntu/+source/mono/+git/mono/+ref/ubuntu/eoan-proposed
<tpokorra> so is the sync already happening?
<doko> sforshee, apw: are riscv64 builds broken with 5.3? LP: #1843458
<ubottu> Launchpad bug 1843458 in cross-toolchain-base-ports (Ubuntu) "linux 5.3 breaks building glibc for riscv64" [High,Confirmed] https://launchpad.net/bugs/1843458
<rbasak> +1 for iptables revert FWIW. It's the job of the distribution to coordinate, and having it move "by accident" and then scramble is hardly coordination.
<WoC> Which card would you recommend for OpenCL that has drivers that actually work and won't rape my wallet? pcie x16
<ahasenack> cjwatson: hi, openssh showed up in our server page as being stuck in migration:
<ahasenack> openssh-server/amd64 unsatisfiable Depends: runit-helper (>= 2.8.14~)
<ahasenack> that package is in universe
<ahasenack> +               dh-runit (>= 2.8.8), <-- was added in 8.0p1-5
<ahasenack> LocutusOfBorg: ^ you synced that from debian this past weekend?
<WoC> Captain Picard, greetings;)
<LocutusOfBorg> ahasenack, already discussed and MIR opened for runit...
<ahasenack> LocutusOfBorg: ok, it showed up in our list at https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#ubuntu-server
<ahasenack> LocutusOfBorg: https://bugs.launchpad.net/ubuntu/+source/dh-runit/+bug/1843236 right?
<ubottu> Launchpad bug 1843236 in dh-runit (Ubuntu) "[MIR] runit-helper" [Undecided,New]
<Odd_Bloke> WoC: Hi, this channel is for the development of Ubuntu itself, so isn't the right forum for that question.  Perhaps try in #ubuntu?  (I would also ask you to reconsider casual use of language pertaining to sexual assault, as a matter of basic decency.)
<WoC> K ty
<stgraber> xnox, juliank: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1843468
<ubottu> Launchpad bug 1843468 in iptables (Ubuntu) "nftables based iptables wrapper break userspace" [Critical,Triaged]
<ahasenack> bryce: hi, I just filed https://bugs.launchpad.net/ubuntu/+source/fetchmail/+bug/1843474 which affects us too
<ubottu> Launchpad bug 1843474 in fetchmail (Ubuntu) "/usr/bin/fetchmailconf not completely removed" [Undecided,New]
<bryce> ahasenack, ok
<juliank> Thanks stgraber
<rbasak> I just saw wireguard enter eoan-proposed \o/
<sarnold> woot; do you know off-hand if we're getting the kernel config turned on too?
 * rbasak doesn't know
<ahasenack> bryce: so about that horde error,
<ahasenack> I found this:
<ahasenack>  /usr/share/php/Horde/Test/Case.php:class Horde_Test_Case extends PHPUnit\Framework\TestCase
<ahasenack> that's where that class is being defined
<bryce> ahasenack, right
<ahasenack> yet I still got
<ahasenack>  /tmp/autopkgtest.y3OCQg/phpunit-stderr:PHP Fatal error:  Uncaught Error: Class 'Horde_Test_Case' not found in /tmp/autopkgtest.y3OCQg/build.dRo/real-tree/Horde_Text_Filter-2.3.6/test/Horde/Text/Filter/LinkurlsTest.php:11
<bryce> ahasenack, what I found is if I added a require Horde/Test/Case.php; at the top of the file, then that error would be resolved (I guess?)
<ahasenack> does this fail with php 7.2?
<ahasenack> do we know that?
<bryce> ahasenack, however then I got a slew of errors with all the other tests, that Horde_Text_filter not found
<bryce> checking...
 * ahasenack checks last green
<bryce> looks like it has been failing since before the transition
<ahasenack> it passed with phpunit 7.5.3
<ahasenack> we now have 7.5.6
<bryce> yes you're right, phpunit all 7.5.3-1
<ahasenack> php-horde-test was the same
<ahasenack> 2.6.3+debian0-3ubuntu1
<ahasenack> that's what is defining that class
<bryce> phpunit_renamed_phpunit_classes.patch has:
<bryce> -class Horde_Test_Case extends PHPUnit_Framework_TestCase
<bryce> +class Horde_Test_Case extends PHPUnit\Framework\TestCase
<bryce> ahasenack, aha think I know what needs done
<bryce> (wish we had a better tool for managing trigger tweaks...)
<ahasenack> what is it?
<ahasenack> and that \ hurts my eyes, no idea what is going on with that replacement
<bryce> the \ is php's namespacing mechanism
<bryce> so it's moving from a simple class named "PHPUnit_Framework_TestCase" in the top level namespace, to a class called TestCase inside the Framework namespace, which is itself under PHPUnit
<bryce> ahasenack, I've queued up -ansel/amd64 to test my theory, if it works I'll rebuild the rest
<ahasenack> ok
<ahasenack> bryce: by "queued", do you mean uploaded, or added as a test trigger or something?
<ahasenack> this thing is failing in debian ci as well
<ahasenack> also an error about an unknown class, just not the same one
<ahasenack> bryce: the green runs of php-horde-ansel are using libapache2-mod-php7.3, whereas the red one is using libapache2-mod-php7.2
<ahasenack> libapache2-mod-php comes from php-defaults
<ahasenack> the only red in php-defaults is our friend php-horde-text-filter
<bryce> ahasenack, sorry, 'triggered' I suppose is the better term
<bryce> ok looks like the test worked, I'll trigger the rest
<bryce> interestingly, even though I only ran -ansel/amd64, everything switched to green which is weird, but I think false positive
<ahasenack> bryce: hope it's better by tomorrow :)
<ahasenack> I'm eod'ing, cya
<bryce> cya
#ubuntu-devel 2019-09-11
<rbasak> mysql-router (from src:mysql-8.0) ships /usr/bin/mysql-router which needs some shared objects
<rbasak> They don't need to be shared objects because nothing except /usr/bin/mysql-router loads them. I'm not sure I'd call them plugins either.
<rbasak> libmysqlrouter.so.1 is one of them. But it's strictly internal.
<rbasak> I stuffed them inside /usr/lib/mysql-router/ to try to keep them away from public use.
<rbasak> Do you think that's acceptable, or should packaging go further?
<Skuggen> ^ we want to clean this up upstream, but I have no clear idea of how long it would take
<doko> seb128, xnox: the mismatches graph for duplicity changed, lockfile now a direct dependency of duplicty after my lockfile upload. I think the python2.7 dependency comes from the missing ppc64el build
<xnox> doko:  ah
<seb128> ah, good, we just need someone to sort that one out then
<ahasenack> bryce: did you trigger php-horde-text-filter already?
<ahasenack> I think we need it in two places: itself, and under php-deaults
<ahasenack> php-defaults*
<rbasak> cpaelzer: around still? About bug 1840872
<ubottu> bug 1840872 in The Ubuntu-power-systems project "ISST-LTE:KVM:Ubuntu1804:BostonLC:boslcp3g5: libvirt fails to check for duplicate address in hotplug xml and causes the guest to go to shutoff state" [High,In progress] https://launchpad.net/bugs/1840872
<rbasak> "causes the guest to go to shutoff state" sounds like an SRU is justified assuming it's the wrong behaviour
<rbasak> But that doesn't seem to be in your test case?
<rbasak> Should we be verifying that in the failure case the guest is stopped and in the expected case the guest is still running?
<ahasenack> when a package has no debian/tests directory, but its control file declares "Testsuite: autopkgtest-pkg-ruby", what exactly is run?
 * ahasenack reads https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst in the meantime
<bryce> ahasenack, yep I've triggered it for itself, will be keeping an eye out.  I wonder if php-defaults will then clear automatically or will need another trigger but we'll see.
<ahasenack> I see, autodep8
<ahasenack> bryce: if that gets green, it should migrate, unless there are issues in update_output.txt
<cpaelzer> rbasak: the guest isn't "shut off"
<cpaelzer> it is bad behavior
<cpaelzer> and it could in the long run cause issues which might kill and therby shut it off
<cpaelzer> but the testcase description is the short term test (without waiting for later issues) and fine vor the verification
<cpaelzer> rbasak: I have that on my list to verify already
<cpaelzer> I sometimes just hope that the reporters would actually care
<rbasak> cpaelzer: what abou the user impact for SRU policy justification?
<bryce> ahasenack, you probably already saw but the php-horde-text-filter test case failure persisted through the re-triggered runs
<Unit193> Odd_Bloke: Howdy!  Re: LP 1840483, there won't be a new release in time for Eoan, but there's been a few commits you could grab if you feel a fix is important.
<ubottu> Launchpad bug 1840483 in barrier (Ubuntu) "barriers leaks memory when clients with duplicate names attempt to connect" [Undecided,New] https://launchpad.net/bugs/1840483
#ubuntu-devel 2019-09-12
<DarkTrick> General question: Why is bugzilla necessary, if there is launchpad?
<DarkTrick> As my understanding, bug reports can be filed with both, but launchpad seems to also include a deploy mechanims.
<sarnold> launchpad was written because bugzilla wasn't the kindest thing to work with
<DarkTrick> what would now be the difference between filing a bug in bugzilla vs filing one in launchpad?
<DarkTrick> e.g. thunar bugs can be filed in both systems
<Unit193> thunar is part of Xfce, they use bugzilla as their tracker whereas Launchpad is Ubuntu's bugtracker for *distro* bugs.  If you're asking "Why don't they set up Launchpad?" well that's much easier said than done, I'm only aware of one instance ever.  It's basically open core, not made for others to set up a clone.
<Unit193> (In time, Xfce may move to Gitlab and its "issue" system)
<DarkTrick> Unit193, "distro bugs" are bugs related to the interaction between the software/package and the distro?
<DarkTrick> For example: thunar crashes on raspi .... ?
<Unit193> DarkTrick: I'd try the latest one, if it's still an issue then I'd report on upstream's tracker.
<DarkTrick> Unit193, that was just an example to check, if I understood it correctly
<DarkTrick> but if I understand you right, you would report a "thunar crash on raspi" to bugzilla of thunar (as it is their bug-tracker)
<Unit193> After checking the latest released version*
<DarkTrick> So, what would be a "distro bug" then?
<DarkTrick> (I don't see a dividing line)
<Unit193> Sometimes it's a configuration or integration issue, or if you don't check the latest version.  (It doesn't help that I assist with maintaining thunar, soo.)
<Unit193> Different people see that line differently.
<DarkTrick> Unit193, thank you
<sarnold> Unit193: heh, you know I've actually seen another launchpad instance up somewhere in the wild..
<Unit193> sarnold: I know which one, because there's only one! :P
<sarnold> Unit193: hah. of course you do :D I shoulda known.
<Unit193> Granted, I have to *find* it every time...And to be fair, there's a chance you linked me the initial time.
<sarnold> but if you can find it again, that's something. :)
<Unit193> You mean, https://quickbuild.io/ ?
<Unit193> I didn't think it was really updated, but https://quickbuild.io/~kb9vqf/+archive/ubuntu/mythtv-029 seems to indicate it is.
<sarnold> Unit193: there we go!! that's the one :)
<cpaelzer> rbasak: the SRU template that I added already is correct
<cpaelzer> rbasak: just ignore the exagerrated initial report
<cpaelzer> mruffell: I don't immediately see the issue
<cpaelzer> mruffell: is this reproducible, e.g. if you just retry the build?
<mruffell> cpaelzer: yes, it is
<cpaelzer> what is the config of that PPA that you use?
<cpaelzer> any odd dependencies enabled?
<mruffell> it is reproducible on each build
<mruffell> the only strange thing is a private ppa, let me check deps
<mruffell> there are no dependencies enabled
<cpaelzer> I'm comparing it to the last good build now ...
<mruffell> on the last good build, posix_openpt and openpty both PASS
<cpaelzer> mruffell: just to eliminate differences, can you on the ppa enable proposed in the dependencies
<cpaelzer> because that is how the e.g. SRUs will build
<cpaelzer> I'm not really expecting this to be the difference
<cpaelzer> that breaks it
<mruffell> okay, I have resubmitted the build with -proposed enabled
<mruffell> cpaelzer: if you are wondering, I'm making a test package for LP 1681839, which someone is now experiencing on xenial. We have a solid reproducer now.
<ubottu> Launchpad bug 1681839 in libvirt (Ubuntu Bionic) "libvirt - disk not ready for pivot yet" [Medium,Fix released] https://launchpad.net/bugs/1681839
<cpaelzer> mruffell: I have prepped and kciked a local build and a PPA rebuild test of my own - just to be sure; continuing checking the logs now
<cpaelzer> oh the solid reproducer surely was a great help
<cpaelzer> but I'd try to help you no matter what - no need to explain :-)
<mruffell> =)
<cpaelzer> next difference, the PPA is not building debug symbols - that aagin should make no difference - but I see DEB_BUILD_OPTIONS=noautodbgsym...
<cpaelzer> the next obvious diff are your 4 patches
<cpaelzer> for the sake of eliminating options, have you tried rebuilding without them?
<mruffell> the 4 patches are to the same file, and should have no effect on the openpt testcase
<mruffell> but I haven't yet
<mruffell> it fails with -proposed added, on the same openpt tests
<cpaelzer> It sounds vaguely familiar, like failing these tests on container based builds on armhf in the past
<cpaelzer> but why should that hit these builds now ... ?
<mruffell> google brought me to LP 1641615 since it mentions the same failing testcase
<ubottu> Launchpad bug 1641615 in libvirt (Ubuntu) "gnutls api breakage in 3.5.6" [High,Fix released] https://launchpad.net/bugs/1641615
<mruffell> but you resolved that years ago
<cpaelzer> heh - I know that guy
<cpaelzer> mruffell: https://salsa.debian.org/libvirt-team/libvirt/commit/2be70b3 ?
<mruffell> hmmm intriguing
<mruffell> I'll add the patches and give it a go
<cpaelzer> sure, but you should know that my rebild test started to complete builds successful https://launchpad.net/~paelzer/+archive/ubuntu/xenial-test-rebuilds/+packages
<cpaelzer> no amd64 yet, but ppc & s390x are good already
<mruffell> even more interesting
<cpaelzer> still - try that patch just so we know if it would help your case
<cpaelzer> ha and x86 fails
<cpaelzer> same reason
<cpaelzer> some of the bumps in Xenial to the libs might have made it an FTBFS there
<cpaelzer> or changes in the build env, but I'd not have heard of any
<cpaelzer> mruffell: I can even recreate the same locally in sbuild
<cpaelzer> as there the chroot has the same attributes
<mruffell> interesting, my xenial vm doesn't recreate it. Its not fully patched though
<cpaelzer> nono in a VM you'd have full pty
<cpaelzer> only triggers in chroots
<cpaelzer> like sbuild/pbiuld/...
<cpaelzer> mruffell: I'm already building with the fix I linked applied
<cpaelzer> I should know in ~3-5 minutes if this is a fix to the FTBFS
<mruffell> cpaelzer: same here. Just submitted a second ago
<cpaelzer> if that turns out to be true we just open a bug and you can tag and close it with your upload
<mruffell> sounds like a good plan
<cpaelzer> mruffell: fix doesn't apply cleanly to xenial
<cpaelzer> ../../../../gnulib/tests/test-openpty.c:47:24: error: 'ENENT' undeclared (first use in this function)
<mruffell> fun times.
<cpaelzer> mruffell: I have filed https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1843674 for us
<ubottu> Launchpad bug 1843674 in libvirt (Ubuntu Xenial) "FTBFS of libvirt in Xenial" [Undecided,New]
<cpaelzer> Diving into my sbuild env to check what we could do ...
<mruffell> cpaelzer: thanks for filing the bug!
<cpaelzer> ok I have it in the build env down to the gcc call that breaks
<cpaelzer> ENENT sounds wrong right?
<cpaelzer> ENOENT ?
<mruffell> yeah, ENENT is not defined in <errno.h>
<cpaelzer> yep that gets it working
<cpaelzer> there surely was a fixup later
<cpaelzer> let me check git
<cpaelzer> mruffell: https://salsa.debian.org/libvirt-team/libvirt/commit/7baa0daf8b104fa9b8dafd70dd9ec4bdd9ccee5a
<cpaelzer> and https://salsa.debian.org/libvirt-team/libvirt/commit/0ce5eb75bdeaa3ef306457a03ed74b6a6bd65cba
<cpaelzer> "recent debootstrap" might be the reason here as well
<cpaelzer> throwing that into my build as well
<mruffell> would you look at that
<mruffell> yep, let's give it a go
<cpaelzer> 'll eventually probably push you a branch somewhere to mcombine witho your work
<cpaelzer> mruffell: oh I frogot - the build works now
<cpaelzer> mruffell: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1843674/comments/2
<ubottu> Launchpad bug 1843674 in libvirt (Ubuntu Xenial) "FTBFS of libvirt in Xenial" [Undecided,New]
<mruffell> cpaelzer: excellent! Thanks again =)
<cpaelzer> doko do the issues I see with new binutils in bug 1843394 ring any bell ?
<ubottu> bug 1843394 in ipxe (Ubuntu) "FTBFS in Eoan - Error: operand type mismatch for `push' - gcc 9.2.1" [Undecided,New] https://launchpad.net/bugs/1843394
<doko> sforshee: replied to 1843458, empty linux-source package :-/
<doko> cpaelzer: I'll have a look
<ahasenack> good morning
<doko> Laney: why do you keep the pcre2 changes in vte2.91?
<Laney> doko: if you're saying they can be dropped, I didn't know that, nobody told me
<doko> Laney: well, the desktop team pushed for pcre2 promotion ...
<Laney> ok
<seb128> doko, we didn't, jbicha did iirc
<Laney> want to know the cool thing?
<Laney> it's already dropped :D
<Laney> the changelog is a copy and paste mistake
<Laney> happy doko is happy
<seb128> :)
<cpaelzer> doko: dovecot-antispam in the eoan rebild seems to be a LP infra problem
<cpaelzer> doko: I'd love to just hit rebuild at https://launchpad.net/ubuntu/+archive/test-rebuild-20190906/+build/17542928 but I can't
<seb128> doko, those ftbfs you are opening, any idea why -Wno-error=deprecated-declarations isn't working?
<doko> cpaelzer: given back, but that's the third time ...
<doko> seb128: any concrete example?
<seb128> e.g https://bugs.launchpad.net/bugs/1843744
<ubottu> Launchpad bug 1843744 in libdbusmenu (Ubuntu) "libdbusmenu ftbfs in eoan" [High,Confirmed]
<seb128> hum, I guess the failure might not be the deprecated/first error but
<seb128> ../../../libdbusmenu-glib/defaults.c:77:13: error: G_ADD_PRIVATE [-Werror]
<seb128> though that doesn't state what the error is
<rbasak> vorlon: could you delete my mysql-8.0 upload from eoan-proposed please? It didn't achieve what it was supposed to achieve, I'll be a week or two before I can get back to it, and in the meantime I understand it's entangling with other things (PHP?)
<vorlon> rbasak: I don't see it entangling anything else, what do you see?
<rbasak> bryce: ^?
<vorlon> I don't mind deleting it - but I was explicitly checking what else was entangled to know what needed no-change rebuilds if I deleted it
<rbasak> There are no API/ABI changes in mysql-8.0 between release and proposed, so I don't think no-change rebuilds would be needed?
<rbasak> otp, I'll look deeper in abit
<doko> seb128: is that symbol dropped?  maybe a warning emitted by one of the included header files?
<seb128> doko, I don't think the symbol is dropped, it's deprecated in the code just unsure why it hits a warning not a deprecated one ... I'm just going to fix the deprecation, easier, thx
<bryce> rbasak, vorlon php-horde-activesync and php-horde-db seem to have mysql ties
<doko> seb128: the deprecation warning is about g_type_class_add_private
<seb128> doko, right, it's not unclear what it doesn't like about G_ADD_PRIVATE to me
<seb128>  ../../../libdbusmenu-glib/defaults.c:77:13: error: G_ADD_PRIVATE [-Werror]
<seb128> but it doesn't tell what the error is
<cjwatson> cpaelzer: LP infra> in what way?
<cpaelzer> cjwatson: build issue without any log in https://launchpad.net/ubuntu/+archive/test-rebuild-20190906/+build/17542928 (before it was restarted)
<cpaelzer> cjwatson: and I keep saying "LP infra" when I mean builders - sorry for that
<doko> seb128: I asked you to look for a #warning statement in one of the header files ...
<vorlon> bryce: but I don't see that either of these packages are blocked in -proposed as a result of mysql-8.0 being there
<cjwatson> cpaelzer: OK, that sometimes means a network problem between buildd-manager and the builder, and sometimes means that the build ran amok and crashed the builder VM
<seb128> doko, ah ok, I didn't get that bit before, will do, thx for the hint
<bryce> vorlon, I don't know what is blocking them tbh
<vorlon> bryce: I only see php-horde-mime with a failing autopkgtest, autopkgtests test against the release versions of all other packages by default, and I don't see that the failing autopkgtests pull in mysql-8.0 from -proposed
<cjwatson> doko: third time> I think you must be misremembering; there is only one previous record of that build failing in our logs
<cjwatson> There are vaguely network-blip-like symptoms in the logs here but it's hard to be certain
<doko> cjwatson: hmm, I gave back all failed builds twice for the test rebuild ppa, but maybe one of them didn't complete
<cjwatson> That would be to be expected, I think, given that the queue is deep
<cjwatson> Lots of builds will be getting exactly the same score, and in that case the tie-breaker is first-in-first-out
<doko> jamespage: simplestreams dep-waits on python-swift. is this expected?
<powersj> doko, https://bugs.launchpad.net/ubuntu/+source/simplestreams/+bug/1841277 server will look at it next week
<ubottu> Launchpad bug 1841277 in simplestreams (Ubuntu) "please drop Py 2 OpenStack dependencies" [High,Triaged]
<doko> powersj: ta
<kyrofa> Hey folks, the robotics community is pinging me about https://bugs.launchpad.net/ubuntu/+source/urdfdom-headers/+bug/1817595 . A debdiff is attached there, can we get a pair of eyes on it? Does anything more need to happen?
<ubottu> Launchpad bug 1817595 in urdfdom-headers (Ubuntu Bionic) "[SRU] urdfdom-headers and urdfdom should not use locale dependent parsing for floating point numbers" [Undecided,New]
<kyrofa> sil2100, I suppose you're the vanguard today, huh. That's probably a question for you ^
<juliank> kyrofa: You're one step too far, the next step would be to request sponsorship
<juliank> Or well, ubuntu-sponsors is subscribed
<juliank> but like that's sponsorship territory atm, not really SRU team stuff
<juliank> IMHO This also needs a proper test case, not a Dockerfile that pulls patched versions from the PPA
<juliank> FWIW, I have no intention of sponsoring this upload, it's too complex
<kyrofa> juliank, that type of feedback would be useful in the bug, if you don't mind
<juliank> Ah, it's just my personal opinion
<juliank> I'll add some notes, though
<kyrofa> juliank, that would be excellent, thank you. Even just the feedback about proper tests would be useful
<kyrofa> I just don't know enough about SRU's to help them on their journey, best I can do is find someone who does :)
<juliank> kyrofa: basically same procedure as for normal upload, except that you test it after the upload, and that SRU team approves the uploaded package rather than release team / automatic
<juliank> and yes, version numbers are different
<juliank> kyrofa: I think the main blocker for me (when looking at sponsoring it) is that I'd want someone who commits to actually testing it and drive down any autopkgtest regressions
<juliank> As I'd be fine uploading it if you say you're committed to actually driving it, but I wouldn't want to drive that myself
<juliank> same for somebody else
<juliank> like I don't care who is committed to driving this
<kyrofa> juliank, I think Jose would commit to that, they have a vested interest in this going through, and I can  help with autopkgtest failures. I'll ask for him to state it on the bug if you like
#ubuntu-devel 2019-09-13
<LocutusOfBorg> doko, hello, do you have a plan for mono being stuck with test failure on s390x?
<cjwatson> Might be worth asking directhex (not here, I think, but should be easy to track down)
<RikMills> is it intended now that bionic users will get offered an updrage from 18.04 LTS to 19.04, if they switch to normal releases?
<RikMills> *upgrade
<rcj> Could I get a SRU sponsor for uploads of livecd-rootfs in in x/b/d for bug #1837254?
<ubottu> bug 1837254 in livecd-rootfs (Ubuntu Disco) "ubuntu-cpc parallel builds produce unused files" [Undecided,New] https://launchpad.net/bugs/1837254
<xnox> rcj:  hm i think it's all uploaded now, no?
<xnox> https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=livecd-rootfs
<xnox> https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=livecd-rootfs
<xnox> https://launchpad.net/ubuntu/disco/+queue?queue_state=1&queue_text=livecd-rootfs
<xnox> rcj:  it's just needs an SRU person to accept them now
<rcj> xnox: yes, sorry.  I need to work on my language around SRUs.
<rcj> I'm looking for an SRU team member to approve uploads for livecd-rootfs
<xnox> tjaalton:  vorlon: can you look at above packages ^ ?
<xnox> rcj:  although they both might be out travelling =/
<tjaalton> rcj: there's already a version in proposed
<tjaalton> at least disco
<rcj> tjaalton: ah.  Well, it's marked verification-done-disco and that was long enough ago.  https://people.canonical.com/~ubuntu-archive/proposed-migration/disco/update_excuses.html#livecd-rootfs is passing for everything.  Can that be pushed out to -updates now?
<tjaalton> no it wasn't
<tjaalton> bug 1836594 is unverified
<ubottu> bug 1836594 in livecd-rootfs (Ubuntu Disco) "Snaps are broken in daily images" [Undecided,Fix committed] https://launchpad.net/bugs/1836594
<rcj> shoot, didn't see that bug for it.  Let me check on it.
<rcj> I've downloaded the disco ISO and I'll verify that bug
<tjaalton> but it's also friday, and the general rule is not to release updates on a friday
<rcj> okay and I need to *build* the iso to test this, so it's not getting done today anyway.  thx
<rcj> Laney: Will you have time to validate bug #1836594 on disco by early next week?
<ubottu> bug 1836594 in livecd-rootfs (Ubuntu Disco) "Snaps are broken in daily images" [Undecided,Fix committed] https://launchpad.net/bugs/1836594
<xnox> tjaalton:  livecd-rootfs is harmless as we don't release images built with it, unless they are good. hence livecd-rootfs can always go in, and even get published i thought.
<xnox> tjaalton:  but i might be mistaking things.
<Laney> rcj: Probably - I forgot about it tbh
<Laney> do we have disco dailies? why did I upload it there?
<rcj> Laney: The breaking change landed back in disco and then was fixed.  So that has to be verified.
<Laney> right, I get the idea
<ahasenack> are the daily eoan images ok?
<ahasenack> I'm booting one via kvm, and it's stuck at "booting from hard disk"
<ahasenack> and qemu is at 100% cpu
<ahasenack> paride: are you aware of any issue?
<paride> ahasenack, server or desktop?
<ahasenack> not the iso image, the cloud image
<ahasenack> both multipass and uvt show that behavior
<ahasenack> paride: multipass launch daily:eoan -n e1
<paride> ahasenack, trying. The KVM boot-speed measurement job ran ~6 hours ago with no problems
<paride> and it runs eoan via multipass
<ahasenack> and the host?
<ahasenack> my host is bionic
<paride> that's on bionic too
<ahasenack> my kernel is 4.15.0-62-generic #69
<paride> ahasenack, Launched: e1
<paride> just tried on: Linux dugtrio 4.15.0-62-generic #69-Ubuntu SMP Wed Sep 4 20:55:53 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
<ahasenack> hmpf
<paride> and it actually works (I can multipass exec stuff)
 * ahasenack stuck without able to run a test with an eoan kernel
<ahasenack> let me try diglett
<Laney> rcj: I guess I have to build a new disco desktop iso. I'll do that. Is someone going to be able to verify the other bugs?
<paride> ahasenack, remember that you can login to dugtrio too, if that helps
<rcj> Laney: 1836594 is the only bug that still needs verification
<rcj> unless I'm missing something
<Laney> Guess it could have been done with a home cooked image...
<Laney> OK, if the SRU team are happy with that (the verification comments are light on details), then fine
<tjaalton> rcj: true
<tjaalton> err, xnox ^
<vorlon> xnox: no sorry, travel swap
#ubuntu-devel 2019-09-15
<karlthane> Hello, trying to help test. Downloaded the current daily iso for 19.10, not giving option to install to zfs in installer. Is there something special I have to do. Sorry if this is wrong channel.
<valorie> karlthane: try #ubuntu+1
<caribou> Hello, I'm preparing an SRU upload of systemd for LP: #1805183. Anybody has something inflight on systemd ?
<ubottu> Launchpad bug 1805183 in systemd (Ubuntu Bionic) "systemd-resolved constantly restarts on Bionic upgraded from Xenial" [Medium,In progress] https://launchpad.net/bugs/1805183
<tomreyn> gnupg2 (as well as gnupg, i.e. v1) in bionic fails to handle keys without user ids, as provided by the (only, as far as i know) key spam safe openpgp server keys.openpgp.org, which most applications now default to.
<tomreyn> so it's not currently possible to use a safe keyserver in bionic, from what i can tell.
<tomreyn> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930665
<ubottu> Debian bug 930665 in gpg "gpg won't import valid self-signatures if no user ids are present in imported transferable public key" [Important,Fixed]
<TJ-> tomreyn: I find that vulnerabilty useful... as I have multiple IDs if the same email arrives for multiple IDs it gets deleted instantly by procmail
<tomreyn> TJ-: well, that's not so useful to me ;)
<TJ-> hehehe
<TJ-> tomreyn: so is it no longer possible to search by userid to find a key?
<TJ-> tomreyn: hmm, is that keyserver not connected to the pool? it doesn't find my key
<tomreyn> TJ-: it is not connected to the SKS pool. are you aware of the signature spamming issues?
<tomreyn> i just filed bug 1844055 about the above.
<ubottu> bug 1844055 in gnupg2 (Ubuntu) "Importing public key from keys.openpgp.org fails with "no user ID" " [Undecided,New] https://launchpad.net/bugs/1844055
<TJ-> tomreyn: you mean the email addresses being harvested for spam? Yes, seen it for a long time which is why I have procmail rules to block it
<TJ-> tomreyn: hashes the subject and counts for all IDs in the keys
<tomreyn> TJ-: no, i don't mean e-mail addresses harvested for spam. i mean the issue known as (variants of) OpenPGP certificate (key signature) flooding / spam. I added more context to the bug report now.
<TJ-> tomreyn: ahhh, thanks, so adding lots of signatures to a key as a DoS because clients cannot cope with the quantity?
<tomreyn> TJ-: yes, this sums up CVE-2019-13050, mitigation of which got deferred https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2019-13050.html
<ubottu> Interaction between the sks-keyserver code through 1.2.0 of the SKS keyserver network, and GnuPG through 2.2.16, makes it risky to have a GnuPG keyserver configuration line referring to a host on the SKS keyserver network. Retrieving data from this network may cause a persistent denial of service, because of a Certificate Spamming Attack. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13050)
<TJ-> tomreyn: reading about the unmaintained 'toy' SKS software and the fact 2 key devs of openpgp have known about this for 10 years... I dispair!
<TJ-> I despair, too!
<tomreyn> yes, it's overall a sad situation. :/
<TJ-> the argument 'no-one can understand the code' is a poor one though; that is always possible if sufficient time is applied
<tomreyn> i wouldn't personally claim to be able to do so, not now, nor anytime soon. but certainly time, accompanied by other resources, such as knowledge and experience, money, could. the argument resting within this, that infrastructurally important or at least relevant software should be written in a widely understood programming language, accompanied by good documentation. (this said, i'm very grateful to kfiskerstrand and other contributors to
<tomreyn> the SKS keyserver code and network over the years.)
<tomreyn> s/within this , that/within this is that/
<tomreyn> and we should move to -discuss.
<karlthane> @valorie Thank You
<udevbot> Error: "valorie" is not a valid command.
<karlthane> valorie Thank you.
<Eickmeyer> cyphermox: Still no movement on bug 184319?
<ubottu> bug 184319 in GetDeb Software Portal "Update Package: alarm-clock 0.5" [Wishlist,Fix released] https://launchpad.net/bugs/184319
<Eickmeyer> Oh, wrong bug...
<Eickmeyer> cyphermox: bug 1843196
<ubottu> bug 1843196 in ubiquity-slideshow-ubuntu (Ubuntu) "[Merge Request] Updated Ubuntu Studio Slideshow" [Undecided,New] https://launchpad.net/bugs/1843196
