#ubuntu-devel 2005-07-18
* lamont__ larts daniels
<lamont__> xresprobe on ia64/hoary is busticated - X asked me a question.
<lamont__> oo.o even runs... woot
<lamont__> hrm... ia64 hotplug seems to not like the hoary-security kernel very much
<trulux> mako: ping
<daniels> oh my god
<daniels> xkeyboard-config has its own XML parser in Perl
<wasabi> Hmm.
<HrdwrBoB> wtf
<daniels> thanks guys
<wasabi> We totally need an ubuntu-crack mailinglist.
<daniels> we needed another one of those
<wasabi> Where people can just post "Cool Shit."
<wasabi> "omg wobbly windows, w00t", etc.
<wasabi> Basically I find searching for crack to be frought with frustration.
<daniels> yet you have to have XML::Parser installed ANYWAY because of intltool
<daniels> so much hate
<daniels> also, they hardcode prefix=/usr into their configure.in, and it also has this gem:
<daniels>   --enable-xkbcomp-symlink      create xkbcomp symlink to $(xkb_base)../../../bin/xkbcomp
<daniels> it creates that symlink no matter what you do, and that breaks horribly when xkb_base isn't /usr/X11R6/lib/X11/xkb
<daniels> but it's OK
<daniels> i didn't care about having anything actually work anyway
* daniels ruminates on --enable-xkbcomp-symlink=no.
<schweeb> daniels: nice philosophy
<schweeb> lol
* daniels removes xlibs, giggles.
<luis_> daniels: ?
<daniels> luis_: YES, MASTER
<daniels> luis_: (be warned, rhythmbox shuffle put on some mind-blowing drum n bass way too early in the morning, so I'm kind of in a stupid mood)
<luis_> haha
<daniels> also I'm kind of high on removing shit from xorg
<luis_> current libxv dev packages don't seem to have .h files- known?
<daniels> xbase-clients?  NOT ANY MORE
<daniels> luis_: yeah, waiting on some NEW action
<daniels> i think
<luis_> OK, cool
<luis_> just wanted to make sure it was knonw
* luis_ has a gstreamer build that is FREAKING OUT, MAN
<daniels> *cough*
<daniels> daniels@brainfreeze:~/canonical/xorg/monolith/xorg-6.8.2/debian% (dpkg-deb -c ~/canonical/xorg/proto/x11proto-video/x11proto-video-dev_2.2+cvs.20050712-1_all.deb && dpkg-deb -c ~/canonical/xorg/lib/libxv/libxv-dev_2.2.0+cvs.20050712-1_amd64.deb) | grep usr/include/X11/extensions
<daniels> drwxr-xr-x root/root         0 2005-07-12 11:30:29 ./usr/include/X11/extensions/
<daniels> -rw-r--r-- root/root      5478 2005-07-12 11:30:28 ./usr/include/X11/extensions/vldXvMC.h
<daniels> -rw-r--r-- root/root      3123 2005-07-12 11:30:28 ./usr/include/X11/extensions/Xv.h
<daniels> -rw-r--r-- root/root      3730 2005-07-12 11:30:28 ./usr/include/X11/extensions/XvMC.h
<daniels> -rw-r--r-- root/root      4981 2005-07-12 11:30:28 ./usr/include/X11/extensions/XvMCproto.h
<daniels> -rw-r--r-- root/root     13225 2005-07-12 11:30:28 ./usr/include/X11/extensions/Xvproto.h
<daniels> drwxr-xr-x root/root         0 2005-07-12 11:35:02 ./usr/include/X11/extensions/
<daniels> -rw-r--r-- root/root     10301 2005-07-12 11:35:02 ./usr/include/X11/extensions/Xvlib.h
<daniels> so when you get those two, you should be sweet
<daniels> (and libxvmc-dev 1.something+cvs.20050712-1 has XvMClib.h)
<luis_> cool thanks
<Amaranth> "If I get one more email/bug report/flame from some idiot about how libaspell15c2 has broke their KDE or some shit because it conflicts with libaspell15, I might have to break more than just their KDE."
<Riddell> Amaranth: what's the problem?  is some part of KDE using a pre c++ transition libapsell?
<Amaranth> Riddell: No, it's a Debian developer. :)
<Amaranth> just thought it'd get a chuckle seeing how ubuntu just went through all that
<Riddell> aah, yes, fun stuff
<daniels> KKKKKKEEEEEEEEEEEEEEEYYYYYYYYYYYYYYYYYYYBBBBBBBBBBBBBBBBBBBBBBUUUUUUUUUUUUUUUUUUUUUUKKKKKKKKKKKKKKKKKKKKKKKKK
<daniels> Keybuk: dude!
<daniels> Keybuk: you told me dpkg had support for migrating conffiles :(
<poningru> I had a question
<poningru> why dont dpkg have double click install feature?
<poningru> I asked before but didnt get an answer
<Amaranth> poningru: afaik it's just a mime issue
<crimsun> dpkg doesn't, but Kynaptic and Synaptic do
<poningru> crimsun: what do you mean?
<poningru> for that wouldnt you need synaptic to run always?
<poningru> also Amaranth why not just fix that then?
<crimsun> poningru: I don't have context of your original question, so I have to address it in this vacuum.
<poningru>  why dont dpkg have double click install feature?
<poningru> thats my original question
<crimsun> dpkg is a command line application. It would be rather disastrous to make it have a double-click install feature.
<Amaranth> He wants double-click install, which imo is a security risk.
<daniels> this is probably not a #ubuntu-devel question
<crimsun> true
<poningru> just ask for passsword 
<poningru> oh
<poningru> where should I move it to?
<poningru> and will you guys follow?
<poningru> crimsun: I am talking about .deb files
<poningru> I think
<crimsun> move this to #ubuntu, please
<calc> daniels: is xserver-xorg going to move the remaining files out of /usr/X11R6/bin ?
<daniels> calc: when it gets modularised, yes
<calc> oh ok
<calc> so is the entire /usr/X11R6 going away after modularization or just most of it?
<cartman> is there a problem with archives, xorg pack. still not moved to archives though it compiled fine for amd64 in last 3 uploads
<daniels> it's stuck in NEW
<cartman> daniels: sorry, that means? :/
<daniels> there are new binary packages which weren't in previous uploads
<daniels> they need manual approval
<cartman> ah :/
<cartman> I seem to miss XWrapper here and startx doesn't work once again, thought new upload would fix it
<cartman> daniels: thanks for info
<fabbione> daniels: is the new X sitting in NEW?
<fabbione> morning
<daniels> fabbione: binary NEW, yeah
<daniels> and there are a bajillion source packages in source NEW
<fabbione> no wonder
<fabbione> jbailey: ping?
<Amaranth> uh oh
<Amaranth> time for the backports guys to do stupid things with firefox and users to complain :/
<Amaranth> no offense to any backports guys who might be here
<jsgotangco> heh
<pitti> Hi guys
<fabbione> hi pitti
<pitti> Hi fabbione, how's life?
<fabbione> pitti: tired... i didn't sleep well in the last days. it's just too warm
<pitti> fabbione: hehe, it's +30C here in the north...
<fabbione> yeah same here + or -
<fabbione> how is debconf going?
<pitti> fabbione: pretty great, and pretty relaxed; much hacking, talking, and a full day trip to an island today
<fabbione> ah nice
<fabbione> have fun
<pitti> thanks :-)
* pitti hands fabbione an ice cube to prevent his melting
<fabbione> ehhe
<fabbione> pitti: do you know if elmo is coming around?
<pitti> fabbione: he's here
<pitti> fabbione: shall I poke him about anything?
<pitti> fabbione: well, he's still asleep, though :-)
<infinity> pitti : I don't suppose you could beg him to un-VAC for a few minutes to NEW all of the pending X stuff?
<fabbione> pitti: well if possible i need the new glibc on breezy chroot on concordia. they should be ale to fix the problem i have building the kernel
<fabbione> that too :)
<pitti> infinity: Kamion isn't available either?
<fabbione> pitti: Kamion won'
<fabbione> pitti: Kamion won't be around for another bunch of hours
<infinity> pitti : Kamion will be around at some point, I assu,e but not yet.
<pitti> ok
<infinity> s/assu,e/assume/
<infinity> I'll bug him, though, if elmo can't get to it.
<pitti> alright, if I see him before we meet to start the trip, I ask him
<infinity> fabbione's chroot request still stands though, since we only have one sysadmin right now.
<pitti> does thom still have root?
<fabbione> pitti: can't you leave me a paper message right in front of his nose?
<fabbione> pitti: thom is at debconf as much as you are i think
<infinity> pitti : If he does, he's not supposed to use it.
<infinity> pitti : So, in effect, he doesn't.
<pitti> alrigh
<pitti> t
<fabbione> inotify is upstream!
<pitti> wow
<whiprush> woo!
<mae> ??
<mae> how is breezy coming
<Keybuk> daniels: "migrating conffiles" ?  are they going south for the winter ?
<daniels> Keybuk: moving from xlibs -> xlibs-data
<daniels> er
<daniels> moving from xlibs -> xkeyboard-config
<Keybuk> yes ?  that's why dpkg doesn't remove conffiles
<Keybuk> xkeyboard-config ... Replaces: xlibs
<daniels> which helpfully prompts me for every single conffile
<daniels> i'd like it to not prompt unless it's actually been changed
<Keybuk> if you changed them, yes
<daniels> unchanged
<Keybuk> it's a bit broken, of course
<daniels> i hacked around it by just nuking it in preinst/postinst in any case
<daniels> hah :P
<daniels> and keeping the xlibs package around
<fabbione> hmmm we are missing slang2 source from ubuntu
<pitti> fabbione: still no sign of elmo, sorry
<fabbione> pitti: ok thanks
<pef> hi
<jsgotangco>  #ubuntu-mot
<jsgotangco> j  #ubuntu-motu
* Treenaks gives jsgotangco a /
<jsgotangco> yaahh sorry
<jsgotangco> i just finished rebuilding my laptop tee hee
<Treenaks> jsgotangco: rebuilding hardware-wise or software-wise?
<jsgotangco> software-wise
<jsgotangco> im forced to dual-boot on this laptop due to my client running oracle
<Treenaks> jsgotangco: dual-boot? what's wrong with an oracle-supported chroot (redhat or something I guess)
<jsgotangco> Treenaks, the client software (JInitiator) only runs on IE and Netscape atm
<jsgotangco> seeding the data requires me to have JInitiator
<jsgotangco> tee hee
<Treenaks> yay
<jsgotangco> i should get an extra laptop just for that jeez
<Treenaks> jsgotangco: vmware/qemu + windows then?
<jsgotangco> i would have gone that route if my machine was good
<jsgotangco> im saving for a new one though
<daniels> fabbione: any chance we could get the trackpoint patch merged, but not autodetecting -- so you need to specify a boot option?
<daniels> i'm really missing it
<Treenaks> daniels: only weenies use mice & their substitutes
<fabbione> daniels: it's upstream already.. what do we need more?
<Treenaks> Real Men use the keyboard
<fabbione> anyway i am off to bed. i am not feeling good today
<daniels> fabbione: oh, is it?
<daniels> fabbione: g'night dude, feel better
* jsgotangco switches to his kb-based wm
<daniels> bah.  both of productplacement and intuneandontime are too long.
<Treenaks> daniels: ?
<daniels> Treenaks: machine names
<Treenaks> daniels: ah
<Treenaks> those can be too long?
<daniels> having to type ssh intuneandontime can be a pain in the arse
<daniels> brainfreeze is about as long as I'd like to get
<daniels> i settled on ephemera (contraction of excessiveephemera)
<Lathiat> daniels: thats what ssh tab completion is for
<dilinger> daniels: heh, dj shadow?
<daniels> dilinger: sensing a pattern? :)
<daniels> dilinger: i'm a bit of a shadow fanboy
<dilinger> i stumbled upon entroducing's deluxe edition a few weeks ago
<dilinger> good stuff
<daniels> yeah, the mix from oxford is just too awesome
<Amaranth> inotify merged into linus's kernel!
<Lathiat> oh nice
<Amaranth> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0eeca28300df110bd6ed54b31193c83b87921443
<zyga> hello
<zyga> will firefox 1.0.5 be included in hoary or will the changes be ported back to 1.0.2?
<Amaranth> that second one
<Amaranth> the security fixes will be backported
<Amaranth> any other changes won't be
<zyga> great
<mdz> though perhaps firefox 1.0.5 will land in the newly established hoary-backports?
<mdz> s/\?//
<Amaranth> does that actually exist yet?
<Amaranth> http://archive.ubuntu.com/ubuntu/dists/hoary-backports/
<Amaranth> whoa
<\sh> woot?
<\sh> since when
<ivoks> today
<zyga> hmm
<zyga> :)
<Amaranth> did i miss another meeting or something?
<Amaranth> i mean, i've missed a month of meetings...
<mirak> hi
<mirak>  I want to use gcc3.4.4 instead of gcc3.4.3 to build a cross compiler with toolchain-source. Is it possible ?
<Amaranth> hey, hoary-backports already has things in it
<Amaranth> dpkg and dselect??
<mirak> what ?
<mirak> in fact I changed the symbolic links
<mirak> but I got compile error at some point
<Amaranth> mirak: Oh, I have no idea about that stuff.
<mirak> there is almost no docs about this
<\sh> hmmm...
<tsume> does anyone know why ubuntu's kernel takes _SO_ long to load compared to fedora's?
<\sh> anybody can have a look, why the binary packages of gfccore_2.3.1-2ubuntu1 are not in the archives? :) it's builded already...sources are on the servers
<Treenaks> \sh: how long ago?
<Kamion> Amaranth: they were a test
<Kamion> \sh: they're in NEW
<Amaranth> Kamion: ah
<Kamion> daniels: any particular order all this X stuff in NEW needs to be done?
<Amaranth> Kamion: what's with ~hoary1?
<Kamion> Amaranth: elmo's test
<Kamion> Amaranth: I imagine/hope that'll be nuked before it goes public
<Amaranth> ok
<Amaranth> except i just announced it to the world...
<Kamion> fool :)
<Kamion> don't announce things just because there's some stuff visible in the archive ...
<Kamion> it's being worked on
<Amaranth> i did for hoary-updates too :P
<infinity> Kamion : daniels just headed off to come hang out with me.
<infinity> Kamion : Just NEW the whole lot (please), and if his build-deps are wrong, I'll smack him around later (or upload fixes)
<Kamion> hmm, I wish I knew how to NEW stuff straight into universe
* Kamion does it the awkward way
<Amaranth> doesn't it just fall into universe if it's not in a certain seed?
<Kamion> Amaranth: not when I process NEW - haven't figured out why
<Kamion> Amaranth: also the relationship between seeds and main/universe is only semi-automatic
<Kamion> hmm, is this really the first time an hppa kernel has made it into the archive?
<mdz> Amaranth: ;-)
<mdz> dpkg was the test case which was run through the system
<Kamion> infinity,daniels: all these bazillion xserver-xorg-* were run past elmo, weren't they?
<Amaranth> *cough*yes*cough*
<Kamion> daniels: do all of xserver-xorg-* *really* need to Conflicts xserver-xorg (<< split) as well as Replaces?
<Kamion> daniels: seems to me that'll make upgrades a pig for no really good reason - Replaces alone would be fine?
<infinity> Replaces alone would almost certainly be fine.  I'll smack him when I see him in 1.5 hours.
<infinity> (He's stuck on busses/trains for a while)
<Kamion> sure, I'm expecting stuff to queue up :)
<Kamion> daniels: DUDE
<Kamion> daniels: YOU FORGOT XSERVER-XORG'S DEPENDS LINE
* Kamion only noticed after NEWing, sadly
* mdz moans
<infinity> Shall I halt it at the buildds?
<Treenaks> Why do you notice this while I hear REMs "It's the end of the world as we know it"
<Kamion> infinity: might be a good idea
* Amaranth remembers to not get -35
<infinity> Kamion : Source package?
<Kamion> infinity: xorg
<infinity> Oh, yay.
<infinity> Oh, wait.  I can't halt it.  You were NEWing binaries.
<infinity> For some reason, I thought you were NEWing source.
<infinity> It's alreayd beyond my control.
<infinity> already, too.
<Kamion> so I was
<Kamion> I'll fetch source and fix
<infinity> Or just kiss breezy goodbye for a while. :)
<Mez> Kamion, are you breaking things again ?
<Mez> :P
<Kamion> Mez: no
<Mez> lol - good :D
<Amaranth> when you NEW binaries doesn't that mean they've built and are just waiting to get copied to the mirrors?
<Treenaks> Mez: he's unbreaking it
<Treenaks> Mez: I hope
<Kamion> Amaranth: binaries end up in the NEW queue when no binaries of that name have been in the archive before
<Kamion> (approximately)
<Amaranth> i mean after you've accepted them though
<Kamion> Amaranth: yes
<Kamion> d'oh, daniels tried to use the [arch...]  syntax in xserver-xorg's Depends - that only works in Build-Depends
<infinity> That would explain the problem..
<infinity> Get to replace it in debian/rules with an arch-dep:substvars, I guess.
<Kamion> yeah, doing that
<infinity> Want to beg mdz to un-ACCEPT the binaries, and I can fix it properly later?
<infinity> Or, you can do it now. :)
<infinity> I'm off in 5 mins to go smack daniel on your behalf.
<infinity> Anything you'd like me to convey?
<Kamion> UNACCEPT is just bad - I'll fix it and shove through an extra cron.daily
<Mez> siretart, ping
<Mez> infinity - you still here?
<Mez> poop
<Mez> infinity, or lamont, ping
<bob2> it might be better to just ask your question
<bob2> and perhaps someone else can answer
<Kamion> for x in `ls debian/scripts/vars.* | sed 's/.*vars\.//'`; do echo $x; ARCH=$x perl -ne 'print qq{XSERVER_XORG_SPECIAL_DEPENDS="}; chomp; @drivers = split /, /; for my $driverline (@drivers) { $driverline =~ /(.*?) \[(.*)\] / or exit 1; $driver = $1; %arches = map { $_ => 1 } split / /, $2; print "$driver, " if $arches{$ENV{ARCH}} } print qq{"\n}' ../drivers | sed 's/, "/"/' >> debian/scripts/vars.$x; done
<Amaranth> oops
<Kamion> you know I'm sure there was a more elegant way to do that
* Amaranth found a problem with changing the foot icon next to the applications menu
<Mez> bob2, I was poking them because I need them to take some stuff OUT of the backports repository :D
<Amaranth> it changes the System->About GNOME icon too
<Treenaks> Amaranth: make them reference different files
<Amaranth> Treenaks: Not my place.
<Treenaks> Amaranth: in my SuSE install they're distinct
<Amaranth> Treenaks: Plus I don't even know where to look.
* Lathiat stares at his kernel compile
<Lathiat> its in net/core
<Lathiat> after a good 6 hours at least
<Amaranth> are you on a 486?
<Lathiat> 133mhz mips 
<Lathiat> w/ 2M/s disk i/o
<Treenaks> Lathiat: wooo
<Lathiat> i think the disk i/o should be faster
<Lathiat> but my internal scsi bus is lacking a temrinator
<Amaranth> Mez: You mean the dpkg stuff that's in there>
<Lathiat> because i dont have one
<Amaranth> ?
<Mez> yeah Amaranth 
<Amaranth> That was just a test.
<Amaranth> btw, if breezy can look like http://www.realistanew.com/desktop.png out of the box we can get a lot more users :D
<Lathiat> Amaranth: whats "remote storage"
<Lathiat> just a mount?
<Amaranth> yeah
<bob2> Lathiat: indy?
<Lathiat> bob2: yep
<Lathiat> bob2: r4400
<bob2> ah, mine has a 4600sc or something
<bob2> I should power it up sometime
<Lathiat> http://bur.st/~lathiat/network.jpg <-- doesnt it just look sexy?
<Mez> yeah Amaranth I know it was a test, but it needs to be taken out :D
<Lathiat> bob2: want to get my indycam going
<Lathiat> it detects in debians 2.4.27 but the image comes up all black
<Amaranth> Lathiat: Gateway Multimedia Keyboard?
<bob2> Amaranth: or by being awesome, it can attract non-14-year-olds ;)
<Lathiat> Amaranth: not gateway, its "Genius"
<Lathiat> Amaranth: you can send me that picture ;p
<Amaranth> bob2: Dude, that's Cristina Scabbia. She sings better than she looks. :)
<bob2> never heard of her
<Treenaks> bob2: you attact 14-year-olds?!? WTF?
<Amaranth> http://reverend.warp1.net/wallpapers/files/christina_scabbia_01.jpg
<Amaranth> bob2: Lacuna Coil
<Mez> Amaranth, I've met her :D
<Amaranth> Mez: Die.
<Mez> lol :D
<Mez> and nightwish :D
<Mez> and am meeting sonata arctica and epica in the next 11 days
<Seveas> nightwish is awesome
<Treenaks> Mez: I know some people who would like to meet epica
<Lathiat> Amaranth: http://bur.st/~lathiat/park21024x768.jpg
<Amaranth> Lathiat: meh
<Mez> Treenaks :D well I have Access All Areas for thirteenth day festival
<Lathiat> pff, meh
<Amaranth> Mez: I'm going to find you, steal your pass, and beat you just for fun.
<Treenaks> Mez: nice
* Mez tries and finds his old suicidegirls wallpaper
<Mez> Amaranth, are you coming 13th day ?
<Amaranth> no
<Amaranth> Lathiat: linda park from star trek?
<Lathiat> Amaranth: yes
* Amaranth _is_ a geek
<Amaranth> damnit
<Lathiat> hahaha
<Mez> damn
<Mez> weoulda been cool if you were :D and woulda been able to get your key signed for ya :P
<Mez> come on, linda park *IS* hot
<Treenaks> Mez: agreed
<Treenaks> Mez: but does she sign keys?
* Lathiat laughs
<Lathiat> Amaranth: sok, you should use this: http://bur.st/~lathiat/bg.jpg
<Amaranth> Lathiat: dude, that's just weird
<Mez> Treenaks, in the future, I'm sure they have subdermal ID devices, so they dont need keys :D
<Treenaks> Mez: still
* Mez turns safesearch off and sees what it returns
<Treenaks> geek pickup lines.. "Would you sign my key?"
<Mez> lol
<Mez> I need to get my gf to get a key so she can have it signed
<Mez> hmm
<Mez> http://frightenedarmadillo.lunaticsworld.com/fakes/Linda_Park-04-Frightened_Armadillo.jpg
<Lathiat> Amaranth: hahaha
<Treenaks> Mez: that redirects to some php
<Mez> does it?
<Mez> weird
<Amaranth> whee
<Lathiat> refer checking
<Amaranth> Mez: faked
<Lathiat> the problem i have
<Lathiat> is i have widescreen
* Treenaks shakes his fist at the referer check
<Lathiat> and nautilus wont do a "full screen aspect scaled"
<Lathiat> so i have to manually edit bg images
<Amaranth> i didn't get any referer check
<Treenaks> Lathiat: yes it will
<Lathiat> which is such effort
<Lathiat> Treenaks: no it doesn
<Lathiat> Treenaks: how?
<Treenaks> Lathiat: yes it does
<Lathiat> which option
<Mez> hmm
<Treenaks> Lathiat: scaled
<Lathiat> that leaves bars down the side
<Treenaks> Lathiat: which is scaled + aspect ratio maintained
<Lathiat> i said
<bob2> so, how about that local ubuntu development team?
<Lathiat> *full screen*
<Lathiat> i.e.
<Lathiat> stretches it out
<Lathiat> and crops some of the edge off
<Treenaks> Lathiat: stretch?
<Lathiat> Treenaks: that doesnt keep aspect
<Lathiat> i tried to figure out how to patch it and failed
<Treenaks> Lathiat: hm ok
<Mez> Amaranth I know it's faked
<Mez> aw poop! I just realsie din my disk crash -= I lost all my pr0n - noo
<Lathiat> at least its easy to do in the gimp
<Lathiat> i resize to 1680 wide
<Lathiat> and then use the canvas size thign to crop it
<Lathiat> and i can move where it crops it
<Lathiat> which is cool
* ..[topic/#ubuntu-devel:ogra] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://www.ubuntulinux.org/wiki/DeveloperResources | If you have unexpectedly lost editbugs privileges, talk to mdz/ogra/kiko | Colony CD 2 released | dont forget the bugday today !
<Amaranth> Mez: When I did the Great Setting Purge of May (rm -rf ~/.*) I lost all my pr0n (was in ~/.pr0n) :/
<Mez> lmao
* Lathiat smirks
<Mez> Amaranth, I did something similar to that :D
<Mez> but... I did rm -rf /bin 
<Mez> instead of rm -rf /*.bin
<Lathiat> you keep your pr0n in /bin/pr0n ?
<Mez> no
<Lathiat> i guess you needed /bin/pornview
<Mez> I just deleted something I shouldnt have by accident
<Mez> :P
<Treenaks> Lathiat: /srv/ftp/pr0n/ of course
<Mez> Treenaks : is that publically accessible ?:P
<Lathiat> heh
<Lathiat> who uses /srv
<Lathiat> thats like
<Treenaks> Mez: of course not
<Lathiat> against the LSB or something
<Mez> Treenaks, damn
<Treenaks> Lathiat: /srv is the new coolness
<Treenaks> Lathiat: it's not against LSB..
<Lathiat> isnt that a djb thing
<Lathiat> i hate djb with a passion
<Lathiat> only because he writes about things he has no idea about
<Lathiat> like his ipv6 rant
* Lathiat grumbles
<Treenaks> Lathiat: http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
<Lathiat> Treenaks: bah
<Lathiat> i retract my comment
<Lathiat> wow
<Lathiat> i have a /srv
<Lathiat> i didnt know that
<Lathiat> so i should have /srv/www not /var/www ?
<Treenaks> Lathiat: the apache packages don't know about that
<Treenaks> Lathiat: but I imagine it would be eventually, yes
<Lathiat> i know
<Lathiat> but i should, in theory right
<Treenaks> Lathiat: /srv/www/vhost1 /srv/www/vhost2 or something
<Lathiat> right
<Kamion> it's up to the local admin to configure stuff in /srv
<Treenaks> I think this was introduced around the same time as /media/
<Lathiat>  /media is cool
<ivoks> hi all
<Lathiat> largely cus gamin doesnt eat file handles
<Kamion> many people do things like /srv/$HOSTNAME
<Treenaks> Kamion: yes, but stuff like apache's suexec don't cope with it yet
<Lathiat> Kamion: yeh i noticed fd.o do that
<Treenaks> doesn't
<Amaranth> hey, i have a /srv
<ivoks> we all do :)
<ivoks> what is /srv for? :)
<Amaranth> i don't want a /srv!
<Amaranth> get rid of it!
<Treenaks> Amaranth: you know how rmdir works, right/
<ivoks> Kamion: i noticed few bugs in installer (they are reported on bugzilla), so i'll be here for some time, if you need additional info
<Lathiat> im sure the next incarnation of base-common or whatever it is will pu tit back ;p
<Amaranth> Treenaks: That'll do evil things.
<JaneW> ***Nag Alert***
<ogra> JaneW, ?
<JaneW> Could all those responsible to deliver Breezy Goals please...
<JaneW> Please head over to: 
<JaneW> http://udu.wiki.ubuntu.com/UbuntuDownUnder/BreezyGoals 
<JaneW> 1. Make sure your status indicator is up to date.
<JaneW> 2. Add a line or 2 to the notes section of your BreezyGoal to ensure
<JaneW> that it's reflecting the current activity on that goal, so that we all
<JaneW> know where it stands, and 
<JaneW> 3. Please prefix your comment with the date, so we can easily see when
<JaneW> last a goal was updated. 
<Lathiat> What is this some kind of organized organization?
<Kamion> ivoks: at least two of them are duplicates I'm afraid
<JaneW> As you should know the code freeze for the Breezy Release is on
<JaneW> 11 August 2005 - that's less than one month from now.
<Kamion> JaneW: code freeze != feature freeze
<JaneW> Lathiat: that's the end goal yes
<Mez> hmmles
<ivoks> Kamion: that's great then.. sorry, i checked for reported... :(
<Mez> whats the difference between using libgtkhtml3.8-dev and libgtkhtml-dev for a build-Depends ?
<JaneW> Kamion: oops, so is it Feature Freeze....?
<ogra> Lathiat, we try to :)
<Lathiat> JaneW, ogra: :)
<Kamion> JaneW: yes
<diarrhoe> will smart-batteries be supported in breezy?
<JaneW> Kamion: sorry my mistake...
<JaneW> Lathiat: although once achieved we may spontaneously combust...
<seb128> Mez: libgtkhtml-dev is a GNOME 1 lib
<seb128> Mez: libgtkhtml3.8-dev is the current version
<Mez> so I should use 3.8-dev ?
<Lathiat> yUP
<Mez> ah ok
<\sh> Kamion: u said the package (gfccore) is in the NEW queue? can u move it from the new queue? cause it's a g++ lib which I renamed
<Kamion> \sh: when I have time
<\sh> Kamion: thx
* Mez changes build-deps to libgtkhtml3.2-dev | libgtkhtml3.8-dev (cause then it'll backport!)
<Kamion> \sh: it's like the most recent thing in the NEW queue, other stuff has higher priority
<Lathiat> theres 3.6 too
<seb128> Mez: don't do this
<seb128> Mez: why 3.2 ?
<Mez> 3.2 = last version in hoary
<Mez> 3.2 is not in breezy
<seb128> Mez: no way
<Mez> and 3.8 is not in hoary
<seb128> Mez: 3.6 for hoary
<Mez> sorry: using 3.2 as that was the original depends :D
<Mez> I can just put it as 3.6| 3.8
<Mez> or just 3.6
<Kamion> newest first
<Mez> ah :D
<Mez> yes :D
<Mez> the debian package askes for 3.2 :D
<Kamion> and you should be changing build-depends where appropriate for backporting
<Mez> yes I know :D
<seb128> Mez: I'm against putting | .. | ... just for backports
<Mez> that's why I am
<Kamion> no, you're not, you're putting the backport build-depends in the main package
<Mez> Kamion, as mz said to...
<Mez> because we dont have upload access...
<ogra> Kamion, could you look at #12642 ? i guess there is a reason anacron gets stopped at 11 and started at 89...
<Kamion> which means that if both -dev package happen to be in breezy then the result of building the package in breezy is at best indeterminate
<Kamion> ogra: sorry, flat-out here
<ogra> oki
<Mez> we've just got to chang eit in breezy so it builds from scratch
<ogra> sorry
<Kamion> Mez: boggle
<Kamion> mdz: could you please clarify?
<Mez> and Kamion hence why I did 3.2|3.8 3.2 is not in breezy, 3.8 is not in hoary
<seb128> Mez: don't change an official package for backports
<Kamion> Mez: that MUST be the other way round
<seb128> Mez: just 3.8
<Mez> yeah, I meant the other way round
<Lathiat> Mez: 3.6 is in hoary, for a start
<Kamion> mdz: surely backports folks will be getting upload access
<Lathiat> Mez: so at the very least, 3.8 | 3.6
<seb128> no
<seb128> 3.8 and that's it
<Lathiat> Mez: But seb128 is saying, you shouldnt change it, and put 3.6 in if you upload a backport
<Lathiat> Mez: and leave the main one as 3.8 ONLY
<Mez> we're not uploading backports though
<seb128> or we start putting | for Debian too, and for hoary, and for backports, and for ...
<Lathiat> Mez: exactly, but if you, or someone does, they can modify it themselves
<ogra> Kamion, a i understood it, backports are done automatically from the next dev version and the backports guys have to trigger a build
<bob2> is backport main upload access distinct to main upload access?
<bob2> ah
<ogra> Kamion, so fixing stuff to compile on a older vrsion is up to MOTU or main devs
<Kamion> ogra: meh, ok, that's going to be ... uh, interesting
<ogra> Kamion, i probably understood it wrong, lets wait for mdz's word :)
<Mez> Lathiat I was told that noone would have upload access - it's be built automatically from breezy - and if it didn't build from scratch, we had to change it to build from scratch by changing breezy
<Mez> ogra: nope, its up to the backporters to fix it tow ork on an oolder versin
<Kamion> I see
<seb128> backport gtkhtml3.8 so
<ogra> Mez, thats not how i understood your log....
<Mez> aw poop
<seb128> but don't mess the Build-Depends for all the other packages
<Mez> ogra, can you send me a copy abck ? and I'll post it
<Mez> hmm
<Mez> lol ..
<Kamion> backporting libraries doesn't seem like a great idea
<seb128> Kamion: messing main packages and creating sync work from Debian for this neither
<Mez> this thing actualyl asks for libgtkhtml-3.1 in the ./configure
<Kamion> but I have sympathy for seb128's viewpoint, build-depends are primarily for the distribution to which the package was uploaded
<Mez> so it seems like that's going to have to be chnaged
<Lathiat> Mez: its usually a >= thing
<Mez> I understand seb's POV too
<Mez> Lathiat - yeah :D but in this it's bitching for the certain version
<ogra> Mez, sent
* Mez goes and fiddles
<Kamion> my preferred option would be for backporters to be able to override just the build-depends, or something similar
<Xof> clhs null
<Xof> oops, sorry
<Mez> one sec, lemme get that log and post it somewhere
<ogra> my preferred option would be that backporters have to go at least through the MOTU process to make sure they know what they are doing
<Kamion> mdz: are we putting hppa kernel udebs in main or universe?
<Mez> ogra: we DONT have direct upload to backports
<Mez> hence if WE want to make changes we do need to go though MOTU
<ogra> Mez, i know...
<ogra> Mez, yes, and i'd like you to do them yourelf ;)
<ogra> so you should be a MOTU :)
<ogra> Mez, but i dont need to tell you this, youre already on your way :)
<Mez> http://www.sourceguru.net/stuff/10/chat-with-mdz-log
<Mez> that's the log
<Mez> aw poosticks
<Amaranth> way to not escape < and >
<Mez> Jul 08 10:48:26 <mdz>for cases where the package doesnt build out of the box on hoary, you will need to make changes in breezy
<rob^> has offical backports been confirmed for Breezy yet?
<Mez> Amaranth, fixed :D I thought TextPatter would do it
<Mez> rob^, I'm sure that when developemnt on breezy+1 starts, we'll start backports for breezy
<rob^> Mez, but will it be on an offical Ubuntu server or like it is now?
<ogra> rob^, the question is how official they get :)
<Mez> rob^,  it's moving onto an official server now (and we'll be uilding as soon as elmo wakes up)
<ogra> rob^, they are on a official server then, but i doubt they will be officially supported in any kind
* davyd looks where he can aquire an AMD64 image from
<ogra> davyd, cdimag.ubuntu.com ?
<rob^> ok, when will a list of packages be available (obviously not for a while)?
<ogra> davyd, cdimage.ubuntu.com 
<davyd> ogra: trying to find a more local copy
<ogra> ah
<Lathiat> davyd: mirror.pacific.net.au
<davyd> Lathiat: any more local still?
<Lathiat> davyd: its still waix
<davyd> Lathiat: does UWA have images?
<Lathiat> davyd: not afaik
<Lathiat> they only mirror the archive
<davyd> hmm, seems not
<davyd> pity
<Mez> ogra: I doubt they'll ever be officially supported
<ogra> Mez, yes, thats what i said
<Nafallo> davyd: apt-get install jigit? :-)
<bob2> Mez: dude, w32codecs in multiverse is insane
<bob2> Mez: what do you think the chances of getting permissions to distribute them from MS, AOL, Real and every other .DLL copyright holder is?
<davyd> Nafallo: nah, I've found one close enough, now it just seems that my homedir isn't mounted on the machine I'm trying to suck it do
<Amaranth> those things go into 'hoary-extras'
<davyd> *to
<davyd> :(
<Treenaks> bob2: if you don't try...
<Amaranth> which will use the hosts they have now
<Amaranth> according to jdong
<Lathiat> davyd: see, you should have a cd burner in your laptop ;)
<bob2> I don't think any one in the world has permission to distribute it
* Kamion uploads xorg -37
<davyd> Lathiat: I do, but I want to suck it down, and then walk there and burn it
<davyd> not have to sit there for hours
<Amaranth> Kamion: yay!
<Lathiat> just suck it to martello
<Lathiat> it'l only takes 5 minutes anyway
<davyd> Lathiat: I want to put it on /away
<rob^> bob2, thats the problem with have with the docs at the moment, which is why I wanted to know where backports is heading
<Lathiat> mirror.pacific flies
<Treenaks> Lathiat: I got a dual-layer DVD writer in my laptop.. never use it
<Lathiat> davyd: move it when you get there?
<davyd> Lathiat: yeah, sure
<Lathiat> Treenaks: i have one too, and i use it daily
<davyd> Lathiat: why abuse the network?
<Lathiat> well, once every 2 or 3 days at least
<Treenaks> Lathiat: what do you burn?
<davyd> if I don't have a homedir on the workstations, it's not much use anyway
<Lathiat> Treenaks: lots of things
<Lathiat> depending on the time
<ogra> bob2, sure MS has
<Mez> whats the & code for a | ?
<Lathiat> various os cds, backup cds, archiving files, testing ubuntu install cds on other machines
<bob2> ogra: MS gave you permission to freely distribute their .DLLs?
<Lathiat> davyd: dude its like 100mbit, its hardly abusive
<ogra> <bob2> I don't think any one in the world has permission to distribute it
<ogra> they have :)
<davyd> Lathiat: loving remember the network of ye ole' time
<bob2> ogra: no, they don't have permission to distribute the Real codecs
<bob2> etc
* davyd gives up
<Treenaks> bob2: MS has permission to distribute MS codecs. Real for Real codecs, etc.
<Lathiat> davyd: could goto ucc and suck it into your laptop and go back home :)
<ogra> bob2, real is in w32codecs ?
<davyd> I may as well go there and suck it onto my laptop
<Burgundavia> ogra, yes
<Lathiat> bing
<ogra> oh
<Burgundavia> ogra, and apple stuff
<davyd> Lathiat: yeah
<Lathiat> bah
<bob2> ogra: yes
<ogra> that happens if you never use illegal stuf...tsk...
<Lathiat> i just spent 7 hours building this kernel
<davyd> although, it's wet, I didn't want to take my laptop to UCC...
<bob2> Treenaks: right, my point is no one has permission to distributed the aggregate
<Lathiat> only to hav eit fail at the end with an undefined reference to 'release_task'
<Lathiat> bleh
<davyd> Lathiat: dude, cross compiler
<Lathiat> when linking the kernel
* Lathiat shoots the kernel
<Lathiat> davyd: find me breezy compatible packages
<Burgundavia> but the cleanroom patent-infringing only stuff should be find
<Burgundavia> fine
<Lathiat> Burgundavia: 'cleanroom' ?
<Treenaks> bob2: true.. but then we could split the .deb into parts & ask the vendors to distribute it
<davyd> Lathiat: remind me later on and I'll find them for you
<Treenaks> bob2: or ask them for permission separately
<Burgundavia> Lathiat, stuff that was reverse-engineered and not "acquired"
<Treenaks> bob2: which I think nobody has even tried yet
<davyd> I did have them
<bob2> Treenaks: sure, that's worth a try
<Burgundavia> real and apple will probably say no
<Lathiat> Burgundavia: which is none of w32codecs
<davyd> only gcc-3.4 though
<bob2> but it annoys me when people think it's cool to bliethly distribute it
<Burgundavia> Lathiat, I was thinking of libdvd and the gstreamer stuff
<Treenaks> Burgundavia: Real might say yes -> RealPlayer is shipped with the free SuSE ISOs as well
<Lathiat> Burgundavia: right, ffmpeg, etc
<Burgundavia> Treenaks, they might say yes to realplayer, but not to just the codecs
<Lathiat> Treenaks: isnt that helix which is free anyway?
<Treenaks> Lathiat: yes, it is
<Burgundavia> Lathiat, not the real codec
<tseng> helix doesnt support anything more than we already do
<Treenaks> Burgundavia: SuSE distributes the codecs too, and Sun Java, and lots of stuff like that
<Burgundavia> Treenaks, what I am saying is that they are distributing realplayer with codecs, not just codecs for another player (thus real looses all their branding)
<Treenaks> Burgundavia: oh true, but the codecs are .so files
<Burgundavia> yes
<Treenaks> Burgundavia: so it's not hard to "patch them in"..
<bob2> so, instead of speculating on irc, go email them!
<Lathiat> but that might bnto be allowed....
<Lathiat> theyre license may only permit redistribution in whole form
<Burgundavia> better to support the reverse engineering efforts I think
<Lathiat>  thats grey in some place stoo
<Lathiat> depend son the country
<Burgundavia> but w32codecs is black
<davyd> mm, 1 MB/s
<davyd> it's a nice speed
<Lathiat> slow
<Lathiat> i've sucked over like 10M before
<davyd> I blame manbo ;)
<JanC> Apple will never give permission for all the quicktime codecs, as many of those codecs aren't owned by them
<Kamion> daniels: the epoch-matching in libxrender seems a bit redundant given that the version you uploaded is lower than that in Debian anyway?
<seb128> any reason to not assign kubuntu bugs to the kubuntu-bugs list or something?
<seb128> keeping them assigned to debzilla create a lot of noise on the "unassigned bugs"
<Riddell> seb128: generally I think they're assigned to me with kubuntu-bugs as QA
<Kamion> they generally are already
<Riddell> seb128: assigning to kubuntu-bugs is also fine if bugzilla can do that
<Kamion> assuming the submitter selected the option to file them on Kubuntu, as opposed to Ubuntu with a KDE package
<seb128> Riddell: not by default, there is a bunch of kdelibs bug assigned to debzilla
<Kamion> seb128: "default" not meaningful
<seb128> Riddell: yep, what do you prefer? I'm going to change the default for some stuff
<Kamion> as I say there are two possible ways one can file bugs on kdelibs ...
<seb128> Kamion: hum? any case it should be assigned to somebody and not debzilla
<Riddell> seb128: assigning to kubuntu-bugs gives it a community feel
<ogra> Kamion, in any case kubuntu should care for the kdelibs bugs, no matter how they got filed
<seb128> Riddell: k, I'll change for that 
<Riddell> I need to have a major kubuntu-bugs cleanup
<ogra> Riddell, ITS BUG DAY !! do it now :)
<Riddell> ogra: it is?  well it's on the end of my todo list, I'll see if I get down to it
* ogra wonders if he should send the bugday announcements to kubuntu lists too... i was assuming kubuntu devs read ubuntu-devel
<Riddell> ogra: sending to kubuntu-devel too would be good actually, I'm not always up to date on ubuntu-devel
<ogra> Riddell, ok, will do for the next one....
<mirak> hello
<mirak> I have some problems with toolchain
<mirak> anyone use it here ?
<Kamion> no, no developers use the toolchain ever ;-)
<Treenaks> sed + awk are excellent compilers ;)
<Treenaks> (hm.. would that be possible? a C-compiler written in awk..)
<mirak> I just want to cross compile
<mirak> there is very few understandable docs
<JanC> Treenaks : I only know about a C-compiler written in python  :)
<Treenaks> JanC: I know of a webserver in postscript
<Treenaks> JanC: (inetd-based)
<JanC> http://people.cs.uchicago.edu/~varmaa/mini_c/
<jbailey> fabbione: pong
<fabbione> hi jbailey
* fabbione starts to feel a bit better
<fabbione> jbailey: the last glibc upload will fix that ld.so problem?
<fabbione> (on amd64 i mean)
<jbailey> No - I still cannot reproduce it.
<jbailey> That last upload was the fix a hang in mysql (and other threaded apps) in hoary
<fabbione> jbailey: i can reproduce it constantly on concordia chroot
<fabbione> and you can also see it on some build logs...
<fabbione> like ocfs2-tools
<fabbione> just installing some pkgs can cause the error
<jbailey> Right, but I don't have the rights to install packages on any amd64 box.
<jbailey> And the kernel build didn't fail for me.
<fabbione> try to rebuild until it shows up ?
<fabbione> it comes to me at least once a build...
<jbailey> The best I was able to do was to have mv segfault on my  irreproducably.
<jbailey> s/my/me/
<fabbione> ok i guess i need to start building in verbose
<fabbione> anyway i have a more interesting problem for you
<fabbione> i did try the following installation on a laptop
<fabbione> with hda (internal hd) with only /boot and swap
<fabbione> the rest on an lvm volume on an external (usb) device
<fabbione> the installation is perfect...
<fabbione> the problem is the first reboot
<fabbione> initrd contains all the correct modules to get sda up (usb disk)
<fabbione> but the pivot_root is called way too fast
<fabbione> before the device is scanned and initialized by the kernel
<fabbione> how can i introduce an arbitrary delay there?
<fabbione> between loadmodules and "pivot_root"
<Mez> lol - fabbione I had the same propbelm
<Mez> cause the USB disk counts as a SATA drive, then it causes problems with pivot_root as it doesn't seem to like SATA drives
<Mez> *shrugs*
<fabbione> it's not SATA
<fabbione> it's pure SCSI over USB
<jbailey> fabbione: Is there any reasonable way to just detect that the drive isn't ready but will be shortly so I can sleep automatically?
<jbailey> fabbione: Given all the efforts to reduce boot time, I'd hate to introduce an arbitrary sleep 1 everywhere.
<Mez> fabbione, well, it clases it as SATA (or is it SCSI) becaus eit's USB
<Mez> jbailey, doesnt one distro have a seven second boot?
<Riddell> Kamion: how can I find out why all the KDE packages are listed on breezy_probs.html ?
<fabbione> jbailey: if you can first tell how to insert the sleep i can first check that the initrd is good 100% :)
<jbailey> Mez: No idea.  I don't actually care about bootspeed outside of embedded devices.
<jbailey> And in those cases, 7 seconds seems like a really long time. =)
<fabbione> jbailey: at that stage i am not sure what facilities you have to check what's going on.. SCSI devices might take an arbitatry amount of time to settle
<Mez> lol @ jbailey
<fabbione> Mez: it's SCSI <- over USB-
<jbailey> fabbione: If it's SCSI, there should be a way of asking the bus if the devices are in the ready state.
<fabbione> jbailey: well the SCSI layer is an emulation ...
<fabbione> it could easily be a real ATA device on the other end
<Mez> fabbione, that's it... yeah - I had the same problem... device not found or some poo like that
<jbailey> fabbione: Sure, but I imagine that the worst you get is a false positive - so no worse than we have now.
<jbailey> A false negative would be the only concern.
<jbailey> Causing the system to just hang there waiting for drives.
<fabbione> jbailey: yup.. ok.. how can i add that sleep now? ;)
<fabbione> i just want to see it working
<jbailey> fabbione: Patience, my smurf.
<jbailey> fabbione: Are you sure the mount succeeds?
<fabbione> jbailey: yes master
<fabbione> jbailey: what mount?
<jbailey> ISTM that you'd want the sleep before the mount, not the pivot_root
<jbailey> mounting the root
<jbailey> partition
<fabbione> well i need to sleep before the call to vgchange -a y
<fabbione> because otherwise the vg isn't initialized properly
<jbailey> feh, lvm. =)
<fabbione> and that would make the / device not available
<jbailey> (I did get my laptop installed with lvm yesterday.  New installer option makes that very nice)
<fabbione> (did you like it? ;))
<jbailey> Not so far, but that's mostly because I was finishing the debootstrap by hand to work around an installer bug, and gnome won't install because some things need syncrhonising. =)
<jbailey> Nothing to do with lvm, though, just the annoyance of having my laptop in a less than useful state.
<fabbione> no i mean.. if you liked the autopartitioning with lvm :)
<fabbione> i had to workaround this installation too.. with shadowconf on inside the target chroot
<jbailey> Yeah.
<fabbione> and it's there where i am "stocked" atm...
* Mez has no idea what lvm is
<Mez> but when I tried it ... it managed to get me stuck on the partitioner
<Mez> (and lvm reported that there was nothing on my hard disks)
<jbailey> Mez: Sounds like my first attempt.  Are you on ppc?
<Mez> nope
<Mez> and I cant be arsed witha  reinstall now
<Mez> (even though I do have a complete backup of my systenm
<jbailey> fabbione: Is the vgchange the first access to the drive with lvm on it?
<fabbione> jbailey: i think so yes..
<fabbione> i am considering to make vgchange a dash script with sleep in and wrap the call to the real vgchange
<fabbione> since the call to vgchange happens in script
<Mez> jbailey - Am on k7 :D
<fabbione> and i have no idea who/what executes it
<jbailey> fabbione: You need to edit /usr/sbin/mkinitrd then and insert the sleeps before each instance of vgchance.  There are two sections in there, one for lvm and one for device mapper.
<Kamion> Riddell: apt-get install them in a clean chroot
<jbailey> The lvm stuff is all detected and dynamically generated for the lvm, so it doesn't cleanly exist in its own script.
<Kamion> Riddell: you don't need to wait for them to install all the way - it'll throw an error immediately on breakage
<Kamion> Riddell: oh, and make sure the chroot's sources.list does not include universe or multiverse
<Riddell> Kamion: ah, universe might be the issue.  will investigate. thanks
<fabbione> jbailey: can't i just edit inside the initrd? or do i really need to regenerate?
<fabbione> jbailey: in the initrd there is only one call to vgchange.. in /script
<fabbione> but who does execute that file?
<fabbione> and with what shell?
<jbailey> fabbione: The shell inside the initrd is dash unless you've enabled busybox.
<jbailey> fabbione: Sure, you can edit inside the initrd if you want.  I just find it easier to edit mkinitrd and friends and apt-get --reinstall the kernel.  Less to think about, and no fussing with loop devices, etc.
<fabbione> jbailey: well for me it's not an option to reinstall the kernel from d-i all the time :)
<fabbione> jbailey: /script: line 12: sleep command not found
<fabbione> it means that it's not executed with dash
<fabbione> (i didn't change the default shell)
<jbailey> sleep isn't a built-in with dash, I don' think.
<jbailey> it's usually /bin/sleep
<fabbione> oh right...
<jbailey> I'm surprsied it's not in there, though./
<fabbione> impressive.. sleep is linked with more stuff than ls
<fabbione> or almost :)
<jbailey> Eh?  Why does sleep need -lm ?
<fabbione> don't look at me that way.. i didn't write it :)
<Kamion> subsecond sleeps
<fabbione> jbailey: do i need to add more libs for libm ?
<fabbione> Kamion: sleep never accepted less than a sec sleep...
<fabbione> Kamion: probably for keeping track of secs?
<Kamion>        Pause for NUMBER seconds.  SUFFIX may be s for seconds (the default),
<Kamion>        m for minutes, h for hours or d for days.  Unlike most  implemen
<Kamion>        tations  that require NUMBER be an integer, here NUMBER may be an arbi
<Kamion>        trary floating point number.
<Kamion> see the last sentence
<Kamion> $ time -p sleep 0.1
<Kamion> real 0.10
<jbailey> fabbione: I don't think we copy libm to the initrd right now.
<fabbione> no we don't..
<jbailey> ldd is recursive, so it'll show all the libraries you need (assuming nothing is dlopen'd)
<fabbione> jbailey: i added libm and for the sake sleep 20 || dash
<fabbione> so in the worst i get to a shell
<jbailey> 'k
<Amaranth> if xserver-xorg is a dummy package that can be removed x-window-system-core shouldn't depend on it
<Amaranth> oh, i guess i should file a bug report or something
<jbailey> Amaranth: =)
<Kamion> it's much simpler for x-w-s-c to depend on that rather than keeping track of all the driver deps
<Kamion> x-window-system-core is also a dummy package ...
<Amaranth> it's so nice being able to only install the ati driver
<Amaranth> i'd better get vesa too though in case i switch cards
<fabbione> jbailey: AHHHH i think i got it... it's missing librt too, but other than that.. now i noticed that it's missing the usb module for the host controller...
<Amaranth> wow, you have to be careful upgrading to -36, it doesn't even install the mouse and keyboard input drivers by default
<jbailey> The dependancy on -lm is spurious.
<Kamion> Amaranth: yes, as I said above
<Kamion> xorg -37 is accepted for i386 and powerpc
<jbailey> It needs -lrt for clock_gettime, though.
<Amaranth> so is the end goal having d-i figure out what xorg packages to install?
<Kamion> Amaranth: I sincerely hope not
<Kamion> hello, madness
<Amaranth> well, not d-i itself
<ogra> heh
<seb128> Kamion: are gnome-control-center 1:2.11.5-0ubuntu3 and totem 1.1.2-0ubuntu5 waiting on new processing?
<seb128> Kamion: I've changed the binary packages
<Kamion> seb128: I already did gnome-control-center
<Kamion> seb128: totem is in NEW
<seb128> can you accept it?
<Kamion> looking
<seb128> I've splitted libtotem-plparser to a new package
<seb128> so rhythmbox can Depends on the lib instead of totem
<fabbione> seb128: hey dude.. got my mail?
<seb128> fabbione: yeah, is that a "can you patch now", or "or patch for the next upload in a few days" ?
<Amaranth> oops
<fabbione> seb128: "next upload" is fine..
<Kamion> seb128: you only need a Replaces on totem-{gstreamer,xine}, not both Conflicts and Replaces
<seb128> fabbione: k, cool
<fabbione> seb128: thanks a lot
<seb128> np
<seb128> Kamion: does the Conflicts hurts? It prevents downgrade breaks
<Kamion> seb128: that dpkg bug has been fixed, you can stop working around it
<Kamion> seb128: the Conflicts makes upgrades painful
<seb128> k
<Kamion> seb128: also I think the version on the Replaces is wrong - shouldn't it be << ubuntu5?
<seb128> Should I fix it now and reupload or for next upload ?
<Kamion> next upload's fine
<Kamion> although given the Replaces bug you might want that to be quite soon ;)
<seb128> ups
<seb128> right
<seb128> can you reject this one, so I reupload with this fix ?
<seb128> or I just upload a new version
<Kamion> oh, too late, I just accepted it
<Kamion> sorry
<seb128> np, I'll upload a new one now
<jbailey> Hmm.  sleep and tail both include -lm unnecessary.  Looks like historical magic.
<fabbione> jbailey: ok i got it.. and i found another bug too
* jbailey emails upstream.
<fabbione> jbailey: i will let you know quite soon about the sleep, but it might not be required at all
<fabbione> the 2 bugs are: missing USB host controller module
<fabbione> and the otherone is/was the missing ide-* modules from being loaded
<fabbione> the main issue is that / lives on a USB/SCSI disk.. but /boot is on an ide disk
<jbailey> Ah.  Yeah, that won't work for you.
<fabbione> so initramfs and/or mkinitrd logic needs to take that into account...
<fabbione> or at least should :)
<Kamion> infinity: what happens if I REJECT binaries? I assume the reject message only goes to you ...
<Kamion> infinity: do you routinely forward them to the maintainer, or is it just a black hole?
<jbailey> The mkinitramfs does because it just walks all of the drivers in the system.
<jbailey> When detecting  what you think the 'root' is, the decision heuristic gets confused at multiple choice. =)
<bddebian> Hello
<fabbione> jbailey: yeps.. the sleep is required to give time to the device to settle down and devfs to create the devices...
<fabbione> given the sleep it boots perfectly
<jbailey> So is the issue scanning the SCSI bus, or the USB bus?
<Amaranth> is -37 fixing 'keyboard' vs 'kbd'?
<Amaranth> xorg i mean
<Kamion> no
<Amaranth> oh
<Kamion> I wasn't aware of that issue
<Amaranth> i just found out what it was
<Kamion> the changelog says exactly what I fixed
<Amaranth> i had to edit xorg.conf and change the driver to 'kbd'
<Amaranth> i ran dpkg-reconfigure a couple times, it always set the driver as 'keyboard'
<Kamion> make sure a bug's filed, please
<fabbione> Kamion: is there any problem with -changes mailing list?
<fabbione> i didn't get a single change since midnight
<fabbione> or around that time
<infinity> Kamion : It's not terribly common for binaries to get rejected after the source is accepted, really..
<infinity> Kamion : Except in odd cases like this, I gues. :)
<infinity> s/gues/guess/
<infinity> Kamion : In this case, I'd definitely pass the message on, but in most cases, I'd assume a REJECT would come with an IRC conversartion or email to the rejectee.
<fabbione> infinity: can we build -37 or should we skip?
<infinity> fabbione : If you built -36, build -37.  If you still have -35 installed for your arch, you can probably expect a -38 reasonably soon.
<Amaranth> whoops, i left it assigned to daniels 
<Kamion> infinity: in this case, a manual reject because the binary is broken, but I couldn't see that until getting the binaries in NEW
<Kamion> fabbione: don't know - I've not seen much either
<fabbione> Kamion: ok thanks
<fabbione> infinity: -35 has been rejected... but i will have it for a little while in my local cache
<fabbione> but it was rejected this morning
<fabbione> so it's not anywhere really...
<fabbione> infinity:  i guess i will wait -38 directly
<infinity> -37 will be rejected anyway.
<infinity> katie just tossed it on the floor.
<Kamion> fabbione: -35 was auto-rejected because there was newer source in the archive
<infinity> Kamion : Did you inadvertently manage to turn some binary packages back on or something?
<Kamion> infinity: huh? -37's in accepted
<infinity> Kamion : THe -37 uploads are all being reject/unaccepted.
<infinity> Kamion : Oh, wait.  It's daniels' fault.
<Kamion> infinity: oh, I NEWed a batch of binaries which xorg is still building
<infinity> Yes, that would be the problem.
<infinity> He shoud have turned those off in his most recent xorg upload. :)
<Kamion> only ia64 got rejected
<infinity> (though, if xorg had beat those to the archive, it would be okay)
<Kamion> well, it was a question of NEW queue handling order
<infinity> ia64 was rejected, powerpc was unaccepted.
<Kamion> meh, hate unaccepts
<Kamion> they're still in queue/accepted/, evil confusion
<infinity> Yes, I don't think automatic unaccept actually works.
<Kamion> I imagine they'll stay there until elmo cleans them up
<infinity> I've got 3 emails claiming that powerpc was unaccepted.
<infinity> Make that 4.  Just got another.
<infinity> YAY.
<Kamion> you'll probably get a mail once every half-hour ...
<infinity> That would make sense, yes.
<Kamion> I am not hard enough to move stuff around in the queue by hand
<infinity> The simplest solution is a new xorg, probably.
<Kamion> infinity: is daniels at your place, then?
<infinity> daniels will be home soon.  But maybe I should just build a -38 that turns those packages off.
<infinity> No, he's on his way home after an evening of drunke debauchery.
<infinity> s/drunke/drunken/
<Kamion> you'll probably keep getting mails anyway, I think unaccepts stay around forever or something
* bddebian needs more days of drunken debauchery
<Treenaks> debuggery?
<infinity> Ahh, the "do you forward shit to maintainers" email was in relation to the xvinfo REJECT?
<Kamion> yes
<Kamion> I mailed daniels separately
<infinity> Given that REJECT mails are delightfully light on information (I don't see the .changes or anything), I'd have to do some digging to find the person responsible.  Probably easier for you.
<infinity> But, I don't much care who does the job.  Just let me know in the reject mails.  I do read them.
<infinity> So, as you did (Mail sent to maintainer), or the opposite (Too lazy to mail the maintainer, do some work you slackass buildd maintainer), either works for me.
<Kamion> :-)
<Kamion> it's a bit of a fundamental problem with this source-only-uploads business, really - have to reject every single buildd upload separately because I didn't get to find out until all of them started building
<infinity> Yeah.
* Lathiat uh
<daniels> Kamion: i'm told I should probably buy you a drink at some stage
<Lathiat> Why doesn't something pull in things like oh sya, xserver-xorg-input-kbd
<Amaranth> hahaha
<infinity> And I tend to read REJECT mails because in Debian, REJECT mails sent to a buildd almost always mean "DAK BROKE, HELP!"
<Amaranth> Lathiat: We've said that a million times.
<Kamion> Lathiat: it will, see above conversation for what's going wrong
<Lathiat> ah
<Lathiat> righto
<Amaranth> Lathiat: Make sure you get your display driver and the mouse driver too. :)
<Kamion> daniels: I'll settle for knowing what we need to do to turn off the binaries that are making xorg be unaccepted :)
<daniels> it's all part of the Great Leap Forward to modularisation
<Lathiat> Amaranth: dont need display driver but mouse yeh, got that
<daniels> Kamion: to what the what?
<infinity> daniels : THere's still breakage.  For starters, xorg is still producing binaries that are now built from other sources.  A -38 that turns those packages off (I can forward you the REJET mail for a nice list) would be nice.
<Kamion> oh, if you're sober enough to do it, so much the better
<Lathiat> kbd was just an example :)
<daniels> Kamion: let me catch up on scrollback
<daniels> infinity: oh, that.  yeah, my uploads were sort of assuming xorg would get built by anything else.  gnar.
<Kamion> daniels: I NEWed a bunch of modularised X libraries and stuff; xorg's still building them though, so it's getting rejected/unaccepted/depending
<infinity> daniels : Stuff cleared NEW in a suboptimal manner.  No big deal.
<Amaranth> Lathiat: And if X won't start edit xorg.conf and change Driver 'keyboard' to Driver 'kbd'
<Lathiat> Amaranth: yep did that
<Lathiat> work snow
<Kamion> libxi-dev libxi6 libxi6-dbg libxinerama-dev libxinerama1 libxinerama1-dbg libxres-dev libxres1 libxres1-dbg libxss-dev libxss1 libxss1-dbg
<Kamion> ^-- list of packages
<Lathiat> has nautilus lost a pmount change
<Lathiat> when i hit mount volume it complains about /dev/sda1 not being in /etc/fstab
<daniels> Kamion: if the newest xorg int he archive is still -34, we're probably on a winner there
<daniels> Kamion: is that the status?
<daniels> give me five minutes to feed and dry the dog, get a drink, and download my mail
<infinity> daniels : No, the newest in the archive is the hideously-broken -36.
<infinity> daniels : -37 was Kamion's upload to fix the xserver-xorg dependency issues.  But it's being REJECTed due to the "still building binaries that now come from elsewhere with higher version numbers" issue.
<daniels> oh, right.
* daniels scratches head.
<daniels> wonder how that will play with some Conflicts/Replaces
<infinity> Oh, also, check backscroll.
<infinity> Kamion complained about your conflict/replace usage.
<infinity> Stuff doing both when all you really needed was "Replaces".
<infinity> (And using both just makes the package management system's brain hurt, trying to order things Just Right, do multiple installation passes, etc)
<infinity> Note that Keybuk fixed the dpkg bug that led to C/R being used where just R should have been appropriate, so there's no excuse anymore.
<daniels> yeah, just saw that, and for xvinfo, too
* fabbione goes back to bed
<daniels> test build whirring now
<Amaranth> hmm, those should go faster now, right? :)
<daniels> yeah, down to 30min flat
<daniels> did I ever mention that dpkg is shit at migrating conffiles between packages?
<ivoks> ok, maybe it was mentioned, but... xvinfo package?
<ivoks> xbase-clients depends on it, and there is no xvinfo package...
<sabdfl> hey guys, anybody feeling artistically inspired?
<sabdfl> i'm looking for some nice images for the front page of the website
<Amaranth> we have artists?
<ivoks> sabdfl: ubuntu.com?
<seb128> Kamion: I've uploaded a new evolution-data-server with some soname changes, can you get it out of new with the new libcamel1.2-6 libegroupwise1.2-8 to main?
<mdz> ogra,Kamion: what's the question?
<sabdfl> ivoks: yup
<ogra> sabdfl, run a contest
<sabdfl> ivoks: banners to link to Kubuntu, and Edubuntu
<sabdfl> want to slip them above the circle-of-friends image, same width
<Treenaks> sabdfl: hackergotchis?
<Treenaks> oh wait
<sabdfl> Treenaks: more like banners... have one that says "Partner projects:"
<sabdfl> then one for kubuntu
<sabdfl> then one for edubuntu
<ogra> mdz, how will beackports be handled exactly.... from a technical POV
<sabdfl> with their logo's
<ivoks> well, everybody could do something
<daniels> ivoks: i know, I've seen it
<ogra> sabdfl, the edubuntu logo needs adjustment before we use it widely... 
<ivoks> daniels: ok, i was pretty sure you did... anyway, thanks
<mdz> ogra: the backports team will select packages from breezy to be copied into hoary-backports and built
<Kamion> seb128: when it arrives, sure
<mdz> ogra: they will send those selections to elmo
<sabdfl> ogra: we can fix it when we have finalised it, but it would be good to get it on our front page, even as a draft logo
<ogra> sabdfl, e and d need to be closer together... i thin silbs mentioned it in the first review
<sabdfl> minor
<mdz> ogra: and he will effect the changes in katie
<ogra> yep
<seb128> Kamion: k, I've already get the ACCEPTED mail from the upload queue
<Kamion> mdz: I can't say I'm entirely convinced by the "backport with no changes" plan - I'd kind of prefer them to be able to override build-dependencies somehow
<ogra> mdz, but they wont do uploads etc
<daniels> Kamion: can I upload the same version, or do I need to rev it higher?
<Kamion> daniels: need to rev to -38
<Kamion> daniels: I'll mail you the diff if you need it
<daniels> Kamion: er, xvinfo, sorry
<ogra> mdz, so if a backporter wants to change stuff, he should be MOTU ?
<Amaranth> ok, before you do that
<seb128> mdz: so they have to mess with Build-Depends on main packages to backport them?
<daniels> Kamion: i already have a xorg build spinning with your changes incorporated
<Kamion> seb128: yeah, but it doesn't appear in NEW until the binaries upload
<seb128> Kamion: k
<Kamion> daniels: oh, right - you need to upload -2 for that because source for -1 is already in the archive
<mdz> Kamion: my feelings are: 1) many packages will build unchanged, and 2) where possible, we should prefer to preserve hoary-buildability in breezy rather than forking the package
<Amaranth> daniels: is Driver 'keyboard' changed to Driver 'kbd' in this one? :)
<mdz> seb128: see above
<Kamion> mdz: I'm mostly concerned by the approaches people will need to take to do 2)
<ogra> mdz, the control files will get huge over time then
<ogra> mdz,  a lot of | in there...
<seb128> mdz: hum, yeah ... I'm not really happy with that, that create sync work from Debian and wrong Build-Depends for the current distro
<Kamion> mdz: and that some of those approaches will adversely affect determinisism of builds in breezy
<Kamion> er, determinism
<seb128> mdz: wrong Build-Depends beein extra | | | ... not required
<mdz> seb128: additional != wrong
<mdz> Kamion: the buildds are quite deterministic about how they handle |
<mdz> ogra: I think 'huge' is an exaggeration
<seb128> yeah, still creating the sync work, I would prefer to give this work to people doing the backports :p
<ogra> mdz, i tend to that, yes :)
<daniels> Kamion: 'kay
<daniels> Kamion: but not the .orig
<mdz> seb128: let's try this first, and if it doesn't work well, we'll reconsider the options
<seb128> k
<ogra> mdz, but we should limit the number of backported versions thn... i wouldnt like to have to regard backports to warty in breezy+10
<mdz> I really don't think the changes will be that extreme
<\sh> who is responsible now for backports?
<mdz> ogra: I don't expect we will do backports for more than one release at a time
<ogra> \sh, qgood question
<ogra> mdz, ok
<mdz> \sh: the same people who have been doing it already
<\sh> mdz: jdong?
<ogra> mdz, jdong hanst been around for some weeks now
<ogra> hasnt even
<seb128> mdz: some GNOME libs have changed their soname, and they need to " | previous-version" on all the packages using them by example ... but let's try
<daniels> Amaranth: err ... yeah, might as well
<daniels> Amaranth: keyboard should still be there though
<daniels> oh, bloody hell automake is braindead sometimes
<Lathiat> sometimes?
<bddebian> heh
<daniels> sometimes it's useful
<daniels> sometimes it impedes progress, and radiates hate
<mdz> ogra: Mez, who you were talking to earlier, is one of the backports folks
<ogra> mdz, i know... and he's going for MOTU, but jdong seems not very responsive at all... and he somewhat took the lead
<ogra> so i would xpect some more interaction
<bddebian> Yeah
<daniels> sometimes automake's braindeadness is matched only by my own
<ogra> mdz, curretnly Mez is more backports guy in ubuntu for me then jdong.... 
<ogra> from a dev POV 
<mdz> ogra: perhaps he's away from home or busy
<ogra> hmm, yes...
<spotter> anyone know what package has the xorg keyboard drive?R
<daniels> spotter: s/keyboard/kbd/ while I figure it out
<daniels> Kamion: more sensible xvinfo headed your way
<spotter> danke
<spotter> that did it
<Kamion> daniels: thanks
<daniels> Kamion: the strange thing about -36 is that I let xserver-xorg choke on the great stream of modularisation love by not forcing people to install modules, but left xlibs-dev where it stood
<mdz> ogra,Kamion: how close are we to having edubuntu seeds and CD images?
<ogra> mdz, i'm still waiting for some license decisions... i'll do it soon
<ogra> (this week, to probaly have a colony3 with edubuntu-meta packages)
<mdz> ogra: license decisions on what?
<ogra> mdz, squeak
<mdz> ogra: that shouldn't block seeds or CD images
<mirak> there is a problem with toolchain, to compile a cross gcc, I have this problem, either on powerpc or i386 !
<mdz> we can always add packages later
<Kamion> ogra: as I said before, it will be separate CD images, not part of the regular Ubuntu CD images, and I will not block Colony 3 on it
<ogra> Kamion, thus "probably"
<sabdfl> Riddell, ogra: heads up, links to kubuntu and edubuntu from www.ubuntu.com
<Kamion> nor do I intend to multiply the load of doing Colony releases up further
<ogra> Kamion, i want the edubuntu-desktop -server -whateverelse packages in ubuntu 
<Kamion> yes, but not in the Ubuntu CD images
<ogra> sabdfl, yay
<Kamion> certainly they must be in Ubuntu main
<Riddell> sabdfl: images are missing
<sabdfl> Riddell: ?
<sabdfl> looks fine for me?
<sabdfl> ctrl-shift-r?
<Riddell> sabdfl: I think the permissions are set wrong on the images
<sabdfl> Riddell: ah, good catch
<sabdfl> i'm logged in
<Riddell> if I go to http://www.ubuntulinux.org/kubuntulogo.png is asks me to log in
<Kamion> mdz,ogra: I've just done cdimage support for edubuntu - ready to build CDs as soon as seeds are up
<sabdfl> Riddell: now?
<Treenaks> kubuntu is for gearheads? *ducks*
<ogra> Kamion, thanks
<Treenaks> sabdfl: looks ok now
<sabdfl> thanks guys
<Treenaks> sabdfl: but the images are browser-scaled-ugly
<sabdfl> Treenaks: yes, i just did a qnd hack, my image-fu is not great
<sabdfl> contributions welcome
<Lathiat> Treenaks: haha
<Riddell> sabdfl: groovy, works now
<Lathiat> the edubuntu logo is cute
<Lathiat> but yeh it needs some love
<ogra> they are awful scaled...
<ogra> sabdfl, wait a sec, i have a small one here....
<Riddell> webbrowsers arn't very good at scaling images
<ogra> Riddell, thats why you scale them before :)
* pitti waves
<Treenaks> hey, teh p1tt1
<Riddell> Treenaks: do I want to know what a gearhead is?
<pitti> 'evening Mr. Tr33n4ks :-)
<Treenaks> Riddell: you might want to
<Kamping_Kaiser> hi all
<bddebian> Hello Kamping_Kaiser
<mdz> Kamion: great, thanks
<Lathiat> pitti: are large usb drives supposed to not be mounting?
<Kamping_Kaiser> is it possible to pretty up the Ubuntu boot to more like knoppix? i just had someone ask me
<Kamping_Kaiser> with the penguins etc
<mjg59> Kamping_Kaiser: That is the aim
<Treenaks> Riddell: http://www.urbandictionary.com/define.php?term=gearhead
<Lathiat> pitti: my 200G doesnt automount but it appears in computer, but if i hit mount volume it complains about /dev/sda1 not being in fstab (no pmount love?) -- my say 128M memory card in a usbh reader does automount tho
<Kamping_Kaiser> mjg59: ok.
<mjg59> Kamping_Kaiser: see http://udu.wiki.ubuntu.com/USplash
<pitti> Lathiat: they are supposed to just work
<lifeless> pitti: btw I filed that bug on my CF card in bugzilla
<pitti> Lathiat: can you /msg me the output of "pmount -d /dev/sda1"?
* daniels winces, aims -38 at jackass and fires.
<ogra> ARGH, my gimp is broken
<lifeless> pitti: do I need to get you more info ?
<jsgotangco> salut
<mdz> ogra: what is the ETA for the edubuntu seeds?
<pitti> lifeless: I didn't look at bz in that week
<ogra> mdz, is friday ok with you ? 
<lifeless> pitti: ok, well please let me know what I can do ;0
<pitti> lifeless: I don't know whether I will find time during the debconf week, but I'll do a huge bug triage at next Monday anyway :-)
<{Seb}> looks like X is broken again
<lifeless> pitti: ok. 
<Amaranth> {Seb}: Not broken, just in need of extra packages
<daniels> {Seb}: yeah dude, known issue
<Amaranth> {Seb}: If you're talking about -36, that is.
<{Seb}> i want to use ubuntu
<{Seb}> i want to like ubuntu
<jsgotangco> jeezz
<{Seb}> but i keep installing it and getting screwed
<daniels> {Seb}: if you are not comfortable with fixing broken systems, breezy is not for you
<jsgotangco> then don't use an unstable version
<jsgotangco> its not supposed to be used by everyone anyways
<{Seb}> i might see if i can get Mono 1.1.8 source installed on Ubuntu Hoary
<ogra> sabdfl, scaled to 300px www.grawert.net/edubuntu_logo.png
<jsgotangco> oohh right...i need an edubuntu logo as well
* jsgotangco keeps this
<Amaranth> {Seb}: What xorg driver do you use?
<{Seb}> ati
<Amaranth> ok
<Kamping_Kaiser> what happened to X?
<Amaranth> install xserver-xorg-input-kbd, xserver-xorg-input-mouse, and xserver-xorg-driver-ati
<Amaranth> then edit xorg.conf and change Driver 'keyboard' to Driver 'kbd'
<Amaranth> and X works again
<Amaranth> yay
<Amaranth> Kamping_Kaiser: xserver went modular
<{Seb}> from Colony 2?
<Kamping_Kaiser> Amaranth: oh, at last ;)
<Amaranth> colony 2?
* Kamping_Kaiser shuts up... i dont code
<Amaranth> i'm talking about latest and greatest
<{Seb}> i install colony 2 - X works
<{Seb}> i run upgrade and X breaks
<Amaranth> ok, this is how to make X unbreak
<{Seb}> so it has become modular since X2?
<Amaranth> yes
<jsgotangco> yeah
<Amaranth> it just changed today
<{Seb}> i'm doing a fresh install
<{Seb}> what should i do when upgrading to the newest X?
<{Seb}> what you said?
<Amaranth> install xserver-xorg-input-kbd, xserver-xorg-input-mouse, and xserver-xorg-driver-ati
<infinity> ...
<Amaranth> then edit xorg.conf and change Driver 'keyboard' to Driver 'kbd'
<infinity> Where did my amd64 buildds go?
<Amaranth> and X works again
<{Seb}> will do
<infinity> pitti : Is elmo around?
<{Seb}> thanks Amarnath
<{Seb}> will be back soon
<pitti> infinity: he didn't join us at the trip, I i
<pitti> infinity: ... didn't see him today yet
<Kamion> {Seb}: it's being fixed, go have a coffee :-)
<Kamion> easier to wait an hour or two than to work around it ...
<infinity> pitti : All three amd64 buildds seem to have gone *splat*.
<infinity> pitti : Can you say "yay"?
<pitti> *vomit*
<infinity> sabdfl : ping.
<Kamion> sigh, firefox ate my laptop. again.
<Amaranth> all at once?
* Amaranth blames xorg
<Amaranth> :P
<{Seb}> Kamion: how long till the fix?
<Amaranth> Kamion: Easier to wait an hour or two than to edit one line and install 3 packages? :)
<Kamion> {Seb}: it's building
<Kamping_Kaiser> lol
<Kamping_Kaiser> nice work
<ogra> meh, "save as..." doesnt work in any app for me...
<bddebian> Nice
<Kamion> Amaranth: the problem with workarounds is that you have to go and un-workaround them later. After you edit xorg.conf by hand, automatic xorg.conf updating won't happen any more until you follow the runes at the top of the file.
<{Seb}> Kamion: if i make Amaranth's suggestion now and then upgrade to the new stuff, will everything be ok?
<Kamion> {Seb}: see above.
<ogra> bddebian, yes, especially in firefox thats fun... i cant download with it....
<{Seb}> also, why does /usr/bin/X11 get filled up with loads of stuff when i upgrade to X?
<Amaranth> um
<{Seb}> but sometimes, there is nothing there and I have to make symbolic links for X and Xorg
<{Seb}> i.e. ../../X11R6/bin/X --> /usr/bin/X11/X
<{Seb}> i.e. ../../X11R6/bin/Xorg --> /usr/bin/X11/Xorg
<{Seb}> but sometimes /usr/bin/X11 is filled with loads and loads of stuff - mainly unrelated to X
<Kamion> /usr/bin/X11 is a symlink to /usr/bin nowadays
<Amaranth> hehe
<Amaranth> that'd be why
<bddebian> ogra: Need me to fix that for ya? ;-P
<ogra> bddebian, go ahead :)
<ogra> its bugday !
<{Seb}> ok - i will be back in a bit
<{Seb}> thanks guys
<{Seb}> i just won't upgrade X!
<ogra> sabdfl, and the same for kubuntu www.grawert.net/kubuntulogo.png
<{Seb}> Kamion: will it be in the repos. tonight then?
<{Seb}> or just ready?
<bddebian> It's bugday again??
<ogra> bddebian, its wednesday
<eruin> woops, what changed in X today?
<Amaranth> eruin: It went modular
<daniels> Kamion: to be fair, the rune is just the single dpkg-reconfigure
<bddebian> It really is too bad that I'm worthless.. :'-(
<Amaranth> eruin: wait awhile or check out the xserver-xorg-* packages
<Kamion> seb128: evolution-data-server done
* ..[topic/#ubuntu-devel:daniels] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://www.ubuntulinux.org/wiki/DeveloperResources | If you have unexpectedly lost editbugs privileges, talk to mdz/ogra/kiko | Colony CD 2 released | dont forget the bugday today ! | yes, X is broken.  a fix has already been uploaded.
<seb128> Kamion: thanks
<{Seb}> will Xorg go up to -37 when it is done?
<eruin> Amaranth: aah, yeh, I skimmed through the changelog and saw that... I thought the nasty stuff was over, actually ;)
<Amaranth> {Seb}: -38
<{Seb}> kk - i will be watching ;-)
<{Seb}> bye
<Amaranth> -37 was DOA
<pitti> lifeless: "Error: invalid file system name 'auto'" -> that's fixed in Breezy
<daniels> -37 was doa through no fault of kamion's, it must be said
* Amaranth looks at daniels 
<Amaranth> :P
<Amaranth> who cares, as long as it gets fixed
<{Seb}> http://people.ubuntu.com/~lamont/buildLogs/x/xorg/6.8.2-37/
<{Seb}> 37 seems to be good
<Amaranth> it got unaccepted
<Kamion> {Seb}: it didn't make it through the archive for various complicated reasons
<daniels> Amaranth: yeah, Kamion fixed one of my screw-ups and I took care of the rest
<daniels> although this was a complete rush upload to take care of the problems
<daniels> so, uhm, xlibs might be fun
* lamont looks around for some tomatoes
<Amaranth> https://bugzilla.ubuntu.com/show_bug.cgi?id=12664 can be closed?
<Amaranth> hehe, ivoks replied to the bug
<Amaranth> ivoks: Kamion told me to file that :)
<daniels> if you're upgrading to -38, you probably (really) want to put xlibs on hold
<Amaranth> i'll stick with -36 then
<infinity> daniels : What have you done to xlibs?
<eruin> shouldnt xserver-xorg-input-kbd be all thats needed for the keyboard module?
<Lathiat> eruin: yeh but you need to s/keyboard/kbd in xorg.conf
<eruin> sometimes I think I should stay off my computer after coming home from work... thanks
<Lathiat> nah, its just cus it got broken good
<Lathiat> it'l be fixed soon
<lamont> daniels: I was asked yesterday when l-r-m will become current again...  seems it has xorg breakage....
<lamont>  /usr/include/X11 !-> /usr/X11R6/include/X11
<daniels> oh, I see
<daniels> remove_conffile_prepare doesn't actually work
<daniels> #@$UO*I@##$\
<daniels> infinity: programs/xkbcomp not getting built -> no XKB data
<ivoks> Amaranth: let me check what was that about
<ivoks> Amaranth: this is pendingupload, right?
<Amaranth> ivoks: yes
<hughsie> ogra: ping?
<ogra> hughsie, give me 10min
<hughsie> ogra: k
<Kamion> infinity: could you dep-wait debian-installer on udev-udeb (>= 0.060-1ubuntu2), please?
<Lathiat> Has anyone noticed spurious icon sizes in the file chooser
<Lathiat> say a .py file has a 48x icon
<Lathiat> or have i just got somethign weird going on here?
<Lathiat> also the gaim icon looks really crap, like a real small one scaled up
<infinity> Kamion : It's currently dep-wait on libiw27; is that still valid as well?
<infinity> Kamion : Erm, wait, no it can't be, libiw28 is in breezy now, right?
<Kamion> nope, that should be taken ofg
<Kamion> off
<infinity> I seem to recall doing that merge myself.
<Kamion> I fixed that earlier today
<Lathiat> xorg people: so what before depended on xlibmesa-glu, what should it be now?
<daniels> libglu1-xorg | libglu1c2
<{Seb}> hi all
<Lathiat> and for dev packages?
<{Seb}> speaking from ubuntu now
<{Seb}> Kamion: how is it going?
<daniels> Lathiat: xlibmesa-glu-dev will continue to work, but libglu1-xorg-dev is the new canonical name
<Lathiat> so i should change them if i have the chance?
<daniels> sure
<infinity> Kamion : All fixed up.
<Lathiat> ok
<Kamion> infinity: great, thanks
<{Seb}> Kamion: can you say when -38 is ready?
<Lathiat> {Seb}: Just wait or subscribe to the changes mailing list
<daniels> {Seb}: it's already been uploaded, just give it two hours or something and try then.  no-one knows exactly when.
<daniels> although -38 is broken too
<{Seb}> is it?
<daniels> and I'm looking at a -39 build while trying not to faceplant into the keyboard
<daniels> yes, it is
<daniels> xlibs won't upgrade
<ogra> {Seb}, subscribe to breezy-changes to see it coming into the build process, look at http://people.ubuntu.com/~lamont/buildLogs/ to see it coming out :)
<ogra> {Seb}, if it built it will show up in the archive soon
<Lathiat> daniels: does xlibmesa-gl have any problems?
<Lathiat> daniels: or 'better' changes ?
<Lathiat> daniels: same thing as glu?
<Lathiat> hrm *tries to understand the relationship*
<daniels> Lathiat: no, xlibmesa-gl is fine
<ogra> hughsie, re
<hughsie> ogra, cool.
<hughsie> ogra: hold fire on the PowerManager thing
<ogra> oki
<hughsie> i'm talking to davidz about getting it into HAL properly
<mdke> lists are down again?
<ogra> hughsie, hmm, but that means we wont see it n breezy....
<ogra> s/n/in
<hughsie> ogra, hence the PowerManager bodge if you need it..
<ogra> hughsie, hal wont see huge version jumps anymore i think
<hughsie> http://lists.freedesktop.org/archives/hal/2005-July/002711.html
<hughsie> it's in today's cvs, in a raw state
<ogra> yep, i saw that...
<ogra> but i dobt pitti will grab CVS for the release.... 
<mirak> what is the glibc version in ubuntu
<mirak> ?
<ogra> (pitti is our hal maintainer)
<mirak> hoary
<hughsie> ogra: agreed.
<tseng> mirak: packages.ubuntu.com
<hughsie> ogra: the powermanager thing should be good for you guys
<mdke> guys? anyone getting mail from the lists?
<ogra> hughsie, yes...
<ogra> mdke, hmm, none the last hours...
<mdke> guess they have gone phut again
<hughsie> ogra: what if the action support wasin 0.5.4 of HAL?
<jbailey> mirak: 2.3.2 snapshot from Sep 2003
<ogra> that coud be feasable, but still depends on pittis decision if he upgrades or not...
<mirak> ok
<hughsie> ogra: let me get more details from davidz
<ogra> hughsie, we are in upstream version freeze,so new upstream versions are considered very carefully and looked over twice
<seb128> Kamion, mdz: Debian has just got wxwidgets2.6, are we getting it now or that's for n+1?
<hughsie> ogra: cool. you tell me what works for you guys best, and i'll do my best
<ogra> seb128, NOW !! please ...
<Amaranth> users will like, scream and stuff if we don't get it
<seb128> but that's upstream freeze ....
<tseng> Amaranth: people use that?
<Amaranth> tseng: Well, vlc looks like ass with GTK1. :P
<mdke> even worse than scream... they backport
<Amaranth> mdke: true
<ogra> hughsie, if it will be in the next hal version, a backport would be cool, if its included upstream and pitti thinks its non intrusive and safe, we *could* get it in
<hughsie> ogra: i wouldn't use the word safe...it's a bit raw at the oment
<ogra> hughsie, whil powermanager would get dropped in the next release in favor of that... so my personal preferred solution would be to go with the backport
<ogra> s/whil//
<hughsie> powermanager is only a temp bodge (although this morning i thought it was less temporary!!)
<ogra> hughsie, if davidz is fine with a backport i'd prefer it... but i have to talk to pitti about his plans with hal
<jbailey> Kamion: ping?
<Kamion> jbailey: pong
<hughsie> ogra: okay, thats cool. pitti's decision really. it's p-m or the upstream HAL
<ogra> yep
<jbailey> Kamion: 3c509 is the old ISA card, isn't t?
<seb128> there is a new 0.5.3 hal today
<Kamion> jbailey: believe so
<Mithrandir> jbailey: yes, it is
* jbailey squirms.
<hughsie> ogra: i'll keep you informed with whats happending with hal
<jbailey> Can't we just send people a nice cheap PCI ethernet card?  It might be cheaper than sending them the breezy CD through shipit...
<Kamion> heh
<ogra> hughsie, great... note that i'm subscribed to the list ;)
<hughsie> ogra: no worries then :-)
<Kamion> jbailey: hmm, I think I'm going to need to backport the udev-udeb fixes from 0.062-1 - is that going to be OK?
<Mithrandir> jbailey: the right response to "I have a problem with $ISA_NIC" is "here's a nickel.  Buy yourself something less bad"
<seb128> ogra: have you ever mailed the guy who made the anjuta2 packages?
<ogra> seb128, we talk about backportig a feature from CVS 
<jbailey> Kamion: backport to Hoary?
<jbailey> Oh, from unstable.
* jbailey actually looks at the version.
<Kamion> jbailey: unstable->breezy
<ogra> seb128, wasnt he in -motu ? i thought they are in revu already....
<seb128> ogra: that was a mail on ubuntu-devel with 0 reply, I'm not on motu 
<jbailey> Kamion: I don't see a problem, which fixes are you bringing in?
<ogra> seb128, looking ....
<ogra> seb128, i've seen him in -motu and i know he was told to put it in revu for a review.... i'll mail him
<Kamion> jbailey: the fix to use a second optimised build, and presumably your fix to lndir.sh
<ogra> (its not in revu=
<ogra> )
<jbailey> Kamion: That's unclear, sorry.  I don't see a problem with you backporting bits.  For curiousity, what are you bringing in. =)
<seb128> ogra: k, thanks
<Kamion> jbailey: I need to build udev-udeb without selinux, you see ...
<jbailey> Kamion: My fix to lndir.sh should already be in our 0.060, I had to do it in order to build the udeb at all (And the only fix I think in his version is a bashism I did by accident)
<Kamion> ah, ok
<Lathiat> whats wiki for those code blocks
<Kamion> there's a debian/rules tweak or three, though
<Kamion> Lathiat: {{{ ... }}}
<Lathiat> thats what i thought
<Lathiat> are they no longer put in a nice little bordered section?
<Lathiat> or doe sit need to be more than 1 line
<Kamion> jbailey: the issue I saw was that build-tree/udev-udeb/ doesn't seem to be getting built usefully; i.e. no build-tree/udev-udeb/udev
<jbailey> Kamion: Ah, okay.  Are you already buried in the code?  If not, I can dig in there as I've seen it recently.
<Lathiat> ah, yes
<Lathiat> needs to be more than 1 line
<Lathiat> or at lesat have the }}} on the next line
<Kamion> jbailey: relatively buried, but I don't know it well so more eyes wouldn't hurt
* jbailey checks to made sure 0.060-1ubuntu1 is still the most recent
<Kamion> jbailey: actually, never mind, I see the problem
<Kamion> s/\(BUILD_.*\)__/\1/
<jbailey> Ah.
<jbailey> Oh, weird.
* jbailey wonders if he made that typo.
<Kamion> it seems to have been from Debian
<jbailey> cool, thanks.
<Kamion> there, fixed
<\sh> re
<bddebian> wb \sh
* daniels dputs xorg 6.8.2-39 and xkeybaord-config 0.5-1, goes to bed.
<daniels> your /etc/X11/xkb/xkbcomp symlink will disappear if you upgrade to xkeyboard-config.  for the meantime, just add it by hand if you care about XKB.
<mdke> :)
<mdke> that file was missing when I upgraded xorg recently in gentoo _stable_
<mdke> damn cowboys
<Lathiat> daniels: still around?
<daniels> Lathiat: no
<Lathiat> daniels: will shlibs:Depends handle the right depends?
<daniels> yes
<Lathiat> ok thanks
<daniels> np
<eruin> Lathiat: I've seen the weird filechooser sizes too
<lamont-away> daniels: pretty soon you're going to run out of fingers on your family's hands, yes?
<lamont-away> hrmpf.  no fun to troll him when he's sleeping
<Lathiat> anyone got a hack so that when using pbuilder it will dump the resultant .debs in the current directory
<Amaranth> why do you need that?
<Lathiat> cus im sick of sifting through the result directory :)
<winkle> BUILDRESULT=$PWD maybe?
<Lathiat> hm thats an idea
<cartman> (yes/no question) X.org on breezy is broken?
<Treenaks> yes.
<Treenaks> a lot.
<cartman> ok :)
<lamont-away> Kamion: you around?
<eruin> xorg isnt really that broken
<infinity> daniels : There's an x11proto-resource release sitting on your hard drive somewhere that you forgot to upload, isn't there?
<mdke> can someone try to connect to http://lists.ubuntu.com pls? I can't connect 
<bddebian> mdke: I can't hit it
<mdke> okay
<mdke> i'm always worried about my nameserver :)
<bddebian> :-)
<thierry> bug day today!? can I help?
<bddebian> Yeah, squash some bugs :-)
<hughsie> ogra: ping?
<ogra> hughsie, 
<ogra> pong
<hughsie> cool.
<hughsie> Been talking to davidz
<hughsie> the HAL thing could be a little way off release quality, certainly not in the next 3 months timeframe
<thierry> bddebian : yeah but you could say what is the mean task?? LIke confirming bugs, stack traces ect..
<ogra> hughsie, ok, so we'll go with the daemon ...
<bddebian> thierry: Well I couldn't, because I don't know anything.  I'm just here to entertain ogra. :-)
<hughsie> ogra: i thought you would say that
<hughsie> whens the next version of ubuntu? (silly question mode off)
<bddebian> Oh shoot, wrong channel
<thierry> ogra : what is going on with bug day? Can I help?
<ogra> code freeze is on augus 11th .... release some time in oct
<ogra> august even 
<hughsie> ogra: okay, the daemon might be pushing it even then?
<ogra> thierry, sure, look at the buglists in the topic of #ubuntu-bugs 
<thierry> ogra : http://tinyurl.com/c7gafa doesn't work (in the #ubuntu-bugs topic)
<ogra> hughsie, we'll get it sorted... worst case i can go with the pmi calls directly if necessary... 
<ogra> gah
<hughsie> Cool, what about mjg59 - has he acked anyhting?
<hughsie> gah?
<ogra> hughsie, yes the bug url is broken
<ogra> hughsie, wasnt for you
<ogra> hughsie, i havent met him yet
<hughsie> okay, no problems
<hughsie> i've uploaded the new site too (if you need to explain to anyone) gnome-power-sf.net
<ogra> hughsie, great, thanks :)
<ogra> thierry, link ficed
<ogra> fixed even
<thierry> ogra : k thanks
<hughsie> ogra: cheers, off to call g/f
<ogra> hughsie, bye and thanks :)
<hughsie> ogra: thank me when GNOME works like my g/f says it should. :-)
<ogra> hehe, improve it ;)
<ogra> i bet she's worth the extra work ;)
<AndyR> howdy
<thierry> ubuntu bug 1813 really should be solved before breezy : it's simple and would clear a lot of things to new users with the sudo command
<ivoks> fabbione: ping
<fabbione> ivoks: i am heading off line in 2 seconds
<ivoks> :(
<ivoks> fabbione: one q... is breezy kernel compiled with debuging?
<fabbione> ivoks: no.
<ivoks> ok, thanks
<fabbione> np
<fabbione> debugging make the linux-image ~ 150MB
<fabbione> so it's not an option
<fabbione> and the initrd ~40MB (if you are lucky)
<ivoks> https://bugzilla.ubuntu.com/attachment.cgi?id=2986
<ivoks> dmesg has strange output here, so i was wondering...
<ivoks> i don't understand this numbers in [ ] 
<fabbione> these are timestamps
<ivoks> i tought, maybe some kind of debug...
<ivoks> or that
<fabbione> it is useful for debugging yes.. but it's the full debug
<ivoks> timestamps are not in default kernel, or?
<ivoks> 2 seconds :)
<fabbione> it's a config option
<fabbione> yeah i need to go or my wife will kill me
<ajf> no longer is dmesg | grep ^hd
<ajf> :D
<fabbione> i haven't been feeling too good today and she is worried
<fabbione> cya
<ivoks> fabbione: get some rest and go to your wife
* fabbione &
<ubuntu> colony 2 cd doesn<t have the ubuntu cursors, is it normal^
<ivoks> yes
<ubuntu> ok so its not a bug to report^
<ivoks> https://bugzilla.ubuntu.com/show_bug.cgi?id=12490
<ivoks> allready reported
<ubuntu> thanks ivoks
<siretart> does anyone know about wxwidgets2.4 breackage in breezy?
<subjectdenied> hi, is lists.ubuntu.com down at the moment?
<lsuactiafner> yeh
<kiko> yo smurfix?
<smurfix> kiko: ?
<kiko> I was wondering
<kiko> could you be troubled to file a bug on signing the CoC using detached signatures so I don't loose that suggestion?
<smurfix> You mean as a separate bug? https://launchpad.ubuntu.com/malone/bugs/286 already has it, IMHO keeping the discussion together makes sense
<kiko> smurfix, the problem is that 286 is now "fixed".
<smurfix> ah, OK
<smurfix> will do
<kiko> smurfix, I think a separate bug -- you can refer to the old bug when filing it -- would be ideal for me bringing up the discussion
<kiko> thanks, I really appreciate it.
<AndyFitz> morning
<jp> /home/jp/.gconf/apps/evolution
<jp> sorry <-
#ubuntu-devel 2005-07-19
* lamont grumbles at xorg...  kamion: if you wanna make it quit sending me UNACCEPTs over and over I wouldn't complain
<tseng> daniels: what is the proper way to slow down a usb mouse that is on crack, but not affect the touchpad
<daniels> infinity: not any more, there isn't
<daniels> tseng: uhh ... right now, you can't
<daniels> they're not presented to xorg as distinct devices
<tseng> go xorg
<infinity> lamont : Should be fixed once the new version builds, which should be right around now.
<lamont> infinity: yeah... it's just annoying me
<infinity> You'll live.
<lamont> did xorg need some give-back love?
<infinity> It will once the new x11protowhateverthingee is in.
<Lathiat> daniels: When you got a chance could you look at https://wiki.ubuntu.com/MOTUGLUTransition and make sure it looks ok? (siretart wanted an xorg guru to check)
<lamont> right
<jp__> :S at breezy, with upgraded x packages I got: no screens found.. who couild fix it? thanks guys
<infinity> jp__ : It's already being fixed.  Just wait a few hours.
<seth_k> daniels: since libxrender-dev no longer ships libXrender.la, what do I tell this build that is asking for it? What do I use instead?
<jp__> infinity ok thanks
<infinity> daniels : "not anymore" was code for "I just uploaded it", right?
<infinity> daniels : Not seeing it in any queues, so now I'm paranoid. :)
<pef> good night !
<thierry>  ubuntu bug 10131 and 12380 are duplicate of ubuntu bug 11669
<thierry> could someone make the changes? I don't have the permissions to do so
<thierry> and bug 11669 should be set as critical
<AndyFitz> ping
<AndyFitz> JOIN #ubuntu-devel
<jp__> !
* infinity applauds AndyFitz's attempts to reinforce the stereotypes about the technical ineptitude of artistic people.
<lsuactiafner> lol
<AndyFitz> hehehe.   its sooo true..    im typing from centreicq now that X has broken
<daniels> infinity: yeah
<daniels> infinity: well, I uploaded it 25 minutes ago now
<lsuactiafner> try bitchx for the console..
<AndyFitz> damnit.. i trusted those updates  and as soon as you fall in love your heart gets broken
<daniels> seth_k: just -lXrender
<seth_k> how's that again, daniels?
<seth_k> forgive my lack of knowledge
<AndyFitz> fix my X and i'll e-mail some shiny bling icons :)
<daniels> x is fine
<daniels> seth_k: which build?
<seth_k> daniels: i'm in the middle of packaging kmobiletools
<AndyFitz> no.. X isnt fine.  last update broke it
<seth_k> no, you just need to install the mouse and kbd drivers
<seth_k> the drivers got modularized
<infinity> AndyFitz : It'll unbreak in the next few hours.  Just waiting on various computers to do their thing.
<infinity> AndyFitz : Or get someone like seth_k to walk you through fixing it manually. :)
<AndyFitz> so what should i apt-get install..   i kinda need X before 10:30 GMT+10
<AndyFitz> seth_k,  mate,
<seth_k> AndyFitz: xserver-xorg-input-kbd and xserver-xorg-input-mouse and xserver-xorg-driver-###
<daniels> Lathiat: ta
<seth_k> ati or nv or whatever
<AndyFitz> nv
<seth_k> okay, those three then
<daniels> AndyFitz: also xserver-xorg-core
<AndyFitz> nvidia-glx if possible
<infinity> Have a LAN party you need to urgently attend? :)
<infinity> (I'm pretty sure binary nvidia drivers are still a no-go on breezy until someone gets some round tuits)
<AndyFitz> nah, just Red Hat
<seth_k> yep, nvidia glx still dead
<seth_k> libtool: link: cannot find the library `/usr/lib/libXrender.la'
<seth_k> anyways daniels, my build goes happily along until we get to that
<thierry> where do I go if I want to propose a new applications to the MOTU team?
<seth_k> have you packaged it? If so, revu
<thierry> seth_k : this one? http://siretart.tauware.de/revu/
<seth_k> thierry, that's right
<thierry> k thanks
<AndyFitz> bizzare,  its still not running.   would dpkg-reconfigure xserver-xorg  do anything
<AndyFitz> or would i dig myself deeper :)
<infinity> AndyFitz : What's it complain about?
<seth_k> AndyFitz: one more change to make
<infinity> AndyFitz : s/keyboard/kbd/ in xorg.conf may be required.
<seth_k> bah, beat me to typing it :)
<seth_k> indeed, you must sudoedit /etc/X11/xorg.conf and change your keyboard driver from "keyboard" to "kbd"
<AndyFitz> sudo nano /etc/X11/xorg.conf here we go
* infinity grumps.
<AndyFitz> IT WORKS!
<infinity> daniels : You did get an ACCEPT mail for that proto-resource upload, I assume?
<AndyFitz> the future is now .  many thanks
<infinity> daniels : Ahh, so you did.  Finally got it on -changes.
* seth_k ponders the cryptic "-lXrender" and hopes daniels did not die, so he can clarify
<daniels> seth_k: um, yo
<tseng> link to the lib Xrender
<daniels> seth_k: i'll check the problem out a bit later
<daniels> seth_k: just dealing with the world having exploded in my inbox overnight
<seth_k> yeah, I know you're probably busy :P
<seth_k> hence I wait
<davyd> I was labouring under the misapprehension that Hoary shipped with tomboy
<tseng> davyd: uh
<tseng> davyd: it didnt?
<davyd> by shipped I mean
<davyd> was in universe
<Surak> hello
<tseng> ...
* tseng hands davyd packages.ubuntu.com
<Surak> Hello people
<davyd> I always forget you have one of those
<davyd> aah, not built for amd64
<daniels> right, we didn't have mono for amd64 in hoary
<davyd> aah
<davyd> is it in breezy?
<tseng> dude
<tseng> packages.
<tseng> use it
<Surak> who should I ask about breezy daily builds? live isn't being built for i386 for some days...
<davyd> yeah, doing that
<davyd> I don't have a mouse handy
<davyd> so I'm having to alt tab around a lot
<davyd> hmm, I wasn't going to go to breezy on this machine... but for tomboy...
<TerminX> daniels: what's the accepted fix for the problem where xkbcomp spits out a bunch of errors on X startup and then every keypress just changes the resolution?
<daniels> TerminX: 'make xkbcomp not do that'?
<daniels> what were the errors?
<davyd> (stupid X-chat)
<daniels> it sounds like one of /usr/lib/X11/xkb or /usr/X11R6/lib/X11/xkb is not a symlink to /etc/X11/xkb
<davyd> tseng: is someone doing mono backports to hoary?
<tseng> davyd: unfortunately.
<daniels> and/or /usr/lib/X11/XKeysymDB and/or /usr/X11R6/lib/X11/XKeysymDB is not a symlink to /usr/share/X11/xkb
<davyd> unfortunately?
<TerminX> hmm.. I don't have any of those symlinks
<tseng> yes, they never approached me before doing it
<TerminX> if they're needed, shouldn't the packages be creating them?
<tseng> and made a big mess of it
<daniels> TerminX: of course ... that's why they do create them
<TerminX> they don't seem to here.
<davyd> tseng: so don't even bother with them?
<tseng> davyd: i dont remember if they even bothered with !x86
<TerminX> as soon as I install any newer libx11-6/xlibs/xlibs-data than what is in hoary, the problem happens
<TerminX> like with the current packages
<daniels> TerminX: and you have the latest x-common installed as well?
<TerminX> yes
<daniels> bong
<daniels> daniels@brainfreeze:~/canonical/xorg/lib/libx11% dpkg-deb -c libx11-6_6.2.1+cvs.20050711-1_amd64.deb | grep XKeysym
<daniels> -rw-r--r-- root/root      8298 2005-07-11 10:15:09 ./usr/share/X11/XKeysymDB
<daniels> lrwxrwxrwx root/root         0 2005-07-11 10:15:13 ./usr/lib/X11/XKeysymDB -> ../../share/X11/XKeysymDB
<daniels> lrwxrwxrwx root/root         0 2005-07-11 10:15:13 ./usr/X11R6/lib/X11/XKeysymDB -> ../../../share/X11/XKeysymDB
<TerminX> hmm
<davyd> tseng: would building breezy Mono debs on Hoary lead to much pain?
<davyd> I can't imagine that the Mono dependancy tree has changed incredibly much externally
<davyd> (stupid X-chat again)
<tseng> well it takes me a few hours
<davyd> I only want enough Mono for tomboy and muine
<tseng> as for anyone else
<tseng> cant say.
<davyd> is it likely to just be a matter of getting the source and debuilding it?
* davyd has not worked with the toolchain on amd64 yet
<tseng> mono and cli-common needs to be bootstrapped
<tseng> then build gtk-sharp, gtk-sharp2, muine, tomboy
<davyd> but suspects he'll be getting good somewhere around 3 weeks from now
<tseng> we dont really have docs on it
<davyd> failing that... can I somehow jam breezy mono onto Hoary?
<tseng> you have to remove cli-common build-dep, and remove dh_*cli* calls from rules
<tseng> build, install
<tseng> build cli-common
<tseng> install
<tseng> replace above, rebuild mono
<whiprush> mako: has that jdong guy talked to you lately? I'm supposed to sign his key but he seems missing.
<tseng> and then work your way up the rest of the ladder
<davyd> tseng: ok, I'll have a play with that tonight when I get home from work
<davyd> it's time for me to go now
<tseng> ok
<davyd> thanks
<tseng> np
<TerminX> daniels: is /usr/share/X11 supposed to be a symlink to /usr/X11R6/lib/X11?
<daniels> TerminX: ... no
<TerminX> wtf
<TerminX> what's the easiest way to purge all of X and reinstall it
<TerminX> heh
<daniels> delete the symlink, create a dir in its place, I'll take care of it in an x-common upload
<daniels> err ... heh
<TerminX> I checked into that XKeysymDB thing -- there was no actual file
<TerminX> just symlinks linking to symlinks linking to nonexistent stuff
<daniels> how recent is your libx11-6?
<daniels> ok
<TerminX> current as of now
<daniels> so nuke the symlink, create the dir, reinstall libx11-6
<TerminX> done
<TerminX> daniels: that appeared to work, but I had to mv /usr/X11R6/lib/X11/fonts to /usr/share/X11
<TerminX> should I need to do anything else?
<Nafallo> ehm... why are there no buildlogs for amd64 for the more recent uploaded packages?
<Nafallo> I can see no *_amd64.deb hitting the archive either :-/
<daniels> the amd64 buildds appear to be dead in the water
<daniels> TerminX: that should be alright
<Nafallo> oh joy! :-(
<TerminX> daniels: okay, thank you for your help :)
<Nafallo> anyway, goodnight! :-)
<jp> is x good now?
<seth_k> sure
<seth_k> works fine
<seth_k> with a bit of tweaking
<jp> cool, so I keep tweaking it :P
<jp> thanks
<infinity> daniels : -39 is FTBFS.  Missing build-dep.
<infinity> daniels : cannot find -lXtst
<mrd`> Anyone else having problems trying to upgrade openoffice.org2-* in Breezy?
<jp> how did some symlinks to get working xorg? to share them... :( thanks :D
<jp> :$
<mrd`> I have no idea what you just said.
<mrd`> (Anyways, I think I found a workaround for OOo2 on bugzilla...)
<jp> mrd`:  I can't start x, and somebody of here said me that x is working, but I can't start it (sorry my english)
<jp> and Ive been doing some symlinks, reinstalling xserver but I cant get it working :/
<KaiL> mrd`: uninstall openoffice.org2-base, then do apt-get -f install and then install base again
* mrd` tries KaiL's method since the bugzilla one didn't work.
<KaiL> it's a very "funny" version of file conflict (one file moved from base to common and one from common to base), so you can't just say "install the other one first"..:(
<mrd`> Was the file swap intentional?
<KaiL> I don't know
<jp> :(
<daniels> infinity: let me guess, hw/dmx?
<mrd`> KaiL: Your method seems to be working, thanks!
<mrd`> jp: Sorry, X's working for me.  Did you check if your problem's listed in Bugzilla?
<KaiL> well, it worked here too :)
<jp> how did you get it working?
<jp> doing ln -sf /usr/X11R6/bin/X /etc/X11/X ?
<KaiL> I wonder, that openoffice.org website doesn't have this 114 ;)
<jp> I can't, sorry guys..
<mrd`> jp: Yeah, I had to do that once upon a time.
<KaiL> at least it seams to be faster
<infinity> daniels : Dunno, already deleted the log mail.
<infinity> daniels : They're copied into ~lamont, though.
<daniels> infinity: -40 uploaded
<infinity> Schwoit.
<lamont> daniels: so who's fingers are you gonna use to figure out the revision for the next upload??? :-)
<daniels> i won't mind if you force me to take sick days
<jp> I know that it's a development channel, but can somebody help me to get working x? sorry guys and thanks
<jp> uhmm where is the correct X file now? /usr/X11R6/bin/ ? where? that would help me a lot, I treied with /usr/bin/X but doesn't work
<mrd`> My /etc/X11/X points to /usr/bin/X11/Xorg.
<jp> thanks mrd` 
<jp> heheh mrd` no it says me no screens found that's an advance, thanks :)
<mrd`> Sorry, that's as far as I'll be useful helping out. ;)
<jp> heheh :P
<jp> i really want to cry 
<jp> I've been trying more than 2 hours :(
<jp> the log file says that it doesn't recognize my hardware... that can't load "sis" "keyboard" "mouse" module
<jp> :/
<infinity> If anyone can explain to me why I've been awake for over 26 hours, they get a prize.
<infinity> Alternately...
* infinity -> sleep.
<mrd`> Caffeine?
<jp> mrd`: a gun :)
<TerminX> jp: you need to install some new packages
<TerminX> like xserver-xorg-input-mouse, xserver-xorg-input-kbd, and xserver-xorg-driver-sis
<TerminX> and you might have to change your xorg.conf to use kbd instead of keyboard for the keyboard driver
<TerminX> oh
<TerminX> he left.
<TerminX> shit.
<mrd`> My xorg.conf still has ``Driver "keyboard"''; should I change it?
<tseng> kbd
<mrd`> Hm... the xserver-xorg package says "This package is a dummy package which depends on the core X.Org X server", but it doesn't seem to have any dependencies.
<daniels> mrd`: /topic
<mrd`> daniels: Ah. :)
* mrd` didn't notice that when he joined.
<lamont> did python-apt get tweaked to support hoary-backport versions, I wonder?
<fabbione> morning
<wasabi_> dev related question sorta: Is Ubuntu installable alongside Windows currently?
<wasabi_> ie resize tools? I had heard we were making progress on that front.
<wasabi_> has any thought been put into doing so, and when done, automounting the windows drive in some position and providing an icon on the user's desktop?
<wasabi_> "Windows Documents" for instance, which would be a .desktop file which would point to /windows/Documents and Settings/*somehow find previous username*
<schweeb> wasabi_: NTFS resize is included in hoary
<schweeb> in the installer
<schweeb> I used it on this laptop
<wasabi_> Well, I was just thinking about the whole auto mounting exposure thing...
<wasabi_> So as soon sa the user gets in, he has his docs in front of him.
<wasabi_> We're still read-only NTFS without Captive though aren't we.
<wasabi_> Still, it woudl be a step.
<schweeb> the docs would be pretty hard to do
<schweeb> considering you couldn't reliably determine which username is which
<wasabi_> Yeah I had thought of that.
<wasabi_> best idea I guess is to put them all in there.
<wasabi_> I wouldn't wnat to link directly to C: though, as a large majority of people don't even know their stuff is in Docs and settings
<schweeb> a better option would be... "migrate my windows documents and settings" icon
<schweeb> that allows you to select a user name
<schweeb> and brings in the favorites
<schweeb> which I think is actually in the works
<wasabi_> Hmm. Well. I dunno if I like that.
<wasabi_> Mostly because it dehooks them.
<wasabi_> I'd like that, if I could run it whenever I chose to.
<wasabi_> I might want to dual boot for awhile.
<wasabi_> Or forever.
<schweeb> no matter what, your settings aren't going to go both ways
<schweeb> until you have captive
<schweeb> and it provides less clutter on the desktop with the icons from all 20 users on your system
<wasabi_> Yeah. Well... is that an option?
<schweeb> not legally
<schweeb> captive requires microsoft's NTFS driver
<wasabi_> It's there.
<wasabi_>  /windows/WINDOWS/System32/NTFS.dll
<wasabi_> =)
<schweeb> you need a specific version, matching what captive expects
<wasabi_> I think knoppix did this.
<wasabi_> And it works.
<schweeb> knoppix includes a script that downloads this driver for you
<schweeb> afaik
<schweeb> and/or they can get away with it a bit, because it's not a commercially supported distro (ubuntu is gaining commercial support, through canonical)
<wasabi_> I would think Captive would be able to use any NTFS.dll version from Xp anyways
<daniels> gnar
<daniels> svenl: ping
<wasabi_> Aren't they all the same? Maybe slight modes for sps
<schweeb> wasabi_: nope
<schweeb> it wants a specific version in all of my experiences
<wasabi_> Guess it should just be fixed. ;)
<wasabi_> Either way, ya can mount /windows originally with the read only ones, copy NTFS.DLL, and remount it with the new ones pretty easily.
<schweeb> think it's just due to how captive works
<schweeb> like I said...
<schweeb> copying NTFS.dll doesn't necessarily work
<fabbione> daniels: libxtst is FTBFS...
<fabbione> daniels: ETA for a fixed version?=
<fabbione> libxevie too
<schweeb> daniels: no sleep for you until X is release ready!
<wasabi_> Yeah, doesn't support SP2
* fabbione hands a clean buildd chroot to daniels
<wasabi_> I suspect that could be fixed.
<schweeb> wasabi_: you can't really depend upon users having a certain version of windows installed
<daniels> fabbione: both fixed
<schweeb> some may have 2k, 2k3 server ,xp sp1, xp sp2... or any patchlevel thereof
<daniels> fabbione: libxevie was fine, it's just that I forgot to upload the new x11proto-evie
<fabbione> daniels: that's sitting in NEW now... right?
<daniels> should be in the queue
<wasabi_> schweeb, huh?
<wasabi_> Sure you can. There is a finite set.
* fabbione tries a rsync
<fabbione> daniels: i just got my adsl upgraded at 6Mb/768 :)
<daniels> fabbione: eh, I uploaded it all of two minutes ago
<daniels> nice
<daniels> i still have 1.5
<fabbione> ah ok..
<fabbione> i tought you did a while ago :)
<daniels> ah, no
<daniels> i prepared it days ago
<daniels> just never got to upload it
<fabbione> punk
<schweeb> wasabi_: you'd have to know at which patchlevels in between NTFS.DLL was changed, and account for each one.  and as I said, I'm pretty sure captive wants an exact version of said dll
<lifeless> rotfl
<wasabi_> Just fix Captive to work with them all. ;)
<schweeb> wasabi_: think it's just part of how captive works
<schweeb> is is a known bug, dev nodes not being created for /dev/input/mice and /dev/psaux, even though psmouse and mousedev are loaded?
<schweeb> can't exactly check bugzilla right now, as my X isn't working due to these 2 issues...
<daniels> apparently udev is having issues
<schweeb> wonderful
<schweeb> could someone give me the major/minors for those 2 nodes plz?
<daniels> crw-rw----  1 root root 13, 63 2005-07-09 16:46 /dev/input/mice
<daniels> crw-rw----  1 root root 10,  1 2005-07-09 16:46 /dev/psaux
<schweeb> much appreciated
<daniels> np
<schweeb> and that fixed it
<schweeb> whee
<schweeb> is udevd having issues, or is it in the conf files?
<jsgotangco> hi
<sivang> morning all
* lamont wanders off
<sivang> does anybody know if the laptop testing team propsal is still on?
<doko> Kamion, mdz: please promote xcursorgen to main, split out from the xbase-clients package, all packages in main depending on kdelibs4-dev currently FTBFS
<daniels> xvinfo as well
<HrdwrBoB> xvattrib?
<daniels> yeah, we need to get xvattr in
<daniels> but it not being in main won't cause anything b-d'ing or depending on xbase-cleints to ftbfs ;)
<daniels> -> doesn't make doko quite as upset
<HrdwrBoB> heh no :)
<doko> upset? no, I'm quiet, I'm really quiet, I'm not upset, I'm not even getting upset. Really. 
<doko> ;)
<svenl> daniels: pong ?
<daniels> svenl: my pegasos is broken to hell
<dilinger> svenl: did you see my message yesterday?
<dilinger> regarding the build failure
<svenl> dilinger: don't think so.
<svenl> daniels: huh ? Can you give any more diagnostic info than that :)
<dilinger> svenl: log into the ppc machine as user guest
<dilinger> and run screen -rD
<dilinger> (or screen -rD <pid>, if there's multiple ones)
<dilinger> and you can see the build error i got
<svenl> dilinger: ok, but we are on wrong forum now.
<svenl> here i mean.
<dilinger> *shrug*
<dilinger> just passing the message along, we can discuss it later if there's anything to discuss
<svenl> Kamion: ping ?
<svenl> Kamion: did you activate the mkvmlinuz calls on the daily builds ?
<mdeboer> hello
<mdeboer> anybody knows what version of debian-installer was used to create the hoary livecd?
<Treenaks> mdeboer: the version that is in hoary, probably
<mdeboer> yes, sorry
<mdeboer> i see 
<mako> whiprush: i haven't talked to him for a little while
<Kamion> daniels: xcursorgen promoted
<Kamion> svenl: er, ENOCONTEXT
<Kamion> daniels: although again, please remove its Conflicts on xbase-clients
<daniels> Kamion: right.  will do that when I get to uploading it.
<daniels> only had the chance to do it for xvinfo so far
<daniels> thanks for the promotion
<fabbione> Kamion: hey dude..
<Kamion> yo
<JaneW> APPEAL: doesn;t someone wants to take on PrintingRpoadmap and give it some love? Pretty please? http://udu.wiki.ubuntu.com/PrintingRoadmap
<daniels> not me sorry, I'm overcommitted already
<svenl> Kamion: a couple of month ago, i asked you to enable the mkvmlinuz call in the ubuntu-installer builds to generate the vmlinuz for chrp at least, and maybe even the two prep.
<svenl> Kamion: not including them in the cds is ok, but maybe they could go in the common dvd, since there the place constraint is not as strong.
<sivang> JaneW: I already hacked on gnome print, I may give it a glance but since I'm already started some work on LaunchpadINtegration, not sure how much time I have for it
<sivang> JaneW: I did the "enable" browing stuff :-)
<pef> hello
<JaneW> sivang: cool, whatever you can do will help :))
<svenl> Kamion: i will fix nobootloader to pull in mkvmlinuz and make the call, so it will be complete in this way.
<mdeboer> i am trying to build linux-kernel-di-386-2.6, but it (kernel-wedge) complains about missing firmwares...
<mdeboer> kernel-wedge copy-firmware 2.6.12-rt-v0.7.51-28 386 2.6.12-rt-v0.7.51-28-386
<mdeboer> missing firmware atmel_at76c502.bin
<mdeboer> any idea? i have the firmware package installed
<Kamion> svenl: it's a udeb bug
<Kamion> fabbione: please add /usr/lib/linux-image-* to the kernel-image udeb on powerpc
<Kamion> mdeboer: linux-kernel-di-i386-2.6 isn't the supported way to build udebs for our kernels any more; the linux-source-* source packages build them directly
<mdeboer> Kamion: how?
<Kamion> mdeboer: normal package build
<fabbione> Kamion: hmmm is that the same we did a long time ago?
<Kamion> fabbione: you did it for the .deb, but not the kernel-image .udeb
<fabbione> Kamion: i am not sure if we can easily do that.. but i will look into it
<svenl> Kamion: huh ?
<mdeboer> Kamion: uhm...
<svenl> Kamion: this time is me that don 't follow ....
<Kamion> svenl: please read context SURROUNDING what I said ;-)
<Kamion> fabbione: oh, hang on, it might be a kernel-wedge thing, one sec
<fabbione> Kamion: yes.. that's what i meant
<Kamion> fabbione: yeah, I'll fix
<svenl> i still don't get it.
<fabbione> Kamion: ok, just be sure that they don't land in the ppc64 too...
<svenl> Kamion: and am i right in thinking that it is fully unrelated to what i asked you ? 
<mdeboer> Kamion: let's get this straight... I downloaded the linux-source-2.6.12 from the ubuntu pool, patched it, and did a make-kpkg .... binary
<fabbione> Kamion: the postinst hook that does that for ppc is not installed in the ppc64 flavour
<svenl> make-kpkg is fully broken :)
<mdeboer> Kamion: that gave me a bunch of packages, included the image i am running now, but no udebs.
<svenl> maybe make-kpkg should be patched to prodyce the udebs also.
<mdeboer> Kamion: it also gives me a new linux-source package with my patched kernel
<svenl> or fully replaced or something.
<fabbione> svenl: dude... make-kpkg does NOT make udebs
<svenl> fabbione: exact, it should though.
<fabbione> mdeboer: you need to look at how is done in apt-get source linux-source-2.6.12
<svenl> fabbione: the idea would be to be able to generate exact the same packages using the official build stuff or make-kpkg, this was the initial goal of make-kpkg.
<fabbione> svenl: no. it's not make-kpkg job to do it.
<fabbione> there is kernel-wedge for it
<svenl> fabbione: well, there should be a make-kpkg target to call kernel-wedge, don't you think ? 
<Kamion> svenl: no please stop it I'm fixing it.
<svenl> Kamion: it -> make-kpkg ? 
<Kamion> mdeboer: use dpkg-buildpackage
<svenl> Kamion: ah, ok.
<Kamion> svenl: no.
<svenl> Kamion: you still didn't reply to me about the mkvmlinuz call in the installer builds.
<mdeboer> Kamion: ok. i'll try.
<Kamion> svenl: I'M FIXING IT
<Kamion> OK? :-)
<svenl> Kamion: mmm , sorry, i probably got totally confused by the 2 (3?) discussions going about here.
<Kamion> svenl: as I say it's a bug in our kernel-image udeb, not in the installer builds
<svenl> Kamion: could you explicit the "it" part of your phrase for poor confused me ?
<mdeboer> Kamion: i appreciate your help. I sent a mail to the ubuntu-devel mailinglist, explaining what i am doing, and why.
<Kamion> svenl: which is due to a bug in kernel-wedge, which I am fixing now
<Kamion> svenl: the installer builds *do* include a call to mkvmlinuz. That call fails because the /usr/lib/linux-image-* directory is missing from our kernel-image udeb.
<svenl> Kamion: ah, ok.
<svenl> Kamion: thanks.
* svenl was confused by the mention of 's problem concerning firmware and stuff, and the make-kpkg comments where not for you but for his issue.
<svenl> Kamion: thanks for fixing it.
<mdeboer> Kamion: just to make sure, i am using hoary, so no 2.6.12 source package here. if i take the breezy 2.6.12, would that give me any problems?
<Kamion> svenl: I was having the discussion with fabbione as well as with you, because I briefly thought that it must be a bug in the kernel build process; sorry if that confused you
<Kamion> mdeboer: linux-source-2.6.10 generates udebs too
<Kamion> mdeboer: yes, you need newer initrd-tools and possibly newer udev; we don't support 2.6.12 on hoary ...
<Kamion> it gets complex
<svenl> Kamion: yeah, it was rather strange, especially as you adked me to read the surrounding which was full of 's problem :)
<mdeboer> Kamion: ok.
<Kamion> 09:42 < Kamion> svenl: it's a udeb bug
<Kamion> 09:42 < Kamion> fabbione: please add /usr/lib/linux-image-* to the kernel-image udeb on powerpc
<Kamion> that :-)
<mdeboer> Kamion: i need 2.6.12, because i want to use the latest rt-preempt patch
<svenl> Kamion: ah, well.
<svenl> 10:35 <deboer> am trying to build linux-kernel-di-386-2.6, but it (kernel-wedge) complains about missing firmwares...
<svenl> 10:35 <deboer>ernel-wedge copy-firmware 2.6.12-rt-v0.7.51-28 386 2.6.12-rt-v0.7.51-28-386
<svenl> 10:35 <deboer>issing firmware atmel_at76c502.bin
<svenl> 10:36 <deboer>ny idea? i have the firmware package installed
<svenl> 10:36 <Kamion>venl: it's a udeb bug
<svenl> :)
* svenl still wonders why screen/irssi/ssh eats the first char of the lines :/
<fabbione> svenl: if you stop flooding the chan, you won't have to worry about screen eating one char
<Kamion> svenl: anyhow, kernel-wedge 2.05ubuntu2 should fix this; thanks for drawing it to my attention
<fabbione> svenl: try to change to a more sensible locale...
<fabbione> like avoid {fr,*}_{*,FR} ;)
<Lathiat> fabbione: you know that expands to *_* as well ;)
<fabbione> Lathiat: yes.. it still allow you to use LANG=C
* Lathiat laughs
<fabbione> given there is no _
<Lathiat> true
<Lathiat> i use en_AU.UTF-8
<Lathiat> works good
<razr23> X works again, but depends are missing for xserver-xorg-input-kbd and mouse. maybe you already know that
<mdeboer> Kamion: if i manage to succesfully generate the udebs, and i modify the hoary live-cd to include those, and the 2.6.12 vmlinuz, and the initrd to include the 2.6.12 modules, do you think the livecd will work?
<Kamion> razr23: yes, we know, the fix hasn't made it into the archive yet
<Kamion> mdeboer: you'll have to modify a LOT of stuff, including the debian-installer source package
<mdeboer> Kamion: the problem is, i cannot find any documentation on generating the livecd from scratch...
<Kamion> mdeboer: there isn't any yet :(
<svenl> fabbione: nope, it has been happening everytime since i arrived in HEL, must be something funny going on.
<mdeboer> Kamion: i did manage to boot the livecd with 2.6.12
<mdeboer> Kamion: it fails when it looks for the module udebs.
<Kamion> mdeboer: yeah, I'm sure it won't load any modules though
<svenl> fabbione: i run ubuntu with probably fr-utf8 on the laptop, and debian with probably fr-latin1 on the server box where irssi is running, probably that.
<mdeboer> Kamion: well, it loads the initial modules from the initrd
<svenl> Kamion: no problem, i was helping daniels out doing a pegasos install, which brang it to my attention.
<Kamion> mdeboer: yeah
<mdeboer> Kamion: if i put the 2.6.12 module udebs on the cdrom, wouldn't that be enough?
<Kamion> mdeboer: you could follow the documented customise-an-existing-live-CD process to slam the new kernel package in
<svenl> lui doesn't help, oh well.
<Kamion> mdeboer: you really need to rebuild debian-installer against that new kernel, modifying stuff in build/config/
<Kamion> and if you're unlucky, build/pkg-lists/ too
<mdeboer> Kamion: ok, using the hoary debian-installer?
<Kamion> mdeboer: using hoary, you have to port it to 2.6.12. As I said.
<mdeboer> Kamion: yes, but i meant, would it be better to use hoary's debian installer, and modify it to 2.6.12, or use breezy's debian installer and backport it?
<Kamion> mdeboer: I'm honestly not sure. I'd probably do the former.
<chrissturm> hey guys, how do i get my keyboard back in X?
<jsgotangco> hi
<Lathiat> chrissturm: xserver-xorg-input-kbd s/keyboard/kbd in xorg.conf
<Lathiat> chrissturm: or wait 
<mdeboer> Kamion: ok. but first things first. I will build the linux-source-2.6.12-2.6.12 with dpkg-buildpackage
<jsgotangco> waiting is good
<chrissturm> thx Lathiat
<Kamion> daniels: so, uh, is the Xtst build failure in xorg -39 known?
<mdeboer> hmm... dpkg-buildpackage fails at: cp -p debian/patches/00list-3.4 debian/patches/00list
<mdeboer> oh, i understand why
<mdeboer> sorry
<mdeboer> Kamion: should I apply my kernel patch inside linux-source-2.6.12-2.6.12, before running dpkg-buildpackage there, or should i do that later on?
<Kamion> mdeboer: the former
<Kamion> mdeboer: well, stick it in debian/patches/ and massage stuff to make it apply
<Kamion> mdeboer: at that point you are out of the realm of things I am familiar with
<mdeboer> ok
<SloMoSnail> where can i request a resync of a universe package from debian? we have a *-ubuntu1 version but the changes from the debian version are not relevant anymore so a plain resync will do
<herve> hello
<herve> I guess debconf took the people I was trying to reach
<dave_>  hi! shot question: i am creating a custom-ubuntu-cd! i do it all in my shell-scripts - what i wonder: can you download the build-shell-scripts/tools of ubuntu anywhere? i _can_ create my own build system - but do i have to ?
<Kamion> apt-get install bazaar && baz register-archive http://people.ubuntu.com/~cjwatson/archives/colin.watson@canonical.com--2005 && baz get colin.watson@canonical.com--2005/cdimage--mainline--0 cdimage && cd cdimage && baz build-config configs/devel
<Kamion> ... or words to that effect ...
<Kamion> you'll have to poke at it a fair bit to make it work on your system - changing paths and such
<herve> hello Kamion, I was trying to reach you or mdz about merging packages with debian unstable 
<dave_> thanks Kamion !
<dave_> i will try that!
<Kamion> herve: yes?
<herve> dia 0.94-11 contains all of my patches plus one
<herve> so we can drop the -ubuntu stuff
<herve> no, more than one
<pef> can I put 755 files in /usr/share/foo/* ? it's for a tcl/tk script package
<tseng> ugh, no?
<herve> pef, it should be in /usr/lib then, no?
<pef> herve: I don't know how to to things properly. I want a script be in the $PATH, can I 755 the script in /usr/share/foo, and symlink it to /usr/bin ?
<herve> seems bad to me
<herve> Kamion, now packages.ubuntu.com tell me dia is in universe... so I could upload it as a motu
<pef> herve: to me too, but see that : $ find /usr/share/ -type f -perm 755 |grep -v examples
<herve> last time, seb128 had to upload it for me, I'm getting lost
<herve> pef, broken upstream? :-)
<pef> hum
<Kamion> herve: the source is in main
<pef> herve: so, how can I do ? leave the script as 644, and wrote a wrapper script in /usr/bin/foo ?
<Kamion> herve: and you must not just upload in cases where you're syncing back to the exact Debian version
<Kamion> herve: anyway, I've reviewed the changes, and syncing looks fine. Please mail James Troup with the sync request, saying that I've approved it.
<herve> Kamion, ok thanks
<bob2> herve: non-arch-specific things should not be in /sr/lib
<herve> /usr/share you mean?
<bob2> no
<herve> or arch-specific?
<Kamion> ... unless it's gratuitously inconvenient for them to be elsewhere
<bob2> well, yeah
<bob2> but sticking a pile of TCL in /usr/lib/ seems kinda pointless
<Kamion> having non-arch-specific things in /usr/lib is only a dubious space problem at worst. having arch-specific things in /usr/share is actually a problem
<herve> argh, I missed the two negations!
<lifeless> TCL is pointless
<Kamion> people get a bit too religious about the former
* fabbione kicks xorg -40
<fabbione> Rejected: libxtst6-dbg_6.8.2-40_sparc.deb: old version (1:1.13.0-1) in breezy >= new version (6.8.2-40) targeted at breezy.
<fabbione> Rejected: libxtst6_6.8.2-40_sparc.deb: old version (1:1.13.0-1) in breezy >= new version (6.8.2-40) targeted at breezy.
<fabbione> Rejected: libxtst-dev_6.8.2-40_sparc.deb: old version (1:1.13.0-1) in breezy >= new version (6.8.2-40) targeted at breezy.
* fabbione sighs
<sivang> Kamion: do you make distinction between ppc64 installer images and 32bit ones?
<Nafallo> still no debs for amd64?
<mdeboer> if dpkg-buildpackage in linux-sources-2.6.12-2.6.12 fails halfway, is there a way to restart the process?
<mdeboer> without recompiling everything
<Kamion> infinity: could you dep-wait libxtst on x11proto-xext-dev (>= 6.8.99.7-2), please?
<ogra> highvoltage, ping
<Mithrandir> pitti: are you going to resync zlib in breezy with debian soonish? I uploaded a sash which needs a newer zlib1g (which is fixed in ubuntu, but I can't depend on the ubuntu versions in any sane way)
<sivang> hi pitti ! back in home ?
<pitti> Mithrandir: sure, I can do that
<pitti> Mithrandir: but probably not before Monday
<Mithrandir> pitti: sure, no hurry.
<pitti> sivang: no, still at debconf5
<sivang> pitti: how is it going? nice progress?
<sivang> hey davyd 
<davyd> hey
<pitti> sivang: pretty relaxed, and nice to meet so many of fellow DDs here :-)
<davyd> hmm, is it still tseng's timezone?
<shackan> hi pitti, would you mind if I pm you ?
* davyd attempts to bootstrap mono on amd64 on hoary
<davyd> hmm, I might have to go to breezy anyway, just so that I get gcc-4.0
<fabbione> Kamion: TypeError: unpack non-sequence
<fabbione> does it mean anything to you?
<Kamion> fabbione: find a python expert :)
<fabbione> Kamion: i did :) thanks
<ogra> hey swimmer ace ...
<fabbione> hey mdz
<rob^> has an actual date been set for Breezy's release yet?
<ogra> rob^, sure look at the release plan on the wiki....
<rob^> ok
<rob^> just wondering if software freedom day is before or after it :)
<ogra> rob^, the dates are quite fixed in oct. and apr. for all our releases
<rob^> ah ok
<rob^> np
<Kamion> http://udu.wiki.ubuntu.com/BreezyReleaseSchedule
<rob^> looking at it now
<mdz> fabbione: morning
<fabbione> mdz: how is going? having fun?
<ogra> fabbione, he has, obviously : http://oskuro.net/blog/travel/pop-the-trunk-2005-07-14-09-23 
<ogra> *g*
<mdz> fabbione: yes, very much so
<fabbione> ehhehe
<ogra> mdz, do you think it makes sense to have a fontserver on the LTSP machine ? does that raise or reduce the bandwith ?
<fabbione> ogra: probably reduce
* \sh is going to upload wine  now
<fabbione> because you will get to ask only for the fonts you need without accessing the FS as nfs
<ogra> \sh, yay
<fabbione> so need to scan the FS to find the fonts
<ogra> fabbione, thats what i thought, but i found different reports about bandwith usage... there seems to be a 50/50 opinion out there...
<ogra> but since we have crazy people out there that want hundrets of fonts installed, a fontserver probably makes sense
<fabbione> test it is probably the best
<ogra> yes... i thought i could come around that :)
<ogra> i imagine you 'll probably have a DOS if all pupils boot theirs systems at the same time
<Treenaks> ogra: not really.. font-servers are not really complex
<\sh> ogra: provide some common fonts on the clients and put other fonts which are normally not used in a common sense on the fontsrv
<ogra> Treenaks, but havin 20~50 machines on the net loading the fonts at the same time ? 
<Treenaks> ogra: no prob
<ogra> \sh, yes thats the idea
<Treenaks> ogra: they were designed to do that :)
<mdz> ogra: LTSP includes font server capability, but I haven't incorporated that yet
<Treenaks> ogra: though I only tested with ~10 clients
<mdz> ogra: I expect that it won't make much of a difference for GNOME
<mdz> or KDE
<ogra> mdz, and a mix ? ;)
<\sh> no problem :)
<ogra> i'll do some testing after the seeds are ready and i can take a breath...
<Amaranth> so...
<Amaranth> is edubuntu using GNOME?
<Treenaks> Amaranth: of course :P
<Amaranth> good :P
<ogra> Amaranth, yes, for the first release it does... i think we'll have kde as an option available in the breezy+1 release....we mix up the apps anyway
<Treenaks> Amaranth: otherwise it'd be kedubuntu or edkubuntu and those just don't sound right ;)
<Amaranth> I might look into doing group menu changes then.
<ogra> yay
<Amaranth> it'll be a hack
<Amaranth> Basically we make the users not able to touch their own ~/.config/menus/, ~/.local/share/applications/, and ~/.local/share/desktop-directories/
<ogra> Amaranth, i'll get the source to an awesome user management tool on the weekend, lets see if we can incorporate your stuff there
<Amaranth> groups would have to be defined in a tool though
<Amaranth> ok
<Treenaks> ogra: apt-get source sabayon ? :P
<ogra> Treenaks, and the KDE aps ?
<Amaranth> sabayon needs everything to be in gconf
<Treenaks> ogra: if you ignore them, they'll go away ;)
<Amaranth> this is why people want fd.o to define a common config system for the _entire_ system
<Treenaks> Amaranth: but sabayon defined groups too, right?
<\sh> wine_0.0.20050628 uploaded
<ogra> Treenaks, sabayon only gives me access to the gconf settings... no vnc takeover of the pupils desktop, no further management
<\sh> winehq packages are on their way ,-)
<Treenaks> ogra: true.. but it might help as a basic "set up" tool?
<ogra> Treenaks, the tool i'll get is specially tailored for classrom maintenance aleady... its only drawback is TCL :)
<Amaranth> *shudder*
<ogra> heh
<Treenaks> ogra: Rewrite in python! Rewrite! ;)
<ogra> Treenaks, i doubt i'll have the time for that in the first release, but thats the longterm plan ;)
<Treenaks> ogra: thought so.. cool
<Amaranth> I don't know TCL and I would want to port thousands of lines of Python to TCL just for menu editing. :)
<Amaranth> Smeg itself isn't very large but that's because it leans heavily on PyXDG, which is fscking huge.
<ogra> (the longterm plan actually is to write our own tool that aggregates the best of all the others indeed)
<Treenaks> Amaranth: that's with most python programs
<Treenaks> Amaranth: the programs are tiny, but the libs are HUGE
<ogra> Amaranth, its far more then menu editing
<Amaranth> hehe
<Amaranth> PyXDG is, sure
<Amaranth> but 80% of the code (or more) is menu editting
<ogra> Amaranth, not at all
<ogra> Amaranth, see a outline here: http://edubuntu.org/TeachersPet
<Amaranth> you can say all of it is though, since the other things it supports are used by the menu system
<\sh> Subject: wine_0.0.20050628-1_source.changes ACCEPTED
<\sh> yay
<Amaranth> ogra: I was talking about pyxdg
<ogra> Amaranth, ah... ok
<ogra> \sh, did you make the package building on i386 only ? i heard they work on a amd64 and ppc solution too... is that in already ?
<Amaranth> ha
<Amaranth> wine can only work on amd64 and ppc with emulation
<\sh> ogra: i should build for all...actually, if this is working right now, I can do some other changes on the packages...
<ogra> \sh, lets see... if it builds for amd64 i'll test it ;)
<\sh> Amaranth: if winxp64 is working we will have a wine64 ,-)
<Amaranth> \sh: only for programs compiled for just winxp64
<\sh> well...I have to go and find a place to hide
<siretart> \sh: grats for wine :)
<Amaranth> or did they fake it like apple does?
<Amaranth> can't you make it built as 32-bit on amd64?
<siretart> \sh: do you know if wine will be able to run win32 apps on amd64? 
<\sh> Amaranth: i think MS is using some compat layer 
<\sh> siretart: poke ogra ;) he can test if it's building
<siretart> :)
<\sh> Amaranth:hmm...that's an idea
<\sh> <mindnote> I have to earn more money, I need reference computers, and I have to change the 24h mode of a day to 96h</mindnote>
<ogra> Amaranth, sure you can
<\sh> ogra: http://www.netzwelt.de/news/71893_4-kolumne-warum-niemand-auf-linux.html
<\sh> smoking
<Amaranth> stupid body, needing sleep
<Amaranth> why can't we just stay awake non-stop? :)
<ogra> Amaranth, get rid of it then... :)
<Amaranth> not needing it right now, just got it
<Amaranth> after 30 hours of not getting it...
* Kamion fixes breezy debootstrapping, I think
<ogra> yay
<Kamion> that should get live CDs and such going again
<ogra> yay++
<Amaranth> colony 3?
<Kamion> at least once the desktop is installable. er.
<Kamion> Amaranth: patience, padawan
<Amaranth> it's not installable right now?
<ogra> does it fix pbuilder too ? you cant bootstrap breezy directly currently
<Kamion> http://people.ubuntu.com/~cjwatson/testing/ <- no
<Kamion> ogra: pbuilder just uses debootstrap
<Kamion> sme problem
<Kamion> +a
<ogra> yep
<Amaranth> oh, capplets
<Amaranth> wtf, gcc4 can't be installed?
<Amaranth> oh, amd64
<Kamion> please don't go through being surprised at all of the entries on channel - you're welcome to analyse what's wrong with them and suggest fixes though :)
<Amaranth> ok, i know the solution: drop amd64 support ;)
<Kamion> sigh, maybe that URL should be *less* public rather than more :P
<Amaranth> seeing how i don't have an amd64 machine i don't think i can be of much help here
<Kamion> the amd64 buildds are currently down (or were, last I checked), so I would suggest not worrying too much about amd64 problems at the moment - many of them are probably due to that
<fabbione> Kamion mdz Keybuk: you will love this: http://people.ubuntu.com/~fabbione/Screenshot-1.png
<fabbione> it
<fabbione> it's not exactly bug free :) but we can get there ;)
<Amaranth> wow, i actually found someone who uses GNOME's default theme :)
<fabbione> Amaranth: you are talking about me ... yes. i never spend time customizing my desktop
<ogra> Amaranth, isnt clearlooks gnomes default since a while ? 
<Amaranth> but you should have Human :)
<Amaranth> ogra: no
<Amaranth> ogra: they've been talking about changed the default since 2.8 and clearlooks is one of the suggestions, nothing has happened
<ogra> Amaranth, i think they switched with 2.10....
<Amaranth> err, changing
<sivang> fabbione: is this the clustering gui control written in python?
<fabbione> Amaranth: i just can't be bothered to customize when every once in a while i scratch all my systems to test install-cd or net install aand so on
<fabbione> sivang: yeps... i didn't write it.. be aware
<fabbione> sivang: i am just trying to make it working :)
<sivang> fabbione: so cool, wh did it?
<fabbione> redhat
<Keybuk> so Xorg is broken again today?
<Keybuk> (WW) Warning, couldn't open module ati
<fabbione> Keybuk: did you see the screenshot? ;)
<Keybuk> (WW) Warning, couldn't open module keyboard
<Kamion> Keybuk: topic
<Kamion> it's stuck in various buildd fun
<Keybuk> gah
<Kamion> 11:52 < Kamion> infinity: could you dep-wait libxtst on x11proto-xext-dev (>= 6.8.99.7-2), please?
<Kamion> I think that's the current blocker
<Kamion> hm, I wonder if I can set dep-waits ...
* Keybuk tries to remember how to drive the console ;)
<fabbione> Kamion: if you can set Dep-Wait, you can just kick back
<fabbione> Kamion: i can probably help you with w-b
<fabbione> but i only know the direct interface.. not the mail one
<fabbione> Kamion: in any case xorg -40 will be REJECTED
<fabbione> even if you build it
<fabbione> (see the scroll back from this morning)
<Keybuk> I'm guessing this won't be fixed any time soon, then?
<Keybuk> what's the easy way to undo the damage?
* davyd continues to build mono packages
<davyd> man, I feel like a Gentoo developer
<fabbione> Keybuk: there is none afaik
<Kamion> I just set "Database for breezy doesn't exist"
<Keybuk> can I download and install the hoary X packages?
<davyd> or user
<fabbione> Keybuk: probably the keyboard thing is something i heard of s/keyboar/kbd/
<fabbione> Keybuk: but i am not sure about the ATI. that might be due to the missing Depends: on the proper driver
<ogra> Keybuk, change keyboard to kbd in xorg.conf ...
<Kamion> Keybuk: you can install the xserver-xorg-{driver,input}-* packages by hand
<Amaranth> wow, someone turned gecko into a server tool
<ogra> dunno if it solves the ati prob though
<Kamion> fabbione: right, but need to get libxtst sorted first
<fabbione> Kamion: yes.. you need the external libxtst to be able to build -40, but -40 will be reject because it still has it :)
<fabbione> Kamion: do you have access to w-b ?
<fabbione> Kamion: if so a command like wanna-build -d breezy --give-back libxtst_$version should do
<fabbione> you will have to do it as buildd user i guess..
<fabbione> dunno the exact details of the config over there
<Keybuk> (EE) Failed to load module "kbd" (module does not exist, 0)
<Keybuk> (EE) Failed to load module "mouse" (module does not exist, 0)
<ogra> meh
<Keybuk> ati fixed though
<Mithrandir> Keybuk: apt-get install xserver-xorg-input-{kbd,mouse}
<Amaranth> xserver-xorg-input-mouse, xserver-xorg-input-kbd
<Keybuk> ah, got it, missed those
<Keybuk> (I was looking for -driver-input-...)
<Kamion> libxtst: not taken by you, but by buildd+rothera. Skipping.
<Kamion> I don't have access to the buildds so that might not work
<Kamion> fabbione: ^--
<fabbione> Kamion: hold on a sec..
<Keybuk> thanks guys, that works :)
<Kamion> I don't know if I can use -U safely
<fabbione> Kamion: wanna-build --user=buildd+rothera --override -d breezy --give-back libxtst_$version 
<mdeboer> hm.. the rt-preempt patch and the ubuntu 2.6.12 patches don't play nice...
<Kamion> fabbione: is that safe to do as the katie user on jackass?
<fabbione> Kamion: in the worst case you will get w-b to error on you
<fabbione> i guess so...
<mdeboer> do you think any of the 2.6.12 ubuntu patches are needed for a properly working live cd?
<fabbione> i have no idea how/if it is customized
<fabbione> here i get an error if the operation is invalif
<fabbione> invalid
<fabbione> Kamion: you probably want to check under what user the wanna-build db are stored
<fabbione> and use that user as --user=
<Keybuk> pmount/udev/gnome-volume-manager is broke as well
<Kamion> fabbione: ok, given-back on i386/powerpc/ia64, I'll blame you if it goes wrong ;-)
<fabbione> Kamion: if it is a standard install ls -alsd /var/debbuild will tell you
<pef> what's about the libaa transition ? I can't find the wiki page
<fabbione> Kamion: ok :)
<fabbione> Kamion: or we can blame gtk because there is no GUI to wb :P
<Kamion> didn't need --override
<Kamion> I think daniels is in the middle of his sleep cycle - I might fix xorg too
<doko> lamont-away, infinity: please requeue openoffice.org2 on the i386 and powerpc buildd
<sivang> fabbione, Kamion : what is wanna-build used for?
<Kamion> sivang: buildd coordination
<ogra> sivang, http://www.nl.debian.org/devel/buildd/
<Kamion> daniels: xorg -41 uploaded, dropping libxtst* from debian/control
<sivang> ogra: so much to read, so little time :-)
<ogra> sivang, not really 
<ogra> wanna-build
<ogra>     a tool that helps coordinate package (re)building through a database that keeps a list of packages and their status. There is one central database per architecture that stores package states, versions, and some other information.
<sivang> ogra: k, thx
<ogra> indeed, if you want to step into the details....
<Kamion> I: Base system installed successfully.
<Kamion> hooray
<hephey> shouldn't the fixed X be on uk.archive.ubuntu.com about now?
<Kamion> hephey: no, it'll take a while longer
<Kamion> hephey: (and do you really mean uk as in Ukraine?)
<Kamion> hephey: I only just uploaded -41, which should (a) build and (b) not be rejected by the archive maintenance software
<hephey> Kamion: no uk as in United Kingdom
<Kamion> hephey: then you want gb.archive.ubuntu.com
<hephey> Kamion: Uh, ok, *bonk*
<Kamion> uk actually isn't the two-letter code for any country due to the United Kingdom / Ukraine confusion - my mistake above, Ukraine is ua.archive.ubuntu.com
<Kamion> that said they're the same machines at the moment anyway
<Amaranth> yeah, it seems like all of them point to archive.ubuntu.com
<Amaranth> except for us and ca
<hephey> Kamion: Ok, I'll wait patiently.
<jbailey> Kamion: Hey.  Do you actually have access to a 3c509 card?
<Kamion> jbailey: don't think so
<maswan> Amaranth: and se
* Amaranth tries to think of what se is
<Kamion> Amaranth: and fr, and de
<Kamion> at least
<jbailey> Amaranth: Sweden
<Amaranth> ah, that's right
<Mithrandir> jbailey: I might have access to one.  Possibly, maybe.
* Amaranth wonders if it's safe to remove 'PLEASE DON'T USE BREEZY YET -- REALLY' from #ubuntu's topic
<ogra> Amaranth, WHAT ?
<Amaranth> ogra: universe and X are the only problems
<Amaranth> X is almost done
<ogra> Amaranth, i dont think X is done yet...
<sivang> Amaranth: didn't you see Keybuk little fight a 30 minutes ago?
<Amaranth> nope
<Amaranth> wasn't here
<ogra> Kamion made it work for now, so we can have a colony, but i'm pretty sure daniels wont stop yet
<sivang> ogra: the only thing in the way of X other then xlib-mesa transition ?
<ogra> so the first upgrade after installing the colony could break everything again
<jbailey> Mithrandir: Cool.  Colin was asking yesterday about detecting them with hotplug.
<ogra> Amaranth, its safe to remove it if the preview is out...
<Amaranth> ...
<Amaranth> You really think breezy is going to ship on time if no one uses it until the preview?
<ogra> Amaranth, nope, but i'd keep the warning where it is
<Amaranth> btw, bugday was yesterday :P
* Amaranth looks at the topic
<ogra> i know, i ran it....
<ogra> was very quiet but some got sorted
* ..[topic/#ubuntu-devel:ogra] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://www.ubuntulinux.org/wiki/DeveloperResources | If you have unexpectedly lost editbugs privileges, talk to mdz/ogra/kiko | Colony CD 2 released | yes, X is broken.  a fix has already been uploaded.
<ogra> :P
<jbailey> Amaranth: Once feature freeze hits, it's a little easier to recommend that people try it out - things shouldn't be shifting quite so madly underneath them.
<jbailey> Mithrandir: Safe to assume you don't really have access to it until next week?
<Amaranth> btw, does anyone here dual boot?
<Amaranth> linux and windows, i mean :)
<\sh> Amaranth: I did
<Amaranth> i'm trying to figure out if i've found a bug or not
<maswan> jbailey: one of these? Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone]  (rev 30)
<jbailey> maswan: Nope, but thanks.  The 905s are PCI cards, the 509 vortex cards are ISA.
<maswan> ah, right. mixed up the numbers, as usual
<jbailey> Yeah, I used to do it all the time when I was selling hardware.
* maswan privately hates 3com for that naming
* Amaranth dives back into the forums
<jbailey> Luckily they were *both* crazy popular cards, so I could just take it back and hand the other one off the shelf. =)
<maswan> :)
* jbailey pokes seb128 
<jbailey> seb128: Aren't you supposed to be off celebrating?
<seb128> hey jbailey 
<seb128> jbailey: kind of :p
<jbailey> The fte national de Qubec is a huge street party.  I assumed that yours would be the same. =)
<seb128> not really
<seb128> usually we have party on the evening with some nice fireworks
<lu|sleep> jbailey: they are all inside watching the Tour :)
<seb128> and it's too hot today to hang outside :p
<\sh> lu|sleep: oh u mean the "bike jump break legs tour"?
<jbailey> seb128: Ah.  From what I remember from Qubec City two years ago, the drinking started about 4pm and by 7pm the streets were wall to wall people.
<jbailey> And it more or less stayed that way sun up.
<jbailey> +until
<davyd> any idea what provides dh_netdeps?
<ogra> cli-common
<davyd> my version of cli-common doesn't
<ogra> davyd, have you seen the cli policy on the wiki ?
<davyd> ogra: no I haven't
<ogra> its called dh_clideps now i think.... its a while ago since i compiled mono
<davyd> ogra: ok, I have that
* Kamion tries to understand the gnome-panel build failure
<davyd> next question, is there documentation to port from one to the other?
<ogra> davyd, https://wiki.ubuntu.com/CLIPolicy
<ogra> davyd, the breezy packages work over all arches... (they should at least)
<davyd> ogra: I've backported the mono from breezy
<davyd> the problem is dbus
<ogra> davyd, i know... 
<ogra> ah, dbus
<ogra> yes, there you need to depend on the hoary -dev package.... dbus-sharp-dev or something like that
<ogra> it was separated in hoary
<davyd> ok, I appear to have a dbus package
<Kamion> xorg -41 accepted for powerpc
<ogra> davyd, i'm not sure how good the new mono works with the old dbus.... even if it compiles it will lack functionallity i guess
<ogra> but try it :)
<davyd> we'll see
<davyd> I'm just installing the in-tree dependancies for tomboy at the moment
<davyd> wait till I try to get gcc-4.0
<KaiL> who has stolen the manpages from X packages?
<davyd> hmm, I can't compile tomboy...
<davyd> and I don't understand these errors
<Mithrandir> jbailey: correct, no access until next week, and I'd need to rig up a whole system to get one working
<jbailey> Mithrandir: If you could, that would be lovely.  I'm at OLS next week (so almost completely offline) so there's no rush right when you get back.
<jbailey> But it looks like there *might* be some basic modalias support for isapnp.  If I can use it somehow, that would be sweet.
<Mithrandir> jbailey: ok, I'll see what I can do then
* davyd discovers he needs a secret version of gtk-sharp
<daniels> Kamion: *cough*
<Kamion> daniels: re xorg?
<davyd> I home that building gcc-4.0 won't be this much pain
* davyd wonders if someone has already done a backport of that
<daniels> Kamion: yeah
<mdeboer> can anyone explain how the "abi" stuff works in linux-source-2.6.12-2.6.12?
<mdeboer> typically, after pushed the revision (dch -i) in the changelog, and i run dpkg-buildpackage, i get an Missing /mnt/hda6/src/linux-source-2.6.12-2.6.12/debian/abi/2.6.12-3.3/abiname file.
<mdeboer> "Check for the previous kernel's abi file; now a requirement for builds!"
<mdeboer> where do i get the 2.6.12-3.3 abi file?
<Kamion> daniels: also, does the gnome-panel 2.11.5-0ubuntu1 build failure mean anything to you?
<Kamion> /tmp/gnome-panel-2.11.5/./libpanel-applet/panel-applet.c:395: undefined reference to `XQueryTree'
<Kamion> etc.
<mdke> Seveas, ping a ling
<daniels> Kamion: missing -lX11
<Seveas> mdke, pong a long
<mdke> Seveas, hi, i noticed a bit of to-and-fro ing on the NUN guidelines, so i made a /talk page so that people can put their opinions forward without amending that page. Did you see it?
<Seveas> seen it now :)
<Seveas> good idea
<Kamion> hmm, it's just using pkg-config, what's wrong ...
<Kamion> shouldn't something like gdk-x11-2.0.pc or gtk+-x11-2.0.pc be doing Requires: x11?
<Mithrandir> possibly, but x11.pc is new&shiny.
<surak> Is there a wiki describing what's broken with X and how we can help?
<Kamion> surak: moving too fast for that
<Kamion> xorg -41 accepted for i386/ia64 now
<surak> The live's daily build stopped last week. Is this related?
<Kamion> surak: yes
<Kamion> surak: well, that's one reason. Another is that debootstrap breezy hasn't worked for about a week. I fixed that today.
<Kamion> surak: the live filesystem builds are pretty brittle, it's easy for the distro to break them
<lamont-away> Kamion: it's not so much that the process is brittle... it's that it depends  on the distro being installable... :)
<surak> :-)
<Kamion> lamont: well, right :)
<surak> it looks like our own build process :-)
<Darryl> Will it be possible to get Ruby updated in Hoary before the release of Breezy?
<Kamion> lamont: (that's a brittle requirement, that's all - unavoidable, but ...)
<lamont> Kamion: yeah
<tseng> davyd: it is now
<lamont> Darryl: if it meets criteria for hoary-security, hoary-updates, or hoary-backports, it could conceivably be uploaded to the appropriate one of those
<lamont> Darryl: but hoary itself is _closed_.
<lamont> Darryl: and, btw, that's a #ubuntu question
<Darryl> Alright, thanks
<surak> Kamion: help me understand the fix process. When you say xorg-41 was accepted for platform X, what happens? You source is merged with the build system and thus package is generated?
<Kamion> given the version in hoary is apparently a prerelease, I wouldn't be opposed to having updated ruby in hoary-updates, if somebody did the work
<Kamion> surak: buildd grabs source package, does dpkg-buildpackage, uploads result
<Darryl> Kamion, yeah, that's the problem
<Kamion> don't confuse matters by thinking of "merged"
<surak> ok
<Kamion> surak: "accepted" has the specific technical meaning that it's in the accepted queue on the machine "jackass" and will be installed into the archive proper within half an hour
<Kamion> i.e. the buildd has uploaded it and it passed the archive maintenance system's automatic checks
<surak> ok, thanks
<surak> What happens then? What are those checks?
<Kamion> surak: too many to describe
<Kamion> sanity checks on the structure of the package
<Kamion> and on the archive database
<Kamion> every half an hour a process runs that installs packages from queue/accepted/ into the pool, which you can see on archive.ubuntu.com
<ivoks> any1 else has problems with evolution? :/
<surak> What kind of problem, ivoks?
<ivoks> crashes on clicking forward
<surak> is this happening with an specific message or with any message?
<ivoks> any
<surak> is your default to compose html messages?
<ivoks> noo
<ivoks> symbol lookup error: /usr/lib/evolution/2.4/components/libevolution-mail.so: undefined symbol: CAMEL_IS_MULTIPART
<bob2> ouch
<bob2> also, I can't eject an audio cd anymore
<surak> ivoks: that's news for me. evolution 2.4 is only in breezy, isn't it? or is there a hoary one?
<ivoks> surak: breezy, of course
<surak> Kamion: when I find something strange in breezy, what's the best way to report it? Bugzilla/malone, here?
<ivoks> bugzilla
<ogra> or malone
<ogra> depends on the component you report the bug for
<ogra> malone = multi/universe
<ivoks> surak: http://bugzilla.gnome.org/show_bug.cgi?id=310330
<surak> I got into #ubuntu to offer help on X, someone just told me "don't post bugs for breezy in bugzilla"
<ivoks> ok, this is upstream
<ogra> surak, thats wrong
<tseng> dont post universe bugs in bugzilla
<ogra> surak, main and restricted bugs go to bugzilla
<ogra> even for breezy
<ivoks> *verse goes to malone
<surak> I know.
<surak> He told me not to post any bugs for breezy at all - (trying to remember his/her nickname) - something like "it's breezy, the devs know about it already"
<surak> I though strange.
<surak> Another question: about string translations. I have three volunteers to help translate gnome 2.12 to pt-br. Should we do this on ubuntu or directly with gnome guys?
<ivoks> surak: that was about that specific X problem
<ivoks> poor daniels got stuffed with mail :)
<surak> Probably - but someone who chooses to maintain X probably likes that :-)
<surak> Several pt-br strings got lost from gnome 2.10 to 2.11
<Amaranth> best to do it upstream i'd think
<Amaranth> or in rosetta if it's in there
<surak> There are some guys doing it for fedora already - would be duplicated effort. How do you publish this to gnome project? Say, if we translate it in rosetta faster than gnome cvs...
<mdke> you can download the .pot file from rosetta and send it upstream
<mdke> to the gnome maintainer for pt_br
<surak> I'll put the guys working on it - there are several lost strings.
<Kamion> surak: anything but here
<Kamion> IRC's pretty awful as problem reporting media go ...
<surak> Kamion: the -41 xlibs returns error code 1.
<surak> when installing
<siretart> surak: please report bugs in xorg via bugzilla.ubuntu.com
<siretart> surak: there you can easily add more details about what exactly happened and what you suspect what went wrong
<surak> yes. Just to let kamion know there's something wrong . The update just went to archive
<siretart> surak: Im sure he already knows
<surak> :-)
<Amaranth> grr
<Amaranth> it's clobberin time!
<Amaranth> fscking spammers
<Amaranth> ok, who is actually in #ubuntu?
<Kamion> surak: 16:25 < Kamion> surak: anything but here
* Amaranth blames windows for xchat failing him
<Amaranth> one more round then i'm rebooting
<Amaranth> ping me if someone happens
<tritium> Amaranth, bob2 and I
<\sh> grmpf..updating X ,-)
<\sh> brb
<TerminX> hmm.. xlibs_6.8.2-41 is broken?
<surak> TerminX: it looks so
<surak> https://bugzilla.ubuntu.com/show_bug.cgi?id=12686
<Kamion> I could try NEWing xkeyboard-config and see if that makes a difference ...
<Kamion> daniels: ?
<Kamion> daniels: you said something worrying about xkeyboard-config so I was holding off on NEWing it until you showed up
<\sh> ok..once in a while a dpkg-configure xserver-xorg is ok :) but now, alt+strg+FN is not working anymore ;)
<lamont> Kamion: sorry for all the noise hppa is causing in *-meta changelogs...
<Kamion> ah well
<lamont> it means I'm getting closer... :-)
<TerminX> hmm.. what's with the dependencies on xserver-xorg?  what's the point of having all the drivers in separate packages if they're all just dependencies now anyway
<TerminX> jp: did you get X working?
<tsume> I'm still curious why the ubuntu kernel takes WAY longer than fedora to load 
<jp> TerminX no dude, Im runnin hoary now :/ 
<tsume> why Can't ubuntu have a small kernel like fedora?
<TerminX> jp: oh, I had an answer for you like 2 minutes after you /quit yesterday
<TerminX> all of the drivers are in separate packages now man, which as of the latest xserver-xorg package are all dependencies.. so you could've just apt-get installed three packages and had it working, or waited until the next version was uploaded, heh
<jp> heheh thanks TerminX :)
<TerminX> * jp (~jp@216-155-91-100.bk2-dsl.surnet.cl) has quit ("Lost terminal")
<TerminX> * robitaille (~daniel@d154-5-117-228.bchsia.telus.net) has joined #ubuntu-devel
<TerminX> TerminX: jp: you need to install some new packages
<TerminX> TerminX: like xserver-xorg-input-mouse, xserver-xorg-input-kbd, and xserver-xorg-driver-sis
<TerminX> bad timing
<jp> I'll try it
<TerminX> didn't notice you left before I said something
<jp> ohh
<jp> I saw some like these packages but not with my drivers :D
<jp> hehehe thanks TerminX ;)
<TerminX> yep
<jp> I'll try it on another pc now!
<jp> :D
<carstenh> jbailey: ping
<TerminX> jp: xlibs is currently broken though
<TerminX> ;\
<jp> oops :$
<jp> well... I'll wait a bit TerminX :P
<Kamion> TerminX: it's not possible to split them out into separate packages without having something to arrange for those packages to be pulled in on upgrades.
<Kamion> TerminX: note that, if you want, it's possible to install just xserver-xorg-core, xserver-xorg-driver-$whatever, and xserver-xorg-input-$whatever.
<TerminX> Kamion: I understand that, but shouldn't it be some other metapackage?
<TerminX> and how can I not have xserver-xorg installed when it's the package that has the "Xorg" binary in it
<Kamion> no, it should not be some other metapackage
<Kamion> the Xorg binary should be moved to xserver-xorg-core, I think
<Kamion> daniels: ^--
<TerminX> there are a bunch of X modules in xserver-xorg as well
<Kamion> yes, they should be moved to -core
<Kamion> please file a bug
<TerminX> wouldn't that in effect make xserver-xorg the theoretical metapackage? ;p
<Kamion> yes, that's the intent
<Kamion> furthermore another point of having the drivers in separate packages is so that ultimately they can be uploaded separately rather than in one giant blob
<TerminX> that makes sense; I just don't want to have to have it all installed here if a) I don't need it and b) it can be avoided
<Kamion> it will all continue to be installed as part of ubuntu-desktop
<TerminX> I don't have that package installed, heh ;p
<ogra> TerminX, you wont be able to upgrade cleanly without it... at least thats its main usecase
<Kamion> ogra: please don't tell people that
<TerminX> ogra: that sounds inaccurate
<ogra> Kamion, why, if its true... how else do you change the changed dependencys and requirements ?
<ogra> (between releases)
<TerminX> apt-get dist-upgrade?
<JanC> unfortunately ubuntu-desktop includes lots of things most people don't ever need  :-(
<Kamion> ogra: if we add extra packages to the standard desktop, yes, ubuntu-desktop is needed to pull them in
<JanC> that's why they uninstall it...
<Kamion> ogra: but it is *required* that upgrades work (to a reasonable extent) without it!
<ogra> Kamion, so its important to have it there on upgrades
<ogra> Kamion, sure but what do you get then ? its not breezy, but a upgraded hoary...
<Kamion> ogra: only if you want to ensure that any new desktop features are present. Your system *must* continue to work as well as it did before even if you don't have it installed; you might just not get new features.
<Kamion> ogra: yes it is breezy. breezy is still breezy even if you don't have the desktop
<TerminX> it's not breezy, but an upgraded hoary?  that's illogical to the point of not even making sense
<Kamion> agreed
<highvoltage> hi guys
<ogra> Kamion, sure, but not working as intended... i had quite a lot supports between warty/hoary where lang packs were missing or breakage could easily be solved through -desktop installation
<TerminX> damn, if I was to install ubuntu-desktop I would have to pull down 200 megs of packages
<Kamion> ogra: language packs were a ghastly hack, package-wise ...
<Kamion> ogra: and I think we should acknowledge that as an upgrade bug rather than just punting to the metapackages
<Kamion> because people, in practice, do *not* reliably keep them installed
<ogra> sadly, yes
<Kamion> also, installing ubuntu-desktop doesn't give you language packs
<ogra> and btw, do you know how many hoary systems run with broken warty fam out there
<ogra> thus the "and" in the sentencs
<ogra> sentence
<Kamion> we have to support upgrades that do not involve ubuntu-desktop
<Kamion> if they break, it's our bug, not the user's
<Kamion> punting to the user is bad form
<ogra> sure thats an alternative, but currently my wordin for upgraders is install ubuntu-desktop to be safe... since it is the safe option that generates less support...
<ogra> even if it should be upgradeable all over...
<Kamion> getting into the habit of saying "you have to install all this stuff you don't want in order to make upgrades work" will generate bad press for us in the long run
<TerminX> ogra: it's the option that downloads 200 megs of stuff someone might not want or need
<Kamion> frankly, I'd rather we had to deal with the support, because then we would have more motivation to fix the problems properly
<JanC> ogra, the main reason (for me) to uninstall ubuntu-desktop was the fonts it "includes": I don't want 20 arabic fonts that I can't read at the top of my fonts list...
<JanC> and I guess it's similar simple things for other people...
<ogra> TerminX, it depends... i guess you dont use gnome and dont need the additional feauters... but explain it to my (your, somebodys) mother for example...
<Kamion> in the long run I'd far prefer for the metapackages to go away and for apt to have more intelligence about task installation
<Kamion> but this is a long-standing debate between mdz and me
<TerminX> ogra: uh, I do use GNOME
<ogra> TerminX, did you use warty before ? 
<TerminX> yes
<TerminX> and it was sid before that
<ogra> TerminX, are you running fam or gamin below ? 
<Kamion> Debian doesn't have this desktop metapackage nonsense to nearly the same extent, and upgrades have long been a feature of Debian
<TerminX> gamin
<ogra> TerminX, and where did you find out you have to use gamin now instead of fam ?
<TerminX> how is this relevant in the slightest?
<ogra> TerminX, simply because the vast majority doesnt know about fam or gamin... for the the meta package is important...
<mdke> meta package ++
<TerminX> a whole lot of packages depend on gamin
<Kamion> libgnomevfs2-common Depends: libgamin0
<TerminX> which conflicts with fam
<Kamion> which Depends: gamin
<TerminX> so the problem really sorts itself out
<mdke> i did a warty -> hoary upgrade without the meta package and gamin didn't get pulled in
<mdke> the meta package saved me
<ogra> me too... on a tet system
<ogra> test even
<Kamion> that should have been reported, debugged, and fixed, rather than relying on the metapackage
<bddebian> Hi
<mdke> Kamion, sure. I guess i just like the idea that Ubuntu has a bunch of set base/desktop applications
<Kamion> mdke: yes, that's a feature for many, certainly - but we need to get over this business of failing to support people properly who choose not to use it
<Kamion> anyway, gotta run, night all
<mdke> night
<ogra> ciao Kamion 
<TerminX> later Kamion 
<ogra> TerminX, so, sorry for failing to support you right and taking the mass approach ;)
<jdub> heh, X upgrade... 57 new packages ;-)
<jdub> 57 is my favourite number
<Surak_away> and a complete brokeup here :-)
<jp> wuahah
<jp> that's os much
<\sh> jdub: can we reduce it to 42? *g*
<jdub> :-)
<\sh> anyways kdelibs4-dev is broken :(
<Riddell> \sh: works fine for me
<ogra> Riddell, broken on the buildd
<\sh> riddell: let me update pbuilder again
<\sh> ogra: no..broken locally here in my pbuilder...:(
<ogra> look at the ggz-kde-client buildlog
<\sh> nope..doesn't work
<Riddell> ogra: yes, any ideas?
<Riddell> ogra: ggz-kde-client is broken because of a lack of /usr/lib/libXrender.la
<\sh> i had problems just now with xlibs_*-41_i386.deb
<\sh> it doesn't want to install, cause of postinstall problems
<ogra> Riddell, ah, silly me, i looked at the ppc builglog
<ogra> http://hwdb.ubuntu.com/buildlogs/?show=http://people.ubuntu.com/~lamont/buildLogs/g/ggz-kde-client/0.0.7-2.1ubuntu1/ggz-kde-client_0.0.7-2.1ubuntu1_20050714-1548-powerpc-failed.gz
<Riddell> ogra: yes, that's an X problem 
<Riddell> which has been fixed on the other platforms today
<ogra> yep
<ogra> thats why i said silly :)
<jesper> A quick question: Would it break Hoary to "dpkg -i <breezykernel>" on it? 
<bddebian> Because Hoary != Breezy ?? :-)
<ogra> jesper, it should leave the old kernel in place in any case if you dont take the linux metapackage... 
<jesper> So there isn't anything "incompatible" in it .. I just need the QLogic FC-drivers. 
<jesper> thanks
<ogra> jesper, i dont think its a good idea, but trying it wont break it as long as the old kernel is in place to switch back
<ajf> yay, we should use sulogin on init 1.
<seth_k> the new kernel is still broken for me on k7
<Surak_away> https://launchpad.ubuntu.com/distros/ubuntu/breezy/+lang/pt_BR is weird: The proxy server received an invalid response from an upstream server.
<Surak_away> The proxy server could not handle the request GET/distros/ubuntu/breezy/+lang/pt_BR. Reason: Error reading from remote server
<Surak_away> (I don't use proxies, before someone tell me that)
<Lathiat> yeh it breaks like that, saw that once before
<mxpxpod> is there a quick fix to the xlibs install problem?
<mxpxpod> bug #12686
<lamont> daniels: ping
<mxpxpod> or do I have to wait for a new build?
<\sh> someone or something was removing my /etc/X11/xkb that's why it's failing...
<\sh> (IMHO)
<Surak_away> mxpxpod - I'll install the live from 7/7 again - tomorrow I'll try to break X again :-)
<mxpxpod> Surak_away: huh?
<\sh> and I think I will break my whole system just now...apt-get remove xlibs ,->
<Surak_away> I'm using a installed breezy-live (with a installer from myself) - and did just what \sh is doing :-)
<\sh> ok..i just fscked my system
<Surak_away> it removed so much stuff that I gave up - will re-install it from scratch. Just waiting to finish my /home to another machine.
<\sh> hmm...
<\sh> Depends: gdm but it is not going to be installed
<\sh> and more of it..for ubuntu-desktop
<Surak_away> someone asked about evolution some hours ago... wasn't the upgrade from libcamel1.2-3 to 1.2-6 which caused that problem?
<jesper> 6
<ed1t> wow this channels dead 
<highvoltage> ed1t: developers need rest too
<ed1t> true
<bddebian> ed1t: Don't listen to him, it's always dead. :-)
<highvoltage> Why did the chicken cross the information super-highway? To get to the other site.
<ed1t> lol
<ed1t> i wanna help out with ubuntu projects...
<seth_k> -motu is the place to be, they're the ones that need help
<ed1t> well i said in there...no reply
<jbailey> Kamion: around?
<jp> jbailey hi :) how's going the bug :P
<jp> hopefully it'll be fixed for october :)
<jbailey> jp: This is the evo-exchnage one, yes?
<jp> jbailey yep, pretty horrible :(
<bandini> is -41 the fixed version of X?
<Kamion> jbailey: briefly
<Nafallo> nothing new on amd64 buildds? :-)
<Nafallo> there is no fun running breezy without the daily breakage ;-)
<lamont> Nafallo: nothing new that I know of 
<lamont> Kamion: ping
<Nafallo> lamont: they need elmo present to reboot them or what? :-)
<lamont> at the very least, he's the one with console access.  physical presence may nor may not be required
<weirdcreep> i want sex included in ubuntu brezzy
<zanaga> sadly, that is something that is recommended outside of ones computer life..
<lamont> weirdcreep: it's in universe, iirc
<weirdcreep> lo
<weirdcreep> so how is breezy going anyway
<zanaga> has anyone else noticed that the latest totem(-gstreamer) crashes after a while in full screen, or is it just me?
<zanaga> actually, it doesn't crash. it just exits
<Kamion> lamont: yo
<Lathiat> zanaga: well, i noticed it in mjy custom 1.1.3 package
<zanaga> Lathiat: so it's not just me..
<Lathiat> probably not
<Lathiat> my totem wont work at all now
<Lathiat> i downgraded bac kto the ubuntu package
<zanaga> i'm just going through the upstream bugs to see if there are workarounds to this..
<weirdcreep> why doesnt ubuntu come with icewm?
<zanaga> it's a pain to debug because it really exits (with exit code 1)
<Lathiat> zanaga: so break on exit :)
<Lathiat> or write a oibrary with an exit functionj that assigns 0.08 to a functiojn pointer adn executes it and LD_PRELOAD it as exit()? :)
<Lathiat> and i cant type
<Lathiat> or write a library with 
<Lathiat> an exit function that assigns 0x08 to a function pointer adn then executes it, and LD_PRELOAD it
<Lathiat> is waht i meant to say :)
<Panzerboy> hello guys
<Panzerboy> just a quick question: where would be appropiate to ask questions about the packages from backports?
<carstenh> weirdcreep: some kind of light ubunutu with icewm is planned iirc and it should be also in universe
<weirdcreep> when?
<carstenh> weirdcreep: http://mirror.ovh.net/ftp.ubuntu.com/ubuntu/pool/universe/i/icewm/
<carstenh> weirdcreep: http://udu.wiki.ubuntu.com/LightweightDesktop
<carstenh> weirdcreep: the latter should be finished in august
<weirdcreep> ok danka
<carstenh> weirdcreep: and be included in breezy
<carstenh> weirdcreep: but i'm not really involved in this project, so maybe something i don't has changed...
<carstenh> ... i don't know has changed
<weirdcreep> ok hows head of that project\
<carstenh> this project is a summer of code project and has a mentor and a student who implements all this
<carstenh> the student is Vedran Ljubovic
<weirdcreep> oh ok umm what cool stuff is comeing in breezy
<carstenh> ich don't know who the mentor is
<carstenh> yes, a eays to use firewall frontend is planned too :)
<weirdcreep> carstenh whats ur main languag
<carstenh> german
<weirdcreep> i thought so
<weirdcreep> u used ich
<carstenh> why?
<carstenh> hehe
<carstenh> s/ich/I/ :)
<weirdcreep> danka bitten
<weirdcreep> snail
<weirdcreep> langa
<weirdcreep> hitler ist kaput
<weirdcreep> null
<weirdcreep> eins
<weirdcreep> sex
<carstenh> danke bitte
<weirdcreep> u sure
<weirdcreep> not danka bitten?
<carstenh> snail and langa are not german words
<carstenh> no danka bitten is wrong
<weirdcreep> then were are they from
<carstenh> yes, i am sure
<weirdcreep> well i saw danka and bitten
<weirdcreep> in a langauge program
<carstenh> then your teacher has no clue about german?
<weirdcreep> no it was a computer software
<Lathiat> hmm
<Lathiat> has xfce4 been considered for lightweightdesktop?
<carstenh> then it is "kaputt" (with two ts)
<weirdcreep> oh ok
<carstenh> Lathiat: | The target platform for Ubuntu Lite is a 200 MHz Pentium with 64 megabytes of RAM 
<Lathiat> i run xfce4 on my p133 with 32M of ram happily
<Lathiat> well, ran
<Lathiat> havent used it fo ra little while
<carstenh> oh, i'm surpriced :)
<Lathiat> but i dont suspect its gotten much heavier
<Lathiat> just because its gtk2 based
<Lathiat> it would seem a nicer fit
<Lathiat> its also a very active oroject
<Lathiat> icewm seems to have no had udpates in over 7 months
<carstenh> but you have to talk to the people that are involved with this project
<Lathiat> well
<Lathiat> i dont know who to talk to
<Lathiat> theres no contact information on the wiki page
<carstenh> Vedran Ljubovic vljubovic smartnet ba
<weirdcreep> was that german
<carstenh> no, that was the mail-adress without the @ and the dot
<weirdcreep> lol
<weirdcreep> carstenh: does ur nick mean anything
<Lathiat> .ba exists?
<carstenh> Vedran Ljubovic <- name  mail -> vljubovic smartnet ba
<carstenh> i guess
<carstenh> weirdcreep: /whois carstenh
<weirdcreep> ??
<carstenh> weirdcreep: type this in your irc-client
<bddebian> Sheesh
<Lathiat> I also know theres a local co called "computer angels"
<Lathiat> that recycle computers and put linux on and give to people
<Lathiat> and they use xfce4 with rox
<Lathiat> and they are all 200mhzish machines
<Lathiat> hm
<Lathiat> xorg updates
<Lathiat> do i really want to update
<Lathiat> might wait till daniels is around and had a chance to whinge or something
* Lathiat heads to bed
<tsume> Lathiat: I could do that at the local Salvation Army ;)
<Lathiat> tsume: :)
<tsume> Lathiat: except I've been installing Fedora Core 4 on them
<Lathiat> tsume: theres a few organizations like that in australia
<Lathiat> they run a customized debian install
<tsume> mainly because someone is blind in most distros I've seen because they won't install important things like Internet connection wizard etc 
<Lathiat> http://www.computerangels.org.au
<tsume> and I'm still curious why ubuntu's kenrel takes so fucking long to load at start compared to fedora's
<tsume> fedoras takes like 3-6 dots.. ubuntu's about 30-40
* lamont brb
<weirdcreep> no wait ubuntu is a lot quicker then other distros
<tsume> weirdcreep: actually no
<tsume> weirdcreep: fedora starts up faster
<weirdcreep> yes i have used slack
<tsume> weirdcreep: I don't know whyy
<weirdcreep> and vector
<weirdcreep> and they all take longer
<tsume> weirdcreep: then they are doing something wrong
<tsume> why can't linux distros be friendly like bsds and just take code?
<weirdcreep> slackware takes like years to load
<tsume> theres nothing wrong with taking code from other projects, so it must be ego
<weirdcreep> ???
<Lathiat> ubuntu starts *very* fast
<weirdcreep> yes it does
<Lathiat> on the scale of startups
<tsume> Lathiat: not compared to fedroa
<Lathiat> tsume: bugger of it does
<Lathiat> i was running fc4 on this last week
<hunger> Lathiat: not compared to windows.
<Lathiat> ubuntu definately starts faster
<weirdcreep> i hate fedora
<Lathiat> give your windows install to your mum and after a month, try that again
<tsume> Lathiat: then you know how fast fedora starts much faster than ubuntu
<Lathiat> hunger: also, ubuntu is fairly comparible to my windows startup
<Lathiat> i should time them
<weirdcreep> yes it is
<Lathiat> anyway this if O-T
<Lathiat> im goign to bed
<tsume> Lathiat: I tmied the damn thing, Fedora starts 20 seconds faster
<hunger> Lathiat: Win takes less than 15s for me (real startup, not suspend or so).
<hunger> Lathiat: It does run less stuff, so this number is not really compareable though.
<tsume> Lathiat: get a 4200rpm drive, and time it
<tsume> Lathiat: you will see the difference
<Lathiat> tsume: well, i have a 5400
<tsume> Lathiat: no, get a 4200
<tsume> its what I have on my laptop
<Lathiat> gnome login would suck on a 4200
<Lathiat> i can tell you that now :)
<tsume> ubuntu's kernel takes about 30-40 dots
<Lathiat> 30-40 dots?
<tsume> fedoras takes about 3-6
<weirdcreep> whats a dot
<Lathiat> my kernel starts loading before i can blink
<tsume> Lathiat: to initially load the kernel
<Lathiat> what speed cpu?
<tsume> 1.7 p-m
<tsume> theres something wrong with ubunt
<Lathiat> well on my 2.0 p-m with a 5400 rmpm drive, the kernel starts booting practically instantly
<tsume> Lathiat: get a 4200 drive..
<Lathiat> takes maybe 2-3 seconds tops after grub hands off
<tsume> Lathiat: you'll notice a difference
<Lathiat> tsume: how bout no
<tsume> anyway, fedora is still faster on boot
<tsume> I don't know why.
<tsume> but it is
<weirdcreep> i like lilo
<Lathiat> thats nice
<Lathiat> guys, this is off-topic
<tsume> Lathiat: not really
<tsume> Lathiat: its discussin ubuntu's boot time
<Lathiat> it is, because your all just whinging and blahing, which isnt constructive
<tsume> Lathiat: then help find the problem
<Lathiat> I don't have a problem, so I can't find anything
* Lathiat -> bed
* lamont grumbles at Kamion 
<jbailey> Do we regenerate the live CDs occasioanlly with hoary-updates?
<lamont> no
<lamont> or rather, not at this time
<wasabi_> I suspect xhost and xrandr and friends are in NEW?
<jbailey> lamont: thanks
<hunger> Where did the xkb keymaps go?
<mitsuhiko> uff
<fEnIo> hello
<fEnIo> could someone remind me what is an address with patches against Debian packages?
<lifeless> people.ubuntu.com/~scott IIRC
<fEnIo> yes that's it
<fEnIo> thanks
<fEnIo> ok that's question for @ubuntu, but please maybe someone will be some kind and tell me how to install ubuntu's mplayer on Debian using as more dependencies from sid/unstable as possible? ;)
<mdke> fEnIo, sounds like a question for #debian, but good luck with that
<fEnIo> most Debian users don't know what are the sources from Ubuntu :P
<fEnIo> ok bye
<fEnIo> thanks for help
#ubuntu-devel 2005-07-20
<wasabi__> So, is there some sort of easy way or command to remove a package and everything it depends on?
<wasabi__> snip  a branch of the dependency tree
<Riddell> daniels: most of KDE doesn't compile since libXrender.la was removed
<wasabi__> X itself doesn't install currently. :0
<mwh_> Hi, not perticularly a devel question, but I couldnt seem to get an answer on #ubuntu, i'm looking for a list of the HP-laptops which will be certified for Breezy, anyone know where I can get it, you see I want a new laptop and I want to make sure Ubuntu runs flawlessly on it
<mwh_> ahh foundhttp://www.ubuntulinux.org/support/custom/hplaptops
<daniels> Riddell: word
<daniels> lamont-away: pong
<daniels> Kamion: xkeyboard-config should be OK
<Riddell> daniels: word?
<TerminX> daniels: did you see bug 12690?
<mrd`> Bah, none of those laptops have AMD chips.
<tseng> how would you handle this scenario
<tseng> a binary package has 2 sets of files, set A and set B
<tseng> the next version splits it off into two binaries
<tseng> upgrading causes the usual "this file belongs to some other package" bit
<daniels> TerminX: yeah
<daniels> tseng: Replaces: foo (<< 1.2.3-4)
<TerminX> will you move the files to xserver-xorg-core?
<tseng> daniels: on both new binaries?
<tseng> daniels: or the NEW binary, if you catch how i mean
<daniels> tseng: well, let's say foo contains everything, and you split foo into foo, bar, and baz
<daniels> both bar and baz need Replaces: foo (<< 1.2.3-4)
<tseng> ok
<daniels> assuming they contain files that used to be present in foo
<tseng> indeed
<tseng> thanks
<daniels> Kamion: when you NEW xkeyboard-config, could you please add it to the same seeds as xserver-xorg?
<daniels> heh
<daniels> had xserver--core.install.* files through an accident of sed
<daniels> felt like arch
<lifeless> see, its good for you
<Riddell> daniels: so how do I get KDE stuff compiling again without libXrender.la?
* seth_k wants to hear this too
<tseng> Kamion: ping
<daniels> Riddell: grep -r libXrender.la /usr/lib, recompile anything which still references it
<daniels> if you want to improve the world by getting rid of that project's .la file too, be my guest
<tseng> Kamion: looking for a thumbs-up to sync gmime2.1 from unstable
<katoc> hi, have you modified a ubuntu install cd 
<katoc> ?
<Riddell> daniels: so once lower level libraries are recompiled they will no longer reference libXrender.la and KDE should start compiling again?
<daniels> Riddell: right
<Riddell> daniels: ok, thanks
* mrd` sighs at X not wanting to swap caps lock and ctrl after upgrading.
<pef> good night !
<daniels> mrd`: xkb is interesting right now
<daniels> mrd`: make sure you have xkeyboard-config installed
* mrd` checks.
<mrd`> I don't see an xkeyboard-config package.
<chrissturm> daniels: is keyboard handling broken in x right now? i cant set my keyboard layout
<daniels> 00:32 < daniels> mrd`: xkb is interesting right now
<daniels> 00:32 < daniels> mrd`: make sure you have xkeyboard-config installed
<daniels> mrd`: hmm, mustn't have actually made it through NEW yet
* chrissturm finally gets it
<mrd`> daniels: Is there an ETA on that?
* davyd yawns
<davyd> tseng: I got most of the useful part of mono built
<tseng> congrats
<davyd> but I can't build gtk-sharp-unstable
<tseng> and?
<davyd> well, that kinda blocks the tree to build muine or tomboy
<tseng> yeah well
<tseng> "I can't build" doesnt get you much
<tseng> sorry.
<davyd> yeah
<tseng> could you be more specific?
<davyd> I'm not entirely sure how to read errors from mcs
<davyd> but it is complaining about GLib.Object.LookupGType being inaccessable
<davyd> due to the wrong protection level
<tseng> nice one.
<tseng> i think you can safely blame upstream for that
* davyd nods
<davyd> you seem to have a package in breezy on amd64 for it
<davyd> did you work around it?
<tseng> no
<davyd> the obvious question then, is, have I likely done something wrong?
<tseng> no
<davyd> but yet you have a package, and I don't?
<bddebian> probably :-)
<tseng> i didnt build it on hoary
<ajmitch> morning
<tseng> yay ajmitch 
<davyd> tseng: it's just interesting that it would fail, given that it would appear to be a dependancy that I've already built
<davyd> perhaps I should just go to breezy
<davyd> I didn't see any other major destabilisations on the horizon
<ajmitch> yay?
<tseng> ill not tell you waht you should do, but i cant support backporting
<tseng> esp on archs i dont have access to
<davyd> tseng: sure
<davyd> I was simply trying to gain access to your comprehensive experience on the subject
<davyd> I'm sorry if it's pissing you off
<tseng> i have no such thing :)
<tseng> eh its not you at all, im bitter about mono backports
<davyd> I figured it was easier to start on then a gcc 4.0 backport
<tseng> maybe :)
<davyd> perhaps I should move to breezy, I miss GNOME 2.11 features
<davyd> it's amazing how patches fc4
<davyd> I've been using it at work
<davyd> and lots of random stuff that is only in breezy made it into fc4
<tseng> another source of crabbiness might be the last week spent trying to write an expect script to interface with credit card validation machines
<tseng> with incorrect documentation and request strings butchered by Outlook
* davyd laughs
<davyd> I've been debugging stack eating bonobo applications
<HrdwrBoB> the whole credit card network is garbage
<tseng> word.
<HrdwrBoB> cobbled together eith pieces of string
<tseng> HrdwrBoB: dude, its totally shithouse
<HrdwrBoB> I'm very glad I don't work with it anymore :)
<tseng> "uh, we dont include the STX in the LRC, just the ETX"
<tseng> because doing things logically is for the birds
<davyd> hmm, linux-restricted-modules is missing from breezy still
<tseng> davyd: sure is.
* tseng watches beagle crash and burn over and over
<HrdwrBoB> "you can't connect higher than 9600 baud because our 1980s systems can't take more than that
<bddebian> Heya ajmitch 
<davyd> tseng: so why has linux-restricted-modules blocked?
<davyd> things don't compile against 2.6.12?
<tseng> davyd: because daniels is a lazy bum
<davyd> tseng: I see
<bddebian> doh
<davyd> ooop, late for work
<davyd> later
<jp> who knows a bit about planet planet? I have an issue :/ with how order the parameters of <TMPL_VAR new_date> 
<jp> :o at planet.py :$
<lamont> Kamion: you around?
<dieman> "an OQO-specific build of ubuntu linux  -- while officially unsupported by OQO -- is available and can be pre- loaded on this model 01 if the winning bidder so desires"
<dieman> hahaha
<dieman> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=5219297710&ssPageName=ADME:B:SS:US:1
<dieman> did you guys know about that? :)
<daniels> yeah
<dieman> cool
<bob2> I hope firefox doesn't eat too much entropy deciding when to randomly segfault
<bddebian> heh
<Amaranth> would ubuntu-art be the place to request an icon for Smeg? :)
<bob2> I wish people would say "cisco vpn" or "the pos thing MS calls a 'vpn'" when they propose gui tools
<wasabi> What POS thing MS calls a VPN?
<wasabi> I have to try to defend it.
<dieman> hahah
<calc> bob2: pptp?
<dieman> the cisco 3k isn't all that bad
<dieman> its not great
<dieman> but it works
<wasabi> Windows has L2TP support now.
<wasabi> Has since 2k.
<bob2> calc: yeah
<dieman> plus, theres an open source vpn client, but its not perfect either
<wasabi> THeir VPN client kicks ass.
<wasabi> You plug the host IP in, and that's IT.
<wasabi> it automatically detects the type, L2TP or PPTP, the auth mechs, etc.
<calc> rdp is cool
<calc> i can break w2k3 servers via the internet :)
<wasabi> ssh is cool.
<wasabi> i can break linux servers via the internet.
<calc> but rdp is faster than X forwarding
<wasabi> Faster than VNC too.
<calc> i suppose you can use vnc to try to get it down to rdp levels
<calc> vnc with super compression isn't supposed to be too bad
<wasabi> RDP also supports end to end encryption
<calc> can you use rdp with a linux host?
<calc> instead of eg vnc?
<wasabi> There are no servers that I know of.
<calc> oh :\
<wasabi> You definatly could though.
<wasabi> Could just fix VNC though and stick encryption on top of it.
<wasabi> I doubt it's that bad.
<wasabi> I think RDP supports GSSAPI auth though
<calc> that would be pretty cool then you could use it with winterms
<wasabi> VNC should get SASL support.
<wasabi> That would be bad ass.
<calc> hmm i upgraded my brothers w2k3 server to sp1 and now its taking a while to boot back up :)
<calc> i hope i didn't kill it
<wasabi> It usually takes awhile.
<wasabi> Since windows can't modify in use files, it actually installs a lot of stuff to another dir
<wasabi> and moves it at boot.
<calc> oh yea
<calc> btw i found that tsclient causes major pain if it hangs
<calc> or perhaps its rdesktop that does it
<wasabi> yeah
<wasabi> the whole stealing the cursor thing
<calc> you have to go to console and kill it
<wasabi> it's rdesktop
<calc> because it steals all input in X
<wasabi> yeah
<wasabi> it's lame.
<wasabi> on a slow network it's hell.
<wasabi> you can alt-tab to another window, and have to wait a few seconds to be ablet ot ype in the other window.
<wasabi> until the remote server says you can.
<calc> daniels: we need r300/Xegl in breezy ;)
<daniels> xegl, no.  r300, maybe.
<calc> ok
<wasabi> So what's up with X?
<wasabi> xbase-clients now depends on xhost which isn't in the archive.
<wasabi> Oh. TOpic. Hehe.
<TerminX> I think the topic refers to different breakage
<daniels> it relates to general X breakage
<TerminX> has a new version of xbase-clients been uploaded?
<TerminX> (or all the nonexistent packages it depends on)
<daniels> the latter will get uploaded later today
<TerminX> alrighty
<fabbione> morning
<schweeb> fabbione: mornin, got a question... it may be for you, or it may be for mjg59
<wasabi> daniels, you're in AU right (trying to define today)
<daniels> wasabi: yeah.  'some time in the next eight hours'
<schweeb> fabbione: is support for suspending with SATA disks going to be a goal for release?
<wasabi> heh. i busted up my work comp today doing an X upgrade.
<fabbione> schweeb: there is no code yet for it
<schweeb> I know there's a patch out there... I haven't yet had a chance to try it
<wasabi> And apparently I had forgotten to turn apt cleaning off.
<daniels> fabbione: but gentoo have this really cool patch
<schweeb> may not do evreything you need
<wasabi> Oh hey.
<fabbione> schweeb: the patch out there is broken according to upstream
<wasabi> Do we have a snapshot site for breezy? 
<wasabi> LIke that cool Debian snapshot site.
<daniels> sort of
<schweeb> fabbione: k.  just curious.  kinda sucks using this x41 w/o suspend
<daniels> morgue.ubuntu.com, although that's not terrifically useful if you can't run find across it
<calc> so why doesn't suspend with sata just work?
<TerminX> daniels: should I assume that since you marked my bug PENDINGUPLOAD that you'll be moving the files from xserver-xorg to xserver-xorg-core?
<schweeb> daniels: I'm not that cavalier with kernel patches
<daniels> because you need to kick the controller to consistent states
<daniels> TerminX: yeah
<TerminX> awesome
<calc> ah
<fabbione> calc: because it's not implemented
<schweeb> the scsi stuff doesn't have power management hooks
<calc> kind of like why suspend on my laptop doesn't work ;)
<schweeb> or some such shyte
<calc> it seems to leave my keyboard dead
<wasabi> daniels, it's also not up to day at all
<calc> supposedly suspend/resume with the new r300 driver works
<calc> would be nice if i could get that working on my amd64 laptop
<calc> maybe in 64bit mode my keyboard would work too :\
<wasabi> suspend resume on my ppc is still flakely
<wasabi> better than it was though. before the screen wouldn't even come back on.
<fabbione> daniels:
<fabbione> Setting up xlibs (6.8.2-41) ...
<fabbione> dpkg: error processing xlibs (--configure):
<fabbione>  subprocess post-installation script returned error exit status 1
<wasabi> now it lcoks up doing something to eth1 (wireless)
<schweeb> fabbione: did you just rm -rf /etc/X11/xkb ?
<calc> wasabi: in 32bit i can use the reinit hack, but 64bit can use it due to real mode interrupts being needed
<schweeb> if so mkdir /etc/X11/xkb
<calc> wasabi: so my screen doesn't come back on in 64bit either :(
<fabbione> schweeb: no, that's on a clean install...
<fabbione> schweeb: and i can't work around it. it's on a buildd
<schweeb> ahhh
<schweeb> daniels: fabbione's failure is cause there is no /etc/X11/xkb afaict
<schweeb> cause I ran into that earlier, when I removed
<daniels> yeah
<daniels> i've fixed that locally, just watching a test build run around
<wasabi> Does a Conflict on previous version of a Depend work as I'd expect it to?
<wasabi> ie, remove the old one, install this new other one, upgrade the old one.
<wasabi> Moving a file from one package to another, etc.
<daniels> i believe yes, but I don't think order is guaranteed
<lifeless> I think you want Replaces:
<wasabi> It doesn't replace.
<daniels> won't be configured by the time you unpack, and may not be unpacked when you are
<wasabi> It's just one file, out of a few hundred.
<lifeless> ok
<daniels> but if you just need it unpacked when you configure, sure
<wasabi> It's just a file conflict.
<wasabi> package b depends on package a. File in package b moved to a.
<daniels> use replaces, in that case
<wasabi> Replaces has no meaning other than to determine order?
<wasabi> It's a big word. ;)
<wasabi> I don't want it to convey the semantic meaning that hte package is actually a replacement.
<daniels> sure
<daniels> its specific meaning is 'files that used to be *here* are now over *here*'
<wasabi> Setting up libgtk2.0-bin (2.6.8-1ubuntu2) ...
<wasabi> Updating the IM modules list for GTK+-2.4.0.../usr/bin/gtk-query-immodules-2.0: error while loading shared libraries: libXi.so.6: cannot open shared object file: No such file or directory
<daniels> cool
<daniels> can you please run dpkg -L libxi6?
<wasabi> It's not installed.
<wasabi> It's just a missing dep.
<daniels> oops
<daniels> iz gtk boog :)
<wasabi> mmm
<wasabi> EVerynow and then I uninstall everything on my system back to ubuntu-minimal, and then install it all again.
<wasabi> Just to make sure it works. :0
<wasabi> Hmm. I suspect that would be a good buildd test.
<wasabi> Install the package into a clean chroot and make sure it installs properly.
<Lathiat> daniels: do i want to update xorg?
<daniels> updating is ok
<Lathiat> COOL
<Lathiat> argh, caps
<weirdcreep> hello
<Lathiat> daniels: xlibs, rmdir /etc/X11/xkb directory not empty
<daniels> Lathiat: known issue
<Lathiat> dan	okie
<Lathiat> daniels: what did it want to update in my config?
<Lathiat> daniels: also on my laptop, it asks (with -phigh) if i want to attempt monitor autodetection and what resolutions i want, that didnt used to happen
<Lathiat> (but has done if for a few releases)
<daniels> Lathiat: update in what config?
<daniels> Lathiat: hm, that sucks
<Lathiat> daniels: in xorg.conf, but it doesnt matter i just regenned it myself
<daniels> could you please send the output of debconf-show xserver-xorg?
<daniels> hm
<Lathiat> also it is detecting my vert/horiz differently
<Lathiat> not that that matters i guess
<Lathiat> seems to look sane
<Lathiat> http://bur.st/~lathiat/xserver-debconf
<daniels> i'll check it out in a bit
<Lathiat> ok, im not caring, just letting you know
<daniels> bonus
<Lathiat> if you want anythign else just yell
<weirdcreep> Ken Charles Barger, 47, accidentally shot himself to death in December in Newton, NC. Awakening to the sound of a ringing telephone beside his bed, he reached for the phone but grabbed instead a Smith & Wesson 38 Special, which discharged when he drew it to his ear.
<fabbione> clearly offtopic...
<fabbione> Kamion, elmo, mdz: can you please NEW system-config-cluster ?
<lifeless> tho weird and creepy
<fabbione> (gui interface to configure redhat-cluster-suite)
<comadreja> is anyone trying to build gcl-2.6.6 ?
<TheMuso> ==/c
<TheMuso> arrgh
<Treenaks> morning all
<tsume> hmm
* mode/#ubuntu-devel [+o daniels]  by ChanServ
* mode/#ubuntu-devel [+b *!*re@*.hsd1.ga.comcast.net]  by daniels
* weirdcreep was kicked off #ubuntu-devel by daniels (serial troll)
* mode/#ubuntu-devel [-o daniels]  by daniels
<Burgundavia> daniels, he also showed up in #gnome-hackers
<daniels> yeah, I saw
<daniels> and #ubuntu
<Burgundavia> oh joy
<tsume> anyone remember the whoopi goldberg movie/commercial where she is shooting this guy with a shotgun repeatedly in the gut about 9 feet away. the guy is wearing bullet proof armor, then he smiles and say something like "bullet proof armor". She pulls out a gun and shoots him in the head, whoopi says.. "Smith and wessen" :)
<tsume> I'm going to have to find that movie
<tsume> whatever its called
<pitti> Hi
<Lathiat> pitti: yo, did the g-v-m update ftbfs?
<pitti> Lathiat: *grump*, no?
<Lathiat> well, i just havent seen an update
<daniels> you won't, if you're on amd64
<Lathiat> not on amd64
<tsume> amd64 > intel
* Lathiat hugs his pentium-m
<tsume> I'll never use Intel again
<tsume> not after the crap they've pulled
<tsume> I hope intel looses bigtime
<tsume> at the lawsuit
<tsume> I hope the EU raided all their offices, not just some
<Treenaks> tsume: even the US ones?
<tsume> Treenaks: no, just the EU
<tsume> AMD launched a lawsuit in the US
<Treenaks> tsume: no but do you hope it ;)
<tsume> Intel fucked themselves since 6 years ago pulling this crap
<tsume> this would mean alot
<tsume> this would also clarify the things I've been hearding from friends about AMD sucking at being a windows server. They probably were running some app compiled byt he intel compiler
<tsume> Not I'm never buying intel ever again because their monoplising crap ways
<thom> this is massively offtopic
<tsume> thom: actually I don't think so
<Lathiat> tsume: Yes it is, so please take it elsewhere.
<sivang> tsume: have you read the amusing slashdot comments?
<tsume> thom: has to deal with ubuntu by the amd64 port ;)
<pitti> Lathiat: hmm, odd bug: "  libgksuui1.0-dev: Depends: libgksuui1.0-0 (= 1.0.5-1ubuntu1) but it is not going to be installed
<pitti> E: Broken packages
<pitti> "
<tsume> sivang: no.
<thom> tsume: no.
<sivang> tsume: this should go somewhere else
<tsume> sivang: I don't read /.
<tsume> I mean.. trolldot
<sivang> tsume: either way, this should be continued in ubuntu-talk or something :-)
<daniels> i'm with thom, this has wandered hugely offtopic
<tsume> just out of curiosity, how much support does the amd64 port have?
<daniels> it works just fine
<tsume> daniels: then steer it on-topic, don't end the conversation
<tsume> its rude
<sivang> oh, and howdyall
<daniels> tsume: how do you steer something like this on-topic? the reason off-topic conversations get ended is because cluttering a development channel with random chatter is rude also.
<daniels> tsume: there is #ubuntu-offtopic for other random stuff, please use it
<tsume> daniels: then you steer it on topic ;)
<thom> tsume: no, rude is continuing to be off topic when you've been asked to stop
<tsume> thom: btw, you guys ship those cds too late by the tiome I moved =] 
<tsume> thom: I didn't want them 4 weeks after ordering the cds
<daniels> you are entitled to a full refund
<tsume> daniels: hah
<tsume> daniels: well I kinda wanted them here in Alaska
<tsume> daniels: they would have helped
<sivang> daniels: hehe, be careful , someone might take you seriously :-)
<tsume> sivang: heh.
<tsume> sivang: Can I get a refund on the 40 dollars shipping them over here?
<Amaranth> hey, a refund should be you paying canonical money :)
<tsume> sivang: shipping from NL to US is expensive. I know
* Lathiat nods at Amaranth 
<daniels> you want canonical to pay you money that they paid to send you stuff?
<Lathiat> At least some unsuspecting stranger will get ubuntu love
<tsume> heck
<daniels> good plan.  anyway, this is also off-topic.
<tsume> those 39 cds probably cost 80 dollars in US currency to ship
<tsume> a 1 lb book from NL cost 48USD
<Amaranth> why did you order 39 CDs?
<tsume> to NL from US
<thom> GUYS, PLEASE DON'T USE #u-devel FOR OFFTOPIC STUFF
<Amaranth> sorry
<tsume> Amaranth: I was going to give them to people
<Burgundavia> tsume, please take this elsewhere
<tsume> Burgundavia: who is in charge of the shipit then? :P
<Treenaks> tsume: Take it elsewhere, please.
* mode/#ubuntu-devel [+o daniels]  by ChanServ
<thom> tsume: shipit has nothing to do with ubuntu development
<tsume> okay, but this has to deal with ubuntu and devrls. 
<Amaranth> #ubuntu-shipit :)
<thom> NO
<tsume> users don't know squat.
<Treenaks> tsume: Try reading FAQs
<Amaranth> this is very much a user question though
<thom> it has to do with Canonical sending CDs. it's a business function utterly unrelated to development or the developers
<tsume> Amaranth: and who qualifies for answering such a question?
<Treenaks> tsume: The answer to that question is in the shipit FAQ, linked from about 20 places on www.ubuntu.com and shipit.ubuntu.com
<Amaranth> tsume: http://www.ubuntulinux.org/support/documentation/faq/shipit/
<Amaranth> kthxbai
<tsume> Amaranth: heh
<Lathiat> daniels: would xlibmesa-dev -> libglu1-xorg-dev | libglu1-dev, xlibmesa-gl-dev | libgl-dev # be a good idea
<Lathiat> daniels: or should i just leave it as xlibmesa-dev, apt-cache show xlibmesa-dev says its a transition package for packages without fixed deps, so i assume thats an appopriate fix
<daniels> depends on whether it needs libgl or libglu, really
<Lathiat> oh so it doesnt need both?
<Lathiat> hrm
<daniels> well, not if it doesn't *use* both ...
<Treenaks> Lathiat: it might not need both, I guess
<sivang> Lathiat: you're asking about out little package from yesterday ? :-)
<tsume> daniels: you really shouldn't op in a conversation like so. it just adds gasoline
* Lathiat tries to figure out what it wants
<Lathiat> sivang: snes9x atm
<Lathiat> well, it references some glu* functions
<Treenaks> Lathiat: try it with either
<Lathiat> so i assume it wants glu
<Treenaks> Lathiat: check if it works.
* Lathiat wonders what gl functions are
<daniels> Lathiat: just look for what it #includes
<Lathiat> right, needs both
<Lathiat> daniels: is libgl-xorg-dev likely to happen anytime soon
<daniels> dunno
<daniels> it sounds worthwhile, but hardly urgent
<daniels> i'll ask gravity about it when I speak to him next
<Lathiat> just wondering cus im about to change abunch of packages that could do with that change, but if its not on the horizon for now i wont worry about it
<daniels> don't worry about it
<infinity> Doing it for consistency's sake would be nice.
<infinity> And if it was done very, very soon, could easily be dealt with for breezy.
<tsume> hmm
<tsume> out of curiousity, what are the usual time gaps between releases?
<Amaranth> 6 months
<daniels> infinity: *grunt*
<Treenaks> tsume: PLEASE PLEASE read the website before asking such basic questions
<Treenaks> tsume: all the answers you seek are there
<infinity> daniels : If you do it soon, I'll even promise to fix all of main for you.
<tsume> Treenaks: I could have thought of another way besides answering with the #debian way
<infinity> (The MOTU guys have a backlog of GLU fixes to make anyway, so adding GL to the mix wouldn't hurt)
<daniels> infinity: bone-arse
<Treenaks> tsume: We like to keep the channel on-topic. This is not on-topic.
<Lathiat> well, thats why i was asking about it now
<Treenaks> tsume: So please ask in #ubuntu, or read the FAQ
<Lathiat> cus im working on the glu stuff
<pitti> infinity: do you have any idea about http://people.ubuntu.com/~lamont/buildLogs/g/gnome-volume-manager/1.3.2-0ubuntu3/gnome-volume-manager_1.3.2-0ubuntu3_20050713-1742-i386-failed.gz? I don't have a breezy at hand here
<tsume> Treenaks: look, devels have to deal with the release stages, not the users.
<Treenaks> tsume: That doesn't mean you shouldn't read
<infinity> Ugh, katie is officially on crack.
<tsume> Treenaks: and if I was reading and passed it up?
<doko> daniels: daniels: is there a list of packages, that are split out of xbase-clients?
<daniels> tsume: it's not a conversation that helps #ubuntu-devel.
<infinity> Despite xorg -41 being installed for powerpc now, It's still trying to UNACCEPT the -37 binaries every half hour. :/
<tsume> Treenaks: you going to shoot a kid for not reading the sign when it says wet paint, because that basically how you are acting right now
<infinity> pitti : Looking.
<tsume> daniels: don't look at me. I didn't answer with a cocky remark
<Lathiat> pitti: hrm, that package installs here
<Treenaks> tsume: is HostingGeek your brother?
* Lathiat laughs at Treenaks 
<pitti> Lathiat: it built fine for me, too
<infinity> pitti : Looks like the same transient whackiness that happens on every GNOME library upload...
<Lathiat> pitti: maybe the b-d needs some upgrading or something
<pitti> Lathiat: shouldn't
<infinity> pitti : I'll give 'em back for kicks, then spend some real energy on it when/if they fail again.
<tsume> Treenaks: can't find the site. Don't know what you're talking about
<Treenaks> tsume: www.ubuntu.com maybe?
<Treenaks> tsume: on the front page, third bullet point.
<thom> tsume: look. you're on the devel channel. we assume that people who want to talk here have some basic level of clue that means we can talk about stuff that's actually interesting without burning energy answering pointless questions
<tsume> Treenaks: let me give you a lesson in proper responses. "tsume: Well yes 6 months. You must have overlooked the information on the website. For future reference, the information on release stages are located at><URL here?"
<Lathiat> tsume: This is not a user help channel
<tsume> thom: and how long could this conversation lasted if Treenaks had manners? 1 second from a response of "6 months"
<Treenaks> tsume: welcome to /ignore-land
<Lathiat> tsume: if you want a response like that, goto #ubuntu
<Lathiat> tsume: also, someone said  6 months 10 minutes ago, now please, go away
* mode/#ubuntu-devel [+o thom]  by ChanServ
<pitti> infinity: thanks a lot
<thom> tsume: we've asked you politely to restrict your conversation to on-topic subjects. please do so
<tsume> Lathiat: I'm just enlightening some manners to someone who is really making other like me uncomfortable.
<mdeboer> hello.
<tsume> thom: yes, thank you I realise that. But I ask how is, "go read the website" on topic?
<thom> tsume: because you should have enough clue to use the resources we provided and not waste people's time. *that's* basic politeness
<tsume> thom: yes, I'm aware. As I also stated I overlooked the "6 months" context.
<mdeboer> i'm trying to build a 2.6.12 kernel on hoary, using the linux-source-2.6.12-2.6.12 from breezy. i run into some problems, so i am looking for documentation... i am used to make-kpkg, but it seems dpkg-buildpackage is the current way to do it?
<Lathiat> mdeboer: make-kpkg is for rolling your own kernels, the official kernel packages are built with the standard build system
<mdeboer> Lathiat: but if i want to create a livecd with this kernel?
<Lathiat> mdeboer: There is a thraed on the mailing list at the moment about putting a custom kernel on the livecd, that might be a good reference
<mdeboer> i think i started that thread :-)
* Lathiat laughs
<tsume> hehe :)
<mdeboer> lack of documentation.... :-(
<mdeboer> so, it's a bit trial and error, which is not really practical given the time it takes to compile a kernel.
<Lathiat> mdeboer: you might be able to remove the clean target
<Lathiat> mdeboer: speed up the trial and error a bit
<mdeboer> yes, but even so... i get errors in the end, that seem to effect the whole build process
<mdeboer> do you know if someone has been backporting the 2.6.12 kernel?
<infinity> Lathiat : TO dpkg-buildpackage without cleaning, you just need "-nc" on the command line, no need to remove the target.
<Lathiat> infinity: ah
<Lathiat> infinity: neat
<tsume> well thank you to who were appropriate in conversation, but I don't believe ubuntu is correct for my standard in user friendliness by the community standards. Japanese do not act inappropriately in context so I'll go back to Vine Linux where its stable, and there are community which knows how to speak appropriately.
<Lathiat> tsume: Thanks, bye.
<infinity> pitti : Head to #flood
<pitti> infinity: thanks for checking, so we should prod daniels to fix xbase-clients?
<jsgotangco> wow what was that about
<jsgotangco> (vine linux is japanese btw)
<Lathiat> just a passing troll
<infinity> daniels : What's up with this?
<infinity> The following packages have unmet dependencies:
<infinity>   xbase-clients: Depends: xdpyinfo but it is not installable
<infinity>                  Depends: xhost but it is not installable
<infinity>                  Depends: xrandr but it is not installable
<infinity>                  Depends: xsetmode but it is not installable
<infinity>                  Depends: xsetpointer but it is not installable
<infinity> E: Broken packages
<infinity> pitti : WOuld it be helpful if I added Debug::pkgProblemResolver output to all build logs?... I do on my Debian buildds, but it's not enabled on the Ubuntu ones (currently)
<infinity> I have to see if it would hideously break the (possibly fragile) regexps in the auto-dep-waiter, but for people who can actually read the output, it might be helpful.
<pitti> infinity: for cases like that, in any case
<pitti> s/in any case/yes, I'd love it/ :-)
<robitaille> infinity:  someone filled that xbase problem on the bugzilla tonight: #12707 
<pitti> Hi sabdfl 
<sabdfl> hi guys
<JaneW> fabbione:ping 
<Lathiat> daniels: (sorry to be a hassle) -> libgl-dev | mesag-dev | xlibmesa-gl-dev, libglu-dev | libglu1-mesa-dev | xlibmesa-glu-dev
<ogra> hey sabdfl 
<daniels> doko: not yet, no
<daniels> Lathiat: er, don't put libgl-dev first
<daniels> just put xlibmesa-gl-dev | libgl-dev, libglu1-xorg-dev | libglu-dev
<Lathiat> daniels: well, thats whats in there now, with that mesa stuff, is it fine just to replace the lot with..
<Lathiat> daniels: what you just wrote
<daniels> pure virtual packages being first leads to unhappy buildds
<daniels> stick with what I wrote ;)
<Lathiat> yeh thats what i was told
<Lathiat> daniels: yeh well thats whats in the debian package, i didnt put that there :)
<daniels> the maintainer is on crack
<Lathiat> Martin Albert :)
<comadreja> anyone has tried to build gcl ?
<Lathiat> nope
<comadreja> it gives lots of errors, I fixed the C ones, but still gives lisp errors
<comadreja> even latest cvs sources
<Lathiat> haha lisp errors
<Lathiat> GOOD LUCK
<comadreja> :D no kidding
<Lathiat> bah
<Lathiat> i hate things that dont build
<Lathiat> haha i love g++
<Lathiat> note: try removing the parenthesis around the type-id
<daniels> infinity: if you can install xbase-clients from -36 or older in the chroots, I strongly recommend you do so
<comadreja> hey daniels :)
<comadreja> yesterday I upgraded and lost my keyboard mapping
<comadreja> now I'm using xmodmap
* Amaranth remembers something about needing a symlink
<Lathiat> Option.h:107: warning: 'class OptionDummy' has virtual functions but non-virtual destructor
<Lathiat> can someone clue me in to what that actually means
<Lathiat> code-wise
<Lathiat> this package gets like 5 of those on every single sourcefile
<Lathiat> does it matter?
<pitti> Lathiat: this pretty much speaks for itself, doesn't it? just make the destructor virtual
<Lathiat> pitti: right, but im wondering if its actually an issue
<Lathiat> i.e. is it worth changing
<pitti> Lathiat: I think so
<Lathiat> hrm
<Lathiat> they dont appear to actually have destructors
<pitti> Lathiat: hm, I thought g++ would then automatically create a dummy one?
<daniels> comadreja: yeah, sounds about right; make sure xkeyboard-config is installed
<Lathiat> pitti: i guess
<Lathiat> apparently not
<Amaranth> all you have to do is install xkeyboard-config?
<comadreja> trying
<daniels> Amaranth: and make sure /etc/X11/xkb/xkbcomp is still a symlink to /usr/bin/xkbcomp, yeah
<comadreja> no such package ?
<Amaranth> hrm, synaptic doesn't know what xkeyboard-config is
<Amaranth> yeah
<daniels> maybe it's still in NEW
<Amaranth> xkbd-config? :)
<Amaranth> doh
<comadreja> daniels : also xlibs fail to install properly
<daniels> comadreja: yeah, known issue
<Lathiat> whats the right command to gpg sign the CoC (like, AA output?)
<Treenaks> Lathiat: it's on the page where you can download it in launchpad ;)
<Treenaks> Lathiat: gpg --clearsign file
<Lathiat> oh i wasnt looking at launchpad
<Treenaks> Lathiat: it has a feature for signing CoCs
<Lathiat> where abouts?
<Treenaks> Lathiat: on your "personal info" page
<Treenaks> Lathiat: (click on your name in the top right corner)
<Lathiat> ah ok
<Lathiat> so i have to login
<Treenaks> yeah
<Lathiat> thats cool
<Lathiat> it could do with an upload button
<Lathiat> rather than the paste thing
<Treenaks> Lathiat: file bug ;)
* Lathiat wonders what keyserver option he could use to upload directly to ubuntus keyserver
<daniels> Lathiat: 'none at all'
<Lathiat> i must have uploaded this key to a crap keyserver
<Treenaks> Lathiat: use subkeys.pgp.net .. that works for me
<Lathiat> yeh, and now i play the waiting game
<Lathiat> launchpad is pretty cool
<mdke> keyservers don't take long to sync iirc
<pitti> Hi shackan 
<pitti> shackan: how's it going?
<shackan> pitti!!!
<shackan> hi!
<shackan> I was trying to reach you on irc yesterday but couldn't find you
<shackan> read the mail I wrote this morning ?
<sivang> shackan: what was it about?
<shackan> sivang, sorry ?
<sivang> shackan: oops,
<sivang> shackan: wrong window
<Lathiat> hrm
<Lathiat> how do i file a bug on launchpad
<Lathiat> it doesnt appear in the package list
<bob2> in launchpad
<Lathiat> bob2: yeh but if i search source packages, launchpad doesnt exist
<Lathiat> so not sure where i should go
<bob2> it's not a source package
<bob2> https://launchpad.ubuntu.com/malone/products/launchpad/
<Lathiat> ah
<Lathiat> ahhhh i see
<Lathiat> that wasnt so obvious
<daniels> no
<Lathiat> (well, not that it wasnt a source package, but i just saw a 'file a bug' link and clicked that from the malone page)
<Lathiat> wow this is looking rather swanky tho
<Lathiat> bein gable to say bug exists upstream, in distro, in release, etc
<Kamion> daniels: xkeyboard-config source NEWed, will add it to desktop as soon as the seeds aren't broken
<Kamion> Riddell: please 'chmod -R g+w /home/warthogs/archives/ubuntu-devel\@lists.ubuntu.com/seeds/seeds--breezy/seeds--breezy--0/patch-75/++revision-lock' on chinstrap
<daniels> Kamion: thanks dude
* mode/#ubuntu-devel [-o daniels]  by daniels
<Kamion> Riddell: your umask is still broken; please add 'umask 002' to the top of chinstrap:~jriddell/.bashrc before making further seed commits
<Kamion> lamont: yo
<fabbione> Kamion: yo.. can you please NEW system-config-cluster ?
<Kamion> tseng: [gmime2.1]  what's the new upstream release needed for?
<fabbione> Kamion: btw.. pkging system-config-lvm.. we need a new upstream version that's not publically available yet
<fabbione> Kamion: the old version is too buggy 
<Kamion> tseng: and I assume you've checked all the mono stuff is sane in it
<Kamion> fabbione: I'm still working my way through all the requests in scrollback, give me a sec
<fabbione> Kamion: sure.. sorry :)
<fabbione> take your time
<Kamion> fabbione: source NEWed, will do binaries when they show up
<fabbione> Kamion: only one bin _all.deb :)
<fabbione> so that's fast and simple :)
<fabbione> thanks a lot
* Amaranth hugs python
<fabbione> Amaranth: i had to make 100K of patches to make that thing to work 
<fabbione> there are almost more patches than code
<Amaranth> haha
<Amaranth> I was starting down the same path for their service manager.
<Amaranth> Did you have to patch out a bunch of weird RH gettext stuff?
<fabbione> no...
<fabbione> i didn't check (neither i can) the internazionalization stuff
<fabbione> also because it's not even translated...
<mdeboer> fabbione: can i ask you something about building the 2.6.12 kernel (breezy) on hoary?
<mdeboer> (you are the maintainer, right?)
<sivang> fabbione: more patch then code in python? :-)
<fabbione> mdeboer: yes i am one of the maintainers. we don't support building .12 in hoary.
<fabbione> sivang: almost :)
<sivang> fabbione: hehe, I thought you were referring to the kernel
<mdeboer> fabbione: i know it is not supported, but i'd like to try anyway.
<Riddell> Kamion: done, sorry about that, why does my commit to the kubuntu seed alter the ubuntu seed?
<mdeboer> fabbione: and i have the impression that the problem i have is not hoary-related
<fabbione> mdeboer: yes i understand, but i don't have time to support a backport. sorry
<Lathiat> fabbione: whats gfs like to actually use?
<fabbione> mdeboer: try to reproduce it in a breezy environment. if it works on breezy.. it's a backport problem, otherwise you are welcome to file a bug
<fabbione> Lathiat: it's pretty simple
<Lathiat> is it solid?
<fabbione> it seems to work...
<mdeboer> fabbione: hm, ok. anyway, i'll just mention what happens. maybe you've seen it. i only want to build for 386. i get really far, but then it fails with: dpkg-genchanges: failure: cannot open upload file ../linux-headers-2.6.12-3-686_2.6.12-3.3custom1_i386.deb for reading: No such file or directory
<fabbione> Lathiat: GFS is not a filesystem you would use on your desktop
<Lathiat> fabbione: i know that :)
<fabbione> and you need to really get to a certain hw level
<fabbione> mdeboer: that's a backport problem related to the version you are using
<mdeboer> fabionne: notice it complains about 686, when i explicitely say flavours := 386 
<mdeboer> fabbione: ah.
<fabbione> and to the fact that you need a specific control file if you only build one flavour
<fabbione> again.. it's a backport problem :)
<Lathiat> fabbione: too much management babble docs
<fabbione> Lathiat: ?
<mdeboer> fabbione: maybe it will be easier modifying the hoary 2.6.10 package to kernel 2.6.12 then backporting the breezy package...
<Lathiat> fabbione: too much of the redhat stuff on it is largely management babble rather than usefull technical documentation :)
<fabbione> Lathiat: it depends to what docs you are looking at
<fabbione> i found both of them
<Lathiat> fabbione: got a pointer for me?
<fabbione> and the tech part is pretty well done
<Lathiat> im just looking at their homepage for it atm
<mdeboer> s/then/than/
<fabbione> http://www.redhat.com/docs/manuals/csgfs/
<Lathiat> ah, thanks
<Amaranth> should i both filing xorg bugs right now?
<Amaranth> err, bother
<daniels> depends what for
<daniels> if it's for any form of anything failing to install, not really
<mdeboer> fabbione: will a dpkg-buildpackage in hoary 2.6.10 generate the modules udebs as well?
<fabbione> mdeboer: i am not sure what you are doing the but error is that you are trying to build one flavour only without modifying all the files
<Amaranth> ubuntu-desktop, x-window-system-core, and xorg-driver-synaptics depend on xserver-xorg
<fabbione> + required to build only one
<Amaranth> i'd rather not pull in all those useless drivers
<fabbione> the build system is pretty similar
<mdeboer> fabbione: 'all the files' == control, and... ?
<fabbione> mdeboer: control.stub mostlikely
<mdeboer> fabbione: i see. i followed the wiki package - which is actually warty based :-/
<Amaranth> daniels: are the things xbase-clients needs sitting in NEW?
<fabbione> brb
<mdeboer> fabbione: so, i rip out all the other flavours from the control.stub, and generate control ?
<Amaranth> mdeboer: tias :)
<daniels> Amaranth: sitting in ~daniels, more like it
<Amaranth> ah
<daniels> Amaranth: i'll fix synaptics later on, but the others won't change for a little while yet
<Kamion> Riddell: it didn't, you committed to the Ubuntu seed apparently by accident
<Kamion> Riddell: although the commit contained no actual content, only a log
<mdeboer> Amaranth: ?
<Amaranth> mdeboer: try it and see
<mdeboer> Amaranth: :-) i looked it up in the hackers dictionary, but it isn't there
<Amaranth> daniels: you ported the exposity crack to metacity 2.9.0?
* Amaranth is poking around in p.u.c
<daniels> Amaranth: yeah, didn't even last thirty seconds on my laptop
<Amaranth> haha
<daniels> kept wanting to put my fist through the screen every time I hit alt-tab and just wanted to switch to the last frigging window I was using
<Riddell> Kamion: yeah, pretty stupid of me
<Kamion> Amaranth: ubuntu-desktop is going to continue depending on xserver-xorg, very likely
<Amaranth> daniels: It needs to use F11 like expose does.
<Amaranth> Kamion: That's understandable. I'd just rather not lose a driver. :)
<daniels> Amaranth: yeah
<daniels> Amaranth: the main advantage to having it all split out right now is that I can easily get people to roll back to specific driver revisions
<daniels> instead of having to arse about trying to work out if the problem's driver or core
<Amaranth> heh
<Amaranth> can you build just one driver?
<Lathiat> well, its all in one source package no?
<\sh> Lathiat: yes
<Amaranth> btw, is the exa stuff getting into 7.0?
<Amaranth> i might poke the ati driver and try to port it, it sounds simple enough
<seb128_> Amaranth: hi
<Amaranth> hi?
<seb128> you don't know what it means? :)
<seb128> Amaranth: how is working smeg on breezy? Do you have user feedbacks on it?
<Amaranth> some odd issues i can't figure out, yeah
<Amaranth> and pyxdg has a bug that's fixed in CVS that's pretty crucial
<Amaranth> the issues are one or two people with unexplainable problems that make absolutely no sense, so i'm calling PEBKAC :)
<seb128> Amaranth: I want to propose it as the breezy menu editor
<Amaranth> ooh
<seb128> but it has to work fine for that
* Amaranth would probably get 0.8 moving along then
<Amaranth> err, should
<seb128> are you confident we will have a version working fine soon?
<Amaranth> aside from the one or two issues it works fine now
<Amaranth> but 0.8 is going to be the first version that's translatable
<Amaranth> oh, and i'm switching to making it gnome only so i can use gnome-vfs and such
<Lathiat> haha, gave up on kde?
<Amaranth> if i really kick ass on it i could probably release it this time next week
<Amaranth> yeah, i don't use KDE so i don't care much for it :P
<Amaranth> besides, they can install gnome libs if they really want it
<Lathiat> kde? whats that ;p
<Lathiat> gah
<Amaranth> or someone could rewrite the frontend to make a KDE version, it's only a glade file and about 600 lines of code
<Lathiat> cthugha is shitting me
<seb128> Keybuk: around?
<Lathiat> glColorTableEXT is fscking well defined
<seb128> Keybuk: do you remember what issue this patch is supposed to fix exactly?
<seb128>    * debian/patches/14_dont_override_user_removals.patch:
<seb128>      - Ensure we don't override user removals when we take system backgrounds
<seb128>        by checking they don't have information about it already.
<seb128> 
<\sh> backing up home
<seb128> Amaranth: oh, translation would be nice ... when is that landing ? :)
<\sh> reinstallubuntu...
<Amaranth> hopefully a week from now
<\sh> i need a noob desaster recovery function
<Amaranth> i'll make it before the feature freeze :)
<Amaranth> pyxdg maintainer won't though, he is on vacation
<Amaranth> so a CVS package of that will probably be needed
<seb128> no pb with that
<Amaranth> right now filenames with ' make pyxdg die horribly
<seb128> we already have rb and other CVS sutff
<seb128> I'll mail ubuntu-devel today
<Amaranth> oh, i haven't looked at rhythmbox in so long i forgot about 0.9 :)
<GNULinuxer> seb128: the cairo you uploaded to Debian breaks Pango support in Firefox
<Amaranth> GNULinuxer: read the blog entry
<seb128> GNULinuxer: I've not uploaded any cairo
<GNULinuxer> Amaranth: I have read it
<Amaranth> do what it tells you
<seb128> GNULinuxer: read it again?
<Riddell> Amaranth: hmm?
<GNULinuxer> Amaranth: that's not the issue
<Amaranth> Riddell: ?
<GNULinuxer> seb128: no pango means no Indic support
<seb128> hint "than firefox has some issues because gecko assumes than gtk uses pangoxft which is not true with cairo"
<seb128> GNULinuxer: fix firefox, or switch to epiphany/galeon
<Amaranth> do the mozilla folks know about it?
<Amaranth> that should probably be something to be fixed in firefox 1.1
<seb128> I guess so
<GNULinuxer> seb128: yes ... and that implies that Indic support is broken in Firefox for now
<seb128> GNULinuxer: and? I'm not maintaining firefox
<seb128> GNULinuxer: that's a firefox issue
<Riddell> Amaranth: what KDE support are you dropping?
<GNULinuxer> seb128: who is the firefox contact?
<seb128> GNULinuxer: http://packages.qa.debian.org/m/mozilla-firefox.html
<Amaranth> Riddell: Making smeg depend on python2.4-gnome2.
<Riddell> Amaranth: but you'll still be able to edit KDE's menu?
<Amaranth> sure, all the backend code will still be there
<Amaranth> someone should volunteer to right a KDE/Qt frontend :)
<Amaranth> err, write
<Amaranth> stupid typing at 4am
<Riddell> Amaranth: doesn't seem like much has changed then, having to install python-gnome2 is not much worse than having to install python-gtk
<Amaranth> ok then
<Riddell> groovy, just checking :)
<Amaranth> now i just need andy to help me make humility icons not look bad in smeg
<Amaranth> oh, and all that pesky 'code' to write
<\sh> back in a few minutes
<Riddell> Amaranth: I'll ask around if anyone is interested.  it may be they're all perfectly happy with the current KDE menu editor
<Amaranth> #kde-devel seems to hate mine
<Riddell> Amaranth: hate as in "you're gnome, we're #kde-devel, we will be abusive" or hate as in sensible reasons?
<Amaranth> no sensible reasons that i saw
<Riddell> sounds like #kde-devel then
<Amaranth> bah, stallman just ruined harry potter for me
<Treenaks> Amaranth: how?
<ogra> Amaranth, oh, he's around at your place ? 
<Amaranth> no
<Amaranth> his website has a spoiler
<Treenaks> Amaranth: oh?
<Amaranth> he did it on purpose
<Amaranth> says to not buy the books then ruins the whole things by telling who the half blood prince is
<seb128> daniels: around?
<chrissturm> if harry potter was *really* free this wouldnt have been necessary :P
<Amaranth> oh, that reminds me
<Treenaks> Amaranth: Rumours like that have been going around for ages
<Amaranth> if i get my hands on that book 0.8 will be at least a week late
<Amaranth> smeg 0.8 i mean
<Riddell> Amaranth: why does he say not to buy the books?
<Amaranth> because of the whole thing in canada
<Amaranth> someone sold the books to people
<Amaranth> appearently they have an injuction against anyone reading the books before today
<Treenaks> Amaranth: like that's going to work
<Riddell> oh aye, that is crazy
<Amaranth> exactly
<Treenaks> Amaranth: the people who got it will have read it anyway
<Amaranth> "Don't buy this evil book! Oh, and here is what happens so it's ruined for you anyway. Don't buy this evil book!" *smack*
<seb128> daniels: you know about #12705 , right?
<chrissturm> Amaranth, looks like he bought the book :)
<daniels> seb128: yeah.  feature, not a bug. :)
<pef> hi
<seb128> daniels: how do I fix the builds so?
<seb128> daniels: ie gnome-control-center ftbfs on that
<daniels> seb128: grep libXrender.la /usr/lib/*.la, rebuild every lib which references it
<seb128> GRRRRAAAAA
<daniels> seb128: i know it's a crap solution, but having it there was breaking other builds in interesting ways ... sorry
<seb128> thanks
<seb128> $ grep libXrender.la /usr/lib/*.la | sed 's/:.*//' | wc -l
<seb128> 15
* seb128 cries
<daniels> :\
<daniels> i don't actually like causing more work for you
<daniels> ... often
<seb128> k, let's rebuild what is required
<ogra> daniels, does that mean we will have to rebuild _all_ stuff depending on libxrender1 or is it only temporary ?
<ogra> ogra@honk:~/k12/bastel $ apt-cache rdepends libxrender1|wc -l
<ogra> 359
<ogra> there is a lot universe stuff in that list....
<Lathiat> daniels: have you ever noticed that dialog that comes up when X fails to start (would you like to view a log, etc), stops your keyboard from working?)
<Lathiat> daniels: (happens all the time here, and i have to use mjy power button to reboot)
<Treenaks> Lathiat: yes! though Alt+SysRq+e works too
<Treenaks> (or whichever one gives you a tErminal)
<Lathiat> daniels: also
<Lathiat> daniels: the new vertrefresh/horizsync im getting
<Lathiat> daniels: wont let me run at 1680x1050
<Lathiat> daniels: and its sitting on 1280x800 or something now
<Lathiat> Treenaks: do you also get it printing out with bad fonts?
<Lathiat> Treenaks: like, random crap characters instead of borders, and random crap on other bits
<Amaranth> Lathiat: You're on the wrong console or something.
<Treenaks> Lathiat: no
<Lathiat> Treenaks: hm
<Amaranth> I've gotten the random crap chars on everything but tty1
<Lathiat> that said i have an issue with my fb sometimes
<Kamion> pkgstriptranslations: inconsistent /CurrentlyBuilding file, Component: value is empty
<Lathiat> like, in the hoary installer
<Kamion> infinity: ^-- the above is happening on all d-i daily builds
<Lathiat> the top two lines move down
<Lathiat> the bottom two lines disappear
<Lathiat> and the top two lines stay blue with lines along the side of each character bound
<Kamion> try different vga= parameters
<Lathiat> that often ends up in a black screen
<Lathiat> i just turn framebuffer off to install
<Lathiat> debian-installer/framebuffer=false
<Kamion> that works too
<Lathiat> Kamion: when specifying a vga mode in grub
<Lathiat> Kamion: do i want 0x or no 0x
<seb128> ogra: he didn't say depends
<ogra> seb128, phew..
<Kamion> Lathiat: I don't recall
<Lathiat> hm
<Kamion> Lathiat: I believe without 0x
<Kamion> Lathiat: actually, looking at the code, either should work.
<seb128> Kamion, mdz: is there any plan to get wxwidgets2.6?
<ogra> Lathiat, vga=771 is 1280x600
<ogra> err x800
<seb128> Amaranth: should I update to python-xdg CVS now?
<ogra> (at least on my lappie)
<seb128> or wait for some changes?
<Kamion> seb128: not that I'm aware of (but likewise I don't know of an explicit decision against it)
<Amaranth> the changes are in
<Lathiat> ogra: ooh, widescreen vga mode?
<Lathiat> ogra: can you do 1680x1050? :)
<ogra> Lathiat, yep
<ogra> Lathiat, nope
<Lathiat> aww
<Lathiat> how come?
<Amaranth> not sure what else changed, i know that fix is in Menu.py
<ogra> Lathiat, my display cant do higher res...
<Lathiat> ogra: oh i mean
<Lathiat> ogra: do you know if theres a mode for that
<Lathiat> (cus mine does)
<ogra> Lathiat, no idea
<Lathiat> cus ws modes arent mentioned in the linux docs
<Lathiat> so i have no idea where to find them
<seb128> Kamion, Amaranth: thanks
* Amaranth is just going to get wxwidgets from debian and build vlc on his own
<Lathiat> irc vlc needs sdl love too
<Lathiat> oh no
<Lathiat> it was dbus/hotplug/etc love
<Amaranth> no, it needs hal love
<Lathiat> yeh
<Amaranth> pretty sure 0.8.2 fixes that
<Lathiat> interesting...
<Lathiat> 771 seems to be 1024x768 for me
<Lathiat> maybe thats why the other modes blank my screen
<Amaranth> i think it depends on your card
<Lathiat> well, i have a nvidia
<ogra> yes... 
<Lathiat> ogra: yes what?
<Lathiat> see the linux kernel docs say that 41B or something is 1024x768
<Lathiat> err, 31B
<ogra> depends on your card....
<Lathiat> right
<Lathiat> that sucks
<ogra> i.e. on the bios...
<Amaranth> yeah, debian sid has vlc 0.8.2
<Lathiat> wonder if i can extra a list from the bios
<Lathiat> daniels: is there a tool to dump the vesa table?
<ogra> Lathiat, try vga=ask 
<Lathiat> ogra: everytime ive tried that i jsut get crap mdoes
<ogra> and reboot... it should offer a list... (which is not always correct)
<Lathiat> also they tend to be numbers, rather than hex number, which dont seem to work with vga=
<ogra> correct == you can very often have other modes too...
<carlos> daniels, Breezy Xorg is a bit fucked, it's missing some packages. Are you aware of that?
<tseng> Kamion: gmime2.1 in unstable builds the mono bindings (-cil), ours does not. beagle needs latest version (ours had ancient 0.6)
<tseng> Kamion: and yes i built it and build beagle against. latest beagle is failing for unrelated reasons, will dig at that
* Amaranth wonders where aalib1-dev went
<Kamion> tseng: ok then, mail James Troup with the request, mentioning that I approved it
<mdeboer> fabionne is still away?
<seb128> do we have any firefox maintainer nowadays, or should I just go ahead to apply some patches?
<jsgotangco> night all
<fabbione> hey seb128 
<carlospc> Hello, i've been testing Colony CD2 and i realise that partman doesn't recognise any partitions of my disk
<seb128> hi fabbione 
<Amaranth> whee, building wxwidgets2.6
<siretart> Amaranth: I filed https://bugzilla.ubuntu.com/show_bug.cgi?id=12673 for aalib, but it is still unconfirmed :(
<ogra> Amaranth, i guess wx 2.6 will come anyway (if not held up by UVF)
<Amaranth> UVF?
<carlospc> Having a look at https://bugzilla.ubuntu.com/show_bug.cgi?id=1235 i guess that it's my problem
<fabbione> seb128: -Wl,--as-needed seems to misbhave on sparc.. :/
<ogra> upstream version freeze
<fabbione> seb128: and basically 3/4 of gnome is FTBFS
<fabbione> seb128: is there any easy way to remove that flag?
<seb128> fabbione: what kind of error?
<fabbione> seb128: so that i can test it?
<seb128> fabbione: it works fine for Debian/sparc
<seb128> fabbione: drop it from debian/rules
<fabbione> seb128: the error is sort of weird and not gnome's fault afaict
<fabbione>  /usr/lib/gcc/sparc-linux-gnu/4.0.1/../../../../lib/crt1.o:../sysdeps/sparc/sparc32/elf/start.S:60: multiple definition of `_PROCEDURE_LINKAGE_TABLE_'
<fabbione>  /usr/bin/ld: Disabling relaxation: it will not work with multiple definitions
<seb128> urg
<fabbione> collect2: ld returned 1 exit status
<fabbione> seb128: is Debian using gcc-4.0.1 ?
<mdeboer> fabbione: just to let you know, with the modified control.stub, it works ok
<seb128> fabbione: that's specified from debian/rules, just drop the line
<fabbione> seb128: ok thanks.. 
<seb128> fabbione: that would be a question for doko :p
<fabbione> i will let you know if it works...
<Amaranth> cool, wx2.6 can use gnome-print
<mdeboer> fabbione: so i now have a 2.6.12 compiled for hoary. 
<Amaranth> mdeboer: congrats
<mdeboer> thnaks
<Amaranth> mdeboer: others are dying to get that for various reasons
<fabbione> if it does, can i give you a list of packages that will need to be reworked? i don't need them to be fixed right away... just to include the change in the next uploads...
<fabbione> mdeboer: fine.. now you need to deal with the entire userland to make it working as it should...
<Amaranth> hehe
<mdeboer> fabbione: :-)
<Amaranth> i know some things need fixed as far as inotify
<Amaranth> you need a new initrd and related things
<mdeboer> fabbione: i have been running (a vanilla) 2.6.12 for a while without any problems
<Amaranth> well, see you in 20 hours when this compile finishes
<fabbione> mdeboer: sure.. until it doesn't break there are never problems..
<fabbione> you are not running .12 on N thousands different user boxes
<fabbione> with millions of different HW configs
<mdeboer> fabbione: i cannot think of anything obvious that might break from a .10->.12 kernel upgrade
<ogra> Kamion, have a second ?
<Kamion> ogra: maybe
<fabbione> mdeboer: udev? ndiswrapper? ipw2100 and ipw2200 ?
<fabbione> + other stuff
<fabbione> but i will let you figure that out
<ogra> if i add a new seed for edubuntu called server, all stuff in there needs to be in ship ?
<ogra> or in suported ?
<ogra> +p
<ogra> and must edubuntu supported be identical with ubuntu ?
<ogra> s/ubuntu/ubuntu supported
<Kamion> ogra: what are the semantics of server?
<seb128> daniels: 
<seb128> # grep libXrender.la /usr/lib/*.la | sed 's/:.*//'
<seb128> /usr/lib/libXft.la
<Kamion> ogra: no, supported doesn't have to match
<ogra> Kamion, great...
<seb128> daniels: is that ok if I upload a libxft for that?
<Kamion> ogra: the archive basically cats all the outputs together and considers the whole lot to be in main
<daniels> seb128: sure
<seb128> thanks
<ogra> Kamion, server holds the list of server stuff i have to install with the edubuntu-server metapackage (ltp, moodle php, mysql etc)
<daniels> sorry 'bout that
<seb128> np, don't worry
<ogra> s/ltp/ltsp
<Kamion> ogra: will it fit on a CD?
<ogra> Kamion, edubuntu is a DVD release ;)
<Kamion> it is?
<fabbione> wow
<ogra> and hopefully a liveDVD release with Express installer :)
<Riddell> ogra: all computers in schools have DVDs?
<Kamion> anyway don't confuse the issue
<ogra> Riddell, i'd like to have a iso image for download or to put it additionally on the DVD for separate burning, but word is to go with DVD
<Kamion> so is the aim to be able to install edubuntu-server via some magic CD boot option?
<ogra> Riddell, the amount of stuff will get to big at least with the second release...
<Kamion> and should all the server stuff be copied to the hard disk during a regular Edubuntu install?
<ogra> Kamion, something along this line
<Kamion> ogra: you *sure* you want it all copied to the hard disk during a regular Edubuntu (non-server) install?
<ogra> Kamion, i'd like either a question in the installer like "is this a standalone WS or a LTSP install" or a bootoption
<Kamion> question's tricky, boot option is much easier
<ogra> nope, only for the server install
<Kamion> ok, in that case you should have server < supported, but not server < ship
<ogra> ok, so the default will be the server install then... and the bootpotion stanalone gets you a WS install
<ogra> oki
<Treenaks> bootpotion?
<ogra> Treenaks, installer bootoption
<Treenaks> ogra: *phew*
<Kamion> ogra: so edit the STRUCTURE file in the Edubuntu seed, add a line "server: minimal standard" (assuming server doesn't include desktop) and add "server" just after "standard" in the supported: line
<Treenaks> though a bootpotion sounds like Dark Magic ;)
<Kamion> Treenaks: boot options are really easy
<Kamion> Treenaks: questions require actual code
<Treenaks> Kamion: potion not option
<Kamion> heh
<ogra> Treenaks, the tricky biut her is to decide whats the default ;)
<ogra> but since sabdfls word is classrom install, its the server i guess
<Kamion> mdeboer: you'd be amazed what random apparently-totally-unrelated stuff broke in the installer because 2.6.12 was a bit more strict about some things
<Treenaks> ogra: for edubuntu you mean?
<ogra> yepo
<Kamion> mdeboer: when we switched to 2.6.12, the installer just hung on amd64 and powerpc. It turned out to be a cdebconf signal handling bug, but it really wasn't obvious
<Kamion> mdeboer: there are probably plenty of similar things outside the installer
<fabbione> there are reasons why i seriously DISCOURAGE backports of the kernel
<Keybuk> seb128: otherwise if the user "Remove"d a background from their list, it'd just come back again
<comadreja> daniels : where did libXrender.la go ?
<daniels> comadreja: taken out the back and shot
<daniels> its body dumped in a ditch, violated and unloved
<seb128> Keybuk: I don't get the bug without it, maybe it has been fixed since by upstream, thanks
<Keybuk> perhaps
<rubenv> I've just been checking out the build logs for linux-restricted-modules in breezy
<rubenv> they appear to have been built succesful, but why are they not installable?
<comadreja> daniels : really, gnome-terminal doesn't build
<rubenv> is this because of the xorg split, or because of nvidia?
<daniels> comadreja: i know -- our good man seb is taking care of it
<comadreja> daniels : oh, thanks
<rubenv> also, I can't find the packages for them, for some reason
<rubenv> makes it quite hard to try to fix them
<fabbione> seb128: i confirm that removing the relaxation work
<fabbione> seb128: can i give you a list of packages to do when you upload the next versions?
<ogra> rubenv, there is no l-r-m for breezy yet, for what did you look ?
<fabbione> seb128: i really have no rush to get everything fixed by yesterday
<rubenv> ogra: http://people.ubuntu.com/~lamont/buildLogs/l/linux-meta/2.6.12.3/
<rubenv> oh, I get it wrong
<rubenv> those are stub packages right?
<rubenv> in the linux-meta source
<seb128> fabbione: you want to drop the flag from every single GNOME package?
<ogra> yep, they not ready yet....
<seb128> fabbione: better to fix the buildchain than workarounding a pile of packages imho
<fabbione> seb128: only on sparc.. yes
<rubenv> oh, I'm sorry, I thought they were unbuildable for some reason
<fabbione> seb128: yes.. but apparently the fix is unknown yet..
<fabbione> seb128: but let's wait a bit.. what is your time schedule to get the latest gnome crack in?
<rubenv> without them I can't upgrade my laptop to breezy and do day to day testing, so I figured if there was debugging to do
<seb128> fabbione: still, I'm not happy to divert 30 packages from Debian only to workaround an issue instead of fixing it
<rubenv> I'll just sit tight and keep updating my vmware breezy
<fabbione> seb128: neither am i
<seb128> fabbione: sep. 7th is GNOME 2.12.0
<fabbione> seb128: ok thanks.. there should be enough time to get it right
<seb128> np
<fabbione> seb128: hmmm interesting.. it seems a bug introduced in 4.0.1
<fabbione> because in Debian they are building with 4.0
<fabbione> hmm no
<seb128> can you try downgrading gcc on your box and note if that fixes the issue?
<fabbione> so i am 
<seb128> no what?
<fabbione> gcc-4.0.1 did FTBFS on sparc (gnat-4.0)
<fabbione> so i am building with the same gcc-4.0 as in debian
<rubenv> 
<ogra> seb128, https://launchpad.ubuntu.com/malone/bugs/1219
<lifeless> win 11
<ogra> lifeless, loose 10
<ogra> lifeless, 1 left :)
<lifeless> 99 bottles of beer on the wall, 99 bnottles of beer
<ogra> hehe
<fabbione> oh well guys
<fabbione> time to start the weekend
<fabbione> cya on monday
<ogra> ciao fabbione 
<fabbione> have fun
<thom> http://www.andrewsavory.com/blog/archives/000785.html
<seb128> ogra: what about it?
<ogra> seb128, since it was in malone, a MOTU hopeful grabbed it... is the bug accepted by you ? so he can forward a patch....
<comadreja> seb128 : that motu is me
<comadreja> seb128 : I was working on it
<jdub> thom: nice :)
<seb128> I don't have any ownership on bugs
<seb128> feel free to deal with upstreams
<seb128> I give all the GNOME bugs, just pick one and fix it
<seb128> send the patch upstream
<seb128> and everybody is happy :)
<seb128> hey jdub 
<ogra> :)
<ogra> nice: This is what linux should be like. This, my friends, is the future.
<seb128> and I don't care about this bug
<ogra> oki
<seb128> is concern people using the command line
<seb128> and copying emails from here
<seb128> which is almost no user
<seb128> and that's only a cosmetic label issues for these people
<ogra> thats why i asked if its a accepted bug for you :) 
<ogra> comadreja, look if there is a bug for it in gnomes bugzlla the... link it to the malone bug if there is one...else open one and submit your patch to that
<seb128> it's one """bug"""
* ogra wants a new keyboard
<comadreja> ogra, ok, I'll do
<daniels> thom: working X -> world peace, obviously
<daniels> 'xresprobe flies to jerusalem for negotiations'
<thom> rofl
<pef> ogra: http://www.artlebedev.ru/portfolio/optimus/
<Treenaks> pef: yes.. they should make that one for real, instead of just concept images
<daniels> pef: oh my god
<pef> Treenaks: are you ok to spend $200 for a keybaord :D
<Treenaks> pef: if it's that one: yes
<jdub> http://assorted-sinks.info/?p=29
<jdub> blog spammers using ubuntu :-)
<jdub> er, using the reference
<jdub> that is
<jdub> *cough*
<daniels> sure, sure
<ogra> pef, ping me again if they offer this for crappy acer laptops ;)
<seb128> jdub: l10n-list? The french guys asked again ...
<Keybuk> ok, rhythmbox is stupid, it won't go to the next track
<mdeboer> Kamion: 
<seb128> Keybuk: it's fixed with the version uploaded yesterday ... which FTBFS because of xorg changes
<mdeboer> Kamion: the documentation of debian-installer says to build the udebs with linux-kernel-di-i386-2.6
<Kamion> mdeboer: yeah, out of date
<mdeboer> Kamion: ok, just confirming
<Kamion> mdeboer: feel free to file a bug
<mdeboer> Kamion: i don't understand how to tell the debian-installer build where to look for the udebs.
<mdeboer> oh sorry, i see it now
<Amaranth> omgwtfhax
<Amaranth> stupid debian package has hardcoded python2.3 command
<daniels> it's common
<Amaranth> i've spent a long time waiting for this to compile just to have it fail on building the wxpython module
<mdeboer> Kamion: FYI, the hoary debian installer builds correctly with by backported breezy kernel
<Kamion> it won't actually work
<Kamion> at least not on amd64 and powerpc
<mdeboer> Kamion: and qemu boots the netboot mini.iso
<mdeboer> Kamion: i am only interested in 386
<Kamion> furthermore you'll probably need a new udev to get it to do correct hardware detection
<Kamion> just as long as I never end up with users using your images and filing bugs assigned to me
<mdeboer> Kamion: don't worry about that. 
<mdeboer> Kamion: the purpose is a very limited use live cd, the experimental use of 2.6.12 will be advertised all over.
<Kamion> ok, please tell users not to file bugs in the Ubuntu bugzilla
<mdeboer> Kamion: maybe I should include both the original 2.6.10, and 2.6.12 
<mdeboer> Kamion: i will
<Amaranth> hmm
<Amaranth> what can i do to not have to recompile all of this stuff yet still make a deb?
<seb128> debuild binary
<Amaranth> dpkg-buildpackage isn't the say to go
<Amaranth> ah
<seb128> it doesn't clean, just "make" again
<Kamion> Amaranth: debuild's just a wrapper around dpkg-buildpackage
<Amaranth> and now the nickname makes sense
<jordi> http://www.advogato.org/person/Uraeus/diary.html?start=484
<jordi> ahem
<Amaranth> haha, saw that earlier
<Amaranth> real classy
<daniels> christian is a good man
<daniels> whose opinion I value
* Amaranth too
* ogra is really tired of FF discussions on ubuntu-users
<highvoltage> FF?
<ogra> firefox
<ogra> we have he discussion why the version is 1.0.2 n hoary every 6 weeks...
<Treenaks> ogra: the "Omg! We are teh vulnerables!!" one?
<ogra> yes, yawn....
<highvoltage> well, nothing stops anyone from downloading it at mozilla.org.
<Treenaks> highvoltage: well, the nice packaging probably
<highvoltage> i'll shutup about FF before we contaminate this channel too and then ogra hates me :)
<\sh> ogra: filters are helping ,-) scoring as well 
<ogra> hehe, i wont :)
<highvoltage> ogra: will you be on-line this weekend? i got my internet connection sorted out.
<ogra> highvoltage, times where i'm not online are rare :)
<highvoltage> kewl.
<ogra> highvoltage, we'll have to talk about your scripts and your setup for the skeleton user, i'd like to adopt that... 
<ogra> highvoltage, and i was promised to get the source for the guadalinex admin tool this weekend
<highvoltage> good stuff. we can do that this weekend. and then i can finally learn how to create .debs :)
<ogra> yeah
<ogra> you get a personal class :)
<daniels> AWESOME
<daniels> sudo apt-get dist-upgrade  308.85s 50.23s system -1% cpu -9:-43:-48.02 total
<Treenaks> daniels: X works now?
<daniels> go zsh, it's your birthday
<ogra> Kamion, if i have a software in the server seed that has a alternative dependency (mysql|postgres) i have to include the SQL server i want, right ?
<Kamion> germinate will pick one, if it's not the one you want then you need to specify
<Kamion> are your seeds in arch yet somewhere that I can check them out?
<mdeboer> Kamion: is it the debian-install that should create the whole pool and dists directories for the cdrom ?
<Kamion> mdeboer: no that's debian-cd
<ogra> Kamion, not yet, i suck with arch... can i mail you a tarball ?
<Kamion> but don't bother with the source packages in the archive
<Kamion> ogra: I'd really rather not
<mdeboer> Kamion: what do you mean?
<Kamion> ogra: it *has* to be in arch for various systems to work properly
<ogra> hmm
<Kamion> mdeboer: colin.watson@canonical.com--2005/debian-cd--ubuntu--0 in arch is what we actually use, with some wrapper scripts around that
<Kamion> ogra: and it *has* to be branched from the breezy seeds, and you should set that up sooner not later
<ogra> Kamion, i branched it, i'm working in seeds--breezy--0--patch-71
<Kamion> because we need to be able to merge Ubuntu seed changes into Kubuntu and Edubuntu from time to time
<ogra> (locally)
<Kamion> did you actually baz branch?
<mdeboer> Kamion: hmm, maybe i could just do a quick hack, putting the udebs in there, and modifying the packages...
<ogra> Kamion, i did a checkout....
<Kamion> mdeboer: the words "debian-cd" and "quick hack" don't go together
<Kamion> ogra: then you didn't branch
<daniels> Kamion: ... they don't?
<Kamion> daniels: well, maybe apart from with "is a" in between
<daniels> right
<mdeboer> :-)
<ogra> Kamion, as described on the seeds wikipage
<Kamion> but doing quick hacks *with* debian-cd doesn't really happen
<Kamion> ogra: the seeds wiki page doesn't really go into how to create custom seeds. You have to 'baz branch'. Want me to set up the infrastructure?
<daniels> yeah, not half wrong
<ogra> Kamion, yes please...
<Kamion> ogra: is there an edubuntu development mailing list?
<ogra> Kamion, yep
<ogra> edubuntu-devel@
<mdeboer> Kamion: but "with some wrapper scripts around that" doesn't really sound like something i could use either... 
<Mez> edubuntu-devel@
<Kamion> ogra: ok, I'll want you through it
<Kamion> er, "walk"
<Kamion> ogra: baz make-archive --signed sftp://chinstrap/home/warthogs/archives/edubuntu-devel@lists.ubuntu.com
<ogra> Kamion, great , some people will kill me if my seeds are not up soon :)
<Kamion> mdeboer: not trivially, no
<ogra> Kamion, drops me a usage line
<carlospc> mdeboer: have a look on http://groups.yahoo.com/group/Berita-Mr-K3/message/180 this page explain how to download debian-cd and some others stuff
<Kamion> ogra: hang on, you've never actually logged into chinstrap. Do that first, and put 'umask 002' at the top of ~/.bashrc
<mdeboer> carlospc: thanks
<ogra> phew
<ogra> ok
<fabbione> mdeboer: are you going to take care of the bugs of that custom cd you are doing?
<daniels> Kamion: what would you need umask 002 for when you're committing to seeds?
<fabbione> mdeboer: or is it a one go shot to drop on the floor after?
<Kamion> daniels: otherwise ++revision-lock ends up non-group-writable
<mdeboer> fabbione: i mentioned to Kamion that it will have "experimental" warnings all over
<carlospc> mdeboer: after you have download all, have a look on the cdimage/bin/ directory, there is a script called build-image-set, have a look to understand the process
<daniels> Kamion: </sarcasm>
<Kamion> ah
<mdeboer> fabbione: and "don't file ubuntu bug reports"
<Kamion> carlospc: it's still not simple to customise though
<fabbione> mdeboer: no that's not enough to avoid people to use it and file bug reports on official packages.
<fabbione> mdeboer: you need to change versions of the packages you are adding there from the official ones
<Kamion> carlospc: and it's too much effort unless you're setting up automated daily builds
<mdeboer> fabbione: i will include 2.6.10 and 2.6.12-rt-preempt, and make 2.6.10 the default.
* Mez yells at elmo
<fabbione> we need to be able to discern easily what's official and what's not
<Mez> gb mirror is down
<mdeboer> fabbione: and i will setup a mailinglist.
<Mez> BACK UP AHAIN
<Mez> damn caps
<carlospc> Kamion: i'm agree with you, i've been customizing this scripts for some days...
<mdeboer> fabbione: but we are talking limited use.
<fabbione> mdeboer: no that's again not enough.. all each single package you modify there needs to have a custom version
<fabbione> mdeboer: because if you change udev to work for .12, it will break .10
<fabbione> or stuff like that
<fabbione> so.. please use custom versions all over
<seb128> can a buildd guy kick vte?
<mdeboer> fabbione: sure. all will be properly versioned
<mdeboer> fabionne: i wrote to ubuntu-devel what this livecd will be for.
<Kamion> ogra: problems logging into chinstrap?
<fabbione> mdeboer: yes i read that.. i am the same person that told you not to backport kernel...
<mdeboer> fabionne: and as it is, it is not unlikely that i will stick with 2.6.10, even though it will give a wrong impression of linux for audio use...
<mdeboer> fabbione: i know. guess i'm a bit stubborn.
<fabbione> mdeboer: i don't care the amount of customizations you do. I care how you are doing them.
<\sh> reinstalled hoary..now upgrade to breezy..*shiver*
<fabbione> and that given that the kernel is not something you change easily, please add custom versions all over
<fabbione> so that we can identify bug reports..
<chrissturm> mdeboer, are you working on an audio distro?
<fabbione> because even if you don't believe me, we will get them from people using your CD
<mdeboer> fabbione: as long as i but something like 'icmc', or 'agnula' in the versions.
<fabbione> because you have no idea on the audience and some user behavior
<fabbione> mdeboer: i don't care.. it's enough it doesn't match anything that's in Ubuntu already
<mdeboer> chrissturm: i am working on a livecd to be used during the icmc (computer music) conference.
<fabbione> mdeboer: it can be 'ping' or 'pong' or 'audiobackport'
<mdeboer> chrissturm: but it is not unlikely this will go into agnula
* fabbione takes off from IRC and heads to a party
<mdeboer> fabbione: many custom packages i use come from agnula, and are already correctly marked.
<mdeboer> fabbione: thanks for your comments
<chrissturm> mdeboer, does it contain additional debs that are not in ubuntu? is it possible to get those debs from somewhere?
* chrissturm is *very* interested in linux audio
<mdeboer> chrissturm: see www.agnula.org
<mdeboer> chrissturm: or join #agnula
* terrex is back (gone 00:56:06)
<Amaranth> grr
<Amaranth> all that work to make wx2.6 build and vlc depends on wx2.4 in ./configure
<JanC> Amaranth : lol  :-P
<Amaranth> well no
<Amaranth> it just does some weird crap with wx-config that i don't feel like messing with
* mdeboer just gave up
<seb128> daniels: 
<seb128> Setting up xlibs (6.8.2-41) ...
<seb128> dpkg: error processing xlibs (--configure):
<seb128>  subprocess post-installation script returned error exit status 1
<seb128> daniels: that breaks some of the GNOME builds too :p
* Amaranth remembers this
<daniels> seb	yah
<daniels> seb128: -42 uploading now to fix this
<seb128> cool
<seb128> maybe I can fix GNOME stuff before the WE :p
<Amaranth> is xbase-clients installable in -42?
<daniels> Amaranth: not tonight
<Amaranth> oh well
<Amaranth> not like i need it anyway
<daniels> just grab an older xbase-clients from the archive
<Amaranth> yeah, i have -36 still
<seb128> daniels: is current xorg known to be b0rked or works?
<Amaranth> you need xkeyboard-config, then current xorg should work
<seb128> daniels: I still have -33 installed here and don't intend to break my box 
<Amaranth> well, -42 should work
<daniels> seb128: everything but xbase-clients should work fine.  if xlibs won't install, run sudo rm -rf /etc/X11/xkb, install it, and hand-create the link to xkbcomp
<daniels> seb128: and yeah, need xkeyboard-config
<seb128> k, thanks
<daniels> unfortuantely because I'm thpethul, I badly screwed the xbase-clients thing
<daniels> it was meant to be a *lot* smoother
<seb128> xbase-clients not working as some bad effect?
<Kamion> it just won't upgrade
<seb128> k
<ogra> Kamion, i still get the usage message from baz with the above command
<daniels> right
<daniels> so if all the buildds had the old version installed in their chroots ... *cough*
<lifeless> ogra: what command ?
<ogra> (yes i added umask 022)
<Kamion> ogra: yeah, sorry I braino'ed it, one sec
<Kamion> ogra: umask 002, NOT 022
<daniels> this is why I should never do rushed uploads
<ogra> Kamion, yes 002, sorry typo
<Kamion> ok
<Amaranth> should xkeyboard-config be a part of xbase-clients?
<Kamion> ogra: baz make-archive --signed edubuntu-devel@lists.ubuntu.com sftp://chinstrap/home/warthogs/archives/edubuntu-devel@lists.ubuntu.com
<Kamion> lifeless: don't worry, my fault
<daniels> Amaranth: errr ... no
<daniels> Amaranth: arguably xlibs if anything, since that's where it used to be
<Kamion> lifeless: (though actually it'd be nice if it auto-guessed the archive name, like make-archive --help sort of implies it will)
<Amaranth> ah
<daniels> but xlibs can't depend xkeyboard-config, because xk-c pre-depends xlibs
<Amaranth> and xlibs is a dummy package
<Amaranth> d'oh
<daniels> (so the config files get removed if they haven't been customised)
<daniels> it'll get added to the seeds
<Amaranth> phew
<ogra> Kamion, do you have a hosts file with chinstrap in it? :)
<ogra> *g*
<Kamion> ogra: no of course not, .ssh/config is my friend
<ogra> ah
<daniels> the point of modularisation is to make life easier for everyone, not to assume that default users don't want or need xkb maps by default so there's no point in providing it :P
<Kamion> daniels: relying on the seeds is gross though, I want to come up with a better upgrade path at some point
<daniels> night guys
<daniels> Kamion: if you think of one, let me know
<daniels> Kamion: but we're doing shit like directory-to-file conffile migration
<Kamion> yeah, I know
<Kamion> Host chinstrap
<Kamion>         HostName chinstrap.ubuntu.com
<Kamion> ogra: ^--
<Amaranth> shit
<Amaranth> debconf in GNOME mode steals focus!
<daniels> Kamion: i need to play around with dpkg semantics to see if there's anything better I can do
<Kamion> patches welcome, none of the debconf maintainers are GNOME experts AFAIK
<ogra> Kamion, thanks... didnt know that one... i always used hosts
<daniels> Kamion: itmt, I'm just recommending it from xserver-xorg (as of -42)
<daniels> Kamion: so *hopefully* apt drags that in by default
<Kamion> ogra: ok, now 'baz branch ubuntu-devel@lists.ubuntu.com/seeds--breezy--0 edubuntu-devel@lists.ubuntu.com/seeds--breezy--0'
<Kamion> ogra: get the latter, and work there
<Kamion> daniels: aptitude will, apt won't
<Kamion> apt-get won't, rather
<infinity> daniels : apt ignores recommends by default, thank god.
<daniels> cock
<infinity> daniels : All other frontends will select it by default.
<daniels> infinity: both a bug and a feature at this point
<infinity> (dselect, aptitude, synaptic..)
<daniels> infinity: i assume getting a sensible versions of xbase-clients installed in the chroots is out of the question?
<infinity> Define "sensible?
<infinity> s/?/"/
<daniels> -34 or something
<lamont> daniels: and that would be wrong
<daniels> sensible -> installable
<infinity> Oh, "older".
<daniels> lamont: well, yeah
<daniels> lamont: but so is everything else about our buildds :P
<Amaranth> daniels: /etc/X11/xkb should be a symlink to /usr/bin/xkbcomp?
<infinity> Preseeding chroots only happens when something is so hideously broken we have a bootstrapping issue.
<daniels> Amaranth: yeah
<daniels> infinity: ok, sweet
<infinity> Can we not kjust fix xbase-client for now?
<daniels> infinity: we can, it just requires lots of time
<Amaranth> err, wasn't /etc/X11/xkb a dir before? :)
<daniels> Amaranth: oh, sorry
<daniels> Amaranth: /etc/X11/xkb/xkbcomp should be a symlink to /usr/bin/xkbcomp
<lamont> daniels: is xorg still building xbase-clients?
<daniels> infinity: put it this way -- if I do all the libs and programs, and *nothing* goes wrong, I could maybe have it done by the end of Tuesday (busy all weekend)
* lamont bets no
<infinity> daniels : Tuesday is fine for me.
<daniels> lamont: yes.  which is why it's so screwed.  because it's sort of empty.  and uninstallable to boot.
<infinity> daniels : It's not the end of the world if stuff is broken for a while, it's the end of the world if it's broken for weeks.
<seb128> lamont: can you kick vte, it should build again with new xft
<daniels> infinity: note the large number of conditionals
<lamont> seb128: given
<seb128> thanks
<infinity> daniels : Will an ULIIT make things better or worse?
<daniels> infinity: that you buy me? undoubtedly better.
<infinity> Consider it done, then.
<infinity> Immediately after xbase-clients works.
<infinity> :)
<seb128> daniels: is that ok if I upload xcursor for a rebuilt without Xrender.la ? 
* Amaranth beats xbase-clients
<daniels> anyway, now that I've figured out gcc4 generating broken code AGAIN is what's responsible for i810_drv making my video BIOS execute invalid code, I'm going to crash.
<Amaranth> it owns /etc/X11/xkb/compiled
<Amaranth> i thought xkeyboard-config was a part of xlibs before
<daniels> seb128: upload anything you need to fix stuff, I'm going to be out of touch all weekend
<seb128> k, thanks
<daniels> Amaranth: it was, but xkbcomp was a part of xbase-clients, I think
<daniels> infinity: make that 'on the friday night immediately after xbase-clients works'.
<daniels> the mid-week tgi's thing isn't working out.
<infinity> daniels : I'll get her number for you.
<infinity> And her address, if you feel the urge to serenade her from her bedroom window.
<\sh> jesus
<\sh> I got it 
<\sh> install xlibs-6.8.2-36, apt-pin it and start over with the upgrade...*phew*
<\sh> no nightmare anymore
<ogra> Kamion, wow, there has changed a lot since my first checkout on sunday...
<Kamion> ogra: seeds do change relatively often, although the diff against patch-71 is not huge
<ogra> Kamion, nope, not huge, but essential (keyboard config ... yaboot)
<mdeboer> Kamion: would it make sense to file a bug on the lack of documentation of the LiveCD generation? (i don't ask this to nag, it's a honest question)
<Kamion> ogra: yaboot in live is not particularly essential yet; I added it as a preparatory measure for ubuntu-express on powerpc
<Kamion> mdeboer: I guess, I thought there was probably one already though - but it's not my responsibility
<ogra> ah, ok, i thought the live bootprocess had changed
<mdeboer> Kamion: if there is, i have not been able to find it...
<Kamion> mdeboer: ok
<mdeboer> Kamion: anyway, i have given up.
* pitti waves to Ubuntu land
<mdeboer> Kamion: i won't have the time to get the 2.6.12-rt-preempt kernel working with the livecd.
<{Seb}> hi all
<{Seb}> is the Xorg problem we talkeld about yesterday fixed?
<{Seb}> i see Xorg is up to -41
<mdke> who works on java in Ubuntu?
<Treenaks> -42 even
<{Seb}> the actual available packages are only -41 though
<Lathiat> hrm, malone is broken, doh
<ogra> Kamion, thanks a lot for all the help, i owe you a bottle single malt now :) the seeds are up now....
<ogra> now on to the metapackages... :)
<Amaranth> i think vlc just need a sync from debian and a recompile
<Amaranth> since we have libwxgtk2.4c2
<ogra> Amaranth, i think we want to get 2.6 in before breezy releases...
<Amaranth> in that case vlc will need a couple patches
<Kamion> ogra: let me set up mirroring first, that'll help you there
<Amaranth> i think 2.6 is backword compatible so it should just be a fix in ./configure
<ogra> Kamion, ok....
<ogra> Kamion, anything special i have to regard with the metapackages ? 
<Kamion> copy the structure off kubuntu-meta
<Kamion> that should do basically the right things
<Kamion>  * schooltol
<Kamion> ogra: typo
<ogra> oki, i was looking a ubuntu-meta...
<ogra> ergh
<Amaranth> hmm, backports forum moved out of 3rd party projects
<Kamion> ubuntu-meta generates the minimal metapackage too which you don't want
<Amaranth> damnit, they're always first
<ogra> ok
<ogra> fixed
<ogra> Kamion, i need to add server to the seeds line in the update script ?
<Amaranth> It's kinda funny, in making the backports project official you've basically replaced the devs with a machine. :)
<Amaranth> Should give them more time for MOTU work, right ogra? :)
<bddebian> Heya
<ogra> Amaranth, thats mybig hope, that the backports team joins us
<wasabi__> xbase-clients fix around?
<Amaranth> wait for -42
<Amaranth> wait
<Amaranth> no
<Amaranth> xbase-clients is going to take about a week
<chrissturm> what is the last xbase-clients version that works?
<slomo> ogra: well it works partially ;) at least i'm trying to join you
* chrissturm runs -36
<wasabi__> Oh. I need an old version of it then.
<wasabi__> Where can I find such a thing?
<ogra> slomo, yes, thats heard to ignore :) 
<Amaranth> -36 is the latest
<ogra> hard even
<ogra> slomo, and a very good move ;)
<ogra> slomo, i'm really happy to have you aboard.... but i'm a bit sad jdong doesnt want to...
<wasabi__> Crud.
<wasabi__> I need an old version of X then.
<slomo> ogra: hmm... has he said why he doesn't want to?
<ogra> nope
<chrissturm> wasabi, i can email it to you
<wasabi__> Can you post it someplace? I am stuck at a console at work heh.
<chrissturm> ok
<wasabi__> I'd appreciate that.
<ogra> slomo, he just refused all attempts i made ...
<ogra> with no reason given...
<Amaranth> /usr/bin/ld: cannot find -ltheora_pic
* Amaranth stabs things
<Kamion> ogra: yes, and a suitable block in debian/control
<ogra> yep
<Amaranth> i have libtheora-dev, stupid vlc
<Kamion> ogra: will all Edubuntu server admins want all those server packages?
<Amaranth> *boggle*, it went passed that point this time
<Kamion> ogra: (noting that the DVD installer will just install the task, not the metapackage)
<ogra> Kamion, we build a single classrom release for ltsp currently...
<ogra> so yes... i guess so... but with the additional option for a workstation install as well...
<chrissturm> wasabi, http://i-understand.com/xbase-clients_6.8.2-36_i386.deb
<Kamion> ogra: anyhow, you've got http://people.ubuntu.com/~cjwatson/germinate-output/edubuntu-breezy/ now
<ogra> since we might have thick clients too...
<Kamion> ogra: and http://people.ubuntu.com/~cjwatson/seeds/edubuntu-breezy/, which you'll need for edubuntu-meta/update
<ogra> ok
<Amaranth> chrissturm: ugly
<ogra> the former is the CD build ?
<Amaranth> chrissturm: pin it
<Kamion> ogra: no the former is germinate output
<Kamion> does it look like a CD build? :-)
<ogra> which i thought is the base for the CDs ?
<Kamion> yes, it is
<ogra> ah, ok
<Kamion> although the CD build runs germinate itself, it doesn't use that run
<ogra> did you ever think about visualizing germinate trees as wllpapers ?
<chrissturm> Amaranth, i dont need to pin it because all later versions of xbase-clients wont install anyway because of missing deps. or am i missing something?
<Amaranth> Package: xbase-clients
<Amaranth> Pin: version 6.8.2-36
<Amaranth> Pin-Priority: 1001
<Kamion> ogra: only when drunk
<ogra> hehe
<Amaranth> it won't even ask you to install later versions, iirc
<Kamion> (because *I've* hacked on germinate ...)
<ogra> would be cool to have one :)
<Kamion> I value my sanity :)
<Kamion> germinate hacking => non-trivial
<ogra> i belive...
<ogra> i'm wondering if i want all these arches...
<Kamion> in what?
<ogra> edubuntu
<Kamion> you mean in the seeds?
<ogra> architectures = ['i386', 'amd64', 'powerpc', 'ia64', 'sparc', 'hppa'] 
<Kamion> if you leave the stuff there then it's easier for us to merge things
<ogra> the update script
<ogra> oki
<Kamion> oh, please leave them there, it's simpler
<ogra> i just doubt i'll find a hppa machine in a classroom.... :)
<Kamion> you should always go for maximum portability in packages themselves, and then just release what you want
<ogra> ut who knows where donations come from
<Kamion> ogra: so, ready for a test CD build?
<ogra> sure
<ogra> Kamion, JaneW will hug you a lot for it ;)
<JaneW> ogra: don't scare him away!
<ogra> heh
<Kamion> $ cron.edubuntu-daily
<Kamion> running
* JaneW gets all excited
<Kamion> obviously no magic server customisation yet or anything, nor is it a DVD build
* ogra can imagine worse things then being hugged by jane
* Amaranth gasms
<Amaranth> err, wait, it's just edubuntu
<JaneW> thanks ogra :)
* jsgotangco doesn't mind being hugged by JaneW
<JaneW> Amaranth what do you mean *just* edubuntu ;)
<JaneW> ok... group hug!
<ogra> Kamion, nope, i'm still pondering how to make my config changes... i'm not really a friend of cfengine ....
<ogra> yay
* Amaranth is looking into doing some work on edubuntu, so don't hurt me
* Amaranth hugs ogra 
<Amaranth> I HAVE A SHIELD!
<Kamion> ogra: for stuff like server metapackage installation, just tell me what you want
<Kamion> that lives in debian-cd
* JaneW puts pointy stick down and moves away from Amaranth's eye...
<ogra> Kamion, how do you solve it ? 
* Lathiat grins
<Kamion> ogra: d-i preseeding
<Amaranth> /usr/include/wx/menu.h:38: warning: inline function virtual wxMenuList::~wxMenuList() used but never defined
* Amaranth wonders how that can only be a warning
<Kamion> Amaranth: because the compiler doesn't know it's not just a missing prototype; only the linker can know that it's totally missing
<ogra> Kamion, ah... that works for all configs ? 
<Kamion> hmm, I forgot to do the standard Edubuntu preseeding
* ogra thought about proposing a update-alternatives system to debian... not sure if its a silly idea...
<Kamion> ogra: all configs? EPARSE?
* Amaranth hates C
<Amaranth> and C++
<Amaranth> great, gnome-terminal crashed and took my build with it
<Lathiat> hahaha
<Lathiat> i love that
* highvoltage crosses fingers that you're not going to say you love c#
<Lathiat> use screen :)
<Lathiat> I LOVE C#
<ogra> Kamion, i need special configs for edubuntu
<Amaranth> Python
<Amaranth> C# is second
<Kamion> ogra: what kind of configs?
<ogra> Kamion, preinstalled ones
<Kamion> ogra: what kind of configs?
<Kamion> do you mean configuration files in /etc?
<ogra> Kamion, for the different servers i run
* highvoltage shakes head (for C#, not python)
<JaneW> highvoltage: what happened to 'going home' ? ;)
<highvoltage> JaneW: I just got home.
<ogra> Kamion, samba should offer a open directory for sharing networkwide etc
<Kamion> ogra: ok, none of that has anything to do with metapackage selection in the installer!
<ogra> i'll have to have a preconfigure proxy...
<highvoltage> JaneW: I'm never away from work though ;)
<Kamion> ogra: totally different layer and not something I'd be involved in
<JaneW> highvoltage, oic, so you can connect from home now? *impressed*
<ogra> Kamion, thats why i was astonished you could do it with preseeding
<Kamion> 15:58 < Kamion> ogra: for stuff like server metapackage installation, just tell me what you want
<highvoltage> JaneW: yes, I got my connection sorted out yesterday *yay*
<Kamion> metapackage installation, obviously installer territory
<ogra> Kamion, yes...
<JaneW> highvoltage, cool
<jsgotangco> brrr cold
<highvoltage> JaneW: http://www.wo.co.za/products.html - I got the package for 699
<JaneW> jsgotangco, me too
<ogra> Kamion, so what would you think about a config system similar to thealternatives system, i.e. having different configs in place for different tasks and setting the link to it for a usecase ?
<JaneW> highvoltage, nice, so you don't need a telkom line at all?
<Kamion> ogra: cfengine appears to be the standard for doing this sort of thing; beyond that I have no experience, sorry
<highvoltage> nope, i _don't_ have a telkom line at all :)
<ogra> Kamion, cfengine is crack... i want something better...
<ogra> that interates nicely with upgrades etc
<JaneW> highvoltage, why didn;t you get the R599 one? You gonna be there during o/h too?
<ogra> integrates even
<jsgotangco> wow is that cheap? (R400)
<highvoltage> jsgotangco: yes.
<highvoltage> very cheap. compared to telkom. very expensive, compared to anywhere else in the world.
<Kamion> ogra: in that case, as I say, I have no experience.
<ogra> yep
<jhaltom> where's mkfontdir supposed to be these days?
<ogra> Kamion, but you have experience in distro structures :)
<Amaranth> wow, 9 year olds can be MSCEs
* lamont grumbles...
<highvoltage> JaneW: i took the all day one, so that i can still upload/download while I'm at work at home.
<lamont> HTH did pkgstriptranslations wind up in the d-i daily build chroots?
<wasabi> heh. odd. mkfontdir is failing to run... and I can't even find it.
<JaneW> highvoltage, ok, makes sense
<highvoltage> Amaranth: MCSE's
<JaneW> Amaranth: yes, a shame to wadste a life - so young
<JaneW> waste even
<highvoltage> I wanted to do a MCSE when I was 17. thank goodness i was saved in time.
<jsgotangco> heh i did 2 MCP exams before though
<jsgotangco> till i saw the light
<jsgotangco> it came in handy though
<highvoltage> my friends with mcse's and c#, .net, etc can't get jobs, but those with just a little linux/opensource skills get good jobs quite easily.
<ogra> heh
<bddebian> highvoltage: And what planet are you from? :-)
<dredg> there are plenty of jobs out there. it's just that most of them are somewhat more specialist than they were in the 90's
<highvoltage> bddebian: I currently live on a strange planet, called Earth. Don't worry, it's mostly harmless.
<dredg> at least, that's what i've found in ireland anyway
<JaneW> highvoltage, LOL!
<jsgotangco> mostly harmless
<jsgotangco> hehe
<jsgotangco> thanks for all the fish
<bddebian> dredg: Amen to that.  And usually the so-called "specialists" don't know jack about their "specialty" :-)
<dredg> bddebian: i know
<jsgotangco> well some people just brain dump on exams
<bddebian> Of course I don't know jack about anything so... :-)
<JaneW>  know jack
<dredg> MCSE and friends are still useful from a HR POV
<dredg> but once you get past that it's ok
<bddebian> Aye.  "Looks good on the CV" ;-)
<highvoltage> dredg: i don't think it's like that everywhere, hey.
<wasabi> grrr. now X is missing "input driver named keyboard"
<highvoltage> in south africa, the average toilet cleaner gets more that the average person who only has an MCSE (except for those MCSE that are actually toilet cleaners, of course)
<dredg> highvoltage: of course it's not, just talking about here :)
<JaneW> highvoltage: for instance it wouldn;t look good on a .doc CV sent to Canonical for instance!
<ogra> wasabi, change to kbd in xorg.conf
<highvoltage> JaneW: exactly!
<JaneW> highvoltage, stop making me laugh!
<highvoltage> JaneW: sorry
<jsgotangco> plumbers earn big though
<dredg> JaneW: any jobs going? :)
<jsgotangco> (in some countries anyway)
<JaneW> dredg: no sorry
<dredg> google are taking too long with my application
<Amaranth> wasabi: s/keyboard/kbd/ in xorg.conf
<highvoltage> My grade 10 Afrikaans teacher threw me with a bible once because I made too much jokes in the class.
<wasabi> Odd. I did. Same error.
<highvoltage> she was real angry.
<Amaranth> wasabi: Not possible.
* JaneW laughs again at 'afrikaanerism'
<ogra> wasabi, nd you need the matching drivers installed... tere is no dependency on them afaik
<Amaranth> wasabi: Driver 'keyboard' changed to Driver 'kbd'?
<wasabi> Well... I did. Maybe it's using a different config is all I can think of.
<JaneW> highvoltage: you drove someone to throw a bible at you!? Hard core ;)
<wasabi> Yup. In the keyboard device. It says kbd very clearly.
<highvoltage> hehe
<jsgotangco> wow throwing a bible..
<Amaranth> oh yeah, and sudo apt-get install xserver-xorg-input-kbd xserver-xorg-input-mouse xserver-xorg-driver-*
<ogra> wasabi, xserver-xorg-input-kbd
<JaneW> 'Psycho Boy'
<wasabi> Oh that's odd. X started alone works.
<bddebian> You mean my MCSE, MS SQL, Windows, Office, etc experience isn't going to get me a job at Canonical? :-(
<wasabi> gdm however doesn't.
<Amaranth> o_O
<Amaranth> bddebian: It might get you a job at ev1. :)
<bddebian> Heh
<dredg> Amaranth: LOL
<highvoltage> brb
<bddebian> MS is my life unfortunately
<jsgotangco> MS for me is only for games now
<Amaranth> same here jsgotangco 
<jsgotangco> they seem to do good on that lately
<Amaranth> i only play one game on windows, otherwise i'm all ubuntu
<wasabi> could gdm be using a different config?
<Amaranth> and i hear a WINE guy is working on support for this game, so woo
<Amaranth> (continuum)
<JaneW> I have to go now, I have some non-cycber activities planned for tonight.
<jsgotangco> i did the cedega route for sometime but i just dropped it
<jsgotangco> non-cyber activities
<JaneW> ogra: lemme know how it goes 
<wasabi> Buh. gdm reinstall doesn't configure itself right.
<wasabi> missing /etc/X11/default-display-manager
<ogra> JaneW, yep
<JaneW> so long and thanks for all the seeds ;)
<ogra> :)
<JaneW> jsgotangco: i.e I will be interacting with *REAL* people shudder
<ogra> wasabi, purge it before ? 
<jsgotangco> lol
<Amaranth> i give up on vlc
<Amaranth> stupid X
<davyd> so, the rule of thumb for breezy on amd64
<davyd> don't reboot
<ogra> davyd, 
<ogra> ogra@honk:~ $ uname -a
<ogra> Linux honk 2.6.12-1-amd64-k8 #1 Fri Jun 17 11:53:15 BST 2005 x86_64 GNU/Linux
<ogra> ogra@honk:~ $ uptime
<ogra>  17:29:27 up 1 day, 21:23,  5 users,  load average: 0.17, 0.21, 0.13
<ogra> no problems here
<davyd> ogra: some things appear to be uninstallable
<davyd> which is a little concerning
<ogra> davyd, new install or hoary upgrade ?
<davyd> upgrade from a new hoary install
<ogra> hmm, here too... but i never dist-upgrade in a development system... i only upgrade and pick the left over stuff manually
* davyd discovers he can't check out a software module from work because of permissions
<Nermal> ooooh.. davyd
<davyd> so g77 is in main, but gfortran is in universe
<davyd> that hardly seems fair now, does it
<ogra> heh
<davyd> what's the gcc flag to compile a 32-bit binary?
<Kamion> -m32
<davyd> cheers
<Kamion> ogra: http://cdimage.ubuntu.com/edubuntu/daily/current/
<jp> wtf is cheers?
<Kamion> see a dictionary
<ogra> heh
<davyd> is it possible to link to a 32-bit .a file from a 64-bit binary?
<Kamion> I doubt it ...
<ogra> Kamion, that looks bad http://cdimage.ubuntu.com/edubuntu/daily/20050715/report.html
<davyd> yeah
<davyd> this is going to get messy, I may need to set up a chroot
<wasabi_> oh man, everything on my machine is nicely crashing now.
<wasabi_> epiphany too.
<Kamion> ogra: hah, I'll have a look
<davyd> because I have a lot of 32-bit libraries that I need to call into
<ogra> Kamion, :( # amd64:895 # i386:925 # powerpc:768
<davyd> I wonder how many of them I can rebuild for Opteron
<siretart> help!
<siretart> I'm trying to fix ghc6, which is uninstallable atm. it build depends on itself :/
<siretart> how to proceed?
<Kamion> ogra: haha, whoops, I screwed up debian-cd
<ogra> oh, phew :)
<Kamion> ogra: and for that matter I just noticed that I never adjusted Kubuntu for the base->minimal/standard split
<Kamion> no wonder it's not been working
<Kamion> but Riddell didn't nag me enough to notice, or apparently debug it himself ...
<ogra> yay for edubuntu then :)
<Kamion> "libc6 is missing" would have been enough of a hint :P
<wasabi_> Question.
<wasabi_> What is Ubuntu's stance on unique ways to bypass copyright?
<wasabi_> For instance, program A doesn't allow distirbution by anybody really... is it acceptable to have a wiki article describing how to get it, and promoting that wiki article?
<ogra> heh
<Kamion> depends on your jurisdiction I think
<wasabi_> I speak of Java.
<davyd> anyone have an idea what libguide is?
<Kamion> but consult a lawyer
<wasabi_> Well, I ask from the point of view of the guys running the Wiki.
<Kamion> I don't think Ubuntu/Canonical should be giving you legal advice here
<wasabi_> It's Canonical's wiki.
<Kamion> Heh, in that case Canonical probably ought to consult a lawyer. :-)
<wasabi_> Take this current circumstance... Sun's Java. Bunch of guys, who are not realted to Canonical, package up Sun's JDK.
<wasabi_> And distribute. Which is technically illegal to do.
<jsgotangco> you mean backports
<wasabi_> Yes.
<wasabi_> Exactly.
<wasabi_> https://wiki.ubuntu.com/Java
<jsgotangco> i've read the wiki entry
<wasabi_> I'm just curious about that.
<Kamion> I don't know who's liable for information published on a wiki.
<wasabi_> Is there an official Canonical stance?
<wasabi_> Personally I don't like it.
<Kamion> One could argue that the wiki is basically just being a common carrier, but it might well depend on the judge ... the Wikimedia Foundation might know more.
<jsgotangco> yeah we've discussed that during the docteam meeting as well regarding stuff in theUbuntu wiki
<wasabi_> I don't want to promote it. There are other legal ways to get the software on your machine.
<jsgotangco> we decided to raise it on CC
<Kamion> I haven't heard of an official Canonical stance on this, largely because everybody runs away screaming
<wasabi_> Hah.
<Lathiat> so..
<Kamion> we were very careful not to get into the issue when we released warty, but many of the people who got involved chose not to respect that decision
<Lathiat> can we get libaa synced in yet
<jsgotangco> the issue really is questionable content on official servers
<Lathiat> aalib was transition to libaa
<Kamion> if we deleted that stuff, it would just get added straight back again
<Lathiat> and all the sdl stuff is broken till we get libaa and fix sdl
<wasabi_> jsgotangco, well, I wouldn't say in some jurisidictions linking to questionable content is pretty much cut and dry
<wasabi_> take that recent .au case.
<Kamion> jsgotangco: the CC doesn't consist of lawyers, either
<Riddell> Kamion: I havn't noticed the base->minimal/standard split before.  what needs to be adjusted?
<Kamion> Riddell: it's done
<wasabi_> But regardless, in this specific case, is it something we can come down on? The software is available legally.
<wasabi_> It's just not available legally from backports.
<wasabi_> Have to go to Sun's website to get it.
<Kamion> Riddell: you didn't notice that the Kubuntu CDs didn't contain any of the base system?
<Riddell> Kamion: well I noticed they didn't work at all
<Kamion> right, but I need you guys to help me debug this sort of thing
<Kamion> I cannot manage CD builds for three distributions by myself with no help
<siretart> may I file a bug for ghc6 in bugzilla? I don't think that we MOTU's can handle this issue on our own :(
<Kamion> so when they don't work, please try to find out why :-)
<Riddell> Kamion: will do.  so tomorrow's should work in theory?
<Kamion> Riddell: it'll have this particular bug fixed, but beyond that I don't know
<Riddell> or maybe they won't if X still has issues
<Kamion> Riddell: I've just kicked off a new build
<Riddell> Kamion: cool, I'll give that a go then
<Kamion> should be ~50mins
<Riddell> Kamion: is the base split documented somewhere?  it's not on SeedManagement
<ogra> Riddell, you could just compare the seeds
<ogra> (guessing you have a locl branch without the split)
<ogra> local even
<Riddell> don't think I do
<eruin> any plans to add something like this in ubuntu?  ( http://www.math.vt.edu/people/jbwillia/calendar.jpg ) - note the evolution tasks, which I gather is a fedora-specific patch
<jsgotangco> good night!
<Kamion> Riddell: http://udu.wiki.ubuntu.com/PackageSelection
<Kamion> though I think that says base and standard, not minimal and standard
<Kamion> Riddell: I've updated SeedManagement
<Kamion> somewhat, anyway
<Riddell> Kamion: thanks
<Riddell> ogra: seen http://italc.sourceforge.net/home.php ?
<comadreja> where's xmodmap now ?
<dredg> xmodmap is so X 3.3 :)
<comadreja> I had xmodmap until last upgrade to -41
<cartman> anyone knows why latest X.org is not built for amd64? Same q. for xvinfo which xbase-clients depend on
<eruin> gnome complained about xorg/gnome keyboard mismatch ;D
<carstenh> jbailey: ping
<seb128> lamont: please kick gnome-control-center too
<davyd> how hard is it to build a 32bit library and shove it into /lib32 etc (as appropriate)
<davyd> is there a nice howto for this?
<Kamion> Riddell: new Kubuntu daily CD build up, contains libc6 now ;-)
* Kamion rebuilds Edubuntu
<herzi> the ubuntu installation freezes when creating the ext3 partition on a sata drive (always at the 5% step) with a sempron machine, any hints how i can find out why?
<eruin> is xbase-clients going to be dropped?
<cartman> eruin: why?
<Kamion> no
<eruin> just wondering ;)
<eruin> this modularization stuff has my head in a horrible spin
<cartman> eruin: it depends on xvinfo so its borked on amd64 now
<cartman> in case you use amd64
<Riddell> is there a way to subscribe to all pages in the wiki?
<eruin> I was thinking more of its conflict with xkeyboard-config
<eruin> no doubt daniels is working way too hard on fixing it
<Kamion> eruin: modularisation means that individual packages can be fixed without everyone having to download an enormous 50MB blob
<cartman> Riddell: use rss feed maybe
<ivoks> i think daniels would appriciate some peace these days :)
<eruin> yeah ;)
<eruin> he's been in this x mess for well over a month now hasn't he?
<cartman> no way without fixing amd64 :P
<Kamion> actually, let's call that more like 200MB, since that's the mirror hit of xfree86
<eruin> poor lad
<ivoks> hard job
<Kamion> cartman: it's not daniels' fault; the amd64 buildds are down
<cartman> Kamion: oh why? :(
<Kamion> cartman: uh, dunno, last I heard they just weren't responding to stimuli
<cartman> Kamion: :(
<Kamion> probably needs somebody to reboot them, but the relevant people are in Finland
<cartman> :/
<cartman> Debconf5 ?
<Kamion> yes
<cartman> I see :/
<eruin> where are the buildds at?
<Kamion> datacentre in London
<eruin> I'm going there soon
<eruin> I'll do it! :P
* Kamion somehow doubts they'd let you in
<eruin> you didn't calculate in my amazing charms ;>
<Kamion> "hi, I'd like to reboot some servers" "who are you?" "oh, just this guy"
<eruin> haha
<ivoks> "what guy?" "you know, the guy..."
<ivoks> "piss of kid"
<eruin> the reboot guy
<cartman> the guy with the amd64
<cartman> :P
<eruin> I think they
<eruin> 'd rather say something along the lines of sod off
<ivoks> ah right, london :)
<jbailey> carstenh: pong!
<dilinger> "listen, this guy on IRC told me he needed a server rebooted.."
<jbailey> dilinger: Sure, just give me the root password. =)
<carstenh> jbailey: hi, did you find out who the mentor of GraphicalConfigTools is?
<jbailey> carstenh: No, I'll ping Jane again.
<herve> hey jbailey!
<carstenh> jbailey: ok, thanks
<jbailey> Heya Herv
<jbailey> Gah, one of thes edays I need to figure out why opening a new windows in evo to send an email brings my system to its knees.
<Amaranth> Solution: Don't use evolution.
<Amaranth> *cough*
<jbailey> Amaranth: I have to support it, so it's better if I use it.
<eruin> http://www.math.vt.edu/people/jbwillia/calendar.jpg
<eruin> anyone see that?
<Amaranth> what is that?
<eruin> is that a fedora-specific thing or hidden inside ubuntu?
<eruin> the evolution tasks in the calendar
<Amaranth> that's e-d-s
<jbailey> eruin: The calendar?
<jbailey> It works in Ubuntu
<eruin> hmm
<eruin> not by default?
<ogra> eruin, sure...
<eruin> hm
<eruin> I wonder why my tasks dont show
<Amaranth> you made a task in evolution for today?
<eruin> ohhh
* eruin bangs head on laptop
* Amaranth giggles
<Amaranth> i was wowed when i first found that
<Amaranth> until i realized i used tomboy to make a todo list instead of evolution
<eruin> haah
<eruin> the backend for that thing should really be more generic, so as to allow apps like tomboy to add/control it
<eruin> evolution is a bit over-the-hill for most people
<ogra> eruin, thats planned, thats exactly what e-d-s was written for
<eruin> I obviously need to educate myself more
<JanC> wasabi : I think in almost all countries you're safe if you remove "illegal" stuff from a wiki when you are asked to do so by the copyright holder
<JanC> and sun would be really stupid to ask that in this case...
<JanC> "stupid" being an euphemism
<Kamion> Amaranth: so gtk_window_set_focus_on_map (window, FALSE) is the right way to avoid debconf's GNOME frontend stealing focus, isn't it?
<davyd> oh man, packaging libraries for /lib32 is hard work
<jbailey> carstenh: I've emailed her, since she's not online.
<Amaranth> Kamion: Not sure.
<carstenh> jbailey: thanks
<Amaranth> Kamion: I thought it was a WM hint.
<carstenh> jbailey: i just startet system-config-services in a fedora-chroot... should we support different configurations in different runlevels?
<jbailey> Hmm, good question.
<Amaranth> Kamion: #gnome-hackers says it should Just Work
<Riddell> how do I rsync daily CDs?  can't find the URL
<jbailey> carstenh: Y'know, that sounds like a royal pain in the butt to support.
<jbailey> carstenh: I think we should probably just either start the firewall or not.
* jbailey wonders how often people change runlevels for anything other than system recovery or system backup
<carstenh> jbailey: sure, services is the last thing to do, but we should talk about it earlier
<Amaranth> system-config-services? hehe
<Amaranth> i tried to port that once
<Amaranth> do we even need it? we have the GNOME one and BUM
<Kamion> Amaranth: http://mail.gnome.org/archives/desktop-devel-list/2004-December/msg00306.html implies I need to set_focus_on_map(), I think
<lamont> seb128: kicked
<Kamion> Riddell: rsync://cdimage.ubuntu.com/cdimage/kubuntu/daily/current/breezy-install-i386.iso
<lamont> daniels: is -42 happy then, or is it still b0rked?
<Amaranth> Kamion: yep, that's it
<Riddell> Kamion: thanks
<Amaranth> lamont: xbase-clients will take about a week, from the sound of it
<Amaranth> if you pin it to 6.8.2-36 you should be ok though
<lamont> Amaranth: my question was more whether I should expect to see -43 today or not... :)
<Amaranth> ah
<carstenh> Amaranth: currently two summer of code projects are planing to implement something like this...
<Amaranth> daniels passed out a long time ago
<comadreja> Amaranth : where can I get xbase-clients 6.8.2-36 ?
<Amaranth> comadreja: apt pinning
<comadreja> my x are screwed
<Amaranth> man apt_preferences
<comadreja> yep
<Amaranth> what is wrong with your X?
<comadreja> the keyboard
<comadreja> I lost xmodmap, and the mapping doesn-t work anymore
<comadreja> it was on xbase-clients, but it's not anymore
<lamont> carstenh: implement what?
<Amaranth> you symlinked /usr/bin/xkbcomp to /etc/X11/xkb/xkbcomp and installed xkeyboard-config?
<carstenh> lamont: something like system-config-services for ubuntu
<lamont> ah, ok
<Amaranth> that can't be the only thing on your list
<Amaranth> that should only take a week or so to port, you have to have something else
<carstenh> Amaranth: no, it is only a part in both projects
* davyd needs to build a 32-bit version of libgfortran
<comadreja> let me check
<Kamion> bah, I need a new libgtk2-perl for this
<comadreja> Amaranth : I have no /etc/X11/xkb/xkbcomp
<Amaranth> comadreja: exactly
<comadreja> neither /usr/bin/xkbcomp 
<Amaranth> ...
<Amaranth> wtf
<comadreja> yes
<Amaranth> you installed xkeyboard-config?
<comadreja> yep
<Amaranth> do you have apt-file?
<comadreja> nopes
<Amaranth> use apt-file to see what package supposedly has xkbcomp
<Amaranth> get it, set it up, and search for xkbcomp
<comadreja> ok
<comadreja> Amaranth : xbase-clients
<Amaranth> you have xbase-clients -36?
<comadreja> nopes, i have -42
<Amaranth> ...
<Amaranth> i told you to pin -36
<comadreja> too late :(
<comadreja> I already had it
<Amaranth> no, pinning -36 will make it downgrade
<comadreja> Package: xbase-clients
<comadreja> crispin: version 6.8.2-36
<comadreja> Pin-Priority: 1001
<comadreja> I've got that
<Amaranth> yeah
<comadreja> no downgrade, though
<Amaranth> apt-get update and apt-get install xbase-clients
<Amaranth> the 1001 should force it to downgrade
<comadreja> Package xbase-clients is not available, but is referred to by another package.
<Amaranth> i haven't done this in a _long_ time though
<Amaranth> wtf
<Amaranth> ok, let's install it manually
<Amaranth> and _leave it at -36_
<JanC> probably -36 isn't in the archive anymore...
<comadreja> where can I download it ?
<comadreja> that's it
<Amaranth> damn
<Amaranth> -36 is only in for amd64
<Amaranth> since the amd64 buildds fell over
<Amaranth> someone posted a link to it in here
<Riddell> http://dev.kubuntu.org.uk/~jr/kubuntu/xbase-clients_6.8.2-32_i386.deb
<Amaranth> they had a copy
<Amaranth> woo, close enough
<Amaranth> ok, install that and change the pin to that version
<comadreja> conflict
<comadreja>  xcursorgen conflicts with xbase-clients (<< 6.8.2-35)
<Amaranth> ...
<Amaranth> *sigh*
<comadreja> I could force it...
<Amaranth> no
<Amaranth> http://i-understand.com/xbase-clients_6.8.2-36_i386.deb
<comadreja> cool :)
<Amaranth> fabbione's logs to the rescue!
<Riddell> http://dev.kubuntu.org.uk/~jr/kubuntu/xbase-clients_6.8.2-36_i386.deb
<comadreja> awesom
<crimsun> Kamion: please sync wxwindows2.4 from Sid
<comadreja> but the keyboard is still broken
<comadreja> I made the link
<Amaranth> kick back and wait for daniels to wake up, i guess
<comadreja> but at least I have xmodmap
<comadreja> yes, no problem with this :)
<Amaranth> you installed xkeyboard-config?
<ogra> comadreja, there is also a post on -devel with a handfull of links ;)
<Amaranth> you might want to reinstall it
* lamont notes that he is still getting UNACCEPT's for -37.  kamion/elmo: fix that pls. kthxbye
<Amaranth> i seem to remember it conflicting with xbase-clients
<lamont> ah, just on powerpc...
<lamont> I bet it didn't finish building there yet or something,
<Amaranth> yeah, powerpc accepted it and we were all happy
<Amaranth> then it unaccepted and we cried
<comadreja> ogra: thanks, I'll check it
<Amaranth> then nothing built until -41, whee
<Kamion> crimsun: I don't do syncs
<Kamion> crimsun: if you want approval of a sync, ask for it :)
<crimsun> Kamion: ah, only NEW?
<lamont> crimsun: and only when it's trivial
<Kamion> sort of general backup stuff
<crimsun> sorry, not current with policy
<Kamion> bah, why is wxwindows2.4 a native package anyway?
<ogra> crimsun, what about 2.6 ? 
<Kamion> ogra: Edubuntu CD builds updated; rather healthier now
<crimsun> ogra: Debian maintainer is waiting for cvs to stabilise
<ogra> Kamion, thanks a lot :)
<chrissturm> hmm, is 2,6.1 not stable_
<highvoltage> edubuntu CD builds? are they downloadable anywhere?
<ogra> crimsun, i thought i heard seb128 mention its in now ...
<Amaranth> it's in experimental
<Amaranth> i built it today
<ogra> highvoltage, yes but unlikely to work with the current X suituation
<Kamion> crimsun: does it not need to be merged? there are Ubuntu changes
<seth_k> does the -42 X fix the issues of yesterday?
<ogra> highvoltage, i'll annouce ste start of the autobuilds in edubutu-devel soon
<Amaranth> seth_k: stick with -36
<ogra> s/ste/the/
<Kamion> crimsun: in any case, the last Debian version is from before upstream version freeze, so you don't need approval - if it doesn't need a merge, talk to elmo when he's around, or send him mail
<highvoltage> ogra: ok. cool.
<seth_k> Amaranth: word
<Amaranth> seth_k: it's going to be the only version to work for the next week or so
<ogra> highvoltage, with the appropriate warnings :)
<highvoltage> hehe, of course.
<seth_k> Amaranth: thank you for the info, 36 it is
<comadreja> I get this when trying to install xkeyboard-config
<comadreja>  trying to overwrite `/etc/X11/xkb/compiled', which is also in package xbase-clients
<Amaranth> exactly
<Amaranth> force it
<crimsun> Kamion: all right, thanks
<highvoltage> ogra, do you have lots of bandwidth where you are, to download a ~680MB file?
* lamont -> office
<ogra> highvoltage, i have a flatrate but only a 768k line
<Kamion> lamont-away: UNACCEPTs> if elmo can't do it right now, get him to tell me what to do please ...
<davyd> so... can I request that libgfortran be added to ia32 libs?
<highvoltage> <gasp> only!?
<lamont-away> Kamion: actually, looks like -42/ppc made it in finally, so they're really gone.
<lamont-away> Kamion: and I think it's as simple/trivial as nuking the offending package from Accepted.  but that's just a guess.
<lamont-away> anyway, --> office
<ajf> anyone have a PPC deb of -36?
<ajf> :D
<Amaranth> we did about 5 minutes ago
<comadreja> Amaranth : do I have to pin xlibs and xlibs-data too ?
<Amaranth> see if you can find it on a mirror
<Amaranth> xlibs is a dummy package
<comadreja> xlibs-data ?
<ogra> highvoltage, 1M is the common minimum here, i just live to far away from the next headend, so i pay 1M but only get 768k 
<Amaranth> dunno about xlibs-data
<Amaranth> i don't think you have to worry about anything other than xbase-clients
<comadreja> trying...
<comadreja> rmdir: `/etc/X11/xkb/geometry': Directory not empty
<comadreja> dpkg: error processing xlibs (--configure):
<Amaranth> you know, if something breaks the only option is reinstalling or waiting
<Amaranth> since -36 isn't on the archives
<comadreja> yes, now I've got it on the hd
<Amaranth> sure, that one package
<highvoltage> ogra: i just got a 128k connection, and I've got a faster connection than any of my friends.
<Amaranth> no one has a mirror of the rest of the -36 packages
* highvoltage mutters... damn evel telcom monopoly...
<ogra> highvoltage, yep
<Amaranth> so if you break something you're sol
<comadreja> Amaranth : thanks a million for your help :)
<ogra> highvoltage, its over here in germany, i think its only a matter of time for SA
<jp> who knows what dbus-sharp version requires muine from cvs?
<highvoltage> yes, that's what they say.
<ogra> jp, tseng
<jp> ogra ;) ok :)
* Amaranth goes to bed
<ivoks> night
<highvoltage> gnight
<Kamion> Amaranth: morgue.ubuntu.com
<comadreja> what's the position regarding the libXrender.la file ? should it be included or not ?
<Riddell> comadreja: no, other .la files are yet to be updated to stop referencing libXrender.la though
<comadreja> damn, another transition :)
* davyd wonders if it'll be easier to just steal the libraries he wants from a 32-bit machine
* seth_k waits for codeslaves to rebuild all the libraries that depend on libXrender.la
<seth_k> work, codeslaves, work
<hughsie> mjg59: ping?
<mjg59> hughsie: Hi
<mjg59> Only here briefly
<hughsie> cool, no problem.
<hughsie> have you had a chance to speak to ogra?
<mjg59> Not really - I'm at Debconf at the moment
<hughsie> ahh, forgot, sorry
<hughsie> going well?
<mjg59> Pretty good, yup
<Simira> ah
<mjg59> I've just ported vbetool to use x86emu on non-x86 platforms
<hughsie> and power stuff going on? :)
<mjg59> So amd64 support ought to be improved now
<hughsie> mjg59: cool
<hughsie> mjg59, honestly, what you make of gnome power manager. be blunt
* davyd decides that a chroot is the only way he's going to get a sane compile environment
<mjg59> hughsie: From the looks of it, it's coming together really well
<davyd> just until I can recompile my dependancies for amd64
<hughsie> mjg59, with the HAL backend?
<mjg59> Yeah
<hughsie> What about pmscripts? suitable for ubuntu?
<mjg59> Not sure yet
<mjg59> I honestly haven't had a chance to look - I've just moved house
<hughsie> i'm guessing you could hack them around better than kI ever could
<hughsie> mjg59, i know what you mean, me too a few weeks ago
<hughsie> hell, on earth
<mjg59> We'll probably just end up integrating the scripts we currently have
<davyd> damned crack scripts
<hughsie> mjg59, thats what i wanted really
<hughsie> the distros to do what they wanted, and just use g-p-m as the front end
<mjg59> Yeah
<mjg59> Anyway, I need to head out now
<hughsie> cool.
<hughsie> mjg59, enyoy the conf.
<mjg59> I'll be hacking on this in the next week or so, so look forward to bug reports :)
<hughsie> mjg59, nice one!
<mjg59> Bye
<hughsie> i love patches
<hughsie> bye
* davyd thinks he should go to bed about now
<hughsie> davyd, you say that every day!
<davyd> hughsie: I'm up a lot later then usual
<davyd> been playing with building some software on amd64
<hughsie> not got that luxury :-(
<davyd> but it's too hard to recompile my libraries to 64-bit
<davyd> and I don't have a good enough compiler
<hughsie> i'll stick with my i386 old pc's
<davyd> this is a new work PC they've given me
<hughsie> davyd: yum install ? (joke!)
<hughsie> davyd, with my new laptop, i figured 64 bit wasn;t worth the extra hassle
<davyd> I have 64 bit versions of the maths library
<davyd> but only a 32 bit version of the Intel Fortran compiler
<hughsie> davyd, make much difference?
<davyd> hughsie: apparently
<davyd> gfortran is not fantastic
<hughsie> lol, i could have guessed that!
<davyd> at some point it's going to be my job to autotools up a whole lot of our random libraries
<davyd> ideally make them less 70s UNIX
<davyd> there are UNIX admins in my company who appear to have missed the 80s and 90s
<davyd> programmers too
<hughsie> lol, i do not envy you one little bit!
<hughsie> autotools, ... hummmm... not that nice fuzzy feeling
<davyd> I'm getting ok at it
<davyd> I managed to rewrite the macros for the app I'm working on
<hughsie> cool.
<davyd> but it has too many hard coded paths for my liking
<hughsie> on phone, sorry
<hughsie> davyd, g2g, catch you later
<davyd> later
<Burgundavia> jdub, ping
<jp> he's in japan
<Burgundavia> ah
<Burgundavia> bugger
<aurax> hay can anyone have access to #ubuntu's bans ?
<aurax> someone banned me ..
<aurax> with no reason .
<tritium> aurax, do you recall when/why?
<aurax> week and a half ago
<aurax> dunno why
<aurax> i got d/c and when i get back i was banned
<aurax> got*
<tritium> aurax, yes, I see it now
<thom> you may well have been bouncing
<aurax> i got many ip's
<aurax> <-dynami
<aurax> c
<tritium> aurax, let me talk to the person that banned you.  one moment
<aurax> ok
<aurax> thanks
<tritium> aurax, I reviewed the irc logs at the time you were banned.  It is my opinion that the op who banned you had justification.
<lamont> Kamion: you still around?
<Riddell> Kamion: the kubuntu install CD says No Kernal Modules Were Found
<Kamion> lamont: about to go shuffle from house to house again, but say it and I'll read scrollback
<\sh> does anybody have a xutils 6.8.2-36 package with mkfontdir inside? 
<ajf> \sh: ditto, heh :D
<ajf> I <3 breezy
<ajf> also, apt-file doesn't depend on curl, and it should
<tseng> bugs go to bugzilla/malone please
<Kamion> Riddell: hmm, I think we need to do some seed merging
* lamont wonders if he caught Kamion in the private window before he ran off, or if he gets to wait...
<Kamion> Riddell: I'll take a look in a bit
<Riddell> \sh: http://dev.kubuntu.org.uk/~jr/tmp/xutils_6.8.2-34_i386.deb
<\sh> riddell: i love u honey :)
<Kamion> Riddell: yep, requires a merge of the 2.6.12-2 -> 2.6.12-3 installer seed change - I'll fix in a bit
<Kamion> Riddell: thanks
<Riddell> Kamion: if seed in kubuntu/edubuntu is always the same as in ubuntu could ./update not grab the current version from ubuntu?
<\sh> *grm*  bbl
<ajf> Riddell: you don't have one for powerpc, do you?
<Riddell> ajf: one what?
<Riddell> ajf: no xutils for powerpc I'm afraid
* jortega is away: gone home for the weekend
#ubuntu-devel 2005-07-21
<pef> good night !
<jp> jdub, are you there?
<HiddenWolf> jp, the fashionable way to ask that around here is "ping?"
<HiddenWolf> the proper response being "pong"
<HiddenWolf> ;)
<robitaille> but variations have been known to occur on the ping/pong front
<jp> hahahha
<jp> ok HiddenWolf and robitaille :)
<Riddell> what's the services program jorge is blogging about here? http://www.whiprush.org/2005/07/services.html
<tiglionabbit> when I try to print something from firefox, it omits most of the text on the page.  I can print properly from other programs like OpenOffice.  What could be configured wrong?
<JanC> Riddell : it's in GNOME in System --> Administration (or something like that, my locale is in Dutch)
<tiglionabbit> could someone help me?  I can find no information on this problem..
<JanC> Riddell : services-admin
<Riddell> JanC: does it work on Ubuntu?
<Riddell> JanC: is there a package?  apt-cache doesn't know about it
<JanC> never changed anything with it   :)
<tiglionabbit> when I try to print a postcript file it says "Cannot execute print command:    ".  What is the print command I should configure it with?
<carstenh> Riddell: it is included in gnome-system-tools in breezy
<tiglionabbit> guys
<tiglionabbit> when I lpr a postscript file, it skips printing a lot of the text in it.  It's awful
<tiglionabbit> what's up with this?
<tiglionabbit> somebody help me, please
* mrd` never uses his printer. :/
<tiglionabbit> it wont print pdfs or postscript files or html files
<dos> hi guys, 13 july I downloaded the 13 july dialy iso and on the installation (blue iinstaller) I got: initnrd error, and today I downloaded 15 july iso and I got the same... :/ just saying that error...
<dos> :(
<dos> initrd
<dos> :/
<dos> I think I'll download the colony :)
<tiglionabbit> does anyone know how I can configure my printer properly?  It is ommitting large amounts of text from postscript and pdf files
<schweeb> sounds like you're using the raw driver
<tiglionabbit> what should I do to fix it?
<schweeb> you need to select a driver specific for your printer
<tiglionabbit> I did
<tiglionabbit> I have an HP Deskjet 920C.  I added my printer as exactly that
<schweeb> think you need  to install ghostscript or something
<schweeb> are you using cups?
<schweeb> btw, this is a #ubuntu question
<tiglionabbit> I think.  I tried to print using the "lps" command
<tiglionabbit> I'm not sure how it's set up, but it's Hoary Hedgehog and I haven't changed anything
<tiglionabbit> about the printer
<tiglionabbit> it doesn't print the text that should be on the sample page
<tiglionabbit> how do I install ghostscript?  I have gsfonts
<tiglionabbit> I've been in #ubuntu and haven't gotten any help
<tiglionabbit> I'm usually the one helping other peopel
<LinuxJones> tiglionabbit, have you run gnome-cups-manager ?
<carstenh_> tiglionabbit: do you know apt-cache? if not install gs :)
<tiglionabbit> what I have done is system -> admin -> printers, and added my printer
<tiglionabbit> er, printing
<LinuxJones> tiglionabbit, was your printer listed ?
<tiglionabbit> yes
<calc> whats going on between capplets and gnome-control-center?
<calc> is capplets deprecated now?
<tiglionabbit> Okay, I've removed the printer and added it again from detected, and it still misses the text.  And what gs package do you want me to install?  There are 8 packages that start with "gs"
<calc> hmm it seems gnome-control-center replaces capplets but hasn't been updated
<carstenh_> tiglionabbit: i did not read the complete discussion, but there are three  different flavors of the Ghostscript PostScript interpreter... (see apt-cache show gs-common). i don't know which is the best
<tiglionabbit> http://nickr.kicks-ass.net/~nick/badprint.jpg
<tiglionabbit> there's a pdf, looky, no text!  wtf
<lamont-away> mdz/elmo/kamion: anyone know if python-apt got updated to deal with tilde's?  could we get that into hoary-updates?
<lamont-away> kthx
* lamont-away -> movies
<davyd> has bad things happened in breezy re the syncing of version numbers for GNOME?
<jdub> davyd: ?
<davyd> jdub: it's trying to uninstall a lot of things
<davyd> because of version mismatches
* jdub updates mirror to see
<davyd> this is on amd64, so it could be specific to that
* davyd begins to master chroot building
<jdub> ah, more X
* davyd wonders how well bonobo activation plays inside a chroot
<mrd`> The X fixes that have been uploaded include fulfilling the dependencies for xbase-clients -42?
<infinity> mrd` : Not yet.  Wait until mid-week.
<infinity> davyd : amd64 is currently out of date, cause the buildds are down.
<davyd> infinity: aah, wonderful
<infinity> davyd : Should clear up in a few days, but then X will be broken for a bit. :)
<mrd`> Hm... in the mean time it's causing xkeyboard-config to conflict... is it safe to force xkeyboard-config to install?
<davyd> that would explain my world of pain
<davyd> I wish that had been mentioned before I dist-upgraded
<infinity> mrd` : Check the -devel mailing list.  There's lots of talk about this, including advice (and links) to install xbase-clients -36 to work around current breakage.
<mrd`> infinity: Hm, too late... I just --force-overwrite'd xkeyboard-config. :)
* mrd` restarts X and crosses his fingers.
<mrd`> Poo, swap-caps-lock still doesn't work. :/
* mrd` checks out the ubuntu-devel mailing list.
<bddebian> Poo? :-)
<mrd`> Yeah, poo.
<mrd`> I like having a usable control key. :)
<bddebian> Yes I could see where that would be useful. :-)
<mrd`> Yeah... every once in a while I find a use for the control key on the command line.
<mrd`> Oh well.  I'm l33t h4x0r that lives on the bleeding edge... this is what I deserve.
<bddebian> heh
<mrd`> ... oddly ctrl+alt+f1 now just results in 'P' being entered.
<bddebian> Nice feature 
<davyd> yeah, imagine when you break your P key
<mrd`> Thank God.
<bddebian> davyd: lol
<mrd`> Bah, I don't seem to be able to get a lowercase p though.
* mrd` considers a bug... 'C-M-S-F1 doesn't give lowercase p'
<daniels> 'vt switch key does not respect modifiers'
<bddebian> I was just gonna say that... haha
<mgalvin_away> hey guys, whats a good irc logging bot, er which do we use here?
<mrd`> daniels: Pfft, you and your technicalities.
<mrd`> At least 'sudo chvt 1' works.
<bddebian> mgalvin: I have used supybot in the past and liked it
<mgalvin> bddebian, thnx, i will give that one a try
<bddebian> NP
<mrd`> daniels: Are you already aware of this problem, or should I file with bugzilla?
<daniels> nope, but sounds cool.  bz, please
<mrd`> Alright.
<mrd`> File on package 'xorg'?
<daniels> file it on xlibs-data for the time being
<mrd`> Filed.
<seth_k> can somebody with editbugs mark #12568 as dupe of #8925 sometime, thanks
<seth_k> also how does one apply for editbugs; i've reported some and patched some... wouldn't use it a whole lot, but would be nice to mark the occasional dupe or invalid
<Mitario> mornin everyone
<Mitario> has anyone seen mdz lately?
<jdub> Mitario: he's at debconf
<Mitario> hmm, ok
* Mitario needs the new python-apt uploaded for the new update manager :/
<Mitario> (which I think should be in breezy)
<dilinger> Mitario: he was up a few hours ago, playing guitar
<dilinger> 's what i'm told, anyways
<Mitario> ah
<Mitario> well yeah i knew he was busy with debconf, but i was hoping for my e-mail to peak trough his work schedule :)
<Mitario> and since michael vogt is on vacation now :/
<Mitario> and upstream version freeze is in place..
<whiprush> seth_k: marked. see /topic on #ubuntu-bugs for the edit bugs thing.
<Mitario> when will debconf be over?
<davyd> what is messed up with xlibs-42?
<sivang> hi all
<\sh> morning
<pef> hi
<lamont-away> xorg_6.8.2-42_hppa.changes
* lamont-away ^5's daniels
<Lathiat> heh
<lamont-away> (it replaces -32, which was the last one that built
<siretart> any buildd admin available?
<lamont-away> siretart: sup?
<siretart> Can someone check http://people.ubuntu.com/~lamont/buildLogs/c/cpphs/0.7-2ubuntu1/
<\sh> hmm
<siretart> lamont: the package builds on my pbuilder, but not in sbuild. I think there is some manual intervention needed, but I'm not that sure about this
<siretart> it tries to install ghc6 (which is not installable), but has hugs as alternative (which is)
<lamont> those are totally whacked build-deps, but that shouldn't prevent it...
<siretart> the whole process is because of https://wiki.ubuntu.com/MOTUGhc6Transition
<lamont> ghc6 is in the archive, and listed first, so sbuild tries it.
<lamont> pbuilder does it in the reverse order.
<lamont> have we mentioned recently that or'ed build-deps are evil?
<siretart> ghc6 is broken
<lamont> right
<lamont> what
<lamont> what's broken about it?
<siretart> lamont: this is designed by the debian maintainer. should I change that?
<siretart> ghc6 is uninstallable because there is no libgmp3 anymore available
<lamont> well, in _theory_ the first package listed in the or-list is preferred.
<siretart> it was renamed to libgmp3c2
<lamont> is ghc6 buildable?
<siretart> it build depends on ghc6
<siretart> :/
<\sh> wow..my spamassasin is so good to me, it filters spam from debian-devel..clever
<siretart> so we try to work around this, sistpoty did create ghc6-bootstrap package
<lamont> that would be most cool
<siretart> but this needs other build dependencies, e.g. cpphs
<siretart> the status for this is on https://wiki.ubuntu.com/MOTUGhc6Transition
<lamont> and so it's really still circular
<siretart> cpphs builds with hugs!
<lamont> too late here for me to coherently think about working on it tonight.....
<siretart> oh
<lamont> if hugs would be preferable (and break the circle)... then an upload with hugs listed first would be a solution
<siretart> hugs is an alternative to ghc6, cpphs need either ghc6 or hugs, (ghc6 preffered, of course)
<lamont> and btw, the new charlie and the chocolate factory movie is sick.  Highly recommended
<\sh> and to early to get my X running again..
<siretart> lamont: ok, then I'll prepare a new transitional cpphs package. right?
<lamont> E: Package hugs has no installation candidate
<lamont> that's on {i386,ppc,ia64}, at least
<siretart> damn
<siretart> err
<lamont> worst case is to come up with a set of .debs and a sequence of builds that will produce success.  Provide me with those and I'll make it happen.  The ideal is to have it just happen in the archive/autobuilders.  but I fear we may need to re-bootstrap ghc6
<siretart> in my breezy chroot, there is hugs
<lamont> oh...
<lamont> my bad.
<lamont> probably just have main in the sources.list on those chroots.
<siretart> yes, this is universe stuff
<lamont> so an upload of cpphs listing hugs first might be all that is needed
<siretart> ok. on my way
<lamont> but if you do that, please _leave_ it that way for a good long time...
<lamont> that is, if you build cpphs with hugs, does it then Depend: hugs, or does ghc6 provide the same virtual package (if any Depend is present)???
<siretart> will check that, but I don't think so
<siretart> cpphs uploaded
<siretart> lamont: the idea is to get cpphs and haskell-utils built without any need of ghc6, which seems possible
<siretart> lamont: after that we try to build ghc6-bootstrap (a completly new package packaged by sistpoty), which can build ghc6 itself
<siretart> ok, it got accepted. now let's see what the autobuilders do ;)
<lamont> siretart: part of my desire here is that sparc and hppa just work when they finally get that far...
<siretart> lamont: I see. the way described on MOTUGhc6Transition should allow that. if you have any objections, feel free to give us cluebats ;)
<lamont> ok.  I'll try to remember to give it a read tomorrow...  of course, if I actually even knew what ghc6 was (other than in rough conceptual terms), I might actually care...
<lamont> care more.  I meant to say more. :-)
<siretart> :)
<\sh> lol
<siretart> ghc6 is the most grown up haskell implementation available
<lamont> right.  so if I knew anything about what haskell is......
<siretart> nearly everything which is written in haskell (darcs and whitspace to name prominent examples) build depend on ghc6
<siretart> :)
<siretart> ok
<siretart> gotta do more stuff here. *wave*
<lamont> enjoy
<Kamion> Riddell: the seeds aren't always the same between Ubuntu and Kubuntu/Edubuntu though - in particular the seeds looked at by the ./update script are almost certainly not the same
<Kamion> aargh
<Kamion> Riddell: 'chmod g+w /home/warthogs/archives/kubuntu-devel@lists.ubuntu.com/patch-*' on chinstrap please
<Kamion> then I can do this merge ...
<lamont> Riddell: and fix your umask, too. :-)
<nomeata> Hi. Is there a list of souces for Ubuntu's universe?
<daniels> http://archive.ubuntu.com/ubuntu/dists/breezy/universe/source/Sources.gz?
<nomeata> daniels: no, I'm looking for the origins of the packages. There is debian unstable, but supposedly, there are more
<jdub> tjere
<jdub> there aren't much more
<jdub> and the extras we have are in main
<jdub> if anywhere
<jdub> well
<jdub> that's not entirely true
<nomeata> so there are more :-)
<Kamion> there're a few bits in multiverse actually
<Kamion> but it's like marillat, apt-get.org, blah
<jdub> there are a bunch of other things in multi-- yeah
<nomeata> Kamion: only multiverse? So universe is a proper subset of debian unstable?
<bob2> no
<Kamion> making set-theoretic claims about a distribution is kind of tricky
<Kamion> there were some new packages introduced into universe by the universe maintainers
<nomeata> ok, I rephrase: For all package in universe, that have not originated from debian unstable, where do they come from.
<maswan> jdub: poked jbailey yet? :)
<nomeata> Ok, so it is either debian unstable, or manual upload by MOTU?
<Kamion> where do packages in unstable come from? (same answer.)
<jdub> maswan: yeah, i'll poke again :)
<maswan> jdub: ta
<nomeata> Kamion: well, unstable does not autmatically pull from anywhere. while universe seemts to (from unstable, in this case)
<Kamion> nomeata: I *think* that's true at the moment but I'd have to run a full comparison to be sure
<nomeata> Kamion: thanks. Is there a list of manually uplaoded packages, that are not in unstable?
<Kamion> no, not without essentially performing the set subtraction yourself
<Kamion> you could go look at the archives of the *-changes lists and get it that way
<jdub> would packages.ubuntu.com have something that could determine that?
<Kamion> oh, also anything with a version number matching *ubuntu* was manually uploaded
<Kamion> that's the mechanism by which we suppress auto-syncing
<jdub> though some of our packages don't have that
<nomeata> Kamion: ah, that's a nice tipp
<Kamion> jdub: right, some - I think that's mostly main rather than universe, though I haven't checked
<nomeata> this should do the job,right: lynx -source http://archive.ubuntu.com/ubuntu/dists/breezy/universe/source/Sources.gz|zcat|grep-dctrl -FVersion ubuntu -s Package
<Kamion> that'll get you most of them, but (a) isn't guaranteed to include everything, (b) will also include packages from unstable/whatever that we've modified
<nomeata> ok, thanks
<jdub> nomeata: that will only really tell you about packages with ubuntu changes
<nomeata> jdub: so not packages that are uploaded to ubuntu directly?
<Kamion> some of those too - many get *-0ubuntu1
<jdub> everything with ubuntu in the version number is uploaded directly
<jdub> but it doesn't guarantee they're exclusive to ubuntu at all, far from it
<jdub> it really means "changed by ubuntu", and i don't think we've made sure that *all* exclusive to ubuntu packages have it in their version number
<jdub> or even that there's any special origin or anything
<\sh> daniels: sorry to bug u, but any workaround for "fatal error: ca't find ffixed font" which I didn't try out already?
<\sh> daniels: ok..the last shot was correct...missing link to /usr/lib/X11/fonts/misc 
<cat> ):D
<\sh> thx to cat...I owe him some beer..
<cat> yeah i'm gonna go read a lil bit check you later \sh a pleasured to meet ya
<\sh> cat: thx for u r help...sometimes someone doesn't see the forrest with all those trees in front of it
<cat> true
<\sh> ok..switching to work mode ;)
<nomeata> ok, thanks guys. this command seems to give me packages missing in debian (run on debian): for package in  $(cat /tmp/Sources|grep-dctrl -FVersion ubuntu -s Package|cut -c10-); do apt-cache search --names-only $package |grep -q . || echo $package ; done
<lamont> g'night
<Riddell> Kamion: g+w done (and I'm sure I had my umask set...)
<TPC> I thougt this keyboard layout problem was supposed to be fixed, but after just updating my breezy test machine I get it again
<TPC> it defaults to us layoyut, and if I try to change to a Swedish one it crashes
<TPC> so now I can only type a to z the way I\m used to
<TPC> I am
<TPC> see, can t even shorten things like that
<TPC> just reporting that its broken again
<TPC> here is a screenshot of the error: http://www.tpwch.com/temp/error.png
<TPC> is there some better place to report this -questionmark-
<bob2> the bts...
* thom applauds seb128 loudly. new firefox maintainer!
<seb128> thom: roooh
<seb128> thom: no way! 
<thom> the new upload appears to work, fwiw
<seb128> I knew it, you do an upload for something and next day people point you as new maintainer :p
* dilinger .oO(sucker)
* mode/#ubuntu-devel [-o thom]  by thom
<seb128> thom: nice :) But some people start asking why we don't have 1.0.5 :/
* thom is getting good at dumping packages on unwilling victims ;-)
<thom> seb128: heh
<chrissturm> will gtk 2.7 land in breezy?
<seb128> when upstream state that GNOME 2.12 will use 2.8
<chrissturm> and thats not decided yet?
<seb128> they are not sure between 2.6 and 2.8 (though it seems that 2.8 will be fine)
<seb128> no
<seb128> you can use my people.ubuntu.com page to get i
<seb128> i386 packages
<chrissturm> cool
<tseng> seb128: fonts seem odd with 2.8
<seb128> tseng: no bug, no fix
<seb128> they are fine here ...
<seb128> what's wrong with your fonts?
<tseng> they are much larger than with 2.6
<tseng> at the same dpi
<seb128> they don't use the dpi setting
<seb128> that's a known issue
<tseng> figured as much.
<seb128> http://bugzilla.gnome.org/show_bug.cgi?id=305391
<tseng> rock.
<ogra> seb128, did you recognize that xscreensaver stops working as soon as you have gnome-screensaver installed ? even if xscreensaver runs, locking doesnt work for me... seems they clash soehow
<seb128> GNOME starts xscreensaver
<seb128> it needs a patch to use gnome-screensaver
<seb128> but killing xscreensaver before starting gnome-screensaver works fine here
<ogra> yep, but xscreensaver doesnt work anymore...
<thom> yeah, the hinting seems very different
<mdke> just out of interest, is anyone developing a grub configuration tool @gnome/ubuntu?
<seb128> ogra: maybe they should conflict yep
<seb128> mdke: gnome-system-tools has one, but it needs to be fixed to handle the autogenerated format for update-grub
<ogra> mdke, GraphicalConfigTools has a minimal one.... i didnt move it to breezy yet and am not sure if i find the time
<mdke> thanks
<mdke> so basically, help needed
<seb128> always welcome
<seb128> same as for patches :)
<ogra> mdke, not really, i have a bounty student who should care for it
<mdke> ah good
<seb128> ogra: fixing the gst one or reinventing the wheel ?
<ogra> and his ndiswrapper gui is ready soon, so he'll be out of order then :)
<mdke> eugh
<chrissturm> what about "boot manager settings" in breezy. isnt that some kind of grub config? :)
<ogra> seb128, fixing either of them
<mdke> grub > ndiswrapper ;)
<seb128> chrissturm: that's it
<chrissturm> whats the problem with it?
<ogra> mdke, but ndiswrapper was good for training pygtk skills... its a simple fileselector for the .inf file
<mdke> all good
<ogra> now he's ready for something bigger :)
<mdke> heh
<mdke> ogra has an apprentice
<ogra> seb128, i dont like the gst one, too many options to break your system....
<ogra> seb128, while in fact you only need two options to adjust... timeout and default OS
<ogra> (for grub)
<mdke> hmm
<ogra> mdke, ?
<mdke> my grub menu had two copies of everything after i installed a breezy partition. i would have used a graphical tool to remove the duplicates
<ogra> mdke, but you know what youre doing
<mdke> debateable
<mdke> but i know what you mean
<chrissturm> mdke, dont you have system/administration/boot ?
<ogra> mdke, imagine you remove the wrong one :)
<mdke> chrissturm, i'm on hoary so I haven't looked yet
<mdke> ogra, true
<chrissturm> ogra, just dont let him remove the one that he is currently running
<ogra> that was my main concern with bum.... thesaltydog wasnt to convince that he should supress the option to remove udev, else i would have promoted it for main inclusion
<mdke> ogra, i guess you could put in the ability to change colours and other such things in the grub config
<ogra> chrissturm, yes, good idea, but gst doesnt provide uch functionallity yet
<ogra> mdke, sure.... everything that doesnt break your system is fine
* mdke nods
<mdke> passwords, hiddenmenu, timeout, colour, default OS
<ogra> yep
<Keybuk> Kamion: ping?
<opi> smurfix: ping, are you there? :-)
<smurfix> opi: not really
<smurfix> anything important?
<opi> smurfix: not really, I just wanted to ask you for planet.ubuntu-pl.org IN A ;)
<opi> smurfix: but that's low pri, if you have something more important
<smurfix> opi: send email please
<opi> smurfix: I'll pas
<opi> smurfix: OK, have fun
<smurfix> opi: I'm going to take my hammock, two trees, and a few hours ;-)
<opi> smurfix: looks like hi priority task to me
<smurfix> opi: exactly ;-)
<opi> smurfix: throw a beer, too ;)
<opi> OK, off with me
* ogra looks up hammock....
<ogra> smurfix, have fun :)
<\sh> ogra: hammock? translate ,-) i'm too lazy right now ;)
<ogra> haengematte
<\sh> hmm....
<ogra> \sh, have you seen this ? http://www.ubuntu-de.org/viewtopic.php?t=3759&highlight=thunderbird
<\sh> ogra: I'm not in this forum business ;)
<ogra> "...the taskbar has a buttonbar to switch between 4 monitors in the lower right.... why do they include it? i only have one monitor..." *g*
<davyd> I think GNOME could really benefit from better documentation for some of these things
<\sh> well..yes...read on my german weblog...there is link...and that's really annoying to read for 2005
<ogra> "a very important folder is 'etc' , from the latin 'et cetera' thats the folder where programmers put all the stuff they dont know where to put durig development... thus you will also find some important files here..."
<davyd> where is that from?
<dilinger> i'd put $5 down on slashdot
<ogra> "the files from the CDROM are copied into the /dev/cdrom folder, dev stands for 'development' this shall show that the cdrom support in linux is still under development and not stable..."
<ogra> davyd, http://www.ubuntu-de.org/viewtopic.php?t=3759&highlight=thunderbird
<ogra> the german ubuntu forum... but quotes from a linux help site...http://linuxpraxis.li.funpic.de/
* davyd fires up his German skills
<ogra> "linux uses harddisks as virtual images but since you even cant access these as root directly you need a image manipulation program like the gimp to make them accessible..."
<jdub> ?!
<jdub> creative
<ogra> ^^ my favorite... :)
* sivang hopes that this is some kind of a joke :-)
<davyd> too many years of working in IT support taught me that all manner of things are awfully serious
<davyd> particularly to managing directors, who seem incapable of comprehending the fact that something malicious might be able to ask questions of him, that somehow aren't identified as that software
* tseng scribbles a moustache on his root filesystem
<tseng> much better.
<infinity> ogra : Please tell me this is a joke.
<\sh> tseng: wow...now the reiser looks like my xfs ,-)
<tseng> \sh: me? reiser? no thanks.
* davyd laughs ricerfs
<davyd> 1000% more elite then any competing filesystem
<davyd> incidently, my breezy installs are a little hosed, I hope I don't lose power before I can fix them up
* davyd twiddles his thumbs while he waits for new packages
<davyd> if this was Debian, our Sunday morning and Monday morning were always the best time for new code
<davyd> I've never noticed a trend with Ubuntu
<tseng> davyd: !weekend
<tseng> the canonical dudes burn most of the oil during the working week
<davyd> yeah, I live in fear that it's going to be Wednesday or Thursday before I feel I can reboot
<tseng> you cant reboot?
<davyd> there are currently things running in memory
<davyd> that the installed versions are a little fucked up
<\sh> davyd: if u speak about Xorg...I think with 1mio bucks for daniels...you will get Xorg working tomorrow ,-)
<davyd> \sh: I asked him if there was a Melbourne based mail order liquor store
<lsuactiafner> is there an app that reinitialises the display, like when you lose the console running x and going back to console brings the console up again...
<davyd> there would be a six pack from Mr James Squire heading his way
<bytee_> he's not in melbourne atm, i think
<davyd> man, he gets around... where is he?
<\sh> davyd: well...I got it running..after some hours 
<\sh> 34h now
<davyd> \sh: this is the xlibs uninstallableness?
<\sh> davyd: this is xlibs, xbase-clients, and font problems again..
<davyd> \sh: is it an easy fix once you know?
<\sh> install xlibs 6.8.2-36, and xbase-clients
<\sh> apt-pin xlibs to this version
<\sh> install the apps from utils
<\sh> xutils
<\sh> old version as well :)
<davyd> is there an ubuntu version of snapshot?
<Mez> davud - the screencaprture program ?
<\sh> then create a link from /usr/share/X11/fonts/misc to /usr/lib/X11/fonts/
<\sh> update your xorg.conf
<Mez> davyd *
<davyd> Mez: no, snapshot.debian.net
<\sh> change your fontsettings to match /usr/lib/X11/fonts/*
<\sh> and hopefully it starts without german keyboard ,-) 
<davyd> since I only installed this machine, I don't have older packages in my cache
<\sh> davyd: read ubuntu-devel...there is a mail with the links to old packages
<davyd> cheers
<Lathiat> http://morgue.ubuntu.com
<davyd> \sh: one of those is architecture dependant
<davyd> Lathiat: oh, nice
<Lathiat> :) handy
<Lathiat> im just waiting for daniels to unbreak it for me
<davyd> it appears to only go up to march
<bddebian> Hello
<Lathiat> seb128: know about file:/// urls nto working?
<seb128> "nautilus file:///usr" works here, just tried
<Lathiat> seb128: try gnome-open
<seb128> I guess "no" 
<seb128> gnome-open is not made for that
<Lathiat> well, places->blah doesnt work
<seb128> it works for me
<Lathiat> and gives the same error that doesnt for me anyway
<Lathiat> ok
<Lathiat> what woudl be good debugging info?
<seb128> try with an another user
<seb128> I would blame a gconf setting
<Lathiat> i get "There is no default action associated with thsi location"
<Lathiat> righto
* Lathiat tries
<seb128> have you set a "/desktop/gnome/url-handlers/file" or some such b0rker
<seb128> ?
<Lathiat> i dont have one
<Lathiat> and it doesnt exist in /etc/gconf/gconf.xml.defaults either
<Lathiat> so no
<Lathiat> bleh, xnest adn gdmflexiserver are broken
<Lathiat> broken with another user too
<wasabi> It can be considered a milestone when I actually start using Nautilus for everyday tasks, instead of popping open the terminal.
<seb128> Lathiat: good luck to debug, there is no such bug upstream or on the ubuntu bugzilla and that works fine for me
<Lathiat> seb128: right, hence my question, what woudl be good debugging info, as i have no idea
<Lathiat> wasabi: heh
<seb128> Lathiat: "gnomevfs-info file:///usr"?
<seb128> what is "MIME type"/"Default app"
<Lathiat> want th e toutput?
<Lathiat> ahh
<Lathiat> it is
<Lathiat> x-directory/normal, default ap... dont see one
<seb128> what distro do you use?
<Lathiat> ubuntu breezy...
<seb128> "dpkg -l libgnomevfs2-common" ?
<Lathiat> 2.11.3-0ubuntu1
<wasabi> gnomevfs-info doesn't show default app for me either.
<seb128> update to 2.11.4
<wasabi> heh
<seb128> it doesn't build probably if you guys don't have it :p
* seb128 goes to the build log
<Lathiat> broken X stuff might be holding back an update
* Lathiat looks
<Lathiat> yeh
<Lathiat> this broken X stuff is holding back the update
* Lathiat tries to fix
<seb128> no, it FTFBS http://people.ubuntu.com/~lamont/buildLogs/g/gnome-vfs2/2.11.4-0ubuntu1/
<Lathiat> ah
<seb128> Lathiat: grep directory /usr/share/applications/nautilus-folder-handler.desktop ?
<Lathiat> nothing
<seb128> that's the issue
<seb128> dpkg -S /usr/share/applications/nautilus-folder-handler.desktop ?
<Lathiat> nautilus
<seb128> grumpf
<seb128> you have edited this file?
<Lathiat> nope
<seb128> grep MimeType /usr/share/applications/nautilus-folder-handler.desktop
<Lathiat> MimeType=x-directory/gnome-default-handler;x-directory/normal;inode/directory
<Lathiat> i make a point of not editing systme config files
<seb128> hum
<seb128> so grep is b0rked
<seb128> it's not able to find "directory" on a line with several instance of the word
<seb128> interesting
<Lathiat> erm
<Lathiat> actually it works now
<Lathiat> maybe i mis-spelt it
<seb128> ?
<seb128> gnome-open works?
<seb128> or grep?
<Lathiat> grep
<seb128> do you use an i386?
<Lathiat> yes
<Lathiat> err no i spelt directory right
<Lathiat> but.. it shows up now
* Lathiat boggles
<Lathiat> oh
<Lathiat> whoah
<seb128> what?
<Lathiat> archer:/usr/share/applications> grep directory nautilus-folder-handler.desktop
<Lathiat> MimeType=x-directory/gnome-default-handler;x-directory/normal;inode/directory
<Lathiat> archer:/usr/share/applications> grep /usr/share/applications/directory nautilus-folder-handler.desktop
<Lathiat> zsh: 31443 exit 1     egrep /usr/share/applications/directory nautilus-folder-handler.desktop
<Lathiat> wtf is with that
<Lathiat> eh
<Lathiat> somethings screwing with my commands
<Lathiat> hrm
<seb128> grep /usr/share/applications/directory nautilus-folder-handler.desktop
<seb128> no
<Lathiat> yes i know
<Lathiat> nm that
<seb128> grep directoy <path>
<Lathiat> dunno how i did that twice
<Lathiat> ah
<Lathiat> X is reaking havoc on my keyboard
<seb128> wget http://people.ubuntu.com/~seb128/gnomevfs-info
<Lathiat> and randomly tab works, and randomly it prints a tab
<seb128> ./gnomevfs-info file:///usr
<seb128> and "Default app"?
<Lathiat> nautilus-folder-handler.desktop
<Lathiat> whoah wtf, now its working opening directorys
<Lathiat> this is screwed
<seb128> bong
<seb128> let's say we have fixed it :p
<Lathiat> uh
<Lathiat> yeh
<Lathiat> maybe something ran a postinst that hadnt ran before
<Lathiat> not that i can see anything
<Lathiat> thanks, sorry for the hassle
<seb128> np
<jsgotangco> good night
* lamont ponders how libnss-dev_1.7.6-1ubuntu2.1_i386.deb came to be
<lamont> doh
<lamont> _6_ not _8_
<lamont> nm
<Treenaks> lamont: i368?
<lamont> no. 1.7.6 not 1.7.8 (which is current)
<mjg59> I've written usplash
<jdub> mjg59: yay!
<jdub> mjg59: you crazy fucker!
<sladen> mjg59: dude you rock!
<mjg59> 169 lines of code
<jdub> surely you jest
<sivang> mjg59: is the laptops testing give away still on? ;-) (now that I catch you here)
<pef> libqt3c102-mt-mysql is replaced by libqt3-mt-mysql right ?
<Lathiat_> other way around
* robitaille crosses his fingers he will be one of the laptop testing crowd...
<sladen> jdub: splatter, fifo watcher and watchdog
<Riddell> how does someone get edit privilages on bugzilla?
<robitaille> Riddell:  ask mdz or ogra
<Riddell> there you go seth_k 
<seth_k> righto Riddell 
<\sh> pef: let me build libqt3 first :) i adjusted the build-deps...and if this is fine...i send riddell the diffs
<pef> \sh: ok, it's because I've found a package with this old dependency
<\sh> pef: put it on UnmetDeps
<Riddell> pef: yes, libqt3c102-mt-mysql is replaced by libqt3-mt-mysql
<bddebian> libqt3 is a PITA
<Riddell> bddebian: how so?
<bddebian> A lot of dependencies.  At least it was a PITA building on GNU/Hurd :-)
<Kamion> Riddell: ok, Kubuntu seeds fixed up
<pef> \sh: already in, but can I correct this then upload a new version ?
<Kamion> thanks
<schweeb> mjg59: any status on sata suspend?  i saw a patch on lkml, haven't yet had the time to try it yet
<\sh> pef: sure..w8 for new libqt3 ,-)
<mjg59> schweeb: It's not currently mergable
<pef> breezy-changes
<pef> breezy-changes
<pef> \sh: when you have done I will be announce on 
<pef> oups :)
<mjg59> It breaks other things
<mjg59> I'll be looking into that shortly
<schweeb> okay
<schweeb> need any help testing, I'm more than happy to... just ping me
<infinity> mjg59 : If you need a lab rat, I just got an SATA laptop.
<infinity> mjg59 : I'm also very good at performing repetitive tasks for very little reward.
<seth_k> food pellets?
<daniels> it's true.  i've made him run through mazes for no apparent reason before.  good entertainment.
<schweeb> infinity: lol
<schweeb> infinity: which laptop?
<schweeb> mine's an X41
<daniels> schweeb: some battletank
<infinity> schweeb : T43.
<schweeb> so, similar hardware
<schweeb> <3 IBM
<infinity> Quite likely, yes.
<\sh> my laptop is burning in this heat compiling qt
<highvolt1ge> before it's too late to play i've-got-a-thinkpad-too, i have a T42 :)
<tseng> Kamion: do you have to approve universe syncs?
<sivang> seb128: hey Seb, just before posting the source pkg somehwere so you can download, do configure.ac changes need go inside a debian/patch or is it ok to just have the source build include it?
<opi> smurfix: are you still busy? :)
<trygvebw> evening
<trygvebw> i see that the xorg fix has been uploaded, but i can't find anything in dist-upgrade. is there a special package i need to install?
<seth_k> I think that message is old
<seth_k> last version of Xorg that really works is -36
<seth_k> -42 is still death
<trygvebw> oh
<trygvebw> :(
<trygvebw> so is there anyway i could fix my xorg installation, or do i have to boot into my old hoary install? :p
<schweeb> do you have your packages in your apt archives?
<schweeb> /var/cache/apt/archives
<trygvebw> probably not :(
<schweeb> the older versions should still be inthere
<trygvebw> hm
<schweeb> unless you explicitly cleared them out
<trygvebw> what packages should i install?
<schweeb> or it's a new install
<trygvebw> from there?
<schweeb> you'll have to manually dpkg -i the older X packages from there
<schweeb> any more info than that, and you should probably ask in #ubuntu
<trygvebw> :(
<trygvebw> ok
<trygvebw> thanks for the help :] 
<lamont> hrmpf.
<lamont> no mdz.  no elmo.
<lamont> jdub!
<\sh> but qt built
<\sh> *dancetheqtdance*
<lamont> \sh: really?
<lamont> qt-x11-free is d-w libglu-dev-xorg (>=6.8.2-42) for me....
<lamont> Kamion: you about?
<\sh> lamot: ubuntu8 ;)
<\sh> not 7 anymore
<lamont> ah, woot
<highvolt1ge> when is debconf over?
<\sh> apt-get update fast...qt is hot and spicy now.tomorrow 
<highvolt1ge> mdz and elmo really need to come back.
<Nafallo> amd64 needs to come back ;-)
<\sh> hmm...I wonder if kdelibs4 builds now...
<lamont> Nafallo: that's dep-wait: elmo
<\sh> *laptopburningtime*
<Nafallo> lamont: I know. I'm not sure it's a bad thing they are down. I still got working X :-)
<lamont> hehe
* \sh should apply for kde main ,-)
<Nafallo> \sh++
<\sh> kicking kdelibs4 through the hell of the buildd ,-)
<\sh> riddell: dch -i and kick it please ,-)
<lamont> \sh: if it's ftbfs already, just have me kick it
<\sh> lamont: I think it was only because of qt...cause right now my pbuilder is saying: yes 
<\sh> lamont: i can't upload 
<\sh> give me 3 hours ,-)
<eruin> gnome-keyboard-properties crashes when I try to add a new keyboard layout... I guess this is due to X being broken... should I hold submitting a bug about it?
<lamont> actually, kdelibs is marked as "Installed"
<lamont> or does it need a rebuild to be installable?
<\sh> yes
<Gnobody> does x work in Breezy yet after a dist-upgrade?
<\sh> rebuild
<eruin> Gnobody, yes
<Amaranth> Gnobody: sort of
<\sh> well..strange
<Amaranth> Gnobody: did you get my PM?
<Gnobody> sort of?
<Gnobody> yes
<Amaranth> Gnobody: You need xbase-clients 6.8.2-36
<eruin> Gnobody, your keyboard might get toasted... some packages are still missing
<Amaranth> which you can't get from the archives anymore
<Gnobody> oh
<lamont> Amaranth: rooting around on morgue.ubuntu.com can be productive
<Amaranth> If I said I had a window 'with all the chrome turned on' to you guys, would you know what I meant?
<Amaranth> lamont: irc logs and the forums produce about 10 mirrors of it as well
<\sh> strange...
<Gnobody> Amaranth does "chrome" involve nude pictures of the girl from Lacuna Coil?
<Amaranth> no...
<Gnobody> damn
<Amaranth> and nude pictures of her don't exist
<eruin> Gnobody, down boy!
<Gnobody> are you sure
<Gnobody> ?
<Amaranth> yeah, pretty sure
<Gnobody> damn my life is screwed then
<\sh> looks like we need to rebuild kdelibs4 
* Gnobody pulls out revolve, clenches trigger
<highvoltage> Gnobody: I think if you're in ubuntu-devel you're not supposed to have much of a life to begin with ;)
<Gnobody> ;)
<Gnobody> Damn free software and it's lack of fun
<Gnobody> </sarcasm>
<highvoltage> Gnobody: free software is fun!
<Gnobody> yeah
<Gnobody> free software sex goes something like this: mount /dev/mounter /media/bush ; fsck ; unzip thestuff.zip ; fsck ; umount /media/bush ; slocate pants
<highvoltage> hehe
<Gnobody> in a root terminal of course
<highvoltage> no no no.
<Gnobody> ?
<highvoltage> never do that as root. you might end up with a std.
<Gnobody> lol
<Gnobody> you mean fu-ware
<highvoltage> of course.
<Gnobody> or a windows virus in wine
<highvoltage> you might be infected with software with an incompatible license.
<highvoltage> we don't want that.
<highvoltage> what will the children look like !?
<Gnobody> eww a bsd/gpl system
<Gnobody> what a bastard
<highvoltage> exactly.
<Gnobody> it would look like Darrel McBride
<highvoltage> or a Michael Jackson.
<highvoltage> or a Rosie O'Donnel
<highvoltage> or a Jerry Springer
<Gnobody> nah michael can't be as low as Darrel McBride
<Gnobody> and talkshow hosts
<highvoltage> ok then, Arnold Swarchenegger
<Gnobody> agreed
<Gnobody> eww republicans
<highvoltage> or Britney Spears. okay, she's republican too.
<Gnobody> really?  does she even know how to spell conservative?
<highvoltage> No, but she can spell B.M.W.
<highvoltage> first post, btw
<Gnobody> she thought Canada was an "over-seas country"
<schweeb> pretty sure politics is way off topic
<Gnobody> Oh come on there are know republicans in free software
<schweeb> ...
<schweeb> I would suggest ending it at that.
<Burgundavia> Gnobody, schweeb highvoltage this is completely offtopic for this channel, please take it elsewhere
<Gnobody> sorry burgundavia
<highvoltage> Burgundavia: right, sorry.
<schweeb> Burgundavia: ... I was trying to end it.
#ubuntu-devel 2005-07-22
<Nafallo> hmm, anyone got that video with mdz and sabdfl that got blogged @ planet.debian.org?
<Nafallo> seems the link doesn't work anymore
<Gnobody> when was it posted?
<Nafallo> 2005-07-16 08.07.00
<Nafallo> Joey Hess: thanks..
<Amaranth> wow, classpath has 1mil lines of code
<Amaranth> Gnobody: I don't need naked pictures of cristina scabbia, I have 1 million lines of code!
<Amaranth> :0
<Gnobody> yes and in that world there are two sexes; emacs, and vi
<eruin> then tell me what nano is!
<highvoltage> there was an announcement about an ubuntu-artwork team. is there a wiki/web page about it somewhere? (sorry, lost original email)
<JanC> yes
<mdke> ArtworkTeam
<mdke> or ArtTeam
<JanC> https://wiki.ubuntu.com/ArtTeam
<mdke> (the wiki search is really good btw)
<highvoltage> i just seemed to have entered the wrong keywords.
<mdke> fair enough
<bddebian> Nano R0x! :-)
<lamont> Connecting to archive.ubuntu.com[82.211.81.151] :80... failed: Connection refused.
<lamont> feh
<Amaranth> http://www.pumuki.org/?q=node/119
<Amaranth> owned.
<sladen> Nafallo: I saw it on somebody's laptop here before it got uploaded, I forget who it was though
<pef_aw> bye !
<Riddell> daniels: libxcursor still mentions libXrender.la, can I do an upload to fix that?
<seb128> I've already uploaded a xcursor package 2 days ago
<seb128> you should better ping a buildd guy to know why there is no build log for it
<seb128> http://archive.ubuntu.com/ubuntu/pool/main/x/xcursor/
<mitsuhiko> dcop, bonobo and dbus do the same thing, will dbus get standard?
<seb128> there is no build for the 1.1.4 packages
<seb128> they don't do the same thing
<Riddell> lamont: back from your wanderings?
<mitsuhiko> seb128: they can do the same thing
<seb128> no
<seb128> dbus is not a bonobo replacement
<mitsuhiko> hm. ok
<seb128> it's simpler
<mitsuhiko> bonobo is simpler?
<seb128> no, dbus
<Riddell> mitsuhiko: dbus will replace dcop if someone can make nice enough bindings for KDE
<Riddell> bindings as nice as dcop has :)
<mitsuhiko> thanks for the informations
<mitsuhiko> so I can use bonobo for my python project
<seb128> depending of what you try to do
<seb128> if dbus does what you want better to use it
<seb128> bonobo is beeing dropped because it's to complex to use
<mitsuhiko> so bonobo is dying?
<seb128> I would not say that
<seb128> he's standing where it is
<seb128> but new code is not using it
<mitsuhiko> ok. thx
<seb128> np
<mitsuhiko> my problem is that i'm using hoary at the moment and there is the old dbus api which is not compatible to the new one
<Riddell> xcursor is dep-wait pkg-config but pkg-config is installed fine
<Riddell> tsk
<\sh> grmpf
<seb128> where do you get the dep-wait?
<Riddell> http://people.ubuntu.com/~lamont/buildLogs/Lists/breezy.all.i386
<seb128> thanks
<seb128> probably needs lamont to poke it
<Riddell> wake up infinity, fix xcursor so me and seb128 can go to bed :)
<seb128> that too :)
<Riddell> 23:31  * lamont wanders off
<seb128> bah
<\sh> so..we should go and sleep....today is another day to kick
<\sh> oh 
<\sh> esc+4 != esc+5
<\sh> anyways...off to bed
<OddAbe19> hey, when I do make on a program i do the following:  ./configure 'CFLAGS=-march=athlon-xp -pipe -O3' 'build=i686-linux' 'CXXFLAGS=-march=athlon-xp -pipe -O3' 'build_alias=i686-linux'
<OddAbe19> how do i point it to gcc 4
<OddAbe19> with make not ./configure
<bob2> you use breezy, which has gcc 4.0 as the default
<bob2> using gcc 4.0 with c++ code on hoary will break
<OddAbe19> i have gcc 4 installed through backports
<bob2> that'll work awesomely then
<bob2> but as above
<OddAbe19> i don't have to do a 'gcc=4'?
<bob2> if this program involves C++ code, you can't use gcc 4.0, sorryy
<bob2> unless it's so simple it uses nothing but libstdc++
<OddAbe19> na, it's gimp
<OddAbe19> lol
<OddAbe19> i'm working on a more optimized version for distribution
<OddAbe19> and i hope all those options will work like that, it has in the past
<bob2> then set the C compiler when running ./configure
<bob2> you're doing benchmarks to find if gcc 4.0 is usefully faster?
<OddAbe19> so, do this instead?  ./configure 'CFLAGS=-march=athlon-xp -pipe -O3' 'build=i686-linux' 'CXXFLAGS=-march=athlon-xp -pipe -O3' 'build_alias=i686-linux' 'gcc=4.0'
<bob2> no
<OddAbe19> no, i just want to make an athon/i686 optimized version of it
<bob2> ./configure 'CFLAGS=-march=athlon-xp -pipe -O3' 'build=i686-linux' 'CXXFLAGS=-march=athlon-xp -pipe -O3' CC=gcc-4.0
<OddAbe19> with O3
<bob2> er...
<bob2> if you're not planning to see if it's faster, what's the point?
<OddAbe19> well, a little of both
<mdke> i can't seem to download my breezy packages: get connection refused from the various archives.ubuntu.com I've tried. Does anyone know what might be up?
<bob2> OddAbe19: I mean "what's the point of making your own k7-specific package if it's not actually faster?"
<OddAbe19> it sort of is, loads faster
<OddAbe19> and some of the plugins work better
<OddAbe19> that's why
<OddAbe19> it's because i'm a speed whore and want to get every last bit
<OddAbe19> lol
<bob2> ah, so, you have benchmarked it and found it faster
<OddAbe19> meh
<OddAbe19> lol
<OddAbe19> if by benchmark you mean stopwatch
<OddAbe19> lol
<OddAbe19> human error
<OddAbe19> tenth of seconds faster
<OddAbe19> but i'm a speed whore
<carstenh> OddAbe19: how much time do you spend to optimize your system?
<OddAbe19> not much
<OddAbe19> just most packages i use usually
<OddAbe19> and my kernel
<tseng> "my name is nikolai, and I'm that annoying guy who keeps pushing his idea of a new logo/mascot for ubuntu: the medicine mask!"
<tseng> speachless.
<sladen> tseng: -devel/-users?
<slomo> tseng: lol
<tseng> sladen: http://lists.ubuntu.com/archives/ubuntu-art/2005-July/thread.html
<tseng> sladen: he posted in triplicate (html)
<tseng> THE MASK CONQUERS ALL
<bob2> ugo: the list, not the channel
<ugo> im not pasting anything here bob2
<ugo> jeeze...lighten up
<tseng> bob2 is the channel hammer dude
<sladen> oh, in an HTML stripped part, even better
<ugo> yeah he did a fine job on two "sweethearts" about an hr ago
<Amaranth> cool, debian's udev problem got resolved
<Amaranth> sabdfl and mdz got drunk and started dancing together? i can't see the video, it's gone
<bddebian> Hmm
<lamont> eh?
<lamont> Riddell: what do you need poked?
<lamont> xcursor.  rigth.
<lamont> dep-wait cleared.
<ugo> *blinks*
<ugo> so sorry to disturb but does anyone know if its possible to have gcc3 and gcc4 on the same box
<Amaranth> aye
<bddebian> Should be fine
<Amaranth> I have /usr/bin/gcc-4.0 and /usr/bin/gcc-3.4
* seth_k has those and 3.3 too
<ugo> Armanath im guessing this isn't the proverbial aptitude install
<TerminX> daniels: you have an ETA on the xdpyinfo/xhost/xrandr/xsetmode/xsetpointer packages?
<Amaranth> TerminX: Next week, maybe.
<TerminX> d'oh
<TerminX> I thought that he'd said "tomorrow" when asked about it yesterday
<TerminX> I guess I was mistaken :)
<seth_k> btw that Nikolai guy is insane, the medicine mask guy. He does not understand the concept of mailing lists at all
<seth_k> plus his mask sucks, because 1) it's too complex for a logo, 2) it doesn't represent Ubuntu, 3) it is rather stereotypical, 4) it is ugly (opinion)
<sladen> seth_k: the artwork itself is good.  Whether it fits is, as your say, another matter
<Amaranth> do you guys agree with this: "If 'Aunt Tilly' needs to use distutils we've already failed."?
<Burgundavia> probably
<bob2> python distutils?
<Amaranth> yeah
<jdub> Amaranth: is aunt tilly a web developer?
<jdub> (or above)
<Amaranth> no, aunt tilly is esr's fictional end-user
<Amaranth> she _might_ know what firefox is
<jdub> end users can be low end developers
<Amaranth> maybe
<Amaranth> if her nephew has explained it to her more than once
<jdub> but if she's specifically not, then yes, it's absolutely insane
<Burgundavia> jdub, can you give me a quick opinion on the wiki page death I just sent to the -devel list?
<Amaranth> Basically if someone knows what distutils is, they should know how to get it or how to get help.
<Amaranth> If they don't know what it is and need to use it, we've failed.
<jdub> Burgundavia: dunno
<Burgundavia> jdub, that was quick but no exactly what I was looking for ;)
<jdub> you're not really asking the right person
<Burgundavia> who should I ask?
<jdub> Burgundavia: you've posted your question to the right list
<jdub> "It's target audience is high school students and Refugees."
<jdub> ^ awesome
<jdub> that is one heck of a target market specification
<daniels> that apostrophe is grating on my eyeballs
<Treenaks> jdub: second-hand bookstore?
<Burgundavia> jdub, cheers and I understand you just got back from japan
<jdub> Burgundavia: i did? rad.
<Burgundavia> oh
<Burgundavia> did you enjoy your non-trip?
<Treenaks> someone really needs to fix the launchpad SSL key
<jdub> Treenaks: ubuntu lite
<Treenaks> jdub: Cool
<fabbione> morning
<fabbione> jdub: ping?
<madduck> when and where is ubuntuconf? is there a url?
<bob2> not announced yet
<madduck> mh, ok.
<pef> hi
<davyd> hey, does anyone have links to an amd64 binary for xbase-clients -36?
<davyd> ok, possibly ignore me on that front
<Amaranth> hehe
<Amaranth> still need it?
<davyd> I didn't get around to fixing it last night
<davyd> I saw the xlibs links though, now I just need to grab them
<davyd> mmm, w3m
<Amaranth> ok...
<Amaranth> still need it?
<Amaranth> yes or no please, it's 4am
<Amaranth> doesn't matter anyway, morgue.ubuntu.com doesn't have them
<davyd> morgue seems to be dead
<Amaranth> yeah
<davyd> ok, I seem to have found them
<Amaranth> http://archive.ubuntu.com/ubuntu/pool/main/x/xorg/xbase-clients_6.8.2-36_amd64.deb
<Amaranth> err
<Amaranth> oh yeah, the amd64 buildds fell over
<Amaranth> you shouldn't have any problem on amd64, it looks like the latest X you have is -36 anyway
<davyd> yeah, except for xlibs
<davyd> which is arch 'all'
<Amaranth> xlibs -42 is fine here?
<Amaranth> wait, no it isn't
<Amaranth> -41 was
<daniels> -42 shouldn't be any more broken than -41, certainly
<daniels> at least, I don't think
<Amaranth> but xlibs is just a metapackage, isn't it?
<daniels> davyd: if it's any consolation, my laptop is stuck in console mode, my amd64 won't accept any keyboard input, and my powerpc is also in the console
* Amaranth giggles
<Amaranth> i guess that's great motivation to fix something though :D
<daniels> yeah -- specifically, the modular server
<daniels> which I'm fixing now
<Amaranth> btw, are the all changes you're making going into xorg cvs?
<daniels> trying to track down exactly how gcc4 miscompiles i810_drv.o, making the modular server happy with big-endian machines, and stuff
<daniels> yeah, they are
<Amaranth> gcc bugs are always fun
<davyd> daniels ; are you in Melbourne at the moment?
<Amaranth> did it work on 4.0.0?
<daniels> davyd: yeah
<davyd> daniels ; someone said you weren't
<daniels> Amaranth: pretty sure it didn't
<davyd> daniels ; is there some sort of mail order liquor store in Melbourne?
<daniels> davyd: uhm nope, I've been here for a fair while now
<daniels> davyd: since LinuxTag
<daniels> davyd: not that I'm aware of ...
<davyd> daniels ; hmm
<davyd> I was going to send you a sixpack, but I'm too stingy to fedex it from Perth
<daniels> haha
<daniels> dude
<daniels> what for?
<davyd> daniels ; because I said I would, and you refused to fix my Xserver till I do
<cat> hey everyone
<davyd> and maybe then you'd feel guilty and drunk
<davyd> and perhaps you'd fix it
<davyd> I need to buy more Squire, so that I can read chapters 2, 3 and 5 of the fucking story
<davyd> because my six-pack only had chapters 1, 4 and 6
<davyd> twice!
<davyd> also, it seems wrong to be using a console on a 20" LCD screen
<davyd> daniels ; what's your ETA for getting some sanity into this?
* davyd discovers there is no version of xvinfo for amd64
<davyd> that seems to be messing up my dependancy tree pretty bad
<\sh> amd64?
<\sh> it's out of order..,-)
<daniels> davyd: amd64's buildds are all dead
<fabbione> go GCC-4.0 it's your birthday!
<davyd> daniels ; oh man, still?
<daniels> davyd: well, elmo's been on holiday ...
<daniels> davyd: making xbase-clients and xlibs installable are my first priorities, bugger everything else
<davyd> daniels ; righto
<daniels> i'm forecasting tuesday
<davyd> I can start building things
<davyd> do source packages still get updated when the binaries don't?
<daniels> because at this stage, I need to modularise every single remaining library before xdpyinfo can be built
* davyd builds a new xvinfo
<davyd> excelltn, now I can install gdm
<davyd> I feel like a gentoo user
<\sh> davyd: oh u r using this funny little filemanager as well? *lol*
<davyd> hmm?
* davyd builds gnome-panel
<davyd> how hard is it to set up a buildd?
<Amaranth> http://packages.ubuntu.com/breezy/x11/gentoo
<davyd> oh, I know about that thingy
<davyd> I almost installed fc4 on this machine
<Amaranth> disturbingly ugly
<davyd> because it has the tools I need
* Amaranth whips davyd 
<eruin> should I create an enh.bug on the ubuntu bugzilla if I'd like to see some added functionality for shares-admin ?
<Amaranth> naughty!
<davyd> but I would have no idea how to install Mono on it
<davyd> or a chroot
<davyd> dchroot and debootstrap are wonderful tools
<eruin> or should I take the discussion to the seemingly dead system-tools list on mail.gnome?
<davyd> eruin ; why not file it in the GNOME bugzilla?
<\sh> davyd: it's funny that u can do a `emerge debootstrap` on Gentoo ,-)
<eruin> that's probably the best now that you mention it :)
<davyd> \sh ; does it work the same?
<davyd> ie. install a Debian chroot?
<\sh> davyd: yes 
<Treenaks> \sh: any idea why wine is still uninstallable in breezy?
<Treenaks> \sh: (the GLU mess?)
* davyd laughs
<Amaranth> daniels: i thought you said you could only get xbase-clients done by tuesday if you worked non-stop through the weekend and didn't have any problems
<\sh> treenaks: it builds ... lemme check
<davyd> I didn't realise how patched Fedora was till I started using it at work
<eruin> Treenaks, its due to xorg being broken
<Treenaks> eruin: GLU madness
<Amaranth> Yeah, blame everything on xorg being broken!
<Amaranth> :)
<davyd> but it did ship with GCC-4.0, which was a nice touch
<eruin> xrandr not split out etc
<Treenaks> Amaranth: but wasn't xorg broken because of GTK boogz?
<\sh> treenaks: i will give it a punch in the face...now
<Amaranth> haha
* davyd snerks
<Treenaks> \sh: \o/
<\sh> or me?
<Amaranth> "it's a bug in GTK" then it got fixed in xorg :)
<Treenaks> \sh: I'm building the current source locally now.. see if it works
<davyd> daniels ; non the less, if you locate some sort of online beer mail order system, located in fair Melbourne, let me know
<\sh> no I don't blame anybody for doing mistakes...
<eruin> davyd, oooh, no more leaving the house?
<Amaranth> davyd: That'd be stupid, kids would be ordering beer.
<daniels> davyd: heh, sure
<davyd> dude, this is Australia
<eruin> kids can already buy beer :p
<davyd> kids already buy beer
<davyd> you see them on the foreshore drinking EB
<daniels> Amaranth: i think if I work non-stop through monday and tuesday with no problems, I can sort it
<Burgundavia> any timeframe on the new live/install work landing?
<daniels> Amaranth: i'm actually using my weekend as a weekend; it's novel
<davyd> thankfully they stopped making Swan Gold
<daniels> (hacking on the modular server instead)
<Amaranth> daniels: wtf are you doing on IRC then?
<Amaranth> haha
<daniels> davyd: eep, swan is terrible
<daniels> Amaranth: sucker for punishment
<\sh> hmm
<Amaranth> this exa stuff seems pretty buggy
<davyd> daniels ; exactly
* davyd still has a Coopers Pale in the fridge
<Amaranth> eek, i accidently found the detach tab keyboard shortcut in xchat
<\sh> strange dependency
<davyd> ctrl-I
<Amaranth> whew
<Amaranth> i couldn't get it back
<davyd> the problem with working in open source is that the idea of a weekend becomes blurred
<\sh> aye
<Nafallo> hmm
<davyd> I am experiencing a similar problem with this working from home thing
<\sh> mesa-common-dev
<Amaranth> weekends are when your users will bitch the most
<\sh> is seriously b0rked
<Nafallo> my rhythmbox craches ;-)
<davyd> brilliant idea, write it down, explore it a bit, find you've implemented it
<Amaranth> Nafallo: Mine plays the flute.
<Nafallo> or really, it crashes :-)
<\sh> ok...fixing first the mesa deps in mesa-common-dev
<davyd> hmm, it's always the -data packages
<Nafallo> Amaranth: I'm on amd64, I guess I build it locally soonisch :-)
<eruin> anyone here have xbase-clients -36 ?
<davyd> the buildd dies and it all goes to shit
<davyd> because there are still new -data packages
<Amaranth> haha
<Amaranth> someone has a mirror of them too
<Amaranth> if you can find them in the logs
<Nafallo> Amaranth: baah, I got a pbuilder :-). the only problem is getting source over this crappy ADSL of mine ;-)
<Amaranth> Nafallo: i meant xlibs-data 6.8.2-36 :)
<Nafallo> Amaranth: ahh *s*
<Amaranth> my muine and rhythmbox both suck
<Amaranth> something somewhere forgot to check for errors
<eruin> grab sonance cvs :)
<cat> well, i wanna help out two (:
<Amaranth> probably in id3 reading, everyone seems to suck at that
<Amaranth> sonance cvs starts, randomly
<eruin> ehehe
<Amaranth> i mean, sometimes i get a real GUI, sometimes i get half a gui overlapping itself
<Amaranth> that is insensitive
<eruin> that's cute
<Amaranth> but some of the things still prelight
<Burgundavia> daniels, when should I start reporting X autoconfig regression bugs?
<cat> hey if i want to help out packaging what should i do?
<Burgundavia> cat, talk to the people in #ubuntu-motu
<Amaranth> cat: join the MOTU :)
<Nafallo> cat: basically repeat that sentence in #ubuntu-motu :-)
<cat> alright (:
<\sh> hmmm...
<\sh> actually...
<\sh> I know where this comes from...
<\sh> wine_0.0.20050628 is not in the archives..
<\sh> the source yes...but not the binaries
* \sh 's looking around for some NEW love ,-)
<Treenaks> \sh: then there was a build error
<\sh> no
<Treenaks> no?
<\sh> it's in new i think
<Treenaks> \sh: wine is already packaged.. how can it be in NEW
<Treenaks> \sh: it should just replace it
<\sh> no...i will replace a lot of old bins...and I think it's stucked somewhere
<\sh> i386 is build
<\sh> http://people.ubuntu.com/~lamont/buildLogs/w/wine/0.0.20050628-1/
<\sh> Treenaks: have the same problem with gfccore 
<\sh> but it's a good time to upload it with the right version number ,-)
<\sh> guys...can anyone approve my theory, that right now, "empty the trash" in gnome is not working?
<Amaranth> you have something in there you aren't allowed to delete?
<chris`> \sh, in my breezy it works fine...
<\sh> hmmm...
<\sh> Amaranth: no
<\sh> oh
<\sh> moment
<\sh> funny
<littlepaul> \sh it works for me too
<\sh> empty trash doesn't update the trash ...clicking on the files with the right mb..disappeared...strane
<\sh> can someone kick kdelibs4 again,pls?
<\sh> moins pitti
<sivang> pitti: Hey Martin :-)
* pitti is back and enjoys is brand new amd64
<Mithrandir> pitti: do you have pmount in a baz archive somewhere?
<pitti> Mithrandir: it's in bzr
<Mithrandir> pitti: hm, ok.
<pitti> Mithrandir: http://people.ubuntu.com/~pitti/bzr/pmount
<Mithrandir> pitti: shame you left already, I wanted to discuss some stuff about mmount with you.  Basically what hooks would be good for you to have.
<sivang> Mithrandir: mmount the successor to pmount? :-)
<Mithrandir> sivang: no, the modular mount which is the successor to the current mount.
<Mithrandir> hopefully.
<pitti> Mithrandir: so far I need hooks for "authentication" (removable, fstab, /etc/pmount.allow) and some device map checks (is a device encrypted and devmapper needs to be set up?)
<Mithrandir> pitti: pmount shouldn't care about encrypted stuff, that should be a luks plugin.
<Mithrandir> pitti: plugins should be stackable
<Mithrandir> have to run now, I'll be back in half an hour or so
<jdthood> pitti: I want to reassign a bug.  In what package would a new button on System|Preferences|Sound be implemented?
<pitti> jdthood: I think it's control-center
<jdthood> k
<jdthood> There is also a 'gnome-control-center'.  Not that, eh?
<Burgundavia> jdthood, that is it
<jdthood> thanks
<shackan_> hi pitti 
<\sh> I wonder if it's possible to build wine on amd64
<davyd> hmm, I still can't start X
<\sh> davyd: fixed font?
<davyd> \sh ; wine will work in a chroot, I don't like your chances of making it work in 64-bit
<\sh> davyd: no..i mean using 32bit compat libs for amd64 e.g.
<ogra> \sh, just building it...
<\sh> ogra: nice :)
<\sh> looking at the time...
<ogra> \sh, lets see.... needs about 100 pkgs not in my pbuilder yet
<ogra> meh
<ogra> Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/x/xorg/libxaw7_6.8.2-34_amd64.deb 
<davyd> hmm, I don't like the error that Xorg is giving me
* ogra updates his pbuilder
<davyd> failed to load module keyboard
<davyd> failed to load module mouse
<davyd> failed to load module nvidia
<\sh> change "keyboard" to "kbd"
<pitti> Hi shackan_ 
<davyd> \sh ; where does this change come from?
<davyd> this is xorg-36
<\sh> oh..
<\sh> I have -42 
<\sh> yeah...-36 should be keyboard
<davyd> hmm, it's a bit strange
<Nafallo> I got -36 and has to use kbd, fwiw
<davyd> well, what about the other two?
<davyd> incidently 'kbd' doesn't fix it
<Nafallo> davyd: you will want xserver-xorg-input-{kbd,mouse}
<davyd> aah, nice
<Nafallo> xserver-xorg-driver-nv should be nvidia :-)
<tseng> +1 funny
<davyd> ok, so I have everything bar whatever is needed to make nvidia work
* davyd guesses he needs nvidia-glx
<davyd> which is nicely uninstallable
<ogra> davyd, that in l-r-m .... we dont have it yet
<ogra> thats even
<davyd> ogra ; I built the kernel module by hand
<ogra> ah
<davyd> using make-kpkg, the old fashioned way
<davyd> nvidia-glx appears to have what I want, I might have to have a crack at building it later
<ogra> \sh, wine with gcc4 seems not to work on amd64
<ogra> checking for C compiler default output file name... configure: error: C compiler cannot create executables
<\sh> ogra: hmmm....
<davyd> ogra ; check config.log
<davyd> you may be missing libraries
<ogra> davyd, yes... sadly my pbuilder doesnt keep config.log....
<tseng> wine works on !x86?
<Amaranth> ha, no
<Amaranth> it _might_ work on amd64 compiled as a 32-bit app though
<\sh> --enable-win64          build a Win64 emulator on AMD64 (won't run Win32 binaries)
<ogra> tseng, they *wanted* to make it work on amd64 and ppc, but i havent heard about it yet, so we are trying
<Amaranth> worthless
<\sh> but this is not
<\sh> I want to have a wine for adm64 running 32bit win apps
<Amaranth> the darwine project is the only thing i know about as far as ppc goes
<Amaranth> doesn't that require a 32-bit xserver and everything else wine uses?
<\sh> what are the 32bit compat libs for amd64 to run 32bit apps?
<ogra> ia32-libs ?
* \sh is amd64 noob
<\sh> ogra: put it into the b-d ,-) what ever
<ogra> i'm just trying to figure out where the -m32 compilerflag comes from... 
<ogra> probably disabling that is enough
<\sh> configure.ac
<\sh> if test "x$enable_win64" != "xyes"
<\sh>     then
<\sh>       test -n "$CC" || CC="gcc -m32"
<\sh> and ff
<ogra> aa
<davyd> I think you'll need to run wine as a 32-bit binary
<davyd> else how will you link into 32-bit windows DLLs?
<Treenaks> davyd: the same way windows itself does that ?
<Treenaks> davyd: (the 64-bit windows thing)
<davyd> treenaks, last time I played with 64-bit windows it was (a) crack and (b) didn't run 32-bit code
<davyd> I wonder if they've fixed it
<Treenaks> davyd: Windows is crack anyway..
<davyd> hmm, I need a new xlibmesa-glu
<davyd> which apparently means I need the X.org source
* davyd wonders if he can compile a single modules from that
<davyd> I guess that's why it's being modularized
<tseng> davyd: heh, known issue that my battery applet goes up to 135% now?
<davyd> tseng ; are you using the HAL backend?
<davyd> it seems to do exciting things
<tseng> hm I guess
<Treenaks> tseng: it's just a very good battery ;)
<ogra> tseng, battery applet will go...
<davyd> rather then copy our battery code, that took years to work around all the shitty bugs
<ogra> tseng, we'll have gnome-power
<davyd> they've started again
<davyd> so they're getting all the same issues
<davyd> gnome-power or PowerManager or whatever they've now called it, shouldn't have an applet
<ogra> davyd, do you use richard huges' acpi backend in HAL ?
<davyd> it should just be a policy system
<davyd> ogra ; I think he wrote a heap of it
<ogra> davyd, yes... i was wondering if you use this for your applet
<Amaranth> today's userfriendly rocks
<Amaranth> http://www.userfriendly.org/
<ogra> gnome-power has a notification area icon...for the battery... and uses libnotify now
<ogra> \sh, wine throws a millon warnings about signedness, but compiles now :)
<ogra> eeek
<ogra> /usr/bin/ld: cannot find -lXext
<ogra> GRRRR
<sivang> anybody see seb128? knows if he's supposed to come back?
<ogra> sivang, its sunday.... and the weather is nice....
<davyd> yeah, we're using HAL now, but it might get backed out for 2.12
<davyd> it's a little dodgy in places
<davyd> but it does need testing
<davyd> because it's our ultimate goal to lose the other backends
<\sh> ogra: hihi
<ogra> davyd, yep, HAL should be the center of the HW world...
<sivang> ogra: hehe
<sivang> ogra: so why aren't you out in the sun? :-)
<ogra> sivang, i have a terrace with wlan ;)
<ogra> \sh, sadly my pbuilder gets xlibs-dev -42 but all other X is -36 ..... so libxext is incompatible... wont work before the archive is in shape again :/
<sivang> ogra: woo , makes me wanna come and visit you there even more :-)
<ogra> its not as shiny as it appears, but .... :)
<\sh> ogra: yep
<Lathiat_> davyd: hal for what?
<ogra> Lathiat_, *all* hardware interaction....
<ogra> Lathiat_, in the curent case for battery monitoring....
<Lathiat_> ogra: right, the problem is, gnome runs on !linux
<Lathiat_> and hal runs on *linux
<Lathiat_> right?
<ogra> nope
<ogra> hal also runs on solaris afaik... and they are porting it further....
<Lathiat_> oh?
<Lathiat_> didnt know that
<Lathiat_> cool
<ogra> note, i'm talking about CVS here.... 
<jdthood> pitti: Good news and bad news.  Which do you want first?
<Lathiat_> ogra: ya, cool none the less
<pitti> jdthood: hard choice... good one?
<jdthood> pitti: The good news is that I have added lsb init function support to the ALSA mixer-level restoring initscript, thus dispensing with the need to patch it.
<pitti> yay
<pitti> jdthood: you now detect for the lsb-init include file and use it if it's available?
<jdthood> yep
<pitti> jdthood: (that's what I did for postgresql-common)
<Amaranth> http://www.artlebedev.com/portfolio/optimus/ <--i need one
<jdthood> pitti: The bad news is that the initscript has been split into two.  /etc/init.d/alsa now does module (un|re)loading.  /etc/init.d/alsa-utils does mixer level restoring.  Hopefully this won't cause too many headaches.
<jdthood> alsa-base and alsa-utils no longer Depend on each other.
<mitsuhiko> Amaranth: wow. thats cool
<pitti> jdthood: that should be fine, thanks for the notification
<pitti> jdthood: shouldn't module loading be performed by hotplug?
<ogra> Amaranth, the mouse is way ooler :)
<ogra> cooler even
<jdthood> pitti: Yes.
<jdthood> pitt: /etc/init.d/alsa is no longer linked into the runlevel directories
<Amaranth> ogra: haha, it's goofy
<mitsuhiko> Arrogance: has this keyboard linux support?
<jdthood> It gets called from alsa-modules* postinst and from /etc/apm/scripts.d/alsa
<Amaranth> mitsuhiko: This keyboard isn't available yet.
<Amaranth> mitsuhiko: They mention 'open-source' though.
<jdthood> ... if the user has set "force_unload_modules_before_suspend" to something.
<mitsuhiko> i want it :)
<mitsuhiko> Amaranth: http://www.daskeyboard.com/ <== another good keyboard :)
<Amaranth> http://www.artlebedev.com/portfolio/determinator/caller_id/ sneaky
<mitsuhiko> Amaranth: don't understand a singel word :(
<Amaranth> neither do i
<Amaranth> it's a caller id
<Amaranth> really small, patched right into the line
<davyd> hmm, was it X.org 41 or 42 that was broken?
<Amaranth> both
<\sh> http://www.joachim-breitner.de/blog/archives/60-Launchpad,-Google-and-why-Microsoft-is-not-the-problem.html
<\sh> cu later dudes..have to think about this...and have a shower :)
<Amaranth> *yawn*
<Amaranth> It's not Free so it might be evil.
<Amaranth> It's obviously a conspiracy against the people of the world.
<sivang> \sh: that's you're blog post?
<Nafallo> sivang: naah, joachim breitner.
<sivang> Nafallo: interesting mind excersize :-)
<Nafallo> hehe
<zyga> hello
<LinuxJones> zyga, hiya
<Seveas> is there a preseed expert in here who can answer a few simple wuestions?
<\sh> sivang: no
<sivang> \sh: sure, I guessed it already :-)
<Seveas> it's JB's second 'attack' on Canonical/Ubuntu in one day :)
<\sh> lol
<\sh> they helping us...it's positiv ,-)
<Nafallo> depends on how you look at it :-)
<Seveas> the tone of the blogposts is quite negative though
<Nafallo> the first one is something we want done and needs help with.
<Nafallo> the second is more an attack on canonical than ubuntu ;-)
<Seveas> so I guess there is no preseeding/d-i guy in here now..?
<\sh> Nafallo: well...i wouldn't mind if matthew szulik and mark are sitting the next time together in a small restaurant and talking about kicking ms and sun 
<\sh> but I think matthew is the wrong guy for it..lets talk to bob young :) 
<Nafallo> \sh: :-)
<\sh> a really nice star linux alliance between fedora and ubuntu / redhat and canonical 
<Kamion> Seveas: maybe, though I'm mostly doing Debian stuff today
<Seveas> Kamion, just 2 simple generic questions: if I install a package via apt-get in base-config/late-command, can I preseed it in the same file? And which task for tasksel installs ubuntu-base?
<Seveas> (same file refers to the preseeding file)
<Kamion> Seveas: 1) yes, you can; however it would be easier to preseed base-config/package-selection
<Kamion> default value is ~tubuntu-standard|~tubuntu-desktop; it's an aptitude pattern, see the aptitude docs
<Seveas> Kamion, ahhhh, that answers 2) too, simply install no packages with tasksel :)
<Kamion> Seveas: 2) we do not use tasksel; debootstrap is called from base-installer and installs the base system
<Seveas> thank you!
<Kamion> tasksel isn't even in Ubuntu main, actually
<Seveas> heh :)
<Seveas> the installer manual does use it :)
<Kamion> Seveas: mm, yeah, that would be out of date
<Kamion> I've updated a lot of the manual, but not all of it
<Seveas> does this also work for PXEboot installs?
<Seveas> appendix C-1, the default preseeding file contains this info by the way (in case you are interested)
<Kamion> Seveas: yes, no difference between cdrom and netboot there
<Seveas> Kamion, once again: thanks very much!
<fabbione> hmmm
<fabbione> what package is lacking /usr/lib/libXrender.la ?
<tuhl> what has to be done to fix the broken X? update the system? is this enough?
<ogra> fabbione, libxrender-dev
<fabbione> GRRR
<fabbione> daniels: ???
<ogra> yep
<fabbione> it just made gcc-4.0 FTBFS after 10MB of log
<ogra> gcc ?
<fabbione> yes
<ogra> why does it depend on xrender ?
<fabbione> no gcc needs gtk that pulls in xrender somewhere as B-D and linking
<ogra> err, and why does gcc need gtk ? seems somewhat strange
<fabbione> it does.. ask doko :)
<ogra> weird
<fabbione> we also need to import slang2
<fabbione> otherwise quite a bunch of pkgs in main are FTBFS
<ogra> hmm...
<ogra> sounds like there are other transitions waiting for universe
<fabbione> Kamion: there are 3 or 4 binaries for sparc waiting to be NEW'ed...
<fabbione> Kamion: can you be so kind to give them love?
<zyga> gcc needs gtk?
<Mithrandir> zyga: gcj needs it for some swing stuff, at least.
<zyga> ah... 
<zyga> makes sense then
<fabbione> MOTU's are going to be soon very busy
<zyga> the time when your compiler depends on a gui toolkit is troubling though :>
<ogra> hmm, they should be split into two packages then... having the main compiler depending on gui stuff doesnt seem sane to me...
<fabbione> ogra: that's no option with gcc
<ogra> :-/
<zyga> fabbione: can't gcc be built withoug java?
<zyga> silly questiong
<fabbione> zyga: than you don't have java
<zyga> there are separete packages for gcj and stuff but they all build from gcc
<zyga> sorry
<fabbione> bootstrapping compilers is not exactly simple
<tuhl> X is still no starting after an update
<Amaranth> fabbione: libXrender.la no longer exists
<Amaranth> fabbione: daniels seems to be happy to be rid of it
<Kamion> ogra: the main compiler doesn't depend on GUI stuff; it *build*-depends
<Amaranth> tuhl: You'll have to wait for daniels to finish his work on xbase-clients for X to be usable.
<tuhl> Amaranth: thanks for the info
<Kamion> fabbione: the sparc binaries are all part of other things; I was kind of planning to leave those to elmo
<fabbione> Kamion: hmm ok..
<fabbione> Amaranth: if daniels got rid of that, than we a have circular B-D problem....
<fabbione> because i need new gcc to (probably) fix a bug in the actual gcc...
<Nafallo> have eny decisions been taken on what proxy to use for 
<Nafallo> 
<Nafallo> NetworkWideUpdates 
<Nafallo> ?
<fabbione> that means i can't build the new gtk to get rid of that .la thingy
<Amaranth> fabbione: kick ass
<Amaranth> :/
<Amaranth> seb was working on making the GNOME stack stop using it
<Amaranth> gnome-terminal, libraries, gtk, etc
<fabbione> yeah and gnome is FTBFS due to that gcc bug
<Amaranth> oh, fun
<Amaranth> is that the same one that is making the i810 driver mess up?
<Amaranth> in xorg
<fabbione> Amaranth: no. it's a specific sparc bug
<Amaranth> oh, sparc
<fabbione> the -Wl,--as-needed is broken
<Amaranth> yeah, the --as-needed stuff, right?
<mjg59> Woo, working usplash demonstration
<Amaranth> mjg59: gimme :)
<ogra> Kamion, thats still not right in my eyes...
<ogra> mjg59, the *real* usplash ?
<Amaranth> fabbione: So until you fix gcc you can't fix gtk and until you fix gtk you can't fix gcc.
<Amaranth> Nice
<fabbione> Amaranth: exactly...
<Amaranth> fabbione: hack time, build gtk without --as-needed once
<Amaranth> or talk to seb128 :)
<sivang> seb128: ping
<fabbione> Amaranth: that's what i was planning to
<sivang> seb128: did you get my email?
* Amaranth goes back to reading harry potter
<mjg59> ogra: Yes
<Amaranth> anyone want any spoilers :D
<ogra> wohoo
<mjg59> ogra: (I wrote it yesterday)
<ogra> yay for mjg59 !!!
<seb128> hi
<mjg59> Amaranth: Needs a bit of work yet, not least to make it buildable
<sivang> hi again seb128  :-)
<seb128> sivang: calm, that's the WE
<seb128> yes I got the mail
<seb128> I've to ping jamesh before packaging the lib
<seb128> then I can try the patch
<fabbione> Amaranth: i will need to do a local build in a chroot without exporting the binaries, build gcc, be sure that it fixes the relaxation bug, reinstall gcc, rebuild gnome with relaxation, rebuild gcc, upload gcc and rebuild gnome...
<fabbione> Amaranth: that's just to be 100% sure not to kill anything
<mjg59> It's going to need a bit of work to get it to deal with the initrd/root changeover
<sivang> seb128: you can try the patch also, if you take the baz archive and make install it in some chroot or a dev machine
<seb128> I know how to install a lib, thanks
<seb128> that's just the weekend
<sivang> seb128: sure, sorry, I didn't mean it that way
<sivang> ogra: what is that gcc bug?
<ogra> sivang, there is no bug... gcc build depends on gtk through some java dependencys for gjc
<sivang> ogra: ah I see
<sivang> seb128: ok, so let me know when the pkg is in, as I will continue patching apps using the non pkged version of the lib
<seb128> sivang: probably tomorrow
<eruin> does anyone have -36 packages of xorg mirrored somewhere?
<eruin> tseng, http://tseng.ath.cx/images/cowbell.png - nice battery status :-)
<Lathiat_> eruin: i think you'll find he has 2 batteries
<jnc> that answers my question
* jnc peers at topic
<eruin> Lathiat_, never seen that before. cute ;)
<tseng> Lathiat_: nope.
<tseng> Lathiat_: davyd says its the hal backend
<Lathiat_> tseng: oh, heh
<jnc> now, with X broken occasionally in development, is there a convenient way to make ubuntu boot into multi-user without X11?
<Lathiat_> jnc: if it breaks just login and fix it, if your keybaord gets screwed like mine then boot recovery mode from grub :)
<tseng> you could remove gdm from your runlevel
<tseng> man update-rc.d
<jnc> oh
<jnc> no  ubuntu=xbroken  boot flag  ?  ;)
<eruin> Lathiat_, got your keybd fixed?
<Lathiat_> eruin: yep
<eruin> Lathiat_, mind sharing how in a pm? :P
<jnc> Lathiat_: that's a bit more permenant than i was looking for, effective though
<jnc> :/
<jnc> it seems like the Xorg drivers are missing, is that what broke X11?
<eruin> well, yes and no
<eruin> you should be able to install them fine
<jnc> okay
<eruin> ie xserver-xorg-input-kbd
<eruin> and change keyboard in xorg.conf tokbd
* jnc apt-cache search's
<eruin> but now that I think of it, the latest updates seemed to drag in all the drivers I hadn't installed, so I believe that's fixed
<jnc> heh
<eruin> xkeyboard-config conflicts with xbase-clients though
<jnc> i  had a trouble with Xlibs though, it wouldn't fully install
<jnc> ah
<eruin> rendering my keyboard useless in non-english conversations (and for switching to a terminal)
<jnc> :(
<jnc> sorry to hear that
<eruin> no doubt poor daniel will have it fixed next week :)
<jnc> yea
<jnc> i'm looking at the output, here it says errors were found while processing xlibs 
<Amaranth> eruin: Force it through.
<jnc> i remember this happened before, and i had to edit some file  and run it manually
<jnc> i forgot exactly where that was though
<Amaranth> amd64 users need xlibs and xlibs-data 6.8.2-36 and x86 and ppc users need xbase-clients 6.8.2-36
<Amaranth> good luck finding these, they aren't in morgue or the archives
<eruin> what about i386?
<Amaranth> i said that
<Amaranth> x86
<eruin> I'm halfblid
<eruin> blind* :)
<eruin> I've got it locally 
<eruin> yay
<jnc> Amaranth: you're referring to using an old version of the package, due to the new one being fubar?
<fabbione> seb128: ping?
<Amaranth> yes
<jnc> hmm xvinfo isn't available on amd64
<jnc> i wonder what that i
<jnc> s/i$/is/
<Lathiat_> jnc: the buildds are broken for amd64 last check
<jnc> awwe
<Lathiat_> and X has some borked stuff too
<Lathiat_> xvinfo is a program that shows info about Xv, which provides video overlays
<jnc> thanks for the info
<Lathiat_> just bare with the Xorg team
<jnc> 'k
<jnc> hey, on a different yet related topic,  why is it that i'm running out of X11 connections over a few days?
<jnc> eventually i cannot open new X11 client windows
<jnc> they  get a message like "maximum X11 clients reached"
<jnc> i've seen forum posts about it and the resolve was something like, deal with it just restart X11 every few days
<jnc> that's not acceptable IMO
<jnc> have you seen this problem?
<seb128> fabbione: pong
<pef> bye !
<Gnobody> ping
<Gnobody> pong
<Gnobody> marco?
<jnc> POLO
<jnc> ^||~
<jnc> kitty
<niran> does anyone know if there's a python library out there for dealing with deb packages?
<ogra> python-apt ?
<niran> i know i can install packages with that, but i'm trying to extract the .desktop files from packages
<fabbione> seb128: sorry i was out.. i think i found the way to get that gnome stuff fixed.. i am doing a set of test build now, but it will take sometime
<fabbione> seb128: specially because of that libxrender.la thingy
<seb128> cool
<fabbione> seb128: gtk+2.0 needs to grow a libxfixes-dev B-D
<fabbione> seb128: that will kill libxrender.la from it (on sparc at least)
<fabbione> next is libcairo
<seb128> what next ?
<fabbione> (note i am not uploading anything.. just testing locally)
<seb128> libcairo has to come before next gtk upload
<seb128> because gtk depends on cairo now
<seb128> as pango does
<fabbione> after that i can build the new gcc and see if the -Wl,--as-needed is fixed there
<fabbione> seb128: i am using a grep in /usr/lib atm to check what is still mentioning libxrender
<fabbione> just to be able to build the latest gcc
<seb128> I does the same here when I get a ftbfs :p
<fabbione> (long story about gcc..)
<fabbione> gcc FTBFS at the first run on gnat... today i did give it back for a mistake and it was building till the libxrender :)
<fabbione> go figure..
<fabbione> so i realized of all the mess
<fabbione> but i need to build gcc before i can really check the liking thing
<fabbione> it's a one day job at least
<fabbione> actually.. if i could remember how to disable the test suite... it would be only a few hours...
* ogra curses at Xcursor
<pef> bye !
<mxpxpod> I'm trying to make a backup of my laptop since my hard drive is going bad and I need to figure out how to get tar to preserve ownership of directories (NOT files)... does anyone know how to do that?
<Lathiat> mxpxpod: -fprdx iirc
<mxpxpod> Lathiat: what's r do?
<mxpxpod> and d for that matter
<Lathiat> -r is recursive
<Lathiat> no idea about -d
<Lathiat> oh
<Lathiat> nevermind me
<Lathiat> its 5am, im thinking of copy
<mxpxpod> ha
* Lathiat crawls back into a hole
<Lathiat> -p doesnt preserve them?
<Lathiat> perhaps 'dump' or 'cpio' would be usefull
<mxpxpod> what's cpio?
<Lathiat> man cpio :)
<mxpxpod> :P
<mxpxpod> Lathiat: I thought p would preserve them, but for some reason it keeps setting all the directories as belonging to root
<mxpxpod> Lathiat: when I extract as root
<Lathiat> shrug
<Lathiat> sorry
<Lathiat> :P)
<mdke> there is a good howto on the forum for it
<mxpxpod> mdke: for what?
<mdke> for making an archive of your installation
* Nafallo hugs backuppc *
<mxpxpod> mdke: could you give me a link?
<mxpxpod> I'd have to use lynx to search and I'm not really up to that
<mdke> ah no problem
<mdke> http://www.ubuntuforums.org/showthread.php?t=35087
<mdke> mxpxpod, ^
<tseng> infinity: any chance you can take a look at my buildd gtk-sharp2 issue from some weeks ago?
<mxpxpod> mdke: awesome, thanks
<Mez> why does ubuntu create /dev/dsp and no /dev/dsp0
<Mez> crw-rw-rw-  1 root audio 14,  3 2005-07-17 20:06 /dev/dsp
<Mez> crw-rw-rw-  1 root audio 14, 19 2005-07-17 20:07 /dev/dsp1
<Mez> crw-rw-rw-  1 root audio 14, 35 2005-07-17 20:07 /dev/dsp2
<Mez> shouldnt /dev/dsp be a link to /dev/dsp*
<Mez> so that you can change the sound device?
<Kamion> that would be an ecumenical^Wudev matter
<Kamion> but you can change it in udev configuration anyway, surely?
<Kamion> then it persists across reboots etc.
<Kamion> not that I know how, offhand
* Mez wouldnt know how either
* Mez wouldn't know why it isnt done like that normally like every other linux install
<schweeb> Kamion: I've been having problems similar to that for a few days with breezy... udev doesn't create /dev/psaux and /dev/input/mice
<Kamion> Mez: most other GNU/Linux distributions are moving to udev too
<Kamion> schweeb: there was a bug along those lines in Debian lately; I haven't been following it in detail but I think we'll probably just grab a newer version from Debian
<schweeb> me being lazy, I just created a shell script to make the dev nodes, lol
* Mez cries
<Mez> I need to get a sound editor working
<Kamion> you can always just move the devices around as a temporary hack
<Mez> kamion: I wouldnt trust myself doing that.
<tseng> Kamion: can i upload a bugfix mono (manual sync with debian)
<Mez> oh, you mean renaming them ?
<Mez> would that work?
<Kamion> rename == move
<Kamion> sure
<Mez> and it wouldnt break my comp?
<schweeb> Kamion: come to think of it, it started happening after your July 13th upload of 0.060-1ubuntu2 :p
<Kamion> I don't see why anything should fall over just because a sound device got renamed
<Kamion> schweeb: it was a race condition; it will be difficult to pin down to a single upload. I'm pretty confident my upload changed nothing remotely relevant to that
<Mez> Kamion; couldnt I move the compat.rules to /etc/udev/rules.d
<Kamion> Mez: not if you don't understand udev
<mxpxpod> Nafallo: does backuppc backup a computer so that you can restore the backup to a clean hard drive?
<Kamion> and no, that file is shipped by the package so don't move it around
<Kamion> tseng: rationale?
<schweeb> Kamion: yea.  that's just when it exhibited itself.  although, I can't remember how quickly before that I had rebooted my PC
<Mez> Kamion: by the looks of it though, that makes the udev similar to a devfs
<Kamion> schweeb: 0.060 proper is a more likely candidate
<Kamion> Mez: run away
<Mez> Kamion :P I'm messing
<Kamion> Mez: we use that in the installer, but only for historical reasons. don't do it just to shift a couple of devices
<tseng> Kamion: numerous bugfixes, packaging improvement (it can bootstrap itself properly)
<Mez> I jsut need to get this f**king program working so I can edit audio now I've lost Windows
<tseng> Kamion: which will fix my earlier DOA upload
<Kamion> tseng: needed for applications?
<Kamion> oh, yeah, 1.1.8-0pre3ubuntu2 didn't build
<tseng> not specifically
<tseng> but it can build on its own power.
<Kamion> tseng: ok, go ahead
<Nafallo> mxpxpod: I've not tried it. on a clean install I'm almost certain you can do that though :-).
<tseng> Kamion: thanks.
<Kamion> losing that bootstrap madness will be very nice
<Nafallo> mxpxpod: or get partimage or something like that :-)
* Mez sighs
<Mez> wtf?
<Mez> this is freaky
<Mez> this is scary as hell.
<mxpxpod> Nafallo: partimage doesn't work on xfs
<tseng> Kamion: oh sorry. i forgot to mention this needs cli-common update also
<tseng> Kamion: cli-common is just the dh_* scripts. they are fixed up to use internal mono to bootstrap
<Mez> ahah
<Mez> not so weird anymore
<Nafallo> mxpxpod: ah, oki. backuppc uses ssh+tar. should work :-).
<Kamion> tseng: bonus points if you can tell me that we can sync to exactly the Debian version
<tseng> Kamion: yes.
<Kamion> tseng: (and, if so, mail elmo, etc.)
<mdke> mxpxpod, also if you wanna good backup, try mondo rescue
<mxpxpod> mdke: mondo rescue?
* mdke nods
<mdke> dot org
<Mithrandir> Kamion: would you mind if we synced in the new pkg-config upstream version?  It fixes one cosmetic bug, one which doesn't affect us and one which can potentially cause evil build failures (freedesktop #3682).  The fix for the last bug is a one-line change.
<tseng> Kamion: we can sync cli-common as is. in mono i am doing one change ( use __thread on all archs ) since jbailey is threatening to remove pthread in breezy+1, and __thread is upstream default
<tseng> mailing
<mxpxpod> mdke: any ubuntu pkgs?
<mdke> yep
<mdke> universe
<Mez> wewt
<Mez> now I can like...
<Mez> do stuff with audacity
<mxpxpod> mdke: what's the package name? I only see mondo-doc
<Kamion> Mithrandir: looks fine
<mdke> mxpxpod, mondo
<Kamion> Mithrandir: (and a good idea)
<Mithrandir> Kamion: great, I'll mail elmo then.
<ogra> mxpxpod, mondo is x86 only
<mxpxpod> oh, that's nice
<carstenh> jbailey: ping
#ubuntu-devel 2005-07-23
<jbailey> carstenh: pong
<Mez> how do you make a diff that's like dpatch
<bob2> dpatch-edit?
<Mez> no, in the style, I mean I can use diff
<Mez> but using diff confuses me - I'm used to the stlye using +'s and -'s
<Mez> instead of using like... < and >
<bob2> diff -u
<Mez> ah, ty
<daniels> fabbione: sup
<daniels> fabbione: oh, that
<daniels> fabbione: yeah, packages depending on xrender need to be updated.  fun.
<davyd> daniels ; you around?
<daniels> davyd: yo
<davyd> daniels ; I've answered my original question through sweat and pain
<davyd> however, if I install a version of nvidia-glx I just built
<davyd> is Xorg going to like it and use it?
<davyd> seems the answer is... yes
<davyd> oh, Xserver, how I've missed thee
<mdke> elmo, ping?
<Burgundavia> elmo, ping as well
<daniels> davyd: yeah, should be fine
<daniels> heh
<davyd> hmm, why does my chroot not share my theme?
<davyd> I thought that stuff was exposed through Xsettings
<mdke> Burgundavia, he sleeps
<daniels> davyd: gconf, innit?
<daniels> davyd: probably want to be bind-mounting /tmp
<davyd> daniels: gnome-settings daemon exposes it to Xsettings from gconf
<davyd> daniels: I would appear to have done that
* daniels shrugs.
<daniels> iz gtk bug
<davyd> indeed, most annoyingly strange
<AndyFitz> ping
* davyd decides it wasn't entirely clear why X-chat was killed
<davyd> this is mighty strange
<davyd> when running my debugger in the chroot
<davyd> (gdb) r
<davyd> Starting program: /home/davyd/src/CVS/fugro/shading-scale/test/.libs/test-shading-scale
<davyd> [Thread debugging using libthread_db enabled] 
<davyd> Error while reading shared library symbols:
<davyd> Cannot find new threads: generic error
<Burgundavia> elmo, elmoooooo....
<Kamion> Burgundavia: dude, it's 3am
<Burgundavia> Kamion, yes
<Kamion> and he just got off a plane
<Burgundavia> oh yes, he was beating up jordi, I saw the blog
<mdke> Kamion, you never know what time you guys will be up :)
<mdke> HrdwrBoB, ping?
<HrdwrBoB> yo
<mdke> HrdwrBoB, hi there. Got a few minutes to chat in #ubuntu-doc?
<HrdwrBoB> yeah
<fabbione> morning
<pitti> Good morning
<fabbione> hey pitti
<seth_k> morning pitti
<seth_k> 34 minutes into Monday, here
<fabbione> pitti: i think i saw some kernel dildo's flying around in cogito
<Amaranth> I'm never going to get anything done on Smeg. :/
<Amaranth> I got Morrowind working on my computer again. That's a bigger timesink than WoW.
<swarm> is reiserfs stable under amd64? I was losting all data on root partition / that is reiserfs. The harddisk is ok as I have tested it at hw level. FS got broken due to raw two power offs. I got kernel panics and NMI watchdog lockups. 
<daniels> please use #ubuntu rather than #ubuntu-devel for this sort of question.
<Amaranth> daniels: can you do some quick fact checking for me on http://ubuntuforums.org/showpost.php?p=259915&postcount=64 ?
<Amaranth> daniels: I have a feeling I shouldn't speak about things I don't understand. :)
<swarm> daniels: I thought it was better suited to ubuntu-devel as it's related to lower-level things. thanks for redirection info.
<daniels> Amaranth: it's pretty correct, actually.  xgl isn't really a hack as such.  the concept is solid, but the implementation is very much proof-of-concept for the time being.  the problem being that right now you need another server (usually Xorg) capable of direct rendering behind it.
* Amaranth didn't say xgl was a hack
<Amaranth> that was a quote
<Amaranth> woo, i almost know what i'm talking about
<fabbione> swarm: reiserfs is a bug.
<Amaranth> Isn't there work being done on moving OpenGL into the kernel or something?
<fabbione> don't use it...
<daniels> glitz just translates cairo calls into gl calls on the client side, thus cutting out the need for cairo to translate to render ops, which then get translated to gl ops on the server side.  glitz will probably be quicker for graphics-intensive operations when it comes down to it, though.
<daniels> Amaranth: that's sort of long-term handwavy stuff, in where X no longer has intimate knowledge of the devices, but is just another GL client.
<Amaranth> hehe
<Amaranth> sounds like a fd.o spec
* Amaranth ducks
<swarm> fabbione: which journaled fs you suggest? 
<highvoltage> reiserfs!
<daniels> Amaranth: aieeeeee
<Amaranth> daniels: dconf!
<daniels> Amaranth: oh man
<Amaranth> daniels: we'll change the g to a d and shove it down the KDE dev's throats through fd.o! yay!
<Amaranth> anyway...
<fabbione> swarm: ext3
<Amaranth> I seem to remember another plan was to basically strip Xorg of everything not needed to run Xgl.
<daniels> Amaranth: tell me about it.  hopefully we'll vaguely end up with something useful
<fabbione> swarm: if you need special performance optimizations i strongly suggest you to read the mke3fs man page
<daniels> Amaranth: yeah, but we should probably kick this to another channel or something, 'cause it's rather off-topic for #u-d now
<fabbione> swarm: and tune2fs
<daniels> but not right now, I have to take off for a little bit
<Amaranth> ok
<swarm> fabbione: thanks
<pitti> Hrmpf, back from 5 kernel crashes and xorg breakage. did anybody say anything to me previously?
<fabbione> pitti: yup...
<daniels> pitti: xorg isn't broken, it's just the kernel
<pitti> daniels: did you already fix the "test -d .. && .. " bug in xlibs.postinst?
<fabbione> <fabbione> pitti: i think i saw some kernel dildo's flying around in cogito
<daniels> pitti: yeah
<cat> hey everyone
<fabbione> daniels: fix xorg.. the kernel has no bugs
<pitti> fabbione: new microrelease?
<fabbione> pitti: not released in stable
<fabbione> pitti: i just noticed some git commits that might be interesting
<fabbione> cat: if you need something you can talk to me in public
<cat> oh not really
<highvoltage> wow. i suddenly received almost 20 new edubuntu-devel messages.
<jsgotangco> its smokin' :)
<jsgotangco> JaneW, most of the existing Ubuntu documentation will get its way into Edubuntu but I'm sure there would be translation in edubuntu-specific docs when it gets written (when its already usable)
<JaneW> jsgotangco: ok
<JaneW> jsgotangco: I am just not sure how to organise the ppl who want to translate now...
<jsgotangco> JaneW, they can go to launchpad
<jsgotangco> as some Ubuntu docs that were shipped in Hoary are already there
<JaneW> jsgotangco: isn't that still 'closed'?
<JaneW> jsgotangxo: is rosetta publically usable now?
<jsgotangco> it is :)
<JaneW> ok.
<highvoltage> Does Ubuntu have something similar to the debian-policy doc? I searched the wiki and site for repositories, I need to know what the Ubuntu equivilent of 'non-free' is.
<highvoltage> Is it the multiverse?
<Burgundavia> non-free is multiverse for non-supported
<Burgundavia> and restricted for supported
<jsgotangco> JaneW, if the latest docs aren't in rosetta yet, it'll have to wait till we open up the docs for translation 
<Amaranth> That's next month, isn't it?
<daniels> Kamion: any idea where the morgue is?
<Amaranth> The morgue died. :/
<daniels> ack!
<jsgotangco> Amaranth, next month would  be murder for us tee hee
<JaneW> jsgotangco: ok, ic
<JaneW> jsgotangco: do you know anything about wiki translations?
<Amaranth> jsgotangco: It must been done next month! *cracks whip*
<Amaranth> :)
<highvoltage> Burgundavia: so if we wanted to include something like Wikipedia, which contains elements that are strictly non-free, and we want to support it, it should go into multiverse?
<Burgundavia> yes
<highvoltage> thanks.
* JaneW slots Amaranths names into all outstanding BreezyGoals...
<Burgundavia> multiverse is not a curse
<Treenaks> Burgundavia: It's not quite a blessing either
<Burgundavia> no
<jsgotangco> JaneW, Edubuntu wiki? In Moin No. But its an open wiki in the first place so anyone interested in translating should go ahead imo.
<JaneW> jsgotangco: I was just wondering how updates are tracked and kept up to date etc...
<jsgotangco> JaneW, it can be hard if its done on the wiki, at the moment Burgundavia and robitaille are cleaning up the Ubuntu wiki for dead/non-active stuff
<Amaranth> JaneW: Ouch. That's going to conflict with my Morrowind playing time.
<jsgotangco> ohhh a Morrowind player
<jsgotangco> what is it outlander
<Amaranth> at least i'm a dark elf so they don't all hate me
* jsgotangco is hyped already with Oblivion
<Amaranth> jsgotangco: uncanny valley
<Amaranth> jsgotangco: first thing i thought of when i saw screenshots, it looks too real
<Amaranth> http://en.wikipedia.org/wiki/Uncanny_valley
<jsgotangco> heh yeah
<jsgotangco> nonetheless for a game made in 2002, morrowind is still amazing
* jsgotangco goes back to work before he becomes completely OT
<Amaranth> aye
<Amaranth> hehe
<pef> hi
<teo> 'morning
<sivang> moring all
<sivang> morning, even
<Treenaks> hey sivang, Seveas 
<Burgundavia> now that this bug has been fixed, can this page die? https://wiki.ubuntu.com/ParallelPortIRQ7#preview
<\sh> infinity: pingling
<Treenaks> Burgundavia: keeping it while Warty is still "out there" might be nice
<Treenaks> Burgundavia: it does have 18 months of support..
<Burgundavia> true
<infinity> \sh : pong... long?
<\sh> infinity: hehe...could u please have a look to wine_0.0.20050628? its build, sources are on the archives, but the binaries not :( 
<Treenaks> \sh: people.ubuntu.com/~lamont ?
<Treenaks> \sh: http://people.ubuntu.com/~lamont/buildLogs/w/wine/0.0.20050628-1ubuntu1/wine_0.0.20050628-1ubuntu1_20050717-1120-i386-successful.gz
<Treenaks> hmmm
<\sh> treenaks: universe/otherosfs/wine_0.0.20050628-1ubuntu1: Uploaded by buildd+terranova [optional:out-of-date] 
<Treenaks> hmm
<sivang> hey Treenaks 
<sivang> Treenaks: do you happen to how to package a shared library?
<sivang> Treenaks: (I'm looking for a guide/tutorial or a recipie 
<sivang> )
<\sh> coffee
<Treenaks> sivang: http://dc5video.debian.net/2005-07-14/01-Shared_Library_Packaging-Junichi_Uekawa.mpeg
<Treenaks> sivang: on video :)
<sivang> Treenaks: amazing
<sivang> Treenaks: :-)
<sivang> Treenaks: do you know also about a document?
<Treenaks> sivang: uh..
<Treenaks> sivang: the packaging manual
<sivang> Treenaks: you mean the policy?
<Treenaks> uh yes
<sivang> Treenaks: I know there is a debian packaging manula, but it said to be old and out dated
<Treenaks> sivang: then mail Junichi about the slides? :)
<infinity> \sh : Did it have NEW binaries?
<sivang> Treenaks: whi is he?
<sivang> ;-)
<Treenaks> sivang: google for him :)
<Treenaks> sivang: some d-d
<\sh> infinity: it replaces a couple of binary packages into one..yes
<\sh> does anybody have a copy of the video of marks speech at debconf? the server is not responding right now :(
<Burgundavia> yes
<Burgundavia> it is 200mb
<\sh> so i need a mirror server or someone who has enough bandwith to send it to me *g*
<\sh> forget it :) working again
<\sh> 30 secs left
<Burgundavia> good talk, btw
<pitti> daniels: does the "X is broken" in the channel subject refer to the broken XKB?
<siretart> how about a torrent tracker for this? ;)
<daniels> pitti: to everything
<daniels> pitti: if you get it installed in the first place, you're doing well
<pitti> daniels: I upgraded my notebook and now keyboard is broken (no umlauts, no Ctrl+Alt+Fn to switch to consoles, etc.)
<carlos> daniels, I cannot finish its installation, I have it partial installed
<daniels> pitti: cool
<daniels> carlos: yeah
<daniels> that'll happen
<pitti> carlos: does xlibs postinst break?
<carlos> daniels, do you know where the problem is?
<carlos> pitti, yes
<carlos> since last week
<pitti> carlos: sudo vi /var/lib/dpkg/info/xlibs.postinst
<\sh> Burgundavia: yeah..I just saw the introduction now...I need some peace to watch it to the end
<pitti> carlos: right before all the "test -d ... && ...", prepend a "set +e"
<\sh> but actually I  will mirror the stuff on my server...;-9
<carlos> pitti, so it's that?, thank you. I looked into that file but I was not sure where the problem is
<pitti> carlos: the problem is that "a && b" will exit with 1 if !a
<pitti> carlos: so the proper fix for daniels would be to append a "|| true" to every line
<infinity> Or wrap them in if blocks.
<pitti> yes, but that bloats it quite severely
<daniels> it's already wrapped in a block and unbroken
<daniels> i just need to fix some other stuff and upload that too
<daniels> patience, young jedis
<carlos> pitti, hmm, it does not work
<carlos> or should I prepend it to every single line?
<pitti> no, just before the first one
<carlos> I added it just before the block of tests
<pitti> that worked for me
<fabbione> daniels: eheheh
<daniels> just add exit 0 at the end of the file
<daniels> and sudo dpkg --configure -a
<Treenaks> 01001110011011
<carlos> that worked
<carlos> hope the script didn't fail :-P
<daniels> obviously daniels > pitti
* fabbione hits inotify with a kstrdup cluebat
<pitti> daniels: hehe - well, obviously my last test succeeded, so it worked for me...
<carlos> daniels, pitti thanks, Now I'm a bit less scared about restart my X session
<pitti> Hey seb128 
<fabbione> hi seb128 
<seb128> hi pitti 
<seb128> how was the debconf?
<seb128> Hi fabbione 
<pitti> it was really cool
<daniels> carlos: there's no room for complacency, it will still be broken in other ways
<pitti> very relaxed, lots of chatter and some interesting talks
<daniels> carlos: you'll lose everything but the US keyboard keys if you don't have xkeyboard-config installed
<seb128> pitti: nice
<daniels> but then again, everyone uses a US keyboard, so it's OK
<daniels> seb128: good morning mr shakley
<fabbione> seb128: new gcc is still building.. for now i am sure i need new libcairo and new gtk+2.0 to get rid of libXrender.la
<carlos> daniels, I'm using a spanish one, but I'm writting in English so it's not a bit problem to work
<fabbione> seb128: i should be able to give you more info later today
<seb128> hi daniels 
<seb128> "mr shakley"?
<daniels> seb128: i meant to type 'shakeley'
<carlos> daniels, and I only said  that I'm a bit less scared. ;-)
<carlos> only a bit
<seb128> carlos: don't upgrade xorg 
<seb128> carlos: I've seen many GNOME guy complaining this WE because they couldn't install the keyboard stuff 
<daniels> seb128: yeah
<daniels> seb128: i've just fixed that for carlos :P
<daniels> carlos: you'll need to install xkeyboard-config with --force-overwrite, unless you install it in an hour or so when the new version is in the archive
<seb128> fabbione: k
<seb128> daniels: sorry but I don't get the "mr shakeley" reference neither :p
<fabbione> seb128: remember to add the libxfixes-dev B-D
<carlos> daniels, I will wait for the new version
<seb128> fabbione: what's this? a new lib?
<carlos> seb128, I have that broken since last week, so your warning comes too late 
<carlos> :-P
<seb128> carlos: ah ah
<daniels> seb128: i can't remember where it's from
<seb128> carlos: you have not learnt yet to not upgrade xorg?
<daniels> quit moaning and fix my panel already :P
<seb128> carlos: I still have -33 :)
<carlos> seb128, I love the risk
<seb128> carlos: and now you enjoy what it gives :p
<Burgundavia> updating is fine, as long as you don't restart your X server, you are fine
<sivang> daniels: what's wrong with the panel? I can't see anything wrong with it ;-)
<daniels> sivang: it used to hang my machine
<daniels> and it will do so again as soon as seb128 marks it RESOLVED/FIXED
<carlos> seb128, anyway, I hope I will get my new laptop tomorrow so I can move back to Hoary :-)
<seb128> daniels: k, I'll close it as WORKSFORME so :)
<sivang> daniels: hehe
<sivang> seb128: lol
<fabbione> seb128: it's another bit that has been splitted from xorg
<daniels> in all seriousness, though, xkeyboard-config really does need all the testing it can get
<fabbione> seb128: so it's not pulled in automatically anymore
<seb128> fabbione: and Build-Depends are supposed to break?
<daniels> it's a different upstream and they say things are broken
<fabbione> seb128: well dude.. it's xorg :P
<daniels> seb128: uh, what's broken?
<seb128> daniels: GTK bog, it needs to b-d on libxfixes-dev
<carlos> pitti, I just moved so I have all my gadgets inside boxes or in my parent's house, so the check you asked me will take a bit to be done
<fabbione> daniels: gtk+2.0 needs another B-D
<daniels> seb128: does it use Xfixes.h directly?
<daniels> seb128: if not, that's my problem
<seb128> gdk/x11/gdkcursor-x11.c:#include <X11/extensions/Xfixes.h>
<seb128> yeah, it does
<daniels> iz gtk boog
<seb128> what I said :)
<siretart> daniels: i read on debian-devel that the libglu c++ transition seems unnecessary and debian's xorg libglu packages will provide the older package names. what does this mean for us ubuntus?
<Burgundavia> seb128, https://bugzilla.ubuntu.com/show_bug.cgi?id=11908
<Burgundavia> does the .12 kernel have inotify on by default?
<sivang> Xfixes is like a xorg pkg for easing the breakage on the modularization process ?
<sivang> s/pkg/lib/
<daniels> siretart: it means I'm going to sync up with their changes
<daniels> sivang: heh, no
<sivang> daniels: becasue it sounded funny :-)
<seb128> Burgundavia: that's a question for fabbione, but probably
<daniels> sivang: provides functions for changing the cursor and the Region type
<sivang> daniels: Region type?
<infinity> Uhh, what?... How was the libglu1 -> 1c2 transition "unnecessary"?
<siretart> daniels: so the https://wiki.ubuntu.com/MOTUGLUTransition becomes completly uncessary?
<daniels> sivang: yeah, it's just a data type that expresses a region
<siretart> unnecessary, even
<daniels> infinity: libglu has a pure C ABI
<daniels> infinity: the fact it's in C++ is an implementation detail
<sivang> daniels: ah, you mean, display region wise
<daniels> infinity: myself and vorlon went over it with objdump
<infinity> daniels : Ahh, so its linking to libstdc++ is irrelevant.
<Burgundavia> fabbione, does the .12 kernel do inotify by default?
<daniels> sivang: right
<daniels> infinity: correct
<infinity> daniels : Well, uh.  Oops. :0
<daniels> infinity: which means that both xorg and mesa need to provide libglu1 as well as c2
<fabbione> Burgundavia: it did since the beginning
<Burgundavia> fabbione, ok
<fabbione> Burgundavia: but now inotify is upstream in .13 so i am backporting that version to .12
<infinity> daniels : Why would they need to provide c2 as well?  I can rebuild everything to get the proper shlibs (again) and just make it right.
<fabbione> Burgundavia: it's pointless for us to keep an old unmaintained version around
<fabbione> but it's giving me the creeps
<Burgundavia> fabbione, fun
<daniels> infinity: makes it easier, no?
<fabbione> yes.. specially when to edit a patch for a line takes almost 40 minutes
<infinity> daniels : I suppose it does, but at the expense of pointless cruft.
<fabbione> i need to get 16GB of RAM on this machine to do it at a decent speed
<daniels> infinity: sure
<infinity> daniels : I guess it's less effort for me if you go the cruft route, though.
<daniels> infinity: debian is going to keep the c2 cruft because they're Debian, but we can fix it in Ubuntu if we want.  your call.
<infinity> daniels : I can fix mesa right now.
<daniels> infinity: tell me what to do with xorg.
<infinity> daniels : Why would Debian want the c2 cruft?  They just started the transition ffs.
<daniels> infinity: take it up with vorlon
* infinity grumps.
<infinity> siretart : Alright, after some discussion with the Debian side of things, looks like your transition just needs to be reversed.
<jsgotangco> j #ubuntu-ph
<jsgotangco> ngayy
<infinity> siretart : We'll update xorg and mesa to have the old shlibs again (no c2), and then anything that currently depends on libglu1c2 prett much MUST be rebuilt before breezy, so we can drop the c2 provides from the libraries if we so choose.
<siretart> infinity: I'm pretty confused now. Could you please update https://wiki.ubuntu.com/MOTUGLUTransition with the correct build dependencies?
<siretart> else I'm guessing and pinging you again ;)
<infinity> siretart : I'll ping you back after mesa and xorg have been fixed.  No point in doing anything about it right now, except to tell you "stop the GLU transition".
<infinity> siretart : I'll need to get main sorted first.  Which shouldn't take long.
<daniels> fwiw, libglu1-xorg will likely just crawl into a hole and die for breezy
<infinity> daniels : So, if your next xorg can change the shlibs back, and add the extra provides, we'll go from there.  We can drop the c2 provides in a month.
<daniels> infinity: err ...
<daniels> ok
<infinity> Crawl into which hole?
<daniels> keep libglu1c2 in shlibs
<daniels> ?
<daniels> i don't know -- any
<infinity> No, shlibs should change to libglu1
<siretart> infinity: I cannot do ubuntu stuff for the next 3 days anyway, but I'll be hanging around here just in case. Will update the wiki with a warning
<infinity> Change provides to libglu1, libglu1c2
<daniels> infinity: 'kay
<pitti> argh, fabbione, stop DoSing davis
<daniels> infinity: (i'm rather tired)
<infinity> daniels : Whatever hole it plans to crawl into, it better still work properly from there, cause half the world build-deps on it.
<infinity> daniels : Alternately, I can make the changes tonight when I do mesa, as long as you merge my changes into your next upload.
<daniels> infinity: libglu1-mesa, yo
<daniels> infinity: make what changes?
<infinity> daniels : Flipping the shlibs.
<infinity> daniels : And bringin back the old provides.
<infinity> daniels : You really are tired, aren't you? :)
<daniels> infinity: will be done tonight
<daniels> yeah
<infinity> daniels : And mesa isn't an option, unless you want to change the build-deps on a mess of packages (or make libglu1-xorg-dev depend on libglu1-mesa, I guess)
<fabbione> does that mean that breezy will be unbuildable for the next 2 days?
<daniels> infinity: don't they b-d on libglu1-xorg-dev | libglu-dev?
<infinity> fabbione : No, this will be done right the first time.
<daniels> infinity: and if mesa suddenly becomes the sole provider of libglu-dev ...
<infinity> daniels : Isn't mesa in universe..?
<daniels> we can fix that
<daniels> it comes into main for breezy anyway
<daniels> i think I'll have to start maintaining it
<daniels> unless we decide that GL support is for suckers
<siretart> MOTUGLUTransition updated
<infinity> daniels : sbuild may or may not have a conniption fit about losing the first option in the alternate build-dep.
<infinity> daniels : Not that sbuild is intentionally stupid about these things, to keep the world consistent.
<infinity> s/Not/Note/
<daniels> infinity: oops
<daniels> infinity: well, we can check it out at a later date
<infinity> If the two are binary compatible, I'd prefer to just leave both in for breezy and kill off the xorg variety in the first two days of breezy+1 devel.
<daniels> there will be no xorg variety in breezy, unless I get hit by a bus and modularisation stops
<daniels> currently we just copy in the mesa source to the monolith; in the modular world, we just build Mesa for all our GL* needs
<infinity> ... Or, mesa-dev can provide xorg-dev
<infinity> Assuming no one has a versioned build-dep on xorg-dev, which seems unlikely, given that all those build-deps were just added.
<doko> daniels: was the xorg keyboard driver replaced by something else?
<daniels> versioned deps on xlibmesa-gl-dev are far more likely
<infinity> daniels : Hit me with a small bat when you tear out xorg-dev, and we'll make sure all is well.
<doko> just trying to update xorg on amd64
<daniels> doko: make sure you have xserver-xorg-input-keyboard installed
<daniels> may be -input-kbd
<carlospc> An easy question: The udebs that are in the arch of colin (for example) will pass to universe and then to main???
<doko> daniels: still getting a (EE) Couldn't load XKB keymap
<daniels> doko: got xkeyboard-config installed? is /etc/X11/xkb/xkbcomp a link to a valid xkbcomp executable?
<ogra> doko, you noticed the buildds were down ? i only got half of X updated yesterday (havent looked today yet)
<ogra> (i.e. the libs are at -42 already, but the rest is -36 or something)
<doko> daniels: the link is ok, but xkeyboard-config does conflict with xbase-clients
<daniels> doko: --force-overwrite
<doko> hmm, now the gnome session is missing
<daniels> iz gtk boog
<doko> maybe it was a bad idea for an upgrade
<doko> Ctrl-Alt-F? doesn't let me switch to a text console either
<daniels> yeah, that will happen when you can't load the XKB config
<daniels> did you restart the server after installing xkeyboard-config?
<doko> yes, I did restart gdm
<ogra> doko, did you select gome as a session... i have to do that on my x86 machine, else the session doesnt load
<j^> doko same here and bugs 12695, 10939, 10695
<doko> ogra: gnome session doesn't exist anymore in the gdm menu
<ogra> ouch
<\sh> doko: try to reinstall ubuntu-desktop?
<\sh> for me it worked
<sivang> yay, X is working again
<\sh> sivang: ????
<sivang> \sh: was borked before the last update I did just now, and I dist-upgraded, and it's working
<sivang> \sh: (just upgrade didn't help it)
<\sh> sivang: u mean the last xkeyboard* and x11proto* uploads from daniels?
<sivang> \sh: not, I had the machine last updated about a week a ago, and X couldn't start. I dist-upgraded and it's working ok now, besies the XKB configuration.
<\sh> sivang: so u running now -42?
<seb128> elmo: glib2.0 (experimental) inkscape hardware-monitor meld anjuta myspell syncs please
<pitti> thom: ping
<jmr> hi - anyone in ubuntu land built the gnome stack with lazyload linker directive to reducestartup time ? Vague memory Jeff had postedon this early in the year but can't track down the post. Thanks - JR
<sivang> \sh: XKB ?
<fabbione> Kamion: what's the deadline for Colony 3?
<Kamion> fabbione: none yet
<sivang> Kamion: would you say booting breezy PPC under an LPAR would be the same like on a regular Apple Mac ? 
<fabbione> Kamion: ok thanks
<Kamion> sivang: not at the lower levels
<Kamion> powerpc subarchitectures differ fairly substantially
<pitti> Kamion: booting "install" on the current amd64 dvd results in live system boot <- already known or do you want a bz report for this?
<Kamion> pitti: report, please
<pitti> ok
<Kamion> pitti: I see the problem, anyway ...
<sivang> Kamion: k, I'm still researching how we can make the iso boot cleanly under the LPAR, looking at some of the fedora resources wrt to it. 
<ogra> Kamion, didnt you set u a cronjob for the edubuntu builds ? there is still only the iso of the 15th...
<ogra> s/u/up
<Kamion> ogra: no, I didn't - done now
<ogra> thanks
<ogra> also, cold you wave through edubuntu-meta ? its still sitting in NEW
<Kamion> ogra: source NEWed, at least
<Nafallo> hmm. any chance to get smartmontools lack of SG_IO fixed before the release?
<ogra> Kamion, ta :)
<Nafallo> there is a new stable upstream and a backported patch in debian bts.
<ogra> Nafallo, isnt that universe ? 
<Nafallo> ogra: nope. I run it on my server, so it has to be main ;-).
<ogra> ha ha
<Nafallo> apt-cache policy agrees :-)
<ogra> hmm
<ogra> Nafallo, a patch shouldnt clash with UVF, but probably the new upstream is the better choice, do you know what debian plans there ?
<Nafallo> ogra: nope. not yet anyway. the experimental release is in debian experimental.
<ogra> hmm, experimental...
<Nafallo> debian bug #269051 fwiw :-)
<ogra> Nafallo, could you test the atch against the current package ?
<ogra> s/atch/patch
<fabbione> pitti: ping?
<ogra> (since i dont use smartmontools)
<pitti> Hi fabbione 
<Nafallo> ogra: I can test if it builds, but my problem is at the server which run hoary :-). I could build a package for hoary and dpkg -i on my server though.
<pitti> fabbione: btw, no mails wrt the thing you mentioned
<fabbione> pitti: ok.. let see what they say
<fabbione> pitti: do you still have the RedHatClusterSuite review?
<fabbione> (on the wiki i mean)
<pitti> fabbione: sure, it's meant to be there forever
<pitti> fabbione: https://wiki.ubuntu.com/MainInclusionReportRhCluster
<fabbione> pitti: thanks..i just couldn't remember the link
<fabbione> pitti: can we update it together or are you busy?
<pitti> fabbione: I'm currently fighting with the Hoary ffox security update
<fabbione> pitti: ok. i am going offline for a nap
<pitti> fabbione: that will still need my brain for at least two days
<fabbione> pitti: i will ping you later?
<fabbione> AH
<pitti> fabbione: so if it's anything urgent, I can switch context :-)
<pitti> fabbione: sure, I'm here for another 4.5 hours
<fabbione> pitti: nah it's not urgent.. i need to review with you the status
<fabbione> for that and OCFS2
<pitti> fabbione: ok, then I'd rather do that after ffox is settled
<fabbione> since i would like to get them in main...
<fabbione> and tag ClusterFileSystem as Deployed :)
<fabbione> pitti: ok.. let see how it goes later...
<fabbione> i can wait tomorrow.. but no longer than mid-week
<fabbione> later &
<ogra> Nafallo, ok, then a build test would be nice for now...
<Nafallo> ogra: oki. then I'm on it :-).
<ogra> great, thanks
<ogra> :)
<\sh> wow
<\sh> just finished the speech of mark...
<mdke> url?
<highvoltage> \sh: which mark?
<Nafallo> highvoltage: sabdfl :-)
* highvoltage always thought that sabdfl made up his speeches in real time
<\sh> highvoltage: please have a look on the planet...whiprushs post...
<Nafallo> highvoltage: or \sh's post ;-)
<\sh> i mirrored only..
<\sh> and my traffic is increasing 
<\sh> i don't mind ;)
<highvoltage> ok. i'll go check it out.
<ogra> the talk is very good.. i watched it this morning
<\sh> ogra: did u ever read robert 'bob' youngs book: Under The Brim?
<sivang> \sh: speech from debconf / udu ?
<\sh> sivang: debconf
<ogra> sivang, yes
<highvoltage> now, where's that video of sabdfl and mdz singing?
<ogra> \sh, nope
<sivang> \sh: cool, where can I download it from?
<retrix> hi ogra
<jnc> so ... uh.   xvinfo is missing amd64... for any particular reason?  i just built it myself without problems
<\sh> ogra: i hope i have it in my flat...you should read it..some thoughts are matching ,-)
<ogra> highvoltage, someone has taken it off the ne :(
<retrix> wondering if youve had a look at my ndiswrapper gui package?
<Nafallo> jnc: buildds dead
<Nafallo> (still dead) ;-)
<jnc> Nafallo: i built it myself without problems
<jnc> what do you mean it's dead
<ogra> retrix, i have only (re)set up my i386 yesterday, i'll test it today...
<jnc> ;)
<ogra> retrix, sorry for the lag
<retrix> ogra, ok np
<ogra> retrix, i'll mail you the results :)
<Nafallo> jnc: yes. the buildmachines are still not working. haven't been for a week (atleast it feels like).
<highvoltage> ogra: :(
<jnc> oh!
<retrix> ogra, thanks
<mdke> sivang, planet, see jorge castro's post for the ogg
<Nafallo> jnc: they needs elmo-love :-).
<jnc> Nafallo: now that is a different thing than what i thought you meant. good to know
<jnc> sad to hear about
<jnc> say, if xlibs is only half-configured,  what's that file i could tweak and make it configure manually?
<jnc> i forgot the location, it was some dpkg cached configuration script
<jnc> maybe /var/lib/dpkg/info
<pef> jnc: backup /etc/x11/xkb, empty it, then xbase-clients will configure normally, then install xkeyboard-config
<jnc> hmm
<jnc> okay, thanks
<jnc> i had gotten that far, and then was stuck what to do about /etc/x11/xkb
<jnc> :)
<jnc> pef: is xlibs configuration script incorrect?
<Nafallo> ogra: built and installed on breezy. I'm about to compile it and test on hoary as soon as my chroot is ready :-)
<ogra> great :) did it complie cleanly ?
<Nafallo> ogra: yepp :-)
<ogra> yay
<pef> jnc: package mainly broken :) https://bugzilla.ubuntu.com/show_bug.cgi?id=12695
* Kamion fixes a minor whoopsie in cdimage which, er, caused it to totally forget to sync the archive
<ogra> heh
<ogra> Kamion, who cares if a third of the buildds is missing anyway...
<\sh> amd64 is obsolete...just use ia64 ,-)
<Nafallo> \sh: baah. and that's all I say ;-).
<ogra> its a tme where broken infrastructure doesnt really matter...
<Nafallo> ogra: installed on my server :-)
<ogra> ....until its heart is in place again...
<\sh> Nafallo: *eg*
<ogra> Nafallo, works fine ? 
<Nafallo> ogra: seems like it.
<ogra> great, can you put your fixed breezy package online anywhere ? 
<\sh> damn
<Nafallo> ogra: sure. hold.
<\sh> I just wondering why xmms-coverviewer is not accepted, no mail nothing...yeah...I just uploaded the same version :( instead of build1 *gnah*
<Nafallo> ogra: http://www.magicalforest.se/tmp/smartmontools_5.32-3ubuntu2.diff
<ogra> Nafallo, thanks
<Nafallo> ogra: and sent a mail to the maintainer asking about the new stable upstream also :-). should be in your mailbox.
<ogra> Nafallo, cool, youre the best :)
<Nafallo> ogra: naah. I got other packages not fixed for a long time :-/. I could probably lame the weather though ;-).
<Nafallo> s/lame/blame/
* jnc grumbles
<jnc> "why did i feel compelled to reboot!"
<jnc> hehe
<jnc> well i hope you guys get a working build server and make the progress you'd like to
<Kamion> \sh: slightly more detail than "rebuild cause of UnmetDeps" would be nice in changelogs - maybe which library dependencies have been replaced by which other library dependencies, or whatever
<\sh> Kamion: the reason is correct...when I'm changing something, I would put something else in what i changed, it's a single rebuild only (see: w.u.c/UniverseUnmetDeps)
<\sh> actually the list quite strange anyways...
<Kamion> \sh: nevertheless, there is certainly more detail you could include, which would be helpful.
<Kamion> (also, "because" not "cause")
<sivang> seb128: in the gedit patch, I had to rerun autoconf to recreate the configure script for gedit - so autoconf would add the required stuff for linking against the launchpad lib, however, as you can see in the debdiff, that created a lot of differences in some of the auto created scripts compared to the original source. Any way you know around this?
<seb128> sivang: running autoconf from debian/rules
<sivang> seb128: you mean, as in debian/rules auto* ?
<seb128> yeah
<seb128> but I don't like running the autostuff when not required
<sivang> seb128: well, I think we have to in this case, any other way to work against the lib?
<mdke> ciao thesaltydog 
<thesaltydog> ciao matt
<seb128> use a autoconf patch, but it needs to be updated for new versions which sucks
<seb128> jamesh: around?
<jamesh> seb128: yeah
<seb128> jamesh: hey :) About the LaunchpadIntegration seems we lack some com between sivang/you and other people/me :p
<seb128> jamesh: sivang pointed me to a baz archive with a lib for that ... is that ready to be packaged? 
<jamesh> seb128: I suppose it could do with some initial packaging -- it is missing gettext foo and some error checking
<seb128> jamesh: k, this really needs to move, I'll package the lib today and sivang is working on some patches
<adamh> Where can I find QT4 development packages for ubuntu?
<seb128> jamesh: what should we do to build with the lib, running autoconf on every package or is there a non-ugly way to abuse a .pc from something else for this?
<\sh> Kamion: k
<jamesh> seb128: the alternative would be to include the configure file changes in each patch
<seb128> jamesh: which would mean a patch update on new versions because configure is quite likely to change
<jamesh> seb128: maybe.  It depends how much the configure script changes from release to release for an app
<jamesh> which is a pain
<bddebian> Morning
<sivang> seb128: sorry, I don't understand, do we need to patch against the .pc file? (to my best understading, we need only have one line change per each configure.ac/in file, we shouldn't change a lot in the future)
<jamesh> sivang: the problem seb is bringing up is that either (a) the patch against individual packages needs to include the changes to the generated configure file or (b) the package build needs to rerun autoconf after applying the patch
<jamesh> sivang: patches to configure files can be a bit more fragile than the associated configure.in/ac changes
* jnc whistles disgruntedly, building packages
<jamesh> seb128: if the app has AM_MAINTAINER_MODE in its configure.in, then patching configure.in and rerunning autoconf won't cause all the Makefile.in's to be rebuilt
<jamesh> seb128: and we're not using any extra autoconf macros, so the already generated aclocal.m4 should work fine, so I don't think we'd run into unknown macro problems (hopefully)
<seb128> jamesh: k, seems to be the best option so, thanks
<seb128> running autoconf should be fine
<Riddell> daniels: is iceauth ment to be in xbase-clients or is it hiding elsewhere now?
<seb128> Mithrandir: how did you get the new pkg-config to Ubuntu?
<sivang> jamesh: sure, we merely use PKG_CHECK_MODULES, right?
<zyga> <
<sivang> seb128: I see, well, I think that's basically what I did for gedit, but as I Noted to you , debdiffing it afterwards showed alot of changed in the auto* stuff
<pitti> zyga: interesting :-)
<sivang> seb128: but I just changed the .in file, and rerun autoconf before debuild -S
<jamesh> sivang: yeah.
<seb128> pitti: any plan to fix language-packs soon?
<seb128> pitti: upstream will start needing a translated GNOME know to work for GNOME 2.12
<pitti> seb128: depends on when I can get the first update from Rosetta
<seb128> s/know/now/
<seb128> carlos: ping ?
<carlos> seb128, pong
<seb128> carlos: cf was I just asked to pitti
<pitti> carlos: is Rosetta ready for exporting a breezy tarball?
<carlos> pitti, yes
<highvoltage> elmo: any news on that hosting for edubuntu?
<seb128> daniels: around?
<carlos> pitti, I could give you hoary tarballs already, breezy needs to wait one or two days until all .po files get imported
<pitti> carlos: do you have time for this tomorrow? I'm busy as hell right now
<carlos> pitti, I'm always busy so it's better if you just ask me when you have sometime.
<carlos> Anyway, I will try to get some spare time for you.
<pitti> carlos: so could you please build me a hoary tarball when you have time? I could probably do hoary updates tomorrow
<pitti> carlos: that tarball will also be enough for me to device how to continue with the breezy langpacks
<seb128> I don't care about hoary updates :p
<carlos> pitti, ok, will do
<thom> pitti: started my new job today; don't expect responses until out of work hours now
<carlos> seb128, we don't care about you :-D
<jnc> yay i have X11 up again
<jnc> had to build a few packages
<jnc> new 'kbd' driver does not properly map out some dead keys
<jnc> oh well
<seb128> carlos: k, noted
<carlos> seb128, ok, ok, it's just a joke
* carlos doesn't like to sleep outside the room next conference :-P
<seb128> :)
<pitti> seb128: would you be able to merge the new 1.0.5 firefox from debian?
<seb128> working another 2 hours after my 15 hours/days probably
<seb128> who needs to sleep anyway
<seb128> why? :)
<ogra> seb128, if you can do it in 2h youre the man for it :)
<seb128> I've not said it would take 1 day :p
<ogra> :)
<jnc> thanks again for the suggestions Nafallo , pef
<Mithrandir> seb128: I asked for it to be synced.
<seb128> Mithrandir: where did you ask?
<seb128> Mithrandir: I'm trying to ping elmo on IRC for syncs for 10 days but no luck
<Treenaks> seb128: blame debconf
<ogra> Treenaks, debconf is over
<Mithrandir> seb128: I dropped him a mail last night.
<seb128> Treenaks: I don't complain, but some guy manage to get syncs, so just wondering where is the right place
<seb128> jdub: ping
<jdub> yo
<elmo> seb128: remind me of what you wanted synced?  but when I'm not on IRC, mail is a good bet...
<seb128> jdub: l10n list? Sorry to bother you with that, but l10n guys could really use it
<eruin> any pending kernel updates?
<seb128> elme: "elmo: glib2.0 (experimental) inkscape hardware-monitor meld anjuta myspell syncs please"
<seb128> ups, s/elme/elmo/
<seb128> elmo: thanks, k noted for mails next time
<jdub> seb128: sec
<elmo> seb128: done
<seb128> thanks
<elmo> doko: ?
<doko> yep
<seb128> pitti: I can probably have a look on the firefox sync this afternoon if you want, other stuff can wait a few hours
<doko> seb128: if you do the firefox update, please build libnss and libnspr from the firefox source. kthxby
<doko> elmo: here
<elmo> doko: how does this wxwidget's upload interact with the upstream version freeze?
<seb128> doko: hum, no, no way I start forking the package
<doko> wxwidgets2.5 was removed from hoary/breezy, to be replaced by 2.6. I did work with the upstrem/Debian maintainer for an upgrade path to 2.6. we should get packages built against 2.6 for breezy
* Amaranth cheers
<elmo> doko: is there any documentation to that effect?  (e.g. a spec) if not, pls mail mdz, colin and cc me, and ask for UVF exemption
<Amaranth> 2.5 was removed from hoary? I thought it was too late.
<doko> elmo: ok
<ogra> isnt that universe anyway ?
<ogra> doko, or do you plan to include wx in main with 2.6
<bddebian> tritium!!
<doko> ogra: we do want to have a python-ide in breezy. this will be eclipse-pydev, or a simpler one, i.e. boa-constructor or spe (both require wx)
<tritium> hello bddebian :)
<ogra> doko, ah, that requires a move tzo main then, i understand...
<\sh> eric3? ,-)
<ogra> SPE !
<doko> eric3 is qt ...
<ogra> yep
<ogra> thats why \sh likes it ;)
<\sh> say it like this: it works
<\sh> not as big as eclipse stuff
<ogra> \sh, as gvim works *G*
<\sh> and qt is in main 
<\sh> but gvim is not a python ide in a common sense
<doko> eclipse-pydev works as well
<doko> ... (with 2GB of RAM at least ;)
<ogra> hehe
<\sh> and boa-constructor...it's a *censored* from handling and feeling it's horrible (IMHO)
<doko> seb128, thom: do you know, where to fetch the source for the firefox 1.0.6 release candidate/prerelease?
<\sh> well...when breezy comes out, I heared everybody gets 2GB extra memory for every shipment of free cds, no? ,-)
<seb128> doko: I don't know anything about firefox, I don't even use it
<doko> crap, developers should use the tools they dump on their users ;)
<\sh> so...eric3...that's settled ,-)
<ogra> doko, especially maintainers of packages, even if they just adopted it ;)
<Amaranth> doko: cvs?
<seb128> doko: I dump epiphany-browser on users and I use it :p
<\sh> ogra: sorry..but I'm using it...but not dumping it to the users...it's universe, it's their free will to use it or not...when they're not using it, those users will go to hell ,-)
<doko> Kamion: I just read, that gcc-4.0.1 requires gettext 0.14.5. Is it ok to update/sync from unstable?
<highvoltage> cool. sabdfl mentioned the shuttleworth foundation at debconf.
<Kamion> doko:    gettext | 0.14.5-1ubuntu2 |        breezy | source, amd64, hppa, i386, ia64, powerpc, sparc
<\sh> highvoltage: why not?
<highvoltage> \sh he normally doesn't. ;)
<doko> Kamion: oops, old chroot
<seb128> pitti: ping?
<pitti> Hi seb128
<seb128> pitti: hey again :p Should I look on the firefox merge so?
<pitti> seb128: well, this wasn't a command :-) only a question whether you know about the Ubuntu changes
<pitti> seb128: we need 1.0.5 in Breezy to fix a ton of security stuff
<mgalvin> Kamion, do you happen to know of any good docs on preseed that you may be able to point me at?
<seb128> pitti: nop, no clue, but the Debian changelog is small, I should find my way to apply that to the current ubuntu package
<fabbione> seb128: can I or can you please upload libcairo and gtk+2.0 in sequence so that i can build gcc-4.0 ?
<highvoltage> hehe. seb128 the gnomanator.
<fabbione> seb128: the linking problem is a glibc bug
<seb128> fabbione: nice
<seb128> fabbione: I'll update cairo to 0.5.2 when it's here
<fabbione> seb128: yeah just 24 hours to get there...
<Kamion> mgalvin: erm, the installation manual's about the best I have
<seb128> ie: sometime today
<\sh> going home...bbl
<fabbione> seb128: sure.. today is fine
<fabbione> seb128: can you also make gtk+2.0 ?
<seb128> fabbione: current gtk doesn't use cairo yet
<seb128> next upload will
<fabbione> seb128: doko is going to upload gcc-4.0 later
<mgalvin> Kamion, ok thnx
<seb128> gtk should not been an issue
<fabbione> seb128: i know.. but I need a non libXrender.la gtk+2.0 :)
<fabbione> seb128: it's question of a clean rebuild.. no changes needed (otehr than the B-d)
<doko> seb128: are 0.5.1 and 0.5.2 API compatible?
<seb128> doko: probably not
<seb128> doko: but as said before, I don't care :p
<doko> did I mention, that I love cairo?
<ogra> elmo, any ETA when we'll have amd64 love again ?
<seb128> doko: they stated it'll not be API stable before 1.0
<doko> seb128: so, you'll sync with the package naming from unstable?
<seb128> doko: no, I'll keep doing what I was doing
<seb128> ie: upload need version with the 3-4 stuff than need a rebuild
<seb128> nobody even noticed on the previous upload
<doko> let me know, when you do have a test package
<seb128> doko: a "test package"? what's this?
<seb128> doko: I'll upload the new version when it's here
<elmo> ogra: the buildds are alive; just need laminity love now, AFAIK
<ogra> elmo, yay
<ogra> elmo, i just discovered i have to hug you to become a DD !
<bddebian> heh
<fabbione> ogra: slightly more than that :)
<elmo> ogra: that was a slide typo
<bddebian> Isn't funny how some people's nicks affect you.  Whenever I see elmo, I can't get Elmo's World out of my head. :-)
<fabbione> you need to hug also some AM :)
<fabbione> hey elmo
<elmo> it said you have to hug me if you DON'T want to become a DD
<ogra> hehe
<fabbione> elmo: can you kindly NEW some of the sparc binaries that have been uploaded a while ago?
<lifeless> elmo: you still doing DAM stuff ?
<mdke> elmo, we really need some docteam love... if you can find the time, it would be appreciated
<doko> crap, alt-gr doesn't work anymore
<pitti> doko: neither does ctrl+alt+Fn nor umlauts
<sivang> seb128: how do you trigger autoconf run before build, if patching only the .ac file in the debian/pathch ? (trying to recreate the gedit patch)
<pitti> sivang: don't. patch the configure file together with .ac
<Kamion> (and ideally make sure the configure timestamp >= the configure.ac timestamp)
<pitti> right
<Amaranth> wtf, the totem depends on totem-gstreamer only now?
<Amaranth> err, minus the
<Kamion>  Package: totem
<Kamion>  Version: 1.1.3-0ubuntu3
<Kamion>  Depends: totem-gstreamer (= 1.1.3-0ubuntu3) | totem-xine (= 1.1.3-0ubuntu3)
<Kamion> although the description disagrees ;-)
<Amaranth> ok, synaptic is stupid
<Amaranth> rather than upgrade totem-xine to 1.1.3-0ubuntu3 it wanted to remove 1.1.3-0ubuntu2 and install totem-gstreamer
<seb128> sivang: the patches are applied before the configure, so you can run autoconf between patches and ./configure
<sivang> seb128: what about pitti's suggestion? is that how you are going to do that?
<seb128> what pitti suggestion?
<seb128> updating firefox to 1.0.5?
<pitti> seb128: <pitti> sivang: don't. patch the configure file together with .ac
<seb128> oh, that
<seb128> configure is quite of a moving target no?
<seb128> not at the same point as patching a Makefile.in, but still
<seb128> pitti: I want to avoid having to redo the patches on every new version if not required
<pitti> seb128: as long as it's tarball.mk, thus doesn't destroy source, it's also fine
<sivang> pitti: but you would still have to redo the patches, if I understand that .mk ;-)
<seb128> sivang: go for the configure/configure.in patch combo
<seb128> pitti has a point
<seb128> tarball.mk sucks, so use a patch
<sivang> seb128: k, your instructions are my commands :-)
<fabbione> seb128: i think i even have a fix :)
<seb128> fabbione: for the libc bog?
<fabbione> yeps
<fabbione> building the glibc now.. as usual i will know by tomorrow :)
<sivang> pitti: thanks 
<sivang> seb128: so, just to make that straight, (a) Patch the .in script to be able to run autoconf on demand, (b) patch the supposed to be created configure script , as if autoconf was rexecuted in the build process. Am I following you?
<pitti> sivang: right; please make sure to use the correct autoconf version to minimize the diff
<pitti> sivang: also make sure to remove the autom4te directory after running autoconf
<doko> Kamion, elmo: please accept an exception from the UVF for isdnutils. I didn't get to it earlier, then sync it from unstable
<doko> daniels: why is /usr/lib/libXrender.la missing from libxrender-dev?
<Amaranth> ha!
<Amaranth> 'breezy was scaring for about...4 weeks?'
<Amaranth> err, scaring
<Amaranth> fuck
<Amaranth> scary
<highvoltage> it's still scary!
<Amaranth> exactly
<Nafallo> naah. not scary. fun! :-)
<highvoltage> elmo: how are things going for the hosting of the edubuntu site?
<highvoltage> Nafallo: yes, it developes random features ;)
<hughsie> ogra: how goes things?
<Amaranth> wow, some of the things sabdfl is talking about with communication between ubuntu and debian are the same as ubuntu backports and ubuntu
<seb128> sivang: what pitti said
<seb128> pitti: k, so nobody works on firefox 1.0.5? To be sure before duplicating work
<pitti> seb128: no, currently we don't have any mozilla lover
<pitti> seb128: I'm doing the security stuff right now, but that takes a while
<seb128> let me clear, I'll do this sync but I'm not a firefox maintainer :p
<pitti> seb128: hehe :-)
<pitti> seb128: this will lead us to hell anyway, we still need new tbird and mozilla upstreams
<pitti> seb128: maybe we should just demote mozilla to universe, it's a PITA
<bddebian> heh
<sivang> seb128: you need a firefox maintainer? ;-)
* sivang runs away for even offering himself
* dieman busy watching the ubuntu talk from dc5
<seb128> sivang: yeah, want to maintain it?
* highvoltage would be a firefox maintainer, if he new how
* highvoltage joined debian-mentors today, so it won't be too long ;)
<seb128> elmo: sync for glib2.0 (2.7.3) from Debian incoming please
<sivang> seb128: is it hard? O:-)
<seb128> thom managed to do it, so that's probably easy :p
<sivang> heheh
* seb128 runs from thom 
<Amaranth> how come thom doesn't do it anymore?
<sivang> seb128: I can try start learning the current packaging scheme, but only with lp integration work is over
<sivang> highvoltage: did you talk to chirsh ?
<sivang> highvoltage: he's a very good freind of mine :-)
<seb128> sivang: it was a joke, maintaning is probably not a piece of cake you should rather start with something else
<seb128> Amaranth: he has changed job
<sivang> seb128: sure thing
<Nafallo> seb128: hmm, what that does mean for network-manager? :-/
<cartman> any idea when amd64 buildd would be back?
<Amaranth> 2017
<dieman> heh
<dieman> i should look at firefox
<cartman> thats soon enough
<dieman> ive got a few ugly bugs in hoary i need to come up with testcases for
<Amaranth> MMMMXVII
<Amaranth> i think i got that right, i hate roman numerals
<cartman> you got it right
<sivang> seb128: He's no longer with Canonical?
<seb128> sivang: nop
<seb128> Nafallo: waiting for your patches? :)
<Amaranth> :/
<Nafallo> 18:13 < elmo> ogra: the buildds are alive; just need laminity love now, AFAIK
<Nafallo> cartman: ^ amd64
<cartman> Nafallo: thanks for info!
<doko> lamont, lamont-away: why is the xrender build log not available on your pages (0.9.0-1)?
<j^> Amaranth in that case you should look it up MMXVII (http://www.guernsey.net/~sgibbs/roman.html)
<Amaranth> ah, two Ms :/
<Nafallo> seb128: haha. was fun why it lasted then ;-)
<Nafallo> s/why/when(
<Nafallo> s/\(/\//
<comadreja> I need to forward a gcc-4.0 bug to somebody (I received it by mail and I don't understand it :) )... any pointers ?
<ogra> comadreja, doko (he just went offline)
<sivang> pitti logged off?
<Lathiat> 01:09 -!- pitti [~pitti@195.227.105.180]  has quit [Remote closed the connection] 
<sivang> bah
<comadreja> I'll send him by email
<Lathiat> that was about 36 minutes ago
<comadreja> thanks ogra :)
<sivang> I didn't get what he said abour removing the auto4te directory
<seb128> sivang: that's easy, remove the autom4te.cache dir
<seb128> sivang: that's not useful for the patch
<sivang> seb128: ah right, the dir that holds the cache stuff for making subsequent calls to autoconf faster :-)
<sivang> seb128: k, thanks!
<seb128> np
<mdz> morning
<Amaranth> morning
<fabbione> hey mdz
<Amaranth> hmm, i'm not on the CC agenda at all
<fabbione> mdz: it's sort of evening in uk ;)
<Amaranth> did i just get through without showing up or did you drop me? :)
<seb128> hi mdz
<highvoltage> mdz: i almost get nostalgic when I see george.kkhotels.co.uk :)
<mdz> highvoltage: :-)
<mdz> highvoltage: did you get a chance to try the thin client stuff yet?
<ogra> mdz, arent you supposed to crawl through rockets currently ?
<highvoltage> i have a question for ubuntu-devel, are there any specific responsibilities to being the community contact for an ubuntu project, such as edubuntu?
<highvoltage> mdz: no :(
<mdz> ogra: that was this morning
<highvoltage> i've been  catching up with work.
<ogra> mdz, wow, thats quick
<highvoltage> things are going better now. tomorrow i'm going to download that cd, if xorg doesn't work that's fine.
<mdz> very short visit
<ogra> oh :/
<highvoltage> and then i'll test it tomorrow evening.
<mdz> great fun though
<ogra> :)
<Kamion> crawl through rockets?
<highvoltage> i've been extremely interested in how it actually works.
* ogra is really sad he didnt hear the jam session
<highvoltage> mdz: did you punch mark?
<mdz> ogra: unfortunately, someone captured it on video...
<dieman> heh
<mdz> highvoltage: punch?
<ogra> hehe, i'll find it then 
<highvoltage> mdz: for the skinny guy comment
<highvoltage> mdz: where can we get the video where you and other ubuntu ppl sang? no one seems to have it.
<Amaranth> yeah, it disappeared
<dieman> heh
<dieman> its not on dc5video.d.n?
* Amaranth looks around
<mdz> highvoltage: Debian people, actually ;-)
<Amaranth> I didn't see anything
<dieman> hrm
<Amaranth> Don't hurt me!
* highvoltage has ambitions of becoming a debian-person.
<Amaranth> okay....I shouldn't make jokes after being up 24 hours....
<Kamion> mdz: can I have a small UVF exception for localechooser 0.13? I have to merge from 0.04 to 0.12 anyway (0.12 was pre-UVF), and 0.13 fixes a few bugs that got introduced somewhere in there
<mdz> debconf was a blast
<mdz> Kamion: yeah, certainly
<Kamion> cool, cheers
<ogra> yes, we saw it :) planet was full of good stuff
<highvoltage> next time, i'm going to debconf, even if i have to go hungry for 6 months.
<dieman> heh
<bddebian> heh
<dieman> its in mexico city next year i hear.
<highvoltage> although, i'm already going hungry for the other 6 months to pay for my internet connection.
<bddebian> Doh. :-(
<ogra> highvoltage, makes slim hips though ...
<highvoltage> ogra: yeah, i could actually do with going hungry a bit, if you know what i mean ;)
<Kamion> doko: isdnutils looks fine, provided that you/somebody goes over everything that cares about the libcapi soname change
<highvoltage> anyone in this channel an existing community contact? i really want some more info.
<dieman> heh
<comadreja> awesome, I could finally fix gcl :D
<dieman> damn, 404 on that chorus video
<ogra> highvoltage, just ask, the appropriate people will answer
<Amaranth> highvoltage: I tried to be once, but it's been 4 months now.
<Amaranth> (lilo is overworked)
<ogra> oh,, you mean contact to freenode ?
<Amaranth> yeah
<highvoltage> I'm going to be the community contact for edubuntu, so I'd just like to find out if there's any specifice responsibilities i'll be accountable for.
<Amaranth> well, if freenode wants to talk to edubuntu they come to you
<ogra> highvoltage, care for the community :)
<seth_k> ogra, did you happen to see my message on #ubuntu-bugs the other day?
<highvoltage> ah, ok.
<Amaranth> and if edubuntu wants to talk to freenode they go through you
<jdub> highvoltage: if anyone sticks their fingers in the power sockets, we'll hold you responsible for any ill effects.
<ogra> seth_k, oh, missed that, whats your bugzilla login ?
<seth_k> seth@sethkinast.com
<highvoltage> ah, ok. I should probaby add my name to the edubuntu wiki then as community contact.
<highvoltage> jdub: hence my nick ;)
<jdub> highvoltage: almost self-documenting :)
<highvoltage> i wonder if i should go for something more conventional for the ubuntu channels.
<seth_k> conventional is overrated
<highvoltage> 'highvoltage' doesn't look as elegant as the other names.
<highvoltage> such as "ogra"
<seth_k> take bddebian, he uses a name with "debian" in an Ubuntu channel
<ogra> seth_k, you can edit bugs now, use this power wise and carefully, dont change the wrong bits ;)
<seth_k> the nerve
<ogra> hahaha
<seth_k> ogra: always. thanks a lot
<ogra> :)
<bddebian> Hey
* bddebian gets NO love.. :'-(
* highvoltage wants an ubuntu e-mail address
<ogra> highvoltage, soon 
<highvoltage> bddebian: who needs love when you can have 'debian' in your nick?
* bddebian wants a brain
<highvoltage> ogra: cool.
<highvoltage> anyone been in contact with elmo? i keep missing him on irc. e-mail doesn't help much either.
<bddebian> He was here earlier
<ogra> highvoltage, he's been around
<bddebian> Hmm, speaking of which, I haven't heard back from Mako on my CoC?
<ogra> bddebian, he was at debconf...
<bddebian> Ohh
<bddebian> Couldn't check his e-mail at debconf? ;-)
<ogra> so it might take some time until he cached up all this mail
<highvoltage> cached up :P
<ogra> bddebian, from my own experience, you only check half as often for mail on conferences
<ogra> heh, catched indeed
<bddebian>  "is caught up on" :-)
<seth_k> Yeah bddebian, I haven't heard back from him on mine either. The universe probably exploded in his inbox
<bddebian> Heh
<doko> Kamion: yes, I'll update the libcapi dependent stuff. elmo, please sync isdnutils from unstable
* seth_k didn't help things by sending his CoC as a binary attachment the first time around :D
<\sh> ogra: right
<Lathiat> bddebian: What about your CoC?
<Lathiat> you can upload them on launchpad now
<ogra> bddebian, thanks :)
<Lathiat> no idea if it still needs mako blessing, iw ould have assumed not
<ogra> bddebian, thats really 'is', not 'has' ?
<bddebian> Lathiat: I just sent a signed one to Mako.  Oh, didn't know that though
<doko> lamont, infinity: gettext fails to detect jar on the i386 buildd, although that alternative should be provided by fastjar. please could you have a look?
<bddebian> ogra: No, you are correct, should be "has caught up on all his mail"
<seth_k> Lathiat: I signed one on Launchpad, but my key is not signed into the strong set, so methinks that I need additional CoC love, e.g. a physical copy signed
<ogra> ah, but i learned something :)
<Lathiat> seth_k: nope
<Lathiat> not afaik anyway
<seth_k> whoaaaa
<bddebian> ogra: Well since I'm useless at packaging, I'll be your English guide ;-P
<ogra> bddebian, you see, youre not only here for entertainment purposes :)
<bddebian> Heh
<seth_k> Lathiat: well, I'm still a pending Ubuntu member instead of confirmed, even though the CC accepted me July 5 and I have a CoC in Launchpad... so I dunno
<\sh> seth_k: mako is doing it by hand...i think
<Lathiat> wel, quite possibly to be confirmed as a member, it needs blessing by someone, but the CoC in launchpad should be enough on that sidde
<Lathiat> probably good to tell him
<seth_k> okay \sh, Lathiat, thanks for all the info. Maybe I just hit things at the wrong time, with debconf.
<\sh> seth_k: ping him tomorrow ;)
<seth_k> I'll be at the meeting \sh, so I shall sneak-attack him then ;)
<\sh> seth_k: sniper him ;)
<seth_k> hehe
<Treenaks> elmo: ping?
<highvoltage> mdz, ogra: so would it be advisable that we have a #edubuntu and #edubuntu-devel? I've just registered both.
<mdz> highvoltage: #edubuntu sounds reasonable
<mdz> highvoltage: I'd prefer that development talk remain on #ubuntu-devel unless it's too much traffic
<highvoltage> mdz: ok, that sounds good to me. i'll send it to the list.
<Amaranth> arg, too many channels
* Amaranth looks into xchat-gnome
* \sh is refering to the easy solution: ircII ,-)
<Amaranth> *shudder*
<Amaranth> it needs to have a GUI, for a start
<highvoltage> \sh: how about irssi? it works well.
<ogra> err
<\sh> highvoltage: I found pictures from me from days without software like irssi ,-)
<ogra> Amaranth++
<\sh> highvoltage: so...ircII is ok :) but irssi is better, u r right
<highvoltage> ok, sorry. i see you are using irssi :)
<\sh> highvoltage: hehe
<doko> elmo: please install gcc-4.0's b-d's on concordia/unstable
<\sh> doko: ping
<\sh> doko: unping..nevermind..
<dnakata> is there some sort of postinst script debugging harness i don't know about? (just curious)
<dnakata> i guess that would suggest some sort of verbose bash, wouldn't it..
<Mithrandir> dnakata: add set -x to the top of the postinst script
<lamont> doko: gettext build _installed_ fastjar...
<doko> yes, I know, looks like the alternatives are broken in the buildd
<dieman> ugh
<elmo> doko: done
<dieman> i hope this xpdf problem one of my amd64 users just ran into goes away when i upgrade them to hoary.
<dieman> for some reason it flips out with a "Broken Pipe" to his x session, but it works fine over an ssh x tunnel.
<doko> elmo: thanks
<lamont> doko: which alternative?
<doko> lamont: jar
<lamont> There are 0 alternatives which provide `jar'.
<lamont> does that mean I need to tell it something?
<mdke> elmo, pleeeeease docteam svn accounts?
<doko> well, fastjar registers an alternative for jar. why isn't it available, when fastjar is configured?
<ogra> mdke, you dont use bazaar ? 
<dilinger> 31657 dilinger  15   0  180m  57m  10m S  0.0 11.5   1:46.95 evolution-2.2
<mdke> ogra, svn
* dilinger grrs
<ogra> mdke, hmm, i find bazaar way easier (i just learned to use it)
<lamont> doko: lrwxr-xr-x  1 root root 29 Jun  2 06:01 /etc/alternatives/jar -> /usr/lib/jvm/java-gcj/bin/jar
<mdke> ogra, for the future that is on the agenda definitely. but for now we continue to use the svn repo
<lamont> could that be the reason?
<ogra> mdke, but up to you anyway...
<mdke> ogra, it will happen I'm sure
<ogra> mdke, oh, you already have one...
<doko> lamont: yes, java-gcj-compat once had a bug unregistering the alternatives, but infinity fixed that on the buildds AFAIK
<mdke> ogra, we have been using svn for some time. i'm sure bazaar will come in maybe for breezy+1
* lamont does --auto for all of them.
<ogra> mdke, great... its really easier... i'm not a friend of version control systems. but bazaar finally convinced me to use one...
<mdke> i've heard its good
<Burgundavia> ogra, the plan is for the doc team to switch after breezy
<Treenaks> is there a docteam channel?
<Treenaks> I'd like to discuss some small thing
<mdke> yes
<jdub> Treenaks: #ubuntu-doc
<mdke> ah hey jdub
<ogra> Burgundavia, yeps i understood that from mdke
<Treenaks> jdub: hmm.. that's quite obvious.. thanks
<jdub> "irc channel names for human beings"
<lamont> jdub: like #ubuntu-jdub-bashing?
* lamont ducks
* Lathiat grins
<wasabi_> i feel like im MUDding
<wasabi_> 'heh. =(
* lamont considers tossing mud at wasabi_, but decides that would be a CoC violation
<lamont> doko: python-popy seems to be pgsql-unhappy... or is that a pitti question..
* lamont can't remember right now
<jdub> lamont: hey man, get off my wavelength, i was just writing about throwing mud
<lamont> LOL
<doko> lamont: when in doubt, it's a pitti question ;) I think I didn't touch popy
<lamont> doko: yeah - ISTR pitti was postrgresql,  and you were pythoin\
<dnakata> hmm
<ogra> lamont, depends on security flaws ;)
<dnakata> that's hillarious
<dnakata> the script doesn't return a value, so it fails
<doko> elmo: please could you run on concordia/unstable: apt-get --reinstall install ia32-libs ia32-libs-dev lib32z1 lib32z1-dev ? the preinst of the current lib32gcc1 is broken
<comadreja> hello doko
<doko> comadreja: hi
<comadreja> there was a problem on gcl that prevented it from compiling
<comadreja> I applied some fixed and it compiled, but the it failed compiling lisp
<comadreja> I emailed the developer about that
<comadreja> he found out that it works when not using optimization
<doko> hmm, I remember that ogra or sh tried to compile it for breezy
<comadreja> I did
<comadreja> it compiles now
<ogra> doko, not me...
<comadreja> I submited to revu
<comadreja> well, the point is that he found out what seems to be a bug in gcc-4.0
<comadreja> what he says is basically that... let me read again
<doko> where did you submit it?
<ogra> thats dokos fault, we all know it :)
<comadreja> to revu
<comadreja> gcc-4.0 clobbers a variable across a longjump
<doko> sorry, I don't know revu
<comadreja> without a warning
<comadreja> let me find the link
<ogra> siretart.tauware.de/revu/
<ogra> doko, ^
<comadreja> that's it :)
<ogra> it cool
<ogra> its even
<comadreja> doko: he asked me to let you know :) that's it
<comadreja> doko : he's got a patch for gcl 2.6.7
<comadreja> doko : but I guess it should be solved on gcc
<comadreja> until then I disabled optimization and included the fixes in the revu package
<doko> comadreja: for a fix in gcc, we need a proper bug report. the information that replacing -O3 by -O0 doesn't help much
<comadreja> doko: I know, I can send you by mail the mail he sent to me, sure you can decypher it
<comadreja> doko : would that be ok ?
<doko> comadreja: let's try that
<comadreja> doko : right away
<doko> better submit a bug report to bugzilla.ubuntu.com, pasting the mail
<comadreja> doko : perfect
<dieman> yay, only 8 or 9 warty machines left to upgrade
<dieman> so that makes 42 hoary machines
<ogra> cool
<dieman> and 210 woody machines to go
<dieman> but i'll be doing 69 of them next month (labs)
<dieman> so really, 141 desktops to upgrade as soon as we can.
<dnakata> wow, alrighty then.
<dnakata> right on.
<dnakata> is there a breezy badger dev channel?
<mdz> this is it
<dnakata> alrighty
<dnakata> anybody felt any difficulty upgrading xlibs to 6.8.2-42?
<dieman> win 3
<dieman> sorry, mistype.
<ogra> dnakata, see topic
* topic unset by dnakata on #ubuntu-devel
<dnakata> woops.
<ogra> gah
<dnakata> shit.
* ..[topic/#ubuntu-devel:dnakata] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://www.ubuntulinux.org/wiki/DeveloperResources | If you have unexpectedly lost editbugs privileges, talk to mdz/ogra/kiko | Colony CD 2 released | yes, X is broken.  a fix has already been uploaded.
<dnakata> well, i can see it states X is broken
<dnakata> as a fact, it works
<ogra> heh... 
<dnakata> i suppose my patch was in vain then
<dnakata> alright, cool, neato
<dnakata> i think it's time i start jumping in to help around here
<dnakata> i've gotten to the point with both debian and ubuntu where i don't ask questions about it, only about politics and statuses, but i've never walked away from a system in a broken state
<dnakata> i think that's something ubuntu releases are striving for
<pef_aw> night !
<seth_k> \sh, is KDE stuff buildable again yet?
<Riddell> seth_k: should be, unless it needs kdebase installed
<seth_k> ok
<\sh> going to bed..tomorrow gents
<seb128> thom: around?
<TheMuso> c
#ubuntu-devel 2005-07-24
<seb128> jdub: l10n list? You are doing it now? I've the feeling it's going to while for a long time after reading your mail :p
<jp_> wow, muine sux as package :/ I got millions of errors and segmenations faults :) tseng ;)
* jp_ brb
<daniels> doko: it causes problems when linking sometimes
<mjg59> usplash actually does useful stuff now
<mjg59> I'll try to get a tarball up in the morning
<HiddenWolf> mjg59, you mean there is actually work being done on usplash?
<Nafallo> mjg59: does it support 16:10? :-)
<HiddenWolf> mjg59, it'd better ;)
<mjg59> It'll use640x480 in 16 ccolours on x86. This is non-negotiable.
<mjg59> HiddenWolf: Well, my laptop currently uses it while booting, so yes...
<mjg59> A few things to sort out yet, though
<HiddenWolf> mjg59, Will it actionally be in Breezy?
<Nafallo> mjg59: no amd64 in other words :-P
<mjg59> Should be
<mjg59> Nafallo: The same on amd64
<mjg59> On PPC, it should look nicer
<Nafallo> baah
<Nafallo> then the artwork team has to do something that looks great both on 4:3 and 16:10 ;-)
<Gnobody> are you talking about usplash?
<HiddenWolf> mjg59, why does it look better on ppc?
<Nafallo> Gnobody: indeed
<mjg59> Because PPC has offb
<infinity> HiddenWolf : Because PPC has video init in the firmware.
<mjg59> Whereas we're stuck with vga16fb on x86
<mjg59> (if we want suspend/resume to work)
<tseng> jp_: +1 funny
<Gnobody> I hope it is black & white because if they try to add colours it will look fugly
<mjg59> Mm? 
<mjg59> It's eays enough to do an attractive 16 colour image
<daniels> 640x480x16 is the only thing that's guaranteed to work
<Gnobody> ouch
<daniels> at least, if it doesn't work, you're justified in stabbing your laptop manufacturer in the eye
<Gnobody> but most hardware can do higher res/colour FBs 
<daniels> in theory, yes
<daniels> in reality, you need to work out exactly *how*
<mjg59> Gnobody: Yes. But not if you want suspend/resume support.
<daniels> the logic for this is too complex to put into a tiny image-displayer
<infinity> Gnobody : I don't recall anyone complaining about the 640x480x16 Win32 boot screens ovre the years.
<Gnobody> yeah but it's windows; everything is a second grade hack
<Gnobody> and XP is 4 years old
<tseng> so are many pcs
* infinity fails to see the issue.
<infinity> It's a boot screen, not the desktop.
<Gnobody> it's not a big deal
<Gnobody> I probably wont use a splash
<daniels> if the boot screen is up for any length of time, then we've failed anyway
<Gnobody> I like my kernel messages, they scare n00bs away
<Nafallo> hehe. like xorg.
* Nafallo hides *
<infinity> Hey, would you look at that?... xorg is in sync on amd64 again.
* infinity cheers the buildds for catching up.
<tseng> infinity: oh dude
<mdke> sometimes I come across users who report dependency errors with libraries when using backports. How can I report these? do backports have a bug area?
<Gnobody> does xorg work by default in breezy yet?
<tseng> infinity: did you look at my gtk-sharp2 x86 segfaults
<mdke> malone?
<infinity> tseng : Yes, but I have no satisfactory answer for you yet.  I'll look harder in a bit.
<jp_> can somebody update to th new sticky notes? it rocks :)
<infinity> tseng : How on earth that tool segfaults at all is a bit of a mystery, though.  Seems rather fragile.
<tseng> infinity: thanks. it breaks other packages
<tseng> eh it doesnt segfault in my chroot
<tseng> or on the other buildd's
<infinity> By "other", you mean "other non-i386", right?
<tseng> yes, but my pbuilder is x86
<infinity> It does die on all 3 i386 buildds the same.
<tseng> so, whats the difference between pbuilder and sbuild chroot
<infinity> I can grab you a list of installed packages.
<elmo> eh, pbuilder vs. sbuilder isn't going to cause a segfault
<tseng> elmo: exactly.
<elmo> it's far more likely to be what's installed/not installed, versions or the kernel
<tseng> *baffle*
<elmo> tseng: that's hardly the only difference
<infinity> Beyond that, not much.  /proc mounted (or not), kernel versions.
<seth_k> mdke: backports bugs go on the forums I think
<infinity> elmo : Thanks for reviving amd64, BTW.
<tseng> well, ive tested it to be sure that it doesnt segfault on missing proc
* Jimbob patiently awaits the xbase-clients deps in powerpc
<tseng> it dies spectacuarly
<tseng> but its not a segfault
<elmo> infinity: no prob
<Gnobody> does xorg work by default in breezy yet?
<elmo> infinity: but we need to kill one of them at some point this week with the breezy kernel
<Jimbob> Gnobody: Works for Me(tm)
<mdke> seth_k, ok i'm writing there
<infinity> elmo : Fine by me.  The backlog will be dead within another few hours, at this rate.  At that point, you can have one for the rest of the week. :)
<elmo> infinity: since "breezy kernel doesn't survive as a buildd" is a teh suck of bugs
<Gnobody> did you have create a bunch symlinks and hack the crap out of you xorg.conf?
<Gnobody> jimbob
<daniels> infinity: in sync on amd64 -> broken for EVERYONE.  whoohoo!
<infinity> elmo : We could dedicate the breezy kernel test to a single buildd doing breezy-test builds, killing two birds with one stone.  Heavy buildd useage, and breezy-test.
<elmo> infinity: yah
<Nafallo> daniels: haha! I wont update then ;-)
<infinity> daniels : Fair's fair.
<daniels> ARGH LIBTOOL SMASH
<Nafallo> hehe. I wonder if my neighboors here my laughing in the dark ;)
<daniels> elmo: thanks for fixing them, all the same
<Nafallo> indeed. thanx elmo :-).
* Gnobody is wondering if he should take the Breezy plunge... again..
<infinity> Gnobody : Not for about 3 or 4 days.
<Gnobody> why 3 or 4 days?
<infinity> Gnobody : If you like pretty graphical thingees, anyway.
<Gnobody> you mean X?
<infinity> That'd be the one.
<Gnobody> ahh it's still broken
<Gnobody> ?
<infinity> <daniels> infinity: in sync on amd64 -> broken for EVERYONE.  whoohoo!
<HiddenWolf> Gnobody, I'd think so
<Gnobody> who needs X when you can have bitchx and links2
<crimsun> elmo: please pull wxwidgets2.6 from experimental
<Gnobody> lol
<elmo> crimsun: no, there's something like that in NEW already
<crimsun> elmo: err, oops. Thanks!
<opi> hey guys
<elmo> crimsun: and doko wants it to go in main or some such crack, so it's getting bounced up the chain
<opi> anyone has a WAP enabled mobile toy? ;)
<crimsun> elmo: ah, well he knows better than I do. :)
<opi> I've just hacked a WAP Planet.ubuntu-pl.org feed ;)
<Nafallo> hmm. updates. a week of them :-P
<tseng> elmo: did you get my mails for gmime2.1 and cli-common from unstable?
<tseng> elmo: no rush, just have trouble with loosing mail
<elmo> tseng: yes, already done
<tseng> thanks :)
<Burgundavia> can I pull crackish ideas like Yast2 from IdeaPool ?
<tseng> you can comment on their high level of crackfulness
<Burgundavia> ok
<mdke> i thought crackish ideas were your speciality burgs
<Burgundavia> there is a difference between good crackish and bad crackish
<tseng> im not sure if its fair for a docteam member to arbitrarily axe feature requests
<tseng> not as a slap, just saying.
<Burgundavia> ok
<tseng> i seem to recall sitting around with silbs and daniel laughing at most of the idea pool
<tseng> but not really having a good feeling about actively blowing people off
<tseng> its just a wiki page
<Burgundavia> there are some gems there
<Burgundavia> and if you read through what people want and not what they say, you might be able to do something
<tseng> does it include our friend with the mask?
<Burgundavia> the logo idea?
<mdke> that guy is working hard on his page
<mdke> :/
<mdke> strange idea
<daniels> nothing if not enthusiastic
<Burgundavia> his art isn't bad
<tseng> daniels: best. changelog. ever.
<mdke> point him at ArtTeam
<Nafallo> tseng++
<tseng> mdke: he is on the mailing list. cant miss him.
<daniels> where's scott when I need him?
<daniels> cybersaga writes "ZDNet reports: "The open source Firefox browser and Thunderbird e-mail client will be updated for the second time in a week due to code changes that have unintentionally stopped some third-party extensions from functioning correctly." More details at MozillaZine. Firefox and Thunderbird versions 1.0.6 and Mozilla 1.7.10 are on their way."
<daniels> WHEN WILL HOARY HAVE 1.0.6 OMG
<bob2> it'd be cool if security fixes stopped breaking extebsions
<bddebian> WHEN YOU BUILD IT :-)
<infinity> My extebsions work great.
<bob2> that's because they're made out of ice tea
<bob2> ULTIMATE ice ta
<daniels> ullit
<daniels> er, uliit
<Riddell> daniels: what package have iceauth been moved to?
<daniels> Riddell: i assume it used to be in xbase-clients
<daniels> Riddell: it'll be in a package called 'iceauth' when everything's shuffled around
<Riddell> daniels: ok, I'll look forward to that then
<daniels> won't we all
<infinity> daniels : DO we get to un-transition GLU today?
<daniels> infinity: yeah
<daniels> infinity: shortly after breakfast
<daniels> i'm just trying to fix the mechanics of the xlibs transition
<Nafallo> hmm, we might want to rebuild network-manager to remove libiw27 :-)
<Nafallo> or is that motu now?
<infinity> Smack thom.
<infinity> It's his baby currently.
<Nafallo> thom: we might want to rebuild network-manager to remove libiw27 :-)
* infinity glares at the arts failure on amd64, then glares at daniels.
<infinity> daniels : Did libXrender.la wander off to neverneverland recently?
<tseng> daniels: oh, should we axe dbus-mono?
<daniels> tseng: yeah, totally
<daniels> infinity: yes, by choice
<tseng> daniels: someone bothered me to update/fix it. funny
<tseng> elmo: can we axe dbus-mono source?
<infinity> daniels : Feh, so arts needs an update to stop looking for it.
<tseng> elmo: built by dbus proper now.
<infinity> Riddell : arts has enough of a KDE heritage that I can pawn this one off on you, right? :)
<Nafallo> wth! firefox is in swedish :-P
<Nafallo> how did that happen?
<daniels> infinity: it's probably libqt-mt-dev, I'd guess
<Riddell> infinity: that's weird, qt should have been recompiled so it wouldn't pick up libXrender.la
<infinity> Riddell : Would that have broken if qt and xrender were built out of order?
<Riddell> infinity: quite possible
<infinity> Riddell : ie: Did you have strict enough build-deps and a deterministic debian/rules, or were you just counting on the archive being consistent? :)
<daniels> or qt and xcursor, or qt and xft
<infinity> Riddell : If the build-deps weren't strict enough, please make them stricter (for the benefit of bootstrapping) and reupload.
<Riddell> infinity: not sure, I did have quite strict build deps because lamont was looking over my sholder, but could well have missed one
<infinity> Riddell : Cause qt is definitely up to date on amd64, and arts is failing on Xrender.
<Riddell> I'll build it on condordia and see what's up
<Riddell> or can I?  condordia would need it's chroot updated
<infinity> It would.  Good thing elmo's awake.
<Riddell> elmo: could you update concordia's chroot please
<Nafallo> infinity: amd64 is up2date already?
<daniels> Nafallo: a week's backlog is nothing
<daniels> our buildds are world-endingly fast
<infinity> Nafallo : Everything but a few FTBFS issues and the entire QT/KDE chain (which is stuck on this issue)
<infinity> Nafallo : Otherwise, amd64 is back up to speed.
<Riddell> who looks after the cdimage torrents?
<Nafallo> infinity: yey! :-)
<Nafallo> Riddell: kamion I guess
<Nafallo> daniels: seems so. and btw. you're soon to be blamed for waking up my neighboors. nice blogentry :-).
<Nafallo> infinity: evolution for example. I'll try to build it locally :-)
<Riddell> Kamion: I've had a complaint that the hoary kubuntru powerpc DVD isn't seeded
<Riddell> elmo: please install libxcursor-dev too
<Riddell> on condordia chroot
<infinity> Nafallo : I'm going to kick back all the failures once the new gcc-4.0 is built.
<Nafallo> infinity: ahh, oki :-)
<infinity> Nafallo : So, anything that's still failed in another 12+ hours is probably worth looking at.
<Riddell> elmo: also libmysqlclient12-dev on concordia
<Nafallo> infinity: mostly I want my calenders back or I'm gonna miss that CC-meeting ;-)
<daniels> Nafallo: i try
<infinity> Calendaring is for the weak.
<infinity> Or the week, if you're into puns.
<Nafallo> hehe
<infinity> doko : I will buy you a new car if you split the non-system compilers out of the gcc source package.
* infinity falls asleep watching libjava build.
<daniels> infinity: sleep? it's only 1134!
<Lathiat> 0933!
<Lathiat> and i havent slept yet
<daniels> i can prove that western australia doesn't exist
<Lathiat> how so
<Lathiat> that said, if you prove it to me
<Lathiat> you would not have proved it, since i would no longer exist and never witnessed your proof
<infinity> daniels : Well, I was up all night...
<infinity> daniels : But mostly, libjava is just mind-numbingly dull to watch build.  (you should try it on m68k... no, really)
<daniels> infinity: vancouver!
<bob2> hahaha
<daniels> wow
<daniels> there's a flag called ToolkitStringsABIOptions in imake
<daniels> which passes the options to makestrs, which is used in the libXt build
<daniels> this is -intelabi everywhere
<daniels> even on Solaris/SPARC
<daniels> even though there are things like, y'know, -sparcabi
<daniels> GAR
* Lathiat laughs at daniels 
<Lathiat> "Studies have shown that grilled cheese on toast is 97% better than libtool"
<luis_> don't most people think that grilled shit on toast would be 97% better than libtool?
<tritium> mmm, did somebody say grilled shit on toast?
<Lathiat> luis_: yes but its funny :)
<infinity> Feh.  gcc-4.0 is FTBFS trying to link Xrender.la too.
<infinity> Brought in by god knows what.
<daniels> infinity: cairo
<infinity> Was the last cairo upload not meant to fix that?
<infinity> (Which I'm building against)
<daniels> oh.  might be something else, then.
<daniels> infinity: lesstif?
<infinity> cairo could have just been built out of order...
<infinity> What's the fastest way to find the culprit?...
<daniels> infinity: grep -r libXrender.la /usr/lib
<daniels> or /usr/lib/*.la /usr/lib/**/*.la
<daniels> i can never remember the syntax for **
<infinity> Xft, cairo, gtk-2.0/2.4.0/immodules/*
<infinity> Yay.
<daniels> cairo probably needs a stricter b-d on xft
<daniels> alternately, no-one in the world should be shipping .la files
<infinity> And what's Xft's excuse? :)
<daniels> as they're not useful on linux
<daniels> xft probably needs a rebuild as well, though I thought riddell did one
<infinity> Again, probably not tight enough build-deps.
<infinity> amd64 being down for a week likely exposed a few issues in that area, since I'm sure things weren't built in the order expected.
<infinity> If pure rebuilds will fix this, I'll just upload them in the right order again.
<infinity> Any ETA on xbase-clients becoming installable again?
<daniels> remind me again which binary packages are missing
<daniels> if xhost, xdpyinfo, xsetmode and xsetpointer, I'm angling for tonight
<daniels> but, uh, the package will be somewhat empty
<infinity> Those 4 and xrandr.
<infinity> And I don't much care if the package is green with pink polkadots, so long as it installs and the things that indirectly build-dep on it start building again. :)
<daniels> the former, yes
<daniels> the latter, not so much
<infinity> Is there a minimum version of libxrender-dev I should be setting these build-deps to?
<infinity> They're currently unversioned.  Naughty.
<daniels> 1:0.9.0-1
<daniels> elmo: when NEWing stuff I upload, please put it into main unless I explicitly say otherwise
<daniels> elmo: i'm about to upload a bunch of new source packages to replace xbase-clients
<lamont> mdz: ping
<infinity> Changed-By: Adam Conrad <adconrad@localhost.localdomain>
<infinity> Go me.
<infinity> I'm so asleep at the wheel.
<bddebian> Heh
<daniels> yeah, I've uploaded a few from Daniel Stone <daniels@brainfreeze.fooishbar.org>
<infinity> Alright, libxft, libcairo, and gtk+2.0 fixed.  Hopefully, that'll do it.
* infinity taps his foot and waits for katie and wanna-build to get chatting.
<infinity> Hrm.  Uploads from non-whitelisted addresses get listed as "From: Ubuntu Installer"... Cute.
<infinity> Guess that hides my idiocy from plain view of the mailing list, at least.  <cough>
<daniels> heh
<schweeb> infinity: I noticed :p
<bddebian> Anyone know why zeiberbude wouldn't be able to find -lqt ?
<zwnj> i cannot build source packages with dpkg-deb -b.  any introdustoin/howto?
<bddebian> Use debuild or dpkg-buildpackage? :-)
<zwnj> bddebian: uhu, thanks
<zwnj> i'm new to ubuntu/debian.  i used to use redhat/fedora for 5 years... but no deb-based distro
<bddebian> Ah, well welcome
<bddebian> Sorry to hear about those 5 years of wasting your life. ;-)
<daniels> bddebian: because -lqt has been deprecated for years
<bddebian> daniels: What is it now?  -lqtthreads?
<daniels> try apt-cache search
<bddebian> Search for what?
<daniels> libqt, maybe?
<zwnj> bddebian: ;)
<bddebian> I realize that it is libqt3 now but you can't do -lqt3 can you?
<daniels> no, you can't.  keep didding.
<daniels> digging, also.
<zwnj> bddebian: btw, i just started to read Redhat RPM Guide and dpkg's manuales to build packages... of course i try to build my RPMs on ubuntu ;)
<bddebian> zwnj: Are you building for others or yourself?  If you just want to install, try alien
<zwnj> bddebian: we develop some Persian localized utils, and i want package them in rpm and deb for Iranian users
<bddebian> Ah, cool
<zwnj> bddebian: just got familiar with alien yesterday...
<bddebian> daniels: Well my only options in /usr/lib are libqtthreads and libqt-mt.  Am I going about this the wrong way?
<zwnj> is anyone here familiar with gedit's plugin system?  who is the package manager of gnome stuff?
<bddebian> zwnj: In Ubuntu, there is a Gnome team I believe.  As I understand Ubuntu, there is no 1 maintainer for a particular package
<bddebian> But don't quote me, I'm learning too :-)
<zwnj> i want to know how i should package a gedit plugin... because it's build system for plugins is a little complicated
<zwnj> is anyone from gnome team here right now?
<bddebian> daniels: -lqt is single threaded but all the build depends use libqt-mt.  Why would they link against the single threaded version?
<daniels> bddebian: exactly
<bddebian> Will I cause a problem if I use -lqt-mt ?
<Amaranth> holy crap it's been 8 hours and blam hasn't died
<Amaranth> that's a new record
<bddebian> Fux, I cleaned my build-tree. :-(
<Amaranth> if i try to read it, it will die
<Amaranth> it's taunting me
<bddebian> Even though it pained you, thanks daniels  :-)
<davyd> someone may know this
<davyd> why is Xscreensaver in Fedora Xinerama aware, but Xscreensaver in Ubuntu not?
<davyd> is it a compile time option?
<daniels> i'd imagine so
<daniels> just needs a build-depends on libxinerama-dev
<daniels> i think ogra maintains xscreensavetr
<Amaranth> daniels: libtool doesn't like you?
<daniels> Amaranth: it despises me and everything I stand for
<Amaranth> yeah, good luck with that
* davyd attempts to establish why his chrooted GTK+ is ugly
* davyd wonders if it's because something isn't installed
<davyd> seems that might be the case
* davyd smacks himself for basically being an idiot
* davyd dances
<davyd> go davy, it's your birthday!
* davyd copies his 4 gigs of test data onto his machine
<Amaranth> hrm, i don't think i want to mess with using bonobo to talk to rhythmbox
<Amaranth> i was looking at some python code to do it, but it has a method named 'unfuckBonobo' so i think i'll forget about it
<bob2> bddebian: install ccache
<bddebian> bob2: ??
<bob2> bddebian: ccache > you (apt-cache show ccache)
<bddebian> Ah cool, thanks
<bddebian> OK, I'm now trying to patch this sucker with cdbs-edit-patch but I don't get a Makefile and that is what I need to patch?? :-(
<davyd> has someone broken gdb on breezy?
<luis_> worked here this morning, more or less
<davyd> seems to work in 64bit land
<davyd> but not 32-bit land
<fabbione> morning
<bddebian> Hello fabbione 
* davyd attacks trs80 with a dalek
<trs80> hey davyd
<davyd> now... I wish I knew why I don't have GCC in my chroot
<trs80> I'd ask about my iowait problem, but it's pub lunch time
<davyd> mmm, lunch
* davyd considers gate crashing
<trs80> just for reference, breaking the raid 1 mirror didn't affect iowait times
* lamont sleeps
<calc> anyone know when thunderbird is going to be recompiled for new c++ ?
<Amaranth> so, what's the magic command to make xlibs install? :)
<Amaranth> or, does anyone have xlib 6.8.2-36?
<calc> Amaranth: probably lots of holds
<calc> i have 6.8.2-42 installed
<Amaranth> how?
<daniels> infinity: ?
<Amaranth> i know i have to do something to the postinst script, but i don't know where it is or what to do to it
<calc> i also have ~ 9 holds currently to be able to upgrade
<calc> i didn't do anything special
<seth_k> graah, anyone have any clue how to get my timezone back to normal after getting hit by this bug (https://bugzilla.ubuntu.com/show_bug.cgi?id=9207) ?
<seth_k>  /etc/timezone even says (correctly) "America/Chicago", but I'm stuck at GMT and don't know how to make it go back
<Amaranth> yay, fixed it
<Amaranth> i needed to recreate /etc/X11/xkb/types/ as an empty dir so postinst could remove it
<infinity> daniels : ?
<daniels> infinity: when are we transitioning?
<daniels> infinity: do you want to start at, say, 5?
<daniels> infinity: or do you need to crash?
<daniels> i'd like to do some more upgrade testing
<Amaranth> transitioning?
<daniels> Amaranth: libglu needs to go back from c2 -> ligblu1
<Amaranth> oh yeah
<Amaranth> because even though it's C++ it exports a C interface or something like that
<Amaranth> fun
<daniels> yeah
<daniels> the fact it's written in C++ is an implementation detail
<daniels> not the ABI
<infinity> daniels : I'd LIKE to crash, but the reality is that I have to head out in an hour for family obligation stuff.
<daniels> infinity: tomorrow?
<infinity> Yeah, tomorrow's fine.
<infinity> I may even have all this Xrender mess sorted by then.
<infinity> (just did another upload)
<daniels> ok, sounds cool
* #ubuntu-devel  [freenode-info]  help freenode weed out clonebots, please register your IRC nick and auto-identify: http://freenode.net/faq.shtml#nicksetup
<pitti> Morning
<pitti> Riddell: thanks for the qca-tls report; did you check for debian and upstream bugs? can you mention the status of those? as well as the security history?
<fabbione> hey pitti
<pitti> Good morning fabbione
<fabbione> pitti: before you start the firefox mess, should we review a few things?
<pitti> sure
<fabbione> pitti: perfect
<fabbione> let's start with https://wiki.ubuntu.com/MainInclusionReportRhCluster
<fabbione> point 1) the entire suite is in main/universe
<pitti> neat
<fabbione> the libdlm transition for clvm (universe, source lvm2) has been done right away
<fabbione> 4) there is a also a GUI now.
<fabbione> Regarding QA the upstream situation has been changing a lot
<fabbione> they did clean up their mess
<fabbione> in terms of how they use CVS
<fabbione> and tons of bug fixes made it to the STABLE branch
<pitti> what's the package name again?
<fabbione> redhat-cluster-suite (source and meta)
<fabbione> now it's also possible to compile modules for custom kernels + we provide them by default
<fabbione> pitti: as you can see from their bugzilla all the CRI bugs have been addresses
<fabbione> addressed
<pitti> looks really good
<pitti> GUI is sensible?
<fabbione> so even if you already approved it, i am going to ask for official inclusion in main and see the packages
<fabbione> pitti: yup and it works very well
<pitti> cool
<fabbione> pitti: all our packages have been tested by upstream
<fabbione> <pjc> they worked beautifully
<fabbione> <pjc> the meta-package was great. Fedora should have something like that
<fabbione> one of the upstream comments testing on ppc :)
<fabbione> (oh and they fixed the config file permission problem rigth away ;))
<pitti> I did these updates at https://wiki.ubuntu.com/MainInclusionReportRhCluster
<pitti> ... if it ever finishes, it's so slow...
<pitti> hrmpf, $)(/)$ wlan card
<pitti> fabbione: <pitti> I did these updates at https://wiki.ubuntu.com/MainInclusionReportRhCluster
<pitti> fabbione: did you say anything after "<fabbione> one of the upstream comments testing on ppc :)"?
<fabbione> nope
<fabbione> pitti: what wireless?
<pitti> fabbione: sitting at my laptop in the kitchen now, gf is still asleep :-)
<fabbione> pitti: if it's the ipw2x00 i will have a fix in the next upload
<pitti> fabbione: nevermind, that device always breaks after it gets hot, but it's the only one that is registered in my wlan here
<fabbione> hehe ok
<pitti> fabbione: I have another one (same model) which works fine (just not here since it's not registered)
<sivang> morning pitti , fabbione 
<pitti> Hi sivang 
<sivang> pitti: where can I read about our cluster packaging and infrastructure ?
<Mithrandir>  /win 31
<sivang> (the one I see you too are so hard working at :-) )
<Mithrandir> argh
<fabbione> sivang: you want to talk with me about that
<sivang> fabbione: ah , ok , basically everything is borrowed from fedora / RH (I recall you told me they wrot the GUI control tool)
<fabbione> sivang: RH..
<fabbione> fedora is no upstream
<fabbione> yes.. they wrote a gui that is already in universe
<fabbione> pitti: speaking of which.. we should move the GUI to main to
<fabbione> pitti: it's written in python..
<pitti> fabbione: right, the packages are fine and I already approved the stuff
<fabbione> pitti: ok thanks.
<fabbione> FYI: the GUI is called system-config-cluster
<sivang> fabbione:  system-config-cluster: Depends: redhat-cluster-suite but it is not going to be installed
<sivang> hmm, seems something's wrong with apt-file pkg, looks like it should depend on curl, but it doesn't
<fabbione> sivang: yes i know. i need to upload a new kernel or you need to rebuild the cluster modules
<sivang> fabbione: ah well, it's no rush , I will try install it when you finish :-)
<fabbione> sivang: it is finished, that's only the result of a trick Depends: / Provides: to ensure that at least a kernel with the cluster modules is installed...
<fabbione> and to complete the trick i need to upload a new kernel
<sivang> fabbione: I'm glad to know it prevents you from just installing the supportive stuff when you don't have a comptabile kernel.
<sivang> :-)
<sivang> fabbione: Does it use the mosix kernel for grid computing, or is a cluster something different? :)
<fabbione> sivang: it's a HA cluster. mosix is high performance
<fabbione> they are 2 different implementation
<fabbione> the RH cluster aims for High Availability (HA)
<sivang> fabbione: so basically, it replecates one node to the other, to be able to respond even if some of them break?
<Treenaks> sivang: basically, yes
<fabbione> sivang: not really..
<Treenaks> no?
<Treenaks> isn't the goal of HA basically "Little or no downtime and/or corruption"
<fabbione> HA does not replace.. it switches services across the nodes so that service foo is always available
<fabbione> Treenaks: yes, but it doesn't replicate the nodes
<fabbione> or replace them
<fabbione> the work is done at service level
<Treenaks> fabbione: no, the nodes should do that themselves
<fabbione> Treenaks: ??????
<fabbione> the HA cluster takes care of migrating services from a failed node to a working one
<Treenaks> fabbione: well, what you said.. the different services shuold take care of replication, some other piece of magic takes care of the failover
<fabbione> Treenaks: exactly.. replication is something different
<sivang> fabbione: that's interesting, so we basically have autonomic nodes (as each one is a seperate box) which all run the same services, and there a kind of a "switchboard" to find open slots per services (on each machine) and delegates the request there?
<fabbione> sivang: no, that's a load balancer
<fabbione> sivang: let say you need service foo (apache for example)
<fabbione> to be always up 100% of the time
<fabbione> node A and node B ( just to keep it simple )
<fabbione> the HA cluster will make a fake node C, masking A and B
<fabbione> (sort of)
<fabbione> so if apache is running on node A and node A fails, the service will automatically be switched to B
<fabbione> without you even noticing
<fabbione> this is a very SIMPLE example
<Treenaks> even in the middle of a request?
<fabbione> but there are tons of consideration behind doing something like that
<fabbione> Treenaks: no, that's too apps specific
<fabbione> but:
<fabbione> a) you don't lose the service
<fabbione> b) a shared cluster FS will not lose consistency
<fabbione> so even if effectly you lose one transaction in the middle of the switch..
<fabbione> you don't lose the service
<sivang> fabbione: and data is consistent due to (b)
<fabbione> sivang: exactly
<sivang> wow, cool
<fabbione> but you need a shared storage device between the 2 node
<fabbione> using local disk is pointless in a cluster :)
<\sh> emc is overload but a netapp is nice for those things
<\sh> good morning btw
<sivang> you can just as well build a custom shared storage with linux, there a howto somewhere (can't recall where)
<sivang> pitti: do you recall by heart the env vars that dch and other pkging tools use? i.e. for maintainer name and email, etc
<pitti> sivang: DEBEMAIL="Sivan Green <sivan@green>"
<fabbione> sivang: well in a cluster enviroment you try to use good hw ...
<fabbione> sivang: like a redundant shared device
<fabbione> and stuff like that
<fabbione> fencing devices... remote controlled power swiches
<sivang> fabbione: hmm, makes sense. No real benefit comes from a shared storage with 50% failing disks :-)
<sivang> pitti: thx 
<\sh> sivang: sometimes an expensive emc rack or some netapp heads with a couple of diskshelfs better then any selfmade solution
<carlospc> Hello everybody, have you read in ubuntu-devel list the thread "GNOME panel and sudo"? I would like to know if this funcionality will be implemented
<Burgundavia> carlospc, it is a google bounty and thus is quite likely
<carlospc> Maybe i could help, does anyone knows if it's a goal? if so, how it's called?
<sivang> pitti: is it ok to create patches with diff (talking about the configure patches) manually, and then concantate them into the one file debian/patch together with the code?
<carlospc> Ouh, thanks Burgundavia
<pitti> sivang: why not use something sensible like dbs-edit-patch or cdbs-edit-patch?
<Burgundavia> carlospc, http://udu.wiki.ubuntu.com/GnomePanelEnhancements
<Burgundavia> Google SoC project. Assigned to Emmanuel Cornet ([MAILTO]  manu.cornet@gmail.com). See Spec for further details.
<carlospc> Thanks in advance
<sivang> pitti: hmm, since I want to avoid cdbs's diff against all file in the source dir, to avoid autofu trails from the other files created by it
<pitti> sivang: just don't use autoreconf, use automake/autoconf manually
<sivang> pitti: inside the cdbs-edit-patch "chroot" ?
<pitti> sivang: it's not a chroot, but yes
<sivang> pitti: how would you define it? :-)
<pitti> sivang: it's pushd, nothing more
<davyd> so is muine known to die on amd64?
* davyd was labouring under the impression that an amd64 binary on one architecture was as good as another
<Treenaks> mono is known weird
<sivang> Treenaks: muine uses mono?
<GNULinuxer> sivang: yes
<sivang> GNULinuxer: as in to do music playing and other cpu bound stuff?
<davyd> music playing is done via Gstreamer
<davyd> so all of that is really in C
<Treenaks> but don't tell the mono guys
<sivang> hehe
<sivang> why did I had a feeling? ;-)
<pef> hello
<Nermal> morning
<trs80> so, does anyone have any ideas why my dual 3.4ghz xeon with 1gb of ram is spending 10-60% of its time in iowait?
<trs80> (warty, 2.6.10, two 160gb seagate 7200.7s in raid 1, lvm on top of that, hp proliant dl360 g4 which has a intel 6300ESB sata controller using ata_piix)
<{Seb}> hi guys
<{Seb}> how is breezy looking - broken wise?
<{Seb}> is X working again?
<Burgundavia> sort of
<davyd> oh boy
<{Seb}> sort of?
<fabbione> Kamion: ping?
<Burgundavia> depends on box and archictecture
<davyd> amd64 is broken
<{Seb}> they both have ATI cards and they are both Intel x86
<davyd> I had to build about 5 packages by hand
<fabbione> {Seb}: these are #ubuntu questions.. you have been told millions of time by now
<fabbione> trs80: stop running bonnie?
* davyd smirks
<davyd> nice, rhythmbox has decided that non of my music is actually music
<davyd> and muine doesn't start
* davyd continues to work in silence
<trs80> fabbione: nope not running bonnie. breaking the raid 1 doesn't make a difference either
<pitti> davyd: but you do have gstreamer plugins installed? (or, rather, didn't uninstall at least the ogg vorbis one)
<Burgundavia> guys, this discussion belongs on #ubuntu
<fabbione> trs80: i/o wait is highly dependend on what your box is doing.. it might as well be very normal
<davyd> pitti: good call
<pitti> davyd: gstreamer0.8-mad already helps a lot
<trs80> fabbione: it's just serving mail, dns, mailman etc. actual cpu usage is 1% or so
<davyd> pitti: yeah
* davyd wonders if he should --get-selections off his old machine for this one
<fabbione> trs80: mail* is an I/O bottleneck...
<fabbione> trs80: CPU usage != i/o wait
<fabbione> or better.. that becomes true if there is no DMA
<trs80> yeah, but a dual p3 733 was handling the same load faster
<trs80> the disks are sata
<fabbione> exactly
<trs80> ?
<fabbione> sata "has" DMA
<fabbione> so that's not the problem
<trs80> yeah
<fabbione> trs80: i would monitor /proc/interrupts and see if there is a device that is sucking IRQ
<fabbione> and stalling I/O
<fabbione> if that's the case try to boot with irqpoll
<fabbione> boot option i mean
<trs80> 1000 timer int/s
<davyd> that's sane
<davyd> HZ on linux 2.6 is 1000
<davyd> (on i386)
<trs80> 200-400 libata int/s
<fabbione> trs80: you need to check it for a long time...
<fabbione> not just in a 10 minutes phase
<fabbione> there might be processes that reises the I/O load
<fabbione> and not always running
<trs80> what's LOC in interrupts?
* trs80 leaves vmstat running
<trs80> fabbione: I have things like 3 kjournald sitting in the D state
<trs80> yeah, things are just sitting there, waiting for IO, not actually doing anything
<trs80> the disks are barely pushing a few MB/s
<fabbione> what FS?
<trs80> ext3
<fabbione> did you say warty + 2.6.10 ????
<trs80> hoary
<trs80> whatever 5.04 is, I always get the names mixed up
<fabbione> ok
<fabbione> trs80: if you the option i would try to boot with irqpoll
<fabbione> not sure it will make any difference
<fabbione> but it's defenitily worth a try
* trs80 ponders 2.6.12
<fabbione> 2.6.10 introduced a big IRQ routing change
<fabbione> and not all drivers managed to be converted on time
<pitti> Hey seb128
<seb128> hi pitti 
<Nermal> fabbione: any details ?
<Nermal> just normal IRQ routing, or ACPI IRQ routing ?
<fabbione> Nermal: normal IRQ
<Nermal> ah
<mdz> pitti: how is the bluetooth work going with Paolo?
<pitti> mdz: that's mainly done with chmj, but last week Paolo just reported back, he just started coding
<pitti> mdz: (he didn't have time before)
<pitti> infinity: ping
<chmj> mdz: I'm waiting to hear from him
<mdz> chmj: how long have you been waiting?
<JaneW> mdz: the Google guys on te whole seem fairly slow on the uptake (some are better than others though)
<JaneW> mdz: one is totally MIA
<chmj> mdz: since last week 
<ogra> davyd, yes, it's a compile time option i have it enabled on my local build, will be in the next upload as soon as i'm ready with the new  lockscreen (needs code cleanup)
<JaneW> mdz: a few look like shining stars :))
<ogra> morning all
<davyd> new lockscreen?
<ogra> <davyd> why is Xscreensaver in Fedora Xinerama aware, but Xscreensaver in Ubuntu not?
<JaneW> morning ogra :)
<trs80> my xscreensaver at home from debian testing is xinerama aware ...
<davyd> ogra: yeah, I remember asking about that
<davyd> ogra: I was asking what kind of new lock screen?
<davyd> similar to before
<davyd> or that Xembed crack?
<ogra> trs80, other X
<ogra> davyd, ah
<trs80> ogra: xf86 vs xorg?
<ogra> davyd, no Xembed, a simple hack like hoary had, but a bit cooler
<ogra> trs80, yes
<davyd> ogra: ok
* trs80 nods
<davyd> that Xembed solution is kinda clever
<davyd> he was obviously thinking a little more outside the ballpark then Mesh and I were
<ogra> but what i see here with gnome-screensaver is far from being ready....
<ogra> (dunno if its a amd64 thing)
* davyd laughs
<davyd> so much stuff appears to be
<davyd> ogra: are you running amd64?
<Kamion> Riddell: the torrent stuff is there on the cdimage backend machine, so I guess it's something wrong with torrent.ubuntu.com; you'll have to take that up with elmo
<ogra> davyd, yes... 
<Kamion> fabbione: pong
<ogra> davyd, on a sh*tty acer laptop
<davyd> ogra: do you know anything about chrooting a 32-bit set of libraries?
<davyd> and specificially, why gdb doesn't seem to work
<ogra> there are some docs on alioth afaik
<davyd> about gdb being broken?
<ogra> nope about chroots :)
<ogra> on amd64
<davyd> ok, well I have a chroot
<davyd> using debootstrap and dchroot
<davyd> and I've mount-binded things into it
<davyd> that all seemed fairly easy
<davyd> stuff seems to generally work... but gdb doesn't
<ogra> davyd, Mithrandir is your man for amd64 specialitys... the only chroot i use is my pbuilder ...
<davyd> ogra: ok, thanks
<davyd> I'll assume you haven't seen anything like it
<Riddell> elmo: can you confirm if the PowerPC Kubuntu DVD is seeded or no?
<fabbione> Kamion: yo..
<fabbione> Kamion: do you know of any linux-image-2.6-di that already use kernel-wedge 2?
<fabbione> Kamion: i am not sure i understand right how the .lnk has been changed...
<fabbione> afaics the file has been renamed and the contents changed to #include <> or #include ""
<fabbione> mdz: https://wiki.ubuntu.com/MainInclusionReportRhCluster <- review from this morning. if we can seed it to go to main, we can consider ClusterFileSystem deployed :)
<Kamion> fabbione: linux-kernel-di-i386-2.6 in Debian has been changed
<mdz> fabbione: did you add it to maininclusionqueue?
<fabbione> Kamion: thanks
<Kamion> fabbione: the changelog and the README file explain it, though
<fabbione> mdz: not personally.. probably pitti did?
<pitti> fabbione: yes
<fabbione> Kamion: yes, the README explain the current format, not how to migrate.. i just wanted to be 100% sure with a double check
<mdz> fabbione: is it seeded yet?
<fabbione> mdz: not that i know off... i usually don't touch the seeds at all
<mdz> ok, go ahead and seed it, and Kamion or I will promote it with the next batch
<fabbione> mdz: ok.. what seed is preferred? supported?
<mdz> yes
<fabbione> ok
<ogra> mdz, oh, while youre at seeds, which stuff (if any) has to move to ubuntu main/supported for edubuntu ? 
<ogra> mdz, any policy for that ?
<mdz> ogra: isn't that a question that I would ask you? ;-)
<mdz> anything new that you added to the edubuntu seeds needs main inclusion reporst
<ogra> mdz, nope, i know the software, but you know the policy ?
<ogra> so everything thats not in main or supported yet ?
* fabbione scratches his head
<mdz> ogra: pitti created a wiki page with instructions
<pitti> ogra: http://wiki.ubuntu.com/UbuntuMainInclusionQueue, instructions are linked from that
<fabbione> mdz: did the seed archive change location recently?
<ogra> mdz, i know, i already wrote reports ...
<mdz> ogra: edubuntu will be treated just the same as Ubuntu; anything that you add which is not obviously supportable needs a review
<mdz> fabbione: no
<JaneW> mjg59: ping
<ogra> mdz, ok, yay for bureocracy then.. that'll be a lot
<Burgundavia> ogra, I might be able to help you
<mdz> ogra: main implies an 18-month support commitment; these basic sanity checks are essential for that
<ogra> Burgundavia, look at the seeds http://people.ubuntu.com/~cjwatson/seeds/edubuntu-breezy/
<ogra> mdz, yes, i know, i just wasnt sure about the difference between edu and ubuntu
<Burgundavia> ogra, basically the seeds have everything that is needed? now i need to figure out what is not in main and create reports for it?
<ogra> and there are many odditys on the list, pitti will scream :)
<Burgundavia> ok
<Burgundavia> I will do some work tomorrow
<fabbione> mdz: did you ever get to test the kernel with the tpm fixup?
<pef> when is the review day ?
<fabbione> mdz: the same fix made it in stable release.. so it should work
<ogra> Burgundavia, desktop and server are the interesting bits, the rest is similar to ubuntu
<Burgundavia> yes
<Burgundavia> I have seen the wiki
<mdz> fabbione: no, I haven't
<fabbione> mdz: ok.. it's more important you had fun :)
<JaneW> ***NAG ALERT***
* ogra hides
<JaneW> ATTENTION all BreezyGoal Leads. Please update your BreezyGoals if you have not done so in the last week.
<mdz> daniels: which version of X is referred to in the topic?
<ogra> mdz, any ?
<mdz> ogra: hmm?
<JaneW> ogra: :)
<ogra> since -36 ?
<JaneW> ogra: I did update 'edubuntu' for you ;)
<ogra> JaneW, thanks :)
<mdz> ogra: current is -42
<ogra> yep
<mdz> but there is still a problem
<mdz> Setting up xlibs (6.8.2-42) ...
<mdz> rmdir: `/etc/X11/xkb/rules': Directory not empty
<mdz> thus my question
<ogra> and since -36 i've seen no working version 
<JaneW> mdz: little nag... LiveCDPrompts - what's happening there?
<mdz> JaneW: the resolution was that the ideal experience could be achieved by allowing the keyboard layout to be configured from the gdm login screen
<mdz> however that is not something that I will be able to spend time on (it'd be a good bounty)
<mdz> we should talk with the person (vincent untz?) who has done other gdm work
<JaneW> ok, so deferred for Breezy? or on the bounty page in the hopes that someone will make it happen in time?
<JaneW> mdz: ok, shall I contact him?
<ogra> JaneW, ask vuntz ?
<Burgundavia> ogra, shall I create a wiki page for all the various maininclusion pages?
<JaneW> ok
<ogra> Burgundavia, that'd be very nice :)
<mdz> JaneW: yes; it is a bit late in the cycle to start on it, but it is worth a try
<ogra> mdz, one last edubuntu question ... 
<seb128> asking what to vuntz ?
<ogra> mdz, i'll build the CD that it installs a ltsp classroom by default, but want a option to install a standalone workstation too...
<mdz> seb128: mdz JaneW: the resolution was that the ideal experience could be achieved by allowing the keyboard layout to be configured from the gdm login screen
<seb128> mdz: I've read that, but if you want him to work on gdm he rejected the bounty (jdub asked him at GUADEC) because he's too busy with other stuff atm
<ogra> mdz, since ltsp will be the default, i need a boot/installer option.... or a question in the installer... the latter will generate work for Kamion but is far more userfriendly...
<mdz> seb128: is there someone else we can ask?
<mdz> ogra: it's already done; Kamion has the details
<Burgundavia> ogra, a start --> https://wiki.ubuntu.com/EdubuntuMainInclusion
<seb128> mdz: not that I know of
<ogra> mdz, youre to fast :)
<mdz> untested as far as I know
<seb128> mdz: maybe jdub as some idea on the topic, but apparently he didn't find anybody for the running gdm bounty ...
<jdub> mdz, seb128: i've been polling people about it, not having much success
<seb128> hey jdub :)
<seb128> :(
<mdz> pitti: I forgot to give you your business cards at debconf
<JaneW> seb128,mdz: I just went thoguh my e-mails I already asked jdub... nothing came of it (back then anyway)
<ogra> jdub, thats the gdm/screensaver integration ? 
<seb128> do we have a freeze for universe now or can we get new crack?
<ogra> seb128, UVF ... but with approval you can get new stuff in
<mdz> JaneW: ok, then I guess it's deferred+bounty
<seb128> ogra: read GdmRoadmap spec
<seb128> ogra: for universe too?
<ogra> seb128, yep
<pitti> mdz: oh, I still have plenty
<seb128> DOH
<mdz> seb128: yes, but it's sort of a slushy freeze
<seb128> anjuta2 has been uploaded to Debian
<ogra> seb128, but we'll handle it quite loosely
<ogra> seb128, yay
<pitti> mdz: so at the oct/nov conference will be enough, I guess
<ogra> seb128, move it over then....
<mdz> pitti: did you get a batch of defective cards?
<seb128> mdz: any policy for new packages like anjuta2? That's a cool GNOME IDE expected by some users for some time but nobody stepped to package it before
<mdz> seb128: I have no problem with it
<pitti> mdz: yes, about 1/4
<jdub> ogra: the prettifying stuff
<seb128> mdz: cool, I'll get it so
<ogra> jdub, ah ok....
<seb128> ogra: read GdmRoadmap
<jdub> ogra: turn seb off /ignore :)
<ogra> heh...
<ogra> reading
<Burgundavia> ogra, all the links are there now
<Amaranth> seb128: When I get smeg 0.8 ready and packaged should I just give it to you?
<seb128> Amaranth: sure, thanks
<fabbione> Kamion, mdz: it's seeded..
<seb128> mdz: are you ok with making smeg the default menu editor?
<fabbione> or at least it should be
<ogra> Burgundavia, you can add mediawiki to the serverstuff too... its not seeded yet..
<Amaranth> seb128: Ok, if any bugs come up are you ok with just taking an 0.8.x package to fix them?
<JaneW> doko: ping
<JaneW> fabbione: why so quiet on the new kernel name front? 
<seb128> Amaranth: depending of the changes, if that's a rewrital of half of the code, nop 
<doko> JaneW: pong
<fabbione> JaneW: because i am working on quite a big piece of cleanup
<fabbione> JaneW: and it's taking time :(
<Amaranth> seb128: haha, the rewrite is happening for 0.8, thats why i asked
<JaneW> doko: hi, do you have an update on OpenOfficeLocalisation?
<fabbione> JaneW: unfortunatly i am cleaning what happens at the end of a kernel build.. and to test it properly it needs to be done from scratch everytime = TONS OF TIME
<JaneW> fabbione: ok fair enough (just checking)
<JaneW> fabbioneL at one stage I was at risk of running out of names...
<doko> JaneW: yep, last time I tried to edit the wiki, firefox crashed ... let me upgrade to the new one and try again
<JaneW> fabbione: sounds like loads of fun ...
<pitti> fabbione: did you have any success with the "open /dev/dsp multiple times" hack?
<fabbione> JaneW: don't worry :) you know i don't just sit here and IRC :P
<JaneW> doko: or just give me the update, I can post it for you...
<trs81> fabbione: nope, irqpoll didn't do anything, still lots of procs in the D state causing 30% iowait
<fabbione> pitti: nope :(
<JaneW> fabbione: you don't!? ;)
<fabbione> JaneW: that's only as sport
<seb128> JaneW: you have send this mail 3 time for wiki update now :p
<JaneW> seb128: i KNOW
<ogra> seb128, cant gdm support animated gif out of the box ? this one should be fairly easy if you ask in #ubuntu-artwork for a good animation :)
<seb128> STOP IT NOW
<mdz> seb128: I don't know about the menu editors; what is the other option?
<pitti> fabbione: ok, then we ditch that
<JaneW> seb128: not to mention the public and private IRC nags and induvidual e-mails... you;d think people were reluctant... ;)
<mdz> seb128: the inquiries will continue until the updates happen ;-)
<mdz> resistance is useless
<seb128> mdz: you have not catch-up on ubuntu-devel list or just skip my mails ? :p
<mdz> I have hundreds and hundreds of unread ubuntu-devel messages
<seb128> k, I've mailed the list about that next week
<mdz> HEAPS
<seb128> right click on the menu, you have an edit
<fabbione> mdz: welcome back to work :P
<seb128> that's the trivial GNOME stuff
<seb128> it only hide/show entry
<seb128> as said with the mail, user expect to be able at least to put new entries
<mdz> fabbione: I have been busy fostering improved community relations
<seb128> so I propose to change this one by smeg
<fabbione> mdz: eheh
<JaneW> seb128: I have seen your e-mails... but you do still need to update your BreezyGoal to keep the updates central - my ubuntu-devel inbox is sitting at close to 800 now...
<mdz> seb128: I have no objection; if you're unsure, maybe ask ubuntu-devel for opinions
<doko> JaneW: OO.o2 works out much nicer with adding new translations. xhosa was updated, is missing some outdated message strings. integration with rosetta is started. building language packs without building binaries needs input from our ftp master
<ogra> seb128, smeg should automatically submit bugreports with the .desktop file for missing ones if one ges created ;)
<mdz> if no one else has strong feelings about it, it's your call
<ogra> s/ges/gets
<\sh> hmmm...Jane is whipping her devs very badly today ,-)
<seb128> which is written by Amaranth, used by many users already (that's the editor pointed to hoary users asking for one) and using pygtk/pyxdg
<JaneW> \sh: they are making me do it... they obviously love being nagged... ;)
<seb128> mdz: I've asked ubuntu-devel for opinion, people agree ... but since I got mainly reply from users and not from other distro guys
<Amaranth> I'm sorry, Amaranth is currently unavailable due to stupid vlc build problems. Please try again in 12 years.
<seb128> JaneW: I've updated my wiki goals yesterday !
<ogra> Amaranth, just wait until wx 2.6 is there
<JaneW> got this yesterday, why did God invent the female orgasm?
<Amaranth> ogra: it's not that
<\sh> JaneW: yeah..I know this feeling ...;)
<ogra> \sh, female orgasm ?
<Amaranth> ogra: it's theora_pic, some X stuff, etc
<ogra> \sh, YOU ?
<JaneW> so that woman can moan even when they are happy ;)
<\sh> ogra: nonono
<ogra> hehe
* davyd handles the drumkit
<\sh> ogra: it didn't refere to this female ...what isit?
<davyd> badoom-tish!
<ogra> \sh, lol
<JaneW> seb128: many thanks - in which case messages are not directed at you :))
<seb128> you're welcome :p
<JaneW> davyd: lol
<Burgundavia> ogra, look now
<\sh> actually I need a love^Wlife again
<mdz> seb128: I'd say go ahead with it, then
<ogra> Burgundavia, WOAH
<seb128> mdz: thanks
<Burgundavia> ogra, now comes the hard part, all the research
<ogra> Burgundavia, many many thanks :)
<seb128> Amaranth: go to code on smeg, 0 bug must remain
<JaneW> er is Xen and XenIntegration the same thing? (I thought not)
<Amaranth> ok, someone else can sync vlc from sid and make it build
<Amaranth> have fun!
<ogra> Burgundavia, its just goint throug 3 security searchengines, mostly you wont find anything... but there are some where pitti will get bad headaches :)
<Burgundavia> yes
<JaneW> Mithrandir: ping
<seb128> "Sorry, a system error occurred "
* seb128 kicks malone
<ogra> seb128, gtk bug in malone ?
<seb128> no, malone bug 
<pitti> haha
<ogra> heh
<Amaranth> JaneW: what are you "re porting" exactly? :)
<seb128> it refuses to edit a bug
<ogra> pitti, look at the big wave of ugly packages that will approach you soon: https://wiki.ubuntu.com/EdubuntuMainInclusion
<ogra> seb128, logged in ?
<seb128> ogra: no no, I'm stupid
<ogra> :-P
<seb128> ogra: https://launchpad.ubuntu.com/malone/bugs/1468, click on "Ubuntu mail-notification"
<JaneW> Amaranth: huh?
<pitti> ogra: already saw them, I get autonotified on wiki changes
<ogra> seb128, eek
* fabbione takes away the caps lock from JaneW
<Amaranth> JaneW: Oh, I'm just making fun of a typo. :D
<ogra> pitti, ah...
<JaneW> fabbione: I never use caps lock :P
<\sh> Amaranth: oh man, be careful...this girl is hitting hard ,-)
<fabbione> JaneW: ehehe
<seb128> pitti: <jdub>  seb128: you just synced firefox, <jdub>  seb128: but... you touched it... now you own it!
<seb128> pitti: happy? :p
<davyd> yeah, don't you feel silly when you're typing in caps
<pitti> seb128: works for me
<JaneW> Amarthan: typos however are very frequent... I fancy myself as being able to type far faster than I actually can... hence the errors . I'm working on it...
<Amaranth> seb128: hehe, 1.0.6 will probably be out tomorrow
<seb128> pitti: NO WAY
<davyd> and then you realised that you could have used the capslock?
* pitti hands seb128 a cute fox mascot
<Burgundavia> pitti, can i just link to https://wiki.ubuntu.com/EdubuntuMainInclusion#preview to MainInclusionQueue
<Amaranth> JaneW: Tab completion works wonders. :)
* Amaranth hides now
<JaneW> Amaranth: yes, when I remember to use it ;)
<pitti> Burgundavia: why didn't you put it on the main page in the first place? well, but linking is okay for me
<Burgundavia> pitti, the list is huge and may be worked on by specific people
<pitti> right
<seb128> Amaranth: I've a smeg bug for you .... why does it list all the app submenus as <Menuname>... ?
<Amaranth> eh?
<\sh> lunchtime...bbl
<seb128> Amaranth: maybe that's made by gnome-menus
<Amaranth> <Menuname>?
<Burgundavia> ogra, I am off to bed. I will work on some tomorrow
<Amaranth> I don't know what you mean.
<seb128> Amaranth: anyway an editor put "Edutainment" at the bottom of the menu instead of its normal position
<ogra> Burgundavia, thanks for tha help :)
<Burgundavia> ogra, np
<Amaranth> oh!
<Amaranth> you're messing with layout stuff
<seb128> an editor made
<seb128> <Layout>
<seb128> <Menuname>...
<seb128> <Menuname>...
<seb128> <Menuname>...
<Amaranth> yeah
<ogra> cool
<seb128> </Layout>
<Amaranth> but it didn't include <Menuname>Edutainment</Menuname>
<seb128>                 <Menuname>Multimedia</Menuname>
<seb128>                 <Menuname>Edutainment</Menuname>
<seb128>                 <Merge type="menus"/>
<ogra> you can shuffle positions ? 
<Amaranth> Why did you put it on the bottom?
<Amaranth> ogra: Yep. :D
<ogra> cool++
<seb128> Amaranth: I didn't!
<Amaranth> And put in separators, and put entries on the main menu...
<seb128> Amaranth: if that's not smeg that's gmenu-simple-editor
<Amaranth> gmenu-simple-editor doesn't support that
<seb128> yeah, that's why I pinged you
* fabbione -> food
<Amaranth> it looks like you did a DnD reorder
<seb128> hum
<Amaranth> otherwise i have no idea
<seb128> hint
<seb128> that's "ducation" in french
<seb128> and it seems to not like the special char
<Amaranth> d'oh
<Amaranth> i have a feeling it's a pyxdg bug
<seb128> that's fine with a C locale
<Amaranth> if you don't have <Layout> defined the menus are supposed to be sorted alphabetically
<seb128> Amaranth: anyway, where do you want bugs... should I create a bugzilla.ubuntu.com smeg entry and assign bugs for it to you? :)
<Amaranth> i'm guessing it's sorting ducation last and then do you something to make pyxdg create a <Layout> it gets stuck there
<Amaranth> not my bug
<Amaranth> file a bug on the fd.o bugzilla against pyxdg
<seb128> Amaranth: I've moved ~/.config/applications.menu away, I run smeg and ducation is at the bottom
<Amaranth> although the dev won't be back for another 3 or so weeks
<seb128> Amaranth: you are no upstream for pyxdg too? :)
<Amaranth> no
<seb128> ups, I thought
<Amaranth> you're the one who told me to use pyxdg :P
<seb128> you said "we are going to get a new version", etc
<Amaranth> yeah, we work together
<Amaranth> usually a pyxdg release comes out the same time a smeg release does
<seb128> yeah, but some weeks after you were using "we" for pyxdg, so I assume you became an upstream :p
<Amaranth> i can sort of figure out what's going on in there, mostly i just helped write xdg.MenuEditor
<Amaranth> i'll see if i can't figure this out
<seb128> /usr/share/doc/python-xdg/examples/test-menu.py list ducation at the bottom
<Amaranth> yeah, pyxdg bug
<seb128> thanks
<JaneW> fabbione: if you have a minute... please look at BreezyGoal Xen...
<JaneW> fabbione, do you agree with the comment? And even if you do there's an issue that Ed is still MIA...
<JaneW> pitti: thanks for the updates :))
<Amaranth> seb128: shit, it's a python bug :/
<seb128> Amaranth: oh?
<pitti> JaneW: nothing really exciting, I'm afraid :-/
<Amaranth> seb128: cmp('ducation', 'System Tools') returns 1
<Treenaks> Amaranth: in your locale
<Treenaks> Amaranth: sort order is locale-dependent
<Amaranth> oh yeah
<Amaranth> so i can't even work on this, don't feel like reading french :)
<ogra> Amaranth, there will be more languages .... 
<ogra> Amaranth, ubuntu supports about 90
<Amaranth> i know
<Amaranth> i'm saying i can't work on this bug
<Amaranth> wait, how do you run just one app with a certain locale?
<seb128> Amaranth: LC_ALL=C ./app 
<Amaranth> ok, what do i put to get french?
<seb128> dpkg-reconfigure locales
<seb128> pick fr_FR.UTF-8
<seb128> and LC_ALL=fr_FR.UTF-8
<pitti> Amaranth: LANG=C foobar
<seb128> LANGUAGE=C for graphical apps
<seb128> GNOME seems to pick this one before LANG
<Amaranth> cmp('ducation', 'System Tools') returns 1 with french too
<Amaranth> python bug?
<pitti> mdz: I recently asked on the list about interested persons about printing, but silence so far
<mdz> pitti: mark suggested that we contact cups upstream
<pitti> mdz: I can probably manage the derooting of hplip until feature freeze, but I can't test it
<pitti> mdz: about our PrintingRoadmap spec proposals?
<pitti> mdz: that would rather be gnome-cups-manager upstream for the hotplugging side
<pitti> mdz: or eggcups, depending on how well seb128's experiments with eggcups go
<JaneW> pitti: did you see the e-mail I sent...?
<pitti> JaneW: yes, I saw
<JaneW> ok
<pitti> currently I don't even have a printer
<pitti> it went away with the moving of my flatmate
<seb128> pitti: eggcups will probably not replace gnome-cups-manager, it nice but has not the same feature (ie: you can't set up a smb or lp printer with it)
<JaneW> pitti: do you think this guy can do it? I asked him to send some more details, but he is worried that the spec is not very clear...
<pitti> JaneW: which spec/guy are you talking about?
<JaneW> pitti: the printing roadmap guy...
<pitti> JaneW: oh, I thought you meant your reply to my "Seeking help with/takeover of PrintingRoadmap" mail to u-devel
<pitti> JaneW: I don't see any other email wrt printing from you
<Amaranth> why can't we all just speak english? :)
<highvoltage> elmo
<JaneW> pitti: mdz just repsonded to us both... did you not received them? (I may be using the wrong address for you...?)
<pitti> JaneW: I just checked my ~/.procmail.log
<fabbione> JaneW: what comment in Xen specifically?
<pitti> JaneW: ah, that one. I didn't download that yet, sorry
<JaneW> martin.pitt@ubuntu.com
<Amaranth> seb128: This is not going to work, sorry.
<JaneW> fabbione: well mithrandir said your student is handling Xen... but he is actually doing Xen Integration - PLUS he is MIA...
<seb128> Amaranth: k, maybe I'll reconsider the menu editor choice, thanks
<Amaranth> seb128: It's a python bug. Unless I can find a workaround nothing is going to do any better.
<seb128> Amaranth: gmenu-simpler-editor works fine
<fabbione> JaneW: Mithrandir was the original assigned to Xen, than the student come up... now the student is MIA...
<mdz> ok, time to go catch the final plane
<Amaranth> seb128: Yeah, their sorting is done in C.
<fabbione> JaneW: probably Mith can take Xen back...
<fabbione> mdz: have fun
<seb128> Amaranth: do the same ...
* Amaranth doesn't know C
<fabbione> JaneW: but at 2/3 weeks from feature freeze i seriously doubt they can manage to do it
<JaneW> sigh
<fabbione> JaneW: i will talk with Mith and see..
<fabbione> but the option to make that happen seriously clashes with my planned vacation
<pitti> JaneW: replied
<JaneW> fabbione: :(
<Amaranth> collation tables, yay
<{Seb}> fabbione: please don't get angry with me this time but...
<{Seb}> what does  subprocess post-installation script returned error exit status 1 mean?
<pitti> {Seb}: which package?
<{Seb}> xlibs
<pitti> {Seb}: it generally means that the maintainer screwed up :-)
<pitti> {Seb}: known bug; sudo vi /var/lib/dpkg/info/xlibs.postinst
<pitti> right before the "test ... && ..." lines, prepend a "set +e"
<pitti> and right after, put "exit 0"
<{Seb}> prepend? you mean add?
<pitti> then sudo dpkg --configure -a
<fabbione> {Seb}: it's not question of being angry. these are #ubuntu questions and you are offtopic
<pitti> {Seb}: prepend = add in front of
<{Seb}> pitti: you are my hero!
<{Seb}> pitti: sorry to ask but it now gives me errors like rmdir: /etc/x11/xkb/types: Directory not empty
<{Seb}> pitti: should i remove the dirs
<{Seb}> pitti: i mean the /etc/x11/xkb dir
<pitti> {Seb}: please ask daniels in #ubuntu
<{Seb}> sorry
<pitti> {Seb}: I'm not sure, but you shouldn't remove them I guess
<comadreja> I'm interested in helping with the laptop stuff also... who should I talk to ?
<Nafallo> comadreja: mjg59 :-)
<trulux> anyone hre using prelink in Breezy who can feel free to send me the /var/log/prelink.log?
<pitti> trulux: wanna crack his machine? :-)
<pitti> trulux: please be aware that I recently patched prelink to not spit out addresses in the logs
<trulux> pitti: OK, great then
<trulux> no need
<Amaranth> seb128: Fixed. :D
<trulux> pitti: no 0-day for prelink so far
<seb128> Amaranth: ROCK
<seb128> Amaranth: how did you do?
<Amaranth> seb128: replaced cmp() with my own hackjob that creates a list and calls sort()
<seb128> k
<Amaranth> You'll have to include it as a patch until the pyxdg dev gets back
<Amaranth> let me pull from cvs and make a diff
<seb128> np, thanks
<Amaranth> seb128: http://dev.realistanew.com/locale_sort.patch
<seb128> thanks
<Amaranth> oh, i don't even need all that, hang on
<Amaranth> seb128: http://dev.realistanew.com/locale_sort2.patch
<Amaranth> much better patch
<Amaranth> it's weird, that didn't work in the interpreter, works in real code though
<JanC> <infinity> Gnobody : I don't recall anyone complaining about the 640x480x16 Win32 boot screens ovre the years.
<JanC> That's because they are/were 320x400x256   :-P
<seb128> Amaranth: cool
<j^> but so far nobody complained about the gray apple
<Treenaks> JanC: no, they're not..
<Treenaks> JanC: the Win95/8 one was, Win2k and XP have 256-color 640x400 (or 480?) screens
<Amaranth> yeah, that's what we should get
<Amaranth> like apple has
<Amaranth> just a simple logo and a little throbber
<JanC> well, anyway, they weren't 16-color
<Amaranth> that doesn't represent anything
<Treenaks> Amaranth: yes, but with semi-naked people
<Treenaks> JanC: that was win31 ;) 16-color 640x480 "starting up" screen
<JanC> only semi- ?   ;-)
<Amaranth> yay!
<Amaranth> 102F saturday and sunday
<Amaranth> 100F friday
<Treenaks> Amaranth: Farad?
* davyd coughs
<davyd> SI units
<JanC> davyd : you mean temperature in Kelvin ?  ;)
<davyd> sure, why not
<Treenaks> JanC: what does he mean by 100 Farad?
<Treenaks> JanC: ;)
<Treenaks> JanC: I mean.. that's a lot
<ogra> Treenaks, capacity, what else ?
<davyd> that's a lot of charge
<Treenaks> ogra: lots of it
<ogra> yeah
<Amaranth> It's going to be 39C
<Amaranth> 312K
<JanC> taht would be 39 C / 100 F I think   :)
<Treenaks> 312K, ah :)
<ogra> ah 312K, ok... finally a sane unit
<Amaranth> JanC: 102 degrees Fahrenheit = 38.8888889 degrees Celsius
<Amaranth> 100 is 38
<Treenaks> Amaranth: i.e. 
<JanC> well, here it's 18-20 C today...
<Treenaks> "too hot"
<Amaranth> Treenaks: yes, "too hot"
<Amaranth> "What's the temperature today? Too hot."
<Amaranth> 33C here today
<Amaranth> good thing i have air
<Nermal> Amaranth: ouch
<Amaranth> seb128: I thought you should know I do know of one issue with PyXDG that is kinda major. It totally bombs on non-UTF8 things. Shouldn't be a problem in Ubuntu though.
<seb128> Amaranth: k, thanks
<Amaranth> seb128: If you can figure out a way to actually make this error happen (non-UTF8 filename) it'll help me fix it.
<pitti> D'oh, who kicked my computer while I was at luch?
* Treenaks whistles
<seb128> Amaranth: what error should it give exactly?
<Amaranth>   File "/usr/lib/python2.4/site-packages/xdg/Menu.py", line 1025, in getMenuEntries
<Amaranth>     if menuentry.DesktopFileID not in ids:
<Amaranth> UnicodeDecodeError: 'utf8' codec can't decode bytes in position 25-27: invalid data
<Amaranth> this is easily hidable but the lanius would rather leave it failing until someone comes forward with enough data to solve it for real
<davyd> are the amd64 buildds back up?
<Nafallo> davyd: yes :-)
<Amaranth> if they are amd64 users are X-less now too
<davyd> Amaranth: mmm, -42 is still dodgy?
<Amaranth> yep
<davyd> ok
<Nafallo> Amaranth: I knew X is bad and didn't update ;-)
<davyd> they were X-less before
<davyd> because the data packages were still getting installed
<seb128> Amaranth: easy to get
<Amaranth> ?
<seb128> Amaranth: generate a non UTF-8 locale
<Amaranth> hmm
<seb128> ie: de_DE
<seb128> start LC_ALL=de_DE xterm
<seb128> cd /usr/share/applications
<seb128> cp gedit.desktop gedit.desktop
<davyd> there looks like nothing in the update that I really want/need
<seb128>     if menuentry.DesktopFileID not in ids:
<seb128> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc9 in position 6: ordinal not in range(128)
<Amaranth> ascii?
<seb128> I've that by running /usr/share/doc/python-xdg/examples/test-menu.py
<Amaranth> oh, python only knows ascii and unicode
<Amaranth> *shrug*
<Amaranth> shouldn't be a problem in ubuntu though, should it?
<Amaranth> everything is supposed to be utf-8
<ogra> Amaranth, yes, everything is supposed to, but tere is a lt of stuff not converted yet in universe
<Amaranth> yeah, someone installed 'iPodder' and got this error
<Amaranth> but i just realized i think there are about 10 places to find and fix to make pyxdg fail silently
<Amaranth> and skip that file
<ogra> Amaranth, there is a utf8 migration tool, written by Mithrandir, its not ready yet, but you probably can grab some conversion code from it
<Amaranth> python?
<seb128> what is the issue? the filename?
<Amaranth> yeah
<seb128> I don't think that a lot of packages install no utf8 filenames
<seb128> I don't have one here
<Amaranth> bad filename means bad DesktopFileID
<seb128> I would say that's a minor bug
<seb128> but still a bu
<Amaranth> if no packages do it only someone who knows what they're doing should be able to make non-UTF8 filenames
<seb128> or some broken software
<pitti> Hi carstenh, how's it going?
<carstenh> hi pitti, fine. i'm currently working on the core module ond hope to release a first version before jbailey comes back from vacation
<JaneW> carstenh: hello
<\sh> pitti: it isn't the truth, right, that mentors.debian.net is running on ubuntu?
<carstenh> JaneW: hi
<JaneW> carstenh, nice to see you here - seems like you are busy :)
<seb128> elmo: glib2.0 (2.7.3/experimental) sync please :)
<carstenh> pitti: JaneW: i will send a weekly report today or tommorow
<carstenh> JaneW: yes :)
<JaneW> carstenh: excellent thanks. Just been reporting an MIA student, so you are a huge contrast to that:)
* JaneW hands carstenh a virtual Gold Star (tm) ;)
<carstenh> JaneW: jbailey wanted to ask you who the maintainer for GraphicalConfigTools is
<carstenh> JaneW: thanks :)
<carstenh> pitti: a few thinks have changed, but they are not on the wiki at the moment
<Mitario> hello everyone
<JaneW> carstenh: I think it's ogra - but let me check
<JaneW> ogra: ping
<ogra> yep
<JaneW> ogra: do you maintain GraphicalConfigTools?
<JaneW> ogra: you were the lead on the soec...
<JaneW> spec
<ogra> thats me, or rather retrix who is working on the bounty
<JaneW> carstenh: is that all you needed?
<carstenh> JaneW: yes, thanks
<ogra> carstenh, doe he need something from me ?
<ogra> does even
<Riddell> pitti: did you see the QCATLS main review request?
<carstenh> ogra: hi, i'm working on the firewall bounty. are you going to implement another system-v service configuration tool?
<carstenh> ogra: or rather your student
<ogra> carstenh, i think we're fine with the one from gnome-system-tools thats currently in
<carstenh> ogra: ok
<ogra> do you plan a startup script for the firewall ?
<Mitario> hmm, xbase-clients has been broken for a few days now right?
<ogra> Mitario, yes....
<carstenh> ogra: do you think integrating the firewall-gui in your framework makes sense?
<carstenh> ogra: yes, it will be in /etc/network/if-{up,down}.d/
<ogra> carstenh, do you write something new ? or do you adjust the firestarter stuff ?
<carstenh> ogra: and a gui to easily configure the firewall
<carstenh> ogra: something new, integrating firestarter in ubuntu the way we do it would be very hard
<retrix> ogra, carstenh, i could possibly manage that
<retrix> carstenh, how involved do you imagine the configuration options would be?
<ogra> there is no special framework, but if you need someone to write a gui probably retrix is your guy, the ndiswrapper gui he wrote is nearly in shape so there might be time for more :)
<carstenh> retrix: hi, i don't really understand your question :/
<carstenh> ogra: i will write the gui myself, it's part of the bounty ;)
<schweeb> I've always rather disliked firestarter
<ogra> ah, ok
<retrix> ok
<schweeb> it could use quite a bit of fixing before it's ready for the home user
<ogra> schweeb, its not worse then zone alarm ;)
<schweeb> at least zone alarm manages to cleanly remove all of its rules before exiting
<Nafallo> I started to dislike firestarter when I couldn't upload POs to rosetta :-P
<carstenh> retrix: are you writing your tools with pygtk?
<retrix> carstenh, yep
<schweeb> firestarter tends to leave behind all kinds of rules
<pitti> \sh: their web site says so
<\sh> pitti: and then this discussion...funny..really
<carstenh> retrix: i will integrate my gui into gnome-system-tools (glade2 + c + python)
<schweeb> last time I tried it, it basically blocked all access to the internet, and then after I quit, it stayed that way
<schweeb> I had to manually flush my iptables
<pitti> \sh: well, there's not really sth to discuss about, it rather belongs to debian-curiosa or whatever :-)
<pitti> Riddell: yes, I did. Sorry, still EBUSY
<pitti> Riddell: could you add the bug and security history?
<Riddell> pitti: no rush, just checking you'd registered it :)
<ogra> carstenh, g-s-t had a perl backend last time i looked (dunno if garnacho rewrote it)
<Riddell> pitti: ok, will do
<pitti> Riddell: yes, I subscribed to the wiki page
* schweeb goes to work
<\sh> pitti: I just had to laugh...but not because it's running an apache2 package with ubuntu string, but that there is a small thread about it
<carstenh> ogra: they would accept pery and python backends (according to the readme)
<ogra> carstenh, so its rather (glade2 + c + perl) ;)
<ogra> oh, thats new, nice :)
<carstenh> ogra: ... and ubuntu projects are normally written in python
<ogra> yep
<carstenh> pitti: do you think a firewall should be started by default, even if no service is installed? it would prevent viruses from being accessed from outside.
<carstenh> ... of couse it would be possible to disable it i.e. with vi /etc/default/firewall or the gui
<pitti> carstenh: sure, if the default policy is sane (which it should anyway), it should just work
<Nafallo> ++ on that one :-)
<pitti> \sh: it's not the apache string, the web site advertises "powered by ubuntu"
* Nafallo reads the wikipage
<carstenh> pitti: it will be sane, but only services that provide rules would be able to listen to the network. if a use installs something without using the package-system it would be blocked
<carstenh> ... unless the user writes rules for that daemon
<pitti> carstenh: I guess we can still disable it last-minute if we don't manage to create rules for all servers?
<Nafallo> ... or add an advanced tab in the gui?
<ogra> eeek
<carstenh> pitti: sure, will be a 1-line-patch :)
<ogra> Nafallo, rather leave them out of the gui and make it gconf keys you can set with the gconf-editor
<carstenh> must all rules be finished before the 11th of august?
<carstenh> i guess a missing rule is some kind of important bug, so it should be fixable even later
<Nafallo> ogra: I would prefer an "advanced" button. you should not have to use the registry ;-).
<ogra> Nafallo, its not a registry, its the place where advanced options have to go to not clutter the GUI and make it ugly
<mdke> gconf is totally similar to a registry
<mdke> IMO
<ogra> not at all
<Treenaks> gconf != debconf :)
<Nafallo> ogra: IMO it looks more like winreg than anything else I've ever seen in linux ;-)
<mdke> from a user perspective
<ogra> the windows registry is a havoc...
<Nafallo> or regedit rather
<ogra> mdke, gconf is dotfiles-ng ;)
<Treenaks> ogra: no, Havoc wrote gconf (right?)
<ogra> hehe
<mdke> ogra, naturally it is not as bad, but it has a similar feel for the user
* ogra likes this wordgame everytime
<mdke> it is totally un-user-friendly
<ogra> mdke, thats why its for advanced users that need advanced options...
<azeem> mdke: normal user shouldn't need to use it, anyway
<mdke> that is debateable
<Nafallo> anyway. with an advanced tab to override serviceports and the like you could actually run your apache2 as localhost only if you would want to.
<mdke> but i don't really think its that good for advanced users either
<jdub> ogra: that's not what gconf is for
<ogra> jdub, so explain it to us then :)
<jdub> mdke: gconf is for *programmers*; it is an api and infrastructure for handling configuration metadata, including policy (mandatory/default settings)
<mdke> jdub, sometimes users edit gconf to change settings which do not appear in the gui, right?
<jdub> mdke: gconf-editor, the raw front end, is not intended to be used by regular users
<jdub> only very particular kinds of users
<ogra> jdub, how do i set burnproof for n-c-b then ?
<carstenh> pitti: what about logging _spoofed_ packets, sould it be possible?
<jdub> ogra: hrm?
<ogra> jdub, without using gconf-editor as a advanced settings tool
<jdub> ogra: it's not designed to be an "advanced settings tool"
<pitti> carstenh: unintrusively, yes. some syslog
<azeem> ogra: just edit the XML data in ~/.gconf with vi
<mdke> jdub, yes I mean gconf-editor the frontend. the discussion was about whether settings should be ommitted from a gui preferences tool because they can be accessed there. My view was "no"
<ogra> jdub, burnproof is off by default, n-c-b has no option to enable it, gconf is the only way... there are many apps that use it this way
<bob2> hah, nearly raster
<jdub> i don't know what burnproof is, or what the use cases for it are, so i can't answer that
<Nafallo> ogra: that's a bug then
<jdub> azeem: those files are not meant to be modified directly
<ogra> jdub, a important CD burning setting you need to burn on underpowered machines
<carstenh> pitti: ok, so i have to add spoofing rules... using /proc/... iirc does not support logging
<Nafallo> jdub: make cd-rws detect what maximum speed to use on the fly (or something like that)
<bob2> burnproof = not get buffer underruns, even when the cpu is hammered
<Nafallo> s/rw/r/
<ogra> Nafallo, nope
<jdub> mdke: the presence of gconf-editor is not related to the choice to make things 'just work' or the requirement for a preference
<azeem> Nafallo: no, it just stops the laser when there is a buffer-underrun and restarts when the buffer has been refilled
<ogra> Nafallo, it cares for buffer underruns while burning
<mdke> jdub, that is also my view
<azeem> Mr. Schilling argues that it does make 1:1 copies, so you have to forcibly enabled it in cdrecord
<mdke> the point i was making
<azeem> eh, s/does/does not/
<Nafallo> azeem, ogra: ahh, thanx :-). I've always wondered exactly how that worked.
<jdub> ogra: is there any reason to not use it?
<ogra> jdub, i'm just opposed to having "advanced" tabs anywhere in a config tool
<ogra> jdub, yes, some writers dont support it
<jdub> can that be detected?
<seb128> jdub: k, I'm bugging you again, sorry ... but l10n list?
<ogra> dunno... but i can look at it for breezy+1 :)
<seb128> jdub: if there is no way just say it, ubuntu-fr.org guys will set one
<Nafallo> ogra: yay! breezy+1 goal assigned to you already? ;-)
<seb128> jdub: I was just trying to make them working closer of Ubuntu
<ogra> Nafallo, heh
<mdke> seb128, what is l10n list?
<jdub> it sounds like the feature exists in n-c-b, but there has been no decision to make it 'just work' or put in a pref
<azeem> does n-c-b still use cdrecord, or rather libburn these days? (and are those two really independent?)
<bob2> mdke: localisation
<ogra> azeem, still cdrecord
<jdub> seb128: going to do it tonight; standard will be ubuntu-<lang>-l10n
<seb128> mdke: a list to coordinate translators work
<ogra> azeem, and yes, they are independent
<seb128> jdub: THANKS :)
<mdke> seb128, different to ubuntu-translators@lists.ubuntu.com?
<seb128> mdke: I want a french list for french translators
<mdke> ah cool
<mdke> nice idea
<seb128> mdke: to coordinate french translations
<mdke> we've been doing ours on freelists.org
<ogra> jdub, i think its a HAL thing... the newer versions should be able to detect if burnproof is possible...
<jdub> seb128: i'll make you the owner for now, and you can help them sort out owner/admin stuff :)
<jdub> ogra: sounds about right :-)
<Nafallo> jdub: could we have one for sweden to? I try to get those guys started to make some decisions on coordination. I haven't got an answer yet.
<ogra> yep :) 
<seb128> jdub: k, I'm getting used to be set as owner for the lists :p
<jdub> ogra: so in the mean time, defaulting to off and not bothering with tweaky bits in the ui is the right idea
<jdub> Nafallo: i generally only create lists based on clear demand :)
<ogra> jdub, ok... it was just my example.... we were talking about advanced options for a default enabled firewall originally ;)
<jdub> seb128: should get an email  in a minute
<Nafallo> jdub: good point. I will probably send them another mail soon, and then go with "I took the silence as yes" to put me as coordinator ;-). anyway, that's nothing that can't be undone.
<jdub> Nafallo: is this for translation team stuff, or loco team stuff?
<Nafallo> jdub: translation
<jdub> Nafallo: and there's too much traffic on the loco team list for it?
<Nafallo> jdub: we don't have a loco for sweden that I'm aware of.
<mdke> jdub, if you intent this sort of list to become standard, we can think about moving ubuntu-l10n-it from freelists.org to lists.ubuntu.com. The list is used to coordinate the whole italian documentation team, regarding both rosetta and the wiki work
<mdke> intent/intend
<jdub> mdke: yeah, if there are others out there, we should pull them in
<mdke> jdub, okay, will you sort it? I can get the archive
<jdub> Nafallo: hrm, had odd memory of an se list -> anyway, that's the first step, creating a loco team, then we can split off an l10n list later if required
<mdke> but we use the list for all documentation rather than just rosetta translation
<jdub> mmm, i was thinking of making them ubuntu-<lang>-dev, but... meh
<jdub> l10n covers what that development would be, so
<highvoltage> elmo
<Nafallo> jdub: I disagree. why do we need a loco for translation work? I rather expand the other way around.
<jdub> Nafallo: the idea is that loco teams handle localisation and local community outreach
<mdke> jdub, well we have a number of groups in the locoteam, like forum/website development and locoteam, that don't use the ubuntu-l10n-it list
<jdub> Nafallo: so first we'd create ubuntu-se (which doesn't really have to be a full-on loco team)
<jdub> Nafallo: then once the l10n traffic got too much for the other loco tasks, we split off a -l10n list (as has happened in france)
<jdub> mdke: that's what loco teams do
<mdke> we use our ubuntu-it for support
<Nafallo> jdub: in other words we create a loco-team that really is a translation team? :-)
<Nafallo> hehe, might work :-)
<jdub> Nafallo: to start with, if that's the major activity of the loco team, yes
<jdub> the loco teams focus on different kinds of things, depending on their drive
* davyd futzes with control.tar.gz to install a package
<Nafallo> jdub: sounds good to me. I'll try to get those things rolling when the schools start again and all students are back at broadband ;-).
<JaneW> am I correct that there is no tech board tonight?
<mdke> next week?
<mdke> 26th
<Nafallo> JaneW: 26 July 20:00 UTC: Tech Board
<Nafallo> :-)
<ogra> JaneW, Tue 19 July 14:00 UTC Community Council -- http://wiki.ubuntu.com/CommunityCouncilAgenda 
<mdke> jdub, seems to be no "export archives" on freelists.org
<jdub> mdke: if you figure out how, let me know - though i'm going away for a week tomorrow, so perhaps we'll do this after that
<mdke> jdub, we don't have a problem continuing to use that list, its rocket fast :D
<mdke> jdub, i'll email them tho
<azeem> are universe packages not built automatically from unstable?
<ogra> azeem, we're in UVF
<ogra> no autosyncs anymore
<azeem> ah
<azeem> pymol might actually become installable when getting a sync, but I'm not sure
<davyd> ok, my attempt to build a Xinerama aware xscreensaver has failed
<ogra> davyd, as i said, i have it here... i just need to clean the code of the new lockwindow hack
<davyd> ogra: but I wanted to do it now
<davyd> also, I am avoiding dist-upgrading X for a while
<davyd> which is likely to be a dependancy of a new xscreensaver
<davyd> my xscreensaver appears to link against libXinerama
<ogra> davyd, wait a sec... you need amd64 ?
<davyd> ogra: yeah
<davyd> I'm mostly interested in why mine didn't work
<davyd> the 'test-xinerama' reports things sanely
<ogra> davyd, just uploading a binary... should be there in 5min
<ogra> davyd, but it might not work as well, my X is a bit outdated...
<davyd> I'm running -36 with random recompiled crack
<ogra> so it myight link to the wrong lib currently
<davyd> mmm, anything could happen really
<tseng> Nafallo: how big is your mirror
<ogra> davyd, http://www.grawert.net/xscreensaver_4.21-4ubuntu6_amd64.deb
<ogra> davyd, breakage in the unlock window is intentional :P
<Nafallo> tseng: 15G or so. main+restricted amd64+i386 :-)
<davyd> so turn of screen locking?
<Nafallo> tseng: and not updated in some days ;-)
<davyd> s/of/off/
<ogra> davyd, nope, but dont report any bugs if you find some.... and tell me how you like the window ;)
<davyd> ok, can do
<davyd> ogra: hard to tell, something is wrong with the xinerama-ness
<davyd> ogra: this is the same problem I was having earlier
<ogra> davyd, yes, but its a X prob...
<davyd> it isn't aware, and screen0 flashes
<Nafallo> tseng: was about 60G when it was full !ppc :-)
<ogra> davyd, lets solve it together if X is in shape (i have the bugs about it assigned anyway)
<davyd> ogra: I wonder if it's my half baked X setup
<ogra> davyd, if my compile fails for you too, its unlikely your setup
<ogra> (i have no xinerama machine around here)
<davyd> it's not the compile
<ogra> (at least not set up=
<davyd> it simply doesn't work as advertised
<davyd> which is the problem I was having
<davyd> however, the test-xinerama thingo that is buildable in the xscreensaver source tells me about the screens
<ogra> does it show the lockscreen in the middle of both screens ?
<ogra> or only on screen0 ?
<davyd> ogra: in the middle of both screens
<dave> hi! anyone here who is experienced with preseeding of custom ubuntu/debian boot cds ?
<davyd> it also has the hack spread across both screens
<ogra> davyd, thats the xinerama implementation in X then
<davyd> ogra: so, out of interest, how is it working for GTK+
<cartman> hi all
<ogra> davyd, in debian its not even compiled with the -with-xinerama-support compile option, but works anyway
<cartman> gcc doesn't build on amd64, seems like ada should be disabled
<davyd> hmm
<ogra> davyd, dunno, i'd never touch gtk for the screensaver
<Treenaks> teh gtk bong!
<ogra> davyd, its all fake ;) theming with xpm and xft
<davyd> I meant actual GTK+
<davyd> my desktop is Xinerama aware, and the test app is aware, but the main xscreensaver is not
<ogra> davyd, ah, thats what you mean...
<davyd> they appear to be linked against the same library
<ogra> davyd, but probably xscreensaver does the wrong calls
<davyd> hmm, strange
<davyd> I've seen it work, it works in fc4
<ogra> when i started the lockwindow theming last year, the lock.c file hasnt been touched for about 10 years... might apply to other parts too
<ogra> so i'd guess jwz has built in some hardcoded crap to acheive xinerama (as he does with the logo in the original lock win)
<dave> preseeding ? anyone ?
<davyd> ogra: and for the hacks themselves?
<davyd> on fc4 it runs a hack per screen
<ogra> davyd, most is third party stuff
<davyd> ogra: redhat patches?
<ogra> dunno hiw jwz incorporates them
<ogra> yep, sounds good
<davyd> I wonder if you can get a list of patches in a Fedora package
<ogra> davyd, as i said, i'm currently not working on that one and wanna wait until X is in shape again
<davyd> mm, I'm just interested
<ogra> but fedora patches might solve it
<ogra> i just havent looked :)
<ogra> yet
* davyd shoves in the fc4 DVD
<davyd> hmm, no source...
<ogra> davyd, cant you just digthe bug database at fedora ?
<davyd> I was imagining I could get it from the SRPM
<ogra> hmm
* davyd finds it on the university mirror
<davyd> hmm, I was meant to be studying
<davyd> I think I got distracted
<ogra> hehe
<bddebian> Heya
<davyd> nautilus is annoying not Xinerama aware, I should work on that, it's annoying me
<davyd> nope, they don't seem to patch that particular thing
<ogra> hmm
<Amaranth> CC meeting starting now
<Amaranth> sabdfl: The meeting started already
<pitti> Hey sabdfl 
<pitti> Hi Keybuk 
<Keybuk> ugh, laundry is so tedious
<Keybuk> someone should invest heavily in self-cleaning clothes
<chmj> heh
<dilinger> Keybuk: are you aware that they've invented machines to do laundry *for* you?
<dilinger> you simply put the clothes in the machine, put in some detergent, turn it on, and 30mins to an hour later, the clothes are clean!
<dilinger> it's quite amazing :)
<Amaranth> dilinger: Ok, self-folding clothes then.
<Amaranth> :)
<dilinger> feh, folding clothes is optional :)
<Keybuk> dilinger: yeah, but the clothes then require drying, ironing in some circumstances
<dilinger> i suppose if you wear things other than tshirts and jeans, then yes, additional care is required
<trygvebw> is there any reason why mkfontdir is NOT in the xutils package? how soon will that be fixed?
<Amaranth> 2017
<Amaranth> daniels is working on it, just be patient
<seth_k> you forgot to account for the time dilation produced by faulty Xorg... 2018
<Amaranth> it might be a week or so though
<trygvebw> ok
<cartman> any idea about gcc 4.0.1 problem?
<cartman> maybe someone can tell me irc nick of "Matthias Klose" ?
<davyd> Mithrandir: you around?
<cartman> so I can notify him
* ogra hands mjg59 the "usplasher of the century" award !
<davyd> ooher, is usplash available in something?
<pitti> D'oh, the current dailys are so *horribly* broken...
<ogra> davyd, see ubuntu-evel@ ;)
<pitti> anyway, gotta go, cu tomorrow
<ogra> devel even
<davyd> yay. devel mailing lists
<jani> elmo, I know it's upstream freeze, but what about new packages in sid? I see mecurial has been there for a while but it's not in ubuntu
<jani> http://packages.debian.org/unstable/devel/mercurial
<jani> also http://packages.debian.org/experimental/mail/mutt-ng :)
* davyd sleeps
<ogra> jani, you need approvement
<jani> ogra, where do we get those?
<ogra> after the meeting...
<jani> irc, ml, wiki?
<jani> ah ok
<jani> sure I didn;t want to get them myself, just ask elmo to sync if he finds it reasonable
<Mithrandir> davyd: yes
<dieman> daniels: poke
<Amaranth> dieman: xbase-clients isn't done
<dieman> heh
<dieman> any other x-like people in here?
<Amaranth> depends on what you need
<dieman> i was wondering how fucked I may be if I backport breezy's x server to hoary.
<dieman> ie: are upgrades to breezy going to be ok
<Amaranth> I'll strangle you.
<dieman> or is there major breakage coming?
<dieman> hey, its just a local package :)
<dieman> im not distributing this stuff
<Amaranth> oh
<Amaranth> well, xorg doesn't work now and work on making clean upgrades from hoary to breezy xorg hasn't even started
<dieman> heh
<dieman> ok, that answers my question
<dieman> now to look into backporting the intel driver into hoary's x server :)
<Amaranth> dist-upgrade takes 3-4 trys to even get everything installed
<dieman> hah
<dieman> awesome
<Amaranth> and that's when xorg is working
<dieman> I need i945 support like, now. :)
<dieman> so i'll just look into it on this end
<Nafallo> jdub: blog-ping ;-).
<Nafallo> jdub: you got mail instead :-)
<doko> Keybuk: would it be technically possible to run MOM for a list of source packages, i.e. those from CxxLibraryList?
<Keybuk> sure
<Keybuk> list needs to be of the form "source-package-name distro-release-name"
<Keybuk> ie. "coreutils main" ... "wpasupplicant universe"
<Keybuk> etc.
<doko> ok, I'll prepare one. sepratate by newline?
<Keybuk> yup
<Keybuk> if you get it to me within the next ~24 hours, I can set up a run for you
<Keybuk> otherwise you'll have to wait until ~Friday
* dieman hates building X someplace just after hating building openoffice.
<dieman> openoffice builds suck.
<seth_k> haha, how long did it take?
<dieman> oh, i think that one was at least 12 hours, i dont remember
<dieman> it was awful
<dieman> took like 10gb of space too i think
<dieman> i just remember it being a few order of magnitudes worse than X
<dieman> lamont probally knows well how long it takes on the buildds
<lamont> OO.o is around 6 hours on i386 (building arch all)
<dieman> heh
<lamont> faster everywhere else
<dieman> youve got faster boxes most likely too
<fabbione> hey lamont 
<dieman> this was only on my 3ghz with 1gb of memory and single disk
<lamont> dieman: 3Ghz, 2GB RAM
<dieman> yeah
<dieman> more memory
<dieman> lamont: how you doing these days?
<dieman> or you busy, i can talk to you some other time too.
<lamont> doing well, mostly.  catching up on email and such before heading to the office for the day
<dieman> heh. i hate the email after being gone for a week
<dieman> we moved just earlier this month, so i wasn't in the loop here for a bit. 
<lamont> iz daily thing...
<dieman> heh
<lamont> week or 2 ago, I did a hoary install on ia64, and we got the one bug fixed for breezy..
<dieman> ive got a old itanium 1 collecting dust
<dieman> its been turned off for a while.
<lamont> I need to fetch a new d-i build for ia64 and see if the most recent kernel needs some ia64 love, or where my issue is there
<dieman> 2 processor, 4 way mobo
<bddebian> Well send it to me! :-)
<dieman> so broken spatial is going away in breezy it sounds, right?
<mjg59> jbailey: Ping? We need to discuss initrd/initramfs and usplash integration at some stage
<carstenh> mjg59: he will not answer before wednesday
<mjg59> carstenh: No problem
<Keybuk> 2005-07-19 17:36:33,017 INFO Creating manifest item for 'apache2-2.0.54/debian/patches/001_apachectl_is_differently_fucked'
* Keybuk giggles
<Keybuk> I still think that's funny, every time I see it
<fabbione> seb128: ping?
<seb128> fabbione: pong
<fabbione> seb128: i found the problem... 
<fabbione> seb128: i will need your help to find the cure :(
<seb128> the libc bog?
<fabbione> seb128: basically a set of gnome libs have been linked wrongly
<fabbione> the toolchain now seems to work
<fabbione> probably it was in the past..
<fabbione> this link error did propagate quite wildly around all of gnome
<seb128> what send? and do they have anything caracteristic?
<seb128> s/send/set/
<fabbione> up till now i figured only 2 libs that need to be rebuilded..
<fabbione> seb128: eh i am not sure..
<fabbione> it's nothing you can grep for
<seb128> if you wait next week there is a new GNOME upstream
<seb128> I'll probably reupload almost the whole stack again
<fabbione> actually..
<fabbione> i think we can grep for it..
<seb128> oh, cool
<fabbione> no it's not cool
<seb128> if we can list the stuff to rebuild I can manage to upload with the right order
<fabbione> seb128: i am afraid it will be faster to rebuild sparc from scratch
<seb128> fabbione: grumpf .. so what do you want to do?
<seb128> fabbione: I'll reupload a good part of GNOME for new version next week as said, I can reupload the libs with the right order this week to start if you want
<fabbione> seb128: just do what you need to do... i am checking some extra stuff to see if i can actually recover it
* fabbione needs a smoke
<fabbione> seb128: ok.. sparc is gone is to hell
<fabbione> go ahead and don't worry...
<seb128> fabbione: k :/
<fabbione> seb128: well either i kill the entire port
<fabbione> or we fork 30 pkgs..
<seb128> fork for what?
<fabbione> but given that the toolchain is not good.. i had rather prefer the former
<seb128> 30 package doesn't seem to be a lot to rebuild
<fabbione> seb128: there is a workaround to that problem..
<fabbione> seb128: it's not enough to rebuild..
<fabbione> you need to build changing linking flags
<seb128> your build-chain is fixed?
<fabbione> so it's NO option
<fabbione> seb128: no idea..
<fabbione> i will have to figure it once i get gcc-4.0.1 builded
<seb128> if the build-chain is not fixed that's going to be tricky
<fabbione> seb128: i will have to investigate
* Amaranth goes to lunch
<fabbione> seb128: thanks a lot for your support
* fabbione drops a tear on seb128's shoulder
<seb128> no problem, don't worry :)
* sivang is back
<fabbione> elmo: ping+
<elmo> fabbione: ?
<fabbione> elmo: is it possible for you to kill all the sparc binary pkgs for breezy?
<elmo> sure
<fabbione> elmo: just asking.. don't do it right away please
<fabbione> ok
<fabbione> thanks
<ogra_> elmo, did highvoltage approach you yet ? wrt edubuntu.org ?
<seb128> elmo: can you sync glib2.0 (2.7.3) from exp please?
<elmo> ogra_: yeah
<ogra_> great:)
<fabbione> elmo: btw.. did you notice that morgue.u.c is stalled at 3 months ago or so?
<highvoltage> hi elmo.
<elmo> seb128: it's not in experimental yet?
<elmo> fabbione: oh, no
<elmo> highvoltage: hi
<sivang> seb128: I'm getting an error on another breezy box of mine trying to autogen a lib, 
<highvoltage> elmo: how's that webspace for edubuntu going?
<sivang> aclocal: configure.ac: 12: macro `AM_PATH_PYTHON' not found in library
<sivang> aclocal: configure.ac: 14: macro `AM_PATH_GTK_2_0' not found in library
<elmo> highvoltage: it hasn't happened yet, I'm working on it, and will let you know as soon as it's ready
<sivang> seb128: what am I missing?
<ogra_> seb128, what do you think about having some export calls in gnome-session and a gconf set of environment vars, so we could have a gui later to set environment vars without editing files ?
<seb128> sivang: you need some -dev packages you don't have installed apparently
<sivang> seb128: thanks
<ogra_> seb128, breezy+X question indeed
<highvoltage> elmo: thanks.
<seb128> elmo: http://ftp.debian.org/debian/pool/main/g/glib2.0/glib2.0_2.7.3.orig.tar.gz has it, it should be here since yesterday run
<elmo> ok, maybe ftp.uk's being crap again, one sec
<seb128> ogra_: what issue are you trying to solve?
<ogra_> seb128, fiddling with .gnomerc and .bashrc 
<lamont> elmo/mdz: what was the policy on promoting things from universe-> main for ports architectures?
<elmo> lamont: same deal as normal, AFAIK?
<seb128> ogra_: why the heck to you want to change these files from gnome-session?
<Amaranth> no one has needed the morgue until all this X stuff so no one noticed :)
<ogra_> seb128, i dont want to change these files, but want a process to extend your PATH for example ...
<ogra_> seb128, even windows has a gui to set nv vars
<elmo> seb128: done
<ogra_> env
<lamont> elmo: ok...  binutils-hppa64 is universe, needs to be main (gcc-4.0 build-dep), and there are 3-4 palo packages that should move, too... email to mdz cc you?
<seb128> ogra_: gnome-session doesn't seem to be the right place
<seb128> elmo: thanks
<ogra_> seb128, and this issue comes up once a month in -users
<seb128> ogra_: users are lame
<ogra_> seb128, other suggestions where to introduce such a feature ?
<seb128> ogra_: they know what PATH is but not how to edit a file?
<Amaranth> PATH has been around since the DOS days for them though
<seb128> and why do you need to set PATH?
* fabbione &
<ogra_> seb128, the prob is tha PATH is handled in different files... until a user discovers .gnmerc might do it, he already fucked up his /etc/environment /etc/profile ~/.bashrc ~/.bash_profile
<elmo> lamont: binutils-hppa64 should be easy, it's part of an existing main package, the others are relatively small and harmless too.  so, mail might work, but i believe there's some hoops to jump through these days
<seb128> ogra_: they don't have to mess with PATH
<ogra_> seb128, its not PATH but any environment vars...
<sivang> ogra_: what kind of env vars do you think they would want to modify?
<ogra_> seb128, we have no easy way to do that
<lamont> elmo: there should be hoops, given UVF and all
<seb128> ogra_: and next you want a UI to set LDFLAGS and CFLAGS for people programming but to lame for that?
* lamont sends email
<ogra_> dunno... some want ~/scripts in their path etc
<seb128> ogra_: start by listing good reason to edit variables
<ogra_> seb128, user demand ?
<seb128> ogra_: good reason I said, users ask all sort of craps
<sivang> ogra_: you're thinking of something like the set environment variables in Win ?
<ogra_> seb128, yes, but its discussed quite often in -users... i'll collect some reasons over time
<ogra_> sivang, yes
<seb128> ogra_: k, do a spec
<seb128> ie: a rationnal
<ogra_> seb128, its not urgent, i just wanted a second opinion
<seb128> then we will fix the it
<ogra_> oki
<seb128> there is no good rationnal for that imho
<seb128> we already change gdm.conf to set a correct PATH for users
<seb128> that should "just work"
<ogra_> seb128, beside "others do it" ?
<seb128> if they have specific reason I'm sure we will find how to fix that, but figure the reasons to start
<ogra_> seb128, i'd see it as part of commandline disintegration
<seb128> nobody should have to set a PATH even from an UI
<seb128> or PYTHONPATH or whatever
<ogra_> i.e. you install java from the sun package... you have to set some vars
<seb128> usually if you start changing that, that's because you use the command line and you should be able to edit a file
<seb128> no
<sivang> seb128: you have any idea where lies AM_PATH_PYTHON macro? My autogen is complaining about it..
<seb128> read the wiki on how to install java packages
<seb128> sivang: python-dev (random guess)
<ogra_> seb128, if you take the original sun package you have to... 
<sivang> seb128: tried that :-(
<seb128> ogra_: the point it to use packages
<ogra_> seb128, i know
<seb128> you workaround an issue (installing the jvm) which something totally orthogonal
<seb128> sivang: automake1.7: /usr/share/aclocal-1.7/python.m4
<seb128> by example
<seb128> use a correct automake version :p
<sivang> seb128: how do I know what the correct version is? :-)
<sivang> seb128: or better, how do I know to find the right version when getting such an error?
* sivang finally watches the lp integration library autogens on the other dev box
<seb128> sivang: I've already package launchpad-integration yesterday, don't bother with that
<seb128> I'll upload tonight
<seb128> sivang: and update-alternatives --config automake to set the default automake
<sivang> seb128: ah no, I had a problem with refreshing my gedit package - I knew you were already packaging the lib, I just built from jamesh's baz to test 
<sivang> seb128: acutally, I had to install 1.7, wasn't my default (it was 1.4)
<seb128> sivang: k
<pabs3> hi all, while doing some qa work for debian's xchat package, I looked at the ubuntu patches that scott provides. it seems ubuntu has included an xhosa translation for xsane in the ubuntu xchat package. is this intentional? was their an xchat xhosa translation, does anyone know where it might have went?
<Kamion> Canonical paid some contractors to do Xhosa translation; it may have been part of that. Don't know whether it was submitted upstream.
<mdke> i think the xhosa stuff is in rosetta, you should be able to find it there
<pabs3> but, including a translation for a completely different package in xchat is probly the wrong thing to do, no?
* pabs3 checks rosetta
<Kamion> oh, I see what you mean
<Kamion> sounds like a mistake, yes
<pabs3> nope, no xhosa translation in rosetta
<mdke> no, confirmed
<pabs3> hmm, rosetta is nice tho
<pabs3> anyway, cyas
<JanC> <Amaranth> oh, python only knows ascii and unicode
<sivang> seb128: darn, I did as you said about the configure stuff, and still I got alot of diff for the configure script
<Amaranth> ?
<lamont> export DH_COMPAT=1
<JanC> the default encoding in python is ascii for normal strings
* lamont giggles
<Amaranth> JanC: yes
<JanC> and unicode for unicode strings
<seb128> sivang: what is the size of the diff?
<mdke> carlos, here?
<Amaranth> JanC: yes
<JanC> filenames are normal strings if they are not unicode
<carlos> mdke, yes
<Amaranth> JanC: yes
<sivang> seb128: 42k
<seb128> sivang: that's quite small
<JanC> so you need to use encoding/decoding
<seb128> autostuff patch usually do ~200k
<Amaranth> JanC: There are things that are not unicode that python can't handle.
<seb128> sivang: gzip it, what size?
<JanC> it can, after encoding/decoding  :)
<Amaranth> only if you make it drop things it doesn't understand
<JanC> I think there was a discussion about this on python-dev recently
<mdke> carlos, is there a page where I can view all the languages and status on (.e.g) the quickguide? Since rosetta was organised by language rather than by package I can't find it...
<Amaranth> or somehow know the encoding
<JanC> you should know the encoding ?
<sivang> seb128: 4k
<seb128> sivang: that's nothing for a package
<Amaranth> nope
<Amaranth> in ubuntu it's utf-8 which will work fine
<Amaranth> except for broken packages and such that make things non-utf-8
<mdke> carlos, this page gives me a system error https://launchpad.ubuntu.com/distros/ubuntu/hoary/+sources/ubuntu-docs/+pots/quickguide
<Amaranth> if it's not utf-8 i don't have a clue what it is
<sivang> seb128: ok, so I'll check if the already posted package (that I Sent you the link to) is ok, if so, that's still the package to use
<carlos> mdke, yes, there is
<carlos> mdke, but as you say, it gives a system error.
<carlos> that's a bug, it should work
<mdke> carlos, ah ok, is it filed? shall i do so?
<JanC> Amaranth: I think most of the time anything 8-bit should work fine if you use the same codec for encoding & decoding  ;-)
<Amaranth> i'm getting a unicode error when using utf-8
<carlos> mdke, please, file it
<mdke> carlos, ok i've filed it at #1511. I've also noted the difficulty in finding the page at #1510, although maybe that won't be accepted ;)
<carlos> mdke, well, you have a link to it from the sourcepackage page
<carlos> mdke, you want to see the translations for a concrete package
<carlos> so you look for the package and then select "see the translations"
<carlos> mdke, we just removed the duplicate list of sourcepackages
<carlos> one for translations and the normal one from the normal "soyuz" functionality
<carlos> mdke, anyway, if you still think it's not as user friendly as you think it should be, is ok to bug us about that so we can try to think a way to improve that
<mdke> i went to ubuntu-docs but didn't see any links to it, but I'll have another go, and close the bug if necessary
<mdke> carlos, ^
<carlos> mdke, look at the column on the left
<carlos> "translation sets" box
<mdke> carlos, from which page?
<carlos> mdke, the one you told me: https://launchpad.ubuntu.com/distros/ubuntu/hoary/+sources/ubuntu-docs
<sivang> seb128: ok, last post from me to you about the gedit package still holds
<sivang> seb128: so test it, and upload if you like
<mdke> carlos, ok i see it! How do I find the +sources/ubuntu-docs page?
<mdke> carlos, i tried some searches on https://launchpad.ubuntu.com/distros/ubuntu/hoary/+sources but couldn't find anything
<carlos> then that's a bug on soyuz ;-)
<mdke> ok i'll file that too
<carlos> right, no source package found..
<mdke> perhaps that is the cause of the system error :)
<dieman> there we go
<dieman> now ive got a hoary x server with i845G support
<pitti> Hi
<dieman> 945G rather
<pitti> ogra_: did you recently happen to install an amd64 daily?
<ogra_> pitti, nope
<pitti> I tried this afternoon, and apt-cdrom seems to be broken
<ogra_> pitti, but X is been very outdated here... and there were other issues reported to -users
<pitti> ogra_: no, I don't even come that far
<Mez> do the xorg changes affect xf86? 
<ogra_> apt-cdrom is new to me
<pitti> ogra_: stage 2 fails since it claims that my Ubuntu CD is not an Ubuntu CD
<ogra_> oh 
<ogra_> how old is this build ?
<pitti> ogra_: today
<pitti> ogra_: did you try colony 2? does it work?
<ogra_> pitti, nope, i didnt try, but there were many reports that it doesnt...
<pitti> so I bought an amd64 and can't install it *sniff*
<ogra_> pitti, currently i'm waiting for the next colony for my first edubuntu CD tests
<ogra_> pitti, hoary....
<ogra_> and upgrade then...
<pitti> ogra_: no, I just continue to use my i386 partition for now
<ogra_> if you install anyway it doesnt matter if hoary or breezy... and apt-cdrom work on hoary to upgrade from it :)
<pitti> ogra_: I don't install, I still have the hds of my old computer
<ogra_> ah
<pitti> ogra_: well, ubuntu-desktop is not installable anyway due to X breakage
<pitti> so I'll just wait
<pitti> and sorry for being OT
<ogra_> heh, yes, next time ask in #ubuntu please :)
<OddAbe19> how stable IS X anyway?
<OddAbe19> for a dist-upgrade from hoary
<ogra_> OddAbe19, dont do it
<ogra_> wait a week
<wasabi_> I would suggest you don't do it, as well.
<OddAbe19> lol, that's what i was wondering
<OddAbe19> what broke it? the GCC transition?
<ogra_> OddAbe19, the X transition :)
<ogra_> x gets modularized and the X11R6 paths dissapear completely
<OddAbe19> oh wow
<OddAbe19> that's quite a change
<OddAbe19> i had no idea
<ogra_> it happens upstream too...
<OddAbe19> heh
<doko> daniels: is xutils just broken, or does it get restructered? no, I don't mind an empty package, really.
<ogra_> doko, saves bandwith :)
<Lathiat> haha
<wasabi_> Hmm. Nautilus crashes nicely while trying to access https
<highvoltage> i like it more when it crashes spectacularly, that way there's a bigger chance that it will be fixed soon.
<ogra_> wasabi_, https ? with nautilus ?
<wasabi_> Yes.
<wasabi_> Supposed to be webdav.
<ogra_> ah...
<wasabi_> and somebody should compile cadaver with ssl support
<Keybuk> is gossip broken?
<Keybuk> no, is me
<thom> Keybuk: you're a gossip? we knew that already ;-)
<Keybuk> lol
<jammcq_ottawa> hey all, anybody know when/where the next Ubuntu developer meeting is going to be?
<ogra_> jammcq_ottawa, no final word about that yet
<ogra_> rumors about south america, canada and germany have been heard 
<jammcq_ottawa> ogra_: thanks.  we're trying to plan our LTSP dev meeting, and we've picked Nov 3-6
<ogra_> where will it be ?
<jammcq_ottawa> Southwest Harbor, Maine
<jammcq_ottawa> wanna come ?
<jammcq_ottawa> anybody is welcome
<jammcq_ottawa> this will be our 3rd annual event, and this year, I'm going to try and run it the way UDU was run. I was pretty impressed with that
<ogra_> dunno nif i have the time... i would be interested as the edubuntu guy here, but we just ha release then and i guess i might have to do some promotional stuff...
<jammcq_ottawa> sure
<jammcq_ottawa> i'm just trying to keep it clear of the Ubuntu mtg
<highvoltage> jammcq_ottawa: do you have some details up somewhere?
<jammcq_ottawa> and I vote for Canada, if anybody cares :)
<ogra_> jammcq_ottawa, make sure mdz nows about it, i guess he might be very interested
<ogra_> jammcq_ottawa, canada in oct/nov ? 
<ogra_> *shiver*
<jammcq_ottawa> highvoltage: http://wiki.ltsp.org/twiki/bin/view/Ltsp/WebSearch?search=BTS&scope=text
<jammcq_ottawa> heh
<jammcq_ottawa> highvoltage: sorry,
<jammcq_ottawa> lemme get the right link
<maswan> northern sweden in february? :)
<ogra_> lol
<jammcq_ottawa> http://wiki.ltsp.org/twiki/bin/view/Ltsp/LtspBTS2005
<ogra_> *freeze*
<jammcq_ottawa> Sydney in April ?  nice :)
<dnakata> i'm afraid if it's in the usa, a lot of people won't show, who would otherwise love to attend
<ogra_> yeah
<dnakata> canada would certainly be a slightly more politically accessible country
<jammcq_ottawa> I agree
<jammcq_ottawa> and i'm from the US :)
<dnakata> australia would work too, unfortunately it's rather expensive to travel to from any major continent
<dnakata> (as far as i know, at least)
<bddebian> WTF.  We need to have SOMETHING in the US
<ogra_> dnakata, our last one was in sydney
<dnakata> cool
<thom> bddebian: fix your government
<thom> bddebian: then people might want to risk it
<ogra_> bddebian, as thim said :)
<dnakata> hehe
<ogra_> thom even
<bddebian> Nothing wrong with it any more than many other countries
<jammcq_ottawa> heh, we tried, last november
<dnakata> i should put a vote in for great britain
<thom> bddebian: dude, the possibility of dmca arrests on entry is a pretty big turn off
* jammcq_ottawa thinks Canada would be a fine place
<maswan> bddebian: it is on the list of rather few countries that have put someone in jail for giving a presentation at a conference
<highvoltage> really?
<thom> jammcq_ottawa: nod, definitely
<dnakata> well, canada's a bit large.
* ogra_ would prefer south america
<dnakata> by 'canada', are you implicitly saying toronto?
<jammcq_ottawa> brazil would be FINE with me
<dnakata> vancouver, calgary, edmonton?
<dnakata> montreal, there's a good spot
<highvoltage> lots of stuff are happening in brazil. it sounds like a free-software friendly place.
<ogra_> dnakata, the woods !
<jammcq_ottawa> dnakata: I think vancouver would be nice.  i'm tired of Toronto
<dnakata> ogra_: yellowknifo!
<ogra_> dnakata, we are supposed to work there ;)
<dnakata> hehe, yeah vancouver
<dnakata> totally
<jammcq_ottawa> dnakata: montreal is also a great place, or ottawa
<bddebian> Oh you are right, I'd much rather go to a country where they'd just kill me on site
<ogra_> bddebian, they do this in canada ? o_O
<jammcq_ottawa> ok, so apparently the Time/Place hasn't been decided yet
<jammcq_ottawa> hopefully it won't be Nov 3-6
<ogra_> jammcq_ottawa, could be....
<jammcq_ottawa> but /me thinks it will be
<bddebian> ogra_: No not in Canada :-)
<ogra_> bddebian, ;)
<bddebian> ogra_: Though Jeff Bailey might shoot me if I go to Canada ;-P
<ogra_> hehe
<JanC> Amaranth, still around ?
<JanC> or maybe seb128 ?
<seb128> don't ask to ask just ask
<JanC> I think this fixes python-xdg: http://paste.ubuntulinux.nl/680
<JanC> at least, smeg works on my system after changing those 2 lines...
<Amaranth> i'm willing to bet the DesktopFileID isn't right though
<JanC> what's "right" ?
<JanC> I don't see how it can be "right" in case of a broken filename...
<Burgundavia> jdub, you know how in your 10x10 meeting you talked about MS p2p stuff? http://www.microsoft-watch.com/article2/0,2180,1835355,00.asp
<Amaranth> JanC: You get unicode errors without that?
<JanC> Amaranth : UnicodeDecodeError yes
<Amaranth> ooh, finally a guinea pig
<JanC> both with unicode filenames & with broken filenames
<JanC> and both are fixed by this 2-line change  :)
<JanC> (for me, at least)
<Amaranth> do you know what file it's breaking on and what menu entry that file represents?
<JanC> ah, not like that, I just copied gedit.desktop
<Amaranth> and mangled it's filename?
<JanC> I made 2 copies, both as "gdit"
<JanC> one utf-8 encoded
<Amaranth> which works, right?
<JanC> the other iso8859-15 encoded
<Amaranth> which doesn't, right?
<JanC> I'm not sure about utf-8
<Amaranth> get rid of it
<JanC> the test-menu.py script is broken
<Amaranth> have just the iso8859-15 one so we know which one you're working with
<Amaranth> what do you mean broken?
<JanC> everything gets converted to ascii before printing   :)
<JanC> which obviously gives an error
<Amaranth> oh
<Amaranth> well, whatever, we're using smeg :)
<JanC> I was first testing with it, that's why I'm not sure about the utf-8   :)
<Amaranth> ok, you have your mangled gedit and smeg loads with that patch, right?
<JanC> yes
<Amaranth> ok, use smeg to move that gedit to another category
<Amaranth> make sure it moved in smeg, then restart smeg and make sure it's still moved
<mdke> ooh i have X in breezy. an unexpected delight. Not gnome though
<Amaranth> JanC: done?
<pitti> mdke: your session doesn't start and just hangs at the first progress icon?
<JanC> how do I move ?
<Amaranth> drag and drop
<JanC> I can't move anything it seems ?
<Amaranth> err
<Amaranth> what version of smeg do you have? :)
<mdke> pitti, it doesn't start and I don't get any progress icons. Sadly I can't get into the console either :) ctrl alt F1 doesn't work
<JanC> I use the last smeg in breezy ?
<Amaranth> ok
<Amaranth> any errors?
<JanC> started smeg from cli & no errors
<Amaranth> you're dragging from right treeview to left treeview, right?
<JanC> moving is implemented after 0.7.5 ?
<Amaranth> no
<Amaranth> 0.6
<mdke> pitti, i can get a failsafe gnome though, with some xkb errors
<Amaranth> so you have it
<Amaranth> mdke: System->Preferences->Keyboard, reset defaults
<mdke> k
<Amaranth> as long as /etc/X11/xkb/xkbcomp is a symlink to /usr/bin/xkbcomp and you do that you shouldn't get any xkb errors
<Amaranth> JanC?
<mdke> i get 13 packages that don't upgrade on a dist-upgrade, most of which are core gnome components
<JanC> Amaranth : xdg doesn't like unicode DesktopFileIDs or what ?
<Amaranth> pyxdg likes _only_ unicode DesktopFileIDs
<JanC> they weren't unicode before...
<Amaranth> mdke: why don't they upgrade?
<Amaranth> JanC: pyxdg deals in pure unicode
<Amaranth> it converts everything to unicode objects
<mdke> dependency problems, i'm still trying to figure out what is the cause, probably xlibs tho
<JanC> I added some print repr() statements to Menu.py and they were not all unicode strings ?
<Amaranth> something is very broken then
<Amaranth> the moment pyxdg reads something from the files it should be converting to unicode
<Amaranth> anyway, this is not our problem
<JanC> they are all unicode now though
<JanC> with my patch
<Amaranth> ok, cool
<Amaranth> this is not our problem
<mdke> Amaranth, the xkb link looks fine, but its having trouble configuring xlibs due to an error "rmdir: `/etc/X11/xkb/geometry/digital_vndr': Directory not empty" that seems to be blocking the dist-upgrade, afaics
<JanC> Amaranth : it's a filename, not read from a file
<Amaranth> mdke: haha
<Amaranth> mdke: that was a PITA
<mdke> Amaranth, known?
<mdke> good
<mdke> bug is filed?
<Amaranth> mdke: rm -rf /etc/X11/xkb/*, see what the error is now (something about a dir missing iirc), create an empty dir for it
<JanC> Amaranth, look at the original code:
<JanC> self.DesktopFileID = os.path.join(prefix,filename).replace("/", "-")
<Amaranth> after xlibs is installed reinstall xkeyboard-config (dunno if you need this or not)
<Amaranth> JanC: *beats lanius*
<Amaranth> ok, this is not our problem
<Amaranth> come on, you never answered me
<mdke> Amaranth, ok i will try that workaround, but is the problem filed as a bug do you know? if not, I'll search b.u.c
<Amaranth> *shrug*
<Amaranth> daniels is busy with other things
<mdke> in that case, doubly important to file a bug
<Amaranth> JanC: what happens when you drag something from the right treeview to the left treeview?
<mdke> that way, when he is less busy, he can handle it
<Amaranth> mdke: oh, you need to recreate the xkbcomp link afterward
<JanC> Amaranth : hm, seems like it works when I drop on _some_ folders & not on others ?
<mdke> Amaranth, #12743 looks like what I have
<Amaranth> JanC: Yes, it won't work if you drop it on the 'Other' menu.
<mdke> :)
<JanC> Amaranth : yeah, that seems to be the issue  :)
<JanC> that's another bug ?
<Amaranth> no
<Amaranth> just the way the menu system works
<JanC> strange...
<Amaranth> other is for things the menu system couldn't sort into anything else
<Amaranth> anyway, your busted gedit moved?
<Amaranth> and stayed moved in smeg?
<Amaranth> if so, restart gnome-panel and see if it matches smeg
<JanC> moved & restarted & still at the same location
<JanC> now restarting gnome-panel
<Amaranth> ping me when you find out
<JanC> Amaranth : one didn't get moved
<Amaranth> which one?
<Amaranth> the one you mangled?
<JanC> I can't see...
<Amaranth> heh
<JanC> they are all listed as "Tekst-editor" in the menu  ;-)
<Amaranth> *sigh*
<Amaranth> the one you mangled didn't get moved
<Amaranth> which means your patch won't do it
<Amaranth> i'll look at how libgnome-menu handles it after i wake up
<JanC> Amaranth : where are changes saved ?
<Amaranth> ~/.config/menus/applications.menu ~/.local/share/desktop-directories/ ~/.local/share/applications/
<Lathiat> sounds like a bundle of fun
<JanC> ah, forgot about .config
<Lathiat> i am unenvious
<JanC> Amaranth : maybe files with bad filenames should just be ignored ?
<Amaranth> not if the menu doesn't ignore them
<JanC> does the menu spec have a spec for translating impossible filenames ?  :)
<Lathiat> heh
<Amaranth> no
<JanC> so this is undefined behaviour...   :-/
<JanC>  DesktopFileID is something internal from python-xdg, nothing from the menu-spec ?
<Amaranth> no, it's in the menu spec
<Amaranth> it's pretty goofy, actually
<Amaranth> <Filename> takes a DesktopFileID
<bob2> oh, wow, there're x40 tablets now
<Amaranth> which is generally just the filename but it might have a prefix on it depending on where it came from or other xml in the menu
<Amaranth> bob2: slashdot beat you to it by about 2 weeks :)
<bob2> I dont read slashdot
<bob2> they look kinda arse, tho
<Amaranth> yeah, and you probably can't drop them from a two-story window onto concrete :)
<JanC> Amaranth : then you can't fix this
<Amaranth> JanC: sure i can, i just have to use the same cheap hack libgnome-menu/glib uses
<ogra_> hmm, we have no mediawiki package ? 
* ogra_ cries
<JanC> Amaranth : they don't implement this
<JanC> the entry is available in the menu
<Amaranth> JanC: they must, you said your mangled gedit showed up
<JanC> but when you click it, it says it can't find it  :)
<Burgundavia> ok, this is cool --> http://myscreen.org
<Amaranth> haha
<Amaranth> JanC: file a bug in gnome's bugzilla against libgnome-menu
<Amaranth> let them decide what to do about it before 2.12 so i can make smeg match
<Amaranth> oh, and please CC alleykat@gmail.com
* Amaranth goes to bed
<JanC> I'll go to bed after filing the bug too, have to get up early...   :-/
<Mez> is ubuntu doing a slang2 transition?
#ubuntu-devel 2006-07-17
<dieman> holy crap, samsung released amd64 binaries for their printer
<Chipzz> nice :)
<jdub> dieman: their printer is amd64? ;-)
<wasabi_> That was too easy.
<JanC> dieman: most samsung printers work OOTB on Ubuntu?
<JanC> I guess you mean their proprietary GUI installer ?  ;-)
<floam> BenC: is there any obvious reason an initrd might fail to be created with no message upon install of the 2.6.17 kernel-image packages?
<floam> update-initramfs -c -k 2.6.17-4-k7 seems to make one (havn't checked to see if it works yet)
<infinity> floam: Because, afaict, the postinst for the -4- kernel just plain doesn't create an initramfs at all.
<jdub> infinity: massive!
<jsgotangco> hey jdub
<jdub> yo jsgotangco 
<tseng> hi jsgotangco 
<jsgotangco> hey tseng how's it going?
<tseng> fine, you?
<jsgotangco> pretty good starting the week though *groan*
<tseng> does anyone know the current method of getting a dapper-updates approved?
<tseng> mail mdz, file bug assigned to foo, ...?
<Riddell> tseng: send diff to mdz and kamion.  upload when approved
<tseng> Riddell: cheers.
<BenC> floam, infinity: Yeah, the kernel-package used to create the -4 kernel was screwed
<labuser> I have a fix for a buggy package in ubuntu, where do I send it to? (It's a one-line diff)
<Chipzz> labuser: I guess file a bug in launchpad ?
<Chipzz> you can mark your attachment as being a patch I think
<labuser> it's been on launchpad for 2 months but the package is still broken
<labuser> someone else filed it here: https://launchpad.net/distros/ubuntu/+source/mldonkey/+bug/42632
<Ubugtu> Malone bug 42632 in mldonkey "startup script is broken" [Medium,Confirmed]  
<labuser> it's not a minor thing either... attempting installation of the package breaks apt alltogether
<labuser> http://rafb.net/paste/results/sonrqK93.html
<labuser> I pasted the fix there... maybe someone can commit it
<Fujitsu> Which package? mldonkey-gui
<labuser> mldonkey-server
<Fujitsu> Ah.
<Fujitsu> OK.
<Fujitsu> Works fine for me...
<Fujitsu> How does it break it?
<Fujitsu> It doesn't actually install the mldonkey binary... But it doesn't break.
<labuser> Installation of any other package fails. I forgot the exact message
<labuser> I did an apt-get source and applied the fix, then did dpkg -i with that, and everything was ok
<JanC> sounds like a failed install script?
<labuser> yes that's right
<Fujitsu> Works fine for me, still.
<labuser> Fujitsu, the installation ?
<Fujitsu> labuser, yes... I installed both mldonkey-server and mldonkey-gui, and it still works.
<labuser> dapper right
<Fujitsu> Hmm.
<Fujitsu> Yeah.
<Fujitsu> BOOM
<labuser> I don't know then
<Fujitsu> I remove mldonkey-gui, try to remove mldonkey-server and it explodes.
<labuser> there you go :)
<labuser> I guess it really did go BOOM ... :)
<floam> BenC: oh, okay
<Hobbsee> morning all
<dieman> JanC: the ml-2010 driver isn't actually in foomatic yet
<dieman> ml-1710 supposedly works, but margins are off and you can't use the 1200x600 mode
<Hobbsee> hi Burgundavia 
<Burgundavia> hey Hobbsee
<bluefoxicy> wow that's nice, I just typed <tseng> tab and xchat-gnome printed:   tseng tseng tseng
<bluefoxicy> anyway.  tseng:  If you're still up do you know what glibc detects of corrupted heap elements?
<bluefoxicy> I'm thinking it's entirely possible to detect double free(), free() of a corrupt heap element, and free() when the next and previous elements in the chain of heap allocations are corrupt; but I'm not sure if glibc detects all of these AND differentiates between double free() and other weird corruption (which is doable simply by marking an entry in a special way when it's free()'d)
<bluefoxicy> i know it'll catch some level of dirtiness.
<fabbione> morning
<Hobbsee> hi fabbione!
<fabbione> hey Hobbsee 
<Hobbsee> fabbione: edgy isnt actually broken that badly :)
<fabbione> it's all because we are too cool :)
<Hobbsee> fabbione: of course :)
<fabbione> hmmm
<fabbione> i need more bw
<Hobbsee> fabbione: bw?
<fabbione> bandwidth
<fabbione> SCORE
<jsgotangco> how cheap/expensive is bw there in dk?
<bluefoxicy> https://wiki.ubuntu.com/AutomatedSecurityVulnerabilityDetection  This would be awesome, if https://wiki.ubuntu.com/AutomatedProblemReports ever happens.
<Hobbsee> fabbione: ahhhh...
<bluefoxicy> Actually the double free()/heap corruption/stack smash detection and reporting can be done without the kernel-level facilities
<fabbione> well who did activate the libata shit didn't prepare the transition properly
<fabbione> jsgotangco: not that expensive..
<bluefoxicy> also it may be possible to load default signal handlers and modify signal() to unload them when new handlers are installed and load ours when signal handlers are cleared.
<bluefoxicy> ours would have to be able to tell signal() to load no handler *reliably* (ours would be in glibc though so no problem) and then send the signal to self to die though.  Hrm.  Or something creepy like that.
* bluefoxicy is trying to get AWAY from kernel modification.
<Hobbsee> do we  have any current ETA for l-r-m for 2.6.15-5-686?
<Hobbsee> ah, i'ts oddly named, and it FTBFS.  fun.
<floam> Hobbsee: it already exists
<floam> it's probably sitting in line to be built
<Hobbsee> floam: i'm meaning the one that depends on linux-image-2.6.17-5-686
<Hobbsee> which is l-r-m-2.6.17-6-686, which FTBFS, it seems.
<bluefoxicy> FTBFS?
<Hobbsee> bluefoxicy: failed to build from source
<bluefoxicy> oh
<basanta> does ubuntu use different technique than debian to get flash drives automounted? 
* bluefoxicy was thinking like 'fucked too bad for ...?' or something
<jsgotangco> :P
<floam> basanta: does debian use HAL/pmount?
<bluefoxicy> .... for signoff?
<basanta> floam, yes
<floam> then they probably do the same thing
<Hobbsee> bluefoxicy: no, those have other acronyms
<basanta> yes, but ubuntu can automount flash drives that debian can't 
<bluefoxicy> Hobbsee:  yes but I assumed you wouldn't say 'fubar' if you intended somebody repair it :P
<Hobbsee> bluefoxicy: well...
<Hobbsee> bluefoxicy: stuff that's counted as fubar'd usually gets fixed, eventually, and after much swearing and cursing
<Hobbsee> whee!  where's that darned autoconf patch.
<bluefoxicy> Hobbsee:  You guys need your own reality TV, seriously.  Swearing and cursing is amusing.
<floam> basanta: there's a good chance ubuntu has patched things up a bit or has something newer, but I think they use the same general stuff
<bluefoxicy> Did you see when Keybuk spent like 15 minutes spouting 'fuck' every other word because he tried to build openoffice.org and it installed over a gigabyte of build deps?
<basanta> floam, ok
<bluefoxicy> He was after poor doko's blood :P
<Hobbsee> i heard about it, yeah
* Hobbsee doesnt usually end up swearing and cursing much, unless she's been to work latetly.
<basanta> floam, do you think ubuntu-developers would share this patch? and do you know where to ask?
<fabbione> Hobbsee: l-r-m will be sorted once 5.13 is built
<Hobbsee> fabbione: 5.13 of linux-image?  or of l-r-m?
<floam> basanta: well you can look through the packages yourself or ask in ubuntu-devel
<floam> I'm sure they would share it
<fabbione> Hobbsee: the former
<Hobbsee> floam: everything's GPL'd...it's  likely to be around here somewhere.
<floam> I assume by share he meant they'd find him for it and hand it over
<Hobbsee> fabbione: right, know off the top of your head if that's about to be built?
<floam> of course they have to allow him to use it
<lifeless> floam: we share all out patches
<fabbione> Hobbsee: https://launchpad.net/+builds
<lifeless> erm, I meant basanta: we share all the patches
<johanbr> basanta: Try looking at http://patches.ubuntu.com .
<basanta> lifeless, johanbr thank  you .
<Hobbsee> fabbione: ahh :)  that's the page i was looking for :)
<bluefoxicy> <floam> basanta: well you can look through the packages yourself or ask in ubuntu-devel  <-- uh floam?
<floam> uh bluefoxicy?
<bluefoxicy> this IS ubuntu-devel
<floam> bluefoxicy: this is #ubuntu-devel
<floam> there is also ubuntu-devel the mailing list
<bluefoxicy> you said in, not on ubuntu-devel@
<floam> whatever
* bluefoxicy was confused
<floam> clearly we are here so there is only one other, I thought it made sense
<floam> I will be sure not to mistake my prepositions in the future though
<Hobbsee> floam: to be fair, #ubuntu-devel is usually the irc channel, and ubuntu-devel is the mailing list.
<Hobbsee> bluefoxicy: ^
* Starting logfile irclogs/ubuntu-devel.log
<pitti> Good morning
<Hobbsee> hi pitti!
* Starting logfile irclogs/ubuntu-devel.log
<Hobbsee> Mithrandir: i think britney is confused - that's not the version of amarok in the repositories.  oh.  lovely.  hardcoded dependancy on amarok in amarok-arts, therefore the bugger wont install anyway.
<bluefoxicy> pitti:  not so hot on that idea?
<Mithrandir> Hobbsee: oh well, it's just a first milestone, it's not that important if it's not perfect. :-)
<Hobbsee> Mithrandir: hehe that is true.  i'm just merely annoyed that it's taken me this long to notice, and that a few packages which i was told/thought were uploaded werent.  
<Mithrandir> Hobbsee: become a core dev and you can fix it yourself. :-)
<pitti> bluefoxicy: when I played with my preloaded-library approach (which is essentially the same thing) I had some problems with it as well, like gdb not being able to cleanly attach and so on; but that might be unrelated to the crashed process' state
<Hobbsee> Mithrandir: heh.  yeah.  reckon you can give me dev and core dev in the same meeting?  :P
<Hobbsee> s/you/the TB
<pitti> bluefoxicy: anyway, we can consider modifying glibc later, since it is totally independent from the actual spawned agent which collects data
<Mithrandir> Hobbsee: I don't think that's being done, no..  But you're active and seems clueful enough that making core-dev shouldn't take long anyway.
<Hobbsee> Mithrandir: hehe.  actually, it was funny.  i was told when i originally started packaging, by two separate people, that they could see me going for core dev soon.
* Hobbsee has time at the moment.  it's good.
<bluefoxicy> pitti:  nod.  At any rate the program will sleep if you SIGSTOP it.
<bluefoxicy> pitti:  i am still looking at this thing for automatically prioritizing things that look like new security vulns, by the way.
<bluefoxicy> pitti:  do you think you'll have something ready by Edgy?
<pitti> bluefoxicy: (btw, you can't ptrace() a stopped process)
<bluefoxicy> pitti:  (shit)
* Hobbsee adds stacks of stuff to our  meeting tonight :)
<pitti> bluefoxicy: yes, that's the goal
<pitti> bluefoxicy: (having something for edgy)
<bluefoxicy> pitti:  gdb seems to be able to attach to less after I ctrl-z less
<pitti> bluefoxicy: not here, it just hangs indefinitely at 'Attaching to program:'
<pitti> bluefoxicy: and after fg'ing the target process, gdb suffers a horrible death
<bluefoxicy> ah right, it is hanging.
<bluefoxicy> I see :o
<pitti> bluefoxicy: it makes sense, since waitpid() on a  stopped process will never return
<bluefoxicy> it looks like you can attach with ptrace(), just gdb doesn't understand why you would try.
<bluefoxicy>  /build/buildd/gdb-6.4.90.dfsg/gdb/linux-nat.c:1025: internal-error: linux_nat_attach: Assertion `pid == GET_PID (inferior_ptid) && WIFSTOPPED (status) && WSTOPSIG (status) == SIGSTOP' failed.
<bluefoxicy> ^^^ this is gdb bitching that the target process didn't return the status it was expecting
<bluefoxicy> or that it just couldn't attach I guess.
<bluefoxicy> it's one of the two, maybe you're right.
<bluefoxicy> pitti:  want me to ping the gdb devs tomorrow on that?
<pitti> bluefoxicy: if you feel like it, but I'm not sure whether it's merely a gdb restriction or a principal restriction of ptrace()
<bluefoxicy> well, I'll find out.
<pitti> thanks
* bluefoxicy asks the kernel devs about ptrace()
<bluefoxicy> night.
<Hobbsee> night bluefoxicy 
* Hobbsee frowns.  she's just more than doubled the meeting length.
<bluefoxicy> pitti: https://wiki.ubuntu.com/AutomatedSecurityVulnerabilityDetection by the way.
<bluefoxicy> (this would be the only reason I'm as interested as I am in this :)
<pitti> bluefoxicy: thanks, will look at it
<Mithrandir> ogra: you're aware that e-d is installable now?  Do you want me to spin you CDs?
<ogra> Mithrandir, oh, yes please :)
<Mithrandir> ogra: edubuntu livefs-es building.  Do you need new alternate CDs too?
<fabbione> mdz: i am ready to upload the new redhat-cluster-suite. am I still go or do you want me to send email for UVF exception?
<mdz> fabbione: what's in it?
<ogra> Mithrandir, if you like :)
<Mithrandir> ogra: alternate cds building.
<fabbione> mdz: it's the natural upgrade from dapper (gfs1) to edgy (gfs1 and gfs2) userland. gfs2 is already in the kernel
<ogra> Mithrandir, thanks ! 
<fabbione> mdz: i only didn't manage to upload it before becuase of the big changes in the infrastructure
<fabbione> mdz: (as i reported to the last meeting)
<mdz> fabbione: backward-compatible?
<fabbione> mdz: gfs2 no, the userland with gfs1 is modulo one line change in the config
<fabbione> mdz: there is a proper debconf message for that
<fabbione> mdz: that points to the wiki where we will build proper upgrade paths and stuff
<mdz> fabbione: I mean is the package backward-compatible, not the filesystem
<mdz> i.e., does it still support gfs1?
<fabbione> mdz: yes it does
<fabbione> it does support both
<Kamion> argh, how do I get rid of the "Slow Keys Alert" without being able to click on it?
<fabbione> but i need to merge the new gfs1 in the kernel.
<mdz> ok, go ahead
<Kamion> my mouse is already grabbed by vmware
<fabbione> the new one uses shared lock manager with gfs2 to avoid code duplication
<fabbione> mdz: perfect thanks
<Kamion> and ctrl-alt does not work while the slow keys alert is up, apparently
<mdz> Kamion: kill $random_gnome_component?
<Kamion> yeah, which one though ...
<Kamion> ah, gnome-settings-daemon maybe
<Kamion> no, the bastard just comes back and leaves my keyboard screwed
* Kamion will have to kill vmware :(
<Riddell> Mithrandir: kubuntu-desktop is broken because of koffice which is waiting on ruby1.8 compiling on powerpc
<Riddell> doko: any idea what the gcc bug is that's cauing ruby1.8 to fail on powerpc?
<bluefoxicy> mdz:  I'd wanted to bring your attention to https://wiki.ubuntu.com/CommunityEdgyIdeas/Install-CD earlier due to the /home directory thing.
<infinity> Riddell: Are you sure it's a GCC bud and not a ruby bug?
<bluefoxicy> I think.  I know there was something I wanted to bring your attention to specifically.
<bluefoxicy> anyway I'm sleeping, it's 5am
<Riddell> infinity: look at the build log, seems to be a gcc segfault
<infinity> I don't see a GCC segfault.
<dholbach> hey infinity! how are you?
<infinity> /build/buildd/ruby1.8-1.8.4/build-tree/ruby-1.8.4/lib/mkmf.rb:804: [BUG]  Segmentation fault
<infinity> ^^^ That's ruby segfaulting.
<Riddell> hmm, right
<infinity> Of course, it could be GCC miscompiling it still, but I'd like to blame ruby until I know for sure.
<ogra> does anyone have experience with fakechroot ? i dont seem to be able to set up an environment ...
<Mithrandir> ogra: your dailies are served.
<ogra> thanks !
* ogra downloads
<mdz> bluefoxicy: I reviewed those pages a couple of weeks ago and commented on things where I had an opinion
<bluefoxicy> mdz:  nod, I did it a couple hours ago.
<bluefoxicy> mdz:  short version:  some people I know actually have 500-750 gig hard drives and fill them with questionable content (for example, downloads of anime series they don't own...); that's like 100 DVDs or so.  It'd be nice to be able to nuke everything but /home at install if you're honestly going to make /root a big 500 gig partition just because the disk is 500 gigs wide.
<bluefoxicy> er. /, not /root
<bluefoxicy> sleep time for me.
<Kamion> use manual partitioning then. there's no way for autopartitioning to keep everybody happy here.
<Kamion> there's a reason we provide manual partitioning in non-expert mode
<mdz> right, I think that's a fairly uncommon use case
<Kamion> not so much uncommon use case as that there are N different common use cases. at least with the present situation it's easy to see that we chose it because it was the simplest alternative.
<Kamion> Mithrandir: live CD's buggered - "User not known to the underlying authentication module" all over the place
<Mithrandir> Kamion: gnr
<Kamion> huh, it worked a second time, without quiet splash - except now my gdm login screen is ENORMOUS
<Kamion> like 2048x1536 or something
<Mithrandir> maybe it's a bad CD, then.
<Kamion> it's vmware
<Kamion> and autologin fails
<Mithrandir> uh, ok
<Mithrandir> I'll burn a dvd and see what happens on real hardware.
<Mithrandir> this is i386, then?
<Kamion> yes
<Kamion> Mithrandir: since I'm here, anything I can do to debug it? I've forgotten how to debug casper
<Mithrandir> Kamion: boot with break=bottom and poke /root to see if the ubuntu user is there.
<Kamion> 'k
<doko> Riddell: already checked, it's not a gcc bug, rechecked rebuilding with gcc-3.4 and gcc-3.4
<infinity> s/3.4$/4.0/ ?
<Kamion> bash: line 2: pwck: command not found
<Mithrandir> Kamion: uh.
<Kamion> it's in /usr/sbin; I suspect $PATH
<Mithrandir> I thought casper set path, but maybe not?
<Kamion> oh, never mind, I'm running this manually
<Mithrandir> we should just make sbin a symlink to bin and get rid of that sillyness. :-P
<Kamion> what's the break= to let me edit casper-bottom scripts before they run?
<Mithrandir> break=casper-bottom
<Kamion> ta
<Mithrandir> (surprise!) :-)
<Mithrandir> it would also have been nice if udev hadn't suddenly removed udevplug without telling me.
<Kamion> ah yes, try udevtrigger && udevsettle
<Kamion> I thought Scott was going to leave a wrapper :(
<Mithrandir> apparently not.
<Kamion> Mithrandir: you need to do 'set passwd/make-user false' too.
<Kamion> er, true, not false
<Kamion> dunno why that didn't break dapper
<Mithrandir> why doesn't it default to true?
<Kamion> er. it does. I haven't had breakfast yet.
<Mithrandir> may I suggest eating breakfast and coffee, then? ;-)
<Kamion> yeah
<Mithrandir> Kamion: ok, it seems like casper doesn't set the path correctly, somewhere.  I'll just export it at the top of the casper script and let it be with that, I think.
<Kamion> oh, you saw the same thing then?
<Kamion> ./scripts/casper:301:    PATH=/root/usr/bin:/root/usr/sbin:/root/bin:/root/sbin:$PATH run_scripts /scripts/casper-bottom
<Mithrandir> yeah
* Kamion would have thought that would be enough ...
<Mithrandir> well, it works if I pass PATH=/usr/sbin:/usr/bin:/bin:/sbin on the kernel command line
<Kamion> that creates the user for me too, yes
<Kamion> I have no xorg.conf now
<Kamion> I think I didn't on one of my previous boots too, so it's not due to PATH
<Mithrandir> me neither, but I wonder if that's just X being b0rken.
<Mithrandir> export PATH=/root/usr/bin:/root/usr/sbin:/root/bin:/root/sbin:/usr/bin:/usr/sbin:/bin:/bin
<Mithrandir> should be sane?
<Kamion> oh, I understand the problem now
<Kamion> /root/usr/sbin is not useful once you've chrooted
<maswan> Mithrandir: shouldn't you have a /sbin in there btw?
<Mithrandir> maswan: thanks, fixed.  The last one should have been /sbin
<Kamion> just do PATH=/root/usr/bin:/root/usr/sbin:/root/bin:/root/sbin:/usr/bin:/usr/sbin:/bin:/sbin:$PATH run_scripts /scripts/casper-bottom
<Mithrandir> Kamion: well, no, but if you do break=bottom and echo $PATH it includes sbin
<Mithrandir> iirc
* Mithrandir reboots to check again
<Kamion> dpkg-reconfigure xserver-xorg -> still no xorg.conf
<Mithrandir> iz X bug, then
<Mithrandir> oh, thepthul.  break=top gives me PATH=/usr/local/bin:/usr/bin:/sbin:/bin
<Kamion> score
<Kamion> initramfs-tools bug?
<Mithrandir> it seems it's the PATH coming from the kernel
<infinity> yeah, initramfs-tools doesn't define a PATH.
<infinity> Probably should.
<infinity> Though the kernel shouldn't be broken in this regard either.
* Kamion will fix xorg, one way or another
<Mithrandir> Kamion: if you fix xorg, I'll do casper.
<Kamion> you're on
<Kamion> xorg fixed
<Kamion> what's up with the lack of wallpaper in a default edgy install?
<infinity> Kamion: I'm running the publisher by hand right now to speed up the ABI switch.  Poke me when that xorg is uploaded, so I can publish again.
<infinity> Mithrandir: Ditto, for casper.
<Kamion> infinity: it's already uploadd
<Kamion> +e
<Kamion> if you mean source
<Mithrandir> infinity: cheers.
<simira> Mithrandir: that was quick
<infinity> Kamion: Kay, you win.
<infinity> Mithrandir: And you?
<Mithrandir> infinity: just a sec, I want to test this locally first.
<infinity> 5 minutes of testing, or 30?
<Mithrandir> closer to 30 than 5
<Mithrandir> so just push Colin's stuff through first.
<infinity> Okay, I'll publish while I wait, then.
<simira> do I feel a Knot approaching?
<ogra> smells like it
<ogra> :)
<fabbione> Mithrandir: mind if i upload openais? it's -server/cluster stuff
<Mithrandir> fabbione: please do.
<fabbione> Mithrandir: thanks
<Kamion> simira: ubiquity doesn't work yet, so it'll take a while ...
<pitti> mdz: what do you think about updating mutt from a cvs snapshot to the stable 1.5.12 version? mainly bug fixes, translation updates, and code cleanup, and two small new features; I can send you the full changelog if you want
<mdz> pitti: edgy or dapper?
<pitti> mdz: edgy
<pitti> hi slomo 
<slomo> hi pitti 
<doko> Mithrandir, Kamion: please could you sync dmake (needed to build OOo, doesn't touch the CD's)
<pitti> wb mdz
<pitti> mdz: in case you sent an answer after '<pitti> mdz: edgy', I didn't get it
<Mithrandir> doko: I can't do syncs.
<doko> Mithrandir: yeah, but you're current the lock holder ;)
<Mithrandir> doko: if it doesn't touch the CDs, I have no objection.
<Kamion> ok, I'll start a sync run
<Kamion> doko: please assign sync requests for single packages to the relevant package - it makes things slightly easier to find
<infinity> Mithrandir: ETA on the casper upload?
<Mithrandir> infinity: sorry, had to bootstrap a bit here, if stuff works, in ten minutes.
<infinity> Okay, I'll wait.
<infinity> (Well, I'll build xorg and massage it through while I'm waiting)
<mdz> pitti: <mdz> pitti: sure, yes
<doko> Kamion: 53158
<Kamion> yes I've found it now, just for the future
<Kamion> main reason is that if it's assigned to the right package then launchpad tells us right on the bug page what component it's in
<ogra> i'm trying to bootstrap a fakechrrot here, seems it fails on initscripts installation because its not able to bind mount / to /.root anybody having a hint what i could look for to find ot why mount says "no such file or directory" ? (/.root exists) 
<ogra> *fakechroot
* Mithrandir points ogra to the first part of the topic.
<ogra> meh 
<ogra> Mithrandir, its developemtn related, i need the fakechroots on the DC machines :P
<Kamion> fakechroot's probably just broken. I don't think it's ever had any love in Ubuntu.
<ogra> nope, it hadnt
<Kamion> and it does some invasive things which are likely to break
<ogra> its also in universe ... and we dont have a debootstrap variant (i'm just creating one)
<Lathiat> hey wow thats kinda cool
<ogra> Kamion, elmo wants me to use it ...
<Kamion> fix it, then :)
<Kamion> er ... debootstrap variant?
<ogra> funnily not even the sarge.fakechroot variant bottstraps cleanly... seems it had not more love in debian 
<Kamion> please run that by me before uploading, some of the proposed debootstrap hacks are really nasty
<Kamion> that's probably because aj thinks it's horrible crack too
<ogra> Kamion, i didnt plan to add it to the package (unless you want fakechroot in main)
<Kamion> hell no
<ogra> :)
<Kamion> if the debootstrap script is in the fakechroot package I guess that's ok
<ogra> but a review would be appreciated :)
<ogra> (i simply took the edgy script and changed device, ldd functions and proc mounting to the fakechroot functions debootstrap provides)
<ogra> *device creation
<Mithrandir> ok, casper seems to work now.
<Mithrandir> infinity: ok, uploaded, so do your thing.
<infinity>    72793 | S- | casper               | 1.61                 | 5 seconds
<infinity> Heh.  Wasn't there when I looked 10 seconds ago.
<Mithrandir> :-)
<Mithrandir> thanks
<Kamion> hmm. ubiquity works (ish), gparted --installer doesn't.
<Kamion> I guess that wasn't really a surprise
<mdz> fabbione: how is sparc looking for a milestone?
<mdz> Kamion: the i386 desktop CD i built on Saturday booted but failed to start X
<mdz> had to leave for the airport at that point
<mdz> did someone look into powerpc?
<Kamion> mdz: that's sorted nonw
<Kamion> now
<Kamion> xserver-xorg.postinst was broken
<mdz> Kamion: was there anything besides gnome-applets hurting powerpc?
<Kamion> apparently not
<mdz> yay
<Kamion> not dependency-wise anyway
<Kamion> doko: bug 50311 is another reason why you should assign to the proper package; then launchpad will do typo validation for you
<Ubugtu> Malone bug 50311 in wajig "wajig grabs information from debian.org instead of ubuntu.com" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/50311
<Kamion> doko: er, bug 53011
<Ubugtu> Malone bug 53011 in Ubuntu "sync request" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/53011
<Kamion> speaking of typos :)
<Kamion> build-bot doesn't exist
<doko> Kamion: buildbot, yes, I will do so for the future
<ogra> hmm, intresting ... a DD who recompiles his packages for hoary and breezy http://people.debian.org/~dexter/dists/fakechroot/
<Kamion> thanks
<thom> nrrrgh dexter
<basanta> G0SUB, bg in disguise??
<infinity> We should totally hire dexter and convert the entire archive to yada.
<ogra> heh
<thom> infinity: is that before or after we shift to using rpms?
<ogra> i thought we'd stay with deb but use alien ?
<ogra> ;)
<ogra> Setting up initscripts (2.86.ds1-14.1ubuntu1) ...
<ogra> mkdir: cannot create directory `/.root': File exists
* ogra kicks initscripts
<ogra> ah, thats the second attempt ...
<ogra> Setting up initscripts (2.86.ds1-14.1ubuntu1) ...
<ogra> mount: No such file or directory
<ogra> grmbl
<fabbione> mdz: no specific sparc work has been done. So whatever is in the other arches is on sparc
<Mithrandir> Kamion: what's the state of ubiquity, etc wrt knot-1?
<G0SUB> Kamion: bug 53238
<Ubugtu> Malone bug 53238 in ubiquity "Ubiquity doesn't complain about bootable XFS partitions" [Untriaged,Confirmed]  http://launchpad.net/bugs/53238
<pitti> Hi G0SUB 
<G0SUB> pitti: hello :) I came back today
<Kamion> G0SUB: duplicate of about a million other bugs; see DapperReleaseNotes/UbiquityKnownIssues
<Kamion> Mithrandir: need to sort out gparted
<G0SUB> Kamion: ok, thanks for the pointer
<Kamion> 12:40 < Kamion> hmm. ubiquity works (ish), gparted --installer doesn't.
<Kamion> 12:41 < Kamion> I guess that wasn't really a surprise
<Kamion> G0SUB: it'll be fixed in my first edgy upload, too
<Kamion> well, worked around anyway
<pitti> G0SUB: can we meet today?
<G0SUB> pitti: tomorrow at 14:00 UTC?
<pitti> G0SUB: ok
<G0SUB> fine
<Kamion> mdz: have you done the validation for the ubuntu-archive e-mail change?
<Kamion> Hmm. Now gparted at least plugs in correctly but you can't do anything in it.
<Fujitsu> Kamion, can I ask you a quick question about the carpaltunnel sync?
<zul> heylo
<snorre> Take a look at this: http://pastebin.ca/90171
<Hobbsee> Fujitsu: what's the question?
<Kamion> Fujitsu: sure
<Fujitsu> Would it be acceptable to just rebrand carpaltunnel 0.0.9-0.1 as 0.0.9ubuntu2, without putting in the rest of the changelog entries, etc?
<Fujitsu> Because merging is silly if it increases the delta more than necessary because a sync isn't possible.
<Kamion> Fujitsu: yes
<Fujitsu> OK, thanks.
<Kamion> just note it in the changelog so that we know to sync it if 0.0.9.1 or 0.0.10 or whatever shows up
<Fujitsu> OK, shall do.
<snorre> Can someone that's into kernel compiling please look at this issue: http://pastebin.ca/90171
<Hobbsee> Mithrandir: did you ever find out what the problem with ppc kubuntu-desktop was?
<Hobbsee> hi Keybuk 
<Mithrandir> Hobbsee: Riddell told me it was koffice.
<Hobbsee> Mithrandir: right.  how bizarre
* Hobbsee checks if koffice is on her system
<Hobbsee> it's not.
<Keybuk> Hobbsee: heyhey
<Hobbsee> Keybuk: i've been breaking things :D
<Hobbsee> well, not really...
<Keybuk> so have I :)
<Hobbsee> Keybuk: hehe..  what'd you break?
<Kamion> TTOTD: dpkg-genchanges > foo.deb is not very useful
<Kamion> (meant foo.changes obviously)
<Hobbsee> Kamion: TTOTD?
<Kamion> top tip of the day
<Riddell> Hobbsee: ruby on powerpc isn't compiling, which is blocking koffice
<Hobbsee> Riddell: ah.  but why's koffice in k-d anyway?
<Riddell> Hobbsee, Mithrandir: I uploaded kubuntu-meta without koffice so once that's in the archive we should be able to start making CDs
<Riddell> Hobbsee: for krita
<Hobbsee> Riddell: ahh.  right
<Hobbsee> Riddell: do we know what happened to wlassistant?
<Riddell> Hobbsee: looks like it got uploaded to dapper, let me reupload to edgy
* Hobbsee snorts
<Hobbsee> Riddell: oops?  right.
<Hobbsee> Riddell: why?
<Kamion> ah, gparted is SIGSEGVing; that would explain why it disappears ...
<Riddell> Hobbsee: the changelog had dapper in it not edgy
<Hobbsee> Riddell: oops.
<Kamion> it's not in dapper's unapproved queue
<Kamion> apparently got randomly auto-rejected; I wish soyuz would stop doing that
<Hobbsee> hehe
<Kamion> oh, there was no .orig.tar.gz in the .changes (which would have been fine for edgy but not for dapper)
<dholbach> i'd be so happy if there was a "xgl or whatever" strike force - we get a bunch of bugs just because our versions of xgl/compiz/... are broken and some random packages on the net seem to work
<dholbach> (apart from that I'd be happy, if I could subscribe an xgl team to a bug to get some input) :)
<seb128> Mithrandir: is that ok to upload epiphany-extensions (just a rebuild), it's not on the CD
<Mithrandir> seb128: please do
<seb128> thank you
<lucas> is there a know problem with /usr/include/scsi/sg.h being in both libc6-dev and linux-kernel-headers ?
<dholbach> Gloubiboulga, Riddell: we thought about having a "fix your favourite desktop" hug day on wednesday
<simira> :)
<Riddell> dholbach: sure
<dholbach> Gloubiboulga, Riddell: if you want to add / fix things on wiki.ubuntu.com/UbuntuBugDay wiki.ubuntu.com/UbuntuBugDay/Draft - that'd be nice
<Gloubiboulga> dholbach, would be nice
<Riddell> dholbach: poke me in half an hour after the kubuntu meeting
<dholbach> Gloubiboulga, Riddell: just look at the pages and add whatever you think might be useful
<Hobbsee> dholbach: that'd be cool :)
<sladen> Keybuk / infinity: could you represent wxwidgets2.6 to the buildds
<Keybuk> sladen: I'm on holiday today
<sladen> Keybuk: holiday!   I didn't know Canonical /did/ holiday :)
<Hobbsee> surely they dont.
<Hobbsee> there's no such thing as a holyda
<Hobbsee> *holiday
<jdub> see, no such thing, Hobbsee can't even spell the word
<ogra> Kamion, the installer on ppc tells me it finds no kernel modules
<Hobbsee> jdub: hehe!  i cant typing-spell anyway
<simira> Mithrandir: hey, time to get home to make pancakes! I am hungry!
<^robertj> what's the correct method for requesting a package from non-free be brought into multiverse?
* pitti points out that https://wiki.ubuntu.com/AutomatedProblemReports spec is missing the most imprortant thing: what should be the name of that damn thing? :)
<pitti> ^robertj: a sync request, I'd say
<Hobbsee> pitti: heh, surely not...
<^robertj> pitti: hrmm, where?
<fabbione> pitti: apr sounds good.. like libapr.. and make it clash with libapr from apache :P
<pitti> ^robertj: file a bug against an unknown package, ask for the sync, give the package name and source and subscribe ubuntu-archive
<^robertj> pitti: aha, thanks
<pitti> fabbione: the current name is crash-reporter, but that feels like namespace trampling
<Mithrandir> pitti: call it apport, which means to fetch something (like, a dog which fetches a stick you throw) as well as the description on http://en.wikipedia.org/wiki/Apport
<pitti> Mithrandir: hm, I like 'apport'
<Mithrandir> "Category: Occult"
<Mithrandir> ;-)
<pitti> Mithrandir: has some connotation to a watchdog
<Mithrandir> simira: yes, dear.
<ogra> Kamion, hw-detect: Missing modules 'ide-core, ide-mod, ide-probe-mod, ide-detect, ide-generic'
<jsgotangco> jdub: do you have the fridge drupal theme handy with you?
<Mithrandir> pitti: it's also APpoRt so you have the right letters in there. :-P
<pitti> Mithrandir: heh @ asport
<fabbione> simira: isn't about time to call Mithrandir when pancakes are ready instead? ;)
<pitti> Mithrandir: now I know a verb for this well-known effect :)
<pitti> fabbione: you have been married for too long already :-P
<Mithrandir> pitti: haha. :-)
* Mithrandir decides to go home and make pancakes.  The livefs-es will build without me watching them every step along the way.
<pitti> Mithrandir: 'crapport' :)
<fabbione> pitti: ahaha
<pitti> Mithrandir.apport(pancake)
<Mithrandir> wuff
<^robertj> pitti: bug #53245
<Ubugtu> Malone bug 53245 in Ubuntu "sync request for tremulous" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/53245
<pitti> ^robertj: and now subscribe ubuntu-archive
<^robertj> looking for that op[tion now
<Kamion> ogra: not surprising
<Kamion> ogra: probably built against the wrong kernel version or something
<pitti> ^robertj: 'Subscribe someone else'
<^robertj> done
<pitti> ^robertj: looks good now
<^robertj> thanks a heap, great game btw :)
<^robertj> Vicious though...
<ogra> Kamion, likely... are these modules coming from a udeb or should i see them in /lib/modules somewhere ?
<Kamion> ogra: udebs get unpacked into /lib/modules
<Kamion> at least those udebs do
<Kamion> modprobe does not magically know how to unpack udebs ;-)
<ogra> yes, but thats at the very first screen after selecting the language and scanning the CD
<Kamion> ogra: alt-f2, uname -a
<ogra> so there are no modules with these names at all
<Kamion> the initramfs is also built out of udebs
<ogra> 2.6.17-5-powerpc
<ogra> which matches /lib/modules
<Kamion> ogra: look in /cdrom/pool/main/l/linux-source-2.6.17; see if there are any udebs there with the right kernel versions
<ogra> ah, well
<ogra> all 2.6.17-4.6 
<ogra> so we'll need a d-i rebuild i bet
<Kamion> ogra: no
<Kamion> ogra: is this edubuntu?
<ogra> yes
<Kamion> ogra: you need to do a seed merge to pull in my most recent change to the installer seed
<ogra> built some hours ago
<ogra> eek, ok
<Kamion> if the udebs are out of date, that's never something that needs a d-i rebuild
<Kamion> because the debian-installer source package does not build any udebs - it is strictly a consumer of udebs
<ogra> oh, right they come from the kernel source, i forgot 
<Kamion> if the kernel/initramfs are out of date, then *that's* due to d-i being out of date
<mxpxpod> are the vmware modules for the new dapper kernel scheduled for compile?
<Kamion> ^robertj: FYI we sync source packages not binaries, so it's best to just give the source package name
<^robertj> yeah, should have it's just called tremulous so I think if anyone tackles it they will find it without much difficulty :)
<Kamion> nod
<Kamion> s/if/when/, sync requests are processed relatively promptly
<^robertj> ooh, good :)
<Hobbsee> Kamion: that they are.  thanks :)
* Hobbsee wonders if the one she filed last night, but without the stamp of a MOTU got accepted.
<Kamion> Hobbsee: which one was that?
<Kamion> I think I did all of yours so I probably overlooked that
<Hobbsee> Kamion: ah, it was a gnome one....camorama
<Hobbsee> Kamion: hehe thankyou :)
<Kamion> I didn't process that; I assume ubuntu-archive wasn't subscribed
<Hobbsee> Kamion: okay, i'm not sure why.  i'll grab you a link
<Kamion> oh, it's because you assigned it to ubuntu-archive too
<Hobbsee> Kamion: oh dear.  did i really do that?
<Kamion> that causes it not to show up on the list we normally use (probably due to a Malone bug); I suggest you leave syncs unassigned, as a general rule
<Kamion> https://launchpad.net/distros/ubuntu/+source/camorama/+bug/53153/+activity says so :)
<Ubugtu> Malone bug 53153 in camorama "[Edgy MoM]  Please sync camorama  0.17-5 from Debian Sid" [Untriaged,Confirmed]  
<Hobbsee> Kamion: i thought i subscribed it, sorry about that.  i suspect i might have done that with another one too
<Kamion> I'll hunt all other such bugs down now
<Kamion> just two
<Hobbsee> yeah.  i didnt think i'd done it on the one. sorry about that.  i'd only recently started subscribing the archive myself, rather than getting a MOTU to do it.
<Kamion> no problem
<ogra> Kamion, does the seed tree have a LP page i can subscribe to to getnotified (its not on SeedManagement or i'm blind)
<Kamion> ogra: I guess that would be https://launchpad.net/people/ubuntu-core-dev/+branch/ubuntu-seeds/ubuntu.edgy/+subscribe; I've never tried it, but let me know if notifications work for that and I'll add it to SeedManagement
<Kamion> I think it only pulls every day though
<ogra> Kamion, thanks, i'll tell you if it works 
<Kamion> but probably better than nothing
<ogra> yep, i wouldnt have missed the last changes that way ...
<ogra> but i have not gotten any change notifications from the other branches, so tha feature might only be available in gui yet :)
<ogra> *that
<Kamion> ok, anyone who understands gtk and window managers around? gparted is creating dialogs that are marked transient for a GtkPlug, and they're appearing behind the window containing the corresponding GtkSocket
<Kamion> I've tried both raise() and present() (although admittedly not in combination)
<Kamion> present() has no effect whatsoever here as far as I can tell; raise() does cause the dialog to appear in front of a terminal window that's also on the screen rather than right at the back, but doesn't bring it to the front of the window-containing-the-socket
<Riddell> groovy, kubuntu-desktop installable everywhere, I guess that means we can start making CDs
<Riddell> Kamion: could you kick off a livefs build for kubuntu?
<Kamion> Riddell: running
<Kamion> you'll need at least one more before knot-1 of coursse
<Riddell> Kamion: why?
<Kamion> Riddell: ubiquity's not remotely ready
<Kamion> I have a huge pile of stuff in bzr to upload
<Riddell> fair enough
<Kamion> but only when it works :)
<Riddell> Kamion: how's the alternative installer doing?
<Kamion> tolerably OK I think
<Riddell> I'll start an alternative CD build for kubuntu
<elmo> dpkg: error processing /var/cache/apt/archives/linux-kernel-headers_2.6.17-5.13_i386.deb (--unpack): trying to overwrite `/usr/include/scsi/scsi.h', which is also in package libc6-dev
<elmo> so, err, do I need to run away screaming from this box now or what?
<sladen> niiice.
<tseng> i did --force-overwrite and lived happily ever after
<Hobbsee> elmo: yeah, i got that.  i used --force-overwrite too
<tseng> ignorance is bliss.
<elmo> did either of you report bugs?
* Hobbsee lived to tell the tale.
<Hobbsee> elmo: no, i made a mental note to do it though.
<tseng> no, I assumed it was so horribly obvious
<Hobbsee> sheesh we're terrible
<tseng> yeah.
<fabbione> elmo: known bug
<fabbione> elmo: we need to get Ben to upload a new kernel
<Kamion> infinity noticed it and stuck l-k-h on hold in all the buildds' edgy chroots
* fabbione & for a bit
<dholbach> mjg59: hello! i came across bug 49503 and thought that the Power spec had an idea for solving cases like the one mentioned there. or am i wrong?
<Ubugtu> Malone bug 49503 in gnome-session "Hibernate button being displayed and functions on remote connections" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/49503
<doko> Keybuk: when are merges manual? is this status dropped again, if unstable has a new upstream?
<Keybuk> doko: ?
<doko> Keybuk: universe-manual.html
<HiddenWolf> Keybuk: I have a tv tuner (pci) and a webcam (usb); when both are plugged in it seems random which device is /dev/video0. Is that expected with dapper's udev?
<pitti> zul: ping
<Keybuk> doko: those are the list of sources for which there is no version in Debian less than the version in Ubuntu
<Keybuk> ie. Ubuntu packages 1.0-0ubuntu1 and Debian packages 1.0-1
<Keybuk> there's no base version for comparison
<Keybuk> HiddenWolf: yes.
<doko> ahh, thanks
<HiddenWolf> Keybuk: right. :(
<Keybuk> HiddenWolf: modern software shouldn't care ... it should present you a list of the available video devices
<Keybuk> and remember them by more useful details
<HiddenWolf> Keybuk: so the bug is in tvtime. :)
* HiddenWolf looks at sfllaw
<HiddenWolf> Keybuk: thank you
<sfllaw> The video layer under Linux is just horrible.
<sfllaw> tvtime really can't do much.
<Hobbsee> hi sfllaw :)
<sfllaw> It's like the bad old days of DOS printers.
<ogra> dholbach, the simple bug is gnome-session not caring for the /apps/gnome-power-manager/can_{suspend,hibernate} gconf key 
<ogra> if it would do that, the buttons wouldnt be shown
<mcquaid> hello i wanted to backport baobab from edgy to dapper.  however no version of baobab is currently in edgy
<siretart> https://launchpad.net/distros/ubuntu/+source/baobab
<siretart>    Removed on 2006-07-05 12:44:06 UTC
<mcquaid> does that happen sometimes when the next version is building up or does that mean a pkg has been dropped?
<siretart> why that?
<mcquaid> hmm, no reason listed there..
<ogra> its included in control-center or gnome-system-tools now you wont be able to backport that right away
<mcquaid> huh? sorry not quite getting that. it's become part of gnome-system-tools?
<dholbach> siretart: it's in gnome-utils now
<ogra> ogra@edubuntu:~/seeds/edubuntu.edgy$ dpkg -S /usr/bin/baobab
<ogra> gnome-utils: /usr/bin/baobab
<ogra> sorry, gnome-utils ... 
<dholbach> siretart: and we have a bug report marked as fix committed, which will add it to the packages description
<siretart> ok
<mcquaid> oh well, i guess i'll use the swartz
<mcquaid> but why do that anyway? baobab has no gnome deps
<siretart> I assume gnome-utils handles upgrades from baobab users in dapper gracefully.. 
<mcquaid> seems limiting
<siretart> thats right. what about xfce users, who want baobab without gnome-utils?
<mcquaid> for ex, i use it in xfce
<ogra> ask gnome about it ...
<dholbach> bad luck... baobab upstream wants to maintain it in gnome-utils and asked me to get rid of the old package
<ogra> it was an upstream decision by the looks of it
<dholbach> debian will do that too once they have gnome 2.15
<dholbach> as it makes no sense to have the same code in the archive twice
<mcquaid> yes, but makes just as little to tie something to a particular de when it's not needed
<LaserJock> Kamion: ping?
<ompaul> No manual entry for pickups <--- this is cos its a real guitar :)
<ompaul> woops
<Kamion> LaserJock: hi
<LaserJock> Kamion: doh, nvm. I wondered why you unassigned ubuntu-archive from some sync bugs.
<Kamion> pitti: sudo 1.6.8p12-4ubuntu2 doesn't seem to have the "keep all environment variables for users with unrestricted sudo" behaviour you added
<pitti> Kamion: oh, indeed
<pitti> Kamion: thanks for spotting, I will fix that
<Kamion> thanks - it breaks ubiquity
<pitti> Kamion: (it still has the patch, but the Debian fix breaks it)
<Kamion> well, slightly. it means that it can't talk to gnome-screensaver
<pitti> Kamion: (I'm in a meeting now, will fix later)
<Kamion> I figure you can fix it faster than I can :-) but if you don't have the time, let me know and I'll switch to that
<ogra> BenC, would it soemhow be possible to change the load order for {e,o}hci_hcd ? seems my laptop only recognizes ohci (USB 1.1) if thats loaded first somehow slowing down my USB disks ...
<bluefoxicy> ogra:  I recommend a bios update as well ;)
<mjg59> ogra: No
<mjg59> That's handled by udev
<mjg59> We should fix the bug
<ogra> Kamion, does lithium not publish automatically anymore ? i see no trace of  20060717.1
<ogra> mjg59, yes, i wasnt aware it was udev 
<Riddell> Kamion: where's the place to look for livefs buildlogs?
<BenC> ogra: It should matter...ehci should work still
<Kamion> Riddell: http://people.ubuntu.com/~cjwatson/livefs-build-logs/
<BenC> shouldn't matter
<BenC> 2.6.7-5.14 coming to a buildd near you...
<ogra> BenC, i have a dmesg entry that the device will only be used at low speed as long as ohci is loaded
<Kamion> ogra: look at the end of the build log and the reason will be clear (i.e. I broke some code); fixing
<ogra> ah
<Kamion> ogra: please always look at the build log before asking me :)
<ogra> Kamion, will do, sorry
<mcquaid> btw, regarding packages, since i went to dapper i've noticed a fair amount of 'orphaned' packages listed in synaptic but can't actually be installed as it's no longer available
<BenC> mcquaid: python stuff?
<Kamion> only edubuntu was affected, so I'll fix it by handd
<mcquaid> is there any way to clear those up, or is it other avail programs that referenced it in some dep
<Kamion> mcquaid: deborphan
<mcquaid> BenC, for example libgtop-2.5 is still listed
<Kamion> oh, ones you don't have installed?
<pitti> Kamion: for me, I can start fixing it in about 90 minutes; how urgent is it?
<mcquaid> yes
<Kamion> I think those are just ones that are referenced in dependencies
<mcquaid> ok, 
<Kamion> pitti: I guess that would be OK; do you know the fix already?
<pitti> Kamion: shouldn't be hard to do, I guesstimate 45 minutes for fixing and proper testing
<Kamion> ah, if you don't know the fix immediately I'll leave it to you; I have a lot of other knot-1-critical-path stuff to do
<Kamion> pitti: could you make sure to roll in the fix in bug 53273? the consequences of that bug are a bit nasty
<Ubugtu> Malone bug 53273 in sudo "prerm doesn't work with dash" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/53273
<pitti> oh, another bashism?
<pitti> sure
<ogra> pitti,  we have tons of them
<Kamion> argh, can we please at least put command editing into dash? it's really frustrating not having that
<Kamion> ogra: the bulk of them are in scripts that say #!/bin/bash though
<Kamion> which is not ideal but not a bug either
<ogra> well, *my* scripts didnt until now :)
<ogra> but i have seem some other incidents ...
<ogra> like debian/rules failing because of "rm -f /blah/{targetfile1,targetfile2}
<ogra> "
* ogra wasnt aware that was a bashism at all
<Kamion> yeah, there's not a lot of that left though
<Kamion> most of that was dealt with in Debian a long time ago
<ogra> but debian never switched ...
<ogra> so it might have reappeared 
<Kamion> there have been people building stuff with dash as /bin/sh to test for that
<Kamion> and lintian warns about its use in maintainer scripts
<Kamion> so it doesn't tend to reappear all that much
<Kamion> yes, there is the odd exception
<ogra> :)
<Kamion> generally speaking, though, it's in dodgy upstream shell programs rather than debian/rules or maintainer scripts
<Kamion> the bulk of Debian maintainers have been made well aware of the problems by very long mail threads and lots of bug reports
<ogra> yu, i noticed that ... its hard to find info on bashisms since you only get a long list of debian bugs at google :)
<ogra> *yup
<Kamion> http://www.opengroup.org/onlinepubs/009695399/nfindex.html is the POSIX specification, which includes the shell
<Kamion> avoid things marked [XSI]  in /bin/sh scripts
<Kamion> and avoid things not listed at all
<ogra> thanks a lot, i'll see if i can get ltsp dash clean ...
<Kamion> the dash man page is a reasonable thing to program to, although not perfect
<ogra> ltsp-build-client currently relies somewhat on bash stuff ...
<Kamion> but it's a lot better than programming to the bash man page
<Kamion> ogra: edubuntu 20060717.1 fixed
<ogra> well, i'm an old abs-howto user :) i never programmed after manpages
<ogra> Kamion, thanks
* ogra rsyncs
<Kamion> I'd run away from all the howtos
<Kamion> they are rarely written with an eye to portable shell, more with an eye to SHINY
<ogra> well it was what i used to learn bash scripting ages ago ...
<ogra> but indeed you see my code isnt bashism free now (in fact i ever cared before i saw dash the first time )
<Kamion> http://www.greenend.org.uk/rjk/2001/04/shell.html is also worth reading, written by a friend of mine; it's not specifically about portability but is generally worthwhile reading for shell programmers
* ogra bookmarks
<Keybuk> also get a copy of Blinn
<ogra> blinn ? 
* ogra googles
<Keybuk> http://www.amazon.com/gp/product/0134514947/
<ogra> ugh, dead trees
<ogra> i even read my pratchetts on the laptop nowadays :)
<ogra> but i'll get a copy ... )
<mjg59> iwj: My fonts have changed in Epiphany again
<iwj> mjg59: Oh ?
<iwj> (I have to go soon; it's Monday and if I don't I'll miss my dinner ...)
<mjg59> iwj: Back to blurry colour madness
<mjg59> iwj: Sure, no urgency
<iwj> Is it using Nimbus ?
<iwj> (Easiest way to tell: select Nimbus from the font preferences and see what it does.)
<iwj> Perhaps some of my fontconfig-related changes have been undone or not merged properly.
* iwj makes a mental note to check up on it.
<ogra> mjg59, on a lappie ? i noticed that subpixel rendering was disabled after an upgrade to edgy
<ogra> just switching it on in the fonts ui solved it here
* iwj goes.  I'll catch up on this conversation tomorrow :-).
<mjg59> iwj: Hm. Could be. The font preferences don't seem to let me change the main one that's being used
<iwj> Ug.
<Keybuk> Kamion: your friend wins a "useless use of $@ award"
<Keybuk> sfere$ for x in "$@"; do  echo "[$x] "; done
<Keybuk> ...
<mjg59> ogra: If subpixel rendering was disabled, I don't think I'd be seeing coloured blur
<Keybuk> why not just "for x; do" :p
<ogra> mjg59, thats how it looks on my screen ...
<ogra> if i switch on subpixel rendering its crisp again
<mjg59> ogra: If there's no sub-pixel anti-aliasing, then there is no coloured blurring
<mjg59> iwj: Interestingly, it's not nimbus. Hrm.
<Kamion> Keybuk: given that it's in a section entitled "Special Behaviour of $@", I think it's semi-justifiable
<ogra> mjg59, well, then the ption in the font settings gui might be mis-named ... i can just tell waht i see here 
<Kamion> Keybuk: but you could always mail him and suggest he add a note
<Keybuk> Kamion: I disagree ... a bad example, even when demonstrating a particular behaviour, is a bad example
<Keybuk> people tend to copy and paste examples without reading the surrounding text
<Kamion> then I repeat my second comment :)
<Keybuk> cf. the famous "wrong example of wait()" in Stevens which has been copied into many UNIX programs and defended
<Keybuk> I have just mailed him, actually
<Kamion> ta
<Keybuk> (Stevens gives an example of a SIGCHLD handler that calls wait() as a general example of the kinds of things you do in such handlers ... this handler has been used as the template for many a developer's handler
<Keybuk> the problem is that it calls wait() only once ... when you in fact need to do it in a loop to consume all child processes, as you may have received more than one signal or had signals dropped as you were beginning processing of one)
<Keybuk> he fortunately corrected the example in later books (UNP carries a correct one)
<Kamion> Keybuk: urgh, speaking of dodgy wait code, look at /usr/lib/python2.4/site-packages/apt/progress.py and search for waitChild
<Kamion> let's wait for children by SPINNING
<Keybuk> *blink*
<Keybuk> I can see why they've done that ... but ... eww
<Kamion> what's wrong with read() and a signal handler
<Keybuk> I'd select() on an empty list ;)  but yeah, same thing
<mdz_> fabbione: that isn't what I mean; for example, is ubuntu-desktop on sparc installable?  are the livefses building?
<Kamion> Keybuk: actually select() is indeed better because the reason it spins is that (in my case) read() is immediately returning EAGAIN
<Kamion> -> bug 53282
<Ubugtu> Malone bug 53282 in python-apt "InstallProgress.waitChild spins if read fails immediately" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/53282
<ogra> hmm, intresting 
<ogra> that daily iso rsync had only changes on ppc
<ogra> ARGH
<ogra> Unknown terminal: bterm 
<ogra> where does that come from in the installer ??? 
<sitontony> i have a suggestion
<sitontony> i have a suggestion for the developement
<Keybuk> Kamion: I guess the Debian BTS LDAP gateway is down atm?
* Starting logfile irclogs/ubuntu-devel.log
<pitti> Kamion: sudo still purges if root once had a password which was then locked with passwd -l root
<pitti> Kamion: so I'd like to fix the prerm to check whether getent shadow root *starts* with ! instead of checking whether it is equal to !
<pitti> Kamion: are you fine with that?
<fabbione> mdz_: no i didn't check because it was higher priority to finish other stuff. Also sparc desktop for knot-1 can be broken. It's not a regression and there for not so important
<pitti> Mithrandir: ok to upload a new sudo with the env hanling fix Kamion needs for ubiquity? I also fixed a bashism and a bug in the prerm
<fabbione> pitti: openais with your requested changes is up
<pitti> thanks
<fabbione> pitti: it's only waiting your magic touch to enter main
<fabbione> pitti: so that i can unleash the new r-h-c-s
<pitti> fabbione: -ENOMAGIC here
<fabbione> pitti: and transit lvm2 to the new locking manager
<pitti> fabbione: that requires ftpmaster powers (Kamion/Keybuk)
<fabbione> pitti: well you still need to tell ftp-master to go ahead :)
<pitti> fabbione: anyone can, they'll look at the MIR queue
<pitti> Kamion, Keybuk: for the record, openais is good for main
* pitti assumes a 'yes' for sudo and uploads
<pitti> grr, I'm a fool, I just locked myself out of sudo
<fabbione> pitti: you can use one of the unpatched exploit :P
<pitti> heh, good idea :) the prctl one should work
* pitti tries that instead of rescue mode just for the fun of it
<fabbione> yeah they actually do.. i think elmo knows :P
<pitti> fabbione: the advantage of the prctl one is that the exploit works fine on all arches; that's pretty rare usually :)
<Mithrandir> pitti: please
<ogra> xorg postinst fails
<Burgwork> ajmitch, do you have a blog for your network auth stuff?
<Burgwork> Petaris, I just asked him
<Petaris> Burgwork: Ok
<ogra> Jul 17 18:45:04 in-target: Setting up xserver-xorg (7.0.22ubuntu5) ...
<ogra> Jul 17 18:45:05 debconf: Obsolete command TITLE Configuring xserver-xorg called
<ogra> Jul 17 18:45:08 in-target: xserver-xorg postinst warning: not updating /etc/X11/X; file has been
<ogra> Jul 17 18:45:08 in-target:    customized
<ogra> Jul 17 18:45:08 in-target: [: 31: 
<ogra> Jul 17 18:45:08 in-target: ==: unexpected operator
<Keybuk> BASHISM!
<ogra> ideas anyone ? i have no clue what that should tell me ... but it breaks edubuntu installs 
<ogra> *sigh*
<jdub> :o
<ogra> funnily i cant find any == in there
<Mithrandir> ogra: I think Colin fixed that later today.
<ogra> nope, its the recent package
<ogra> it installs fine (even though it shows the error) in the normal system ... but breaks ltsp chroots 
<sladen> s/==/=/
<ogra> i would have sworn there is no == in that file at all .. but i just found it :D
<ivoks> why do we have /var/lock and /dev/shm mounted as tmpfs with default size (each is half of RAM), and every user can write in those dirs
<Keybuk> ivoks: why does it matter?
<Keybuk> any user can malloc() the equivalent size anyway
<Keybuk> it's just page cache
<ivoks> i know, but...
<ivoks> do we really need 256MB for /var/lock? :)
<Keybuk> no, you could always add an appropriate limiting option in /etc/fstab if you needed it
<ivoks> sure... well, there's no harm in leaving it like this...
<Keybuk> note that you can set this in /etc/default/tmpfs
<Keybuk> (for /dev/shm, that is)
<ogra> Mithrandir, o if i upload a bashism free package for xorg ? 
<ogra> *ok even
<Mithrandir> ogra: can I look at the diff, please?
<ogra> heh, sure
<ogra> +++ /tmp/GfWNPqHI0J/xorg-7.0.22ubuntu6/debian/xserver-xorg.postinst.in  2006-07-17 21:13:09.000000000 +0200
<ogra> @@ -383,7 +383,7 @@
<ogra> 
<ogra>    # Set a sane monitor id default if probe fails
<ogra>    if [ -z "$MONITOR_IDENTIFIER" ] ; then
<ogra> -      MONITOR_IDENTIFIER=="Generic Monitor"
<ogra> +      MONITOR_IDENTIFIER="Generic Monitor"
<ogra> and a changelog entry
<ogra> Mithrandir, ^^
<Mithrandir> that's not even a bashism.  It's just illegal shell.  Looks good to me.
* ogra uploads then 
<ogra> i wonder if it finishes before all kernel builds :)
<bluefoxicy> pitti:  utrace?
<bluefoxicy> pitti:  http://www.redhat.com/archives/fedora-cvs-commits/2005-October/msg00448.html as well.
<pitti> bluefoxicy: that looks useful, thanks for digging it out
<tseng> bluefoxicy: i met that jjohnson guy 2 years ago
<tseng> with russel
<bluefoxicy> pitti:  yeah, also <drow> you do know other people have written code to automatically attach gdb to things, right?  Last time I looked, gnome and kde could do it. <DannyB> drow: it's not good unless you've written it yourself <DannyB> don't you know anything
<bluefoxicy> tseng:  interesting.  BTW mdz wants to put the libgcrypt11 update into dapper-backports instead of dapper-updates.
<tseng> bluefoxicy: er, ok.
<Kamion> Keybuk: BTS LDAP> no idea, sorry, I've never really followed that
<Kamion> ogra: export TERM=linux and get on with your life :)
<Kamion> ogra: the installer uses a terminal called 'bterm' and unfortunately not much else really understands that terminal type
<ogra> Kamion, hmm, but why does it do that suddenly ? it worked before
<Kamion> pitti: sudo.prerm> sounds reasonable
<Keybuk> Kamion: I did a BeautifulSoup version instead -- cf. ubuntu-archive
<Mithrandir> Kamion: what bts ldap thing?
<Kamion> ogra: while that MONITOR_IDENTIFIER fix was correct, it's not what the warning was about
<Kamion> Mithrandir: there's an LDAP gateway to bugs.debian.org which aba (IIRC) wrote
<Mithrandir> Kamion: oh, that's down pending the cronjobs on merkel being reenabled.
<ogra> Kamion, whats it then ? i didnt understand it 
<Mithrandir> AIUI
<Kamion> ogra: just some stuff complains about a $TERM it doesn't understand, that's all; various things have warned about it in rescue mode for years
<Kamion> Mithrandir: sounds plausible
<Kamion> ogra: well, I don't know yet or I'd have said :)
<ogra> Kamion, ok, i'll add a TERM=linux to the top of the ltsp-build-client script, even i find it weird that it always worked until now
<Kamion> ogra: you didn't give me any context about where the "Unknown terminal" message was coming from before now
<Kamion> you should check what you're using that's trying to open a terminal; nothing in ltsp-build-client should be trying to talk to the terminal surely
<ogra> Kamion, well, from xserver-xorg prostinst ...
<Kamion> the unknown terminal message is coming from xserver-xorg.postinst?
<ogra> ltsp-build-client is supposed to fail if the second stage install (xorg and ldm) in the chroot fails
<ogra> yes
<Kamion> I've found the == bashism; it's in xresprobe. fixing
<ogra> i have an error with configuring xorg and xserver-xorg failed
<ogra> ah
<Kamion> world conspiring against me. now apt is behaving weirdly.
#ubuntu-devel 2006-07-18
<Keybuk> 01:48:33.099049 169.254.141.111.137 > 169.254.255.255.137: udp 68 (ttl 128, id 15045, len 96)
<Keybuk> 01:48:33.102586 169.254.141.111.137 > 169.254.255.255.137: udp 68 (ttl 128, id 15046, len 96)
<Keybuk> 0
<Keybuk> heh
<Keybuk> random traffic on my network
<Keybuk> methinks a neighbour wants internet access
<tseng> Keybuk: bootp, kinda weird
<Keybuk> isn't that part of the link-local discovery protocol?
<Keybuk> could be a windows machine
<Burgwork> Keybuk, do you run segmented wireless networks?
<Keybuk> Burgwork: and in English?
<Keybuk> 01:55:13.382275 arp who-has 82.108.80.243 tell 82.108.80.254
<Keybuk> ^ that's weird too ... why is it ARPing an IP address that's unused?
<Burgwork> Keybuk, run two seperate wireless networks, one public and one private
<Keybuk> oh, I know ... I stuck it in the root dns temporarily
<Keybuk> heh
<Keybuk> Burgwork: nah
<tseng> Burgwork: im not that friendly
<Keybuk> I used to, but my neighbours were taking the piss and downloading porn on it
<Burgwork> ah
<Keybuk> so I now only run a restricted-mac network
<Burgwork> would be nice if the routers could do it ootb
<Keybuk> "the routers" 
<Keybuk> ?
<Burgwork> sorry, end of the day, mind is spacing
<Burgwork> s/the//
<Keybuk> I never run production firmware on a router anyway
<Keybuk> always replace it with a Linux of some kind
<sistpoty> openwrt is nice :)
<HrdwrBoB> I just run the wireless network seperately
<HrdwrBoB> and use a vpn over the top of it
<Keybuk> want to get to the point where I can just run Ubuntu on a WRT
<sistpoty> yay, that would be great
<Chipzz> Keybuk: why would you want to do that?
<Keybuk> Chipzz: because I can
<Keybuk> what better reason is there? :p
<Chipzz> you could consider using your better judgement? ;P
<Chipzz> ubuntu is waaaaaaaaaaaay to big in way too many sizes to be usefull in allmost any way on a wrt
<Chipzz> let alone that apt would not be a big advantage giving the limited rewritability of flash
<ogra> Keybuk, that looks very much like my linksys router a minute before it dies :)
<Kamion> woo, complete ubiquity installation of edgy
<Kamion> whether it boots is another question for another day, I feel
* ogra applauds
<Keybuk> Chipzz: hmm?  Ubuntu can be as small as you want
<Keybuk> a kernel, initramfs and minimal klibc-based or busybox-based root filesystem
<Keybuk> doesn't need to use dpkg or apt, etc.
<Keybuk> To: 	scott@ubuntu.com
<Keybuk> Subject: 	Happy Birthday from Ubuntu Forums
<Keybuk> Date: 	Tue, 18 Jul 2006 00:01:13 +0100 (BST)
<Keybuk> how tacky
<Chipzz> Keybuk: then what is the point in using ubuntu anyway?
<Keybuk> Chipzz: means it's our code on there, rather than something else
<ogra> Keybuk, H A P P Y  B I R T H D A Y ! ! ! ! ! 
<Keybuk> ogra: not officially my birthday until "tomorrow"
* ogra throws a big bunch of flowers ove Keybuk 
<ogra> bah
<ogra> it starts at 00:00 !
<Chipzz> Keybuk: happy birthday :)
<zul> happy pre-birthday
<Keybuk> ogra: but that's 19 hours before I was born
<ogra> pfft, did you never party into your b-day ? did you care then ? 
<lifeless> Keybuk: its tomorrow here already, deal. HAPPY BIRTHDAY.
<lifeless> Keybuk: or do you mean wednesday?
<ogra> no he means in 19h
<crimsun> Keybuk: so I hope you're going to take a nice break from irc for a bit :-)
<crimsun> (since you did mention taking the day off)
<Keybuk> yeah, we're going on a day out somewhere
<crimsun> rock, enjoy :-)
<Keybuk> anyhoo, beer and dvd time
<Keybuk> night
<Kamion>  ubiquity_1.1.0_source.changes 3.7 kB, ok (0 s, 3.72 kB/s) ] 
<Kamion> ha. right. bed. night.
<Kamion> (that was almost poetic.)
<jdub> "To sum it up - Dapper Drake is Ubuntu's best release to date, where just about everything just works. The massive array of packages, with the user friendliness bolted on, mean that I can recommend Ubuntu to anybody that wants a nice, simple distribution. Just make sure you download the alternate CD."
<jdub> heh
<jdub> hrm
<jdub> ;-)
<BenC> what's the rule for patching packages in universe?
<BenC> do I need to coordinate with motu, or can I just patch and upload?
<crimsun> the latter
<LaserJock> I don't know I think he should have to have a MOTU sponsor it ;-)
<LaserJock> sorry, that just struck me as funny for some reason
<infinity> BenC: As a member of core-dev, you're implicitly also a MOTU.  If it's a package with significant Ubuntu changes and someone who looks like an "Ubuntu maintainer" taking care of it, though, it's always nice to ping them.
<BenC> infinity: it has no changes from the debian version
<BenC> kexec-tools...so I doubt it has any significance as of yet
<BenC> I need the kdump patch in it though
<infinity> BenC: Yeah, just mangle and upload.
<infinity> BenC: Also, new kernel built everywhere, and the new lkh is good on all arches (I updated the chroots and was much relieved).  Thanks.
<BenC> sweety
<BenC> err, just "sweet"
* infinity snickers.
<BenC> now I don't have to worry about Mith killing me for holding up knot-1 any longer than I already have
<infinity> I may still hurt you. ;)
<sladen> BenC: Mithrandir is a _nice_ person.  If he's going to kill you, it'll be done in such a nice way that you might never notice...
<infinity> Or such a nice way that you'll actually appreciate it while it's happening.
<infinity> Maybe he'll get dholbach to hug you to death.
<sladen> jdub: that's a good quote.  Perhaps worthy of El Fridge?
<BenC> hehe
<sladen> infinity: :)
<sladen> Crossiant|Nose>Keyboard
<infinity> Ow.
<sladen> wow, Mithrandir was fast.
<sladen> infinity: can you kick 'xaralx' out of DEPWAIT please
<infinity> Erm, the depwait is incorrect?
<infinity> Looks correct to me.
<infinity> It'll resolve itself when the right version of wx2.6-headers is published.
<infinity> sladen: Check the build log to see what I mean.
<sladen> infinity: it has been.  wx2.6 failed because of errno.h not being around
<infinity> https://launchpad.net/distros/ubuntu/edgy/+package/wx2.6-headers
<infinity> ^^ That shows 2.6.1.2ubuntu2 published
<sladen> infinity: yes  2.6.3.2.1.1ubuntu2 finally got built yesterday 
* sladen goes to investigate
<infinity> It may be in the NEW queue, then.  It's definitely not published.
* infinity goes to look.
<infinity> Yeah, the binaries are in NEW.
<infinity> libwxbase2.6* was NEW.
* infinity processes.
<sladen> infinity: rocking
<stub> Launchpad will be going down in 15 minutes for its regular code update. Estimated downtime is 25 minutes.
<pitti> Good morning
<jsgotangco> hello pitti
<crimsun> infinity: hi, is there a failed upload of kst from 17 minutes ago?
<infinity> crimsun: Could just be unprocessed, since stub stopped all the cronjobs on drescher in anticipation of the LP update.
<crimsun> infinity: ah, must be. Thanks.
<infinity> crimsun: Yeah, it's in incoming.
<crimsun> ah, greta.
<crimsun> great^
<Hobbsee> oh darn it.  just when i was going to file a whole lot of bugs on it.
<Spads> http://flickr.com/photos/mbp_/112373573/ <-- he got the shot
<Spads> oops, MCM
<fabbione> morning guys
<fabbione> hey Hobbsee 
<Hobbsee> hi fabbione :)
<Hobbsee> fabbione: i think you're in luck, you're not listed in my "todo" list.
<fabbione> Hobbsee: i am not sure how i want to read what you just wrote
<Hobbsee> fabbione: um, okay.  while i was out, i made a list of all the stuff i had to tell people, and worked on amarok a bit.
<Hobbsee> fabbione: so now i'm finding those people, and telling them whatever i wrote down to tell them.
<fabbione> ah ok :)
<fabbione> well i don't use kde or amarok
<Hobbsee> fabbione: i figured that.
<fabbione> it's unlikely you will ever have to hunt me down
<Hobbsee> fabbione: sure i will - to scream at you for breaking X?
<crimsun> (quick, acquire a sparc, Hobbsee)
<Hobbsee> crimsun: heh
<fabbione> Hobbsee: nope.. i am off X too :)
<Hobbsee> fabbione: oh yeah.  oops. i could scream at you anyway?
<fabbione> Hobbsee: cluster? sparc?
* Hobbsee has one i386, that's it
<fabbione> Hobbsee: sorry.. none of what i do fits in there
<Hobbsee> fabbione: yeah, i figured that out eventually.  
* Hobbsee looks around for whatever happened to her brain.
<nomed> hi all
<Hobbsee> hi nomed 
<Kamion> jdub: URL? I'd like to ensure that his desktop CD problems are fixed in the first point release.
<Kamion> (since I believe I've now fixed at least half of the top ubiquity crashers from dapper in edgy)
<Hobbsee> Kamion: yay!
<jdub> Kamion: sorry
<jdub> Kamion: http://www.free-bees.co.uk/articles/ubuntu606/
<Kamion> ok, one system freeze, no idea what that is
<Kamion> one instance of gparted not embedding properly, hmm
<Kamion> another instance of the installer spewing an unspecified error message
* Kamion goes to send a comment
<Mithrandir> TheMuso: care to look at https://launchpad.net/bugs/53277 ?
<Ubugtu> Malone bug 53277 in casper "casper's accessibility ubiquity hook shouldn't use log_end_msg" [Untriaged,Unconfirmed]  
<pitti> Riddell: pth needs work before main approval, see MIR
<pitti> seb128: FYI: cairomm approved for main (gtkmm2.4 b-dep)
<sivang> morning
<seb128> pitti: thank you
<Hobbsee> hi sivang 
* sivang hugs Hobbsee :)
* Hobbsee hugs sivang in return :)
<Mithrandir> seb128: why can't I enable system sounds without enabling software mixing?  My sound card does hardware mixing just fine..
<seb128> Mithrandir: because libgnome uses the esd API to play them
<seb128> Mithrandir: switching that code to gstreamer is planned though
<Mithrandir> seb128: ahkay.  Any good reason for the panel eating 40% cpu here?  up-to-date-edgy
<seb128> Mithrandir: is the menu "flicking" too?
<seb128> we have some bugs about it but nobody provided useful enough datas about the issue
* sivang dist-upgrades
<Mithrandir> seb128: the applications menu is, the others seem fine.
<seb128> ok
<seb128> let me find the bug number
<seb128> ogra was supposed to get a debug log but he didn't
<seb128> Mithrandir: bug #52405
<Ubugtu> Malone bug 52405 in gnome-panel "gnome-panel eats 50% cpu for half an hour and flickers" [Untriaged,Confirmed]  http://launchpad.net/bugs/52405
<seb128> Mithrandir: gnome-session-remove gnome-panel && MENU_VERBOSE=1 GNOME_PANEL_DEBUG=1 BONOBO_ACTIVATION_DEBUG_OUTPUT=1 gnome-panel ... and try to figure what event make it updates in loop could be useful
<seb128> Mithrandir: a backtrace (with gnome-panel-dbg install) could be useful too
<Mithrandir> seb128: I gotta grab some food, but I'll do that once I get back.
<seb128> thank you
* pitti hugs dholbach 
* dholbach hugs pitti
<dholbach> good morning
<Hobbsee> hi dholbach, pitti 
<dholbach> hey Hobbsee
<seb128> hi dholbach
<seb128> utch
<seb128> they reversed the order of comments to launchpad?
<dholbach> hey seb128
<seb128> new comments are on top now
<dholbach> yeah seems like :/
<seb128> it's very confusing
<thom> not again?
<seb128> and you don't have the current comment next to the text entry, which is not handy to reply to it
<Kamion> seb128: apparently a bug, should be fixed soon
<Kamion> (already fixed on staging)
<seb128> Kamion: ah, cool, thank you
<Hobbsee> are uploads to main still frozen?
<Mithrandir> yes.
<Mithrandir> we'll hopefully be able to get knot out today, though.
<Hobbsee> Mithrandir: okay, i'll put it in the "to do list of packages to either upload myself, or bug people to upload"
<HiddenWolf> whiprush: your blog entry works on your blog, but is horridly broken on planet.ubuntu
<dholbach> HiddenWolf: known bug :)
<HiddenWolf> heh, i figured.
<ogra> Kamion, in case you are intrested in the precise error from yesterday (i only worked around it in ltsp) http://paste.ubuntu-nl.org/18254 (i also have the full log stored)
<Kamion> ogra: looks like you're not (correctly) telling debconf to use the noninteractive frontend
<Kamion> there is no reason it should be trying whiptail if invoked correctly
<ogra> hmm
<Kamion> also a bug that debian-installer/{keymap,language} aren't being copied
<ogra> thats why i always get the resolution question then ...
<ogra> i thought it was an X breakage :)
* ogra looks why its broken
<Kamion> uh
<Kamion> ok, so do you want the resolution question to be asked in the event that X can't autodetect it?
* Kamion goes and looks at the code
<Kamion> oh, I see, very broken
<Kamion> ogra: I'd suggest replacing that whole env -u ... command (including the redirections) with 'in-target /usr/sbin/ltsp-build-client --mirror file:///cdrom'
<ogra> Kamion, i dont want any configuration ... that would be the best, but we're missing a debconf key for that :)
<Kamion> needs di-utils (>= 1.20)
<Kamion> you could probably do 'DEBIAN_PRIORITY=critical in-target ...' to avoid the question
<Kamion> it's asked at priority high
<ogra> in-target does all the chroot magic ? 
<ogra> Kamion, *all* the redirections ? you mean i shouldnt create a separate logfile ? 
<Kamion> ogra: correct
<Kamion> /var/log/messages is obsolete
<Kamion> in-target does the logging for you
<Kamion> and yes, in-target does all the chroot magic
<Kamion> of which nowadays there is quite a lot
<ogra> well, i'd lie to keep a separate log as well, so i dont have to dig for the ltsp stuff in the big one
<ogra> *like
<Kamion> you don't keep a separate log right now though
<ogra> sure
<ogra> in /var/log/installer/messages in the target system after install
<Kamion> that's only by fluke because you're out of date with respect to the rest of the installer code
<ogra> (i had renamed that in my branch to ltsp-client.log already)
<ogra> ah, k
<Mithrandir> Kamion: I have a live cd where gfxboot doesn't work, but usplash does.  It worked with my old monitor, though.  Is there a useful way for me to debug this?
<Kamion> ogra: it would really be strongly preferable for you to use in-target, but perhaps you could do:
<Kamion> in-target sh -c '/usr/sbin/ltsp-build-client --mirror file:///cdrom > /var/log/ltsp-build-client.log 2>&1'
<Kamion> it will be less convenient for users trying to work out what's going on though
<Kamion> because that log won't appear on tty4
<Kamion> Mithrandir: hmm. I think there might be some magic keystrokes
<Kamion> Mithrandir: I think you can hold down shift at boot to get into a failsafe mode
<ogra> Kamion, i'll live with the bigger log, dont worry
<Kamion> well, anyway, the above is how to get a separate log
<ogra> yep, thanks :)
<Mithrandir> seb128: gnome-settings-daemon fails to start on the live cd -- no reply within specified time.
* Mithrandir wonders how to debug that.
<ogra> btw, whats holding us up now ? 
<Mithrandir> we need to get all the ISOs tested.
* ogra was looking and saw no isos :)
<Mithrandir> and I have the problem mentioned above which would be nice to debug or check if it's just my system.
<ogra> well, it works on my installed system from  20060717.1
<Mithrandir> ogra: dude, I can surely build you ISOs, but if you want me to, you need to actually ask.  I suck at mind-reading, just ask simira.
<ogra> Mithrandir, no, i'm fine building them myself :)
<ogra> i didnt know ubuntu was ready so far 
<ogra> but livefses would be nice :)
<Mithrandir> just a sec, I need to get this kiwi juice off my fingers
<ogra> no hurry :)
<Mithrandir> ok, edubuntu livefs-es building.
<Mithrandir> Riddell: you probably want kubuntu livefs-es too?
<Riddell> Mithrandir: yes please
<Mithrandir> Riddell: I'll build you ones once the edubuntu ones are done, then
<Kamion> Riddell: there are a lot of qtparted crashes relating to NTFS; see bug 47194 and the zillion duplicates. Is there anything you can do to stop it crashing? If so, getting a fix into the Dapper point release would be nice.
<Ubugtu> Malone bug 47194 in ubiquity "qtparted seems to crash on some setups; deal with this better?" [Medium,Needs info]  http://launchpad.net/bugs/47194
<Kamion> (I'm not sure if all of those are related to NTFS though)
<Kamion> unfortunately there's no particularly easy way to get a crash dump from people, and it doesn't seem to output anything on stderr when it crashes
<Riddell> Kamion: is there a way to create NTFS partitions so I could try it out?
<Kamion> install Windows
<Riddell> tricky, no windows CD here
<Kamion> ntfstools might be able to do it
<Kamion> dunno - I doubt it happens on all NTFS filesystems
<Kamion> I think only ones that are subtly buggered
* Hobbsee hopes she doesnt get asked to test.
<Kamion> is it possible to try to trace through the qtparted code and make sure that it handles NTFS check failures gracefully?
<fabbione> Kamion: speaking of point release, we left a couple of sparc changes in the middle. I was wondering if after knot1 we can start looking at them and possibly start to push them in the archive. Mainly so that i can build a custom d-i for pre-testing
<Kamion> fabbione: sure
<fabbione> Kamion: thanks that would be just awesome.
<Kamion> remind me afterwards
<fabbione> yup
<Hobbsee> I dont think i found that ntfs bug on the dapper ubuntu cd that i tried, with ubiquity.  i never tested kubuntu cd, so i'm probably not much help.
<Lathiat> Riddell: i could create an ntfs image for you?
<Riddell> Lathiat: on my machine?
<Lathiat> no but i could dd it off?
<Lathiat> and send?
<Lathiat> how large does it need to be?
<Lathiat> altho fi i zero it first should compress ok
<Riddell> not large
<Lathiat> name a size?
<Robot101> sladen: daf was packaging it for Debian I think, but then at guadec I heard that dholbach had packaged most of it for Ubuntu anyway
<zul> pitti: im just uploading breezy/hoary kernels now
<pitti> zul: thanks
<pitti> zul: I already released the dapper one this morning, since this was quite urgent
<zul> i saw that
<Riddell> Lathiat: 10MB
<Kamion> Lathiat: we have no idea - I'm not sure random NTFS filesystems will help
<Kamion> Lathiat: needs to be one that we know the Kubuntu CD crashes on, really
<Kamion> er Kubuntu ubiquity
<Lathiat> hm right
<Lathiat> when does it crash? resizing?
<Lathiat> or just magically?
<Riddell> seb128: what's the best way to get a patch into launchpad-integration?
<Lathiat> cus i can try the iso and see if it crashes?
<Kamion> Lathiat: I believe it's when they go into the advanced partitioner, do pretty much anything, and then say Next
<Lathiat> where do i get the iso?
<Kamion> I don't generally get a whole lot of detail
<Riddell> kubuntu.org/download.php
<Kamion> http://releases.ubuntu.com/kubuntu/dapper/
<Lathiat> oh dapper?
<Kamion> yes
<Lathiat> im pretty sure i've installed kubuntu dapper ..
<Lathiat> cant remember if it was final
<Lathiat> i'll give it a shot, cant hurt
<Mithrandir> oh, grrrrrrrr, now it managed to start the daemon.
<Mithrandir> but my background is slate, not brown
* Mithrandir twiddles his thumbs while vivies finishes the edubuntu image.
<Riddell> Mithrandir: it's still doing edubuntu livefs's?
<Mithrandir> Riddell: yeah.  The sparc is slow as molasses.
<Mithrandir> Riddell: eta ~15 minutes
<Mithrandir> ogra: edubuntu built.
<ogra> thanks !
<Kamion> Riddell: could you also review the kde-ui changes in r1403 in my ubiquity branch?
<Kamion> I haven't tested them ...
<Kamion> Riddell: of course it's still not perfect - if gparted/qtparted keep crashing, then ubiquity should give up
<Kamion> and tell the user
<Kamion> hmm, actually that's relatively easy to do isn't it ...
<Riddell> Kamion: looking..
<Mithrandir> ogra: the livefs didn't work due to an untested change to the livefs build script.  Sorry; I'll rebuild it once we've tested the change properly.
<ogra> oki
<infinity> ogra: You can blame me for not testing.  Or blame Mithrandir for having the machines blocked when I wanted to test.  Pick one. :)
<infinity> I need to clear up some disk space to test livefs changes locally again.
<ogra> infinity, pfft i'll take our best whipping boy and just blame launchpad :P
<pitti> ogra: you mean it's a GTK bug?
<Mithrandir> it's the bug comment ordering's fault! :-P
<infinity> I prefer to blame launchpad only when it's actually at fault, so we get heard. :)
<infinity> Blaming GTK is fair game, though.
<ogra> pitti, yeah ... 
<Hobbsee> Mithrandir: everything's the fault of that, yes.  that sends everyone crazy, then they understand nothing. :P
<infinity> Grr, security really needs to move back to the DC...
<pitti> infinity+++++++++++
<pitti> OTOH, I mean, it's just *yet* another 45 minutes of delay...
<infinity> Oh, for the love of.  Options come AFTER the source/dest args?  WHO WROTE THIS TOOL?
* infinity tries AGAIN.
<Mithrandir> infinity: oh yeah, I forgot to tell you that, didn't I?  It's crackful.
<infinity> Whee, why is it failing there?  I didn't break that part...
* infinity fiddles MORE.
<maswan> infinity: Yes, we're going to do that. We were planning on doing that after this kernel bandwidth peak.
<seb128> Riddell: open a bug with it on the launchpad-integration package
<Kamion> Riddell: another untested patch (r1404) in my branch to stick up crash dialogs if gparted or qtparted crash so that we don't spin repeatedly reinvoking them. (I'll test before release; I just wanted to get the patch out of the way.)
<Riddell> Kamion: it's still branching..
<infinity> Mithrandir: Okay, I think it's sorted now.
<Mithrandir> infinity: I'll build edubuntu and kubuntu livefs-es, then
<Mithrandir> infinity: thanks
<ogra> hmm, http://cdimage.ubuntu.com/edubuntu/daily-live/20060718/ looks a bit weird ...
<ogra> seems i got dapper isos :P
<infinity> Picky, picky,
<Hobbsee> ogra: hehe...who wants edgy iso's anyway.....
<Kamion> ogra: yeah, easy to fix
<Kamion> it's a quirk of the CD build system changes done in the dapper cycle
<ogra> i just noted that my rsync script fails ... it looks fo redgy :)
<Kamion> fixed
<Kamion> oh, hang on, you got ONLY dapper ISOs
<Hobbsee> seb128: Riddell:  assuming you're talking about the browser launchpad-integration opens with, there's a bug listed at https://launchpad.net/distros/ubuntu/+source/launchpad-integration/+bug/3810 and i added my comments to it
<Ubugtu> Malone bug 3810 in launchpad-integration "Launching "Get help online" from a browser should launch within that browser" [Medium,Confirmed]  
<Kamion> ogra: so, you know the way I asked you recently to check the build log before talking to me?
<Kamion> ogra: did you listen? :-P
<ogra> Kamion, i know that this livefs is broken ... but at some point i need something to rsync on
<ogra> else it'll take me days to download 
<Kamion> ogra: you need to rm -f ~/.ssh/known_hosts on lithium, because a lot of host keys have changed; and furthermore there was no livefs at all for lithium to fetch from any of the buildds
<Kamion> it's not so much broken as NOT THERE
<Kamion> at least not at the time of build
<ogra> hmm
<Kamion> it might be there now
* ogra removes the host keys
<Kamion> looks like it was a casualty of the livefs build bug that infinity and Mithrandir were discussing above.
<ogra> yep
<seb128> Hobbsee: I rather think he's speaking about lpi for KDE
<Hobbsee> seb128: huh?
<seb128> Hobbsee: what?
<Mithrandir> so, it appears that gnome-settings-daemon will fail to start if it takes more than 25 seconds.  Which can conceivably happen when you're booting a live cd.
<Hobbsee> seb128: were you originally referring to my comment about the bug report, said above?
<seb128> Hobbsee: no, replying to "assuming you're talking about the browse"
<Hobbsee> seb128: yeah, right.  the same thing as what i'm referring to.  i'm a KDE user...
<seb128> Hobbsee: let me phrase it again, "no we are not speaking about "open with"", but about launchpad-integration (apt-cache show launchpad-integration)
<Mithrandir> seb128: do you have any ideas what to do about the problem I'm talking about above or should we just ignore it?
<Hobbsee> seb128: ohh...sorry.  FYI, Riddell's just got a patch about fixing the "use the default browser" patch for kde...
<seb128> Mithrandir: the flicking menu one? not good to ignore, but if you commented on the bug with bt and log I didn't read it yet
<Mithrandir> seb128: no, the "I don't get my brown colours" one.
<Mithrandir> seb128: on the live cd.
<seb128> Hobbsee: I don't use about KDE and I didn't know he was not using the right browser ... for dapper only Ubuntu had lpi, I think the discussion is rather about getting the feature for kubuntu too no?
<seb128> Mithrandir: ah, the gnome-settings-daemon, did read enough backlog when coming back :p
<seb128> Mithrandir: does starting it by hand works fine?
<Hobbsee> seb128: unless i'm going totally mad, which is quite possible, it came into kubuntu edgy today.
<seb128> Hobbsee: ok, please stop trying to stop to that conversation, you seem to have better information than me, I don't use KDE
<Mithrandir> seb128: it's actually started automatically after the dialog complains about it not starting quickly enough.
<seb128> Hobbsee: if it landed to KDE it might be a discussion about having that code shipped with the previous launchpad-integration source package
<seb128> Mithrandir: weird, now gnome-session starts it over dbus ... I'm wondering if that could be a dbus issue
<seb128> Mithrandir: like the session bus starting late or something
<Mithrandir> seb128: it's a timeout.  The default dbus timeout is 25 seconds and I wouldn't be surprised if it could take more than that to start stuff when booting the live cd.
* Hobbsee disappears in a puff of very confused smoke.  I'm using kubuntu edgy, and the only problem so far is that it doesnt use the default browser.  Riddell's got a patch listed on LP against it, which fixes the issue.  That's all i'm trying to say, seb128 
<seb128> Hobbsee: so, no, that's not what we are speaking about to reply to your first question
<seb128> Hobbsee: I didn't know that kubuntu got lpi yet and I didn't know about that bug
<Hobbsee> seb128: okay, i'm sorry.
<seb128> np
* Hobbsee guessed, as Riddell said he was going to talk to you earlier about it.  i think i'll go and fix kaffeine.  i might win that battle :P
<seb128> Hobbsee: your comment to https://launchpad.net/distros/ubuntu/+source/launchpad-integration/+bug/3810 is confusing too
<Ubugtu> Malone bug 3810 in launchpad-integration "Launching "Get help online" from a browser should launch within that browser" [Medium,Confirmed]  
<seb128> Hobbsee: the bug is about "if you click on a lpi item from firefox, it opens a new window instead of loading the page to the window you used for the click"
<Hobbsee> seb128: okay, ignore my comment.
<seb128> Hobbsee: it's not about what app is started
<Hobbsee> oh shit, i'm really reading things wrong tonight.
<seb128> Mithrandir: is that happening with all the CDs atm? I would need to try ... maybe we can change the timeout as a workaround?
<dholbach> Robot101: i'll work with daf together to get it done and included in ubuntu
<Mithrandir> seb128: seems to be all CDs, yes, but it appears gnome-settings-daemon isn't the only problem.  The theme is just wrong too.
<Mithrandir> seb128: isn't "Human" supposed to be default?
<seb128> Mithrandir: without gnome-settings-daemon no theme is applied
<ogra> themes are overrated on alpha quality CDs
<seb128> Mithrandir: and yes, Human is supposed to be the default one
<Mithrandir> seb128: but gsd is running now and I still have the seagreen background.
<seb128> Mithrandir: the background is not part of the theme
<seb128> Mithrandir: are the GTK theme and icons correct?
<Mithrandir> seb128: the icons are wrong too; appears to be clearlooks.
<Mithrandir> almost, at least
<seb128> gconftool-2 --get /desktop/gnome/interface/gtk_theme ?
<seb128> gconftool-2 --get /desktop/gnome/interface/icon_theme ?
<Mithrandir> Clearlooks and gnome, respectively.
<seb128> right, same on my box
<Mithrandir> that's wrong, isn't it?
<seb128> looks loke the .gconf-defaults has been dropped when merging with Debian
<seb128> should I fix that now?
<seb128> that's a libgnome update
<Mithrandir> hmm, let me think a little.
<Mithrandir> what about the background?
<seb128> probably same reason
<Kamion> Mithrandir: partman's unhappy here, on a blank disk
<Mithrandir> even though artwork isn't crucial for an alpha, I think we should have it in place.
<Mithrandir> Kamion: alternate?
<seb128> Mithrandir: I think too
<Mithrandir> seb128: ok, go ahead and upload with fixed gconf-defaults.
* seb128 slaps dholbach
<seb128> dholbach: you did that merge :p
<seb128> Mithrandir: ok, fixing that now
<Mithrandir> seb128: thanks.
<infinity> Mithrandir: Okay, looks better now, you should be on track.  I'm off.
<seb128> np
<Kamion> Mithrandir: yeah
<Kamion> trying to track it down now
<Mithrandir> infinity: yay, thanks.  Sleep well, or whatever you're off to.
<Mithrandir> Kamion: any idea if it affects ubiquity?
<Kamion> Mithrandir: also, I have a gparted crash fix affecting XFS. Upload now or wait?
<Kamion> Mithrandir: no idea yet, will take a while to determine
<Mithrandir> Kamion: how big is the diff?
<Mithrandir> if it's small enough, upload.
<Mithrandir> if it's big, I'd like to at least eyeball it
<Kamion> -               output = output .substr( output .find( "fdblocks" ) ) ;
<Kamion> -               if ( sscanf( output .c_str(), "fdblocks = %Ld", &N ) != 1 )
<Kamion> +               index = output .find( "fdblocks" ) ;
<Kamion> +               if ( index >= output .length() ||
<Kamion> +                    sscanf( output .substr( index ) .c_str(), "fdblocks = %Ld", &N ) != 1 )
<Kamion> about that big
<Mithrandir> ew, evil C++ style.
<seb128> grrrraa
<Kamion> (the crash comes when output.find returns "not found" which is (size_t)-1 which when fed to substr() throws an exception
<Kamion> )
<seb128> dholbach dropped all the Ubuntu customizations to libgnome
<seb128> the sound events list too
<Mithrandir> Kamion: ah, just upload, then
<Kamion> Mithrandir: yeah, gparted isn't fun to hack on due to that style
<seb128> Mithrandir: I'm fixing the sounds event list with the same upload :p
<Mithrandir> seb128: please do.
<dholbach> seb128: sorry
<Mithrandir> seb128: that's less crucial, though.  I assume it's all just gconf defaults so it's safe anyway.
<seb128> dholbach: that's fine :)
<seb128> Mithrandir: no, it's not gconf, that's a file to etc but no issue with it
<Mithrandir> ogra: do you want a rebuild once we have the new libgnome in or are you overriding the themes etc anyway?
<ogra> Mithrandir, my themes on the 17.1 cd were fine ...
<ogra> but i havent tested 18.1 yet 
<Mithrandir> ogra: let's hope they still are, then. :-)
<ogra> :)
<ogra> but i dont really care to be honest ... its alpha ...
<Mithrandir> ogra: ok, that's your choice, obviously.
<ogra> oh, and we're tlaking about the liveCD, right ? i havent had any successfull build yet :)
<Mithrandir> ogra: yeah, live cd.  You manage your install cds yourself.
<ogra> so i guess i'll get it for free anyway ;)
<Mithrandir> not if the current livefs-es end up working
<Mithrandir> ogra: you don't care about sparc livecds, do you?
<Kamion> I never build sparc live CDs for Edubuntu
<Kamion> or live filesystems
<Kamion> for projects other than ubuntu|kubuntu|ubuntu-server, I just build on king, terranova, and royal
<ogra> Mithrandir, not really, but fabbione might get unhappy :)
<Mithrandir> Screw fabio. ;-P
<ogra> i cant, we share a room at the sprint ... i dont want to have pinhead in the other bed in the room :)
<fabbione> Mithrandir: tsk :P
* Mithrandir hugs fabbione
<fabbione> Mithrandir: we will work on sparc livefs sometimes after knot-1
<fabbione> Mithrandir: so just skip it for now
<Mithrandir> fabbione: yeah, I know.  No worries.
<fabbione> Mithrandir: perfect
<Mithrandir> fabbione: but I suspect you won't do an edubuntu livefs?
<Chipzz> something I wrote recently in case anyone cares: http://chipzz.studentenweb.org/pageant/
<Chipzz> feedback is welcome :)
<Chipzz> and yes it probably also needs a new name ;P
<fabbione> Mithrandir: as it stands i will be pleased to have ubuntu livecd working and if derivates want livecd, they will have to do it and test it
<Kamion> woo, bug comment ordering back to normal
<Kamion> ... or not
<Kamion> back to normal *sometimes*. how weird. :)
<Hobbsee> hehe
<Hobbsee> that's goign to drive me more insane, i think
* Kamion hopes that this partman breakage isn't the change in busybox semantics that he thinks it is ...
<Kamion> ah, no, just parted_devices returning nothing apparently
<Kamion> haha, I forgot to add disks to the vmware instance
<Kamion> ok, fixed the two bugs thusly exposed
<Kamion> no particular necessity to have them in knot-1 but I've tested them both anyway
<fabbione> Kamion: can you please add to the openais UVF exception reasons that it also fix a major failover/fencing loop bug?
<Kamion> ok
* Kamion rejects lots of bugs. It's very cathartic.
<fabbione> Kamion: thanks
<toma> '
<sharms2> I noticed a new patch for WPA and Prism54 drivers, I am guessing there is no way to get this into edgy, or is there some way I can make like a "module" package that I can include on a personal repository?
<slomo> are autosyncs from debian for universe still running or is this manual now?
<pitti> slomo: manual
<pitti> slomo: we don't autosync since UVF any more
<Kamion> sharms2: talk to the kernel maintainers
<bluefoxicy> I wish someone would write up wifi drivers for everything.
<Kamion> it should be possible to get new driver patches in at this point
<bluefoxicy> I hear freebsd has wifi drivers for a lot more than Linux, but nobody's announced effort to port yet; and porting quietly is kind of stupid, then you have 6 people doing duplicate work >/
<mjg59> ?
<mjg59> I don't think there are any cards supported in FreeBSD without having a Linux driver
<giftnudel_> maybe the support is better?
<mjg59> They're in the kernel, unlike Linux
<mjg59> Where they're scattered all over the place
<mjg59> But, to some extent, we support pretty much every wireless card available now
<sharms2> Kamion: the driver patch itself is very untested right now
<mjg59> sharms2: Push it to Ben, it'll probably get applied
<giftnudel_> there is a post on planet.gnome.org about it
<sharms2> yeah that is what I am referencing
<sharms2> what is ben's nick?
<giftnudel_> benc
<Kamion> Mithrandir: Ubuntu alternate i386 OK
<Kamion> apart from starting up without the Human theme of course
<Kamion> Mithrandir: Ubuntu desktop i386 also seems ok for me modulo the theme problem.
<Kamion> Mithrandir: I'd suggest not worrying about it too much. For the first milestone, "it sort of works, ship it" is OK ...
<gnomefreak> update-manager with the -d option should not upgrade to edgy yet right?
<Kamion> -d => development release, so I'd expect it to
<gnomefreak> Kamion: it hasnt worked yet so i figured maybe it wasnt configured to yet and now im seeing a bug on it
<Kamion> gnomefreak: perhaps mvo hasn't set it up yet
<Kamion> status way-too-damn-impatient
<Kamion> subscribe mvo to the bug, anyway
<gnomefreak> i dont think people should use edgy for normal use anyway
<gnomefreak> ok
<sladen> gnomefreak: correct.  Not yet
* gnomefreak been using it sice day one
<dholbach> i doubt he's going to set it up anytime soon (especially given that dapper is supported on the desktop for 3 years) :)
<gnomefreak> since*
<sladen> gnomefreak: okay, if you're willing to help with the testing, that's very much appreciated
<gnomefreak> sladen: always love testing
<gnomefreak> mvo = micheal vogel <<< that mvo
<dholbach> Michael VOGT
<gnomefreak> k
<gnomefreak> ok one down one to go
<gnomefreak> Tonio_: did hobbsee drop off kaffeine issue to you?
<Tonio_> gnomefreak: yes, I didn't upload the good package....
<gnomefreak> ok cool
<Tonio_> the new one is just beeing uploaded
<Tonio_> and this time it works
<gnomefreak> ;)
* gnomefreak spent a couple hours with her on that one :(
<Tonio_> gnomefreak: you cannot imagin how stupid it is....
<gnomefreak> its the .la files
<Tonio_> I simply uploaded a package without kaffeine-xine.install file :)
<gnomefreak> omg
<gnomefreak> it happens
<sladen> gnomefreak: if you're wondering, dholbach is mvo's favourate fanboy :)
<zul> dholbach: where is the fun in that on not running edgy
<Tonio_> sometimes yes ;)
<gnomefreak> :)
<Tonio_> new gwenview is beeing uploaded actually too :)
<Tonio_> Riddell: ping ?
<Riddell> Tonio_: hi
<Tonio_> hey Riddell
<Tonio_> Riddell: raphink suggests me to ask toonight at TB concerning coredev (he looks borded uploading my packages ^^)
<Tonio_> isn't that a bit late to ask ?
<raphink> haha
<raphink> Tonio_: I really think you can go for it
<Riddell> Tonio_: do it
<Riddell> make sure your wiki page is up to date of course
<Tonio_> Riddell: okay, I'l try at least
<Tonio_> Riddell: it won't, I have so many things to do on it...
<Tonio_> or maybe if I go right now....
<raphink> the TB is in 2 hours and a half
<Tonio_> okay I can do it... let's go
<Riddell> Tonio_: find some example packages you can use to show your leet skills
<Tonio_> Riddell: yes, I know the good examples (kds and knetworkmanager for example
<Tonio_> and the bunch of patches I did for kdebase too
<Toadstool> Kamion: hi, Gloubiboulga_ will confirm the gnome-sudoku sync as soon as he gets back to his computer ;)
<pitti> fabbione, infinity: OO.o2 breezy-security build on vivies (sparc) failed due to 'no space left' :(
<^robertj> heya all, where do packages go after they are synced? do they not show in launchpad until they are autobuilt?
<pitti> Kamion: can you check whether vmware-player kernel modules for dapper-security are still in NEW?
<Kamion> ^robertj: new packages land in the new queue
<Kamion> pitti: have to go out now, remind me when I'm next around?
<bluefoxicy> should I file a bug if I can hit system->administration->time and date; hit the checkbox for automatic synchronization of time; and it says to install NTP support
<bluefoxicy> so I install ntp, ntp-simple, and ntp-server, and it doesn't fix it... that's a bug, right?
<mjg59> bluefoxicy: That depends. Did you install ntpdate?
<bluefoxicy> (yes I'm busy going through the 40 clicks it takes to get into launchpad)
<bluefoxicy> mjg59:  ntpdate can't be removed without removing ubuntu-minimal, so yes it was already installed.
<mjg59> Then yes, it's probably a bug
<bluefoxicy> oh
<bluefoxicy> there's no /etc/init.d/ntpdate either, or ntpanything for that matter until ntpserver is installed... that probably the problem?
<bluefoxicy> (edgy...)
<mjg59> Dunno
<bluefoxicy> filing.. https://launchpad.net/distros/ubuntu/+bug/38610 looks like breakage in dapper but has a work-around, not working for me.  Should I file a separate bug or note the problem is even worse in edgy on same bug?
<Ubugtu> Malone bug 38610 in Ubuntu "Time: no synchronise option" [Medium,Unconfirmed]  
<Riddell> Kamion: patch for ubiquity at https://launchpad.net/distros/ubuntu/+source/ubiquity/+bug/53367
<Ubugtu> Malone bug 53367 in ubiquity "Ubiquity crash (Edgy)" [Untriaged,Confirmed]  
<pitti> Kamion: sure
<Riddell> Kamion: I'm getting "raise InstallStepError("HwDetect failed with code %d" % code)" when installing with ubiquity 1.1.0
<bluefoxicy> re https://wiki.ubuntu.com/IntegratedDesktopSearch has anyone packaged Tracker yet or is working on it?
<slomo> afaik no (for both questions)
<bluefoxicy> the upstream author has some debs, I wonder if I could get his source packages
<bluefoxicy> nautilus tracker integration gets a separate package, so I'd assume there's some nautilus debian/ directory hacks going on in that
<LaserJock> or maybe the author is using checkinstall ;-)
<slomo> and patching of the nautilus source probably... but just ask him for the source packages ;)
<bluefoxicy> AFAIK there's no patch to nautilus itself, it's got tracker code right in the official source tree, activates it if tracker is around
<bluefoxicy> slomo:  nautilus since some version should have it.
<bluefoxicy> "Once you have installed Tracker and have some indexed contents, you should now compile Nautilus (ver 2.13.4 or higher) which should auto detect that tracker is installed and automatically compile in tracker support."
<LaserJock> but it still requires recompiling after tracker is installed?
<slomo> seems like it
<LaserJock> that's going to be interesting
<bluefoxicy> LaserJock:  he has a deb for tracker integration into nautilus.  I assume that this would mean 1) tracker (and a lib tracker depends on that's currently in universe) goes into main; 2) nautilus gets a build-dep on tracker-dev; 3) we emit an extra nautilus package.
<slomo> would mean that we would need to get tracker into main to get nautilus support for it... and as we don't have packages for it anywhere and nobody is working on it i doubt that we get this for edgy
<bluefoxicy> that being a nautilus plug-in probably.
<slomo> and i also doubt that tracker is already ready for wide use but well :) we have to see
<bluefoxicy> it doesn't matter with edgy as much, as long as it works right?  IIRC tracker doesn't have the ability to autoparse as much meta-data as things like beagle, namely e-mail and IM logs.
<bluefoxicy> aside from that I've heard it's pretty stable
<bluefoxicy> "The very energetic move would be for Ubuntu/Canonical to sponsor Jamie to work on Tracker. This would be a move that would position Ubuntu/Canonical has bleeding edge technology contributors to the free desktop along side Novell and Red Hat."  <-- very nice but keep dreaming, moving corporate money around means getting corporate big-shots VERY interested
<bluefoxicy> I would imagine that would happen if sabdfl was a hard-core tracker fan :P
<bluefoxicy> otherwise no
* bluefoxicy is reading the comments on https://wiki.ubuntu.com/IntegratedDesktopSearch btw.
<bluefoxicy> slomo:  there's been buzz here and there about beagle/tracker/glscube on ubuntu-users@ and ubuntu-devel@ too, might be more information about whether it breaks/works/is lacking things/etc
<tseng> bluefoxicy: there is buzz about tracker everywhere
<tseng> bluefoxicy: alot of it is based on features that arent built yet, certainly not the same level as beagle
<mdke> gotta love buzz
<tseng> pretty tiring
<slomo> bluefoxicy: i don't really care about such stuff :) but from what i heard tracker is just not there yet and i don't see a good reason to reimplement the wheel instead of improving beagle here... seems mostly be caused by "C is much faster"...
<bluefoxicy> tseng:  nods, I noticed that too.  "tracker will eventually be able to index .desktop files for gnome" is silly.
<slomo> hmm... "for gnome"? isn't xfce using .desktop files and kde in the future too?
<bluefoxicy> slomo:  Tracker is much faster, I hear, they just attribute it to C (possibly properly, possibly not, that's not the issue).  I also hear it uses much less memory.  Mine has 8.2 megs resident.
<tseng> things with less features often use less memory
<bluefoxicy> yeah
<bluefoxicy> tseng:  for me there's also the issue that I've never actually seen beagle live up to any of its claims at all.
<tseng> lets not get caught up with what tracker might or might not be
<bluefoxicy> tseng:  in fact, the most I've seen beagle do is crash :P
<tseng> bluefoxicy: i havent crashed it in months.
<mjg59> bluefoxicy: Ah, but by the same token I've never even seen Tracker start up correctly
<slomo> bluefoxicy: are there bug reports for the crashes? it doesn't crash for me (but likes to use much ram sometimes :) )
<mjg59> (I've never seen it start up incorrectly either, but that's not the point)
<bluefoxicy> mjg59: I got trackerd loaded, just nothing to use to do a search.  It'd be nice if he had a stand-alone search UI >:|
<mjg59> Beagle works fine here, but, well.
<mjg59> The plural of "anecdote" is not "data"
<tseng> you should post that to ddl
<tseng> next to a comment about phallic objects
<bluefoxicy> tseng:  i'm most interested in that tracker is apparently integrated with gnome tbh, and that it's not mono.  Both of those.  On equal ground.
<Burgwork> mjg59, damn we need a quote engine. That was good
<mjg59> Burgwork: Not original, I'm afraid
<tseng> Burgwork: havent you run into mjg59 in person?
<mjg59> Results 1 - 10 of about 61,400 for "plural of anecdote".
<bluefoxicy> or well, integrated with nautilus mainline.
<Burgwork> tseng, I have never met the person
<tseng> Burgwork: its one a minute
<tseng> ah, thats too bad
<mjg59> "Not mono" isn't a selling point
<mjg59> "Well integrated" is
<tseng> beagle is integrated in mainline, and a few other places, more in SLED
<tseng> (mainline nautilus)
<bluefoxicy> mjg59:  "not afflicted with the overhead of loading a virtual machine into memory and having its executable pages actually require physical RAM for each individual instance of the process because runtime generated code cannot be mmap()'d and shared" then.
<tseng> tracker cant index muhc of anything, and isnt integrated anywhere
<tseng> which would be fine if people werent trying so hard to sell it
<bluefoxicy> tseng:  interesting.
<mjg59> When tracker is feature-comparable with Beagle, we'll worry about things
<bluefoxicy> Is it possible to use both, but not make it mandatory?
<mjg59> What /would/ be worthwhile would be cooperation between the two projects on defining an interface for querying indexing systems
<zul> ./unignore bluefoxicy
<bluefoxicy> i.e. have integration packages for Nautilus+Tracker/Beagle?
<tseng> zul: not worth it.
<bluefoxicy> mjg59:  or that.
<mjg59> So applications don't have to care
<slomo> bluefoxicy: hm, mono is using much shared memory... not sure whether this is for code too ;)
<tseng> in beagle especially i hear from alot of people they just stopped using it instead of filing bugs or doing anything at all proactive
<tseng> "plugged in" people who know better
<slomo> well, i stopped using it because it always ran in the background but i never actually used it :P
* mjg59 wonders what DAEMON_RADAR_DETECT means
<LaserJock> well, tracker would make a great Universe package if the nautilus recompiling thing was worked out
* bluefoxicy gets beagled running and tries to figure out how to call up a UI
<slomo> LaserJock: i don't think that is possible
<LaserJock> slomo: that's a pretty serious deficiency then, IMO
<bluefoxicy> http://rafb.net/paste/results/7ffomk32.html  so much for that
<slomo> LaserJock: why? it integrates very tightly into nautilus afaik... same as beagle does
* bluefoxicy didn't even find a ui... beagled vanished, beagled-helper replaced it.
<slomo> bluefoxicy: dapper or edgy?
<LaserJock> slomo: if users have to recompile Nautilus just to use the thing ...
<slomo> bluefoxicy: edgy obviously... ok, i think there is a problem with evolution-sharp right now because of the changed e-d-s API/ABI... should work fine with the evolution stuff disabled (i.e. removing beagle-evolution or how the package was called) until we fixed that ;)
<mjg59> eds appears broken there
<slomo> bluefoxicy: could you please a bug for this (well, look whether there already is one) and assign it to me? i'll look at it when i find some time for it
* ..[topic/#ubuntu-devel:Keybuk] : 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 | http://wiki.ubuntu.com/HelpingWithBugs | Knot-1 freeze in effect - uploads to main frozen, ask Mithrandir for exceptions
<toma> fabbione: ping
<bluefoxicy> slomo:  edgy but I've done it with dapper without evolution, normally it spits out memory addresses
* bluefoxicy tries removing that.
<slomo> bluefoxicy: and then start beagled --fg --debug
<slomo> bluefoxicy: then beagle-search for searching for example... but the wrapper script is broken too right now ;) just change sh to bash in the first line of it...
<bluefoxicy> I thought beagle had a pretty GUI
<slomo> beagle-search is a pretty gui :P
<bluefoxicy> bug 53337
<Ubugtu> Malone bug 53337 in gedit "gedit crashes X on large xml file" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/53337
<bluefoxicy> slomo:  interesting.
<slomo> bluefoxicy: why?
<Hobbsee> morning all!
<gnomefreak> morning Hobbsee 
<bluefoxicy> slomo:  beagled is running, it's indexed ~/writing/ fully, or so I think.. I searched for 'linker' (optimizing linker load times, the article I'm writing for LWN right now), nothing found.
<bluefoxicy> Debug: Parsed query 'linker' as text_query
<tseng> how long has it been running?
<slomo> tseng: ~2 minutes at most :P
<tseng> im guessing you just started it, as you claimed before you never saw it do anything but crash
<tseng> yeah.
<bluefoxicy> tseng:  it ran for a couple minutes before it crashed last time, I figured it had to get somewhere.
<tseng> eh
<tseng> it starts at the begining
<bluefoxicy> but the --debug output isn't saying "I'm indexing files"
<tseng> every time
<tseng> it uses xattr to know where its already been
<bluefoxicy> ..... oh.  Maybe it doesn't tell me what it's doing.
<tseng> you run beagled --fg --debug
<bluefoxicy> yeah I did
<tseng> then it tells you.
<bluefoxicy> <slomo> bluefoxicy: and then start beagled --fg --debug
<slomo> tseng: what was the env variable to force indexing?
<tseng> EXERCISE_THE_DOG=1
<slomo> that's what he needs right now to get everything indexed as fast as possible and not only in the background :P
<tseng> turns off the friendlier scheduling
<bluefoxicy> what the jesus.  It just started indexing things.  It's indexing web sites!
<tseng> from rss? or from firefox plugin
<bluefoxicy> oh THAT explains it, it found an rss feed.
<tseng> yes.
* bluefoxicy hasn't used liferea in eternity.
<tseng> it reads blam/lifrea feeds
<slomo> tseng: it indexes epiphany cache/bookmarks too, right?
<tseng> I have to say this is getting pretty far off topic
<tseng> slomo: i think you need to build-dep on ephy and build a plugin for that
<slomo> tseng: sounds like something we want to do then ;)
<tseng> yes
<slomo> ok... so we have the following for beagle: wv1/gsf-sharp to main, epiphany build-depends, evolution-sharp fixing for the new API/ABI ;) will you do it?
<tseng> evo-sharp api? no thanks :)
<tseng> where is lukas :)
<slomo> ok, i'll do it then ;) i hope it's only soname changing...
<Kamion> Riddell: applied, thanks
<Kamion> Riddell: well, then, hw-detect is failing :) /var/log/syslog may say why
<bluefoxicy> Hey I bet I can search for "new vulnerabilities" with this thing, it'll probably return loads of old stuff from bugtraq and cert
* bluefoxicy is really, really bored.  Needs to find something else to do besides make bad jokes in #-devel.
<Hobbsee> hi pitti 
<toma> Hobbsee: can you upload already?
<Hobbsee> toma: no idea, havent tried yet.  in truth, i dont have any uploads for universe this second, i've been workign on main.
<tseng> slomo: good luck
<Hobbsee> toma: i might have to bug ogra to upload or something, after this knot 1 freeze stops
<slomo> tseng: thanks :P
<toma> Hobbsee: time for cake!
<Keybuk> should be able to
<Keybuk> as far as I know, as soon as I click the approve button, you can upload
<Hobbsee> toma: hehe, it's a little too early for that still.  but this is an early birthday present
<Hobbsee> Keybuk: thanks :)
* Hobbsee just needs something to upload for universe :P
<Kamion> Hobbsee: knot-1 freeze is really just main/restricted; don't worry about it for universe
<Keybuk> clicked I should say
<Kamion> oh, but reading more closely, I think you knew that
<bluefoxicy> crud, it doesn't spit out a plug-in, it just gets bulit in.  *kicks tracker*
<ogra> Kamion, so is there another ubiqity uplad planned ? 
<Hobbsee> Kamion: yeah, but i've got uploads for main :P
<ogra> *upload
<Kamion> ogra: probably, given the kde frontend breakage. why?
<ogra> i just iscovered it doesnt suffice what i did to te udeb ... i'll need the full change you gave me for it ... so i'd either wait until ubuntu is done and i dont put anything in danger or i have the luck that you do another uplad 
<ogra> *the
* ogra looks at his keyboard if all these keys are really missing ...
<Hobbsee> ogra: hehe.  i ate them.
<ogra> heh
<Hobbsee> ogra: i was hungry!  what's the problem?
<ogra> with yur first coffee i guess ;)
<ogra> add an o where appropriate
<Hobbsee> The status of your membership on team "ubuntu-dev" (Ubuntu Development Team)
<Hobbsee> was changed from Proposed to Approved.
<Hobbsee> yay, thanks Keybuk 
<Kamion> ogra: well, ubiquity changes only need a desktop CD rebuild, and ltsp changes only need an alternate CD rebuild
<Kamion> ogra: so they're sort of independent really
* Hobbsee doesnt drink coffee.
* Kamion prods hopefully at ubiquity
<ogra> hmm, kay
<Kamion> and ltsp changes would only need an edubuntu install CD rebuild at that, so they're pretty safe
<Mithrandir> Kamion: sorry, I've been out laying the foundation for a new fence in our yard.  Have you had a chance of testing ppc too, by any chance?
* Hobbsee watches ubiquity roll over and play dead for Kamion.
<ogra> Kamion, well, th eltsp-server(-standalone) packages are in ubuntu as well, but indeed the udeb changes wont affect ubuntu
<Kamion> Mithrandir: no, still haven't got a new CD drive
<Kamion> to be honest I wouldn't worry much about powerpc
<ogra> edubuntu ppc worked fine apart from the ltsp udeb breakage
<Kamion> the Kubuntu desktop CD breakage is a bit more annoying though
<ogra> i just tested it 
<Kamion> ogra: cool, thanks
<Hobbsee> Kamion: how'd it break?  i seemed to have missed that bit
<ogra> edubuntu workstation worked completely 
<Kamion> Hobbsee: bug 53367
<ogra> (on ppc)
<Ubugtu> Malone bug 53367 in ubiquity "Ubiquity crash (Edgy)" [Untriaged,Fix committed]  http://launchpad.net/bugs/53367
<Kamion> I don't know the exact circumstances; may not have been for everyone
<toma> nasty questions to answer before you can become a motu
<ogra> Mithrandir, so given the discussion above, are you ok with an upload of ltsp (doesnt affect ubuntu)
<Hobbsee> Kamion: ah.
* Hobbsee just used dist-upgrade
<Mithrandir> ogra: you're free to change packages which only touch edubuntu, yes.
<ogra> thanks 
<toma> Hobbsee: what's the diff between ubuntu-dev and core-dev?
<Hobbsee> toma: ubuntu-dev is universe, core is main
<toma> oki
<mhb> hello everyone, how are the Knot CDs?
<ogra> knotted
<mhb> ogra: smart answer :o)
<mhb> ogra: any wiki page or something like that where I can read more about them?
<Kamion> it's not really that organised
<mhb> (the first one, I mean, of course)
<Kamion> we're slamming all the bits together until they stick, right now
<ogra> there will be an announcement that outlines the worst known bugs ...
<ogra> apart from that its alpha software 
<Zomb> hi
<Zomb> stupid question
<Hobbsee> Kamion: "bang the rocks together guys!"  heh.  glad to see you have such confidence
<Zomb> WTF is loading the ipv6 module all the time?
<Zomb> there is even "alias ipv6 off" in modprobe.d/aliases
<ogra> Zomb, see topic ... please go to #ubuntu for support 
<Zomb> ok
<Hobbsee> Zomb: otherwise ogra will get in his miniskirt and pompoms again, and cheer you, telling you to go away :P
<Zomb> though I doubt they will know it better
<Kamion> I suppose you could try 'blacklist ipv6' in /etc/modprobe.d/blacklist
<ogra> Hobbsee, haha, honestly that can scare peope ask elmo about paris :)
<BenC> anyone here able to reproduce a crash easily in edgy (or better yet, have a crash that only happens in X, where the backtrace cannot be seen)?
<Zomb> Kamion: that is what I did and rebooting now
<Hobbsee> ogra: hehe....do tell.....
<BenC> a kernel crash that is
<Hobbsee> BenC: er, what?  I've never managed to get a kernel crash.
<BenC> I don't care if firefox bombs on your favorite porn site :)
<BenC> Hobbsee: then you cannot help me :)
<BenC> I need guinea pigs for kexec/kdump
<Hobbsee> BenC: yeah, unless you can tell me a way to make it crash, and i can try it out for you :P
<Hobbsee> BenC: i warn you, my brain istn really here yet.
<Hobbsee> BenC: give it a few hours :P
* gnomefreak would be guinea pig if i had a clue what you wanted :(
<BenC> what I want is someone who is experiencing a reasonable consistent crash in edgy's kernel
<gnomefreak> i havent had kernel crash yet in edgy 
<BenC> so that the person can run the new kexec/kdump kernel set and see if they can get it to work, and capture the crash
<gnomefreak> just the booting issues
<Hobbsee> BenC: you didnt make the thing buggy enough that we could crash it!  :P
<BenC> well I'm glad everything is so perfect for you ppl :P
<gnomefreak> :)
<Zomb> Kamion: did not help
<BenC> I don't have any crashes either, I'm just forcing them with Alt+SysRQ+c
<Zomb> oh, no, it did somehow
<Kamion> Zomb: ok, sorry, I'm no expert on this, was just an educated guess
<Zomb> now there are other problems
<Kamion> er semi-educated
<Zomb> thanks, however
<Kamion> there may be something that's doing modprobe without the -b option
<Kamion> Mithrandir: ok, I'm doing another ubiquity upload for KDE
<Kamion> you can ignore it for Ubuntu if you like
<Kamion> though I wouldn't complain if it got in :)
<BenC> acpi does modprobe without -b, or at least it used to
<Kamion> (makes the consequences of {g,qt}parted falling over in a heap much less bad)
<Mithrandir> Kamion: ok, I'll do livefs builds in the morning, then full testing, then release.  I'm tired of waiting. :-)
<Kamion> absolutely
<Kamion> ok, that's ubiquity uploaded
<Kamion> night all
<ogra> snight Kamion, thanks for all the help again :)
<Hobbsee> night Kamion 
<Riddell> pitti: what's wrong with the soname/package name of libpth?
<ogra> you cant pronounce it if you are german ? 
<Riddell> ah, version number
<pitti> Riddell: soname 20 vs. package name 2 (IIRC)
<Hobbsee> ogra: i cant either.  but ubuntu stuff loves unpronouncable names, so it's all good.
<ogra> heh
* toma tries unpronouncable ten times in row..
<ogra> toma, better try libpth
<ogra> but with a german accent :)
<Hobbsee> ogra: i had to actually learn to say ubuntu and kubuntu when ajmitch was over here, and so we were out talking about it, and then for the podcast.
<ogra> hehe
<micahcowan> what, is there a trick to it?
<Hobbsee> ogra: i've refused to do more podcasts ever since :P
<HiddenWolf> oeboentoe? :P
<Hobbsee> hehe
<pitti> ogra: unpronouncible???? try libchipcard2-libgwenhywfar38-plugins :)
<ogra> loool
* StevenK still needs to hear this podcast that Hobbsee's in.
<Riddell> Hobbsee: what happened to that podcast?
* Hobbsee works her way thru pitti's satement
<tseng> try alan cox's blog
<pitti> that sounds so Welsh :)
<Hobbsee> Riddell: i think it's still sitting on jdub's hardrive
<Hobbsee> StevenK: you've heard me in person, why do you need a podcast?
<tseng> Hobbsee podcast?
<tseng> woo
<Hobbsee> tseng: yeah, jdub made ajmitch and myself do one before we could leave.
<tseng> oh
<tseng> ajmitch podcast!
<Hobbsee> and i was stuck against the wall, so had to do it :P
<StevenK> Hobbsee: *shrug* because you're embarrased about it? :-P
<Hobbsee> StevenK: yes.  why wouldnt i be?
<tseng> hah
<ogra> Hobbsee, why should you ? 
<Hobbsee> StevenK: it's just one more obvious indication that i'm different from anyone else.  why should i want that?
<Hobbsee> ogra: ^
<Hobbsee> and it tends to bring more attention, and i really dont like giving out death stares.
<StevenK> Sure you do!
<Hobbsee> heh
* Hobbsee makes a mental note to give StevenK a death stare the next time she sees him
* StevenK may return it.
<Hobbsee> heh
<Hobbsee> StevenK: no, no, death stares are only reserved for very special people.
<StevenK> Aww
<Hobbsee> StevenK: dont you have to be at work by now?
<StevenK> Nope.
<StevenK> I start at 9.
<Hobbsee> StevenK: oh nice.
#ubuntu-devel 2006-07-19
<Fujitsu> lamont, are you around?
<Hobbsee> Fujitsu: you're looking to take a merge?
<Fujitsu> Hobbsee, I'm looking to have apt-watch rebuilt on ia64.
<Fujitsu> And lamont is the only buildd-admin around.
<Hobbsee> Fujitsu: ah
<infinity> Fujitsu: No he's not.
<Fujitsu> Ah.
<Fujitsu> I would have asked you, infinity, but you're apparently away...
<infinity> Yes, well.  I spend most of the day at my keyboard wiht my IRC client claiming I'm away.  Lamont spends mods of the day AFK with his IRC client claiming he's around. :)
<infinity> Anyhow, not sure what you want done about apt-build.  It's built on all arches...
<infinity> Err, apt-watch, not apt-build.  I need to learn to read.
<infinity> Morning.
<zul> well...the sarcasm is dripping
* infinity looks at the right package.
<Fujitsu> infinity, good.
<infinity> Fujitsu: built.
<Fujitsu> Thanks.
<Fujitsu> And then there's the fact that hwinfo hasn't ever built on sparc... But that's due to missing kernel headers, and is long-standing.
<Riddell> Kamion: any ideas on this welcome https://launchpad.net/distros/ubuntu/+source/ubiquity/+bug/53400
<Ubugtu> Malone bug 53400 in ubiquity "kubuntu ubiquity crashes on hw-detect" [Untriaged,Unconfirmed]  
<solid_liq> anyone know where I can get a textfile list of ubuntu/kubuntu mirrors?
<fabbione> toma: pong
<solid_liq> anyone know where I can get a textfile list of ubuntu/kubuntu mirrors?
<crimsun> solid_liq: https://wiki.ubuntu.com/Archive
<solid_liq> crimsun: thank you
<solid_liq> crimsun: no, I meant a textfile list
<solid_liq> crimsun: I'm writing a script to automatically install all desirable software for a well configured desktop system, and I'd like it to use apt-spy to setup the sources.list as well.  I want it to be painless for someone who's never used linux before
<solid_liq> anyone know where I can get a textfile list of ubuntu/kubuntu mirrors?
<Kamion> I think the wiki page is the best there is, to be honest. In the installer we just use $COUNTRYCODE.archive.ubuntu.com
<pitti> Good morning
<Kamion> (so we haven't had the strong need to have a machine-readable list)
<pitti> Kamion: good mornign
<Kamion> I believe our sysadmin who handles mirror issues has some kind of machine-readable list but I don't know if he's ever exported it anywhere
<Kamion> morning
<pitti> Kamion: can I remind you of NEWing the vmware-kernel modules for dapper?
<solid_liq> Kamion: do you know if there's any way I could get ahold of it?
<Kamion> pitti: thank you, I was just about to ask you to remind me of whatever it was I'd asked you to remind me of. :-)
<Kamion> solid_liq: ask Znarl when he's around
<pitti> Kamion: heh :)
<solid_liq> Kamion: or that he could be talked into exportin
<solid_liq> k
<solid_liq> thaks
<solid_liq> s/thaks/thanks/
<dholbach> good morning - HAPPY HUGDAY to everybody!
<solid_liq> pitti: that reminds me, is there any way we could get vmware-tools apt-get installable?
<pitti> solid_liq: no idea, I have never ever used vmware, what's the problem with that package?
<solid_liq> pitti: you need to install vmware-tools in an OS that's running in a virtual machine, or you get severly degraded video performance and network performance isn't so great
<Kamion> pitti: hmph, somebody newed stuff incautiously last time
<Kamion> vmware-player-kernel-modules-2.6.15-25 | 2.6.15.10-7 | dapper-security/restricted | amd64, i386
<Kamion> (should be multiverse)
<Kamion> fixed, I think
<pitti> thanks
<solid_liq> vmware-tools is located in a .iso in the vmware-server package, so you have to d/l that, extract the gzip'd tarball, then loopback mount the iso, copy the .tar.gz off, extract that, and finally install.  It's a pain
<solid_liq> d/l it into the vmware client that is
<Kamion> pitti: done
<sivang> morning
<Burgundavia> morning sivang
<sivang> hey Burgundavia 
* sivang is glad to see the SATA-PATA bridge bug was fixed in -5-686
<infinity> Yes, booting is nice.
<sivang> infinity: my thought exactly :-D
<infinity> I'd been running a dapper kernel until yesterday.
<sivang> hehe
<sivang> was same here :)
<Fujitsu> sivang, which bug is that?
<infinity> The "BenC hates Thinkpad T43s" bug.
<infinity> (And other SATA-PATA bridged machines)
<infinity> pitti: Who do I whine at about hal/g-p-m bugs?  You, or dholbach?
<dholbach> infinity: not me
<pitti> infinity: I have zero knowledge about gpm, hal should be fine
<infinity> dholbach: So, you then? :)
<dholbach> infinity: mjg59, Kinnison, ogra and pitti worked on it, afaik.
<pitti> grrr@ my ISP, I'm a thin modem wire away from being offline
<infinity> dholbach: Kinnison's a non-option.
<infinity> pitti: g-p-m gets battery info from hal, yes?
<ogra> infinity, whine at me 
<ogra> :)
<pitti> infinity: yes
<fabbione> hey guys
<dholbach> infinity: i'm quite sure it's fixed in the merge/update that ogra has been preparing
<fabbione> i found something fantastic
<fabbione> http://www.openpegasus.org/
<fabbione> is there anybody that would like to package it for me?
<infinity> ogra: Oh, if this is a known bug (that g-p-m is COMPLETELY LYING about both my battery's charge level, and the state of my AC plug), then I'll just shut up.  I couldn't find the bug.
<ogra> yes it works on 2.15 ... but thats waiting for new hal which is waitng for the knot lock 
<simira> fabbione: sure, if you can teach me how ;p
<fabbione> simira: that's the whole point :)
<Kamion> fabbione: that web site is distressingly unclear about "so what the hell is it?"
<Kamion> to somebody who does not know the acronyms
<ogra> heh, i thought the same 
<fabbione> Kamion: sssshhhh!!!! 
<infinity> Kamion: It's a solution for leveraging open synergy.
<fabbione> Kamion: don't tell everybody! that's the whole point.. somebody might need it as much as i do!
<fabbione> Kamion: since conga B-D on it for about 2 headers
<fabbione> Kamion: conga being another package i want to outsource.. i know exactly what it does, but it has C++, zope, python, dbus, rpm and snmp stsuff all in one...
<Kamion> fully buzzword-compliant
<fabbione> Kamion: conga is the new redhat cluster *web* management system
<fabbione> you install ricci on the clients and luci on the server
<fabbione> and you can automatically make coffee across all cluster nodes
<Kamion> and a katie-style naming scheme to boot! bonus
<infinity> Clustered coffee sounds like a bad idea.
<infinity> s/bad/very bad/, no less.
<infinity> Also, not knowing how much battery you have left is very disconcerting...
<infinity> Oh, spiff, the battstat applet works just fine.  I'll just add one of those while I wait for g-p-m to stop sucking.
<pitti> infinity: erm, you mean there was no battery inside? :)
<infinity> pitti: s/how much battery/how much battery life/ ... Also, ":P"
<seb128> infinity: what about fixing g-p-m? :)
<fabbione> seb128: iz gtk bugz
<infinity> seb128: Apparently, ogra's working on a big merge that covers this bug, not about to duplicate the effort.
<seb128> infinity: not sure if that covers the bug, but new g-p-m is likely to take some time since apparently it requires policekit from hal CVS which is not packaged yet and doesn't make pitti that happy
<ogra> infinity, seb128 i havent seen new g-p-m with the new hal yet (due to lack of new hal in ubuntu) 
<seb128> infinity: it would be nice to get the bug fixed with current version if it takes weeks to do that
<seb128> especially that some GNOME upstream people complain to me several times about it
<seb128> and we would like to keep those people using Ubuntu :p
<infinity> seb128: Sure, now you're just trying to sucker me into fixing GNOME bugs.  I see how it is.
* pitti is swamped with non-hal stuff ATM, I wouldn't count on new hal in the next days
<seb128> hum
<seb128> I'm not subtle enough apparently ;) 
* infinity considers it.
* seb128 hugs pitti, no problem :)
* dholbach adds infinity to desktop-bugs :-)
<infinity> I'll need to dig a bit and figure out where the heck it's getting this info FROM.
<ogra> Kamion, Mithrandir, powerpc live is ok so far, but usplash dies half way in the shutdown process and the machine doesnt shut down after pressing enter
<infinity> Cause it doesn't match /proc/acpi... And it doesn't match hal (which matches /proc)
<ogra> apart from that its a go
<infinity> It's a complete fabrication.  Woo.
<seb128> infinity: afaik gnome-power-manager didn't change since dapper ... so something in the stack changed
<seb128> infinity: I think it get the info from hal
<infinity> seb128: I thought that too, but lshal has the correct info, and g-p-m is on crack.
<infinity> seb128: Anyhow, I'll poke later if bored.
<dholbach> i think the gnome-applets battery applet gets sane info
<ogra> infinity, let me upload the 2.15 source for you to rookery
<infinity> dholbach: Yes, the applet is correct.
<infinity> dholbach: I added one as a stop-gap for now. :)
<seb128> maybe we could lazily ping the g-p-m upstream about the issue, he might now about it and what to do to get it fixed :)
<dholbach> he'll say it's fixed with new hal and new gpm
<dholbach> :-p
<infinity> Probably, yes.  Pinging people about bugs in old releases of their software tends to make them cringe.
<ogra> sure, thats his standard answer :)
<Kamion> ogra: ok, just make sure a bug is filed; I think we can tolerate that for knot-1
<seb128> dholbach: you basically say upstream would not be happy to give some help, sucker
<ogra> you will have probs pinging him anyway
<ogra> he'
<ogra> s moving houses
<dholbach> seb128: no, that's not what I said
<pitti> infinity: 'old releases'? they are talking about cvs head of hal, with a not-yet decided policy backend
<ogra> and is on mobile dialup
<pitti> infinity: 0.5.7 is still the latest release :(
<infinity> pitti: If you're not living in HEAD, you're not l33t.  You've been in the free software world long enough to know THAT.
<seb128> dholbach: it looked like upstream made some effort to include Ubuntu patches and accomodate it to work fine for dapper by example ... no reason he would not reply to that if he knows what is breaking it
<seb128> pitti: that's not edgy enough :p
<pitti> infinity: :) (it's not the HEADness that worries me, but the crackfulness of this PolicyShit^H^H^H^HKit
<ogra> seb128, you are both right :) hughsie includes what he can but his standard answer is actually "that needs new hal" ;)
<infinity> HEADness.  Heh.  Not HEADitude?  Or maybe HEADosity.
<dholbach> seb128: ok ok ok - i  hughsie - better now? ;)
<seb128> is that going an another "we don't like upstream and are going to make it differently and rewriting half of the world"? :)
<pitti> seb128: I hope not
<seb128> dholbach: if he still refuses to reply to a simple question, not really :p
<seb128> pitti: it looks like your opinion is "policykit is crap", which basically means "I would prefer not use it" ... where everybody else is going for it apparently
<pitti> seb128: however, the Sun people (Artem Kachitchkin) want to replace this system policy daemon with something less crackful, I hope that they'll come up with something
<seb128> ah, you are not alone ranting on that one, good :)
<pitti> seb128: anyway, I'll take a look and play with it, before I cannot really have a definitive yes or no
<pitti> seb128: I just need some time for this
<seb128> yeah, I totally understand that
<seb128> anyway, enough discussions, better to get work done :)
<seb128> today is bug day :)
<Kamion> speaking of ...
* Kamion dives into #47859
<ogra> infinity, http://people.ubuntu.com/~ogra/ltsp-tarballs/
<ogra> err
<ogra> sorry, wrong paste
<ogra> http://people.ubuntu.com/~ogra/
<ogra> has the 2.15 g-p-m
<infinity> ogra: spiffy.
<ogra> it wont suspend or hibernate
<infinity> Who needs those features anyway?
<simira> infinity: the ones of us that doesn't work 24/7
<ogra> tell that to mdz :) i'd have uploaded it already but he wants it *working* ...
<infinity> simira: People who don't work 24/7 are stealing from the company.  If they're not employees, then they're mocking the ideal of free software by not giving their all to make the world a better place.
<simira> infinity: oh. I'm sorry then. My mistake.
<simira> ^_^
<Kamion> urgh. where's mvo when you need him? python-apt's InstallProgress is fundamentally misdesigned ...
<dholbach> Kamion: he'll be back tomorrow afaik
<Kamion> ah, thanks
<Kamion> basically it's trying to throw exceptions in a subprocess
<simira> I'd like to have a word with mvo as well, yes...
<Kamion> which is obviously not very useful because (a) they have a nasty tendency to fire exception handlers in a process that wasn't expecting its control flow to suddenly pop out to the exception handler, (b) how do you propagate the exception to the main process?
<Mithrandir> Kamion: does this mean we need Yet Another Rebuild or should ubiquity which is hopefully published about now be ok?
<Kamion> no no, this bug's in dapper too, don't worry about it
<Kamion> it's just next on my list, that's all
<Mithrandir> oh, ok.
<ogra> Kamion, btw, have you been serious when you said you'd jump on dexconf to get it fixed in edgy ? or did i misunderstand that ?
<Kamion> ogra: no
<Kamion> (I don't have time for serious dexconf hacking in edgy)
<ogra> ok
<ogra> (it thought so, thats why i'm asking)
<ogra> i'd really love to add a dummy mode for ltsp that only copies an empty xorg.conf in place ... this screen probing is annoying and useless during chroot creation ...
<Mithrandir> ogra: make ltsp put an xorg.conf there before X is installed?
<ogra> hmm, good idea !
<Mithrandir> iirc, xorg will then just say "whatever" and go on its merry way.
<ogra> yep, it will
<ogra> even touching the file should be enough ... Mithrandir you made my day ! :)
<doko> Kamion: are promotions to main handled during the freeze?
<Kamion> doko: sometimes
<Kamion> preferably only if they don't touch the CD
<doko> Kamion: libuninameslist, b-d of fontforge
<Kamion> doko: will do after this publisher run
<doko> thanks
<Riddell> Kamion: should your upload this morning fix the hw-detect problem I was having?
<Kamion> Riddell: yes
<dholbach> happy hug day, Riddell!
<Kamion> hw-detect plus the ubiquity upload that includes it
<Riddell> Kamion: great, are we ready to roll some more candidate knot CDs?
<Kamion> Riddell: Mithrandir's on it
<Kamion> needs the publisher run that is currently in progress
<Riddell> cool
<Riddell> dholbach: hug day already?
<dholbach> yeah!
<pitti> infinity: is the publisher in manual mode? the kernel security updates should have been on the mirrors for 75 minutes now, but still aren't
<ogra> Kamion, Mithrandir, did either of you get i386 install running ? i'm left with a black screen after gfxboot
<Kamion> ogra: worked for me but that was in vmware
<ogra> hmm
<infinity> pitti: It's running right now...
<Mithrandir> I'm rolling new livefs-es with ubiquity 1.1.2 now.
* ogra tries other graphics options
<infinity> pitti: Though I don't recall seeing kernel stuff in the output.
<Kamion> ogra: hold down shift to try the failsafe mode
<ogra> hum, it hunng completely ... not even capslock ...
<pitti> infinity: I got the security lp_archive mail > 2 hours ago, and it didn't indicate any problem; strange...
<ogra> ah, ok, in vga moide i get an apic error ... its the i386 kernel not liking my turion
<Kamion> oh, you mean gfxboot displays fine?
<Kamion> but after it the kernel falls over?
<Mithrandir> Kamion: did we need new alternate CDs?
<Kamion> Mithrandir: yes, for apt-setup
<Mithrandir> Kamion: I'll go make those, then
<Kamion> sounds good
<infinity> pitti: Random package name and version?
<infinity> pitti: 2.6.15-26.45?
<pitti> infinity: linux-source-2.6.10_2.6.10-34.22.dsc and linux-source-2.6.12_2.6.12-10.36.dsc
<pitti> infinity: no, I released the dapper update yesterday already
<infinity> Oh, hoary and breezy..
<pitti> infinity: (since this is an 'OMG, the sky is falling' hole)
<Kamion> doko: please file sync and removal requests separately
<infinity> pitti: Upload failed.  Unsure why.
<Kamion> doko: because sync requests can be processed at any time but removal requests can only (AFAIK) be safely processed while the publisher is not running
<Kamion> so it's not convenient to have both glommed together in one bug
<infinity> pitti: I'll poke it back through and see...
<pitti> infinity: hm; I uploaded them manually since my network connection crashed while running amber
<pitti> infinity: thanks
<pitti> infinity: (and yes, most often I use screen, but I forgot it this morning...)
<pitti> infinity: hm, I'm also missing  openoffice.org2_1.9.129-0.1ubuntu4.1.dsc (and this was ambered normally)
<doko> Kamion: done
<infinity> pitti: You forgot to upload the udebs.
* Mithrandir hopes that's the linux-source udebs and not the ooo udebs.
<infinity> pitti: As for OOo, it's in this publisher run.
<pitti> infinity: oh, I see; thank you
<Mithrandir> ok, new (20060719) alternate images built.  Now test!
<ogra_> Kamion, Mithrandir, all fine, i had to boot with nolapic, now it works fine 
<Mithrandir> Kamion: is {k,edu}buntu also affected by the apt-setup problem?
<Riddell> Mithrandir: yes
<ogra_> apt-setup problem ? 
<ogra_> is that ubiquity ? 
<Mithrandir> Riddell: I'll build you new ISOs unless you already have done that, then.
<Riddell> Mithrandir: please do
<Mithrandir> ogra_: no.
<ogra_> hmm, what are the symptoms ? all my installs seems to be fine 
<Mithrandir> ogra_: apparently, apt-setup wrote botched (or half) sources.list files.
<ogra_> oh, ok 
<ogra_> i didnt check that :)
* ogra_ will look after the running i386 install is done
<ogra_> wow, portmap with a borked network config takes more than 10 mins to install ...
<ogra_> when was that netstat stuff added to the postinst ? seems thats holding it up ...
<ogra_> ah, now it moved on ...
<Kamion> ogra_: both d-i and ubiquity
<Kamion> it's not the fault of ubiquity, but it happens in ubiquity
<Mithrandir> ogra: so, you need a rebuild or not?
<ogra> Mithrandir, still installing, but if it affects all installs i assume yes ...
<ogra> even though i'm not sure we should delay knot 1 for another build for this
<ogra> its something we could note under known issues
<ogra> i mean, heya, its the first *beta* release ... doesnt need to be perfect ...
<Mithrandir> ogra: well, ubuntu and kubuntu are rebuilt, but if you'd want to just put it under known issues for edubuntu, that's your choice.
<ogra> nah, if you already rebuilt the others i wannt to stay in sync 
<Mithrandir> ok, edubuntu building, then.
<ogra> i'll care for the isos ... 
<Mithrandir> ogra: too late.
<ogra> heh
<ogra> ok
<Mithrandir> I had the command ready already. :-P
<ogra> i dont want to cause more work than needed for you :)
<Mithrandir> Riddell: kubuntu alternate rebuild finished, please test.
<Mithrandir> ogra: rebuilding cds is trivial, it was just s/k/edu/ in my previous command
<ogra> i know, thats why i dont want to bnother you with such trivial tasks ;)
<tuck3r> I'm building a ubuntu server CD for ipbxs, i can't get the md5sum.txt file to generate right any idea on how to do it right? sorry if i bothered you, just not sure if this falls under "support"
<Mithrandir> tuck3r: find -print0 | xargs -0 md5sum > md5sum.txt doesn't give you the right output?
<tuck3r> thats not exactly what i was doing but close, let me try it
<Riddell> Mithrandir: thanks, are live CDs also coming?
<Mithrandir> Riddell: yeah, building ubuntu livefs-es now.  I'll do kubuntu ones when they're finished.
<Kamion> ogra: although I'm generally for not putting too much effort into the first milestone, I think generating a sources.list for everyone that doesn't even have archive.ubuntu.com edgy in it is pretty crap and should be avoided.
<ogra> bah ... the installer didnt take my nolapic over to grup ...
<Kamion> Mithrandir: will you do xubuntu too?
<ogra> *grub
<Kamion> ogra: did you put it after -- on the boot line?
<ogra> yes
<Mithrandir> Kamion: yeah, Jani mailed me and asked me to.
<ogra> after quiet even ...
<Kamion> ogra: after -- too?
<ogra> yes, isnt that before splash quiet ? 
<Kamion> (-- is after quiet already)
<Kamion> ogra: no!
<ogra> i've put it at the end of the line
<ogra> so i assume it was after --
<Kamion> any parameters you want to have carried over to grub must come after --
<ogra> hmm
<ogra> i'll check that with the next install
<Kamion> you seem unclear, but if you can ensure that you really put nolapic after --, please file a grub-installer bug
<Kamion> APPEND $KERNEL_PARAMS $DEFAULT_PRESEED boot=casper initrd=/casper/initrd.gz ramdisk_size=1048576 root=/dev/ram rw quiet splash --
<ogra> yup, if i've verfied it ... 
<Kamion> ^-- default boot line
<Kamion> hmm, if only I had a brain; we could drop a bunch of *-installer modifications just by putting 'quiet splash' after --, I suspect
* ..[topic/#ubuntu-devel:siretart] : knot
<ogra> i *think* ive put it at the end ... but i'm not sure anymore ... luckily we have to do another install :)
* ..[topic/#ubuntu-devel:siretart] : 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 | http://wiki.ubuntu.com/HelpingWithBugs | Knot-1 freeze in effect - uploads to main frozen, ask Mithrandir for exceptions
<siretart> sry
<tuck3r> Mithrandir: using your command i still get an error at ./isoboot/boot.cat when i run a check for defects 
<Mithrandir> ogra: edubuntu install cds done
<Mithrandir> tuck3r: rm boot.cat, it's written by mkisofs.
<tuck3r> Mithrandir: that fixed it thanks, now it fails on md5sum.txt, do i have to change it by hand with the new md5sum of itself?
<Mithrandir> tuck3r: or just do find -not -name md5sum.txt -print0 | xargs -0 md5sum > md5sum.txt
<Mithrandir> new ubuntu -desktop up, please test.
<Mithrandir> at least once cdimage is done rsync-ing
<pitti> Mithrandir:  20060719?
<Mithrandir> pitti: yes, both -desktop and -alternate is 20060719
<pitti> ok, thanks for confirming
<Mithrandir> ogra: do you need new livefs-es?
<ogra> Mithrandir, if there are none with the ubiquity fix, then yes
<Mithrandir> ogra: building, then
<ogra> thanks
<tuck3r> Mithrandir: well all the md5 checks are fixed but when i go to install it i get "Warning: file://cdrom/dists/dapper/main/binary-i386/Packages.gz" i'm think this has to do with my apt-ftparchive conf files
<Kamion> you need to update /dists/dapper/Release
<tuck3r> oh forget that command :( thanks
<pitti> hello mdz
<mdz> morning
<ogra_> hey mdz 
<ogra_> not melted yet ?
<mdz> mjg59: if S05vbesave runs, my system hangs during gdm startup.  if I disable it, all is well.  if I run it after X has started, all is also well
<mdz> no, it is not as hot here as it was in LA
<ogra_> well, its hot as hell in germany atm ...
<mdz> it was 43C when I left LA
<ogra_> woah
<ogra_> ok, thats warmer than the 35 i have here atm
<thom> 42 is just excessive
<ogra_> yeah
<ogra_> 35 is still nice if you have a cool place to sit outside 
<tuck3r> well after regenerating /dists/dapper/Release it says "Failed to copy file from CD-ROM. Retry?" at load installer components from cd
<zul> hi
<mdz> 35 != hot as hell
<ogra_> mdz, well, depends on your definition of hell :P
<mdz> depends on the relative humidity actually ;-)
<ogra_> more than 30 in germany is *hot*
<ogra_> heh, right, you're on the seaside additionally ... :)
<mdz> it has cooled off some since I left
<mdz> will be back up to 39 or so by friday though, according to forecasts
<ogra_> so you dont stay in europe until wiesbaden ? 
* ogra_ wonders how much jetlag a human can bear 
<Mithrandir> ogra: I think mdz is trying to find out. :-P
<ogra_> heh
<rodarvus> Wiesbaden is one month from now - quite bearable :)
<tseng> ogra_: ask Nat Friedman
<ogra_> heh
<ogra_> well, he lives in planes, doesnt he ? 
<tseng> yes
<Arbiter> uhm... i have a question: what are default CFLAGS used by buildd for x86?
<Kamion> mdz: the problem with UK summers is not their heat but our complete national lack of preparedness for them (i.e. no widespread aircon)
<Arbiter> (and LDFLAGS, CXXFLAGS, if possible)
<Kamion> pretty much corresponds to our total lack of preparedness for UK winters, in fact (more than an inch or two of snow)
<tseng> Kamion: there was a widespread *lack* of aircondition in Spain
<Kamion> Arbiter: the buildd doesn't force anything; it's just whatever the package uses, and then gcc's defaults
<Kamion> which you can find in the gcc specs file on your own system
<Arbiter> so, 486 optimizations?
<Arbiter> o.O
<tuck3r> do you have a 486?
<tseng> -march=486 -mcpu=pentium4 atm.
<mjg59> mdz: Have you recently changed hardware?
<Arbiter> mh...
<tseng> but dont get caught up in it.
<Kamion> Arbiter: I see you have not checked gcc's default
<Kamion> s
<Arbiter> Kamion, nope :D
<Kamion> gcc -dumpspecs
<tseng> dumpspecs is pretty opaque
<Kamion> mm, true
<Arbiter> heh
<tseng> not that there is any better way of looking at it..
<Arbiter> thanks anyway :)
<Kamion> Arbiter: anyway, failing the above, apt-get source gcc-4.1 and look at debian/rules2
<Arbiter> sure
<Kamion> which is pretty much where the default optimisation configure arguments live
* ogra_ wonders what Mithrandir rebuilt there, this iso rsync is taking noticeable longer than the others before 
<Kamion> doko: promoted libuninameslist
<Mithrandir> ogra: nothing in particular
<Kamion> ogra_: it probably has the squashfs sorting now
<ogra_> aha
<Mithrandir> Kamion: it's a null sortfile, though..
<Kamion> unless I'm mistaken and that was in earlier
<Kamion> Mithrandir: oh, ok
<stub> Launchpad will be going down in 15 minutes for some brief unscheduled maintenance. Downtime will be approx five minutes.
<ogra_> bah, now i know why its so slow 
<ogra_> yep, driven with USB 2.0 this disk is a lot faster :)
<Mithrandir> Riddell: kubuntu -desktop ready to test
<Riddell> thanks
<pitti> argh, cdrecord was merged from Debian, now it doesn't work as user any more
<ogra_> oh fun
<pitti> did anyone else notice that? 'Operation not permitted. Cannot send SCSI cmd via ioctl'
<ogra_> i just burned from a knot 1 test install ... worked fine with n-c-b
<ogra_> but i have an ide writer
* pitti too
<pitti> ogra_: doesn't matter, ATAPI is SCSI protocol over IDE bus
<ogra_> yep
<pitti> carlos: what's the status of edgy langpacks?
<ogra_> pitti, burning is working flawless here with 4:2.01+01a03-5ubuntu1
<ogra_> i'm just running another one 
<pitti> ogra_: which arch?
<Viper550> Good news for those people watching over the Slab specification...
<ogra_> pitti, i386 running on y turion laptop
<ogra_> s/y/a
<pitti> ogra_: ok, I'm on amd64
<ogra_> the test install i talked about before was amd64
<maswan> pitti: Am I supposed to find a difference between the two mails for USN-319-1? They seem to be talking about the same version for dapper, etc, etc.
<Viper550> I've got an APT repository now!
* maswan looks closer
<pitti> maswan: two mails for USN-319-1?
<pitti> maswan: sure that you don't mean USN-319-2?
<maswan> pitti: I just got a USN-319-1 Date: Tue, 18 Jul 2006 11:13:52 +0200
<pitti> ok, that's the dapper update from yesterday
<pitti> maswan: and some minutes ago I released USN-319-2 for the breezy/hoary fixes
<maswan> huh.
<zul> hey
<pitti> maswan: I didn't want to wait for dapper since this was somewhat critical
<ogra_> Viper550, thats better suited for #ubuntu-motu than here :)
<pitti> maswan: s/for/with/
<maswan> pitti: Yes, I was just surprised, since I got that yesterday too.,
<maswan> Oh, well. Now I got -2 too. So never mind, I'll try to look at the mails to see if I find where the duplicate spent a day in hiding. :)
<Mithrandir> ogra: edubuntu -desktop done too
<pitti> seb128, Mithrandir: on current ppc/live, I get half a thousand error dialogs about 'The panel encountered a problem while loading $someapplet'
<Mithrandir> pitti: hmm, does dmesg show read errors?
<ogra_> Mithrandir, ta !
<ogra_> pitti, hmm, i didnt have that with the last live test here 
<pitti> Mithrandir, seb128: and a single additional one about nautilus not being able to start
<pitti> Mithrandir: yes, some familiar-looking buffer i/o errors on the cd-rom
<pitti> Mithrandir: ok, I'll check CD integrity first (would be a strange coincidence, but let's be sure)
<Fujitsu> maswan, I've got two USN-319-1s as well. One signed, the other not.
<maswan> Huh, looks like securityfocus.com resent it, or something.
<pitti> https://lists.ubuntu.com/archives/ubuntu-security-announce/2006-July/thread.html only has one
<pitti> and I'm quite sure I only approved one mail
<Mithrandir> pitti: fwiw, I can't see it on amd64 or i386 so I'm tempted to blame dodgy media or such as a first approximation.
<pitti> yes, may be a bounce from bugtraq or full-disclosure
<pitti> Mithrandir: I'll find out
<ogra_> i'll do a ppc live test once the currently running install is done
<maswan> pitti: Yes, bugtraq, just found a Delivered-To: mailing list bugtraq@securityfocus.com
<ogra_> pitti, did your suspend lamp also turn into a HDD indicator on the ibook ?
<pitti> ogra_: oh, I didn't pay attention to that; probably
<pitti> ogra_: that's what MacOS uses it for (but I prefered the glowing effect while suspending)
<ogra_> pretty annoying (says my GF who cant sleep with it in the bedroom anymore because its flashing all the time)
<ogra_> i personally like the idea of having a HDD indicator though ... but i'd prefer it being a panel applet or something like that :)
<seb128> pitti: weird your applets issue, let's blame the CD for now :)
* pitti blames the heat
<seb128> too much heat
<seb128> I want the winter and some snow :p
<ogra_> bah
<ogra_> whiners
<pitti> meh, CD integrity check succeeded
<seb128> pitti: the usual issue when applet don't start is gnome-applets not being installed :)
<pitti> seb128: it was, I checked
* pitti boots again
<ogra_> icon issues ?
<seb128> pitti: try running /usr/lib/gnome-applets/mixer_applet2 from the command line and add it then to the panel
<pitti> ogra_: the desktop issues are most likely a consequence of the read errors
<seb128> pitti: you mioht get some errors on the command line ...
<pitti> right
<ogra_> pitti, yeah
<tfheen_live> \o/
<ogra_> gah, this portmap postinst is evil ...
<Robot101> <o/
<tfheen_live> i386 and amd64 -desktop are good to go.
<tfheen_live> now I just need to test the alternate ones.. but that's quicker.
<pitti> odd, alternate installs take much longer here
<ogra_> for me as well
<ogra_> but thats because i install 300 MB ltsp-client :)
<pitti> copying a live system is just so much faster than copying .debs to the hd and unpacking/installing them...
<ogra_> yeah
<ogra_> i whish i could use the liveCD for edubuntu installs
<Zomb> pitti: not much faster, depends on the harddisk
<Mithrandir> pitti: depends on your hardware.
<Zomb> and filesystem and ram, of course
<Mithrandir> and cpu
<Kamion> the live CD method's faster on reasonably modern systems with adequate RAM so that it doesn't swap all the time, and not-hideously-slow disks
<pitti> seb128: ok, if I run mixer_applet2 in a shell, it just sits there and nothing happens (no icon etc.)
<Kamion> on more constrained systems, traditional installation can certainly be faster
<seb128> pitti: that's expected, you need to add it to the panel then
<seb128> pitti: that's sort of the server part waiting for a client :)
<pitti> argh, what happened to middle/right mouse button emulation?
* pitti is unable to produce a right click
<ogra_> whoops, why did i get the http proxy question now ?
<Kamion> ogra_: changes in choose-mirror
* ogra_ hast had that on the other installs
<Kamion> ignore it for now, may or may not stay there
<ogra_> ah, k
<Kamion> also your other installs were before my apt-setup fix, right?
<ogra_> yep
<Kamion> there you go then
<ogra_> :)
<Kamion> the apt-setup bug prevented choose-mirror from running
<seb128> pitti: shift-f10 with focus on the panel?
<ogra_> ah
<pitti> seb128: ok, that works, but that's not mouse emulation :) (thanks, though)
<seb128> dunno about the mouse, looks like xorg material to me :)
<ogra_> pitti, thats broken since 2.6.17
<pitti> ok, somebody dropped the emulation stuff from /etc/sysctl.conf
<pitti> not a big deal to fix
<ogra_> ah
* pitti TODOs
<ogra_> i was digging at the kernel before and didnt find anything :)
<pitti> seb128: meh, shift-F10 on the panel gives me the gnome-terminal menu
<Kamion> hmm, I wonder where my middle/right-click mappings are coming from
<seb128> pitti: because the focus is on the g-t launcher :)
<Kamion> oh, perhaps I haven't rebooted since the last procps upgrade
<pitti> seb128: and if I minimize g-t, s-f10 doesn't do anything
<pitti> Kamion: my /etc/sysctl.conf has no emulation on the live system, how about your's?
<seb128> pitti: ctrl-alt-tab
<Kamion> pitti: you assume my system can manage to read CDs
<seb128> pitti: go on the panel with that and do shift-f10 then
<ogra_> Kamion, dont you have a usb drive ? 
<Kamion> ogra_: no
<pitti> seb128: I did, that only selects the 'exit' icon
<pitti> darn
<ogra_> sad then ...
* pitti searches his notebook usb mouse
<seb128> pitti: try with the bottom panel maybe :)
<pitti> ok, here we are - proper 3-button mouse :)
<seb128> pitti: ups, ctrl-f10 rather
* ogra_ ran one of his thin clients for some days from a USB attached liveCD, worked very nice 
<seb128> too late :p
<seb128> pitti: ctrl-f10 should work (for next time)
<pitti> seb128: no mixer applet in the 'add to panel' dialog; and surprisingly few apps in total there (well, related to the initial failure, I guess)
<seb128> pitti: are you sure gnome-applets-data is installed?
<pitti> seb128: affirmative
<Kamion> pitti: alt-f1, start terminal, 'sudo sysctl dev/mac_hid/mouse_button_emulation=1', 'sudo sysctl dev/mac_hid/mouse_button2_keycode=87', 'sudo sysctl dev/mac_hid/mouse_button3_keycode=88'
<seb128> pitti: you have a /usr/lib/bonobo/servers/GNOME_MixerApplet.server ?
<Kamion> er sysctl -w for all of those
<pitti> seb128: I do, and it looks sane
<seb128> pitti: weird then ... nothing to .xsession-errors about bonobo or the panel?
<seb128> pitti: does bonobo-browser works fine?
<pitti> seb128: failed to load applet OAFIID:GNOME_MixerApplet: Moniker has an unknown moniker prefix
<pitti> ah, I knew that Monica was to blame
<seb128> hehe
<ogra_> mjg59, ping
<mjg59> ogra_: Hi
<ogra_> mjg59, would you mind commenting on http://bugzilla.gnome.org/show_bug.cgi?id=347855
<pitti> seb128: where is bonobo-browser?
<seb128> pitti: what version of libbonobo-0 do you have on that CD?
<Ubugtu> Gnome bug 347855 in general "Pressing brightness keys on laptops wakes up the screensaver" [Normal,Unconfirmed]  
<ogra_> i attached your patch to it ...
<seb128> pitti: libbonobo2-0 rather
<pitti> seb128: 2.15.0-0ubuntu2
<seb128> libbonoboui2-dev: /usr/bin/bonobo-browser
* pitti jumps through some hoops to get network on his laptop, minute
<pitti> (to install the -dev)
<pitti> seb128: aarrgh, that wants to pull a million packages
<pitti> seb128: any easier way of debugging this than with libbonoboui2-dev? (if not, I'll install it)
<mjg59> ogra_: Done
<seb128> pitti: you just the binary, dpkg-deb -x the .deb if required
<ogra_> mjg59, thanks a lot 
<seb128> you just need the binary
<mjg59> ogra_: At least, it would be if bugzilla were responding
<mjg59> It seems to have gone very slow
<seb128> pitti: it's to the -dev to no ship a binary with the lib and not create a -bin
<ogra_> mjg59, i'm trying to work towards a patch free g-s-s in edgy :)
<ogra_> mjg59, yeah, i think they are just moving to a new machine ...
<pitti> seb128: oooh, wait
<seb128> ?
<pitti> seb128: 'date' says 1 Jan 1904
<seb128> ah
<ogra_> heh
<seb128> bonobo hates that
<pitti> seb128: my laptop ran out of power during the last days
<seb128> that is a known issue
<pitti> ok
<pitti> seb128: sorry for the noise then
<pitti> seb128: I had no clock applet to notice ;)
<seb128> np ;)
<ogra_> heh, we're so addicted to our desktop :)
<pitti> so, bonobo says 'hey, in 1904 computers weren't invented yet, therefore I fell into the hands of some evil alien time travellers and so I refuse cooperation'
<Mithrandir> Kamion: uh, alternate i386 fails here.  base-installer complains about dmsetup not found [: crypt: unknown operand, etc.
<Mithrandir> Kamion: (nuke disk + LVM install)
<carlos> pitti: I just found a way a small problem with tests that delayed me a bit the code that will open edgy will be ready to be reviewed today
<seb128> pitti: something like that ;)
* pitti reboots to test the amd64 live CD
<Kamion> Mithrandir: will be LVM-specific
<Mithrandir> Kamion: ok, retrying with regular now.
<Kamion> wonder why dmsetup-udeb isn't installed
<pitti_live> Mithrandir, seb128: ok, works fine now
<seb128> pitti_live: good
<pitti_live> doko: OO.o doesn't start on ppc live; 'javadlx: relocation error: /usr/lib/libstlport_gcc.so.4.6: symbol logl, version GLIBCXX_3.4, not defined in file libstdc++.so.6 with link time reference'
<pitti_live> doko: any idea?
<pitti_live> Mithrandir, Kamion: my locale is en_US.UTF-8, although I chose German in gfxboot; know issue or do you want a bug?
<Mithrandir> pitti_live: not known issue, please file a bug (on casper)
<Kamion> pitti_live: what's in /proc/cmdline?
<Kamion> oh, I bet I know
<Kamion> Mithrandir: gfxboot-theme-ubuntu changed to use locale= instead of debian-installer/locale=, which is the new preferred syntax for d-i - but I forgot that casper would need to be changed too
<Kamion> sorry about that
<Mithrandir> Kamion: np; just file a bug.
<pitti_live> Kamion: right, 'locale=de'
<doko> pitti_live: no build on edgy yet. and it currently FTBFS
<pitti_live> doko: ok, that sounds as if it would sort itself out then after it's built
<Kamion> filed
<ogra_> pitti_live, can you check if your CD shuts down properly ? i had problems with it ...
<Kamion> Mithrandir: base-installer fix committed upstream; do you want to rebuild with it?
<pitti_live> ogra_: ok, after the ubiquity installs finish
<Kamion> or just errata it?
<Mithrandir> Kamion: nah, I'll put it in as a known problem.
<Mithrandir> Kamion: I want to get this CD out now.  Bored.
<Mithrandir> ogra_: usplash quits and you're sent to the wrong terminal so casper reads from the wrong tty.
<Kamion> Mithrandir: nod
<pitti_live> Mithrandir: do you want to wait for my ppc ubiquity test or just push it out now?
<ogra_> Mithrandir, ah, so thats a known one ... great
<Kamion> Mithrandir: workaround is to boot with anna/choose_modules=dmsetup-udeb if you want to do an LVM install
<pitti_live> (I am doing an amd64 ubiquity test ATM, too)
<Kamion> (I'm guessing, anyway)
<Mithrandir> pitti_live: I'm doing i386 alternate test and then I'll do amd64 alternate and then we'll release, if nobody complains.
<Mithrandir> ogra_: how's edubuntu looking?
<Mithrandir> Riddell: how's kubuntu looking wrt knot-1?
<Mithrandir> Kamion: it's probably not important.  Better to get this out.
<Mithrandir> pitti_live: so I'll wait for your.
<Mithrandir> -r
<ogra_> Mithrandir, last run was all fine ... i'm just statring pc live ... and have all intel/amd64 ones ahead ...
<ogra_> *ppc
<ogra_> i dot expect regressions, so it should be fine to go
<Riddell> Mithrandir: i386/powerpc alternate good, i386 desktop good, others progressing
<pitti_live> Kamion: ppc/ubiquity complains about not finding a bootstrap partition, although there is one; I'll try to continue
<Mithrandir> Riddell: thanks.  Do you have anybody testing amd64?
<Mithrandir> Riddell: and do you have an ETA on when you'll give me thumbs up or down?
<Kamion> pitti_live: yeah, known from dapper too
<Kamion> see DapperReleaseNotes/UbiquityKnownIssues for a discussion of that
<Kamion> I'll try to get it fixed soon
<pitti_live> ok, thank you
<pitti_live> (just making sure we have recorded all bugs)
<pitti_live> G0SUB: ping
<Mithrandir> pitti_live: ooo keeps crashing on i386 here too
<pitti_live> Mithrandir: hm, works fine on amd64/live here
<Riddell> Mithrandir: I'm doing amd64, but it has my CD burner on it so it gets done last
<Mithrandir> pitti_live: amd64 rocks, you know. :-)
<Mithrandir> Riddell: ah, ok.
<Riddell> Mithrandir: kubuntu live amd64 and powerpc also good
<Mithrandir> Riddell: so amd64 alternate is the only one left?
<pitti_live> moin Keybuk
<Riddell> Mithrandir: yes, doing now
<Keybuk> pitti_live: afternoon
<ogra> Mithrandir, edubuntu ppc all good ... going for amd64 now
<ogra> err, intresting 
<ogra> this time shutdown worked fine
<ogra> (on ppc live)
<pitti> Mithrandir: amd64/live hangs after ejecting the CD (Enter doesn't reboot), but apart from that and the already discussed locale issue live system and ubiquity worked fine for me
<Mithrandir> pitti: it reboots if you press alt-f8 and then press enter
<pitti> ah
<Hobbsee> hi pitti, Mithrandir 
<pitti> hey Hobbsee 
<Mithrandir> hiya Hobbsee
* Hobbsee panics.
<ogra> hey Hobbsee 
<Hobbsee> hi ogra 
<Hobbsee> what did i do with my kopete and amarok stuff?
* Hobbsee suspects that she shouldnt have left them sitting on her desktop
<Hobbsee> oh, they're on revu, that's all right.
<ogra> no idea ... one starts with K the other ends with K :) 
<Hobbsee> ogra: heh, how useful :P
<Hobbsee> ogra: for that, i'll poke you to upload them when the freeze ends
<Hobbsee> and then we have less buggered armarok and kopete packages :)
<ogra> hehe, good ...
<ogra> (even i never used either) 
<ogra> but feel free to bug me for uploadng 
<Hobbsee> ogra: true.  do you trust my upload though?
<ogra> sure 
<Hobbsee> :)
* Hobbsee wonders if karamba and superkaramba are the same thing.
* ogra wonders if one has 98 octane and the other is rather regular :)
<pitti> ogra: ppc CD shut down fine here
<ogra> yes, intrestingly for me too this time 
<gnomefreak> Hobbsee: good luck ive been wondering that for a while now
<Hobbsee> gnomefreak: seems they're different.
<gnomefreak> im sure its something like super can do things the other one cant
<Hobbsee> ogra_ibook: 1build1 goes to 1ubuntu1, doesnt it?
<pitti> Mithrandir: ppc live and ubiquity worked fine (apart from discussed issues)
* Hobbsee can never remember
<Mithrandir> pitti: thanks.
<Kamion> Hobbsee: yes
<Hobbsee> Kamion: cool, thanks.
* Hobbsee wonders why people use build1 anyway.
<Hobbsee> well, i know why, but it's still annoying.
<Kamion> Hobbsee: why is it annoying?
<Hobbsee> Kamion: because it requires me to remember how it changes?
* Hobbsee shrugs
<Kamion> damn, installation in languages whose default country's name contains a comma will fail
<Kamion> due to a bashism in the localechooser build (echo -n, whee)
<fooforyou> hi
<infinity> Kamion: Countries with commas in the name don't deserve free software, just by virtue of their silly naming scheme.
<chrisjr> pfft
<chrisjr> what country has a comma in its name?
<Riddell> Mithrandir: all Kubuntu CDs good to go
<infinity> chrisjr: Several, actually.
<chrisjr> why should this conflict for their getting free software?
<chrisjr> s/for/with/g
<infinity> chrisjr: It was a joke, you're lacking context. :)
<infinity> 08:27 < Kamion> damn, installation in languages whose default country's name contains a comma will 
<chrisjr> figure as much :)
<infinity>                 fail
<infinity> 08:28 < Kamion> due to a bashism in the localechooser build (echo -n, whee)
<chrisjr> heh
<Kamion> chrisjr: "Iran, Islamic Republic of"
<Kamion> chrisjr: "Moldova, Republic of"
<Kamion> etc.
<chrisjr> gotcha
<chrisjr> just cant think of where that would come up
<Kamion> localechooser due to a bashism
<Kamion> commas need to be \-escaped in debconf choices lists
<chrisjr> ive done a lot of preseeding, etc and never had problems that would break with that
<chrisjr> yeah
<Kamion> I'm one of the debconf maintainers and I've had lots of problems due to that. :-)
<chrisjr> i see
<ogra> hmm, so $(echo blah|grep blupp) isnt a bashism, but if i add .n it is ?
<ogra> errr
<chrisjr> i sure do use lots of debconf
<ogra> -n
<Kamion> ogra: http://www.opengroup.org/onlinepubs/009695399/utilities/echo.html
<ogra> yes yes ..
<Kamion> "If the first operand is -n, or if any of the operands contain a backslash ( '\' ) character, the results are implementation-defined."
<chrisjr> i have been working on an easy to set up server type install, http://suriyan.org
<infinity> Technically, I believe "echo -n" is a "undefined XSIism"...
<chrisjr> okay
<ogra> Kamion, oh, i didnt expect a quote, thanks :)
<Kamion> infinity: actually XSI requires that -n must not be treated as an option
<infinity> But yes, its use in most Linux distributions is very bash-centric.
<infinity> Kamion: Oh, really?... I need to re-read my specs.  I'm clearly rusty.
<Kamion> so echo -n isn't even XSI, it's pure pot luck whether it works or not
<Mithrandir> Riddell: yay. :-)
<Kamion> "printf '%s' "$foo"' is better
<Kamion> er
<Kamion> printf '%s' "$foo"
<infinity> Kamion: Well, note the "undefined".. That seems to match with your "pot luck".
<Kamion> infinity: right, but I mean you can't even appeal to a standard as dodgy as XSI
<infinity> printf irritates me, only because printf in every language is subtly different and I always hurt my brain remembering how.  As a result, I tend to reserve it for C only and find other similar mechanisms in other languages.
<Kamion> anyway, ripping all that code out now; any code that requires eight consecutive backslashes in a sed expression deserves to die anyway
<chrisjr> hah
<ogra> -n is a pretty new enhancement anyway, no ? i remember being able to use things like \n \t without -n before 
<Kamion> ogra: -n has nothing to do with \n \t
<infinity> ogra: You're thinking of -e
<ogra> yeah, muddled it, sorry
<ogra> just saw it in the manpage
<infinity> ogra: -n means "no trailing newline"... When it works.
* Mithrandir runs off to find dinner while the amd64 install finishes up.
<Hobbsee> dinner?
<Kamion> -e is also non-POSIX, of course. On some systems you can use \n or \t in echo and it'll be expanded, and on others you can't. (That's an XSIism.)
<Mithrandir> Kamion: any chance you could kick off xubuntu livefs + isos for me?  Jani was fine with them being released untested..
<chrisjr> dinner happens.
<Hobbsee> where the the heck is it dinner time?
<Kamion> The only portable way to use echo is with plain strings containing no backslashes and not beginning with "-", and with no options.
<infinity> Hobbsee: Anywhere where people are hungry.
<ogra> Hobbsee, 1-2h ahead of europe ...
<Hobbsee> infinity: hmmm...so i can have dinner at 1am..nice...
<ogra> israel would be a bet i guess
<Hobbsee> ogra: ah
<Kamion> Mithrandir: ok, building
<Mithrandir> Hobbsee: CET; I have to make the dinner too, which takes an hour today.
<infinity> Hobbsee: I'm going to guess Thailand, just based on the IP.  Or because I'm psychic.
<Mithrandir> so dinner'll happen at aroud 1800
<chrisjr> thailand here
<ogra> gah, now i'm hungry
<Hobbsee> infinity: hehe, true
<Hobbsee> ogra: :P
<tmccrary> Has anyone in here tried building Xorg 7.1?
<ogra> and that with a nonexistent kitchen and the next possibility to buy food 20km away
<Hobbsee> Mithrandir: ah...right.  CET means close to nothing to me
* Hobbsee sends ogra some ice to munch on
* infinity breaks out a bottle of wine that Daniel left behind when he moved out and eyeballs it cautiously as "dinner".
<ogra> yummy
<ogra> wine !
<Hobbsee> heh
<Hobbsee> wine != dinner
<ogra> i have at least 3 bottles left ...
<ogra> but no food at all ... and the kitchen is packed in boxes already
<infinity> A rather imposing looking bottle, with the only words on the label being "black label"... I'm not sure if I should be frightened.
<mjg59> ogra: Empirical evidence suggests that it's broadly possible to live on alcohol alone
<mjg59> For certain values of "live"
<ogra> infinity, sure thats wine ? 
<infinity> mjg59: You're Irish; your opinion doesn't count here.
<infinity> ogra: I just pulled the cork.  It smells vaguely like wine.
<ogra> mjg59, heh, right, but i doubt the police would like it if i drive after only having wine :)
<mjg59> infinity: Daniel ought to be awake by now, you could ask him
* ogra has to transport all these boxes with the kitchenn in them ...
<infinity> mjg59: If I know Daniel, he bought it purely due to the label, and would have no advice to offer on its drinkability.  I'll just have to take the plunge myself.
* Hobbsee pictures a drunken infinity trying to run the archive.
<infinity> Hobbsee: There's a reason I'm not logged into any canonical/ubuntu hosts right now.
<alephant> I think I know the answer, but is anybody interested in a bug report here before I hit the bugzilla?
* ogra imagines that will likely work better than sore
<Hobbsee> infinity: hehe :)
<infinity> alephant: We tend to prefer bug reports in Malone, unless you actually want to discuss the solution a bit with someone.
<infinity> alephant: If it's just a bug report, or a simple patch, file it and we'll get to it.
<ogra> gah, muddled my vocabulary ... s/sore/sober/
<alephant> I'm actually rather curious why the installer fubared my grub/menu.lst so badly
<infinity> ogra: I dunno.  I had to argue at length with both katie AND soyuz earlier today.  I suspect that would not have gone well if I had been drunk.
<Kamion> alephant: what version?
<Kamion> and fubared how?
<ogra> infinity, you could have offered them wine :)
<alephant> 6.06 / alternate_install
<mjg59> ogra: Despite the naming, I don't think offering Katie wine gets you very far
<infinity> Okay, wow.  Daniel MUST have purchased this based on the label.  If he bought it based on experience, the man has no taste buds.  None.
* Hobbsee is really, really glad that she isnt named katie.
<infinity> mjg59: If you run into the boy, smack him for me.  This is godawful.
<alephant> partitioning /dev/sd{a,b} 1GB swap, remaining raid
<infinity> (And I'm drinking it anyway... Go me)
<alephant> /dev/md0 == /dev/sd{a,b}2, ext3, /
<Kamion> oh, wouldn't surprise me at all if there was raid breakage
<sharms> can anyone send me in the direction of where to get started if I want to make sure when using just a usb joystick that the screensaver doesn't go on?
<Kamion> file a bug and attach /var/log/installer/syslog please
<sharms> is there some activity monitor that needs to be updated?
<ogra> Hobbsee, whats wrong with katie, she sends you friendly mails for every upload :)
<alephant> then grub/menu.lst has an incorrect root() stanza and totally missing initrd stanza
<alephant> I'll file th ebug
<alephant> if I can ever get the dang thing to pass fsck
<Hobbsee> ogra: because it would send my nick highlighting psycho.  ah, is that katie.  it usually ends up telling me i screwed up.
<infinity> Hobbsee: well, no.  katie is the old archive software (or the software Debian runs)... You get angry mails from soyuz these days.
<Hobbsee> ah right
<Hobbsee> heh
<infinity> Hobbsee: I will petition to rename soyuz to sarah, just for you.
<Hobbsee> like "you've tried to upload to main, you stupid moron"
* Hobbsee got one of them earlier.  oops.
<ogra> Hobbsee, heh, ask Spec how it feels in here short before ubuntu conferences
<Hobbsee> ogra: haha, yeah.
<Hobbsee> infinity: heh.
* Hobbsee would never respond to sarah at all, if you did that.
<infinity> #slug... Sydney?
<jdub> THE SUN IS SO HOT THAT EVERYTHING ON IT IS A GAS
<Spads> a gigantic nuclear furnace
<Hobbsee> infinity: yes
* Hobbsee worries about jdub's sanity.
* jdub hugs Spads 
<thom> Hobbsee: too late.
* infinity is naturally suspicious of Sydneysiders.
<jdub> thomarse!
<Hobbsee> infinity: why so?
<thom> jeffurry
<jdub> infinity: noofie.
<Hobbsee> thom: yeah, quite possibly.
<infinity> jdub: Nonsense.  I've been in Melbourne almost 1.5 years now, I claim it as my home.
<infinity> jdub: I also, uhh... Love footy and such.  Or something.
<jdub> infinity: fake mexicans can't diss.
<infinity> jdub: But most importantly, I have an unbridled and unfounded hatred for Sydney.  Just cause.
<chrisjr> fake mexicans?
<thom> infinity: your accent gives the game away, sonny
<infinity> thom: Shh. :)
<Kamion> Keybuk: well, switching to dash as /bin/sh is certainly uncovering a lot of bashisms
<Kamion> Keybuk: some of them are pretty worrying though, because they aren't at all visible
<Kamion> Keybuk: I could easily not have noticed that localechooser one for weeks
<ogra> Kamion, Mithrandir, edubuntu amd64 all good
<Kamion> is there anything we can do to search for this automatically? like grepping the archive for 'echo *-' or something
<Kamion> ogra: thanks
<Keybuk> Kamion: heh, interesting
<Keybuk> I guess if we knew the bashisms we had to look for, we could grep the archive, yeah
<Keybuk> doesn't the installer already use dash/busybox anyway?
<ogra> apparently not
<ogra> else ltsp would have failed since breezy
<Kamion> Keybuk: not in its build proces
<Kamion> s
<Kamion> ogra: the installer most certainly does use busybox sh
<Kamion> ogra: however stuff run in /target used bash up to dapper
<Keybuk> ahh
<Kamion> this was a misbuilt templates file in the udeb
<ogra> ah, ok
<lucas> maybe it would be possible to write a bash/dash script parser and find bashisms we want to find like this
<ogra_> thats a mean one: $(echo ${1:2} | tr "-" "_") 
<tmccrary> Are there any packages for Xorg 7.1 available anywhere yet?
<ogra_> tmccrary, no
<ogra_> Keybuk, is there a way that you could revert the order ohci_hcd and ehci_hcd are loaded in udev ?
<ogra_> i'm slowly going mad here because i always forget to unload them and reload them in the right order before trying to burn off my usb disk ...
<ogra_> and burning a 700MB CD with usb 1.1 takes 30 min or more at full speed
<Keybuk> ogra_: no.
<ogra_> so thats a kernel thing ? 
<Keybuk> yup
<ogra_> meh
<ogra_> BenC, ^^^^
<Keybuk> the order of loading shouldn't matter
<Keybuk> do you have a buggy driver?
<ogra_> seems like
<ogra_> if i unload both and load ehci first, all is fine 
<ogra_> but directly after boot all devices are recognized as 1.1
<ogra_> so it seems to me that ohci grabs all ressources ...
<Keybuk> definitely a kernel problem
<Keybuk> as the same bug would exhibit if udev forced the order for that device, but you did have a 1.1 only bus with an earlier PCI id
<Keybuk> ehci should be able to take the devices off ohci
<ogra_> hmm, ok, so its an ehci_hcd bug then ...
<Keybuk> I wouldn't begin to place the area of blame for the bug yet
<coided> Where can I obtain a copy of the NDA/preamble required for ubuntu-kernel devs?
<ogra_> NDA ?
<coided> non-disclosure agreement
<BenC> ogra: dapper or edgy?
<BenC> coided: what NDA would ubuntu-kernel devs have to agree to?
<ogra_> BenC, edgy
<ogra_> coided, i now what NDA means
<BenC> ogra: works in dapper I assume?
<coided> sorry, I can't be sure all the time
* BenC hasn't signed an NDA
<ogra_> BenC, no idea i have that laptop since a week and dapper didnt stay longer than 10 mins on it ...
<BenC> coided: technically, an NDA agreement by nature is not publicly available :)
<Keybuk> I thought our kernel was public? :p
<coided> well you have restricted modules by non-os vendors, so
* zul hasnt signed one either
<BenC> ogra: If you could boot to 2.6.15 and retest, I'd appreciate it
<coided> now im just wondering if there is one
<BenC> if it's different, then dmesg's to compare would be nice
<BenC> coided: restricted means we have restrictions on how we distribute them
<coided> so there is no NDA?
<BenC> coided: we have no special access to source code
<BenC> it's the same restrictions most other ppl have...mainly just the LICENSE that comes with it
<coided> yeah I see now
<coided> thanks for clarifying that
<ogra_> BenC, its a HP pavillon ze2000 (turion) runnign edgy i386 ...
<ogra_> i'll boot 2.6.15 asap (have to do some work on the machine atm)
<ogra_> BenC, i also have to boot i386 with nolapic, amd64 seems fine though
<LaserJock> iwj: ping?
<seb128> LaserJock: he's away (probably for the evening)
<LaserJock> seb128: ok, thanks
<seb128> np
<LaserJock> it seems he and I have opposite hours
<Petaris> ajmitch: ping
<Petaris> ajmitch: I hear you have been working on AD integration, had any luck?
<glatzor> elmo: ok.
<elmo> glatzor: as in http://<mirror>/ubuntu dapper-security ?
<glatzor> elmo: yes.
<elmo> glatzor: ugh
<glatzor> elmo: but it is not such an evil issue to use the dapper-security repo of the mirrors that I should revert them to security.ubuntu.com automatically?
<elmo> glatzor: oh, heck no
<elmo> glatzor: but don't go making it easy for people ;-)
<glatzor> elmo: onther question: there are mirrors for every iso 3166 country code?
<elmo> glatzor: there's a wildcard in place
<elmo> (so: yes ;-)
<sladen> http://pr0n.archive.ubuntu.com/  rocking
<glatzor> :)
<glatzor> elmo: there is currently no connection speed testing program to detect the best mirror? at the moment I provide a 'fake' option "Server for COUNTRY" extracted from the locale
<elmo> glatzor: unfortunately not really, no
<elmo> server for country based on locale is a pretty good start though
<elmo> the launchpad guys are working on automated mirror testing, once that's a bit more involved you could hook into that to refine your list of choices for the user
<elmo> s/involved/evovled/
<glatzor> elmo: ok. Is there a way to identify "official" Debian repos not using the URL of the repo?
<elmo> ... Ubuntu ? :P
<glatzor> elmo: I want to reuse the code for Debian :)
<elmo> ok - so I don't quite understand the question?
<glatzor> elmo: oh, perhaps I should point you to the user interface mockups. I plan to abstract the source.list:
<glatzor> https://wiki.ubuntu.com/UpdateManagerEdgyRepo
<glatzor> To abstract the sources I need to know the corresponding repositories of the used distribution
<elmo> glatzor: (random nitpick, main should come first in any listing of components)
<elmo> (specifically in https://wiki.ubuntu.com/UpdateManagerEdgyRepo?action=AttachFile&do=get&target=better_desc.png)
<glatzor> elmo: For Ubuntu we base the decision on the hostname of the server and the dist part of the repo
<glatzor> *archive.ubuntu.com
<glatzor> elmo: Right.
<elmo> glatzor: ok, well debian, does have a ftp.$cc.debian.org system, but it's not desperately well maintained, and I'm not sure they have the same level of URL facism we do (i.e. requiring debian/ to work)
<toma> '
<elmo> glatzor: so I'm not sure you could do that for debian, I'm afraid
<glatzor> the mirror list at http://www.us.debian.org/mirror/list is maintained regularly?
<glatzor> I will add an option to add a custom server, so that you can also use your local mirror
<elmo> err, kind of.  the people doing mirror stuff in debian are pretty MIA, so I'm not sure if that list is kept up to date
<elmo> but it's the best Debian has
<hungerW> no new debs all day long:-(
<ogra_> Kamion, Mithrandir, edubuntu is good to go ...
<tmccrary> xorg sucks 
<infinity> elmo: IME, debian/ always works for CC mirrors.  Just not for other random mirrors.
<tmccrary> anyone here familiar with git
<tmccrary> ?
<tmccrary> defaulting to local storage area
<tmccrary> fatal: unexpected EOF
<tmccrary> clone-pack from 'git://anongit.freedesktop.org/git/util-makedepend' failed.
<tmccrary> defaulting to local storage area
<tmccrary> fatal: unexpected EOF
<tmccrary> clone-pack from 'git://anongit.freedesktop.org/git/util/makedepend' failed.
<dholbach> hum, could it be that wesnoth's binary packages on AMD64 still sit in NEW? or something?
<Keybuk> https://launchpad.net/distros/ubuntu/edgy/+queue?queue_state=0&queue_text=wesnoth
<Keybuk> ^ no
<Keybuk> the i386 ones do though
<dholbach> ok
<bSON> hi
<bSON> is somebody thinking about integration of tracker into ubuntu and development of it, maybe for edgy+1?
<sladen> Keybuk: are xaralx binaries sitting in NEW too?
<Keybuk> sladen: yes
<Keybuk> bSON: what's tracker?
<HiddenWolf> Keybuk: beagle and more, but fast and memory-efficient
<sladen> Keybuk: could you give um a kick pleaes
<bSON> Keybuk: a freedesktop alternative to beagle written in c, currently in early stage of development: http://freedesktop.org/wiki/Software/Tracker
<Keybuk> sladen: I'd rather not during knot freeze, in case they break something
<Keybuk> bSON: if it's in an early stage of deveopment, it's almost certainly not ready for "integration into ubuntu"
<bSON> Keybuk: that's why i said edgy+1 and also upstream development
<sladen> Keybuk: it's multiverse with nothing depending on it
<dholbach> bSON: but if you want to get it packaged to be able to showcase it or expose it to users, you might want to ask for followers in #ubuntu-motu
<dholbach> bSON: or add it to http://wiki.ubuntu.com/UniverseCandidates
<Keybuk> bSON: we're not thinking about edgy+1 yet
<bSON> dholbach: ok, thanks
<bSON> i just meant, it's just the tool the ubuntu folks were looking for as summer of code project, "A complete beagle-like desktop search app that doesn't use mono, but any of C, Ruby, Python or Perl as a programming language"...
<bSON> and it's a freedesktop project
<Keybuk> what's wrong with Mono?
<fabbione> and why should we trust a freedesktop project more than others?
<ogra> doesnt tracker need some intrusive changes to nautilus and needs to be compiled in ?
<bSON> fabbione: maybe becaus freedesktop is about desktop standards, and ubuntu is about standards too
<Riddell> bSON: just being on freedesktop doesn't make it a standard
<bSON> fabbione: and there's already tracker integration in nautilus upstream
<bSON> as far as i heard, you can enable it through a configure switch
<fabbione> bSON: what Riddell said
<bSON> and gnome is also hosting tracker, so maybe they are thinking about heading that direction too
<bSON> what would make it a deal for ubuntu developers
<fabbione> bSON: prepare a demo package and find somebody in #ubuntu-motu to upload it for you
<bSON> the tracker page has a nautilus 2.14 version with tracker integration enabled, but i couldn't get my hands on it because freesesktop.org is down
<bSON> i'll do what i can
<crimsun> bSON: coordinate w/ bluefoxicy, who has looked into it
<bSON> crimsun: ok, thanks
<bluefoxicy> ogra:  tracker appears to need nautilus to build-depend and depend on libtracker
<ogra> crimsun, bluefoxicy has looked into it ? does that mean we'll see a hardened tracker ? 
<bluefoxicy> apparently libtracker is a thin wrapper around dbus
<ogra> bluefoxicy, yes, thats how i understood it :)
<bluefoxicy> however I would consider that it does take a little time to load an extra lib
<bluefoxicy> (dynamic linking)
<bSON> it's way better than beagle with a whole run-time system
<bluefoxicy> ogra:  I thought it would be a plug-in but the ABI for search extensions is volatile so the nautilus maintainer has yet to export it, for fear that suddenly plug-ins would be made for it and then find they were incompatible due to sudden changes.
* bluefoxicy was hoping for beagle/tracker nautilus extensions and then we could wait to see what happens from there.
<ogra> well, they will come one day :)
<bluefoxicy> nods.  OH!
<bSON> bluefoxicy: that means the tracker stuff is in nautilus directly now and not in a plugin
<bSON> ?
<bluefoxicy> bSON:  if you build nautilus with tracker installed it will automatically depend on tracker.
<bluefoxicy> Jamie says:
<bSON> i understand
<bluefoxicy> I guessed that - I could provide a patch to Nautilus to make it runtime 
<bluefoxicy> selectable (with Nautilus depending on both libtracker and libBeagle) 
<bluefoxicy> but this would not make it into the main nautilus source and so it would 
<bluefoxicy> have to be maintained externally.
<bluefoxicy> bSON:  as I understand, Nautilus has both beagle and tracker code in mainline nautilus' source tree; but they can't work at the same time and they're not plug-ins, nor are they runtime selectable.  Anyhow the tracker maintainer says if you want he can patch nautilus to be runtime-selectable but you'll probably wind up maintaining that patch down here.
<bSON> so the problem is that somebody got to do and maintain it
<bluefoxicy> yeah, or more directly that there's no exported search API yet
<fabbione> Keybuk: could you be so kind to NEW libopenais2 & co.?
<fabbione> Keybuk: and please promote libvolumeid* to main (it shouldn't need any MIR since udev source it's already in main) thanks.
<fabbione> Keybuk: they are both B-D for redhat-cluster-suite already in main
<ogra> gnomefreak, did you read mdz's comments in the "update-manager vs apt-get" thread before you answered ?
<sharms> I just addressed it on the mailing list and tried to tell him via irc
<gnomefreak> ogra: no 
<gnomefreak> ill look now
<ogra> yep...
<gnomefreak> ah ok got it sorry bout that missed it
<sharms> thats one cool thing about gmail is that I can see all the messages in a thread
<gnomefreak> i use thunderbird for gmail it might have showed it but i guess i over looked it
<LaserJock> mjg59: ping?
<mjg59> LaserJock: Hi
<LaserJock> mjg59: pm'd you
<Viper550> Are any of you good at GTK coding?
<Treenaks> GTK? what's that
<Viper550> Gimp Toolkit?
<Viper550> Aren't you developers?
<Viper550> Or, is that just a joke?
<HiddenWolf> Viper550: no, really!
<toma> we like qt ;-)
<Viper550> You don't know GTK? You know GTK 2?
<Riddell> Mithrandir: what happened to the Knot release?
<Burgwork> Riddell, tomorrow, due to wine (the beverage)
<Mithrandir> Riddell: happening tomorrow morning.  I've drunk more wine than advisable for releasing cd's with.  Such things happens when parents visit.
<Riddell> they're a bad infuence on you :)
<ogra> heh
<Riddell> Mithrandir: should we be ok to upload stuff now?
#ubuntu-devel 2006-07-20
<zul> hey
<bddebian> Howdy folks
<lifeless> who here is a total X guru ?
<lifeless> I have a repeating issue after suspect with ice auth becoming non responsive :(
<lifeless> And I'd like to know what info to get, to file a useful bug on it.
<jdub> Keybuk: how are debian developers informed of totally new packages in our repos atm? (or not)
<Keybuk> jdub: they're not
<bddebian> That was going to be my guess but I didn't want to be wrong as always :-)
<jdub> deb http://people.ubuntu.com/~jdub/edgy/ /
<jdub> ^ beaglefs
<jdub> wait, don't play with that yet
* tseng halts
* bddebian tips tseng over
<tseng> bddebian: woo!
<tseng> bddebian: what are you weekend plans
<jdub> okay
<jdub> now you can play with it
<tseng> ok.
<jdub> it helps if your .deb contains the binary file it purports to
<bddebian> tseng: Dunno for sure.  I know my wife is going to the American Idol concert Sat. night. (puke)
<tseng> bddebian: double puke
<tseng> I enjoy the American Idol auditions
<tseng> where the guy is a major dick to everyone
<bddebian> Yeah, and that's about it :-)
<tseng> yep.
<tseng> bddebian: Wachovia Center?
<bddebian> I think so but I'm not sure
<tseng> nice place
<Fjodor> Erm, it would seem gksu doesn't see that it should default to sudo mode as per gconf in amd64. gksu <something> prompts for password, even though there is a NOPASSWD entry, gksu -S doesn't
<whiprush_> anyone else notice significant battery life improvements with the last kernel in edgy?
<Hobbsee> whiprush_: dont know about that - i've been doing a lot of building, but the laptop certainly seems to run better
<whiprush_> I was having pretty horrible battery performance, but thought it was just my battery going bad, but it seems to be much better since the last few days of updates.
* Hobbsee will try to remember to look :P
<Hobbsee> Kamion: argh, almost assigned the archive again, but i remembered this time :P
<fabbione> morning guys
<Hobbsee> hi fabbione!
<fabbione> hi Hobbsee 
<bddebian> Hello fabbione
<jdub> open("/var/lib/aptitude/pkgstates", O_RDONLY) = 3
<jdub> fcntl64(3, F_SETFD, FD_CLOEXEC)         = 0
<jdub> fstat64(3, {st_mode=S_IFREG|0644, st_size=140622, ...}) = 0
<jdub> fstat64(3, {st_mode=S_IFREG|0644, st_size=140622, ...}) = 0
<jdub> fstat64(3, {st_mode=S_IFREG|0644, st_size=140622, ...}) = 0
<jdub> mmap2(NULL, 140622, PROT_READ, MAP_SHARED, 3, 0) = 0xb7073000
<jdub> 
<jdub> ^ stracing aptitude search
<jdub> at this point it sits around using 100% cpu
<Chipzz> ; Please register your domains at
<Chipzz> ; http://www.cheapass.be
* ..[topic/#ubuntu-devel:irc.freenode.net] : 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 | http://wiki.ubuntu.com/HelpingWithBugs | Knot-1 freeze in effect - uploads to main frozen, ask Mithrandir for exceptions
<pitti> Good morning
<Hobbsee> hi pitti 
<bluefoxicy> holy crap, the networking dialog looks really dumbed down o_o
<pitti> no wonder I couldn't connect for 10 minutes or so
<Hobbsee> pitti: heh, it's borked
<Amaranth> Get off freenode spec, anyone? :P
<pitti> Amaranth: OFTCMigrationSpec? :)
<fabbione> it's about time to implement that
<FunnyLookinHat> Heh
<whiprush> jdub: ping
<jdub> whiprush: ppong
<whiprush> jdub: I know you're on your way out the door, but my friend at google has confirmed that they intend on hosting the ubucon right after lwe.
<jdub> whiprush: hrm - i wonder who will actually go, apart from you guys and google guys.
<whiprush> he got a response from the guy and he's going to send a mail out this week ...
<jdub> whiprush: and i wonder if anything is actually going to happen at it.
<jdub> ugh!
<whiprush> jdub: well, I'm thinking, it's in socal, surely a post on planet and a digg or two could possibly make it rock.
<sharms> whiprush: pm
<jdub> whiprush: yeah, possibly - 'specially san fran
* fabbione wonders what ubucon is and who from ubuntu is going to partecipate
<whiprush> sharms: I'm responding to you but I seem to be getting freenoded'd, can you IM me at jorge.castro@gmail.com?
<whiprush> fabbione: well, the guy in charge of LWE wanted to do an ubuntu thing after the show
<whiprush> so he announced it, and then disappeared.
<jdub> whiprush: 'in charge of lwe'?
<jdub> i thought he was just some random dude
<jdub> who had good links with google
<whiprush> jdub: not afaik, let me find a link.
<whiprush> jdub: I see him all over the linuxworld blog, john mark walker ...
<whiprush> http://www.blogger.com/profile/18000952
<whiprush> google says "director of the LinuxWorld Expo conference program"
<jdub> ah, of the conf programme
<jdub> ok
<whiprush> So, I found out about the ubuncon on digg, but past the announcement, there has been zero activity on his site or on his list, and he doesn't respond to emails.
<whiprush> but it's on things like the LWN schedule and whatnot
<whiprush> and I was planning on going, so I was thinking if, people can show up, maybe we can make something happen.
<whiprush> since apparently google has committed to hosting the event.
<jdub> yeah
<jdub> he hasn't replied to jane or i either
<whiprush> but, I've been rolling up friends, and we have at least a day's worth of ubuntu programming we can do, including the guys who did Ubuntu hacks, so if someone promised google a con, then maybe we can rescue this mess.
<jdub> rad
<whiprush> jdub: to cut to the chase, I was leaning on "hey, you know chris, can you call and find out what I need to do?" :)
<jdub> oh man, you can totally email him
<jdub> he's very helpful
<jdub> or
<jdub> i could bug him at oscon
<whiprush> it's a short notice, but I'm pretty sure we can pull it together, especially in such a geekladen environment like mountain view.
<jdub> them thar mountains
<jdub> laden with geek
<whiprush> jdub: that would work out perfect. :D
<whiprush> jdub: if chris is worried about content, then let him know I've got a pocketful of arsians ready to rock and roll wrt. ubuntu content.
<whiprush> plus I got booth duty at LWE so I'll be making sure I get the word out.
<whiprush> fabbione: if you want to make the trip I can schedule you to do some X and kernel talks. :)
<fabbione> whiprush: when that would be?
<whiprush> august 14-19
<whiprush> ubucon is the last 2 days, apparently.
<fabbione> no i can't sorry
<whiprush> it's all a corporate thing anyway, LWE, it's best to save the funds for more hacker-friendly events.
<fabbione> i have a wedding the 19 and the 20 we need to be in Germany for the hack sprint
<whiprush> fabbione: to be honest, most shows here in the US suck, so you're not missing much.
<whiprush> but jdub would be better off describing them than me. :D
<fabbione> well let me decide that
<fabbione> that as in what sucks and what not
* whiprush nods
<whiprush> fabbione: there is a newer show here in the midwest US, the ohiolinuxfest, which rocks, it's a one day event, I can send you some info via mail if you're interest, sep 30.
<fabbione> whiprush: nah thanks
<fabbione> a one day event surrounded by 2 days travel is like kicking somebody in the testicles
<fabbione> with the difference that the testicles will stop to hurt after 5 minutes
<whiprush> fabbione: yeah, I know you're from another country, but I do my best to find content for the show, so I gave it a shot. :D
<fabbione> eheh sure
<jsgotangco> hahaha
<G0SUB> pitti: hello
<pitti> hey G0SUB, how are you?
<G0SUB> pitti: i am fine, i mailed you just now. please check
<pitti> G0SUB: if you want to lock into a small room with just a computer and pizza to hack for a week, that's fine :)
<G0SUB> pitti: that's what I want. really
<pitti> G0SUB: a meeting is not required, only if you want to discuss about something
<G0SUB> pitti: i am badly behind schedule, so there is n other way.
<G0SUB> pitti: i have already talked to pygi wrt the GUI. he will assist me in getting it right when I am ready
<pitti> G0SUB: ok; the backend should really work in a week
<G0SUB> pitti: yes, it will. with the command line frontend
<G0SUB> pitti: ok, so I will leave now. see you.
<pitti> G0SUB: see you, happy hacking!
<dholbach> good morning
<Mithrandir> 'morning, Daniel
<dholbach> hey Tollef - how are you?
<Mithrandir> good, I can feel the knot loosening up now.
<Mithrandir> ;-)
<sladen> makes it sound like constipation!
<pitti> Mithrandir: 'Straight-Cord-1'? :)
<dholbach> :)
<Mithrandir> pitti: ;-)
<Kamion> Mithrandir: shout if publish-release hates you
<fabbione> hey Mith
<fabbione> hey Kamion 
<Kamion> (morning)
<pitti> Hi Colin, how are you?
<Kamion> hot
<Kamion> and not in a good way
<Mithrandir> Kamion: seems good so far.
<fabbione> Kamion: when you have time could you be so kind to NEW libopenais2 and move libvolumeid* to main (the latter being part of udev source)
<fabbione> Kamion: they are both B-D of the redhat-cluster-suite
<Kamion> ok
<fabbione> Kamion: it's not urgent
<fabbione> even after knot is fine
<Kamion> I'll just do a NEW pass now, it's been a bit neglected
<fabbione> i still need the new headers for the suite to be able to build
<Mithrandir> hmm, did we want to do an ubuntu-server knot-1 release too?
<Kamion> Mithrandir: why not
<Kamion> oh, you know how to publish server, don't you?
<Mithrandir> Kamion: yeah.  We do want to build it first, though.
<Kamion> oh
<Kamion> I'll do that
<Mithrandir> thanks
<Mithrandir> hmm
* Mithrandir goes to clean out the dapper images from /srv/cdimage.ubuntu.com/www/full/edubuntu/daily-live/20060719.1
<Kamion> fabbione: does that /etc/ld.so.conf.d/openais.conf thing actually work?
<fabbione> Kamion: yes
<Kamion> interesting
<Kamion> weird, but interesting
<Mithrandir> Kamion: ld.so.conf.d is something we've dragged in from Debian, iirc.
<fabbione> cat  ld.so.conf
<fabbione> include /etc/ld.so.conf.d/*.conf
<pitti> /etc/ld.so.conf.d/$machine-$os ??
<fabbione> Kamion: yeah i did check it too when i first saw it
<pitti> ^ that looks like quoted once too much
<pitti> s/much/often/
<fabbione> pitti: i have seen a couple of different way to call those conf files
<fabbione> pitti: also $source-$arch.conf
<pitti> fabbione: yes, but a literal '$machine-$os' as filename looks wrong
<pitti> looks like it was intended to be 'linux-amd64' or so
<fabbione> pitti: yeps.. you really want $binary.conf or something
* fabbione reduces the cluster patches from 13 to 4
<fabbione> other 9 accepted upstream
* fabbione pats himself for being cool
<Kamion> fabbione: new/override changes done
<fabbione> Kamion: thanks a lot
<fabbione> Kamion: would you object a lot for a UVF exception for the redhat-cluster-suite? the only changes are our local patches that have made their way upstream and 2/3 bug fixes i did backport
<fabbione> it's basically the same source with 2 different names...
<fabbione> s/names/versions
<Mithrandir> ogra: can you look at http://cdimage.ubuntu.com/edubuntu/daily-live/current/ ?  I don't think the header text is correct for edubuntu?
<Kamion> hmm, yes, that should have the old live CD text really
<Mithrandir> do you have that around somewhere?
<Kamion> yes
<Kamion> Mithrandir: make-web-indices again and you'll get it
<Kamion> or, publish-release will do it
<Mithrandir> well, I've already run publish-release for edubuntu
<Kamion> ok, 'for-project edubuntu make-web-indices /srv/cdimage.no-name-yet.com/www/full/edubuntu/releases/edgy/knot-1 edgy' should fix it then
<Mithrandir> yeah, just figured that out.
<Mithrandir> uh, the edubuntu live cd doesn't actually give you the option of installing, does it?
<Kamion> should do?
<Kamion> it has ubiquity on it
<Mithrandir> oh, ok.
<Mithrandir> I thought it didn't.
<Kamion> it'll only install a workstation, but shrug
<Kamion> it's not promoted in the same way as the other derivatives because it doesn't let you install an LTSP server or whatever
<Mithrandir> yeah
<Mithrandir> Kamion: ubuntu-server ready to be published?
<Kamion> sladen: xaralx binaries accepted
<fabbione> Mithrandir: unlikely.. 
<fabbione> Mithrandir: but you can try if you want
<Kamion> Mithrandir: ports didn't build
<Kamion> but the main build should be fine
<Kamion> (cdimage-wise)
<dholbach> morning mdz
<mdz> morning
<Mithrandir> Kamion: hmm, ok.  They're supposed to be published in their own tree or into the ubuntu tree now?
<Kamion> into the ubuntu tree
<Kamion> so publish-release daily ../ubuntu-server/daily/20060720 ...
<Kamion> must simplify that at some point
<Mithrandir> for-project ubuntu publish-release daily ../ubuntu-server/daily/20060720 server no should work, then
<Mithrandir> (yes, I know for-project ubuntu is a no-op, but I still like to do it)
<Kamion> nod
<Kamion> add knot-1 to the end of that command
<Mithrandir> uh, true.
<Mithrandir> I wonder where that went.
<pitti> G0SUB: still here?
<G0SUB> pitti: yes?
<pitti> G0SUB: nevermind, sorry (I had a python-apt question, but I found it out now)
<G0SUB> ok
<Mithrandir> maswan: any chance I could ask you to run a mirror sync?
<pitti> hey knopper 
<Kamion> infinity_,BenC,iwj,doko_,ogra,seb128,Mithrandir: you guys are all even later than me at filling out DistroTeamMeeting20060720 :-)
<Kamion> (others too, but they aren't here)
<Mithrandir> Kamion: yeah, I suck, I know.
<seb128> ah, right
<Mithrandir> seb128: does knot-1 have a new gnome?
<torkel> Mithrandir: I don't think he is awake yet
<dholbach> Mithrandir: it has 2.15.4 (minus some modules, which didn't make it)
<dholbach> torkel: he is
<Mithrandir> Riddell: does your knot-1 have anything particularly interesting you want to note?
<Mithrandir> dholbach: ok, thanks.
<dholbach> 2.15.90 next week - YAY!
<Kamion> Mithrandir: https://wiki.ubuntu.com/Testing/Kubuntu/Edgy/Knot1
<torkel> dholbach: ok. He has not showed up at the office yet though :-)
<Mithrandir> Kamion: that was an odd URL to put such information at, but ok.
<Kamion> Mithrandir: I agree, just happened to find it by a search a moment ago
<seb128> Mithrandir: 2.15.4 yep, and GTK 2.10 :)
<dholbach> torkel: seb128 talked to me an hour ago already
<Kamion> whoa
<Kamion> https://launchpad.net/distros/ubuntu/+spec/ubuntu-server-tasks
<Kamion> when did that dependency tree appear?
<seb128> torkel: speaking of me?
<dholbach> whoa, nice
<torkel> dholbach: I was speaking of maswan...
<dholbach> torkel: ok, sorry then :)
<Mithrandir> torkel: ah.  Can you trigger the mirror for us?
<torkel> dholbach: np :-)
<torkel> Mithrandir: nope. sorry. I don't have super cow powers at ACC...
<maswan> Ok, guys, I just woke up. The mirror run is at :13 though, so I should rather rush off to work than make the sync go 2 minutes earlier. :)
<Mithrandir> maswan: ah, ok.  You're mirroring hourly now?  (Including cdimage?)
<maswan> Mithrandir: Oh, no, just archive.
<maswan> Mithrandir: You want a cdimage sync? And/or release sync?
<torkel> maswan: ah, you are awake. Not need to call you then... :-)
<pitti> maswan: any chance to run at :43 instead of :13? lp_archive usually finishes around :30
<Mithrandir> maswan: cdimage, please.
<pitti> maswan: :43 would reduce the lag of security updates
<Mithrandir> maswan: no need for release syncs, unless I've seriously fucked up. :-P
<maswan> pitti: Ok, done. We're likely to move security back to the DC soon though. I just need to wake up, get to work, do work stuff, then talk to Znarl a bit.
<Kamion> pitti: no it doesn't
<Kamion> takes much longer than :30
<pitti> maswan: thanks
<pitti> Kamion: oh, since when?
<Kamion> :50 would be a better bet
<Kamion> for ages
<pitti> *grump* some weeks ago :30 to :35 was fine
<maswan> :53 now
<Kamion> maswan: sounds good, thanks
<pitti> Kamion: thanks
<pitti> maswan: merci
* maswan runs off to work
<Kamion> cron.daily mails usually arrive between :44 and :47 at the moment, but of course you then have to allow a bit of time for internal mirroring
<Kamion> I'm not sure exactly when that finishes
<seb128> Kamion, mdz: do I need an UVF mail to update xchat-gnome to a new version? It's mainly bug fixes, it adds a "unread line" as xchat and support passwords to join a chan from the UI now
<Kamion> does xchat-gnome follow the GNOME release schedule?
<seb128> no
<seb128> they tend to roll a tarball every month
<seb128> but they have no freeze, etc
* Kamion looks through changelogs
<Mithrandir> http://err.no/tmp/knot-1.txt ; please proofread.
<seb128> Kamion: I'm fine sending an UVF mail to make your job easier if you want to have a look on changes for it
<Kamion> seb128: no, looks ok to upload
<seb128> ok, thank you
<Kamion> Mithrandir: s/caldron/cauldron/ normally although I suppose it might have been an old spelling ...
<StevenK> Mithrandir: Kernel version is not 2.17
<Kamion> Mithrandir: s/primary changes from Dapper has been/primary changes from Dapper have been/
<StevenK> Mithrandir: Maybe a comma after Ubuntu in "In Ubuntu GNOME has been updated to 2.15.4 ..."
<Kamion> yeah, I was about to say tat
<Kamion> that
* StevenK high fives Kamion
<Kamion> Mithrandir: "Notable Kubuntu changes are noted" sounds bad. "Notable Kubuntu changes are listed" perhaps
<Kamion> Mithrandir: "malone" => "Malone:"
<Kamion> Mithrandir: has the default theme been fixed? I haven't tried the most recent round of images
<Riddell> looks good with Kamion's change, thanks Mithrandir 
<iwj> LaserJock: pong
<Kamion> ogra: I've renamed server to server-ship. When you merge it, be careful; you want to end up with a server-ship seed that has the same contents and bzr id as the server-ship seed in Ubuntu, and a server seed that has the same contents as what you have in Edubuntu now
<Kamion> ogra: do you want me to do that merge? getting it such that future merges are clean might be delicate
<Kamion> ogra: actually, I've got a merge done locally anyway, I'll just commit that ...
<Mithrandir> StevenK: fixed.
<Riddell> Kamion: does that apply to kubuntu too?
<Mithrandir> Kamion: fixed.
<Kamion> Riddell: no
<Kamion> Riddell: you can just do an ordinary merge and it'll DTRT
<StevenK> Mithrandir: What about the second change I suggested?
<Kamion> Riddell: but Edubuntu already has its own server seed which I'm now divorcing from the Ubuntu server seed, since they have different meanings
<Riddell> ok
<Mithrandir> StevenK: I noticed it myself.
* StevenK nods.
* StevenK checks again.
<StevenK> Mithrandir: s/\(Malone\)/\1:/
<Mithrandir> thanks, fixed.
<StevenK> Mithrandir: Looks fine to me.
<Mithrandir> thanks.
<StevenK> And that Shakespeare quote. Ouch.
<Mithrandir> well, I'm not going to mangle Shakespeare. :-)
<Kamion> StevenK: ouch?
<Mithrandir> Kamion: caldron, I think.
<StevenK> It's been a while since I read Macbeth, I seem to recall that quote not being so brutal-sounding.
<Kamion> Mithrandir: my version has cauldron. :-)
<Kamion> Mithrandir: oh, "howlet" -> "owlet"; that's what my version has and it makes a lot more sense to modern readers
<Mithrandir> Kamion: URL so I can C&P?
<Kamion> Mithrandir: http://www.shakespeare-online.com/plays/macbeth_4_1.html
<StevenK> I was half tempted to grab the dead tree copy my wife more than likely has around here.
<Kamion> I'm sure we have one but it would take a while to dig it out
<Mithrandir> Kamion: ok, better now?
<Kamion> Mithrandir: much, thanks
<ogra> Kamion, thanks for the merge
<mdke> so bugs should be filed on edgy now, rather than on ubuntu?
<mdke> "There are currently no open bugs."
<dholbach> filing on ubuntu is fine
<mdke> dholbach: which is preferred?
<dholbach> if you have a bug that needs fixing in edgy and dapper, you'd file it on ubuntu and add a dapper task
<mdke> right now it seems that only 18 bugs have a dapper task
<seb128> mdke: no need to add a dapper task if we don't intend to backport a fix
<dholbach> mdke: we only fix serious stuff in dapper
<mdke> yes.
<mdke> so bugs in edgy should have an Ubuntu task, or an Ubuntu Edgy task?
<seb128> ubuntu
<mdke> Mithrandir: ^^
<seb128> ?
<mdke> the bug report link on the knot release announcement needs to be adjusted
<Kamion> ur. bugger
<Mithrandir> mdke: hmm?
<Kamion> Mithrandir: you haven't sent that yet have you?
<Mithrandir> Kamion: not yet, waiting for the nl mirror to sync.
<Mithrandir> Kamion: why?
<Kamion> Mithrandir: https://launchpad.net/distros/ubuntu/edgy/+filebug -> https://launchpad.net/distros/ubuntu/+filebug
<Kamion> the /edgy/ there does obsolete things
<Mithrandir> hm, ok.
<Mithrandir> changed now
<mdke> I wonder if +bugs would be a better link
<Mithrandir> *shrug*; either is fine with me.
<mdke> it might encourage people to search for dups
<Mithrandir> that's a nice theory, if nothing else. :-P
<Mithrandir> (changed)
* pygi wonders who's evolution's maintainer
<pygi> ...so he doesn't have to look :P
<seb128> pygi: there is none
<seb128> pygi: if you have a question ask to dholbach or me 
<pygi> seb128: there is a new patch which removes 40-60MB of memory usage,...but you probably already know that
<seb128> mmap?
<seb128> no way
<pygi> :P
<seb128> we have enough bugs without using an alpha patch with many issue changing the way evolution stocks its datas and which might be an issue on NFS by example
<seb128> you deserve some good kicking for thinking about it :p
* pygi kicks himself =P
<seb128> you really suggest using an alpha patch against upstream for something like that?
<pygi> no, I was just wondering, don't eat me pls :)
<seb128> so no need to wonder
<seb128> we are not going to use that patch before upstream
* pygi nods :)
<seb128> pygi: BTW I'm not sure it spares that much on memory usage, those numbers seems to be on loading, not on constant use 
<pygi> seb128: indeed
<mdke> iwj: around?
<iwj> mdke: Y
* sladen congratulates simira on being the first person to test knot-1
<simira> sladen: working on it, at least. Installing Dapper final first, I am already stuck on partman. So... Kamion, where do you want the bug reports?
<ogra> mdz, mind to give an opinion on a ltsp change i plan ? 
<Kamion> simira: debian-installer
<Kamion> if you don't know more accurately
<simira> Kamion: not directly on partman? currently it's the partitioning that goes wild.
* ..[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 | http://wiki.ubuntu.com/HelpingWithBugs
<Kamion> simira: no, there's no partman package at present
<Kamion> (you might find one in LP, but it's obsolete)
<Kamion> partman is made up of a number of components
<Mithrandir> (that is, we're no longer frozen)
<Mithrandir> just UVF.
<ogra> ya
<ogra> y
<Mithrandir> so, go wild.
* ogra goaes wild 
<simira> Mithrandir: my installation already did
<ogra> *goes too
* ogra notes its to warm to go wild and stops again
<rodarvus> Hooray \o/
* dholbach hugs Mithrandir
<dholbach> hey rodarvus
* Mithrandir hugs dholbach back
<dholbach> ROCK ON :)
<rodarvus> dholbach: hi there! :)
<mdz> ogra: what's the change?
<mdz> I'm leaving for lunch in about 2 minutes
<ogra> mdz, i just wanted a second opinion on genererating the sshkeys for ldm through if-up.d
<ogra> but rodarvus already gave his opinion :)
<ogra> s/generating/copying/
<ogra> mdz, enjoy your tapas :)
<thom> pitti: how is cryptdisks-early supposed to work? currently it just bitches vigorously that it doesn't have the right devmapper, doesn't have the right cyphers, and then forces me to hit enter $check times to get to the real cryptdisks startup by which point everything works
<Kamion> simira: bug 53511, is that the desktop CD installer or the text-mode installer?
<Ubugtu> Malone bug 53511 in debian-installer "Partitions doesn't appear correctly in the "Prepare partitions" part (Dapper Final)" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/53511
<pygi> sivang: poke poke
<simira> Kamion: the cd, yes. I'll add that
<Kamion> simira: which CD? :-)
<Kamion> if you mean the desktop CD, sorry, I gave the wrong answer earlier - bugs on that installer go against ubiquity
<simira> Kamion: ok, I guess I should have made that clear. I'll move the bug.
<Kamion> simira: thanks
<simira> Kamion: bugs for edgy coming up soon ;p
<Kamion> simira: good :)
<zul> hi
<simira> what is this kind of madness???
<simira> (booting edgy desktop cd)
<Kamion> huh?
<simira> Kamion: just the background pic on boot. A bit ... messy.
<tseng> simira: the usplash test card?
<simira> yup
<tseng> multi colored boxes with gradings
<tseng> yeah, thats for testing.
* Hobbsee looks in
<Hobbsee> is the freeze really over?
* Hobbsee wants a couple of uploads.
<Kamion> Hobbsee: yes
<Hobbsee> Kamion: yay!
<doko> fabbione: is there some documentation about snakeoil certificates?
<doko> dholbach: is there some documentation about dh_iconcache?
<Hobbsee> doko: what did you want to know about dh_iconcache?
<dholbach> doko: hm, with the comments in /usr/bin/dh_iconcache, i thought that it'd produce a manpage, somehow   man dh_iconcache  does not work, hrm
<Hobbsee> doko: i think there was originally a page on "this is why we're making this dh_iconcache change", if you were looking for that
<dholbach> doko: http://wiki.ubuntu.com/DhIconCacheChanges
<seb128> doko: what do you need to know about it?
<doko> dholbach, seb128: I was looking for something that I could use for https://wiki.ubuntu.com/UbuntuPackagingChanges
<dholbach> doko: ah ok
<Hobbsee> oh yeah, guess new packages still need that, dont they...
* Hobbsee thought they were all done (finally)
<seb128> doko: what is the wiki page about?
<seb128> doko: explaining changes we have over Debian or something else?
<doko> seb128: https://wiki.ubuntu.com/UbuntuPackagingChangesSpec
<seb128> doko: basically dh_iconcache is "update GTK icon cache" and is useful for "any package shipping an icon to /usr/share/icons/some_theme"
<Hobbsee> doko: shouldnt be hard.  rationale is that mailing list thing, affected packages are anything that installs files into those two directories
<doko> seb128: in /usr/share/icons/some_theme or /usr/share/icons/ ?
<dholbach> doko: they all ship to <somet_theme>
<seb128> doko: is there anything dropping an icon directly to /usr/share/icons? that would be a bug
<seb128> doko: the icons are meant to be part of a theme, which is a why the some_theme directory
<dholbach> and the some_theme/index.theme gives instructions on how the theme "works"
<seb128> dholbach: that's not revelant for dh_iconcache
<dholbach> without that dh_iconcache skips the directory
<dholbach> OOo ships to locolor which has no index.theme
<dholbach> which is ... a bit weird :)
<seb128> OOo is bugged 
<seb128> icons are not used in that case
<seb128> nothing to do with the cache 
<dholbach> yeah
<seb128> keep it easy
<seb128> <seb128> doko: basically dh_iconcache is "update GTK icon cache" and is useful for "any package shipping an icon to /usr/share/icons/some_theme"
<seb128> that is good enough as a summary probably
<doko> dholbach: can you fix  the missing index.theme?
<seb128> dholbach maintains OO.o :)
<dholbach> doko: i'd suggest to use the hicolor index.theme
<dholbach> forget it
<dholbach> i'm off - bye
<dholbach> :-p
<seb128> dholbach: come on, it's a funny package I'm sure :p
<seb128> doko: nice try, didn't work apparently though :p
<dholbach> seb128: you had the sun shining on your head for too long, if you ask me
<seb128> dholbach is not that easy to trick into OOo maintainship :p
<dholbach> seb128: what do you think why doko makes me drink cocktails all the time... apparently i never got drunk enough to take over :)
<seb128> dholbach: possible, it's too hot here :)
<seb128> hehe
<Kamion> dholbach: is there any chance dh_iconcache will ever go back to Debian?
<seb128> there is a bug to the BTS about it
<Kamion> ah good, I think last time I looked there wasn't
<seb128> but Debian guys don't like that all packages have to be transitioned together ...
<seb128> so there is some open discussion
<dholbach> Kamion: what seb128 said. the gtk-gnome team has a proposal but didn't take it forward yet
<dholbach> they need to take the transition slower than we did
<Hobbsee> dholbach: i hate the idea of updating all their packages like we did.  assuming they have way more packages.  ouch.
<maswan> Mithrandir: sync finally done, don't know why it took so long, but for some reason it didn't want to pull more than 1-2M/s
<seb128> Hobbsee: they don't
<dholbach> Hobbsee: they don't have more packages, it's just there are more maintainers involved, migration to testing, etc
<seb128> Hobbsee: you know, we do sync on Debian, so we have the package they have
<seb128> packages they have
<Hobbsee> seb128: yeah, i do know that.  for some reason, my brain was expecting that there was a section of debian we didnt sync from.
* Hobbsee wonders if her sync got approved.
<seb128> Hobbsee: the issue is that it requires the different maintainers to upload their packages, you can get dholbach uploading everything that needs to be transitioned :p
<Hobbsee> more architectures to build on too, although i guess they have more build machine
<Hobbsee> seb128: yeah, true.  :P  or me too
<Hobbsee> *to
<dholbach> seb128: is still angry that i touched kde packages
<dholbach> he doesn't get over it easily
* seb128 hugs dholbach
<Hobbsee> haha
<dholbach> ;-)
* Hobbsee touched a gnome package.
* dholbach hugs seb128 back
<dholbach> Hobbsee: and it felt good, didn't it?
<ogra> haha
<Hobbsee> dholbach: no, it felt horrible, and it had so many icky dependancies to install.
<Hobbsee> hi ogra 
<ogra> hey
<dholbach> haha
<dholbach> see you later
<Hobbsee> bye dholbach 
<seb128> dholbach: have fun
<ogra> enjoy the sun
<Mithrandir> maswan: thanks
<Hobbsee> hi Mithrandir!
* Hobbsee tickles Mithrandir 
<Hobbsee> whiprush: you may well be right, w.r.t. laptop power
<Keybuk> meh, do I upgrade my desktop to edgy or leave it on dapper?
<Hobbsee> Keybuk: upgrade to edgy.  breakage is fun.
<Keybuk> Hobbsee: heh, breakage of one's primary machine isn't
<Hobbsee> Keybuk: sure it is.
* Hobbsee has one laptop.
<Kamion> Hobbsee: we don't autosync from contrib/non-free, only on request
<Kamion> (at present)
<Kamion> but there's really not a huge amount in there
<Hobbsee> heh.  so i was right :P  true
<Hobbsee> Kamion: did you see/process my sync?
* Hobbsee hopes she did it right.
<Kamion> I saw it, haven't done a sync run since though
<Hobbsee> Kamion: cool, okay.
* Hobbsee makes a note not to run rm -rf on the folder that contains kdar, depending on that :P
<simira> and live in from Edgy Knot 1 we've got Simira!!!
* jsgotangco showers confetti at simira
<Hobbsee> simira: yay!
* Hobbsee coats simira in flour
<simira> *coughs*
<Hobbsee> heh :P
<Keybuk> mdz: you so should be in the UK this week
<Keybuk> it'd cure ALL your bitching about how the UK weather is never hot enough
<mdz> Keybuk: I will be there next week
<thom> it'll probably rain all next week
<Keybuk> oh, any special occasion?
* Hobbsee considers bitching about it being cold here.
<mdz> and for the record, I don't complain so much about the cold as about the rain
<mdz> Keybuk: no, just stopping in for a few days on my way home
<Hobbsee> hi bddebian 
<thom> Hobbsee: aussies have no understanding of what weather actually is
<Hobbsee> thom: :P
<Keybuk> mdz: ah, how has spain been?
<mdz> hot
<Mithrandir> Hobbsee: it's just +25C?
<Hobbsee> Mithrandir: more like 10C outside, more like 20C in here
<thom> like i said...
<ogra> mdz, i thought you complain about the clouds 
<Keybuk> man, LWN is heavy going today ... it's huge with all these kernel summit summaries
<bddebian> Heya folks
<bddebian> Hi Hobbsee
<mdz> ogra: that too
<mdz> ok, back to the mines
<Mithrandir> Kamion: hmm, Simira just did an install here and seems to be bitten by the apt-setup bug.
<simira> (it didn't hurt very much, just a small itch)
<simira> should I report/comment it somewhere?
<Kamion> simira: details?
<Kamion> simira: anyway, yes please, bug on apt-setup with /var/log/installer/syslog attached
<Mithrandir> Kamion: just security repos enabled in sources.list, nothing else.
<Kamion> ok
<Kamion> oh also /var/log/syslog (before reboot) please if this was a ubiquity install
<Kamion> unless you've already rebooted in which case I guess I might lose, but we'll see
<Kamion> need to get round to unifying those
<simira> Kamion: sorry, I already bootet. I seldom check sources.list before the boot ;)
<Kamion> well, do the best you can log-wise then
<simira> Kamion: it won't add empty files (syslog)
<Kamion> check whether it's really empty or just only readable by root
<simira> weird
<fabbione> doko: what kind of documentation are you looking for'+
<fabbione> ?
<simira> Kamion: do you want the version file also?
<Kamion> simira: no
<doko> fabbione: just what consists of a patch for a snakeoil-cert change
<fabbione> doko: you mean how a package need to be changed to use the snakeoil-cert?
<Gloubiboulga> Mithrandir, hello, is there a problem with the xubuntu Desktop CDs? 
<Kamion> Gloubiboulga: very oversized
<Gloubiboulga> Kamion, oh, ok
<Kamion> live fs build logs are here if you want to investigate: http://people.ubuntu.com/~cjwatson/livefs-build-logs/edgy/xubuntu/current/
<Gloubiboulga> thanks
<doko> fabbione: yes
<ogra> Gloubiboulga, http://cdimage.ubuntu.com/xubuntu/daily/current/report.html is a rough indicator for oversizedness
<Kamion> daily-live not daily
<Kamion> (there is no report.html for daily-live)
<ogra> oh, right 
<ogra> but .OVERSIZED files (sometimes :) )
<fabbione> doko: there isn't much of an howto. snakeoil gives you a (fake) cert in standard path. Your package can Depends: and use that certificate as it please (modulo remove it).
<Kamion> since the alternate CD is apparently not oversized, its report.html isn't too useful in this case
<ogra> yup
<fabbione> doko: you want to notice that the secret part of the cert is also special group readable. so if your daemon or wahtever does not run as root, can still gain read access if you in postinst make that daemon part of the group
<fabbione> doko: you can see how pitti did pqsql
<Gloubiboulga> I guess we'll have to remove some language packs
<rodarvus> guys, just for a quick update on X.Org -> UVF excpeption has just been authorised by mdz, x11proto-* are on their way to the archive right now. As usual, further updates on this topic will occur on #ubuntu-x
<Kamion> jesus, *how* many language-support-*?
<Kamion> Gloubiboulga: I'm sure I've commented before on the unwisdom of having lots of language-support-* on the CD
<Kamion> the other CDs just have language-support-en
<rodarvus> I apologize in advance for any brokeness that might happen during the process :D
<fabbione> rodarvus: you are a good guy with good hopes.. 
<doko> fabbione: ok, I that should suffice
<fabbione> rodarvus: people will still hunt you down :PO
<ogra> rodarvus, yippie !
<Gloubiboulga> Kamion, Jani added language-packs for dapper because we had some free space, he hasn't changed this for Edgy I guess
<ogra> we know where to send angry users, dont worry :)
<rodarvus> :)
<Kamion> Gloubiboulga: nod
<jsgotangco> expect a death threat or two lol
<simira> Kamion: everything seems to work too well, though, so don't you guys break too much!
<ogra> simira, we havent even started yet :)
<ogra> feature development *ends* on sept 7, expect some funny weeks ahead :)
<simira> ogra: *sigh* It works NOW
<Hobbsee> heh
<pitti> ogra: actually, I think the debian sync rave should have accounted for the majority of breakage (package-wise, at least)
* Hobbsee goes off and breaks the archive then :P
<ogra> pitti, do you have any features that involve packaging ? 
<ogra> i dont :) 
<pitti> ogra: I have some that involve all packages, okay :)
<ogra> i'll just break code :)
<pitti> ogra: but packag*ing*, only two new packages
<pitti> ogra: so I'm better off, I add new broken code :)
<ogra> hehe
<Kamion> infinity,BenC,doko,sfllaw: ping, #ubuntu-meeting
<Kamion> missing heno
<doko> Kamion: already there
<Kamion> doko: ok, thanks, I was a bit lagged working out who was/wasn't there
<Kamion> and irssi's tab completion was confusing me
<seb128> pitti, ogra: better to discuss here or after the meeting
<pitti> seb128: ack
<seb128> vuntz: around?
<ogra> yup
<vuntz> seb128: yes
<seb128> vuntz: we are annoyed by gnome-power-manager 2.15, it apparently requires hal policykit which a CVS feature still being worked and discussed ... do you know what if that's a concern for GNOME too?
<seb128> vuntz: like 2.16 will not depends on hal CVS, will it?
<vuntz> seb128: we don't know that
<vuntz> seb128: can you send a mail to release-team?
<vuntz> we have a meeting tomorrow to discuss this
<vuntz> s/this/modules inclusion/
<seb128> ok, will do, thank you
<seb128> I'm not subscribed to the list, will somebody moderates it? :p
<seb128> or is the list moderated every n weeks and I should ping somebody about it after sending? :)
<vuntz> seb128: it should work
<vuntz> if you need moderation, ping me :-)
<seb128> ok
<bddebian> WTF should the GLwM library be?
<Kamion> something we removed
<Kamion> if it's anything to do with GLw
<Kamion> which is mesa's widget library thing that needed lesstif in main
<bddebian> Ahh, so we don't have it?
<vuntz> seb128: btw, did you discuss this with the g-p-m maintainer?
<seb128> vuntz: like upstream maintainer or ubuntu one?
<bddebian> Kamion: libgl1-mesa-swx11-dev seems to provide the headers.  Are you saying we aren't providing the libraries themselves?
<seb128> vuntz: ogra pointed he's blocked to package g-p-m 2.15 due to that
<seb128> vuntz: he's going to mail upstream about it but has not done yet
<vuntz> upstream
<vuntz> cool
<fabbione> bddebian: we don't provide the libraries no
<ogra> vuntz, hughsie just moved houses and was only online via gprs ...
<Kamion> bddebian: right, we killed GLw
<vuntz> ogra: can you cc the release-team? :-)
<ogra> vuntz, will do
<bddebian> Eeks
<Kamion> it had like four rdepends, several of which were removable anyway
* vuntz hugs ogra 
<seb128> ogra: today? :)
* ogra hugs vuntz 
<ogra> seb128, yes
<seb128> ok, thank you
<bddebian> Kamion or fabbione: So any idea what I should do about grass?
<fabbione> bddebian: what's grass?
<ogra> bddebian, whats wrong ? 
<bddebian> Besides smoke it ;-P
<Mithrandir> bddebian: smoke it! :-)
<dholbach> haha
<fabbione> (other than the green thing you smoke)
<bddebian> Mithrandir: ;-P
<Mithrandir> jinx
<ogra> fabbione, GIS system 
<ogra> editing/creating maps etc
<bddebian> ogra: It build-deps libgl1-mesa-swx11-dev and looks for Glw libs
<fabbione> ogra: ah ok
<bddebian> http://pastebin.us/1702
<Mithrandir> bddebian: port it to SDL or write an API-compatible replacement for libGLw which uses SDL or GTK or something.
<ogra> bddebian, fix the build dep ? 
<fabbione> ask for green removal from archive
<seb128> vuntz: looks like g-p-m has a --disable-policykit configure option, sorry for the noise, I'll look next time before pinging you about what orgra said
<seb128> pitti, ogra: g-p-m has a --disable-policykit
<seb128> fedora is packaging it using that flag
<seb128> looks like it's no issue
<ogra> seb128, yes, ten it doesnt suspend/hibernate anymore :P
<pitti> seb128: \o/
<ogra> i already tried it :)
<pitti> ogra: teaching it to use pmi is too hard?
<seb128> ogra: are you sure?
<ogra> yes i am
<tseng> ogra: it doesnt support if you build with with policykit and pk isnt there, too
<tseng> support suspend
<ogra> (i spent two days with this package ...)
<seb128> ogra: I'm surprised that fedora guys just dropped suspend and hibernate like that
<ogra> seb128, they run suid scripts 
<ogra> they can just use the gconf key and set it to /sbin/hibernate
<pitti> ogra: eek
<pitti> ogra: why the heck don't they use hal 0.5.7's power backends?
<pitti> hi mdz
<seb128> ogra: ok, better to mail GNOME list and upstream then 
<ogra> pitti, i must admit i havent looked into their 2.15 package yet ... its what they did in 2.14
<ogra> seb128, yep
<pitti> ogra: right, for this purpose we needed hal 0.5.7 in dapper, AFAIR
<pitti> ogra: that worked reasonably well, I think
<ogra> hughsie should also be available on irc again  ... i'll see if i can catch him after meeting
<pitti> ogra: (hey, don't get me wrong, I'm not blaming you :) )
<pitti> iwj: the changelog doesn't really look promising, though
<iwj> I didn't look at it ...
<iwj> You mean the `patches to fix regressions' ?
<pitti> iwj: I just looked at the .changes (a signed one, yay... :) )
<iwj> The latest in ftp.debian.org is sarge5 so there were quite a few attempts and you only see the last one there (lack of -v).
<pitti> iwj: oh, you mean sarge8 had the actual fixes, and sarge9 only some fixes of the fixes?
<iwj> I think so (that's what I guess - I didn't look at sarge8).
<iwj> Presumably sarge6 were the fixes and sarge7 the fixes to the fixes, which makes sarge9 the fixes to the fixes to the fixes to the fixes or something.
<pitti> iwj: ah, I just looked at the sarge8 changelog, that has quite a bunch of fixes
<pitti> iwj: but sarge8 changelog is from mid-june
<iwj> Yes, it's taken them a while.
<pitti> iwj: erm, wait, I'm confused. we already have 1.0.8
<iwj> I mean 1.0.9.
<pitti> iwj: it's a common 1.0.9 tarball that we are looking for
<pitti> iwj: yep, ok, so we want the 1.0.4-2sarge8 + 9 changes
<fabbione> BenC, ogra: the setup is simple
<fabbione> you need machine A to export a block device via AOE for example
<fabbione> (doesn't need to be x86)
<fabbione> then you need machine B and C that will play cluster
<fabbione> the cluster setup is easy
<fabbione> you import the device from A to B and C
<fabbione> format with GFS and/or GFS2
<fabbione> start the cluster in minimal setup
<fabbione> mount GFS/GFS2 read/write to it
<fabbione> no need to play dbench with a million instances
<fabbione> right now the bug we need to hunt down doesn't allow you to get that far
<fabbione> BenC: unfortunatly the cluster stuff still doesn't run properly on sparc. i am working with upstream to get that fixed
<pitti> dholbach: I'll make some time for the motu school
<fabbione> so who wants to take it?
<dholbach> pitti: you rock - i think i'll do the "package update" session soon, now that I watched seb128 in awe for a long time ;)
<BenC> fabbione: I have a xeon/k8/ia64/hppa "cluster"
<fabbione> xeon/k8/ia64/ppc should be good
<fabbione> you can use ppc to export the AOE device
<ogra> fabbione, i only have a bunch of laptops, but after my move is done i'll hapily test for you
<fabbione> it can just be a 2GB file loopback mounted and exported with vblade
<fabbione> that i know it works
<fabbione> BenC: xeon-k8 cluster is perfectly fine
<Petaris> ajmitch: ping
<Petaris> ajmitch: Are you still working on AD integration?
<fabbione> BenC: does it sound to scary?
<Hobbsee> Petaris: not a chance you'll catch him now
<seb128> pitti: how do you manage to crack on so many things in the same time :)
<BenC> fabbione: Scary yes...too scary, never :)
<Petaris> Hobbsee: Ahh, ok
<fabbione> BenC: hehe ok, should we arrange a session tomorrow around 2am UTC so i can help you setup the environment?
<pitti> dholbach: oh, it's *today*? argh, I have a concert this evening
<Hobbsee> Petaris: 4am there
<dholbach> pitti: today?
<Petaris> When is he usually around?
<fabbione> BenC: it won't take too long
<Petaris> ahh
<dholbach> pitti: it's whenever you have time and we can announce it
<BenC> fabbione: Yeah, I can do that
* pitti lends seb128 his crack pipe *hui*
<fabbione> BenC: ok sounds good.
<dholbach> pitti: and it just needs to be a 20 min session
<BenC> fabbione: that's 32 hours from now, right?
<seb128> pitti: thank you :p
<dholbach> pitti: with questions and examples afterwards... or something
<BenC> well, 34 hours from now, or do you mean 10 hours?
<fabbione> BenC: 10 hours.... i think
* fabbione recalculate
<fabbione> 10 hours from now
<fabbione> 34 hours would be saturday for me
<pitti> dholbach: that sounds manageable
<fabbione> and that's like asking for my wife to kick me out of the door :)
* dholbach hugs pitti
<pitti> dholbach: as I said, today is baad, tomorrow or Monday is better
<dholbach> pitti: sure, it's good if we can announce it in advance
<pitti> dholbach: anything particular I should talk about?
<dholbach> pitti: the good thing is: somebody will make wiki pages and documentation from it, so it really *should* make a change
<dholbach> pitti: whatever you like... but you can take a look at http://wiki.ubuntu.com/MOTU/School/Requests
<BenC> fabbione: ok, so tonight for me :)
<fabbione> BenC: yes i guess so
<fabbione> BenC: but i just read on -meeting you are going vac.. how many weeked?
<fabbione> weeks
<pitti> dholbach: oh 'how to patch sources' would suit me fine
<pygi> sivang: poke poke?
<pitti> dholbach: after getting to know all the different weird patch systems out there while doing security updates, I feel I have some experience in that :)
<BenC> fabbione: all of next week
<dholbach> hehe :)
<dholbach> super, pitti
<fabbione> BenC: ok.
<fabbione> BenC: have fun :)
<BenC> "and make money" :)
<BenC> the two sort of go together though
<simira> fabbione: how's Ulla? Did she deliver yet?
<zul> oh yes...poker tournament
<fabbione> simira: nope...
<fabbione> BenC: ehehhehe
<fabbione> BenC: money->females.fun();
<pitti> dholbach: do these dates mean the date of the request or the date of the session? :)
<dholbach> pitti: request ;)
<fabbione> simira: she is big like a UFO now...
<dholbach> pitti: i added suggestions after i wrote the spec
<ogra> fabbione, she has little blinking lights ? o_O
<Hobbsee> ogra: yes, for mind control.
<fabbione> ogra: i did place them around the baloon to make sure she is 100% visible at night
<pitti> dholbach: alright, sign me up for the patch session
<simira> fabbione: she's a week overdue or something?
<ogra> LOL
<ogra> simira, two or three rather ? 
<pitti> dholbach: shall I just pick a date and announce it to the -motu list? or do you already have a process for that?
<fabbione> simira: yeah...
<dholbach> pitti: just add it to the wiki and write to the list that'd be great
* dholbach hugs pitti
* pitti hugs dholbach 
* Hobbsee ignores the hugging, and passes out instead.
* pitti hugs Hobbsee 
<Hobbsee> pitti: :)...but i'm passed out, so...
* bddebian throws water on Hobbsee
<Hobbsee> oh grr. make me even colder then.
<Hobbsee> and soaking wet.
* pitti gives Hobbsee an ice cream
<pitti> Hobbsee: colder? ah, sorry, I forgot - take this nice herb tea instead
* fabbione ships ice cubes to Hobbsee 
<Hobbsee> heh
<Hobbsee> fabbione: you want to keep those, surely.
* Hobbsee wonders why her bed always seems to grow rubbish while she's not looking.
<fabbione> Hobbsee: with this heat? yes
<Hobbsee> fabbione: heh.  heat. how hot's it for you at the moment?
<fabbione> around 30
<fabbione> C
<pitti> Hobbsee: 38 degrees Celsius here...
<Hobbsee> pitti: bah.  nice and warm :)
<pitti> Hobbsee: (in the shadow, I don't want to know how hot it is in the sun)
<Hobbsee> pitti: yeah, okay...if that's in the shaddow, then i'm a bit more compassionate
<Keybuk> Mithrandir: my problem with the 24 hour thing is the 0800 meeting ... I 
<Keybuk> I'd have to have the text in the wiki by 0800 on Wednesday
<Hobbsee> 30C should be nice, fabbione, although not for your wife, i expect.  no airconditioning?
<Keybuk> which means that I really need to write it on Tuesday
<Keybuk> so, effectively, we end up having a "what we did LAST WEEK" meeting, over half way into the next week
<Mithrandir> Keybuk: make 0800 special, then
<Keybuk> given the meeting is supposed to be about resolving blockers, and getting help, I don't see the point in that
<fabbione> Hobbsee: no a/c but 30 is not nice when you add on top the temperature of a rack heat :)
<Keybuk> if the meeting were just as a progress report, we could just do the wiki and not meet at all
<fabbione> anywa
<Hobbsee> fabbione: well...what can i say... :P
<fabbione> does anybody need anything from me? otherwise i am off for BBQ
<Keybuk> the fact it's supposed to be a "I'm blocked here, I need help here, etc." type of meeting means that the information we're discussing needs to be current
<Hobbsee> fabbione: stick it in the cellar or something?
<fabbione> Hobbsee: ehehe
<Hobbsee> fabbione: no, wait, that's where all the bodies are, that wont work.
<fabbione> Hobbsee: that too :)
<Hobbsee> :P
<Hobbsee> (sway sway thud bang ouch sway)...hmmm...i dont think i should handle a large knife tonight.
* fabbione heads outside
<pitti> dholbach: ok, I scheduled the lesson for next Tuesday 1600 UTC, that should suit both the Americans and the Europeans
<Hobbsee> pitti: what time is that, euro time?
<Hobbsee> oh hang on, dont worry.
<Hobbsee> i though that was a sane meeting time, for a second
<pitti> Hobbsee: UTC
<Hobbsee> pitti: oh bleh.  so it is, london's only 1 hour ahead.
<Hobbsee> pitti: dholbach you'll log that, i take it?
<dholbach> Hobbsee: me? we had so many ubuntu motu doc team people around, didnt we? :)
<Hobbsee> dholbach: well, whoever.
* Hobbsee certainly wont be logging it
<ogra> Hobbsee, sudo apt-get install gworldclock :)
<Hobbsee> ogra: meet kclock, installed by default.
<pygi> dholbach: you have a sec for me? :)
<dholbach> pygi: yes
<ogra> Hobbsee, pfft ... by default ... pfft 
<Hobbsee> ogra: unforunatly, i cant apt-get reinstall brain.
<pygi> dholbach: how's your student coming along? any progress?
<Hobbsee> whichis the problem
<ogra> heh ... 
<sladen> Hobbsee: excessive bling and bloat I'll tell yer
<ogra> i'd prefer a apt-get fridge brain
<Hobbsee> sladen: :P
<dholbach> pygi: i pinged him for 2-3 days now and i didn't hear back - i'll write him a mail later and see what's goingon
<dholbach> pygi: i hope he's alright and all
<pygi> dholbach: I mailed him
<dholbach> pygi: ahhh good
<pygi> It's end of his semester now, and he said he'll work harder now to catch up on things
<dholbach> yeah, exactly
<pygi> nice, just wanted to inform you :)
<ogra> dholbach, whats he doing ? was that the epiphany stuff ? 
<dholbach> ogra: yup
<pygi> ogra, aha
<ogra> ah
* dholbach fetches some water and does a quick break
<pitti> Hobbsee: I'm fine with another time, but I have observed that European evenings/American mornings work well so far
<Hobbsee> pitti: indeed :)
<dholbach> 35,0 C
<pitti> Hobbsee: and I don't want a huge discussion about the time :)
<ogra> i'm lagging a bit with Amaranth's willowng package, but it should hit universe the next days
<Hobbsee> pitti: had no intention of having one.  for a minute there, i thought you'd found a good time on *all* timezones.
<ogra> dholbach, lucky you, my thremometer hangs in the bright sun ... i cant even guess the temp :)
<pygi> ogra, I could probably also package the Olive backend, but I think I'll wait for UI to be done
* Hobbsee shakes her head.  you really all whine about the weather when it's less than 40C?  guess if you have no airconditioners...
<Amaranth> ogra: oh, did i ever actually give you the package i made?
<Amaranth> ogra: right as i finished you disappeared
<ogra> Amaranth, i bzr puled the changes :)
<ogra> *pulled
<Amaranth> ah
<Amaranth> i wonder if i pushed the latest stuff :P
<ogra> i made some comments ... but you were afk or something (and actually i forgot what comments that were, need to look again)
<Hobbsee> night all
<ogra> night Hobbsee 
* Hobbsee goes and falls on the floor somewhere.
<Amaranth> whoops
<Amaranth> looks like the latest stuff wasn't pushed
<ogra> Amaranth, great, likely my comments are adressed then ;)
<ogra> i
<ogra> 'll look later 
* ogra has to prepare for his landlord inspecting the chaos here ...
<doko> getting some ice cream, floating away ...
<Amaranth> it looks like my init script doesn't actually work :P
<LaserJock> Kamion (or others): is the devlopment team meeting wiki publicly available somewhere?
<Kamion> LaserJock: https://wiki.ubuntu.com/DistroTeamMeeting20060720
* Kamion -> evening, bye all
<LaserJock> Kamion: oh, thanks
<zul> Kamion: ping...
<rodarvus> Kamion: have a good night!
<zul> Kamion: btw...the xen kernel boots now
<ogra> zul, awesme+1
<Tonio_> hi
<Gloubiboulga> Is it possible to run a new Xubuntu Desktop iso build with updated seeds?
<fschoep> dholbach: ping
<bddebian> Oh shite, qgis is broken because of grass :-(
<dholbach> fschoep: pong
<dholbach> fschoep: where do we meet?
<fschoep> PM?
<dholbach> ok
<ogra> Gloubiboulga, i could trigger an iso build, but you will need someone with access to the livefs build system before else i can only build from an old livefs which gains you nothing
<Gloubiboulga> ogra, thanks, I don't actually know the processes for all these build things. Do we have a doc somewhere?
<sharms> mako: ping
<ogra> Gloubiboulga, i dont think so ...
<ogra> Gloubiboulga, the process is: pester Kamion, infinity or Mithrandir to trigger a livefs build ... if thats done, poke either of these three, Riddell or me to make an iso from that 
<ogra> for install CDs the livefs step isnt needed indeed
<Gloubiboulga> ogra, ok, I'll bug everyone tomorrow ;)
<ogra> :)
<bddebian> doko: ping?
<sharms> My laptop, running edgy, had a reiserfs partition on it that apparently only has 1 bad sector and now reiserfs is reporting it is a hardware issue.  I am now reinstalling dapper as a ext3 system, but I have the feeling it is not a hardware issue but a reiserfs issue.  I don't have any logs or anything, although I didn't shutdown the system properly, but should I be thinking about filing a bug report or write it off to freak hap
<sharms> pening?
<sharms> That bad sector was apparently in /boot which makes it more odd that it would just be in my boot loader
<dholbach> can somebody promote cairomm to main?
<Petaris> sharms: reiserfs is sort of know for not being overly reliable
<sharms> Ah see I always got the impression it was better, but just like the bastard of linux
<Petaris> Don't get me wrong its a great fs if you need the speed and work with small files but there is always a payoff
<Petaris> s/payoff/tradeoff
<dholbach> Kamion, Keybuk: can somebody of your promote cairomm to main? :)
<Keybuk> dholbach: it doesn't appear to be depended on by anything or seeded?
<dholbach> Keybuk: gtkmm2.4 will need it
<dholbach> gtkmm2.4 upload first?
<Keybuk> ok
<dholbach> Keybuk: shall i do the gtkmm2.4 upload now?
<Keybuk> if you like
<dholbach> yeah, very much so :)
<sharms> so I run /sbin/badblocks on the said drive with reisferfs, and the bad block is near the grub location.  I format, put ext3 on, and run /sbin/badblocks and I have no bad blocks
<sharms> but I really have no diagnostics to report a bug with
<Petaris> sharms: I would guess it was a reiser issue then
<dholbach> Keybuk: thanks a lot
<Gloubiboulga> No desktop cd for xubuntu but at least the alternate iso works just fine :)
<Burgwork> jdub, take a look at the front page of eweek --> http://eweek.com/
<sladen> Burgwork: excellent find!
<rodarvus> Keybuk: ping
<Keybuk> rodarvus: yup?
<rodarvus> may I ask you to sync three rather urgent X libraries (their sync was requested a few minutes ago)
<Keybuk> sure
<rodarvus> thanks :)
<Keybuk> xtrans?
<rodarvus> no, xtrans is built already
<Keybuk> hmm
<Keybuk> which three?
<rodarvus> just a sec
<Keybuk> you're faster than Malone! :p
<rodarvus> libxau, libxdmcp and libfontenc
<rodarvus> the sync requests were made on Malone (ubuntu-archive subscribed to them, too)
<Keybuk> right, but Malone hasn't actually mailed them out yet <g>
<rodarvus> oh
<rodarvus> haha
<Keybuk> meh, you've changed your lp id!
<rodarvus> I apologize for asking you here - its just that it would be great to have the base of X already published by the end of the day today :)
<rodarvus> Keybuk: right, is rodarvus for a few weeks, now
<Keybuk> no problem
<Keybuk> it isn't a few weeks! :p  it's a week at most
<rodarvus> internet time ;)
<Keybuk> uhh, are you sure these are updated in Debian?
<rodarvus> Keybuk: debian experimental
<Keybuk> heh
<rodarvus> :D
<pygi> sivang: poke? :)
<Keybuk> [NOT Updating - Modified]  libfontenc_1:1.0.1-6ubuntu2 (vs 1:1.0.2-1)
<Keybuk> [NOT Updating - Modified]  libxau_1:1.0.0-3ubuntu1 (vs 1:1.0.1-1)
<Keybuk> ok to override?
<rodarvus> sure
<rodarvus> (its marked as 'ok to override' on the sync requests, for reference)
<Keybuk> they still haven't turned up yet <g>
<rodarvus> hahaha
<Keybuk> done
<rodarvus> thanks a lot!
<Keybuk> can you close the bugs?
<rodarvus> sure
<ogra> rodarvus, wow, my ltsp change today gives me a lot of feedback ...
<rodarvus> Keybuk: bugs closed - thanks again!
<rodarvus> ogra: oh, good feedback? :)
<ogra> well ... 
<ogra> i guess once the users use it i will get good feedback from less support questions ...
<ogra> but debain seems not happy ...
<ogra> *debian
<ogra> ARGH
<ogra> *d e b i a n
<LaserJock> why?
<ogra> becuse they dont like the idea to copy the sshkeys into the ltsp chroot on every ifup  
<rodarvus> can't we check if they are different before copying?
<ogra> rodarvus, sure, but that would slow down significanty ... 
<ogra> adding grep and stuff
<ogra> i podered it ... but i think just copying them is way faster
<ogra> mdz asked as well about it :)
<lfittl> ogra: do you plan to update blender to 2.42 for edgy?
<ogra> lfittl, is that the version with all the movie stuff added ? 
<lfittl> yep
<rodarvus> ogra: I'm reading the backlog on #ltsp now - didn't noticed the conversation you had with vagrantc was there
<ogra> i'll look into it ... i think we should ... but i have to find some time to examine
<lfittl> ogra: can I help with that somehow?
<ogra> rodarvus, well vagrantc is a hardliner ... usually the compromises we find after some discussion are te best solution :)
<ogra> lfittl, testbuild it run it ? 
<lfittl> ogra: debian has 2.42 and I rebuilt it on edgy, basic stuff works without a problem
<ogra> oki
* bluefoxicy sighs.
<ogra> then i'll request an UVF exception 
<lfittl> perfect :)
<Amaranth> ogra: if you pull from my branch the packaging should all be good now
<ogra> ok
<Amaranth> afaik the init script works now
<smokeyd> Hey all, is openoffice for dapper 64bit compiled against the same libraries as included in the 32bit emul in dapper 64bit?
<smokeyd> Openoffice says it is not with me
<smokeyd> On the normal ubuntu channel I only get the repluy: run 32bit
<smokeyd> I hope one of you has a more satisfactory solution
<smokeyd> see http://www.copypot.com/200
<smokeyd> fir the errors I get
<smokeyd> I don't mind if a solution takes some work on my part, but I would like to get it to work
<ogra> smokeyd, please see the topic ... especially the first sentence
<smokeyd> yeah, I know, but I don;t know where support ends and devel starts. This is on the edge and I had the feeling the general ubuntu channel was more, "my printer doesn't work" stugg
<smokeyd> stuff
<Keybuk> "my openoffice doesn't work" is just as supporty
<tseng> there isnt a difference between "my printer doesnt work" and "open office doesnt work" until you are telling us exactly why
<tseng> and working towards fixing it
<tseng> instead of throwing out a line
<rodarvus> Keybuk: are you able to promote universe packages to main?
<smokeyd> no, it's a compile problem
<smokeyd> I told you
<tseng> goodness.
<rodarvus> (or rephrasing my question) I need x11proto-print to be promoted to main (since it has become a build-dep for libxaw)
<rodarvus> do I need to fill a MainPromotionRequest for it?
<smokeyd> The problem is that the glibc version libstdc++.so.6 expects is not the same as provided in the 32bit emul
<tseng> smokeyd: now you're getting somewhere.
<smokeyd> (22:22:12) smokeyd: Hey all, is openoffice for dapper 64bit compiled against the same libraries as included in the 32bit emul in dapper 64bit?
<Keybuk> rodarvus: yes
<smokeyd> libstcd++.so.6 is not present in the lib32 folder on dapper
<Keybuk> rodarvus: you need an MIR for it though
<smokeyd> if I softlink libstdc++.so.5 to libstdc++.so.6
<Keybuk> https://wiki.ubuntu.com/UbuntuMainInclusionQueue
<rodarvus> Keybuk: I will fill it now - thanks!
<smokeyd> I get the error /usr/lib32/libstdc++.so.6: version `GLIBCXX_3.4' not found (required by /usr/lib/openoffice/program/javaldx
<Keybuk> smokeyd: see, that's definitely a support question
<ogra> Keybuk, is ipconfig a busybox builtin or is there any source package ?
<Keybuk> it's a klibc utility
<ogra> ah, thanks
<Keybuk> Accepted makedev 2.3.1-83 (source)
<Keybuk> gnargh!
<Keybuk> I hate it when I do that
<Keybuk> (used -i and didn't add ubuntuX)
<ogra> meh
<ogra> but you rejected it early enough ?
<Keybuk> <g>
<ogra> so that looks like "tear down instead of shut down" what you are doing there :)
<Keybuk> right
<Keybuk> wiki.ubuntu.com/Teardown
<ogra> YAY!
<ogra> \o/
<ogra> yep
<ogra> you explained it to me in mataro i think ;)
<ogra> i dont forget the good stuff ;)
<Keybuk> hehe
<Keybuk> dpkg-checkbuilddeps: Unmet build dependencies: bison flex libpam0g-dev mail-transport-agent
<Keybuk> WHY THE FUCK DOES THIS NEED AN MTA TO BUILD ?!
<ogra> ugh
<ogra> to mail you the build errors ?
<lucas> how often does the mirror push happen in ubuntu ?
<Keybuk> hourly
<lucas> ty
<wasabi> Is there any other suspend to disk tech besides to a swap file?
<Keybuk> wasabi: such as?
<wasabi> Eh. Something that can suspend to something without relying on a static partition that must be >= ram size.
<wasabi> Ya know. More flexible.
<Keybuk> like what? :p
<Mithrandir> Keybuk: uh, what build-deps on mta?
<wasabi> Eh. Well how does windows do it? I suspect they suspend to a file on the FS.
<Keybuk> Mithrandir: "at"
<wasabi> And resume, I have no idea.
<Keybuk> Build-Depends: bison, flex, libpam0g-dev, mail-transport-agent
<Mithrandir> Keybuk: probably lazy configure script or something, I'd guess
<wasabi> But if you upgrade your ram in a windows box, hibernate doesn't break.
<Keybuk> wasabi: you need something that you can write to without affecting anything in memory
<wasabi> Sure. I understand the reasons it's done the way it's done now.
<Mithrandir> wasabi: I have an interesting idea for how to do suspend to swap files and with the automatic swap manager rodarvus has been working on, I think we should be able to just put swap on / or something and let it grow automatically.
<wasabi> Yeah. MS puts a file in C:\System32\
<wasabi> Err, WINDOWS\SYstem32
<wasabi> Suspect it's probably static on the FS in some way.
<wasabi> No clue there though.
<wasabi> Mithrandir: ahh. cool.
<wasabi> Mithrandir: So there isn't anything now, but the problem is being worked on.
<wasabi> Thanks. :0
<Mithrandir> wasabi: I have an idea on how to do it.  I've not yet implemented it, but I was going to tell Scott about it at the distro sprint so he doesn't think my crack level has gone down.
<Mithrandir> ;-)
<rodarvus> :D
<Keybuk> suspend to usb key?
<Mithrandir> Keybuk: nah, rewrite initramfs on suspend.  Will work great with runtime assembly of same.
<ogra> suspend to pocket ...
<Keybuk> why not just give grub a different initramfs option on resume?
<Mithrandir> suspend to USB is trivial. :-P
<wasabi> I bet MS does something like store the physical disk locations of the swap file in something related to the bootloader
<Keybuk> rewriting menu.lst is probably cheaper
<Mithrandir> because that would require grub to know if it resumes or not?
<Mithrandir> wasabi: that's basically what I'm suggesting.
<wasabi> For instance, append resume=/dev/hdc#1234:1234 into the menu.list
<wasabi> Yeah.
<Mithrandir> you can just tell the kernel "resume from those blocks" or something like it.
<wasabi> Yeah.
<wasabi> Would have to create a non fragmented file.
<wasabi> Or... handle that complexity.
<Mithrandir> just give the kernel a list of blocks.
<Mithrandir> not hard.
<Keybuk> makes a lot of sense
<lucas> what's the best place to fetch changes for ubuntu packages from ?
<wasabi> Yeah. Right now if our user's upgrade their ram, suspend breaks.
<wasabi> Basically.
<lucas> http://changelogs.ubuntu.com/ ?
<Keybuk> lucas: define changes
<lucas> s/changes/changelogs
<wasabi> I'm working on swapd right now.
<lucas> sorry
<Mithrandir> anyway, 'night.
<wasabi> Hey Mithrandir, you aware of any way for a user space program to be notified before the OOM killer ... kills?
<Mithrandir> see you around.
<wasabi> ahh. night. ;)
<Keybuk> lucas: right, I think you answered your own question then
<lucas> okey
<elmo> wasabi: you mean, like, the kernel announcing in a booming voice "WIZARD IS ABOUT TO DIE"?
<wasabi> heh.
<Keybuk> wasabi: surely  you wouldn't have the memory to start or run such a program? :p
<wasabi> Yeah. That's an issue. Basically what I'm doing is fixing swapd.
<wasabi> To support a) a minimum number of swap files. So you can always make it manage/create one.
<wasabi> b) would like it to have a chance to beat the OOM killer, by adding more swap, before the OOM killer kills.
<wasabi> ie, some sort of notification of "memory is this low, and is about to get lower."
<Keybuk> MORE SWAP!!  MORE SWAP!!
<wasabi> with an additional SIGSTOP to the process that is about to make the system run the OOM killer.
<wasabi> ie, it freezes, more swap is created, it proceeds.
<Keybuk> yeah, that can be really bad you know
<Keybuk> what if it's init that made the system run the OOM killer?
<Keybuk> BYE BYE SYSTEM
<wasabi> yeah. doesn't usually happen in practice though. the OOM killer basically kills the program using hte most memory.
<wasabi> and init isn't usually that.
<wasabi> on my system it consistantly takes out vmware, though.
<wasabi> which is super annoying.
<Keybuk> you are confusing two things though
<Keybuk> "the process that is about to make the system run the OOM killer" is the process that asked for more RAM
<Keybuk> that is not "the process that the OOM killer kills first"
<wasabi> Oh yeah. I know.
<Keybuk> clunits.h:88: error: extra qualification 'CLDB::' on member 'get_file_join_coefs'
<Keybuk> ^ someone who talks C++ese tell me what that means
<wasabi> The OOM killer though doesn't just randomlly choose a process. It chooses the biggest one.
<wasabi> That's not likely going to be init.
<Keybuk> wasabi: right, but that's not the process you claimed you were going to send SIGSTOP to
<wasabi> You're right. I'd stop the one that is about to spawn the OOM killer.
<wasabi> So that it doesn't.
<Keybuk> erm?
<Keybuk> like I said, the process that _spawns_ the OOM killer is not the process that the OOM killer, once spawned, chooses to target
<wasabi> RAM gets increased before the kernel code (the thing allocating the page basically) runs the OOM killer.
<wasabi> Yeah? I'm just preventing the OOM killer by running.
<wasabi> s/by/from/
<Keybuk> as an experiment, to demonstrate what I mean, kill -STOP 1 ;p
<wasabi> heh. I'm unsure what that will do. I suspect it will stop init, but no children.
<wasabi> Am I right or wrong?
<wasabi> I'd rather not test right now. ;)
<Keybuk> like I said, sending STOP to the process that just needed more RAM may actually have other consequences than you think :p
<wasabi> Well, does it stop children too?
<Keybuk> actually, I believe it does nothing in this case
<wasabi> If so I'd probably do it another way.
<Keybuk> (ie. doesn't even stop)
<wasabi> Heh.
<wasabi> There is going to be a function in the kernel which handles lazy-allocating a page for a process that is trying to write in it. That line of code will basically say if (no pages left!) { run oom killer; }
<wasabi> I'm just going to replace it with, { pause calling process; tell swapd to make more ram; wait for swapd to finish; are there free pages yet? no? Oom killer. =( }
<Keybuk> how you going to deal with SMP?
<wasabi> nfi. =)
<wasabi> I'll figure that out when I get there.
<Keybuk> or even the basic fact that the kernel is pre-emptive?
<Keybuk> so another process might ask for pages while you're in that routine
#ubuntu-devel 2006-07-21
<wasabi> cool. minswaps option added to swapd... and also default values for memlimit and swapsize.
<wasabi> defaulting to total physical ram.
<wasabi> So, with minswap 1, and memlimit and swapsize set to default, it will always create one file the size of your ram.
<Keybuk> hplip_0.9.11-2ubuntu3.dsc: invalid Build-Depends field; cannot be parsed by apt.
<Keybuk> eh?
<ogra__> heh
<Keybuk> siretart: ping?
* bluefoxicy yawns
<bluefoxicy> sfllaw, lifeless, either of you awake?
<lifeless> I appear to me
<bluefoxicy> is there somewhere I can track what exactly is going on with AutomatedProblemReports
<lifeless> the spec, or pitti
<bluefoxicy> ah, so you wouldn't know :>
<lifeless> :)
<bluefoxicy> I was curious about this part mainly:  "Debug symbols are very big and we want to avoid requiring to download them on the client machine. So we need a server which processes the incoming reports, generates a backtrace from the report data, stack frame, and debug symbols, and adds the stacktrace to the generated report."
<bluefoxicy> re "a server" == a daemon or just a Web application like a CMS (i.e. Launchpad) that can take the data over https into a CGI script
<bluefoxicy> I guess I'll ask pitti though.
<bddebian> Howdy
<bluefoxicy> hi bddebian
* ogra comforts Keybuk 
<Keybuk> :p
<bluefoxicy> what happen
<Keybuk> "oh, I know, I'll just test one more thing ... damn!"
<bluefoxicy> did he apt-get build-dep another one of doko's packages?
<ogra> woah
<bddebian> Hello bluefoxicy
<ogra> http://www.dylanknightrogers.com/faster-dapper.sh
<tseng> ogra: do i need policykit? :(
<ogra> sudo /sbin/hdparm -u1 -m16 -c1 -A1 -a64 -d1 -K1 $INSTALLED_DRIVE > /dev/null
<tseng> scary
<ogra> LOL
<bddebian> Hmm, what to do, what to do..
<ogra> # Enable dash as /bin/sh to run shell scripts instead of bloated bash
<ogra> # See
<ogra> if ( ! dpkg -l dash >/dev/null 2>&1 ); then
<ogra>     sudo apt-get install dash && sudo update-alternatives --install /bin/sh sh /bin/dash 1
<ogra> else
<ogra>     sudo update-alternatives --install /bin/sh sh /bin/dash 1
<ogra> fi
<ogra> hahahaha
<Keybuk> -u often results in massive filesystem corruption
<bluefoxicy> # Disable sudo asking for your password for the remainder of the script
<bluefoxicy> sudo sed -ie '/^%admin/s/ALL$/NOPASSWD: ALL/' /etc/sudoers
<tseng> haha!
<bluefoxicy> ogra:  Fuck that.
<Keybuk> -m16 is sane
<Keybuk> likewise -c1 is sane
<tseng> bluefoxicy: easy there killer
<bluefoxicy> the moron should have used 'id' to check if he is root; if not, sudo $0
<Keybuk> -A1 is the default
<ogra> if ( ! grep "Ubuntu 6.06" /etc/issue >/dev/null 2>&1); then
<ogra>     echo "This script is only intended for Ubuntu 6.06 Dapper Drake"
<ogra>     exit 1
<ogra> fi
<ogra> *GRIN*
<bluefoxicy> tseng:  immediate brain damage
<Keybuk> -a64 is probably slower than the default!
<bluefoxicy> and a race condition you can exploit to get root
<ogra> hah
<Keybuk> -d1 is usually set by default
<Keybuk> so the usual sane hdparm flags, and some odd ones
<ogra> yeah
<ogra> the rest of that scripts is similar ...
<Keybuk> dash we do by default now
<ogra> thats why i laughed my ass off :)
<bluefoxicy> ogra: that script installs preload
<bluefoxicy> I haven't used preload
<bluefoxicy> looking at it I had guessed that it would make the system rather slow as shit, but I haven't actually tried.  Comment?
<tseng> bluefoxicy: can you seriously take it down a notch?
<tseng> bluefoxicy: you know I would love to ban you
<bluefoxicy> tseng:  okay
<tseng> thanks.
<bluefoxicy> also Method loves to ban me more
<tseng> I'm sure he does
<tseng> moving right along, policykit anyone?
<tseng> is out plan to patch it out?
<bddebian> tseng: policykit?
<tseng> bddebian: hal policykit
<bddebian> Ah
<tseng> says "can I do this?"
<bddebian> Speaking of policy, anyone want to help me make hamlib conform to the new python policy? :-)
<ogra> tseng, we'll likely rather stay with old g-p-m if it doesnt work without plokit
<ogra> *polkit
<tseng> ogra: well
<tseng> ogra: old gpm wont show me battery % anymore
<tseng> they are both broken
<ogra> then we'll need to fix that ... at least it suspends/hibernates
<bddebian> doko: ping again?
<ogra> bddebian, 3:14
<bddebian> Oh
* bddebian needs a mentor :-)
<zul> ogra: oh i know this one...bible verses 3:14 we own your bases
* zul had too much sugar tonight
<ogra> heh
<bddebian> Anyone think doko would care if I uploaded adonthell?
<crimsun> hmm
<bddebian> Hi crimsun
<crimsun> now that I think about it, I have to manually restore my volume in gnome using the hotkeys anyhow. Why does alsa-utils's initscript even bother storing on action-stop?
<crimsun> granted not everyone uses gnome, but even kmix and xfce4-mixer AIUT handle restoring the mixer levels
<bddebian> WHAT?  No everyone uses Gnome? :-)
<wasabi> I take it xorg is broken? Missing fixed. Unless it's moved.
* wasabi searching.
<rodarvus> wasabi: what do you mean by "xorg is broken"?
<Hobbsee> hi rodarvus 
<rodarvus> hi Hobbsee
<rodarvus> I was about to turn off my computer but wasabi's comment got my attention :)
<rodarvus> wasabi: I've been doing xorg-related uploads all day long, but they shouldn't be related to any fonts brokeness
<rodarvus> wasabi: per your description, it seems like you have problems with your fontpath (but that should have been handled by updates done about ten days ago, by now)
<fabbione> morning
<fabbione> rodarvus: he can open a bug.. go and get some sleep
<rodarvus> indeed :)
* rodarvus goes to bed
<rodarvus> good night all
<bddebian> Gnight rodarvus
<wasabi> Ahh. Looks like update-fonts-dir is broke.
<wasabi> Breaking because /usr/lib/X11R6/fonts was removed.
<wasabi> Quicky find/replace job in it fixed it right up.
<wasabi> whoops. wasn't paying attention and missed him.
<wasabi> sily VTs.
<floam> tseng: any idea how much longer muine will be broke for? I rebuilt it and looked at it a bit, it appears it's not as obvious as I guessed
<netdur> ubuntu says I have seven floppy readers, actually I don't have any, I can edit /etc/fstab to fix problem but I want fill bug first... what information should I attach to soon-to-be-opened-bug?
<fabbione> netdur: i think there is already a bug open for that
<fabbione> netdur: no actually i am pretty sure. i just can't remember against what exact package
<Hobbsee> morning fabbione 
<fabbione> hey Hobbsee 
<fabbione> morning is a big word.. changing TZ is horrible
<Hobbsee> fabbione: okay. evening then.  it's not morning here either
<netdur> fabbione: thanks, there's no need for dupes :)
<fabbione> Hobbsee: it's 5am here now :)
<fabbione> well 5:30
<Hobbsee> fabbione: urgh.
<fabbione> but i have been awake for over an hour
<Hobbsee> fabbione: then why are you awake?
<fabbione> Hobbsee: to be able to work on cluster. It's too warm during the day to keep all the equipment turned on
<Hobbsee> fabbione: ah...yes...of course
<Hobbsee> and i'm currently freezing cold.  hum.  that still seems weird ot me :P
<fabbione> Hobbsee: ain't my fault if you live on the wrong side of the planet :)
<Hobbsee> fabbione: yeah, true.
<bluefoxicy> what time is it at pitti's place
<Hobbsee> bluefoxicy: europe time?  5-6am?
<bluefoxicy> what is his native language anyway
<bluefoxicy> talking to him is like talking to trulux, just a little more sane
<Hobbsee> bluefoxicy: not sure, i've only been told that he's in europe
<fabbione> bluefoxicy: .de. it's 6am now
<bluefoxicy> ah
<bluefoxicy> lucky, I hear the people in germany are actually friendly
<fabbione> bluefoxicy: it really depends with who :P
<fabbione> specially after the WC2006 ;)
* fabbione HEAD -> WALL
* fabbione HEAD -> WALL
* fabbione HEAD -> WALL
<Hobbsee> hi all
<fabbione> init/built-in.o: In function `try_name':
<fabbione> do_mounts.c:(.text+0x604): undefined reference to `__stack_chk_fail'
<fabbione> grep stack_chk_fail * -r | wc -l
<fabbione> 0
<fabbione> so what's this now?
<fabbione> doko: ^^
<bluefoxicy> fabbione:  that should be in glibc
<bluefoxicy> fabbione:  what are you building?
<fabbione> bluefoxicy: a kernel 
<bluefoxicy> .... oh, shit.  Right.
<fabbione> i think it's that ssp crap
<bluefoxicy> They turned on the stack smash protector by default
<fabbione> how do i disable that?
<bluefoxicy> probably didn't manage to set it to disable on kernels.
<bluefoxicy> -fno-stack-protector
<fabbione> it's a custom kernel
<fabbione> thnkas
<bluefoxicy> you know how to change the flags the kernel uses to build right?
<fabbione> 2 hours wasted
<fabbione> i am not even going to answer to that question...
<bluefoxicy> (I don't remember which lines in the Makefiles to edit anymore)
<bluefoxicy> haha.  It's not something you normally gotta screw with :P
<pitti> Good morning
<pygi> morning pitti
* fabbione larts pitti with a __stack_chk_fail error when building a kernel
<fabbione> pitti: good morning to you too :)
<pitti> hi pygi 
<pitti> hi fabbione 
<pitti> fabbione: -fno-stack-protector, dude :)
<fabbione> pitti: can you please add that to gcc man page?
<pitti> fabbione: this was a known issue when we discussed how to enable ssp
<pitti> fabbione: and we requested to fix that upstream
<pitti> fabbione: yep, will prepare a snippet and send it to doko for the next upload
<fabbione> because there is the enable flag
<fabbione> but not how to disable and crap
<fabbione> also with that kind of error mentioned it might help
<bluefoxicy> pitti
<bluefoxicy> With the AutomatedProblemReports, you mention a "server" to handle incoming requests?
<bluefoxicy> Can Launchpad somehow just be extended to accept problem reports submitted over https and index them etc etc?
<bluefoxicy> (which would be a "Web application" instead of a "server" I guess...)
<pitti> bluefoxicy: we didn't specify that part yet
<pitti> bluefoxicy: but we need some backend service which takes core dumps/stack frame dumps and debug symbols and assembles good stack traces out of them
<bluefoxicy> pitti:  nods.  I am still overly excited about that :P
<bluefoxicy> pitti:  that can likely be done or called from a php or python script.
<bluefoxicy> Also, with the stack traces
<bluefoxicy> if you have a /proc/PID/maps file and a list of addresses, you can locate what addresses fall in what mappings
<bluefoxicy> you can then take said mappings, subtract their offsets from the addresses you have, and produce offsets in those mappings (i.e. relocations!)
<bluefoxicy> Then you can load the same library or program, take its base load address, add that to the offset you computed, and you now have the address you need :)
<bluefoxicy> I noted this on AutomatedProblemReports somewhere at the end.  Figured it might be helpful.  You can keep the debugging symbols separate from the actual library itself right? (you really should have binarily identical files to do this...)
* bluefoxicy is far too easily amused.
<pitti> bluefoxicy: something like that will be necessary if we don't have a full core dump, yes :/
<pitti> bluefoxicy: right, see AptElfDebugSymbols
<pitti> bluefoxicy: there's already a package in the archive that automatically builds .ddebs (separate debug symbols)
<pitti> bluefoxicy: pkg-create-dbgsym
<bluefoxicy> cool.
<bluefoxicy> That relocation technique shouldn't be too tough, I mean you can load any program that loads the library or executable image and then tell gdb to give whatever info about the new calculated address.
<bluefoxicy> You won't have the convenience of having the heap, stack, and anonmappings from a core dump of course.
<bluefoxicy> but you'll at least be able to get a symbolic backtrace.
<pitti> bluefoxicy: well, we still need a stack dump for the function arguments
<pitti> bluefoxicy: incorporating them will be some more fiddling work
<pitti> Riddell: any idea about bug 53518?
<Ubugtu> Malone bug 53518 in Ubuntu "Problem with login in!!" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/53518
<bluefoxicy> a little more work.
<bluefoxicy> However, the function arguments are not as important as the function itself; we still have a win if we learn a code path is broken, even if we don't know why it's broken.
<dholbach> good morning
<bluefoxicy> i have to sleep, it's 3am
<Burgundavia> fabbione: I don't know if I am more scared about you becoming a father or the poor child with you as a father ;)
<fabbione> Burgundavia: i think my wife is more scared than you are for the poor child to become like me :D
<Burgundavia> fabbione: indeed
<crimsun> congrats fabbione :-)
* carthik hugs fabbione
<fabbione> i am not father yet
<fabbione> there is nothing to congratulate...
<crimsun> bah
<fabbione> you will all know when i will be father
<fabbione> trust me on that :D
<Burgundavia> crimsun: I was commenting on the scary prospect of fabbione actually having to teach the little rotter about ethics and all that jazz
<crimsun> ah
<Kamion> mvo: over your holiday, I found some serious weirdness in python-apt, and was trying to decide if it merited a bug report or not
<Kamion> mvo: specifically, InstallProgress forks a child process and runs pm.DoInstall() in that
<Kamion> mvo: the problem with this is that any exceptions get raised in the child process, rather than in the parent process where the application can actually deal with them anely
<Kamion> sanely
<mdke> is anyone working on some knot reviews like mgalvin did with the flights at http://www.ubuntu.com/testing ?
<Kamion> I rewrote ubiquity's InstallProgress subclass to do it the other way up, which also means it doesn't spin so much on waitpid/read
<Kamion> but I don't know if you want to do something similar with apt.progress; I guess you'd have to hunt down and check all the users now
<mvo> Kamion: interessting! I will have a look, is it in your ubiquity bzr branch?
<Kamion> mvo: yep
<dholbach> heya seb128!
<seb128> hey dholbach
<Kamion> mvo: the only downside is that if the work done to process apt status messages is remotely likely to raise an exception, then there isn't much that can be done to get that exception out to the main program
<Kamion> but it seemed better to me to make the trade-off that way
<seb128> ogra: did you send that mail about gnome-power-manager?
<dholbach> can somebody get jokosher out of NEW? ;)
<Kamion> in a bit
<dholbach> yoohoooo!
* Kamion is concentrating on complicated seed structure changes
* fabbione kills another really annoying bug
* pygi yays :)
<pygi> dholbach: :)
<fabbione> let's not make my work useless..
<simira> who's fault is it that my sd-card isn't automatically mounted when I insert it in the reader (on my laptop)?
<fabbione> FYI in .18-rc statfs call uses dentry while in .17 uses sb
<fabbione> now.. you might think who cares...
<fabbione> that it wasted about one day of work to understand why a FS doesn't work and you get 20GB instead of 200GB of free space (when not oopsing)
<fabbione> (and let's skip the story in the middle of changing HW and stuff.. ok?)
<ogra> seb128, the error must be on my side or a bug ... seems its supposed to work without plokit according to hughsie
<seb128> ogra: you mailed him?
<ogra> seb128, i talked to him
<seb128> ok
<ogra> i'll dig for the reason 
<seb128> vuntz: looks like g-p-m 2.15 doesn't require policykit, it should work without
<seb128> ogra: ok, thank you
<ogra> seb128, thanks me if i got it workig ;P
<ogra> ugh ... i should train typing 
<ogra> *thank me if i got it working ;P
<seb128> ogra: "get"? :p
<vuntz> seb128: ok
<seb128> lu vuntz ;)
<ogra> oh, that reminds me ... 
* ogra puts a pessulus main inclusion report on his todo :)
<tseng> floam: its not obvious, im assuming its calling dbus_session_closed or whatever they just took out of the api
<tseng> floam: the weekend is coming up, I might manage to fix it, might not... now accepting patches
<seb128> Kamion: do we need an UVF for gstreamer or is that the same exception than GNOME?
<ogra> seb128, isnt it a requirement of gnome ? 
<seb128> ogra: it is, like xorg is one too, doesn't mean xorg has a permanent UVF :p
<dholbach> http://gstreamer.freedesktop.org/releases/gstreamer/0.10.9.html looks quite good :)
<ogra> seb128, right, but if it doesnt work without :)
* vuntz hugs seb128 
* seb128 hugs vuntz :)
<ogra> huggers !
<ogra> vuntz, is there something planned for pessulus that makes it possible to edit profiles of other users ? or do i need to copy gconf stuff around ? 
<Kamion> seb128: I don't know about permanent UVF exceptions, but I'm OK with you uploading that
<seb128> Kamion: ok, that's slomo who did that update actually but should be fine too, thank you :)
<Kamion> ok, I think the seed/cdimage world is a bit saner now
<seb128> slomo: read that? 
<ogra> vuntz, see "Lockdown on the fly" for why i'm asking: https://wiki.edubuntu.org/StudentControlPanelCompletion
<Kamion> adding new seeds that should end up on the CD generally doesn't require coordination with me any more now
<slomo> Kamion, seb128: ok, i'll upload gst and gst-plugins-base then... thanks :)
<seb128> cool
<Kamion> you just have to make sure that the ship seed inherits from those seeds (in the STRUCTURE file)
<Kamion> this meant I had to go around editing STRUCTURE files in old releases, but that's life
<vuntz> ogra: would this be running on the same computer?
<ogra> vuntz, yes, its a ltsp server, everything runs on one machine
<Kamion> ship> or server-ship for the server build
<vuntz> ogra: and I guess you don't want to disable the command line for the user using the control panel
<aliasfred>  q. does the apt source list support something like /etc/apt/sources.d/[list of file]  with each of the file in the list contains repository description ?
<ogra> vuntz, not really ... that will run under sudo :)
<vuntz> ogra: it should be easy to do what you want
<ogra> is there a howto or something ? 
<vuntz> nope :-)
<ogra> or do i need to su $USER pessulus ?
<vuntz> you just need to change the GCONF_MANDATORY_SOURCE variable in pessulus
<ogra> (that would be my ugliest fallback)
<ogra> ah !
<ogra> cool
<vuntz> so it should be possible to patch pessulus to take a command line argument to do so
<Kamion> aliasfred: yes, sources.list.d
<vuntz> ogra: well, I believe this should be enough. You'd have to verify ;-)
<ogra> yeah, that should be no problem ... 
<aliasfred> Kamion: thanks
<ogra> vuntz, thanks for now  :)
<vuntz> ogra: feel free to open a bug upstream (and attach a patch there if you do one)
<ogra> vuntz, only if thats necessary :)
* ogra knocks on update-manager ... which blocks the packaging system since 20min ...
<doko> pitti, fabbione: read the manpage. it's there
<doko> bddebian: no, I don't care, even not at 3am ;-)
<mvo> ogra: what is it doing?
<ogra__> mvo, nothing anymore ... i just killed it with a failed hibernate attempt ...
<ogra__> mvo, welcome back btw ! :)
<mvo> ogra__: ah, ok. thanks for the welcome, its good to be back (although it was good to be away too ;)
<ogra__> heh
* ogra__ would love to be away ... especially far away from moving :P
<mvo> *ick* moving is no fun!
<ogra__> nah ...
<ogra__> i'm all alone and the heat doent really help 
<ogra__> *doesnt
<mvo> :(
<ogra__> well, i'll make it ... and then i'll enjoy the new luxury \o/
<ogra__> the new house is so lovely with all its gadgets :)
<mvo> it has a pool and/or a sauna, right?
<ogra__> nope, not yet
<ogra__> thats stuff i'll add
<mvo> "yet"
<sivang> re all
<doko> mvo: apt-get dselect-upgrade isn't yet fixed in 0.6.44.2ubuntu3
<ogra__> but it has a solar powered heating, electrical time/brightness based window blinds .... and the most square thing evah, an electrical garage door :)
<ogra__> sauna and hot tub are planned for autumn :)
<mvo> doko: with ubuntu4?
<mvo> doko: that was the version I uploaded
<Kamion> .2ubuntu3 was my upload and wasn't expected to fix dselect-upgrade :)
<doko> mvo: not yet built/in the archives ..
<mvo> doko: please keep me updated once it hits the archive 
<ogra> hmm, where is my cloak
<tseng> ogra: i see it.
<tseng> ogra: cloaks are inherently racy
<ogra> hmm, i see dip.t-dialin.net
<tseng> whois says masked
<ogra> i also got no message from nickserv
<ogra> usually it tells me it sets the cloak
<aigarius> can anyone point me towards where to dig to find all hardware dependant bits of a fresh Dapper install? i.e. what bits can change when installed on a different hardware?
<Kamion> all the stuff hw-detect does; /etc/{mkinitramfs,initramfs-tools}/conf.d/resume (oops, need to fix ubiquity for the new location); /boot/initrd.img-*; /etc/network/interfaces; /etc/iftab
<Kamion> I think that's about it
<Kamion> you can look through the stuff ubiquity does
<Kamion> (scripts/install.py)
<aigarius> thanks, will look at that.
<Mithrandir> hmm, bzrk seems to be broken in dapper.
<tseng> Mithrandir: hasnt worked for me in awhile
<tseng> Mithrandir: but i blamed my ssh X forwarding or something
<Mithrandir> bzr: ERROR: exceptions.AttributeError: 'BzrBranch5' object has no attribute 'get_revision' at /usr/lib/python2.4/site-packages/bzrlib/plugins/bzrk/graph.py line 42 in distances
<tseng> thats it
<Mithrandir> doesn't look like SSH breakage. :-P
<tseng> yeah :p
<tseng> I screwed up some permissions, too
<tseng> having 3 people edit in a directory is bad news
<tseng> (I use bzr to merge between devel and production, not between developers.. they arent totally up on the VCS bit yet) :(
<dsas> Mithrandir: that's supposed to have been fixed once. bug #37162
<Ubugtu> Malone bug 37162 in bzrk "bzrk is broken with current version of bzr in dapper" [High,Fix released]  http://launchpad.net/bugs/37162
<pygi> released, but not commited perhaps?
<tseng> pygi: that doesnt make sense.
<ogra> pygi, no, sivang uploaded that to dapper
<ogra> but bzr might have changed since :)
* Mithrandir downgrades bzrk to what's in dapper. :-P
<thom> tseng: ACLs for the win, in that case, i guess :-)
<gnomefreak> is there a plan to add opera to dapper repos?
<tseng> thom: yeah that would be nice
<Kamion> gnomefreak: it's in dapper-commercial
<ogra> ??
<tseng> thom: or not letting networking guys write code
<ogra> gnomefreak, its there :)
<gnomefreak> Kamion: can someone add that to the site
<ogra> ah, damned lag
<Kamion> archive.canonical.com
<Kamion> gnomefreak: -v
<Kamion> also gnome-app-install in dapper will list it
<gnomefreak> this is what im talking about http://www.ubuntu.com/news/opera9
<Kamion> gnomefreak: er, -v => please be more verbose. what site?
<Kamion> gnomefreak: upgrade to current dapper-updates and add/remove programs will list it
<ogra> gnomefreak, whats wrong with that page ? i find it pretty clear
<Kamion> it should tell you that you need to upgrade, but I can't edit that page
<Kamion> there is an Ubuntu contact e-mail address at the bottom of that page
<gnomefreak> ok ty
<thom> tseng: heh, or that
<mdke> it's not clear about how to install it without add/remove programs though, he has a point
<ogra> seb128, is it intentional that my volume mutimedia keys dont follow the selected soundcard in the volume control applet ?
<gnomefreak> im emailing yates
<ogra> they appear to always only work for the internal one ... 
<dholbach> heya rodarvus!
<rodarvus> dholbach: hi there!
<dholbach> you did rocking work on the X front!
<mdke> anyone with access to the fridge? can you add the docteam meeting of today at 19UTC?
<dholbach> mdke: if everything else fails, frigde-devel@ might help - but i guess you know that already
<rodarvus> dholbach: thanks :)
<rodarvus> theres lots of stuff to do, though :/
<dholbach> i can imagine - how many source package are those?
<rodarvus> I have to finish updating the rest of the libs (15-20, I think), and then theres xorg-server, mesa, and aaaaall the drivers
<rodarvus> I think 100+
<mdke> dholbach: yeah, will try that
<rodarvus> not counting apps, which are less important
<dholbach> time to attract followers to a x team :)
<Kamion> ooh, Debian fixed the yaboot initramfs/XFS bug
* Kamion sends UVF exception request
<HiddenWolf> rodarvus: I noticed x detects my resolution wrongly on the knot-1 livecd, which data should I gather for a proper bug report?
<dholbach> I started https://wiki.ubuntu.com/XSwat and worked on an announce of the team, but infinity and fabbione never found the time
<rodarvus> let me take a look there
<ogra__> mumble mumble ...
<rodarvus> HiddenWolf: to be sincere, I haven't touched any bits regarding xorg configuration during install, yet (so I'm not completely aware of the installer log files) - but /etc/xorg.conf and /var/log/Xorg.0.log are a good start
<rodarvus> also possibly the output of lspci -v
<HiddenWolf> rodarvus: Right, i'll start there then.
<bishop> ogra__: gnome-power-manager indeed does work when configured with --disable-policykit
<ogra__> bishop, it didnt two weeks ago
<ogra__> but actually it does now ...
<ogra__> (just uploaded it)
<bishop> ogra__: yes, theres some fancy charting and projecting in it now
<dholbach> yay
<ogra__> i suspect we're missing a versioned dependency on something
<bishop> ogra__: on eissue is that i have two batteries and when I swap them the new one is not recognized
<ogra__> bishop, no need to tell me that i spend about 4 workdays on it ;)
<ogra__> dholbach, i left the icon stuff in the source package, just disabled it in rules so you can fix/add the new icons and re-enable it ...
<dholbach> ok
<dholbach> merci beaucoup
<ogra__> but beware, there are a lot new ones and 50% need to be resized
<dholbach> will you do gnome-screensaver next?
<ogra__> is there a new one ? 
<ogra__> then i'll do it indeed
<dholbach> 2.15.4
<ogra__> oh, right 
<dholbach> ogra__: do you use a rss reader?
<ogra__> nope, but i can :)
<dholbach> http://ftp.gnome.org/pub/GNOME/LATEST.xml
* ogra__ apt-gets liferea
<dholbach> they have a mailing list as well, but it was broken some days ago, and i prefer rss anyway ;)
<dholbach> liferea is good stuff since slomo maintains it
* ogra__ loves tray icons :)
<dholbach> hehe
<dholbach> gotta collect them all
<ogra__> its the only reason i listen to intern radio all the day :)
<ogra__> *internet
<ogra__> just for the RB icon :P
<slomo> dholbach, ogra: but the mozilla/firefox backend is broken in latest edgy :( use the gtkhtml one for now
<StevenK> "I listen to Internet radio for the tray icons."
<dholbach> slomo: yeah
<dholbach> 'i don't know what this "gnutella thing" does, but it has a nice trayicon'
<ogra__> lol
<StevenK> Heh
<bishop> ogra__: which package is responsible for detecting that a battery has been swapped for another one?
<ogra__> bishop, hal
<bishop> ogra__:  ok, but /proc/acpi/battery is not changed
<bishop> as well
<ogra__> that sounds like a kernel prob then
<bishop> ogra__: so i file a bug against linu?
<bishop> x
<ogra__> i'd start with that ... the kernel team will point you in the right direction if its wrong
<bishop> ogra__: ok thanks. i'm down to 47% capacity on my small battery :(. something the new g-p-m made me aware of.
<ogra__> slomo, 
<ogra__> ogra@edubuntu:~/packages$ LANG=C liferea
<ogra__> A stale lockfile has been found, and was deleted.
<ogra__> No browser module configured!
<ogra__> trying to load browser module Mozilla (liblihtmlm.so)
<ogra__> Segmentation fault
<dholbach> ogra: what slomosaid
<ogra> thats not shipped it seems ...
<dholbach> ?
<ogra> ** (liferea:8216): WARNING **: Failed to open HTML widget module (/usr/lib/liferea/liblihtmlg.so) specified in configuration!
<ogra> /usr/lib/liferea/liblihtmlg.so: cannot open shared object file: No such file or directory
<dholbach> sudo apt-get install liferea-gtkhtml
<ogra> ah ... just found it with apt-file as well :)
<Mithrandir> seb128: why does gnome-system-monitor recommend ligksu2-dev and libsexy-dev?
* netjoined: irc.freenode.net -> brown.freenode.net
<StevenK> Mithrandir: Because gnome-system-monitor wants more sex appeal.
<Mithrandir> Kamion: the live cds include .disk/base_components , base_installable and udeb_include.  That's kinda wrong.
<Kamion> I guess, yeah
<doko> I LOVE vim's changelog mode ...
<Kamion> could you file an ubuntu-cdimage bug about that and I'll clear it up?
<Mithrandir> Kamion: sure.
<Kamion> ta
<zul> hi
<ogra> mumble mumble ...
<ogra> why the heck cant i convince g-s-s to pick up the xscreensavers ...
<ogra> seb128, i'm just stracing the g-s-s preferences gui, is it normap that such apps load all .desktop files on startup ? seems like a major slowdown to me ...
<ogra> *normal
<seb128> ogra: does it use the .desktop for something?
<ogra> nope
<ogra> open("/usr/share/applications/rhythmbox.desktop", O_RDONLY|O_LARGEFILE) = 19
<ogra> fstat64(19, {st_mode=S_IFREG|0644, st_size=7523, ...}) = 0
<seb128> I'll have a look
<ogra> thast from the strace
<seb128> is it using gnome-menus of libgnome-desktop for something?
<ogra> grepping for it doesnt show anything ... 
<ogra> i'll upload the output ... wait a sec
<seb128> I'll have a look and let you know if I figure something
<ogra> i dotn think thats the issue i have here, i just find it weird that it does it
<seb128> $ ldd $(which gnome-screensaver-preferences) | grep menu
<seb128>         libgnome-menu.so.2 => /usr/lib/libgnome-menu.so.2 (0xb76be000)
<ogra> hmm, not in the strace
<ogra> http://people.ubuntu.com/~ogra/gss.log
<ogra> open("/usr/lib/libgnome-menu.so.2", O_RDONLY) = 3
<ogra> err
<ogra> why didnt less find it ?
<ogra> weird ...
<ogra> hmm, seems less doesnt wrap while searching anymore by default ...
<seb128> ogra: hum
<seb128> "     - suspend and hibernate support need the new hal policy kit now so
<seb128>        please dont file bugs about either before that is avaliable in ubuntu"
<seb128> ogra: ?
<ogra> argh
<ogra> sorry
<ogra> i forgot to fix the changelog ... sily me
<ogra> *silly too
<seb128> Mithrandir: because ithey are dlopened at runtime
<seb128> ogra: ah ok, so it works? what was wrong before?
<tseng> ogra: :D
<Mithrandir> seb128: and it doesn't dlopen the soname, but the unversioned one?
<tseng> ogra: thanks for the hard work
<seb128> Mithrandir: no, the .so
<seb128> ups, misred
<seb128> misread
<ogra> seb128, dunno, i think it required a versioned dependency on something ... hughsie is offline atm, i'll ask him about it later 
<seb128> right, it opens the unversioned one
<ogra> the rebuild just worked
<seb128> Mithrandir: but you are right, that's ugly, I should patch to open the versionned and Recommends the binaries instead of the -dev for them
<seb128> ogra: weird, but nice that the update has been done
<Mithrandir> seb128: thanks. :-)
<seb128> np ;)
<ogra> seb128, yep, very weird, i cant imagine what caused it ... but building it 10 days ago resulted in non working binaries ... building the same today worked
<seb128> ogra: 
<seb128> $ grep gmenu gnome-screensaver-2.15.3/src/gs-job.c | wc -l
<seb128> 22
<seb128> ogra: src/gs-job.c:   themes_tree = gmenu_tree_lookup ("gnome-screensavers.menu", GMENU_TREE_FLAGS_NONE);
<seb128> ogra: must be some gmenu item parsing the .desktop
<ogra> hmm, but it should read from "gnome-screensavers.menu" as i understand it
<seb128> ogra: might be some performances work to do on it :)
<ogra> yeah
<ogra> first lest me look if gnome-screensavers.menu is correct :)
<ogra> hmm, according to that code we could also drop the --xscreensaver-* options from rules ... 
<mvo> hm, strange things after my dist-upgrade with X, it /etc/X11/X points to /bin/true
<Hobbsee> hi mvo 
<mvo> hi Hobbsee
<zul> mvo: yeah that is kind of weird
<pitti> mvo: would you object if I just close bug 47592?
<Ubug2> Malone bug 47592 in cupsys "breezy->dapper upgrade failure on amd64" [Medium,Unconfirmed]  http://launchpad.net/bugs/47592
<ogra> mvo, you picked a bad time for the upgrade :) rodarvus is just switching us over to 7.1
<rodarvus> err
<rodarvus> I didn't touched /usr/X11/X
<ogra> hmm
<mvo> pitti: no, go ahead
<rodarvus> (not now, at least :) )
<robertj> could someone please remind the inhabitants of the mailing list that the list has a lot of traffic anyway and that it's not appreciated when people go on about things that they have no understanding about at all? I'm quite sick of the me-tooing on the list, especiall RE: Avahi
<rodarvus> if someone did that, it must have been ocurred about 10 days ago
<rodarvus> (so, not very likely)
<ogra> yeah, -devel is a pain recently ...
<hyperactivecrond> has the installer for knot-1 crashed on x86 for anybody else besides me here?
<rodarvus> quite likely :D
<hyperactivecrond> i can't seem to find a bug report for it on lp.net
<ogra> seb128, what do you think about patching fusa out of g-s-s ad run gdmflexiserver directly ? 
<hyperactivecrond> rodarvus: yes it dies close to its finish
<rodarvus> hyperactivecrond: please check if this is one of the known problems of the knot-1 livecd, if not, search for bugs like this on LP
<ogra> fusa is very confusing since it doesnt prefill the gdm login ... i find it always very confusing that yu can select a user and dont gain anything from that 
<rodarvus> finally if they are not there, please report the bug you had
<rodarvus> hyperactivecrond: https://wiki.ubuntu.com/DapperReleaseNotes/UbiquityKnownIssues
<ogra> seb128, alternatively a --user option to gdmflexiserver that just prefills the username field would work too ...
<hyperactivecrond> ugh maybe becuase my /boot is in an xfs partiton :\ duh
<hyperactivecrond> alright no bug here then with ubiquity...
<hyperactivecrond> i'm going to try with a reiser / partition.. that might get it to install
<hyperactivecrond> and if not, bug reports away
<wasabi> cant believe this zeroconf thread is still going
<Kamion> the XFS thing should be fixed
<wasabi> rodarvus: update-font-dirs was breaking. Was trying to update a non existant dir.
* Hobbsee suspects someone should set a filter on the -devel mailing list for a couple of days, sending *zeroconf* to /dev/null.
<Kamion> hyperactivecrond: please just file a bug report about that ubiquity problem regardless
<Kamion> I'd much rather get duplicates than not find out about the bug at all
<hyperactivecrond> Kamion: it's already listed in the issues
<Kamion> hyperactivecrond: XFS?
<seb128> ogra: why do you want to do that?
<hyperactivecrond> Kamion: will do
<hyperactivecrond> Kamion: yes
<Kamion> hyperactivecrond: that is supposed to be fixed in knot-1. therefore, I want to know about it when it still fails
<ogra> seb128, because it doesnt work intuitive
<hyperactivecrond> oh ok i will do that then Kamion
<Kamion> i.e. the partitioner is meant to just disallow XFS /boot
<seb128> ogra: there is a list of user and you can just pick one, no?
<ogra> seb128, if you click switch user in the locked screensaver it opens a userlist ... if you select a user there and move on you get a gdm login but not the user prefilled
<hyperactivecrond> What would be useful for ubiquity though would be the option to change the FS type
<hyperactivecrond> it currently does not allow one to change the partition type.. or reformat as a different FS
<ogra> seb128, yes, sure, but selecting one doesnt result in anything :)
<gnomefreak> Kamion: the XFS is same with mac/yaboot?
<hyperactivecrond> Kamion: i'll also attach fdisk -l 's output for my partition table
<ogra> seb128, as long as it doesnt work as expected its just one unecessary click i have to do ... 
<Kamion> gnomefreak: sort of
<ivoks> howdy
<Kamion> hyperactivecrond: the logs requested in the crash message are all I care about
<hyperactivecrond> Kamion: ok will do
<Kamion> you can attach other random stuff if you like but I'll ignore it :)
<zul> Hobbsee: a mental filter is a nice thing to have as well
<Hobbsee> zul: that is true.
<Kamion> gnomefreak: XFS breaks with yaboot at present due to a yaboot bug, although there's a fix for that in Debian which we'll get soon
<seb128> ogra: I think there is some bug about it, gdm needs a --user option
<hyperactivecrond> Kamion: i'm installing right now...
<seb128> gdmflexiserver rather
<pygi> hey ivoks
<gnomefreak> ok im gonna look for the bug that i am thinking of
<Kamion> hyperactivecrond: please make sure to grab those logs before you reboot
<hyperactivecrond> btw when one tries to install xchat-gnome in knot-1 find complains about hard link count not being correct
<hyperactivecrond> Kamion: will do
<ogra> seb128, yes, either is fine ...
<Kamion> hard link count is a known weirdness with squashfs/unionfs; it's no big deal
<ogra> seb128, as i said above :)
<seb128> ogra: http://bugzilla.gnome.org/show_bug.cgi?id=342100
<Ubug2> Gnome bug 342100 in Applet "switch user should pre-fill the username for gdm" [Normal,New]  
<hyperactivecrond> Kamion: ok just making sure
<ogra> ah cool
<ogra> Click System  lock screen.
<ogra> hm, nifty ... whats the keycode for that triangle ?
<hyperactivecrond> Is the splash screen supposed to look ghetto in knot?
<Kamion> yes
<Kamion> it's a test card
<Mithrandir> U+25BA BLACK RIGHT-POINTING POINTER
<seb128> ogra: gucharmap, open the search and copy the char
<Mithrandir> seb128: or unicode(1)
<hyperactivecrond> Kamion: ok just making sure that its not a bug with usplash
<ogra> Mithrandir, thanks )
<ogra> :)
<rodarvus> wasabi: strange, this bug was supposed to be fixed
<rodarvus> (actually, it was supposed to exist only for a few days, during transition)
<ogra> rodarvus, i told you abuout it ...
<rodarvus> *nods* you did :)
<ogra> rodarvus, and you told me that we'd get a new version with 7.1 anyway :) 
<ogra> so just mae sure its fixed there :)
<ogra> *make
<sladen> keybuk: do we really have to put  TEST CARD  in really big letters for people to realise?
<Kamion> sladen: yes :-(
<ogra> wow, i wonder where that gnome-screensavers.menu.in came from its as wrong as it can be
<tseng> sladen: i kind of hoped that Keybuk's mail at the begining of the cycle would do it
<Kamion> sladen: (Keybuk's not here)
<tseng> sladen: so much for that
<tseng> we are unbroken enough to get your "crack-o-the-day" kids testing now
<hyperactivecrond> i'm not sure if this a gnome bug but shouldn't 'lock screen' be seperate from the 'quit' dialog box?
<wasabi> rodarvus: Eh, well, as of last night, fully apt-get updated, it happened.
<tseng> they didnt get the memo.
<wasabi> rodarvus: I fixed it by just killing those parts of the update-font-dirs script
<ogra> hyperactivecrond, you mean in a separate popup box ?
<wasabi> update-fonts-alias failed too for the same reason I believe.
<hyperactivecrond> ogra: in a seperate 'system' menu entry
<rodarvus> wasabi: I'll take a good look at it today, thanks for the report!
<ogra> nope
<ogra> that was dropped long ago
<hyperactivecrond> well that's a gnome quirk then ok
<ogra> at the beginning of dapper somewhere
<wasabi> Gnome-screensaver locking even though it's set not to lock in the panel known?
<ogra> wasabi, on which occasion ? by pain screensaving or after suspend ? 
<hyperactivecrond> i dont know if this would be a place for suggestions but maybe we should put xchat-gnome in the knot cds so that people can access this channel, rather than having to add the pkg first?
<ogra> *plain
<Mithrandir> hyperactivecrond: you can irc using gaim
<wasabi> plain.
<wasabi> It's a probably for me for a second reason: it won't let me unlock. ;0
<Kamion> xchat-gnome was intentionally removed from desktop in the dapper cycle
<hyperactivecrond> Mithrandir: i completely forgot about that. +1 branfart for me
<wasabi> s/probably/problem/
<hyperactivecrond> s/bran/brain
<ogra> wasabi, hmm ... are you sure your account is ok ? do you use any weird keymap setting or something ?
<wasabi> Oh. I'm quite sure my pam setup is breaking that part.
<wasabi> xscreensaver wouldn't let me unlock either.
<wasabi> Either way, I can't seem to turn it off. ;)
<ogra> can you look in your gconf-editor if there are any left over settings under /apps/gnome-screensaver (i.e. ones with no key owner or something)
<ogra> (they should all be owned by g-s-s)
<wasabi> dpms_suspend
<wasabi> that's it.
<ogra> hmm, thats moved to g-p-m since ages ...
<wasabi> lock_enabled is false
<ogra> can you change the values (i.e. check/uncheck lock_enabled)
<wasabi> Yeah. It's false.
<wasabi> But I still woke up this morning and had to kill it because it was locked.
<hyperactivecrond> Kamion: crashed. right now. during 'installing bootloader'
<hyperactivecrond> ..and i'm filing a bug report
<ogra> wasabi, hmm ...
<Kamion> ok
<ogra> wasabi, are you sure you only run g-s-s and dont have the x-s-s daemon installed/running
<wasabi> Yes.
<ogra> is /apps/gnome-power-manager/lock_use_screensaver_settings probably unset but /apps/gnome-power-manager/lock_on_blank_screen set ?
<wasabi> lock_on_blank is.
<ogra> yep .. thats it then ...
<wasabi> that's probably it.
<ogra> :)
<wasabi> where the hell is the setting in the UI?
<ogra> there is none ...
<wasabi> super. ;)
<doko> mvo: dselect-upgrade works now
<wasabi> So the whole "lock the screen" option in the g-s-s settings is pretty useless.
<hyperactivecrond> what is the package for ubiquity? ubiquity?
<ogra> as long as that default is set in g-p-m yes
<wasabi> Ahh. Well. Something should obviously be done about that. ;)
<wasabi> One of these days I'll fix teh actual unlocking problem, too.
<Kamion> hyperactivecrond: yes
<ogra> well, there were a lot of bugs for either side ... i think Kinnison just made *a* decision
<ogra> but while it makes sense to lock on hibernate and suspend by default, we should probably leave this one off
<hyperactivecrond> Kamion: just put the contents of the files it requests to be posted in the "further information, etc." section?
<Kamion> hyperactivecrond: file the bug, then use the "Add Attachment" link for each file
<Guard] [an> hello
<ogra> meh
<mvo> doko: thanks
<Guard] [an> i'm not sure it's the good place to ask, but still, where could i find the api reference for X11 ?
<Guard] [an> i need to learn how to code for X, without using GTK or QT
<ogra> seb128, dholbach, i cant copy/paste more than 50 lines from gnome-terminal anymore neither by select+middleclick, nor by shift+ctrl+c/v
<ogra> known ?
<ogra> s/50/~50/ (didnt count them)
<ogra> counted ... its 30
<hyperactivecrond> ugh great... i just put everything together as one
<hyperactivecrond> https://launchpad.net/distros/ubuntu/+source/ubiquity/+bug/53642
<Ubug2> Malone bug 53642 in ubiquity "When installing with /boot as an XFS partition, the installer crashes" [Untriaged,Unconfirmed]  
<Kamion> don't worry about it
<hyperactivecrond> Kamion: alright... i'm going to manually set the partition types with cfdisk then install
<Kamion> should be no need for that
<hyperactivecrond> Kamion: my / is an xfs partition.
<seb128> ogra: not by me, but that's rather dholbach who is maintaining that package
<Kamion> hyperactivecrond: create an ext3 /boot, then
<hyperactivecrond> Kamion: alright..
<ogra> seb128, oki
<Kamion> fiddling with partition types will not help you
<hyperactivecrond> Kamion: i haven't used a /boot in a while.. 320.79 mb should be enough?
<Kamion> hyperactivecrond: should be more than enough yes
<Kamion> BenC: we have a problem with the libata transition
<Kamion> BenC: the installer's mkswap has never set uuids on swap partitions
<dholbach> ogra: gnome bugs 348038 (vte), fixed in CVS
<Ubug2> Gnome bug 348038 in VteTerminal "Cannot mark and copy text larger than visible terminal area" [Normal,Resolved: fixed]  http://bugzilla.gnome.org/show_bug.cgi?id=348038
<ogra> dholbach, thanks :)
<Kamion> BenC: I can fix this for installs going forward, but for the upgrade process, we're going to have to mkswap again (and be VERY CAREFUL about possible hibernate images etc.)
<hyperactivecrond> I shall see if that grub bug while dealing with windowsXP dualbooting is still around, too
<hyperactivecrond> providing this install works
<hyperactivecrond> Kamion: it worked this time with /boot as ext3
<siretart> Keybuk: pong
<Keybuk> siretart: so, err, what's with /etc/rc0.d/S15wpa-ifupdown
<Keybuk> ie. what the hell is it doing?
<Kamion> 15:03 < Kamion> BenC: we have a problem with the libata transition
<Kamion> 15:04 < Kamion> BenC: the installer's mkswap has never set uuids on swap partitions
<Kamion> 15:04 < Kamion> BenC: I can fix this for installs going forward, but for the upgrade process, we're going to have to mkswap again (and be VERY CAREFUL about possible hibernate images etc.)
<Kamion> Keybuk: ^--
<Mez> Kamion, will you be at LRL this year?
<Kamion> Mez: no, afraid not
<pitti> Keybuk: dhcp3-server can also drop it's stop script at 0 and 6; do you already have a pending package or shall I care for this?
<pitti> Keybuk: ... and festival
<Mez> Kamion: shame :(
<pitti> Keybuk: ... and klogd
<Keybuk> pitti: festival and klogd should be in the archive (source wise)
<Keybuk> I didn't touch dhcp3-server because it wasn't a dep of ubuntu-desktop, feel free to do that one yourself
<pitti> Keybuk: ah, cool
<BirthdayHobbsee> Kamion: thanks for some of the syncs :)
<ogra> iwj, ping ... arent you a iptables specialist ? i'm looking for a hint
<Keybuk> Kamion: hmm, interesting
<Kamion> BirthdayHobbsee: no worries
<Kamion> and happy birthday, it appears ;)
<BirthdayHobbsee> Kamion: hehe, thankyou.  there are still some more that i'm waiting on :)
<hyperactivecrond> Grub now plays nicely with windowsxp
<BirthdayHobbsee> Kamion: hence the "some" bit :)
<ogra> BirthdayHobbsee, birthdays ?
<Keybuk> Kamion: if the swap is active, there won't be any hibernate image in it :)
<BirthdayHobbsee> ogra: hmmm?
<ogra> BirthdayHobbsee, we hope so :)
<ogra> BirthdayHobbsee, "  there are still some more that i'm waiting on :)"
<hyperactivecrond> Kamion: iirc this is already reported, /etc/apt/sources.list only contains edgy-security
<Kamion> BirthdayHobbsee: yeah, I was just doing a few of them because rodarvus had an urgent pair
<Kamion> hyperactivecrond: yep, already reported thanks
<BirthdayHobbsee> ogra: ah, right, yeah
<ogra> :)
<BirthdayHobbsee> Kamion: if you could put thru dar in your next batch, i'd appreciate it - then i can finish off kdar.
* BirthdayHobbsee doesnt have a set interest in the other few, apart from the fact that they're on the MoM
<Kamion> Keybuk: does swapon check for the hibernate signature?
<hyperactivecrond> Kamion: is it safe to put just edgy instead of edgy-security in /etc/apt/sources.list?
<Kamion> hyperactivecrond: "instead of" => "as well as"
<hyperactivecrond> Kamion: never mind
<Keybuk> Kamion: I assume so, you can't swapon a swap partition that's still got a hibernate thingy in it
<hyperactivecrond> Kamion: can i see a working /etc/apt/sources.list for edgy that contains something other than security?
<Kamion> Keybuk: right, just saying then that we need to check whether the swap is active as well as just whether it's in sources.list
<Kamion> hyperactivecrond: ok, come on dude, check the bit about support in the topic
<Kamion> sources.list fragments are trivial to find
<Mez> !tell hyperactivecrond about source-o-matic
<hyperactivecrond> Kamion: i heartily apologize
<hyperactivecrond> Mez: thx
<Keybuk> Kamion: fstab ;)
<Kamion> Keybuk: er right :)
<Kamion> thinking about two things at once
<Mez> hyperactivecrond, did that actually send you anything ? it used to confirm it with me
<Mez> wqhen it sent something
<Kamion> Mez: we don't have the bot here
<Kamion> (deliberately)
<Mez> Kamion: ah
<Mez> whoops
<BenC> Kamion: how hazardous is that mkswap transition?
<bddebian> Heya
<Kamion> BenC: it's *probably* ok with the check Keybuk suggested (is the swap active?)
<Keybuk> the only worry is that an upgrade isn't the time to call "swapoff" ?
<BenC> so it's something that'll be done on reboot?
<BenC> since the UUID stuff isn't need till the next reboot, that sounds safe enough
<Kamion> oh, huh, that's awkward
<BenC> actually, no it isn't
<Kamion> we'd need to check for the hibernate signature by hand rather than relying on whether the swap is currently active
<BenC> if the driver goes hda->sda, then it's too late
<Keybuk> right, swap devices a little more difficult
<Keybuk> Kamion: ?
<BenC> so you can't change the UUID of a swap partition while it's in use, like you can for ext2/ext3?
<Kamion> Keybuk: we need to ensure not to re-mkswap something that contains a hibernate image
<Keybuk> Kamion: right, if it's active, that's the clue -- no?
<Keybuk> also you can't make a UUID for a swap partition, no?  I thought they could only have labels
<Kamion> but if we can't do the mkswap until reboot, it won't be active any more
<Kamion> they can have uuids too, there's a slot in the v1 swap area header
<Keybuk> we can't do the mkswap after reboot, because the drive assignments will have changed by that point
<Kamion> if we could change it while it's in use, that would be ideal I guess
<Keybuk> yeah, I wonder whether we could just edit the active swap partition ;)
<Keybuk> I don't see why not
<fabbione> if they have space in the header area
<iwj> ogra: I can probably help you with iptables, yes.
<Kamion> two things: (a) will the kernel just overwrite it again (i.e. does it remember the existing header and blat it back out), (b) can we safely change UUID on an S1SUSPEND area too
<fabbione> i don't see why just change it on the fly
<Keybuk> Kamion: I don't know the answer to these two things ... what does an S1SUSPEND area look like?
<Keybuk> does it replace the swap header, or go after it?
<BenC> interesting, my swap has a UUID
<Keybuk> BenC: how did you find out?
<Kamion> Keybuk: the problem is probably that the UUID goes after the first page
<Kamion> of the swap
<fabbione> Keybuk: what will happen to special devices like RAID when you change the underlay device from hd* to sd*?
<BenC> ls /dev/disk/by-uuid/
<Keybuk> fabbione: no idea
<BenC> fabbione: LVM will handle it nicely
<fabbione> is somebody going to test this stuff before hand?
<fabbione> BenC: LVM i know.. what about RAID
<BenC> you'll have to edit the md config by hand
<Kamion> I'm not sure, but I have a suspicion that swsusp uses the area that swap uses for the UUID for something else
<Kamion> Keybuk: vol_id can parse it too
<ogra> iwj, i want to build a transparent content filter ... i have an OUTPUT nat rule that forwards everything from port 80 to another port ... i know there is a possibility to exclude by pid s the locally running content filter would be excluded from that port 80 rule, do you know any example pages where i could read up about that pid thing ?
<iwj> You mean an intercepting proxy ?
<Keybuk> Kamion: right, we'll have to find out how these partitions are structured
<fabbione> BenC: md config isn't of any use anymore.. the devices are autodiscovered via md magic sb
<Keybuk> and find someone with a laptop that has working suspend
<Keybuk> fabbione: autodiscovered devices should still work. no?
<BenC> fabbione: then the magic should still work
<iwj> I don't think you want to exclude by pid.  You want to exclude by local username, surely ?
<ogra> i mean a locally running transparent proxy without proxying but content filter rules :)
<Keybuk> fabbione: it's my understanding that they all just look for partitions with a given signature -- which will work fine
<BenC> fabbione: if it autodiscovers based on something other than hda/sda naming
<fabbione> Keybuk: i need to check, but i think RAID sb has hardcoded info of the other drives in the RAID
<ogra> well, then the app would need a own user, but that would work as well, yes
<iwj> (Also, please reconsider whether an intercepting poxy is the right answer.  They're generally a bad idea.)
<Keybuk> fabbione: if it has hardcoded kernel device names, that will need to be fixed
<iwj> ogra: check out iptables(8) and --uid-owner.
<ogra> iwj, its for ltsp servers that have no separate box for content filtering (its also not proxying, only a fiter)
<iwj> You almost certainly want that instead of eg --pid-owner.
<ogra> iwj, thanks ! thats the hint i was after :)
<Keybuk> let's move this into #ubuntu-kernel, because there are too many conversations going on at once
<iwj> If you want to enforce the use of the proxy, better to block port 80 rather than intercept it.
<BenC> Kamion: if it overwrites swap partitions UUID, then we are screwed anyway
<BenC> so either the UUID is good, or this whole excecise is futile
<fabbione>         __u32 major;            /* 1 Device major number                      */
<fabbione>         __u32 minor;            /* 2 Device minor number                      */
<fabbione> it stores info on major/minor for each device on each disk
<fabbione> at least this is according to the sb struct
<fabbione> how it's handled is something that needs to be verified
<ogra> iwj, i want it transparent ...
<BenC> yeah, because the device majors for hd and sd are different
<ogra> so users dont even have the ability to change proxy settings at all
<iwj> ogra: You mean you want it intercepting.  Why ?
<iwj> You can enforce the use of the proxy by blocking port 80.
<ogra> iwj, sure, but that means additional setup for the sysadmin
<ogra> since he will need to point the proxy settings to the proxy port then
<iwj> Err, you mean by default it will be set up not to use a proxy and the interception will get it ?
<ogra> yep
<iwj> Do we not have a way of setting the proxy settings globally ?
<ogra> totally transparent
<BenC> Kamion, Keybuk: I was able to run "sudo mkswap -L `uuidgen` /dev/hda4" on an active swap partition, and it didn't redo-the swap
<ogra> sure we have ... but it should hook in at a lower level 
<iwj> No, `transparent' is the wrong word.
<iwj> You mean `intercepting'.
<ogra> ok
<Keybuk> BenC: "redo the swap" ?
<iwj> I know marketroids use the word `transparent' for this because it sounds more friendly.
<ogra> for the sysadmin its transparent behavior :)
<iwj> But actually it's the opposite of transparent.
<BirthdayHobbsee> Keybuk: any reason why the -sa flag wouldnt be in merge-genchanges and merge-buildpackage, for the MoM scripts, for some merges?
<BenC> Keybuk: as in erase it
<ogra> the thing is that if the proggy is installed it should just work without configuration ...
<Keybuk> BenC: ok, so you can tune a swap on the fly?
<ogra> (on either side)
<Keybuk> BenC: what happens if you change the version? :p
<BenC> Keybuk: it would seem so
<Keybuk> BirthdayHobbsee: if the upload shouldn't need it because the orig.tar.gz should already be in the archive
<BenC> Keybuk: that's probably not possible :)
<BirthdayHobbsee> Keybuk: right, okay, that's what i thought
<iwj> RFC2616 `A "transparent proxy" is a proxy that does not modify the request or response beyond what is required for proxy authentication and identification'
<Keybuk> BirthdayHobbsee: sometimes it gets it wrong, dunno why
<BirthdayHobbsee> Keybuk: yeah, that's what i was thinking....
<iwj> ogra: See RFC3143 for why you don't want an intercepting proxy.
<iwj> `Known HTTP Proxy/Caching Problems'
<iwj> ogra: See in particular 3143 s2.2.1.
<iwj> `if the proggy is installed it should just work without configuration'> You mean it should do the configuration.
<iwj> Is there a spec for this ?
<iwj> `Solution(s)       Eliminate the need for interception proxies and IP spoofing, ...'
<ogra> iwj, nope its a SoC project ... and you cant do it differently on a ltsp server ...
<iwj> Why can't you do it differently ?
<ogra> at least if you dont have a second machine
<iwj> What's the second machine got to do with it ?
<iwj> I'm not suggesting you should have a second machine.
<ogra> well, thast the other way to set up a so called "transparent proxy"
<iwj> I'm suggesting you should reconfigure the UA to know to talk to the proxy; if you want to enforce use of the proxy you can block other processes' attempts to connect to port 80.
<iwj> I'm saying you DON'T WANT AN INTERCEPTING PROXY
<iwj> ARE YOU LISTENING TO ME ?
<ogra> yes
<iwj> So what is `thast the other way to set up a so called "transparent proxy"
<iwj> '
<iwj> That's not relevant at all.
<iwj> I know how one might set up an intercepting poxy on one or on two machines.
<iwj> I'm saying you shouldn't do it.
<iwj> You should block, not intercept, port 80.
<iwj> And reconfigure the browser.
<ogra> well the usual reciepe is to have a GW with nat rules where dansguardian or something similar runs ...
<iwj> I'm saying you DON'T WANT AN INTERCEPTING PROXY
<ogra> forwarding port 80 to something internally
<iwj> I'm saying you DON'T WANT AN INTERCEPTING PROXY
<pygi> iwj: can you please stop shouting? thanks :)
<ogra> i'm outlining what our userbase falls back to
<iwj> ogra: I'm saying you don't want an intercepting poxy.  Are you listening to me ?  Do you understand what I mean ?
<ogra> iwj, yes, and i dont want to have blocked settings in the ui
<iwj> Our aim is to produce sensible working setups, right ?  Discussion of crazy semi-broken setups is not interesting.
<lifeless> iwj++
<lifeless> interception is evil.
<ogra> i'D have to disable the ability to change the proxy settings if i do it your way
<lifeless> please dont make baby jebus kill butt plugs
<lifeless> ogra: that does not follow
<ogra> lifeless, well, some thousands of school sysadmins would disagree 
<Kamion> ogra: transparent proxies aren't. They cause all kinds of subtle problems that school sysadmins probably shrug their shoulders and try to ignore.
<lifeless> ogra: I'm spoken to god knows how many of them on IRC and email w.r.t. squid and interception
<ogra> its what they use everywhere 
<lifeless> ogra: and its broken everywhere!
<Kamion> that's not a good reason to perpetuate it
<Kamion> in order for a proxy to work correctly, the client needs to know that it is talking to a proxy
<ogra> i'm still not taking about a proxy at all ...
<ogra> but well
<lifeless> HTTP does not define semantics for interception. there have been uncountable many bugs related to interception-caching, and there will be uncountable more
<ogra> i'll look into it
<lifeless> if you hijack port 80, its interception
<ogra> i wsnt arguing that :)
<ogra> *wasnt
<iwj> uncountable many bugs> RFC3143 (from June 2001) is just the start of it.
<lifeless> if you give it to anything other than the requested port, and the thing you give it to may honour the request - then its a proxy
<wasabi_> Hmm. Cool. Fixed up swapd.
<wasabi_> It now creates one swap file minimum, and defaults to autodetecting the ram size.
<sladen> so.  We all in a agreement that Transparent Proxies are teh evil now?  Or perhaps so more shouting and burning of small children would help.
<lifeless> iwj: yahuh.
<lifeless> it was surprising to see it even being a subject for debate here. 
<lifeless> I *thought* we were all sane.
<lifeless> gnight
<BirthdayHobbsee> night lifeless 
<geser> is it possible to still use file-rc (an alternative to sysv-rc) on edgy?
<iwj> ogra: You don't need to disable the ability to change the proxy settings.  You can just firewall out port 80 so that if they change the proxy settings it stops working completely.
<ogra> iwj, yes, that apparently what i have to do ... even the traffic isnt even touched by the app ...
<ogra> *thats
<iwj> I'm afraid I can't make sense of that.
<sladen> ogra: "[x]  block direct web connections to the Internet (prevent proxy bypassing)"
<ogra> it works like a pipe ... delays the answer, recieves what the user wanted, does a bayesian check, if the target is not worth to be fitered it removes the delay and pipes the traffic ...
<ogra> thats all ... no rewriting of headers or the like ...
<iwj> ogra: Have you read RFC3143's comments on interception ?  If not go away and do so and come back when you understand.  If you don't think you want to or can understand then take the advice of people who do ?
<ogra> i'm just fearing that if we dont have the buzzword "transparent" anywhere teachers wont adopt it... but i'll try other solutions ...
<iwj> You can use the buzzword `transparent' whenever you like.  Remember that it's a marketing term and can mean whatever you like.
* iwj goes to do something more productive.
<ogra> yes, i know ... but it has certain expectations attached to it
<ogra> like you dont have to adjust anything :) but i'll find a way without interception ...
<Kamion> ogra: doesn't this content filter ever deny requests?
<ogra> it drops the traffic and puts a "access denied " page in place ...
<ogra> its very minimalistic
<Kamion> ogra: then it is an intercepting proxy within the meaning of RFC3143
<ogra> ok
<Kamion> it doesn't matter how small the changes it makes are
<Kamion> 200 -> 403 is a pretty big change all by itself :-)
<ogra> yep
<ogra> i'll go sladens way i guess ...
<bddebian> doko: around?
<ogra> even though its not what the teachers want ...
<Kamion> you're making the mistake of taking requirements at the wrong level
<Kamion> the requirement is not <particular technical implementation>
<Kamion> the requirement is <particular result for users>
<ogra> nope, its marketing driven
<ogra> yeah
<Kamion> you can write whatever you like in marketing, as iwj says
<Kamion> "transparent configuration of content filter"
<ogra> heh
<Kamion> also, marketing can be tweaked
<bddebian> Am I correct in understanding the Python policy that if it uses Python modules, it still needs the versioned python dependencies? (i.e. usr/lib/python2.x)?
<Kamion> marketing expectations I mean
<Kamion> if you do most of what people want, they will give you a bit more slack if you're different in one particular area, and eventually that approach may become the standard and they'll start asking others why they don't do it that way
<ogra> yes ... we'll see how it works out ... as long as i dont have to install squid on already extrabusy servers i'm fine
<Kamion> c.f. Ubuntu's sudo configuration, which was very unusual in the Linux world when we first did it
<ogra> but its userfriendly ...
<ogra> this is the exact opposite t the existing used setups ... from a userfriendlyness POV
<doko> seb128, dholbach: in unstable libgnomevfs2-dev depend on libbonobo2-dev, but not in edgy, leading to an OOo build failure. please fix or I'll rename the package to gopenoffice.gorg
<jdub> ogra: not to many traditional unix users
<Kamion> ogra: only if you don't put the effort in to make it user-friendly. :-)
<ogra> jdub, i'm talking about teachers 
<Kamion> ogra: and ultimately, not randomly breaking people's web browsing is user-friendly
<dholbach> doko: we're happy that gnomevfs doesn't use bonobo anymore - the situation is 'fixed'
<jdub> ogra: (re: sudo)
<ogra> Kamion, yes i uderstand and agree
<ogra> jdub, ah, right ...
<doko> dholbach, seb128: will that be changed in unstable as well?
<dholbach> doko: that's a change in gnome (gnomevfs) 2.15
<dholbach> doko: yes, once they use 2.15 too
<bddebian> Do be do be dooo
<seb128> doko: when GNOME 2.16 is packaged, which might be after etch
<seb128> doko: gnome-vfs uses dbus instead of libbonobo now
<seb128> doko: anyway, if OOo uses libbonobo it should have an explicit Build-Depends on it and don't expect that some other lib grab it 
<pitti> Keybuk: do you have a script anywhere (from MoM) that takes two changelogs and merges them together? svn merge produces nothing but a mess :(
<Keybuk> I have some python
<Keybuk> pitti: merge_changelog() in produce-merges.py
<Keybuk> sftp://chinstrap.ubuntu.com/home/warthogs/archives/scott/merge-o-matic
<pitti> Keybuk: thanks
<dholbach> can somebody get jokosher out of NEW? :-)
<geser> does anybody know if it should be possible to use file-rc (an alternative to sysv-rc) on edgy?
<geser> because some packages start depending on a specific version of sysv-rc and file-rc and sysv-rc conflict
<ogra> fabbione, there is something strange going on with the channel logs ...
<ogra> are you working on them ? 
<highvoltage> jdub: http://people.ubuntu.com/~fabbione/irclogs/ubuntu-devel-current.html seems confused, it's mixing -devel and -motu
* #ubuntu-devel  [freenode-info]  if you need to send private messages, please register: http://freenode.net/faq.shtml#privmsg
<bencer> hi all, i'm looking for documentation about how dapper livecd is generated, there's many info about how to remaster the ubuntu or kubntu livecds, but none about how are them generated by ubuntu team
<bencer> could you point me to something interesting ?
<fabbione> ogra: no what's wrong with them?
* Starting logfile irclogs/ubuntu-devel.log
<fabbione> test
* ..[topic/#ubuntu-devel:siretart] : proposed
<fabbione> siretart: mind to put the chan topic back?
* ..[topic/#ubuntu-devel:siretart] : "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 | http://wiki.ubuntu.com/HelpingWithBugs"
<siretart> fabbione: sorry, wrong alias command. my bad :(
<siretart> whats the deal with 'dapper-proposed' and 'edgy-proposed' upload targets? are they pocketed or a free for all upload target?
* Window 8
* 	Server: [0]  <None>
* 	Screen: 0x8181ddc
* 	Geometry Info: [77 81 0 4 4 4] 
* 	CO, LI are [79 87] 
* 	Current channel: #ubuntu-devel
* 	Query User: <None> 
* 	Prompt: <None>
* 	Second status line is OFF
* 	Split line is ON triple is OFF
* 	Logging is ON
* 	Logfile is irclogs/ubuntu-devel.log
* 	Notification is OFF
* 	Hold mode is OFF
* 	Window level is NONE
* 	Lastlog level is ALL
* 	Notify level is ALL
<fabbione> ogra: dude?
<fabbione> highvoltage: ping?
<fabbione> bah ok logs should be fine again
* fabbione -> weekend
<highvoltage> fabbione: ok, thanks. have a great weekedn!
<fabbione> highvoltage: please get somebody from the team to SMS me if it is still broken in let say one hour
<fabbione> i can't see anything obvious
<fabbione> actually
<fabbione> i can check it right now
<Kamion> siretart: dapper-proposed is supposed to be a staging area for dapper-updates
<Kamion> it's by approval only (uploads there land in the unapproved queue)
<Kamion> dholbach: jokosher doesn't follow the new python policy
<Kamion> dholbach: how does Jokosher.py get onto the $PATH for use by the .desktop file? (this is why I hate cdbs, it's bloody impossible to figure out what it's going to do short of building the damn thing)
<dholbach> Kamion: *whine* you mean that it should install to /usr/lib/python<something>?
<Kamion> dholbach: policy says that binaries on $PATH shouldn't have a .py suffix
<Kamion> dholbach: no? read the new python policy
<Kamion> it allows for private modules in /usr/share/foo
<Kamion> but you aren't doing the XS-Python-Version, XB-Python-Version, dh_pycentral/dh_pysupport (pick one) stuff
<dholbach> Kamion: the package is more of a hack, since upstream didn't manage to have a proper install/build system and relies on hardcoded paths for their first release
<dholbach> Kamion: that's why i adjusted the desktop file
<Kamion> sure, but there's no particular need for an upstream build system in order to follow the new python policy
<Kamion> you just need a /usr/bin/jokosher -> /usr/share/jokosher/Jokosher.py symlink plus the control/rules stuff
<rodarvus> I wonder if build speed on ia64 depends solely on processor speed, or if we are limited by memory/disk too.
<dholbach> Kamion: Ok. Thank you very much and I'll read it now.
<rodarvus> the ia64 machines on our build farm appear to take much longer to build than other platforms
<Kamion> dholbach: also, you need to copy the gstreamer licence exception from COPYING into debian/copyright
<dholbach> Kamion: Ok.
<Kamion> ah, I see the .desktop file patch now
<Kamion> (grr, patch systems, etc.)
<dholbach> Kamion: thank alot
<Kamion> dholbach: http://people.debian.org/~piman/python-policy/python-policy.html/ and http://wiki.debian.org/DebianPython/NewPolicy may be helpful
<dholbach> gracias
<elmo> rodarvus: it's a combination of CPU and the compiler being slower on that CPU
<elmo> rodarvus: it's certainly not memory or disk
<rodarvus> elmo: oh, thats sad news :/
<Kamion> dholbach: let me know when you've uploaded an improved version and I'll look at it
<dholbach> Kamion: you rock!
<rodarvus> means its basically quite hard to do anything there to increase build speed
<Kamion> we do need to follow the new python policy though, it's one of our goals for this release
<elmo> to be fair, we have realtively slow itaniums.  if we've been willing to spend the $$$, we could have got CPUs that would match or outclass our other platforms
<elmo> rodarvus: well, it shouldn't be a problem, ia64 isn't a blocker for anything as it's not a supported platform
<rodarvus> binaries are published on a per-arch basis, then?
<bddebian> Yep
<rodarvus> I'm usually waiting for ia64 to complete its builds, before uploading packages with build-deps
<Kamion> yes, the publisher works in units of .changes files
<Kamion> which, for us, are either source uploads or the output from a single buildd for a single source package
<bddebian> Kamion: Did you happen to see the sync request for xcircuit?
<Kamion> bddebian: yes, it's in the queue with the others
<bddebian> OK, thanks
<Kamion> you can always check https://launchpad.net/people/ubuntu-archive/+subscribedbugs
<Kamion> that's what we look at
<bddebian> Well I saw some others come through and I thought maybe I forgot to subscribe ubuntu-archive
<elmo> rodarvus: you shouldn't need to do that, the build-deps should be automatic, and even if they aren't, the only affected arch ia64
<rodarvus> elmo: in this case the package won't wait to build, as there is already an older version of the library installed
<bddebian> Can I bug anyone about my python policy question now?
<rodarvus> bddebian: don't ask to ask - just ask - someone might pick you question and answer it
<elmo> rodarvus: you should be increasing the build-depends in that case
<bddebian> rodarvus: I asked earlier :-)
<rodarvus> elmo: yeah, but its not a strict versioned build depends, just a "would nice to build with this new version" :)
<Kamion> bddebian: I only did a small pass earlier today, not a full one, 'cos I was in a hurry. in any event you can check the URL above to make sure
<bddebian> Kamion: Aye, fair enough
<Kamion> bddebian: what's your python policy question?
<elmo> rodarvus: IMHO those should be in build-depends, but that's just my opinion, I know others on the team disagreee
<bddebian> Kamion: If I understand it correctly, if a package uses python extensions, it is still correct to use python2.x build deps and /usr/lib/python2.x/ etc?
<elmo> in the long term we should really one day have build-depends-auto and build-depends-for-humans
<rodarvus> elmo: you're right, actually - the only reason I (personally) don't add these versioned build depends is to not diverge (more than needed) from debian
<Kamion> elmo: (it's awkward when some of what rodarvus is trying to do is sync with Debian)
<rodarvus> yup
<elmo> right, that's a valid use case for not doing it, I guess
<elmo> one day I should spec build-depends-auto
<Kamion> bddebian: as in compiled C extensions? build-depend on python-all-dev not pythonx.y-dev, compile for all $(pyversions -r), then install to /usr/lib/pythonx.y/ and use dh_pycentral or dh_pysupport
<Kamion> bddebian: please follow the howto in http://wiki.debian.org/DebianPython/NewPolicy for conversion
<Kamion> elmo: I sort of feel it should be possible for uploaders to set dep-waits in some limited way
<Kamion> dunno how that could be done sanely though
<rodarvus> via LP, after an upload, maybe?
<bddebian> Kamion: Thanks
<infinity> Could be represented at a Build-Depends-Strict in the .changes or something.
<infinity> s/at/as/
<infinity> (So as to avoid having our .dsc differ from Debian's)
<elmo> Kamion: I think build-depends-auto should be generated at build time  from shlibs type files, and shift the burden of what's needed to being by default on the library package as they are for Depends
<elmo> Kamion: but keep build-depends as build-depends for humans/backporters or whatever
<elmo> (not necessarily specific to ubuntu, I've thought Debian should do this for a long time too)
<Kamion> elmo: mm, I could agree with that yes
<Kamion> right, another partial sync run I'm afraid, have guests arriving and had to cut it short
<bddebian> So this:  mv $(CURDIR)/debian/tmp/usr/lib/python/* $(CURDIR)/debian/python2.3-libhamlib2/usr/lib/python2.3/site-packages
<bddebian> would become: mv $(CURDIR)/debian/tmp/usr/lib/python/* $(CURDIR)/debian/python2.3-libhamlib2/usr/lib/python_support/site-packages
<bddebian> ?
<bddebian> s/python2.3-ham/python-ham/
<dholbach> Kamion: I uploaded a new version. I hope it's alright now.
<bddebian> And would .dirs be /usr/lib/python-support/site-packages ?
<LaserJock> is the NEW queue fisable on LP at all?
<LaserJock> s/fisable/visable/
<LaserJock> or anywhere for that matter
<bddebian> Damn, I think I lost Kamion :-(
<infinity> LaserJock: Only to members of the archive team, afaik.
<bddebian> Heya infinity
<LaserJock> infinity: hmm, to bad :-)
<infinity> LaserJock: https://launchpad.net/distros/ubuntu/edgy/+queue <-- Can you see that?
<LaserJock> yes
<infinity> Oh, then I'm wrong.
<LaserJock> oh, that's a nice page
<infinity> Not visible if not logged in, which was all I checked.  I don't have an "unprivileged" account to test with.
<LaserJock> infinity: are they usually handled FIFO?
<infinity> LaserJock: They're handled however we feel like. :)
* bddebian bows
<LaserJock> of course, I should have guessed ;-)
<LaserJock> so does bribery help?
<infinity> LaserJock: If we need a specific thing for a build-dep, we process it.  If it's an easy package to process, we do it.  If it requires effort and research, it might sit for a bit.
<LaserJock> k, no problems, just wondering how the proccess worked
<infinity> (ie: sketchy licenses, complex package to give a once-over to, etc)
<infinity> LaserJock: What are you after having processed right now?
<LaserJock> infinity: not exactly anything in particulare there is an easy one (gisomount) that I'm tracking but that's it
<Gloubiboulga> infinity, I have new xubuntu seeds which should resolve the oversize issue, would it possible to run a new Desktop build?
<infinity> Gloubiboulga: I can give it a whirl.
<Gloubiboulga> infinity, seeds are at http://tiber.tauware.de/~gauvain/bzr/xubuntu-seeds/edgy/desktop, do you need something else (I'm very new to this)?
<infinity> Gloubiboulga: Oh, feh.  I thought you'd committed to the main branch and I already started the builds.
<infinity> Gloubiboulga: Do you not have access to commit to the seeds in LP?
<Gloubiboulga> infinity, if it needs main priviledge uploads, no
<infinity> Gloubiboulga: If you don't have the access to do so, can you get janimo to look over your changes, commit them, and do a xubuntu-meta upload.
<infinity> Gloubiboulga: THEN, I can spin new CDs.
<LaserJock> hehe, I love that phrase
<Gloubiboulga> infinity, well, the problem is that janimo doesn't even answer my mails...
<Gloubiboulga> that's why I was trrying to make this run myself :)
<Gloubiboulga> anyway, I'll wait for his answer
<infinity> Gloubiboulga: Perhaps he's away currently?  I dunno.  I prefer not to touch Xubuntu without his consent.
<Gloubiboulga> infinity, no problem
<bddebian> Kamion: still here?
<infinity> bddebian: 11:57 < Kamion> right, another partial sync run I'm afraid, have guests arriving and had to cut it 
<infinity>                 short
<bddebian> Gah
<bddebian> Damnit Jim
<infinity> bddebian: For the timezone-impaired, that was about 38 minutes ago.
<bddebian> Well shit, hamlib seemed to build with my changes, how do I know if I did it right?
<bddebian> Later folks
<highvoltage> bye bddebian 
<bddebian> Later highvoltage
* mvo is offline for a bit
<highvoltage> FINE
<jdub> fabbione: ping
<fabbione> jdub: pong
<fabbione> jdub: i only have 3 minutes or so before the movie start
<jdub> fabbione: i looked at the sparc/ pages on the wiki - any more info i should look at about installing on a T2000?
<jdub> (specifically dapper)
<fabbione> jdub: nope. it should just work
<fabbione> jdub: there is only the KnownIssues that you want to be aware of
<ogra> fabbione, logs are fine again ... somehow -motu and -devel were merged this afternoon
<jdub> so the comments about silo CD booting and stuff is no longer relevant?
<jdub> oh
<fabbione> ogra: yes i have no idea why because the logs were good here
<jdub> so it's relevant?
<ogra> (only in ubuntu-devel-current.html )
<fabbione> jdub: it's not relevant for the T2000
<jdub> ah, ok
<fabbione> jdub: it's OBP version dependent
<fabbione> jdub: T2K is fine
<jdub> sweet
<jdub> but skipping 1MB at the start of the disk does apply, etc?
<fabbione> jdub: something you really want to do carefully is d-i refresh waiting time
<fabbione> jdub: yes that's generic to the sparc disk layoyt
<fabbione> layout
<jdub> ok
<jdub> thanks :-)
<fabbione> jdub: *IF* you install via telnet sessions
<fabbione> the installer is in *color*
<fabbione> serial 9600 bps eyecandy
<fabbione> (next will be GLX over 9600)
<jdub> heh
<fabbione> it takes time to refresh stuff.. let d-i to do the full refresh before you start pushing buttons
<fabbione> even when inside a menu
<fabbione> otherwise strange things can happen
<jdub> right
<fabbione> otherwise.. works for me, David Miller, SUN but not for elmo
<fabbione> so if you manage to fail, sucks to be you :P
<jdub> apparently sparc hardware hates elmo and/or vice versa
<fabbione> jdub: ehehe yeah i noticed.. sparc hates znarl too
* jdub wonders if sparc will hate spads too
<zul> sorry...i saw that as spaz
<LaserJock> yeah, if you spaz I'm sure sparc will hate you
<fabbione> ok you are all set
<fabbione> have fun
<fabbione> -> movie
* jdub hugs fabbione 
<fabbione> jdub: have fun with the t200
<fabbione> jdub: you will notice the typo in the OBP ;)
<fabbione> jdub: oh btw.. let me find something for you
<fabbione> how much ram do you have on that box?
<fabbione> jdub: ?
<jdub> fabbione: not sure, the box is in boston
<fabbione> jdub: http://sunsolve.sun.com/search/document.do?assetkey=1-21-122430-03-1 <- ALOM/OBP update.
<fabbione> jdub: unzip the jar, read the instructions on how to update
<fabbione> it's not required
<fabbione> but it's nice to have
<fabbione> jdub: ok, have fun
<fabbione> i am off
<jdub> doable with ubuntu?
<fabbione> you do the update via the ALOM itself
<jdub> oh
<fabbione> all the procedure is explained there
<fabbione> just read it
<fabbione> i did it, you can do it :D
<jdub> ;-)
<jdub> thanks!
<fabbione> cya
<djbmister> does anyone have experience with the ubuntu kernel 2.6.15 and powerpc?
<djbmister> this question is mostly related to a chrp system - pegasos 2
<djbmister> any powerpc devs here?
#ubuntu-devel 2006-07-22
<troy_s> who is working on the installer?
<Burgwork> troy_s, that would be Kamion 
<Burgwork> troy_s, what is your issue?
<lifeless> morning
<Burgwork> morning lifeless 
<tseng> hello lifeless 
<bluefoxicy> The morning sun has breathed life into the lifeless
<bluefoxicy> Welcome back to the land of the living.
<holycow> guys ... does anyone know what happened to apt-setup in dapper?
<holycow> it doesn't seem to exist any more?
<shawarma> I'm trying to install a new system with debootstrap (only ssh access to the box)... I used to do the debootstrap and the base-config and that pretty much took care of everything. Now that base-config is empty in Dapper is there a similar way to do it?
<crimsun> what functionality do you need it to have?
<crimsun> you can probably get away with editing /etc/fstab and /etc/host{,s}, executing shadowconfig on, and installing a language pack
<crimsun> also tzconfig
<shawarma> crimsun: Yeah, that's pretty much what I have on my checklist as well.
<shawarma> crimsun: I just wanted to make sure I didn't miss anything. 
<shawarma> crimsun: How about creating the admin group? Is that done by some package or is it the installer?
<crimsun> beyond my familiarity, probably the latter.
<shawarma> Probably.
<bddebian> Heya
<Hobbsee> Kamion: thanks for dar :)
<mantas> Hi all
<mantiena> doko, Hi, could you tell me if you are planing to backport OpenOffice.org 2.0.3 to Ubuntu Breezy ?
<sharms> mantiena: https://help.ubuntu.com/community/UbuntuBackports
<Burgundavia> mantiena: no, just to dapper
<mantiena> sharms, I don't find any info about OpenOffice backports plans at https://help.ubuntu.com/community/UbuntuBackports
<mantiena> Burgundavia, I'm asking not about official backports, but about private doko backports, he oftet puts OOo backports to http://people.ubuntu.com/~doko/
<sharms> mantiena: you find out how to request it, and that is all the information available.  Any developers are generally working on edgy, not a distribution release 2 back
<sharms> mantiena: in that case ask doko
<mantiena> sharms, I'm not requesting, I'm just asking about doko plans, because I need OOo 2.0.3 for Breezy and I'm planing to make backport if doko isn't planing to make backport for breezy ;)
<liable> what are the build depends for compiz/compiz-gnome??
<tseng> apt-get build-dep compiz
<tseng> next time ask #ubuntu please (see topic)
<liable> right. thanks
<doko_> mantiena: no plans. if you do that, please name the packages openoffice.org2-*
<mantiena> doko_, why I need to rename openoffice.org 2.0.3 packages to openoffice.org2 ?
<fabbione> mantiena: because that's how OOo 2 was called in breezy
<mantiena> fabbione, this was a beta/unstable version of OOo, I think such package name just confuses users - in all ubuntu and debian versions (except breezt) stable version of openoffice was called openoffice.org, because of this I think better packages name for breezy backport is openoffice.org
<fabbione> mantiena: doesn't matter. use the same name convention or you will make people very upset
<mantiena> are there any other important reasons why I need to change name of OOo 2.0.3 to openoffice.org2 ?
<fabbione> specially because somebody might land with OOo in version 2 and start filing bugs
<fabbione> ^^
<fabbione> and that would make doko very upset
<doko_> mantiena: fabbione already said all ...
<mantiena> fabbione, sorry, I don't understand. If there are bugs in OOo 2.0.3 ubuntu packages, then why don't fill them in launchpad ?
<doko_> just don't package names in a release
<doko_> just don't change package names in a release
<fabbione> mantiena: because bug filed again OOo in breezy automatically tells us what version to look for
<fabbione> mantiena: if you change the version in a stable release, and we start getting bugs
<fabbione> mantiena: it becomes impossible to track what the hell is going on
<fabbione> mantiena: to the point in which we can't support OOo in breezy anymore. So by definition you don't override package names in a release
<fabbione> mantiena: you do it with the proper ones
<fabbione> mantiena: and a backport, will show a whole new world of bugs
<fabbione> mantiena: that 1) we don't care about 2) nobody is going to fix 3) we don't care about 4) all of the above
<mantiena> fabbione, it's too hard for me to understand you :(
<fabbione> mantiena: well i can't help your english
<mantiena> fabbione, ;)
<sivang> morning
<sivang> fabbione: is there somehwere archives devel meeting logs with dates ?
<fabbione> simira: wiki
* sivang goes to look
<sivang> ah,okay, only two archived so far, which is probably only the ones I missed :)
<The_8472> ok, whoever reads this, i've a little request (being from the azureus support staff):
<The_8472> you updated your gtk build at some point which broke a little part in azureus' gui and gets us lots of of complaints...
<The_8472> it's already fixed in the current azureus cvs tree and the current beta builds
<The_8472> it would be nice if you could update your repository and ship a beta to fix that bug, otherwise azureus is a bit unusable because ontop slideshells aren't hideable and thus steal focus from the interface
<The_8472> thx
<slomo> The_8472: you might want to file a bug for that... https://launchpad.net/distros/ubuntu/+source/azureus/+filebug
<The_8472> do i have to register for that?
<The_8472> blergh... that would be the case
<The_8472> i'm not using ubuntu, i'm just forwarding a good load of complaints ^^
<slomo> ok, i'll file the bug for you :) but there already should be one
<The_8472> thx
<The_8472> yeah, but it would be nice if you guys could deploy a beta instead of the latest stable... that should fix it for the time being...
<The_8472> https://launchpad.net/distros/ubuntu/+source/azureus/+bug/41813 <- that's the bug
<Ubugtu> Malone bug 41813 in azureus "pop-up dialogs doesn't close." [Unknown,Unknown]  
<slomo> yes, already found it :) and it's fixed in debian already
<The_8472> as i said it causes lots of complaints and some users even don't have a clue how to locate the .jar file, so an autoupdate would be neat
<The_8472> thx guys
<\sh> is there any plan to propose discover to main?
<Hobbsee> doko_: i just stole your xgsmlib (universe merge) - hope that's okay with you
<bddebian> Howdy
<desrt> pitti; good morning
<pitti> hi desrt 
<desrt> pitti; it rains here.
<Hobbsee> hi pitti, desrt 
<desrt> Hobbsee; hello.
* desrt is in the market for exotic apple power adaptors :/
<desrt> it's a bad market to be in.
<Arbiter> ehm... could you nuke this upload? colorscheme [Source]    0.3.91-0ubuntu1  Release  2006-07-20 11:05:07 CEST  [view] 
<Arbiter> (it's in NEW queue)
<Arbiter> upstream has changed the application name and i made another package
<Arbiter> (colorscheme -> agave)
<darius_> Is it safe to assume that someone knows that US repositories are down?
<gnomefreak> darius_: normal
<sebest_> why do 64 bits kernel are not available on 32bits install?
<sharms> sebest_: #ubuntu will help you out
<sebest_> sharms: already tryed
<sebest_> sharms: do you know the answer?
<sharms> sebest_: to my knowledge if you installed the 64-bit kernel, nothing on your system would run 
<sharms> sebest_: unless you had everything in a 32-bit chroot, which would be messy and above most peoples ability
<sebest_> sharms: you mean, that if i compile a 64 bit kernel it can't work with a 32 bit install?
<sharms> sebest_: yes
<sebest_> i thought that only the contrary was true
<sharms> sebest_: if you are looking for better 32-bit performance just install linux-k7, it is still optimized for your processor.  Otherwise install an amd64 based system, so that the packages are all 64-bit and will run on your kernel
<sebest_> i have xeon MP
<sebest_> so i think i should use the amd64 version
<sebest_> in fact i didn't want to reinstall everything just to have a 64 bits kernel
<sharms> sebest_: directly from ubuntu.com download page: For computers based on the AMD64 or EM64T architecture (e.g., Athlon64, Opteron, EM64T Xeon). It is not necessary for all (even most) processors made by AMD -- only their 64 bit chips.
<sebest_> i need a 64 bit kernel to run 64bit guest os in vmware
<sharms> sebest_: this is really better suited for #ubuntu, this is not a support channel or discussion channel
<zul> do you have the amd64 kernel installed?
<sebest_> sharms: sorry, but #ubuntu seems only usefull for probleme about firefox and gnome in general
<sharms> sebest_: #vmware can't help you?  odd
<sebest_> zul: no, for some reason apt-cache search doesn't list this version of the kernel
<zul> did you install from the amd64 cd?
<sharms> zul: no this is all covered in the above test
<sebest_> sharms: my problem is not related to vmware
<zul> if you have an amd64 that is
<sharms> zul: he is running a 32-bit system and wants a 64-bit kernel
<zul> ah
<sebest_> i don't see any reason i couldn't install a 64bit kernel
<sebest_> they can run both 32 and 64 bit binaries IMO
<sharms> sebest_: because the 32-bit compatibility leaves much to be desired in integration at this point.
<sebest_> sharms: ok, thanx for your help , i'll install -amd64 version of ubuntu
<sharms> good luck
<sebest_> sharms: just a last question
<sebest_> dapper contains a package  called kernel-patch-vserver, and the patch in it doesn't apply on package linux-image-2.6.15, is it considered as a bug?
<sharms> sebest_: you cannot apply a patch to a linux-image file, because it is already compiled
<sharms> sebest_: a patch infers that you have the source code and will later compile
<sebest_> linux-source
<sebest_> sorry for the confusion
<sebest_> linux-source-2.6.15
<sharms> sebest_: it appears it *should* apply to that
<sebest_> 4 rejected appeared
<sharms> sebest_: https://help.ubuntu.com/community/ReportingBugs
<sebest_> sharms: i know how to report bugs on ubuntu, even if i may look like a noob i'm using launchpad since a long time
<sharms> sebest_: great! Go for it then :)
<bluefoxicy> Is there a point to edgy's bootsplash?
<bluefoxicy> A bunch of boxes, circles, colors, and black and white stripes seems .. I dunno.  o.o
<gnomefreak> bluefoxicy: its a test usplash
<crimsun> bluefoxicy: https://lists.ubuntu.com/archives/ubuntu-devel/2006-July/019435.html
<HiddenWolf> Gees, that surely created a lot of fuss
<bluefoxicy> ah
<bluefoxicy> No I was just curious as to wtf it was for.
<HiddenWolf> bluefoxicy, seriously, when did test screens on unused tv-channels go out of fashion.
<bluefoxicy> HiddenWolf:  they were replaced with snow IIRC.  :P
<HiddenWolf> I feel old now.
<HiddenWolf> I knew what it was the second I saw it.
<HiddenWolf> Which didn't stop me from having an "OMG, UGLY" moment.
<bluefoxicy> It's unfortunate that apparently we can only use something like 16 colors
<bluefoxicy> has anyone booted a Gentoo 2006.0 install CD?  It comes up with this friggin' awesome boot splash, shows icons as each thing loads and everything, but I think it uses every possible shade of blue and purple with <60 luminoscity
<bluefoxicy> apparently keybuk found (new) laptops that break with anything over vga16fb though :<
<bluefoxicy> or kamion.. .or someone else... one of those two told me something about high color bootsplash breaking things.  :/  How unfortunate.
<HiddenWolf> bluefoxicy, yeah, hardware developers suck.
<HiddenWolf> If they can get away with developing broken crappy stuff, they'll do it to save a dime.
<bluefoxicy> it'd be nice if it could be tested for at least.
<HiddenWolf> Yeah.
<HiddenWolf> unfortunately, that will never happen. :)
<bluefoxicy> HiddenWolf:  I want to make a desktop background that if you sub-pixel anti-alias it it spells out something :P
<bluefoxicy> it'd be like Disney.
<bluefoxicy> "artywulf was fired from the Ubuntu Art Team today when somebody noticed that passing the Ubuntu desktop background image through an antistropic filter produced clear writing that stated, 'Ubuntu works best on AMD processors because Intel can't design shit'"
<HiddenWolf> eh?
<HiddenWolf> You're kidding me?
<bluefoxicy> what?
<HiddenWolf> What you just pasted.
<bluefoxicy> I didn't paste that; try reading everything I say and not just the last line
<HiddenWolf> Yeah, you want a cool background, the inspiration is that someone messed with a background?
<bluefoxicy> no XD
<bluefoxicy> It's completely hypothetical wtf
<HiddenWolf> heh
<bluefoxicy> actually the inspiration would most nearly be Disney, since artists frequently get fired for freudian undertones in their art
<HiddenWolf> that's why I asked if you were kidding. :)
<bluefoxicy> the most well known are the castle in the Little Mermaid movie poster, and the writing in the dust that gets brushed up when Simba and Nala are wrestling in the Lion King
<HiddenWolf> I did not know that.
<HiddenWolf> I'm a typical consumer, I watch movies for the story.
<HiddenWolf> And don't think about them for a minute when I get out.
<bluefoxicy> Ah.  The little mermaid one I've seen, it's on http://artfiles.art.com/images/-/The-Little-Mermaid-Poster-C10313393.jpeg That one, which is also the box art for the video casset release.
<LaserJock> jeeze that's dumb, you really have to be looking
<HiddenWolf> What is supposed to be in it?
<bluefoxicy> http://www.snopes.com/disney/films/mermaid.htm
<bluefoxicy> (possibly NSFW sry)
<bluefoxicy> and yeah, it was an "accident"
<bluefoxicy> the artist who drew it really "didn't know" that it looked like that
<HiddenWolf> LaserJock, damn, how did you spot that so fast?
<pygi> hey raphink
<slomo> infinity: ping? please give-back gnucash everywhere... thanks :)
<bluefoxicy> crap
<bluefoxicy> speaking of gnucash I never noted how much I spent on food yesterday in my accounts.
<zul> reall...how interesting and how offtopic
<bddebian> :-)
<gnomefreak> bddebian: would you happent o know where i can find latest konsole tar?
<robertj> so once a package is synced, what has to happen for it to find it's way to the packages archive?
<bddebian> robertj: Once it builds successfully on the buildds it gets moved in
<bddebian> gnomefreak: You mean upstream?
<robertj> ahh so It's time to go scrounge the build logs?
<gnomefreak> bddebian: i want to build it from source but cant find ttar
<bddebian> It's part of kdebase
<gnomefreak> that means i have to build kdebase?
<bddebian> Yep
<gnomefreak> :( ty
<bddebian> And why would a gnomefreak want konsole? ;-)
<gnomefreak> lol
<gnomefreak> i like kde but this type of thing keeps me a gnomefreak :)
<sistpoty> gnomefreak: hm... konsole sometimes just hangs for me... do you have the same problems?
<gnomefreak> sistpoty: nope
<gnomefreak> sistpoty: i need to build it for links
<sistpoty> ah... k
<gnomefreak> konsole doesnt let you open links
<gnomefreak> ill brb
<robertj> bddebian: i'm stumped, I can't find the build logs. Are they somewhere besides http://people.ubuntu.com/~lamont/buildLogs/
<bddebian> robertj: They are on launchpad now.  What's the package?
<robertj> tremulous
<bddebian> Hmm, should be there:  https://launchpad.net/distros/ubuntu/edgy/+source/tremulous/1.1.0-2
<robertj> it shows they built successfully but https://launchpad.net/distros/ubuntu/edgy/+search?text=tremulous fails
<crimsun> they won't be there because they're in the NEW queue.
<crimsun> https://launchpad.net/distros/ubuntu/edgy/+queue?queue_state=0&queue_text=trem
<robertj> crimsun: so what happens next?
<robertj> there needs to be a video documentary, like when Sesame Street visits the crayon factory
<crimsun> robertj: an admin will NEW it
<robertj> is there a very-import-and-very-obvious document that outlines this stuff?
<robertj> I'm sure it's gotta be there somewhere
<Amaranth> robertj: debian might have something about it
<Amaranth> launchpad works the same way
<Amaranth> with the NEW queue and such
<robertj> ok sauerville now works with the new version ;)
<robertj> doh wrong channel ;)
#ubuntu-devel 2006-07-23
<robertj> Amaranth: thanks, http://ftp-master.debian.org/REJECT-FAQ.html sheds some light on what that phase is for. I assume packes in NEW are reviewed periodically without the need for poking?
<Amaranth> i think so
<Amaranth> most people poke though
<robertj> so who is the most-chosen victim of such attention?
<crimsun> robertj: yes, they are.
<robertj> so err, don't poke?
<crimsun> correct, unless it's a critical package
<robertj> ok, no-pokey pokey
<jadaz87> hello everyone i was wondering if there is a list somewhere of every package that is installed by default for the ubuntu server distro
<Burgundavia> jadaz87: see the seeds, http://people.ubuntu.com/~cjwatson/seeds/
<jadaz87> ahh thanks Burgundavia 
<Burgundavia> jadaz87: no worries
<jadaz87> Burgundavia: and it has everything categorized thanks
<jadaz87> Burgundavia: may i pm you?
<Burgundavia> sure
<LaserJock> the seed are also on LP
<LaserJock> I'm not sure if they are kept in sync with ^^ or not
<warpup_lite> hmm
<sistpoty> mjg59: thanks for the feedback on debian/copyright issue... I'll overhaul parts of the FAQ (tomorrow, it's 3.30 here)
<warpup_lite> debian copyright?
<sistpoty> warpup_lite: see the ubuntu-motu mailing list at lists.ubuntu.com
<warpup_lite> i don't have an account at lists.ubuntu.com
<infinity> slomo: Done.
<bddebian> Heya infinity
<Hobbsee> warpup_lite: make one?
<sistpoty> mjg59: sorry for last highlight, mixed up nicks here
<mjg59> sistpoty: No problem :)
<Hobbsee> hi mjg59, and everyone else
<mjg59> Oh my god I've been in a converted warehouse and there was loud music and it was entirely I WANT IT TO LOOK JUST LIKE THIS
* jdub straight-arms a laptop against the wall
<bddebian> heh
<mjg59> jdub: totally
<mjg59> We need to bring GUADEC people her next year
<mjg59> (I'm in Wolverhampton, which is about 20 minutes from Birmingham)
<mjg59> AND YES, IT'S IN THE MIDLANDS
<Hobbsee> heh...hi jdub 
<jdub> morning Hobbsee 
<jadaz87> repos down?
<mjg59> jdub: We watched Jono shave his beard. It was touching.
<jdub> mjg59: WHO was touching?
<bddebian> jadaz87: Just US afaik
<jadaz87> bddebian: oh ok
<mjg59> jdub: Bastian
<mjg59> Damned Frenchmen
<mjg59> Hrm.
<mjg59> One of these lightswitches makes the room go dark, the other does nothing
<LaserJock> bddebian: I think CA is also down
<bddebian> Oh really?  Hmm
<Burgundavia> bddebian: ca has been having issue for a while now
<bddebian> Well I know that, but I didn't know their archive was having problems.. ;-P
* Burgundavia smacks bddebian
<bddebian> Burgundavia: Uh-oh, are you from Canukistan? ;-)
<Burgundavia> bddebian: well, lets just say that ubuntu.ca and my home machine resolve to the same IP address
<bddebian> Doh :-)
<mjg59> Oh christ Linus is sending me bug reports
<Burgundavia> mjg59: aren't you special
<LaserJock> mjg59: are they good?
<bddebian> Heh
<mjg59> He's absolutely right - everything only works by accident and we're doomed to death
<bddebian> Hmm, joyful outlook
* mjg59 replies
<mjg59> It's possible that I should have waited until I was sober
<Burgundavia> mjg59: nah, that makes things less fun
<Burgundavia> hey js
<Burgundavia> jsgotangco, that is
<jsgotangco> that is?
<mjg59> Burgundavia: But dude, it's Linus
<LaserJock> mjg59: maybe he was less than sober when you reported the bug so you are even :-)
<LaserJock> *he reported
<mjg59> LaserJock: Well, ther were capitals...
<LaserJock> uh oh
<mjg59> From Linus, not me
<jadaz87> hmm it seems the repos errors are only for some people
<Burgundavia> jadaz87: uhh?
<jadaz87> Burgundavia: i tried sudo apt-get update
<jadaz87> and it times out
<jadaz87> the first couple go through though
<Burgundavia> you using the US or CA repos?
<jadaz87> Burgundavia: how can i tell?
<jadaz87> Burgundavia: probably the us since i am in NJ
<Burgundavia> check your sources.list
<Burgundavia> move off the us repos, they have had issue for a while now
<jadaz87> Burgundavia: oh ok thanks
<jadaz87> :)
<jadaz87> interesting does the same thing
<davyd> hi all
<davyd> has anyone noticed problems with NetworkManager in edgy?
<ploum> I think that we really need python-sexy in Edgy
<ploum> (python bindings for libsexy)
<ploum> Ok, I admit...
<ploum> I need them...
<lfittl> ploum: please link to the debian rfp when you add it on https://wiki.ubuntu.com/MOTU/Packages/Candidates, thanks
<ploum> lfittl: It was not yet listed
<ploum> I plan to add the link when it will appear
<lfittl> ploum: oh, k :)
<Espenfjo> Is there a changelog somwhere? A place i can see what packages have been changed, and why? Mainly in Edgy
<Gloubiboulga> Espenfjo, the edgy-changes ML
<Gloubiboulga> you can browse the archives
<Espenfjo> ok
<ulaas> i have a flashing apps menu
<jsgotangco> that's known in edgy
<ulaas> jsgotangco: thanx
<Lathiat> hrm, problems with the websites?
<Spads> Lathiat: We are aware of the problem and are working on it.
<Lathiat> heh your subnet isnt even in the global route table
<Lathiat> awesome :)
* Treenaks wonders why the -server kernel won't boot on his system
<sivang> Spads: you the new web master? :)
<Hobbsee> sivang!!!!
<Spads> sivang: no, not exactly
* Hobbsee hugs sivang 
<bddebian> Howdy
<bddebian> Uhm, I know some of the archive machines are having problems, but are other machines having issues today?  I can't get to changelogs.u.c..??
<shenki> the datacentre is down, apparantly
<bddebian> Eeks
<shenki> "Spads> shenki: It's a known problem, and we're working on it."
<bddebian> Thx shenki
<shenki> np
<zealot> Can anyone give me an idea of why *ubuntu.com is down? I'm just curious...
<shenki> heh
<zealot> Did they have a powerfailure in the datacenter or something?
<Hobbsee> argh, what'd i miss?
<bluefoxicy> <blondie> the crappy ubuntu servers got h4x0red
<bluefoxicy> confirm/deny
<Spads> Deny.
* bluefoxicy swats silly user.
<HiddenWolf> bluefoxicy: they got beamed up by martians
<Spads> bluefoxicy: on point of fact, our servers are now more secure than ever
<bluefoxicy> what does that mean, stack smash protection everywhere?  Don't say you installed openBSD.
<jdub> electricity is *SO* insecure.
<HiddenWolf> Spads: yeah, you can't hack em while offline. ;)
<Spads> HiddenWolf: exactly :)
* Spads electrocutes jdub 
<HiddenWolf> jdub: it's a blackout?
<thom> jdub: http://www.ipapp.com/broadband.html ;P
<bluefoxicy> having the power out is not secure
<bluefoxicy> it totally drops availability.
<jdub> thom: especially that kind!
<bluefoxicy> so what this is a case of somebody needing to set up redundant power in the server facility?
<robertj> so who was it that tripped over the plug :)
<HiddenWolf> Someone without the muscle to put that big heavy plug back in. ;)
<Chipzz> network problems guys?
<robertj> bunch of former employees leave to form own initiatives...ISP goes down for "unknown" reasons...convenient eh? :)
<Chipzz> archive.ubuntu.com (82.211.81.182) is unreachable
<Chipzz> so is security.ubuntu.com (82.211.81.138)
<HiddenWolf> and launchpad.net
<HiddenWolf> and markshuttleworth.com
<HiddenWolf> and the forums, kubuntu, xubuntu, edubuntu
<HiddenWolf> etc. :)
<Chipzz> trace seems to die somewhere in the UK (from here)
<robertj> not markshuttleworth.com!
<HiddenWolf> It's terrible
<Spads> We do have staff on-site and are working on the problem
<Spads> Unfortunately, it is largely out of our control at the moment.
<Chipzz> Spads: thx
<Chipzz> Spads: what do you mean with "out of our control"?
<Spads> Chipzz: it's not a problem in our cage
<Spads> Chipzz: the outage affects many other customers, and it could take a while to meet everyone's needs
<Chipzz> Spads: ok :)
<Chipzz> Spads: so what is the staff doing on-site if it's a problem with the hosting company? ;)
<HiddenWolf> Spads: is it the isp?
<zul> maybe trying to help
<Chipzz> zul: I work for a company that does hosting in 4 datacenters; I think they would rather be in the way than help
<Spads> I haven't spoken to them in a few hours, but I would guess that there's a lot of waiting involved.  When things do come back on-line, there will definitely be a scramble to shepherd things back to normal.
<ozamosi> Is there any kind of link that contains info from the hosting company or something like that, that I can show the people that says "ubuntu's been hacked!"
<Spads> ozamosi: alas, no.  I'd love one myself.
<zul>                  company or something like that, that I can show the people
<zul> whoops
<Spads> haha
<Spads> ooh
<Spads> strike a light...
<Chipzz> Spads: is it a problem with power or with the network link?
<Spads> our systems are beginning to appear again.  Please be gentle, as they're likely to be hammered for a little while.
<HiddenWolf> ozamosi: there is a notice upon entering #ubuntu that explains that the servers are out.
<Spads> Chipzz: as jdub hinted at, it was a catastrophic power failure in our DC building.
<Qwell> Are you guys aware of any (unreported?) bugs relating to the partition tool hanging during install on a Niagara?
<Qwell> It happens literally every time...
#ubuntu-devel 2007-07-16
<Riddell> Mithrandir: could you give back kde4pim
<login_>  I have been compiling kernel 2.6.22 and have run across a dilemna. My compiled kernel weighs in at about 400-500 mb while the ubuntu kernel weighs about 100-200 mb. How did you guys get the kernel to be so thin?While i was uncompressing the kernel i saw it uncompress folders such as sparc so is it possible that my kernel installed all architectures? if so , how can i make it only use 1386?
<ion_> Please read the topic.
<login_> this is a topic related to feisty
<login_> ..
<ScottK> login_: This is not the place to come for kernel compiling lessons/support.
<Burgundavia_> login_: that is a support issue, please use the -users list or the forums
<zabin> Hello I was wondering if any of you knew of a list of current projects going on that i could get involved helping with?
<persia> zabin: What sort of thing are you interested in helping with?
<zabin> persia: Well im currently a college study studying computer engineering and I would be interested in helping out with some programming developing perhaps a program or application of the open source community.
<zabin> persia: *for the open source community.
<Amaranth> zabin: I think he meant what area of Ubuntu are you most interested in?
<persia> zabin: Hmm..  That's a broad goal :)  For Ubuntu specifically, we usually focus on patches and maintenance (for which #ubuntu-motu is a good discussion channel), implementation of new features (a list of specifications is available from https://blueprints.launchpad.net/ubuntu - be sure to check to see who else is working on it, and have a few leftovers that need code listed at the bottom of https://wiki.ubuntu.com/MOTU/TODO.
<persia> Amaranth: Not necessarily :)
<zabin> Hrm, pretty much anything that would involve programming.
<persia> zabin: Depending on your interest, you may be able to contribute as much (or more) working with some of our more prominent upstreams (e.g. GNOME, KDE, OOo, mozilla, X, linux, etc.)
<zabin> persia: thanks for that link earlier there are a few projects on there that i could see myself getting involved in.
<persia> zabin: Great.  Welcome, and thanks for helping!
<zabin> Thanks
<Amaranth> zabin: you should work on compiz :)
<zabin> I'm looking into working on the easy-encryption project lol
<zabin> Amaranth: The compiz stuff would probably way of my head for my first team development project.
<Amaranth> yeah, it does require a somewhat interesting set of skills
<zabin> Amaranth: do you know of any projects that you would think would be good to start out on as a noob?
<Amaranth> GNOME and KDE have bugs marked for beginners to tackle
<zabin> Do you know where i would have to look to find where that is online?
<zabin> Amaranth: do you know where that page is located?
<Amaranth> for which one?
<zabin> Amaranth: GNOME and KDE have bugs marked for beginners to tackle
<Amaranth> do you want GNOME or KDE?
<zabin> Amaranth: GNOME
<Amaranth> zabin: http://bugzilla.gnome.org/reports/gnome-love.cgi
<sbalneav> If someone happens to see seb128, let him know I posted a patch for bug #122544
<ubotu> Launchpad bug 122544 in nbd "nbd-server crashed with SIGSEGV" [Medium,Incomplete]  https://launchpad.net/bugs/122544
<sbalneav> I also duped all the other nbd-server SIGSEGV to that one.
<sbalneav> Evening Hobbsee
<Hobbsee> heya sbalneav!
<fabbione> morning
<Hobbsee> morning fabbione!
<Burgundavia> hey fabbione, Hobbsee
<Hobbsee> hi Burgundavia
<gaze_> what packages are the man pages for strlen strcpy etc. in?
<gaze_> *package
<Amaranth> gaze_: manpages-dev, please use #ubuntu next time
<gaze_> sorry about that
<gaze_> thanks anyway
<pitti> Good morning
<Burgundavia> morning pitti
<Hobbsee> morning pitti!
<StevenK> Morning pitti
<pitti> hey all
<StevenK> pitti: So, do you want to remove some NBS packages? :-)
<StevenK> pitti: There are 3 that are zero-sized in the list, I'm working on a fourth. I can start on a fifth, but only after you look at/approve a MIR.
<pitti> StevenK: yeah, can do
<Hobbsee> oh good, i wont have to kill calc today
<StevenK> Heh, maybe tomorrow?
<Hobbsee> StevenK: depends.
<Hobbsee> StevenK: i dont like my documents corrupted, then ooo dying over trying to uncorrupt them.
<StevenK> Sounds like fun.
<Hobbsee> although it appears that this one is not a .doc, which is good, as it's kinda important, so did actually recover correctly
* StevenK curses arb.
<StevenK> Now it fails with a linking problem.
<ccm> is there a reason why there is no jigdo download for desktop images but for alternate isos?
<ccm> ah, maybe dholbach knows
<ccm> 08:58 < ccm> is there a reason why there is no jigdo download for desktop images but for alternate isos?
<dholbach> hi ccm
<ccm> hi dholbach :)
<ccm> :)
<dholbach> no, no idea
<dholbach> sorry
<ccm> okay
<Hobbsee> ccm: depending on what you want to download, there's mostly no point in it anyway
<Hobbsee> as in, downloading things yet
<ccm> Hobbsee: well, jigdo updates packages in an iso
<ccm> so a jigdo would give you an iso with the most recent kernel and stuff
<ccm> i think this is even more than a nice to have
<Hobbsee> ccm: the livefs' arent building yet for most arches/flavours, so the iso isnt worth downloading anyway, at this particular point in time.
<Hobbsee> but true, i see your point
<ccm> Ah I get the problem
<Fujitsu> jigdo can't work with desktop CDs, as most of the space is taken up by one file (the squashfs)
<ccm> its about building the final desktop iso
<ccm> okay
<ccm> then this is not a political decision just a technical one
<Fujitsu> I suppose it might be possible to have a jigdo-like thing that reconstructed the squashfs after downloading the packages, but such a thing doesn't exist and would be non-trivial.
<ccm> Fujitsu: I see. I have actually no clue about squashfs but I'll have a look at this
<Hobbsee> infinity_: ping
<pitti> infinity_: bah, oo.o on ppc still failed with your increased waiting period
<StevenK> pitti: I'm very tempted to give up on removing the last Build-Depends of libglew-dev. It's a package called arb that hasn't built and doesn't look like it's going to build without a lot of swearing and screwdrivers being thrown at a wall.
<pitti> StevenK: right, just ignore it then
<dholbach> hi pitti
* pitti hugs dholbach 
* dholbach hugs pitti back
<StevenK> pitti: In that case, libglew1, libglew-dev, libgeda20, libparrot0.4.6 and libquantlib-0.8.0 can be NBS'd out of the archive.
* Hobbsee hugs dholbach and pitti 
<Hobbsee> StevenK: but screwdrivers being thrown at the wall might be fun!
* dholbach hugs Hobbsee back
<Hobbsee> :)
<pitti> StevenK: yay
<StevenK> The changelog for the arb Ubuntu changes is ten lines, and it still didn't completly build. Besides, it looks like a complete PoS to build, too.
<StevenK> Someone *very* sadistic wrote their Makefile.
<StevenK> pitti: Can I convince you to look at a MIR? :-)
<Fujitsu> Can someobody please give back banshee on ia64, amd64 and i386?
<pitti> Fujitsu: kicked
<pitti> StevenK: NBS axe applied
<StevenK> pitti: Woot, way cool.
<Fujitsu> pitti: Thanks.
<pitti> StevenK: which MIR?
<StevenK> pitti: Mutagen
<StevenK> pitti: Needed for new libgpod.
<Fujitsu> Grr, evil 1.1.6 build log breakage.
<pitti> StevenK: "MainInclusionReportMutagen (I will talk to dholbach in person -iwj)" -- hmm
<pitti> dholbach: ^ did Ian ask you about this?
<dholbach> pitti: no, he didn't
<pitti> StevenK: I'll ask Ian about that before
<StevenK> pitti: Okay, cool.
<StevenK> pitti: You'll regenerate the list after the publisher finishes running?
<pitti> StevenK: yeah, but that will be a while
<pitti> since the current one didn't catch it yet, I think
<StevenK> Ah
<StevenK> That's okay, I'm aout to drive home, and then off to my mothers for dinner. (Oh joy, oh rapture)
<Hobbsee> say you were abducted or something, and dont go :P
<StevenK> I'm very tempted.
<Fujitsu> Right, what the heck is going on with !{sparc,powerpc} banshee builds? hal's failing to start on installation, causing the world to explode.
<pitti> Fujitsu: why would the package need to build-dep on hal? that seems wrong to me
* Fujitsu has no idea. I just saw things depending on a newer banshee than existed on most archs.
<Fujitsu> Argh, it has a lot of direct build-deps.
<pitti> scary
<pitti> b-dep'ing on g-v-m, hal, dbus, etc. seems definitively wrong
<pitti> I doubt that we can make hal work correctly in any chroot
<pitti> if /sys or /proc are not mounted, it'll go nuts
<Fujitsu> That'd do it.
* Fujitsu works out which build-dep is pulling in hal.
* Fujitsu also wonders why it succeeded on powerpc and sparc.
<pitti> Fujitsu: their buildd chroots might have /sys, or so
<pitti> Fujitsu: I suspect libipod-cil
* Hobbsee dies of freezing
<pitti> Fujitsu: libipod-cil -> libipoddevice0 -> gnome-volume-manager -> hal -> dbus
* pitti melts
<Fujitsu> pitti: Aha, thanks.
<Hobbsee> pitti: what's the temp there?
<pitti> Hobbsee: 30 degrees
<Hobbsee> pitti: i'll swap
* Hobbsee waits for the house to warm up a bit
<Hobbsee> hi Tonio_
<pitti> infinity_: terranova still seems to have the old apt and thus does not build live CDs; can you please poke that?
<Tonio_> hi Hobbsee :)
* Fujitsu wonders what the new buildds will be named.
<Hobbsee> Fujitsu: i want to name one "doom"
* fabbione scratches his head
* Hobbsee throws small rocks at fabbione 
<fabbione> something is broken...
* Hobbsee didnt break it
<fabbione> bzzzzzzzzzzt
<dholbach> hey slomo
<slomo> hi dholbach :)
<dholbach> slomo: how's it going?
<slomo> dholbach: everything's alright, just very busy as always ;)
<slomo> dholbach: and you?
<dholbach> same here :-)
* dholbach gets some more coffee
* Hobbsee waves to elmo 
<elmo> hi Hobbsee
<infinity_> pitti: I'll look into both OOo and terranova, thanks.
<infinity_> Hobbsee: pong?
<Hobbsee> infinity_: same as what pitti later said, sorry
<pitti> infinity: cheers
<infinity> You'd think if there was any word in the world I could type, it would be "infinity"... :/
<Hobbsee> haha
<Hobbsee> infinity: just blame it on the cold or something
<infinity> It's summer...
<Hobbsee> oh, so you did move.
<infinity> pitti: apt in terranova's gutsy-live chroot is up to date...
<infinity> Hobbsee: No, I'm just in London for the next week.
<Hobbsee> ah right
<infinity> pitti: No idea why it wasn't before, but it fixed itself in the meantime.
<pitti> infinity: weird; ok, I'll try another livefs build
* dholbach hugs infinity
<infinity> pitti: I'm changing the livefs stuff to trigger a chroot upgrade bfore each build anyway, sinc the cron.daily updates seems a bit less reliable at times.
<dholbach> evand: slomo took care of the tomboy update in the meantime already - marking it as done
<pitti> infinity: hmm, still the same problem; might be an mvo bug then
<infinity> pitti: Lemme look...
<infinity> Uhh...
<infinity> pitti: Which dist are you building?
* pitti wonders why buildlive ubuntu suddenly produces an awful lot of output
<pitti> infinity: ubuntun
<infinity> pitti: I see no logs for i386 since 20070712.1
<pitti> infinity: I manually triggered some last Friday and today
<infinity> ...
<pitti> king is currently grinding
<pitti> and terranova once again exited with the usual
<pitti> elmo: Couldn't find task minimal
<pitti> elmo: Couldn't find task standard
<pitti> erk, "E:", not "elmo" (sorry, elmo)
<infinity> pitti: Exact command you're running as cdimage on lithium?
<pitti> buildlive ubuntu
<pitti> just as the cronjob does
<infinity> Argh, why does lithium still have that ps-unfriendly kernel patch?
<pitti> ps aux works quite fine here?
<infinity> 24 processes is "fine" to you? :)
<pitti> well, for my purposes, yes :)
<infinity> And no useful output from "w" or "who".
<pitti> hi iwj
<iwj> Hi.
<iwj> Hmm, I wonder why this client wasn't connected over the weekend ?
<iwj> Oh well.
<Hobbsee> greetings iwj, thanks for your mail
<infinity> pitti: When the cronjob building dailies is done, we're going to reboot with a less gimped kernel, so you might want to lay off lithium for a bit.
<pitti> infinity: sure; I don't mind at all if you kill the current build, too
<infinity> (Not that a less gimped kernel will solve the issue you were having, but it'll make it less painful for me to diagnose life)
<pitti> infinity: it was just for testing the apt issue on terranova
<iwj> Hobbsee: Hi.  The dpkg one ?  NP.
<infinity> pitti: When we bring lithium back, I'll try to figure out WTF is going on between lithium and terranova.
<pitti> ah, seems to have finished
<Hobbsee> iwj: yeah
<iwj> Hobbsee: I've done what I think is fixing it and if I'm wrong I'm sure we'll find out soon enough.
<infinity> pitti: Since terranova isn't actually building anything, and hasn't done since the 12th, I'm curious what you're seeing. ;)
<Hobbsee> iwj: cool, OK
<pitti> infinity: it seems it dumped a large portion of the log to stdout instead of the log file
<pitti> infinity: that may or may not be related to the symptoms
<infinity> pitti: Do you have stdout in a buffer?
<pitti> infinity: hm, the remaining bits actually seem to indicate a moblin build
<infinity> pitti: The first 20 lins or so...
<infinity> pitti: Yeah, that's what I thought.
<infinity> pitti: I blame Tollef.
<infinity> pitti: I'll lookinto it after the reboot. :)
<pitti> infinity: only the last 40 lines or so
<pitti> infinity: cheers
<infinity> pitti: I suspect someone swapped live/moblin to do some testing or something. :)
<pitti> infinity: it currently seems to run a cronjob for some sparc image
<pitti> but I don't need any image right now, so just kill off anything you like
<infinity> ... or it could be my own retarded misuse of authorized_keys
<Fujitsu> slomo: Got any ideas on how to convince hal to work on the buildds? pitti says it's probably not going to happen.
<slomo> Fujitsu: nope, not really
<pitti> slomo: would it be entirely unreasonable to drop the g-v-m dependency from libipoddevice0?
<Fujitsu> Why does libipoddevice0 need g-v-m?
<Fujitsu> Damn, beat me to it.
<pitti> Fujitsu: I smell an agreement here :)
<Fujitsu> I really don't see why it needs something so desktopy.
<pitti> (disclaimer: I neither have a shiny iPod nor an idea what libipoddevice0 does in particular)
<slomo> pitti, Fujitsu: it needs it for getting the volume informations, mounting, whatever... at least it needs hal & g-v-m to work ;)
<Hobbsee> pitti: then get one, and claim it as a work expense :P
<pitti> slomo: but g-v-m?
<pitti> "Recommends: hal" maybe?
<slomo> pitti: and people who don't look at recommends will have a non-working library...
<pitti> the better fix would probably to have a policy-rc.d in those chroots to not start daemons in the first place
<slomo> pitti: and it definitely needs g-v-m, upstream told me that ;) i just don't know why
<slomo> pitti: i have the same problem on the debian buildds btw, well... only on ppc and ia64...
<infinity> pitti: I'm a muppet, it's my fault. :)
<infinity> pitti: Give me a few minutes to write a wrapper for livefs/moblin, and it should sort itself.
<pitti> yay
<soren> I forget: Against which package/product should bugs on the ubunut.com website be reported?
<infinity> (where "few minutes" involves things like getting a Coke, having a smoke, and generally waking up)
<Hobbsee> soren: ubuntu-website?
<soren> "No results found for keyword 'ubuntu-website'."
<Fujitsu> That's definitely the project name, but LP search is not great.
<Hobbsee> soren: LP search is on crack.  see https://launchpad.net/ubuntu-website
<soren> Ah..
<soren> Yes, I'm an idiot. Found it now. Thanks!
* Fujitsu tried it once then decided it wasn't worth the pain.
<Hobbsee> it either returns nothing, or returns results which dont contained the search term
<Hobbsee> which i find...slightly odd
<Hobbsee> of course, occasionally it returns the right things.
<Hobbsee> (when searching by keywords, in a bug report)
<Fujitsu> If you're lucky, and choose keyword characters carefully.
<pitti> slomo: any idea about https://launchpad.net/ubuntu/+source/gnome-power-manager/2.19.5-0ubuntu1/+build/356089 ? do the gstreamer pkgconfig files specify -Werror somewhere? We must not use that on sparc and ia64
<pitti> slomo: (the better alternative is of course to actually fix the gstreamer includes)
<fabbione> OH GREAT
<fabbione> grrrrrr...
<soren> ?
<fabbione> FTBFS missing B-D
<fabbione> i hate when i make that mistake
<Hobbsee> soren: how's https://bugs.launchpad.net/ubuntu/+source/mysql-dfsg-5.0/+bug/119075 going?
<ubotu> Launchpad bug 119075 in mysql-dfsg-5.0 "Root password policy for mysql" [High,Confirmed] 
<soren> Hobbsee: Um... I think it's blocking on me now, I'm afraid. I talked to upstream (MySQL, not Debian) and they marked it as wishlist with a note that I should not expect anything to happen anytime soon.
<Hobbsee> soren: right - so i should remilestone to sometime later?
<infinity> pitti: Testing now, but the wrapper should DTRT.
<pitti> infinity: \o/
<infinity> soren: Note that I am Debian MySQL upstream, if you wanted to discuss that one with "upstream". :P
<soren> infinity: Oh, no. :)
<soren> infinity: You've read the bug report?
<infinity> soren: The end of the bug log seemed to imply it was blocking on discussing with Debian.
<soren> infinity: As I just said to Hobbsee, I decided to go directly to MySQL.
<infinity> soren: And since I don't se Christian or Sean onling, that leaves me. :)
<soren> infinity: Who apparantly found that their current methods for doing this were just fine. :(
<infinity> soren: Hrm, I'm not sure there's a "proper" solution from MySQL AB, really... They never seemed to mind installing the daemon with an empty root password.
<infinity> soren: It's always been up to distributors to figure out how to deal with that, if we cared.
<soren> infinity: Alright. the major difficulty is that we don't like having clear text passwords lying around in text files.
<infinity> In the case of MySQL, we have one anyway. :)
<infinity> And without completely rethinking the upgrade process, we'll continue to have the debian-sys-maint user for a while.
<soren> infinity: I know, and we (pitti and I) want to lose that.
<infinity> soren: We could try to rework things so maintainer scripts use --skip-grant to do everything, but that involves bouncing the daemon more times, that's all.
<infinity> soren: Certainly, any such drastic changes, I would like to discuss to the level where we can be happy putting it in Debian's SVN as well.
<soren> infinity: Yeah, and that sucks too. The perfect solution would be to patch the mysql-server to just grant (system) root full access.
<infinity> soren: This level of maintainer sciprt forking gets ugly. :)
<soren> infinity: Agreed.
<pitti> infinity: I agree; there's nothing you can hide from root anyway, so 'sudo mysql ...' should just do things without password
<infinity> soren: Surely, we'd want to grant access to the controlling user, not to root.
<pitti> so the password should initially be disabled, and the admin needs to 'sudo mysqladmin set-password' or so
<infinity> (This is what postgres does, isn't it?  The postgres user has full access)
<pitti> infinity: right, s/root/mysql server system user/
<infinity> But not hardcoded, actual controlling user (so, if I start a mysql instance as adconrad, I get full access to my little daemon)
<infinity> I wouldn't be against such a patch, by any stretch.
<infinity> It would make postgres admins happy, I suspect, to have similar behavior. :)
<pitti> and would make the entire 'password in file' and debian-sys-maint fiddling unnecessary, too
<infinity> Yeah, obviously.
<infinity> Having an "rm -f /etc/mysql/debian-sys-maint" in a future maintainer script won't hurt my feelings any.
<soren> infinity: Good point. Yes, "if the connecting user is the same as the user the particular mysql instance is running as, grant full access" is what we want.
<infinity> pitti: Latest i386 ubuntu image looks good again.
<pitti> infinity: thanks muchly!
<soren> infinity: I just don't think my C++ fu is strong enough to have a go at it right now. I'd need quite a bit of time.
<infinity> pitti: Feel free to smack me at allhands for being ssh-retarded. :)
<pitti> pfft, I'll mention your quick solution rather :)
<infinity> soren: My general rule is "if your C++ is weak, make mvo do it"... But I get the impression he's overworked lately (perhaps due to that very rule)
<Hobbsee> infinity: or find someone else good with c++, and make them do it
<infinity> soren: I can certainly look at it this week when I find some "RT is cleaned out and I'm bored" time.
* Hobbsee wonders why the world keeps randomly spinning
<infinity> Hobbsee: Vodka.
<Hobbsee> oh, was that it.  right.
<infinity> soren: Care to transpose the relevant bits of this converation into the bug as some sort of pseudo-spec about just what we'd like to see happen here?
<infinity> soren: Cause the last few comments in the bug still seem to be hinging on --skip-grant ugliness.  I do prefer this EUID==connectingUser concept.
<soren> infinity: Will do.
<infinity> soren: With any luck, some keener will step up and fix it for us before I have a chance to find free time to look at it. :)
<infinity> soren: Otherwise, I'm sure I can sell it to Christian and Sean, and one of the three of us should be able to find time.
<infinity> pitti: If terranova gives you any more grief, let me know.  Writing ssh wrappers in shell is a big no-no, but it's a secured network with a know good set (or set of good?) users, so whatever. :)
<viviersf> BenC, ping
<soren> infinity: That would rock!
<pitti> StevenK: oh, http://people.ubuntu.com/~ubuntu-archive/NBS/ is up to date, btw
<dholbach> who could I assign bug 125336 to? who is the udev 'maintainer' nowadays?
<ubotu> Launchpad bug 125336 in udev "typo KERNEl in rules.d/20-names.rules" [Undecided,New]  https://launchpad.net/bugs/125336
<infinity> soren: No promises about such rocking occuring, you understand, that was with my Debian hat on, not my Canonical hat.
<pitti> StevenK: sorry, forgot to tell you; I also increased the regeneration frequency to 4 times per day
<infinity> soren: But I will talk it over with them.
<dholbach> ok, I'll assign to keybuk
<fabbione> dholbach: Scott... but if it's urgent i can look at it now
<dholbach> no, I doubt it - it's just one of the bugs out of the review queue
<fabbione> dev/raw... i don't think it's really wildly used but the patch is right
<dholbach> but thanks fabbione
<dholbach> I'll assign you a different one ;-)
<fabbione> dholbach: you can just upload that.. really.. udev is not maintained in bzr or anything
<soren> infinity: Sure, sure. Got it.
<fabbione> dholbach: just make sure to tell me before... my LP income mail is too huge to notice
<dholbach> alright
<pitti> dholbach: is there a way to find all bugs assigned to me which came from sponsoring requests?
<dholbach> pitti: hrm, no, not really
<StevenK> pitti: Way cool.
<slomo> pitti: that -Werror must come from somewhere else... only gstreamer cvs is built with -Werror and then it's not in the pkgconfig files
<slomo> pitti: maybe g-p-m development releases have this?
<BenC> viviersf: pong
<pitti> dholbach: ^ ?
<StevenK> pitti: Did you manage to corner iwj?
<pitti> hey BenC
<pitti> StevenK: not yet, but he's alive now :)
<dholbach> pitti: I don't know
<StevenK> Heh
<slomo> pitti: can you give me a patch for the gstreamer includes and i get it upstream... no idea what this warning means :)
<pitti> iwj: what were your concerns about the mutagen MIR?
<dholbach> hum, ogra isn't around
<iwj> pitti: Let me look again.
<StevenK> Riddell: Ping, about kdepimlibs4{,-dev} NBS.
<Riddell> StevenK: what about it?
<BenC> hey pitti
<BenC> pitti: I should have draft of kernel-updates policy today
<StevenK> Riddell: Do you need to throw a bunch of rebuilds up?
<StevenK> Er, need me to
<viviersf> BenC, we can still get new driver support into gutsy right ?
<pitti> BenC: were the modifications that I did ok for you?
<Riddell> StevenK: what of?  everythig kde 4 has been rebuilt last week
<iwj> pitti: Looks like it's fixed.  The review report was incomplete.
<BenC> pitti: I haven't reviewed them completely, but I'm pretty sure they are
<BenC> viviersf: in lum, yeah
<iwj> pitti: Shall I deal with it again ?
<StevenK> Riddell: kde4pim and kdepimlibs4-dev still Depend on kdepimlibs4.
<slomo> pitti: do you understand the warning?
<StevenK> Riddell: And it looks like kdepim4 failed to build on ia64, based on the NBS output.
<pitti> iwj: ah, nice; it looked quite complete to me, so I wondered
<pitti> slomo: not really
<slomo> pitti: good :)
<StevenK> iwj, pitti: Ah. That was me a few days finishing it off.
<pitti> iwj: if you have time to review it again, that would be much appreciated
<Riddell> StevenK: everything has failed on ia64, I'm not that bothered myself
<viviersf> BenC, the new dell notebooks has intel 4965 wireless network card and isnt supported in gutsy. Where do i file the issue again to get the driver in ?
<iwj> pitti: On it.
<BenC> viviersf: already a known issue, rtg is getting the iwlwifi driver prepared for lum this week I hope
<iwj> StevenK: Right.  We were just a bit confused because it found its way into the approval queue before it was finished.
<viviersf> BenC, cool thanks
<BenC> viviersf: no need to file a bug
<BenC> viviersf: if you could stay in contact with rtg, that'd be great, because we'll need testers
<StevenK> iwj: Ah. That's curious. I didn't move its place in the queue, just checked that it was in there.
<viviersf> BenC, cool ill do that
<viviersf> whos rtg ?
<infinity> pitti: We don't want OpenOffice on powerpc anyway, do we?
<BenC> viviersf: Tim Gardner, kernel-team
<infinity> pitti: I'll just P-a-s it out!
<viviersf> BenC, cool ta
<cjwatson> infinity: *blink*
<StevenK> Heh
<infinity> cjwatson: (that was sarcasm)
<pitti> infinity: I'm not sure, so far it worked; I never really used it except for opening some files sent around by email :)
<pitti> infinity: I'm really stunned, though; nothing significant changed since the last build
* StevenK idly wishes a few upstreams would get off their collective backsides and fix their projects to build against new versions of certain libraries.
<cjwatson> infinity: (I know)
<viviersf> BenC, you know about sata not working on dell D630 ?
<BenC> viviersf: no, do you know what chipset it is?
<infinity> pitti: The moon phase changed.  That's about all it takes to upset OOo.
<viviersf> BenC, just trying to find out
<infinity> pitti: Also, there was a new upstream version...
<infinity> openoffice.org | 2.2.0-1ubuntu3 |         gutsy | powerpc
<mjg59> D630 is 965gm
<infinity> openoffice.org | 2.2.1-5ubuntu3 |         gutsy | source, amd64, i386, sparc
<infinity> pitti: powerpc hasn't built since 2.2.0
<infinity> pitti: In fact, it hasn't built since gutsy opened, so one could blame any number of factors.
<pitti> oh, oops
<viviersf> BenC, mjg59 actually its the cdrom that doesnt work so it should be ide
<infinity> pitti: This would be the part where the OOo people and the toolchain people get to point fingers for a week until someone notices the "DONT_STALL_BUILD" variable in debian/rules is set to "0" on powerpc.
<pitti> lol
* StevenK gets tempted to build asterisk-spandsp-plugins from alioth SVN.
<iwj> DONT_STALL_BUILD> WTF?
<infinity> StevenK: As tempted as you are to try an OOo build on PPC and tell me why it hangs? :)
<StevenK> infinity: Send me one of adare, ross or royal and you've got a deal. :-P
<infinity> Right, then.  Guess I'll do it myself. :)
* StevenK chuckles
* infinity offlines adare.
<StevenK> infinity: While you're paying attention, why is vivies marked as MANUAL for LiveCDs? Sparc doesn't have live CDs ....
<infinity> StevenK: It's alsothe security/dak buildd.
<infinity> StevenK: But sparc does have livefs builds, they just don't work.
<viviersf> BenC, only info i get from lspci is intel 82801H :(
<StevenK> Ah
<Hobbsee> ....what legit use is there for a  DONT_STALL_BUILD anyway?
* Hobbsee erks.  2 hours until results.
<infinity> Hobbsee: It was a joke, there's no such variable...
<infinity> Evidently, my Monday morning sense of humor is lost on some. :)
<Hobbsee> infinity: quite possibly.  then again, iirc, there's a BSD call, asking if the machine is on fire, so...
<StevenK> Actually, the line printer code returns 'on fire' if it gets back an error from the printer.
<StevenK> So you might see 'lp0 on fire?' in dmesg.
<Hobbsee> okay, so strangely named variables/functions...what i said still applies.
<soren> cjwatson: https://bugs.launchpad.net/ubuntu/+source/partman-auto-lvm/+bug/126328   <--- I've still got the error message showing in my vmware instance. Do you need any more debug info?
<ubotu> Launchpad bug 126328 in partman-auto-lvm "swap volume fails to mount" [Undecided,New] 
<cjwatson> soren: /var/log/syslog, /var/log/partman
<cjwatson> the message is just partman-target/mount_failed
<cjwatson> with luck there's an error from swapon in the syslog
<aquo> hi i have some problems with Network-Manager
<aquo> it is no problem to connect to my home network with commandline tools wpa_supplicant and dhclient ...
<aquo> but with network manager it doesn't work
<soren> cjwatson: Surprisingly, no.
<aquo> Jul 16 14:04:15 cayley NetworkManager: <information>^Iwpa_supplicant(6005): WPA: No WPA/RSN IE available from association info
<aquo> Jul 16 14:04:15 cayley NetworkManager: <information>^IActivation (ath0) failed for access point (bp3aGnZo)
<aquo> Jul 16 14:04:15 cayley NetworkManager: <information>^IActivation (ath0) failed.
<soren> cjwatson: Quite the opposite, actually.
<soren> cjwatson: Jul 16 14:00:34 kernel: [  438.154245]  Adding 401400k swap on /dev/mapper/ubuntulvmtest-swap_1.  Priority:-1 extents:1 across:401400k
<soren> cjwatson: I'll upload the log files.
<aquo> cjwatson: i gave up remastering an ubuntu live cd, there seem to be files that are not available for public
<soren> aquo: Huh? What are you missing?
<soren> cjwatson: I've just suspended the vm. If you need anything from it, just shout.
<cjwatson> soren: can you fish out a tarball of /var/lib/partman somehow? (you might need to get a proper tar from somewhere)
<soren> cjwatson: Sure.
<aquo> soren: can't remember, i think something like a minimal images
<soren> cjwatson: It's the current daily server CD, by the way.
<aquo> i purged all the files, was too hard for me
<aquo> i tried to rebuild cdimage server and service, but didn't work
<soren> aquo: You should have everything needed to build a livecd available.
<cjwatson> aquo: it's all available. The last piece, the livecd-rootfs package, was uploaded to the gutsy archive recently
<aquo> so i will retry after the exams next week
<cjwatson> aquo: but it is definitely "some assembly required" and requires some skill and time to put together
<ryanakca> cjwatson: morning... erm, I have a couple questions regarding LVM in the Kubuntu Alternate installer (Bug?) to quote #kubuntu-devel earlier:
<aquo> cjwatson: normally no problem for me, i am used to build distributions, i have an large own scriptset to build special distribuition for embedded and arm ...
<aquo> cjwatson: but at the moment there are lots of exams, today i had exam in signal coding, convolution codes, viterbi, huffmann ...
<ryanakca> should the installer try to mount swap? http://pastebin.ca/621144 , If so, I'll file a bug saying that it
<ryanakca> repeatedly fails, if not, I'll file a bug against debian-installer saying that it tries to mount swap
<Hobbsee> cjwatson: ^
<soren> ryanakca: I've just reported this :)
<soren> ryanakca: https://bugs.launchpad.net/ubuntu/+source/partman-auto-lvm/+bug/126328
<ubotu> Launchpad bug 126328 in partman-auto-lvm "swap volume fails to mount" [Undecided,New] 
<cjwatson> ryanakca: FWIW "mount swap" just means "run the mount.d script for swap" in this case which more or less equates to swapon. It doesn't literally mean /bin/mount.
<ryanakca> cjwatson: ok
<ryanakca> cjwatson: and, in an LVM, you don't need to worry about primary/logical partitions, right? If not, why is it that I can only create one partition in my LVM before the rest of the space becomes 'Unusable'?
<ryanakca> the only way around it I've found is to create LVM, go back, and select 'guided partition a whole disk', select the LVM, and then modify/delete the created partitions in the LVM manually
<cjwatson> ryanakca: create multiple LVs for that; LVs aren't partitionable and each single LV can only hold one filesystem
<ryanakca> ah, ok
<cjwatson> the display is a little bit confusing
<cjwatson> the "Configure the Logical Volume Manager" menu entry should help
* ryanakca nods
<ryanakca> ok, thanks :)
<ryanakca> cjwatson: if you shouldn't partition disks, maybe find a way to remove LVM from the 'guided partition a whole disk' menu.
* ryanakca can file a wishlist bug...
<aquo> i hate network manager.
<ryanakca> s/partition disks,/partition lvms,/
<pitti> StevenK: mutagen promoted, thanks to iwj's approval
<StevenK> pitti: Great, thanks.
<StevenK> pitti: In that case, I'll prepare a bunch of rebuilds to be uploaded in the morning.
<cjwatson> ryanakca: what? I think you've misunderstood me
<cjwatson> ryanakca: given a single logical volume on the partitioning menu, you can only get one filesystem (partition-equivalent) into it. That doesn't mean you can't have as many LVs as you like on a disk, nor that it doesn't make sense to partition a whole disk into LVM-style pieces.
<fabbione> zul: hey dude...
<fabbione> zul: what's the reason why you dropped xen-3.1 from amd64?
<fabbione> zul: is it possible to build userland without kernel?
<pitti> fabbione: might just have been a packaging error; the amd64 binaries were completely empty and thus rejected
<fabbione> pitti: it's possible, i just need to know because a change there is propagated up in the stack with libvirt and cluster
<fabbione> pitti: i don't want to end up having to run behind amd64 yes, amd64 no, amd64 probably... till release
<pitti> yep
<zul> fabbione: we dont have an amd64 xen enabled kernel yet should be fixed soon
<fabbione> zul: what stops you to build userland without a kernel?
<fabbione> zul: if you can still build userland, i suggest you keep doing it.. otherwise it's  a pain for all stuff that B-D on xen
<zul> fabbione: it doesnt but its not very useful without a kernel though
<Mithrandir> zul: people routinely compile their own kernels.
<zul> fabbione: sure ill upload one tonight
<fabbione> zul: it does or it doesn't?
<Mithrandir> especially since the one in edgy for instance is completely useless on amd64.
<Hobbsee> Mithrandir!
<fabbione> zul: useful or not, we can't keep changing packages on top...
<fabbione> zul: the kernel might be solved by release
<zul> fabbione: ill fix it  tonight
<fabbione> zul: but we can avoid to upload a few packages everything it changes
<fabbione> ok thanks
<ryanakca> cjwatson: no I understood you, but I'll explain later, I need to run :)
<fabbione> (and please make sure it builds.. libvirt upload you did, did not build)
<Mithrandir> Hobbsee!
<Hobbsee> :)
<pitti> hello calc
<calc> pitti: hi
<ScottK> cjwatson: When you have a moment, I'd like to discuss a source backport with you.  Jdong has reviewed/approved and told me to discuss with you.
<Hobbsee> hi calc.  you will not be murdered today.  by me, at least.
<calc> Hobbsee: great :)
<cjwatson> ScottK: does it need discussion, or just to be done?
<Hobbsee> calc: still, when my next .doc corrupts via openoffice, and it cant be recovered, then you may not be so lucky :P
<aquo> ha, i finally found the right bug for my problem, and again a kernel problem ...
<aquo> https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/50214
<ubotu> Launchpad bug 50214 in network-manager "can't connect to hidden network" [Undecided,Confirmed] 
<ScottK> cjwatson: For dapper just done, for Edgy, not sure how to proceed.
<cjwatson> ScottK: what's the problem?
<StevenK> Hobbsee: I note the 'when', not 'if'...
<ScottK> The issue is backporting clamav 0.88.7 while we work the rdepends for clamav 0.9x.
<aquo> not just that drm is not working for savage, no  ... wireless interfaces is also compiled in wrong way
<calc> Hobbsee: heh :\
<ScottK> Dapper needs source changes (I have a package).
<ScottK> Edgy can use what WAS in Feisty unmodified, but has been superceded and so isnt' in the archive.
<Hobbsee> StevenK: heh.  well, if people stopped insisting on sending me .doc files, and sent in a free format instead, then that'd make me happier.  i could just save as .odt, but i usually have to send them *back* as .doc, so get stuck.
<cjwatson> ScottK: what version exactly? we can probably resurrect it
<ScottK> cjwatson: clamav 0.88.7-1ubuntu1
<ScottK> cjwatson: For Edgy it's Bug #83065
<ubotu> Launchpad bug 83065 in edgy-backports "Please backport clamav 0.88.7-1ubuntu1 to edgy from feisty" [High,Incomplete]  https://launchpad.net/bugs/83065
<Hobbsee> ScottK: so the decision was to backport the entire thing?  cool
<ScottK> For dapper, do I dput to dapper-backports and you accept it?
<ScottK> Hobbsee: Yes.  Ugly details at https://wiki.ubuntu.com/MOTU/Clamav
<cjwatson> ScottK: no, you need a core-dev sponsor
<cjwatson> otherwise it will simply be rejected, unless I misremember the code
<ScottK> OK.  I can give you a url for the Dapper source package.
<cjwatson> please, no, not me
<StevenK> ScottK: Point me at it, I'm happy to test build, and upload.
<ScottK> StevenK: Thanks.  Gimme a sec for the url.
* Hobbsee watches cjwatson engulf himself in the SEP cloud again
<ScottK> StevenK: http://www.kitterman.com/clamav/clamav_0.88.7-1ubuntu1~dapper.dsc
<sbalneav> seb128: bug #122544, I posted a patch.
<ubotu> Launchpad bug 122544 in nbd "nbd-server crashed with SIGSEGV" [Medium,Incomplete]  https://launchpad.net/bugs/122544
<Hobbsee> ScottK: sounds reasonably sane.  and ugly
<ScottK> StevenK: Bug #74216 is the bug in question for that.  May I assign it to you?
<ubotu> Launchpad bug 74216 in dapper-backports "clamav in dapper-backports vulnerable" [Undecided,New]  https://launchpad.net/bugs/74216
<Hobbsee> ScottK: btw - i presume you saw that the new clamav has a bug filed against it already, about upgrading or removing it?  i dont remember which
<ScottK> Hobbsee: I liked make an alternate package and don't whine about what it breaks a lot better, but here we are.
<seb128> sbalneav: nice, subscribe the sponsor team if you want
<Hobbsee> ScottK: true.  it's backports, so it's not supported anyway
* StevenK digs around for a Dapper chroot.
<ScottK> Hobbsee: I do get all the clamav bugs.  I saw the one about the upgrade.  I think he got bit by the related kernel bug that was fixed in 22-8.
<ScottK> Hobbsee: I agree it's not 'supported', but I still like to avoid breaking people's systems.
<StevenK> Ah! Found it.
* StevenK blows the dust off of it.
<ScottK> Excellent.
<Hobbsee> ScottK: oh, true that
<Hobbsee> ahhh
<sbalneav> seb128: Thx, joined.
<ScottK> cjwatson: While StevenK is looking at Dapper, is there anything additional I need to do for the Edgy backport (which just needs to be found)?
<StevenK> ScottK: Builds fine, just looking at a upgrade.
<ScottK> Great.
<StevenK> ScottK: Okay, looks fine to me.
<StevenK> cjwatson: Will I need to include the orig in the upload to -backports?
<ScottK> Great.  This is very good.
<persia>  StevenK: about bug 124900: Would you mind the libgpod task being used additionally to track the progress of that package (with Fix Committed), rather than Invalid?
<ubotu> Launchpad bug 124900 in libgpod "Please sync gtkpod-0.99.10, libgpod-0.5.2 from debian unstable" [Wishlist,Invalid]  https://launchpad.net/bugs/124900
<StevenK> persia: I don't mind.
<seb128> persia: I did upload libgpod 0.5.2 on friday
<cjwatson> ScottK: no, I'm just hacking up scripts to let me backport from random stuff I've downloaded from the librarian; there's nothing you need to do
<cjwatson> StevenK: I think so; shouldn't hurt to do so, anyway
<ScottK> cjwatson: OK.  Great.  Should I assign the bug for that backport to you?
<cjwatson> ScottK: whatever, it's not necessary but if it makes you feel better ...
<persia> seb128: Right.  LucidFox has a bug open for a transition plan (still needs main for kipi-plugins), and I wanted to keep using that bug to track it to help know when it was time to apply all the patches / sync requests for the new build, rather than leaving it Invalid, and perhaps missing a bit (or later catching it in NBS).
* ScottK won't bother.
<StevenK> persia: I was planning on uploading six uploads in a few hours for the gpod transistion.
<seb128> persia: I'm not sure I understand what the bug is about, updating libgpod has been fixed
<seb128> persia: I would prefer not to mail flood main sponsor with other discussions on this bug
<persia> StevenK: In that case, I won't get back to LucidFox to track it :)  Everything was tested, and built fine, except that a new version of gtkpod was requested.
<StevenK> persia: Right. I'm waiting for the new libgpod to get built, which should happen soonish, and then for it to clear NEW.
<persia> seb128: Sorry.  I realise that main sponsors and universe sponsors lists are tracked a little differently, but just wanted to make sure things worked smoothly.  I'll leave it alone from now.
<persia> StevenK: OK.  I've just been chasing this on the other side, so wasn't sure.  Thanks.
<seb128> persia: there is no main sponsor list, you mail every sponsor every time you add a comment
<persia> seb128: Ah.  That's really good to know.  Thanks.
<Hobbsee> mvo!!!
<seb128> hey mvo
* mvo is not here
* seb128 neither
<Hobbsee> hello not here, then.
<StevenK> You're remarkably talkative for someone not here
<mvo> hey Hobbsee, StevenK and seb128
* StevenK waves to mvo
<cjwatson> ScottK: done
<ScottK> cjwatson: Thanks.  Just got the accept mail.
* StevenK gets out and pushes this upload himself.
<StevenK> Oh, that'd be why. The bloody orig tarball is 9Mb.
<Hobbsee> gotta love the au shoestring.
<ScottK> Yeah.  Be glad it's not a 0.9x version.  That one goes to 11.
<StevenK> Ah. The Spinal Tap release of clamav.
* StevenK hides.
<ScottK> No need to hide.  It was on purpose.
<StevenK> Heh
<StevenK> cjwatson, ScottK: clamav uploaded.
<ScottK> StevenK: Thanks.
<ScottK> StevenK: I got the accept for that too.
<StevenK> Excellent.
* StevenK idly wonders how long a depwait'd build takes to retry
<ScottK> cjwatson: I take it from your comment on the Edgy clamav bug that "Can I backport this thing that used to be in the repos, but got superceded" is not a question I should ask very often?
* Hobbsee rofl's at the comment
* ScottK appreciates the effort.  It's a good upgrade for people running the older releases.
<cjwatson> ScottK: that's correct
<cjwatson> at least until we make the script a bit smarter
<ScottK> OK.  Thanks again.  I think it's an important backport.
<ScottK> It should have been dealt with during Feisty when it was in the repos.  Glad we could get it taken care of now.
<pitti> hi mathiaz
<mathiaz> pitti: hi
<siretart> can someone please give-back freemind?
<pitti> siretart: done
<siretart> thanks
<StevenK> pitti: libgpod should have hit the NEW queue. Are you able to poke it?
<pitti> I am
<cjwatson> pitti: would you be able to do an updated merge of dhcp3? I'd like to switch the installer from dhcp to dhcp3, and there are some relevant changes in unstable that we don't have yet
<cjwatson> I was about to try to do it myself, but there are a LOT of Ubuntu changes
<pitti> cjwatson: yes, I can do that; right, that'll take a while
<cjwatson> pitti: thanks
<StevenK> Ouch! A screenful.
* StevenK ponders. Waiting 45 minutes until 1am to upload six rebuilds, or doing them when he gets up at 8.
<pitti> StevenK: libgpod NEWed
<StevenK> pitti: Ahh, thanks
<pitti> StevenK: or fix the build deps for packages which are modified anyway
<StevenK> Damn, he slipped through my fingers.
<StevenK> pitti: Fix the build deps? The -dev package name didn't change...
<pitti> StevenK: but the version
<pitti> >= (1.2.3)
<movi> i think i have a bug against linux-source-2.6.22-generic
<movi> but id rather talk about it here first, can i?
<StevenK> pitti: I'm just wondering about your rationale.
<pitti> StevenK: with this you can upload everything right now and have the buildds sort out the depwait themselves
<StevenK> Ahh
<StevenK> Let's do that
<pitti> StevenK: doesn't work so well for -buildN versions, of course
<StevenK> Two of them will be.
* pitti summons mvo back
<soren> Mithrandir: You plan on doing a bit of source NEW queue processing today?
<Hobbsee> pitti: good luck with that
<Mithrandir> soren: no, I'm at guadec with spotty network coverage.
<soren> Mithrandir: Oh, I see.
<soren> Mithrandir: Carry on then. :)
<soren> movi: #ubuntu-bugs or #ubuntu-kernel are likely to be better options. The former being the preferred one if you're not entirely sure it's a kernel bug.
<infinity> soren: I might touch source NEW at some point today.  Anything in particular you wanted looked at?
<soren> infinity: storm, please.
<soren> infinity: That would be much appreciated.
<StevenK> pitti: Right. Thanks for the suggestion, 4 of the six uploaded, I'll do the other two when I get up, since they're simple -Xbuild1 and I'd rather keep them that way.
<infinity> soren: I'll poke it in ~15 mins.
<soren> infinity: Wicked. Thanks!
* pitti yays mvo
* mvo waves to pitti
<Hobbsee> yay, mvo!
<Hobbsee> infinity: were you the one who poked freemind?
<pitti> Hobbsee: I gave it back
<Hobbsee> pitti: it needs infinity's love.
<aquo> asac: i update on one of the bugs that are assigned to you
<Hobbsee> (requires the java agreement to be accepted)
<aquo> asac: https://bugs.launchpad.net/baltix/+source/knetworkmanager/+bug/50214/comments/38
<ubotu> Launchpad bug 50214 in network-manager "can't connect to hidden network" [Undecided,Confirmed] 
<asac> aquo: which one?
<aquo> asac: network manager, can't connect to hidden network
<asac> aquo: whats your idea?
<asac> pitti: can i push firefox security preview for dapper to proposed or something?
<pitti> asac: we can do that, but I wouldn't normally recommend that approach
<pitti> asac: I'd prefer if you could upload it to a PPA?
<asac> pitti: we won't get any testing there
<pitti> mvo: you lost my /msg apparently
<pitti> mvo: I mailed the log to you
<asac> pitti: i can push them somewhere ... just looking for a place with a bit more automatic exposure
<pitti> asac: well, if you want, you can use -proposed, too
<pitti> asac: once everything built, we can copy it to -security
<pitti> asac: that'll need keescook's ok for getting the md5sum list, though
<aquo> asac: i am not sure at the moment, i think there wont be any way to change libiw28 on feisty, but maybe it is possible to write a patch for network manager.
<pitti> cjwatson: hm, the actual merge works, but the udeb is currently busted because it does not have the derooting infrastructure
<aquo> asac: the kernel, wireless tools and libiw28 are carved into stone i think
<asac> aquo: i don't understand ... how should network-manager workaround a driver problem?
<infinity> Hobbsee: Eww.
<Hobbsee> infinity: yeah.
<infinity> Hobbsee: Wasn't that meant to be resolved in the last year?
<pitti> cjwatson: I don't really want to put it there, so it'll take me some 30 minutes to have a more sane fallback
<Hobbsee> infinity: i'm not sure.  was a sync from debian
<mvo> pitti: thanks, network is very unstable here
<pitti> mvo: got my mail? do you get that, too? does the session-save thing provide a clue?
<infinity> Hobbsee: Oh, it's the Sun Java 5 stuff that's had that fixed, the old Blackdown packages haven't....
<Hobbsee> ahhh
<soren> asac: I believe certain other distros have some patches for network-manager that passes interesting options to wpa_supplicant based on the driver the device is using.
<infinity> Hobbsee: Any chance it could be updated to build-dep (and build with) a java that's not a decade old?
<mvo>  pittiI haven't looked to closely yet, but I got the mail. I will try to find seb to talk about it
<soren> asac: I used to have a patch like that for madwifi-ng, too.
<mvo> pitti: I strongly suspect gnome-session here
<Hobbsee> infinity: probably.  i wonder if there's a new debian version.  i'll look into it, anyway
<infinity> Hobbsee: Well, accepting license agreements in buildd chroots isn't something I'm keen to do. :)
<aquo> asac: i don't know, have to analyze the code
<cjwatson> pitti: ok, thanks
<Hobbsee> infinity: obviously :)
<infinity> soren: Accepted.
<soren> infinity: Rock! thanks!
* soren calls it a day
<soren> Cheers, guys.
<iwj> Hmm, surely it can't really be the case that by chance the alphabetically first source package in gutsy main (acpi) is FTBFS ?
<infinity> Doesn't look FTBFS to me...
<pitti> cjwatson: uploaded; it's not pretty, but works for me; please let me know if it causes trouble
<pitti> cjwatson: not pretty> you get two confusing, but harmless warnings during the run
<iwj> `Dependency is not satisfiable: automaken' but perhaps this is a bug in my test setup.
<infinity> Your test setup may not like build-deps on virtual packages.
<infinity> Our sbuild is slightly more forgiving than that.
<iwj> You're right, that would seem to be the problem.  I'm sure that it used to be discouraged to just list a virtual package like that.
<iwj> But the current version of Debian policy 7.4 seems to say it's optional to list a real package to define a default.
<iwj> mvo: ^
<iwj> I'm using gdebi to satisfy the build-depends and it can't cope if only a virtual package name is given.
<mvo> iwj: oh - I can fix that for you
<iwj> Thanks :-).
<iwj> My test case is the build-deps for acpi; I can provide a recipe for reproduction if you want.
<mvo> iwj: do you have a good example package? was that acpi?
<Kano32> hi, just tested latest daily snapshot on intel g33.
<mvo> iwj: thanks, I hope that this is good enough (using acpi)
<mvo> iwj: how urgent is it? I'm at guadec currently
<Kano32> basically it is ok, just one major package is missing: libgl1-mesa-dri
<iwj> Not very.
<Kano32> without it no 3d
<iwj> Do you want me to file a bug ?
<pitti> Kano32: again? *sigh*
<Kano32> tested kubuntu amd64
<cjwatson> pitti: great, thanks
<Kano32> also "katapult" was in the middle of the screen, dont know what the purpose of that app is..
<cjwatson> pitti: I'll bang it into place and see what happens :)
<Kano32> last thing: as network manager is preinstalled, you only need lo in the interfaces files
<Kano32> not every possible one with auto..
<Riddell> Kano32: katapult is a known bug, I should look at it now
<Kano32> thats what i find in 5 min ;)
<pitti> Kano32: which daily snapshot are you actually using?
<Kano32> the current one
<Hobbsee> Kano32: you're running kubuntu, then?
<Kano32> i hate gnome,yes ;)
<Hobbsee> Kano32: i386 or amd64?
<Kano32> amd64
<Hobbsee> good
<Kano32> i always use the current urls -
<Hobbsee> Kano32: katapult is close to what quicksilver is, in the OSX world.
<Hobbsee> (but it shouldnt flash up at the start, that's a bug)
<Kano32> hmm i did not use osx so deeply
<kylem> doko, around?
<Hobbsee> !katapult | Kano32
<ubotu> Kano32: katapult is the new application launcher for KDE, to be used with applications, bookmarks, and Amarok playlists. Once you have installed, hit Alt+f2 -> katapult, then hit Alt+Space, and type what you want.
<Kano32> so will check again latest this week
<Kano32> bye
<cjwatson> soren,ryanakca: well, I've reproduced that LVM thing here, which is half the battle
<Hobbsee> evand: ping
<evand> Hobbsee: pong
<Hobbsee> evand: did you have an upload of the installer to go in, before the freeze tomorrow?
<Hobbsee> evand: and did you manage to fix that gksudo/sudo bug?
<evand> Hobbsee: not unless I can fix the gksu bug before then
<evand> nope, not yet.  Working on it though.
<Hobbsee> evand: right, okay.  i'm happy to test out, if you think youv'e got it working
<evand> ok, that will be helpful as I'm not entirely sure the bug I've reproduced is the same one the rest of you are seeing.  I'll let you know when I have a proposed fix.
<Hobbsee> evand: cool :)
<infinity> calc: Around?
<infinity> calc: The OOo build appears to be stuck on regcomp.bin waiting patiently for... Nothing.
<infinity> calc: (On powerpc)
<Hobbsee> well, nothing's a good thing to wait for.
<infinity> Hobbsee: Not when it will be waiting forever for said nothing.
<Hobbsee> infinity: no, no, not forever.  gutsy will eventually EOL, and the buildd will be building for another release
<iwj> -anarres:autopkgtest--ubuntu> cd ../autopkgtest--main
<iwj> -anarres:autopkgtest--main> bzr pull ../autopkgtest--ubuntu
<iwj> All changes applied successfully.
<iwj> -101 revision(s) pulled.
<calc> infinity: yea thats very odd
<cjwatson> keescook: are you taking over devmapper from Keybuk? If so, see bug 126379
<ubotu> Launchpad bug 126379 in devmapper "/dev/mapper/* -> /dev/dm-* symlink scheme breaks partman-crypto" [Undecided,New]  https://launchpad.net/bugs/126379
<wasabi> oh man. md broken in initramfs once again.
<wasabi> differently.
<infinity> calc: That's one way of describing it.
<infinity> calc: It's not spinning the cpu or anything it's just hung in msgrcv() perpetually.
<calc> infinity: i'm going to be uploading 2.3 soon anyway :\
<aquo> asac: what is you next action on https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/50214
<ubotu> Launchpad bug 50214 in network-manager "can't connect to hidden network" [Undecided,Confirmed] 
<keescook> cjwatson: he hinted at it, but hadn't said so.  126379's cause, as I understand it, will be going away.  Keybuk was doing that for debugging.
<infinity> calc: That may magically fix it, so by all means, upload soon. :)
<cjwatson> keescook: yep, I mentioned that I knew it was temporary in the bug
<asac> aquo: i have to understand the issue ... and if we can resolve it for real ... i mean we still don't know if anything fixes this, right?
* Hobbsee --> bed.  night all.
<infinity> calc: I'd rather debug failures in 2.3 than debug 2.2.1, only to find something new and differently broken in a week.
<cjwatson> keescook: but no harm having a bug to note that it does actually break stuff :-)
<calc> infinity: exactly :)
<keescook> cjwatson: yeah, it breaks some cryptsetup things too, and makes my "df" output unreadable.  ;)
<keescook> well, unfriendly, not unreadable
<infinity> calc: I'll just kill off my test build then, and wait for 2.3... Is there an ETA on that?
<aquo> asac: yes, maybe it is a real network-manager bug, i read lots of code today, wpa_ctrl.c and some other things ... it is mysterious to me
<asac> yes ... its highly asynchronous ... and some parts are done by applet
<geser> keescook: have you had time to look over the updated debdiffs from bug #124629?
<ubotu> Launchpad bug 124629 in gsambad "[CVE-2007-2838]  Unsafe tmp file usage" [Undecided,In progress]  https://launchpad.net/bugs/124629
<asac> aquo: can you reproduce it?
<aquo> asac: yes, on different systems, edgy and feisty
<asac> you have gutsy?
<aquo> no
<aquo> i tried different versions of network manager, didn't solve the problem.
<aquo> next thing i will try is to upgrade wpa_supplicant.
<keescook> geser: haven't yet, later today, I'm hoping.  :)
<aquo> asac: for another strange reason my synaptic says wpasupplicant-0.5.7 is installed, but the executable says it is different
<cjwatson> soren,ryanakca: OK, tomorrow's image should be happier for swap on LVM.
<aquo> aquo@cayley:~/Temp/network-manager-0.6.4/src$ wpa_supplicant -v
<aquo> wpa_supplicant v0.5.5
<aquo> can someone check this please?
<calc> infinity: no ETA yet, but hopefully i will have it in gutsy by tribe-4
<aquo> just compare package version of wpasupplicant and the version of the binary?
<aquo> on feisty
<calc> infinity: otherwise i will be staying up really late getting it done
<calc> infinity: has to be in before the week after tribe-4 at latest anyway
<infinity> calc: Kay... Upload early, upload often.  If it builds at all, I want to see it, so we can iron out failureds.
<infinity> failures, too.
<calc> infinity: i am hoping to get it in by end of next week though
<ryanakca> cjwatson: ok, what I was trying to say was, in the partitioning menu, you can use guided partition on a whole disk to partition an LVM, even though that's not the way LVM works. Maybe prevent the guided partition a whole disk from working on an LVM?
<aquo> can anybody compare the package version and the version of wpa_supplicant on his system?
<wasabi> yay things now segfault this morning. =)
<mr_pouit> https://wiki.ubuntu.com/MainInclusionReportXfce4PlacesPlugin (approved by iwj) <<< can it be moved to main before the tribe 3, or is it too late ?
<ryanakca> is ReiserFS unmaintained at the Kernel/Upstream level, or at the Ubuntu level?
<mjg59> ryanakca: No
* ryanakca scratches his head...
<ryanakca> ScottK: ??
* aquo is going crazy bout this bug
<mjg59> There's very little maintenance of Reiser upstream
<mjg59> But it's not strictly unmaintained
<ryanakca> ah
<aquo> Yes, because Reiser is a suspected murderer
<ryanakca> oh
<aquo> he is accused of having killed his wife
<mjg59> No, Reiser3's support level hasn't really changed since then
<kylem> reiser3 is completely unmaintained.
<mjg59> kylem: Trivial patches seem to end up in it every so often
<kylem> hans refused to maintain it, so suse did it, and now suse has dropped it.
<mjg59> It's not at the point where it's bitrotting yet
<kylem> so it will only be maintained in the kernels suse continues to support.
<pitti> quit cu tomorrow
<mikmorg> Hello all.
<mikmorg> I have been developing a CD remastering utility for Ubuntu for the past couple weeks at Dell. If anyone is interested in obtaining a copy, you can send me an e-mail at Michael_Morgan@Dell.com. Its still highly beta, but we can always use more hands in making it better.
<Amaranth> mikmorg: you mean like for making your or live cd?
<Amaranth> err, your own
<ryanakca> cjwatson: would bug 126411 have anything with the fail to mount swap bug? (Maybe it doesn't successfully mount anything after the first lvm, thus not creating the home dir)
<ryanakca> https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/126411
<ubotu> Launchpad bug 126411 in debian-installer "Alternate installer doesn't create home directory" [Undecided,New]  https://launchpad.net/bugs/126411
<ryanakca> ah, there we go :)
<mikmorg> amaranth: yes
<mikmorg>  Does anyone know of a very simple dpkg package manager that can be scripted powerfully? Apt seems to do too much for me.
<mikmorg> Apt likes to install stuff that I don't want..
<ScottK> mikmorg: Usually there's a reason it wants it.  Be careful.
<mikmorg> ScottK: It sees a new version of a package already installed, and forces me to upgrade.
<mikmorg> ScottK: Unless you know of a way to keep it from doing that... ?
<Mithrandir> mikmorg: no, it doesn't do that by default.
<Mithrandir> if you're seeing that, it's a symptom something else is going on
<mikmorg> Mithrandir: Hmm.. I'll look into it again then. Thanks.
<mr_pouit> cjwatson: could you add j1mc (jwcampbell_AT_gmail.com) and I (mrpouit_AT_ubuntu.com) to the Xubuntu daily CD health check? (jani asked some time ago, but the mail might have been lost). Thanks :)
<asac> crimsun: is there any good reason that all this debian/config logic exists in flashplugin-nonfree?
<ScottK> Mithrandir: StevenK uploaded a clamav source backport to dapper-backports over 6 hours ago and it has yet to show up.  How long should I wait before asking you to look into it?
<Mithrandir> ScottK: given it needs manual approval, it won't magically show up
<Mithrandir> I can take a look at it
<ScottK> Ah.  OK.  Thanks.
<ScottK> Version is 0.88.7-1ubuntu1~dapper
<cjwatson_> ryanakca: I doubt it
<cjwatson> ryanakca: (though I suppose it's *possible*, but the bug I fixed was very swap-specific)
<cjwatson> mr_pouit: done
<cjwatson> mr_pouit: (I didn't see a mail)
<mr_pouit> cjwatson: thanks a lot :)
<ryanakca> cjwatson: okies :)
<cjwatson> ryanakca: I can't see how to reproduce the thing you mention about running guided partitioning for LVM on just one disk
<cjwatson> ryanakca: could you explain what steps I need to take in the UI to do that?
<cjwatson> mr_pouit: thank me after you've got fed up with the mails ;-)
<mr_pouit> ok ;P
<ryanakca> sure, have an alternate CD up and running?
<cjwatson> ryanakca: yes
<ryanakca> ok, in the partitioning part, go to guided LVM, and set that up so that you have just /dm-0 hogging up most of the space
<ryanakca> erm.. /dev/dm-0...
<cjwatson> have already done that
<ryanakca> (no dm-1, etc), then umm... lemme see, save that initialise it methinks it was, and then it prints an error message, and brings you back to the manual partition
<cjwatson> I have a dm-1
<cjwatson> err. so you mean go back to the main menu and run partition disks again?
<cjwatson> "Configure the Logical Volume Manager" doesn't let me select a disk
<ryanakca> back, sorry
<ryanakca> yep
<ryanakca> that, or select the <go back> and it'll bring you to the original partition menu
<ryanakca> then select guided partiton an entire disk
<ryanakca> you should see /dev/dm-1 amoung the options listed
<ryanakca> I don't think that /dev/dm-1 should be listed there, because it isn't intended to be partitioned that way
<ryanakca> cjwatson: see it?
<cjwatson> oh, guided partitioning, ok, sorry
<cjwatson> right, I'm guessing that's yet another item of fallout from the temporary /dev/mapper/* -> /dev/dm-* symlinks
<ryanakca> ok, so it's known?
<cjwatson> not this particular item
<cjwatson> the installer blacklists /dev/mapper/* but not /dev/dm-*
<ryanakca> ah
<cjwatson> I'll hack around it now
<ryanakca> cjwatson: thanks :)
<cjwatson> those symlinks are due to go away for gutsy though
* ryanakca nods
<cjwatson> actually, I dunno
<cjwatson> I have a feeling that maybe the right thing would be just to revert that symlink for the udeb
<cjwatson> because there is *loads* of stuff that does grep -q /dev/mapper/ or equivalent
<ryanakca> ok...
<psyke83> quick question (I know this isn't support): I've resolved a bug on my system in which the Intel driver using EXA crashes when Compiz is enabled - it's a buggy patch in Gutsy's xserver-xorg-core. I have a bug posted with all the details on bugs.freedesktop.org, do I need to open a bug on launchpad or can I just show an Xorg maintainer the bug directly to have it fixed in the next upload?
<psyke83> here's the bug (and resolution): https://bugs.freedesktop.org/show_bug.cgi?id=11626
<ubotu> Freedesktop bug 11626 in Acceleration/EXA "Intel driver (using EXA) crashes system when starting compiz" [Normal,Resolved: notourbug] 
<ryanakca> cjwatson: umm... I think yesterday's installer was really bad. For some reason, /home/ryan is on the '/' lvm, despite my having created a 'Home' lvm, with a '/home' mounted partition
<psyke83> oops, wrong channel - disregard
<cjwatson> ryanakca: see my comment on the bug
<AlinuxOS> doko, ping
<ryanakca> cjwatson: will do, I'm going to reboot into the gutsy live cd, and try installing with that. I'm having a pile of trouble with the alt... no mouse cursor, etc.
<jdong> quick, someone gimme the name of a package that's the same version in feisty and gutsy!
<jdong> well, maybe not that urgently...
<kylem> nvi?
<jdong> self.post[-1] .append('please','thank you', ... )
<jdong> thanks!
<ryanakca> cjwatson: uploaded
<cjwatson> ryanakca: does 'mount' say that /home is really mounted separately
<cjwatson> ?
#ubuntu-devel 2007-07-17
<cjwatson> ryanakca: I've uploaded a version of devmapper that disables the symlink business in (only) the udeb. I'd be interested to know whether tomorrow's daily build fixes that /home weirdness for you.
<cjwatson> ryanakca: I also fixed another glitch in partman-auto visible on the guided partitioning menu that wasn't fixed by that devmapper change
<ryanakca> cjwatson: http://pastebin.ca/622545
<ryanakca> it doesn't look like it's mounted seperately
<cjwatson> ryanakca: right, could well be something to do with this /dev/dm-* thing in that case; try tomorrow?
<ryanakca> cjwatson: yep
<elpargo> hi I believe I found a conflict between vmware and networkmanager packages, for my wireless setup.
<Burgundavia> elpargo: have you filed a bug?
<elpargo> Burgundavia, I want to confirm it first, but I did search bugzilla and found something similar but it seems it was dismiss as invalid.
<Burgundavia> link to the bug?
<elpargo>  http://www.google.com/url?sa=t&ct=res&cd=1&url=http%3A%2F%2Fwww.mail-archive.com%2Fdebian-bugs-dist%40lists.debian.org%2Fmsg364564.html&ei=3hCcRuGKFaLiepfg7KUK&usg=AFQjCNEoinnG9YivPD0hrB9C8J87rmsHWQ&sig2=glyn_8Whi8fe_YfPy9GraQ
<elpargo> ups sorry
<elpargo> http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg364564.html damn google...
<elpargo> I believe there is a crash between vmware's virtual network devices and network manager, from the little I know vmware creates a virtual that points to eth0 which I think it's not letting network manager set eth1
<Burgundavia> interesting
<Burgundavia> have you chatted with upstream networkmanager?
<Amaranth> yay logout fade with compiz
<elpargo> Burgundavia, not yet I wanted to see if it was a problem with the package itself.
<Burgundavia> elpargo: I have no idea. NM is ubuntu does carry a fair amount of patches
<elpargo> Burgundavia, seems to be a driver issue http://mail.gnome.org/archives/networkmanager-list/2006-March/msg00257.html
<Burgundavia> elpargo: ah
<kyled185> sorry if this is a noob question, but I'm trying to make a "hello world" program using kdevelop and qt4, however when I try to build the project I get "*** AUTOCONF NOT FOUND!." I have autoconf installed however and that's what's confusing me...any ideas on what's going wrong?
<kyled185> ack sorry I just noticed the topic, I'll ask in the proper channel
<RAOF> :)
* jdong hands kyled185 for being a good boy?
<doviende> anyone know why the ping command isn't localized?  i just checked the code and there are no gettext macros, so even if the phrases exist on the system for some language, it won't use them
<doviende> seems like basic things like that would be the first things to be localized
* Starting logfile irclogs/ubuntu-devel.log
<LongPointyStick> how would i troubleshoot why my fan is on full speed, and my system is incredibly slow?
<doviende> LongPointyStick: laptop?
<superm1_> LongPointyStick, ps aux ?
<superm1_> and top
<superm1_> etc
<doviende> if i wanted to know why things are slow, i'd use "top"
<doviende> as for the fan, i know that my bios on my laptop currently isn't supported well, so i can't change my fan speed
<doviende> but i hear that if i could, i'd be able to go to the /proc/acpi directory and find something about my fan speed there
<superm1_> something like this: http://paste.ubuntu-nl.org/30187/ :)
<TheMuso> Hobbsee: Is your hard drive appearing as an sd, or hd device?
<doviende> superm1_: haha, ya.
<Hobbsee> superm1_: nothing of particular interest
<Hobbsee> in htop
<Hobbsee> apart from massive amounts of both cores being used
<superm1_> but no indication of what process?
<Hobbsee> doviende: yes
<Hobbsee> superm1_: nope
<Hobbsee> superm1_: it starts while the machine is booting - fairly early in teh boot sequence
* Hobbsee should turn "quiet" off, and see
<Hobbsee> TheMuso: sda, when it's working properly
* Hobbsee has rebooted now
<TheMuso> oh ok. Thgouth it may have been a DMA issue.
<TheMuso> or something along those lines.
<Eleaf> hi, I have a question about the package nvidia-glx-new.
<Eleaf> I recently booted to find X would not start due to an api mismatch (nvidia kernel & xorg kernel not same version), X has worked before fine.  I let my computer be off for about a week, and when I rebooted, X didn't work.
<Eleaf> It turns out installing nvidia-glx-new makes X work okay again.  Why is this package not installed automatically as an update if it creates such a fatal situation?
<crimsun> asac: it's inherited from the Debian source package; Bart is better addressed
<Eleaf> peace
<Hobbsee> nice, shiny bling...
<Hobbsee> hi Fujitsu
<Hobbsee> Amaranth: ping
<Amaranth> Hobbsee: pong
<Hobbsee> Amaranth: were you planning to fix https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/107109 ?
<ubotu> Launchpad bug 107109 in compiz "No "New Login" for user with Desktop effects enabled" [Critical,Triaged] 
<Amaranth> Hobbsee: not really fixable
<Amaranth> well, i can make compiz bail out and load metacity
<Amaranth> oh, i commented on that bug awhile ago :P
<Amaranth> we can't check 'direct rendering: no'  because thanks to AIGLX and Xgl that doesn't mean anything
<Hobbsee> fun
<Amaranth> i suppose we could jump through some hoops to see if you have more than one X running
<jdong> Amaranth: come on boy
<Amaranth> heh
<jdong> Amaranth: (1) xvinfo | grep Xgl is a good test for Xgl
<Amaranth> well, it's not that hard
<Amaranth> jdong: AIGLX though
<jdong> Amaranth: why doesn't new session work for AIGLX??
<jdong> ah
<jdong> nvm
<Amaranth> jdong: no no, i'm saying with AIGLX checking direct rendering is useless
<jdong> RTFMBR
<Amaranth> uh
<Amaranth> don't know that one
<jdong> Malone Bug Report
<jdong> :D
<RAOF> Could we go crazy and spawn multiple Xgl sessions by default?
<Amaranth> Hobbsee: also i can't fix anything right now because seb128, dholbach, and mvo are at GUADEC and i'm not :P
<Hobbsee> Amaranth: that's what i figured, too
<Amaranth> RAOF: dude that was the original idea :)
<jdong> I got it!
<jdong> how about we have a master X server that spawns child Xgl fullscreens for each user?
<jdong> MUAHAHAHAHA
<RAOF> Amaranth: Aaah.  So, why not.  Oh, of course.  That'd mean Xgl needs to be in main
<Amaranth> jdong: dude that was the idea
<Amaranth> jdong: with some minimal window management in gdm to do a neat transition when you switch users
<Hobbsee> LP: #121135
<jdong> Amaranth: IMO that's not a bad idea at all
<Amaranth> bug 121135
<ubotu> Launchpad bug 121135 in compcomm-plugins-main "/usr/bin/dpkg returned an error code" [Medium,Fix committed]  https://launchpad.net/bugs/121135
<Amaranth> jdong: that's what i said
<jdong> RAOF: meh we just suck patches from Novell buddies
<jdong> Amaranth: I'd totally go for that.... hell Xgl is a lot faster on most system rendering 3D effects anyway
<Amaranth> Hobbsee: I'm not core-dev :)
<jdong> the only painful thing is scrolling :)
<Amaranth> Hobbsee: need to wait for mvo to get anything done
<Hobbsee> Amaranth: true
<Hobbsee> Amaranth: there are other core devs around
<Amaranth> unless you want to snag that package from bzr and upload it
<Hobbsee> that one's fixed, anyway
<RAOF> jdong: Or David could just do an Xgl *release* finally.
<Hobbsee> was sponsored on june 30
<Amaranth> if it's a change i haven't ran past mvo and/or seb128 i'm not going to do anything with it :)
<jdong> RAOF: haha
<Hobbsee> as in, yoru debdiff was uploaded on june 30 for it, but the bug wasnt marked as released.  may have been while LP was broken
<jdong> RAOF: this reminds me of ion?
<RAOF> Amaranth: Bah, just feed crazy untested code through the Hobbsee spigot
<Hobbsee> hah
<Amaranth> RAOF: sounds good
<Amaranth> Hobbsee: I've got this copy rendering patch....
<Hobbsee> dream on.
<Hobbsee> i want to freeze main today
<Amaranth> eh?
<Hobbsee> yay, down to 22!
<Hobbsee> Amaranth: tribe 3
<Amaranth> we got another tribe coming up?
<Hobbsee> Amaranth: see the /topic
<Hobbsee> yep
<Amaranth> wow, that was fast
<Amaranth> it just changed to tuesday here :)
<Hobbsee> only for you who doesnt coordinate them :)
<Hobbsee> it's 4pm tuesday now, but i'll have to wait for a while, yes
<Amaranth> 22 critical bugs?
<Amaranth> bug 122949 has an _easy_ fix
<ubotu> Launchpad bug 122949 in compiz "Tray icons take a LONG time to appear with compiz enabled" [Critical,Triaged]  https://launchpad.net/bugs/122949
<Hobbsee> Amaranth: not critical.
<Hobbsee> https://launchpad.net/ubuntu/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=New&field.status%3Alist=Incomplete&field.status%3Alist=Confirmed&field.status%3Alist=Triaged&field.status%3Alist=In+Progress&field.status%3Alist=Fix+Committed&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_contact=&field.milestone%3Alist=470&field.component-empty-marker=1&field.status_upstream-empty-marker=1&field.omit_dupes.used=&f
<Hobbsee> ield.omit_dupes=on&field.has_patch.used=&field.tag=&field.has_cve.used=&field.has_no_package.used=&search=Search
<Hobbsee> http://tinyurl.com/2krybt
<StevenK> Ouch
<Hobbsee> that's a bad url.
<jdong> Hobbsee: I'm going to check /var/log/snort.... and I think your name will be in there :D
<Hobbsee> :P
<Amaranth> Hobbsee: why doesn't 122949 show up on there?
<Hobbsee> Amaranth: because it's not milestoned for tribe 3?
<Amaranth> oh
<Amaranth> in that case, i can clear compiz off your list ;)
<Amaranth> unless those guys stop drinking and get on IRC :)
<Hobbsee> haha
<Hobbsee> yeah, well.  it looks like gnome* will have to be deferred
<Hobbsee> but i get the suspicion that some of this stuff is already fixed, but not closed
<ajmitch> nice to see so many open bugs there
<Amaranth> how can it be Incomplete and milestoned for tribe-3?
<Amaranth> it == a bug
<Hobbsee> ajmitch: well, i'm shoving a lot of them off, so...
* ajmitch hugs dholbach 
<Amaranth> dholbach!
<Hobbsee> Amaranth: because some people are milestoning things weirdly.  *shrugs*
<Hobbsee> hey dholbach!
<dholbach> good morning
<dholbach> hey Amaranth, ajmitch, Hobbsee!
* Hobbsee hugs dholbach 
* dholbach hugs Hobbsee back
<pitti> Good morning
<Hobbsee> morning pitti!
* pitti hugs Hobbsee 
<Hobbsee> pitti: you uploaded cupsys yesterday - is https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/119289 fixed in that upload?  i'm guessing that it is
<ubotu> Launchpad bug 119289 in cupsys "make backend invocation compatible to upstream" [High,In progress] 
* Hobbsee hugs pitti back :)
<Amaranth> morning pitti
<Burgundavia> morning pitti
<pitti> Hobbsee: no, it is not; that's horribly complicated
<Burgundavia> pitti: was it you who was assigned the hardware db stuff?
<Hobbsee> pitti: right.  i presume you want to defer that, as per the discussions a couple of days ago?
<pitti> Burgundavia: no, it's not assigned ATM
<pitti> Hobbsee: yes, I just didn't get to it
<Burgundavia> pitti: moving to -desktop
<Hobbsee> pitti: deferred
<Hobbsee> oy, ajmitch :)
<Hobbsee> ajmitch: any plans to fix https://bugs.launchpad.net/ubuntu/+source/samba/+bug/85194 ?
<ubotu> Launchpad bug 85194 in samba "samba's package postinst script shouldn't return an error if samba daemon can't be started (e.g. if smb.conf file is incorrect or is removed)" [Medium,Confirmed] 
<Hobbsee> ogra's not at guadec, is he?
<Hobbsee> pitti: also, were you looking into https://bugs.launchpad.net/ubuntu/+source/language-pack-fr-base/+bug/122277 ?
<ubotu> Launchpad bug 122277 in language-pack-fr-base "gutsy language pack doesn't ship the gdebi translation" [Undecided,New] 
* StevenK waves to pitti
<pitti> Hobbsee: oh, I'll do that today
<pitti> hi StevenK
<Hobbsee> pitti: great, thanks
<pitti> Hobbsee: erk, I need to upload new base langpacks, to minimize the space
<StevenK> pitti: Can I bug you about a sync? :-)
<pitti> StevenK: yes
<Hobbsee> pitti: get to it :)
* pitti summons carlos
<StevenK> pitti: Bug 124900
<ubotu> Launchpad bug 124900 in gtkpod "Please sync gtkpod-0.99.10, libgpod-0.5.2 from debian unstable" [Wishlist,Confirmed]  https://launchpad.net/bugs/124900
<pitti> StevenK: so, I shall sync gtkpod and also gtkpod-aac, and then kipi-plugins will build?
<StevenK> I wasn't aware gtkpod-aac was in Debian.
* persia thought gtkpod-aac needed a new special Ubuntu upload
<StevenK> pitti: kipi-plugins has built already.
<pitti> StevenK: so what about the gtkpod-aac and kipiplugins tasks?
<StevenK> I think that was the submitter being over excited. :_)
<pitti> StevenK: synced; I'll just close the gtkpod task, and leave the others to you
<StevenK> pitti: Thanks
<StevenK> I was going to be lazy and ask tepsipakki to deal with gtkpod-aac.
<fabbione> morning
<Hobbsee> morning fabbione!
<Hobbsee> *** WARNING:  IMPENDING MAIN FREEZE ***
* fabbione uploads a couple of new kernels
* Hobbsee beats fabbione with a big stick
<fabbione> you need more than a big stick for me :P
* Hobbsee gets out the large piece of concrete
* ..[topic/#ubuntu-devel:Hobbsee] : Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty, #ubuntu+1 for gutsy support | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Main FROZEN for Tribe 3
<Amaranth> jdong: can you test https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/126469 for me?
<ubotu> Launchpad bug 126469 in gnome-session "[patch]  logout fadeout when compiz is running" [Medium,Triaged] 
<Amaranth> jdong: really want to get it into tribe-3 :)
* Hobbsee waves the Long Pointy Stick of DOOM!!!!!!!!!!!!!!!  threateningly at Amaranth 
<Amaranth> hehe
<Amaranth> Hobbsee: it's related to high priority spec ;)
<Hobbsee> hahaha
<Hobbsee> good luck
* Hobbsee therefore demands kde4, finished, in main, right now.  "it's related to a high priority spec, so it's allowed!"
<Amaranth> heh
<TheMuso> haha
<Amaranth> mine is plausible :)
<pitti> soren: the samba upload was just caught by the freeze
<StevenK> Hobbsee: Good luck with that. :-)
<pitti> soren: how important is this for tribe3?
<Amaranth> oh, you've already frozen
<Amaranth> dang
<dholbach> it'd be nice if people could test the patch that Amaranth pointed to (bug 126469)
<ubotu> Launchpad bug 126469 in gnome-session "[patch]  logout fadeout when compiz is running" [Medium,Triaged]  https://launchpad.net/bugs/126469
* pitti hugs dholbach for fixing bug #122949
<ubotu> Launchpad bug 122949 in compiz "Tray icons take a LONG time to appear with compiz enabled" [Critical,Fix released]  https://launchpad.net/bugs/122949
<Amaranth> pitti: :D
<Amaranth> who would have thought disabling session management would break gnome-session? ;)
<dholbach> it makes compiz working for me again (I have window decorators), but now it seems to take like 30-40 seconds for the logout dialog to show up -- I personally suspect a broken configuration or something, but it'd be nice to know for sure
* dholbach is happy with window decorators
<pitti> dholbach: 30-40 seconds? that rather sounds like another incarnation of the session connection bug?
<pitti> dholbach: did you wait long enough after login?
<dholbach> pitti: yeah, but that was because gnome-session looked for things that gnome-power-manager did not send anymore :)
<dholbach> ahhhhh! ;-)
<soren> pitti: I'd appreciate it if you pushed it through.
<dholbach> ok, I was too impatient
<pitti> dholbach: ^ I thought that got fixed for tribe1??
<dholbach> pitti: yes yes yes it was
<dholbach> :-)
<soren> pitti: Just for the sake of testing.
<Amaranth> dholbach: it works now?
<dholbach> Amaranth: yes, it does - pitti was right: I was too impatient
<soren> pitti: More testing of the previous samba version won't do us much good anyway.
<pitti> dholbach: the problem with compiz is that it does not connect to the session and thus needs a minute, until the other programs in the session (dbus related, etc.) can start up
<pitti> dholbach: ok, good *phew* :)
<dholbach> Amaranth: did you test your patch with metacity?
* dholbach will do that now
<Amaranth> dholbach: yes
<dholbach> if that works out ok, I'll upload it
<Amaranth> i say so in the bug
<pitti> soren: ok; you specifically tested the client lib, right? (through nautilus, etc.)
<dholbach> bbiab
<Amaranth> just start metacity and click logout
<Amaranth> bleh, no need to start a new session :P
<soren> pitti: Both command line utils, server and library (through nautilus), yes.
<Hobbsee> soren: you are the samba person?
<soren> Hobbsee: That's sort of a dangerous question to answer.
<Hobbsee> hah
<pitti> soren: waved through
<soren> pitti: Thanks!
<Amaranth> Hobbsee: that reminds me of http://uwstopia.nl/blog/2007/07/as-heard-on-guadec
<soren> Hobbsee: Do you need anything in particular or are you just looking for who to blame when it doesn't work?
<Hobbsee> soren: the latter
<Hobbsee> soren: and who to assign bugs to when it's broken, and needs fixing.
<soren> Hobbsee: Then it's someone else. :p
<Hobbsee> hahahaha
<soren> Hobbsee: Server team.
<Hobbsee> soren: you're screwed over by the TIL principle
<Hobbsee> which you're on, right?  :P
<soren> Hobbsee: True, but if you assign to the server team instead, someone else might grab it if I ignore it for long enough. :)
<Hobbsee> haha
<Hobbsee> soren: i wield the Long Pointy Stick of DOOM!!!!!!!!!!!!!!! .  ignoring me is not in your best interests.
<Hobbsee> :P
* Amaranth fears
<soren> Nor would it be very easy with that scary thing waving in one's face.
<Hobbsee> haha, indeed :)
<simira> Hobbsee: did you see the nice earrings I bought in Birmingham?
<Hobbsee> simira: i did!  :)
<Hobbsee> simira: they're very pretty
<dholbach> Amaranth: I uplaoded the gnome-session change
<elpargo> hi anyone around that can kick some lamers form #ubuntu
<dholbach> it works nicely for me too
<elpargo> they are spamming the chat....
<Amaranth> dholbach: awesome
<Amaranth> elpargo: they were gone before you even said something here :)
<Hobbsee> elpargo: i saw with the -ops call
<Hobbsee> elpargo: call it earlier, we'll respond earlier.
<Hobbsee> :)
<elpargo> hehe thanks guys
<elpargo> I really don't get why people do that... so annoying nothing to gain out of it.
<pitti> cjwatson_: I guess it won't hurt too much to move bug 118744 to tribe4 and just live with the workaround for some more time?
<ubotu> Launchpad bug 118744 in gfxboot "no gfxboot in gutsy with new syslinux" [High,Confirmed]  https://launchpad.net/bugs/118744
<elpargo> gout another spammer ... :(
<StevenK> elpargo: Please use #ubuntu-ops for this, as opposed to here.
<Amaranth> elpargo: just keep calling !ops when it happens and we'll keep on it, no need to talk about it here
<elpargo> oh I didn't knew about that channel or command will do that from now on.
<doko> pitti: did you demote freetype1? thx anyway
<pitti> doko: yes, I did, nothing wanted it any more; you still need it?
<doko> pitti: no, I did remove the last user =)
* pitti hugs doko
<StevenK> pitti: Was python-eye3d or somesuch also on the list to be demoted?
<pitti> doko: cruft-- :)
<pitti> StevenK: no, I didn't touch that
<fabbione> pitti, Hobbsee: permission to upload lvm2. debdiff: http://people.ubuntu.com/~fabbione/lvm.debdiff
<fabbione> pitti, Hobbsee: it's a safe change.. and tested
<fabbione> affects only sparc
<StevenK> pitti: I was just curious if it was, since libgpod jumped to mutagen from it.
<fabbione> it fixes install on lvm when running on virtual disks
<pitti> fabbione: looks fine to me
<fabbione> (well it fixes lvm on vdisks... but also the install)
<fabbione> pitti: ok thanks
<fabbione> pitti: it's uploaded.. i guess you can allow it or not as you prefer
<pitti> fabbione: I guess we really want that, so that LDOM can be properly tested on tribe3?
<StevenK> Tonio_: Ping, I'd like your opinion about amarok when you have a spare sec.
<Tonio_> StevenK: I'm there :)
<Tonio_> hi everyone
<fabbione> pitti: we don't officially support LDOM yet. so it's not a blocker of any kind but i would like to have it in
<fabbione> pitti: it's a table extension... no code change..
<pitti> fabbione: right; I'll accept it once it's in the queue
<fabbione> pitti: but seriously.. i am not going to force this down your throat
<StevenK> Tonio_: I uploaded a rebuild-only change last night, which failed ... due to some other library changing it looks like.
<fabbione> pitti: cheers
<pitti> dholbach: how save is that gnome-session upload?
<Tonio_> StevenK: hum, interesting....
<Tonio_> StevenK: can't look at that right now, but I'm adding this t my todo....
<Tonio_> StevenK: I'll have a look at the buildlog at 12
<StevenK> Tonio_: Cool, thank you. :-)
<cjwatson_> pitti: sigh. I guess so :-(
<Amaranth> pitti: very
<pitti> Amaranth: it works with metacity, too?
<Amaranth> yep
<dholbach> yes, I tested it with metacity too
<pitti> accepted
<cjwatson> hmm, I wonder if we can demote dhcp to universe in time for tribe-3 if I do a few seed merges?
<Amaranth> woohoo
<Amaranth> right after tribe-3 i'll fix gksu too :)
<Amaranth> that's the one i was originally working with but i noticed a comment saying they'd snagged that code from gnome-session and figured it might be a little saner
<Amaranth> sadly it was
<Hobbsee> fabbione: pitti looks safe
<Hobbsee> ogra!
<ogra> hey
<Hobbsee> Amaranth: you can fix it now.  it'll sit in the queue
<Hobbsee> ogra: i come to poke you about tribe 3 stuff
<ogra> oh sigh, totally forgot about tribe 3
<Amaranth> ogra: main is already frozen :/
* ogra is fully drugged, had a jaw surgery yesterday
<Amaranth> well, freezing :)
<Hobbsee> ogra: ouch
<Amaranth> eek
<Amaranth> ogra: spin around in a circle three times
<Amaranth> ;)
<Hobbsee> ogra: to make it easy for you then, https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/122796 and https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/121547
<ubotu> Launchpad bug 122796 in ltsp "ltsp default dhcpd.conf broken on tribe2 installs" [High,Triaged] 
<ogra> Hobbsee, no, yay ... i was running around with an exploding head for the last 10 days
<Hobbsee> ahhh...
<ogra> Hobbsee, thats fixed, wortse is that i hhave to rewrite the udeb ...
<Hobbsee> ogra: which?
<Hobbsee> there are two bugs there - are they both fixed?
<ogra> Hobbsee, oh, sorry, i (as ubotu) missed the second one
<Hobbsee> ogra: ahh
<ogra> i think its bug 121547
<ubotu> Launchpad bug 121547 in ltsp "[Gutsy]  LTSP chroot building process hangs at 50% on Tribe1 CD" [Undecided,Confirmed]  https://launchpad.net/bugs/121547
<ogra> yeah
<Hobbsee> ogra: so is https://launchpad.net/bugs/121547 an edubuntu-blocker?
<ubotu> Launchpad bug 121547 in ltsp "[Gutsy]  LTSP chroot building process hangs at 50% on Tribe1 CD" [Undecided,Confirmed] 
<ogra> Hobbsee, well, if i dont make it it needs to be at least in the release notes again (which is a bit disconcerting)
<pitti> ogra: is it that hard to fix the dhcp configuration?
<pitti> ogra: that one is pretty nasty
<Hobbsee> ogra: right.
<Hobbsee> pitti: ogra said the dhcp one was fixed, and the other one wasnt.
<pitti> ah, cool
<ogra> pitti, thats already done here, i havent uploaded yet (its a native package, i like to collect stuff before bumping the version)
<Hobbsee> (assuming i read correctly(
<ogra> you did
<Hobbsee> \o/
<Hobbsee> stgraber: ping
<Fujitsu> Are Debian removals still being automagically processed?
<stgraber> Hobbsee: pong
<Hobbsee> stgraber: any chance we can get the iso testing site updated for tribe 3?
<persia> Were Debian removals ever automagically processed?
<stgraber> Hobbsee: yes
<Hobbsee> infinity_: according to http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/gutsy/ubuntu/latest/ amd64 and ppc have built the 17.1 images, but not i386.  can you look into terranova again, and see why i'ts misbehaving, please?
<stgraber> Hobbsee: Can I add all isos or are some still generating ?
<Hobbsee> stgraber: um, they're all invalid, except for kubuntu desktop, i think
<Hobbsee> i'm not sure how your adding works
<pitti> hi mvo
<Hobbsee> mvo!
<mvo> hey pitti
<stgraber> I add isos, then if they are invalid and have to be rebuilt I disactive them, but it's a nonsense to add isos to disable them just a minute later, it's better to wait till we have the new set ready
<mvo> hey Hobbsee
* StevenK waves to mvo
<Hobbsee> mvo: please dont break the livefs', right before the main freeze.
<Hobbsee> stgraber: right, OK, that's fine.  i wasnt sure how much prework needed to be done.
<mvo> Hobbsee: I did not do the compiz upload
<mvo> Hobbsee: but I can do a upload now to fix the breakage
<mvo> Hobbsee: we currently have network so I better be quick ;)
<Hobbsee> stgraber: it seems like we're going to have cds ready for testing in stages
<Hobbsee> mvo: true, but it appears that you did the control changes.
<Hobbsee> mvo: please do
<stgraber> Hobbsee: I put the Tribe-2 isos as tested and set tribe-3 as the release currently tested
<Hobbsee> mvo: keep the netwrok there :)
<Hobbsee> stgraber: neat, thanks :)
<TheMuso> c
<TheMuso> ugh
<TheMuso> damn kvm
<Hobbsee> infinity_: unping, then.
<Hobbsee> greetings, seb128
<Amaranth> hey seb128
<StevenK> pitti: Can I get you to poke through the gtkpod-aac upload I just did?
<seb128> GUADEC network, not good
<pitti> StevenK: no problem, it's multiverse
<StevenK> pitti: Thanks
<Amaranth> seb128: that's a shame
<seb128> yeah
<seb128> just enough network to break compiz ;)
* Hobbsee hunts out seb128 
<Hobbsee> :P
<seb128> hey Hobbsee
<Hobbsee> hiya
<seb128> let's see what I can break today ;)
<Hobbsee> seb128: go ahead.
<Hobbsee> seb128: archive is frozen.
<Hobbsee> seb128: so i'll just deny you :P
<Nafallo> \o/
<seb128> Hobbsee:
<seb128> <- archive admin ;)
<Nafallo> haha
<Mithrandir> hehe
<Hobbsee> seb128: Release manager for tribe 3:  --> Hobbsee.
<Hobbsee> does that trump?
* seb128 hugs Hobbsee
<Hobbsee> :P
* Hobbsee hugs seb128 back :D
<infinity> Let's not get into the who trumps who game. :P
<Mithrandir> if we do, I think elmo wins. :-P
<Hobbsee> infinity: can you turn the cron jobs off king and royal please?
<infinity> Hobbsee: Just did, 5 minutes before you asked. :)
<infinity> Hobbsee: (Was tipped off by the "17.1" question)
<Hobbsee> infinity: ah, so you were summoned.  :)
<Hobbsee> infinity: ahh
<Hobbsee> thankyou :)
<Mithrandir> no, he's just really good at divining stuff
<infinity>  Changed the entry level script from 'project-builder
<infinity>  to 'image-creator',
<infinity> Mithrandir: Do you have a trigger change for that?
<infinity> (And people wonder why I read -changes...)
<Mithrandir> infinity: yes, please pull.
<Mithrandir> I knew I forgot one thing
<infinity> Mithrandir: Merged.
<Mithrandir> merged or pulled?  (as in, do you have any divergence?)
<ajmitch> Hobbsee: you were pinging me earlier?
<infinity> Mithrandir: No divergernce.  Merged, because it's a branch, not a checkout.
<stgraber> Anyone knows if Henrik is supposed to be around today ? (I won't be there this afternoon)
<Hobbsee> ajmitch: yes, was wondering if you were planning to fix that samba bug which was mentioned above, due to TIL,  iirc.
<Hobbsee> i think i pinged with the required info
<Mithrandir> infinity: you should be able to pull anyway.
<ajmitch> Hobbsee: can't say that I was planning to, but I can if you really really want
<infinity> Mithrandir: Oh, maybe.  By bzr-fu is weak.
<ogra> stgraber, depends how long his ferry back from london takes and when he travelled
<Hobbsee> ajmitch: it's not critical.  it was just milestoned for some unknown reason
<Hobbsee> it can wait
<Hobbsee> ajmitch: of course, i fyou fix it, it can just sit in the unapproved queue
<ajmitch> Hobbsee: right, and activity log doesn't tell me who/why
<Hobbsee> ajmitch: indeed.  i'd like to know too.  is the canonical QA group involved?
<ajmitch> reminds me that I have a coreutils FTBFS fix to upload
<ajmitch> well, heno was the last person to touch the bug
<Hobbsee> ajmitch: ie, are they subscribed?
<ogra> Hobbsee, ltsp 5.0.21 for you in the queue to wave through ... (with the dhcp fix)
<ajmitch> nope
<Hobbsee> ogra: it only effects edubuntu, presumably?
<ogra> yup
<Hobbsee> pitti: please accept the ltsp upload.  it's on his own head if he breaks his flavour distro.
<ogra> :P
<Hobbsee> :)
<Hobbsee> stgraber: s/We aren't testing any ISO at the moment/We aren't testing any ISOs at the moment/
* Hobbsee is picky with grammar and such.
<Hobbsee> when you next go to edit :)
<Mithrandir> if you are picky; s/aren't/are not/
<Mithrandir> s/;/:/
<pitti> Hobbsee, cjwatson: http://people.ubuntu.com/~pitti/tmp/dhcp3.fix-udeb.diff should make dhcp3 udeb and thus d-i happy; I tested it
<Hobbsee> Mithrandir: i believe aren't is still legitimate english :P
<ajmitch> Hobbsee: it's rather informal
<Mithrandir> Hobbsee: it's very informal
<Hobbsee> true that
<ajmitch> :)
* Hobbsee tickles ajmitch 
<ajmitch> hey!
<pitti> Hobbsee: if you give your ack in the next two minutes, dhcp will make this publisher run
<Hobbsee> pitti: +1, with the full knowledge that i dont really understand the contents of that diff :P
<pitti> Hobbsee: it multibuilds dhcp3 so that the udeb binary does not have the derooting patches applied, and thus does not depend on libcap1
<Hobbsee> ah right
<stgraber> Hobbsee: oh, right, well if you are picky with grammar I'm sure you'll see tons of others :)
<Hobbsee> pitti: i'd kind of figured that much - but the bit on "is this a sensible change / the right thing to do" i was having trouble over.
<pitti> Hobbsee: *yada yada technobabble* recalibrate phase inverters of secondary antineutrino emitters *bla*
<Nafallo> lol
<Hobbsee> stgraber: true.  it's after i notice something that it really starts to annoy me :P
<Hobbsee> pitti: hahaha.
<pitti> Hobbsee: we do not have a libcap1 udeb, and we do not need the derooting in d-i
<Hobbsee> i see
<ajmitch> pitti: just reverse the polarity
<stgraber> Hobbsee, Mithrandir : fixed :)
<Hobbsee> stgraber: great :)
<pitti> asac, Hobbsee: Do we actually need a new firefox for bug 123800?}
<ubotu> Launchpad bug 123800 in firefox "[gutsy]  resource:/browserconfig.properties not installed" [High,Confirmed]  https://launchpad.net/bugs/123800
<pitti> asac: will that be combined with the security update?
<pitti> ogra: so bug 121547 is for tribe4?
<ubotu> Launchpad bug 121547 in ltsp "[Gutsy]  LTSP chroot building process hangs at 50% on Tribe1 CD" [Undecided,Confirmed]  https://launchpad.net/bugs/121547
<mvo> Hobbsee: hug dholbach for fixing compiz please
* Hobbsee hugs dholbach 
<dholbach> mvo, Hobbsee: hug Amaranth instead :)
* dholbach hugs Hobbsee back
* mvo hugs Amaranth
<Hobbsee> mvo: just spotted that.
* Hobbsee hugs Amaranth too then
* Hobbsee made the mistake of assuming that her apt cache was current
<Amaranth> funny story
<Amaranth> i was going to add --sm-client-id to see if that would help and i noticed --sm-disable got in there somehow
<RAOF> Heh
<asac> pitti: no ... this is gutsy only
<pitti> asac: right, that's what I meant
<asac> pitti: i am still unsure if i will come to get this fixed for tribe-3
<Hobbsee> hiya asac!
<pitti> asac: if that bug is not a OMGSIF type, we can also move it over to T4
<asac> however if I come to it, we should take it ... because currently if you don't have ubufox you have a problem because of this :)
<pitti> Hobbsee: FYI, I fixed langpack-o-matic for bug #122277, waiting for carlos' tarball now
<ubotu> Launchpad bug 122277 in language-pack-fr-base "gutsy language pack doesn't ship the gdebi translation" [Medium,In progress]  https://launchpad.net/bugs/122277
<asac> a real problem ... i mean
<Hobbsee> pitti: great :)
<asac> hi Hobbsee
<pitti> asac: hm, but new installs will have ubufox by default, right?
<asac> yes ... but if you go to add-ons and disable it you have the same effect
<asac> not a first run show-stopper though ... I agree.
<asac> pitti: ok i think i move this to after the freeze ... you have my blessing
<pitti> asac: ok, good
<asac> pitti: done
<ogra> pitti, i'll still try to attack bug 121547 but will have to live with it if i dont manage ...
<ubotu> Launchpad bug 121547 in ltsp "[Gutsy]  LTSP chroot building process hangs at 50% on Tribe1 CD" [Undecided,Confirmed]  https://launchpad.net/bugs/121547
<Hobbsee> ogra: put it this way - the longer that takes to fix, the less testing time you have.  but it is kinda your choice.
<ogra> Hobbsee, i know, its not my first milestone CD ;)
<Hobbsee> ogra: true.  was merely saying that as my opinion, being the RM for tribe 3.
<ogra> yep
* Hobbsee --> dinner, for real this time.
<Riddell> mvo: "No GLXFBConfig for default depth" what causes that in compiz?
<mvo> Riddell: incomplete X drivers, would you be able to test a patch ?
<mvo> Riddell: I have something to detect that, but I have no hardware that triggers it
<Riddell> mvo: sure
<Riddell> mvo: but curious since my x drivers were working last week
<mvo> iwj:  I looked into your acpi build-dep problem and I think we should file a bug against acpi because apt-get build-dep acpi will not get the right b-d. it could be argued that the bug is in apt here that it does not pick a package that provides the given virtual package
<Riddell> mvo: also I reported https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/126521
<ubotu> Launchpad bug 126521 in compiz "compiz should fall back to kwin" [Undecided,New] 
<mvo> Riddell: oh, of course - we will fix that
<Riddell> :)
<mvo> Riddell: could you please apply http://paste.ubuntu-nl.org/30201/ to /usr/bin/compiz and see if it detect it right?
<mvo> Riddell: I have seen this falure when multiple X servers were runing
<Tonio_> Riddell: have you seen that amarok ftbfs issue ?
<Tonio_> Riddell: very strange...
<iwj> mvo: I've posted to u-d.
<mvo> iwj: thanks
<iwj> OMG WTF autopkgtest has sent me rather too much mail.
<mvo> move them to =spam ;)
<Spads> haha
<Spads> iwj: good to know that works then
<iwj> It seems to have got hung up on a couple of packages which broke and keeps trying them too often.  I need to fix the package-to-test-chooser, evidently.
<Tonio_> StevenK: the amarok build issue is due to some recent changes to kdelibs
<StevenK> Ahh.
<StevenK> Tonio_: I'm happy to fix amarok to build and upload it, if you like.
<Tonio_> StevenK: amarok doesn't have to be fix
<StevenK> Tonio_: I'm just unsure of what the source changes need to be.
<StevenK> Ahhh. kdelibs does. Neat.
<Tonio_> StevenK: the patch is not good, redefines kdialogbase class, which potentially causes lots of issues
* mvo needs to find a power plug
<StevenK> Tonio_: If it's backing out one patch from kdelibs, I can do that and upload if you like.
<Tonio_> StevenK: I'm doing it right now :)
<StevenK> Tonio_: Ah, excellent. I suspect Hobbsee can be bribed into accepting it. :-)
<Tonio_> yup
<StevenK> Tonio_: Oh, and I can answer the question you asked in the changelog of kdelibs 4:3.5.7-1ubuntu6, too ... :-)
<Riddell> StevenK: what question was that?
<Tonio_> StevenK: why it only failed to build on i386 ? :)
<Tonio_> StevenK: yeah I didn't understood that, due to the issue, that should fail on every arch I guess :)
<StevenK> Tonio_: Right.
<Tonio_> StevenK: I'd be glad to have an explanation
<StevenK> Tonio_: The reason it only failed on i386 is because only the i386 builds arch: all packages, and that's where the error occured.
<StevenK> i386 buildds builds
<Tonio_> StevenK: ahhhhhhhhhhh, that's clear now :)
<Tonio_> StevenK: kdelibs uploaded
<StevenK> Tonio_: Great, thanks.
<Tonio_> StevenK: once in the repos, you can reupload amarok for rebuild
<Tonio_> StevenK: or ask for rebuild to be launched....
<StevenK> Tonio_: It failed to build, I was planning on begging for a give-back.
<Tonio_> StevenK: is that possible to rebuild without reuploading ?
<Tonio_> pitti, Hobbsee: can you please approve kdelibs upload ?
<StevenK> Tonio_: If it failed on all arches, yes.
<Tonio_> pitti, Hobbsee: there is an issue for a recent patch that may cause lots of kdeapps to ftbfs (amarok as an exemple failed recently)
<StevenK> Tonio_: You may need to explain the changes/show a debdiff to get it approved.
<Tonio_> StevenK: Hobbsee uploaded the patch, so she is aware of the potential problems with it :)
<Tonio_> StevenK: it might not be a surprise for her that we have to drop it
<StevenK> Ahhh
<Tonio_> Hobbsee: fyi, that's the kdesudo patch , redefining the KDialogbase class causes kde apps that call for it (aka, about all of them) to ftbfs, due to ambiguous calling
<Tonio_> Hobbsee: I'll ping _StefanS_ on that point, there should be another way to do that, like writing another class that inherits KDialogbase....
<mantiena-baltix> Hi all
<cjwatson> would anyone scream if I changed our nss-mdns package to take mdns4 off the end?
<cjwatson> (of hosts: in nsswitch.conf)
* ogra wouldnt ... but then i dont use it :)
<ogra> (yet)
<cjwatson> the disadvantage is that mDNS resolution would no longer work outside the .local and 169.254.0.0/16 ranges; the advantage is that normal forward and reverse lookups wouldn't have a 5-second penalty timeout added to them
<cjwatson> mDNS would still work fine within .local and 169.254.0.0/16, due to mdns4_minimal
<cjwatson> see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=414569
<ubotu> Debian bug 414569 in nss-mdns "avahi-daemon: delay on resolving IP addresses when mdns is specified in /etc/nsswitch.conf" [Normal,Open] 
<cjwatson> and bug
<ogra> is there any use for mdns beyond local stuff ?
<cjwatson> bug 94940
<ubotu> Launchpad bug 94940 in nss-mdns "mdns listed in nsswitch.conf causes excessive time  for dns lookups" [Medium,Incomplete]  https://launchpad.net/bugs/94940
<cjwatson> ogra: apparently some people care, I just don't know how many
<fabbione> cjwatson: ++
<cjwatson> which is why I'm asking
* ogra wouldnt want to connect to all rhythmboxes over the world ...
<cjwatson> ogra: ... you wouldn't anyway.
<cjwatson> please, I'm looking for serious responses from people who actually use mDNS
<ogra> well, i'd see them, no ?
* ogra keeps quiet then
<Mithrandir> cjwatson: what is the question?
<cjwatson> Mithrandir: whether anyone needs mDNS resolution outside the .local and 169.254.0.0/16, and if so what for
<cjwatson> s/,/ ranges,/
<persia> I don't know if I'm using mDNS, but I find it nice that services are autodiscovered between my workstation and the local Mac OS X machine, even though they are on a reserved private network, rather than 169.254.0.0/16.
<Mithrandir> persia: and you don't have a link-local address on both hosts too?
<persia> Mithrandir: Hmm.  Maybe I do.
<persia> Mithrandir: At least not on my workstation, so I'd say no.
<broonie> Mithrandir: You're not supposed to allocate IPv4 LL addresses if you have an IP address via other methods.
<Mithrandir> broonie: ah, ok.
<iwj> cjwatson: You shouldn't do mdns outside the expected ranges because it's a security problem.
<Mithrandir> iwj: why is it a security problem?
<iwj> It makes it much easier for people to pretend to be (say) google.
<Mithrandir> dns isn't secure anyway.
<elmo> err
<Mithrandir> (unles you're using dnssec and all that)
<elmo> Mithrandir: that's a deeply unhelpful answer
<Mithrandir> unless, even
<iwj> True, but this provides an explicit mechanism for local overrides by link-attached peers.
<iwj> Without mdns a machine on the same link has to play games with MAC addresses or arp or something.
<iwj> (Which depending on the network configuration can be very difficult, and is certainly harder than configuring your mdns responder to pretend to be google.)
<Mithrandir> I thought it was only looking up .local using mdns anyway?
<cjwatson> Mithrandir: that's what mdns4_minimal does. mdns4 tries everything as a fallback.
<cjwatson> mdns4_minimal resolves in .local and 169.254.0.0/16; mdns4 tries to resolve everywhere.
<cjwatson> so I'm thinking about the example of conferences, where things currently work pretty nicely; people on random wireless networks can discover services that other people advertise with avahi
<Mithrandir> I'm probably dense, but I don't really see a use case for mdns4, then.
<cjwatson> said people won't have IPv4LL addresses (169.254.0.0/16), for the reason broonie points out
<cjwatson> so it seems to me that the effect of removing mdns4 will be that forward lookups of services continue to work fine, but reverse lookups will be disabled
<cjwatson> does that make sense?
<Mithrandir> that doesn't seem to be a big cost?
<cjwatson> I think it's OK, but I don't want to Just Do It
<Mithrandir> I can find Lennart and see if he screams at me.
<Mithrandir> (Lennart as in avahi upstream)
<cjwatson> he's certainly aware of the issue because he's commented on mailing list posts about it and the like
<cjwatson> I would like his feedback on the practical effects
<Mithrandir> yeah, I could just ask him to jump in here
<cjwatson> the particular thing I care about is getting rid of the timeout for ssh connections
<cjwatson> Mithrandir: that'd be good, thanks; can you show him the scrollback so we don't have to recap?
<Mithrandir> sure
<Mithrandir> I'm in a talk right now, but I'll try to find him once this is done
<cjwatson> ok
<pitti> StevenK: what did you want to have given-back?
<pitti> Tonio_: I'll look at kdelibs
<aquo> the more i think about it, the more i hate beryl/compiz
<Mithrandir> aquo: then I suggest you use another WM.
<aquo> all the hype about eyecandy is distracting the developers ...
<aquo> i like the eyecandy, but i would more like if i could synchronize evolution and pidgin
<Ng> isn't there an evolution plugin for pidgin?
<aquo> it is broken and not supported anymore
<aquo> i am locking forward to http://www.opensync.org/
<pitti> Tonio_: no kdelibs in unapproved
<Tonio_> pitti: looking my emails then ? ;)
<Riddell> pitti: I approved it
<pitti> ah
<Tonio_> pitti: is there a specific issue in the packaging then ?
<pitti> Tonio_: no email from you either
<Tonio_> pitti: in fact I was suspecting Hobbsee to look at that, and has we previously discussed the risk of that upload, I suspected no email would be reuiqred
<Tonio_> pitti: need an email now ?
<pitti> Tonio_: no, it's approved already
<Tonio_> oki
<tkamppeter> Some Python packaging experts here?
<doko> pitti: please accept libiodbc2 and libdv, dropping the gtk1.2 b-d's. please accept libdv-bin and iodbc in source NEW, and move to universe
<pitti> doko: just saw them, thanks!
<doko> then demote libglib1.2 and libgtk1.2 ...
<pitti> \o/
<doko> tkamppeter: ?
<TheMuso> c
<pitti> tkamppeter: btw, were you able to reproduce the 'a million dangling FIFO' cups bug?
<tkamppeter> I want to simplify the packaging of HPLIP (mainly written in Python). It has very ugly patches in the .diff.gz file which I want to get rid of.
<tkamppeter> pitti, I never succeeded to reproduce that bug 112803, I always printed without problems and always on Feisty and the newest Gutsy.
<ubotu> Launchpad bug 112803 in cupsys "MASTER [Feisty]  cupsd leaking file descriptors (was: Multiple jobs are not printed)" [Unknown,Fix released]  https://launchpad.net/bugs/112803
<pitti> tkamppeter: same here; I tried for an hour yesterday with different scenarios
<stgraber> sorry, I've to leave you till 15:30 UTC, in case you want to put isos on the tracker, those are the people with admin rights : mathiaz, Hobbsee, pitti, pochu and heno
<pitti> stgraber: thanks
<StevenK> pitti: Ah. amarok, but not until the new kdelibs binaries are published.
<tkamppeter> One of the ugly patches are changes in the Makefile to distribute the files which upstream puts into /usr/share/hplip into /usr/share/hplip and /usr/lib/hplip.
<pitti> doko: libdv-bin changelog looks weird; first "*" does not have text; maybe you can fix this and reupload?
<doko> pitti: please accept binutils, fixing a build failure with GCC-4.2, no other code changes
<doko> pitti: looking ...
<tkamppeter> I think upstream is right putting the .py files into /usr/share/hplip, as these files are platform-independent.
<pitti> doko: do we need binutils for tribe3?
<doko> pitti: no, but for lpia
<tkamppeter> The Debian maintainer Henrique Moraes Holschuh has moved the .py files to /usr/lib/hplip. WDYT?
<cjwatson> how long ago did he do this?
<tkamppeter> cjwatson, I have to look into the ChangeLog.
<doko> tkamppeter: hmm, should be ok. probably he wants to avoid having the files unavailable on package upgrades
<cjwatson> it used to be general practice to ship python modules in /usr/lib because it wasn't clear whether it was safe to have .pyc files in /usr/share, I think
<cjwatson> at least there certainly used to be a lot of confusion about it
<doko> well, afaicr there were .so and .py files, which sould be put into the same directory
<cjwatson> ah, there was the same confusion about perl extensions
<tkamppeter> cjwatson, HMH did this from HPLIP 1.6 on, May 2004.
<cjwatson> some people interpreted policy over-literally and thought that you had to put every single architecture-independent file into /usr/share, whereas actually it was better for .pm and .so to be kept together
<tkamppeter> I have checked the newest HPLIP, installed from upstream source and it has not one .so in its /usr/share/hplip. It uses directories like /usr/lib/python-support for its .so files.
<doko> too hot, my notebook turned off for the third time today ...
<tkamppeter> find /usr -name "*.py*" -print reveals also that lots of .py go into /usr/share,
<tkamppeter> The current HPLIP package is a maintaining nightmare and therefore I want to get as close to upstream as possible, so that one can quickly update it. HP issues a new version every two months, but HMH remakes his patch nightmare perhaps twice a year.
<cjwatson> (have you discussed the problem with hmh?)
<cjwatson> and I would suggest not using the term "patch nightmare" when talking with him; no point being needlessly antagonistic
<tkamppeter> Yes, I have started, but he never tells me what exactly he all changed by hs patches. I have looked now and found that it is the following:
<tkamppeter> - source code cosmetics
<tkamppeter> - .py --> /usr/lib
<tkamppeter> - recompile .ui to the appropriate .py on each build
<tkamppeter> I think only the latter makes sense, so that packagers can patch the .ui files if needed.
<iwj> I think I'm going to have to automate the autopkgtest bug submission.
<tkamppeter> I did not use "patch nightmare" in the mails to him.
<doko> tkamppeter: maybe look at his commit messages in his cvs repo
<pitti> Hobbsee: ok to accept nessus-core with the only change being the dropping of libglib1.2-dev build dependency? (it's not used); it does not affect CD builds
<Hobbsee> pitti: ok
<pitti> soren: I updated #119908
<mantiena-baltix> pitti: are you one of network-manager's maintainers ?
<pitti> mantiena-baltix: not really; asac and Tonio_ come closest to that status
<pitti> yay, compiz is installable again *hugs*
<Hobbsee> yay!
<Pici> yay!
* pitti dist-upgrades and tests
<Hobbsee> works fien in kubuntu-land, although still shows up on gutsy_problems
<mantiena-baltix> asac, Tonio_ :  are you online ? I wanna to backport network-manager from gutsy to feisty ? What you think about this idea ?
<asac> mantiena-baltix: not good :)
<mantiena-baltix> :( why ?
<asac> mantiena-baltix: i think it needs new wpasupplicant as well then ... so.
<Hobbsee> ew
<Jaghound> latest gutsy seems to have initramfs breakage
<Jaghound> I got dropped into busybox, as dir /dev/disk/by-uuid did not exists
<asac> mantiena-baltix: for me 0.6.5 is more broken when i run it on feisty than on gutsy
<Jaghound> other three (label etc.) where there
<Jaghound> sounds like udev breakage
<Jaghound> luckily root=/dev/hda1 worked, and after boot the dir was there
<asac> mantiena-baltix: do you have wireless setup to test?
<soren> pitti: Thanks.
<ScottK> Hobbsee: Thanks for the pinentry upload.
<Hobbsee> ScottK: no problem
<ScottK> Hobbsee: Have you got a moment for a possible bug in LP?
<Hobbsee> ScottK: ish, yes.
<pitti> dholbach: erk, latest compiz still hangs at session start, even worse than before
<pitti> dholbach: before I at least got a panel and desktop, now just a blank screen
<ScottK> When you touched Bug #85194, you didn't actually mark the Baltix task invalid did you?
<ubotu> Launchpad bug 85194 in samba "samba's package postinst script shouldn't return an error if samba daemon can't be started (e.g. if smb.conf file is incorrect or is removed)" [Medium,Confirmed]  https://launchpad.net/bugs/85194
<Hobbsee> as in, i'm here at the moment, and i have time.
<Hobbsee> um, i might have
<Hobbsee> i think i did that on one of the bugs
* Hobbsee is....beyond tired here, though
<ScottK> OK.  Then nevermind.  I'd seen them whine about their bugs being closed incorrectly before and was thinking it might be an LP problem, but if you did it..
<ScottK> Or might have done it...
<ScottK> I'm not going to sweat it.  Thanks.
<Hobbsee> no, i think i did do it
<Hobbsee> people randomly file things under baltix sometimes - wasnt aware that baltix contained samba, i think
<mantiena-baltix> asac: No, I don't have wireless :( Problem is. that static IP configuration doesn't work with NM from feisty, look at https://bugs.launchpad.net/baltix/+bug/5364/comments/22
<ubotu> Launchpad bug 5364 in network-manager "Can't use static ip address with network-manager (and thus no VPN connections menu for static users)" [Wishlist,Confirmed] 
<pitti> erk, thank you, dear aiglx, for killing my box on VT switches
<StevenK> pitti: That's a feature.
<mantiena-baltix> maybe there are another way to solve important problem, described in https://bugs.launchpad.net/baltix/+bug/5364/comments/22 ? Users never understand. why they have manually to deactivate and, later, activate again network interface after they setup static IP configuration :(
<ubotu> Launchpad bug 5364 in network-manager "Can't use static ip address with network-manager (and thus no VPN connections menu for static users)" [Wishlist,Confirmed] 
<asac> mantiena-baltix: so is this fixed for you in 0.6.5 ?
<pitti> dholbach: ok, by and large the new compiz seems to work better
<mantiena-baltix> asac: I don't know (I don't have gutsy, I wanna backport to feisty and test ;) ) It seems this problem exists only in Ubuntu's network-manager, I think it's related to bug #61089
<ubotu> Launchpad bug 61089 in network-manager "NM should notice changes to /etc/network/interfaces automatically" [High,In progress]  https://launchpad.net/bugs/61089
<dholbach> pitti: that was my impression too
<pitti> dholbach: this entire thing is still very brittle, though :(
<dholbach> pitti: yeah :-/
<dholbach> I hope we get the biggest blockers resolved quickly
<dholbach> go amaranth, mvo, seb128, go compiz team! :)
* Hobbsee hugs dholbach and all the others
<dholbach> Hobbsee: I'm not part of that team :)
<Hobbsee> dholbach: oh well, no hug for you then.
<dholbach> I try to become a happy user though :)
<Nafallo> lol
<Hobbsee> ;)
<pitti> fabbione: do you happen to know the current status of bug 105936?
<ubotu> Launchpad bug 105936 in lvm2 "snapshot creation failure race "in use: not deactivating"" [High,Confirmed]  https://launchpad.net/bugs/105936
<asac> mantiena-baltix: that bug should be fixed in gutsy
<mantiena-baltix> asac, pitti : maybe better solution would be to use patch from bug #61089 agains feisty's network-manager instead of trying to backport network-manager from gusty ?
<ubotu> Launchpad bug 61089 in network-manager "NM should notice changes to /etc/network/interfaces automatically" [High,In progress]  https://launchpad.net/bugs/61089
<asac> mantiena-baltix: the gutsy nm should build without problems ... however I had problems with wireless and wpasupplicant
<pitti> soren: your latest samba upload doesn't happen to fix bug 85194?
<ubotu> Launchpad bug 85194 in samba "samba's package postinst script shouldn't return an error if samba daemon can't be started (e.g. if smb.conf file is incorrect or is removed)" [Medium,Confirmed]  https://launchpad.net/bugs/85194
<soren> pitti: I can test it. Hang on.
<mantiena-baltix> We are making feisty-based distro for Lithuanian schools and this bug couses big problems for schools computer's admins (they have almost no experience with Linux desktops or servers, so, every problem is big headache)
<soren> pitti: Ungh... My smbd segfaults right now.
* Hobbsee wonders why it's based on feisty
<Kmos> mantiena-baltix: it's more based in debian
<soren> O.O
<mantiena-baltix> Kmos: what is more based in debian ?
<soren> execve("/usr/sbin/smbd", ["/usr/sbin/smbd"] , [/* 33 vars */] ) = -1 EFAULT (Bad address)
<soren> That's interesting.
<Kmos> mantiena-baltix: ubuntu
<mantiena-baltix> Kmos: I know this, but don't understand why you are telling this ?
<Kmos> mantiena-baltix: try #ubuntu-help
<Kmos> mantiena-baltix: forget
<mantiena-baltix> Kmos: why ? I don't need help in Ubuntu, I wanna fix Ubuntu bug
<Kmos> mantiena-baltix: i read it wrong.. i need to lunch
<Kmos> lol
<mantiena-baltix> Kmos: ;)
<StevenK> Ah ha. libdv-bin turns up in NBS, but it really isn't.
<aquo> mantiena-baltix: network manager is very frustrating for me
<soren> pitti: bug 85194 still exists.
<ubotu> Launchpad bug 85194 in samba "samba's package postinst script shouldn't return an error if samba daemon can't be started (e.g. if smb.conf file is incorrect or is removed)" [Medium,Confirmed]  https://launchpad.net/bugs/85194
<aquo> mantiena-baltix: i spent the whole last afternoon to find a solution https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/50214
<ubotu> Launchpad bug 50214 in network-manager "can't connect to hidden network" [Undecided,Confirmed] 
<aquo> i wrote an email to network-manager-list ...
<mantiena-baltix> aquo: and what are the results of your email ?
<aquo> non at the moment, it hasn't been forwarded to the list
<pitti> soren, fabbione: sorry, network outage, I lost your replies
<soren> pitti: bug 85194 still exists.
<ubotu> Launchpad bug 85194 in samba "samba's package postinst script shouldn't return an error if samba daemon can't be started (e.g. if smb.conf file is incorrect or is removed)" [Medium,Confirmed]  https://launchpad.net/bugs/85194
<pitti> soren: can you please have a look at it?
<pitti> soren: it doesn't sound particularly critical to me
<soren> pitti: How urgent is it? I was about to grab some lunch. I'm starving.
<aquo> mantiena-baltix: are you Witold Krakowski?
<Hobbsee> i thought i shoved that later...
<Hobbsee> (that samba bug)
<pitti> soren: it sounds like tribe-4
<soren> pitti: It should be just a matter of running testparm before killing samba or something to that effect.
<soren> pitti: Right-o. I'll assign it to myself.
<soren> pitti: Did you lose your connection before my execve weirdness thing?
<pitti> soren: thanks
<pitti> soren: no, I still got that
<soren> pitti: Alright. Man, that's weird.
<mantiena-baltix> aquo: no, I'm not polish ;)
<aquo> mantiena-baltix: this guy is a little bit ridiculous, he is telling he has a fix, but he doesn't have one
<mantiena-baltix> aquo: hehe, I'm telling, that I don't have a fix ;)
<asac> i am pretty sure that he is a troll ... at least for this bug
<mantiena-baltix> asac: what you think, maybe better solution would be to use patch from bug #61089 agains feisty's network-manager instead of trying to backport network-manager from gusty ?
<ubotu> Launchpad bug 61089 in network-manager "NM should notice changes to /etc/network/interfaces automatically" [High,In progress]  https://launchpad.net/bugs/61089
<Riddell> is there a way to have an optional build-depends?  I want to be able to backport the package to feisty were the build-dep doesn't exist
<asac> mantiena-baltix: you can do ... afaik there are no known regressions from that patch yet
<infinity> Riddell: Only in really hackish ways that I'd prefer you don't use.
<Riddell> mm, thought as much
<cjwatson> Riddell: you can upload source-change backports yourself though
<Hobbsee> infinity: can i be curious to what these are?
<Hobbsee> infinity: or you wont tell me, out of fear of impending evil?
<ScottK> Speaking of source-change backports, would someone mind releasing clamav 0.88.7-1ubuntu1~dapper from the wilderness?
<infinity> Hobbsee: It involves bogus build-deps, essentially.
<soren> Hobbsee: I suppose one could start by uploading an empty package by the same name as the build-dep.
<pitti> soren: nah; b-dep on "foo || coreutils" or so
<infinity> Hobbsee: "Build-Depends: package-in-gutsy | package-in-feisty-that-i-don't-actually-use"
<soren> pitti: That's valid?
<Hobbsee> ahh, right, yes.
<soren> pitti: Ah, yes, I suppose it is.
<infinity> pitti: Can't be coreutils (or anything that's Build-Essential)
<pitti> soren: not actually coreutils, of course
<Hobbsee> infinity: yeah, that's....
<pitti> soren: a game or so
<mantiena-baltix> asac: no known regressions means that nobody has tested that patch ? :)
<Hobbsee> could just build-dep on gutsypackage | debhelper or something, then
<infinity> The trick is that it has to be a package that wouldn't normally be there during the build, otherwise it'd be satisfied in gutsy and you won't get your real build-dep.
<infinity> Anyhow, it's evil, and if I notice anyone doing it, I'll remove limbs at the next conference.
<Hobbsee> oh, point
<StevenK> Then you get "Why does package <x> Build-Depend on crack-attack?!"
<cjwatson> using one of your other real build-dependencies would be marginally cleaner
<infinity> Yeah, moon-buggy or hello would be my two choices.
<infinity> But there you go.
<cjwatson> (I think that would work?)
<infinity> cjwatson: Depending on parsing order, that may or may not work.
<Hobbsee> infinity: well, you werent in sevilla i dont think, so i could try my luck again there, at avoiding being killed.
<asac> mantiena-baltix: its in gutsy for just a few days ... so we cannot really tell atm
<infinity> Hobbsee: I'll be sure to show up to the next UDS if I have limbs to remove. :)
<Hobbsee> infinity: haha
<mantiena-baltix> asac: hehe, nice to hear that ;)
<cjwatson> infinity: yeah, a bit too unstable
<StevenK> C'mon buildds, pedal faster.
* Hobbsee notes that she cant really blend in with the crowd, either.  dammit.
* soren goes to lunch.
<infinity> Hobbsee: Get a nice hat.  I can't find Colin anymore when he wears his.
<StevenK> I suspect kdelibs will neatly miss this publisher run.
<mantiena-baltix> asac: that patch applies without any problems agains n-m 0.6.5 from gutsy
<Hobbsee> uh.....
<pitti> StevenK: publisher is on manual
<mantiena-baltix> ?
<StevenK> Ah ha. A clue
<asac> mantiena-baltix: its in gutsy already ... in debian/patches/
<StevenK> pitti: How much sweet talking do you need to kick it off? (Not yet, mind you. :-)
<pitti> StevenK: it's currently running; you need to tell me what you need urgently
<pitti> StevenK: when this one finishes, my aim is to get d-i built, and then published
<pitti> StevenK: kdelibs sounds like it'll need an hour, though
<StevenK> pitti: Ah, I'm being impatient about kdelibs, which hasn't even finished building.
<asac> mantiena-baltix: iirc, its debian/patches/23_nm-monitor-eni.diff
<pitti> StevenK: it should need less than 15 minutes
<pitti> StevenK: (remaining)
<pitti> StevenK: I'll watch out for it and let it complete before I kick another one
<StevenK> pitti: Ahh, thanks
<mantiena-baltix> asac: thank you  very much, I hope Lithuanian Linux users will be happy :)
<pitti> dholbach: argh, argh
<persia> xxxxx1: bug 126340 is still "In Progress".  Are you still working on it, or is it ready for sponsorship?
<ubotu> Launchpad bug 126340 in ecryptfs-utils "[needs sponsor]  please update ecryptfs-utils" [Wishlist,In progress]  https://launchpad.net/bugs/126340
<pitti> dholbach: compiz recently started to depend on compiz-fusion-plugins-extra
<pitti> dholbach: can you revert this? that's in universe
<dholbach> pitti: ask mvo about that
<xxxxx1> persia, ready.
<dholbach> grrrrrrrr
* persia apologises for the noise
<dholbach> pitti: I merely fixed it to be installable at all
<xxxxx1> persia, status updated ;)
<dholbach> pitti: I can drop the depends, yes
<pitti> dholbach: hmm; still b0rked, though; I try phoning him
<dholbach> no no
<dholbach> that's fine
<dholbach> I'll just drop it
<Hobbsee> pitti: ahh, so *that*'s why it's in gutsy_problems, but not here
<dholbach>   [ Michael Vogt ] 
<dholbach>   * debian/control:
<dholbach>     - make compiz depend on compiz-fusion-plugins-extra
<StevenK> Neat. amd64 wins for kdelibs
<StevenK> This may be a stupid question, but is there an MIR for compiz-fusion-plugins-extra?
<pitti> dholbach: I got seb and mvo eventually; we can drop it
<pitti> Michael and Seb said that we do not need it
<dholbach> pitti: ok, doing that
* pitti hugs dholbach 
<dholbach> uploaded
<pitti> yay
* dholbach mails mvo to merge from http://bazaar.launchpad.net/~dholbach/compiz/fixes
<dholbach> mvo: please merge from http://bazaar.launchpad.net/~dholbach/compiz/fixes
<StevenK> Dear me, not even a hello.
<StevenK> :-P
<dholbach> pitti: how do I do the apport magic to add Package: etc to the crash report again?
<dholbach> hi mvo :)
<pitti> dholbach: just run it through the UI
* Hobbsee hugs mvo in greeting
<mvo> dholbach: thanks
<dholbach> pitti: how do I do that?
<pitti> dholbach: /usr/share/apport/apport-gtk -c /path/to/crash/file
* dholbach forgot again
<dholbach> ah super
<pitti> dholbach: or use apport-cli instead
<pitti> dholbach: or just touch the /var/crash/ file, then it'll get picked up by update-notifier
<dholbach> pitti: rock and roll - thanks!
<cliebow_> anyone know about pcmcia support in ltsp initramfs?
* mvo hugs Hobbsee back
<Hobbsee> :)
<Hobbsee> well, ubuntu installer doesnt appear to blow up
<Hobbsee> under a VM, anyway
<mvo> Riddell: did my patch help?
<dholbach> mvo: does gnome-appearance-properties crash for you?
<pitti> dholbach: for a lot of people
<dholbach> it seems to be our appearance patch that breaks it
<dholbach> I'm looking into it
<pitti> dholbach: if there's a fix soon, I'd stall the candidate CD builds a bit; if not, I don't call it world-breaking, though
<Riddell> mvo: didn't seem to
<dholbach> I can't promise anything, I just stumbled over http://bugzilla.gnome.org/show_bug.cgi?id=457054
<ubotu> Gnome bug 457054 in Appearance "gnome-appearance-setting crashes during load" [Critical,Needinfo] 
<mvo> Riddell: hm, bad
<dholbach> our patch is quite big, so it might take a while
<pitti> dholbach: bug 125900 is the same, I think
<ubotu> Launchpad bug 125900 in gnome-control-center "gnome-appearance-properties crashed with SIGSEGV in style_init()" [Undecided,Confirmed]  https://launchpad.net/bugs/125900
<Riddell> mvo: http://paste.ubuntu-nl.org/30216/
<pitti> dholbach: but with apport and retrace love
<seb128> re
* pitti hugs the Sebmaster
<seb128> ,oo
* seb128 hugs pitti
<dholbach> pitti: that's a different one
<pitti> dholbach: hm, it's the crash that I see
<Hobbsee> holy cow, this cant be right
<Hobbsee> mvo: can i configure compiz under kde somehow?
<dholbach> pitti: http://daniel.holba.ch/temp/crash is the crash I see
<infinity> Hobbsee: Not so much.  KDE users run Beryl for that reason, generally.
<pitti> dholbach: right, style_init()
<Hobbsee> infinity: beryl dies on kde
<StevenK> And Beryl has been killed in Gutsy.
<infinity> StevenK: Fun. :)
<StevenK> Or at least seriously neutered
<pitti> dholbach: erk, the retrace looks quite broken on 125900
* seb128 kicks the GUADEC network
* StevenK watches the GUADEC network kick seb128 back, off IRC
* Kmos kills GUADEC network
<Kmos> :)
<StevenK> Heh. Ooops.
<pitti> evand: what's the latest word on bug 122645?
<ubotu> Launchpad bug 122645 in ubiquity "manual partitioning hangs indefinitely" [High,Confirmed]  https://launchpad.net/bugs/122645
* evand notes the one downside to /ignore JOINS PARTS
<evand> pitti: still working on it.  I may put in a temporary fix while I track it down.
<pitti> evand: oh, you have one?
<pitti> evand: I was hoping to build candiate images in a few hours
<pitti> evand: temporary fix> something like s/gksu/sudo/ in the .desktop? :-)
<Kmos> i'm having this bug 70880 at my acer laptop with gutsy
<ubotu> Launchpad bug 70880 in linux-source-2.6.19 "PCI: Bus #04 (-#07) is hidden behind transparent bridge" [Undecided,Invalid]  https://launchpad.net/bugs/70880
<evand> pitti: just redirecting stderr seems to fix it
<evand> don't ask me why
<pitti> evand: weird
<pitti> evand: I would really like to avoid releasing T3 with that bug
<pitti> evand: maybe we can upload the workaround now, and if you have something better, we can still consider it?
<evand> fair enough
<pitti> evand: thank you soooo much for finding a workaround! *hug*
<evand> I'll do some more testing and then push out 1.5.6
<evand> quickly
<Kmos> BenC: ping
<pitti> evand: just for publisher running, do you need more like 10 minutes or like an hour?
<Hobbsee> oh yay, evand!
<BenC> Kmos: pong
<pitti> StevenK: kdelibs has finished building, it'll get published soon
<evand> pitti: probably the hour as it's going to take me at least a few minutes to verify that this does in fact fix things, at least for me
<evand> Hobbsee: indeed!
<Riddell> Hobbsee: compiz-kde should work
<pitti> evand: that's fine, then I'll start a publisher in between; thanks
<Hobbsee> Riddell: it mostly works
<Hobbsee> Riddell: it hasnt blown up as spectacularly this time as it usually does
<Riddell> Hobbsee: your windows wobbling?
<cjwatson> evand: redirecting stderr is fine with me. Commit the patch and I'll check it?
<pitti> BenC: is bug 119052 painful enough to stall the tribe? it seems quite hardware specific?
<ubotu> Launchpad bug 119052 in initramfs-tools "[gutsy] ibm-acpi -> now thinkpad_acpi possibly causing problems" [High,Confirmed]  https://launchpad.net/bugs/119052
<evand> cjwatson: will do
<Hobbsee> Riddell: a little.  the zoom is cool
<Hobbsee> Riddell: i cant actually get to teh config thingy to see what's running
<StevenK> pitti: Woot, thanks
<StevenK> pitti: It's still marked as 'Currently building on ia64'
<pitti> StevenK: right, but I couldn't care less RM-wise, since we don't have ia64 CDs anyway
<StevenK> pitti: Yeah, but I'd rather amarok built everywhere. :-)
<pitti> StevenK: right, it'll finish eventually, but it's not critical to shove it into the archive ASAP
* StevenK nods
<BenC> pitti: no, it isn't that serious
<BenC> pitti: but we can fix it for tribe-3 for sure
<Hobbsee> BenC: er, 4?
<StevenK> pitti: Can you give-back amarok when the publisher completes? (If that's soon enough for the buildds to see the new kdelibs)
<BenC> Hobbsee: it's a one-liner rename in initramfs-tools
<BenC> if we can get it through the freeze, it would be appreciated
<Hobbsee> BenC: oh.  for some reason, i thought pitti's line was said by you.
<pitti> BenC: I'd appreciate that
<BenC> Hobbsee: np
<BenC> pitti: doing it now
<pitti> BenC: breaking fan control does sound somewhat serious
<pitti> BenC: rock
<doko> pitti: please accept python2.4 and python2.5 into unstable, fixing a reference counting problem in Python/sysmodule.c
<doko> (introduced by me)
<pitti> doko: is there a bug for it?
<pitti> doko: I don't really want to accept big stuff that'll affect the CD if it doesn't fix tribe-3 bugs
<doko> pitti: #124549
<pitti> Hobbsee: ^ oh, you are still awake; your call, too :)
<Hobbsee> pitti: yeah, i'm still awake, insanely enough
<pitti> doko: python2.4 sounds harmless
<Hobbsee> bug 124549
<ubotu> Launchpad bug 124549 in python2.4 "Calling interpreter more than once is broken" [Low,Confirmed]  https://launchpad.net/bugs/124549
<Hobbsee> pitti: i'll agree with you there - wouldnt really want to touch python2.5, with so much stuff depending on it.  py2.4 looks fine
<pitti> doko: TBH I'd rather leave python2.5 alone. 150000 lines of debdiff ...
<BenC> pitti: that was already fixed by an acpi-support upload (bug 119052)
<ubotu> Launchpad bug 119052 in initramfs-tools "[gutsy] ibm-acpi -> now thinkpad_acpi possibly causing problems" [High,Fix released]  https://launchpad.net/bugs/119052
<BenC> pitti: so no exception needed
<pitti> BenC: ah, cool, so it can be closed?
<BenC> pitti: updated bug
<pitti> BenC: thanks
<Hobbsee> pitti: where is said debdiff for python2.5?
<pitti> Hobbsee: I didn't put it anywhere, shall I?
<Hobbsee> pitti: well, for the sheer hell of appreciating how insane it is, that'd be cool
<pitti> Hobbsee: http://people.ubuntu.com/~pitti/tmp/python2.5.debdiff (8 MB!)
<dholbach> Kmos: I'd prefer if mvo took care of https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/109765
<ubotu> Launchpad bug 109765 in update-manager "run apt-get autoclean after upgrade" [Low,Confirmed] 
<Kmos> dholbach: ok
<dholbach> Kmos: I'm busy with quite a bunch of other things without diving head-first into apt and update-manager at the moment, sorry
<Kmos> np
<Kmos> i understand
<dholbach> ok good :)
<Kmos> i'm testing a bug at my laptop about kernel at gutsy
<BenC> dholbach: do you know of a reason that amitk cannot assign importance to a kernel bug?
<Hobbsee> pitti: yeah..that's...kinda evil
<Hobbsee> BenC: launchpad bug.
<Hobbsee> BenC: actually, it's by design
<Hobbsee> BenC: is he in -qa?
<dholbach> BenC: if he's in ubuntu-qa he should be able to
<dholbach> BenC: if not, ask bdmurray
<BenC> should he be in ubuntu-qa?
<BenC> bdmurray: ping
<Kmos> BenC: to change importance of bugs, yes.
<Hobbsee> BenC: bug contacts, and members of but contact teams cant actually set the importance of bugs, nor the triaged state.
<BenC> ok
<dholbach> BenC: so either bdmurray or heno
<Hobbsee> BenC: which is illogical, i know
* Hobbsee ponders asking for -qa admin rights, or something
<BenC> actually, it makes sense...I hate bug submitters setting "critical" on every little bug they submit :)
<Hobbsee> BenC: that's long gone :)
<dholbach> yeah, the importance is a tool for developers who are going to fix the bug to organize their workload - or it should be
<Kmos> Hobbsee: do it :) sent mail to bdmurray
* Hobbsee will just poke him when he's next online.
<Kmos> https://wiki.ubuntu.com/UbuntuQA
<Hobbsee> wow, i never had to do that :)
* Hobbsee cheers at coming in bfeore the big structure got put in place
<doko> pitti: your call, but it's a regenerated uuencoded tarball
<superm1_> BenC, you might want to add some comments to bug 118708.  Hobbsee and I already commented on it
<ubotu> Launchpad bug 118708 in malone "Package maintainers can't set priorities of their own packages" [Undecided,Confirmed]  https://launchpad.net/bugs/118708
<dholbach> pitti, soren: gnome-appearance-properties crash fixed
<pitti> dholbach: rock!
<dholbach> it involved re-basing a patch, making sense of it and fixing a part that made it ftbfs
<seb128> dholbach: what was broken? it doesn't crash for me
<dholbach> seb128: which version is it?
<dholbach> on your box
<seb128> current one I uploaded last week
<seb128> and I looked at bugs daily in my mailbox
<dholbach> are you sure? which one is installed?
<StevenK> pitti: Did you manage to throw amarok back to the buildds?
<dholbach> seb128: (LP: #125900), (LP: #126192), (LP: #126376), (LP: #126498)
<desrt> simira; sorry.  freenode is blocking my replies.  do you have jabber?
<seb128> ii  gnome-control-center                    1:2.19.5-0ubuntu1                       utilities to configure the GNOME desktop
<dholbach> https://launchpad.net/ubuntu/+source/gnome-control-center/1:2.19.5-0ubuntu1
<dholbach> it ftbfs on i386
<desrt> dholbach; we miss you :(
<seb128> dholbach: I've my local build installed
<dholbach> seb128: I wonder why yours built
* Hobbsee wavse to desrt 
<seb128> why shouldn't it?
<dholbach> an icon which was in capplets-data before was removed
<desrt> Hobbsee; we miss you too :(
<seb128> it built on amd64
<dholbach> so capplets-data.install had to be updated
<seb128> no reason it should not on i386
<dholbach> see also http://bugzilla.gnome.org/show_bug.cgi?id=457054
<ubotu> Gnome bug 457054 in Appearance "gnome-appearance-setting crashes during load" [Critical,Needinfo] 
<simira> desrt: np. And no. Almost everything else. :)
<pitti> StevenK: no, you never told me to
<desrt> simira; get jabber :p
<desrt> <- desrt@desrt.ca
<dholbach> seb128: the crash was because some hunks of debian/patches/95_desktop-effects-integration.patch were not updated
<pitti> StevenK: kicked
<StevenK> [23:36]  < StevenK> pitti: Can you give-back amarok when the publisher completes? (If that's soon enough for the buildds to see the new kdelibs)
<seb128> dholbach: ah, that's a capplet-data.install bug
<dholbach> or did not apply or whatever
<StevenK> pitti: Thanks
<seb128> hum
<dholbach> I fixed it and am about to upload
<seb128> I've a local branch
<seb128> that's going to be fun to merge
<dholbach> local branch?
<seb128> I'm rewritting part of the cappelt
<simira> desrt: I think I have enough with ICQ, msn and yahoo...
<seb128> to have radio buttons
<dholbach> let's move to #u-desktop
<seb128> could you just fix the ftbfs?
<desrt> simira; don't you have something like gaim?
<simira> desrt: yup. Well, they svitched it a pidgeon, but yes.
<Hobbsee> desrt: sure you do.  i'd be one of those rebel KDE'ers :P
<desrt> that's fine.  i want some kde shirts :)
<desrt> y'all shoudl have akademy in turkey next year
<Hobbsee> hehe
<LucidFox> what's the point of qt4-kdecopy?
<Riddell> LucidFox: nothing currently
<Riddell> desrt: as far as I know there's nobody able to host akademy in turkey next year
<desrt> :(
<desrt> Riddell; you here?
<Riddell> here being somewhere other than #ubuntu-devel I presume?
<desrt> UCE.
<desrt> guadec
<Riddell> oh, no, only sunday
<desrt> ah.  i thougt i had seen you
<LucidFox> Riddell> but it will be needed in the future? or it used to be needed in the past?
<desrt> but then i thought maybe it was just a nightmare :)
<Riddell> LucidFox: it was needed in the past.  it may well be needed in the future if kde 4 snapshots need an unstable qt 4
<dholbach> pitti: uploaded
<pitti> dholbach: g-c-c patch> wow, major cleanup
<dholbach> pitti: yeah, some stuff was left around in there
<pitti> hi zul
<geser> pitti: Hi
<pitti> hi geser
<geser> pitti: have you an idea why the universe crash team is subscribed to some crashes for packages from main?
<pitti> geser: we don't actually differ between them any more; it's effectively ubuntu-qa for all crashes
<seb128> pitti: wrong version has been uploaded it looks like
<pitti> seb128: ?
<seb128> pitti: I mean the gnome-control-center update I did some days ago
<seb128> the patch on my disk is clean and working
<pitti> seb128: I just accepted dholbach's
<pitti> seb128: ah, I see
<seb128> hate working from the laptop
<seb128> yeah, that's alright
<seb128> I've some other changes locally but I'll my version after tribe-3
<pitti> evand, cjwatson: ubiquity accepted
<pitti> ok, ubiquity, g-c-c, time for another publisher run
<evand> thanks
<seb128> pitti: what do you think about make cdbs-edit-patch ignore *.rej *.orig *~ ?
<seb128> making
<pitti> seb128: ignoring .rej is dangerous; I don't object against ignoring .orig and *~
* ccm prays tribe-3 will finally enable him to hibernate his laptop. Or let's say: To come back from it :)
<seb128> pitti: k, I've the change locally, I'll upload next week
<pitti> doko: python2.5 accepted
<seb128> pitti: by reading the changelog it looks like the gnome-control-center upload from dholbach is buggy, do you have the debdiff somewhere?
<pitti> seb128: erk, not any more
<pitti> seb128: I just published it out
<pitti> dholbach: ^ do you have it?
<seb128> pitti: you need to add debian/tmp/usr/share/gnome-control-center/pixmaps to capplets-data.install
<wasabi> Anybody familiar with samba enough to review and upload a patch? Bug #118977
<ubotu> Launchpad bug 118977 in samba "winbindd will not start do to invalid cache path" [Critical,New]  https://launchpad.net/bugs/118977
<seb128> the changelog only mentions dropping the icons directory
<seb128> ups, almost no battery power
<seb128> might be disconnected though
<seb128> soon
<ogra> whats up with guadec this year ?
<ogra> no wallplugs ? bad wlan ?
<simira> lousy networks, I believe
<simira> both :p
<ogra> yeah
<ogra> they really should get better sponsors :P
<simira> hehe
<dholbach> pitti: buggy?
<dholbach> http://daniel.holba.ch/temp/g-c-c.debdiff
<dholbach> and that's the new patch: http://daniel.holba.ch/temp/95_desktop-effects-integration.patch
<pitti> dholbach: <seb128> pitti: you need to add debian/tmp/usr/share/gnome-control-center/pixmaps to capplets-data.install
<dholbach> pitti: ok, will take care of it
<pitti> dholbach: so we actually need another upload?
<dholbach> pitti: it seems so - I didn't know that was broken too
<dholbach> pitti: sorry
<dholbach> let me take a look
<pitti> dholbach: no problem, thanks for fixing it *big hug*
<dholbach> it's test building
<dholbach> pitti: fixed, uploading
<pitti> dholbach: accepted, cheers
<dholbach> thanks pitti
<seb128> re
* seb128 kicks the GUADEC network
<Hobbsee> seb128: dont kick it too hard, else it'll really break on you
* pitti imagines seb128 kicking into nothing but air
<seb128> Hobbsee: maybe that's why it's breaking all the time
<Mithrandir> seb128: stop breaking the wireless!
<TeTeT> I've got a problem with the manual partition on a Dell D620 with the latest gutsy, it hangs at scanning disks. Anyone seen this? (Gutsy desktop)
<Hobbsee> pitti: well, people are doing stranger thiings...
<pitti> seb128: don't step on the wifi cable then :)
<seb128> Hobbsee: isn't that middle of the night for you now?
<Hobbsee> TeTeT: tribe 2?  it's mentioned in the release notes, and the workaround is only going in this evening
<Hobbsee> seb128: it's 1.30am
<Hobbsee> seb128: i've learned to live on european time, it seems.
<TeTeT> Hobbsee: kewl, will test it tomorrow then, thanks
<seb128> heh
<pitti> TeTeT: we all cross fingers for that :)
<Hobbsee> TeTeT: there will be cds to test tomorrow, so wait on :)
<seb128> pitti: so I was saying that the capplets-data.install probably needs an update
<pitti> seb128: dholbach fixed it in the meantime, adding the pixmaps
<seb128> ok, good
<Hobbsee> seb128: now, what i *should* do is just more to europe and be done with it, of course, and live on sane time.
<seb128> "move"
<seb128> right ;)
<Hobbsee> or europe should move to me.  either way :P
<Hobbsee> seb128: why, what else would i be doign?  being stationary?
<Riddell> dholbach: "Rarian is a replacement for scrollkeeper" that's not a descriptive title
<Mithrandir> Hobbsee: you'd just end up living on west coast US time if you moved here.
<Hobbsee> Mithrandir: hopefully not.  i did use to keep sane times, long ago.
<Hobbsee> Mithrandir: but that was like...5 years ago, or whatever.
<Hobbsee> well, probably 3.  then the work night shifts started.
<dholbach> Riddell: fixing
<Riddell> dholbach: I'll reject for now then, let me know when you re-upload and I'll take another look
<jdong> why doesn't apt-get -t <distro> source <package> work?
<jdong> mako and I were just playing around with that....
<dholbach> Riddell: done
<jdong> I'd also be a happy camper if there were an alternative way of pulling source packages from an arbitrary distribution
<Mithrandir> jdong: because nobody has written a fix for that yet.
<jdong> oh, is that bug 16whatever?
<ubotu> Launchpad bug 16 in rosetta ""Swedish" and "Swedish (Sweden)" should be the same language" [Medium,Fix released]  https://launchpad.net/bugs/16
<Hobbsee> Mithrandir: but cant you just wave your magic wand and do it?
<jdong> bug 16240?
<ubotu> Launchpad bug 16240 in apt "Cannot Pin on components" [Medium,Confirmed]  https://launchpad.net/bugs/16240
<Mithrandir> jdong: no, I don't think so
<jdong> ok
<Mithrandir> Hobbsee: so many bugs, so little time.
<Hobbsee> true that
<jdong> Mithrandir: do you have any other recommendations for apt-get source -t like functionality?
<Mithrandir> dget?
<persia> jdong: Try https://wiki.ubuntu.com/EmmetHikory?action=AttachFile&do=get&target=src-get if you like.  It's rough, but it works.
<jdong> Mithrandir: do you have a bug number?
<Mithrandir> jdong: no, sorry
<jdong> persia: lol I died a little inside reading that script
<jdong> persia: but I guess it works :D
<persia> jdong: Like I said, rough :)
<mako> persia: yeah, rough :)
<seb128> StevenK: thanks for the libgpod transition, I didn't manage to test if there was no brekage with rhythmbox due to GUADEC
<jdong> Mithrandir: is this broken across all releases of Ubuntu?
<Mithrandir> jdong: yes, it's been broken since -t appeared four or so years back
<mako> wow, i could have *sworn* that worked for me
<seb128> mako: you can use /version
<Mithrandir> mako: I believe you have dreamt.
<mako> Mithrandir: sure.. i trust you more my own memory
<jdong> seb128: /version as in /gutsy, or /1.2-3?
<mako> more than my own memory even
<seb128> like 1.2-3
<jdong> let me try that
<Hobbsee> mako: i concur with Mithrandir.
<jdong> jdong@backports-builder:/tmp$ apt-get source python-support=0.5.3ubuntu1
<Hobbsee> "tell him he's dreaming, son"
<jdong> ^^ that's the syntax
<jdong> sweet
<jdong> that works
<jdong> can we hack apt-get source to do that :D
<jdong> LOL
<jdong> thanks for your time, Mithrandir and seb128
<elmo> (web front end of) launchpad is going down for emergency maintenance for 2-3 minutes in 5 minutes
<Hobbsee> elmo: if you break it, i will be displeased :P
<Hobbsee> and i *will* hunt you out for the next UDS, if it affects the tribe :P
<bdmurray> BenC: I squared away amitk early this AM
<BenC> bdmurray: thanks...would it be possible to just add canonical-kernel-team to ubuntu-qa instead of each of us individually?
<BenC> bdmurray: I admin that team, and it will only consist of hired kernel devs
<bdmurray> BenC: There's a thought.
<pitti> hi mdz_
<seb128> hey mvo
<elmo> launchpad should be back
<dholbach> elmo: there seems to be something wrong:     https://bugs.launchpad.net/ubuntu/+source/dosfstools/+bug/126121     forwards me to         https://blueprints.launchpad.net/ubuntu/+source/dosfstools/+bug/126121
<ubotu> Launchpad bug 126121 in dosfstools "Typo in mkdosfs man page" [Undecided,In progress] 
<dholbach> hum, everything seems to forward me to https://blueprints.launchpad.net/ - which seems to be down or something
<wasabi> Yeah, broked
<pitti> it doesn't answer at all for me
<soren> Can we remove packages from Feisty?
<pitti> soren: we really, really shouldn't
<soren> pitti: it's phpunit. It's uninstallable as it depends on php4, so it's not installable.
* persia notes that packages have previously not been removed from released distroreleases even at the express request of trademark holders, making the bar very high indeed.
<soren> pitti: OTOH there is phpunit2, which is for php5, so that's ok.
<WorkingGeier> hi
<soren> pitti: What if we pushed the transitional package from gutsy into -updates? Would that work?
<soren> pitti: ah, hang on.
<WorkingGeier> I need to compile a package against all releases; I generate the version by appending "~ubuntu6.04" etc.
<dholbach> elmo: it seems to work now - thanks
<WorkingGeier> what would I use for gutsy?
<WorkingGeier> 7.notknownyet would sort after the real version number
<soren> pitti: It's really confusing, actullay.
<WorkingGeier> 7.04+gutsy works, but is ugly
<WorkingGeier> any ideas?
<Mithrandir> persia: uh, are you sure about that?
<Mithrandir> persia: bug #?
<soren> pitti:  Up until feisty, phpunit was the 1.3 tree. In gutsy, phpunit is the 3.0 tree.  phpunit2 in feisty was the 2.3-tree, but is in gutsy a transitional package depending on the phpunit package (i.e. the 3.0 version).
<persia> Mithrandir: bug 80404 as applied to dapper and edgy (given the date of Blizzard's complaint).
<ubotu> Launchpad bug 80404 in freecraft "Please remove freecraft from Ubuntu" [Undecided,Fix released]  https://launchpad.net/bugs/80404
<persia> Mithrandir: My understanding is that Blizzard complained to upstream, and not to Ubuntu, so I doubt there is outstanding liability, but someone qualified should offer an opinion.
<Mithrandir> persia: freecraft is hardly a trademark violation on warcraft.
<persia> Mithrandir: Perhaps.  I'm not an expert on trademark law.  I stand corrected.
<Mithrandir> persia: me neither, but until blizzard complains directly at us, I don't see a need to remove it.
<persia> Mithrandir: I'd agree (no outstanding liabilty)
<Riddell> mvo: were you talking about the emacs22 packaging at the distro sprint?
<mvo> Riddell: briefly, it seems like the package is waiting in the NEW queue now
<ryanakca> cjwatson: I'm going to try out today's CD... let's hope LVM works :)
<Riddell> mvo: it is, from a Michael W. Olson
<cjwatson> ryanakca: good luck
<Hobbsee> ryanakca: i didnt think the cds that were worth testing were done yet...
<pitti> right, we are still collecting fixes
<soren> pitti: I'll see if I can work around this phpunit thing. I'll shout again if needed.
<pitti> soren: what is the actual problem?
<pitti> certainly not an uninstallable package on its own?
<Riddell> mvo: hmm, the docs in emacs22 contain front cover texts
<cjwatson> Riddell: note that Ubuntu's generally been OK with the GFDL in main in the past
* cjwatson -> elsewhere
<soren> pitti: Well, yes. I didn't think a package removal was *that* big a deal.
<Riddell> cjwatson: even with cover texts?
<pitti> soren: it's not for the development release, but we rather not touch stables unless we absolutely have to
<cjwatson> soren: changing a released distribution *at all* is a big deal, and the only way you can remove a package from feisty is to change dists/feisty/ - you can't do it in -updates
<cjwatson> Riddell: I haven't checked, but I think so
<ryanakca> Hobbsee: cjwatson fixed the LVM problems yesterday, I'm going to test that part at least :)
<Hobbsee> ryanakca: fair enough
<pitti> Riddell: we left it in NEW so far, because it seems much more sensible to just sync emacs22 and docs from Debian
<pitti> Riddell: and put the -docs package into main, and maybe even add a dependency
<seb128> pitti: we want to accept the current in NEW I think
<pitti> Riddell: maintaining a trivial diff (dependency addition) seems much saner than having a completely parallel packaging
<pitti> seb128: right, I didn't look at it, just mentioning it
<soren> cjwatson: Yes, I think I understand the implications, but removing a package that is broken doesn't seem all that intrusive.
<soren> Never mind, though. I'll see if I can make the thing work with php5 and go the -updates way.
<seb128> pitti: just to not make the guy who make the efforts run away from Ubuntu
<seb128> like using a diplomatic way
<pitti> Riddell, seb128: as long as it's in universe I do not care much
<pitti> seb128: yeah, fine to me :)
<pitti> soren: OTOH, just leaving it there doesn't hurt either
<Riddell> pitti, seb128: and you're both OK with cover texts in FDL?
<pitti> Riddell: TBH I never answered this question to myself
* soren runs to the shops before they close. bbl.
<seb128> Riddell: same as pitti
<pitti> Riddell: but I have the feeling that these are bit on the edge; copyright texts are not freely modifyable either
<pitti> Riddell: so I'm fine with having them in main, if even the FSF is good with them
<Riddell> elmo: are you know if we allow FDL with cover texts?
<Riddell> s/are/do/
<pitti> Riddell: s/main/archive/
<elmo> Riddell: yes, it's fine
<elmo> if we == Ubuntu
<Riddell> ok, thanks
<pitti> BenC: wrt. bug 54621, this problem is so old that moving it from t3 to t4 is certainly bearable?
<ubotu> Launchpad bug 54621 in linux-source-2.6.22 "Kernel panic - not syncing: IO-APIC + timer doesn't work!" [Medium,Fix committed]  https://launchpad.net/bugs/54621
<BenC> pitti: yeah, we were going to fix that in the upload today, but it's certainly not a regression, so tribe-4 is fine
<pitti> BenC: cool, thanks
<amitk_> pitti: that was me. Why is t3 a problem?
<pitti> amitk_: it takes some 10 hours to get it into the archive at all, and we shouldn't risk major breakage at this point
<pitti> amitk_: I'd like to build a first set of good candidate CDs in an hour or two
<pitti> otherwise we'll miss the deadline
<kylem> it doesn't really matter, it will be on a daily disk after you upload it. if you have a tester just get them to wait a day and grab that.
<pitti> right
<pitti> or just dist-upgrade
<amitk_> pitti: right! I had forgotten that we cancelled a kernel release today
<pitti> amitk_: yeah, sorry for that; next time we need to coordinate that better
<amitk_> pitti: no worries
<pitti> amitk_: timing with last week's sprint and travel was tight and bad :/
<elmo> what's the official position on downgrades?
<elmo> supported or not
<pitti> that'll break very often
<kylem> pitti, are we not waiting for fixed gnome-c-c?
<pitti> kylem: yes, that's the last thing I'm waiting for
<kylem> ok.
<pitti> kylem: publisher just finished, now I'll let it build, publish, build CDs
<elmo> it doesn't in my experience
<elmo> at least on servers
<elmo> but anyway, that's not really my question
<pitti> downgrading things like the python transition is next to impossible, too, I figure
<pitti> I didn't see any official statement about supporting it, that's all I can say
<pitti> zul: any chance to fix xen on amd64? it causes quite a lot of uninstallability
<zul> pitti: I have a fix ready can I upload it?
<pitti> zul: cool! please
* pitti examines why linux-image-xen/i386 and friends are uninstallable
<zul> itll just take a couple of minutes
<pitti> aah, linux-image-2.6.22-8-xen is in universe; is that deliberate?
<pitti> BenC: ^
<zul> yes I belived it is
<Hobbsee> pitti: so's xen-3.1 though
<pitti> Hobbsee: nope
<pitti> all the xen stuff is in main, even linux-ubuntu-modules-2.6.22-8-xen
<Hobbsee> well, was when i looked a few days ago
<pitti> except for the kernel image
<Hobbsee> i thougth
<pitti> xen-3.0 was in main as well
<pitti> Hobbsee: it was recently promoted
<pitti> libvirt, cman, etc. all depend on it, too
<Hobbsee> so after i checked last, yes
<stgraber> hello, still nothing to add on the tracker from what I've read from my backlog ?
<Hobbsee> stgraber: correct.  images havent started being biult yet
<pitti> stgraber: working on it as fast as soyuz allows us
<Hobbsee> pitti: WELL PEDAL FASTER!!!  :P
<pitti> zul: hm, so we should demote the entire xen stack to universe? that'd require some changes to the redhat-cluster-tools and libvirt, and coordination/ack from fabbione
<pitti> Hobbsee: at 35 degrees? c'mon
<zul> pitti: uploaded
<Hobbsee> pitti: i'll swap :P
* pitti bumps the build prio to 5000; can't pedal faster
<stgraber> pitti: that's no problem for me, I really prefer to add them myself just in case I come across a bug with the new tracker (it was tested but some features were added only late yesterday :))
<stgraber> pitti: hehe, 35 degrees can be ok, but the 10 degrees -> 35 degrees in only 2-3 days was well, a bit too fast for me :)
<pitti> stgraber: optimistic ETA is 2.5 hours for ubuntu and kubuntu; will you still/again be online at that time?
<pitti> stgraber: *ack*
<stgraber> pitti: sure, will be around till 01:00 CEST or something like that (holidays :))
<pitti> stgraber: heh
<stgraber> pitti, Hobbsee: Do you know if the assignees on : https://wiki.ubuntu.com/Testing/Matrix?action=recall&rev=27 are still up to date ?
<stgraber> if yes I'll subscribe them to those tests on the tracker as well
<pitti> stgraber: they haven't been updated since feisty, and some people are on guadec and such
<stgraber> pitti: ok, so I'll let Henrik do that once he's back
<pitti> zul: would it hurt much if I put it into main for now, until we have a more consistent solution? or is it actively broken?
<zul> pitti: the kernel image? no complaints from me check with BenC though
<bdmurray> stgraber: they aren't
<pitti> zul: noted for distro team meeting, thanks
<pitti> ah, /me mails instead
<Hobbsee> stgraber: no, those arent up to date.  but they look like they'll be testing images, or at least most of them will
* Hobbsee --> bed.  night all!
<stgraber> Hobbsee: ok, good night
<Hobbsee> :)
<BenC> pitti: xen is just untested, but I've no objections to be it being in main
<pitti> BenC: ah, thanks
<pitti> yay, g-c-c built
* ion_ had to think for a while until i realized another meaning for the acronym than GNU C Compiler. :-)
<pitti> gnome-control-center
<ion_> Yeah
<thom> ion_: gcc has less hyphens in
<pitti> ogra: so, bug 121547 -> tribe4 then? just a cosmetical issue after all, right?
<ubotu> Launchpad bug 121547 in ltsp "[Gutsy]  LTSP chroot building process hangs at 50% on Tribe1 CD" [Undecided,Confirmed]  https://launchpad.net/bugs/121547
<ion_> thom: Yeah, thats why i tried to figure out the other meaning. :-)
<bhale> hey thom
<thom> hey
<wasabi> hmm does /etc/group support using numeric user ids?
<wasabi> in any fashion...
<calc> anyone happen to know why libsvg-dev isn't in gutsy?
<pitti> erk, panel crash, brb
* pitti jumps for joy while he demotes gtk+1.2 to universe; it only took three years!
* pitti hugs doko
<ion_> pitti: Yay :-D
<pitti> ... and glib1.2 with it \o/
<pitti> keescook: do you have any idea about the status of bug 105936 ?
<ubotu> Launchpad bug 105936 in lvm2 "snapshot creation failure race "in use: not deactivating"" [High,Confirmed]  https://launchpad.net/bugs/105936
* bhale watches Hobbsee use her big pointy stick for release management
<Riddell> TheMuso: for some reason I can't help laughing at ubuntustudio-floater :)
<calc> what is the proper procedure to pull in a debian package that has never been in ubuntu before?
<pitti> calc: filing a sync request
<pitti> calc: we can sync it and wave it through NEW
<calc> ok
<fabbione> pitti: uh? no we can't demote xen to universe.. i only need the libraries to build cman & co
<pitti> fabbione: yeah, I promoted the kernel
<fabbione> pitti: if we demote it, i will need to make a mess of splitting packages around
<pitti> fabbione: apparently it was just a minor misunderstanding
<fabbione> pitti: ok..
<calc> pitti: hmm do i need to do that by hand, requestsync complains about madison not containing it
<fabbione> pitti: so we have everything on amd64 too now?
<pitti> calc: ah, just tell me the package
<calc> pitti: libsvg
<pitti> fabbione: that's still in progres
<pitti> fabbione: source is publishing now
<calc> pitti: thank you for the help :)
<fabbione> pitti: ok, i will wait after tribe-3 to reupload the changes tho...
<fabbione> pitti: there is no need to rush them trough
<calc> debian ooo has a dep on it for 2.3 m221 which i am doing a test build for gutsy of :)
<agoliveira> http://browser.garage.maemo.org/
<pitti> calc: hm, then it needs a MIR
<agoliveira> SOrry, wrong window
<pitti> calc: I'll put it into universe for now, that's sufficient for a local test build
<geser> calc: libsvg is new so you would need requestsync -n (but I assume it still won't work as libsvg is in experimental)
<calc> pitti: yea, universe is fine for now
<pitti> calc: hm, libsvg doesn't seem to be in unstble
<calc> oh wow
<calc> ok
<calc> i can do a local grab and build for my testing then
* calc had assumed it was in sid
<geser> pitti: it's in experimental
<pitti> calc: ah, experimental
<evand> Can someone sponsor tasksel 2.67ubuntu2 (http://people.ubuntu.com/~evand/upload/)?
<pitti> calc: do that anyway, syncing/NEWing/building/NEWing/publishing will take a while
<calc> pitti: ok
<geser> fabbione: do you know if xft1 (binary package is libxft1; universe) is still needed? or can it be removed?
<keescook> pitti: sorry, delayed answer: it is not yet fixed.  still waiting for kernel bits, iirc.
<fabbione> geser: no idea....
<pitti> calc: synced and source-NEWed
<calc> pitti: thanks
<calc> i've started the ooo build now, libsvg rebuilt fine in my gutsy chroot
* calc hopes it mostly works, heh
<calc> need to get ooo 2.3 into gutsy ASAP
<geser> fabbione: hmm, I hoped you would knew as the last upload was done by you for breezy
<pitti> evand: is that crucial for tribe3?
<fabbione> geser: check the rdepends
<pitti> geser: ^ checking
<evand> pitti: I wouldn't say crucial, but it should make the gobuntu cd images actually work
<pitti> evand: ok, but not important for ubuntu/kubuntu/etc?
<evand> correct
<pitti> geser: no rdepends whatsoever
<pitti> evand: *phew*, thanks
<evand> heh
<geser> pitti: so it's ok if I file a remove bug for it?
<pitti> geser: sure, that's fine; thank you!
<hansin321> Sorry if this is the wrong place to ask: Where does one make a package request/change for Gutsy?  I see Gutsy still uses 'centericq', but I think the good work going forward will be with the fork 'centerim'.  At least that is my interpretation.
<pitti> geser: /me  clean house :)
<Riddell> hansin321: it's in universe, try finding someone in #ubuntu-motu to package it (assuming centerim has made a release)
<calc> gar
<calc> having build-dep conflicting packages
<Riddell> hansin321: or file a request to package bug according to the process (which is somewhere on the wiki, probably under /MOTU)
* calc notes he can't read long amounts of apt-get output properly, must drink more caffeine
<pitti> ogra: I'll downsize the edubuntu server i386
<pitti> stgraber, bdmurray, all: ubuntu live images up: http://cdimage.ubuntu.com/daily-live/20070717.1/
<pitti> stgraber, bdmurray: kubuntu alternates: http://cdimage.ubuntu.com/kubuntu/daily/20070717.1/
<hansin321> Riddell: Thanks.  I'll take a look.
<pitti> zul: libxen3.1-dev_3.1.0-0ubuntu8_amd64.deb is still empty
<pitti> zul: xen-hypervisor-3.1-amd64_3.1.0-0ubuntu8_amd64.deb seems to work, though
<pitti> zul: libxen3.1-dev on i386 is empty as well, though
<zul> pitti: ok
<pitti> zul: accepting for now, but I guess that's not quite right?
<zul> nope
<zul> will take another look at it when i get home
<pitti> zul: thanks muchly
<ScottK> pitti: Would you be up for accepting clamav 0.91.1-1ubuntu1 - the Debian maintainer enabled new functionality with the update I just merged and I'd rather get it exposed to the rush of upgraders coming on Thursday.
<pitti> ScottK: done
<ScottK> pitti: Thanks.
<pitti> bdmurray, stgraber, gpocentek: http://cdimage.ubuntu.com/xubuntu/daily/20070717/
<mr_pouit> pitti: the seeds were fixed yesterday (issue with goffice), so I don't understand why it still fails :/
<stgraber> pitti: thanks
<pitti> mr_pouit: "it"?
<mr_pouit> pitti: Hobbsee pingued me to tell that the live-cd iso build failed
<pitti> mr_pouit: it didn't get to that yet
<mr_pouit> ok
<stgraber> pitti: alternate are ready for testing as well ?
<pitti> stgraber: no, ubuntu and edubuntu are oversized, fix in progress
<pitti> stgraber: are you fine with me announcing good images to you over IRC, as above?
<ryanakca> cjwatson_: ok, I figured out the /home problem. It's because /dev/mapper/sampi-Home isn't in the fstab, thus, it doesn't get mounted. Going "sudo mount /dev/mapper/sampi-Home /home" fixes the problem.
<pitti> stgraber: there will be some varying version numbers, so I'll give the full URL
<stgraber> yes, that's fine
<pitti> stgraber: do you need the entire list again? or you'll get it from backscroll?
<stgraber> pitti: I'm putting Ubuntu, Kubuntu and Xubuntu desktop on the tracker
<pitti> stgraber: no, please not yet
<pitti> http://cdimage.ubuntu.com/daily-live/20070717.1/
<pitti> http://cdimage.ubuntu.com/kubuntu/daily/20070717.1/
<stgraber> hmm, ok
<pitti> http://cdimage.ubuntu.com/xubuntu/daily/20070717/
<pitti> stgraber: those three so far
<stgraber> ok
<pitti> stgraber: ubuntu-server should actually exist as well, no idea why it's not on the web
<pitti> stgraber: I guess it's just a mirror delay, http://cdimage.ubuntu.com/ubuntu-server/daily/20070717 should exist (and does exist on lithium)
<stgraber> pitti: ok, those three are ready
<pitti> stgraber: http://cdimage.ubuntu.com/kubuntu/daily-live/20070717.1/
<stgraber> ok, I'll keeping refreshing those two urls :)
<pitti> so do I; hm, that was much faster in the past
<pitti> I had a long delay for kubuntu, too, though, and eventually it worked
<pitti> let's check again in 30 minutes or so
<pitti> stgraber: http://cdimage.ubuntu.com/kubuntu/daily-live/20070717.1/ and http://cdimage.ubuntu.com/ubuntu-server/daily/20070717/ are operational now
<pitti> stgraber: http://cdimage.ubuntu.com/daily/20070717.2/ is now ready (ubuntu alternate)
<pitti> mr_pouit: indeed, xubuntu live CDs failed to build
<pitti> mr_pouit: "E: Couldn't find package libgoffice-gtk-0-3"
<pitti> stgraber: wb
<pitti> just in case you did not read it:
<pitti> stgraber: http://cdimage.ubuntu.com/kubuntu/daily-live/20070717.1/ and http://cdimage.ubuntu.com/ubuntu-server/daily/20070717/ are operational now
<pitti> stgraber: http://cdimage.ubuntu.com/daily/20070717.2/ is now ready (ubuntu alternate)
<stgraber> ok, thanks
<stgraber> (Looks like my dedicated server provider is having some port 6667 problem, I had to use 8001 ...)
<pitti> stgraber: I have used 8001 for months, since the time when freenode actively discouraged 6667 for some reason
<pitti> stgraber: http://cdimage.ubuntu.com/edubuntu/daily/20070717.2/
<pitti> mr_pouit: i386 seems to be happy, but the amd64 one failed
<pitti> mr_pouit: ah, no, failed the same way
<pitti> stgraber_: http://cdimage.ubuntu.com/edubuntu/daily/20070717.2/
<stgraber_> pitti: just connected from my laptop as well
<pitti> stgraber_: ah
<stgraber> https://isotesting.stgraber.org/isotesting/build/All <-- Updated
<pitti> looking
<pitti> stgraber: we should now have everything except xubuntu/live, which fails to build
<stgraber> pitti: Edubuntu desktop ?
<pitti> http://cdimage.ubuntu.com/edubuntu/daily-live/20070717.1/
<pitti> ah, mirrored now
<stgraber> good
<pitti> ogra, bdmurray, Riddell, all: time for CD testing
<Kmos> the "quit" button at System menu is working with latest updates in gutsy ?
<stgraber> so yes, we have everything except xubuntu desktop
<Kmos> i've done the latest ones and I click on it and doesn't do anything
* ..[topic/#ubuntu-devel:pitti] : Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty, #ubuntu+1 for gutsy support | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Main FROZEN for Tribe 3 | Please test the Tribe-3 candidates: https://isotesting.stgraber.org/
<stgraber> pitti: Shall I add the *Upgrades builds to the tracker ?
<pitti> stgraber: upgrades builds?
* Kmos its working now
<stgraber> We have : "Ubuntu Upgrade amd64", "Ubuntu Upgrade i386", things like that
<pitti> stgraber: ah, I see; sure, that would be handy
<pitti> stgraber: ah, I like the 'passed/failed' radiobutton and the multi-select 'passed with no bugs'
<pitti> great!
<stgraber_> pitti: that was part of the most wanted features after tribe-2 :), especially the pass/fail radiobutton
<pitti> infinity: find /home/lp_archive/ubuntu/dists/gutsy -name Packages.gz|xargs zgrep "libgoffice-gtk-0-3" -> that does not find anything; are the xubuntu livefs build chroots outdated or so?
* Starting logfile irclogs/ubuntu-devel.log
(pitti/#ubuntu-devel) libapache2-mod-php5 | 5.1.6-1ubuntu2.6 | edgy-security | amd64, i386, powerpc, sparc
(elmo/#ubuntu-devel) keescook: it's syncing now
<mathiaz> keescook, pitti: for apparmor packages into main - what's the next step ?
<pitti> keescook: however, I noticed that CD syncs took drastically longer today than usual, so maybe it's just the same sync slowness
<elmo> keescook: cron.daily on drescher is very slow ATM - I'd adjust your expectations about prop time a little to match
<keescook> elmo: ah! okay, noted.
<mathiaz> keescook, pitti: it seems that we won't try to split the source packages as upstream has one svn repository.
<evand> tretle_: PalmOS is hardly dead, but this is not really the place to discuss that.  This is also not the place to discuss packaging new software for Ubuntu.  That's #ubuntu-motu.
<keescook> mathiaz: okay, cool.  yeah, all the main magic is up to pitti as far as I know.  :)
<mathiaz> keescook: ok. I've asked for an import of upstream.
<pitti> mathiaz: right, let's do this right after the tribe release, I got TeTeT's ack
<keescook> mathiaz: cool!
<mathiaz> pitti: excellent.
<pitti> mathiaz: where would we seed that?
<mathiaz> keescook: once upstream is in bzr, I'll update the package.
<mathiaz> pitti: standard seed ?
<pitti> mathiaz: as a recommends?
<pitti> mathiaz: IOW, installed by default, but removable?
<mathiaz> pitti: yes.
<pitti> mathiaz: apparmor and apparmor-utils, anything else?
<mathiaz> pitti: no.
<pitti> mathiaz: maybe just -utils, since apparmor itself is not that interesting
<mathiaz> pitti: hum - not sure. let me check what's in apparmor
<mathiaz> pitti: i think there is the init ramfs hook.
<pitti> mathiaz: i. e. not interesting on its own to mention it explicitly in the seeds; it'll get pulled in as dependency
<ajmitch> are the modules shipped with the kernel package now?
<pitti> ajmitch: yes, in l-u-m
<tretle_> evand - "tretle_: PalmOS is hardly dead" they have stopped using PalmOS on their devices and one could not argue the fact that their are more people using mobile phones as their organizers these days than PalmOS devices
<ajmitch> pitti: right, I've just got an old version installed :)
<tretle_> their - there
<pitti> mathiaz: ok; I won't change the seeds right now to not get them out of sync to the tribe; we should do this very early after the tribe, Thursday evening or Friday
<mathiaz> pitti: apparmor is needed. it has the init ramfs hook, plus the init scripts.
<pitti> mathiaz: I know
<mathiaz> pitti: ok. np.
<pitti> mathiaz: I mean, having it as a dependency is fine
<mathiaz> pitti: ok - I understand now.
<mathiaz> pitti: so tribe-4 will install apparmor by default.
<pitti> yes
<mathiaz> pitti: what about upgrades ?
<pitti> mathiaz: those, too
<pitti> since ubuntu-standard pulls them in
<kylem> erm, so we intend to ship apparmor everywhere, or just on server?
<pitti> for those people who did not forcefully remove it, anyway :)
<ajmitch> seems like everywhere, from the sound of things
<pitti> kylem: that would be everywhere (without profiles, though, just the infrastructure)
* kylem goes to find his Debian cds.
<ajmitch> kylem: you'd prefer selinux-by-default instead? :)
<kylem> ajmitch, yes.
<ajmitch> so would I, but it's obviously not going to happen for ubuntu
<kylem> we could make it happen...
<ajmitch> sure, it's mostly policy work to clean it up
<pitti> wb ogra
<lamont> so apparmor is the competing thing vs selinux?
<lamont> because, yeah, selinux would be better.
<keescook> lamont: if by "competing" you mean "also uses LSM", then yes.  :)
<lamont> keescook: I wasn't ranking them even close to each other, just making sure they were claiming to at least address similar use cases
<lamont> we'll still install libselinux by default, yes?
<calc> lamont: hi! :)
<keescook> lamont: yeah, roughly, they're both MAC systems.
<lamont> (if for no other eason than that mount Depends: it now...)
<lamont> calc: hi
<keescook> lamont: but afaik, libselinux is still fully incorporated
<calc> lamont: we got to see all the hp servers last week :)
<ajmitch> well a number of apps link to the (admittedly small) library
<calc> lamont: at the DC
<lamont> calc: DC tour?
<calc> lamont: yea
<calc> lamont: most of them were familar to me with my HP testing I had done previously
<stgraber> pitti: How is the Xubuntu desktop build going ?
<pitti> stgraber: not today any more; infinity will fix it tomorrow morning
<stgraber> ok
<elmo> launchpad website going down for emergency maintenance, in 5 minutes - ETD is < 5 minutes
<elmo> LP backup
<stgraber> ogra: Edubuntu desktop is showing the gdm prompt instead of auto-login ...
<stgraber> pitti: minor issue on Edubuntu desktop, auto-login isn't working
<pitti> major issue on ubuntu, compiz totally blocks the machine on session startup :(
<pitti> same problem as we already had right before tribe-2
<david_ross> hehe
<david_ross> pitti: going to send out an update which breaks everything ? :))
<stgraber> pitti: argh, how blocked is it ? black screen, gnome half-starting (need to kill compiz, restart metacity and finally compiz-replace to fix), other ?
<Riddell> infinity: could you give back soprano in feisty-backports
<pitti> stgraber: the 'switch to console, enter a few chars, find it freezing' one
<stgraber> bad :(
<pitti> stgraber: it's not even half starting; I already saw this, it's not the 'cannot connect to session' bug
<pitti> seems that something dropped the nv blacklisting, perhaps
<pitti> I'll dig again
#ubuntu-devel 2007-07-18
* #ubuntu-devel  [freenode-info]  please register your nickname...don't forget to auto-identify! http://freenode.net/faq.shtml#nicksetup
<FireRabbit> are people from the desktop team going to be at ubuntu live next week?
<kylem> a few will be.
<FireRabbit> will there be interest in a BoF to hack on stuff? I am thinking about organizing something.
<kylem> according to the schedule, dholbach will be there, maybe ask him who else is going.
<FireRabbit> okay.
<FireRabbit> (I assume he comes in here?)
* Starting logfile irclogs/ubuntu-devel.log
<calc> getting ooo 2.3 m221 to build is er fun
* ajmitch wonders if it's an improvement over 2.0 for stuff at work
<fabbione> morning
<ajmitch> hi fabbione
<calc> ajmitch: no idea yet, its still a pita to build apparently
<calc> its looking for nspr in the wrong dir :<
<calc> is canonical down?
<calc> i can't get to the servers
* ajmitch can get to launchpad, but others can't
<Burgundavia> calc: certain pieces appear to be down for some
<Burgundavia> I can still get to the wiki
<calc> mail and irc is down for me
<Burgundavia> calc: WORKSFORME
<Burgundavia> clearly you have no paid your tax to Mark for this month
<calc> heh
<calc> he can take it out of my paycheck ;P
<Burgundavia> heh
* calc can't access his ubuntu email now, grr
<calc> hmm security.ubuntu.com seems down for me as well
* calc wonders if the whole DC is down
<calc> or maybe just one of the racks
<ajmitch> calc: routing, I'd say
<ajmitch> since I can reach everything that I know of
<calc> hmm ok
<calc> yep its routing
<ajmitch> mtr tells all?
<calc> level3 in dallas is dead
<calc> not sure if the next hop after dallas is london or not
<calc> i forgot the nicks of the IS/IT staff so i can't ping them either :\
<Burgundavia> calc: whose? level3?
<calc> canonical is/it
<Burgundavia> ahh
<bryce> elmo
<calc> he's asleep probably
<calc> 6:21am there
<bryce> likely
<Burgundavia> I go seattle --> london, so I would suspect you probably go that as well
<Burgundavia> you could try #canonical-sysadmin
<calc> started working as soon as i complained in there, lol
<calc> it had been down an hour
<calc> grr my fiance keeps editing pictures of her wedding dress and tells me not to look at the computer screen, lol
<calc> we get married on sat
<yigal> hey is this the place where I can express my interest in using bob marly and quotes from Mahatma Gandhi in 7.10?
<calc> yigal: huh?
<yigal> wouldn't that be the best
<yigal> huh a palindrome
<yigal> if it were a word
<calc> its american english ;)
<yigal> i dig it
<calc> ooo is melting my brain
<yigal> open office?
<calc> yigal: yea
<calc> i'm trying to build 2.3 m221
<yigal> hmm, I really don't like using ooo its to bulky
<yigal> for my needs
<yigal> abiword/gnumeric
<calc> its a bit large yea
<yigal> its not the size, its just that on my machine its noticeably slower than using other tools for the same purpose, who knows
<calc> mostly due to it being huge probably, heh
<StevenK> calc: Any earth shattering changes from 2.2 to 2.3 m221?
<yigal> probably that it breaks more often
<calc> StevenK: it doesn't build yet for me
<calc> StevenK: which with 2.2 it didn't build randomly now it always doesn't build :)
<StevenK> That's an improvement. :-P
<calc> i know why it fails currently but not sure how to fix it
<calc> its looking for nspr in /usr/include/firefox/nspr
<calc> which is not where it is at
<calc> i probably need to look at what all patches debian is using with it and move them over for ubuntu
<calc> rene is asleep i think so i will have to ask him tomorrow
<yigal> calc: symbolic links?
<calc> yigal: well that could solve it but its probably not the right answer overall
<yigal> calc: why not?
<calc> because it should be looking for nspr where it normally is
<yigal> calc: is there a configure flag to tell it where it is?
<calc> not in a firefox subdir
<calc> not certain, i don't think so, i couldn't determine where it was combining the directory yet
<yigal> calc: so no simple search like, "configure --help | grep -i nspr" does anything
<calc> nope
<yigal> calc: owell
<yigal> :(
<yigal> :)
<minghua> yigal: Also because you can't do symbolic links in /usr/include/ when building on buildds.
<calc> minghua: well if the solution longterm was symlinks they could be added to the firefox-dev package (maybe, unlikely since it would be dangling in some cases)
<minghua> calc: Yes sure.  But I think you agree that it doesn't look like a long-term solution. :-)
<yigal> minghua: I mean there are symbolic links in /usr/include though?
<yigal> minghua: already
<calc> not right now
<calc> hmm it probably should be using nspr-config to get the includedir from
<yigal> minghua: at least on my debian OS there is, im in unstable not ubuntu right now
<calc> which is set correctly
<calc> yigal: there isn't even a firefox-dev on sid
<minghua> yigal: Do you mean symbolic links in general or /usr/include/firefox/nspr/ in specific?
<calc> i installed iceape-dev and it has no symlinks in /usr/include/iceape -> nspr
<calc> what package in sid has /usr/include/firefox ?
<yigal> calc: no what I said before, there are symbolic links in /usr/include
<yigal> :)
<calc> oh ok, nm
<calc> i need to go to bed, have a good few hours :)
<calc> night/day/evening/morning/etc ;)
<ajmitch> night calc
<yigal> night calc
<yigal> sleep tight
<Hobbsee> greetings all
<mneptok> Hobbsee!
<Hobbsee> mneptok!
<mneptok> http://mneptok.com/beer.pl
<Burgundavia> Hobbsee: how long until release?
<Hobbsee> Burgundavia: over 24 hours
<Burgundavia> ok
<Hobbsee> Burgundavia: we need testers, so if anyone's interested...
<Burgundavia> don't have the hardware
<Hobbsee> i meant of people you knew
<Burgundavia> right
<Burgundavia> all the millions whom I share an apartment with
<Hobbsee> i meant in whatever channels you're in
<mneptok> Hobbsee: did you check that Perl?
<mneptok> (maybe so, you went suddenly quiet)
<Hobbsee> mneptok: no, i didnt
<Burgundavia> mneptok: that is wrong
<mneptok> insta-brainfry
<Hobbsee> mneptok: heh :P
<mneptok> some people ...
<soren> SRU's should be based on the newest security version, right?
<Hobbsee> yes, i think so..
<soren> Thought so. Thanks.
<StevenK> SRU and security updates are different.
<soren> StevenK: Indeed, but it seems like at lot of useless work to apply a patch to the originally released version, have it tested an uploaded to -updates and then afterwards have to go through the security patching again and push that to -security.
<soren> StevenK: What would be the purpose of maintaining an insecure version along with a secure version?
<soren> How can I tell dpkg-source that it's ok that the Maintainer is does not contain "ubuntu" even though the version string does?
<soren> -W does not help at all, it seems.
<StevenK> soren: Why not just do -security then?
<soren> StevenK: Because it's not a security fix?
<StevenK> In which case both fixes can be put in an SRU
<soren> StevenK: That's what I suggested to begin with?
<StevenK> It seems so, so I'll shut up now. :-)
<soren> StevenK: :)
* TheMuso chuckles at d-i offering my irda device as a network device.
* Hobbsee now remembers why she was going to change the name of this machine to OnFire
<pitti> Good morning
<Hobbsee> morning pitti!
* StevenK waves to pitti
<pitti> hey StevenK
* StevenK thinks he has run out of NBS work to do.
<pitti> StevenK: great! so the remaining ones are just unsolvable?
<StevenK> pitti:
<StevenK> Oops.
<StevenK> pitti: libspandsp1 is the exception, it's waiting for a new asterisk-spandsp-plugins to hit Debian.
<pitti> ah
<StevenK> pitti: The others either FTBFS completly, or the API has changed completly and upstream hasn't fixed it.
<StevenK> Actually, libatlas-cpp-0.6-0c2a will be done when a new sear hits Debian
<pitti> soren: do you have some time to give a spin to the server CDs?
<StevenK> Hrm. I think the reason graphicsmagick blows up on ia64 is the same reason ps2pdf does.
<soren> pitti: Sure. The current dailies?
<StevenK> pitti: And those 3 libgcj7-0 packages blow up due to Java changes.
<pitti> StevenK: ok, so let's not care
<pitti> soren: right, the ones mentioned in the iso tracker (still /current)
<pitti> soren: congrats for being the only European server team member :)
<pitti> soren: don't do them all, of course, let some to mathiaz and dendrobates as well
<soren> pitti: <g>
<doko> pitti: please approve freetds, changed b-d to avoid sucking in libglib1.2-dev from universe
<soren> pitti: "upgrade" is from Feisty, I presume?
<pitti> soren: right
<pitti> doko: ah, evil; libglib-dev
<soren> pitti: I'll do it when my ISO's are done rsyncing . I'm pushing a mysql upload the other way through my poor internet connection, so everything is a bit slow.
<pitti> soren: oh, new mysql orig.tar.gz?
<pitti> doko: hm, that doesn't seem to be on the CDs
<soren> pitti: Actually and old one. :)
<soren> pitti: I'm using my PPA to test a patch for a Dapper SRU and that apparantly required the orig.tar.gz too.
<soren> pitti: Where are the testing procedures described? I'm not sure whether I should just 'apt-cdrom add && apt-get dist-upgrade' or I should use update-manager-core ?
<soren> pitti_: (resending as I'm guessing you lost your connection?) Where are the testing procedures described? I'm not sure whether I should just 'apt-cdrom add && apt-get dist-upgrade' or I should use update-manager-core ?
<Hobbsee> soren: use the update-manager-core, usually
<soren> Hobbsee: Alright. _ISO_-testing just confused me. :)
<Hobbsee> soren: well, most of it is iso's :)
<Hobbsee> soren: wait, are you testing a dist upgrade, or a cd?
<Hobbsee> soren: as in, dist-upgrade, or clean install
<soren> Hobbsee: It just says "upgrade", which pitti says is an upgrade from Feisty.
<Hobbsee> oh right, yes.
<Hobbsee> then it's a dist-upgrade, with the upgrade manager
<soren> "do-release-upgrade -d" says "Checking for a new ubuntu release\ncurrent dist not found in meta-release file\nNo new release found".
<Hobbsee> i thought it was update-manager -d
<soren> That's the graphical thing. I'm testing the server ISO's.
<pitti> soren: hm, maybe try with good ol' apt-get dist-upgrade?
<pitti> that should still work IMHO
<soren> pitti: Probably.
<Hobbsee> soren: okay, where's the duncecap.  duh.
<soren> Hobbsee: :)
<Hobbsee> i knew that, i'm sure i did.
<stgraber> morning
<Hobbsee> morning stgraber
<pitti> hi stgraber
<dholbach> good morning
<Hobbsee> morning dholbach!
* Hobbsee hugs dholbach 
<dholbach> hi Hobbsee
* dholbach hugs Hobbsee back
<stgraber> morning dholbach
<dholbach> hey stgraber
<cjwatson> soren: 'DEBEMAIL=somethingelse@example.com debuild' will suppress the maintainer check
<soren> cjwatson: Ah, great. Thanks.
<dholbach> Riddell: what do you think about bug 112414?
<ubotu> Launchpad bug 112414 in kdeedu "Error: Could not find service 'kfmclient' using Gnome" [Low,Confirmed]  https://launchpad.net/bugs/112414
<dholbach> Tonio_: can you take a look at bug 113972?
<ubotu> Launchpad bug 113972 in ktorrent "wrong link in .deb summary" [Low,Confirmed]  https://launchpad.net/bugs/113972
<dholbach> bryce: if you have a sec for bug 117939 - that'd be nice
<ubotu> Launchpad bug 117939 in inkscape "tutorial-basic.svg has wrong text" [Undecided,Confirmed]  https://launchpad.net/bugs/117939
<Tonio_> dholbach: oki that'll be fixed today
<Tonio_> dholbach: seems to be a veeeeeeeeeeeeery old issue :)
<Riddell> dholbach: hmm, tricky, that would require edubuntu to ship konqueror, which they wouldn't want
<Riddell> dholbach: ideally we should port kstars or the method it runs to call xdg-utils
<dholbach> rock on Tonio_
<dholbach> Riddell: ah great - idea - can you add that comment to the bug? maybe somebody picks it up... in the meantime, I'll un-assign it from ubuntu-main-sponsors
<dholbach> doko: do you know anything about what's happening with bug 122442?
<ubotu> Launchpad bug 122442 in sun-java6 "Memleak in Sun Java 6 on ubuntu feisty" [Wishlist,In progress]  https://launchpad.net/bugs/122442
<doko> dholbach: no, didn't look at it
<infinity> Riddell: a) soprano is dep-wait on a library not in feisty, b) why is it in main in fesity-backports, when it's in universe in gutsy?
<Riddell> infinity: libqt4-dev (>> 4.3~beta~)  is in feisty-backports
<infinity> Wait, two tildes in a version?  Is that a typo?
<Riddell> could be, it comes from debian
* dholbach hugs infinity
<infinity> Riddell: So, the more curious question, though, why was it accepted to main?
<Riddell> infinity: does soyuz put backports into main by default?
<infinity> Riddell: Anything NEW is ain main by default... One needs to override it.
<infinity> And I assume it was NEW, cause it wouldn't have been in the feisty overrides.
<pitti> cjwatson: ooh, oem install now skips gdm and has that new icon; shiny!
<Riddell> infinity: yes, it was, I'll add a note to the documentation
<infinity> Riddell: Anyhow, I'll move the source package to universe now.
<infinity> Riddell: And I suspect that soyuz is choking on that bizarre version comparison and not clearing the dep-wait, so I'll have to fiddle with it by hand in the DB... (ph34r!)
<Riddell> infinity: I can upload a fixed version if that's easier
<soren> infinity: I have a mysql question for you.. AFAICS the mysql-server (unversioned) package is there to depend on the preferred mysql-server-x.x package, but it also does all sorts of black magic in its maintainer scripts.. Any work needed to migrate to e.g. m-s-5.1 should be in m-s-5.1's postinst, surely?
<infinity> soren: The black magic is specifically for people who are tracking "default versions"... People who install a specific version most likely want that, and will never be auto-updated...
<soren> infinity: So if I have 4.1 installed, and I install 5.0.. What would happen?
<soren> infinity: How is it different from e.g. what our linux-meta package is supposed to do?
<infinity> Oh, I see...
<pitti> a-haa
<pitti> it seems that esd is responsible for a large portion of session hangs
<infinity> soren: The "black magic" in the mysel-server preinst is for migration from before mysql-server packages were versioned.
<soren> I see the sense in having a meta package, but the migration bit belongs in the actual packages, I think.
<infinity> soren: 4.1->5.0 should, in theory, be covered by the 5.0 scripts (and same for 5.1)... This is for 3.xx and 4.0, which were just "mysql-server".
<soren> infinity: Ah, so it should just be removed?
<infinity> soren: I'm not keen on removing it, no. :)
<soren> gah..
<infinity> soren: You may be surprised to know that I still have a MySQL 3.xx installation somewhere. :)
<infinity> And a few 4.0
<infinity> (Okay, anyone who knows me won't be surprised by that at all)
<infinity> I think I still have a potato box behind a firewall somewhere.
<soren> infinity: Well, since Ubuntu has had versioned mysql-server packages since Hoary, I don't see any harm in removing it here.
<infinity> Riddell: It's just as easy for me to fiddle with the DB.  Besides, I'm waiting on a publisher run for the override change to commit anyway, so it's not like there's a rush.
<infinity> soren: Err...
<infinity> soren: Default mysql in breezy was 4.0, and it was unversioned.
<infinity> soren: The versioned "4.1" was in universe.
<soren> infinity: Aw, crap.
<soren> infinity: You're right.
<infinity> soren: Is the preinst causing you grief, or are you just offended by its continued existence?
<soren> infinity: The former.
<infinity> soren: (And people complaining about preinsts stopping daemons doesn't count as "grienf")
<soren> infinity: It stops the running mysql. It's pointless.
<infinity> Or grief.
<soren> infinity: If it doesn't start it again, it counts.
<soren> infinity: Which it doesn't.
<infinity> "OH NOES, WHILE UPDATING MY DATABASE SERVER, IT WENT OFFLINE FOR A FEW MINUTES!" has never been a convincing argument to me.
<infinity> soren: It gets started in postinst...
<soren> infinity: Yes, mysql-server-5.0's postinst.
<infinity> soren: Oh, hrm.  Which would be a problem if youonly updated the metapackage for some bizarre reason.
<soren> infinity: So if you have mysql-server-5.0 installed and later install mysql-server, you're left without a running mysql.
<infinity> soren: Okay, see, now we have a real bug, rather than "why is that there/"
<infinity> soren: And, yet, it's been like this for ages, and I've never seen anyone complain about it going down and never coming back...
<soren> infinity: There's a debian bug about it too.
<soren> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=415124
<ubotu> Debian bug 415124 in mysql-server "transitional package mysql-server stops server in preinst" [Normal,Open] 
<infinity> "At least I guess that it's not a grave issue as it's unlikely that
<infinity> mysql-server gets upgraded at a different time than mysql-server-5.0."
<infinity> I'm inclined to agree with that, from an "is this RC" perspective...
<infinity> But it should be fixed, yes.
<soren> At least Ubuntu doesn't have a "we-only-fix-grave-bugs" policy :)
<infinity> I could just toss a version check in the preinst, so we only bother with upgrade magic if upgrading from an ancient MySQL.
<soren> That's what I'm doing, too.
<infinity> soren: We have no such policy, but we certainly do have a policy that looks a lot like that as we approach release. :)
<soren> infinity: But if you do it in Debian, that's even better.
<infinity> soren: I prefer not to diverge from Debian with MySQL.  The few times I did, it became a headache almost instantly, which is why I joined the Debina MySQL team in the first place, to keep us in sync. :)
<pitti> doko: libquicktime-dev has the same problem
<soren> infinity: Oh, I thought you were on the team since the dawn of time.
<pitti> doko: I think the dependency can just be dropped, it was probably due to .la files in libdv-dev
<infinity> soren: Didn't have commit access until 2 years ago or so.  Had plenty of code in the packages since 3.23 or so, but never bothered to "join a team".
<infinity> soren: Team maintenance is a reasonably new concept in Debian, after all. :)
<soren> infinity: Ah, right.
<infinity> soren: (New, from the point of view of someone who's been contributing for a decade)
<soren> infinity: So... You'll fix it in Debian?
<infinity> soren: Yeah.  I shall.
<infinity> soren: And then I'll just sync.
<infinity> soren: After this candidate release, that is... This bug isn't RC. :)
<soren> infinity: Sure, sure.
<soren> infinity: Thanks!
<infinity> soren: I do have the attention span of a gnat on speed, though.  Can you mail me a reminder, so I get around to uploading to Debian later today?
<soren> infinity: Sure. Would assigning the Ubuntu bug to you be sufficient, or would you rather have "regular" e-mail?
<doko> pitti: fixed
<infinity> soren: Real email.  My Malone bugmail can get lost in the flood off.... Ohter Malone bugmail.
<soren> infinity: Just as I thought. :)
<soren> infinity: done
<pitti> seb128: I'm experiencing a lot of hangs when starting the sessions on live CD and installed systems; did you notice them, too?
<pitti> seb128: I'm starting to blame esd again, as soon as I killed it it continued to start
<pitti> seb128: (the other half is compiz/mesa/aiglx crashing kernel)
<seb128> happened a few minutes ago on my laptop, desktop applications were frozen
<seb128> killing esd make them work again
<seb128> but that was after suspend, I don't think it happened on boot
<seb128> did we have any esound patch before?
<pitti> no, esound didn't change for ages
<seb128> there is a new version which has been uploaded not too long ago and the update has been made by one of the new contributors
<seb128> well, it did
<seb128> I'm just wondering if a patch might have been dropped or something
<pitti> seb128: I have to look
<pitti> seb128: erk, indeed; current version does not have *any* ubuntu patches
<pitti> grrr
<ogra> throw it out !
<pitti> ogra: fixing libgnome is not *that* trivial, but it's still on my wishlist
<ogra> ++
<ogra> there was this patch back then :)
<pitti> ogra: oh?
<ogra> seb128, what was the bug # for the gstreamer patch ?
<infinity> Hobbsee: freeze exception for a new livecd-rootfs to make Xubuntu builds happy?
<ogra> pitti, its for an old version
<pitti> ogra: hm, I hoped for something simple, like using aplay or so
<infinity> Hobbsee: (Doesn't touch anything but Xubuntu)
<ogra> not sure it would work with recet libgnome
<pitti> infinity: go ahead (Hobbsee is on phone, and we need that urgently)
<ogra> and it was never completely finished
<infinity> pitti: Well, I could have approved it myself too, I was trying to use proper channels. :P
<pitti> infinity: I still have an RM hat :)
<infinity> pitti: So do I. :)
<seb128> pitti: did we use to have ubuntu patches to esound?
<pitti> seb128: yes, we did
<pitti> seb128: one was the mutex to fix the session start hang
<seb128> ah
<pitti> seb128: I'll reapply them now
<seb128> ok, thanks
<pitti> what a mess...
<seb128> dholbach: I think it's you who sponsored the update, do you know if there was a reason to the change?
<infinity> pitti: Uploaded.  I may go for a smoke, want to make sure it's accepted before the hour?
<pitti> infinity: yep, will
<pitti> thank you
<pitti> doko: weird change for libquicktime-dev; can't the glib dependency be dropped entirely?
<pitti> :q
<pitti> whoops
<doko> pitti: didn't look too close ...
<infinity> And when that fails to kill IRC...
<infinity> :q!
<infinity> :q!!!!
<infinity> :argh!
<infinity> (And I believe I've just described ever new vi user's first experience....)
* pitti disables focus-follows-inadvertent-mouse-movement
* soren -> lunch
<StevenK> Well, so much for the theory that eating something hot for dinner would warm me up.
<pitti> seb128: oh dear, the Debian patches to this are a mess as well...
<infinity> Oh, wow, I spelled "gutsy" correctly on that upload.  I'm learning.
<dholbach> seb128: no, I don't know - sorry
<infinity> (I could have an entire maildir dedicated to "rejects of uploads to gusty")
<pitti> infinity: trust vim's highlighting :)
<Hobbsee> infinity: that's why you run gutsy - so you never have to type it
<infinity> Yeah, I'm offended by the new behaviour of dch, to be honest.
<infinity> The old "use the last dist in the changelog" behaviour was much saner for my workflow.
<infinity> Since I develop in chroots, but use helper tools in the base system.
<infinity> I can't be alone in that, but I can't be bothered to argue the point either.
<StevenK> infinity: I'm with you on that one.
<pitti> stgraber: can you please invalidate the ubuntu and edubuntu lives and alternates? we need to fix bug 21915
<ubotu> Launchpad bug 21915 in esound "esound causes desktop session to hang" [Critical,Confirmed]  https://launchpad.net/bugs/21915
<pitti> ogra: ^ actually, why do you still install esound by default? I thought you were using pulse now?
<ogra> pitti, gnome-session dep
<Hobbsee> pitti: i should be able to do that
<pitti> ogra: edubuntu-desktop pulls it in, too
<ogra> oh, i'll drop that
<pitti> ogra: and no, gnome-session does not depend on it
<ogra> it did
<ogra> something in there did at least
<pitti> ogra: hm, it B-deps on esound; how weird
<ogra> we're waiting for the livefs tools anyway, dont we ?
<pitti> dependencies are just ubuntu- and edubuntu-desktop and ... system-config-cluster???
<ogra> i can quickly fix the seeds
<pitti> ogra: just for xubuntu
<ogra> ah
<pitti> ogra: yeah, that might be even more beneficial to you
<fabbione> pitti: feh yes :(( one gnome python module pulls esound in indirectly
<pitti> ogra: if you can upload a new edubuntu-meta quickly?
<fabbione> pitti: it is used but no Depends:
<pitti> fabbione: shouldn't it just depend on libesd?
<fabbione> pitti: i can personally drop it is system-config-cluster even now.. but somebody needs to fix pysomething
<pitti> fabbione: don't worry about it for now
<fabbione> pitti: let me check
<stgraber> pitti: sure
<pitti> fabbione: for tribe-3 I'll reapply the esound fix
<StevenK> Fix pysomething hrm?
<pitti> in the future we should really get rid of it, though
<fabbione> pitti: it's something i meant to look at but always forgot
<stgraber> pitti: ok, they are now disabled, ping me when the new ones are available
<infinity> Riddell: My hammer appears to have been applied successfully... Overriding to universe and accepting the binaries.
<fabbione> pitti: looks like the python module has been fixed. i can drop the Depends at the next upload
<fabbione> pitti: if you want i can do it right away
<fabbione> your call
<pitti> fabbione: sure, it doesn't affect the CDs (or does it affect server?)
<Riddell> infinity: thanks
<pitti> fabbione: uploading is always fine, btw
<fabbione> pitti: it should not affect CD's
<pitti> esound uploaded
* seb128 hugs pitti
<seb128> that was quick
<pitti> seb128: well, only the two critical patches to fix the session hang
<pitti> seb128: 98% of the diff are still missing :/
<fabbione> pitti: done
<pitti> seb128: but instead of investing a large amount of work there, I'd rather spend it on libgnome TBH
<seb128> maybe easier to use the previous gutsy package as a base and update this one to the new version
<pitti> ogra: so you are going to change the seeds/
<pitti> ?
<seb128> right
<cjwatson> seb128: if nobody has already, can you talk to the uploader of esound and make sure he understands the negative consequences of dropping patches like that?
<ogra> pitti, done already, waiting for the ./update run to finish
<pitti> ogra: cool, thanks
<seb128> cjwatson: the uploader is dholbach I think, the updated is one of the new contributors, will check and talk with him
<Hobbsee> seb128: take a large hammer :P
<seb128> s/updated/updater
<cjwatson> seb128: sorry, I meant the changed-by
<ogra> pitti, do you do ubuntu or shall i do that as well
<ogra> ?
<pitti> ogra: no, we won't change ubuntu seeds
<ogra> ok
<seb128> cjwatson: right
<cjwatson> though possibly dholbach should have double-checked too :)
<pitti> ogra: I just uplaoded a fixed esound (hopefully)
<ogra> well, lets drop it asap if we can somehow
* cjwatson wonders whether it'd make sense to ship a .bzr tree for the corresponding seeds in the -meta source packages so that ./update runs more quickly
<ogra> good idea, but that requires some discipline to not get out of sync with the real seeds
<dholbach> seb128, cjwatson, pitti: I'll add esound to my list
<seb128> dholbach: list of what?
<pitti> dholbach: what list in particular? 'packages to kill'?
<dholbach> todo list
<ogra> dholbach, we'll need soe patch that replaces esound with aplay in libgnome or so ...
<dholbach> pitti said that things in the diff were missing
<pitti> dholbach: WDYT of spending the effort on libgnome instead? that makes much more sense IMHO
<ogra> *some
<pitti> dholbach: well, the entire diff was missing :)
<dholbach> I'll check if I didn't upload the wrong package or something :-/
<cjwatson> ogra: nope, ./update could still bzr update it
<cjwatson> ogra: it'd be exactly as much in sync as the other files in the -meta source packages
<ogra> cjwatson, ah. right
<dholbach> pitti, ogra: I don't really know much about esound and libgnome - I'd prefer if somebody else did that
<pitti> dholbach: right, I meant, do you agree to the general approach?
<ogra> given that anyone who changes the metapackages has a local branch anyway you could also use a variable to point to it :)
<pitti> esound is and remains a PITA with and without our an Debian's patches
<ogra> and is unmaintained
<dholbach> pitti: I don't know anything about it - I merely wanted to make sure that patches which were dropped because I did not review it properly are back in the package
<dholbach> I'm happy if we can drop it, but I don't see myself contributing much to that
<Hobbsee> ogra: have you seen https://bugs.launchpad.net/ubuntu/+bug/126736 and https://bugs.launchpad.net/ubuntu/+bug/126735 yet?
<ubotu> Launchpad bug 126735 in Ubuntu "edubuntu 2007.07.17.1 live cd's stay on gdm" [Undecided,New] 
<ogra> Hobbsee, i saw stgrabers ping ... just rsyncing the last image
<dholbach> in the meantime, I'll get back to preparing my talk for ubuntulive
<cjwatson> ogra: there actually is one, in update.cfg ...
<cjwatson> ogra: though you have to remember to change it back before uploading
<pitti> dholbach: right, that's fine
* dholbach hugs super-pitti
<ogra> hum
<ogra> Hobbsee, could it be that your edubuntu-meta upload stil sits in the queue ?
<cjwatson> ogra: also if the seed change was more than 15 minutes or so ago you can just change sftp to http; sftp is used because it doesn't have a propagation delay
<pitti> ogra: no -meta in unapproved
<Hobbsee> ogra: that was days ago
<Hobbsee> ogra: as in, days before i asked pitti to freeze
<ogra> my source appraently wants to add it with a freshly pulled -meta source package
* ogra scratches head
<ogra> did the update script change ? it seems my change was just added to Hobbsee's changelog entry
<ogra> instead of producing a new one
<Hobbsee> ogra: possibly because there were no changes
<Hobbsee> ogra: i found that when i tried to update edubuntu meta
<Hobbsee> sorry, ubuntu-meta
<ogra> well, there is a change it properly adds to the changelog
<ogra> but it doesnt seem to use the -i switch for dch
<pitti> hm, maybe germinate-update-metapackage changed recently?
<Hobbsee> it hsould be using dch -Ui
<ogra> at least -i :)
* ogra checks if his germinate is up to date
<pitti> ogra: fix /usr/bin/germinate-update-metapackage, line 316
<pitti> cjwatson: ^ I think this is a recent regression
<pitti>         os.system("dch -U 'Refreshed dependencies'")
<pitti> should be -iU
<ogra> yeah
<pitti> ogra: just change it locally for now, or first do a dch -i 'foo' and ./update
<pitti> ogra: or, just manually fix the changelog :)
<ogra> pfft ... always the easy way ...
<pitti> ogra: yeah, it's just, you are in the critical path now :)
<ogra> sadly it overwrote the timestamp already
<pitti> ogra: you can get the old changelog from the old diff.gz
<pitti> erm, tar.gz
<ogra> i know
<ogra> fiddlsy
<ogra> *fiddly
<infinity> Or just unpack the source and try again? :P
<cjwatson> pitti: wha? -U has always been equivalent to -iU for me
<pitti> cjwatson: oh? never for me...
<pitti> cjwatson: maybe you have a secret alias or so?
<cjwatson> $ type dch
<cjwatson> dch is /usr/bin/dch
<cjwatson> oh, hmm
<cjwatson> I have this in ~/.devscripts:
<cjwatson> DEBCHANGE_RELEASE_HEURISTIC=changelog
<cjwatson> infinity: ^-- which might be closer to what you want ...
* infinity kisses cjwatson;.
<cjwatson> ok, I'll fix germinate, sorry about that.
<ogra> pitti, uploaded
<pitti> yay
<ogra> heh, neat http://www.artecgroup.com/thincan/
<pitti> ogra: diff looks fine, accepted
<ogra> i wonder if US customs would let you in with such a thing in your hand luggage
* ogra goes for some coffee
<pitti> ogra: looks really cool
<infinity> Yeah, I want 12.
<pitti> "A sixpack of thincans, please"
<Hobbsee> heno!
<pitti> hey heno
<heno> hey Hobbsee and pitti!
<stgraber> heno !!! :)
<heno> stgraber: hey :)  I've been on the road a bit ...
<heno> (now in London)
<pitti> seb128, dholbach: I got libgnome working with aplay \o/
* seb128 hugs pitti
<dholbach> pitti: WOW!!!
<pitti> debian/patches/11_aplay_fallback.patch -> hacks'r'us
<pitti> I let that run on my box for a while
<stgraber> Yeah, going to a world without esd :)
<Hobbsee> as long as you dont pick one with arts instead...
<StevenK> Here's hoping artsd dies with KDE 3
<lamont> StevenK: kde dying?  dare we hope? :-
<lamont> )
<stgraber> perfect world would be everything working just fine with alsa and pulseaudio or similar for networked sound
<pitti> dholbach: http://people.ubuntu.com/~pitti/tmp/11_aplay_fallback.patch, I mean
* lamont ducks
<ogra> pitti, sweet, thats all ?
<pitti> ogra: well, we should still these nasty "/bin/sh: /usr/bin/esd: not found" warnings
* ogra cant belive we didnt use that since ages 
<pitti> I don't know exactly where they come from
<pitti> ogra: it's the smallest possible patch I can see, and it's not terribly evil
<ogra> not at all
<mantiena-baltix> hi asac
<asac> mantiena-baltix: hi
<pitti> ogra: the evilness is that it always starts a process for every plop, so it's quite resource hungry compared to esounds' cached samples
<ogra> pitti, well ...
<pitti> OTOH, if our only default sound events are login and logout, that doesn't matter at all
<pitti> if we enable menu clicks by default, then it's worse
<ogra> thats what i was about to say
* Hobbsee makes LamontPudding
* simira waits for UPS to come and take away her laptop :(
<Hobbsee> simira: it broken?
<simira> there they are....
* lamont likes being pudding
<simira> Hobbsee: mm
<Hobbsee> simira: darn
* Hobbsee serves it to everyone at the next UDS.
<mantiena-baltix> asac: I've applied patch debian/patches/23_nm-monitor-eni.diff from n-m from gutsy (see bug #61089 ) agains feisty's network-manager but it seems manual network configuration still doesn't work as should, at least on LiveCD :( I've Noticed, that when I download some file to desktop then I still don't see this file on desktop, I must press CTRL+R manually if I use LiveCD
<ubotu> Launchpad bug 61089 in network-manager "NM should notice changes to /etc/network/interfaces automatically" [High,In progress]  https://launchpad.net/bugs/61089
<Riddell> !CoC | lamont
<ubotu> lamont: The Ubuntu Code of Conduct to which we ask all Ubuntu users to adhere can be found at http://www.ubuntu.com/community/conduct/
<pitti> hm, except that login and logut sounds don't actually seem to work
<pitti> ogra: confirmed, on a fresh profile there's just these two, no menu plopps
<mantiena-baltix> asac: maybe inotify doesn't work on LiveCD ?
<ogra> pitti, yup, does it stutter or something if you enable all soundss ?
<ogra> -s
<asac> mantiena-baltix: hmmm ... actually i have no idea about how livecd works in detail
<lamont> Riddell: ??
<asac> mantiena-baltix: the patch just makes network manager reread interface file after you modified it.
<asac> mantiena-baltix: what fix did you expect?
<pitti> ogra: stutter? no, why? aplay introduces latency, not stutter
<ogra> ah
<mantiena-baltix> asac: I expect to fix important problem, described in https://bugs.launchpad.net/baltix/+bug/5364/comments/22 ? Users never understand. why they have manually to deactivate and, later, activate again network interface after they setup static IP configuration :(
<ubotu> Launchpad bug 5364 in network-manager "Can't use static ip address with network-manager (and thus no VPN connections menu for static users)" [Wishlist,Confirmed] 
* ogra should stop working with 200MHz/64MB HW ... there a bit of latency equals stutter very often :)
<pitti> stgraber: the edubuntu server-addons will be rebuilt as well, btw
<pitti> stgraber: noone tested them so far, so that won't hurt
<Hobbsee> pitti: ok, will mark as such
<stgraber> ok
<ogra> we should propapby start testing them, even though LaserJock's changes are pending
<ogra> *probably
<ogra> bryce, already around ?
<pitti> ogra: bug 126735?
<ubotu> Launchpad bug 126735 in Ubuntu "edubuntu 2007.07.17.1 live cd's stay on gdm" [Undecided,New]  https://launchpad.net/bugs/126735
<infinity> pitti: Testing xubuntu build on i386 to make sure it's vaguely sane...
<pitti> infinity: oh, ok
<pitti> infinity: I schedule new ubuntu and edubuntnu livefs builds in 50 minutes
<ogra> pitti, still waiting for rsync to finish, will check shortly, smells like casper has a prob
<pitti> infinity: do you do for-project xubuntu cron.daily, too?
<pitti> infinity: if they work, we may as well publish them
<infinity> pitti: Looks like it's doing the right thing.  I just triggered it manually on terranova.  I can do the other arches too.
<pitti> infinity: ok; please do xubuntu builds right now, so that they are finished in < 50 minutes
<infinity> pitti: Sure thing.  We're only worried about live here, right?  install was fine?
<pitti> infinity: I'm heading off for lunch and supermarket, so I started the publisher now and a "sleep 50m && <build images"
<pitti> infinity: right
<pitti> infinity: hm, it's not yet there, should I maybe just include it in my && chain?
<infinity> pitti: "it"?
<pitti> xubuntu live builds
<infinity> pitti: I'm doing the livefs builds right now.  If you want to do the live image builds later, that's cool.
<pitti> infinity: ah, good; nevermind me, then
<infinity> pitti: Or I'll do the image builds before you get back.  Pick one.
<pitti> infinity: I didn't see an ssh for this on lithium, so I guess you are working directly on terranova :)
<infinity> Yeah.
<pitti> infinity: please trigger the cron.daily_live once its finished then
<infinity> Will do.
<pitti> infinity: cheers
<dholbach> evand: I commented on your gok udpate: http://revu.tauware.de/details.py?upid=5998
<asac> mantiena-baltix: do you see in syslog that network manager rereads interfaces after you edit it?
* lamont wonders if there's a way to tell network-mangler to leave an interface alone yet
<ogra> hmm, i see a lot of "grep: /var/log/Xorg.6.log: No such file or directory" in my thin client session .xsession-errors
<ogra> is that something the compiz code uses ?
<stgraber> ogra: indeed it'd be pretty hard for the server to access the thin client /var/log :), that's maybe used by compiz to know if AIGLX is available
<ogra> well, on my i910 client compiz works just fine, it seems to do no harm ...
<ogra> it just spams the log a lot
<mantiena-baltix> asac: it seems no, in /var/log/syslog I see lots if things, maybe you could tell me exactly which string I should search in /var/log/syslog
<mantiena-baltix> ?
<stgraber> ogra: so they should check if LTSP_CLIENT is set and if yes not try to access the /var/lob/Xorg.6.log (parsing Xorg.6.log can still be done on the client and result put in a variable when connecting with ssh)
<ogra> stgraber, do you happen to have a running edubuntu live session around ? somehow my rsyncs fail today still didnt get the live iso down
<ogra> stgraber, exactly ...
<stgraber> ogra: I've it on CD just next to me yes
<ogra> it happens after the session is started, so easy to inject via ldms new rc scripts ;)
<stgraber> ogra: I can give you a ssh access on it if you want
<ogra> could you just check if "AutomaticLoginEnable=true" is set in  /etc/gdm/gdm-cdd.conf ?
<ogra> thats what casper should add from an initramfs script
<asac> mantiena-baltix: hmm ... 'nm_info ("/etc/network/interface changed: rebuilding the device list.");'
<asac> mantiena-baltix: search for changed
<ogra> i see no changes in the casper code and edubuntu-artwork didnt change since ages, so the file should be there and casper suld have modified it
<mantiena-baltix> asac: ok, I will disconnect for a while
<ogra> if thats the case my only idea is that gdm doesnt read it anymore
<asac> pitti: can you take a quick look if ffox is building in edgy and feisty security network?
<stgraber> ogra: AutomaticLoginEnable=false in gdm-cdd.conf
<stgraber> ogra: then an empty AutomaticLogin= the line after
<ogra> aha
<stgraber> ogra: but AutomaticLoginEnable=true and AutomaticLogin=ubuntu in gdm.conf
<ogra> bad ...
<stgraber> gdm-cdd.conf pointing to /etc/alternatives/gdm-cnfig-derivative
<stgraber> gdm-cdd.conf pointing to /etc/alternatives/gdm-config-derivative
<ogra> right
<ogra> which should point to /usr/share/edubuntu-artwork/gdm/gdm-cdd.conf
<ogra> i wonder why casper isnt using it for adding the username
<Hobbsee> elmo: ping
<ogra> stgraber, i assume you see the edubuntu theme on gdm
<stgraber> ogra: yes
<ogra> hmm, the code uses  if [ -f /etc/gdm/gdm-cdd.conf ]  ...
<ogra> heh
<ogra> which doesnt work on broken links
<ogra> (the test is not running chrooted, so /etc/gdm/gdm-cdd.conf points to nothing existing)
<ogra> i guess we need to change that to "if [ -L /etc/gdm/gdm-cdd.conf ]  ..."
<ogra> seems not to break even on broken links
<ogra> sigh
<ogra> why did that work before
<ogra> we're using alternatives since -artwork exists for that ...
<ogra> hmm, coreutils changelog doesnt indicate any change to the test binary
<ogra> i really wonder why that ever worked
* ogra pokes cjwatson about http://codebrowse.launchpad.net/~ubuntu-core-dev/casper/trunk/revision/cjwatson%40canonical.com-20070703095403-ukwkjxe6hnfa9jse?start_revid=ogra%40ubuntu.com-20070718124705-jvoqav0uevn5nilh
<ogra> ... and points him to http://codebrowse.launchpad.net/~ubuntu-core-dev/casper/trunk/revision/ogra%40ubuntu.com-20070718124705-jvoqav0uevn5nilh?start_revid=ogra%40ubuntu.com-20070718124705-jvoqav0uevn5nilh
<ogra> alright then, i'm pretty sure that breaks on xubuntu as well ...
<ogra> Hobbsee, any opinion from the release manager POV ? Bug #126735 will prevent both, edubuntu and xubuntu form doing autologin ...
<ubotu> Launchpad bug 126735 in casper "edubuntu 2007.07.17.1 live cd's stay on gdm" [High,Fix committed]  https://launchpad.net/bugs/126735
<Hobbsee> ogra: ubuntu too, surely?
<ogra> pitti, as well ^^^
<Hobbsee> he's out
<ogra> Hobbsee, nope
<cjwatson> ogra: sigh, oops
<ogra> Hobbsee, only distros using gdm-cdd.conf
<cjwatson> sorry, that hadn't occurred to me - my bad
<Hobbsee> ogra: ah right, which i assumed was all gdm-based flavours
<ogra> cjwatson, not sure we need an || [ -e ... ] 
<ogra> currently all derivatives should use alternatives ...
<ogra> but if not it would break
<Hobbsee> cjwatson: please accept that, then, and restart any builds for xuubntu, edubuntu.
<Hobbsee> bah.  it'd help if i could spell
<cjwatson> ogra: maybe it would be better to just revert my change
<cjwatson> once you have to do two tests, there's no saving in not just chrooting
<ogra> cjwatson, hmm indeed
<cjwatson> and stick a comment above it explaining why it chroots
<Hobbsee> ah, point
<ogra> well, we shouldnt have any derivatives using the file directly
<Hobbsee> oh bleh, i'ts not even in the archive yet, so ignore my statement.
<ogra> as long as we can rely on that it will work
<ogra> and save a bit
<cjwatson> ogra: I do think it would be better to revert my change and add a comment. That old code was tested
<ogra> oki
<Hobbsee> ogra: with my RM hat on, i'll say that we ahvent actually lost a lot, as xubuntu is currently building (i think, based on what was said here), and edubuntu needs rebuilding anyway.
<Hobbsee> so we havent actually lost much time, and it does look like something that needs fixing.
<ogra> oki
<Hobbsee> ogra: as for the best way to do it, discuss that with cjwatson :)
<ogra> i'll care fr casper
<ogra> (have to revert my change as well )
<Hobbsee> yep
<pitti> ogra: that fix looks sane, if cjwatson has ack'ed it?
<ogra> pitti, nope
<ogra> wait a sec
<ogra> puching the right fix
<ogra> *pushing
<ogra> pitti, http://codebrowse.launchpad.net/~ubuntu-core-dev/casper/trunk/revision/ogra%40ubuntu.com-20070718130803-e985fi9vvj1byqh2?start_revid=ogra%40ubuntu.com-20070718131036-zkx95c53il1s94nm
<ogra> and http://codebrowse.launchpad.net/~ubuntu-core-dev/casper/trunk/revision/ogra%40ubuntu.com-20070718131036-zkx95c53il1s94nm?start_revid=ogra%40ubuntu.com-20070718131036-zkx95c53il1s94nm
<Hobbsee> looks sane
<ogra> pitti, that actually reverts the change completely to feistys behavior
<pitti> ogra: ok
<ogra> (is it feistys or feisties ?)
<pitti> ogra: out of interest, why don't you commit the changelog and the change in the same revision?
<Hobbsee> ogra: feisty's
<ogra> ok building the source pkg
<pitti> ogra: feisty's
<ogra> ah :)
<Hobbsee> yay, english!
<pitti> genitives FTW!
<ogra> pitti, i somehow got used to that in ltsp ...
<ogra> collecting changes before bumping the native version
<pitti> ogra: but changelog and change should be together for clarity; how is that related to the version?
<ogra> i see cjwatson uses UNRELEASED instead ... i should probably switch to such a beahvior as well :)
<pitti> ogra: right, that's what I use as well; and I commit the s/UNRELEASED/x.y.z/ as "release as x.y.z to gutsy"
<pitti> so that you can get any upload from the history and bzr log
<ogra> pitti, not at all ... its just the way i did it until now :)
<ogra> i usually collect the bzr logs and assemble a changelog right before a release
<ogra> silly extra work, but i dont miss anything from people who didnt do changelog entries in tehir branches
<pitti> stgraber: http://cdimage.ubuntu.com/daily/20070718/ (new ubuntu alternate) and http://cdimage.ubuntu.com/edubuntu/daily/20070718/ (new edubuntu alternate) with updated esound love
<pitti> Hobbsee: ^
<Hobbsee> hooray!  adding
<ogra> pitti, uploaded ... should be in the queue
<pitti> in two minutes
<asac> pitti: will this esound love help my laptop to boot livecd without switching to console and killing esd?
<ogra> asac, thats the plan
<pitti> asac: hopefully :)
<pitti> asac: tests heavily appreciated
* asac hugs pitti
<asac> if i would have time i would instantly test
<asac> but well ...
<stgraber> pitti: done
<Hobbsee> oh bah.
<Hobbsee> stgraber: i may have killed it then
<stgraber> Hobbsee: well, one of us did :)
<stgraber> we can't add the same build twice anyway :)
<Hobbsee> ahhh
<Hobbsee> i was trying to figure out how to specify the build - or does it automatically go to the latest build on cdimage?
<pitti> ogra: I would have appreciated a bug number in the changelog, but so be it
* pitti accepts and pushes through the publisher
<stgraber> at the bottom of the addbuild page, you can specify the milestone (default is Tribe 3) and the "Version number" which is in fact the build
<ogra> pitti, yeah, i alwas miss that, i closed bug #126735 manually
<ubotu> Launchpad bug 126735 in casper "edubuntu 2007.07.17.1 live cd's stay on gdm" [High,Fix released]  https://launchpad.net/bugs/126735
<pitti> thanks
<Hobbsee> stgraber: ah right, so leaving the version number blank will break it?
<stgraber> it won't add anything IIRC
<Hobbsee> ah right
<pitti> ogra: right, anything else that you need for edubunt ATM?
<ogra> testing :)
<pitti> great, so let's build new CDs
<ogra> nothing i'm aware of yet
* pitti starts publisher
<Hobbsee> pitti: yay!  \o/
<ogra> <- break
<pitti> stgraber, Hobbsee: http://cdimage.ubuntu.com/daily-live/20070718/
<Hobbsee> pitti: stgraber adding
<stgraber> done
<stgraber> now, let's wait on Xubuntu desktop and Edubuntu desktop (gdm autologin bug)
<stgraber> Xubuntu alternate i386 has now been entirely tested (4/4) without any bug or failure reported so far
<Hobbsee> surprising
<Hobbsee> ogra: were you able to reproduce http://launchpad.net/bugs/126736 ?
<ubotu> Launchpad bug 126736 in Ubuntu "edubuntu 2007.07.17.1 live cd's ubiquity/grub problem on install" [Undecided,New] 
<Hobbsee> oh, stgraber did.
* Hobbsee remembers to wait for the bug to load *first* before asking
<cjwatson> looks like it crashed midway through installing grub
<cjwatson> 15 : File not found
<cjwatson>      This error is returned if the specified file name cannot be found,
<cjwatson>      but everything else (like the disk/partition info) is OK.
<Hobbsee> oh neat.
<Hobbsee> oh, that's on the tab i didnt read yet.  duh.
<cjwatson> and since it doesn't display the final dialog, that supports the theory of a crash
<pygi> siretart, I'll try to give my thoughts on your mail later today when I'm back home
<Hobbsee> pygi!
<siretart> pygi: thanks!
<pygi> siretart, if you get that mail that joerg sent to him, please do forward
<pygi> hey Hobbsee ... sorry, been busy recently :(
<Hobbsee> pygi: no problem.  who hasnt?  :P
<pygi> Hobbsee, is there anything we need to fix on k3b more? I saw that patch was uploaded
<siretart> pygi: done
<pygi> siretart, thanks
<Hobbsee> pygi: unsure.  havent looked.  there's still mroe bugs open.  ask Tonio_
<pygi> Hobbsee, k, thanks
<Hobbsee> pygi: oh, btw - Tonio_ ended up committing that patch, but didnt close the bug.  i only found that out when trying to sponsor, and it telling me that that patch was already applied.
<Hobbsee> pygi: you left before i could tell you otherwise - i think i was at dinner
<pygi> Hobbsee, dont worry
<Tonio_> Hobbsee: hum isn't the bug supposed to close automatically reguarding to the changelog ? :)
<Chipzz> hrrrrm
<Hobbsee> Tonio_: only if you use the correct syntax - vi will colour it specially
<Tonio_> Hobbsee: seems to me that the syntax is correct, but I'll have a look
<Chipzz> pitti: you were working on getting gtk+ 1.2 demoted, right?
<pitti> Chipzz: it happened yesterday
<pitti> (and glib1.2)
<Chipzz> pitti: uhu
<Hobbsee> hiya BenC
<Chipzz> pitti: but you are not working on eliminating gtk+ 1.2 from as much packages as possible?
<pitti> Chipzz: only from the main ones
<Tonio_> Hobbsee: rahhhhh, # is missing.... sorry for this
<Chipzz> (ie packages in universe/multiverse)
<Hobbsee> Tonio_: ahhh, that'll do it.
<Hobbsee> Tonio_: no problem, i closed it a few days ago
<Chipzz> pitti: I was just checking out lame source code, and noticed it still bd's on gtk+1.2
<pitti> Chipzz: a lot of stuff still does
<ScottK> Tonio_/Hobbsee: There was an LP regression for a bit where automatic bug closing wasn't working.  Maybe that's why it didn't close.
<ScottK> Ah.  Nevermind.  Read to the bottom before responding.
<Tonio_> ScottK: well in that case that's a "myfault" issue :)
<Chipzz> pitti: I can look into rebuilding lame with gtk+2.0 (but I won't be putting too much time in it); would a patch be accepted?
<pitti> Chipzz: I'm sure it will
<pitti> Chipzz: if lame is actually ported to gtk 2?
<pitti> Chipzz: upstream would certainly appreicate this, since gtk 1.2 is obsolete and unmaintained
<Chipzz> pitti: I can just try a recompile against gtk+ 2.0 and see how much breaks; if not too much, I can try to fix it possibly
<pitti> ah, the optimistic approach :)
<BenC> Hobbsee: hi ya
<Chipzz> pitti: well, did that with mplayer once ;)
<Chipzz> it actually wasn't all too bad getting that ported to gtk+2.0 :P
<cjwatson> Chipzz: it can be a lot harder. putty upstream is working on a gtk2 port (I did some initial work on it), but there are still several problems there that are a good deal of work to fix
<cjwatson> notably, putty cares about fonts
* kylem chuckles.
<mjg59> So, uh.
<mjg59> Why did Launchpad just send me email thanking me for my contribution to INVALID?
<ogra> i got the same here
<ogra> but with a date from yesterday
<Hobbsee> mjg59: if my system is often coming on with full speed fan, where should i check for the problems?  syslog, ps aux for any processes eating cpu...anything else?
<Hobbsee> i believe that's your domain?
<ogra> Hobbsee, amitk as well ;)
<ogra> (if he's around indeed)
<mjg59> Hobbsee: Can you define it a bit more? Also, is there anything in /proc/acpi/fan ?
<Hobbsee> mjg59: almost about half the time now, my gutsy system comes on with full speed fan, about 5 seconds after grub.  i'll remove teh quiet later, and check what is actually starting at that section.  the machine seems to be running at about half speed indefinetly, until i reboot
<Hobbsee> it's not happening now, i'll check next time
<agoliveira> Something you might want to know. In my notebook, an Asus G1, suspend and hibernate are working perfectly with Gutsy but I had to update the nvidia driver to the latest version (100.14.11) which is not in the repositories yet.
<cjwatson> mjg59: don't know yet, but it happened to quite a few of us. pitti got several thousand
<ogra> urgh
<Hobbsee> mjg59: i've only got a syslog from when that happened this morning.  no idea if it's of any use.
<mjg59> Hobbsee: Hm. Sounds like the hardware thinks it's overheating.
<Hobbsee> mjg59: acpi -V said it was 25C, when i got to a VT.
<Hobbsee> mjg59: FWIW, http://rafb.net/p/0hWyWE69.html is the syslog
<mjg59> Hobbsee: Is there anything in /proc/acpi/fan ?
<Hobbsee> mjg59: there isnt now.   i'll check the next time it happens
* Hobbsee has rebooted since then, to not have to wait forever for anything to load
<mjg59> Hobbsee: That means the fan control is handled by your firmware, not Linux
<Hobbsee> mjg59: right.  which presumably means that linux is telling the firmware that it's far too hot, or something?
* Hobbsee wonders if it is https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.15/+bug/48395
<ubotu> Launchpad bug 48395 in linux-restricted-modules-2.6.15 "ipw3945 produces 99% cpu, making my laptop unusable" [High,Confirmed] 
<mjg59> Hobbsee: No, it's likely to be done entirely in the firmware
<Hobbsee> ah right
<mjg59> So yeah, one possibility is that something is actually using all the CPU
<mjg59> bootchart ought to be an easy way to see that
<Hobbsee> mjg59: right.
* Hobbsee will check later then
<cjwatson> mjg59: Spads has turned off outgoing mail from that system while it's looked into
<mjg59> cjwatson: Ta
* Hobbsee waves to seb128 
<seb128> hey Hobbsee
<calc> who is in charge or firefox work?
<Hobbsee> calc: asac
<calc> ok
<calc> asac: are you here, i found some annoying firefox packaging bugs
* calc might as well determine which files are buggy before telling asac
* calc bets at all of the pkgconfig files being buggy
<asac> i doubt so :)
<asac> calc: what is the problem?
<calc> wow only the two i need are broken :)
<asac> which are?
<calc> /usr/lib/pkgconfig/firefox-nspr.pc and firefox-nss.pc both refer to invalid include locations
<calc> they either should refer to the right locations(?) or there should be symlinks in /usr/include/firefox to nspr and nss
<calc> i'm guessing anyway...
<evand> dholbach: fixed and reuploaded
<pitti> hm, my expert instal doesn't mount /home with the reason that /dev/disk/by-uuid doesn't exist
<asac> calc: those are old ones ... which should go away
<pitti> what would be to blame for that?
<dholbach> evand: party on - will check it out in a sec
<asac> calc: use the ones provided by libnspr4-dev and libnss3-dev
<Hobbsee> morning mdz_
<calc> asac: yea except that programs use those and fail to build
<calc> typically people don't use pkgconfig files, other programs do
<calc> i'll try deleting them and see if it magically works :)
<calc> asac: should i file a bug to have those two invalid pkgconfig files removed?
<asac> calc: create a link to the proper files
<asac> calc: i guess thats the real fix
<asac> calc: yes ... please test link fix ... and post bugs with your findings
<asac> calc: schedule those for tribe-4
<calc> ok symlink firefox-nspr.pc to nspr.pc ?
<asac> calc: actually it should not fail to build with latest upload ... as i installed compatibility .so files now
<asac> calc: but that upload is stuck because of freeze atm
<calc> ok
<asac> calc: anyway ... its a bug
<calc> ok i will verify it works then file the bug, thanks for the help :)
<asac> calc: yes ... link firefox-nspr.pc to nspr.pc and firefox-nss.pc to nss.pc
<asac> calc: no problem ... thanks for pointing out
<asac> calc: which firefox-dev version are you building against?
<asac> calc: actually the current one in gutsy already has the compatibility links to the new .so files
<asac> calc: do you have a specific problem?
<ogra> hmm, the pulldown in ubiquitiy's partitioner didnt offer me any mountpoints
<ogra> adding / manually works though
<Hobbsee> ogra: i didnt find that
<ogra> i'm installing to a usb drive ... probably its that
<ogra> bah, it locked up ...
<calc> asac: ooo 2.3 was failing to build since it was looking in the wrong dir
<ogra> seems 256M rae not enough anymore nowadays ...
<ogra> *are
<asac> for ooo? ... most likely not
<elmo> if anyone got a bizaare old dak-style ACCEPTED mail recently, please ignore it - it was the archive rebuild dak instance gone insane and it's been fixed not to do that again
<pygi> a
<Hobbsee> b
<pygi> Hobbsee, accident :)
<ion_> c
<Hobbsee> :P sure sure
* pygi feels hungry, so he shall eat Hobbsee 
<Hobbsee> no!
<dholbach> evand: can you reupload your old source? it seems that gnome-speech is broken
<dholbach> evand: it should depends on its library package - I'll fix that instead
<Hobbsee> heno: ping?
<pygi> Hobbsee, o well, I'll leave you for now :)
* Hobbsee does nto wish to be eaten.
<b-tommy> hello
<evand> dholbach: ah, I thought that might be a possibility after poking around a bit.  Uploaded.
<Hobbsee> hiya evand, mvo
<dholbach> evand: super - I'll do the update of gnome-speech now at the same time
<evand> thanks dholbach
<evand> hi Hobbsee
<cjwatson> evand: hmm, tasksel didn't get its sponsored upload last night
<evand> cjwatson: I figured it was because main is frozen and it's not urgent.
<cjwatson> evand: I've uploaded it now. Did you commit those changes to a branch?
<cjwatson> evand: http://bazaar.launchpad.net/~ubuntu-core-dev/tasksel/ubuntu/ is the base
<evand> whoops, will do now
<cjwatson> evand: ta
* mvo waves to Hobbsee
<Hobbsee> mvo: :)
<simira> mvo :) How's guadec?
<mvo> simira: very good!
<ogra> mvo, i get a lot of grep erros on thin client sessions trying to access the Xorg log (which indeed resides on the client) is that from the compiz changes ?
<ogra> (in .xsession-errors that is)
<mvo> ogra: can you please put that file online somewhere?
<pitti> hi mvo
<heno> Hobbsee: pong
<Hobbsee> heno: maniacmusician is looking for you, w.r.t. to cd testing, i think
<maniacmusician> Hobbsee: heno hi
<heno> hi maniacmusician, how can I help?
<maniacmusician> heno: not a big deal, I sent you a PM on UF.
<heno> ok
<maniacmusician> heno: just stickying a thread
<heno> right
<ogra> mvo, http://paste.ubuntu-nl.org/30352/ ... i just see i'm missing displayconfig-restore ...
<pitti> heno: do you know some folks who could help out with CD testing?
<pitti> stgraber, Hobbsee: http://cdimage.ubuntu.com/edubuntu/daily-live/20070718.1/
<pitti> stgraber, Hobbsee: http://cdimage.ubuntu.com/xubuntu/daily-live/20070718.1/
<pitti> ogra: ^
<Hobbsee> pitti: i referred forums people to test
<stgraber> ok
<pitti> that should be everything now
<swimmerino89> hello to evrebody...i am a crazy boy...i'd like to do a thing but i don't know if i will complete it!i'd like to do a distribution based on ubuntu...i am searching for some packages(i am reading a guide to do it),but i don't find this packages!
<stgraber> pitti: done
<pitti> stgraber: thanks
<heno> pitti: it's a bit thin on #ubuntu-iso ATM
* pitti is still experiencing random hangs with not even VT commands working
<heno> bdmurray: around?
<heno> I have just 1 laptop with 0 CD drives ATM :(
<ogra> pitti, rsyncing, thanks ...
<swimmerino89> anyone can help me?i am trying to take the developer packages
<swimmerino89> what is the developement package for bzip2????
<evand> cjwatson: http://people.ubuntu.com/~evand/bzr/tasksel/
<bdmurray> heno: yes
<pitti> ogra: I'd appreciate if you and maybe someone else could boot the edubuntu lives several times on real hw
<pitti> ogra: on ubuntu we experience random hangs (and commands in VTs just block)
<pitti> ogra: one theory is that it is still esound
<heno> bdmurray: can you help out with some install testing of tribe 3?
<ogra> pitti, i usually test on a thin client with usb devices attached :)
<ogra> so i can test on real hw
<pitti> cool
<pitti> ogra: does edubuntu have compiz?
<ogra> but i can also note that 265M with shared videoram isnt working out
<bdmurray> heno: yes, I'll need to download the isos though
<ogra> yes
<ogra> ubiquity usually hangs at some point with this ramsize
<swimmerino89> are you reading me?????
<bdmurray> heno: any particular tests?
<bdmurray> or images rather
<heno> bdmurray: see https://isotesting.stgraber.org/ for the untested ones
<pitti> bdmurray: I'd appreciate some ubuntu live tests, since these seem to be the most fragile ATM
* Hobbsee gets out the sticky tape and chewing gum
<heno> i386 alternate, amd64 desktop
<bdmurray> pitti: cool, I have that iso already. ;)
<pitti> heno: I do amd64 desktop already
<cjwatson> evand: thanks, pulled
<cjwatson> swimmerino89: it's not at all clear what you're asking for. You either want 'apt-get source bzip2' or 'sudo apt-get install libbz2-dev'; I don't know which.
<swimmerino89> cjwatson: i am trying to find 10 packages....all 10 must be for develolp it!all the developement packages are called lib_PACKAGE_NAME-dev???
<Hobbsee> swimmerino89: they usually have -dev in the name, yes
<pitti> swimmerino89: that's the common practice, yes
<swimmerino89> ok
* ogra dances 
<Hobbsee> ogra: it works?
<ogra> edubuntu-server-i386 install went fine, just booting the first time
<swimmerino89> I can't find all the dev packages...who can help me please?
<ogra> (that takes a while from usb stick ;) )
<pitti> swimmerino89: #ubuntu, please
<swimmerino89> #ubuntu
<Hobbsee> ogra: yay!
* ogra grumbles about fsck
<soren> ogra: xfs ftw!
* ogra was a big xfs user until he had the first disk where the fs just wrote beyond the partion end ...
* ogra2 waves to Hobbsee from the fresh install
<ogra2> all fine :D
<Hobbsee> ogra2: yay!
* Hobbsee ^5's
* ogra2 ^5s back
<Hobbsee> ;0
<Hobbsee> * :)
<ogra> hmm, why do i see gdm with teh gnome theme for a second on shutdown ... ?
<seb128> ogra: how do you shutdown?
<ogra> seb128, from gdm
<seb128> would be a gdm bug then
<ogra> it restarts and shows the default gnome theme for a second ... then it shuts down
<seb128> I didn't notice and I don't fancy trying now ;)
<ogra> heh
<ogra> indeed
<seb128> open a bug, I'll have a look later
<ogra> yep
<shac1> anybody on gutsy? I need someone to tell me if 'import cairo' in python dies with a library error
<shac1> just open python and run import cairo
<bdmurray> does anybody have the live cd running at the moment?
<bdmurray> my ttys seem misnumbered
<stgraber> shac1: no error here
<Hobbsee> bdmurray: yes
<Hobbsee> bdmurray: way cool.  they are.
<bdmurray> okay, I'll submit it then
<bdmurray> any idea about what package that would be?
<Hobbsee> none at all
<ogra> seb128, bug #126797 for you
<ubotu> Launchpad bug 126797 in gdm "gdm shows the default gnome theme for a second on shutdown" [Undecided,New]  https://launchpad.net/bugs/126797
<seb128> k
<cjwatson> shac1: works fine here too
<pitti> does anyone notice ubuntu live system hangs?
* Hobbsee raises hand
<pitti> so, mostly it is just painfully slow, but appears eventually
<mneptok> pitti: there may be more conference registrations in the next week.
<mneptok> oh ... not what you meant
<mneptok> >:)
<pitti> but in one case where it seems to be completely stuck (VTs, too), I noticed that there was a lot of I/O and apport action going on
<pitti> mneptok: :)
<pitti> which was due to the fact that dmesg had tons of 'modprobe: segmentation violation  rip:0x234blabla' and modprobe segfaults
<bdmurray> pitti: is there any special compiz testing to be done on the live CD?
<Hobbsee> pitti: each time i get to gnome on that (on the few times that i do), i get a "hal failed to be initialized" error.
<Hobbsee> if that helps, at all
<pitti> bdmurray: only in the sense of 'does it the right thing on your hw'
<pitti> Hobbsee: right, that could actually be related
<ogra> the initscript changed, didnt it ?
<pitti> Hobbsee: can you try to reproduce this, and if it really hangs, use a vt and check dmesg for these modprobe issues?
<pitti> Hobbsee: I think the commands will eventually run, it just takes awfully long
<Hobbsee> pitti: i can already reproduce the initialising hal error, every time that it actually boots without locking the entire machine
<shac1> stgraber, cjwatson: could you try importing zlib too? sorry
<Hobbsee> pitti: if it really hangs, i cant get to a VT.
<pitti> Hobbsee: if it really doesn't run anything, switch to VT during build and repeatedly 'sudo killall gdm' until you actually killed it
<pitti> Hobbsee: "can't get to a VT" -> uuh, I never saw that
<pitti> Hobbsee: that might indeed be a compiz related problem then
<ogra> pitti, i was blaming the low ram config over here ... but i also see hardlocks
<Hobbsee> sorry, can get to a VT, but cant actually get any commands typed in
<Hobbsee> as in, hitting enter on the command freezes it
<pitti> Hobbsee: right; maybe just wait for a while
<pitti> Hobbsee: I had the same once
<pitti> however, I could just reproduce the modprobe segfaults once in four boots
<Hobbsee> i either get that, or it booting fully into gnome, with the hal initialisation error
<pitti> Hobbsee: hm, the hal thing is something separate, I think
* pygi could reproduce the hal problem on a few machines he tried it on
<bdmurray> Hobbsee: I submitted bug 126800 if you want to confirm it
<ubotu> Launchpad bug 126800 in casper "[gutsy]  20070718 Live CD ttys are misnumbered" [Undecided,New]  https://launchpad.net/bugs/126800
<pitti> pygi: can you 'sudo /etc/init.d/hal start' manually?
<pitti> pygi: and confirm that 'pidof hald' really didn't show anything before?
<pygi> pitti, don't have those machines here :-/
<pygi> pitti, but I'll poke people who have the same problem
<pitti> Hobbsee: can you try this?
<Hobbsee> trying
* Hobbsee waits at the orange screen
<Hobbsee> pitti: that loaded normally...no hal error either.
<stgraber> shac1: works
<pitti> Hobbsee: yay heisenbug :)
<Hobbsee> pitti: it's still happening a little too much for my liking, though
<pitti> Hobbsee: for mine, too :/
<pitti> Hobbsee: I would welcome if we could verify that the modprobe crash occurs somewhere else, too, and is not just sun rays
<Hobbsee> bdmurray: done
<stgraber> pitti, Hobbsee, ogra: Please think to put the bugs you've found on the tracker once reported on LP (so other testers will know that's a known bug and won't file a dup on LP :))
<bdmurray> I haven't used the Ubuntu Desktop CD in a while but is Firefox supposed to ask you to create a user profile?
<pitti> stgraber: right, I filed one for missing /dev/disks/by-uuid, but not for that hang, since I cannot even remotely describe it
<ogra> stgraber, indeed :)
<pitti> bdmurray: certainly not; you see that on the live system?
<stgraber> bdmurray: It should : Just work
<shac1> stgraber: thanks, no idea why it fails here, I'm pulling my hair off
<bdmurray> pitti: yes, I see that on amd64
<pitti> you guys are seeing stuff! stop inventing bugz!!!11!!!one!!
<pitti> bdmurray: ubuntu?
<pitti> bdmurray: hm, I never had that; asac, still here?
<bdmurray> pitti: yes, and I can't make a profile either so no browsing for me
* pitti tries that, too
<Hobbsee> pitti: havent noticed it, but have been running with the splash screen
<stgraber> bdmurray: do you have a ~/mozilla/firefox directory ?
<Hobbsee> ogra: can you round up some people to test your edubuntu cds please?
<ogra> i'll try
<Hobbsee> thanks
<stgraber> Hobbsee: I'll do edubuntu server i386 as usual and then workstation (alternate)
<stgraber> ogra: ^
<bdmurray> stgraber: I have a .mozilla/firefox directory yes
<Hobbsee> stgraber: great, thankyou
<stgraber> bdmurray: try moving it to say : .mozilla.bak
<bdmurray> and multiple profiles are there
<stgraber> and launch firefox again (I just don't understand why you'd have a buggy .mozilla in /home/ubuntu/ ...)
* bdmurray can't even submit apport bug reports
<pitti> bdmurray: confirmed here; darn
<pitti> asac: ^ help, please
<stgraber> pitti: so that should also be the case for all others desktop isos ?
<pitti> right
<stgraber> (except if Kubuntu uses Konqueror instead of firefox)
<pitti> and for installs
<pitti> it also affects a fresh profile, I just checked
<pitti> bdmurray: is there already a bug for it?
<stgraber> :(
<bdmurray> pitti: not yet
<bdmurray> do you want to submit it or shall I?
<stgraber> pitti: so that means we'll need a rebuild of all isos ...
<cjwatson> Kubuntu uses konqueror
<pitti> bdmurray: please do, you already have the information about ~
* pitti phones asac
* Hobbsee sigh
<Hobbsee> i agree with pitti - you guys, stop seeing bugs!
<cjwatson> http://people.ubuntu.com/~ubuntu-archive/germinate-output/kubuntu-gutsy/desktop
<ogra> hrm, had another hardlock ...
* ogra starts to wonder if its just to warm and the machine dies
<pitti> ogra: wait, please, for debugging
<pitti> ogra: VT, dmesg?
<ogra> pitti, not even caps lock
<pitti> asac is already away, darn
<ogra> its a real hard lockup ...
<pitti> ogra: hm, that's again something new
<xhaker> ogra, what cpu?
<ogra> via
<ogra> its a thin client with usb DVD and usb disk attached
<soren> Did any of you guys try the plain i386 server install?
<pitti> bdmurray: hm, seems we need to figure this out without asac :/
<ogra> 256M 1Ghz
<stgraber> pitti, bdmurray : last firefox upload was on 2007-07-03
<Hobbsee> pitti: that'll be https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/123917
<ubotu> Launchpad bug 123917 in firefox "Can't start Firefox" [Undecided,Incomplete] 
<Hobbsee> pitti: why, asac's not around?
<Hobbsee> oh, already away
<Hobbsee> pitti: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/124262
<ubotu> Launchpad bug 124262 in firefox "[gutsy tribe-2]  firefox doesn't create profile if not present (dup-of: 123917)" [Undecided,Invalid] 
<ubotu> Launchpad bug 123917 in firefox "Can't start Firefox" [High,Incomplete] 
<pitti> Hobbsee: yup, just saw it
<Hobbsee> i wonder why it tries to create a file, instead of a folder.
<pitti> well, that's the bug :)
<stgraber> pitti: were you able to reproduce on an already installed Ubuntu ? I tried moving my .mozilla to .mozilla1 and starting firefox, it works just fine ...
<pitti> stgraber: yes, I am
<pitti> stgraber: I created a clean user profile
<pitti> and get the same
<Hobbsee> why is firefox not on patches.ubuntu.com?
<pitti> stgraber: do you have ubufox installed?
<stgraber> pitti: yes
<pitti> 8289  open("/home/test/.mozilla/firefox/jrum9hee.default", O_WRONLY|O_CREAT|O_TRUNC, 0777) = 4
<pitti> 8289  open("/usr/lib/firefox/defaults/profile", O_RDONLY) = -1 ENOENT (No such file or directory)
<pitti> 8289  close(4)                          = 0
<pitti> 8289  mkdir("/home/test/.mozilla/firefox/jrum9hee.default", 0700) = -1 EEXIST (File exists)
<pitti> now that looks strange
<pitti> aah
<pitti> may the dangling symlink /usr/lib/firefox/defaults/profile might have somethign to do with it?
<bdmurray> launching firefox seems to create lots of proviles
<pitti> stgraber: ^ does that dangle for you?
<pitti> stgraber: i. e. do you have /etc/firefox/profile?
<stgraber> yes
<pitti> ah, I don't
<bdmurray> nor do I
<pitti> so, current firefox doesn't ship it any more
<stgraber> I tried with/without ubufox and removing .mozilla unable to reproduce on my laptop (update Gutsy Tribe-1), so that could be that /etc/firefox thing
<pitti> stgraber: dpkg -S /etc/firefox/profile?
<stgraber> yeah, firefox not working if I rename /etc/firefox/profile !!!
<Hobbsee> i'd expect that we copy /etc/firefox/profile to ~/.mozilla in the firefox build process, somewhere
<pitti> Hobbsee: no, that's done at runtime
<stgraber> pitti: not found
<pitti> stgraber: right, so the recent version forgets to ship it
<Hobbsee> pitti: oh, sorry, i meant when it's very first started.  i meant runtime.
<pitti> right
<stgraber> pitti: indeed
<Hobbsee> bdmurray: your firefox bug will be a dupe of that other one, i expect
<bdmurray> Yeah, I guess so.  I wasn't sure if it was different for the Live CD.
* Hobbsee wonders why it creates a file then.
<Hobbsee> bdmurray: shouldnt be.  i think it's just clean install in general stuff
<pitti> Hobbsee: I guess it just does the wrong thing when trying to copy the symlink as a directory, when it's dangling
<Hobbsee> pitti: hmmm...yeah, i guess.
* Hobbsee was never terribly good on firefox build structures and such.
<pitti> stgraber: what is in that dir?
<stgraber> pitti: some kind of default firefox profile :
<stgraber> -rw-r--r-- 1 root root  28K 2007-06-01 18:00 bookmarks.html
<stgraber> drwxr-xr-x 2 root root 4.0K 2007-06-25 18:24 chrome
<stgraber> -rw-r--r-- 1 root root  153 2006-09-14 19:13 localstore.rdf
<stgraber> -rw-r--r-- 1 root root  287 2004-11-30 22:26 mimeTypes.rdf
<stgraber> -rw-r--r-- 1 root root  347 2004-07-28 23:20 prefs.js
<stgraber> -rw-r--r-- 1 root root 3.3K 2005-02-01 18:36 search.rdf
<pitti> stgraber: hm, none of these files are in the current source
<pitti> stgraber: can you please send me a tarball?
<stgraber> sure
<Hobbsee> pitti: i wonder if htey're expected to be in ubufox
<pitti> Hobbsee: possibly
<pitti> and I'd much prefer to upload ubufox than firefox, in terms of buildd time :)
<cjwatson> moving conffiles between packages => possible pain though
<Hobbsee> pitti: http://hobbsee.mailbolt.com/Ubuntu/profile/
<pitti> first that, and second, firefox doesn't depend on ubufox
<stgraber> http://www.stgraber.org/download/ubuntu/firefox-profile.tar.gz
<stgraber> :(, Hobbsee was faster
<Hobbsee> stgraber: amazingly, even with my uplink.
<Hobbsee> pitti: that's definetly an empty profile
<stgraber> Hobbsee: my .tar.gz is 11kB large, so even with a 56k uplink :)
<pitti> well, it does have the Ubuntu bookmarks and such, which we want
<cjwatson> http://patches.ubuntu.com/by-release/atomic/ubuntu/f/firefox/firefox_2.0.0.4+2-0ubuntu3.patch has:
<cjwatson> -debian/tmp/usr/lib/firefox/defaults/profile etc/firefox/
<cjwatson> in debian/firefox.install
<Hobbsee> cjwatson: why on earth is that under atomic?
<pitti> cjwatson: aah
<cjwatson> Hobbsee: atomic has the version-to-version changes
<pitti> cjwatson: curious, though, upstream tarball hardly has the ubuntu bookmarks and such
<cjwatson> hmm, isn't that code in bzr?
* cjwatson grovels through codebrowse
<Hobbsee> cjwatson: ah, i've been looking in the ubuntu folder there.
<pitti> cjwatson: for now, my idea is just to take that standard profile, put it as it is in debian/, and add it to firefox.install again
<pitti> cjwatson: that might not be how asac wants it to be, but should certainly work
<Hobbsee> pitti: that'll work, yes.
<cjwatson> * debian/firefox.install: don't install defaults/profile to /etc/firefox anymore
<cjwatson> appears to have been intentional ...
<cjwatson> http://codebrowse.launchpad.net/~asac/firefox/ubuntu-2.0.0.x/revision/asac%40jwsdot.com-20070619172408-7f0yy7g9riwnkb8e?start_revid=asac%40jwsdot.com-20070703083705-8p9r0bgw8x6mowkm&file_id=firefoxtrunk.install-20070321172126-hx4btlytc64jyo4n-15
* soren -> dinner
<Hobbsee> but why would you use a firefox.ubuntu-prefs.js ?
<cjwatson> pitti: if you wanted to revert that change, just reverting the change to debian/firefox.install ought to do it
<pitti> cjwatson: right, but with asac not being available, it's hard to tell why
<cjwatson> I don't think it's been removed from the package
<cjwatson> Hobbsee: that I don't know
<cjwatson> s/package/source package/
* heno -> hotel
<Hobbsee> firefox.cfg is...odd
<pitti> cjwatson: ah, indeed, there's a patch that adds Ubuntu links to the bookmarks
<pitti> TODO -> migrate bookmarks fix together with original bookmarks fix in look-and-feel patch to distromods
<pitti> so, I think he eventually wanted this to move to ubufox, but didn't
<Hobbsee> oh yes, you certainly wouldnt be able to have ubufox as the default thing, and have /e/f/profile
<Hobbsee> i'll bet ubufox only works on a "new" profile
<pitti> Hobbsee: ubufox doesn't ship profiles
<Hobbsee> pitti: yet.
<Hobbsee> pitti: it'll be shipping some changes, to go into profiles, i think
<pitti> Hobbsee: right. but not for T3
<pitti> I do consider this a T3 blocker
<Hobbsee> oh, indeed.  i'm just thinking of why he would have done it that wya at all.
<Hobbsee> which then impacts on hwo this gets fixed for t3
<Hobbsee> this is a t3 blocker, yes, of course.
<pitti> Hobbsee: eventually it makes sense; firefox would be clean upstream, and ubufox the mods to it
<pitti> I tested that resurrecting /etc/firefox/profile fixes the bug, and it has been like that in the past, so it's safer than trying to do the conffile migration in ubufox now
<Hobbsee> pitti: the other thing to test then - does ubufox break, if e/f/p is there?
<pitti> I have the updated firefox here, test-building now
<pitti> Hobbsee: dpkg -L ubufox -> it's very harmless
<stgraber> Hobbsee: no, I've ubufox installed here
<Hobbsee> i'm assuming not, but...
<stgraber> Hobbsee: and works on old and new profile
<pitti> Hobbsee: I have ubufox installed, and fresh profile now works, also my own profile still works
<Hobbsee> good.  just checking.
<pitti> Hobbsee: I'm reasonably sure that this works; what about saving some time and let me beat the new source through the publisher already
<pitti> Hobbsee: if it fails, then we can upload a new source without having lost time
<pitti> but if it works, we save a lot of time
<Hobbsee> pitti: that'd be good.
<stgraber> so reverting this /etc/firefox/profile change + rebuild + wait 1h30 (firefox build time) should do it
<Hobbsee> should do
<Hobbsee> i suggest just changing to konqueror.
* Hobbsee ducks
<pitti> http://paste.stgraber.org/2171
<Hobbsee> pitti: looks good
<pitti> erk, since when does my mouse cursor stutter when I build something like firefox?
<bdmurray> pitti: without a working firefox how should I go about submitting apport crash reports
<pitti> bdmurray: which crash did you get?
<stgraber> bdmurray: you can copy /var/crash/ content
<pitti> bdmurray: you can copy over the .crash file to a working box and use '/usr/share/apport/apport-gtk -c /path/to/crash/file'
<Hobbsee> bdmurray: file it manually.  some of us still do :P
<bdmurray> totem receved an X Window System error
<ompaul> mdz http://photos.jonathancarter.co.za/uds-gutsy/PICT0414web  that is something spooky you are doing there
<bdmurray> . . . The error was 'BadAlloc (insufficient resources for operation)'
<pitti> Hobbsee: 1:30 hours??
<pitti> Hobbsee: last time it took less than an hour on my desktop
<Hobbsee> pitti: i didnt say that, bdmurray did
<Hobbsee> sorry, stgraber
* pitti prepares for a night shift
* Hobbsee has inadvertantly already been doing one :P
<pitti> ok, needs pretty exactly 1 hour on buildds
* ScottK isn't buying inadvertently.
<pitti> stgraber: can you please invalidate everythign but server and kubuntu?
<Hobbsee> pitti: then go do something else for that hour, and make sure that bdmurray and stgraber stop looking for bugs.
<Hobbsee> pitti: even upgrades?
* pitti is still interested in people who experience desktop session hangs on the live CD
<pitti> stgraber: right, upgrades are still valid, too, I think
<pitti> does xubuntu use firefox?
* pitti looks
<Hobbsee> pitti: yes it does
<pitti> yes, it does
<Hobbsee> pitti: no, upgrades wont have a problem - wont have a new profile
<pitti> Hobbsee: also, feisty still has that directory, so shipping it again shouldn't break it
<Hobbsee> pitti: done
<Hobbsee> pitti: true that
<pitti> bdmurray: so, did you hear about or experience any other OMGSIF bug so far?
<Hobbsee> pitti: dont ask, and you wont find out....
<pitti> bdmurray: thanks a lot for discovering this; what a shame
<stgraber> pitti: I also disable Edubuntu server as it installs edubuntu-desktop as well
<pitti> stgraber: right, I meant Ubuntu server
<stgraber> pitti: are you rebuilding edubuntu server add-on as well ? (this one shouldn't change)
<pitti> stgraber: yes, it's integrated into the build process and a bit fiddly to rescue
<pitti> stgraber: it has no tests so far anyway
<stgraber> ok
<stgraber> https://isotesting.stgraber.org/isotesting/build/All
<pitti> *sniff*
<bdmurray> pitti: No, I haven't heard about anything else.  I'm looking at totem crashing atm.
<pitti> Go back to start. Don't draw 4000$. Don't get dinner nor sleep. Start all over.
<pitti> bdmurray: ok, that doesn't sound like a blocker
<kylem> we're allowed to sleep?
<pitti> bdmurray: how did compiz behave for you?
<Hobbsee> kylem: no
<bdmurray> no problems with compiz but I did have a hang like you described 1x
<pitti> bdmurray: eternal, or it just took very long?
<pitti> bdmurray: and how often did you try it? seems to occur in roughly 1/4 cases for me
<pitti> not that we would have an even remote idea what causes it, so we cannot fix it on the spot anyway
<bdmurray> I've only booted it 3 times and it happened 1x
<pitti> ok, sounds like a prominent release note
<stgraber> bdmurray: on ubuntu desktop i386 that's ?
<pitti> amd64 as well
<bdmurray> I'm working with amd64 atm
<stgraber> downloading
* pitti grabs some dinner while firefox builds and the source publishes
<bdmurray> Where does the stuff in ~/Desktop/Examples come from?
<pitti> ah, I got asac on the phone
<pitti> he said that our approach is basically ok
<pitti> bdmurray: example-content, I think
<Kmos> firefox v2.0.0.5 is out :) asac should be here :D
<pitti> Kmos: it is already in the unapproved upload queue
<pitti> Kmos: but not for tribe-3
<Kmos> already? nice :-)
<Kmos> tribe will have v3.0 right ?
<pitti> 2.0.0.4
<bdmurray> pitti: apport-gtk -c requires the gutsy version of apport right?
<pitti> bdmurray: right
<pitti> bdmurray: in feisty you would put the file into /var/crash
<pitti> bdmurray: but that would give wrong results for Dependencies:, package version etc.
<pitti> oooh, firefox built
<Kmos> :)
<pitti> ... and even works
* pitti bounces
<j1mc> cjwatson: are the tribe 3 testing isos being rebuilt because of the FF problem?
<j1mc> anyone can answer that, really ^^  :-)
<stgraber> j1mc: they are
<ScottK> pitti: Do you have time for an archive admin licensing question?
<pitti> j1mc: yes
<j1mc> Hobbsee had come into xubunt-devel saying we had to test within 12 hours.  does that still stand?
<pitti> ScottK: I'm not a license expert at all, but you can try
<ScottK> OK.
<pitti> j1mc: I estimate that we will have new xubuntu images in about 3 hours
<ScottK> The dkim-filter/dkim-milter package is licensed under the Sendmail license for copyight.
<Kmos> pitti: and time for one or two syncs already ACK'ed ? :)
<pitti> Kmos: if they are universe, that's ok
<j1mc> pitti: thanks.  so we'll test them after that for release of tribe 3 tomorrow?
<ScottK> Yahoo! claims a patent on their IP in DKIM and our (Debian's) package does not comply with said license.
<pitti> j1mc: you are of course welcome to test the current images to check for critical bugs
<pitti> j1mc: the new images will just have a new firefox
<Kmos> pitti: yep
<ScottK> pitti: So, are we required to care about patent licenses or do we just worry about copyright?
<pitti> j1mc: so, the new images need to be tested, of course, but testing the current ones is very helpful, too
<j1mc> ok.  thanks.  i'm at work now, so . . .   :)  can't test from here.  i will get the word out to others, though.
<j1mc> i will test the new iamges this evening (i am utc -500)
<pitti> ScottK: ugh, I don't feel qualified to answer that; can you please mail ubuntu-devel@?
<pitti> j1mc: thanks
<ScottK> pitti: Will do.
<j1mc> yw.  ... thanks for your help.
<Kmos> can someone add !karma with https://help.launchpad.net/KarmaCalculation
<ScottK> pitti: Sent.
<bdmurray> Does anybody else have Documents and Desktop 2x in their Places menu?
<lemsx1> bdmurray: on Gutsy?
<bdmurray> Yes, the Gutsy Live CD.
<lemsx1> bdmurray: ok. i just found the question odd... i've not played with gutsy yet
<evand> bdmurray: yes
<bdmurray> pitti: still around?
<evand> on 20070717
<pitti> bdmurray: yes, waiting for firefox on buildds :)
<bdmurray> How long have you waited for the amd64 desktop cd?
<pitti> bdmurray: a minute or so
<bdmurray> I'll stop then.
<bdmurray> Too bad I can't ssh to the system.
<xhaker> bdmurray, my turion x2 hangs on loading acpi modules.. on an older kernel though.. i have the current image here to test later
<bdmurray> xhaker: could you provide some context for me?
<xhaker> bdmurray, weren't you talking about the desktop cd boot time?
<xhaker> amd64 cd
<bdmurray> We were talking about it ocassionally locking up.  I was curious how long pitti had waited for it to do anything.
<bdmurray> evand: I submitted 126848 if you want to confirm it
<xhaker> Heh. I have a friend that uses feisty. his Sempron laptop locks up on him every time, with no apparent reason
<evand> bdmurray: done, thanks
<xhaker> I've tryed to debug it, but the machine freezes completely. You have to remove the battery.
<bdmurray> thank you
<xhaker> It's not heat. It's not random either i presume, but it sure seems so.
<bdmurray> Have you tried Gutsy at all?
<xhaker> Not on his laptop. He prefers running the stable stuff. (not so stable though)
<agoliveira> BenC, will the patch to load custom DSDT files be added any time soon to Gutsy kernel?
<bdmurray> Still testing with the Live CD would be helpful as it is easier to get the development kernel fixed.
<bdmurray> pitti: Did you want to be pinged about odd apport stuff?
<pitti> bdmurray: sure
<bdmurray> bug 124285 seems quite odd
<ubotu> Launchpad bug 124285 in compiz "compiz.real crashed with SIGSEGV" [Medium,Incomplete]  https://launchpad.net/bugs/124285
<bdmurray> Are the dpkg messages part of the crash report or user submitted?
<pitti> bdmurray: hm, I think bug 126805 is really a dup of 123917; do you agree?
<ubotu> Launchpad bug 126805 in firefox "[gutsy]  Firefox on 20070718 Live CD asks which user profile to use" [Undecided,New]  https://launchpad.net/bugs/126805
<Kmos> bug 123917
<ubotu> Launchpad bug 123917 in firefox "Can't start Firefox" [High,Fix released]  https://launchpad.net/bugs/123917
<pitti> bdmurray: that was given by the user as a description
<pitti> bdmurray: that has nothing to do with the compiz crash; I guess he had more than one crash and might have mixed the tabs or so
<Kmos> xhaker: the /var/log/messages doesn't show anything wrong on your friend laptop ?
<keescook> bryce: looking at the mdetect stuff now
<bdmurray> pitti: yes, that is a dup.  apport -> that makes some more sense then.
<bryce> keescook, thx
<pitti> bdmurray: thanks, marked so
<keescook> bryce: the tree of .deps/* files appear in the diff.gz, I would have expected those would get cleaned up during "distclean".
<bryce> that is one of the things I had a lot of trouble with
<bryce> advice on handling that better would be appreciated
<keescook> also, why is mdetect.c in both the toplevel and src dirs?
* keescook switches to privmsg
<xhaker> Kmos, I tryed to wait for it to crash with a tail /var/log/messages
<xhaker> Kmos, ssh from a different pc
<xhaker> It doesn't show anything. I was betting on the rt2500 wireless driver but it crashes without the pcmcia card!
<Kmos> xhaker: there isn't any file at /var/crash ?
<Kmos> firefox failed to install adobe flash player on gutsy
<Kmos> says to install it manually
<pitti> hi Burgundavia
<bdmurray> Is Super+M supposed to do something?
<bdmurray> In compiz.
<Burgundavia> hey pitti
<stgraber> pitti: Has firefox been built ? (I see nothing on LP)
<pitti> stgraber: yes, it has, debs currently publishing
<stgraber> ok
<asac> Kmos: everything is already uploaded ... i am doing some QA for another two hours now ... if no regressions are found they should go out soon
<Kmos> pitti: at gutsy, when the apport open the browser (in this case, firefox), it's add "file:///home/kmos/%22" before the https://launchpad.net ...
<pitti> Kmos: ah, known bug in python's webbrowser module; it's filed with countless dups
<Kmos> ah ok =)
<pitti> Kmos: that only happens for custom browsers in 'prefered applications', though
<Kmos> maybe when you got some time, fix that module
<pygi> siretart, any chance you'r still here?
* pitti respins CDs
<pitti> stgraber: how do I add new CDs?
<pitti> stgraber: ubuntu alternate should be ready soon
<stgraber> https://isotesting.stgraber.org/isotesting/addbuild
<pitti> stgraber: I see how to disable/re-enable a CD
<stgraber> tick the ones which are ready, put the build number in "version number"
<stgraber> check that milestone is Tribe-3 and validate
<pitti> stgraber: aah, I see
<pitti> thanks
<stgraber> they'll be put as active again once you submited the new ones
<stgraber> np
<soren> Stupid question alert: I'm just looking at the debian/rules of apache2. It calls "dh_installinit -a -r --init-script=apache2 debian/apache2.2-common.init.d -- start 91 09". The -a is supposed to mean "do this for all arch-dep packages", isn't it?
<pitti> stgraber: ok, so if you want, I'll add them directly, so that we can reduce the IRC pingpong
<soren> So, that command tells dh_installinit to install that init script for all the arch-dep packages in the source package?
<pitti> soren: seemingly, although this doesn't seem to make much sense
<soren> pitti: That's what I thought.
<stgraber> pitti: sure, just ping if you have any problem
<ajmitch> morning
<stgraber> moin ajmitch
<soren> pitti: It doesn't actually do that, though.
<soren> pitti: From what I can tell, it acts just as it would have without the -a.
<bhale> hi ajmitch
<pitti> hi ajmitch
<pitti> soren: ah, wait
<soren> pitti: I just got it :)
<pitti> soren: it only acts on <package>.init
<pitti> soren: so even if it is called for other packages, there is no .init script for them
<soren> pitti: Yeah, so that debian/apache2.2-common.init.d argument isn't used at all.
<pitti> soren: I guess it'll actually install debian/init to all packages
<soren> pitti: Yes, I imagine it would.
<pitti> soren: right, that is bogus
<cjwatson> soren: debhelper scripts sometimes only apply files specified on the command line to the first package being acted on. There's a -A argument (documented in debhelper(1)) to change that.
<cjwatson>        -A, --all
<cjwatson>            Makes files or other items that are specified on the command line take effect in ALL packages acted on, not just the first.
<soren> cjwatson: Regardless, I'm almost certain that in this particular case, that extra argument isn't used at all.
<pitti> soren: at least it is used in an incorrect way
<cjwatson> soren: easy way to tell is to run that single command with DH_VERBOSE=1
<pitti> soren: it's supposed to be a name, not a path, AFAIU the manpage
<cjwatson> (and any DH_COMPAT from debian/rules, if there's no debian/compat)
<soren> cjwatson: The output is exactly the same if I pass "foobar" instead of debian/apache2.2-common.init.d :)
<cjwatson> heh
<soren> Oh, well. Lesson to be learned: Don't trust everyone else's maintainer scripts to make sense.
<soren> What I needed it for was a quick and simple way to create the init.d dir, install an init script (from the orig.tar.gz, so not in debian/), do the debhelper magic to put update-rc.d into post{inst,rm}, and all that jazz..
<soren> Looking at the dh_installinit source, it looks like I'm SOL.
<soren> ...unless I just copy the init script into debian/, but that doesn't feel right either.
<pitti> new ubuntu/edubuntu/xubuntu alternates up, please test
<pitti> ogra, bdmurray, mr_pouit, gpocentek ^
<pitti> stgraber: I added them, worked fine
<soren> And symlinking it works, but can't be represented in the diff.gz.
<pitti> new ubuntu desktop images up
#ubuntu-devel 2007-07-19
<mathiaz> how can I add new test case or rename test cases on the iso testing tracker ?
<stgraber> mathiaz: you can't (yet)
<mathiaz> stgraber: can you rename some of the test cases for me ?
<stgraber> yes
<mathiaz> stgraber: for the ubuntu server cds, I'd like to rename 'LVM+LAMP' to 'LAMP'
<stgraber> ok
<stgraber> mathiaz: done
<mathiaz> stgraber: excellent. Thank you.
<stgraber> np
<stgraber> an UI will be written but it'll most likely be for gutsy+1 and the QA Tracker as testcases for ISOs aren't supposed to change that often to be high priority
<stgraber> (I think that's the only thing you can't do with the current Admin UI)
<stgraber> pitti: How are Edubuntu and Xubuntu desktop going ?
<pitti> stgraber: edubuntu lives should be up, xubuntu building ATM
<stgraber> http://cdimage.ubuntu.com/edubuntu/daily-live/20070718.2/
<pitti> yep, there they go; I added them
<stgraber> We already have tested Ubuntu server for i386 and amd64, that's a good start, sparc users are a bit harder to find though :)
<pitti> stgraber: I'll ask fabbione tomorrow
<pitti> shiny! firefox is alive on current live CDs
* pitti hugs bdmurray 
* pitti hugs asac as well
<mathiaz> stgraber: can you add another test case to the ubuntu server cds ?
<stgraber> sure
<mathiaz> stgraber: actually I have two : bind9 and lvm partioning
<mathiaz> stgraber: they are all described in the wiki page https://wiki.ubuntu.com/Testing/InstallMethods
<mathiaz> stgraber: under the server cds.
<stgraber> mathiaz: done
<pitti> in my expert test installs I usually create a PV with one VG Ubuntu and LVs swap/root/home
<mathiaz> stgraber: thank you.
<pitti> mathiaz: I assume the automatic one doesn't create a separate home dir?
<mathiaz> pitti: nope.
<mathiaz> pitti: just root and swap.
<pitti> mathiaz: that separate dir led me to bug 126776
<ubotu> Launchpad bug 126776 in udev "/dev/disks/by-uuid not mounted in expert LVM install" [Undecided,New]  https://launchpad.net/bugs/126776
<pitti> mathiaz: maybe you can have a look whether you have that dir in your server installs, just for confirming?
<crippler> I just installed Ubuntu 7.04 on my Dell deminson 4600 and the sound will now work. Any suggestions? The volume is not set to zero.
<mathiaz> pitti: I've also come across another bug 107205
<ubotu> Launchpad bug 107205 in partman-auto-lvm "LVM install crashed - lvm metadata not removed when creating a new partition layout." [Medium,Triaged]  https://launchpad.net/bugs/107205
<crimsun> crippler: this is not a support channel.  Please ask me in #ubuntu+1.
<crippler> Ok.
<asac> pitti: btw, how did that bug get to your attention? through cd testing?
<stgraber> crippler: #ubuntu as it's Feisty
<pitti> asac: yes, bdmurray mentioned it
<pitti> asac: it wasn't on tribe2, I'm pretty sure
<asac> yes ... it wasn't
<pitti> although, hmm
<pitti> last upload was from June 8
<asac> i find it pretty interesting that it didn't even come earlier
<pitti> yeah, I wondered, too
<asac> when was tribe-2?
<pitti> just from looking at the date it must have been earlier
<pitti> June 28th
<asac> 3rd jul wsa last upload
<mathiaz> pitti: /dev/disks/by-uuid is present on my server install.
<pitti> mathiaz: ok; I'm currently running a similar install, will check again
<pitti>  -- Alexander Sack <asac@ubuntu.com>  Fri, 8 Jun 2007 01:11:00 +0200
<pitti> asac: ^ maybe that's not correct then?
<mathiaz> stgraber: I can only create one report for test cases.
<mathiaz> stgraber: I have the following use case: lvm partitionning works on a fresh hardrive, but fails if there has already been an lvm installed.
<mathiaz> stgraber: how should I report that ?
<asac> pitti: hmmm ... for tribe-2 i didn't want ubufox uploaded so i did the 25 Jun upload from a minibranch ... guess the missing date update slipped in when merging that back in right before the upload
<stgraber> mathiaz: we'd consider it as being a fail for that testcase or a pass with comment+bug attached, as the "lvm partitioning" test has failed
<mathiaz> stgraber: ok. I've add a comment and link to the bug report in LP. But I'd still consider it as successfull test.
<stgraber> ok, btw is that LVM bug something new ? I may have had a similar problem with Feisty some weeks ago
<Kmos> democracy player changed name to Miro
<Kmos> www.getmiro.com
<stgraber> I didn't have much time to investigate so I simply created a new partition table and rebooted
<mathiaz> stgraber: bug 107205
<ubotu> Launchpad bug 107205 in partman-auto-lvm "LVM install crashed - lvm metadata not removed when creating a new partition layout." [Medium,Triaged]  https://launchpad.net/bugs/107205
<mathiaz> stgraber: the installer doesn't support creating an lvm partition layout if there has already been an lvm partition layout on the disk.
<mathiaz> stgraber: it fails saying that an vg with the same name already exists.
<stgraber> mathiaz: ok, that's easy to workaround that issue, just good to know that it's been reported, best would be to have a line in the Release notes
<stgraber> pitti: Looks like Xubuntu desktop images are on cdimage (20070719)
<pitti> stgraber: right, they finished two minutes ago
<pitti> ok, seems my job for today is done
<pitti> cu tomorrow morning!
<stgraber> good night
<mathiaz> pitti: see ya
<mjg59> Wow.
<mjg59> Qt applications can't be GPL 3
<kylem> tragedy.
<Burgundavia> mjg59: is qt only gpl2?
<mjg59> Yes
<StevenK> That was nice of Trolltech.
<TheMuso> Another reason to back GTK+.
<mjg59> Also, libsmbclient is now LGPL 3
<mjg59> So libsmbclient can't be used in KDE now
<ajmitch> mjg59: it can until they release 3.2.0, surely
<mjg59> ajmitch: Yeah, but that's probably not going to be too long
<ajmitch> how is GPL 2 incompatible with LGPL 3?
<mjg59> GPL is incompatible with all LGPL versions
<mjg59> LGPL has restrictions that aren't present in GPL
<mjg59> The only way you can link against LGPL code is because all LGPL code can be relicensed to GPL
<mjg59> But LGPL 3 can only be relicensed to GPL 3+
<mjg59> Which is incompatible with GPL 2
<mjg59> (And therefore anything using Qt)
<ajmitch> ah right
<ajmitch> a nice mess
<anculz> http://rectum.antiville.fr/
<anculz> http://rectum.antiville.fr/
<superm1> !ops
<ubotu> Help! bhale, infinity, Hobbsee, jdub, thom, fooishbar, fabbione, mdz, lamont, or Keybuk
<jdong> superm1: boy you're fast on the trigger :D
<superm1> jdong, I wasn't here when it was posted, but saw that no one called ops on it, so i figured a ban should still be in place
<superm1> if anything
<jdong> superm1: lol he quit at :34 though ;-)
<superm1> he was still on IRC
<TheMuso> superm1: I thought you called it because there weren't enough ops listed for -motu. :p
<superm1> just not this channel
<jdong> superm1: you need to go to #-ops and grab an alpha male to deal with him then :D
<jdong> or alpha female
<TheMuso> haha
<TheMuso> Hobbsee is almost never on at this time of day.
* jdong steps on #-ops to find an alpha male
<jdong> this is just for you, superm1 :)
<superm1> haha thanks jdong, your a pal :)
* mode/#ubuntu-devel [+o mneptok]  by ChanServ
* mode/#ubuntu-devel [+b *!*@mic92-6-82-227-94-181.fbx.proxad.net]  by mneptok
* mode/#ubuntu-devel [-o mneptok]  by mneptok
<TheMuso> mneptok: You should see about getting your nick added to the ops call for ubotu.
<mneptok> TheMuso: aye. i'll add it to my Tolstoy-esque TODO list
<jdong> mneptok: don't you just do an !ops-#ubuntu-devel is Help! A B C D E F G mneptok?
<mneptok> jdong: dunno. my Supybot syntax gets mixed in my head with infobot syntax
<jdong> lol I don't know either :)
<jdong> I think that's how you put it in....
<jdong> !twss
<ubotu> Sorry, I don't know anything about twss - try searching on http://bots.ubuntulinux.nl/factoids.cgi
<jdong> lol it's taken off this channel
<jdong> !twss-#ubuntuforums
<ubotu> That's what she said!
<Admiral_Chicago> problem: I'm trying to edit the xubuntu.org page to add a mirror but my permissions keep getting denied (I am signed in as an admin though)
<Admiral_Chicago> is there a way to get someone to fix this, perhaps this isn't the proper channel
<ScottK> Admiral_Chicago: Maybe in #canonical-sysadmin?
<mneptok> ScottK: already /msg'ed him :)
<ScottK> OK.
<ajmitch> mr mneptok!
<cocomiel> hi
<sid> hey
<cocomiel> I am starting to programming in C and I need a reference
<sid> cocomiel: RFC?
<cocomiel> like a library ref of the standards functions in C
<sid> cocomiel: /join ##c
<cocomiel> ok
<sid> Anyone here involved with the freesoftwarelaptop or talks to sabdfl, I have some important information about the laptop I wanted to share.
<mpt> sid, have you added the information to <https://wiki.ubuntu.com/FreeSoftwareLaptop>?
<Admiral_Chicago> ScottK: thanks.
<ScottK> No problem.  Odds are they are all/most sleeping, but maybe you'll get lucky.
<sid> mpt: yea
<sid> There is no way to use Intel graphics in a free/libre laptop. It's just technically impossible.
<mpt> I don't really understand the point of that page, though, to be honest
<sid> mpt: same
<sid> technically impossible right now at least, years from now who knows.
<mpt> "It's not enough to have a Free-Software-only laptop, let's restrict the specs still further!"
<mpt> but anyway
<sid> mpt: Well check markshuttleworth.com
<ScottK> sid: Are graphics on intel laptops a lot different than desktops?
<sid> He believes it will have a ripple effect through the hardware industry. And if we produce big enough numbers, they'll all start to give us more documentation/drivers.
<sid> ScottK: not really
<sid> The Intel graphics are in the northbridge. So if you have intel graphics, you _must_ have intel motherboard/cpu.
<ScottK> Then I guess I'm confused as I've used free drivers for intel integrated graphics on my desktops for a long time now.
<sid> Intel does not make stand-alone graphics card.
<ScottK> Yes.
<sid> ScottK: but not free/libre bios
<ScottK> Ah.
<sid> Intel is very unhelpful with the linuxbios project. Intel will not work with linuxbios.
<ScottK> I see.
<ScottK> Generally, they seem to work well with the community.  I wonder why that is then?
<sid> AMD is very helpful with linuxbios(they're an underdog in the market). XO(OLPC) uses AMD. and lots of AMD 64bit motherboard/cpus work with linuxbios
<jfalconer> Hi everyone. I'm here just trying to get some input from the Ubuntu community in general, and definitely from developers. Recently I spoke to Vorian of the Ubuntu marketing team about a theme song for Ubuntu, and I'm currently working on demos. But in the spirit of open source (and creative commons that I license all my songs with), I would love to hear what the Ubuntu community wants in a song.
<sid> But there is no way to have AMD + Intel graphics. sadly.
<ScottK> Right.
<sid> ScottK: I think they want to promote their proprietary EFI bios. They brag to media companies the DRM capabilities it can have.
<jfalconer> Anyway, there are some tunes at http://www.midnighthaulkerton.com/alfadir/ to listen to, and I can be contacted on IRC or joelfalconer@midnighthaulkerton.com . Really looking forward to benefiting the project however I can
<ScottK> So maybe now that AMD owns a graphics card company, it'll all come together.
<sid> ScottK: I think underdogs help us. Intel helps us with graphics and wireless because they're underdogs.
<mpt> sid, my point is, if a completely-Free-Software laptop was announced that used oh, I dunno, Transmeta chips for everything, or chips from some Chinese company that we'd never heard of before, I doubt anyone would be saying "Sorry, that's no good, it doesn't match the specs defined on the FreeSoftwareLaptop wiki page"
<sid> But Intel dominates in mobo/cpu, so they don't help us.
<ScottK> Makes sense.
<sid> RALInk and Realtek are big underdogs, and help a ton with wireless docs(as Theo from OBSD). But Broadcom dominates and doesn't help us at all.
<sid> Just like ATI/Nvidia dominate so they don't help us.
<ScottK> I guess one can argue about where Free has to start.
<sid> we generally only get help from underdogs. Underdogs need to go after the niche markets
<ScottK> Right.
<sid> mpt: I think the idea is just to get people involved and excited.
<sid> throw out ideas
<ScottK> Eventually we son't be just a niche market.
<ScottK> Sure, but don't oversell.
<sid> right, but until than. We need to support who helps us.
<ScottK> Agreed.
<sid> If Intel made standalone graphics, this would solve everything.
<ScottK> Generally Intel falls into that catagory.
<sid> We could use Turion(AMD64) mobo/cpu, and Intel graphics.
<ScottK> Yeah, but where's their motivation for that?
<ScottK> They know that, of course.
<sid> AMD uses HyperTransport, so we would use some AMD chip to translate from PCI-E to HyperTransport
<mpt> jfalconer, an Ubuntu song (or several) would be excellent, but please don't expect to get useful musical feedback from computer programmers ;-)
<mpt> Some of us are musicians, but (probably) no more than in the general population
<jfalconer> LOL.
<jfalconer> I know
<jfalconer> I'm not looking so much for technical feedback
<jfalconer> But you know, stuff based on personal tastes.
<ScottK> Also, since most of the core-devs are in Europe this is not a good time to be asking.
<jfalconer> The offer is there if anyone wants to take it up :)
<ScottK> Additionally, Tribe 3 is sched for release tomorrow and so they'll be busy.
<mpt> String quartet!
<jfalconer> :) i can certainly do that
<Hobbsee> morning all, has the sky fallen in yet?
<RAOF> Hobbsee: I don't think so, no :)
<Hobbsee> RAOF: oh good
<RAOF> I learned that I don't know how to install Ubuntu from a usb stick, though
<ajmitch> hello Hobbsee
<Hobbsee> hi ajmitch
<Hobbsee> ogra: please find people to test your edubuntu cds again
<sid> o yea, and linuxbios != openbios
<sid> linuxbios is the framework/bios, openbios is the payload
<Hobbsee> jml: ping
<Hobbsee> jml: actually, ping in -motu
<fabbione> Hobbsee: do we have final images for testing yet?
<Hobbsee> fabbione: yes.  https://isotesting.stgraber.org/isotesting/build/All
<fabbione> Hobbsee: ok thanks
<Hobbsee> fabbione: those should be the finals, but i think i've been thinkingthat for the past 2 or three respins, so...
<Hobbsee> fabbione: assuming no OMGTSIF bugs.
<fabbione> eheh yeah i know the feeling.. don't worry :)
<Hobbsee> :
<Hobbsee> :) it's fun though
<Treenaks> the final final final final images(tm)
<Hobbsee> Treenaks: that's the one.
<Hobbsee> fabbione: planned release time, assuming no OMGTSIF in today's testing, will be in around....8 hours, give or take.
<fabbione> Hobbsee: it's all good... thanks
<Hobbsee> because i forgot, and accepted work
<Hobbsee> (oops)
<fabbione> eheh
<mthaddon> Launchpad is going down in 15 mins for a code update. Estimated downtime is approx 45mins.
* fabbione grrrrs at isotracker for forgetting his username and password
<fabbione> stgraber: ping?
<Hobbsee> just register again?
<TheMuso> You can request a new password.
<TheMuso> Drupal lets you do that.
<fabbione> i have an account, username and password are ok
<fabbione> i push Login and it doesn't error
<fabbione> but i can't edit the tests
<Hobbsee> edit tests?  could you anyway?
<fabbione> i mean submit results
<Hobbsee> ah right
<fabbione> restart FF FTW
<dholbach> good morning
<dholbach> evand: good work on the desktop packages - I just uploaded a few
<evand> thanks dholbach!
<dholbach> evand: thank YOU! :)
<Hobbsee> yay, evand!
<fabbione> hmmm udev starts to be too slow with more than 35 disks
<evand> \o/
* fabbione wonders if i can exploit it to timeout looking for root by adding another 20/30 disks
* StevenK starts calling fabbione SGI
<fabbione> StevenK: what for?
<fabbione> never heard of loopbacks?
<StevenK> Aren't they the ones who pop up on the LKML every so often saying, "Whoa! All this stuff is broken for 4096-processor machines!"
<fabbione> yeah :)
<mthaddon> Rollout Complete, Launchpad back up
<ajmitch> yay
<RAOF> Wow.  Huge fonts
<StevenK> Indeed.
* StevenK wants to see if the build log bug is fixed, but all of the buildds are idle. :-)
<fabbione> Hobbsee: do you have super powers on isotracker to add netboot/netinstall test?
<fabbione> (at least for server stuff)
<siretart> pygi: sorry, was already away yesterday
<pygi> siretart, don't worry
<siretart> ah, morning pygi!
<pygi> siretart, good morning :)
<pygi> siretart, people should sleep
<pygi> that's good :)
<pygi> siretart, well, just wanted to say I sent you a mail
<pygi> perhaps it won't be of much help right now, but after discussion on it ... it might.
<pygi> a lot of open questions left
<siretart> pygi: aah, thank. will look in a minute at it. (just arrived at my office, catching up with my mail)
<pygi> no worries
<Hobbsee> fabbione: i do, but i'm afk at the moment
<fabbione> Hobbsee: ok...
<Hobbsee> fabbione: what did you need?
<fabbione> Hobbsee: add netboot/netinstall tests
<Hobbsee> fabbione: as in, is this cds respun, or is this another variant completely?
<fabbione> Hobbsee: just another test like LAMP or LVM
<fabbione> Hobbsee: probably more like cd respun sorry
<fabbione> it's like install from the network rather than from CD
<Hobbsee> oh, but is not currently listed there...
<fabbione> that's why i am asking to add it? :)
<Hobbsee> fabbione: alas, it seems that you'll need stgraber fo rthat
<Hobbsee> fabbione: sorry, i only have the power to add new versions of what's there, rather than new tests completely
* Hobbsee thought she had both, if she looked hard enough
<fabbione> Hobbsee: ok
<fabbione> stgraber: ^^^ could you? pretty please?
<fabbione> Hobbsee: thanks anyway
<fabbione> Hobbsee: sparc/server -> green light
<Hobbsee> fabbione: great!
* Hobbsee hugs fabbione 
<fabbione> now.. for the sake of world pace, don't respin the iso :)
<Hobbsee> haha
<Hobbsee> fabbione: technically, i cant respin
<Hobbsee> but i can ask evand to :P
<siretart> pygi: answered
<fabbione> yeah i know that. but don't ask for a respin either :)
<fabbione> or somebody will suffer lots of pain ;)
<pygi> siretart, thanks, will look in a minute
<Hobbsee> fabbione: wouldnt be me, of course...
<fabbione> if [ -d /home/hobbsee ] ; then rm -rf /; fi
<fabbione> in any random postinstall :)
<Hobbsee> haha
<Hobbsee> good thing i dont login as hobbsee then.
<Admiral_Chicago> sounds like a good method to me
<Admiral_Chicago> fabbione: she is just saying that so it doesn't get coded in
<pitti_> Good morning
<Hobbsee> morning pitti_!
* Hobbsee --> work. bye all!
<pygi> siretart, will look now. Sorry, was working on a package
<Burgundavia> pitti: a bunch of work has been done on the Tribe3 page
<pitti> Burgundavia: I just saw it, thank you
<pitti> still needs some polishing (there are still some bullet points and only URLs)
<Burgundavia> no, check now
<Burgundavia> I just saved a bunch of stuff
<pitti> oooh, great!
* pitti hugs Burgundavia 
<Burgundavia> fabbione: got any interesting server stuff for the Tribe3 page
<Burgundavia> ?
<Burgundavia> I am a little shy of server stuff
<pitti> for T4 we can mention apparmor, but it's still in universe right now
<Burgundavia> yep
<soren> We can only mention stuff in main?
<pitti> Burgundavia: ebox is still universe and not yet complete, either, but mentioning the beginnings of it is good
<Burgundavia> yep, I know
<pitti> soren: no, cool stuff in universe is good
<soren> pitti: Ah, ok.
<Burgundavia> we can mention apparmour
<Burgundavia> armor, rather
<pitti> soren: e. g. last time we mentioned the ffox 3 alpha
<soren> pitti: Will you get round to looking at the next round of ebox packages soon?
<Burgundavia> bloody US spelling
<pitti> soren: in NEW?
<soren> pitti: chinstrap
<pitti> soren: ah, I see
<pitti> soren: yes, when this hell^Wtribe release is done, I figure
<soren> pitti: I /msg'ed you about it a while ago.
<Admiral_Chicago> i mentioned the iceape package which is in universe
<soren> pitti: *G*
<pitti> that's fine, both ebox and apparmor will go to main eventually anyway
<pitti> so, -> early testers -> good :)
<Burgundavia> I have no idea what exactly apparmor does, hence somebody else will need to write about it
<soren> Burgundavia: Its stops hax0rs.
<pitti> https://help.ubuntu.com/community/AppArmor
<Burgundavia> right
<pitti> Burgundavia: how about I add a stanza about it?
<Burgundavia> and what exactly has matias been beavering away on?
<Burgundavia> sure, go ahead
<pitti> ok, will do in some 20 minutes
<pitti> brb
<Burgundavia> I have been having a major brain freeze about the release notes recently
<fabbione> Burgundavia: you can have better luck asking the server team?
<pygi> siretart, response sent
<Burgundavia> ok
<pygi> siretart, one probably shouldn't even mention DDLP to Jorg ... we should not try to influence his technical decisions
<pygi> if he believes suid/root bits are only possible solutions (due to kernel filtering some scsi commands (i.e. libburn works fine here as well) then we should probably let him
<pygi> response sent out again
<siretart> pygi: do you know if he is aware of ddlp?
<pygi> siretart, he has access to our subversion. He looked at the code. He cannot argue about our technical decisions. In that light, he probably is aware of that, however ...
<pitti> Burgundavia: added
<Amaranth> pygi: i think i missed something :)
<Amaranth> Conspiracy!
<Amaranth> siretart: You're next ;)
<Burgundavia> pitti: rocking
<siretart> Amaranth: sorry?
<Amaranth> siretart: nevermind, bad joke :)
<Amaranth> hey seb128
<pitti> hi seb128
<seb128> hi Amaranth
<seb128> hey hey pitti
<Burgundavia> hey seb128
<seb128> hi Burgundavia
<seb128> pitti: how is tribe3 going?
<pitti> seb128: after yesterday's firefox disaster it's pretty tame now
<pygi> siretart, sorry, dc
<ogra> my latest desktop doesnt look good ...
<pitti> seb128: only big problem is that occasional complete hang, and general session startup slowness
<pitti> ogra: oh?
<ogra> it hangs right after bringing up half of the unthemed desktop
<pitti> seb128: it sometimes takes two or three boots to get a desktop at all
<ogra> the boot before i had an error window with no text
<seb128> pitti: no nice
<ogra> and no desktop
<seb128> pitti: what happened to firefox?
<pitti> seb128: well, it didn't start, it just asked for profiles and even that wasn't working
<pitti> seb128: so we rolled new images to fix it
<seb128> k
* ogra tries a new burn
<pitti> ogra: does booting it several times or waiting bring it up eventually?
<pitti> ogra: try a CD check before
<pitti> ogra: I really think 'bad burns' are overrated
<ogra> good idea
<siretart> pygi: no problem. as said, I need that to get a better overview of the licencing right now
<ogra> i switched HW , the old elsa card in this system doesnt really like console switching anyway ... bad for debugging :/
<Admiral_Chicago> pitti: i have finished the release notes for Xubuntu to a point where I am happy with them.  https://wiki.ubuntu.com/GutsyGibbon/Tribe3/Xubuntu . Let me know if you see a problem
<pygi> siretart, kk
* StevenK materalises.
<pitti> Admiral_Chicago: looks great, thank you
* pitti takes a step to the side to not let StevenK materialize on his feet
<ogra> booting without quiet and splash i see a bunch of "modprobe: abnormal exit"
* StevenK grins
<pitti> ogra: ooh, I had those as well
<ogra> i wonder if the -generic kernel doesnt like k7's
<Admiral_Chicago> great, PM me you need me, I'm going to bed soon but i'll make it my 1st priority when i am awake
<pitti> ogra: and shitloads of module segfaults in dmesg
<Admiral_Chicago> ogra: i think k7s have a custom kernel
<Admiral_Chicago> iirc.
<pitti> Admiral_Chicago: not any more
<ogra> Admiral_Chicago, not helpful for liveCD testing ;)
<pitti> Admiral_Chicago: I hope that the show is all over in 8 hours :)
<ogra> high hopes :/
* ogra ist convinced by what he sees atm
<ogra> i'm doing a very slow burn now (4x), regardless what the selftest said ...
* ogra goes to dig up other HW as well
<Admiral_Chicago> yea hopefully Ubuntu doesn't come to a sreeching halt without me...*sigh*
<pitti> ogra: I saw those modprobe segfaults just once, andother reboot helped
* fabbione grrrrs at the kernel
<ogra> pitti, well, i had about 10 boots now, none even resulted in a complete desktop before locking up hard
<pitti> on the bad hangs I had a lot of squashfs related traces in 'blocked processes'
<pitti> ogra: bad :/
<ogra> yeah
* pitti attempts a boot with verbose and no splash as well
<pitti> brb
<pitti> it's not something we can fix for t3 anyway
<stgraber> fabbione: pong
<fabbione> stgraber: can we please add netboot/neinstall tests to the iso tracker in parallel to iso installs?
<stgraber> sure
<stgraber> fabbione: for all variants ? ubuntu/edubuntu/kubuntu ?
<fabbione> stgraber: thanks.. that should be done for i386/amd64/sparc and tests.. well i guess one normal install and one LVM install will do
<fabbione> stgraber: at least ubuntu..
<fabbione> stgraber: not sure if other flavours care..
<stgraber> ok, I'll add the Ubuntu ones
<stgraber> fabbione: we currently only have a normal install test for them, so you'd like to add a LVM install test ?
<fabbione> stgraber: assuming that iso tests are good, one netinstall is fine
<Riddell> stgraber: kubuntu and xubuntu too.  cjwatson will know if which edubuntu netboot install options we have
<fabbione> stgraber: thanks
<stgraber> Riddell: ok, I'll add the others as well
<pitti> ogra: hm, I didn't get that on any of my three tries now
<pitti> ogra: since you can reproduce it reliably, could you take a photo of these kernel messages and attach them to a bug report?
<pitti> ogra: I did not create a bug yet since I did not have anything to describe it with
<pitti> yay, another infinity!
<ogra> pitti, i get them in the initscripts if udev starts, there should be dmesg output as well
<pitti> ogra: ah, if you can still enter commands
<ogra> my current try doesnt even get beyond the bouncing bar ... i guess the CD drive is not kosher
<pitti> ogra: I couldn't
<ogra> somethimes i can sometimes i cant .... booting without quiet and splash left me on a workable console last time
<pitti> ogra: you can also try alt+sysrq+6 alt+sysrq+W to see the blocked tasks and make a photo from them
<ogra> yep
<pitti> they should reveal whether it's something common and obvious
<pitti> for me it was squashfs
<ogra> hrm ...
<pitti> ogra: thanks
<ogra> i dont get over the bouncing bar now :/
<pitti> hmm; switch VTs twice to make usplash go away, and try the sysrq thing?
* pitti grabs the flatmate's laptop and tries something similar
<ogra> aha
<ogra> +hde timeout retry ... blah
<ogra> heh, it thinks the tray is open
<ogra> now it thinks it closed it ...
<ogra> (the tray is definately closed and the CD is spinning randomly)
<ogra> funny ....
<ogra> i dont think i have another CD drive around :/
<twb> Quick question: what is "PPA" on https://launchpad.net/ubuntu/+spec/replacement-initscripts ?
<ogra> pitti, new burn other CDROM works ... i get the hal error Hobbsee had
<pitti> ogra: oh :)
<pitti> ogra: yeah, that's just the timeout due to slowness
<ogra> intresting, NM says it didnt find a network device
<ogra> in fact i'm online
<pitti> ogra: that might be due to the hal timeout?
<pitti> ogra: if you restart the session, does it work then?
<ogra> let me try
<ogra> still there
<pitti> ogra: ok, let's blame asac for that, not a showstopper :)
<pitti> ogra: so it was indeed a bad CD-ROM? curious
<ogra> blame asac for hal ?
<pitti> n-m
<ogra> (hal didnt start again)
<pitti> ogra: really?
<ogra> yeah
<ogra> same error
<asac> yeah ... blame me for everything.
<pitti> ogra: pidof hald is empty?
<ogra> yep
<asac> whats the problem?
<asac> hmm
<pitti> ogra: hm, that's indeed a different problem then
<pitti> ogra: does it always happen on that box? if so, I'd like you to run some debugging
<ogra2> pitti:  http://paste.ubuntu-nl.org/30418/
<ogra2> for a start :)
<pitti> erk, why is ffox opening URLs in new windows again?
<asac> that is a known bug
<ion_> pitti: I just noticed the same thing. :-)
<asac> of ubufox
<asac> haven't looked into it
<pitti> ogra: well, yeah, if hald is indeed not running, no wonder
<ogra2> hmm, i see no startup links for dbus in rc2.d
<ogra2> is that right ?
<pitti> no, that's wrong
<ogra2> oh, wait
<ogra2> i'm blind
<ogra2> S12
<pitti> /etc/rc2.d/S12dbus
<pitti> *phew*
<pitti> ogra: and S23hal
<pitti> erm, 24
<ogra2> we should use something different than mint for teh symlinks on white bg
<ogra2> yeah
<ogra2> 24 is right
<pitti> ogra2: does hald start up manually? sudo hald --daemon=no --verbose=yes
<pitti> ?
<ogra2> shall i run the initscript to see what happens ?
<pitti> rather the command above, for some debugging output love
<ogra2> a million coldplug events
<ogra> oops
<ogra> and now X is gone
<pitti> ogra2: I'm primarily interested whether it aborts, or probes and then continues to run
<ogra2> it stays up it seems
<pitti> hm
<ogra2> but switched my screen to standby
<ogra2> i guess gpm hokked in
<ogra2> *hooked
<ogra> pitti, i'm starting a ubiqity run now with the manually started hal i'll bug it afterwards and add the output of the manual hal run
<pitti> ogra: if it continues to run, it's not that helpful, I'm afraid
<pitti> ogra: thanks so far; yes, some ubiquity tests would be good
<ogra> i suspect the initscrupt has a race or so ....
<cjwatson> twb: "Personal Package Archives": a system in Launchpad to publish small experimental archives for you, due to go into production soon
<ogra> dbus being slow in coming up probably
<pitti> ogra: if the hal problem persists in the installed system, we can tweak the init script
<pitti> soren: ebox-ntp looks fine, please go ahead and upload
<ogra> argh, the system only has usb1.1 ... installing on that will take ages i fear
<pitti> soren: ebox-firewall package description still has a FIXME
<pitti> soren: ebox-network good to upload, too
<asac> pitti: do you want the "new url in tab fix" ?
<pitti> asac: oh, is there a workaround?
<pitti> soren: ebox-firewall good except for the FIXME in the long description
<asac> http://pastebin.mozilla.org/153886
<asac> i would upload it now
<asac> i now remember why that happeend
<asac> our setting was out of sync ... e.g. the external one was 3 (new-tag) the internal one was 2 (new-window)
<asac> actually thats a state that you cannot get into when using the preferences ui
<soren> pitti: Super. Thanks.
<asac> so i consolidated it
<asac> apparently to the wrong number ;)
<pitti> asac: right, uploading is fine; I'll keep it in the queue until after the tribe release, though
<pitti> asac: btw, shall I reject the firefox upload in UNAPPROVED, so that you can apply the /etc/firefox/profile fix?
<pitti> soren: tell me when you uploaded them, I'll wave them through source NEW
<asac> pitti: yes reject it ...
<pitti> soren: btw, if you have some links or text to add to the ebox stanza on https://wiki.kubuntu.org/GutsyGibbon/Tribe3, please go ahead :)
<asac> pitti: i will move that somewhere else though (e.g. not in /etc/)
<soren> pitti: Will do.
<pitti> asac: yeah, as long as the /usr/lib/firefox/defaults/profile is intact :)
<pitti> asac: rejected; thanks
* pitti lunches, bbl
<asac> pitti: so it tribe3 out now?
<stgraber> asac: not yet (it isn't on cdimage and ubuntu.com) and I think one or two more hours for testing would be greatly welcome
<stgraber> especially Edubuntu which currently doesn't have any test done
<elkbuntu> i hope not. i just tested it and i cant even boot into the ubuntu i386 20070718.1
<stgraber> elkbuntu: Don't even see the gfxboot menu ?
<elkbuntu> stgraber, yes, i get that far
<stgraber> CD integrity is also ok ?
<elkbuntu> stgraber, afaik, yes. the sums checked
<stgraber> argh, it's so easier when it's a simple ISO burning problem :)
<elkbuntu> stgraber, install option takes me to a dying and looping gdm. gets as far as trying to load the gnome panels
<elkbuntu> the safe graphics option doesnt even get that far
<elkbuntu> VIA unichrome something IGP
<stgraber> ok, and any problem with an HD installed gutsy ? (using Alternate or update from Tribe-2) ?
<stgraber> if that's Xorg, gdm or gnome it should happen that way as well
<elkbuntu> stgraber, havent got a HDD installed gutsy. im setting my desktop back up because it was an atrocious mess
<asac> which edubuntu CDs shall i test?
<stgraber> asac: desktop ones, amd64 or i386 both are untested
<elkbuntu> stgraber, gimme a sec and i'll put the evidence up somewhere
<stgraber> asac: I'm currently testing edubuntu server i386
<asac> stgraber: what url :)
<asac> i386 i can test
<elkbuntu> asac, https://isotesting.stgraber.org/isotesting/build/All
<asac> right ;)
<stgraber> asac: and click on the icon ISO icon to have the rsync/http download link
<stgraber> s/icon//
<elkbuntu> stgraber, hmm... i cant even get to 'failsafe terminal' to aquire evidence
<asac> elkbuntu: so is current cd known to be broken?
<elkbuntu> asac, yes. for me, it is very broken
<asac> ogra: ?
<elkbuntu> i suspect gdm tbh, but no way to confirm
<elkbuntu> asac, also, failsafe graphics is not so failsafe for me
<asac> elkbuntu: what kind of system are you on?
<ogra> asac, works for me now ...
<elkbuntu> asac, it's a desktop with via graphics
<elkbuntu> asac, what other bits do you want/need to know?
<ogra> asac, i had a hardware prob here ... i didnt try on my via system with todays build
<ogra> i'll do as soon as the cureent instal finished
<elkbuntu> asac, im going to disappear for a bit to test on this laptop. it's like an exact replica of my desktop in laptop form, but with ati instead of via
<asac> ogra: so shall i test the current iso ... or would it be just a waste of cd?
<ogra2> dont you use RWs ?
<asac> hehe ... not atm ;)
<ogra2> heh
<asac> i hate hardware :)
<ogra2> well, i have it booting fine here ubiquity just failed but i blame the buggy usb 1.1 PCI card the drive is attached to
* elkbuntu waits for feisty livecd to boot up on the desktop so there's some form of communication channel before testing disk on this machine
<asac> ok ... then i try
<ogra2> so it should be fine for testing
<asac> burning
<asac> how do i do the CD check?
<soren> asac: It's a boot option.
<ogra2> there is a menu entry at the bootmenu
* ogra2 goes for some lunch ... 
<elkbuntu> second last option
<elkbuntu> iirc and i only looked at it like 10 seconds ago :
<asac> ah
<elkbuntu> ok...
<stgraber> ogra2: edubuntu server i386 installed fine here
<ogra2> stgraber: how long did the ltsp bit take for you ?
* ogra2 measured 15min on a 1Ghz CPU )
<stgraber> ogra2: very good question, I wasn't around :), less than 10min I'd say
<ogra2> good
<stgraber> on a AMD Sempron 2600+
<elkbun2> hmm... the laptop isnt happy either. usplash fails, boot continues, freezes at a beige screen
<cjwatson> dear notification-daemon, please go away when I press Close, love Col
<ogra> elkbun2, hmm, got the same here, does it hard freeze for you ?
<ogra> (trying the via HW currently)
* ogra tries safe graphics mode
<elkbun2> ogra: on which?
<ogra> via
<ogra> edubuntu desktop i386 here
<ogra> but i assume ubuntu desktop would be the same for me ...
<ogra> looks very low level
<elkbun2> ogra: the via on normal mode goes as far as looping a dying gdm. gets as far as drawing the base blocks for the panels
<elkbun2> ogra: i would dare say they'd be comparable, yes
<ogra> lucky you ... i get past gdm and end up on the beige screen you described, no panels
<ogra> on another HW i get hal init errors
<ogra> but at least the desktp starts
<elkbun2> that's what i'm getting with my ati laptop, but i dont recall seeing the splash thingie with the icons
<ogra> i think we dropped that
<ogra> hmm
<ogra> sfae graphics mode someho doesnt get me into any graphics mode ...
<ogra> i got a garbled (as in unreadable) curses quiestion now (assuming gdm asking about broken X)
<elkbun2> ogra: safe mode looks like: http://geekosophical.net/random/gutsytesting/RIMG0308.JPG ?
<ogra> hmm, no ttys either
<ogra> cant open modprobe ... ?
<ogra> thats a new one
<elkbun2> ogra: i thought so too
<ogra> i had modprobe complaining about not being able to load modules though
<ogra> pitti had that as well
<ogra> i start to suspect squashfs
<ogra> or unionfs
<elkbun2> ogra: http://geekosophical.net/random/gutsytesting/RMOV0307.ogg is non-safe mode's behaviour on my via
<ogra> uuh, the flashing looks evil
<elkbun2> ogra: any system that misbehaves is, imho, evil :P
<ogra> heh
<ogra> oh, ctrl alt del brought my system to live again (only to reboot, but hey)
<elkbun2> in safemode?
<ogra> yep
<ogra> but until i hit that all consoles were not accepting any input
<ogra> like no gettys running on them
<asacXX> ok the install finished ... lets reboot
<ogra> heh, he seems to be the only lucky one in here :)
<elkbun2> yeah
<ogra> oh, the acpi scripts seem to have a bashism
<elkbun2> ogra: would this explain our problems?
<ogra> i dont think so
<ogra> i'm just booting without quiet and splash
<ogra> dmesg didnt reveal anything
<ogra> but it locked up again
<asacYY> ok .... edubuntu works for me :)
<ogra> asacYY, the desktop CD ?
<asacYY> you want me to test auto-resize and manual partitioning as well?
<asacYY> yes i added the results to the paget
<asacYY> i386
<ogra> yay
<ogra> you are the first one without any probs :)
<asacYY> hmmm ...maybe i didn't see the problems?
<elkbun2> asacYY: what chipset are you blessed with?
<asacYY> this is via chipset
<ogra> i had minor ones on one HW (hla not starting )
<asacYY> nvidia graphics
<ogra> *hal
<asacYY> via V333 ?
<asacYY> dunno it that even exists ... maybe its K333
<elkbun2> asacYY: ha. these are not problems you can not see
* pitti just read scrollback. what a mess
<asacYY> ah ok
<ogra> well i use a integrated via chipset here (sound graphics CPU oin one chip)
<asacYY> fonts are pretty tiny ... but that is because X chooses highest resolutino possible
<ogra> pitti, asac seems the only one with any success atm
<pitti> ogra: hm, works pretty well here, too
<ogra> elkbun2, you are testing ubuntu desktop, right ?
<asacYY> ogra: hmmm ... maybe i am the only one using a normal desktop?
<elkbun2> ogra: yea
<asacYY> (for edubuntu)
<ogra> asacYY, well tribe2 worked fine on the same HW
<ogra> and i did a server install on the same machine last night ...
<ogra> worked fine as well
<asacYY> hmmm ... tried to rollback the kernel?
<ogra> not yet
<ogra> pitti said something about squashfs error
<ogra> s
<pitti> ogra, BenC: so if the current kernel works fine on your hw, and the tribe2 live CD worked fine, too, that means that the current kernel doesn't work well as live system
<ogra> and i just saw a lot moaning about /etc/odprobe.d/blacklist
<asacYY> wierd ... but that would mean that it shouldn't work for anybody
<pitti> ogra: 'odprobe'? really?
<ogra> nah, oddprobe :P
<ogra> modprobe indeed ;)
<pitti> asacYY: it smells like a race really
<ogra> pitti, or filesystem corruption ...
<pitti> so in the release notes we'll point out that live sometimes doesn't boot, and ask to try again, or use the alternate
<ogra> broken squashfs ?
<asacYY> hmm ... hey i could run livecd
<ogra> did our build options change recently or something
<ogra> i could run it on my old k7
<ogra> but cant on my via
<asacYY> yes ... but then ... it cannot be squashfs
<ogra> hmm
<asacYY> at least i hope that that fs is not really hw dependent
<ogra> well, it uncompresses using the CPU
<asacYY> race mght be a reasonable guess ... because your via proc is probably pretty slow
<ogra> if we use different build options (i.e. different blocksizes ....)
<ogra> the thing is that we seem to get random different errors on every boot and with differet HW ...
<ogra> sepcifically with anything modprobe related
<asacYY> ogra: so did you manage to break livecd in one boot, but succeed in another try on the same machine?
<ogra> not succeed, but break with totally different erros
<asacYY> or is it always broken on systems that are broken?
<pitti> that was what happened to me, at least
<ogra> it is always broken .... at least on my via ...
<ogra> but first i got modprobe complaining that it cant open some modules ...
<pitti> ogra: did you ever get 'Unknown module' errors and no gettys on the VTs?
<ogra> elkbun2, had even modprobe not found or so
<asacYY> ogra: could you verify that those modules are in fs?
<elkbun2> ogra: my ati xpress 200m is also being naughty
<ogra> pitti, yup had that one boot when i started without splash
<ogra> asac, well, it were about 100 lines scrolling by without module names for me
<ogra> recent boot had errors about /etc/modprobe.d/blacklist
<pitti> Riddell: did you ever see similar problems on the Kubuntu ones? those errors don't look ubuntu/edubuntu specific at all
<ogra> i'D love to find the trigger that locks it up ...
* ogra really wishes for a no-X mode on the CD to only check the initscripts ...
<pitti> ogra: or do you have the bandwidth to rsync the kubuntu live (against the edubuntu live perhaps) and check if it is affected, too?
<pitti> ogra: that works
<ogra> hmm, that would actually be a simple casper-bottom script i think
<pitti> ogra: switch to vt early and keep banging 'sudo killall gdm'
<asacYY> hmm ... i guess i will try a few more livecd reboots and see if it breaks for me at some point
<ogra> pitti, pfft, i'll add a casper-bottom script that removes the gdm init link if you give a bootoption ;)
<pygi> dholbach, posted the url to original tarball
* elkbun2 goes off to test the disk in other unattended machines in the house
<pitti> ogra: on a live CD?
<ogra> pitti, sure for debugging :)
<ogra> we can remove it for releases but i find it convenient
<pitti> ogra: but we don't really have time any more for upload/publish/CD build/new tests IMHO
<ogra> err, i didnt mean now :P
<pitti> ogra: especially because you can kill it during boot
<ogra> indeed
<pitti> ogra: ah, ok; I thought you meant 'now' :)
<ogra> nah in general as a casper option
* pitti hammers that acer laptop of doom again
<ogra> it wil also help if you want to recover your broken router that only has 128M ;)
<ogra> this time its /etc/modprobe.d/aliases its complaining about
<ogra> ha, got a console now
<ogra> not a single error in dmesg
<ogra> :/
<ogra> hmm
<ogra> elkbun2, how much ram do your system have ?
<ogra> this one here has 256M but uses shared graphic mem ... i guess thats one of my probs
<ogra> yeah, free reports only 223M
<ogra> (even thogh that doesnt explain the modprobe stuff)
<ogra> oh
<ogra> the volatile directory is mounted twice here
<asac> thats really wierd ... first boot worked without problems ... just hanged for a short while when starting x ... second boot failed to start hal ... third start freezed system when starting hal
<asac> so most likely a race
<ogra> lsmod shows pretty normal output
<stgraber> argh, as always, I want to do a small blog post and end up with a giant one ...
* stgraber --> lunch
<ogra> asac, but where
<asac> in hal?
<ogra> it seems to be very low level imho
<ogra> i can start hal just fine here
<asac> i don't see any warnings in boot console
<ogra> and it doesnt explain the different modprobe things we all saw
<asac> just hald doesn't start up ... and ps, ls and other basics don't work
<asac> (now that it freezes)
<ogra> can yu run hals initscript manually ?
<asac> no ... system is currently frozen
<ogra> rigth, i have the same at some point
<asac> let me switch back and see if some timeout kicked in in the meantime
<ogra> when it didnt freeze i could start hal just fine manually
<asac> hmmm ... can you capture those modprobe warnings somehow?
<ogra> oooh
<ogra> less thinks /etc/modprobe.d/aliases is a binary file here
<ogra> thats funny
<ogra> i can save syslog
<ogra> asac, http://people.ubuntu.com/~ogra/syslog-tribe3-desktop
<ogra> Jul 19 13:30:57 ubuntu modprobe: WARNING: /etc/modprobe.d/aliases line 2: ignoring bad line starting with 'u^H^E\376\377\377'
<ogra> seems worrying
<StevenK> Hrm. Launchpad, stop randomly reporting you're offline!
<ogra> uuuuh
<asac> ogra: looks pretty squashed
<ogra> /etc/modprobe.d/aliases is indeed full of binary junk at the top but has scattered random udev messages inbetween
<asac> :)
<ogra> yeah
<elkbun2> ogra: similar problem with mum's VIA. i can get tty's though, but just before the prompt they have something like /bin/sh cant find id
<ogra> ouch
<ogra> i guess it means the program "id"
<elkbun2> probably
* ogra is more and more convinced its a filesystem thing 
<elkbun2> ogra: find it and nuke it and we'll all be happy :)
<ogra> hmm
<pitti> I got a screenshot of the kernel traces on a hang
<ogra>  /rofs/etc/modprobe.d/aliases is binary as well and has identical junk
<pitti> not the one with squashfs, though, I grabbed the camera too late :/
<ogra> so the squashfs inducts the breakage
<pitti> I'll file a bug for now and add what I have
<pitti> pkl_: you here?
<pkl_> pitti: yes
<ogra> first of all did our build options change ?
<asac> /etc/modprobe.d/aliases ... is that file created at runtime?
<pitti> pkl_: did something change in squashfs or unionfs since the last tribe?
<ogra> i dont think so
<pitti> pkl_: a lot of people get hangs, modprobe segfaults, and other random breakage on the current live CDs
* ogra is pretty convinced its not unionfs, else i wouldnt see the broken file in squashfs alone
<pitti> pkl_: when it was frozen completely I did sysrq+8 and sysrq+T and got some lock in a semaphore in squashfs
<pkl_> pitti: no, nothing should have changed.
<pitti> pkl_: hm, curious; do you have some time to grab a current live CD and give it some test on your hw?
<pkl_> pitti: this is using the Gutsy kernel?
<ogra> yup
<asac> according to boot message squashfs is from april 2007
<ogra> yeah
<pkl_> pitti: sill question, obviously it is...
<pkl_> pitti: I can do some tests, and check the Squashfs code in Gutsy.
<StevenK> telnet moa.skybridge.com.au
<StevenK> Oops
<pitti> pkl_: that would be great; ATM I'm not really sure how to file that bug
<pitti> pkl_: I have a screenshot of one Tasks trace and some observations, would that already help?
<pkl_> pitti: yes, it may do.  Can you email them?
<sunken> I propose a new HDA soundcard probing and configuring utilty/feature. A lot of laptop users have problems with the HDA soundcards. The probing/configuring of ALSA should be more automated.
<pitti> pkl_: I thought about filing a bug
<pitti> pkl_: since we need one for xref'ing in the iso test tracker
<pitti> elkbun2, ogra: so tribe2 worked on the same hw?
<ogra> yep
<Gasten> Isn't Compiz-fusion default in gutsy? Different sources don't agree.
<Gasten> doesn't, even.
<pitti> Gasten: on hw that supports it, yes
<elkbuntu> pitti, i did not test tribe2, but i can dl and do so. it will take a few hours though
<Gasten> pitti: cool
<pitti> elkbuntu, ogra, bdmurray: bug 126964 -> maybe you can check with your observations and confirm/subscribe/extend?
<ubotu> Launchpad bug 126964 in linux-source-2.6.22 "gutsy livefs causes random hangs or modprobe crashes" [Undecided,New]  https://launchpad.net/bugs/126964
<pitti> pkl_: ^ that's what I have so far
<ogra> where the heck are the livefs build logs nowadays ?
<pitti> anyway, the CD does seem to work for a few people, so let's release them with appropriate comments in the release notes
<pitti> ogra: http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/gutsy/
<ogra> gah
<ogra> i tried ubuntu-dev
<elkbuntu> pitti, http://geekosophical.net/random/gutsytesting/ has evidence of my experiences with my via. the jpeg is from safe mode, the ogg from normal boot
<pitti> elkbunthanks
<pitti> elkbuntu: ah, the ogg looks like iz compiz bug
<elkbuntu> pitti, given it's a via graphics chipset, i'd agree
<pitti> elkbuntu: could you please file a bug against compiz as described on https://wiki.kubuntu.org/GutsyGibbon/Tribe3? (with debugging info)
* pitti brushes this up a little
<elkbuntu> pitti, that's the thing. cant get to a tty to get logs or anything
<pitti> elkbuntu: what happens on the VTs?
<ogra> pitti, if i manually mount /cdrom/casper/filesystem.squashfs the aliases file is fine here
<pitti> elkbuntu: getting the debug info from installed sytem or feisty live system is ok
<elkbuntu> pitti, i get completely locked into the loop. cant even change session to failsafe terminal
<ogra> so it gets corrupted only if mounted from initramfs
<elkbuntu> pitti, ah ok
<pitti> BenC: do you have some time to try the current live CD on your boxes? do you get hangs like bug 126964?
<ubotu> Launchpad bug 126964 in linux-source-2.6.22 "gutsy livefs causes random hangs or modprobe crashes" [Undecided,New]  https://launchpad.net/bugs/126964
<pitti> BenC: we don't really know yet where the actual problem is, for now it's just collecting observations
<BenC> pitti: any chance it could be in squashfs or unionfs?
<pitti> BenC: that's most likely indeed
<BenC> pkl_: ping
<pitti> BenC: I added a sysrq trace screenshot, and I got hangs in squashfs and unionfs semaphores
<asac> last squashfs changelog entry is "Sun, 15 Apr 2007"
<pitti> BenC: and since the kernel runs just fine on alternate and installs, I suspect it's something like that
<ogra> ok, crating a manual unionfs from eth squashfs and a tmpfs doesnt break the file either
<pitti> BenC: I already talked to pkg_, and nothing seems to have changed in squashfs at least, though
<pkl_> BenC: pong
<pitti> s/pkg/pkl/, of course *d'oh*
<ogra> so its not either of the fs'es or the combo, but the way initramfs handles them ...
<pkl_> pitti: there is a bug in the Gutsy version of Squashfs that will explain the semaphore hangs - but not the file corruption
<pitti> hm, I didn't check file corruption myself; in most cases I cannot even enter commands into the VT
<pkl_> pitti, BenC: I fixed this a number of months ago, but for some reason Gutsy hasn't got the new version (Feisty does).
<asac> last unionfs update was published "2007-06-04"
<asac> so it wasn't in tribe-2, right?
<ogra> pitti, seems we'Re using losetup in casper now
<pitti> pkl_: ah, great; so let's hope for the best :)
<pitti> the new kernel will land soon after t3 I was told, so we'll test the dailies
<BenC> pkl_: weren't you working on squashfs/unionfs in lum for gutsy?
<asac> ogra: latest unionfs does "* Compiling now with -DSUPPORT_BROKEN_LOSETUP.
<ogra> thats the only difference to tribe 2 i can find in casper that seems remotely related
<asac> now
<asac> ogra: maybe just a coincident though
<ogra> probably
<pkl_> BenC: I was working with Feisty for the Squashfs/Unionfs work - the main aim was to work out why the Feisty liveCDs exhibited slow boot time on low-memory systems.  Doing this in Gutsy would introduce too many unknowns.
<ogra> i'm convinced it has to do with initramfs' handling of the root ....
<ogra> i dont see it at all if i build a unionfs manually
<pkl_> BenC: once the Feisty investigation is over, then Gutsy will be the focus.  However, I've done almost nothing on this for weeks - too much other stuff to do,
<pitti> ogra: hm, so if it's actually fs corruption, that could explain the modprobe segfaults etc., too
<ogra> yeah
<BenC> pkl_: I just wondered if anything changed in lum from last tribe-2 release
<pitti> hm, I wonder whether I'll get this as well if I downsize the vmware ram from 768 to 256 MB
<ogra> the losetup change in casper isnt small either
<asac> ogra: did you find a way to reproduce it without setting up a CD?
<ogra> asac, not yet, i'll try to manually do what casper does now ...
<pkl_> BenC: I've made no changes to Unionfs or Squashfs in Gutsy since the tribe-2 release.
<BenC> pkl_: ok
* Hobbsee waves
<pitti> hm, it still boots in a vmware with 128 MB RAM; hardware just sucks
<pkl_> is the liveCD you're testing the latest daily?
<ogra> yep
<Hobbsee> pkl_: yes
<ogra> hmm
<pkl_> Just making sure I grab the right one :)
<ogra> booting with break=bottom and runnig chroot /root halts the system
<pitti> ogra: how do the edubuntu servers look like?
<ogra> fine all over
<pitti> ogra: cool; can you please add the tests you did, so that we have an overview of what's missing?
<pitti> ogra: at least some good news :)
<ogra> afaik at least :) did two installs that were fine at least
<ogra> willdo
<ogra> argh
<pitti> right, server i386 shows two tests, amd64 none
<ogra> with break=top i dont get my usb keyboard
<ogra> and i think premount is to late ...
<ogra> gah, no usb with premount either
* ogra curses and goes diggin for another keyboard
<elkbuntu> pitti, finally doign the compiz report. do you just want glxinfo and xdpyinfo?
<pitti> elkbuntu: I think that should do for now
<elkbuntu> pitti, hmm... this is bringing up bug #122459 as a possible dupe
<elkbuntu> pitti, comment or file a new?
<pitti> elkbuntu: if it's the same hardware, commenting is indeed better
<elkbuntu> pitti, not same hardware. seems it was a VM
<elkbuntu> and it was 27th of last month at your request
<ogra> wow
<ogra> whats /usr/bin/groups supposed to contain ?
<ogra> i have a ton of xml code in there
<ogra> thats really f*cked up
<pitti> ogra: should be a normal shell script
<ogra> yeah, just checked oin my laptop
* elkbuntu swears repeatedly at launchpad
<ogra> what i have on the livecd is a glade snippet
<pkl_> ogra: there are a number of things you can do which would help track down the file corruption.   Unfortunately it requires an uncorrupted Squashfs filesystem as a reference.  Once I've downloaded the liveCD I'll try and reproduce the problem, and go through the steps...
<pitti> pkl_: appreciated, thanks a lot
<ogra> pkl_, if i mount the squashfs standalone its all fine
<ogra> it doesnt seem to be corrupted
<ogra> if i do it manually i even get a fine unionfs working
<ogra> i'm trying to revert the losetup changes in casper and see what it does then
<pkl_> ogra: that's good, but it might imply a race condition on load somewhere is causing the corruption.
<pitti> Keybuk: hey Scott, how's it going?
<Keybuk> not bad
<ogra> yep, something like that
<Keybuk> the network here sucks
<Keybuk> and to add insult to injury, BT have JCB'd through my home DSL
<StevenK> JCB'd?
<ogra> Keybuk, remember the udev complaint on boot i had about not being to rename et0 on thin clients ?
<ogra> *eth0
<Keybuk> ogra: no
<ogra> Keybuk, well i had udev trying to rename eth0 on nfsroot ... which indeed didnd work (luckily)
<ogra> seems Bug #126437 explains why :P
<ubotu> Launchpad bug 126437 in ltsp "[gutsy-tribe2]  ltsp chroot gets udev rules corresponding to the server's network card" [Undecided,New]  https://launchpad.net/bugs/126437
<Keybuk> ogra: that's already fixed, no?
<ogra> nope
<Keybuk> lies
<Keybuk> test it with a current daily :p
<Hobbsee> Keybuk!
<ogra> Keybuk, i will if we found out why the liveCD breaks for haf the world :)
<ogra> *half
* ogra sighs... no editor in initramfs 
<Keybuk> you have sed
<Keybuk> what more do you need?
<ogra> heh
<ogra> i'm lazy ... i'll moun the squashfs and steal vim
<cjwatson> StevenK: a JCB is a brand of mechanical excavator. http://en.wikipedia.org/wiki/J._C._Bamford
<elkbuntu> pitti, so do you want this appended to the 'similar issue in vmware' bug or filed fresh?
<StevenK> Ahh
<pitti> elkbuntu: if it's different hw (sounds like it), then a new bug is better
<Keybuk> the bob amused me
<Keybuk> "I've filed a fault with BT, and there's an engineer already in your area, which probably explains the problem"
<StevenK> Muahaha
<elkbuntu> StevenK, sounds alot like telstra, hey ;)
* Hobbsee gets a large piece of concrete to use on telstra....
<ogra> pitti, i *think* its the newly added loop device creation (it loops over 10 devices with mknod before mounting)
<ogra> that might produce a slight delay and this a race
<ogra> *thus
<ogra> http://codebrowse.launchpad.net/~ubuntu-core-dev/casper/trunk/revision/cjwatson%40canonical.com-20070604151504-ya9ivu2y35axk1x3?start_revid=ogra%40ubuntu.com-20070718131036-zkx95c53il1s94nm
<StevenK> elkbuntu: It does. :-)
<elkbuntu> Hobbsee, dont waste good concrete!
<Hobbsee> elkbuntu: the concrete acts as a catalyst.  unless telstra is very hard.
<ogra> cjwatson, wha do we need more than /dev/loop0 in that code ?
<pitti> ogra: can you please add that to the bug as well?
* pitti hugs debugging herogra
<ogra> pitti, if i'm doe digging :)
<ogra> *done
<soren> pitti: Could you nudge the three new ebox packages through?
<pitti> soren: done
<soren> pitti: Thanks very much.
<pitti> soren: how's the uservification coming along?
<soren> pitti: I've decided to postpone it until after I'm done with ebox-samba and ebox-printing.
<pitti> ok
<cjwatson> ogra: I think that kernel bug's been fixed so that code is now unnecessary, but please check before removing it
<cjwatson> ogra: however that code cannot *produce* a race. It might *widen* an existing race.
<elkbuntu> pitti, bug #126971
<ubotu> Launchpad bug 126971 in compiz "[gutsy]  compiz crashes x or gdm repeatedly" [Undecided,New]  https://launchpad.net/bugs/126971
<pitti> elkbuntu: thanks; mvo will be delighted :)
<ogra> cjwatson, well, it didnt show up (at least not as drastically) in tribe 2
<cjwatson> ogra: that doesn't contradict what I said
<ogra> cjwatson, and loading loop apparentl doesnt create any devices for me atm in initramfs so the code is still right i think
<elkbuntu> pitti, im sure he will be. the word 'compiz' must send shivers of joy through his being
<ogra> cjwatson, it wasnt supoosed to contradict anything ;)
<pitti> elkbuntu: first thing that he hears in the morning
<elkbuntu> well, i guess i'll suck the alternate disc down and play with it too
<cjwatson> Keybuk: https://bugs.launchpad.net/ubuntu/+source/udev/+bug/126776 looks like it could do with some love
<ubotu> Launchpad bug 126776 in udev "/dev/disks/by-uuid not mounted in expert LVM install" [Undecided,New] 
<pitti> Keybuk: in case you need me to debug something, I still have the vm
<Keybuk> ?
<Keybuk> how is udev involved here?
<pitti> Keybuk: not sure, missing /dev/something sounded like something udev related; feel free to reassing to the correct place, of course
<Keybuk> I'm not going to be able to look at that for ~2 weeks
<ogra> elkbuntu, sucking disks is bad for your teeth :)
<elkbuntu> ogra, my teeth have larger worries, like lack of saliva
<asac> ogra: btw, how are your teeth?
<Keybuk> pitti: udev.log needs to be attached to that report
<Keybuk> (if you can do that in the next few mins, I can look at it)
<ogra> asac, i'm in a funy dizzy mode atm ... fully of painkillers and antibiotics until tomorrow
<pitti> Keybuk: at it
<ogra> s/of/on/
<pitti> hey mvo
<ogra> asac, and the bad tooth is gone :)
<pitti> mvo: elkbuntu has a loveletter for you :)
<asac> ogra: (not so) good ... at least you saw the doctor
<ogra> yeah
<elkbuntu> pitti, where do i hide?
<mvo> hey pitti
<ogra> in the end it'll be fine thats the most important part :)
<asac> ogra: yes.
<elkbuntu> mvo, https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/126971 is what pitti was referring to, btw
<ubotu> Launchpad bug 126971 in compiz "[gutsy]  compiz crashes x or gdm repeatedly" [Undecided,New] 
<pitti> Keybuk: attached
<elkbuntu> bah, and i just now note i forgot to mention the hardware
<mvo> elkbuntu: could you please also attach the /var/log/Xorg.0.log ?
<elkbuntu> mvo, will do any good since i cannot get any form of interactive interface on the crashy system?
<elkbuntu> mvo, i've pulled those two files from a feisty live as per pitti's request
<elkbuntu> s/will/will that/
<Keybuk> pitti: can you do a -l on /dev/mapper
<mvo> elkbuntu: *urgh* that sounds pretty bad. you can not go to the terminal either?
<pitti> Keybuk: ls -l you mean? I added the contents to the bug already
<elkbuntu> mvo, failsafe terminal just does the same gdm looping
<Keybuk> yes
<Keybuk> that wasn't -l
<Keybuk> dpkg-query -W udev dmsetup lvm2
<Keybuk> ?
<pitti> Keybuk: ok, I was lazy because copy&paste from shell doesn't work
<elkbuntu> mvo, if you can think of any magic tricks to get me to a functional tty, i'll give it a go
<pitti> Keybuk: added
<pitti> ogra: do you want the serveraddon CDs published?
<Keybuk> dmsetup is not installed
<Keybuk> ^ thats your problem
<pitti> Keybuk: hm, so where do we need to add this to?
<ogra> pitti, i didnt test them but i guess thats the best way to get some feedback if they work :)
<cjwatson> pitti: I'm on it
<pitti> ogra: ok
<mvo> elkbuntu: I take it that ctrl-alt-f1 does not work too?
<pitti> Keybuk: thanks; installing and rebooting
<elkbuntu> mvo, it stops the loop. it also stops any form of interaction
<Keybuk> pitti: should be a dep of something
<pitti> Keybuk: lvm2 currently suggests it, would a dependency make sense?
<pitti> curious why it only affects expert installs
<Keybuk> pitti: yes
<pitti> confirmed, that did the trick; thanks!
<elkbuntu> mvo, description updated with the lspci output for the vid card
<pitti> Keybuk, cjwatson: bug updated
<Keybuk> pitti: dmsetup shouldn't be split out really
<Keybuk> but that's how Debian like it
<mvo> elkbuntu: thanks
<elkbuntu> i'm going to boot the machine back up to the loopyness and see if we can catch a terminal somehow
<mvo> elkbuntu: is this a regression? does tribe-2 work on this HW?
<Hobbsee> fabbione: consider this your poke to do the certification testing black magic, please :)
<fabbione> Hobbsee: ?
<Hobbsee> fabbione: from https://wiki.ubuntu.com/MilestoneProcess ?  i'm told that that does happen for tribes.
* Hobbsee cant actually see what it involves, hence it's black magic :)
<fabbione> oh that page needs to be updated
<fabbione> Hobbsee: you want to talk to heno :)))
* Hobbsee pokes heno, then
<fabbione> Hobbsee: please update the wiki too
<Hobbsee> fabbione: will do
<fabbione> thanks
* fabbione -> back packing
* cjwatson wonders if we should put dmsetup in standard
<cjwatson> back in standard, rather
<pitti> cjwatson: hm, but when lvm2 doesn't actually work without dmsetup, wouldn't a dependency be more corret?
<pitti> correct
<Keybuk> pitti: it "works", you just don't get uuid symlinks
<cjwatson> ah, I hadn't noticed that it was only a suggests there
<Keybuk> we need conditional deps
<Keybuk> udev depends dmsetup if lvm2 is installed
<Keybuk> <g>
<cjwatson> Keybuk: I think for Ubuntu, that's "doesn't work"
<Keybuk> <g>
<cjwatson> given that we configure fstab for UUIDs by default now
<Keybuk> yes
<cjwatson> the alternative is to make the installer apt-install dmsetup as well as lvm2
<cjwatson> but a dependency feels better
<Keybuk> agree
<elkbuntu> mvo, i never tested tribe2
<mvo> elkbuntu: ok, it may well be that we have to blacklist your driver. if you could gvie me the xorg.0.log file from feisty, that would be good too
<mvo> ogra: IIRC some of your machines have S3 UniChrome cards, no?
<mvo> ogra: do those work well with compiz?
<elkbuntu> mvo, i'm downloading tribe2 to check, but that will be an hour and a bit off
<elkbuntu> mvo, i'm booted into the 18.1 desktop cd now if you want to make suggestions to get a terminal, other than ctrl+alt+f#
<ogra> mvo, they are via unichrome ...
<ogra> and no, since we dont have the openchrome driver packaged at all i cant use any shiny stuff on them
<ogra> (unichrome doesnt work on these)
<elkbuntu> mvo, 01:00.0 VGA compatible controller: VIA Technologies, Inc. VT8378 [S3 UniChrome]  Integrated Video (rev 01) is the lscpci entry
<elkbuntu> ogra, is that the same as your via?
<ogra> no idea, i can tell if i booted again :)
<elkbuntu> ogra, how nice of you to offer ;)
<ogra> gime a minute to burn the modified casper iso i have here :)
<elkbuntu> sure
<elkbuntu> btw, this is why 'options' needs a 'kill gdm' option :
<ogra> elkbuntu, i'll add one after tribe
<ogra> its trivial to supress gdm/X starting
<elkbuntu> ogra, i agree, and it's not the first time i've wanted it
<ogra> yeah
<ogra> lets see if my had knitted CD runs :)
<mvo> Hobbsee: is the bug that elkbuntu experiences a blocker for tribe-3?
<ogra> *hand
<Hobbsee> mvo: this is the fs breakage?
<mvo> Hobbsee: the bug #126971
<ubotu> Launchpad bug 126971 in compiz "[gutsy]  compiz crashes x or gdm repeatedly" [Undecided,New]  https://launchpad.net/bugs/126971
<elkbuntu> Hobbsee, the 'compiz is breaking things... AGAIN' breakage
* Hobbsee kills compiz.
* elkbuntu dreams
<Hobbsee> mvo: do you have a fix?
<ogra> killing wont fix ...
* lamont tries to remember who thought compiz was a good idea, remembers, closes mouth.
<elkbuntu> ogra, but it will be so satisfying :D
* elkbuntu pets lamont
<ogra> elkbuntu, like beer ... only the evening you drink it ....
<Hobbsee> mvo: if we delay the tribe for this and the fs breakage, we may as well cancel it - because neither of these seem to have fast fixes, and we'd probably want to test out this stuff fairly extensively, just due to the number of people this affects.
<Hobbsee> mvo: still, i'd like to see these bits fixed asap, and our next tribe frozen earlier, etc, to get more testing of it.
<Hobbsee> because we cant rely on the metapackages staying installable, for people to test off working dailies.
<mvo> Hobbsee: as a quick fix we could blacklist the s3 driver in use (I would most likely have to ask dholbach for this as the bandwidth here is really very bad)
<dholbach> mvo: I don't know what to do or change
<Hobbsee> mvo: any idea hwo many people this will effect?
<elkbuntu> dholbach, i'm sure he'll hold your hand
<elkbuntu> Hobbsee, 2/6 machines in this house at least
<dholbach> hi elkbuntu, hi Hobbsee
<mvo> dholbach: if we do blacklist it, I'm happy to assist you, I just can't upload (I can not even  checkout/commit properly here)
<Hobbsee> hi dholbach
<elkbuntu> dholbach, hi!
* elkbuntu hugs dholbach
<pitti> mvo: let's do that next Monday when you are back home again
<pitti> that will be much more efficient
<mvo> pitti: ok, fine with me
* Hobbsee thinks on that
<mvo> Hobbsee: I do not think those cards are very commoon
<Hobbsee> mvo: any idea how many other cards this effects?
<Hobbsee> mvo: yeah, that's what i was thinking - seeing as i'd not actually heard of them before :P
<elkbuntu> Hobbsee, i slightly suspect my ati too
<mvo> Hobbsee: *nod*
<elkbuntu> Hobbsee, and that's the radeon xpress 200m. it didnt behave the same, but it got as far as the brown screen then froze
<ogra> Hobbsee, my via doesnt work as well ... but i'm digging on the filesystem corruption atm
<Hobbsee> elkbuntu: that's the fs breakage, it seems, which should be unrelated.
<Hobbsee> or at least, is a different bug
<ogra> the fs stuff affects more machines (3 of 4) fo rme than the compz thing
<mvo> elkbuntu: *ick*
<elkbuntu> mvo, yeah. i buy cheap machines because well, i dont exactly have a job to pay for them with
* mvo hugs elkbuntu
* elkbuntu hugs mvo back
<stgraber> I have a laptop with a xpress 200m around here, I can test the desktop on it if wanted
<elkbuntu> stgraber, please
<stgraber> (I've just started downloading ubuntu desktop i386, will be done in 10 minutes)
<elkbuntu> i dont feel like having both my decent machines rewted
<ogra> hmm, intresting, after the intramfs change i get a lot of scsi errors while mounting the CD
<ogra> elkbuntu, you dont happen to boot from usb CD
<ogra> ?
* mvo needs to find power and better network somewhere
<elkbuntu> ogra, nope. iirc it's on an ata cable
<ogra> ok
* elkbuntu pulls the side off the machien to check
<elkbuntu> cant remembe if it's ata or ide for the cd
<StevenK> ATA covers a multitude of sins
<ogra> well,i was hoping it was a usbcd issue ....
<elkbuntu> cd is IDE
<ogra> would rather limit it to certain HW
<ogra> yeah
<elkbuntu> ogra, certain hardware that's not graphics related, you mean
<elkbuntu> StevenK, yes. it does
<keescook> Keybuk: if you have a second, can you look at #126812 ?  I didn't want to upload that patch until you'd approved it.
<elkbuntu> im fortunate my hdds are ultra ata, not sata
<ogra> elkbuntu, the fs corruption is surely not graphics related
<elkbuntu> ogra, this is true
<lemsx1> i just upgraded to Gutsy and i had to pass parameters to the kernel in order for the system to boot properly. is this already known? "apm=off acpi=off noapic", that's what i used
<elkbuntu> lemsx1, in what way did it not boot?
<lemsx1> everything else is fine... gksu seems NOT to be calling g_thread_init() before calling glib functions... making it crash
<lemsx1> elkbuntu: it simply hung during boot. i switched to single user mode and i saw that the last message was something to do with ACPI
<lemsx1> elkbuntu: and since this is an SMP system (core2 duo CPU), i used those switches to make it work
<elkbuntu> ok then, seems unrelated to my issue
* Hobbsee doesnt want to delay the tribe over that.
* siretart hugs cprov for making PPAs add an X-Katie: header to the archive emails :)
<cprov> siretart: X-Katie header is niiiiiice ! (quoting Borat)
<siretart> :)
<tkamppeter> Anyone there from the printing front?
<stgraber> elkbuntu: I have to move from home, anyway I'll have one of those laptops here as well (my grand-mother's one :)) so you'll have the result in one hour or so
<elkbuntu> ogra, do your hand-knitted tests confirm the FS issue?
<elkbuntu> stgraber, cool
<Hobbsee> ogra: could you check the torrent links for edubuntu please?
<tkamppeter> pitti, ping
<pitti> tkamppeter: hi
<tkamppeter> pitti, I have some problem. Probably you remember that we wanted to get rid of the gnome-cups-manager: https://blueprints.launchpad.net/ubuntu/+spec/printerdrake
<pitti> yep, sure
<tkamppeter> I have found a volunteer via the gnome-love mailing list. Today he told that he does not relly find the time to work on a new GUI for printerdrake.
<ogra> elkbuntu, it dies, no idea why yet
<ogra> Hobbsee, will do
<Hobbsee> ogra: ah, testing them here now, atm, have asked pitti to ask Spads to kick
<ogra> Hobbsee, ok ...
<ogra> i'm pretty deep in the fs thing atm, appreciated
<Hobbsee> ogra: good luck :)
<ogra> Hobbsee, i have a rough idea, but without proving it its worth nothing :/
<Hobbsee> ahh
<ogra> but somehow my handmade initramfs doesnt like me
<Mithrandir> pitti: how much would you laugh at me if I asked for xulrunner in main?
<tkamppeter> pitti, ant idea how the replacement of gnome-cups-manger by something else could be done?
* ogra hugs Mithrandir extatically
<pitti> Mithrandir: MUHAHAHAHAHA *ROTFLWMP*
<pitti> Mithrandir: seriously, I would consider it if firefox would use it
<pitti> Mithrandir: i. e. if future updates move from ffox to xulrunner, that should be fine
<Mithrandir> pitti: ok.
<Mithrandir> asac: how much work is it to get ff to use xulrunner?
<pitti> but I guess that would mean that upstream would need to move to it and such
* Mithrandir nods.
<Mithrandir> ugh
<pitti> Mithrandir: I guess the mobile browser needs it?
<seb128> the upstream plan was to make firefox 3 use xulrunner but somebody told me this week that they decided to do that later
<seb128> so it's not any time soon
<seb128> and xulrunner has no security support nor proper tarballs
<Mithrandir> pitti: no, the mobile UI needs it.
<Mithrandir> UIs in flash! woo!  inhale!
* elkbuntu twitches
<ogra> Mithrandir, rather in gnash i hope :)
<pitti> Mithrandir: hm, and I take it it's not pure flash, either? (so that gnash isn't sufficient)
<ion_> Xulrunner and Flash dont sound like something id put into a mobile platform. ;-)
<ion_> Neither does Java, though. :-P
<Mithrandir> ion_: why not?
<Mithrandir> ogra: eventually, I hope so.
<ogra> ion_, yeah, whats wrong with that ?
<ogra> vector based stuff is a lot less ressource hungry
<ion_> I was just joking about the stereotype of Java being bloated and slow by definition.
<Mithrandir> ion_: the pepperpads use java UIs
* ogra takes a break
<pitti> cjwatson: I guess you don't mind if I upload lvm2 with that dmsetup dependency?
<seb128> pitti: does installing dmsetup still create issues on some configurations?
* elkbuntu still hasnt found a way to a terminal on her loopy VIA
<pitti> seb128: I can't say really, just that I have it installed by default
<pitti> seb128: but not in an expert install
<seb128> k
<cjwatson> pitti: oh, not at all, sorry, assumed you were
<cjwatson> I'd just been looking at it in the installer
<pitti> seb128: it's just the dmsetup binary and some udev rules which create by-uuid symlinks and such; do you have some details about that breakage?
<elkbuntu> it is really annoying me that there is not any surefire key combo to kill gdm and keep it killed
<pitti> cjwatson: done
<pitti> seb128: do you want me to upload my libgnome-on-steroids with gnome_sound_play() aplay love?
<pitti> seb128: http://people.ubuntu.com/~pitti/tmp/11_aplay_fallback.patch
<pitti> seb128: I'm not sure, it doesn't seem to make sound events like login sound or menu plopps work; but OTOH they haven't worked *with* esound so far either
<pitti> seb128: not sure whether disabling startup sound is a bug or a deliberate feature?
<seb128> pitti: sure
<pitti> seb128: well, since sound events don't seem to work anyway ATM (and nobody particuarly complained :) ), I guess unseeding esound is ok
<seb128> pitti: I had to remove something from my laptop because it was spinning on boot during the distro sprint but looks like it's not dmsetup
<seb128> might have been dmraid
<mvo> seb128: was it evms?
<soren> pitti: /win 22
<seb128> mvo: might be, indeed
<mvo> seb128: synaptic keeps logs ;) apt will be soon
<soren> gah..
<pitti> soren: ?
<soren> pitti: nm
<pitti> $ bzr commit -m 'do not install esound by default any more'
* pitti celebrates
<pitti> xubuntu.gutsy/ship: * esound            #needed for ltsp
<pitti> ogra: ^ I guess that's obsolete?
<pitti> ogra: I'll replace it with pulseaudio-esound-compat
<Keybuk> keescook: let me run it by Kay furst
<Keybuk> keescook: he's pulling faces
<Keybuk> let me talk to him and find out why
<Keybuk> (in a talk right now, just handed him my laptop silently)
<keescook> Keybuk: heh, cool.  Yeah, it's a bit of a hack, but it's mostly to avoid the sad state of sysfs in the v4l drivers.  :(
<Keybuk> keescook: video implies X
<Keybuk> so they should use HAL damnit
<keescook> the ultimate goal is to find _some_ way to build a static unique path for a v4l device, since driver init order isn't always the same.
<Keybuk> what needs that?
<keescook> actually video doesn't imply X.  for example, a mythtv backend without a head doing video cap.
<Keybuk> you could still use HAL for that :p
<keescook> mythtv is the biggest user of this.  it ... gets upset ... when video0 and video1 swap places.  ;)
<keescook> I'm all ears for a HAL solution.  I'm just more familiar with udev, and it seemed like other things already had special cases (tape drives)
<keescook> this basically builds  /dev/v4l/by-path/pci-NN...NN-$V4L_DRIVER_NAME
<Keybuk> *nods*
<superm1> if a package is sitting in the archive source NEW queue, will an upload of an new version just override that one and let it take it's place?
<keescook> the other ugliness is that v4l doesn't have any serial number stuff I can use, so the best thing we have is the physical PCI path.
<Riddell> cjwatson: https://bugs.launchpad.net/ubuntu/+source/apt-setup/+bug/118002 doesn't seem to be fixed
<ubotu> Launchpad bug 118002 in apt-setup "add canonical's commercial archive to default sources.list" [Wishlist,Fix committed] 
<pitti> asac: hm, the current ffox 2.0.0.5 upload, is that already with the profile fix?
<elkbuntu> i think we might have a way in. pending experiment
<keescook> Keybuk: any thoughts, or did GUADEC get swapped back in?  :)
<pitti> asac: ah, seems not, seems I forgot to reject it
<asac> yes ... i merged in your changes ... take a look at changelog
<asac> he?
<cjwatson> Riddell: "Fix committed"
<Riddell> ah
<stgraber> elkbuntu: I don't have any graphic issue with an ATI Xpress 200m here :(
<stgraber> elkbuntu: except a fail from HAL, but gnome session opens and works
<elkbuntu> stgraber, what flavour laptop?
<Keybuk> keescook: will chat to Kay after this talk
<keescook> Keybuk: okay, thanks
<tkamppeter> I have a question to Python experts.
<tkamppeter> If I compile .py files to .pyc files, are the .pyc files platform-specific?
<Mithrandir> yes
<tkamppeter> Mithrandir, are these files machine-language files like the executables compiled from C source code?
<Mithrandir> no
<Mithrandir> they are trivially disassembled
<Mithrandir> AIUI
<tkamppeter> I am asking because HPLIP compiles .py files to pyc and therefore the Debian maintainer has moved the .py from /usr/share to /usr/lib with a big patch which breaks on every update.
<elkbuntu> ogra, still around?
<superm1> Mithrandir, I asked a question above regarding what will happen if a newer version of a package sitting in source NEW was uploaded.  Do you know if it will just nuke the old one?
<Hobbsee> superm1: i believe it does
<superm1> thanks Hobbsee
<cjwatson> Mithrandir: I didn't think they were platform-specific
<Mithrandir> superm1: both will be accepted (or rejected)
<Nafallo> Mithrandir: where is Stavanger located? :-)
<Mithrandir> cjwatson: I think they are.  BICBW.
<Mithrandir> Nafallo: south west coast.
<Nafallo> Mithrandir: sounds good to travel from if needed be then. thanks.
<Nafallo> Mithrandir: if I would have to pass Oslo on my way there you could expect a visit of course ;-)
<cjwatson> Mithrandir: http://lists.debian.org/debian-python/2003/11/msg00037.html
<cjwatson> tkamppeter: ^--
<Mithrandir> ok
* ..[topic/#ubuntu-devel:Hobbsee] : Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty, #ubuntu+1 for gutsy support | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | TRIBE 3 RELEASED!!!
* ..[topic/#ubuntu-devel:Hobbsee] : Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty, #ubuntu+1 for gutsy support | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | TRIBE 3 RELEASED! \o/
<Mithrandir> Hobbsee: you win!
<Hobbsee> Mithrandir: :D
* pitti yays Hobbsee 
<Nafallo> woha! and my laptop is delayed. stupid Dell! ;-)
* Hobbsee yay's pitti too :)
<Nafallo> congrats! :-D
<Hobbsee> :)
<tkamppeter> Thanks, cjwatson, another step to get a more maintainable HPLIP.
<Mithrandir> I wonder why flashplugin-nonfree is Arch: any and not all
<ScottK> Isn't it just a stub to grab the package from elsewhere?
<Mithrandir> it is
<stgraber> elkbuntu: It's a Toshiba A100 laptop
<elkbuntu> stgraber, this be a compaq presario v2000 series
<geser> Mithrandir: isn't it only i386 and amd64?
<stgraber> I've marked tribe-3 as released on the tracker and added empty builds for tribe-3 community testing
<Hobbsee> stgraber: ah, thankyou
<Toadstool> yay Hobbsee! well done everybody
<Hobbsee> Toadstool: :)
<Toadstool> good morning
<Hobbsee> now we just get to see how bad the compiz fallout is, and how many people are actually affected by that livefs breakage
<Hobbsee> hi jono_
<Hobbsee> er, fs breakage.
<Toadstool> you scared him away :)
<Hobbsee> so it seems
<superm1> Hobbsee, what was the livefs breakage?
<Hobbsee> superm1: the stuff for xubuntu, or the fs breakage causing the gdm hang?
<superm1> causing the gdm hang
<Hobbsee>  * The desktop CD hangs on a lot of systems, especially slower ones
<Hobbsee>    with little RAM. Sometimes it is just slow, sometimes it will hang
<Hobbsee>    eternally. If you experience this and waiting a bit longer does
<Hobbsee>    not help, try to restart the computer and the live CD. If that
<Hobbsee>    still does not help, please use the alternate CD.
<Hobbsee>    (https://launchpad.net/bugs/126964)
<ubotu> Launchpad bug 126964 in linux-source-2.6.22 "gutsy livefs causes random hangs or modprobe crashes" [Critical,New] 
<Hobbsee> superm1: more detail in the backscroll
<superm1> Hobbsee, ah good.  i've seen some random oddities like this myself in a VM.  I
<superm1> 'll subscribe to this bug and watch for it
<Hobbsee> cool
<elkbuntu> where did mvo go to?
<sladen> elkbuntu: I saw him in person, but that might hav ebeen last night
* Hobbsee ate mvo
<sladen> elkbuntu: actually, saw him during the fire alarm 6 hours ago
* Hobbsee was hungry
<elkbuntu> sladen, tell him i have the logs he desires so much
<elkbuntu> sladen, ha!
<Nafallo> why did I read prison instead of person?
<Hobbsee> morning calc
<dholbach> congratulations pitti and Hobbsee :)
<Hobbsee> thanks dholbach :)
<calc> Hobbsee: good morning
* Hobbsee --> bed.  night all!
<Keybuk> keescook: did you look at the stuff debian have like this?
<Hobbsee> Keybuk: i'm not sure if colin passed it on, but there are various debian-type people who think that an rss feed on patches.u.c/by-release/ would be useful.
<jwendell> is GNOME 2.19.4 shipped with tribe 3?
<Hobbsee> jwendell: 2.19.5, i think.  check the release notes
<pygi> dholbach, around?
<dholbach> yes
<dholbach> I know you replied to that bug
<pygi> dholbach, nah, it's not about that :)
<dholbach> but I'm working on other things atm :)
<dholbach> ahhh ok :)
<pygi> dholbach, ergh, no need to reply since I need to make proper package first ... I made a major mistake by not looking :)
* Hobbsee throws pygi at seb128 in greeting
<dholbach> pygi: ok
<pygi> dholbach, soon we'll be able to sync libtapioca-glib from debian :D
<dholbach> take your time
<dholbach> ok cool
<pygi> and fama as well ofcourse :p
<dholbach> nice
<seb128> hey Hobbsee, congrats on tribe 3 ;)
<pygi> well, wont take anymore of your time
* pygi eats Hobbsee in return
<Hobbsee> seb128: thankyou :)
<Hobbsee> seb128: thank pitti too, when he comes back
<Hobbsee> mvo!!!
<Hobbsee> elkbuntu: ^
<elkbuntu> mvo!
<mvo> hey Hobbsee!
<mvo> found network again :)
<elkbuntu> guess what!
<Hobbsee> mvo: woo!
<elkbuntu> mvo, would you believe i am ssh'd into the livecd?
<mvo> elkbuntu: cool!
<mvo> elkbuntu: how did you managed?
<elkbuntu> mvo: single user. passwd it a password. apt-get install openssh-server. play ball.
<elkbuntu> so simple it's ridiculous
<elkbuntu> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/126971 has the xorg log appended now
<ubotu> Launchpad bug 126971 in compiz "[gutsy]  compiz crashes x or gdm repeatedly" [Undecided,New] 
<mvo> elkbuntu: clever!
<elkbuntu> mvo, i wish i could claim credit
<elkbuntu> and i am going for nicotine. think of anything else you need me to scout off it when i get back, because i am soon to cuddle up to my pillow
<Keybuk> Hobbsee: mmm, RSS
<Keybuk> (pronounced in the Cambridge fasion)
<Hobbsee> Keybuk: :)
<Riddell> infinity: could you give back kde4pim kde4artwork and kde4addons?
<Keybuk> but it's not a blog
<Hobbsee> Keybuk: this is true.
<Keybuk> if they want them when they arrive, they can subscribe to ubuntu-patches
<Keybuk> which is the mailing list they're sent to
<Hobbsee> Keybuk: the suggestion was for per-package
<Keybuk> they get those
<Hobbsee> so the maintainer could subscribe to the list of patches
<Keybuk> they can
<infinity> Riddell: If you ask nicely.
<Keybuk> that's what the Debian PTS does
<Hobbsee> apparently the QA thing they hadnt noticed, or something
<Riddell> infinity: pretty please
<Hobbsee> Keybuk: sounds like bad communication, rather than lack of infrastructure, then.  thanks
<Keybuk> those files are the side-effect of the PTS system
<Keybuk> rather than an end-product
<Hobbsee> right
<Keybuk> I put them on http because normally we only get them through the ubuntu-patches mailing list
<Keybuk> and I figured URLs were more useful
<infinity> Riddell: Done.  (Well, doing)
<Hobbsee> fair enough
<Keybuk> if they want a feed of anything in particular, I can add a subscription to the mailer for them
<Hobbsee> right
<Hobbsee> will pass the info back at some point, ,then
<ynezz> is there something like build.opensuse.org for ubuntu?
<Mithrandir> ynezz: yes, launchpad.
<ynezz> wow, it's nice
* calc thinks his network access is starting to work properly again :)
<Nafallo> doko: I have a friend asking me where he can find a JIT for the sun-java-5 packages.
<dholbach> pitti: I filed bug 127055 - I hope that will make it easier
<ubotu> Launchpad bug 127055 in malone "Filtering on bug assignee A does not work in bug list of bugs related to team B" [Undecided,New]  https://launchpad.net/bugs/127055
<pitti> dholbach: great, thanks
<dholbach> super :)
<pitti> ogra: can you please add your findings to bug 126964? they were quite invaluable
<ubotu> Launchpad bug 126964 in linux-source-2.6.22 "gutsy livefs causes random hangs or modprobe crashes" [Critical,New]  https://launchpad.net/bugs/126964
<pkl_> pitti/ogra: a quick summary would be useful, as I'm looking into the bug now...  Was any definitive cause identified?
<pitti> pkl_: last thing I knew from ogra was checking when the unionfs got corrupted files and when not, possibly related to a losetup change in casper; but I don't know details
<dholbach> Meyvn: fire away - what questions do you have?
<pkl_> pitti: ok, I'm having difficulty in reproducing the file corruption, but I have reproduced the system hangs.
<mathiaz> keescook: upstream svn repository from apparmor has been imported into bzr
<Meyvn> i was wondering how much programming experience you guys generally have before making the plunge
<dholbach> Meyvn: there are lots of different ways in which to get involved in ubuntu
<keescook> mathiaz: nice!
<mathiaz> keescook: so now I'm in the process of removing all the patches from debian/
<dholbach> Meyvn: so it's not only packaging/hacking/coding, but other things too: http://www.ubuntu.com/community/participate lists other ways too
<Nafallo> Meyvn: none at all for me when I got to be a MOTU.
<Nafallo> I think...
<Meyvn> dholbach: i guess i have too little programming experience to participate
<dholbach> Meyvn: if you're interested in ubuntu development as in packaging, you'd might be interested in http://wiki.ubuntu.com/MOTU and http://wiki.ubuntu.com/MOTU/Recipes
<mathiaz> keescook: I've already pushed a new version - https://code.launchpad.net/~mathiaz/apparmor/ubuntu-mathiaz
<keescook> mathiaz: heh.  be sure to branch from the right place -- we don't want to newer kernel modules :)
<keescook> do I need to rebase or something?
<mathiaz> keescook: I've branched from 510.
<keescook> perfect
<Meyvn> although i am interested in OS development
<mathiaz> keescook: after that I cp debian/ and ci.
<dholbach> Meyvn: also join up on the ubuntu-motu-mentors@ mailing list - so you're in touch with people who mentor and people who just start contributing
<mathiaz> keescook: and than pushed to a new branch.
<Meyvn> dholbach: thanks, I'll do that
<dholbach> Meyvn: rock and roll
<mathiaz> keescook: does this sound correct ?
<keescook> mathiaz: I think so; this is new to me too.  :)
<dholbach> Meyvn: I'm about to call it a day for today, let me know how it goes, drop me a mail if anything's unclear or you need help with anything
<cjwatson> Meyvn: http://wiki.ubuntu.com/ContributeToUbuntu, if nobody mentioned it already.
<dholbach> Meyvn: dholbach at ubuntu dot com
<dholbach> see you tomorrow
<Meyvn> dholbach: thanks a lot and goodbye!
<dholbach> seeyou
<pitti> pkl_: ah, good; can you make any sense of it?
<Meyvn> sadly my C# knowledge isn't going to help when developping for Linux, heh
<mathiaz> keescook: so next is to get rid of all the patches in debian/patches/ and apply them inline ?
<pitti> pkl_: I'm a noob in kernel debugging, I could just randomly peck at sysrq+t and such
<keescook> mathiaz: yes, that's my understanding.
<keescook> then it'll be much easier for you to do development work.  :)
<mathiaz> keescook: ok. I'll work on that and see if I can make this thing done.
<mathiaz> keescook: and soon we should have apparmor into main too.
<keescook> \o/
<pkl_> pitti: I know where and what mutex processes are hanging on in Squashfs.  What I don't know yet is why the mutex wasn't release.  I'm working on it now...
<pkl_> pitti: The other piece of the puzzle is the system is running out of memory, and the SLUB is failing, any sloppy code whic doesn't check for this will fail nastily in random ways.
<pkl_> pitti: The OOM killer is also being invoked, this may explain the non release of the mutex.
<pkl_> pitti: s/SLUB/SLUB allocator/g
<cjwatson> Meyvn: mono does exist, but it's true that the majority of packages are in a small number of other languages (C, Python, Perl, C++, shell being probably the most important ones to have a basic grip on depending on what you're doing)
<mathiaz> keescook: hum. The version from the bzr tree is different from the orig.tar.gz
<Meyvn> cjwatson: well my C++ isn't that bad :)
<stgraber> Meyvn: if you want to work on the core packages (library, kernel, daemon, ...) it'll be mainly C, C++ and a bit of scripting (bash), then for frontends it'll be C, C++, python and some others like perl and C#
<cjwatson> mr_pouit: did you notice that you put a copy of GPLv3 in xubuntu-meta, but debian/copyright says GPLv2?
<stgraber> I have forgotten some, I'm sure of that ... :)
<cjwatson> (I'm going to put GPLv2 in the other *-meta source packages)
<pitti> IntuitiveNipple, pkl_: glad to introduce you; IntuitiveNipple was debugging that live CD kernel crash
<IntuitiveNipple> Call me TJ - thats my name :)
<IntuitiveNipple> saves a lot of typing, too
<pkl_> TJ: did you discover anything interesting?
<IntuitiveNipple> Are there any signature errors from the logs that can be ignored? I'm wondering about the clocksource failure in my set of logs - kernel logging timecodes suddenly change dramatically at the same time a TSC error is logged
<IntuitiveNipple> pkl_: I'm not sure yet, there's quite a few faults in the various logs (I've attached the log bundle to the launchpad bug)
<pkl_> TJ: you're getting kernel oopses?  They'll be interesting to have a look at.
<IntuitiveNipple> I saw plenty of segment faults but so far no Oops reported that I've noticed anyhow... I'm just doing yet another boot on another notebook to see how far it goes... its started X ok this time, and is plodding on... just when I needed it to fail :)
<soren> pitti: Do you have a minute to binary NEW the three ebox modules from earlier today?
<pitti> soren: yeah, can do
<soren> pitti: \o/
<soren> pitti: I thought when the "resulting binaries" portlet listed them, they had been accepted, but it seems not to be the case.
<pitti> no, still in new
<pitti> there they go
<soren> pitti: Yay. Thanks!
<ScottK> pitti: Since soren started it ;-) would you be up for releasing clamav 0.88.7-1ubuntu1~dapper (it's a source backport).
<IntuitiveNipple> Phillip, can we ignore things like "containing coreutils, pre-dependency problem: coreutils pre-depends on libacl1" and "coreutils is unpacked, but has never been configured" in bootstrap.log as symptoms rather than causes or is it something to investigate?
<pitti> ScottK: tomorrow preferably, on my archive day; any idea where I get that version from?
<ScottK> pitti: Tomorrow not problem.  StevenK uploaded it as a source backport earlier this week.
<ScottK> It should be sitting there waiting to be accepted.
<pitti> aah, good
<IntuitiveNipple> So weird - its just fully booted tribe-3 now I want it to fail!
<pitti> IntuitiveNipple: happened a lot to me too :/
<IntuitiveNipple> This is my first time it worked... typical!
<IntuitiveNipple> Well I guess that rules out worrying about the pre-dependency warnings!
<IntuitiveNipple> still got the same suspend-then-resumes-immediately issue too :)
<pitti> IntuitiveNipple: ^ that sounds like too little swap
<IntuitiveNipple> suspend, not hibernate :)
<IntuitiveNipple> I *think* it is to do with a USB wakeup event when some device powers-off - I built a USb debug kernel earlier but haven't had chance to test it so far
<IntuitiveNipple> Interesting... don't know if this is significant, but it looks like the successful boots don't have the TSC failed issue I referred to earlier (got another seemingly good boot going now) and the TSC issue is showing up way before the squashfs is touched. might be a lead.
<cjwatson> IntuitiveNipple: those are all expected consequences of bootstrapping
<cjwatson> (the coreutils stuff)
<cjwatson> the world isn't quite sane when debootstrap is in the process of putting it together, and it has to force some things
<IntuitiveNipple> cjwatson: thanks, I thought so but best to ask, trying to elliminate as many stray bits as possible
<IntuitiveNipple> ha! caught it failing again and have access to the logs
<ajmitch> main is unfrozen again, I presume?
<IntuitiveNipple> OK, whilst I have command-line control of a faulting system, is there anything I can look at/for to help us on this tribe-3 random corruption issue?
<cjwatson> ajmitch: yeah
<cjwatson> ajmitch: (https://launchpad.net/ubuntu/gutsy => if that says "Active Development" then there's no freeze in place)
<ajmitch> right, that's what I'd hoped :)
<ajmitch> your remark about coreutils reminded me that I needed to upload a simple FTBFS fix for it
<cjwatson> and this also reminds me that I wanted to sync a new germinate
<cjwatson> *blat*
#ubuntu-devel 2007-07-20
<mathiaz> keescook: I've finished converting apparmor packages to use bzr.
<mathiaz> keescook: It was a bit more complicated as the content of the orig.tar.gz was not the same as the rev I branch from (510)
<mathiaz> keescook: I've published a new branch: http://bazaar.launchpad.net/~mathiaz/apparmor/ubuntu-mathiaz
<Chipzz> not that it matters probably, but I'm in favour of using selinux and against apparmor
<Chipzz> selinux looks like the most mature and most complete solution
<Chipzz> that and debian will also probably go with selinux
<mathiaz> Chipzz: when debian will have integrated selinux, ubuntu will also have it. so we'll have both apparmor and selinux.
<StevenK> Blink. Now NBS is empty.
<pkl_> IntuitiveNipple, pitti, ogra: please test the liveCD iso in http://people.ubuntu.com/~pkl.  That's got a fix for a Squashfs race condition that sneaked into the code in April.  For some reason the Squashfs code in the Gutsy kernel wasn't updated when I found it in May.  With that fix the liveCD doesn't hang in my tests. I've been unable to reproduce the filesystem corruption, and so your mileage may vary.
<IntuitiveNipple> pkl_: I'll grab it now
<pkl_> TJ: (easier to type :) ), thanks
<IntuitiveNipple> the nick is only to make people smile :p
<IntuitiveNipple> I hope you've fixed it - I was trying to focus on a suspend-then-resumes-immediately issue :)
<Nafallo> made me smile anyway :-)
<bluefoxicy> nipples wtf
* IntuitiveNipple wibbles
<bluefoxicy> the only intuitive interface
<IntuitiveNipple> all the rest are learned
<mjg59> bluefoxicy: I really recommend you don't try suggesting this to anyone who's ever breast fed
<keescook> Chipzz: I'm hoping to get selinux fully integrated too.  if you've got some details or patches to help it happen, I would be very interested.
<bluefoxicy> mjg59:  I would hope I'd stop breast feeding by the time I'm old enough to remember.
<pkl_> TJ: I'm not sure it will fix all the issues.  I suspect some of the issues are caused by out of memory in the kernel allocator.  A lot of kernel code fails in nasty ways when that happens (if you need some kernel memory to do something, and you can't get it, you've no alternative but to crap out in as graceful way as possible).
<mjg59> bluefoxicy: It's really, really, really not intuitive
<IntuitiveNipple> pkl_: I'll test it, report, then get to bed... its turning into another all-nighter!
<bluefoxicy> mjg59:  Leo gave me a pic of you in a straw hat, I think.
<pkl_> TJ: yeah, it's 1am here :)
<IntuitiveNipple> snap :)
<IntuitiveNipple> Now if you could only solve this suspend/resume issue I'd be happy!
<pkl_> TJ: UK?
<IntuitiveNipple> Yes, deepest rural Notts on a farm
<pkl_> TJ: sounds good, I'm in rural Wales :)
<IntuitiveNipple> Ahh... used to be a big haunt of mine :)
<pkl_> TJ: OK, what parts?  I live in Chepstow, which is in Monmouthshire, before you get to the built up areas of Cardiff/Swansea etc.  Ceredigion would be a nice area to live, but Chepstow is handy for Cardiff and Bristol (I used to work in Bristol).
<pkl_> TJ: suspend/resume are probably the biggest cause of problems we have with the kernel at the moment.  Two different competing systems (one winner), both broken.  Looks like there's some work going on a third alternative (suspend3), but that won't be ready for a long time.
<IntuitiveNipple> pkl_: I used head out to Llanidloes/Clewedog and also the Lynn penninsula, visiting friends
<IntuitiveNipple> pkl_: Yes, I've been working in it quite a bit recently... I've got a weird one where it suspends/resumes *perfectly* but the resume happens right at the point it should do hw_sleep() and there are no clues anywhere as to what is causing it
<ion_> pkl: And when suspend3 is deemed broken, the situation can be corrected simply by introducing suspend4. ;-)
<IntuitiveNipple> I just installed a USB debug kernel hoping to see some USB wakeup events, but it isn't that
<pkl_> Ah, north wales (Gogledd Cymru).  Very nice part of the world.   I did seriously think about moving to Bangor once.
<IntuitiveNipple> I once fitted a new rear independent suspension unit to a Rover 3500 V8 one saturday afternoon there, after driving 140 miles from Llanidloes to get the only spare part in Wales!
<IntuitiveNipple> That drive was like being at sea... talk about feeling sea-sick driving with broken suspension!
<IntuitiveNipple> pkl_: I'm emigrating in a few weeks, to somewhere rather sunnier :)
<pkl_> TJ: heh, 140 miles from Llanidloes, that's a long drive!
<pkl_> TJ: where are you going?
<IntuitiveNipple> Andulcia, Spain
<IntuitiveNipple> oops, my typing... Andalucia !
<pkl_> TJ: good luck!
<IntuitiveNipple> this download is about at 50%
<pkl_> TJ: yeah, it was going to take me over 5 hours to copy the file to the Ubuntu webserver.  Luckily I could use rsync over ssh to only transfer the changes.  With iso's ADSL is slow...
<IntuitiveNipple> 466MB done
<IntuitiveNipple> Burning Test-CD now
<pkl_> OK
<IntuitiveNipple> time for a fresh cuppa whilst this burns
<ajmitch> hello Burgundavia
<Burgundavia> hey ajmitch
<IntuitiveNipple> Phillip, first boot seems to have gone OK although I saw the same bunch of udev errors that were present with the faulty tribe-3 (presuming they weren't caused by this, then it seems OK)
<pkl_> TJ: sounds good.  Thanks for doing the test.
<IntuitiveNipple> I'll do a couple more boots just to be confident
<pkl_> TJ: I think it is time for bed...  See you tomorrow...
<IntuitiveNipple> lol yeah... my dog has just decided to have a good run about too
<pkl_> TJ: OK, let me know what happens - thanks
<IntuitiveNipple> will do
<IntuitiveNipple> I'll comment on the bug
<Nafallo> damn you guys are confusing :-)
<fabbione> morning
<ScottK> evening
<TheMuso_> Congrats all on the tribe release.
<Jedusor> hihihihi
<Burgundavia> ello?
<Hobbsee> hi all
* Hobbsee hugs Burgundavia 
* Burgundavia hugs Hobbsee
<Jedusor> hi Hobbsee
<Jedusor> hi Burgundavia
<Hobbsee> hi Jedusor
* netjoined: irc.freenode.net -> kubrick.freenode.net
<Hobbsee> morning siretart
<Hobbsee> pkl_: you rock.
<Hobbsee> anyone know if there's a trick to rsyncing off p.u.c?
<Hobbsee> pitti!
<Hobbsee> pitti:  know if there's a trick to rsyncing off p.u.c?
<pitti> Good morning!
<pitti> Hobbsee: for pkl_'s CD?
<Hobbsee> pitti: yes
<pitti> Hobbsee: hmm, only with ssh
<Hobbsee> sarah@LongPointyStick:/storage/isos$ rsync -zhhP rsync://people.ubuntu.com/~pkl/test-gutsy-desktop-i386.iso  ubuntu-gutsy-desktop-i386.iso
<Hobbsee> rsync: failed to connect to people.ubuntu.com: Connection timed out (110)
<Hobbsee> rsync error: error in socket IO (code 10) at clientserver.c(104) [receiver=2.6.9] 
<Hobbsee> darn.
<jdong> aww no rsyncd :)
<jdong> Hobbsee: is wget end of the world or something?
<Hobbsee> pitti: i dont suppose you could copy it somewhere rsyncable?
<elkbuntu> jdong, for bandwidth, yes
<pitti> Hobbsee: you could wget it from a computer with good bandwidth where you have ssh access and then rsync from there
<Hobbsee> jdong: you clearly do not live in australia
<jdong> does rsync really help on squashfs'ed CD's?
<Hobbsee> pitti: oh, point.
<Hobbsee> jdong: seems to
<jdong> I would expect data to be in fairly arbitrary order across rebuilds, no?
<fabbione> hey pitti
<jdong> considering that it's all compressed in 65K blocks or whatnot
<pitti> jdong: yes, that works very well
<pitti> hey fabbione!
<jdong> pitti: cool, didn't know that. Got to try that some time
<pitti> jdong: in breezy or so we made some changes that ensures sane rsyncability
<jdong> pitti: that is really considerate :)
<pitti> jdong: the very first warty/hoary ones were indeed not
<fabbione> pitti:  i just retested #98518 ... IMHO you are good to go...
<pitti> fabbione: ah, good!
<fabbione> pitti: so that can go into .2
<pitti> right
* Hobbsee waves the "i dont suppose anyone can grab that iso, and let elkbuntu and i rsync off it?" magic stick around
* pitti changes to verification-done
<jdong> Hobbsee: lol if I were on wired and not wifi....
<elkbuntu> jdong, heh. your wifi is our wired :
<jdong> 1176.3KB/s
<elkbuntu> i hate you so much
<jdong> 11 minutes...
<pitti> Hobbsee: I wonder whether I could just put it on cdimage.u.c. temporarily
<Hobbsee> jdong: you suck.
<Hobbsee> pitti: that'd work
* jdong not gonna disclose internet2 speeds on wired... :D
<pitti> a lot of people will want to try it, after all
<elkbuntu> jdong, thanks
<Hobbsee> exactly
* jdong hugs elkbuntu and Hobbsee 
<Amaranth> jdong: heh, that's my wireless speed too
<Hobbsee> pitti: i vaguely ponder a respin, with that fix...
<jdong> Amaranth: it's definitely a wireless limit here
<elkbuntu> Amaranth, i hate you too then
<jdong> and it doesn't help that my closest AP is offline
<pitti> Hobbsee: the dailies will have it when we'll get the new kernel
<Hobbsee> pitti: or at least another release annoucement saying "if you're having trouble, try here"
<Hobbsee> ah right
<jdong> what exactly is this ISO?
<jdong> is it an updated tribe3 spin?
<elkbuntu> Hobbsee, see, we could have delayed it the whole of a day!
<elkbuntu> s/we/you/
<elkbuntu> hehe, not even a day
<Hobbsee> elkbuntu: would have been more than a day, though.  testing.
<pitti> jdong: I guess tribe3 with pkl_'s fixed kernel
<Hobbsee> pitti: which we rejected.  great
<elkbuntu> ...
<jdong> pitti: ah, fix for the livefs kernel issues?
<pitti> Hobbsee: no, at that time it wasn't fixed yet
<pitti> it just came up yesterday
<Amaranth> those dang bandwidth limits must really hurt when you're doing a release
<Hobbsee> pitti: oh, This has a fix for a Squashfs race condition that slipped into the code in April. A fix was released in May, but due to some oversight, the Gutsy kernel code wasn't updated.
<Hobbsee> Amaranth: rsync.
<Hobbsee> otherwise it's not possible
<jdong> I'm like 30% across...
<jdong> setting up a dummy user for ssh-age
* Hobbsee now has more plans for tribe 4, if she gets to implement them :P
* jdong wishes he didn't turn off sharkattack.media.mit.edu :(
<jdong> that was on yummy gigabit
<Hobbsee> pitti: but for that matter...why *doesnt* p.u.c support rsync?
<Hobbsee> and can it be made to?
<Hobbsee> Amaranth: rsync, and a lot of ssh, too.
<Hobbsee> Amaranth: paritcularly if a couple of the places that you can ssh to have a local mirror.
<Hobbsee> Amaranth: the speed is the blocker usually, not the bandwidth so much
<Hobbsee> Amaranth: then again, you dont have to upload terribly much, which is the real killer, at least for me.
<jdong> 50 seconds....
<jdong> 18.96.6.40::ubuntu/test-gutsy-desktop-i386.iso
<jdong> elkbuntu: Hobbsee ^^
<pitti> http://cdimage.ubuntu.com/bug-fix-tests/
<pitti> there we go
<jdong> lol
<jdong> identical timing :D
<Mithrandir> asac: you don't have the mobile browser by intel packaged up by any chance?
<Mithrandir> asac: getting that in would be very nice.
<Hobbsee> great, thanks
* Hobbsee waits for it to do anything
<Hobbsee> ahh, here we go
<pitti> rsync -vP rsync://cdimage.ubuntu.com/cdimage/bug-fix-tests/gutsy-desktop-i386.126964.iso gutsy-desktop-i386.iso
<pitti> that seems to work fine
* pitti adds bug comment
<pitti> speedup is 67.88
<pitti> now that's nice :)
<jdong> impressive
<Hobbsee> yeah, that's veyrf nice :)
<Hobbsee> 17 seconds....
<Hobbsee> man i love rsync.
<jdong> wow I never knew it worked so well for ubuntu isos
<pitti> ogra: since you have such perfect hardware for this bug, can you please rsync and try this as well?
<jdong> if that's the case, we should really get cracking on that zsync spec :)
<Hobbsee> pitti: ah ha!  my speedup wins@
<Hobbsee> sent 184.39K bytes  received 8.39M bytes  41.47K bytes/sec
<Hobbsee> total size is 692.42M  speedup is 80.84
<jdong> that's even more impressive :)
<pitti> Hobbsee: so I guess pkl just put a different squashfs.ko into it or so :)
* pitti hugs pkl_ 
<Hobbsee> probably
* pitti burns
* Hobbsee burns too
* Hobbsee burns jdong 
<elkbuntu> lol
<jdong> lol
* jdong started using zsh today....
<jdong> IMO we should ship a more functional zshrc in our packaging...
<jdong> the process of getting a half-decent zshrc was more than painful
<asac> Mithrandir: yes ... i was disrupted by mozilla quick-release ... so ... I will work on the package today
<Hobbsee> asac: if we now have a ubufox, do you also plan for a kubufox, to get the kubuntu defaults?
<Mithrandir> asac: great, thanks.
<asac> Hobbsee: hmm ... for now I have no use-case for making a new extensino package for kubuntu ... but who knows
<Hobbsee> asac: for the "firefox working better on kde" spec, etc
* elkbuntu boots into the testing image
<asac> Hobbsee: i think most of the kde features should go to firefox core ... not to an extension.
<elkbuntu> or tries. stupid cd
<asac> Hobbsee: i think one could say: kde specifics should go to core, while kubuntu specifics might justify a kubuntu extension
<Mithrandir> asac: new firefox broke my middlemouseContentLoadURL setting _again_.
<asac> Mithrandir: what did it do?
<Mithrandir> asac: reset it to false.
<asac> Mithrandir: so its default now again?
<elkbuntu> Hobbsee, can you md5 sum the testing image please?
<asac> if you look in about:config?
<Mithrandir> asac: yes.
<Mithrandir> (well, it's now true again, since I changed it.  I prefer my browser to work)
<asac> Mithrandir: can you reinstall ubufox and see if things get reset?
<Mithrandir> asac: you need to find a way to make sure this works correctly on upgrades; not doing so breaks the golden rule.
<elkbuntu> or pitti or jdong
<pitti> elkbuntu: 7328f59cfdcebce5d0565c332e8691f6 here
<Mithrandir> asac: it did not get reset when I reinstalled the same version of ubufox.
* StevenK appears
<pitti> hey StevenK
<StevenK> Hi pitti
<dholbach> good morning
<cjwatson> pitti: FWIW, the specialised changes in breezy to improve rsyncability were for cloop; when we switched to squashfs, it was sanely rsyncable without the need for anything special
<pitti> hey dholbach
<pitti> cjwatson: ah, cool
<dholbach> heya pitti
<elkbuntu> pitti, thanks. /me snaps the cd
<elkbuntu> pitti, you might want to put that with the image
<pitti> elkbuntu: right
<pitti> elkbuntu: done
<elkbuntu> pitti, cool
<asac> Mithrandir: 1. downgraded ubufox ... all still fine ... 2. upgraded ubufox again ... all still fine here :/
<Mithrandir> asac: I don't think ubufox was upgraded, just firefox.
<asac> i uploaded both
<Hobbsee> pitti: works for me
<pitti> \o/
<Hobbsee> asac: true, as long as they dont overwrite the gnome ones...
<Hobbsee> which i suspect they may
<Hobbsee> pitti: the iso, that is
<asac> Mithrandir: yes ... thats interesting
<asac> Mithrandir: smells like a bug in upgrade code
<Mithrandir> plz fix. :-)
<elkbuntu> Mithrandir, you missed the kthxbye bit
<Mithrandir> elkbuntu: I'm friendly today, so no kthxbye
<elkbuntu> hehe
* elkbuntu hugs the friendly Mithrandir
<Hobbsee> elkbuntu: it's a trick.
* Hobbsee hides away from Mithrandir's big, sharp teeth.
* Mithrandir snatches Hobbsee and chews on her.
<Hobbsee> hey!
* Hobbsee does not wish to be chewed on!
<elkbuntu> Mithrandir, tasty?
* Hobbsee beats Mithrandir up with a large piece of concrete
<Hobbsee> elkbuntu: not tasty.  too bony.
<Mithrandir> elkbuntu: a bit too much bone, yes.
<elkbuntu> what is with the concrete? the stick on hiatus?
<Hobbsee> elkbuntu: more effective than a large pipe, as it's bigger.
* Mithrandir sees Hobbsee try to lift a piece of concrete and getting herself smashed as she can no longer hold it above her head.
<Hobbsee> hah
* Hobbsee can probably still lift reasonably large amounts of weight...
<Hobbsee> depends how big the concrete is, though
<dholbach> you guys are weird
<dholbach> :-)
<Hobbsee> dholbach: you mean it's taken you *this* long to notice?
<dholbach> no, but this time I couldn't stop myself typing it ;-)
<Hobbsee> haha
<elkbuntu> ooh. i get a desktop and no looping gdm
<Hobbsee> woo!
<elkbuntu> where's pitti?
<elkbuntu> and mvo
<Hobbsee> elkbuntu: they were Mithrandir's first and second victims
<pitti> elkbuntu: I didn't go anywhere
<elkbuntu> i get a 'failed to initialize HAL!' though
<pitti> elkbuntu: that usually happens if it takes very long to start the session
<pitti> elkbuntu: does 'pidof hald' print out anything?
<elkbuntu> pitti, ok, it did take a fair while
<elkbuntu> pitti, seems that it wasnt compiz?
<cjwatson> grr, the last firefox/ubufox? upgrade trashed my middlemouse.contentLoadURL preference *again*
<elkbuntu> pitti, opening terminal gives me "/bin/sh: Can't open id" still
<elkbuntu> but i do have a prompt
<pitti> elkbuntu: "file /usr/bin/id" ?
<StevenK> cjwatson: [17:22]  < Mithrandir> asac: new firefox broke my middlemouseContentLoadURL setting _again_.
<Mithrandir> cjwatson: yes, see above.  asac is already looking at it.
<elkbuntu> pitti, hald id is there
<elkbuntu> 8211
<pitti> elkbuntu: hald> ok, so it was just due to slow startup and should be harmless
<pitti> elkbuntu: so /usr/bin/id is still trashed for you?
<elkbuntu> pitti, sec
<pitti> elkbuntu: if so, please note that in the bug report
<elkbuntu> "cannot execute binary file"
<pitti> elkbuntu: what does file say?
<elkbuntu> pitti, gobbledigook
<pitti> bah
<pitti> elkbuntu: ok, so something else still seems to be wrong; please do a bug followup with that
<elkbuntu> pitti, what bug#. i'll attach it
<elkbuntu> oh, my bug id?
<pitti> elkbuntu: bug 126964
<ubotu> Launchpad bug 126964 in linux-source-2.6.22 "gutsy livefs causes random hangs or modprobe crashes" [Critical,New]  https://launchpad.net/bugs/126964
<elkbuntu> right
<elkbuntu> but other than that, it is much improved
<elkbuntu> hmm... has the default font changed or something?
<elkbuntu> it's really hard on my eyes :-/
<Hobbsee> of launchpad?  yes
<elkbuntu> Hobbsee, yeah
<elkbuntu> actually... the font in the firefox menus is crap too, so it might be my screen
<stub> elkbuntu: I believe Launchpad now honours whatever default fonts your browser is configured for rather than rudely overriding them.
<Hobbsee> oh, so that's why my font changed too...
<cjwatson> StevenK,Mithrandir: ah, heh
<elkbuntu> stub, ok. that would explain why all fonts in the firefox window hurt my eyes
<cjwatson> StevenK,Mithrandir: (it was while I was pinged out)
<elkbuntu> which i suspect would be where we blame gtk
<Hobbsee> just switch to qt.  easy fix.
<elkbuntu> pitti, would you like me to attach the id file?
<elkbuntu> Hobbsee, eww
<Mithrandir> cjwatson: pinging ftw. :-)
<thom> Hobbsee: (or tear your eyes out - about the same level of pain and suffering)
<pitti> elkbuntu: the output of "file /usr/bin/id" is enough, I think
<stub> elkbuntu: or the default font selection the firefox packager used. or you for not changing your defaults to something more aesthetically pleasing to you :)
<elkbuntu> stub, this is the livecd. i doubt many people are going to change the default settings for a first-time preview ;)
<cjwatson> elkbuntu: Launchpad 1.1.7 advertised a larger font size as one of its "benefits"
<cjwatson> elkbuntu: I filed bug 126993 about it
<ubotu> Launchpad bug 126993 in launchpad "bug body text font size recently changed to be annoyingly large" [Undecided,New]  https://launchpad.net/bugs/126993
<elkbuntu> cjwatson, the size isnt the issue. the letters are narrow and fuzzy
<cjwatson> elkbuntu: ok, different problem then
<elkbuntu> pitti, file /usr/bin/id is interesting to say the least
<pitti> elkbuntu: some XML goo?
<elkbuntu> it's an mpeg
<pitti> elkbuntu: right, ogra had some XML goo; it obviously points to the wrong bits of the CD
<elkbuntu> sec while i finish the comment. attaching the file for posterity
<cjwatson> I suspect the contents of the file are not all that interesting
<cjwatson> though I suppose correlating it with where that data should have been might be informative
<elkbuntu> pitti, and would explain why it's not quite working as it should
<pitti> right
<elkbuntu> comment submitted
<elkbuntu> pitti, so what should we do with https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/126971 ? i assume nothing changed in that department, so it's probably wrongly filed?
<ubotu> Launchpad bug 126971 in compiz "[gutsy]  compiz crashes x or gdm repeatedly" [High,New] 
<pitti> elkbuntu: just leave it there, mvo is much better skilled to look at it
<elkbuntu> right
<pitti> ScottK: clamav accepted for dapper-backports
<elkbuntu> pitti, would the id mixup be to do with the FS corruption issue? maybe not entirely fixed, just fixed enough to boot?
<pitti> elkbuntu: well, that *is* the fs corruption issue, isn't it?
<elkbuntu> oh. right
* elkbuntu should stop trying to be a l33t h4cker type :
<pitti> oh, please don't :)
* elkbuntu hides
<pitti> elkbuntu: ATM I'm not sure wheter there are actually two bugs: one squashfs race condition (which pkl fixed) and another bug that causes fs corruption
<elkbuntu> i've been supposed to be writing an article over the past day, this kinda... distracted me
<pitti> they did seem to be related at first
* Hobbsee --> gone.  out to dinner
<elkbuntu> pitti, i'd guess the corruption would be what tripped the race condition up?
* elkbuntu has no clue about race conditions, so is talking out her arse here
* pitti doesn't know
<elkbuntu> ok, im going to reboot into the safe graphics mode and see if that goes smooth too
<elkbuntu> hmm. safe graphics mode isnt so safe with the via
<ogra> pitti, ergh, so sorry, the drugs i take tear me down around noon atm, not taking a nap made me fall asleep before meeting/release
<pitti> ogra: no problem :) I hope you'll get well soon!
<pitti> ogra: so, in the meantime we have a new ISO to test, which apparently makes it better, but still doesn't solve the file corruption
<ogra> just had my final examination at the dentist ... pulling the sewing out of my jaw ... ad dont need to take the painkillers anymore, only antibiotics left, should be good now :)
<ogra> yeah i saw the ping
<ogra> my changing back of the loop device creation in casper somehow didnt work ...
<ogra> (it didnt mount at all and i didnt debug further yet ... rsyncing the last image now
<elkbuntu> ogra, are you with your via and is it free at the moment?
<ogra> yup
<elkbuntu> ogra, are you able to boot into 'safe mode' with the new iso?
<elkbuntu> safe graphics mode*
<ogra> i'm still rsyncing
<elkbuntu> no prob
<ogra> ah, no, its done... gmiie a second to burn
<fabbione> cjwatson: do you have a few minutes to discuss a couple of debian-installer/anna changes?
<fabbione> cjwatson: if you are busy i can mail them or file a wishlist bug...
<pitti> Riddell: can bug 126766 be closed now in gutsy?
<ubotu> Launchpad bug 126766 in feisty-backports "latest qt 4.3 backports produces visual corruption during scrolling and in the systray" [Medium,In progress]  https://launchpad.net/bugs/126766
<elkbuntu> pitti, does the 20070720 daily have the race fix?
<pitti> elkbuntu: no, it can't (no new kernel)
<ogra> elkbuntu, behavior didnt change gdm doesnt start, i seem to get the ncurses gui that asks if i want to see the logs but the console display is so broken that i only can guess its that question
<Riddell> pitti: I certainly hope so, the reporter is yet to confirm to me that it fixed his problem
<ogra> pitti, sure thats a kernel thing ?
<pitti>    qt4-x11 | 4.3.0-4ubuntu1 |         gutsy | source
<pitti>    qt4-x11 | 4.3.0-4ubuntu1~feisty1 | feisty-backports | source
<elkbuntu> pitti, ah ok. should i still file bugs against the test image then, or wait?
<ogra> i still think its casper
<pitti> Riddell: so is that the new version you uploaded?
<ogra> eve though it might be that the race comes from the kernel and caper only exposes it after the changes
<pitti> ogra: I think pkl put in a new squashfs.ko in his test iso
<Riddell> pitti: yes
<elkbuntu> ogra, try booting in safe mode again, but add single to the options
<ogra> ah
<pitti> elkbuntu: I'd rather wait for now
<ogra> elkbuntu, oki
<elkbuntu> pitti, right
<pitti> Riddell: curious, I didn't backport that one today, I just binary-NEWed it in backports
<Riddell> pitti: oh I approved it, sorry should have told you
<pitti> Riddell: no problem
<pitti> Riddell: you should just have closed the backports task
<pitti> but let's wait for confirmation, right
<ogra> elkbuntu, single helps ...
<ogra> but lots of complaints about scripts in /lib/udev this time :)
<elkbuntu> ogra, what does lspci report your vid card as
<ogra> so FS corruption persists
<elkbuntu> (if you get to a terminal)
<ogra> VT8623
<ogra> Apollo CLE266
<Riddell> pitti: if you pass qt4-x11 through NEW in gutsy that'll help matters along
<pitti> ah, sure
<elkbuntu> right, we have different VIAs
<pitti> Riddell: done
<Riddell> thanks
<cjwatson> fabbione: I have a few minutes now
<elkbuntu> ogra, for the record, this is the vesa not liking the via. normal graphics mode works for me ;)
<cjwatson> pitti: I'm merging the Ubuntu debootstrap fakechroot scripts into the main scripts, BTW
<tkamppeter> I have a question about Launchpad: How can I remove dependencies between Blueprints?
<fabbione> cjwatson: ok cool.. so basically the use case we are facing often right now is that we need to boot on totally new hw that requires new kernel support.
<cjwatson> pitti: you shouldn't notice a difference, but let me know if you do
<ogra> elkbuntu, this one actually works with via
<ogra> but needs VideoRam set
<pitti> cjwatson: ah, that's sweet; it'll end up as a proper variant?
<cjwatson> pitti: yeah
<fabbione> cjwatson: ideally we would like to piggyback an installer initrd.gz (without ubuntu kernel modules) right into a custom kernel and avoid anna to complain about missing kernel modules
<elkbuntu> ogra, ah. this is probably the problem with mine too
<fabbione> cjwatson: so i did look a bit around and found (general lines) this solution..
<cjwatson> fabbione: my instinctive solution for that would be to use multiple initramfses
<fabbione> cjwatson: debian-installer to have an extra netboot target of somekind that will take the same initrd as generated by the netboot target and rm -rf /lib/modules
<elkbuntu> ogra, is this a known bug?
<fabbione> cjwatson: and anna to not complain if there is no /lib/modules as sign that the image is custom
<fabbione> cjwatson: yeps.. exactly.. but we need to generate and publish an extra initrd
<cjwatson> fabbione: I think that's overkill, just make a tree with the new /lib/modules, cpio it up, and slam it on the end of the normal initrd
<ogra> elkbuntu, for this model at least
<fabbione> cjwatson: but once you did warn me that adding targets to d-i is not trivial
<cjwatson> fabbione: it'll use a bit more memory, but not enough to worry about for us
<fabbione> cjwatson: there are issues with the size of the kernel and the initrd on some arches.
<fabbione> cjwatson: they tend to explode a bit with debugging and custom kernels
<cjwatson> size of single initrds, but not afaik with multiple initramfses
<fabbione> it's a problem with the PXE equivalent of sparc...
<fabbione> it can't cope with more than 9MB
<fabbione> and the image is one file
<cjwatson> I'm not interested in supporting an installer initrd.gz with no modules
<fabbione> in netbooting that's it
<cjwatson> I don't think that's appropriate or sensible
<cjwatson> it's very easy to unpack a d-i initrd and put new modules in it
<cjwatson> it could be scripted trivially
<cjwatson> unless you mean a non-modular kernel, but surely that will break in other places in Ubuntu
<fabbione> we often don't need new modules in.. just a stripped down initrd.. anyway the problem is that we still don't publish the netboot initrd on sparc.. that would be a good start and more than ok to me
<fabbione> non-modular seems to work pretty well at the moment for the installer
<fabbione> except that anna error :)
<cjwatson> in any case, if you just want to kill anna's complaint, that's trivial
<cjwatson> preseed anna/no_kernel_modules=true
<fabbione> ok.. would you be totally against publishing the netboot initrd in the archive?
<cjwatson> if it's not published, that's just a bug
<fabbione> i mean you ca find it in the mini.iso.. but it's an extra set of steps.. etc.
<cjwatson> you mean that's there's no initrd.gz alongside http://archive.ubuntu.com/ubuntu/dists/gutsy/main/installer-sparc/current/images/sparc64/netboot/2.6/boot.img ?
<fabbione> exactly
<fabbione> boot.img is kernel+initrd
<cjwatson> sure, I can fix that
<fabbione> ok that would be more than enough for me to avoid manual rebuilds to grab the initrd.gz
<fabbione> the other stuff was more for a wishlist
<fabbione> we can live with modules and anna complains
<fabbione> cjwatson: do you want a bug for it?
<cjwatson> no, it's ok, I've done it already, just preparing the upload
<cjwatson> like I say, the right way to turn off the anna complaint is preseeding, IMO
<fabbione> yeps.. that's fine
<cjwatson> one reason I don't really want to go the stripped-down initrd approach is that it would logically need to be done for every image
<cjwatson> the d-i image tree is big enough in the archive as it is :)
<fabbione> it's fair enough..
<fabbione> i mean this is havey development anyway
<fabbione> but it will allow us to skip one/two steps with manual builds of d-i
<tkamppeter> Any Launchpad expert around?
<tkamppeter> How can I remove dependencies between blueprints?
<cjwatson> fabbione: ok, debian-installer 20070308ubuntu8 should publish kernel and initrd for sparc64 netboot separately, assuming it builds :)
<fabbione> cjwatson: eheh thanks man
<cjwatson> tkamppeter: go to the depending spec, "Remove dependency" in the menu on the left
<tkamppeter> Thanks, I succeeded now to remove the printerdrake dependency from easy setup of printer sharing (https://blueprints.launchpad.net/ubuntu/+spec/printer-sharing). I did not find this in the first place as I tried to remove a dependency from printer auto-install (https://blueprints.launchpad.net/ubuntu/+spec/automatic-printer-conf) which was assigned to pitti and therefore did not offer the function to me.
<cjwatson> tkamppeter: ah, that's true, there may well be access control
<soren> pitti: *sigh* You remember when we were going through one of the postinst scripts for one of the eBox modules and found that yucky "killall gconfd-2"? I've found out why it was there now.
<pitti> soren: I remember, yes
<soren> pitti: gconfd-2 seems to not handle SIGHUP (which tells it to load new schemas) when it receives the signal, but rather at its next periodic cleanup run which may be up to 30 seconds later.
<pitti> soren: that seems to be a generic problem; shouldn't update-gconf-defaults handle that rather?
<soren> pitti: And hence the rest of the postinst script will fail if there was already a gconfd-2 running.
<soren> pitti: update-gconf-defaults?
<pitti> soren: that seems really mad -- why does the postinst care about user processes?
<soren> pitti: How does that differ from setting the values in a schema?
<pitti> soren: u-g-d regenerates /var/lib/gconf/defaults/ which is necessary for new schemas anyway (handled by dh_gconf)
<soren> pitti: Becase it installs the new schema and then tells ebox to load the corresponding module, but because gconfd-2 hasn't been bothered to load the schema yet, ebox doesn't know about the module's existence.
<ogra> soren, killall gconfd-2 was usual behavior once
<soren> ogra: eek.
<pitti> soren: but that should only affect root's gconfd, not everyones
<ogra> right
<soren> pitti: ebox's gconfd-2, actually, but yes.
<ogra> well there was a system gconfd back then iirc
<pitti> soren: u-g-d does kill -HUP gconfd-2 already
<soren> pitti: I've asked the ubuntu-desktop team for advice.
<pitti> soren: that might be better, yes; thank you!
<soren> pitti: I just wanted to share my frustration :)
<pitti> so if that's wrong or not sufficient, it shuold be changed to s/HUP/TERM/ or so
<ogra> soren, do you want to override system defaults ?
<pitti> soren: :)
<soren> ogra: These settings are only relevant to ebox anyway.
<ogra> you can just put a file into /usr/share/gconf/defaults/
<ogra> no need to fiddle with gconfd at all ;)
<wolfe> I love when people don't understand the bug fix process at all and blast away at people
<ogra> sequence umbers higher than 10 override system settings
<ogra> (have a look in that dir)
<wolfe> I finally tested out the blasted python-fam :)
<wolfe> =] 
<soren> ogra: a) I want the schemas installed anyway, b) I suspect /usr/share/gconf/defaults/ has the same limitations (up to 30 second delays)?
<wolfe> it works nicely.
<ogra> soren, it should take effect immediately ...
<ogra> but to be honest i never tried that on the fly :)
<ogra> edubuntu-artwork and gnome-power-amanger use it for their defaults
<ogra> but they are installed by d-i/ubiquity
<soren> ogra: It has the same problem.
<soren> ogra: I also works by sending every running gconfd-2 a SIGHUP.
<ogra> right
<ogra> thats the way used after killall was dropped iirc
<ogra> but there is a debhelper for that afaik
<soren> ogra: Yes.
<soren> ogra: dh_gconf does the schema registration and defaults installation magic.
<ogra> right, that was it
<asac> doko: ?
<doko> asac: ?
<wolfe> win 3
<tkamppeter> pitti, ping
<pitti> hi tkamppeter
<tkamppeter> hi pitti
<tkamppeter> Yesterday at the meeting we decided on replacing gnome-cups-manager by system-config-printer.
* fabbione pats his 57 disks machine
<tkamppeter> Now I wanted to update the Blueprints, especially that some things are not dependent on printerdrake any more.
<fabbione> like... sddb
<tkamppeter> I succeeded to remove the dependency in https://blueprints.launchpad.net/ubuntu/+spec/printer-sharing as this Blueprint is assigned to me.
<tkamppeter> But I cannot remove it from https://blueprints.launchpad.net/ubuntu/+spec/automatic-printer-conf as it is assigned to you, pitti.
<pitti> tkamppeter: I can remove it
<tkamppeter> Can you remove the dependency on printerdrake there? Thanks.
<pitti> done
<tkamppeter> I have assigned bug 127120 to this Blueprint, as from the printer setup tool side the Blueprint needs to get this one fixed now.
<ubotu> Launchpad bug 127120 in system-config-printer "Add a command line option to run only the add-printer wizard with reduced interactivity" [Medium,Confirmed]  https://launchpad.net/bugs/127120
<tkamppeter> Thanks, pitti.
<tkamppeter> By the way, https://blueprints.launchpad.net/ubuntu/+spec/printer-sharing gets fixed by switching to system-config-printer.
<tkamppeter> pitti, I have already checked whether all features of the gnome-cups-manager are also in the system-config-printer and that is the case. So I think we should through the switch now and make s-c-p the default printer setup tool and take g-c-m out of the distro.
<pitti> tkamppeter: I'm still a bit wary; last time I saw s-c-p it had quite a complicated UI, too
<ScottK> pitti: Thanks for the clamav.  The lifts a load from my mind.  Clamav on Dapper is still ancient, but it's the best we can do for the moment.
<ScottK> pitti: I had been the one who subscribed ubuntu-archive for Bug #117623 - I've now added an explicit comment (the comment that suggests I do that in general is a good one).
<ubotu> Launchpad bug 117623 in feisty-backports "backport libfile-rsyncp-perl 0.68-1 to feisty" [Wishlist,In progress]  https://launchpad.net/bugs/117623
<ScottK> Thanks for all the backports today.
<pitti> ScottK: ah, I see; for later sync bugs I looked at the activity log and just assumed that you knew what you were doing :)
<ScottK> OK.  I hope I do ;-)
<pitti> ScottK: done
<ScottK> Thanks
<ScottK> Dunno if I'm up to know what I'm doing, but I think I'm being considerably less crackful than *-backports has in the past.
<ScottK> I won't fixed one this week and said backports doesn't get you out of the SRU.  Go do an SRU first and then I'll approve a backport for the features ;-)
<ScottK> Thanks again.
<kagou> tkamppeter, do you plan to quicly update s-c-p to 0.7.70 ?
<tkamppeter> pitti, I have checked through the current s-c-p and it does not look much more complicated than g-c-m. There are some smaller usability issues which I have reported as bugs, see bug 127071, bug 127072, bug 127074, bug 127079, bug 127119, bug 127120. They all can be implemented independently and with not to much coding.
<ubotu> Launchpad bug 127071 in system-config-printer "system-config-printer does not save options into .cups/lpoptions for unprivileged users" [Medium,Confirmed]  https://launchpad.net/bugs/127071
<ubotu> Launchpad bug 127072 in system-config-printer "system-config-printer asks for the print queue name before scanning for printers and selecting the printer model" [Low,Confirmed]  https://launchpad.net/bugs/127072
<ubotu> Launchpad bug 127074 in system-config-printer "When system-config-printer lists an auto-detected network printer with IP, it does not fill the IP automatically into the appropriate field." [Medium,Confirmed]  https://launchpad.net/bugs/127074
<ubotu> Launchpad bug 127079 in system-config-printer "system-config-printer should check whether a detected (or also manually entered) network printer works also via HPLIP" [Medium,Confirmed]  https://launchpad.net/bugs/127079
<ubotu> Launchpad bug 127119 in system-config-printer "Introduce printer renaming feature" [Low,Confirmed]  https://launchpad.net/bugs/127119
<tkamppeter> kagou, this is a good idea. Did you already have a look into 0.7.70?
<tkamppeter> ubotu, you forgot bug 127120
<tkamppeter> bug 222222
<cjwatson> tkamppeter: it may well be rate-limited
<tkamppeter> kagou, do you know where I can download the source tarball of s-c-p 0.7.70?
<Mithrandir> asac: how does the mobile browser look?
<tkamppeter> kagou, I have found it on Tim Waugh's home page.
<asac> Mithrandir: i am on it :)
<asac> Mithrandir: i migrated everything ... now i am doing a first package testbuild
<Mithrandir> asac: ok, coolie. :-)
<Mithrandir> asac: please keep me posted as to how it's going.
<asac> Mithrandir: where shall I push the ubuntu bzr branch
<asac> e.g.  i guess to mobile team and not to core-dev right?
<asac> Mithrandir: please add me to mobile team if you want the package branch maintained in the mobile team realm.
<Mithrandir> you're maintaining it in git, not bzr, don't you?
<asac> the packaging is in bzr ... like the firefox packaging
<asac> e.g. just debian/ dirt
<asac> i produce the orig.tar.gz from git repo ... yes
<Mithrandir> ah, ok
<Mithrandir> what's your lpid?
<asac> guess :)
<asac> asac
<asac> http://codebrowse.launchpad.net/~asac/firefox/ubuntu-2.0.0.x
<asac> thats the firefox branch i base on
<Mithrandir> added
<asac> Mithrandir: ok i will add a new project called midbrowser in lp .... and push the packagin to mobile team
<Mithrandir> asac: sounds good.
<lool> Anyone seen Scott James Remnant?
<lool> He's welcome to join the AB meeting on first floor at GUADEC
* Nafallo tries to find the DVDs for Tribe-3 :-P
* Hobbsee waves
<jwendell> Hi, Hobbsee
<Hobbsee> :)
<jwendell> first, congrats for tribe 3 ;)
* Starting logfile irclogs/ubuntu-devel.log
<Nafallo> hmm. 4.5GB
<ogra> soren, is it clear that ebox will enter main for gutsy ?
<Nafallo> baah. I'll clean up some space for them :-P
<pitti> it needs uservification first
* Hobbsee hugs ogra 
* Hobbsee hugs pitti 
<ogra> Hobbsee, hey :)
<ogra> Hobbsee, congrats for your first RM job, well done :)
<Hobbsee> ogra: have you fixed the world yet?  :)
<Hobbsee> ogra: thankyou :)
<ogra> nope :)
<Hobbsee> ogra: it was certainly fun :)
<Hobbsee> awww
<Hobbsee> ogra: hoping it wont be the last, but we'll see
* ogra agrees (seriously) thats the time i love most .... short before releases is even better :)
<ogra> (nobody understands me there :)
<Hobbsee> haha.  i understand that :)
<ogra> its exciting and fun and you know it ends if youre done :)
<ogra> (it == the stress)
<Hobbsee> ogra: indeed!
<elkbuntu> so has anyone installed from the muddled tribe cd successfully?
<Hobbsee> ogra: i'm surprised you werent asked to do the RM job, with that attitude, instead of pitti
<pitti> elkbuntu: actually, yes
<Hobbsee> elkbuntu: hope so!
<elkbuntu> hmm... me debates giving it a go
<ogra> Hobbsee, i'm not as precise as pitti ... :)  i'd let slack more stuff thrugh ....
<Hobbsee> ahhhh....
<ogra> i'm happy to do it for edubuntu ...
<ogra> and if i at some future day have extra time to spend on anythng else i'll probably go for it :)
<Hobbsee> but the whole thing becomes a bigger kettle of fish, yes
<soren> ogra: That's the plan, yes.
<ogra> currently edubuntu, ltsp and classmate are more than a fultime job ...
<ogra> soren, i wonder if shorewall couldnt go then ;)
<soren> ogra: I've never used shorewall, but I'd guess that it is a bit more flexible than ebox' firewall module. I could be wrong, though.
<ogra> i dont think its very flexible ... it ust has a webgui for iptables
<soren> ogra: ebox provides are more digested view of a firewall. It only exposes a quite limited subset of iptables' functionality. (something like http://www.ebox-platform.com/shots/Global_firewall_configuration.png )
<soren> brb
<ogra> ah, standard DSL router stuff
<Hobbsee> pitti: you havent noticed the restricted manager being gone in tribe 3, have you?
<Hobbsee> i thought it must be something here
<soren> ogra: Yeah, much of ebox resembles stuff your garden variety DSL router might provide.
<ogra> sad
* ogra would love to see shorewall go ... but well
<Chipzz> ogra: what's so bad about shorewall?
<Nafallo> yes. please throw that fucking thing away and add firestarter to main instead :-)
<Nafallo> Chipzz: gave me 2Mbit in on my 10Mbit ADSL
<Chipzz> crappy config then I guess
<Chipzz> I use it in the datacenter
<Chipzz> no problems with limited bandwidth :P
<Nafallo> hmm. I think iptables is easier to configure then shorewall anyway :-)
<ogra> Nafallo, shorewall <-> firestarter .... two totaly different things :)
<Nafallo> ogra: it is?
<ogra> one is a portblocker, the other is a firewall
<Nafallo> ogra: I'm not sure I agree there. both are firewalls.
<Nafallo> one of them with a gui.
<ogra> a firewall is a machine oarting two networks securely
<ogra> *parting
<ogra> firwestarter is surely a portblocker to run on your desktop
<Nafallo> a firewall might as well be a wall between inside and outside.
<ogra> even some cool windows marketing people managd to mix the terms  ....
<kylem> "packet filter"
<kylem> itym.
<ogra> yeah, thanks
<ogra> port blocker sounds medical :)
<Nafallo> I still can't really see a big diffrence :-)
<Nafallo> a port blocker is simply a wall between two places as well
<Nafallo> packet filtering is more or less what a firewall does according to me :-)
<ogra> Nafallo, if i build a firewall, i compile a monolithic kernel, dont have any useraccounts on te system and no packages installed beyond whats needed to run that thing
<Nafallo> ogra: when I build a firewall I don't do it the same way as you do ;-)
<ogra> packet filters are only providing fake security
<Nafallo> I can't afford to have hardware running just for that.
<ogra> and are totally pointles on systems with no open ports like ubuntu
<ogra> you dont have an old 486 around ?
<Nafallo> ogra: my ubuntu systems often have open ports ;-)
<Nafallo> ogra: I have something called bills :-)
<ogra> because you wanted these open (i.e. because you installed a certain tool that opens them)
<Nafallo> ogra: yes, but not for everyone.
<ogra> well, there a port mangler would make sense then ....
<ogra> but callin it firewall is still a marketing lie ;)
<ogra> and comparing that to shorewall is simply not working :)
<\sh> paketfilter != firewall...firewall==concept with several security systems attached
<Nafallo> or rather just call the rules I have a firewall, since that's what it essentially is even though it's not on a seperate system until I get virtualisation going :-)
<\sh> moins ogra btw :)
<ogra> hey \sh
<ogra> did you get the link i pasted you last time i pinged ?
<\sh> ogra: which one? I don't think so...
<ogra> \sh, they found marcel with cut throat four weeks ago
<jsgotangco> wha?
<ogra> jsgotangco, my ex landlord (we moved a year ago)
<pitti> Hobbsee: erm, no?
<pitti> Hobbsee: darn, indeed
<asac> Mithrandir: "patch to prevent user prefs being reset to
<asac> default during upgrade"
<Hobbsee> pitti: right
<asac> Mithrandir: http://codebrowse.launchpad.net/~asac/firefox/ubuntu-2.0.0.x/revision/asac%40jwsdot.com-20070720130359-cje0mzxhcr6ne9oj?start_revid=asac%40jwsdot.com-20070720130359-cje0mzxhcr6ne9oj
<asac> i will update ffox as soon as midbrowser is up
<Hobbsee> pitti: want me to file a bug?  looks like you're the maintainer
<Hobbsee> looks like it's in desktop, but not live.  but then, the seed-foo says that desktop is a dependancy of live, so that should be correct
<pitti> Hobbsee: aah, I know
<cjwatson> maybe something to do with it being moved to restricted
<pitti> Hobbsee: ubuntu-desktop is in main, but restricted-manager is in restricted now
<cjwatson> that is supposed to work though
<Mithrandir> asac: thanks.
<Hobbsee> i was about to ask if the seeds supported restricted
<Mithrandir> asac: please ask pitti to NEW midbrowser once it hits.
<cjwatson> they're meant to
* cjwatson checks the build logs
<cjwatson> pitti: I blame apt
<cjwatson> maybe
<cjwatson> it lists restricted-manager under "Recommended packages:"
<Hobbsee> cjwatson: that's what it's supposed to be?
<pitti> hm, it is a recommends of u-d
<Hobbsee> oh fuck.....
<Hobbsee> no no no!!!!
<Hobbsee> do we have *any* recommends installed by default now, since i changed the package?
<cjwatson> oh, hang on
<cjwatson> I bet it's actually a Soyuz bug - I don't see a Task header for restricted-manager
<Hobbsee> oh good, not my fault then.
<Hobbsee> i did check for random breakages from my apt code changes, when it eventually got to work again.  maybe i'm just paranoid...
<cjwatson> yeah, Soyuz doesn't know how to set Task overrides outside main
<cjwatson> this is going to be messy
<pitti> hmm
<pitti> putting it back to main would block evand and gobuntu, I think
<cjwatson> could just symlink more-extra.override.gutsy.restricted to more-extra.override.gutsy.main
<pitti> well, r-m itself is as free as it can get, of course
<cjwatson> let me do that after this publisher run is over and see what happens :-)
<pitti> cjwatson: thanks a lot
<Hobbsee> cjwatson: great :
<Hobbsee> )
<iwj> /usr/bin/make -C /root/adt-downtmp/dsc0-build/dejagnu-1.4.4.cvs20060709/objdir check < /dev/tty
<pitti> cjwatson: hm, it should be over now; what needs to be done for that?
<cjwatson> pitti: I've done it, the next publisher run should pick it up
<cjwatson> with luck
<pitti> ah, great
<cjwatson> lp_archive@drescher:/srv/launchpad.net/ubuntu-archive/ubuntu-germinate$ join <(grep-dctrl -nsPackage -P '' gutsy_restricted_Packages | sort) <(egrep -v -- '^(-|Package| )' desktop | awk '{print $1}' | sort)
<cjwatson> restricted-manager
<cjwatson> good, only one package affected
<pitti> yay, we can finally sync bzr; thanks, Debian
<pitti> hi mathiaz
<mathiaz> pitti: hi
<mathiaz> pitti: could we move apparmor into main ?
<pitti> mathiaz: right
<pitti> mathiaz: done
<pitti> mathiaz: except for -profiles
<pitti> oh, yay soyuz breakage
<Hobbsee> pitti: s/breakage/workage/
<Hobbsee> pitti: the statuses got swapped, because people thought it should work more often that it breaks :P
<pitti> no, change-override doesn't work any more for binaries
* Hobbsee ducks
<Hobbsee> undocumented feature
<pitti> mathiaz: so, -profiles is in main for now, we'll demote it again once change-override.py got fixed
<pitti> mathiaz: however, now we actually need to seed it somewhere so that it stays in main
<mathiaz> pitti: ok.
<pitti> mathiaz: ubuntu-standard Recommends:?
<mathiaz> pitti: seems good to me.
<pitti> mathiaz: ok, doing
<mathiaz> pitti: where are the other package ? ubuntu-standard Recommends ?
<pitti> mathiaz: what do you mean?
<mathiaz> pitti: I mean apparmor-utils
<pitti> ah, right
<pitti> I'll add that
<mathiaz> pitti: IIRC apparmor-utils would be added to ubuntu-standard so that it gets installed by default but can be uninstalled by the user.
<pitti> back in 2 minutes
<Nafallo> that's recommends :-)
<jdub> canonical folks handy?
<jdub> could someone call keybuk for me?
<Hobbsee> jdub: no, we shot them
<mjg59> jdub: I have his number, if you don't?
<Hobbsee> Riddell: any idea why libgl1-mesa-dri isnt on the kubuntu cds?
<jdub> mjg59: yeah, i think i have an old one
<Hobbsee> ditto edubuntu, xubuntu?
<Hobbsee> ogra: ^
<pitti> hey jdub!
<Hobbsee> direct rendering doesnt seem tow ork on some graphics cards without it.
<jdub> yo pitti
<Riddell> jdub: could do, what would i say?
<pitti> mathiaz: ok, -profiles is in universe now
<jdub> thanks, sorting out with mjg59
<Riddell> Hobbsee: presumably nothing depends on it
<pitti> mathiaz: right
<Hobbsee> Riddell: i meant is there any ideological reason why we dont do it, apart from the obvious "because it's not in the seeds"
<mathiaz> pitti: excellent ! Thank you.
<Riddell> Hobbsee: not from me
<Hobbsee> Riddell: what about for the other flavours?
<Riddell> Hobbsee: I can't think why there would be
<Hobbsee> Riddell: ok, will add to all
<mathiaz> pitti: when will this change be reflected on the archive ?
<Riddell> Hobbsee: why do we need it?
<pitti> mathiaz: after next publisher run, thus in about 1:10 hours
<pitti> mathiaz: -profiles is still in main (still soyuz bug), FYI
<Hobbsee> Riddell:  3d for free HW.
<Riddell> Hobbsee: have you checked with bryce?
<Hobbsee> not yet
<Hobbsee> Riddell: it was on the ubuntu cds before
<Hobbsee> [00:35]  [Whois]  bryce has been idle for 14 hours, 13 minutes, and 38 seconds.
<Riddell> idle boy :)
<StevenK> pitti: Do you have a problem NEW'ing something if only i386 has built?
<mathiaz> pitti: ok. Is there anything else that needs to be done so that apparmor is included on the cds ?
<pitti> mathiaz: I need to rebuild ubuntu-meta, doing that now
<pitti> mathiaz: seed change committed
<pitti> StevenK: we usually don't do it
<StevenK> pitti: That's okay. Do you mind keeping an eye out for the rest of ode to hit NEW and accepting it, so I can deal with it's NBS relatives over the weekend?
<pitti> StevenK: ok
<StevenK> pitti: Thanks. :-)
<pitti> am I the only one who gets a lot of timeouts on LP?
<StevenK> I'm getting "Launchpad is offline" sporiadically, but not timeouts
<xxxxx1> pitti, nope
<xxxxx1> since yesterday
* StevenK wishes https://launchpad.net/ubuntu/gutsy/+builds could filter out certain arches
<pitti> mathiaz: ubuntu-meta uploaded with apparmor-utils love
<pitti> cjwatson: hmm, "apt-cache show restricted-manager|grep Task:" is still empty :/
<mathiaz> pitti: excellent. Thanks. :)
<cjwatson> pitti: yes, cron.germinate crashed because I screwed up
<cjwatson> (fixed)
<cjwatson> pitti: and in any event it takes two publisher runs for that sort of thing to land
<pitti> ah, ok
<cjwatson> cron.germinate runs at the end of cron.daily, and the resulting extra overrides are applied by the next cron.daily
<cjwatson> bit of a kludge
<pitti> StevenK: ode doesn't seem to be in NEW, it went straight in
<StevenK> pitti: Not even libode0debian1 or libode-doc
<StevenK> ?
<StevenK> I meant binary NEW, sorry, I should have said.
<pitti> StevenK: ah, wait, that was semi-auto-NEWed
<pitti> StevenK: since it comes straight from Debian
<StevenK> Semi-auto-NEW'd? :-)
<pitti> StevenK: I have a hackish script with generates overrides for packages that we sync from Debian
<StevenK> pitti: Ahh
<asac> pitti: can you look at midbrowser in NEW ?
<TeTeT> how can I add a debootstrap script/target for gutsy on a feisty machine?
<TeTeT> sorry, wrong channel, disregard
<cjwatson> TeTeT: feisty-backports, HTH
<Hobbsee> \sh: ping
<\sh> Hobbsee: pong
<Hobbsee> \sh: what's a nozumi device?
<Hobbsee> sorry, nozomi
<\sh> nozomi devices are umts cards e.g. from qualcom...especially highspeed utms cards..which are not handled by usb-serial
<\sh> Hobbsee: http://www.pharscape.org/content/blogsection/4/53/
<Hobbsee> cool
<\sh> Hobbsee: it's in ubuntu since feisty...and I think feisty was the first distro release with nozomi devices in...kppp patch was provided by me, included by riddell..
<Hobbsee> \sh: i see that, that's how i found you to poke :)
<\sh> so nothing new ;)
<Hobbsee> no, no. just asking debian if theyu want it
<Hobbsee> as it doesnt look distro-specific
<\sh> Hobbsee: afaik are those drivers not included in vanilla...the last time I checked (vanilla 2.6.22.1) I didn't see any config item for it
<\sh> off for now...cu next week :)
<pitti> asac: looking
<pitti> asac: oh, noes! yet another copy of mozilla??
<Hobbsee> pitti: they're spawning, taking over the world!
<pitti> asac: why does it contain a copy of cdbs-rules/debhelper.mk?
<pitti> asac: just thinking... firefox and midbrowser seem to be 99% identical (mostly branding changes); would it be possible to build both firefox and midbrowser from the same source, with two build trees?
* Hobbsee dies of shock
<asac> pitti: no
<asac> pitti: we have to live with mozilla copies till we can use xulrunner
<asac> pitti: currently its still pretty identical, but its a complete new "project" within the mozilla tree
<asac> and will diverge significantly on the mid-/long-run
<pitti> asac: why does upstream go through all this pain?
<asac> he?
<asac> pitti: we are upstream :)
<pitti> I mean, wouldn't it be much more sensible to factorize out the common bits and just build different UIs on top of it?
<pitti> or use --configure options?
<pitti> and keep just one tree?
<Burgundavia> isn't that what xulrunner is supposed to be?
<asac> pitti: yes we could do that for all applications that are in upstream CVS
<asac> however since security updates of different apps are out of sync we would get more frequent updates for all applications
<pitti> Burgundavia: yeah, that's a major part, I think
<pitti> asac: I don't understand?
<pitti> asac: with diverging copies of trees it certainly gets harder to maintain them also security-wise, not easier?
<asac> pitti: we can ship a source tarball with MOZ_CO_PROECJT=browser,mail,mailnews,calendar,xulrunner :)
<asac> e.g. one huge tarball ... and compile it multiple times
<pitti> right, that's what I meant
<asac> thats what i understood as your idea
<pitti> well, not much huger as they currently are
<asac> yes ... but now mail,calendar et al don't release in sync
<asac> for instance thunderbird was released today with a few more checkins then were in when firefox was tagged
<pitti> asac: what I meant was to have one mozilla.tar.bz2 as source package which is multibuilt once with configure --firefox and once with configure --midbrowser
<asac> yes ... but we would have to update the mozilla.tar.bzw whenever a midbrowser release comes out ... same for firefox release.
<pitti> and keep the differences as patches, or #ifdefs, or separate modules/UIs
<pitti> since 90% of the code will certainly stay identical anyway (like gecko)
<asac> pitti: we develop a new upstream project
<ion_> Is midbrowser the same thing as minimo?
<asac> its not minimo ... but its equivalent
<asac> pitti: in short: we cannot do it for the same reasons we cannot release thunderbird and firefox from one source tarball
<pitti> well, I understand that tbird and ffox are not in sync
<ion_> I dont seem to be able to find almost any information about midbrowser by googling.
<asac> ion_: its new :)
<pitti> but why midbrowser and ffox? it's both a browser which is based on the same code and engine?
<pitti> really, I'm fine with having 10 copies of mozilla code in universe, but moving them to main is just pretty much out of the question
<pitti> (not that fine actually, but I can live with it)
<asac> as i said ... atm we are pretty close to firefox ... when we are done with midbrowser we will be almost as far away as tbird
<pitti> right, I didn't doubt that
<pitti> but why make the same error again?
<asac> because the same reasons apply
<pitti> instead of keeping it modular or at least #ifdef'ed right from the start?
<asac> i don't want to loose the flexibility to release out of sync
<asac> pitti: tbird, firefox, midbrowser are already ifdef'ed properly
<asac> that was never the reason
<pitti> asac: an extra no-change firefox build is a small price to pay compared to the large amount of developer effort to keep both trees in sync
<iwj> Is there some document about ~ubuntu-main-sponsors that I'm missing, besides wiki.ubuntu.com/SponsorshipProcess ?  How do I claim a bug to say I'm dealing with it ?
<pitti> iwj: just assign it to you
<iwj> Many of these seem assigned to the submitters.
<pitti> iwj: most bugs should already be assigned, though
<asac> pitti: what large amount of developer effort?
<Hobbsee> iwj: there's little documentation.  just assign yourself anyway, the submitters are incorrect
<asac> pitti: only thing i see is diskspace
<iwj> Hobbsee: So I can reassign if the submitter isn't a core-dev ?
<Hobbsee> iwj: yep
<pitti> asac: to maintain the tree copies istead of maintaining e. g. xulrunner and the separate frontends, or just changing particular modules in the One True Tree
<iwj> OK.
<Hobbsee> iwj: seeing as they obviously cant further action teh bug, as they cant upload it
<iwj> Right.  IWBNI this was documented more clearly somewhere.
<asac> pitti: nobody doubts that its the right way to not-duplicate code once we *can* use xulrunner ... i only say: for now it makes really no sense
<pitti> asac: I still don't understand the reasons TBH
<pitti> asac: if we have almost identical trees, then it's certainly much easier to start developing midbrowser within the main tree?
<pitti> as opposed to, say, trying to reunite the trees for tbird and ffox, which already diverged a lot
<asac> pitti: tbird and ffox have not diverged
<pitti> they have separate origs, separate sources, separate release process  -- that's what I call 'diversion'
<pitti> but, I understand the reason for that one
<pitti> (well, it's not ideal either, a common library type of thing would be much better, but we can't have it right now)
<asac> pitti: the only reason we don't build things out of a single source is that we duplicate binaries anyway ... and that it just removes flexibility ... but it doesn't give us any benefit
<asac> to build from one source
<pitti> asac: what's the problem with duplicated binaries? these aren't problematic at all
<pitti> and of course we do want separate binaries
<asac> pitti: we have to wait till firefox 3
<pitti> I'm talking about a 'single patch fixes all browsers' kind of optimization
<pitti> not buildd time or so
<pitti> asac: ok, I did the first round of review; the .dlls crept in again
<asac> pitti: i will think about it
<asac> pitti: they have never been out
<pitti> gotta leave now, I'll continue with the review on Monday
<asac> except for iceape
<pitti> oh
* pitti files a tribe-4 bug
<asac> we already have a bug for that
<asac> its set to beta ... we repeat discussions
<pitti> hm, wasn't there one already?
<pitti> ah, ok
<pitti> I don't reject it yet, I'll complete the review first
<pitti> to collect issues
<asac> pitti: do a diff to the firefox orig
<asac> the rest is identical
<pitti> asac: that won't help me much, since I (or anyone else) never reviewed firefox for source NEW :)
<asac> ok
<asac> then have a nice weekend :)
<pitti> but it'll probably take me some more hours
<pitti> need to run now, sorry
<pitti> asac: thanks, you too!
<asac> no problem
<asac> its nothing to hurry for me
<asac> it was just Mithrandir who wanted that in asap
<pitti> sorry, but "ASAP" for 345 MB of code is just a while :)
<asac> sure
<micahcowan> BenC ping
<BenC> micahcowan: yo
<micahcowan> BenC hi :)  ...did you see my recent update re the kernel patch I submitted some time ago (SIGXFSZ)?
<micahcowan> It's in 2.6 mainline now
<BenC> micahcowan: yeah, I got it
<micahcowan> Is that enough to get it in for Gutsy, or do you want to see it in an official release?
<BenC> micahcowan: I'll evaluate it...probably can get it in, and just cherry pick from mainline
<micahcowan> BenC, cool thanks
<iwj> Hobbsee: So for example in bug 127121 what does Sebastian Droege's comment `ACK' mean ?
<ubotu> Launchpad bug 127121 in libdaemon "Please sync libdaemon (main) from Debian unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/127121
<iwj> slomo: AYT?
<iwj> slomo: What does your `ACK' in that bug mean ?
<Hobbsee> iwj: means that he's approving the sync
<iwj> I see.  That seems less than clear and he didn't assign it to himself ...
<Hobbsee> iwj: but, he hasnt subscribed the archive
<Hobbsee> iwj: please subscribe ubuntu-archive to that bug
<iwj> Also he has failed to subscribe ...
<iwj> Right.
<Hobbsee> slomo: please ensure that you actually subscribe ubuntu-archive to process sync bugs, else they'll never get found.
<Hobbsee> i believe you also subscribe u-m-s at that point
<iwj> YM unsubscribe.
<iwj> I would like to but I can't because I'm not a member of u-m-s yet :-).
<Hobbsee> iwj: the processes are all a bit of a WIP.  it's only been happening since my motu app, and we've only gone to more formal processes recently, with more people
<iwj> Right.
<iwj> I think writing this all up on the wiki page would be very good.
<iwj> Would you like to do that since you seem to actually know the answers ? :-)
<Hobbsee> iwj: not overly :P
<iwj> OK, I'll hack something up and we'll see who complains.
<Hobbsee> iwj: i'm just teh head of the universe one.  try getting persia to write it all up, as he's been doing it previously
<Hobbsee> oh, i'm not a u-m-s person either
* iwj edits SponsorshipProcess.
<Hobbsee> iwj: i could have - however, i do want to go to bed bfeore 3am.
* Hobbsee thinks lifeless is right.
<iwj> You're subscribed to SponsorshipProcess, right ?  Then you can read my edits in the morning.
<Hobbsee> iwj: dont think so.  but i'll look at some point
* Hobbsee has relatives over soon, so....
<Hobbsee> cant do much ubuntu stuff this week, unfortunately
<Hobbsee> good thing there's no tribe release :P
<elkbuntu> Hobbsee, you'll have to keep 'normal' hours too, i suppose :
<Hobbsee> elkbuntu: yeah.  dunno what they are.
<Hobbsee> i'm going to die of horror, i swear...
<elkbuntu> Hobbsee, the shock. the horror!
<Hobbsee> exactly
* Hobbsee hasnt gone to bed before 11pm in a good couple of years....
<elkbuntu> heh. anyway, since it is approaching 3am. i might go reaquaint myself with my pillow. gnite
<Hobbsee> hehe, night
<bSON> hi
* Hobbsee --> bed.  night all!
<iwj> dholbach: Ah, thank you :-).
<dholbach> iwj: thank YOU! :)
<dholbach> iwj: I wrote a small script to generate an overview of the tracked sponsoring bugs at: http://daniel.holba.ch/sponsoring/
<iwj> Oo.
<dholbach> iwj: it's by no means perfect yet and still has some bugs (which will be fixed in one of the next releases of python-launchpad-bugs), but I hope it'll help
<iwj> Shall I add a reference to that to wiki.ubuntu.com/SponsorshipProcess ?
<dholbach> good idea - I'll add it to http://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews
<dholbach> announce it and move it to people.ubuntu.com once I'm back from my holidays
<iwj> Right.
<jwendell> kylem, around?
* mode/#ubuntu-devel [+o Hobbsee]  by ChanServ
* mode/#ubuntu-devel [+b %*!*@88.203.73.158]  by Hobbsee
* mode/#ubuntu-devel [-o Hobbsee]  by ChanServ
<LaserJock> anybody know if X-Ubuntu-Gettext-Domain is supposed to be set to the source or binary package?
<LaserJock> cjwatson: got a minute?
<Hobbsee> LaserJock: i think he's left for the day
<LaserJock> ah
<LaserJock> why don't people have the same TZ as me? ;-)
<Hobbsee> haha
<calc> because mine is the only correct one
<Hobbsee> TZ's suck
<calc> 8D
<Hobbsee> speaking of bed, i'm going to actually attempt to sleep this time
<zul_> hah
<LaserJock> Hobbsee: do it!
<Hobbsee> LaserJock: well, i'm in bed now - is that close enough?
<LaserJock> no, I know that trick
<jdong> take a laptop
<LaserJock> you gotta have the laptop off
<jdong> and a plug...
<Hobbsee> you know the logic about having to write down a whole lot of stuff, else you keep thinking about it, and never get to sleep?
<Hobbsee> jdong: i have reasonable battery life...
<jdong> Hobbsee: oh that's even worse!
<Hobbsee> hehe
<kevinl-1> hey guys, i see that this isnt a support channel, so i apologize if i am asking in the wrong place, but I cannot get ahold of anyone who can help me in the #ubuntu channel, and Dennis Karrsmarker is apparently on leave from ubuntu (not that he wouldnt be too busy to help me anyhow)
<kevinl-1> my issue is regarding usplash. I have been trying to compile it with a custom theme, and utilize it on an etch-based debian-live system (casper, etc)
<kevinl-1> ive found however, that i have had very little success even compiling usplash/usplash-theme-ubuntu and getting it to work properly
<kevinl-1> errors ranging from: unresolved symbol pixemap_throbber_back , to cannot open /deb/fb0
<kevinl-1> i once had it running on my live cd , but only is black and white with a screwed up progress bar
<kevinl-1> id like to just base my theme directly off of usplash-theme-ubuntu, compile it all on etch and have it work
<kevinl-1> but i wonder if there is a mismatch or difference in some of the dev libraries between etch and ubuntu that cause some weirdness.
<kevinl-1> any help is appreciated, thanks
<mathiaz> keescook: Did you have to a chance to look at my new apparmor packages ?
<tormod> Is there a defined policy or specification on what laptop-mode-tools and gnome-power-manager and acpid should do on laptops?
<keescook> mathiaz: not yet, still feverishly trying to finish the ubuntulive presentation.  :)
<mathiaz> keescook: ok. np.
<mathiaz> keescook: pitti moved apparmor into main this morning
<keescook> sweet!!
<bryce> I'm running into several packages named thusly:  libxext-1.0.3-1build1
<bryce> I'm wondering why 'build' instead of 'ubuntu'
<tormod> ... https://wiki.ubuntu.com/EnableLaptopPowerFeatures is pretty empty
<bryce> from an email from pitti I gather this is when there have been no changes to the package, however can someone point me at some docs explaining this more completely?
<bryce> I've got half a dozen packages named this way and I want to be sure when merging that I name them correctly.
<LaserJock> bryce:  a build1 is for packages that just need a rebuild
<LaserJock> the source isn't touched
<LaserJock> so that when we auto-sync from Debian they get synced automatically rather than put in the merge queue
<bryce> ah, ok
<kylem> 44
<wolfe> kylem: is that the answer to the universe?
<Whelpo> isn't that 42?
<jdong> Whelpo: not after yesterday's security patches.
<Whelpo> what do yesterday's security patches have to do with the answer to the universe?
<jdong> Whelpo: they found a buffer overflow with the universe in the 42 accessor...
<jdong> Whelpo: they tried the 43 accessor but it had shell escape issues...
<jdong> hence it's 44 now.
<jdong> if apparmor profiles for the universe start working properly, then we may revert back to 42 for compatibility reasons
<kevinl-1> what run level is executed when the system is shutdown or rebooted? 0 ? S ?
<kevinl-1> oops, wrong channel :)
<kevinl-1> im sure you guys know though!
<geser> Hi LaserJock
<LaserJock> hi geser
<jdong> kevinl-1: 0 for shutdown 6 for reboot
<jdong> S is basic startup
<bdmurray> Has seamonkey ever been packaged?
<geser> !info iceape
<ubotu> Package iceape does not exist in feisty, feisty-seveas
<geser> !info iceape gutsy
<ubotu> iceape: The Iceape Internet Suite. In component universe, is optional. Version 1.1.1+u2-0ubuntu1 (gutsy), package size 28 kB, installed size 84 kB
<geser> it's in gutsy
<jdong> backport?
<jdong> :D
<LaserJock> jdong: that reminds me, is it possible to backport emacs22?
<bdmurray> Somebody submitted a bug report about seamonkey in Edgy.  I was trying to figure out if we shipped it or not.
<jdong> http://sharkattack.media.mit.edu/inventory/view_log/27
<jdong> *shrug* there goes nothing :D
<jdong> LaserJock: good question :)
<jdong> LaserJock: if it builds then sure
<geser> bdmurray: edgy should have the old mozilla suite, but I wouldn't suggest someone to install it
<keescook> evand: do you know of a way to import .ics files into evolution from the commandline?
* evand uses mutt
* evand off to VA for the weekend.  Enjoy your weekend, everyone.
<keescook> right, someone sent me an ics file, and I want through throw it at the evolution calendar.  :)
<keescook> cya
<Burgundavia> keescook: get the one off the fridge
<evand> oh, right, calendar
<evand> no idea
<evand> sorry
<keescook> Burgundavia: ?
<Burgundavia> fridge has a calendar of events
<keescook> Burgundavia: right, I use that.  I want to take an ics file someone sent me and import it from the command line (i.e. an automatic way to import meeting requests I get from other ics-capable clients) via mutt
#ubuntu-devel 2007-07-21
<stgraber> mathiaz: thanks for the list, I'll assign them right now
<mathiaz> stgraber: thanks
<mathiaz> stgraber: is there any admin interface ?
<stgraber> mathiaz: not yet
<tormod> mjg59: can you please review the patch in bug #127276 ?
<ubotu> Launchpad bug 127276 in laptop-mode-tools "laptop-mode init script links not created (dup-of: 127273)" [Undecided,New]  https://launchpad.net/bugs/127276
<ubotu> Launchpad bug 127273 in laptop-mode-tools "laptop-mode init script links not created" [Undecided,New]  https://launchpad.net/bugs/127273
<mjg59> laptop-mode is going away
<tormod> mjg59: good to know!
<tormod> mjg59: do  you think the patch would be valid for those using laptop-mode in Feisty?
<mjg59> laptop-mode is an error
<tormod> it slipped into Feisty though...
<mjg59> Oh, and various earlier releases
<mjg59> The best we can hope for is that it never manages to turn itself on
<tormod> It's default off in /etc/default so that should be no problem.
<persia> Is laptop-mode-tools also scheduled for removal?  Is it now replaced by ubuntu-laptop-mode?
<tormod> Will it be demoted into Universe? In which case it should be patched.
<mjg59> Yeah, that's the plan
<thunderbolt> Hmm... I remember there was some discussion on the wiki at one time about putting the /etc/ folder (and potentially others) under revision control, either bzr or svn. I've found a userspace filesystem, called wayback, that allows for keeping a history of files... Does anyone else think that this may be a good idea, assuming that someone [me]  can implement it?
<jdong> thunderbolt: I've played with versioning the entire /etc with bzr
<jdong> it worked marginally except for some permissions mishandling sometimes
<thunderbolt> jdong: worked marginally?
<jdong> I find it smarter to selectively version things
<jdong> thunderbolt: yeah...
<jdong> thunderbolt: bzr and svn both create dot directories
<jdong> like .bzr or .svn
<thunderbolt> Ah.
<jdong> and some scripts go BALLISTIC over that
<thunderbolt> Yes, that's right.
<jdong> and not just that...
<jdong> sometimes when reverting, things go back with wrong permissions
<thunderbolt> Eep.
<jdong> yeah...
<thunderbolt> That's really not good.
<jdong> it did get a bit nasty
<jdong> but I do it for some specific things
<jdong> like my /etc/acpi is under bzr
* thunderbolt nods
<jdong> because I find myself hacking my acpi-support a lot
<jdong> and it doesn't seem to get bothered by .bzr
<thunderbolt> Cool.
<jdong> apache's a good choice too
<jdong> basically anything that took time for you to write, and you continue to tweak :)
<jdong> don't version the entire /etc
<jdong> because you have to deal with things like /etc/gconf
<jdong> which seem to change with every other package upgrade :D
<thunderbolt> Hehe
<thunderbolt> The other feature I was looking into was something like VMS's holding history of files, for like a users home directory.
<jdong> ah
<jdong> I think some LVM-ish snapshot magic is probably your best bet for that
<thunderbolt> LVM?
<jdong> Logical Volume Manager
<thunderbolt> Ah
<jdong> amongst other things, it allows you to take snapshots of devices
* thunderbolt nods
<jdong> and they only take up space as content diverges
<jdong> so you can basically snapshot your /home every night
<jdong> and save those snapshots
<jdong> and purge 30-day-old snapshots...
<thunderbolt> Right.
<jdong> to maintain reasonable space
<jdong> then you can at least recover 30 days back should your users request it
* thunderbolt nods
<thunderbolt> I still think it would be nice to have a backup, at least for a while, whenever a file is saved, but I guessed that's handled by application level undo, right?
<jdong> right
<jdong> I've seen some userland filesystem overlays that promise these kinds of features
<jdong> but remember that those things probably make you worse off anyway
<jdong> just because they haven't had rugged testing
<thunderbolt> Yeah, that was my concern. I've looked at FUSE and Wayback, which is built on FUSE.
<jdong> it'd be a really awful twist of fate if your backup mechanism caused data loss :D
<thunderbolt> Yes, definitely.
<thunderbolt> Hmm, one of those nice things to have if we had infinite resources and time, right?
<jdong> yeah, certainly :)
<jdong> backup solutions are tough... very few resources on how to do it properly
<jdong> and one of the sketchiest things to experiment with :)
<jdong> as I said before, I'd recommend version control for /etc and investigating LVM snapshots for /home
* thunderbolt nods
<thunderbolt> Thanks a ton, jdong!
<jdong> no prob
<thunderbolt> Currently I'm using backuppc for my users home directories, it's kind like the snapshots, but uses rsync.
<jdong> right
<jdong> that works too
<jdong> but it tends to have higher overhead
<jdong> i.e. slower to run, takes up more space
<thunderbolt> Yeah, definitely, I also use it to backup some windows PCs.
<jdong> yeah, that's the advantage of a FS-level backup
<thunderbolt> I also didn't know about LVM until you told me about it :)
* thunderbolt nods
* Hobbsee waves
<siretart> asac: can you please have a look at https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/112818,
<ubotu> Launchpad bug 112818 in firefox "wrong pkgconfig dependencies break builds" [High,Confirmed] 
<asac> siretart: yes firefox-nspr and firefox-nss.pc should become links to nspr.pc and nss.pc
<asac> ... or should be completely dropped
<blowfish> hi
<wattazoum> hi
<wattazoum> need a little help on a very basic question : is there a way, in python, looking at a directory, to see if a file inside has changed ?
<Spads> well that's OS dependent
<RAOF> wattazoum: Yes, but this isn't the place to ask :)
<wattazoum> I used "lstat()" and looked at st_mtime but it seems this doesn't change
<Spads> but in the os module you should be able to do a stat on all files and grab the mtime
<Spads> oh wow, totally not the channel I thought i was in
* Spads reorders his irssi channel numbers
<wattazoum> RAOF :  in which place should I ?
<Spads> wattazoum: try #python
<RAOF> wattazoum: Well, possibly ##python?
<wattazoum> #python
<wattazoum> I can't go there ( I lost my nickname password and can't identify :'( )
<RAOF> wattazoum: For an Ubuntu responce, check out the source of Specto, which has a file/folder watch
<wattazoum> RAOF : Cool
<wattazoum> i'll lok at it
<wattazoum> look
<RAOF> NP
<_wattazoum_> Thank you very much
<_wattazoum_> RAOF : just for info, I have looked at the specto code and it does exactely what I would have liked to avoid. watching every last file inside
<_wattazoum_> I guess I have no choice then
<_wattazoum_> :)
<RAOF> If you only care about notifications when your program is running, and don't mind being linux-only, inotify is really easy in python.
<_wattazoum_> well, I actuallly use it :-) , It was just for a matter of performance ( I am developing a backup software and this was to check if I could skip the whole dir when it didn't changed ) .
<_wattazoum_> yep I don't care being linux-only :)
* Hobbsee waves
<jdub> canonical folks handy?
<Hobbsee> all eaten.
<jdub> not useful, need help
<Hobbsee> jdub: seriously though, it's the weekend.  and ubuntulive
<jdub> and my plane has been delayed, and i need to get a message through
* jdub has a fair amount of understanding of the context of his question
<Hobbsee> who to?
<jdub> a canonical person on uk time
<jdub> if there were one here a momeont ago, you could mention their nick instead of drilling me qith questions
<Hobbsee> jdub: havent seen any here in hours, to be honest.  :(
<StevenK> jdub: The only one I've seen that that is likely is Spads, and he last spoke over 5 hours ago
<jdub> StevenK: thanks
<AlinuxOS> doko, hello ;)
<Kmos> LP is back
<jdong> urgh, fglrx performance has definitely regressed on gutsy
<jdong> what a surprise :)
<Kmos> jdong: backport ddclient in gutsy to feisty
<Kmos> thx
<ScottK> jdong: About iceape, whatever floats your boat.
<jdong> Kmos: you do it :P
<jdong> lol
<Kmos> :)
<jdong> what's ddclient
<jdong> a dyndns thing?
<Kmos> yes
<Kmos> u've done the last backport
<Kmos> https://launchpad.net/ubuntu/+source/ddclient
<jdong> http://sharkattack.media.mit.edu/inventory/check_builds/28
<jdong> ok, building
<Kmos> jdong: that was fast :) thanks
<ScottK> jdong: One thing I've been thinking about for Dapper is if we could backport dpkg from Edgy to Dapper we could save a LOT of source backports.
<jdong> ScottK: is that remotely safe?
<ScottK> jdong: I have no idea.
<ScottK> I think it needs some discussion.
<jdong> ScottK: I'd be willing to do it if it were safe
<Kmos> jdong: SUCCESS
<Kmos> :)
<jdong> Kmos: cool
<jdong> Kmos: can you test the packages?
<jdong> IIRC it ships with an init script which could've changed
<ScottK> jdong: I think we need to discuss it with some of the core developers during the week.
<Kmos> it should work fine
<Kmos> but i can test it
<jdong> Kmos: I don't like hearing should :)
<ScottK> should != does
<Kmos> i've running the gutsy version on my feisty
<Kmos> with no problems
<Kmos> that's enough ? :)
<jdong> Kmos: ok good enough...
<Kmos> :)
<Kmos> jdong: thx
<jdong> Kmos: bug 127430
<ubotu> Launchpad bug 127430 in feisty-backports "backport ddclient" [Undecided,In progress]  https://launchpad.net/bugs/127430
<Kmos> jdong: nice :)
<Kmos> thanks
<jdong> yay sharkattack :)
<Kmos> i assigned the bug to you
<Kmos> no problem ?
<jdong> no need to assign
<jdong> it's done
<Kmos> :)
<jdong> archive admins are subscribed
<Kmos> yeah
<Kmos> but you do the work :P
<Kmos> jdong: http://sharkattack.media.mit.edu/inventory/view_log/32
<jdong> mmm?
<Kmos> firefox grandparadiso
<jdong> yeah
<jdong> it builds properly
<jdong> but takes a few hours
<Kmos> it was 0 in # builds
<jdong> right
<Kmos> i clicked in queue
<jdong> I purged out stale builds last night
<Kmos> :)
<jdong> I restarted the builder during testing while it was building
<Kmos> ah, that's the problem
<jdong> that builder really needs some ionice loving
<Kmos> pkg-source: applying ./firefox-granparadiso_3.0~alpha5-0ubuntu2.diff.gz
<Kmos> Fetched 34.5MB in 23s (1475kB/s)
<Kmos> cat: write error: Broken pipe
<Kmos> cat: write error: Broken pipe
<Kmos> cat: write error: Broken pipe
<Kmos> cat: write error: Broken pipe
<Kmos> cat: write error: Broken pipe
<jdong> that's normal
<Kmos> dch warning: new version (3.0~alpha5-0ubuntu2~7.04prevu1) is less than
<Kmos> the current version number (3.0~alpha5-0ubuntu2).
<Kmos> ah ok
<jdong> stop pasting that :)
<Kmos> ok
<jdong> the way it grabs version numbers from the changelog
<jdong> it closes stdout before cat is done
<Kmos> :)
<jdong> yay to hackish code :)
<a-865> can gutsy be installed to a partition above #15 ?
<a-865> The ext3 filesystem creation in partition #19 of SCSI1 (0,0,0) failed.
#ubuntu-devel 2007-07-22
<keescook> jdub: /msg me if you still need to get a message through to canonical folks
<mercurysquad> hi everyone, I'm trying to register a new spec but I keep getting a "Oops"
<mercurysquad> is this temporary or do I need some privileges to be able to register a spec ?
<cypherbios> mercurysquad: Most likely temporary, but if you want you can file a bug against Launchpad or bug them on #launchpad :)
<mercurysquad> hmm I'll try again later, thanks!  the wiki page is already written, just have to register it in launchpad
<manchicken> Any of the debtags folks around?
<MichealxRock> hello.
<MichealxRock> I am making somthing in Blender, and I need a suggested chatroom. I'm 12. and I am trying to get some questions answerd on a #D firt person shooter I am making
<chowmeined> #blender
<jdub> keescook: still there?
<Hobbsee> morning all
<ScottK> Good morning Hobbsee.
<wasabi> good howdy
<Hobbsee> ScottK, wasabi :)
<BirthdayHobbsee> uh...no one's related anything that would break adept, would they?  i cant see anything likely looking on gutsy-changes
<BirthdayHobbsee> enrico: ping
<minghua> libept breaking adept?
<BirthdayHobbsee> yeah, i've found it
<BirthdayHobbsee> i'm now pondering whether we should update the version of debtags - we reverted back to the old lot for t2, as a workaround.
<BirthdayHobbsee> because our libept wasnt ported, iirc
<BirthdayHobbsee> ah, wait, we have actually gone to the new debtags now
<BirthdayHobbsee> cool :)
<BirthdayHobbsee> then unping enrico
* BirthdayHobbsee looks around for someone to do a giveback.
<BirthdayHobbsee> pity it's sunday
<TheMuso> BirthdayHobbsee: Its your birthday? If so, happy birthday then.
<BirthdayHobbsee> TheMuso: nope, i'm just doing this to throw people :P
<jetscreamer> happy non-birthday
<BirthdayHobbsee> :P
<elkbuntu> oh cute. i wonder if that was why i wasnt getting any updates... main, universe, restricted and multiverse are all unchecked in the 'software sources' dialog after a dist-upgrade
<minghua> elkbuntu: Won't all installed packages be labeled as "untrusted" then?
<hunger> I get lots of "hub 1-0:1.0: over-current change on port 2" messages in the kernel's log nowadays. Any idea what might be wrong? Should I write a bugreport about it?
<hunger> Lots as in 1 every second or so.
<hunger> Going up to 8 per sec. at times.
<jwendell> Hi, pitty
<jwendell> around?
<jwendell> pitti ^
<StevenK> pitti: I have an evil plan in progress, and it isn't NBS!
<pitti> StevenK: oh?
<StevenK> pitti: Yes. I have designs on booting yada out of main like the bitch that it is...
<pitti> StevenK: yay!
<StevenK> pitti: The diffs end up looking a little large, though.
<StevenK> pitti: I will be submitting patches to the Debian BTS, so, here's hoping ...
<pitti> StevenK: I guess you turned the build systems upside down? :)
<StevenK> Let's say I prefer a readable 18 line debian/rules using CDBS than an unreadable 300 line mess that uses yada.
<thom> StevenK: i nearly agree that using cdbs rather than yada is an improvement
<thom> but they're both unreadable
<pitti> StevenK: *wholeheartedly agree* :)
<StevenK> thom: Shall I paste examples? *evil grin*
<StevenK> pitti: Well, I did have a question, which was, can we deal with a large diff if it helps us get rid of yada?
<pitti> StevenK: depends on whether it'll eventually go into Debian, whether the Debian package changes very often (so that we have to constantly reflect the changes), etc.
<pitti> StevenK: it's three pacakges AFAICS: libapache2-mod-auth-{plain,pam}, libnss-db
<StevenK> I doubt they change very often, and as I said, I'll be submitting patches along the lines of "yada is a *pox*"
<StevenK> pitti: *nods*, I have a list for main and universe.
<broonie> People have been muttering about doing the same thing in Debian.
<StevenK> vorlon mentioned the death of yada was an unoffical lenny release goal .... :-)
<thom> the apache modules look pretty irrelevant anyway right now
<thom> neither will work with apache 2.2
<pitti> thom: oh, so we should demote them then?
<StevenK> And yet they {Build-,}Depends on it
<StevenK> If you demote it, I'll look at ripping yada off of libnss-db.
<StevenK> s/it/them/
<StevenK> Since my first step was getting yada out of main.
* StevenK blinks. 
<StevenK> Since when does perl need to be listed in Build-Depends ...
<thom> someone seems to have blindly NMU'd them with a changed dep, but no actual changes
<pitti> thom: is that known/handled in Debian?
<thom> the authn/z system in 2.2 is totally different to 2.0
<pitti> StevenK: perl-base is essential, but not perl
<thom> pitti: there're certainly bugs filed
<geser> btw apache2: the last upload to debian fixed two CVEs. Is it ok to sync it as this upload also split the default configuration into several files?
<StevenK> pitti: Ah. Point.
<thom> geser: they're reasonably trivial changes tbf
<StevenK> pitti: Yeah, 184 packages in main Build-Depends on perl, so it stays. :-)
* StevenK digs through libnss-db's debian/packages file, sobbing
<thom> StevenK: why not just repackage from scratch?
<geser> thom: I've read "This version introduces some changes in the configration layout and defaults. You will probably have to adjust your configuration accordingly." in debian/NEWS
<StevenK> I take bits from it, like the copyright, and to see what the current {post,pre}{inst,rm} do.
<geser> and I don't know if it's still ok to include such a change into a package in main
<StevenK> Except in libnss-db's case.
<StevenK> Copyright: GPL
<StevenK>  Copyright (C) 2000, 2001 Free Software Foundation, Inc.
<StevenK> That's the whole bit.
<pitti> geser: it is
<geser> pitti: thanks, will file a sync request
<pitti> geser: independent of the release status, such changes should not break existing configurations on upgrades anyway; do they?
<thom> geser: yeah, i just read the changes and they look reasonably safe
<geser> it checks the md5sum of the oldconfig files and exchanges them only if they are unmodified
<pitti> geser: ah
<infinity> StevenK: Are you de-yadaing libnss-db?
* StevenK nods.
<infinity> StevenK: Yay!
* StevenK grins
<infinity> I'm trying to decide if a 24-hour layover in LAX is a good time to work, or just a good time to complain about the evils of intercontinental travel.
<StevenK> Ouch
<StevenK> And I thought the five hours I spent walking around Singapore airport was bad enough.
<infinity> I blame TFL.
<infinity> Two hours' worth of delays on the Piccaddily line led to me missing my first flight, and it's been all downhill from there.
<StevenK> Oh. Neat.
<geser> Can someone please ACK bug #127537? Thanks
<ubotu> Launchpad bug 127537 in apache2 "[Sync request]  Sync request apache2 (2.2.4-2) from Debian unstable (main)" [Undecided,New]  https://launchpad.net/bugs/127537
<StevenK> src/Makefile.am: required file `./depcomp' not found
* StevenK scratches his head.
<mpech> re
<mpech>  which part of ubuntu uses python and needs help for testing and programming ?
<ScottK> mpech: Python is the preferred language for development of Ubuntu specific tools, so the general answer is lots of it.
<mpech> yeap
<ScottK> What are your interests?
<mpech> testing (black box) and source audit (C, Python)
<[swb] > hello all
<ScottK> Hello [swb] 
<[swb] > hi ScottK
<[swb] > I have a sort of feature request
<[swb] > or a request for information on how to achieve such a feature
<[swb] > http://ubuntuforums.org/showthread.php?t=117027
<[swb] > I have thought ubuntu has been missing this for a while now
<ScottK> mpech: If you are interested in testing, you ought to consider running Gutsy on a test machine/parition.  There are Ubuntu wiki pages describing needed tests.
* ScottK looks
<[swb] > but have not seen anything about it on the internet since this post
<unix4me> Hi. Is this a place to talk about feature requests?
<[swb] > I am fairly proficient with python, but have not written anything involving UIs or with gnome/nautilus
<[swb] > unix4me, I am talking with ScottK about it
<ScottK> [swb] : I would expect that a feature like that would best be addressed with Gnome upstream.
<[swb] > #gnome then?
<unix4me> I think so.
<ScottK> This is actually a better place for discussing work on development of Ubuntu, feature requests are best addressed through development of Blueprints/Specifications.
* ScottK uses Kubuntu, so has no idea how to deal with Gnome devs.  Sorry.
<unix4me> is there a room for that?
<ScottK> unix4me: It's done through Launchpad.
<unix4me> ok
<mpech> ScottK, whats URL for this wiki page ?
* unix4me is still learning C, and doesn't really know what a "preprocessor" is... :P
* unix4me just began yesterday.
<IntuitiveNipple> unix4me: Its the stage when MAKE expands all the macro definitions and such
<ScottK> mpech: I'd have to search.  Do a title search on wiki.ubuntu.com.  If you don't find something let me know and I'll look if I'm still here.
<unix4me> thank you.
<StevenK> Can someone with some autobork clues tell me how I can get it to recreate the 'depcomp' file?
<ynezz> ./autogen.sh
<ynezz> (usually)
<StevenK> No ./autogen.sh, sadly
<ynezz> aclocal, automake -a, autoconf (one of theses)
<ynezz> i don't know which of these create depcomp exactly :)
<mpech> ok
<StevenK> automake --add-missing does, thanks for the hint.
* StevenK sighs at autobork, and his lack of clue about it.
<pkern> What's the policy for packages propagating from universe to the core?
<zul> main/
<StevenK> They need a MIR filed out, and more importantly, a good reason.
<zul> er main?
<infinity> pkern: It needs to pass some criteria (a main inclusion report), but mostly, weneed to want to support it.  If we're not going to ship it and support it, we don't really want or need it in main.
<infinity> pkern: There's no particular shame in one's pet package being in universe (heck, I've worked for Canonical for years, and I have Debian packages in universe)
<StevenK> infinity: Do you have autobork skills to share and a little time? It's for a good cause. :-)
<pkern> infinity: The package was once in main but was dropped AFAIK mainly for having Howl in the dependency list, which is now fixed.
<infinity> StevenK: I'm not all that keen on causes, good or otherwise, 7 hours into my 24 hours of airport bitter.  But shoot anyway.
<StevenK> infinity: Ah. The cause being an upload of libnss-db that builds, and leads to yada being demoted.
<infinity> StevenK: SOLD.
<infinity> StevenK: What's the problem?
<infinity> pkern: We've dropped a lot of stuff from main just because we don't like to bloat the supported list, too...
<StevenK> infinity: It doesn't currently build using CDBS and the autotools class set runs the tools and I get './depcomp' not found, which it isn't. I can forcibly create it with automake --add-missing, but anything more than that and I'm just guessing.
<StevenK> infinity: That sentence is a mess. :-(
<infinity> I don't do CDBS...
<infinity> ever.
<StevenK> Hrm.
* thom ^5s infinity 
* StevenK ponders just switching to straight debhelper and dealing.
<infinity> Moving from Yada to CDBS is likemoving from dating a COBOL hacker to a C hacker... Sure, you may be moving up in the modern world, but you're still dating a programmer.
<StevenK> Personally, I don't see that as a bad thing ... :-)
<infinity> Well, you've moved from dating dexter to group sex with Colin Walters, dilinger, and jbailey.  How's that?
<StevenK> I think I need to scrub so hard that I'll bleed.
<thom> you could use DBS and just fellate doogie
<StevenK> Then again, what do you class debhelper, as? :-P
<StevenK> MY EYES!
* StevenK slaps thom
<infinity> debhelper involves stroking joeyh's beard lovingly.
<infinity> You could do worse, I guess.
<StevenK> Heh. Last time I saw joeyh, he was beardless
<infinity> *shock*
<infinity> Did you notice his hacker-fu had died along with it?
<StevenK> Not really, he was doing serious d-i hacking
<StevenK> (This being at Debconf in Finland)
<infinity> Anyhow, straight dh_make would make me happier, if I was the one who was going to review it and help mangle breakages.
* StevenK nods.
<infinity> And since I have a vested interest in libnss-db (ud-ldap), I might care.
<StevenK> I'm currently shoehorning debhelper in.
<infinity> It's also a simple enough package, that going debhelper-free would be an option too, though overkill.
<pkern> https://wiki.ubuntu.com/MainInclusionReportGobby <-- There's even an old one that got approved back then. \:
* infinity wonders how that extra comma slipped in there.
<infinity> I'm developing German English punctuation.
* infinity shakes his fist randomly at doko and pitti.
<doko> infinity: ?
<infinity> doko: Oh, just complaining that you're ruining my English punctuation.
<infinity> doko: Nothing actually relevant, you can go back to lurking.
<doko> infinity: I didn't edit anything for gobby, why should I?
* StevenK kicks libnss-db.
<StevenK> Oh wait, I'm not applying patches.
<infinity> doko: Err.  What?  I wasn't talking about you and gobby together in any way.
<IntuitiveNipple> Where's all the kernel build experts?
<Kmos> IntuitiveNipple: tomorrow
<Kmos> !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.
<IntuitiveNipple> um, thats me you're referring to :)
<StevenK> infinity: Gah, now it all blows up at the end of ./configure.
<StevenK> Actually, no, it cd's into src and runs automake
<infinity> StevenK: Timestamp skew?
* StevenK sighs, looking at the autoconf mess in debian/packages
<StevenK> aclocal-1.9 -I m4
<StevenK> aclocal: couldn't open directory `m4': No such file or directory
* StevenK sighs
<_wattazoum_> Hello there
<Amaranth> StevenK: what package is that?
<ScottK> Amaranth: It's libnss-db
<Amaranth> ok, thanks
<Amaranth> now i know to stay far away
<FireRabbit> howdy from ubuntu live!
* ogra hugs cjwatson, thanks for the edubuntu intersection stuff :)
#ubuntu-devel 2008-07-14
<emgent> hello
<NCommander> Is there anyone here who can issue a give-back on a package in intrepid?
<LaserJock> NCommander: what package is it?
<NCommander> LaserJock, logwatch
<LaserJock> NCommander: why does it need to be given back?
<NCommander> LaserJock, it successfully builds on amd64 without changes in both pbuilder and sbuild (checked on two machines), If it fails again, then it appears its something in the buildd's chroot jail (possibly a misset permission) that triggered the original FTBFS
<LaserJock> NCommander: ok, retrying amd64
<NCommander> LaserJock, thanks
<LaserJock> NCommander: still fails, perhaps a buildd admin needs to be consulted
<NCommander> how do I contact them
<LaserJock> NCommander: well, asking here during European business hours (i.e. Monday) might work
<nxvl> popey: around?
<pitti> hunger_t: hm, the bug is marked 'pending' in Debian, so I guess there is some race condition in the build
<pitti> Good morning
<jpds> morning
<jr_> asac: svn://anonsvn.kde.org/home/kde/branches/work/knetworkmanager/
<jr_> asac: http://kubuntu.org/~jriddell/tmp/knetworkmanager.tar.gz
<stgraber> moin
<asac> hi stgraber
<hunger> pitti: yeah, you are right. It does build on my system but breaks in the build env. I updated the bug accordingly.
<cjwatson> slangasek: http://people.ubuntu.com/~cjwatson/tmp/recommends-by-size
<cjwatson> lool: please upgrade germinate before updating ubuntu-meta again; thanks :)
<Keybuk> bryce: when you've got a moment ...
<Keybuk> ... could you fix my X server?! :)
<cjwatson> lool: (you added all the essential stuff back to minimal, which had been intentionally removed)
<slangasek> cjwatson: right, so I upload anacron, and then I notice bug #244018 :)
<ubottu> Launchpad bug 244018 in anacron "cron fails for non-root users if no mail program is installed" [Undecided,New] https://launchpad.net/bugs/244018
<slangasek> do we have a trivial MTA in main that we could pull in, instead of postfix?
<Riddell> asac: kubuntu.org/~jriddell/tmp/admin.tar.gz
<bryce_> Keybuk: what's the problem?
<Keybuk> bryce_: compiz just gives me a white screen
<bryce_> ahh
<bryce_> intel graphics?
<Keybuk> yes
<bryce_> right, compiz is busted on -intel presently
<bryce_> known issue I'm working with Intel on, but no solution or workaround at the moment
<bryce_> gfx will work ok with compiz off, although that probably doesn't help you much...
<bryce_> Keybuk: let me dig up the bug id's to see what patches are available
<jcristau> bryce_: http://bugs.freedesktop.org/show_bug.cgi?id=mesa-7.1 points to 14441
<bryce_> 14441 and 15477
<bryce_> there is a patch on 15477
<Riddell> asac: http://kubuntu.org/~jriddell/tmp/knetworkmanager.tar.gz
<bryce_> http://bugs.freedesktop.org/show_bug.cgi?id=14441
<ubottu> Freedesktop bug 14441 in Drivers/DRI/i965 "Compiz shows only black screen on i965" [Normal,Assigned]
<bryce_> http://bugs.freedesktop.org/show_bug.cgi?id=15477
<ubottu> Freedesktop bug 15477 in General "full screen is white when use compiz" [Normal,Resolved: fixed]
<Riddell> asac: https://edge.launchpad.net/ubuntu/+source/dbus-1-qt3
<bryce_> tjaalton: any reason we can't put in the patches for 15477?
<jcristau> bryce_: 15477 is fixed upstream (and in experimental) fwiw
<mdz> Setting up xfonts-base (1:1.0.0-5) ...
<mdz> FATAL: Could not load /lib/modules/2.6.26-3-generic/modules.dep: No such file or directory
<mdz> xfonts-base: and why should you care?
<pitti> mdz: modprobe truetype?
<pitti> nicer printks :)
 * slangasek peers at pitti. :)
<mdz> pitti: eek, installing hal in a chroot fails in disturbing ways
<mdz> polkit-auth: This operation requires the system message bus and ConsoleKit to be running
<mdz> polkit-auth: GeneralError: Error spawning read auth helper: Permission denied
<mdz> is it talking to a running process outside of the chroot?
<YokoZar> Intrepid Alpha 2 still seems to be unable to login to gnome in vmware for me
<YokoZar> hmm...except when using safe mode
<pitti> mdz: it needs to get a PolicyKit privilege to query running consoles
<pitti> mdz: (in the postinst)
<mdz> pitti: during installation?
<pitti> mdz: well, we could alternatively doing it in the init script
<pitti> but that would require an extra d-bus call at every boot
<pitti> yeah, hal generally works very poorly in a chroot unfortunately
<slangasek> YokoZar: bug #246969
<ubottu> Launchpad bug 246969 in linux "[Intrepid alpha1] gdmgreeter freezes in VMware Server 1.0.6" [Undecided,Confirmed] https://launchpad.net/bugs/246969
<mdz> pitti: chroot gets less useful all the time
<mdz> faster than virtualization takes over, I think
<pitti> mdz: I still use them a lot for building packages and test CLI stuff, but for udev/hal/local dbus they are really not working any more
<mdz> pitti: things like http://wiki.laptop.org/go/Ubuntu_On_OLPC_XO have to use qemu rather than chroot for this reason
<pitti> eek, that sounds slow on a platform like that
<mdz> pitti: well, you do the qemu bits on another system
<pitti> mdz: but for a sensible system nowadays you need polkit and d-bus running anyway; we can probably find a solution for the polkit-auth call, but hal will never work without the system bus running
<pitti> I don't see a principal reason why the sytem d-bus shuoldn't be chrootable, it doesn't open an IP port or something like that
 * pitti tries to install dbus into a chroot
<cjwatson> does it really need to *work* when chrooted? all I usually need is for it to shut up and not bother me
<pitti> hm, it even seems to work for me
<pitti> (chrooted system d-bus alongside the outer one)
<pitti> mdz: I installed hal, dbus, and policykit into a sid chroot, and the only thing it did was " Can't start Hardware abstraction layer - detected chrooted session"; but everything installed cleanly
<|xianai|> hi, morning
<xia> hi, guys, how can I make a gfxboot menu for my own ?  where is the detailed doc for gfxboot that tell me about its structure , syntax or sth like this ?
 * cody-somerville wonders why gdmgreeter is segfaulting in Intrepid.
<bryce_> cody-somerville: are you running -vesa?
<cody-somerville> bryce_, whats the quickest way to tell?
<jcristau> cody-somerville: grep /drivers/ /var/log/Xorg.0.log
<cody-somerville> yes vesa
<cody-somerville> bryce_, ^^ :]
<xia> anyone help me ...
<jcristau> cody-somerville: bug 246585
<ubottu> Launchpad bug 246585 in xserver-xorg-video-vesa "GTK applications crashing reproducibly when using vesa" [Unknown,Confirmed] https://launchpad.net/bugs/246585
<xia> is gfxboot opened source ?
<bryce_> cody-somerville: yep, known bug, see jcristau's link
<bryce_> cody-somerville: if you can use a different driver, that should work, otherwise you can launch X manually
<bryce_> however in the latter, most gdk-dependent apps will not work
<jcristau> starting X with -extension RANDR would probably work around the bug
<cody-somerville> I see an failed assertion in GDM. 'value->type == GDM_CONFIG_VALUE_BOOL' failed. acpid client connect, Next is xfailsafedialog segfault error in libgdk-X11, then gdm warning display :0 is busy, then acpid client connected, gdmgreeter segfault
<slangasek> bryce_: hrm, is the gtk+vesa bug likely to be tied to the VMware failures?  I'm not sure if vesa is what gets used under VMware
<bryce_> slangasek: don't think so
<slangasek> ok
<ramvi> I'm customizing the livecd with the help of https://help.ubuntu.com/community/LiveCDCustomization . I try to start gnome to do changes from there, with /etc/init.d/gdm start (howto in the comments), but what is the username and the password?
<Riddell> asac: http://kubuntu.org/~jriddell/tmp/knetworkmanager-0.7.tar.gz
<Riddell> http://www.kubuntu.org/~jriddell/tmp/admin.tar.gz
<ramvi>  /ignore ramvi
<emgent_> hello
<amitk> rtg: you guys/
<mdz> cjwatson: why does the new openssh-client conflict with openssh-blacklist?
<mdz> cjwatson: dropping the -server recommends to a a suggests seems OK to me, but the conflict is puzzling
<mdz> Keybuk: the initramfs-tools/udev thing is now bug 248378
<ubottu> Launchpad bug 248378 in initramfs-tools "cpio: ./lib/udev/pnp_modules: Cannot stat: No such file or directory " [Undecided,New] https://launchpad.net/bugs/248378
<slangasek> mdz: I suspect he mistook the Conflicts line for a Suggests line when moving the entries :-)
<asac> Riddell: http://paste.ubuntu.com/27275/
<cjwatson> mdz: whoops! fixed
<cjwatson> xia: yes, of course it's open source - it's in the gfxboot package
<cjwatson> xia: the gfxboot package ships language documentation in /usr/share/doc/gfxboot/gfxboot.html
<cjwatson> xia: if you are sane, you will base your work on an existing theme (such as gfxboot-theme-ubuntu) rather than writing it completely from scratch. I didn't write ours from scratch - it's a distant derivative of the SuSE theme
<cjwatson> mdz: (slangasek was correct)
<xia> cjwatson: Thanks a lot :)
<xia> I have got my own in a hour, based on your ubuntu theme :)
<slangasek> mathiaz: morning
<mathiaz> slangasek: morning !
<slangasek> mathiaz: can I ask how you managed to get openldap 2.4.10-2 to build in intrepid? :-)
<slangasek> mathiaz: we just got a bug report in Debian about a missing build-dep on 'time', since it's not a shell built-in with dash
<cjwatson> xia: cool
<slangasek> mathiaz: ah, you fixed this by merging 2.4.10 first and fixing it there, I see :-)
<mathiaz> slangasek: right - I've added it as a build-dependency in intrepid
<xia> cjwatson: but, don't you think that the document of gfxboot is somewhat too simple, ....., is gfxboot a intermediate layer of grub & syslinux ? is there any paper explaining how it works?
<slangasek> mathiaz: ok, another bit that can be dropped in the next merge then :)
<mathiaz> slangasek: cool - do you have some time to discuss the cn=config patch I sent on friday ?
<slangasek> mathiaz: I probably need to take the time to grok the patch first, before discussing it
<slangasek> mathiaz: I can take time to digest it today, yes
<mathiaz> slangasek: great - when should we schedule some time to discuss it ? tomorrow ?
<slangasek> mathiaz: tomorrow sounds good
<TheMuso> c
 * lamont tries to remember if trackerd provided any benefit besides making sure the disk spins, considers reinstalling it on his laptop
<ogra> lamont, just remove it unless you really plan to use it
<ogra> (it *was supposed* to just be ignored until the user switches it on manually ... though)
<lamont> ogra: part of it is that I don't know if I want to plan to use it... much the same way as I nuke evo :-)
<TheMuso> What would the best approach be to file an SRU to upload a fix for a memory leak? i.e what information is needed for such an SRU?
<pitti> TheMuso: describe the magnitude of the memleak, if possible, how to reproduce it, and the patch
<TheMuso> pitti: Ok thanks.
<cody-somerville> TheMuso, I have an example if you'd like one
<Hobbsee> oh yeah, i've just remembered
<Hobbsee> who's responsible for the new recovery mode in intrepid?
<Hobbsee> it's seriously cool, and rocks!
<TheMuso> cody-somerville: That would be very useful, thanks.
<tseliot> pitti: can you upload the new nvidia packages, please? Here's the list of files: http://albertomilone.com/ubuntu/newlrm/pitti/links.txt
<tseliot> pitti: they also contain the modaliases files with the name of the package
<cody-somerville> TheMuso, bug #67129
<ubottu> Launchpad bug 67129 in notification-daemon "notification-daemon using 237MB of memory" [Medium,Fix released] https://launchpad.net/bugs/67129
<TheMuso> cody-somerville: Thanks a lot.
<pitti> tseliot: done, thanks
<tseliot> pitti: thanks to you ;)
<pitti> tkamppeter: yummy, just got the first working jockey <-> openprinting.org query working \o/
 * pitti drops one 'working' from that
<calc> any suckers^Wdeveloper want to upload a mono merge i did? :)
<calc> i don't know anything about mono so don't want to upload it myself
 * calc considers uploading a new OOo that requires the new mono that isn't in the archive yet
<calc> will FTBFS until someone who knows mono uploads it
<seb128> slomo__: ^
<calc> slomo__: yes please merge new mono asap :)
<calc> slomo__: i need to upload a new OOo for the alpha next week
<calc> slomo__: it looks really simple, but i don't know enough to trust my merge to upload
<pitti> calc: please use a versioned build dependency then, so that it will depwait instead of FTBFS
<pitti> calc: this will also avoid broken backports
<calc> pitti: yea i misspoke it is versioned dep so it will just get stuck in depwait
<calc> the new version fixes some crashes on amd64 which is why it is needed
<cjwatson> xia: I didn't write it, I just help package it. No, there's no paper explaining how it works as far as I know. gfxboot is a bytecode interpreter specialised for drawing to the screen in a boot loader context and interpreting the results, and requires hooks into the real boot loader (grub, syslinux, etc.) in order to be useful.
<xia> cjwatson: hmm, I see, thanks :)
<calc> cjwatson: OOo 3.0 dates pushed back to 3.0rc Aug 15 , 3.0 final Sep 16, already updated the calendar
<calc> cjwatson: that puts rc being uploaded a week before FF and final the week before BF
<cjwatson> scary monsters
<calc> yea, hopefully they won't slip any more
<calc> once i get 2.4.1 updated in intrepid i will be working on getting 3.0beta2 into ppa
<slangasek> doko: has there been an MIR for dvipdfmx (now needed by dblatex -> texlive-xetex)?
<ScottK> slangasek: nxvl started working on one yesterday.  Dunno how far he got.
<slangasek> ok
<doko> slangasek: afaik, no. see https://bugs.edge.launchpad.net/~ubuntu-mir
<tkamppeter> pitti, great. So one can plug a (formerly ugly) Dell printer to your box now and after some seconds you get asked whether you want to download splix2?
<tkamppeter> pitti, then we will fix the autodownload blueprint in Intrepid?
<seb128> ArneGoetje: http://www.slis.tsukuba.ac.jp/grad/Syllabus/01MA504.pdf is one example that requires poppler-data to be viewed
<tkamppeter> pitti, last week in Tokyo they told me that they have solved the packaging problems with the CUPS filters for the PDF workflow. Seems that we will get this one done, too.
<pitti> tkamppeter: well, not quite that far yet, but I'll get there :)
<pitti> tkamppeter: nice
<tkamppeter> So, pitti, with first query you mean that you got an answer from the OP server?
<tkamppeter> Are you using the code of s-c-p with which Tim Waugh has started to implement PPD download?
<pitti> tkamppeter: yes, I did, and I'm patching it up heavily :)
<pitti> (most got committed upstream already)
<pitti> tkamppeter: s/PPD download/driver lookup/ anyway
<pitti> tkamppeter: i. e. the cupshelpers module
<slangasek> Riddell: so how does kdebase get unbroken, now that kdebase-data is from kde4?  Or, if kdebase is supposed to just go away, how do things like koffice get fixed? :)
<Riddell> slangasek: koffice I'll replace with koffice2 when I get a chance
<slangasek> Riddell: ok
<slangasek> Riddell: what does this do as far as CDs in the meantime?
<Riddell> slangasek: I don't think anything from koffice is on the CDs
<slangasek> ok
<gnomefreak> did we move nvidia-glx-177 ect.. to Hardy or is that just for Intrepid so far?
<pitti> gnomefreak: hardy won't change, it will keep the l-r-m built ones
<gnomefreak> pitti: thanks
<calc> so the edge changes on launchpad are going live tonight?
<calc> i saw joey stanford made reference to it on facebook
<Awsoonn> they are? wow!
<Keybuk> don't believe all you read on Facebook? :)
<Awsoonn> It looks sexy, I must admit.
<Keybuk> (which isn't to say that I know different)
<LaserJock> it also seems to have some brokenness, it'd be nice to have stuff fixed before releasing it
<test3> HAL does not start when /usr is mounted ro in intrepid. Is this intentional?
<pitti> test3: no, it is not intentional; sounds like a genuine bug
<test3> pitti: I'll file a report then...
<lamont> gpg: problem with the agent - disabling agent use
<lamont> why does it hate me so?
<Keybuk> you tell us
<lamont> heh.  working on that
<lamont> ah.  lack of pinentry-$foo
<pitti> lamont: does that happen in a chroot ("me 2") or in your normal system?
<lamont> that's in the real root
<pitti> lamont: I don't think it requires pinentry
<lamont> installing pinentry: prompt for passphrase.  without pinentry: the above
<pitti> lamont: hm; do you have seahorse actually installed?
<lamont>  /usr/bin/gpg-agent --daemon --sh --write-env-file=/home/lamont/.gnupg/gpg-agent-info-mix /usr/bin/seahorse-agent --execute /usr/bin/gnome-session
<lamont> is in the psaux output
<pitti> /usr/bin/seahorse-agent --execute x-session-manager
<pitti> in mine
<lamont> you gnome-hater you. :)
 * pitti pokes sep
<pitti> Seb, even
<pitti> lamont: but I do use GNOME, standard Intrepid
<seb128> 31507 ?        Ss     0:00 /usr/bin/seahorse-agent --execute x-session-manager
<seb128> for me
<seb128> works fine too
<lamont> hrm.. maybe it's related to gnome-session being diverted. :-)
<lamont> I'll see about undiverting that next time I'm restarting gnome
<seb128> what else do you use?
<lamont> I (still) have gnome-session smashing an ssh-agent into place and doing ssh-add before launching the real one
<lamont> seb128: that is, the same magic diversion script that's been there since pre-warty
<seb128> lamont: not sure why it's breaking now then
 * cjwatson fixes syncbugbot not to close sync bugs sometimes with just "Getting binaries for intrepid..."
<pitti> tkamppeter: any idea how we should determine whether an installed printer driver is actually used?
<seb128> doesn't seem a change that should create issues
<lamont> seb128: it's always needed pinentry for me to get to gnupg-agent
<slangasek> mathiaz: can you show me an example cn=config tree, so I can see what it looks like?
<slangasek> (without having to build & run the package :)
<mathiaz> slangasek: I'll get one
<mathiaz> slangasek: http://people.ubuntu.com/~mathiaz/slapd.tar.gz
<slangasek> mathiaz: thanks, that answers my questions
<seb128> lamont: what is the hppa endianess?
<soren> big
<seb128> soren: thanks
<tmmoyer> using the program dch with a source tree in subversion seems to be less than intuitive.  is there any work to make dch respect source trees controlled by subversion (for example, if I have version 1.1 of a package and I run dch -v 1.2, it simply moves the top level directory, what I would prefer is that dch use svn mv to perform the move from <name>-1.1 to <name>-1.2) or is there a better way of using the two tools?
<soren> seb128: np  :)
<lamont> seb128: big, like it should be;
<lamont> although there are hppa boxen that support littlendian-mode, the port has never bothered
<lamont> tmmoyer: if you're committing each and every change, do you really want to have the version number climb that fast>?
 * lamont hopes you're not doing one-commit-per-release
<tmmoyer> lamont: no
<tmmoyer> lamont: what I would like is when I do you dch -v that  I don't have to manually go through and re-add the folder that it renamed
<lamont> ah, you want to svn-rename the directory when you do the dch
<tmmoyer> lamont: yes
<lamont> dunno.
 * pitti generally drops the version number from VCS-controlled source directories; makes things so much easier...
<lamont> then again, I don't think you'll find many users of svn, other than by force/imperial^Wcorporate fiat in this channel...
<lamont> pitti: me too
<tmmoyer> okay
<tmmoyer> i am forced to use SVN so ...
<lamont> then again, I just have a directory called "work" and do "git checkout" when I need to play with old releases... directory-per-branch has always struck me as insane
<lamont> pitti: and one of these days, I'll sit down with some{one,doc} for long enough to figure out how to do that with bzr
<cjwatson> tmmoyer: definitely drop the version from the directory in the svn repository - having it versioned is a recipe for going insane
<ulim> Hiho! I heard ubuntu won't inherit packages from debian anymore. Does that mean I need an ubuntu maintainer for my package?
<LaserJock> ulim: lol, where'd you hear that?
<ulim> LaserJock: emm from a debian maintainer he said that would be the case for intrepid
<ulim> LaserJock: not true?
<LaserJock> a, perhaps there was some misunderstanding
<LaserJock> *ah
<geser> DIF?
<LaserJock> perhaps the debian maintainer was talking about our Debian Import Freeze
<ulim> meaning?
<LaserJock> that is the point in our development cycle where we stop *automatically* syncing packages from Debian
<LaserJock> we resync every release though, nothing is changing about that
<LaserJock> ulim: does that make sense?
<pwnguin> freeze sounds wrong then
<ulim> LaserJock: hmmm he said "i also just saw that ubuntu has their own packages in intrepid."
<ulim> LaserJock: i guess it was a misunderstanding
<pwnguin> this is not the first upstream to make this misinterpretation
<LaserJock> ulim: oh, perhaps we've made changes to the package
<LaserJock> ulim: what package is it
<pwnguin> ulim: keep in mind there IS a date where you'll need extra review before taking packages from debian
<ulim> LaserJock: package is irssi-otr
<LaserJock> ulim: we still merge the packages from Debian if we make changes
<ulim> so you had that freeze for intrepid already?
<LaserJock> ulim: yes
<ulim> LaserJock: do you take stuff from unstable or from testing?
<LaserJock> ulim: it's not a very hard freeze though, if we need to sync to fix bugs, etc. we will
<LaserJock> unstable
<LaserJock> and occasionally experimental
<ulim> when was the freeze?
<ulim> or maybe do you have a page where I can look up if irssi-otr is in intrepid?
<LaserJock> https://wiki.ubuntu.com/IntrepidReleaseSchedule says June 26th
<LaserJock> ulim: I don't see it
<ulim> ah ok then it's probably not
<Spads> oooh, irssi-otr eh?
<LaserJock> so yeah, a bug can be filed to get it included
<ulim> i would have said better take v0.2 if you had v0.1 but if you don't have either that's ok as well i suppose ;)
<geser> I can't find it in Debian either
<ulim> geser: v0.1 is in unstable and maybe be now in testing
<ulim> geser: and i've released v0.2 today and it's uploaded to unstable already
<LaserJock> ulim: do you know what the package is named in Debian? I can't find it
<ulim> Spads: yeah it's off-the-record messaging for irssi (useful together with the im-to-irc gateway bitlbee)
<ulim> LaserJock: oh sry it's called irssi-plugin-otr
<geser> ulim: https://edge.launchpad.net/ubuntu/+source/irssi-plugin-otr
<LaserJock> ahh irssi-plugin-otr
<Spads> ulim: yes I'd been musing o ver the need for such a thing recently.  Sorry to interrupt!
<geser> !info irssi-plugin-otr
<ubottu> Package irssi-plugin-otr does not exist in hardy
<geser> !info irssi-plugin-otr intrepid
<ubottu> Package irssi-plugin-otr does not exist in intrepid
<LaserJock> it is in Intrepid though
<LaserJock> ulim: https://launchpad.net/ubuntu/+source/irssi-plugin-otr
<ulim> LaserJock: yeah geser just posted the same page ;)
<ulim> so v0.1 is in intrepid
<geser> the binary debs are in NEW
<geser> ulim: a git snapshot:   0.1+git20080706-0ubuntu1
<ulim> hmmm that's before the main fix for v0.2
<LaserJock> it's also a 0ubuntu1 version
<LaserJock> we should probably sync/merge 0.2 over
<ulim> LaserJock: yeah I'd prefer that. It's a bugfix release only.
<ulim> LaserJock: tell me if there's anything I should do for that (I'm upstream) or maybe if you need something from the debian dev (I'm in contact with him)
<LaserJock> ulim: well, you can file an upgrade bug if you want to
<LaserJock> or perhaps talk to jpatrick (the Ubuntu dev that created our package)
<ulim> LaserJock: seems he is not on freenode
<geser> LaserJock, ulim: his IRC nick is now jpds
<LaserJock> I see
<LaserJock> *sigh* now I've got to retrain my brain :-)
<ulim> jpds: heyho, I'd like to see version 0.2 of irssi-plugin-otr in intrepid (not v0.1). It's a bugfix release. Tell me if I should file a bug somewhere or if you'll do something about it. Thanks!
<jpds> geser: You physic?
<jpds> ulim: I filed a sync request for irssi-plugin-otr earlier today.
<jpds> ulim: See bug #ss to control file/copyright file.
<jpds> Hmm, bad paste, bug #248469
<ubottu> Launchpad bug 248469 in irssi-plugin-otr "Please sync irssi-plugin-otr 0.2-1 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/248469
<jpds> ulim: I talked to the Debian maintainer earlier today. Thanks for the great plugin by the way.
<ulim> jpds: ah great thanks
<jpds> ulim: And thank you.
<ulim> jpds: maybe if you've scrolled back a little you saw that there was apparently a misunderstanding
<ulim> jpds: it sounded like ubuntu would now have its own packages
<ulim> jpds: you're welcome ;)
<jpds> ulim: No, I try and stick to what Debian has as much as possible.
<ulim> jpds: i see
<ulim> Then debian/ubuntu/frugalware is settled. Missing is at least gentoo and fedora
<ulim> i almost feel like selling a product ;)
#ubuntu-devel 2008-07-15
<KernelKlick> ï»¿I would like to install ubuntu on an older machine...the problem is that the installation CD doesnt work on the machine because it does not have a coproc.  Can I make a kernel that will work with math emulation and then install ubuntu?
<KernelKlick> not sure if I should ask here or in desktop
<KernelKlick> or installer
<KernelKlick> LOL
<LaserJock> sommer: around?
<sommer> LaserJock: yo
<bddebian> lool: You around by any chance? (gdebi)
<nxvl> Pici: when you have time please take a look at Bug #248605 for pbuilder to build
<ubottu> Launchpad bug 248605 in dvipdfmx "Main Inclusion Report for dvipdfmx" [Undecided,New] https://launchpad.net/bugs/248605
<nxvl> err
<nxvl> pitti: when you have time please take a look at Bug #248605 for pbuilder to build
<nxvl> Pici: sorry!
<nxvl> pitti: Thanks!
<Iulian> Good morning.
<Riddell> asac: https://bugs.edge.launchpad.net/ubuntu/+source/network-manager/+bug/248630
<ubottu> Launchpad bug 248630 in network-manager "UMTS PCMCIA modem not picked up" [Undecided,New]
<asac> Riddell: can you add your type https://wiki.ubuntu.com/NetworkManager/Hardware/3G as well?
<slytherin> Is this a right channel to ask about chippit?
<slytherin> /chippit/shippit
<slytherin> Will shipit now ship 8.04.1?
<TheMuso> I'm looking at making use of some X protocol bits in python. According to http://x-python.sourceforge.net/ there is an X extension for python, however I am unable to find it in Ubuntu anywhere. python-xlib is not it, and while python-xlib implements some of what I need, it doesn't implement everything. Thoughts/suggestions welcome.
<gnomefreak> slytherin: not likely
<slytherin> gnomefreak: any particular reason?
<gnomefreak> slytherin: they cut down on amount you can order, they didnt do it for dapper
<gnomefreak> theres 2 off top of head
<cjwatson> gnomefreak: err, I'm pretty sure shipit *will* ship 8.04.1
<cjwatson> gnomefreak: do you have authoritative information to the contrary?
<gnomefreak> cjwatson: to people that already order cds?
<gnomefreak> cjwatson: no just what has been done over the last few releases
<cjwatson> obviously there needs to be some kind of cut-off where they start with the new set
<slytherin> gnomefreak: Sorry for bein unclear. I was talking about orders henceforth.
<cjwatson> gnomefreak: would prefer if you didn't give non-authoritative answers, thanks
<cjwatson> I'm fairly sure that 8.04 shipit was stopped following the openssl vulnerability
<slytherin> cjwatson: I was assuming that shipit will ship 8.04.1. But the website still says 8.04. Do you know anyone I can ask for confirmation?
<cjwatson> correct answer coming along shortly ...
 * slytherin waits
<slangasek> slytherin: so the situation is that shipit is trying to exhaust their rather extensive existing inventory of 8.04.0 CDs before switching over to 8.04.1
<slangasek> slytherin: any 8.04.0 CDs that are still being sent out are being given an insert that explains that the upgrades are needed
<slangasek> slytherin: and in practice, the demand for 32-bit CDs is such that I'm told they've already switched over to 8.04.1 (with new cover art &c)
<slytherin> slangasek: Ok. That is fair enough. Thanks for official word.
<slangasek> n/p
<tseliot> ï»¿TheMuso: Python bindings for XCB, perhaps? http://xcb.freedesktop.org/XcbPythonBinding/
<TheMuso> tseliot: thanks, I'll take a look.
<bryce_> mvo: forwarded the two bugs
<TheMuso> tseliot: Hrm at a glance there is nothing related to python and xcb in the archive. However I'll take a look at the link you posted.
<bryce_> TheMuso: what are you looking for specifically?
<TheMuso> bryce_: I need access to PriorityNotify, XInternAtom, and defining atoms. Basically I have some C code in one project that I need to rewrite in python.
<TheMuso> bryce_: The code is used in gnome-session to detect at-spi-registryd startup, using PropertyNotify, and some other stuff I'd need to read again to be sure what it does.
<TheMuso> bryce_: Basically I need to implement the same code for ubiquity's accessibility code, to make the same check, that at-spi-registryd starts correctly.
<bryce_> hmm
<bryce_> looking
<mvo> bryce_: execellent, thansk a lot !
<TheMuso> bryce_: Thanks.
<mvo> TheMuso: you could use the ctypes module if there is nothing else available (also this is of course a bit ugly)
<bryce_> TheMuso: http://python-xlib.sourceforge.net/doc/html/python-xlib_13.html looks the right direction
<TheMuso> bryce_: Hrm ok, must have not looked hard enough at that. I will take another look, thanks.
<bryce_> TheMuso: both PropertyNotify and XInternAtom are xlib functionality, so I think the ordinary python-xlib binding would be enough
<bryce_> fwiw, 'xcb' == 'X11 C Binding' and is just an alternative binding for the X11 protocol, like xlib.  In fact, it aims to replace it (there is also an xcb-xlib package that implements the xlib APIs using xcb to communicate with the server)
<TheMuso> bryce_: Ok the only thing that looks odd to me, is that it appears that the intern_atom method for pythonx-lib only takes two arguments, whereas the code I am porting calls XInternAtom with three arguments. See http://python-xlib.sourceforge.net/doc/html/python-xlib_16.html however I could be reading that incorrectly.
<bryce_> what's the code you're porting?
<jcristau> TheMuso: it's a method for a Display object, so there's your third argument
<bryce_> ah nevermind, I got it
<bryce_> yeah the python lib seems to be OO, so 'display' is an internal property of that and doesn't need passed in
<bryce_> TheMuso: so you should be safe to use that
<TheMuso> bryce_: Thanks a bunch.
<TheMuso> bryce_: If you rae interested in the code I need to port if youare interested, its in the gnome-session package, gnome-session/gsm-at-startup.c, the first couple of functions in that file.
<TheMuso> gah typing
<poningru> quick question what is valusofts relationship with canonical?
<poningru> how much profit does canonical derive from valusoft?
<Mithrandir> poningru: I doubt you'll find any information about Canonical's revenue streams in here.
<poningru> hehe
<poningru> I should probably just use email
<poningru> thanks anyway
<cjwatson> you shouldn't necessarily expect to get an answer to questions about commercial relationships anyway; *some* things are sensitive ...
<cjwatson> and, by default, questions of the form "how much money" are likely to be sensitive unless and until Canonical becomes a publicly traded company
<poningru> cjwatson: true
<tjaalton> bryce_: fixing 15477 would only reveal 14441, and I thought it wasn't worth it for alpha2
<tjaalton> damn builtin 3G, broke just in time for my vacation..
<bryce_> heya tjaalton
<bryce_> tjaalton: yes I passed both bugs along to mvo
<tjaalton> hi bryce_.. because of the aforementioned problem my connectivity is below average ;)
<poningru> oh I did have a question that is answerable
<poningru> so there is a new chipset in acer aspire one ( a new netbook) of atheros, madwifi just added it to their mainline
<poningru> should I just bug someone to bring it into intrepid or should I package it up myself and offer it on my ppa or something?
<poningru> same goes for a new realtek chipset though the rtl people have yet to add it to their mainline
<poningru> both seem to be done correctly with ieee80211 drivers
<poningru> I can post links if someone wants to take a look at them
<bryce_> tjaalton: ok I filled mvo in; he may play with it anyway since there's interest
<mvo> tjaalton: thanks for the info, I got a bunch of people asking me about this, so I would like to check it out
<mvo> tjaalton: it seems like comment 9 in the 14... bugreport is promising
<tjaalton> mvo: it's just a workaround and probably would affect other setups
<tjaalton> gotta run again, but will get back later today ->
<bryce_> cya tjaalton
<bryce_> asac: http://releases.ubuntu.com/7.10/
<Mirv> mvo: yep, the comment 9 works, but I'd be interested in hearing if there are any possible side effects from it or not. developers haven't commented on the bug since April, but maybe now that the 15xxx bug is fixed it'll get attention.
<bryce_> mvo, Mirv, you might ping on that bug just in case
<Mirv> bryce_: well it's mentioned as 7.1 blocker anyway, but I now pinged it by asking if anyone has information about possible side effects
<bryce_> Mirv, excellent, thanks
<bryce_> mdz: http://people.ubuntu.com/~bryce/Testing/xserver/
<mvo> Mirv, bryce_: right, thanks
<wgrant> Since there seem to be X folks around... is there a fix for Compiz+Intel == blinding yet?
<jcristau> Mirv: the side effect is to break !i965, aiui...
<norsetto> bryce: re. bug 248657, do you have any pointer on how I could patch the app to replace the obsoleted xrgb.txt?
<ubottu> Launchpad bug 248657 in pixmap "pixmap FTBFS with latest xorg" [Medium,In progress] https://launchpad.net/bugs/248657
<pitti> thekorn: hm, I get "ImportError: cannot import name parse_error" from html_bug.py:17 ("from exceptions import parse_error")
<pitti> thekorn: that doesn't work locally either
<thekorn> pitti: och, which version of py-lp-bugs are you using?
<pitti> thekorn: main head
<pitti> -from launchpadbugs import parse_error
<pitti> +from exceptions import parse_error
<pitti> from rev 62.1.45
<thekorn> phew,
<pitti> thekorn: it seems you did some renaming there, and it conflicts with the standard exceptions module?
<thekorn> pitti: I did some renaming, but I thought I fixed all issues,
<thekorn> do you also have a package or something installed, so it conflicts there?
<pitti> how do you mean?
<thekorn> nevermind, I think I found the problem,
<thekorn> let me have a closer look
<emgent> moin
<tseliot> ï»¿pitti: I have adapted the debconf script to the new pattern in the modalias files (see revision ubuntu11 in my PPA). Just FYI
<pitti> tseliot: nice!
<pitti> tseliot: I still have a bunch of unreplied emails from you, sorry (conference...)
<thekorn> pitti: hmm, sorry, I just don't understand the problem right now, can't even reproduce it,
<hunger> pitti: I reported hal requireing /usr to be rw mounted as bug no. 248649.
<thekorn> will have a closer look later today
<tseliot> ï»¿pitti: there's no hurry ;) I have yet to talk to mvo about the Update-Manager part
<pitti> thekorn: I guess at some point it prefers the system "exceptions" module over the one in launchpadbugs/
<pitti> brb
<pitti> hunger: thanks
<thekorn> pitti: right, I think the naming is bad here
<norsetto> bryce: btw, I guess you may want to remove the /usr/share/X11/rgb.txt symlink too. Its dangling now.
<emgent> heya tseliot :)
<tseliot> hi emgent :-)
<norsetto> asac: not to bee pushy, but the freeze for Debian is approaching
<sebner> tseliot: ping
<tseliot> ï»¿sebner: hi
<sebner> tseliot: buh a wonder that I meet you :D Sry, stupid question. Can you tell me what's the difference between nvidia-173 and -177? (though both aren't working xD)
<tseliot> ï»¿sebner: both of them work here. What card are you using?
<sebner> bryce: Are you planning to merge freetype 2.3.7 from Debian?
<sebner> tseliot: 8400GS
<tseliot> ï»¿sebner: seeing your /var/log/Xorg.0.log would help
<sebner> tseliot: I think I once broke my system with coping nvidia files ^^ though the official driver is working. but what's the difference between these 2?
<tseliot> ï»¿sebner: the 173 is a legacy driver while 177 is the latest (experimental) driver which supports the latest (next-gen) cards.
<sebner> tseliot: though experimental is still stable?
<tseliot> ï»¿sebner: make sure you uninstall the nvidia driver from the nvidia installer before you install my packages otherwise nothing will work. Furthermore they work only with 2.6.26 kernels
<tseliot> ï»¿sebner: experimental is experimental ;) I haven't had problems with it though
<sebner> tseliot: yeah I know but as I said I think I broke the system with coping nvidia files around ^^ nvm. thanks for your answers. I'm off for 2 weeks so I'll look at that later (though I think a ubuntu reinstall will this that)
<asac> norsetto: right. ping me on Thu please. i am currently into doing ffox security update. is that ok?
<norsetto> asac: as long as we don't miss the deadline, it would a pity
<asac> norsetto: when is freeze?
 * calc is glad it only takes 1hr to rebuild OOo on his machine
<calc> the cleanup i was doing turned up some other minor issues
<calc> so have to rebuild it again
<thekorn> pitti: FYI, just filed bug 248675
<ubottu> Launchpad bug 248675 in python-launchpad-bugs "issues with import statements" [High,In progress] https://launchpad.net/bugs/248675
<pitti>  thekorn: thanks, subscribing
<thekorn> super
<fabbione> 716922 build (dist-f10, devel:cluster-2_99_06-1_fc10) completed successfully
<fabbione> ops
<fabbione> sorry
<pitti> fabbione: EDIST :)
<pitti> fabbione: hey dude, how are you?
<fabbione> pitti: ahha yeah .. ubuntu uploads are in the queue already :))
<fabbione> pitti: all good thanks and you?
 * doko waves to fabbione 
<fabbione> hey doko
<doko> fabbione: still doing sparc stuff?
<pitti> fabbione: splendid! currently being in London again
<fabbione> doko: not that much no... very little time atm
<fabbione> pitti: oh great.. sprinting?
<pitti> fabbione: indeed!
<fabbione> i am actually hoping for somebody to take over my last 2 packages in ubuntu
<fabbione> but i doubt somebody has the guts to maintain cluster stuff :)
<thom> or the hardware ;)
<fabbione> thom: 2 virtual machines aren't that expensive ;)
<fabbione> doko: what are you looking for sparc?
<thom> fabbione: where's the fun in that?
<fabbione> thom: a lot more than you can think of :)
<fabbione> thom: but you are spoiled by tons of server toys
<fabbione> so you don't count! :P
<doko> fabbione: building a biarch compiler defaulting to 32bit v9 by default. v9 is tightly coupled to 64bit ...
<fabbione> doko: i guess that's based on davem patches to gcc, right?
<fabbione> iirc he did some cleanup in that area not too long ago
<doko> fabbione: yes, but --enable-targets=all --default-cpu=v9 still doesn't work.
<fabbione> doko: bug worth reporting?
<doko> yeah, maybe ... I'll have to check for one more thing before
<norsetto> asac: looks like it is NOW: http://lists.debian.org/debian-devel-announce/2008/06/msg00000.html
<jr_> siretart: another name change for ffmpeg?
<Riddell> siretart: ah, we were insulting upstream
 * calc wants one of the new (not yet released) quadcore centrino 2 laptops
<bryce_> tjaalton: btw mvo says that the 14441 fix plus the newer mesa makes the issues resolve
<asac> jcastro: https://wiki.ubuntu.com/NetworkManager/Hardware/3G
<siretart> Riddell: yes, I gave a verbose explanation in README.Debian
<siretart> Riddell: I wanted to delay that rename until after lenny release, but upstream pushed me
<siretart> Riddell: if you accept it, could you please remove ffmpeg-free along with it? I'll file a bug otherwise..
<norsetto> bryce_: what do you think about bug 248657 ?
<ubottu> Launchpad bug 248657 in pixmap "pixmap FTBFS with latest xorg" [Medium,In progress] https://launchpad.net/bugs/248657
<Riddell> siretart: ok, can do
<Riddell> siretart: done
<jcristau> norsetto: add a local copy of rgb.txt in your source package?
<norsetto> jcristau: already done, but I guess pixmap won't be the only one broken by this change?
<bryce_> norsetto: hmm
<bryce_> is it enough to have an empty /etc/X11/rgb.txt, or will apps expect valid data in it?
<norsetto> jcristau: I think I was just luky that it ftbfs on the buildd because of it  ;-)
<norsetto> bryce_: can't say for all the apps that use it, but pixmap really is using data from it
<norsetto> bryce_: its an old file (from 2000) so I don't expect that the maintenace burden will be on us, is just to avoid breaking legacy apps which expect/use it
<bryce_> well, I've no objection to including it.  jcristau?
<jcristau> yeah i suppose it can come back
<calc> ok OOo 2.4.1-6ubuntu1 is uploaded now, i guess i will look at mono since i didn't get a response from its last uploader
<norsetto> bryce_: jcristau: thanks guys
<siretart> Riddell: thanks!
<mathiaz> slangasek: around for an openldap discussion ?
<jcristau> norsetto: although really i don't think it's used that much..
<slangasek> mathiaz: let me grab something to drink, then yes
<TheMuso> Could anybody please have a look at this mdadm merge in my PPA? I'm not worried about the merge itself, but the error I get when test building. It seems like something that has been introduced in a recent gcc version, but I'm not sure how best to address it.
<TheMuso> Package: http://ppa.launchpad.net/themuso/ubuntu/pool/main/m/mdadm/mdadm_2.6.7-3ubuntu1~ppa1.dsc - Build log: http://launchpadlibrarian.net/16035089/buildlog_ubuntu-intrepid-i386.mdadm_2.6.7-3ubuntu1%7Eppa1_FAILEDTOBUILD.txt.gz
<sistpoty|work> TheMuso: looks like the fault of -D_FORTIFY_SOURCE
<TheMuso> sistpoty|work: Ok, how does that affect the warning that is being treated as an error?
<mathiaz> TheMuso: check out https://wiki.ubuntu.com/CompilerFlags
<jcristau> TheMuso: that might add warnings, and you have -Werror in CFLAGS
<sistpoty|work> TheMuso: it produces the warning in the first place
<TheMuso> sistpoty|work: Right. mathiaz thanks, I'll take a look.
<slangasek> mathiaz: hiyo
<TheMuso> I guess my only concern is that the code is not written to use the asprintf function like it should, i.e a variable used to receive the return value. I guess it would be safer for upstream to correctly make use of this value returned from asprintf.
<kirkland> doko: ping
<doko> kirkland: contentless pong
<norsetto> jcristau: I really wouldn't know, there are 162 depends of x11-common, many of those libraries
<kirkland> doko: regarding bug #247400, you say "debian-security" ... did you mean "ubuntu-security" ?
<ubottu> Launchpad bug 247400 in ecryptfs-utils "main inclusion request: ecryptfs-utils" [Undecided,Incomplete] https://launchpad.net/bugs/247400
<doko> kirkland: yes, of course :-/
<kirkland> doko: fyi, kees and pitti reviewed that setuid program extensively
<kirkland> doko: kees said he'd add a comment as such, once I clarified that you meant "ubuntu-security" ;-)
<sistpoty|work> TheMuso: I just took a glimpse at the code. looks safe to me, it will go wrong when out of memory (and then segfault0
<TheMuso> sistpoty|work: Right, thats safe? :)
<TheMuso> I would have thought not.
<sistpoty|work> TheMuso: heh, I guess it's saner to do s.th. like "ret = asprintf(..); assert(ret >= 0);"
<TheMuso> sistpoty|work: Hrm ok.
<kees> kirkland: comment added :)
<slangasek> TheMuso: yes, if you look at the manpage for asprintf, you'll see that the contents of the pointer asprintf() is supposed to fill on success are undefined in the event of a failure, so the only way to know whether asprintf failed is by checking the return value
<TheMuso> slangasek: yeah I am aware of that. its just how to handle it sanely.
<slangasek> TheMuso: right; sistpoty|work's solution is ok
<TheMuso> ...and adding assert.h makes things blow up in more spectacular ways...
<StevenK> TheMuso: "Feature"
<TheMuso> StevenK: Oh yeah. ;)
<sistpoty|work> TheMuso: how about if (ret < 0) { abort(); }?
<TheMuso> sistpoty|work: Yeah I guess thats also an option. We'll see what happens this time.
<bryce_> interesting article summarizing current state of X in intrepid - http://www.phoronix.com/scan.php?page=article&item=ubuntu_810_xorg&num=1
<Hobbsee> bryce_: i look forward to having a working X to see it :)
<bryce_> Hobbsee: how's your X broken?
<Hobbsee> bryce_: after disabling usplash, i get a white screen after attmepting to log in.
<bryce_> Hobbsee: ah, intel graphics
 * Hobbsee hears something about logging in with metacity, instead of compiz, solving thep roblem.
<bryce_> Hobbsee: mvo is uploading the mesa fix presently
<Hobbsee> bryce_: yup
<Hobbsee> \o/
<Hobbsee> bryce_: how presently?
<bryce_> Hobbsee: workaround is chmod a-x /usr/bin/compiz
<TheMuso> sistpoty|work: Hrm it seems it has  more to do with the abort function causing errors than assert.h itself. I'll post a build log in a minute.
<tseliot> ï»¿bryce_: would disabling Composite in the xorg.conf help as a temporary fix?
<Hobbsee> hm, it's fallen in depwait.
<bryce_> Hobbsee: I wouldn't be surprised to see it uploaded today within a few hours.
<bryce_> tseliot: that might do it too
<Hobbsee> bryce_: 7.1~rc3-1~ppa1?
<bryce_> Hobbsee: no, that was an accident
<Hobbsee> ah
<sistpoty|work> TheMuso: s.th. with "attribute noreturn" in it?
<bryce_> Hobbsee: that one failed to build
<TheMuso> sistpoty|work: Not sure, hang on.
<Hobbsee> bryce_: it says it's in depwait.
<Hobbsee> so it hasn't quite failed.
<mvo> Hobbsee: please ignore it for now, I'm fixing it
<mvo> (or better, I'm in the process of doing that :)
<bryce_> right, raw mesa depends on something which is in universe for security reasons, so it'll never build
<TheMuso> sistpoty|work: gah hang on, caused bya typo of all things. :)
<sistpoty|work> heh
<Hobbsee> mvo: by 'ignore', i've deprio'd them, so the buildds won't waste time on them
<Hobbsee> at least, the ones taht hadn't had a shot at building
<mvo> Hobbsee: aha, thanks for this!
<Hobbsee> mvo: you're welcome
<tseliot> Hobbsee: (if you want) you can add this to your xorg.conf as a temporary fix and try to restart the xserver: http://pastebin.com/m7927ff80
<Hobbsee> tseliot: 'ive been on hardy for days - another one won't matter much.  but thanks :)
<Hobbsee> besides, intrepid seems to hate my proxy, for some reason
<TheMuso> sistpoty|work: Ok, typos fixed, assert works as expected, on my way. Thanks a bunch.,
<sistpoty|work> TheMuso: you're welcome
<pitti> seb128: /etc/X11/Xsession.d/90-console-kit
<rick_h_> asac: ping, jorge wanted me NM testing asap and get the following: http://paste2.org/p/48932
<asac> rick_h_: are there two wpa_supplicant processes running?
<rick_h_> asac: no, only one pulls up
<rick_h_> /sbin/wpa_supplicant -u -f /var/log/wpa_supplicant.log
<asac> rick_h_: ok.
<asac> intrepid or hardy?
<rick_h_> hardy
<hungerTest> pitti: I worked around the "/usr must be rw for hal" issue I reported in LP #248649 and added a note on what I did. Maybe that helps with fixing the issue.
<ubottu> Launchpad bug 248649 in hal "HAL requires /usr to be mounted read/write" [Undecided,New] https://launchpad.net/bugs/248649
<pitti> hungerTest: thanks
<pitti> hungerTest: I just wonder why that actually fails... rm -f should just ignore it
<pitti> but apparently it doesn't
<pitti> hungerTest: fixed in trunk, thanks
<mdz> bryce: is xresprobe obsolete?
<Riddell> tjaalton: ping
<Riddell> tjaalton: I've synced everything in bug 247556, can you close all the entries please
<ubottu> Launchpad bug 247556 in vdr-plugin-bitstreamout "Please sync these plugins from Debian unstable" [Wishlist,Confirmed] https://launchpad.net/bugs/247556
<pitti> Riddell: syncbugbot should do that; are you using that?
<Riddell> pitti: I am not, where do I find it?
<pitti> Riddell: ~lp_archive/bin
<pitti> Riddell: where are you, I'll show you
<cjwatson> Riddell: will KDE display notes dropped into /var/lib/update-notifier/user.d/ in the usual way?
<cjwatson> Riddell: ah - Arne tells me that Command: isn't supported?
<Riddell> pitti: south side
<calc> http://www.engadget.com/2008/07/14/build-your-own-bluetooth-handgun-handset-or-dont/
<Riddell> cjwatson: no I don't think we implemented that, although we did do the reboot notification
<cjwatson> Riddell: it'd be awfully useful for bug 9392
<ubottu> Launchpad bug 9392 in ubiquity "Proper myspell dictionary should be installed at installation time" [High,Fix committed] https://launchpad.net/bugs/9392
<Riddell> cjwatson: it wouldn't be hard to do and ought to have been done a while ago
<calc> once a package is 'DONE' it is available for buildds to use, right?
<cjwatson> Riddell: is there a bug to track it?
<cjwatson> calc: not quite
<slangasek> Mithrandir: you don't want to fix Debian bug #398610 by any chance, do you? :)
<cjwatson> calc: DONE means (at least) that process-accepted has munched it and that the publisher is about to write it out to disk
<ubottu> Debian bug 398610 in time "time: manpage has duplicated lines" [Minor,Open] http://bugs.debian.org/398610
<cjwatson> calc: but until it's been written out to disk and Packages regenerated, buildds won't see it
<cjwatson> calc: buildds *can* see it a little before archive.ubuntu.com gets updated, though
<cjwatson> (which in practice means that they don't have to wait for cron.germinate)
<calc> cjwatson: is there an easy way to tell when it is safe to use, or just look at a.u.c to find out?
<bryce_> ogasawara: I'm bumping 154647 over to 'linux' since it is sounding like a kernel / wireless driver issue, rather than an -intel issue.  It's an old bug, but please take a look when you get a chance
<Riddell> cjwatson: bug 248753
<ubottu> Launchpad bug 248753 in adept "support update-notifier notification messages" [Undecided,New] https://launchpad.net/bugs/248753
<cjwatson> calc: the latter
<ogasawara> bryce_: sure
<cjwatson> Riddell: thanks
<calc> cjwatson: ok
<calc> cjwatson: how often (or lag) do things go from done to the archive?
<bddebian> mvo: You around by any chance? (about gdebi)
<mvo> bddebian: yes (but a bit busy)
<bddebian> mvo: Just curious if you intend to put 0.3.11 in Debian?
<mvo> bdmurray: I do not maintain it in debian, I would be interessted in someone taking care of it there, if I can not find someone, I may do it myself
<tjaalton> Riddell: excellent, will do
<bddebian> mvo: Amaya has asked me to look at it for Debian but there are so many hands in it I'm a bit confused on which way to go.
<bddebian> Maybe lool is a better person to bug? :)
<cjwatson> calc: hourly
<calc> cjwatson: ok
<cjwatson> calc: the publisher starts at :03
<cjwatson> it does take most of the hour to run though :-(
<calc> oh btw lenovo announced their new thinkpad line recently
<calc> cjwatson: ok
<calc> the X200 looks pretty nice and is relatively cheap (compared to the X300 anyway)
<mvo> bddebian: if you have any specific questions, I'm happy to help, but it should be possible to use it pretty much unmodified on debian
<bddebian> mvo: Well it's more about deltas.  There is an added Turkish translation and she wants me to remove the -kde package :-(
<mvo> bddebian: oh? why removing the kde package?
<bddebian> mvo: Well there are some LP bugs about it but apparently theres an Ubuntu patch for KDE that isn't in Debian so it doesn't work?
<subzero__> ciao raga
<subzero__> qualcuno conosce le qt?
<subzero__> ce nessunoooooooooooo?
<mvo> bddebian: hm, there is a patch for konsole that is required for it to work correctly. we could do it in a different way, but that is not available yet
<mdz> asac: did you get vmware-server working?
<bddebian> mvo: Is anyone actively developing/maintaining it? I only ask because of LP #153943
<ubottu> Launchpad bug 153943 in gdebi "Gdebi-kde uses massive amounts of memory!" [High,Confirmed] https://launchpad.net/bugs/153943
<asac> mdz: unfortunately not. did you get the error mail?
<mdz> asac: no..
<asac> urgh
<asac> mdz: its sent according to my mailer ... anyway: http://paste.ubuntu.com/27512/
<asac> mdz: if you have an idea which old lib might provide it I would give it a try
<mdz> asac: try moving /usr/lib/vmware-server/lib/libgcc_s.so.1 out of the way
<doko> mdz: is this in the partner archive?
<asac> doko: yeah
<asac> gutsy
<asac> doko: i try to install that in hardy ;)
<asac> doko: http://archive.canonical.com/pool/partner/v/vmware-server/vmware-server_1.0.4-1gutsy2_i386.deb
<mdz> doko: yes
<doko> asac, mdz: not the first time I do see this. can we disable / fix this for hardy/intrepid?
<asac> doko: there is no hardy package available :(
<asac> mdz: is anyone working on that?
<mdz> ogra: what does ltsp-client-core use xresprobe for?
<mdz> doko: the package is only in gutsy, and it presumably works there
<mdz> doko: it just doesn't seem to work on hardy for asac (it worked for me)
<mdz> asac: I do not think anyone is working on a hardy package; partner packages are very inconsistently updated
<ogra> mdz, nothing anymore debian uses it for xdebconfigurator
<mdz> ogra: can you remove the dependency?
<ogra> mdz, if you want it gone, i can drop it
<ogra> sure
<mdz> ogra: it should move to universe
<ogra> goo, i'll remove it in the next upload, how urgent is that ?
<ogra> *good even
<mdz> ogra: not urgent at all
<mdz> ogra: I just noticed it was still in main despite being removed from the seeds in hardy, and noticed it's due to ltsp-client-core
<ogra> oki, i'm at the ltsp hackfest next week, so i'll have an upload pending then anyway
<ogra> removed in my bzr tree ...
<laga> ogra: ah, then you'll get a patch from me, too..
<ogra> laga, feel free :)
<asac> mdz: ok. moving this away indeed helps. great. (except that i am left with a forced depends state, but i can deal with that)
<asac> mdz: will use it tomorrow for final QA then. thanks
<asac> hmm ... unfortunately i cannot start a VM ... it gives me "end of error message" - how helpful.
<mdz> asac: maybe the server side is broken; I didn't test starting a VM
<mdz> asac: you can ssh in using the same username and password and sudo
<mdz> asac: but maybe it is not worth your trouble at this point
<geser> Riddell: re bug #247630 and bug #247712: did you perhaps need a extra flag to overwrite the ubuntu changes?
<ubottu> Launchpad bug 247630 in itop "Please sync itop 0.1-4 (universe) from Debian unstable (main)." [Wishlist,Fix released] https://launchpad.net/bugs/247630
<ubottu> Launchpad bug 247712 in statcvs "Please sync statcvs 1:0.4.0.dfsg-2 (multiverse) from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/247712
<asac> mdz: most likely not. ill try to workaround somehow. if you find a spare machine in the office i would be greatful ;)
<pitti> geser: can you please reopen the bugs?
<geser> sure
<mdz> asac: you are welcome to butcher norman.local
<asac> ;)
<mdz> asac: but I don't have a spare monitor for it
<mdz> asac: just preserve /var/lib/vmware-server
<asac> mdz: ok. ill see how much feedback i got on QA this night and do that tomorrow
<Mithrandir> slangasek: sure, I can do that.
<slytherin> Riddell: FYI ... Changes in Ubuntu for statcvs can be dropped. geser has already verified it.
<philsf> is there a way, when installing/removing lots of kernel images, to update-grub only once, after all packages are processed?
<philsf> or, perhaps the question is: should there be a way (or is it some sort of policy)?
<calc> my wife managed to turn off the breaker to my computer, lol
<norsetto> calc: its a good excuse to ask her about that new UPS you have been dreaming about
<calc> norsetto: i have an ups just too lazy (really forgetful) to buy a new battery for it
<calc> OOo 1:2.4.1-6ubuntu1 built on amd64/i386/lpia so far
<MTecknology> hi buddies
<MTecknology> somebody wanna help me out with something?.....
<Lynet> Multiboot hardy install dvd, how to make?
<MTecknology> Lynet, pretty much
<MTecknology> Lynet, you already ask about it?
<Lynet> I'm asking now. ;-p
<MTecknology> o
<MTecknology> I have ubuntu iso's put into a cdshell iso. I can use "diskemu ubuntu.iso" to launch the iso. It looks like it's going to work ok, but then this happens. http://img135.imageshack.us/my.php?image=screenshottestrunningviav2.png  I think what I need to do is make ubuntu look at the iso of itself instead of the cd drive itself.
<MTecknology> any ideas for how to do that?
<Lynet> I suspect it would be fairly straight forward if one could tell isoinux to read an alternate lisolinux.cfg, would just require a .cfg to select which 'cd' to use and then change the initrd for each dvd to tell the installer to look in a directory instead of the dvd root.
<Lynet> But isolinux does not support that, afacit.
<MTecknology> afacit??
<MTecknology> http://ubuntuforums.org/showthread.php?t=73384
#ubuntu-devel 2008-07-16
<MTecknology> Lynet, WARNING - at least SuSE, Mandriva, and Ubuntu use a version of SYSLINUX modified with a patch called "gfxboot". This is a highly invasive and unsupported modification of SYSLINUX. Please avoid these versions if possible.
<MTecknology> there's dvd's of 32bit ubuntu {desktop,server} - I know what we're trying to do HAS to be possible
<cjwatson> you can't usefully install from an .iso on the hard drive, so I wouldn't recommend wasting your time trying. When you have an .iso loop-mounted from the hard drive, that has the effect of locking the partition table so that you can't perform much in the way of partitioning changes.
<cjwatson> ah, but are you nesting ISO images on the CD itself? Urgh, seems rather overcomplicated
<Lynet> cjwatson: No repartitioning expected on a dvd. ;-p
<cjwatson> we just merge everything into the CD root and configure the installer to grab only what it needs
<cjwatson> much easier and actually works
<Lynet> Would merging 32 and 64bit be possible?
<cjwatson> would take a little bit of fiddling to boot the right kernels, but ought to be
<cjwatson> most of the relevant path names are architecture-specific
<MTecknology> cjwatson, what I want to do is make a dvd of ubuntu {32,64}bit {desktop,server}, dsl, and systemrescuecd
<cjwatson> I have no experience with or information on DSL nor systemrescuecd, so cannot comment on how feasible it is to merge an Ubuntu CD root with those
<cjwatson> I can say that right now you'd have to mess about with /var/lib/dpkg/info/cdrom-detect.postinst in the Ubuntu CD initrd to get it to loop-mount an .iso image from the CD
<MTecknology> cjwatson, I've been trying to figure this out for about 20ht... i'm very close to scrapping it
<cjwatson> at minimum; there might be other problems as a result
<MTecknology> cjwatson, you should just do it for me :)
<MTecknology> i'm too noob to figure this out
<cjwatson> erm, sorry, no :-)
<cjwatson> lots of other things to do ...
<MTecknology> :)
<MTecknology> i officially give up
<MTecknology> there's not enough documentation about anything like that online either
<Lynet> MTecknology: I'll keep on it a bit, will msg you if I get any further.
<MTecknology> Lynet, sounds good. I think I'm going to go home - i won't be here tomorrow- i think probably about 2 more times this summer
<Adri2000> is it intended that the kernel binaries (hardy, -security/-updates) are in universe? :)
<cjwatson> Adri2000: known, being worked on (Launchpad went a bit weird on us)
<Adri2000> ok
<cjwatson> we can't seem to move it because it thinks it's already in main
<cjwatson> at least at some level
<cjwatson> btw, it's only -security that's affected, not -updates
<cjwatson> I think what's happened is that somehow (not considered in this memo) it ended up in universe when copying into -security, but the change-override implementation doesn't consider pockets when looking for packages - it just takes the newest in the distroarchseries
<nxvl> Riddell: around?
<Adri2000> cjwatson: hmmm, -updates is affected as well on the fr.archive mirror
<Adri2000> linux-image-2.6.24-19-generic | 2.6.24-19.36 | http://fr.archive.ubuntu.com hardy-updates/universe Packages
<Nafallo> linux-image-2.6.24-19-generic | 2.6.24-19.36 | http://archive.ubuntu.com hardy-updates/main Packages
<Adri2000> maybe it was affected and it has then been fixed? and fr.archive is not up-to-date?
<cjwatson> may just be confusion arising from -security and -updates being at the same version with different overrides
<cjwatson> I'm looking at the master, so I'm not too worried about what mirrors have
<Nafallo> linux-image-2.6.24-19-generic | 2.6.24-19.36 | http://gb.archive.ubuntu.com hardy-updates/main Packages
<Nafallo> I'd say it's fine :-)
<Nafallo> and fr.a.u.c's headache.
<nxvl> does anyone know a good regular expresion manual (a better one than the manpage)?
<nxvl> cjwatson: maybe you?
<nenolod> who do i speak to regarding mysqld in ubuntu?
<nenolod> it has a bug which is ddosing my machines.
<LaserJock> nenolod: has a bug been filed?
<nenolod> LaserJock, yes. it has Priority: low, and has been mostly ignored.
<nenolod> LaserJock, i run a cluster where a lot of people have instances of ubuntu, and since hardy, these instances have caused serious performance degradation
<nenolod> it is a problem that warrants something higher than such a low priority
<LaserJock> perhaps giving us the bug number would help :-)
<nenolod> https://bugs.launchpad.net/ubuntu/+source/mysql-dfsg-5.0/+bug/105457
<ubottu> Launchpad bug 105457 in mysql-dfsg-5.0 "mysqd_safe high cpu usage" [Low,Triaged]
<nenolod> note that Debian does not have this bug, so it's something introduced to ubuntu
<nenolod> i will bisect in a few minutes
<nenolod> hmm. wtf
<nenolod> this is weird. i don't see anything in the interdiff that changes mysqld_safe
<johanbr> nenolod: have you tried rebuilding the debian source package on ubuntu?
<nenolod> johanbr, yeah. going to do that now
<nenolod> johanbr, i don't have any ubuntu instances running in production though, so i don't know if i can reproduce the bug.
<nenolod> johanbr, let me fire up a ubuntu instance on my local server. (i run Debian proper on my servers, personally)
<nenolod> johanbr, building it now. i'll let you know how it comes out.
<nenolod> my test server is a via c7-m 1.5ghz though, so it'll take a while
<jdong> nenolod: you poor thing.
<nenolod> jdong, for what?
<nenolod> jdong, i can run it without a fan
<nenolod> ;p
<jdong> nenolod: I can run my potato without a fan either.
<jdong> *ducks* ;-)
<ScottK> jdong: You still here?
<pwnguin> does the tech board really meet every two weeks?
<LaserJock> I think so
<pwnguin> last time i went digging i found two irc logs in the past six months
<pwnguin> maybe i just need to look harder
<LaserJock> well, there aren't always agenda items
<LaserJock> which leads to a quite short meeting :-)
<Hobbsee> tjaalton: ping?  :)
<LaserJock> did we not release a Desktop CD for alpha 2?
<Hobbsee> LaserJock: correct
<LaserJock> odd, I didn't see that mentioned in the release announcement
<LaserJock> perhaps I missed it
<tjaalton> Hobbsee: pong
<Hobbsee> tjaalton: is it worth filing a bug to get the vertical scrolling for synaptics touchpads detected by default?
<pitti> Good morning
<Hobbsee> pitti!
 * Hobbsee hugs mvo
<mvo> hey Hobbsee
<Hobbsee> mvo: it works!
<mvo> Hobbsee: excellent!
<Hobbsee> compiz seems to fall over and die, but the rest of it works!
<Hobbsee> it's more stable than hardy, now (which strangly went unstable after installing intrepid)
<Hobbsee> that, and how firefox spontaneously dies sometimes
<Rocket2DMn> Hi, I confirmed bug 246823 but a package maintainer/contributor needs to handle it
<ubottu> Launchpad bug 246823 in gwyddion "New upstream release of gwyddion (2.10) available" [Wishlist,Confirmed] https://launchpad.net/bugs/246823
<Rocket2DMn> anybody?
 * Hobbsee looks at it
<Rocket2DMn> i think we may have discussed that one last night Hobbsee
<Hobbsee> 4 mins.  wow, you're patient :)
<Hobbsee> Rocket2DMn: i doubt it - that one actually is in debian
 * Hobbsee scratches head
<Hobbsee> why does this hate me today?
<Rocket2DMn> doesnt "Ubuntu Sponsors for universe" need to be subscribed to those bugs?
<Rocket2DMn> aka ubuntu-universe-sponsors
<Hobbsee> Rocket2DMn: yeah, but i was going to do the sync request and get it out of the way.
<Rocket2DMn> i have a few such bugs
<Hobbsee> sarah@saturn:~/Desktop% sync-package.sh http://ftp.au.debian.org/debian/pool/main/g/gwyddion/gwyddion_2.10-1.dsc intrepid
<Hobbsee> Exception: apt-cache madison does not contain gwyddion/intrepid
<Rocket2DMn> i need to know if it is outside my jurisdiction to confirm/wishlist them when they appear
<Hobbsee> pitti: any idea why ^ ?
<Hobbsee> Rocket2DMn: yes, a MOTU will need to confirm that they're right.
<Hobbsee> Rocket2DMn: you can set to wishlist if you like, but it really doesn't matter either way
<Hobbsee> and just causes more mail
<Rocket2DMn> ive checked that the packages do exist in debian
<Rocket2DMn> Hobbsee, another example is a merge request, like bug 248750
<ubottu> Launchpad bug 248750 in git-core "Please merge git-core 1:1.5.6.2-1 from Debian" [Wishlist,Confirmed] https://launchpad.net/bugs/248750
<Hobbsee> that you will need to subscribe u-u-s for, if it's not already done
<Rocket2DMn> so after confirming/wishlisting i just need to subscribe them and thats it?
<Hobbsee> ah, now the syncer is working.
<Hobbsee> Rocket2DMn: no, don't confirm it.
<Hobbsee> Rocket2DMn: it's the job of the MOTU to confirm it if it's right.
<Hobbsee> Rocket2DMn: otherwise, correct.
<Rocket2DMn> ok, that specific one is for Main, not Universe
<Hobbsee> Rocket2DMn: you might find https://wiki.ubuntu.com/MOTU/Contributing helpful
<Hobbsee> there's a u-m-s group too
<Rocket2DMn> yeah i saw
<Rocket2DMn> ok, so in the future if i see a new one, just subscribe the correct one of them and thats it?
<Hobbsee> yes
<Rocket2DMn> alright
<Hobbsee> Rocket2DMn: wait, no, that bug is crap.
<Hobbsee> Rocket2DMn: it doesn't contain a patch, it doesn't contain any of the work done.
<Hobbsee> it just says "someone needs to do this"
<Rocket2DMn> right
<Hobbsee> and while there's nothing actually done there, it's pretty pointless, and there's nothing to sponsor
<Hobbsee> Rocket2DMn: added to that bug.
<Rocket2DMn> ok
<Rocket2DMn> ok Hobbsee , so the bug we had last night: bug 246822 (not in debian)
<ubottu> Launchpad bug 246822 in prism "Prism on Intrepid should be updated to new upstream version 0.9" [Wishlist,Confirmed] https://launchpad.net/bugs/246822
<Rocket2DMn> what do we want to do with that one?
<Hobbsee> Rocket2DMn: probably ask in #ubuntu-motu if there would be any contributors who would like to do it.
<Hobbsee> i've no idea how difficult it is
<Rocket2DMn> yeah i was just there asking about the first one, didnt get much love
<Hobbsee> first one, debian had already done the work
<Hobbsee> but you were probably doing it while they were all asleep.  and there are lots of packages in universe, and people just may not be interested.
<pitti> Hobbsee: maybe you don't have a deb-src for intrepid universe?
<Rocket2DMn> ok im just going through the list of the few bugs like this i have
<Hobbsee> pitti: i thought i had - at least, i had a mirror version of it, which doesn't include the phrase 'archive.ubuntu.com', which may well be it.
<Hobbsee> pitti: it seems to work with uncommenting the rest
<Rocket2DMn> seems bug 242162 has already been subscribed to u-u-s
<ubottu> Launchpad bug 242162 in devede "Please sponsor devede_3.9 into Intrepid" [Wishlist,Confirmed] https://launchpad.net/bugs/242162
<Rocket2DMn> nobody has complained yet that i confirmed it
<Rocket2DMn> we'll wait on that prism bug, ill see if i can get a MOTU to handle it
<Hobbsee> a sync request is not the same as a merge request, or a new version.  in the latter two cases, a MOTU actually uploads it.  whereas in the first case, a MOTU confirms it, then passes it to the next team.
<Hobbsee> either wya, though, you are creating fairly needless bug spam, which doesn't make people generally happy :)
<Rocket2DMn> yeah, i have a friend on the uf beginners team who does some merges and syncs
<Rocket2DMn> basically it seems like i dont want to touch merges
<Hobbsee> yeah, you can usually leave the workflow bugs completley alone.
<Hobbsee> which is all of the categories above
<Rocket2DMn> as for packages from upstream sources, like bug 248575 which im now looking at, i think i can confirm those and ask a MOTU to take care of it
<ubottu> Launchpad bug 248575 in lame "Please Upgrade Lame" [Wishlist,Confirmed] https://launchpad.net/bugs/248575
<Hobbsee> oh yeah, tag them with 'upgrade' too
<Rocket2DMn> otherwise i can leave all these things alone
<Hobbsee> yeah, pretty much
<Hobbsee> tag those ones with 'upgrade', and otherwise leave them.
<Rocket2DMn> so like bug 242162  needs the upgrade tag
<ubottu> Launchpad bug 242162 in devede "Please sponsor devede_3.9 into Intrepid" [Wishlist,Confirmed] https://launchpad.net/bugs/242162
<Hobbsee> Rocket2DMn: it could.  however, there's probably not a lot of point in it, as the upgrade work's already done.
<Hobbsee> the upgrade tag usually gets used for "this software is old, and needs an upgrade"
<Rocket2DMn> i feel like im running in circles
<Hobbsee> hehe :)
<Rocket2DMn> getting an education didnt teach me squat about handling bug reports!
<Hobbsee> Rocket2DMn: technically, yes it should.  what you then run into is the concept of "what is correct, vs what is useful"
<Rocket2DMn> ok well u-u-s already has that bug subscribed, ill let them deal with it
<Hobbsee> Rocket2DMn: once anything is subscribed to u-u-s, anything else you do to it is effectively useless.
<Hobbsee> Rocket2DMn: and just generates mail.
<Rocket2DMn> yeah i know all about mail
<Hobbsee> however, for those packages that *don't* have u-u-s subscribed, the usual rules apply.  afaik, anyway.
<Hobbsee> feel free to continue in -bugs, btw
<Hobbsee> people might want to get development stuff done in here
<Rocket2DMn> yeah i hang out there, too
<Hobbsee> although i suspect they're mostly at their sprint
<Rocket2DMn> im in 7 ubuntu related channels right now
<Rocket2DMn> i make my home with the ubuntu forums beginners team and branch from there to do bug triage and wiki documentation alongside UF support
<Rocket2DMn> once i finish moving back east and settle in, i want to start some programming with some projects as well
<Hobbsee> nice work :)
<Rocket2DMn> thanks, being from the forums has given me some background that other documentors and triagers dont have
<Rocket2DMn> ok thanks again for the help Hobbsee , im gonna go to bed now, im exhausted.  i'll be back here often
<Hobbsee> night :)
<mdz> hmm, I updated to current intrepid (including 2.6.24-4) and ended up with metacity running instead of compiz
<mdz> toggling it back with the appearance capplet got compiz back, but my keyboard shortcuts were gone
<mdz> compiz itself doesn't seem to have changed in a couple of weeks
<pitti> mdz: xorg and mesa did, though
<pitti> mdz: current mesa should unbreak compiz, but gnome-session currently doesn't start compiz; so I wonder how compiz started automatically for you in the first place? Or did you use compiz --replace manually?
<seb128> pitti: he wrote that he used the appareance capplet
<slangasek> pitti: so what starts compiz by default on the liveCD?
<pitti> ah, right
<seb128> mdz: the new gnome-session is not able to do the fallback magic we had, we need to fix compiz
<pitti> slangasek: nothing ATM, I think (with gnome-session from yesterday)
<slangasek> ah
<seb128> mdz: the keybinding breakage is a compiz bug, I spoke to mvo about it yesterday
<slangasek> so this was added as a workaround for the compiz problem?
<seb128> slangasek: no, mesa fixed compiz, the new gnome-session is orthogonal change
<slangasek> oh. why the behavior change?
<pitti> slangasek: it now decided to not actually do any session startup any more except calling xdg autostart .desktop files :(
<slangasek> erm
<pitti> seb128: please confirm ^
<slangasek> does that mean the facility for starting arbitrary programs at startup has disappeared?
<pitti> .gnome2/session is ignored now, and saving session doesn't work either
<slangasek> well, saving session didn't work before either :-P
<seb128> hum
<seb128> - old session should still be used, they are not that's a bug
<pitti> slangasek: well, at least it restored the applications
<slangasek> pitti: not especially
<seb128> - session saving should be there for intrepid
<slangasek> pitti: it consistently fails to remember how many gnome-terminal windows I had open, resetting it to some state that it got from somewhere other than my session
<seb128> slangasek: now gnome-session has stages and use autostart desktop files to start things
<seb128> compiz has to ship a such .desktop and register correctly to the session
<seb128> they will add compatibility code for wm which don't do that but that's not done yet
<mdz> pitti,seb128: thanks
<mdz> my fonts in Firefox seem to have changed as well
<pitti> mdz: I saw it in moin, too, but not on other pages
<mdz> fc-match serif says DejaVuSerif.ttf: "DejaVu Serif" "Book"
<mdz> but I think that was the same before
<mdz> pitti: probably the moin CSS specifies some other font which changed
<mvo> mdz: I'm working on the session registering stuff now
<DktrKranz> Riddell (or any archive-admin around): could you please explain me what this comment is? https://bugs.launchpad.net/ubuntu/+source/drpython/+bug/247665/comments/2
<ubottu> Launchpad bug 247665 in drpython "Please sync drpython 1:3.11.0-1 (universe) from Debian unstable (main)." [Wishlist,Fix released]
<pitti> DktrKranz: sorry, I reopened the bug; Riddell: you have to specify -f for syncbugbot
<DktrKranz> pitti: ah... I've seen some of them, if you want, I can reopen them as well
<pitti> DktrKranz: that would be nice, thanks
<DktrKranz> np, thanks
<calc> http://www.microsoft.com/opensource/heroes/default.mspx <- Become an Open Source Hero (?!) lol
<calc> emgent: hello
<seb128> bzr add *
<seb128> "ignored 2 file(s).
<seb128> If you wish to add some of these files, please add them by name.
<seb128> "
<seb128> thanks bzr for not being helpful and not saying which ones and why
<jpds> "bzr ignored"?
<seb128> jpds: thanks
<elmo> seb128: https://bugs.launchpad.net/bzr/+bug/76616, FWIW
<ubottu> Launchpad bug 76616 in bzr "confusing message about ignored files on add" [Low,Confirmed]
<jr_> pitti: got time to look at policykit-kde sometime today?
<seb128> elmo: thanks
<pitti> jr_: oh, yeah, let's; still working on something, maybe in 30 mins or so?
<jr_> pitti: ok
<tjaalton> Hobbsee: not sure, maybe there already is a bug against xorg
<lifeless> seb128: so you don't need the * :)
<lifeless> seb128: and we found that showing all the files was confusing
<lifeless> seb128: and many files get ignored repeatedly (e.g. \.o)
<lifeless> seb128: so the current output is a compromise :)
<seb128> lifeless: that's fair enough but telling the user to use bzr ignored to get this list would be good
<seb128> that would still fit on one line
<seb128> and would be an useful hint for users
<lifeless> seb128: ack; filing
<seb128> lifeless: bug #76616 as pointed by elmo
<ubottu> Launchpad bug 76616 in bzr "confusing message about ignored files on add" [Low,Confirmed] https://launchpad.net/bugs/76616
<pitti> jr_: can you please come to Danakil for the release team meeting?
<mnabil> hello, how can i lock the network card (lan) with certain interface , i need it to have only stick with eth0 for example
<ion_> /etc/udev/rules.d/70-persistent-net.rules and now please read the topic.
<mnabil> ion_, okay , and thanks
<asac> siretart: there?
<asac> siretart: somehow on boot and resume something is starting wpasupplicant for me (independent from the dbus activation)
<asac> siretart: where would that  be?
<siretart> asac: interesting. do you have a funny /etc/network/interfaces?
<asac> siretart: yeah. sorry for the noise. i added wpa- entries to test my eni backend ;)
<siretart> asac: well, that would be it then :)
<asac> interesting how many packages depend on ifupdown :/
<asac> wonder if those should be recommends instead
<siretart> Package: ifupdown
<siretart> Priority: important
<siretart> that could be the reason :)
<asac> http://paste.ubuntu.com/27715/
<siretart> cdbs depends on ifupdown? - intersting :)
<asac> yeah
<asac> ppp as well
<asac> strange ...why would NM go away :/
<siretart> well, that is not too surprising, since it is related to networking. cdbs however...
<asac> true
<asac> but its not required to have ifupdown in order to use ppp as well ;)
<siretart> nor telnet
<asac> intltool causes cdbs to be removed
<asac> strange
<siretart> asac: I'm about to upload a new git snapshot to unstable right now, do we want that in intrepid as well?
<asac> ok thats libnxml-parser-perl ;)
<siretart> asac: will we go with wpa_supplicant 0.5 or 0.6?
<asac> siretart: do you have it in  a ppa so i can test with latest NM?
<asac> siretart: 0.6.x
<asac> i am about to upload NM 0.7
<siretart> asac: no, but that can be arranged
<siretart> if you want to
<asac> siretart: i can add you to ~network-manager team
<asac> so you can push to PPA there
<asac> we alrady have a bunch of testers on that PPA
<siretart> okay, please do and I'll upload directly there
<asac> let me do that
<asac> done
<asac> siretart: can you also upload hardy there? ... which probably has more testers
<seb128> asac: wpasupplicant still didn't build in intrepid btw
<seb128> asac: you should fix this before uploading nm0.7
<asac> seb128: ouch
<asac> thanks
<seb128> asac: depwait on libpcsclite
<seb128> or libpcsclite-dev rather
<siretart> seb128: asac: I'm still waiting for feedback on my latest post to ubuntu-devel on that issue...
<asac> seb128: oh, right. MIR?
<seb128> asac: dunno, siretart seems to be waiting on a reply
<asac> siretart: ok, then just upload to hardy for now :/
<siretart> TBH, I don't think we want pcscd in main. the libraries however are very useful to have
<asac> siretart: let me know if there is anything I can do to speed things up
<siretart> I'm not sure if we require a full report for this partial MIR
<siretart> asac: convince seb128 to promote the libs without a full MIR
<asac> siretart: why do we need that at all in intrepid?
<siretart> because we get smartcard support for wpasupplicant this way
<siretart> asac: I'll upload to both intrepid and hardy
<siretart> asac: another option would be to say publicy on the mailing list that we don't want smartcard support and why. I'll point users that need that feature to you then ;)
<asac> siretart: cant we dlopen it?
<asac> or does it require too much api symbols to make that feasible?
<siretart> we would still need the headers at build time AFAIUI
<siretart> which is why I propose to do a partial MIR
<asac> ok at least it just depends on libc
<siretart> asac: atm. the new package will additionally depend on libpcsclite1
<asac> siretart: yes i referred to that when saying that it just depends on libc ;)
<lukehasnoname> What is the difference between nvidia-glx-177 and nvidia-glx-173? They look to support a large overlap of video cards, is that just how nvidia made it? Also, will these drivers make it into hardy? It supports some newer cards that Hardy doesn't.
<pitti> lukehasnoname: tseliot would have details, but I think that -177 is still a beta release and will eventually replace -173
<pitti> -173 is by and large the old nvidia-glx-new
<mdz> pitti:  the old new driver ;-)
<siretart> asac: yes. it used to recommend pcscd, but that was for heaven's sake already demoted to suggests
<pitti> . o O { which is why we dropped this silly naming schema altogether :) }
<asac> siretart: good. currently looking at code. seems like the lib doesnt do much if the server is not running
<lukehasnoname> pitti: Makes sense. Will one of those two replace ore stand by the hardy glx-new driver, for my above reason? If you don't know, who would I mention this to, or would I file a bug or needs-packaging?
<siretart> asac: wpasupplicant accepted. please ping me if you have tested it :)
<Hobbsee> tjaalton: i looked earlier, but didn't see one - not sure if i looked in the wrong place
<lukehasnoname> *ore/or
<pitti> lukehasnoname: yes, tseliot is currently developing scripts for auto-migration
<siretart> asac: right. I do use pcscd on my laptop, but not for wpa
<siretart> asac: I use pcscd for my gpg card. for gnupg and libpam-poldi
<asac> siretart: question is how well wpasupplicant deals when SHMClientSetupSession fails
<siretart> what is SHMClientSetupSession?
<asac> siretart: if i understand its the function in the lib used to establish the socket to pscd (take this with a grain of salt)
<tseliot> ï»¿lukehasnoname: have a look at my blog post on the nvidia drivers: http://albertomilone.com/wordpress/?p=212
<asac> siretart: wpasupplicant already uses dlopen? ... i see that it LOADSYM the SCard symbols
<lukehasnoname> tseliot: k
<asac> siretart: maybe just shipping winscard.h in wpasupplicant is enough then?
<siretart> asac: possibly that would be enough. but I don't have the impression that libpcsclite is already dlopened. this would probably need some more additional development
<lukehasnoname> tseliot: So you're saying the envy drivers WILL support new video cards, but official hardy drivers won't?
<siretart> asac: to be more concrete: I have the impression from reading pcsc_funcs.c that dlopen is only used on windows to load some functions from winscard.dll because of mingw limitations
<siretart> which doesn't help us here
 * Hobbsee notes that nm has spontaneiously fixed itself.
<tseliot> ï»¿lukehasnoname: yes, it's too risky to update the official lrm
<rick_h_> asac: thanks for the update, has me back on track with the wireless working
<emgent> heya
<Vlad> this is the development chat for ubuntu correct
<Hobbsee> yes
<Vlad> I was hoping that someone could tell me of an easy to use IDE
<Vlad> i do code some in c++ but new to linux
<wgrant> 'Development of Ubuntu (not support, not application development on Ubuntu)'
<Vlad> I apologize I am a noob
<Hobbsee> try in ##c++ or something
<lukehasnoname> wgrant: Admittedly, there is not Ubuntu-app-devel group. Maybe there should be one... I wonder what sort of popularity that would have? Anyway, Vlad, check out ubuntuforums.org. Lots of help there.
<pwnguin> lukehasnoname: there's a ml post about creating a virtual package
<Hobbsee> lukehasnoname: probably because there really is a heck of a lot of apps, and relatively few similarities between them
<Vlad> Thank you
<wgrant> And there's nothing Ubuntu-specific about application development on Ubuntu.
<pwnguin> wgrant: well aside from knowing which packages to install, and so on
<pwnguin> which we share with debian
<wgrant> pwnguin: Is one going to get far with coding if one cannot work out which packages one needs?
<Hobbsee> pwnguin: isn't that a) what apt's for, and b) what upstream developers should already know?
<pwnguin> and this is what happens every time i bring it up
<lukehasnoname> whoa, I walked away and came back to a bombardment of h8. Good points guys, calm down, I'm convinced.
<Hobbsee> try bringing up a better idea, then?  :)
<pwnguin> Hobbsee: would you then provide that comment to mdz?
<pwnguin> as the virtual package was his idea
<Pelo> morning folks, is there an exhaustive list of the hardware supported throught the restricted driver manager ?
<Hobbsee> pwnguin: i wasn't commenting on the metapackage idea.  as far as i knew, he was referring to an irc channel and corresponding group for people who were interested in application development on ubuntu to concentrate.
<Hobbsee> er, congregate
<Hobbsee> pwnguin: as far as i read it, no one actually replied to your statement about the metapackages.
<lukehasnoname> Hobbsee: right.
<lukehasnoname> That was what I was getting at, but as I said, there are enough resources for that already
<pwnguin> well, someone would have to actually populate the virt package ;)
<Hobbsee> pwnguin: ubuntu-restricted-extras already does that, for a section.
<pwnguin> anyways, no point going on with this if theres no support
<Hobbsee> pwnguin: it's rather troublesome, though, as many people have many different ideas about what they all want.
<siretart> asac: wpasupplicant package in place. please give me feedback if it works for you
<siretart> asac: I'd like to upload it to unstable then
<Hobbsee> pwnguin: the metapackages idea may well be a good one - i've not expressed an opinion on it at all :)
<pwnguin> well every time i mention the need for better dev tools, out of the woodwork come these people with a common theme: new developers should just be smarter
<lukehasnoname> man, I just read a ML post about how GNU needs a rebuild and how distros like Debian have de facto stolen user's rights to free software
<Hobbsee> pwnguin: i doubt that anyone thinks that better dev tools aren't a good idea.  however, some ideas of dev tools are good, and some are not.  from how i see it, some people jumped on a particular idea, saying it wouldn't help.  i don't see how that then leads to your sweeping generality.
<Hobbsee> lukehasnoname: veracity verified?
<lukehasnoname> "Instead, we neglected all that grunt work and thus gave rise to Debian and all of the commercial vendors and all of the problems those "mid-stream" players create as they dominate the entire economics of our efforts to create software freedom."
<lukehasnoname> http://lists.gnu.org/archive/html/emacs-devel/2008-07/msg00466.html
<pwnguin> Hobbsee: its a pattern, not derived from a single event. but at any rate, last time I said i'd come up with a convincing argument before going at length on it again
<pwnguin> as i havent done that yet, i think it's time to start thinking
<bryce_> cjwatson: http://people.ubuntu.com/~bryce/Testing/xserver/
<bryce_> cjwatson: I'll have debs up in half an hour or so once they've built
<bryce_> cjwatson: let me know if that solves the issue and I'll push it to intrepid
<Tonio_> bryce: I'm having a little issue with xauth, that causes kdesudo not to work as expected...
<Tonio_> bryce: hi, btw :)
<Tonio_> bryce: this is how we generate the xauthority file (tmp file) :
<Tonio_> bryce: /usr/bin/xauth -q -f /tmp/kdesudo-TT4636-xauth generate :0 trusted
<Tonio_> bryce: here is the xauth output : couldn't query Security extension on display ":0"
<Tonio_> bryce: any idea what's going on ?
<tseliot> Tonio_: maybe you should ping bryce_
<kees> Tonio_: there were changes in the upstream xorg that disabled the Security extension.  it's getting attention already and should be fixed soon.
<Tonio_> tseliot: ah ;)
<Tonio_> kees: okay, super :)
<Tonio_> kees: is there another workarround ?
<bryce_> Tonio_: yep, was working on that just a bit ago
<Tonio_> bryce_: very nice to ear ;)
<bryce_> Tonio_: can you please test something
<Tonio_> bryce_: sure...
<bryce_> Tonio_: here's an xserver with a proposed fix for this issue:  http://people.ubuntu.com/~bryce/Testing/xserver/
<bryce_> please test that and verify for me that it makes the problem go away
<Tonio_> bryce_: I'll do that in a few minutes and will let you know
<bryce_> thanks
<Tonio_> bryce_: SecurityBadAuthorizationProtocol  (invalid authorization name or data)
<Tonio_> bryce_: the issue changed btw ;)
<bryce_> hmm
<Tonio_> bryce_: maybe I miss something, I don't know
<bryce_> cjwatson is also investigating this issue from the ubiquity side, although he's in a meeting at present
<Tonio_> ok
<Tonio_> bryce_: /usr/bin/xauth -q -f /tmp/kdesudo-TT4636-xauth generate :0 trusted
<Tonio_> bryce_: here is the exact command I used
<Tonio_> I think that's okay
<kirkland> doko: hiya, see https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/249059
<ubottu> Launchpad bug 249059 in lsb "please merge lsb_3.2-14" [Low,In progress]
<kirkland> doko: Debian lsb took the status_of_proc() patches, so we can drop our diff
<kirkland> doko: i did a new merge
<kirkland> doko: the goods are http://people.ubuntu.com/~kirkland/lsb/
<bryce_> Tonio_: hmm, cjwatson was using a different command
<bryce_> xauth -q -f t.xauth generate $DISPLAY . trusted timeout 60
<bryce_> Tonio_: ^ try that
<Tonio_> bryce_: yeah I forgot the . :)
<Tonio_> bryce_: seems to work here
<bryce_> awesome
<bryce_> ok, I'll upload this fix
<jcristau> bryce_: just --enable-xcsecurity?
<Tonio_> bryce_: yep I can confirm it works as expected.... the generated file is working, super :)
<bryce_> jcristau: not sure; the patch disabled both that and app-group
<bryce_> jcristau: do you know of a reason why app-group should be disabled?
<bryce_> er, appgroup
<Riddell> pitti: do you know where till is?  and if he's still doing printing meetings?
<jcristau> bryce_: no idea what the appgroup extension is :)
<bryce_> from its .c file it has to do with the security module
<skymuss> hi
<skymuss> hi
<Hobbsee> hi
<skymuss> where are you from ??
<Hobbsee> sydney
<skymuss> cool
<skymuss> I'm from
<skymuss> bavaria
<skymuss> germany
<skymuss> oktoberfest
<ion_> I have a
<ion_> return
<ion_> key
<slangasek> Does that ordering imply that Germany is a subset of Oktoberfest?
<TheMuso> heh
<liw> slangasek, oktoberfest is bigger than germany, so the answer is probably Bananenkartoffeln
<bryce_> mvo: apt-get source xscreensaver.  configure and make, and run the ./braid command
<bryce_> Tonio_: I've uploaded the fix.
<Tonio_> bryce_: super ;) I've uploaded the fixed kdesudo btw, so it should work toonight.... thanks :)
<mvo> bryce_: thanks, I can not test right now, but I will check it out
<bryce_> mvo, okay thanks.  I can't think of anything else to experiment with so I'm going to file it upstream with -intel for now.  I think I've reasonably decided it's not just bad screensaver coding or something ;-)
<mvo> bryce_: http://bugs.opencompositing.org/show_bug.cgi?id=961 (for the reference)
<ubottu> bugs.opencompositing.org bug 961 in Core "system loses keyboard input after running xscreensaver in kde" [Major,New]
<calc> slangasek: did intrepid a2 not release a desktop cd?
<Riddell> calc: no
<tseliot> mvo: let me know when you're available to work together to make sure that dist-ugrades go smoothly with the new NVIDIA drivers
<calc> ok
<mvo> tseliot: yeah, sorry for not coming back to you about this earlier. I'm traveling right now so my reponse time is a bit worse
<bryce_> mvo, ah, same bug?
<mvo> bryce_: it seems to be, no sure. I added some releavant information and hope one of the compiz upstreams have a idea (if not, I will debug it when I come back home)
<tseliot> ï»¿mvo: no problem
<bryce_> ok, I'll add that to this bug.  I'm forwarding it upstream too
<TheMuso> ogra: is there an MIR for aubio? If so, do you have a bug number handy? Secondly, if we pull aubio into main, we will have to disable jack support at a minimum..
<bryce_> mvo also see https://bugs.launchpad.net/xorg-server/+bug/101943/comments/74
<ubottu> Launchpad bug 101943 in linux-restricted-modules-2.6.24 "braid and other screensavers lock up system when compiz activated [-intel, -nvidia]" [High,Confirmed]
<ogra> TheMuso, whats aubio ?
 * ogra never heard of it
<TheMuso> ogra: According to your latest changelog entry for denemo, which was a merge, libaubio-dev is needed as a build-depend for denemo, and you clearly state here that it needs an MIR.
<TheMuso> ogra: So aubio is the source package for libaubio-dev.
<ogra> ooh, right
<ogra> TheMuso, no, there isnt a MIR yet
<TheMuso> ogra: Right. My attention was brought to it due to looking at the component mismatches list.
<TheMuso> ogra: So, do you want to MIR it, or should be drop building against aubio for now?
<ogra> i'm currently a bit hogged by cmpc building stuff, i'll try to get a MIR prepared the next days
<TheMuso> ogra: No hurry, I was just wondering whether you were aware of it and whether it was on your radar.
<ogra> TheMuso, no, it totally wasnt, i owe you a beer :)
<ogra> thanks a lot
<TheMuso> ogra: np.
<kirkland> doko: regarding https://bugs.launchpad.net/ubuntu/+source/opencryptoki/+bug/247593, could you give a high-level look at the patch I attached?  I'm working with upstream to get this applied to their CVS, but I'd like to know from you if this will take care of most of your inclusion concerns about the library
<ubottu> Launchpad bug 247593 in opencryptoki "main inclusion request: opencryptoki" [Undecided,Incomplete]
<cody-somerville> cjwatson, what did you say needed to be done to fix the daily PPC builds for Xubuntu?
<mdz> pwnguin: I'm not invested in a particular solution, so much as making it simpler for developers to get up and running on Ubuntu
<mdz> Hobbsee: ^^
<cjwatson> cody-somerville: "ignore for now"
<cjwatson> cody-somerville: otherwise, messy fiddling with the mirror layout on antimony
<cjwatson> it's nothing that anyone without shell access to antimony can do, I'm afraid
<pitti> Riddell: yes, he and I were in the hotel for a printing mini-conf; just back now
<siretart_> asac: did you have a chance to test my wpasupplicant package?
<asac> siretart_: nope ... maybe in the hotel. but there are lots of testers on it already. i will look athte forum thread and my blog later to see if someone complained
<asac> and test on my own tomorrow
<asac> will bail out of office now ;)
<siretart_> which forum?
<asac> siretart_: one of the threads that test NM
<asac> ubuntuforums
<asac> siretart_: http://ubuntuforums.org/showthread.php?t=797059&page=12
<siretart_> ok. thnx
<asac> siretart_: ok i told them that there are also new wpasupplicant packages to test
<asac> lets look tomorrow what came out of it
<siretart_> ok. thanks
<slangasek> jelmer: where do I get the orig.tar.gz for your openchange package? :-)
<jelmer> slangasek: Hmm, I seem to've pulled it down at some point
 * jelmer searches
<kirkland> pitti: ping
<mario_limonciell> kees, ping
<norsetto> norsetto, ping
<kees> mario_limonciell: pong
<kees> norsetto: you pinged yourself?
<mario_limonciell> hey kees, i was gonna ask you if you had tried to use mk-sbuild-lv at all on lpia?
<mario_limonciell> or at least lately
<norsetto> kees: yeah, felt alone with all you guys pinging around
<kees> mario_limonciell: not under intrepid, but I've used it on hardy.  You do need to specific the ports mirror
<kees> norsetto: heheh okay
<kees> norsetto: but you didn't reply!  ;)
<mario_limonciell> kees, ah so that might have been where things failed
<norsetto> kees: I never replay to contentless pings!
<mario_limonciell> maybe worthwhile to include that as a default mirror when choosing lpia?
<kees> norsetto: hahah
<kees> mario_limonciell: I thought someone might have added that in intrepid, but let me check...
<kees> mario_limonciell: yeah, totally.  patches welcome.  :)  in the meantime   --debootstrap-mirror http://ports.ubuntu.com/   should work
<mario_limonciell> kees, okay i'm just rebuilding my VG and accidentally nuked all my LV's, so i'll give that a go
<mario_limonciell> thanks!
<kantor> hi, how is made Ubuntu to recognize ATAPI cd devices and ATA hard drivers like SCSI devices ?
<nxvl> pitti: around?
<norsetto> nxvl: pitti is rather slim
<laga> ouch
 * norsetto hides in a corner for macking such feeble attempts at humour
<nxvl> norsetto: indeed
<norsetto> nxvl: can't answer you, I'm hidden in a corner
<geser> nxvl: how is the MIR for dvipdfmx going?
<nxvl> geser: Bug #248605
<ubottu> Launchpad bug 248605 in dvipdfmx "Main Inclusion Report for dvipdfmx" [Undecided,Incomplete] https://launchpad.net/bugs/248605
<asac> cr3_: ping
<cr3_> asac: pong
<pedro> every time i try to ssh to some machine, a window pop-ups asking-me to unlock the private key
<pedro> i've search a lot on the web but havent found any solutions
<pedro> anybody already had the same problem?
<laga> well. what _is_ the problem?
<pedro> wel, i'm trying to access my server, that only allows key authentication..
<pedro> then i'm create the key, and stores it in server's authorized_keys
<pedro> but for some reason, every time i tried to connect, a window pops-up asking me to unlock that key..
<pedro> it freezes my machine twice...
<pedro> laga: sorry for my english... =]
<laga> it freezes your computer? does it lock up? eg your mouse cursor doesn't move anymore?
<pedro> dont, but i cant kill the proccess, and my terminal does not read the keyboard..
<pedro> my its a focus mystake..
<pedro> only solution i found is ctrl+alt+bkspc
<pedro> maybe*
<laga> yes. well, it is supposed to do that. you need to enter your pass phrase for your key. or just click "abort" or whatever button there is
<pedro> yes, but if i click in abort it aborts my ssh..
<pedro> there is a way to disable this?
<pedro> let the default way, asking by the terminal?
<laga> pedro: the windows captures all input to make sure you don't enter your passphrase in the wrong window
<laga> oh yeah, you can do that. but i don't know how :)
<pedro> i search on the web and many people have this doubt..
<pedro> and no aswners!
<pedro> hahaha
<pedro> that problem happens if this window pops-up when you are on a full screen terminal
<mario_limonciell> kees, okay i've  got an lpia patch together on ubuntu-dev-tools.  mind if i just push it out, or would you prefer to look at it first?
<mario_limonciell> kees, er well i'ts in rev 108 on the branch.  if it looks good to you, i'll push it out to intrepid
#ubuntu-devel 2008-07-17
<emgent> heya
<NCommander> hola emgent
 * NCommander needs a main sponsor
<NCommander> I solved the long running mono crashbug
<NCommander> https://bugs.edge.launchpad.net/ubuntu/+source/mono/+bug/247782
<ubottu> Launchpad bug 247782 in mono "Ubuntu mono patch dont_check_proc_self_exe causes random segfaults in mono" [Undecided,Confirmed]
<emgent> NCommander: subscribe ubuntu-main-sponsors
<NCommander> did
<emgent> ok now wait :)
<NCommander> not my strong suite ;-)
<emgent> argh mono
<NCommander> Yeah
<NCommander> The bug was one of the ubuntu patches
<NCommander> A "genius" commented out an entire function to determine the root path so mono would function on an unionfs filesystem
<NCommander> THe end result is it causes mono to randomly crash
<emgent> gh
<NCommander> This resolves the f-spot crash ftbfs, and the evo-sharp one
<NCommander> And probably a  few others
<NCommander> https://bugs.edge.launchpad.net/ubuntu/+source/transproxy/+bug/247886 - BTW, I need an MOTU sponsor, care to donate emgent  ;-)
<ubottu> Launchpad bug 247886 in transproxy "FTBFS fix on AMD64/SPARC/IA-64" [Medium,In progress]
<emgent> hahaha
<emgent> ok i take a look
<emgent> NCommander: remember to add LP bug number in changelog
<emgent> LP: #bug
<NCommander> d'oh
<NCommander> THat debdiff been sitting awhile, its before I started doing that
<emgent> no problem i will fix it first to upload.
<emgent> now i should test it.
<emgent> wait.
 * NCommander waits
<emgent> NCommander: processed.
<NCommander> sweet
<NCommander> ANother day, another FTBFS resolved
<NCommander> Once that mono one goes, quite a few FTBFS will be resolved
<emgent> NCommander: try to see eclipse
<NCommander> what's wrong with eclipse?
<emgent> listed FTBFS in dad
<emgent> (if i remember well)
<NCommander> Ugh
<NCommander> Got any idea why?
<emgent> nope i dont use it
<NCommander> http://science.slashdot.org/science/08/07/16/1831256.shtml - Wow, way too many bad buns
<emgent> NCommander: done. Thanks for your work in Ubuntu.
<NCommander> Well, my HDD is making a wonderful grinding noise
* mthaddon changed the topic of #ubuntu-devel to: Launchpad is going down from 02:00 UTC until 03:00 UTC for a code update | intrepid alpha-2 released, archive open | Ubuntu 8.04.1 released | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-
* mthaddon changed the topic of #ubuntu-devel to: intrepid alpha-2 released, archive open | Ubuntu 8.04.1 released | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<ScottK> If there's anyone around in ubuntu-main-sponsors, Bug 249300 can be unsubcribed.
<ubottu> Launchpad bug 249300 in libnet-dns-perl "Please sync libnet-dns-perl 0.63-2 (main) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/249300
<kees> superm1_: cool, yeah, the lpia changes look good to me.  thanks!
<ScottK> kees: I's appreciate it if you'd add me to ubuntu-main-sponsors.
<kees> ScottK: sure thing, one sec
<ScottK> Thanks.
<kees> ScottK: done!  :)
<Hobbsee> asac: whatever those last changes were in your network manager ppa, did anyone test them?
<Hobbsee> nm doesn't even seem to start for me now
<nxvl> Hobbsee: can you please take a look at Bug 248260
<ubottu> Launchpad bug 248260 in terminator "Please sync terminator 0.9-1 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/248260
<Hobbsee> nxvl: is it urgent?
<nxvl> Hobbsee: not really, just getting old
<nxvl> Hobbsee: if you add it to your ToDo i will be happy
<efnx> hi all
<efnx> i have some programming questions
<efnx> if you're up for them
<Hobbsee> did you read the /topic?
<efnx> so this is a development channel without any talk of developing apps?
<efnx> hmmm
<efnx> sorry i wasted your time
<efnx> what is the appropriate channel?
<Laney> #<name of language> is a good bet
<efnx> my questions involve finding out which language is appropriate
<efnx> hehe
 * micahcowan sighs
<micahcowan> what's the command for editing debian/changelog again?
<ion_> dch
<micahcowan> thanks much
<ion_> dpkg -L devscripts
<micahcowan> Again, thanks :)
<micahcowan> (I can never remember what devscripts is called either; when I install it, it tends to be installed via apt-get build-dep, I think.
<pitti> Good morning
<pitti> kirkland: pong
<pitti> nxvl: pong
<pitti> yay for contentless pings :
<ion_> pitti: ping
<pitti> hi ion_
<ion_> Hi :-)
<tseliot> morning
<pitti> hey tseliot
<tseliot> ï»¿pitti: hi ;)
<asac> Hobbsee: are you talking about "my" ppa or ~network-manager?
<mdz> pitti: grep -i doesn't seem to fold case properly in Hardy with en_US.UTF-8 (C works).  do you know where I might look to track it down?
<mdz> pitti: er, Intrepid
<pitti> mdz: bug 241990 got a detailled analysis and a patch 9 hours ago
<ubottu> Launchpad bug 241990 in grep "[master] grep -i fails to work on intrepid" [Undecided,Confirmed] https://launchpad.net/bugs/241990
<pitti> I haven't looked at it yet, though
<mdz> pitti: thank you
<calc> is there a tag or something else for unreproducible bugs?
 * pitti ususally uses needsinfo
<calc> i don't want to just mark them invalid but i'm getting so far what appears to be a lot of bugs i can't reproduce at all
<slangasek> 'incomplete'?
<pitti> right, sorry
<seb128> cody-somerville: how is bug #249020 a gtk bug? what fileselector backend is xubuntu using?
<ubottu> Launchpad bug 249020 in gtk+2.0 "Places list in "Save As" not up to date" [Undecided,New] https://launchpad.net/bugs/249020
<calc> yea i guess i can leave it as incomplete of course those get cleaned eventually
<calc> but if i can't reproduce it i can't fix it either so i guess its not too big of a problem
<pitti> calc: I consider that a good compromise between "get out of my eyes" and not closing them immediately
<Keybuk> who feels like reviewing my package of pywebkitgtk?
<Keybuk> http://launchpadlibrarian.net/16086285/pywebkitgtk_0.2%2Bgit20080708-0ubuntu2_source.changes
<cody-somerville> seb128, I'm pretty sure it uses the gtk fileselector.
<Keybuk> http://launchpadlibrarian.net/16086287/pywebkitgtk_0.2%2Bgit20080708-0ubuntu2.dsc
<Keybuk> http://launchpadlibrarian.net/16086286/pywebkitgtk_0.2%2Bgit20080708-0ubuntu2.tar.gz
<seb128> cody-somerville: right, the gtk selector is not supposed to list vfs locations
<cody-somerville> seb128, which one is?
<seb128> cody-somerville: the gnome-vfs and gio ones which are in libgnomeui
<seb128> that's fixed in intrepid where the only backend is gio now and is in gtk
<cody-somerville> seb128, okay, thanks.
<mdz> Keybuk: isn't there a tool which can be pointed to <url to dsc> and download a source package?   that would be handy to add to apt-get source
<Keybuk> mdz: not for launchpad that I know of
<liw> mdz, dget ?
<slangasek> 'dget', but it requires the files to be in the same directory
<seb128> cody-somerville: is libgnomeui installed on xubuntu?
<liw> oh, but the urls are different
<slangasek> which evidently the above files are not
<liw> enhancing dget for that would be good, then
<mdz> slangasek: which they are in PPAs
<cody-somerville> seb128, it is, yes.
<mdz> slangasek: oh, not the librarian URLs
<slangasek> mdz: right and right :)
<seb128> mdz: ubuntu-dev-tools has a dgetlp doing that
<Ng> on a similar note, if someone posts a url to a code.lp.net URL, is there something which will grab that branch? I seem to have to open the URL to get a lp:~foo/bar that bzr will use
<seb128> dgetlp http://launchpadlibrarian.net/16086287/pywebkitgtk_0.2%2Bgit20080708-0ubuntu2.dsc
<liw> or perhaps it would be possible for launchpad to do (redirect?) urls that work with dget?
<mdz> slangasek: http://ppa.launchpad.net/scott/ubuntu/pool/main/p/pywebkitgtk/ has adjacent URLs
<mdz> seb128: neat
<seb128> cody-somerville: gconftool-2 --get /desktop/gnome/interface/file_chooser_backend?
<cody-somerville> seb128, one second. booting vanilla Xubuntu.
<cody-somerville> seb128, gio on Intrepid
<seb128> cody-somerville: as said intrepid has no backend now, the new gio backend is in gtk
<seb128> anyway that bug is not a gtk one, the hardy gtk is not supposed to list vfs locations
<cody-somerville> Okay, sounds good.
<seb128> oh, the applications can also specify that the fileselector mode, maybe this one is using the local one
<seb128> what application is the one described there?
<seb128> hum, he didn't specify
<cody-somerville> seb128, looks like abiword
<cody-somerville> http://launchpadlibrarian.net/16086449/save_as.png <-- the file type is ODF
<seb128> I don't have abiword installed to try
<cody-somerville> I'm also pretty sure that we use abiword-gtk
<seb128> ok, so that's likely an abiword gtk choice to not use gnome-vfs
<Keybuk> is there an abiword gtk anymore?
<Keybuk> I thought they all got merged in 2.6
<seb128> hardy didn't have 2.6
<Keybuk> ahh
<seb128> mdz: btw did you fix your compiz workspace switching keybinding issue?
<milian> I think I've spottet a bug in libplot-dev : it is compiled with PNG support (at least it depends on libpng), but in plotter.h is a #define INCLUDE_PNG_SUPPORT missing
<milian> I just added it manually and now I can use PNGPlotter in my C++ program
<milian> before it did not work
<milian> I'll report a bug. but if there's anybody who has the ability to update the packages in backport, please do so. it's just one added line
<Mithrandir> humm, python2.5 2.5.2-2ubuntu5 was removed from -proposed?
<Mithrandir> that seems slightly unfortunate, since python2.5-dev was then uninstallable for me.
<slangasek> yes, packages in -proposed aren't guaranteed to not be rolled back
<Mithrandir> hm, that's not very well communicated, I think.
<slangasek> this one was rolled back because it was blocking 8.04.1 CD builds and had an insufficient SRU justification at the time
<mdz> seb128: mvo asked about which compiz settings backend I was using, and I told him
<mdz> I don't think I heard more after that
<mvo> mdz: did you switched from flat-file to gconf to test if that would fix the issue?
<mdz> mvo: no
<mvo> could you please try that?
<mdz> yes
<slangasek> Mithrandir: probably true that it's not communicated well.  bug report on software-properties-gtk, maybe?
<TheMuso> pitti: If sound-juicer is removed from desktop-recommends, what will be available for CD ripping?
<mdz> mvo: seems to work
<pitti> TheMuso: rhythmbox does that just fine, and much better integrated
<TheMuso> pitti: Oh ok, I'm guessing it uses bits of sound-juicer at the backend then?
<pitti> TheMuso: I think it has its own implementation, but I'll check with Seb
<TheMuso> pitti: No big deal, just wondering.
<pitti> TheMuso: just gstreamer
<Mithrandir> slangasek: or perhaps on apt-setup.
<Mithrandir> (since I don't usually use graphical tools)
<slangasek> oh, does apt-setup handle configuring of -proposed?
<cjwatson> if you pass apt-setup/proposed=true, yes
<slangasek> hmm, difficult to document it better in the case of preseeding :)
<cjwatson> oh, you mean the comment
<Mithrandir> slangasek: it writes the initial sources.list, which could then have a url to a page telling you the policy for each pocket.
<cjwatson> apt-setup does have a comment for proposed
<cjwatson> but only if preseeded
<Mithrandir> well, this install is from back in 2004..
<Mithrandir> it's post-warty, but only barely.
 * liw does not think that warrants a system-cleaner plugin, but would not be opposed to someone writing one :)
<seb128> mdz: ok, mvo has been faster than me on this one ;-)
<mdz> mvo: which one is the default?
<mdz> mvo: I don't think I ever changed it
<mvo> mdz: the default is gconf, but I suspect for a brief period the gconf plugin was broken and then compiz automatically switches back to flat-file
<pitti> asac: can we build firefox against the external rhino packages instead of using the internal copy? it just went to main yesterday for openjdk
<mdz> mvo: permanently?
<mvo> mdz: unfortunately yet, that is something that needs fixing (it should probably just fail to start instead of falling back)
<asac> pitti: rhino?
<asac> pitti: thats a java javascript interpreter
<pitti> asac: doko said ffox has an internal copy?
<asac> pitti: its developed by mozilla, yes. but afaict its not used by ffox ...
 * asac looking
<pitti> ok, thanks
<doko> so what does ffox use for js?
<asac> doko: spidermonkey
<asac> doko: e.g. xulrunner javascript
<asac> doko: dont see any rhino files in xulrunner tree ... except Development/upstream/mozilla/mozilla/extensions/irc/js/lib/connection-rhino.js
<asac> but thats not something different and we dont build the irc extension
<doko> ok
<Karnaugh> is there a rootfs.sort file for hardy anywhere?
<norsetto> asac: is it too late already for gnome-mplayer/gecko-mediaplayer?
<emgent> moin
<Hobbsee> asac: ~network-manager
<slangasek> bitwise negation of network-manager?
<Hobbsee> slangasek: there's a dget-lp too, as LP haven't implemented dget yet
<Hobbsee> slangasek: no :)
<pitti> mdz: argh, I should have interpreted "tehtool" more carefully, I guess :)
 * slangasek grins
<robertj> I'm on hardy with the -restricted driver and am getting some corruption as seen at the bottom of the image at http://pr0t0n.homeip.net/~robertj/boohoo.png, is this a known issue or should I file a bug? Also, what is this kind of visual corruption called so I can better search launchpad?
<Riddell> cjwatson: casper fix for KDM committed, should I upload?
<Riddell> cjwatson: was there a bug for that?  I don't see it in the milestone list
<pitti> for a few days now I get empty root-owned "2.6.26" files in my home and other directories; does that happen to other people as well?
 * pitti blinks at the kernel team
<pitti> Riddell: any luck with polkit-kde yesterday?
<Hobbsee> pitti: not here
<Riddell> pitti: no, didn't get an answer from the author either about what's happening with it, will poke him again
<pitti> Riddell: ok; do you actually aim for getting that into intrepid, or are you fine with kdesudo for the time being?
<Riddell> pitti: kpackagekit is working well and uses policykit so I hinted when I e-mailed them yesterday they might want to look at polkit-kde
<pitti> Riddell: right, I saw your mail on the upstream ML
<Riddell> pitti: I doubt it's worth me spending time on it, so I guess kdesudo is the working plan
<tseliot> ï»¿Riddell: what's the problem with polkit-kde?
<Riddell> tseliot: "doesn't work"
<Riddell> tseliot: I don't know enough about the internals of policykit to say why it doesn't work
<tseliot> ï»¿Riddell: can I see the code?
<Riddell> tseliot: you can indeed, http://websvn.kde.org/trunk/playground/base/PolicyKit-kde/
<tseliot> ï»¿Riddell: thanks, I'll play with it and see what happens
<Riddell> tseliot: good luck!
<tseliot> I'll need it ;)
<pitti> tseliot: it complains at startup that it cannot allocate a PolkitContext or so; it doesn't actually sound like a hard bug, but I don't know how complete the implementation is in general
<tseliot> ï»¿pitti: doesn't Pardus use it already?
<pitti> might be, but maybe with an older PK or so
<tseliot> I think I have Pardus in a virtual machine somewhere. I'll look into this issue
<tseliot> found
<Riddell> tseliot: yeah, this is a KDE 4 port of Pardus' code
<tseliot> ï»¿Riddell: they still use the kde 3 version, right?
<Riddell> tseliot: pardus does yes
<Riddell> tseliot: http://svn.pardus.org.tr/pardus/devel/desktop/kde/PolicyKit-kde/
<pitti> mvo: I just tried pypolkit-0.1, BTW; it works just fine for the client side
<kirkland> pitti hiya
<kirkland> pitti: I think I was pinging about your conffile comments on ecryptfs-utils, but I understand now that you're talking about the auth-client-config bits
<pitti> kirkland: exactly
<kirkland> pitti: sorry, i had totally forgotten about those
<kirkland> pitti: those are temporary, stop gap measures, until such time as we have a pam configurator
<kirkland> pitti: i'm merging right now, and I'll fix that up
<pitti> kirkland: thanks
<pitti> kirkland: btw, since you seem to know about auth-client-config
<pitti> kirkland: I have that package libpam-ck-connector
<pitti> kirkland: after installation I need to add a line to /etc/pam.d/common-session (if it isn'tthere ye)
<pitti> kirkland: can I do that with auth-client-config?
<kirkland> pitti: yes, basically you just need to create a template for auth-client-config
<kirkland> pitti: s/template/profile/
<kirkland> pitti: auth-client-config can generate that for you, actually
<pitti> kirkland: is there an example I can look at? I need that for one of my specs
<kirkland> pitti: sure, ecryptfs-utils
<kirkland> pitti:  in intrepid
<pitti> kirkland: cool, I'll do that
<kirkland> pitti: look at debian/ecryptfs.acc
<Riddell> pitti: looks like network-manager for KDE 4 isn't ready yet, so we do need dbus-1-qt3 in main (bug 249453), also openbabel is synced for a re-review
<ubottu> Launchpad bug 249453 in dbus-1-qt3 "dbus-1-qt3 main inclusion review" [Undecided,New] https://launchpad.net/bugs/249453
<kirkland> pitti: start with a pristine PAM setup
<pitti> mvo: OTOH, my current code for obtaining a PK auth is 5 lines...
<kirkland> pitti: make your change
<kirkland> pitti: or changes
<kirkland> pitti: and then run auth-client-config -S
<tseliot> Riddel: I think that this is the full code of the kde 3 policykit package: https://svn.uludag.org.tr/uludag/trunk/PolicyKit-kde/
<kirkland> pitti: that'll generate the profile you need to add to the package
<pitti> Riddell: ok, noted
<pitti> Riddell: I'm not too scared about adding pure language bindings
<kirkland> pitti: and in your package, you'll want to install it to etc/auth-client-config/profile.d/WHATEVER
<Riddell> tseliot: yes, that looks more like it
<pitti> kirkland: it seems that ecryptfs is the only real user of that so far :)
<kirkland> pitti: hmm, jdstrand might know of some other consumers
<jdstrand> pitti: ldap-auth-config
<pitti> ah, right
<jdstrand> pitti: hi btw!
<pitti> hey jdstrand, good morning
<Riddell> slangasek: where do you notice KDE packages recommending on the dbg packages?
<norsetto> seb128: thx for confirming bug 247909
<ubottu> Launchpad bug 247909 in claws-mail "clawsmail ftbfs with gtk+-2.13" [Undecided,Fix released] https://launchpad.net/bugs/247909
<seb128> norsetto: no problem, thank you for the clear description and looking in the upstream bug tracker too
<slangasek> Riddell: did you get the url I dropped in scrollback yesterday, or shall I fetch it again?
<Riddell> slangasek: let me look in the logs
<slangasek> Riddell: it looks like ktorrent is to blame
<Riddell> slangasek: can't find it in the logs
<slangasek> Riddell: http://people.ubuntu.com/~vorlon/kubuntu-recommends-diff
<slangasek> Riddell: so one upload will apparently take out... 156MB or something :)
<Riddell> hmm, lots of kde 3 stuff in there too which shouldn't be
<slangasek> zul: so do you have an opinion on including samba 3.2 in intrepid still?
<zul> slangasek: mathiaz and I were discussing it and we think it would be a good idea
<mathiaz> slangasek: I think that's the way to go
<slangasek> ok
<slangasek> good :-)
<mathiaz> slangasek: are you planning to upload 3.2 to unstable ?
<mathiaz> slangasek: otherwise we'd have to pull it from experimental
<slangasek> mathiaz: yes, next week or so I think
<slangasek> you'll want -3, -2 isn't ready yet
<mathiaz> slangasek: if you plan to upload to unstable, then we can wait until 3.2 reaches unstable
 * slangasek nods
<zul> cool, are we going to put all of those ubuntu patches back (ie the modifications to smb.conf)
<slangasek> pull them back?
<slangasek> I hope you're going to do a standard merge :)
<mathiaz> zul: well - it will be a standard merge
<zul> mathiaz: ok thats what I thought
<jcristau> slangasek: 3.0.31 ftbfs on goetz because of an unclean chroot fwiw, in case you haven't noticed
<smagoun> cjwatson: I'm having trouble with germinate on hardy, I understand you're the one to talk to. I created a new package in ubuntu-meta (based on ubuntu-desktop) that pulls from 2 custom seeds I have in bzr. I have a custom version # for ubuntu-meta (e.g. 1.102foo1).
<mvo> pitti: thanks
<smagoun> cjwatson: when I run the update script in ubuntu-meta, it updates my new seed properly but doesn't update the changelog - it thinks there are no changes, even though germinate properly regenerates things from my updated seeds.
<slangasek> jcristau: ah, thanks; I hadn't looked too closely, still assumed it was a buildd catch-up issue
<slangasek> gar, kdelibs4-dev again?
<slangasek> Perhaps I should revisit that build-conflicts, anyway
<StevenK> update-alternatives: unable to make /usr/lib/firefox/plugins/libjavaplugin.so.dpkg-tmp a symlink to /etc/alternatives/firefox-javaplugin.so: No such file or directory
<StevenK> Has anyone seen that?
<slangasek> StevenK: not since about a month before the hardy release when it was fixed?
<ion_> benc: /etc/kernel/prerm.d/last-good-boot from my patch made it into the package, but it requires the change to /usr/sbin/kernel-helper which doesnât seem to have been applied.
<bryce_> calc: https://launchpad.net/launchpad-gm-scripts
<StevenK> slangasek: It's showing up in intrepid, which makes me curious ...
<bryce_> calc: there is a bzr branch you can check out, which has a README explaining the scripts and how to install them
<calc> bryce_: thanks!
<calc> anyone know if these 'lzma decoder' errors that people report are just due to bad downloads or something else?
<StevenK> slangasek: So, more information, please? :-)
<slangasek> StevenK: the problem is simply that the package creating the alternative has failed to arrange to create the target directory first
<slangasek> StevenK: nothing more to it than that
<StevenK> slangasek: Ahh, so I need to sprinkle in mkdir -p ?
<slangasek> StevenK: you need to ship the directories in the package...
<StevenK> slangasek: Right, so iz a icedtea-gcjwebplugin bug
<calc> bryce_: oh yea are the greasemonkey scripts still broken with the new pages?
<calc> bryce_: i tried using them but they don't seem to work
<Riddell> bryce: kcmshell4 display
<bryce_> Riddell: thanks
<bryce_> calc: btw you may want to edit the karma-suffix gm script to add teams you care about (the list is about mid-way down the script)
<bryce_> calc, also all the scripts should work.  If you find any issues (or make any enhancements), let us know.
<calc> bryce_: i found out the cp instructions apparently don't work
<calc> bryce_: and it also doesn't work if you have adblock plus unless you disable it on the lp servers
<calc> oh and you have to have ABP disabled to install the scripts as well
<StevenK> slangasek: I don't think icedtea-gcjwebplugin did this in Hardy. So I need to do it for the update-alternatives in Intrepid?
<slangasek> StevenK: it's not an update-alternatives change.
<bryce_> calc: thanks, I'll update the docs
<slangasek> StevenK: update-alternatives has TTBOMK always expected the calling package to take care that the target directory exists first
<mathiaz> slangasek: I'm working on cn=config upgrade - do you think this should be done in the preinst or the postinst ?
<slangasek> mathiaz: postinst
 * calc loves the greasemonkey scripts :)
<ion_> Funny, aptitude wanted to remove aptitude, since it was removed from ubuntu-minimalâs dependencies.
<ion_> pitti: Was that intentional?
<cjwatson> Riddell: casper> please go ahead
<cjwatson> smagoun: germinate> could I have a pointer to the bzr branches in question and a pointer to your existing ubuntu-meta package (i.e. a reproduction recipe) together with a dump of the output you're getting, please?
<mario_limonciell> smagoun, the old "lists" of packages need to be present in the directory for it to determine what's changed
<mario_limonciell> so if you were just using the bzr branch of ubuntu-meta to get started, those likely wouldn't be there
<mario_limonciell> you'd need to copy them from the latest "release" of ubuntu-meta i believe
<cjwatson> mario_limonciell: yeah, though he said he already had a custom version so I was assuming this was on top of that
<cjwatson> plus, I think germinate-update-metapackage's response to that situation would be to claim that everything was added, wouldn't it?
<cjwatson> oh, no, I'm mistaken on that one
<cjwatson> so yeah, could be something like that
<mario_limonciell> yeah at least i remembered running into that way back when when first dealing with creating a meta based off ubuntu-meta
<DarkAudit> Are these two actually bugs, or me not knowing what I'm doing: https://bugs.launchpad.net/ubuntu/+source/apt-build
<mathiaz> slangasek: IIUC all of the code related to ldbm->bdb migration in slapd can be dropped.
<slangasek> oh, we were carrying that around just for the hardy release, weren't we \o/
<mathiaz> slangasek: oh - ok - I wasn't sure about htat
<mathiaz> slangasek: if that was for hardy - then yes
<mathiaz> slangasek: that will simplify a lot !
<slangasek> yes, I think if you look back at the svn history, Russ already removed it once and I asked to re-add it for hardy's benefit (dapper upgrades)
<mathiaz> slangasek: great - that means we don't need to dump any database
<mathiaz> slangasek: should the code be kept around ?
<slangasek> mathiaz: no, that's what VCS history is for :-)
<slangasek> oh, well -
<slangasek> if you mean the code to *do* a database dump and reload, yes it should
<slangasek> since that applies every time we have to deal with a bdb upgrade or a backend change
<slytherin> Can I request here a sync to be processed that has been pending for almost a week now? Or should I leave it as it is?
<mathiaz> slangasek: ok - I'll keep the code around then - it won't be used the maintainer script though.
<slangasek> right
<ion_> benc: Hi. Did you notice my message?
<BenC> ion_: Yeah, can you send me a diff?
<ion_> benc: A new one?
<BenC> ion_: yeah, against the current tree if you don't mind
<ion_> benc: Will do, a moment.
<BenC> ion_: thanks
<slytherin> Can someone please process a sync bug - bug #247712
<ubottu> Launchpad bug 247712 in statcvs "Please sync statcvs 1:0.4.0.dfsg-2 (multiverse) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/247712
<geser> slytherin: as there is currently a developer sprint, I guess sync request make take some time to get processed
<slytherin> geser: Oh, ok
<smagoun> cjwatson: germinate> thanks for your help. I sent you mail with links to the (private for now) seeds and ubuntu-meta source
<cody-somerville> smagoun, were you able to come up with a more optimal solution?
<smagoun> cody-somerville: nope, not yet
<vbman11> so i'm sorry in advance for this question, I just got a new computer and went to compile an app when I remembered that there is a package I need to be able to compile and I forgot the name of the package.
<vbman11> can anyone help me
<LaserJock> vbman11: perhaps you're thinking of build-essential ?
<vbman11> yes!!!
<vbman11> thats it
<vbman11> thanks!
<LaserJock> vbman11: no problem
<vbman11> wow I feel stupid
<vbman11> that should come pre installed
<StevenK> Not all users want to build stuff
<vbman11> not all have to
<vbman11> It's not like it's a huge package
<vbman11> w/ all of it's dependencys
<StevenK> It is, actually.
<vbman11> how big
<vbman11> I didn't really look
<vbman11> It didn't look that big when I glanced at the numbers
<LaserJock> I can't remember if it's on the CDs or not
<LaserJock> but if it isn't then that would defiantly be why
<vbman11> ok
<LaserJock> even 1MB counts when the CD is oversized :-)
<vbman11> ohh
<vbman11> I'm setting up a mythbox
<vbman11> and I need to install ALOT of packages to get the s-video working
<LaserJock> however, it does look to me like build-essential is on the CD, but not installed by default
<vbman11> my card is an ati radeon 7000 pci
<vbman11> (really old comp, no agp or pcie)
<vbman11> ohh ok
<vbman11> well thanks for everyones help
<LaserJock> hmm, I don't really know why it's not installed, it is on the CDs, whatever
#ubuntu-devel 2008-07-18
<Hew> Hey guys, is there a page somewhere that defines the usage of depends/recommends/suggests for a package? I have an idea of what they are for, but figured there should be a guideline/policy for it somewhere to define the grey areas.
<ScottK> asac: I thought you were going to support the firefox package in Hardy?  I don't see the most recent security update for it?
<mcasadevall__> and the internet here makes **** smell like roses
<NCommander> any sponsors in the room?
<NCommander> er
<NCommander> wrong room
<mouz> pitti: new grep fails to authenticate?
<pitti> mouz: authenticate? how do you mean?
<mouz> pitti sorry: the package could not be authenticated. when doing the upgrade.
<mouz> pitty plz ignore :)
<asac> ScottK: its on its way.
<pitti> mouz: that sounds like a mirroring problem rather, not specific to grep
<Keybuk> has anybody got a spare buildd I can borrow
<Keybuk> (would like to find out what will break if I upload libtool 2.2 to the archive
<pitti> o_O? don't we have enough?
<Keybuk>  best way seems to be rebuild the archive with it)
<Keybuk> uploading it to the _real_ archive and using the usual buildds seems to be the second best way
<evand> Can someone else with access to ubuntu-devel run through the moderation queue today?  Broadcom decided I should no longer have access to the machine with my listadmin configuration.
<tseliot> pitti: can you upload these packages to Intrepid, please? They only remove a useless file. http://albertomilone.com/ubuntu/newlrm/pitti/links.txt
<pitti> tseliot: meeting, I'll do it later
<tseliot> pitti: ok, thanks. And maybe you could also move these from hardy-proposed to hardy-updates: https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-envy-2.6.24/+bug/246301
<ubottu> Launchpad bug 246301 in linux-restricted-modules-envy-2.6.24 "Update the FGLRX and NVIDIA driver to 8.6 and 173.14.09" [Undecided,Fix committed]
<calc_> bdmurray: it looks like the graphs messed up last night or at least the OOo ones did
<calc_> oops
<calc> bdmurray: you do generate the graphs and bryce did the web interface (right?)
<ion_> Nice, the new compcache patch might actually fix the bug iâve been running into. http://code.google.com/p/compcache/wiki/Changelog
<bdmurray> calc: that's correct
<bdmurray> calc: that's really odd if you look at the csv file it shows low numbers but not zeros
<calc> bdmurray: yea, i wonder why it reported incorrect numbers, instead of just not at all
<cjwatson> evand: ubuntu-devel> partly done
<evand> much appreciated
<Wubbbi> Bug in Ubuntu Intrepid found: Synaptic Installs things sucsessfull but he dont close. It is installed but after it was installed he freezed up :(
<slangasek> jelmer: hrm, why am I having to pull a source package in order to be able to review bzr-cvsps-import, instead of checking out a bzr branch? ;)
<pitti> tseliot: your upload list doesn't have -173, is that already correct?
<pitti> tseliot: rest uploaded
<pochu> pitti: hi, could you remove emesene from the hardy-proposed unapproved queue? I uploaded it with a wrong version number
<pitti> pochu: done
<pochu> thank you
<tseliot> ï»¿pitti: yes, 173 was not affected by the "problem"
<tseliot> ï»¿pitti: thanks for the upload ;)
<tseliot> ï»¿pitti: did you move the drivers from -proposed to updates too?
<pitti> tseliot: just at it
<tseliot> ï»¿pitti: super! :-)
<ScottK> asac: Thanks.
<asac> ScottK: i guess it will go out today. we just have to wait for security team to wake up ;)
<ScottK> Understand.  I just wanted to make sure it wasn't missed.
<asac> sure. thanks. feel free to remind me ;)
 * Hobbsee ntoes that nm on intrepid seems to have spontaneously fixed itself.  \o/
<slangasek> Riddell: kubuntu desktop image sizes haven't come down because kdeplasma-addons is uninstallable, causing the livefs build to fail
<Wubbbi> slangasek: Please report it here #kubuntu-devel
<slangasek> Wubbbi: erm, I don't intend to join a separate channel to let Riddell know about livefs build problems, sorry
<Wubbbi> slangasek: ohhh ... ok sorry ^^ i have read wrong ^^
<slangasek> ok :)
<Riddell> slangasek: ah hah
<Riddell> slangasek: coincidently that's actually the next think on my todo list for looking at
<slangasek> ok :)
<ion_> benc: Judging from the changelog, the new compcache patch probably fixes the system hang iâve been running into. http://code.google.com/p/compcache/wiki/Changelog
<slangasek> hmm I'm repeating myself
 * pitti discovers gdmflexiserver --monte-carlo-pi and wonders how much other useless crack we ship on CDs by default
<slangasek> wtf
<Robot101> its not even very good at calculating pi :P
<slangasek> why is that in there?
<slangasek> yeah, that's an awful long time to get the first 5 digits right
<pitti> slangasek: for the same reason as Alt+F2 "free the fish" is
<cody-somerville> What does --monte-carlo-pi do?
<Mithrandir> calculate pi.
<Mithrandir> slowly.
<cody-somerville> Atleast the gnome folks are consistent.
<Wubbbi> bug 249850
<ubottu> Launchpad bug 249850 in synaptic "Synaptic Freez up after installing Packages" [Undecided,New] https://launchpad.net/bugs/249850
<mvo> hello Wubbbi
<mvo> Wubbbi: could you please attach the output of pstree -a to the bugrpeort?
<Wubbbi> mvo: done :)
<Wubbbi> mvo: and brause is because ... I have a stupid keyborad ^^
<pitti> daemon/slave.c:static gboolean gdm_can_i_assume_root_role (struct passwd *pwent);
 * pitti thinks it would be better to stop poking in gdm code soon...
<mvo> Wubbbi: hm, the pstree output does not list synatpic currently, is it no longer available when the freeze happens?
<Wubbbi> mvo: yes. I can select my KDE Desktop withput problems. Just Synaptic is frozen and I cant use it anymore. I have to kill it :(
<Wubbbi> but to packages are installed without problems
<mvo> Wubbbi: ok, the pstree output does not contain synaptic, could you please run it (pstree) before you kill synaptic so that I can see what processes are running when it hangs?
<mvo> Wubbbi: could you also please open a terminal window (e.g. konsole) and run "sudo synaptic" and see if that shows the hang then too? or if it only happens if you run it via the menu (by the means of gksu)?
<Wubbbi> mvo: ok wait ^^
<Wubbbi> mvo: I dont know why but now it works without freez up! O.o ... sorry xD
<Wubbbi> Very Strange
<mvo> Wubbbi: so it does work with sudo in a terminal but it does not when you run it from the menus?
<Wubbbi> wait let me test
<mvo> Wubbbi: please add this information to the bugreport, that is pretty useful
<Wubbbi> mvo: ok it just work with terminal :/
<MacSlow> seb128, looks like I've just to add a minor patch to clutter-gtk... so it should be pretty easy and fast
<Wubbbi> at these momtent Synaptic is freezed up.
<MacSlow> seb128, but first I need to test it with my test-case and the drawingcode from gdm
<seb128> MacSlow: no problem, let me know when there is a package to upload
<Wubbbi> you need any informations?
<mvo> Wubbbi: please add this information to the bugreport, when it freeze and (if/when) it does not freeze
<Wubbbi> mvo: done
<Wubbbi> mvo: can i kill synaptic or do you need any information while it's frozen?
<mvo> Wubbbi: the pstree output would be good (if you haven't added that already while it is frozen). other than that, it hsould be fine for now, but I may come back later
<mvo> Wubbbi: and ask for more infomation (depends on if I can reproduce it or not)
<Wubbbi> mvo: ok ... the pstree doesn't change. See you :)
<calc> where are the 8.04 release notes?
<slangasek> the editable ones, or the published ones?
<calc> ah i found them with the search :)
<calc> the published one, i found it via search
<calc> it appears not to be linked very well
 * calc had to reference it to close a bug :)
<slangasek> they're linked from the installer, and I think from the release announcement mail-
<slangasek> mails
<jelmer> slangasek: OpenChange should work better for you now - it was missing a dependency on doxygen
<slangasek> hmm
<slangasek> and adding that build-dep fixed it?
<slangasek> if so, you're missing something in your clean target, because I saw a doxygen error earlier, installed it, and tried a rebuild - got the error
<jelmer> slangasek: ah, I should of course be running distclean
<slangasek> aha :)
<jelmer> should be fixed now
<ion_> benc: Did you get my message? :-)
<liw> is there a tool for corrupting a filesystem (so that one may test fsck)?
<ion_> liw: dd if=/dev/zero of=/dev/sda1 :-)
<BenC> ion_: yes, have you confirmed it?
<BenC> liw: disconnect the driver during a copy of a lot of files
<BenC> s/driver/drive/
<pitti> liw: ext3?
<liw> pitti, ext3, yeah
<pitti> liw: tune2fs -s 0 /dev/bla; tune2ds -s 1 /dev/bla
<ion_> benc: Sorry, no. The crash just seems to match with the changelog description perfectly: a backtrace is dumped from notify_swap_entry_free and the system hangs.
<pitti> liw: that won't actually break anything, but forces an fsck
<liw> pitti, I'm actually looking for somethign to break things so that fsck finds errors, but that will get me started
<pitti> liw: then just do -s0, fsck will complain a lot
<pitti> but be warned, that might really fuck up your fs
<pitti> so don't do it on a partition which you still need
<ln-> i think the freenode channel guidelines forbid the use of the word "fuck".
<pitti> *cough*; /me edits history to say "screw"
<BenC> ion_: are you sure that the compcache patch doesn't cause the problem?
<BenC> ion_: notify_swap_entry_free() doesn't exist unless you patch in compcache
<ion_> benc: http://heh.fi/tmp/compcache-crash-log
<liw> pitti, I'm running this against an fs in a file, so no worries about screwing up the system :)
<ion_> benc: Thereâs a new compcache patch. From its changelog: âFixed incorrect BUG() in notify_swap_entry_free() callbackâ
<liw> oh, wow, e2fsprogs not only has an LSM file, it has an up-to-date LSM file
<BenC> ion_: ah, I was thinking you meant the patch in our kernel
<BenC> ion_: I'll check the patch, thanks
<ion_> benc: The one currently in the Ubuntu kernel causes the crash.
<ion_> benc: Thanks
<ion_> The new patch: http://compcache.googlecode.com/files/patch_compcache_with_notify_support_2.6.26.diff
<\sh> pitti: would you like to take a look at bug 246911 or should I just upload the changed bits to intrepid?
<ubottu> Launchpad bug 246911 in ia32-libs "[Wishlist] please add libnspr4-0d to ia32-libs" [Wishlist,New] https://launchpad.net/bugs/246911
<pitti> \sh: if it's sane, just upload it
<\sh> pitti: well, it's much ;)
<\sh> pitti: but will do it this evening..so I can request a backport to make me happy on hardy and my army of flash media servers
<BenC> ion_: committed
<ion_> benc: Thanks!
<asac> norsetto: any reason why gecko-mplayer wont work with 1.0~rc?
<asac> the depends appear to be too  high for debian
<norsetto> asac: thats what upstream recommends
<asac> if you say its ok to use >= 1.0~
<asac> then i will just bump and upload now
<asac> norsetto: yeah. but 1.0 is not available in sid here
<asac> so not installable ;)
<norsetto> asac: I see
<norsetto> asac: can we wait few hours, I can ask upstream to make sure, or if you want to test it, I can only test in a sid chroot?
<asac> norsetto: i guess i can just bump it
<asac> norsetto: yes. please test in a sid chroot
<asac> my chroot is at home and doing that through internet is not really going to go ;)
<asac> if it starts and works somehow its good enough
<norsetto> asac: hmm, perhaps you should have said that in a query ;-)
<asac> norsetto: no ;)
<asac> thats fine ;)
<asac> norsetto: ok i dumped the revision and took the responsibility by adding a comment in changelog for that under a [Alexander Sack] banner
<asac> norsetto: let me know if thats ok with you ;)
<asac> norsetto: http://paste.ubuntu.com/28285/
<norsetto> asac: no need to do that, just bump it and don't mention it in the changelog, if there are problems I'll take care of that
<asac> ok
<norsetto> asac: its my fault, I should have checked the deps in sid to be sure
<asac> norsetto: no problem
<seb128_> jcastro: https://bugs.edge.launchpad.net/bugs/bugtrackers/gnome-bugs/%s
<seb128_> soren: hey, is virtualbox known to be broken in intrepid?
<seb128_> virtmanager rather
<soren> seb128_: There appear to be some issues w.r.t. installing new vm's from it, yes.
<seb128_> soren: clicking on the "choosing installation method" next button doesn't do anything
<soren> Ok.. that might be a side effect of the same bug.
<seb128_> any workaround?
<soren> So yeah, it's known, but I don't have a fix for it right now. Sorry.
<seb128_> would downgrading something to the hardy version workaround the issue?
<soren> Try installing python-virtinst from Hardy.
<soren> If my hypthosis is correct, that's the actual culprit.
<seb128_> soren: do I need to restart something after installing that?
<soren> seb128_: virt-manager.
<seb128_> no change
<seb128_> do I need to be in the kvm group?
<cjwatson> Riddell: I think oem-config and ubiquity might need to be updated in similar ways to casper - could you check please?
<cjwatson> Riddell: at least for the autologin stuff
<soren> seb128_: Depends on what you're trying to do.
<seb128_> I'm trying to boot an iso
<soren> seb128_: It certainly can't hurt :)
<Riddell> cjwatson: ok
<soren> seb128_: You need it if you're interacting with qemu:///session rather than qemu:///system.
<soren> seb128_: You need membership of libvirtd to interact with qemu:///system.
<seb128_> yes
<seb128_> and virt-manager was working fine in hardy
<soren> Perhaps this it the right time to upgrade my laptop to intrepid. :/
<seb128_> I did upgrade on monday
<soren> seb128_: Oh, right. Well, if it worked in hardy on the same machine, then you should not need additional memberships or anything.
<seb128_> things are mostly working
<seb128_> that's what I though
<soren> My workstation at home has been running intrepid since it opened. I just kept the laptop on hardy to be able to reproduce KVM bugs.
<pitti> kvm hates me in intrepid, too, feels like a pot of tar; it takes half a week to start the desktop CD...
<seb128_> pitti: eventually it starts for you ;-)
<liw> intrepid under hardy kvm fails to boot for me, though
<seb128_> mine just refuse to go to the next wizard stage and let me choose an iso
<cjwatson> intrepid-in-intrepid WFM
<cjwatson> except that there's no mouse cursor in the booted image
<cjwatson> (except for very briefly as the desktop is coming up)
<seb128_> soren: "kvm -m 512 -cdrom iso" is working
<soren> Right. It's totally a virt-manager and/or virt-install problem.
<soren> liw: intrepid under hardy needs "no-kvmclock" on the kernel command line.
<soren> intrepid under intrepid needs a kernel based on 2.6.26 final (which I believe is what the current kernel packages are).
<liw> soren, cool, I'll try that when I get back home
<paran> There is a fixed kvm in hardy-proposed that can boot intrepid without any kernel parameters. However for me it then fails to start Xorg
<mathiaz> slangasek: still working on the slapd upgrade code - I'm trying to figure out how to support systems that don't want to migrate to slapd.d
<mathiaz> slangasek: I'm going through the functions in scripts-common. What should they return when slapd.conf is used ? 0 or 1 ?
<mathiaz> slangasek: I think they shouldn't fail if slapd.conf is used
<seb128_> soren: do you know how I can switch to a vt in a kvm box?
<slangasek> mathiaz: why do we want to give them the option not to migrate? :)
<seb128_> ctrl-alt-f1 switches on the real box
<slangasek> mathiaz: if they don't migrate, then *none* of the other package integration work we're trying to lay on top of this will function, and we'll have to continually special-case those systems
<slangasek> mathiaz: for a use-case that upstream says is going away within a few revisions anyway
<mathiaz> slangasek: there are some modules currently that don't support slapd.conf
<TheMuso> seb128_: Are you using virt-viewer?
<mathiaz> slangasek: *slapd.d*
<soren> seb128_: Depends on your client.
<seb128_> TheMuso: no, I'm using kvm, virt-manager doesn't work
<soren> seb128_: Some clients have a dropdown with "interesting" keypresses you can send.
<slangasek> mathiaz: but from the conversations at UDS, my understanding was that we would either fix or drop those for intrepid
<seb128_> soren: using "kvm -m 512 -cdrom iso"
<slangasek> well, upstream would fix them or we would drop them
<slangasek> ;)
<mathiaz> slangasek: hm. So we'd force user to upgrade to slapd.d/
<slangasek> mathiaz: I don't remember precisely which modules were affected, but I thought they weren't critical ones?
<mathiaz> slangasek: if they don't want, they cannot upgrade.
<mathiaz> slangasek: there probably not critical
<mathiaz> slangasek: they're probably not critical
<slangasek> mathiaz: I think it would be fine to detect use of those modules in preinst and abort the upgrade
<mathiaz> slangasek: ok - the same way as ldbm was handled
<slangasek> (mvo might disagree, but this is server stuff, so pff :)
<slangasek> right
<mathiaz> slangasek: ok - so that supplifies the logic
<Zorocke> Hey peoples, i am looking to contribute a bit to the open source world.
<Zorocke> i have some C++ programming expeirence.
<Zorocke> experience*
<soren> seb128_: Sorry about the long response times here... )
<soren> seb128_: You can do ctrl-alt-2 to get to the monitor.
<seb128_> soren: no problem, I guess I'll not get virt-manager working today anyway
<soren> seb128_: in the monitor, you type: sendkey ctrl-alt-f2
<soren> seb128_: That'll send ctrl-alt-f2 to the guest.
<seb128_> ah ok, good to know
<seb128_> thanks
<soren> seb128_: and then you do ctrl-alt-1 to get back to the actual guest.
<soren> seb128_: Any time :)
<geser> seb128_: is a comment in a sync request enough to get a package moved from multiverse -> universe or do you/the archive admins want a seperate bug for it?
<seb128_> geser: better to have a different bug
<geser> seb128_: ok, will file one then
<seb128_> geser: I usually just check that the sync has been acked to sync something, better to have other requests in an another bug, not sure about other archive admins though
<slangasek> jelmer: openchange packages now build here correctly in a pristine env, cheers
<slangasek> pitti: do we still have both versions of sqlite in main for intrepid, or have we managed to trim the one that was only needed for upgrades?
<pitti> slangasek: still four sources using sqlite: bacula, cyrus-sasl2, php5, qt4-x11
<slangasek> and sqlite is the old one?
<pitti> qt is just bindings I suppose which we could probably disable
<slangasek> yes, it appears to be
<slangasek> php5 is bindings; I failed to manage that transition on the Debian side in a timely manner, and now I don't care about php anymore
<Riddell> cjwatson: hopefully CIA just told you I commited the kdm change to ubiquity and oem-config
<mdz> mvo: hmm, dist-upgrade won't upgrade ubuntu-desktop at the moment
<mdz> needs to remove gnome2-user-guide and scrollkeeper, install rarian-compat
<pitti> cjwatson already tried to demote scrollkeeper to extra and promote rarian-compat to optional, but that didn't help
<pitti> apt- doesn't want to upgrade, but apt-get install rarian-compat works
<mdz> pitti: 2 packages > 1
<mdz> we don't need scrollkeeper anymore?
<seb128_> rarian-compat conflicts, provides, replaces scrollkeeper, not sure why apt doesn't like it
<mdz> oh
<pitti> it's replaced by rarian-compat
<pitti> I had the same problem with cups, though
<mdz> seb128_: what's wrong with gnome2-user-guide?
<seb128_> mdz: looking, I'm not aware of any issue on this one
<pitti> it wouldn't auto-replace/upgrade with only one reverse dependency, but with several it did
<mdz> seb128_: ah, versioned depends on scrollkeeper
 * thom dances briefly on scrollkeeper's grave
<pitti> so I ended up doing an empty transitional package
<mdz> seb128_: change that to rarian and that should make apt happy
<seb128_> mdz: where? I thought I fixed those
<mvo> mdz: hm, should be fine for release-upgrades, the meta-packages get a explicit upgrade call if they are not upgraded as part of dist-upgrade
<mdz> mizar:[~] apt-cache show gnome2-user-guide | grep Dep
<mdz> Depends: scrollkeeper (>= 0.3.14-5)
<pitti> we could just remove scrollkeeper from the archive and let rarian-compat build an empty transitional scrollkeeper?
<mdz> mvo: I'm just dist-upgrading within intrepid
<seb128_> mdz: oh, gnome2-user-guide is an old thing
<pitti> hm, if that works, it would be nice as well
<seb128_> mdz: it has been renamed gnome-user-guide some time ago
<pitti> mdz: does it actually compare for ">1" or "packages depending on scrollkeeper" > "packages depending on rarian"?
<mdz> seb128_: heh, it's from edgy
<slangasek> renamed but without an upgrade path
<slangasek> (no transitional package)
<mdz> I wonder why the  release upgrader didn't remove it
<seb128_> iz mvo bog
<mdz> pitti: sort of the latter, but not exactly
<seb128_> should we change the depends to rarian-compat | scrollkeeper rather than scrollkeeper | rarian-compat during the cycle when touching those sources?
<mvo> mdz: I suspect that the release upgrader back in edgy did something wrong and later it was no longer be able to figure out if the gnome2-user-guide package was a manual (explicit) install or a left-over
<mdz> seb128_: why not just change to rarian-compat and drop scrollkeeper?
<seb128_> that works too
<seb128_> I was just curious to know if inverting the order would make apt happier
<mdz>   Considering scrollkeeper 39 as a solution to rarian-compat 22
<mdz>   Holding Back rarian-compat rather than change scrollkeeper
<mdz> it likes scrollkeeper 77% more than rarian-compat
<seb128_> we should just use aptitude
<mdz> you need to tell it that you love rarian-compat
<slangasek> depending only on rarian-compat would seem to make the relationships more rigid (-> fragile), no?
<seb128_> it's smarter about those things usually ;-)
<mdz> seb128_: troll :-)
<mdz> haha
<mdz> mizar:[~] sudo aptitude upgrade
<mdz> [...]
<mdz> The following packages have been kept back:
<mdz>   ubuntu-desktop
<mdz> The following packages will be REMOVED:
<mdz>   gnome-bin{u} gnome-libs-data{u} libart2{u} libdns42{u} libelfg0{u}
<mdz> (16 packages removed)
<mvo> it is smarter ;)
<slangasek> seb128_: this must be some definition of "usually" meaning "at one point in the distant past", right? :)
<mvo> that gnome stuff is not needed anyway
<seb128_> yeah, that's GNOME 1
<realist> I actually lol'ed just now.
 * seb128_ wonders how much old crap are installed on mdz's box
<mdz> seb128_: it removes 16 packages but still doesn't upgrade ubuntu-desktop :-P
<slangasek> we should all get images of mdz's box to use for upgrade testing
<mvo> !
<mvo> that is a excellent idea :)
<Keybuk> mdz: I blame the previous maintainer
 * ion_ uses debfoster to get rid of the old crap. And ams-run debfoster to synchronize its idea of which packages are installed manually and which automatically to apt and aptitude. :-)
<ion_> It would be neat if aptitude had debfoster-like functionality.
<mdz> ion_: it does, and so does apt
<mdz> The following packages were automatically installed and are no longer required:
<mdz>   openoffice.org-filter-binfilter libdns42 libelfg0 render-dev xmms
<ion_> No. aptitude considers all packages it doesnât specifically know about manually installed. debfoster asks about them and only keeps the ones the user specifically chooses to keep manually installed.
<mdz> sounds like a lot of questions
<mvo> ion_: a long time ago aptitude did it the other way around and people got confused when half of their system got removed suddenly :)
<ion_> Not really *that* many, since it only asks about the ones on the top (or bottom, whichever way you think of it) of the dependency tree.
<mdz> why is libelfg0 still in main?
<seb128_> because the archive admins are slackers? ;-)
 * mdz glares at bug-buddy
<liw> I use a custom meta package (or set of them, actually) to keep track of which packages I am specifically interested in; apt/aptitude mark all manuall istalled packages as "wanted", which is not what I want, when I just briefly try a new program
<ion_> And i donât want that functionality to be aptitudeâs default. I want it to be something you can optionally launch from a menu.
<mdz> seb128_: the bug-buddy maintainer is a slacker, apparently
<seb128_> mdz: I did this change!
<seb128_> doh, didn't upload
 * seb128_ uploads now
 * pitti demotes in the meantime
<pitti> seb128_: no more build depends for you :)
<Keybuk> pitti: could you demote dselect while you're in there?
<mdz> clearly you guys discovered that there's beer in the fridge
<jcastro> beer?
<LaserJock> lol
<ion_> There is, but nothing any good.
<slangasek> jcastro: you can't have any, you're too young
<seb128_> jcastro: do you have an highlight on beer? ;-)
<jcastro> oh, shucks
<elmo> apart from keybuk being a horrific troll, what's the rationale for demoting dselect?
<slangasek> it takes up space and we don't use it? ;)
<Keybuk> elmo: we do not, by any stretch of the imagination, support it
<seb128_> elmo: nobody is maintaining it actively
<ion_> What, dselect still exists? ;-)
<Keybuk> any bug starting with "I used dselect to" is met by laughter and scorn
<pitti> it will just cause yet another instance of main/universe skew, but *shrug*
 * seb128_ got beer, thanks mdz
<slangasek> it's been largely superseded by dpoll
<elmo> slangasek: I use it
<mdz> elmo: it's unmaintained upstream?
<elmo> Keybuk: I've yet to see such laughter and scron
<Keybuk> elmo: we do it behind your back :)
 * pitti still uses dselect
<ion_> :-)
<seb128_> pitti: troll!
<slangasek> elmo: so you want your dpkg front-end of choice to be one maintained by mrvn?
<elmo> mdz: it wasn't any more unmaintained than dpkg, last I looked?
<seb128_> let's move dpkg to universe then ;-)
<seb128_> maybe we can use rpm
<mdz> elmo: it gets built, but no one is fixing its bugs
<pitti> packagekit!!!
<Keybuk> when I took over dpkg, we decided to stop maintaining dselect
<mdz> seb128_: I hear rpm packaging is easier anyway
 * slangasek moves pitti to universe
<Keybuk> well, actually, Colin said he would ... and then he ran away
<mdz> seb128_: and it's already in main
<seb128_> see ;-)
<ion_> No, no, no. Ebuilds.
<Keybuk> dmerge!
<seb128_> mvo: want to maintain rpm for us?
<elmo> slangasek: if I thought he was actually going to do anything, I might be vaguely concerned
<mdz> seb128_: we can use autopackage, then upstreams will do the packaging for us
<stgraber> why is rpm in main btw ? only for file-roller ? :)
 * liw votes for replacing dpkg with bzr
<slangasek> stgraber: lsb, perhaps
<Keybuk> elmo: are you going to start fixing the open bugs against dselect?
<seb128_> file-roller doesn't depends on rpm
<elmo> however much certain members of the distro team might hate it, dselect works and works well for me.  "it's not being actively worked on" could be said of a lot of software in main, as long as it's bugs are not actively causing problems, I don't think that's necessarily a problem
<mvo> seb128_: rpm++
<slangasek> bzr -BORGiE
<stgraber> slangasek: ah, right lsb.
<elmo> Keybuk: so, if 'fix bugs or it gets demoted' is the attitude, I have several bugs against other packages in main I could point you to?
<liw> wouldn't life be so much simpler if we delivered Ubuntu as a bzr branch, which contains a full installed system (anyone wanting to select which software they have installed could just go to Gentoo)
<thom> slangasek: the dpoll pun was terrible, btw. (since no-one else seems to have abused you for that)
<Keybuk> elmo: if nobody was even looking at the bugs, I would certainly not like to ship that software
<LaserJock> gosh, that would be fun to branch :/
<james_w> liw: if only you were able to put VM images in bzr
<elmo> Keybuk: oh please
<slangasek> thom: thanks :-)
<stgraber> liw: you could you multiple bzr branch and use unionfs to have different "packages" installed :)
<stgraber> *you could have
 * LaserJock sticks each of stgraber's limbs in a bzr branch and tries to unionfs them
<liw> otoh, we could convert each .deb into a bzr branch, put them into /bzr/$packagename, then have a script that symlinks from /bin and /usr/bin etc to /bzr/$packagename... yeah, this is a good idea, can I do that for intrepid?
<slangasek> liw: python kernel first
<Keybuk> liw: why not take the opportunity to switch to /System, /Libraries, /Programs and /Users? :-)
<liw> Keybuk, I was thinking of writing a kernel module that does gettext on pathnames so that we can have those names properly localised for the user, based on $LANG
<Keybuk> fuse-as-root!
<ion_> Letâs switch to C:\Ubuntu\System32, C:\Program Files etc.
<liw> slangasek, oh yeah, that old thing, I really should finish it, shouldn't I? let's see, I got as far as saying "mkdir linux.py && cd linux.py && bzr init"... so it's almost done
<seb128_> ogra: rather here, are you sure you can't lock a gnome-panel position?
<slangasek> liw: yes, all you need is a memory manager and I/O, and the Internet will write all the drivers for you quickly enough
<ogra> seb128_, i only found a global key
<liw> slangasek, Python already manages my memory for me, and I have a novel, revolutionary idea for doing I/O, based on the fact that pidgeons can make enough noise to emulate an acoustic modem
<ogra> but that also disables right click and all options of applets ... as well as adding/removing applets indeed
<seb128_> ogra: /apps/panel/toplevels/top_panel_screen0/orientation?
<ogra> thats lockable ?
 * ogra checks
<seb128_> ogra: wouldn't setting a mandatory key work there?
<Keybuk> what's worrying is that I briefly wondered whether you _could_ write a kernel in Python
<seb128_> ogra: well, gconf has a mandatory key concept, sysadmins can force a key value over the user
<Keybuk> and then realised that Emacs already has one in lisp ...
<seb128_> ogra: not sure how much the code would like that though
<ogra> seb128_, hmm, i have never used that out of a gconf defaults file
<elmo> so, out of 70 bugs open in Launchpad for dpkg, 2 are related to dselect, AFAICT
<tseliot> ï»¿Keybuk: a kernel in Python wouldn't have to be (re)compiled. Yay!
<Keybuk> tseliot: and you get pdb for free ;)
<ogra> seb128_, is there any magic to do it from /usr/share/gconf/defaults ?
<liw> I am now planning to use bsddb for storing the process list
<seb128_> ogra: no
<ogra> hmm
<seb128_> that's an administrator thing usually
<Keybuk> elmo: at least 15,000 bugs can be blamed directly on dselect's existance
 * liw stops trolling and lets the channel return to being useful
<seb128_> ogra: http://library.gnome.org/admin/system-admin-guide/stable/gconf-7.html.en
<ogra> right, thats what i thought
<ogra> merci !
<Keybuk> removing it from existence would make the universe a better place, and instantly fix them
<elmo> one of which is a UTF-8 bug with a patch, being actively tracked in Debian
<elmo> the other is likely a duplicate of the same bug/issue
<ogra> seb128_, hrm, that requires gconfd to be running :/ tricky ...
<seb128_> ogra: gconf is autospawned when you call gconftool
<ogra> right, but i dont know if it likes that in a chroot :)
<ogra> i'll fiddle with it
<seb128_> otherwise doing a code patch should not be too hard
<seb128_> to lock a panel position
<ogra> seb128_, well, i dotn reallly want to maintain another package in a separate repo
<ogra> the kernel already gives me a lot of headdache
<seb128_> ogra: well, we could sru this
<ogra> (i'm forced to hardy)
<ogra> hmm, does that qualify for SRU ... its actually a new feature
<cody-somerville> \o_
<seb128_> ogra: well, if the patch is easy enough and required
<ogra> but that would indeed be the best way to go
<ogra> i assume lexington would like to use it too, they have similar screen constraints everywhere
<seb128_> will talk with vuntz about that
<seb128_> but that's not going to be today
<seb128_> brb
<stgraber> ogra: IIRC you can use gconftool without having gconfd running, it directly changes the xml file then
<stgraber> ogra: I use that to disable suspend and similar things when generating a fat client chroot
<ogra> stgraber, ah, that would be cool
<ogra> i will try that
<stgraber> gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --set --type bool /apps/gnome-power-manager/general/can_hibernate false
<ogra> seb128, btw, if we could SRU a fix for bug 247501 that would be very good, i know the guys here areound have a fix that adds another tab and moves elements over, and i'll take a look at that the next days how intrusive that is
<ubottu> Launchpad bug 247501 in cmpc "gdmsetup window is truncated by low resolution screen." [Medium,Confirmed] https://launchpad.net/bugs/247501
<seb128> ogra: UI changes are usually not an option for sru
<ogra> ah, k
<ogra> seb128, hmm, setting the mandatory key results in a big warning on first boot after install about "the admin has locked this setting, it will be set as a readonly setting to your defaults"
<seb128> not good
<ogra> no
<ogra> hmm
<ogra> beyond that it works as intended though
<ogra> seb128, ah, the default panel setup touches the same value as well, if i drop it there the message is gone
<seb128> drop what?
<ogra> the reference to the orientation key for the toplevel panel
<ogra> seb128, http://paste.ubuntu.com/28321/
<ogra> that avoids the msg
<mkrufky>  Is Steve Langasek in here?
<crimsun_> yes, slangasek.
<mkrufky> slangasek: ping
<mkrufky> crimsun_: thanks
<slangasek> 'morning
<mkrufky> hi... i'm the contact for anything hvr950q or sms1xxx related
<slangasek> I noticed :-)
<mkrufky> slangasek: you just touched a bunch of bugs saying "verification needed"
<mkrufky> i mailed out samples to canonical
<mkrufky> and i have tested all those patches BEFORE i merged them upstream and then backported into LUM
<mkrufky> what else should I do ?
<seb128> ogra: ah ok, workaround for your installation maybe then but we should still look at a clean solution
<ogra> yeah
<slangasek> mkrufky: it's not necessarily required that you do anything personally here; we do need in-the-wild verification that the new packages don't regress anything (which is unlikely since these are entirely new drivers), and our SRU QA processes will address that.  It's ideal to also have in-the-wild verification that the packages, as uploaded, actually work on the intended hardware - again, not necessarily something that you have to do pers
<slangasek> hmm, do I have splitlines turned on
<mkrufky> slangasek: that'll be rough, since that hardware itself is not "in the wild"
<liw> slangasek, your line ended "have to do per"
<slangasek> ... personally, but given that I don't know where  within Canonical that hardware is, it might not be a bad idea
<mkrufky> slangasek: this is all for belmont, and we decided to not *only* add support for belmont.  we want users to be able to use their sticks on their OTHER ubuntu machines too
<slangasek> liw: so evidently, I do not have splitlines turned on ;)
<mkrufky> slangasek: ...and I have a very limited supply of samples.  it's possible that the canonical allocations went to {the customer} before getting to canonical ... that i dont know.
<slangasek> mkrufky: er, I wouldn't have any idea, frankly
<cjwatson> mkrufky: just as a general policy, *all* SRU bugs require verification of some kind; I wouldn't recommend tilting at this windmill because previous attempts to bypass it have resulted in Things Going Horribly Wrong, but the exact nature of the verification is open to negotiation
<mkrufky> dont get me wrong -- i dont want to be an exception to any rule
<slangasek> I don't even know what Belmont is, other than having now seen via SRUs who some of the people involved are :)
<mkrufky> all i want is to know what is expected of me
<cjwatson> mkrufky: "verification needed" is not necessarily directed at you personally; it is also a directive to the Canonical QA team that they need to verify this bug
<mkrufky> ok, good to know.
<mkrufky> im not sure that any of them have the hardware..... unless mario_limonciell counts :-)
<cjwatson> if Canonical has the hardware, our QA team should be able to get access one way or another
<slangasek> well, anyone who has the hardware should please check that the binary packages actually work as intended
<mkrufky> pmcgowan has the hardware
<mkrufky> ok, cool... thanks for explaining
<ogra> seb128, gah, i missed that there was still a gconfd runing, removing it didnt actually fix it, so i'll wait for the real fix and keep it completely locked until thats there
<seb128> ok
<norsetto> asac: I have spoken with upstream about the gnome-mplayer problem, I'm trying to convince him to not have gmo created by his make dist. In any case, I have a patch available that solves this. What is the best way forward?
<jdstrand> no-- added to my todo list
<Awsoonn> for the clock it 8.10 it gives a list of locations that can be added to the applet, where does it get the list from?
<Awsoonn> 8.10 and 8.04 accually
<norsetto> Awsoonn: check the source code
<Awsoonn> :)
<mario_limonciell> mkrufky, you still here?
<mario_limonciell> it's the -20 kernel that will be getting the hvr950q support right?
<mkrufky> mario_limonciell: hi
<mkrufky> mario_limonciell: huh?
<mario_limonciell> do you know what kernel to test with?
<mario_limonciell> 2.6.24-20?
<mkrufky> do I know what kernel to test with?
<mario_limonciell> well i thought there was an SRU out there for hardy
<mkrufky> oh!
<mario_limonciell> that will be showing up in one of the proposed kernels
<mkrufky> im sorry
<mario_limonciell> and needed someone to ack it
<mkrufky> yes
<mkrufky> yeah, they need it "validated"
<mkrufky> bugs # 241745 , bug # 241628
<mario_limonciell> bug 261628
<mario_limonciell> hum where's ubottu ?
<mario_limonciell> bug 241628
<ubottu> Launchpad bug 241628 in linux-ubuntu-modules-2.6.24 "HVR950Q not supported" [Wishlist,Fix committed] https://launchpad.net/bugs/241628
<mkrufky> thats what i wanna  know
<mario_limonciell> bug 241745
<ubottu> Launchpad bug 241745 in linux-ubuntu-modules-2.6.24 "Add Siano SMS10xx USB dvb tuner driver" [Medium,Fix committed] https://launchpad.net/bugs/241745
<mkrufky> yay
<mario_limonciell> ah both in lum
<mkrufky> i cant say i understand... at all
<mario_limonciell> they are both in linux-ubuntu-modules 2.6.24
<mkrufky> what i know is that they were merged into the git trees weeks agho
<mkrufky> ago
<mkrufky> so slangasek totally confused me today
<mario_limonciell> well once the binaries show up on hardy-proposed i'll be able to test the first one at least
<mario_limonciell> the second one is dvb only right?
<mkrufky> i sent the dvbt ones to pat
<mario_limonciell> yeah so let pat ack thouse
<mario_limonciell> *those
<mkrufky> actually, i think pat has 'em all
<mkrufky> er....  can you confirm that?
<mario_limonciell> no i'm not sure
<mkrufky> there's a chance those went to compal, now i realize :-/
<mario_limonciell> well my mirror is usually a day behind
<mario_limonciell> so i'll test early next week
<mkrufky> i mean the hardware
<mkrufky> if i get dvb-t sticks over to you, do you have a generator?
<mario_limonciell> yeah i'm not sure who has what at this point
<mario_limonciell> i don't have one personally no
<mkrufky> there's a chance that nobody at ubuntu / canonical actually  has them.  the guy that knows (here) isnt here today, and away from email
<mario_limonciell> okay well can sort it out early next week
<mario_limonciell> no rush on these, since the hardware isn't even "out in the wild" yet
<mkrufky> actually...
<mario_limonciell> shhhhhhhh ;)
<mkrufky> we're thinking two different things, for sure
<mkrufky> all i know is this -- we sent dvb-t sticks, but probably not to you guys yet
<mkrufky> and i would like to send them out right now, if you can give me an address
<mkrufky> (*if* you have a dvbt generator to test with)
<mario_limonciell> jim has one
<mario_limonciell> so sending 1 wouldn't hurt
<mkrufky> a stick, or a generator?
<mario_limonciell> stick
<mario_limonciell> jim has a generator
<mkrufky> oops, i was thinking of you with the other hat on
<mkrufky> jim didnt ask for one, i dont think he needs one
<mkrufky> he only wants plastics, afaik
<mario_limonciell> oh okay
<mkrufky> i need somebody that can ack to get a stick :-)
<mario_limonciell> ah okay
<mario_limonciell> well you should be able to ack yourself too
<mario_limonciell> i mean just install the newer kernel on a  box
<mkrufky> slangasek said no
<mario_limonciell> i don't see why not?  I mean as long as you are testing the binaries in hardy-proposed
<mkrufky> this is going to get worse.....  because i was planning on backporting drivers for tons of totally unreleased products to you ghuys
<mkrufky> and nobody but me will *ever* be able to test them
<mkrufky> the idea was to get drivers out there *before* the hardware is available
<mkrufky> so that it will *actually* JustWork
<stgraber> that should be fine, if you ack the driver works with your hardware and some other ack that the new lum doesn't break the world I don't see where the problem would be
<mkrufky> hmm, ok
<mario_limonciell> yeah the important part is testing that the binary worked
<mkrufky> all i can do is pull down a git tree :-/
<mario_limonciell> that you aren't running off your own source built tree
<mario_limonciell> so once this newer lum hits hardy-proposed, install it, and check.
<stgraber> what we don't want are regressions so having people saying that we don't have regressions and you saying that it works better should be fine to move the package to -updates
<mkrufky> so, when will the binary be availeble?
<mkrufky> ...and how do i install it without totally destroying my own build environment :-P
<mkrufky> eh, scratch that last question
<mario_limonciell> well it's in hardy-proposed as of 4 hours ago
<mkrufky> ah!
<mario_limonciell> but its marked NEW
<mkrufky> how do i get it?
<stgraber> you can get it from Launchpad
<mario_limonciell> so that means that an archive admin would need to "ack" it to get the binaries the "normal" way
<mario_limonciell> https://edge.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.24/2.6.24.14-20.46
<mario_limonciell> click your architecture, and then there should be a list of resulting binaries
<stgraber> as it's a new kernel (-20) you'll also need to download all the other kernel packages
<mario_limonciell> oops thats the lrm
<mkrufky> i can install that on a "2.6.24-19-generic" kernel ?
<mario_limonciell> lum is what you need
<mario_limonciell> let me find that
<mario_limonciell> you might also need lrm though anyway if you have stuff in there like ati or nvidia
<mario_limonciell> here's LUM https://edge.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/2.6.24-20.29
<mkrufky> :-(
<mario_limonciell> and here's the matching kernel image: https://edge.launchpad.net/ubuntu/+source/linux/2.6.24-20.37
<mario_limonciell> so if you install the set of those 3 together, you should have a system that you can boot into the newer kernel and test.  if that's too much mess, then early next week an archive admin will clear these into hardy-proposed
<mario_limonciell> at which point you can follow the directions on slangasek's comment to turn on proposed and install from there
 * mkrufky digging up a hewlet crappard to test this on
<mkrufky> sorry, my humor sucks right now
<mkrufky> gonna be a few minutes... doing a dist-upgrade first before installing the above new packages
<laga> mkrufky: do you need people who can test DVB-T hardware?
<mkrufky> *I* dont...
<mkrufky> i have a generatorm, here
<mkrufky> generator
<laga> nice. i saw one of these a few years back at an exposition and wanted to take it ;)
<mkrufky> dvb-t generator?
<mkrufky> i want one for home...  i can stop coming to the office, then :-P
<mario_limonciell> mkrufky, how pricey are they? i think it'd be really neat to have one at home too
<mkrufky> i just asked them in the lab
<mkrufky> ... it ranges in price, depending on features, etc
<mkrufky> brb
<mkrufky> sorry, had a visitor
<mkrufky> anyway....  ranges from 1500 to 15000
<mario_limonciell> oh yikes okay
<mkrufky> probably a $1500 one would be fine for home
<mario_limonciell> novelty value wears off quick though at 1500 i think
<mkrufky> meanwhile.... i hear the "management" talking from time to time about some generator on ebay for $100
<mkrufky> when they see those, they buy 'em
<mkrufky> hopefully, next time *I* will see one before they do
<mkrufky> for a few hundred bucks, i'd totally buy one
<mkrufky> heh, he didnt like the price, so he ditched
<slangasek> mkrufky: sorry, I certainly didn't mean to give the impression that you weren't /allowed/ to ack
<mkrufky> ah, then i misunderstood slangasek
<mkrufky> slangasek: when we spoke earlier, i had no idea that i was able to test / ack it myself
<mkrufky> meanwhile, apt says there are 42 minutes left in this download.... unlikely i'll stick around long enough
<slangasek> mkrufky: right - the question that I remember you asking me earlier was what you /needed/ to do on the bug
<slangasek> if you are /willing/ to test that the packages work, so much the better. :)
<mkrufky> slangasek: ah, lol
<mkrufky> magically 42 minutes have turned to zero -- yay
<mkrufky> i am surfing thru those links and i dont see a deb to download
<slangasek> which links?
<mkrufky> (5:24:05 PM) mario_limonciell: here's LUM https://edge.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/2.6.24-20.29
<mkrufky> (5:24:41 PM) mario_limonciell: and here's the matching kernel image: https://edge.launchpad.net/ubuntu/+source/linux/2.6.24-20.37
<slangasek> pick an architecture
<mkrufky> did
<slangasek> then you'll get a list of binaries on the right side
<mkrufky> nope
<mkrufky> https://edge.launchpad.net/ubuntu/hardy/+package/linux-image-2.6.24-20-generic
<mkrufky> oops
 * mkrufky shuts up now
<mkrufky> downloading.......
<slangasek> in the case of the linux package, though, those are published in hardy-proposed already
<slangasek> (they have to be, in order for lum to build against them)
<mkrufky> i dont even know how to get hardy-proposed
<slangasek> the (autogenerated) comment at the end of the bug should point to a page that explains it
<mkrufky> i just download the deb
<mkrufky> i'll go with that, if i have a choice
<mkrufky> (i have to leave here in 10 minutes, wanna get this done as fast as i can)
<slangasek> fwiw, it's not urgent; we hold these packages in -proposed for a full 7 days, to get regression-testing from a range of users
<mkrufky> meh
<mkrufky> https://edge.launchpad.net/ubuntu/hardy/i386/linux-ubuntu-modules-2.6.24-20-386/2.6.24-20.29
<mkrufky> ok then... i guess i'll just let the 7 days happen
<slangasek> between linux and linux-ubuntu-modules there are some 30 bugfixes, so that gives some opportunity for regressions
<slangasek> mkrufky: mm, the validation needs to happen /while/ it's in -proposed
<mkrufky> ?
<slangasek> that's a condition of it being copied to -updates
<mkrufky> i dont understand... but...
<slangasek> so "let the 7 days happen" - if no one else verifies this bugfix for us, it becomes more than 7 days
<mkrufky> ugh
<mkrufky> i dont know what to say
<mkrufky> i'm going back to upstream
<mkrufky> whatever gets merged gets merged
<mkrufky> heh
<mkrufky> thanks for explaining slangasek
<mkrufky> slangasek: have a good weekend
<slangasek> mkrufky: sorry for causing frustration
<slangasek> you too... :)
<mkrufky> slangasek: its ok -- i think somebody just assumes that i know the policies, and i dont :-/
<mkrufky> all that _really_ matters is that belmont has these changesets
<mkrufky> belmont *does* have them, so its fine
<slangasek> well, https://wiki.ubuntu.com/StableReleaseUpdates is the policy
<mkrufky> after all deadlines come and go, then i will revisit hardy mainstream
<mkrufky> hopefully this will all be done by then.... if not, then.... oh well
<slangasek> which you're welcome to acquaint yourself with, but again, I don't know that this is anything that you /have/ to take responsibility for directly
<mkrufky> i want to become more active in ubuntu kernel devel
<mkrufky> so yes, i would like to become more acquainted
<mkrufky> ...just now is the end of my week....  no more "retail" work for me... back to upstream kernel hacking ... otherwise there wont be any new code to backport into LUM / Intrepid ;-)
<slangasek> ok; if you have questions about policies, here or #ubuntu-motu are good places to ask
<mkrufky> cool, thanks
<slangasek> heh, enjoy :)
<mkrufky> you too ;-)
<mkrufky> does laga work for canonical?
<mkrufky> laga, if you work for canonical, please email me and i'll have a stick sent to you
 * mkrufky goes home
<mkrufky> goodnight,. all
#ubuntu-devel 2008-07-19
<wgrant> Why does the counter in the new shutdown/logout dialogs not change?
<Wubbbi> bug 249850 ... could someone fix?
<ubottu> Launchpad bug 249850 in synaptic "Synaptic Freez up after installing Packages" [Undecided,New] https://launchpad.net/bugs/249850
<Hobbsee> Wubbbi: it's a weekend.
<wgrant> And it's also Intrepid, IIRC.
<ogra> BenC, hey, thanks !
<nxvl> ScottK: can you please backport debian-policy 3.0.8
<nxvl> err
<nxvl> 3.8.0
<ScottK> nxvl: file a bug in hardy-backports and let me know.
<nxvl> ok
<nxvl> ScottK: where is the hardy-backports tracker?
<ScottK> nxvl: launchpad.net/hardy-backports/+filebug
<nxvl> oh! i was looking for it under ubuntu/hardy-backports
<nxvl> :D
<nxvl> thank you!
<ScottK> !backports | nxvl
<ubottu> nxvl: If new updated Ubuntu packages are built for an application, then they may go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports - See also !packaging
<ScottK> That'll give you additional detail.
<nxvl> ScottK: Bug 250143
<ubottu> Launchpad bug 250143 in hardy-backports "Please backport debian-policy 3.8.0." [Undecided,New] https://launchpad.net/bugs/250143
<ScottK> nxvl: It needs to be tested (build, install, and run the package).
 * nxvl tests
<nxvl> ScottK: ok, done: Bug 250143
<ubottu> Launchpad bug 250143 in hardy-backports "Please backport debian-policy 3.8.0." [Undecided,New] https://launchpad.net/bugs/250143
<ScottK> nxvl: Passed to the archive-admins for doing the packport.  For future reference, all that's needed is a statement that you've tested it builds/installs/runs.  Attaching the logs isn't needed.
<nxvl> oh
<nxvl> ok
<nxvl> :D
<nxvl> thank you
<ScottK> packport/backport in any case ...
<nxvl> heh
<nxvl> indeed
<nxvl> well, need to run
<nxvl> read you!
<nxvl> and thanks!
<alex-weej> this FAT32 volume on my phone...
<alex-weej> every time i replug it in it gets a new UUID according to vol_id
<alex-weej> 4882-XXXX
<alex-weej> where XXXX is some seemingly random string
<alex-weej> as a result, the UDI changes, making it hopeless for me to program with
<alex-weej> anyone have any idea what's going on?
<emgent> base-files, makedev, fuseutils and bash seems broken.
<emgent> more broken packages. upgrading faild.
#ubuntu-devel 2008-07-20
<sponix> http://www.timhardy.net/wordpress/bytopic/howto/  --> Can someone give me a hand implementing this work-a-round so I can burn DVD's with k3b ?
<wgrant> sponix: This isn't a support channel.
<sponix> I'll just do my best to fine a bug report .. Sorry if I disturbed anyone
<sponix> s/fine/file/
<pwnguin> do we have any good docs on actually fixing bugs?
<asac> pitti: how should a MIR look like if its just for some parts?
<asac> e.g. one binary package
<asac> pitti: siretart: bug 250245
<ubottu> Launchpad bug 250245 in ubuntu "[MIR] - pcsc-lite sources + partially binary promotion to main" [High,Confirmed] https://launchpad.net/bugs/250245
<asac> cody-somerville: there?
<asac> cody-somerville: gnomefreak said he asked you to add our mozillateam meetings to the fridge. you still have that on your radar (or are you actually the right to ask)?
<ogra> BenC, had a good trip ?
<BenC> ogra: 13.5 hour drive...but it was nice
<ogra> :)
<BenC> ogra: how's things in waltham?
<ogra> funny, there was a marriage in the hotel last night
<laga> did someone marry their ebox?
<ogra> lots of bikers, burnouts at 1am with an exploding tire etc
<BenC> kick ass
<ogra> i got the 2.4.26 kernel runing on the cmpc btw
<ogra> and indeed it fixes the prob
<BenC> you mean 2.6.26, right? :)
<ogra> but only applying the r8169 changes for .26 to .24 doesnt help :/
<ogra> yeah, indeed :)
<ogra> i saw there is a lot changed in af_packet as well ... but that doesnt build if i dont lso have all the socket.h changes ... which was the point where i gave up las night
<ogra> not sure where to go from here  ...
<BenC> check pci quirks
<BenC> if it isn't the driver itself, that's about the only other place where I can see something getting fixed
<BenC> (I can't see a bug in af_packet only affecting one device, but I guess it's possible)
<ogra> well, its an issue of the NIC not replying to dhcp offers, thats why i suspected af_packet
<BenC> ogra: does setting the IP manually make it work otherwise?
<ogra> but it doesnt work with static IP either ...
<BenC> ok, then definitely not af_packet :)
<ogra> well, not sure if the hotel network doesnt block here
<BenC> direct PC-to-PC ethernet should tell you though
<ogra> might be that the router only accepts connections the dhcp server gave out before
<ogra> good idea, i hope one of the cards i have here does autosensing .... i have no crossover cable with me
<BenC> most modern PHY's have autosensing now adays
<ogra> yeah
<ogra> but i have never used my lappies wired interface, so i'm not sure
<ogra> meh, firs some fiddling ... i dont have a -19 kernel on the cmpc atm ... damned space constraints
<ogra> *first
<ogra> btw, we should look that we start generating the initramfs in /tmp instead of boot ... i constantly run into space issues with /boot through that
<norsetto> asac: I guess you haven't received my last email?
<ogra> BenC, oh, that smells related http://marc.info/?l=linux-netdev&m=121498012600793&w=2
<ogra> (even though i dont see it at all in 2.6.26)
<ogra> hmm, even more ... http://userweb.kernel.org/~romieu/r8169/2.6.26-rc9/20080710-r8169-test.patch
<BenC> ogra: ah, comes from mario too
<BenC> ogra: going to give it a try?
<BenC> ogra: transient may include "works in 2.6.26 and not in 2.6.24"
<ogra> well, it seems we have it in .24
<ogra> http://paste.ubuntu.com/28741/
<ogra> what i wonder is if the call:
<ogra> 1441         dprintk("Set MAC Reg C+CR Offset 0x82h = 0x01h\n");
<ogra> 1442         RTL_W8(0x82, 0x01);
<ogra> that actually happens before the "if (tp->mac_version == RTL_GIGA_MAC_VER_02) {" doesnt trash it for me already
<ogra> it somehow looks like wrongly ordered for me .... but its not different in .26 though
<ogra> if only kernel builds wouldnt take a century :/
<BenC> ogra: hehe, it's easy to just build one driver
<BenC> ogra: mkdir ../build; cp /boot/config-`uname -r` ../build/.config; make O=`pwd`/../build prepare; make O=`pwd`/build drivers/net/8169.ko
<BenC> ogra: or: mkdir tmp; cd tmp; cp ../drivers/net/8169.c .; echo "obj-m = 8169.o" > Makefile; make M=`pwd` -C /usr/src/linux-headers-`uname -r`
 * BenC could go on and on
<ogra> ah, when i clean out the typos it actually works :)
<highvoltage> :)
<ogra> intresting, dropping the RTL_W8(0x82, 0x01); line makes dmesg look a lot better (i get proper link up/down messages now) but doesnt make it work
<ogra> well, but that looks like i'm on the right path ...
<ogra> yay, something to fill my bored sunday with ...
<lamont> what's the plugin to have firefox claim to be IE7/Windoze?
<highvoltage> lamont: user-agent-switcher
<emgent> heya
<lamont> highvoltage: that did the trick -thanks
<ion_> benc: Btw, is there an intention to release a new Linux image soonish?
<highvoltage> lamont: you're welcome.
<ogra> hmpf, seems no matter what i do with the direver  cant get it to work ... even using the complete code from 2.6.26 doesnt help
<BenC> ion_: probably tomorrow or tue
<ion_> benc: Great
<alex-weej> mdz: https://launchpad.net/ubuntu/+spec/no-more-source-packages
<alex-weej> that's obsolete now right?
<alex-weej> someone mentioned this here a couple weeks back to me but i can't remember what they said had taken over
<pwnguin> there cant be that many open blueprints
<pwnguin> https://blueprints.edge.launchpad.net/ubuntu/+spec/distributed-development-importer ?
<alex-weej> pwnguin: thanks
<hmuller> Is it safe to assume the uvesafb/v86d problem (x86_64) is a known issue with the current daily-live?  I didn't see a respective bug in Launchpad.
<hmuller> And is it too early to be reporting bugs for missing firmware in Intrepid?
#ubuntu-devel 2009-07-13
<srid> launchpad down again? this is frustrating.
<ebroder> Seems to WFM
<srid> down for me since last 2 days
<srid> loading forever, that is.
<Laney> works here
<ebroder> Seems snappier than usual to me. Seems like something weird on your end
<srid> IP addr?
<cjwatson> srid: I suggest #launchpad - they actually have some influence over Launchpad's responsiveness
<cjwatson> we, in general, do not
<srid> damn it, it's the damn opera. launchpad loads fine on safari.
<srid> cjwatson: ok
<ebroder> Crap - typed too quickly. Can somebody unsub ubuntu-motu from bug #394398?
<ubottu> Launchpad bug 394398 in open-iscsi "Logic to determine expected number of running session wrong (regression in hardy's open-iscsi 2.0.865-1ubuntu3.1)" [Undecided,New] https://launchpad.net/bugs/394398
<ajmitch> one sec
<ajmitch> ok, it's gone
<ebroder> Thanks
<ajmitch> LP still isn't snappy here :)
<Laney> it has to travel through quite some tubes to get to you though
<ebroder> ITYM they have to make room on the big truck :)
<merkur2k> hey all
<merkur2k> anyone here that can give me some help with customizing the installer via a preseed file?
<ajmitch> ebroder: it's more like each packet gets hand-wrapped & taken to NZ on a rowboat
<cjwatson> merkur2k: I can, but I'm just about to go to bed. I suggest asking on #ubuntu-installer during European working hours
<cjwatson> merkur2k: and, if you haven't already, read the preseeding appendix in the installation guide (linked from help.ubuntu.com) first
<merkur2k> ok, it might be a simple one. I am wanting to run a fairly complicated script from preseed/late_command that needs user input, but the installer has its own dialog up that blocks the screen
<cjwatson> you'll need to use debconf if you want to interact with the user; not simple ;-)
<merkur2k> just looking for suggestions or ideas for fixes or alternate methods
<merkur2k> it is too interactive to be able to ask questions in advance
<cjwatson> can talk you through the issues and possible fixes tomorrow or whatever
<merkur2k> ok
<cjwatson> debconf doesn't necessarily mean in advance
<merkur2k> at the very least it would just be nice to have some progress feedback other than "running preseed command"
<merkur2k> :)
<merkur2k> but have a good sleep, i will be around
<twb> Given an arbitrary source package (e.g. darcs) and release (e.g. feisty), how can I find out if there is a PPA or backport for a recent version of that package for that release?
<ebroder> Google
<twb> That is plan B.
<twb> I had the impression that Launchpad had some sort of predictable naming scheme for PPAs
<ebroder> Not really. They're arbitrary
<twb> Bummer, thanks.
<ebroder> People creating PPAs for backports usually create a team with a name similar to the package, e.g. https://launchpad.net/~git-core
<ebroder> But that's entirely at the maintainer's discretion
<pitti> Good morning
<StevenK> Morning pitti
<StevenK> pitti: So, lool wanted me to fix clutter to build a .pot. I've added langpack.mk to it's rules file, is that all I have to do?
<pitti> StevenK: that should do; build log will tell :)
<StevenK> pitti: But the .pot doesn't turn up anywhere?
<StevenK> pitti: I can pastebin the build log, if you wish
<pitti> StevenK: then it apparently doesn't use standard intltool?
<pitti> StevenK: I just wonder why clutter has translatable strings in the first place; isn't it just a graphics lib?
<pitti> pochu: the total ddeb archive size is 164 GB, 6 arches, 5 releases
 * pitti cleans up gutsy
 * StevenK waits for fbreader to finish building
<StevenK> pitti: I'm not sure about a delta from Debian for the removal of -qt and -maemo
 * ScottK decides not to wait for kdesdk to build and goes to bed.
<pitti> StevenK: lool reviewed clutter and didn't complain about a missing pot
<StevenK> pitti: See later comment
<pitti> ah
<pitti> laga: devkit-power is already used, yes; pm-utils needs to grow support for quirks, it's on the TODO list (https://wiki.ubuntu.com/Halsectomy)
<pitti> laga: most devices today shouldn't need quirks any more, but it's still needed for old hw
<dholbach> good morning
<StevenK> pitti: http://paste.ubuntu.com/216679/
<pitti> StevenK: looks good
<pitti> hey dholbach! *hug*
 * dholbach hugs pitti back
<dholbach> hi thekorn
<thekorn> hey dholbach
<superm1> hi pitti.  so with the old HAL world, I was able to prevent partitions from being exposed in nautilus as user mountable with a nice FDI file.  with devicekit-disks, does similar functionality carry over?
<pitti> superm1: yes, there is; this is just being re-added, see https://bugs.freedesktop.org/show_bug.cgi?id=22707
<ubottu> Freedesktop bug 22707 in detection "Set DKD_PRESENTATION_HIDE for unwanted partitions" [Normal,Assigned]
<pitti> superm1: also, bug 394088
<ubottu> Launchpad bug 394088 in devicekit-disks "Ignore EFI partition on Intel Macs" [Undecided,Fix released] https://launchpad.net/bugs/394088
<superm1> pitti, ah spectacular.
<superm1> yeah i was gonna point out that dell utility partitions are getting mounted and shown too which brought it to my attention
<pitti> superm1: our /lib/udev/rules.d/95-devkit-disks.rules already has an earlier version of that patch
<superm1> which reading through is already in your comments from a few days ago
<pitti> superm1: could you try the patch on the fd.o bug and verify that this covers it?
<pitti> you can just apply it to /lib/udev/rules.d/95-devkit-disks.rules and reboot or udevadm trigger
<superm1> pitti, yeah i should be able to tomorrow morning
<pitti> unfortunately I wiped my recovery partition in a sad accident
<superm1> well the utility partition and recovery partitions are different beasts though
<pitti> tried to dd an image to my USB stick and accidentally picked sda..
<superm1> after things are sorted for the utility partition, i'm planning on having a third party rule that will be part of the recovery media creation tool on factory shipped ubuntu and rhel6 systems
<superm1> ah that'd do it
<pitti> superm1: that would work; you should put it into /etc/udev/rules.d/
<superm1> pitti, well it comes part of an installed system in a proper deb or rpm
<pitti> ah, ok; /lib then
<superm1> normally i'd say it's best to just put it in that upstream devdisk-disks.rules, but unfortunately the partition naming scheme clashes with that of the one for windows factory shipped systems and would cause people with a windows factory shipped system to not have access to their data from linux in a dual boot scenario
<StevenK> pitti: So, I've done everything for fbreader aside from the i18n, since I have no idea how to sprinkle in a standard intltool build system
<pitti> StevenK: that'd indeed be a more intrusive patch, and you should really check with upstream first that they'd take it
<StevenK> pitti: Right.
<StevenK> pitti: So does fbreader have a hope of getting approved without i18n?
<pitti> StevenK: well, if you need it in mobile, sure
<pitti> but as I said, it's really an ugly wart
<pitti> and I really recommend fixing it
<pitti> sure, it's a day of work, but if you consider it an important use case, it's well worth it
<pitti> the intltool build system is easy to do
<pitti> most of the work is writing some python code to generate .po files from the existing xml files
<pitti> superm1: just uploaded a new dk-disks with current ignore rules
<pitti> (needed for NBSing out libsgutils2 anyway)
<StevenK> pitti: fbreader uploaded
<pitti> thanks
<StevenK> pitti: Bug task slammed back to New, too
<lool> StevenK: +include /usr/share/cdbs/1/rules/langpack.mk
<lool> StevenK: that's not mergeable in Debian AFAIK
<lool> StevenK: You could have used -include foo to the same effect, but that would have been mergeable in Debian; I fixed clutter/clutter-gtk in Debian's pkg-gnome SVN to include gnome.mk instead of autotools.mk which should pull in langpack.mk automatically
<pitti> ( ^ confirmed)
<StevenK> lool: Okay, I'll fix them both soonish
<ogra> is my system supposed to drop out of usplash after finding the initramfs with the last kernel update or did i just see a race ?
<chrisccoulson> hi asac
<asac> hi
<coolbhavi> hello
<coolbhavi> do ppa's and archives use different buildd's?
<Nafallo> coolbhavi: yes
<coolbhavi> Nafallo, please take a look: package is building on my ppa https://edge.launchpad.net/~bhavi/+archive/bhavi-upstream-testing/+build/1116212 but ftbfs on archive buildd: http://launchpadlibrarian.net/28954351/buildlog_ubuntu-karmic-i386.libselinux_2.0.82-1ubuntu1_FAILEDTOBUILD.txt.gz
<Nafallo> coolbhavi: ehrm. why would I be a good person to look at that?
<Keybuk> pitti: quick reply to your mail
<Keybuk> pitti: the Mini 9 has an SSD, I/O seek and load times are _rarely_ an issue
<coolbhavi> Nafallo, okay anyone please guide am confused now..
<pitti> Keybuk: well, cold vs. hot cache makes a _tremendous_ difference for gnome-panel, so I wondered how big of an impact it has on ssd
<seb128> pitti, most of the gnome-panel start time on my laptop is the menu building
<seb128> ie it starts in 1.5s rather than 6s when there is no .desktop installed
<pitti> seb128: right, I aked Key to time gnome-menus-ls.py with cold and hot cache
<pitti> for me that's 10s (cold) vs. 0.1 (hot)
<pitti> seb128: that's what I discussed with vuntz on LinuxTag
<Keybuk> pitti: will do that this morning :-)
<pitti> Keybuk: it's not urgent (I won't actually get to this in the next weeks), but I'm curious
<pitti> Keybuk: thanks
<coolbhavi> pitti, can you please help me? /me scratches his head
<pitti> coolbhavi: I guess your PPA package was built earlier, and a new kernel broke it or so?
<coolbhavi> pitti, okay now what to do?
<pitti> coolbhavi: I didn't look into it yet, it probably nees a small fix for current linux-libc-dev
<Keybuk> pitti: I'm doing the i386 vs. i586 performance tests this morning, easy enough to slip that one in as well
<pitti> Keybuk: oh, does that make a significant difference?
<Keybuk> pitti: I'll tell you when I've done the tests
<pitti> good luck
<Keybuk> it certainly did with the last set of test CDs we made
<Keybuk> but we think we made those wrong :p
<Keybuk> the last test proved that the new gcc + i586 makes a much faster install than the old gcc + i386 ;)
<coolbhavi> pitti, okay, in the archive or in the source that I kept for sponsoring?
<pitti> coolbhavi: in libselinux
<seb128> hey coolbhavi
<seb128> coolbhavi, thanks for your work on the pango update
<coolbhavi> okay pitti hey seb128 no mention
<coolbhavi> pitti, sorry for the mistake I created
<pitti> coolbhavi: don't worry; it wasn't a mistake, just a timing issue
<pitti> these things are perfectly normal in a dev release which changes as fast as Karmic
<pitti> coolbhavi: the original version would be FTBFS as well now, so it's a completely new issue
<coolbhavi> I changed the cflag thing and tested it on my PPA it built so I created a diff
<coolbhavi> pitti, now also I tested out on my PPA its building fine
<coolbhavi> but I didnt think it would ftbfs in the archive
<laga> pitti: ok, thanks for the input re devicekit and quirks. i read an email from the pm-utils guy from last year saying that he didn't want the quirks in pm-utils, i guess that has changed then
<pitti> laga: well, it has to
<pitti> nothign except pm-utils is using them
<ogra> pitti, any chance we get the drum sound back into gdm at some point ?
<pitti> ogra: I consider that a feature :-P
 * ogra doesnt 
<ogra> :)
<pitti> anyway, would need to be hacked into the simple greeter
<ogra> i like that i can hear when my system is done booting without watching the screen
<pitti> but DX has some plans for this greeter anyway, I think
<ogra> and i gues TheMuso likes that too :)
<ogra> *gues
<ogra> s
<ogra> pfft
<TheMuso> ogra: Yeah I have been meaning to look into that. It may be a matter of tweaking the default sound theme for the gdm session.
<ogra> yeah, i bet its not to hard
<pitti> ah, indeed
<pitti> I keep forgetting that it's a normal gnome session now
<lool> pitti: I made the same remark to kirkland about the cron job which should move to PAM (slangasek was complaining about the usage of a cron which spams syslogÂ°
<lool> pitti: I think the issue was that you need to update more frequently than on each login, perhaps to display up-to-date information when displaying it within screen for instance
<TheMuso> After all, pulseaudio gets run by GDM, and if you press the backspace key in the password field, you get a sound.
<lool> pitti: But I didn't confirm that; perhaps this information should simply be updated whenever it's needed rather than regularly though; I agree
<pitti> lool: but then screen should directly display the load
<pitti> instead of jumping through the python/cron -> motd -> read motd hoop
<pitti> a static file is simply not the right thing for this kind of information which updates every second
<pitti> (also, why do we need a load, etc. in motd in the first place?)
<lool> pitti: It's not just the load, it's a bunch of things like e.g. number of packages which are update-able
<pitti> lool: right, but that can be updated in the apt cronjob
<pitti> it just feels like throwing a lot of resources into trying to feed dynamic information into a static file
<lool> pitti: I don't want to dive into specifics; I made the same high level remarks than you did, but I don't use it
<lool> To answer this fully, I would have to check every plugin and see how it could be made efficient
<lool> I agree with you on APT updates and on load; I don't know what else is involved
<Keybuk> pitti: replied with numbers
<pitti> Keybuk: wow, SSD has quite an effect
<pitti> thanks
<Keybuk> SSD has the effect of eliminating "hot cache" issues from your performance tests
<pitti> it's a worthwhile optimization for spinning disks still
<Keybuk> since it's almost as fast to read from the SSD as it is from the page cache
<Keybuk> sure
<Keybuk> but that's not the problem I see
<Keybuk> the problem I see is that there are still fundmental performance issues with gnome-panel *after* you eliminate the I/O problem
<seb128> it's named libbonobo
<seb128> and sync calls
<Keybuk> sync calls wouldn't show up as CPU time
<seb128> how much cpu usage do you get?
<Keybuk> I don't have a recent chart to hand, but it's a fair amount
<seb128> ok, I've no been looking at that because it was so small on my chart compared to disk use
<seb128> but I'm using a regular disk
<seb128> and 80% of the gnome-panel start here is ios
<Keybuk> right, when you're using a regular disk, the I/O wait and load times is what will show up
<pitti> hm, an autoreconf in gnome-panel adds "SHAVE_INIT(., enable)
<pitti> " to configure
<pitti> which fails
<Keybuk> seb128: ah, be careful
<Keybuk> don't fall into *that* trap
<pitti> does that ring a bell with anyone?
<seb128> pitti, no
<james_w> pitti: it fails with a syntax error in configure?
<Keybuk> seb128: if a process is waiting for I/O, it'll show up as I/O wait
<pitti> james_w: yes
<Keybuk> even if it's caning the CPU at the same time for something else
<james_w> pitti: check Makefile.am has "ACLOCAL_AMFLAGS = -I m4"
<seb128> Keybuk, ah, I didn't know that
<Keybuk> so the "80% is I/O" just means that on a rotary disk, you spend 80% of your time in I/O wait
<pitti> james_w: find -name Makefile.am | xargs grep ACLOCAL_AMFLAGS -> nothing
<Keybuk> if you take away the I/O, it often doesn't speed it up by removing that
<Keybuk> you just expose what else it was doing while it was waiting for I/O
<Keybuk> often in another thread, etc.
<seb128> Keybuk, ok, it will just unmask the cpu use
<seb128> I see
<james_w> pitti: if there is m4/*.m4 then try adding that line, it fixed it in other packages
<pitti> james_w: to all 25 Makefile.am files? *sigh*
<james_w> pitti: just ./Makefile.am should work
 * pitti sobs at autotools breakage the 23948234th time
<james_w> pitti: then autoreconf
<seb128> pitti, in configure.ac is usually enough
<james_w> fwiw, autoreconf tells you that you should do this :-)
<seb128> it has "AC_CONFIG_MACRO_DIR([m4])" already
<pitti> james_w: autoreconf outputs several hundred lines, admittedly I didn't read them all
<Keybuk> if autoreconf outputs more than a dozen lines, you probably have a problem :p
<seb128> pitti, "libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am." is displayed indeed
<james_w> admittedly only if you run with -v and work out that that particular message is the one you should pay attention to
<pitti> james_w, seb128: I think that helped; thanks!
<james_w> np
<seb128> that's the only message from autotools
<seb128> the flood is for the documentation which you don't really care about
<pitti> yay, gnome-panel configured, building now
<dholbach> who'd like to run a session on merging at UDW? or about anything else ubuntu-develop-y?
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep still has some open slots
<StevenK> Hmmm. How do I change CPU frequency scaling?
<ogra> StevenK, you cant anymore
<ogra> its builtin ...
<laga> ogra: so there is only one governor?
<StevenK> But I don't want this machine to be running at 2GHz
<ogra> at least the governor is hardcoded now
<wgrant> StevenK: The GNOME Panel frequency scaling applet will let you change things temporarily.
<laga> ogra: it might still be possible to change to governor in /sys
<StevenK> I wasn't after temporarily, either. :-)
<wgrant> Is ondemand not sufficient to reduce it?
<ogra> StevenK, it is set to performance during initramfs and should switch to ondemand after boot
<ogra> check if its at ondemand now
<StevenK> How do I check?
<ogra> if not, file a kernel bug
<StevenK> Since that's one of the things I'm not clear on
<ogra> cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
<ogra> should be ondemand
<ScottK> pitti: Is there a wiki page on how to make multimedia keys work in Karmic?  I've got a Dell Mini 10v that's not very happy in that department and I'd like to look into it.
<alkisg> asac, just notifying that I'll be here for the next few hours, in case you'd like feedback on https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/391040
<ubottu> Ubuntu bug 391040 in network-manager "When eth0 is unmanaged, system connections for other NICs aren't displayed nor used" [Medium,Triaged]
<StevenK> pitti: You'll look at fbreader today?
<StevenK> lool: So, should I undo the change to clutter-gtk, and fix clutter to use gnome.mk?
<lool> StevenK: I guess it's ok as long as the person doing the clutter/clutter-gtk merges know that the langpack include can be dropped
<lool> StevenK: I had in mind to do a couple of Debian uploads and then ask for syncs, but didn't have time yet; I guess we'll get the changes after next upstream release
<StevenK> lool: Well, I screwed it up, so I should fix it.
<lool> StevenK: It's not very screwed up, just a bit inelegant; if you like to fix it, perhaps you can do a merge from a snapshot of the SVN packages?
<pitti> StevenK: okay; so mobile team (you, lool, etc.) are fine with broken translations?
<lool> pitti: Which one?
<pitti> ScottK: incidentally I just updated https://wiki.ubuntu.com/Hotkeys/Troubleshooting for Karmic last week :)
<pitti> lool: fbreader
<pitti> lool: it doesn't use gettext, but translated xml files
<ScottK> pitti: Thanks.  I'll have a look.
<tseliot> cjwatson: I managed to get the debian installer to install my product-check udeb (to check hardware and halt the installer) but the script in lib/debian-installer-startup.d doesn't seem to be called: https://pastebin.canonical.com/19636/
<tseliot> cjwatson: am I supposed to tell which script the installer should use in debian-installer-startup.d ?
<lool> pitti: That sounds bad
<dpm> pitti: lool, StevenK: if the decision is to go with xml translations (I'd prefer gettext as well, but I realise this might require some work and coordination with upstream), I'll tell Ubuntu translators that at least they can translate the xml files and also send them to upstream - or maybe someone from the community might want to have a go at adding gettext support to fbreader upstream
<cjwatson> tseliot: name shouldn't matter. To debug it I suggest booting with BOOT_DEBUG=3, exiting the *first* shell you get (but not the second), and stepping through what /sbin/debian-installer-startup would do by hand
<pitti> lool, dpm: adding gettext support and changing the build system doesn't actually sound hard; one just needs to write a script to translate the existing .xml files to .po files
<tseliot> cjwatson: it's an automated installation and after I choose it, there's no way to exit. Or are you suggesting some CTRL+ALT+F1?
<cjwatson> tseliot: so make it not automated for the purposes of debugging! :-)
<cjwatson> tseliot: i.e. boot the installer with BOOT_DEBUG=3 on the kernel command line to see what it's doing
<cjwatson> tseliot: when you do that, it will give you the shells I mentioned, regardless of any automation
<lool> pitti: I think gettext has some support for XML; but I have no idea whether it applies here
<dpm> pitti, lool: do you mean that the most work would be simply in writing a one-time script to convert the existing xml files to PO in order to reuse existing translations? I thought the most (or at least most intrusive) work would be to add gettext support (the code uses string id's instead of the English strings)
<pitti> lool: no, that's just intltool
<pitti> dpm: right
<pitti> dpm: as far as  I can see, all strings are defined in a single .c file, in a string_constant = blabla('string') manner
<pitti> trivial to wrap that in a _()
<lool> pitti: I think xgettext can read Glade files
<dpm> pitti: they are in several files (although I guess that's not important), but I think the problem is that string id's are used instead of the English texts. If we wrap them in _() we're going to get the id's as msgids
<pitti> dpm: right, the English strings need to go into that file
<tseliot> cjwatson: it looks like s37speakup fails with "line 1: cannot open /proc/cmdline: no such file" then debian-installer-startup exits
<dduck> hi
<dduck> are here ubuntu developers?
<dpm> pitti: I'm not sure I can follow. So you're proposing:
<dpm> 1) adding gettext support to the code
<dpm> 2) replace the string id's in the code by the English strings in the .cpp file where those are defined
<dpm> 3) wrap those replaced strings in _()
<pitti> right
<lool> Replacing the string ids sounds like a large diff
<pitti> that's why I said that this should be cleared with upstream first
<pitti> it's much easier to do that one-time (with the xml->po conversion), etc.
<dpm> pitti, lool: ok, I understand it now, thanks. For me 1) is the gray area, since I don't know how the xml strings are loaded at the moment and I don't really now how much work would be to get rid of their own special l10n system and replace it by gettext
<pitti> dpm: I suppose it's a manday of work in total
<pitti> but, it's really only worth it if upstream takes it
<pitti> maintaining that large delta forever would be a PITA
<tseliot> cjwatson: that happens because /proc is still empty
<dpm> pitti: lool, StevenK: would anyone from the mobile team be willing to do this work for fbreader if I contact upstream (maybe some Ubuntu translators might want to help as well)?
<lool> StevenK: ^
<cjwatson> tseliot: sounds as though you ignored my advice to exit the first shell straight away, and use the second one it gives you
<cjwatson> tseliot: the first shell is immediately before /proc is mounted
<tseliot> cjwatson: I can get to the isolinux (boot) screen and to a second shell in which I can select the automatic installation (which then I customise to pass it BOOT_DEBUG=3). Is it wrong?
<cjwatson> on the isolinux boot screen, press F6 to get to extra options
<cjwatson> add BOOT_DEBUG=3 to the kernel parameters there
<cjwatson> press enter
<cjwatson> wait until you get a Unix shell
<cjwatson> type 'exit'
<cjwatson> you will get another Unix shell
<cjwatson> do your work there
<StevenK> dpm: I would be, yes.
<dpm> StevenK: then I'll contact upstream with the proposal and you on CC. Depending on what they say, I'll then also tell Ubuntu translators, since some of them might be able to contribute to the technical work. Sounds ok?
<ScottK> jdstrand: Just about to upload clamav with your apparmor change.  I didn't get to it over the weekend.
<jdstrand> ScottK: oh np. there is no rush on that-- it is just sometime during the cycle
<ScottK> Right. It was mostly I said I'd do it over the weekend and then didn't.
<tseliot> cjwatson: F6 doesn't seem to do anything on the isolinux boot screen
<tseliot> cjwatson: never mind, I got to the 2nd shell
<ogra> doko, the debian package has the same upstream version, i thought it was an upstream change
<ogra> (re binutils)
<ogra> doko, the differentce is that debian builds with gcc-4.3
<cjwatson> tseliot: ok
<doko> ogra: the debian package doesn't have the patch applied
<ogra> oh, i thought it was accepted upstream
<tseliot> cjwatson: it looks like my script is not in /lib/debian-installer-startup.d/ and this is why it's not called.
<tseliot> cjwatson: currently I make sure that it's installed by adding the package to the list in pkg-lists/local
<tseliot> maybe the package is installed after debian-installer-startup
<cjwatson> tseliot: no, pkg-lists is entirely processed at build-time not run-time
<cjwatson> tseliot: I don't know why your udeb wasn't included; check the d-i build log
<tseliot> cjwatson: ok, thanks
<StevenK> dpm: Sorry, I was AFK. That sounds great.
<dpm> StevenK: np, cool, I'll do that, then.
<smoser> anyone else seeing timeouts on keyserver.ubuntu.com ?
<smoser> on --send-keys, i'm getting "gpg: keyserver timed out" and "gpg: keyserver send failed: keyserver error"
<kirkland> pitti: yo
<ogra> ...ghurt ?
<ion> May the Schwartz be with you
<pitti> hey kirkland, good morning
<kirkland> pitti: howdy howdy
<kirkland> pitti: so you're hating on update-motd as a daemon :-)
<pitti> ion: Mr. Coffee or Mr. Radar?
<liw> kirkland, he's not the only one
<pitti> kirkland: well, it's a very large club to slam a small problem :)
<kirkland> pitti: i can revert the upload, but i need to figure out what an acceptable approach might be to all parties
<kirkland> liw: lool: right, i appreciate your views too :-)
 * liw rejects the entire notion of automatically editing /etc/motd to start with :)
<pitti> kirkland: perhaps we should step back for a while
<pitti> kirkland: what is the actual goal? displaying system stats on login?
<pitti> kirkland: since I don't think that modifying /etc/motd is your actual goal, it's just one way to reach your actual goal
<pitti> kirkland: if you want to display system stats on login, wouldn't that be so much easier to do directly in an optional pam module?
<kirkland> pitti: i don't think it's about the stats at all, at this point
<kirkland> pitti: the goal is to provide the system administrator, as well as other packages, a method to dynamically inject interesting information into the MOTD
<pitti> modifying a static system configuration file every 5 seconds seems like an approach that can only result in weird hacks?
<pitti> kirkland: again, into /etc/motd, or for an user to see when he logs in?
<kirkland> pitti: as for the system stats, they are inherently always stale (which was part of the motivation for the byobu-approach to delivering such system stats)
<pitti> (since the latter can be done with a pam module, and doesn't need motd)
<kirkland> pitti: fair enough
<kirkland> pitti: we considered that approach back in August
<pitti> kirkland: I'm just trying to understand what you actually want to achieve
<kirkland> pitti: i'm happy to revisit it though, as it's been almost a year
<pitti> and obviously I don't know all the history
<kirkland> pitti: the objection to pam (actually, it was /etc/profile.d that we examined) was that it could introduce a delay on login, gathering such statistics
<liw> kirkland, what is the goal of modifying motd?
<kirkland> pitti: particularly the calculation of the updates available
<pitti> kirkland: well, that's an one-time 0.1 second penalty, as opposed to the permanent penalty you pay by having a resident python daemon..
<kirkland> pitti: i suppose we could handle those particular cases with appropriate caching
<pitti> kirkland: well, I'm not saying that you should swing to the other extreme and calculate _everything_ on the fly :)
<lool> kirkland: Concerning available updates, there's a daily cron, perhaps you could hook into that?
<pitti> kirkland: e. g. the apt cron job could write that information into a cache, and load etc. is cheap to calculate
<kirkland> lool: yeah, just catting /var/run/updates-available would be the cheapest alternative
<pitti> kirkland: you could still have a motd.d/ with scripts, which are run by that pam module
<pitti> and one would just display apt's cache file, the other would output the load, etc.
<pitti> but then motd could remain static, cause less headache to admins who modify it (and backup systems), and avoids all the cron/daemon stuff
<tseliot> cjwatson: it looks like my package is only added to the packages pool (in binary/pool/main/p ) but it's not installed. Maybe I should use anna-install to make sure that the package is installed?
<kirkland> liw: motd = message of the day, but it's no where near that dynamic in its non-update-motd implementation
<liw> kirkland, I know what motd is, and I know it is semi-useless for providing info to people... so what is your goal in modifying it? :)
<kirkland> pitti: okay, so drop the cronjobs, drop the daemon;  replace it all with a compiled-c pam module that runs every time a user logs in that executes each of the update-motd scripts, concatenating the results
<kirkland> liw: to make it more useful
<pitti> kirkland: for efficiency it could provide some standard stuff itself, such as load
<pitti> kirkland: but well, it shouldn't matter that much
<pitti> login, with all the profile.d/, ecryptfs, etc. stuff is so slow that it would hardly matter
<pitti> kirkland: if that'd be feasible, I would certainly like it much better personally; however, what do _you_ think?
<kirkland> pitti: you think it's better as a pam module?  because it would be like a 5-line script in profile.d ?
<vadi2> I'm not sure where to report this, but the rafal.ca mirror has a 404 on the update manager kde version 0.111.8 for jaunty
<pitti> kirkland: oh, if profile.d/ works, so much the better
<pitti> kirkland: right, that already has legal.sh
<pitti> kirkland: great, that's even easier :)
<pitti> kirkland: so, /etc/profile.d/ubuntu-system-info.sh should be all you need?
<cjwatson> tseliot: putting it in pkg-lists/local should have caused it to be included in your image. anna-install will *not help you at all*, nor will *any run-time methods*.
<kirkland> pitti: i think it would make more sense to keep sysinfo a consumer of a generic update-motd script in profile.d
<kirkland> pitti: i've gotten a few random emails from people telling me how they're using update-motd for their unique situations
<pitti> kirkland: "sysinfo" is the landscape thingy in your context?
<kirkland> pitti: but if you're okay with that approach, so am i
<kirkland> pitti: yes, landscape-sysinfo is one consumer of update-motd
<pitti> kirkland: sure, I don't mind one more level of indirection
<kirkland> pitti: cool, i'll run with this
<kirkland> pitti: until someone else slams me for that approach :-D
<pitti> kirkland: so in summary, it needs an extension to the apt cronjob to cache the package updates, and then just another profile.d/ script? perfect
<pitti> kirkland: I'll come to your defense then :)
<kirkland> pitti: i think the apt cronjob already does that?
<kirkland> pitti: i thought i worked with mvo on that in Jaunty, for screen-profiles and byobu?
<kirkland> pitti: my "requirement" was that /var/run/updates-available be "as current as the last apt run"
<pitti> mmmm retroactive features :)
<kirkland> pitti: where either that was the cronjob apt
<pitti> kirkland: /var/run wouldn't work so well for this, though
<pitti> it should be in /var/cache
<kirkland> pitti: or your last apt-get update manually
<pitti> since /var/run is cleaned on boot
<pitti> I don't have that file there
<pitti> since I rebooted two hours ago
<kirkland> pitti: ah
<pitti> but in /var/cache it should be perfect
<kirkland> pitti: cool, i'll get with mvo on this one
 * pitti ^5s kirkland, thanks so much
<kirkland> pitti: okay, thanks
<superm1> pitti, it appears the updated udev rule in devkit disks you uploaded fixes utility partitions properly
<superm1> I adapted the rule for what factory shipped linux systems should look like.  by specifying the partition number I don't suspect it should clash with windows factory shipped systems.  do you think this should go upstream too, http://pastebin.com/f17bffd6c ?
<mvo> kirkland: I changed the code in u-n to use /var/lib/update-notifier/updates-available now
<lool> Keybuk: hola
<Keybuk> lool: what's up?
<lool> Keybuk: libnih seems to cause upstart to timeout on ARM
<lool> Keybuk: the test_node.c file seems too big
<lool> Keybuk: I couldn't decide whether it's generated
<Keybuk> it's not generated
<lool> It's 16k lines
<lool> Keybuk: Could we split it?
<Keybuk> ogra filed a bug report, it caused gcc to crash for him
<Keybuk> no
<Keybuk> besides, there are bigger files
<Keybuk> there's a ~50,000 line file not long after
<ogra> Keybuk, yes, but thats apparently a HW issue on my side
<lool> Keybuk: Indeed; that's worrying
<Keybuk> why would it take >2.5hrs to compile that file?
<lool> Keybuk: Is this something new?
<ogra> its either ld's fault of the system running out of ram
<NCommander> Keybuk, if its paging out, it might cause the issue. I've seen that when trying to build KDE on the NSLU2
<Keybuk> lool: "new" ?
<lool> Keybuk: Did you recently introduced large files?
<ogra> lool, the whole 0.6 upstart is *new* :)
<Keybuk> NCommander: well, we know that the current I/O scheduler is fucked and can permanently defer forever things using too much I/O :)
<ogra> we had 0.3 until now
<lool> It only took 10 minutes in jaunty
<Keybuk> lool: right, as ogra said; 0.6 is basically a rewrite
<NCommander> Keybuk, we've had issues w/ that before with libipc-sharelite-perl
<lool> Keybuk: Did < 0.6 have large source files as well?
<lool> Keybuk: I'm trying to decide whether it's a regression the toolchain
<Keybuk> lool: some relatively large source files in the test suite, yes
<lool> jaunty's upstart built relatively fast: Build needed 00:10:48, 22740k disk space
<Keybuk> jaunty's upstart had fewer tests
<lool> It didn't have test_node.c though
<ogra> you cant compare them
<Keybuk> lool: it didn't link to libdbus either
 * NCommander wonders how much swap the buildds have ...
<NCommander> rimu has a little under 1.5GB worth of swap; I think the buildds are setup the same ...
<lool> Keybuk: Couldn't we split at least the test_path_valid/test_new/test_start_tag etc. into separate files?
<Keybuk> lool: no, the test suite doesn't work that way
<lool> test_proxy_functions is the huge function; 10k lines
<lool> Keybuk: What do you suggest?
<Keybuk> lool: fix gcc
<Keybuk> hell, I thought we had commercial engagements with the maintainers of the gcc ARM port for precisely this reason
<superm1> Keybuk, ping.  I missed you last week, so I'll retry: I'm having a hard time figuring out something going on with a udev rule.  [ACTION=="add", SUBSYSTEM=="bluetooth", RUN+="/usr/sbin/bluetoothd --udev"] is the rule.  it works fine if the device is hotplugged, but not if the system boots up with the device plugged in.  Any ideas?
<Keybuk> superm1: /usr not mounted when the system is booted?
<superm1> Keybuk, so shouldn't udev be retrying any failed rules then?
<superm1> but that sounds like a sensible reasoning
<Keybuk> superm1: no, it doesn't
<superm1> is there any way to specify in said rule then to defer running it until /usr gets mounted?
<Keybuk> superm1: no
<Keybuk> superm1: indeed, such things are deliberately not permitted
<Keybuk> bluetoothd should probably be in / anyway?
<superm1> Keybuk, oh well when you were saying /usr I was thinking you meant / (and /usr being on /). It is in /
<Keybuk> dunno then
<Keybuk> what does your logs say?
<superm1> well I'm having a hard time figuring out how to get verbose logs from during boot. the init script makes it look like they should be ending up /dev/.udev/, but I'm not seeing logs there
<superm1> /var/log/udev definitely does show an add event for a device on the bluetooth subsystem
<Sarvatt> it isnt loading v4l devices at boot for me and a bunch of people too (no webcams)
<Keybuk> superm1: right, I'm betting /usr/sbin/bluetoothd is failing in some strange way
<Keybuk> ie. that it's not a udev bug
<Keybuk> probably tries to write to the filesystem or something
<superm1> well they've got it working in fedora devel with this udev rule, so I was leaning towards some type of integration problem here. i'll try'n switch it out with a daemon that I know should work then
<Keybuk> run a shell script around it and capture the output?
<pitti> superm1: cool, thanks
<superm1> can't write to the filesystem that early though can you?
<cjwatson> use /dev/
<pitti> superm1: hm, "OS" seems prone to false positives
<cjwatson> /dev/.initramfs/ for example
<pitti> superm1: in that generality I think it'd be better to do as an OEM rule
<superm1> pitti, okay will keep it that way then thanks
<pitti> superm1: no chance to slam a "special" partition type to it?
<superm1> pitti, it unfortunately really is a vfat partition
<pitti> superm1: like 27?
<pitti> superm1: sure, but vfat is the file system
<superm1> dellutility really is a special type that has other data embedded in it
<pitti> superm1: it could still be partition type 27, as opposed to 06 or 0b
<pitti> okay
<Ng> am I the only person seeing ubuntu-bug cause ff35 to crash in karmic? it looks to be spinning up a new instance of ff which immediately crashes :/
<Ng> I've asked a couple of other karmic users and they are able to file bugs fine with ubuntu-bug and ff35
<Caesar> Wee
 * Caesar just read #389322
<Caesar> pitti: what's your preferred way forward for bug 389322 on Hardy?
<ubottu> Launchpad bug 389322 in pidgin "Yahoo server authentication changed: Pidgin =<2.5.6 will not connect to Yahoo! servers." [Undecided,Confirmed] https://launchpad.net/bugs/389322
<ScottK> Caesar: IIRC there's a fixed package in hardy-proposed.
<pitti> Caesar: hm, someone backporting the fix and sending it to the bug? :-)
<pitti> ScottK: only in jaunty-updates
<ScottK> Ah.  Misemembered.
<ScottK> ..r..
<Caesar> pitti: so you're cool with a honking great big debdiff?
<pitti> Caesar: whatever works; jaunty-proposed debdiff was huge, too
<Caesar> Yeah, so I saw
<pitti> but if it only touches the yahoo protocol, it can hardly get any worse
<Laney> if you can succeed where I failed, please go ahead
<Caesar> Okay, I'll see about cooking up a debdiff
<Laney> Caesar: I'll send you what I got if you like
<pitti> Caesar: gret, thanks!
<Laney> I just couldn't get it to work
<Caesar> Laney: sure
<Caesar> I think we have some Pidgin developers on staff
<Caesar> So they might be able to help
<Laney> oh
<Laney> I think I deleted it Â¬_Â¬
<Caesar> Laney: no biggie
<Laney> the simple backport didn't work anyway, kept throwing nss problems
<Caesar> Yay
<Laney> but good luck
<jsteel> Hi. I'm trying to build a custom kernel with a patch to support the latest winbond watchdog. I run `fakeroot make-kpkg --initrd --append-to-version=-custom kernel_image kernel_headers` and everything works great except the /lib comes out to be 1.1GB. Compare that to the 100-200MB that the server image creates in lib. Does anybody know how to make my image smaller? Whats the magical incantation to make?
<BUGabundo> pitti: around? https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/389686
<ubottu> Ubuntu bug 389686 in metacity "compiz --replace fails to kill metacity, resulting in cpu overload" [High,Triaged]
<BUGabundo> oops
<BUGabundo> wrong link ehe
<BUGabundo> pitti: https://bugs.launchpad.net/ubuntu/+source/gui-ufw/+bug/398945
<ubottu> Ubuntu bug 398945 in gui-ufw "File "/usr/share/gufw/gufw.py", line 42, in <module>" [Undecided,New]
<radix> so, uh, has anyone else received (private) responses to u-d-d posts from a guy named "Kevin Croissant" containing a link to a javascript hack which DoSes firefox while displaying extremely disturbing images?
<maco> radix, i have not, but thank you for the warning
<kirkland> seb128: around?
<seb128> kirkland, yes
<kirkland> seb128: hi, update-notifier question for you
<BUGabundo> hey kirkland
<kirkland> seb128: http://pastebin.ubuntu.com/217283/
<seb128> kirkland, update-notifier is mvo's but sure if I can reply
<kirkland> seb128: ah, right, i saw your name in the changelog recently, and mvo is not around ;-)
<kirkland> BUGabundo: hang on a second
<kirkland> seb128: i was about to commit that change to bzr
<kirkland> seb128: i'd like to upload too, but i see that 0.86 is not yet uploaded to karmic
<kirkland> seb128: so i was nervous about pushing
<BUGabundo> kirkland: don't bother. just waving o/
<kirkland> ah, hello
<seb128> kirkland, better to ping mvo about it tomorrow or drop him an email
<kirkland> seb128: okay, thanks
<seb128> kirkland, looking at the source update-mot.d doesn't seem used at all by update-notifier
<kirkland> seb128: i thought you guys might be off for Bastille day tomorrow
<kirkland> seb128: yes, it should be
<kirkland> seb128: in the links
<seb128> kirkland, I am, german guys and mvo are not ;-)
<majikman> are there plans to modify tomcat so that it doesn't log to syslog?
<kirkland> seb128: doh!  sorry
<seb128> kirkland, nothing to be sorry about ;-) you will probably get a reply from mvo tomorrow
<kirkland> seb128: cool, thanks.
<davmor2> guys due to kms and intel the text for ejecting cd press enter to continue is tiny.  Is this a set font size?
<BUGabundo> seb128: still here? did something change on gnome for karmic, not allowing apples to be dragged with mouse middle click?
<seb128> BUGabundo, there is new tarballs every 3 weeks for GNOME I expect that something changed yes, we would not bother doing 60 uploads of nothing
<seb128> BUGabundo, I just moved the clock and the wcnk applet there, works correctly
<seb128> the menus too
<BUGabundo> seb128: not for me! let me find some one else
<seb128> did you lock those applets?
<sebner> seb128: don't forget to re-enable gnome tetris as clutter 0.9.x is now in karmic :P
<BUGabundo> seb128: yes they are unlocked
<seb128> sebner, ah ah, it's far to be on the CD though
<sebner> heh
<NCommander> pitti, ping, has there been any issues w/ the apport-retracer on karmic recently?
<chrisccoulson> seb128 - this g-c-c update is a pain ;)
<BUGabundo> seb128: seems I can't confirme it on another system... but it does happen on this one :(
<chrisccoulson> it doesn't build without libgnomekbd from git
<seb128> chrisccoulson, I'm sure you can win over it ;-)
<chrisccoulson> most probably. i might not get it finished tonight though ;)
<seb128> NCommander, what sort of issue?
<chrisccoulson> shall we wait for a libgnomekbd tarball or do you want me to package it from git?
<NCommander> seb128, Can't exec "/tmp/libssl0.9.8.config.87075": Exec format error at /usr/share/perl/5.10/IPC/Open3.pm line 168. and issues with update-alternatives
<NCommander> seb128, same issue popped up on both powerpc and armel, so I'm kinda curious to figure out what's going on
<seb128> NCommander, well the retracers only use apport-retrace which meanwhile use a chroot
<BUGabundo> seb128: I got this on identica: "jacob: @bugabundo Working only on icons and the notification area. Everything else is stuck, even though unlocked. "
<seb128> not sure about that issue
<NCommander> seb128, I think its a bad interaction between fakechroot, the auto-update, and karmic
<seb128> could be
<seb128> needs debugging I guess
<NCommander> I was hoping the same issue would pop up on i386/amd64, but that doesn't seem to be the case
<seb128> chrisccoulson, I've no strong opinion, patch backport, git snapshot
<seb128> chrisccoulson, I can try pinging upstream when he's around but that's not the case right now
<chrisccoulson> seb128 - no problem. i'll put the g-c-c update to one side for now and work on the gnome-session one
<seb128> ok
<BUGabundo> seb128: another user just confirmed it again. should I open a bug and upstream it ?
<directhex> TheMuso, gabaug's got a11y working in banshee's infamous listview :)
<seb128> no
<BUGabundo> seb128: ok
<seb128> BUGabundo, on what applets do you get the issue?
<BUGabundo> most of them to me
<BUGabundo> but the some do work
<seb128> names!?
<BUGabundo> gnome-monitor, netspeed, diskmounter
<seb128> some standard ones?
<BUGabundo> doesn't are among thes ones don't work
<seb128> ie menus, mixer, wnck, clock, weather, etc?
<BUGabundo> time, menu, work
<BUGabundo> funny.... bright doesn't ,but xkills does work
<seb128> open a gnome-panel bug if you want, upstream would be better if you can open it there too
<BUGabundo> I can
<BUGabundo> I will
<seb128> thanks
<BUGabundo> seb128: should I file upstream on 2.27 snapshot or 2.26, cause gnome-panel is still 2.26.3?
<BUGabundo> https://bugs.edge.launchpad.net/ubuntu/+source/gnome-panel/+bug/399031
<ubottu> Ubuntu bug 399031 in gnome-panel "some applets are not draggble with mouse middle click" [Undecided,New]
<seb128> BUGabundo, there is no 2.27 so 2.26
<BUGabundo> gnome-media:  Installed: 2.27.3.1-0ubuntu1
<BUGabundo> seb128: and I see it on the dropdown list on bugzilla.g.o
<seb128> BUGabundo, gnome-media for applets?
<BUGabundo> even my about says so Version: 2.27.3
<BUGabundo> seb128: no... for gnome
<seb128> BUGabundo, you want gnome-panel
<BUGabundo> ok
<seb128> well gnome-media has 2.27 tarballs
<seb128> gnome-panel doesn't
<BUGabundo> seb128: upstream http://bugzilla.gnome.org/show_bug.cgi?id=588488
<ubottu> Gnome bug 588488 in Panel "some applets are not draggble with mouse middle click" [Normal,Unconfirmed]
<seb128> BUGabundo, thanks
<BUGabundo> seb128: np
<TheMuso> directhex: Great. I am not a banshee user.
<TheMuso> directhex: But good news nonetheless.
<directhex> TheMuso, well, yes. banshee's had a11y problems for years
<directhex> which doesn't cause *me* issues, but i hear some folks without perfect vision like to use computers...
<maco> also, nose prints on the screen aren't so fun :P
<ion> maco: I officially have a nose print on my screen. I had to test whether the touchscreen can be controlled with a nose. :-P
<maco> haha...i was referring to my tendency over time to get closer and closer to my screen. if i dont stop and notice that i'm only 2 inches away...im sure one day i'll smack right into it
<slangasek> pitti: where did hal's Recommends: smartdimmer go?  component-mismatches wants to demote smartdimmer now
<ajmitch> slangasek: a MIR needs to be filled out for any package recommended by something in main, right?
<slangasek> ajmitch: yes
<ajmitch> thanks, I think I'll change it to suggests for a bit instead
#ubuntu-devel 2009-07-14
<isamar> hi folks
<isamar> needing a hand with custom install cd and ubuntu installer..
<isamar> it's freezing when loading bash package.
<isamar> no sure but looks like libncurses is not being loaded for some reason...
<isamar> anyone?
<DPic> Can somebody help move Empathy dependencies to main and change the desktop seed? https://bugs.launchpad.net/ubuntu/+source/telepathy-farsight/+bug/388898
<ubottu> Ubuntu bug 388898 in telepathy-farsight "Move Empathy Dependencies to Main and Update Desktop Seed" [High,Fix released]
<Caesar> dtchen: ping?
<Caesar> Why did you mark bug 192590 as "Fix Released"?
<ubottu> Launchpad bug 192590 in graphviz "dotty hangs" [Low,Fix released] https://launchpad.net/bugs/192590
<Caesar> I see no evidence of this being the case for Hardy
<Ampelbein> Caesar: it is "Fix Released" because it is fixed in the development version, karmic koala. See https://wiki.ubuntu.com/StableReleaseUpdates for info on how to request an update for previous versions of ubuntu.
<Caesar> Ampelbein: did you look at the bug in question?
<ScottK> Caesar: What bug it is doesn't change the fact that Hardy isn't relevant for marking a bug fix released.
<Caesar> ScottK: I suspect we're in violent agreement here
<Caesar> Basically it looks like someone was preparing an SRU, possibly went dark, and then in the meantime someone marked the bug as Fixed
<Caesar> Meanwhile, down on the Hardy ranch, the bug is still very much alive and well
<Ampelbein> Caesar: the debdiff was submitted when hardy was still in development, there were some problems with it and the patch submitter didn't bother to do the changes requested. So now it's still broken in hardy, there you are right. If you want it fixed, I'm afraid you'll have to request a SRU.
<Caesar> Right then
 * Caesar digs out his SRU-making pants
<Ampelbein> Caesar: you can check with one of the team members on irc first to see If they are likely to approve it: https://edge.launchpad.net/~ubuntu-sru/+members
<billybigrig> does anyone know why the nvidia module won't build in dkms? i compiled the daily kernel from linus's tree...and installed the headers, source, and image, but dkms won't build the nvidia module
<Ampelbein> billybigrig: any error message?
<billybigrig> yeah
<Ampelbein> billybigrig: care to share it?
<billybigrig> sudo dkms add -m nvidia -v 185.18.14 -k 2.6.31-rc2-billybigrigger-07.13
<billybigrig> err whoops
<billybigrig> sorry
<billybigrig> :(\
<Ampelbein> ;-)
<billybigrig> ya i care to share gimme a sec :P
<billybigrig> Error! Bad return status for module build on kernel: 2.6.31-rc2-billybigrigger-07.13 (x86_64)
<billybigrig> and then says consult make.log
<billybigrig> so it says...
<billybigrig> *** Unable to determine the target kernel version. *** make: *** [select_makefile] Error 1
<billybigrig> sudo dkms build -m nvidia -v 185.18.14 -k 2.6.31-rc2-billybigrigger-07.13
<billybigrig> that is the command i tried
<TheMuso> billybigrig: How did you install the kernel headers, and where did you put them?
<billybigrig> linux-headers-2.6.31-rc2-billybigrigger-07.13_2.6.31-rc2-billybigrigger-07.13-10.00.Custom_amd64.deb
<TheMuso> billybigrig: How did you build the kernel?
<billybigrig> CONCURRENCY_LEVEL=3 time fakeroot make-kpkg --initrd -append-to-version=-billybigrigger-07.13 kernel_image kernel_headers kernel_source > ~/make.log 2>&1 && git reset --hard origin/master && git clean -xdf && git pull
<billybigrig> from a git clone of linus's tree
<TheMuso> And you only had one headers package get built? Did that package create a build symbolic link in /lib/modules/kernelversion?
<billybigrig> billybigrigger@cabo:/lib/modules/2.6.31-rc2-billybigrigger-07.13/build$ ls
<billybigrig> you want to see the list?
<TheMuso> Is there a symbolic link called build there?
<TheMuso> If not, create a symbolic link called build, which links back to the headers directory for the kernel in /usr/src
<billybigrig> im in build
<billybigrig> billybigrigger@cabo:/lib/modules/2.6.31-rc2-billybigrigger-07.13$ ls
<billybigrig> build is cyan colored when i ls
<billybigrig> im pretty sure thats a symlink isn't it?
<billybigrig> lrwxrwxrwx 1 root root     30 2009-07-13 16:40 build -> /home/billybigrigger/linux-2.6
<billybigrig> yeah so thats right
<TheMuso> Ok. Where did the headers package install the header files? In /usr/src?
<billybigrig> yes
<TheMuso> I suggest changing the build symlink to point to that directory where the headers are instead.
<billybigrig> sudo rm build && sudo ln -s /usr/src/linux-headers-2.6.31-rc2-billybigrigger-07.13/ build
<billybigrig> ?
<billybigrig> or is it build /usr/src/linux-headers-2.6.31-rc2-billybigrigger-07.13/
<billybigrig> and i guess it would be build/ right?
<TheMuso> no the former is correct
<TheMuso> The /  is not needed
<billybigrig> so /usr/src/xxxxx build
<TheMuso> yep
<billybigrig> lrwxrwxrwx 1 root root     55 2009-07-13 18:48 build -> /usr/src/linux-headers-2.6.31-rc2-billybigrigger-07.13/
<TheMuso> man ln for more info
<billybigrig> k
<TheMuso> yep that looks fine
<TheMuso> now try and run the dkms command again
<billybigrig> nice
<billybigrig> thanks TheMuso
<billybigrig> nvidia, 185.18.14, 2.6.31-rc2-billybigrigger-07.13, x86_64: installed
<billybigrig> is there a way to re-build all dkms modules?
<billybigrig> i have a few and would rather not do them manually
<billybigrig> a bunch of vbox stuff
<billybigrig> like how dkms does its post-inst stuff after a kernel image install, where is that script located?
<billybigrig> can't i just run that?
<TheMuso> billybigrig: I don't know how thats done sorry.
<TheMuso> man dkms may tell you however.
<billybigrig> still cant boot that kernel
<TheMuso> billybigrig: ah "sudo /etc/init.d/dkms_autoinstaller start kernelversion"
<TheMuso> should do it
<sleepster> I just need a kernel with CONFIG_HZ = 1000... I am using ubuntu server and the default kernel is set to CONFIG_HZ = 100... is there a pre-built kernel I could use with this option?
<sleepster> or is there a way to use ubuntu server with the desktop kernel installed?
<ScottK> You can install the desktop kernel and use it, but that's a support question and not a development question.
<sleepster> ScottK: ah.. okaythanks
<ScottK> Lovely.  Reliable and repeatable OOo crash in a document that has business sensitive stuff in it so I can't use it for a bug report ....
<lifeless> \o/
<StevenK> ScottK: But that's how it always happens ...
<ScottK> Right.  It's not like I'm suprised.
<ScottK> It's one of these fill-in the form and you can't change all these parts and it must be just so work document that is exactly the kind of thing that would be bugged.
<ScottK> work/word
<lifeless> morale of the story, don't use Oo. for anything you care about?
<ScottK> What's your alternative that handles MS Office file formats?
<ScottK> Everything else I know of sucks even more.
<StevenK> I didn't think abiword or gnumeric handled the embedded stuff?
<ScottK> I don't think so.
<ScottK> Kwrite neither.
<vanz> hi
<ScottK> For a while I tried including an ODF copy with the MS Office copy of stuff I sent to customers to raise awareness.  Then $LARGE_CORPORATION's spam filter decided ODF was dangerous and must be blocked.
<TheMuso> ouch
<ScottK> I had a nice chat with their mail admins, but their spam filtering software was proprietary so all they could do is file a bug with the vendor.
<ScottK> So then I decided not getting fired for not sending stuff was more important than raising awareness.
<\sh> moins
<pam> Does anyone know where is the official ISO build described? I need to test some changes to isolinux (assuming the karmic iso uses karmic's isolinux).
<dholbach> good morning
<JonDoe297> dholbach: good morning :)
<dholbach> hey JonDoe297
<pitti> Good morning
<pitti> NCommander: retracer> just launchpadlib crashing with HTTP 500 errors a lot
<StevenK> pitti: UNR (and Ubuntu) livefs builds are broken due to brasero and nautilus-cd-burner Conflict'ing, halp?
<pitti> slangasek: re-added; hm
<pitti> StevenK: hm, drop n-c-d?
<pitti> StevenK: I think it was done as an upgrade cleanup
<StevenK> pitti: We don't seed n-c-d
<StevenK> piA nautilus             Recommends nautilus-cd-burner | brasero (>= 2.26)
<StevenK> And I think germinate will always jump for the first
<pitti> StevenK: ah, I guess the ubuntu desktop seeds seed brasero earlier than nautilus or so
<pitti> StevenK: where did you see this, BTW?
<pitti> http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/karmic/ubuntu/latest/livecd-20090713-i386.out is differntly broken
<StevenK> 0714
<pitti> http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/karmic/ubuntu/latest/livecd-20090714-armel.out is an evolution thingy
<pitti> any/all desync, as it looks?
<pitti> interesting, _all_ arches have a different failure
<StevenK> Yeah, Ubuntu i386 hasn't tried yet
<StevenK> Anyway:
<StevenK> pi  ubuntu-netbook-remix Recommends rhythmbox
<StevenK> pi  rhythmbox            Depends    libbrasero-media0 (>= 0.9.1)
<StevenK> piA libbrasero-media0    Recommends brasero
<pitti> so is this since yesterday then?
<pitti> brasero was added ages ago
<StevenK> Right, so UNR should seed brasero, too?
<StevenK> I don't think that makes sense.
<pitti> StevenK: oh, did you already NBS out libsgutils{1,2}?
<StevenK> pitti: I've not done NBS in a week or so
<pitti> I did the transition yesterday, but no NBSing yet
<pitti> StevenK: we could just flip around the nautilus dep
<StevenK> pitti: That works
 * pitti uploads
 * \sh should write a rant about klibc's ipconfig dhcp crap inside initramfs while using real network switches and not soho cheap table switches from netgear
<pitti> kirkland: thanks muchly, this is so much better now
 * mneptok is about to fly to Armonk and set IBM on fire
<maco> question: if i have a debdiff for a package waiting for sponsorship to close one bug and i have another bug in that package that i want to fix, should i do the debdiff for this bug against the currently-in-karmic version or against the one that's waiting for sponsorship?
<mneptok> and not happy, warming Yule log fire. ANGRY BALROG MOUTH FIRE!
<maco> or just put one debdiff to do both?
<\sh> maco: do one debdiff to do both...add both (LP: #<bugno>) to the changelog in the debdiff
<maco> ok. ive been told before one bug per upload so wasnt sure
<\sh> maco: TBH i don't think there is a policy or rule...but could be wrong..
<maco> im gonna guess it was just a housekeeping thing. and with quilt, youve got plenty of housekeeping
<maco> :( lp timing out
<\sh> maco: btw...I added some links about the cult of virgin mary to mdzs blog .. just waiting until he moderates his comment area
<dholbach> robert_ancell: you writing a gdm replacement? pitti said so! :)
<pitti> ... configuration :)
<dholbach> that's going to be headline news tomorrow
 * robert_ancell feels thrown to the wolves :)
<\sh> it's all about marketing ;)
<robert_ancell> I've got the GUI mocked up and know the config to change.  The difficulty is navigating the policykit/dbus/... in between
<maco> i didnt break quilt this time :D
 * TheMuso kicks speech-dispatcher's autotools files where it hurts most, and leaves it for tomorrow. :)
<StevenK> maco: Are you sure?
<maco> StevenK, yes. quilt informed me that my patch level was wrong (forgot to add little a/ and b/ to --- and +++ lines) and then i push -a'd and it was happy
<maco> i even remembered the QUILT_PATCHES env var
<StevenK> quilt always curls up into a little ball when I mistreat it
<maco> ive been actively using quilt for the last 2 weeks, so its soaking in
<maco> though ive only got the routine down for quilt import so far. havent tried the start quilt, edit things, stop quilt thing yet
<StevenK> All this mentioning of quilt is making me want to sob
<maco> what if its the kind little amish women sew?
<maco> i can go grab my needlecraft stuff to trick your brain...
<StevenK> maco: I wasn't aware you were Amish
 * StevenK hides
<maco> my facebook profile used to list Amish as my religion
<StevenK> Hah
<maco> a scarily large number of folks believed it
<maco> amish...facebook...amish...facebook...
<\sh> twitter, facebook, youtube what product comes next to steal important life and working time
<maco> is youtube newer than facebook?
<maco> wait, twitter too?
<\sh> in the beginning there was usenet ,-)
<maco> heh
<maco> hmm on the hundred papercuts thing. if youre just reporting a bug so youll have something to hang the debdiff on, is it worth marking it as a papercut?
<pitti> maco: just subscribe sponsors, FWIW
<pitti> maco: the papercut queue is pretty full, and IIRC David asked not to add more
<maco> pitti, ok thanks
<sbeattie> maco: a friend of mine lists his religion on facebook as chaotic good.
<maco> hey mine currently says Church of Vi
<maco> one friend asked what about my Pastafarianism. i said "polytheism"
<cjwatson> pam: I just keep some canned runes around derived from how the CD image building stuff works ...
<cjwatson> sudo mkisofs -r -V 'Ubuntu 9.10 i386' -o karmic-alternate-i386-hacked.iso -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table new-i386
<ogra> pitti, my powermanager tends to crash after some time, is there a known bug for this ?
<pitti> ogra: not to me, but I'm not regularly following them
<ogra> hmm, k
<pitti> ogra: yesterday's update fixed a bug which made gpm crash when the battery got full
<ogra> ah, that might be it, though i rarely unplug at home and didnt actually monitor when exactly its happening ...
<ogra> i have the brightness applet in my panel and notice that it is crossed out in the morning usually until i fire up the power prefs
<ogra> nothing intresting in .xsession-errors ...
<liw> .xsession-errors is a sucky logging facility...
<pitti> ogra: no apport crash either?
<ogra> (it would reallly help to have timestamps in that file)
<ogra> nope, no apport
<pitti> ogra: but perhaps it's fixed with yesterday's update
<liw> ogra, http://blog.liw.fi/posts/userlog/ :)
 * ogra runs an upgrade and will watch if it occurs again tomorrow morning
<svqyqb> http://tinyurl.com/nkypfa
<ogra> liw, :)
<ogra> liw, sounds like something to spec next UDS to me
<ogra> though i would be happy already if we had timestamps
<maco> pitti, where does jockey get the text it displays explaining the driver it's offering?
<maco> (i see you in (C) line)
<maco> nevermind. i figured it out.
<pitti> maco: ok :)
<ogra> seb128, did you upload gtk and the apps out of order again ?
<ogra> The following packages have unmet dependencies:
<ogra>   gnome-icon-theme: Depends: libgtk2.0-bin but it is not going to be installed
<seb128> ?
<ogra> is what i see on armel
<seb128> there is no order, gtk didn't change abi or soname or anything
<ogra> hmm, strange
<seb128> well that probably means that gtk didn't build on armel
<ogra> i'll try a give back of evo and friends
<pitti> arch all/any desync
<seb128> and arch any and all binaries are out of sync
<ogra> it isnt on the ftbfs list, i think its just a timing issue
 * ogra gives back gtkhtml
 * ogra grumbles at whoever gave back mesa on armel 
<dholbach> james_w: did you say you have a fix for the harvest-django filter problem?
<james_w> dholbach: a partial one
<james_w> I have a better idea though
<Keybuk> heh, I can't seem to edit bug titles in LP today
<dholbach> james_w: I was just thinking "having the fix/workaround in trunk already would make testing and playing with it more interesting" :)
<james_w> ok, ok :-)
<ogra> hmm, why is pbuilder attempted to be built on the ports arches ?
<ogra> Package: pbuilder
<ogra> Architecture: all
<ogra> weird
<Quintasan> How should I deal with package that uses a src directory? When you untar the package there is only install.sh src/ and README. Pbuilder complains about missing CMakeLists.txt.
<cjwatson> err that depends on what's in src/ :-)
<cjwatson> basically your debian/rules build needs to do whatever the package says needs to be done to build its source code
<cjwatson> there are no fixed rules
<ogra> oh, hmm
<ogra> Package: pbuilder-uml
<ogra> Architecture: i386 amd64
<Quintasan> cjwatson: it's a plasmoid, I use pkg-kde-tools for compiling it. I think DEB_SRCDIR = src might solve it
 * ogra wonders why armel isnt respecting "Architecture: i386 amd64" in the control file
<cjwatson> ogra: Packages-arch-specific controls what is *attempted*. if debian/control forbids it then of course it will fail
<ogra> cjwatson, well, it even attempts to build pbuilder-uml in a local build
<ogra> (on armel)
<ogra> "Architecture: i386 amd64" should prevent that, shouldnt it ?
<cjwatson> ogra: should it?
<ogra> i would expect it to :)
<cjwatson> you expect wrong :)
<ogra> seemingly
<cjwatson> ogra: whether a source package attempts to build one of its binary packages is controlled entirely by debian/rules, not by debian/control
<cjwatson> after all it's just what debian/rules build / binary depend on
<ogra> well, all pbuilder-uml stiff is in binary-arch
<ogra> while all the rest is in binary-indep
<ogra> doesnt seem wrong to me
<cjwatson> so why should it magically not get built then?
<cjwatson> a -B build basically just does debian/rules build && fakeroot debian/rules binary-arch
<cjwatson> if the package wants to do things only on certain architectures, it needs to conditionalise that in debian/rules
<ogra> hmm, wouldnt it make more sense to check the control file ?
<cjwatson> maybe if we were doing it from scratch; but it's not done that way now
<ogra> if its not Architecture all or any at least
<ogra>        -s, --same-arch
<ogra>            This is a smarter version of the -a flag, that is used in some rare circumstances. It understands that if the control file lists "Architecture: i386" for the
<ogra>            package, the package should not be acted on on other architectures. So this flag makes the command act on all "Architecture: any" packages, as well as on any
<ogra>            packages that have the current architecture explicitly specified.  Contrast to the -a flag, which makes the command work on all packages that are not architecture
<ogra>            independent.
<ogra> cjwatson, ^^^
<ogra> then i dont understand the debhelper manpage
<ogra> (pbuilder uses "dh_builddeb -s" for binary-arch
<ogra> )
<ogra> (well, it uses -s not only for builddeb but for all commands)
<ogra> i wonder if that flag not doing what is described is a fallout of the --dpkg-print-architecture change in dpkg
<ogra> *--print-architecture
<cjwatson> ogra: that causes *those specific debhelper commands* to act on the named packages
<cjwatson> ogra: why don't you use DH_VERBOSE=1 so you can see exactly what's going on?
<cjwatson> you seem to be blaming the tools, which IME is usually a mistake
 * ogra does so ... but the code didnt change, the tools did though
<cjwatson> they aren't perfect but it's not usually a good bet for a first guess
<cjwatson> BTW, why is it a problem for pbuilder to harmlessly fail to build on non-x86 architectures?
<cjwatson> you can just ignore it
<ogra> it fills up my ftbfs list ...
<cjwatson> you can still just ignore it :)
<ogra> just sense of cleanness :)
<cjwatson> pbuilder-uml is listed in Packages-arch-specific, so it's probably a Soyuz bug that it's tried
<ogra> wel, my local system doesnt have PAS
<cjwatson> then it'll fail on your local system. big deal :)
<ogra> if i want to roll pbuilder here from source it fails
<ogra> well, it actually doesnt because it calls arch-indep first if built locally, so i get my pbuilder deb ...
<ogra> *build
<cjwatson> BTW it can't possibly be fallout from the dpkg change you mention
<cjwatson> 1) debhelper uses dpkg-architecture not dpkg --print-installation-architecture 2) dpkg --print-installation-architecture just prints a warning to stderr and calls through to --print-architecture
<ogra> yep, i just looked at Dh_Lib.pm
<cjwatson> debuild -b -aarmel works here
<cjwatson> bunch of whining from dh_* -s but that's all
<cjwatson> you aren't using -B are you?
<ogra> no, and debuild -b -aarmel fails here on my amel machine
<ogra> oh, wait, it fails on signing not due to -s
<ogra> ok, now i'm completely confused
<ogra> Keybuk, ...
<ogra>  * Starting kernel event manager...                                                                                                                                                 error getting signalfd
<ogra>                                                                                                                                                                              [fail]
<ogra> invoke-rc.d: initscript udev, action "restart" failed.
<ogra> Keybuk, thats what i get on armel with a dist-upgrade
<Keybuk> next time we announce a new port of Ubuntu, let's find an architecture that the kernel really supports
<Keybuk> like m68k or something
<ogra> haha
<Keybuk> I assume that ARM has "forgotten" to implement signalfd() or something
<ogra> well, the boards i have all only have a 2.6.26 binary kernel atm
<Keybuk> ah
<ogra> no source ... whats the kernel option that creates signalfd ?
<Keybuk> yeah that probably won't work anyway
<Keybuk> I think the syscall changed in 2.6.27
<ogra> gah
<ogra> i though it changed post .25
<Keybuk> there's no kernel config
<ogra> oh, k
 * ogra just saw bug 397187
<ubottu> Launchpad bug 397187 in ubuntu-on-ec2 "[karmic] udev requires new kernel, breaks on EC2" [Undecided,Confirmed] https://launchpad.net/bugs/397187
<Keybuk> oh, heh
<Keybuk> yeah see my comment there too
<ogra> so i'm not alone
<ogra> yep
<ogra> does upstart *already* use it in 0.6 ?
<Keybuk> yes, but not for anything critical
<ogra> ok
<ogra> i'll try to downgrade udev then until we finally get something usable from the kernel team
<Keybuk> a bug fix going into 0.6.1 makes it use it for critical things though
<ogra> though i bet that will cause other issues
<ogra> grmbl, why isnt signalfd mentioned anywhere in the udev changelog
<ogra> how am i supposed to find out which is the last version i can use :(
<ogra> bah
<ogra> pitti, oh ... Jul 14 13:55:41 osiris kernel: [98748.268006] <6>gnome-power-man[23647]: segfault at 838b0c24 ip 004b0701 sp bfc7ba60 error 6 in libc-2.9.so[43f000+15c000]
<ogra> just found that by accident in my /var/log/messages
<seb128> ogra, use apport to send a bug?
<seb128> ogra, just mentionning a crash on IRC without any detail is of no real use
<ogra> seb128, i'm not up to date with my system yet, i was following up on an earlier conversation
<ogra> bah i was to fast giving back evolution-exchange ...
<mterry> evand, again thanks for the catch.  No summary is normal for me, coming from oem-config land.  :)  I merged your patch
<Keybuk> james_w: how would I make lp:~ubuntu-core-dev/upstart/ubuntu be the "Ubuntu" branch (lp:ubuntu/karmic/upstart) ?
<james_w> Keybuk: I can do that for you
<james_w> however, I'm wary to make *that* branch the one to use given a couple of LP bugs we have at the moment
<james_w> I can push it to another location and make that lp:ubuntu/karmic/upstart
<evand> mterry:  great!  I think given cjwatson's recent comment on the merge page, we're ready.
<james_w> or we can wait for LP to be fixed instead
<evand> I've added you to the installer team, so you'll be able to commit directly to trunk now
 * mterry is nervous anyway
<james_w> also, would we be able to resurrect branches for < karmic?
<mterry> evand, is there a test suite for the installer that the branch has been run through, or can be run through?
<evand> nope, but patches welcome for that
<mterry> evand, oh, thanks for the team add
<mterry> evand, heh
<evand> it is something we have on the horizon, but neither Colin nor myself have found time to write it
<mterry> evand, maybe I could look into that.  I have some experience with ldtp
<evand> mterry: any effort you can make on that would be hugely appreciated
<mterry> evand, OK, well, I'll merge this branch, and keep an eye out for bugs reported, I guess
<pitti> ogra: can you please enable apport then (/etc/default/apport) and send a crash report? thanks!
<ogra> pitti, will do if it turns up with the upgrade, sorry i'm to busy today to donate time to that atm
<pitti> ogra: no prob, just enable apport and let it sort out itself :)
<ogra> yep
<Keybuk> james_w: don't mind if you need to move the branch, the lp:ubuntu/... URL is better ;)
<Keybuk> james_w: there's no real ubuntu/jaunty branches - while there was something in bzr, it actually was buggered up and missing all the changes
<Keybuk> just the changelog entries
<james_w> Keybuk: ok, I could do that
<james_w> not having the branches available is a bit of an annoyance
<Keybuk> james_w: they never really existed properly - you could do an auto-import of them if you liked
<james_w> plus, it would currently take away your ability to write to the branch
<james_w> which I imagine would be a pain for you?
<Keybuk> james_w: err
<Keybuk> it would be kinda helpful to write to the branch :p
<Keybuk> why wouldn't I be able to?
<james_w> because the move would be out of the namespace of a team that you are a member of
<Keybuk> so who can commit to lp:ubuntu/... branches?
<Keybuk> shouldn't that be developers?
<Keybuk> *confused*
<james_w> we are waiting on LP to make the permissions for official branches match the uploaders
<james_w> yes, it should be
<james_w> it is not currently
<Keybuk> oh, who is it currently?
<james_w> and due to the other LP bug I mentioned, the branches can only be owned by the team we are using for "special" privileges
<james_w> it's a team called ~ubuntu-branches
<james_w> it's members are me and jml IIRC
<Keybuk> err
<Keybuk> so
<james_w> and Colin actually
<Keybuk> the lp:ubuntu/ namespace is really just read-only right now?
<james_w> yeah
<james_w> but that will be changing real soon now
<cjwatson> what's the schedule for that bugfix anyway? it's been on the cards for ages
<Keybuk> so I don't want to move the upstart/ubuntu branch there, because the whole point is people commit to it? :P
<james_w> I'm not sure, it doesn't have a milestone yet IIRC
<cjwatson> we need to sit on jml about that
<cjwatson> or possibly thumper
<james_w> Keybuk: yeah, but we can move it once that is fixed
<Keybuk> ok
<Keybuk> when that bug is fixed, does it just become an alias?
<Keybuk> or will it still involve "moving" the branch?
<james_w> bug 347768
<ubottu> Launchpad bug 347768 in launchpad-code "Allow anyone with upload rights to write to a package branch" [High,Triaged] https://launchpad.net/bugs/347768
<james_w> the lp:ubuntu/... thing is an alias
<james_w> however, you can't currently ask which branch that points to using the API without it crashing
<james_w> so there is currently a hard-coded assumption that it is the branches owned by ~ubuntu-branches with a particular name
<james_w> so once that is fixed we can just make the alias point to the ~ubuntu-core-dev branch if we like
<Keybuk> would the same work for lp:debian/
<Keybuk> it might be nice for mbiebl to be able to have br branch lp:debian/sid/upstart for the Debian branch he maintains
<james_w> however, we may want to move it anyway, so that it is a "package branch"
<james_w> it will work for Debian
<cjwatson> james_w: where would LP get information about who can upload to the Debian branches?
<cjwatson> I suppose we could import the Debian keyring but I wasn't aware that we were doing that
<james_w> ah
<james_w> I assume it will have "branch owner, plus those able to upload to the Debian archive through LP"
 * cjwatson comments on 347768
<james_w> which will be no-one
<cjwatson> uploading to the Debian archive through LP would be a pretty odd thing to do :)
<james_w> so only the owner will have write access
<james_w> which I think is ok
<Keybuk> that's kinda boring
<Keybuk> bzr commit --fixes=lp:NNNNNN
<Keybuk> doesn't mark the bug as "Fix Committed"
<Keybuk> and links to the branch, not the revision
<kirkland> Keybuk: yeah, i've been disappoitned with --fixes too
<kirkland> Keybuk: i filed a bug asking bzr/lp to scan the contents of the commit message for "fixes LP: #NNNNNN", because I always mention it there, but always forget it at --fixes
<cjwatson> FWIW debcommit does scan the changelog for LP: so in cases where you use that it works
<Ng> what handles mounting USB devices these days (in karmic, i.e. what should I call ubuntu-bug on?)
<pitti> Ng: hm, nautilus, gvfs, and devicekit-disks, depending on what kind of operation
<Ng> hrm. my phone presents a PTP interface and each time I plug it in I get asked if I want to run f-spot (which is fine). If I don't click Unmount in that dialog and just hit cancel and later unplug the phone nautilus still thinks it has a "Digital Camera (usb:000,007)" device attached. Over the course of the day I end up with about 10 in there
<pitti> Ng: sounds like gvfs then
<Ng> ok
<pitti> could be my bug, I recently did the porting to gudev; can you please assign it to me?
<Ng> pitti: sure, thanks
<Ng> pitti: bug #399320
<ubottu> Launchpad bug 399320 in gvfs "[karmic] PTP devices not auto-unmounting on USB disconnect" [Undecided,New] https://launchpad.net/bugs/399320
<slytherin> Can any of the archive admins clear excalibur-logkit (source) from queue?
<james_w> slytherin: review or reject?
<slytherin> james_w: review
<slytherin> clear as in 'give go ahead'.
<james_w> slytherin: has it been in before as avalon?
<slytherin> james_w: it was in as liblogkit-java
<james_w> ok
<slytherin> james_w: I intend to eventually migrate all r-deps of liblogkit-java to this package because this is the last stable version of the library.
<james_w> slytherin: accepted
<james_w> slytherin: note that debian/copyright doesn't conform to dep-5 by my reading
<slytherin> james_w: really? I thought it ddid. I wrote it from scratch.
<james_w> just small things
<james_w> e.g. it specifies Apache, you used Apache-2.0
<james_w> and a strict reading would suggest your Files: * stanza needs to duplicate the statement about common-licenses
<james_w> or use a standalone license section
<slytherin> oh, ok. I will correct it if I need to upload again.
<james_w> thanks
<slytherin> james_w: Do you mind reviewing the binary as well? It's arch:all package.
<james_w> is it through already?
<james_w> oh yeah
<slytherin> james_w: yes, even I was surprised.
<slytherin> james_w: Got to go. See you later. Thanks for quick review.
<mrec> Hi, does anyone know why I cannot use LD_PRELOAD to intercept stat()?
<Keybuk> mrec: because it's morally wrong
<Keybuk> and are you sure it's stat() you want to intercept, not stat64(), fstat(), lstat(),e tc.
<mrec> Keybuk: why should it be wrong?
<mrec> strace says stat .. although I'll check
<Keybuk> strace tells you underlying syscalls
<mrec> I think almost everything works except stat on ubuntu for some reason
<Keybuk> LD_PRELOAD intercepts glbc library calls
<ion> glbc â is that a fork of glbt?
<mrec> the reason why I need to intercept stat() is I have a usb TV driver written in userspace working across all systems the only reason why it doesn't work with some legacy applications is that they use some kind of stat()
<mrec> the performance is quite good 21 mbyte/second
<mrec> the driver also includes a reimplementation of the linuxdvb and video4linux API so it's compatible with legacy apps
<mrec> tvtime works without any problem
<mrec> without the need of a kerneldriver
<Keybuk> cjwatson: I don't have a GIT branch for your util-linux changes? :)
<vadi2> Hi. In regards to the openjdk news for 9.04, is the certified package already in?
<cjwatson> Keybuk: I sent a patch, and IIRC you said on IRC at the time you would be happy to wrangle it into git for me
<Keybuk> cjwatson: did I?  ok :)
<Keybuk> we're friends, I won't make you use GIT unnecessarily
<Keybuk> cjwatson: unrelated question
<Keybuk> debian/util-linux-udeb.dirs
<Keybuk> contains "sbin"
<Keybuk> but isn't in GIT, is that necessary?
<Keybuk> hmm
<Keybuk> apparently Lamont uploaded to fix that
<Keybuk> but doesn't appear to has pushed
<Keybuk> lamont: ?
<cjwatson> Keybuk: yeah, it is
<Keybuk> oh, no
<Keybuk> "git fetch lamont"
<Keybuk> *sigh*
<Keybuk> HATE HATE HATE
<cjwatson> I certainly remember that coming up ...
<cjwatson> and I think that's why the ln in debian/rules now has a trailing slash
<Keybuk> hmm
<Keybuk> no, that didn't do it
<Keybuk> *confused*
<cjwatson> because if that isn't there, then you get an executable called "/sbin" ...
<Keybuk> oh, no, I see
<cjwatson> if you can point me to the right branch, I can do a git format-patch for you
<Keybuk> git checkout lamont/ubuntu/stable/v2.15
<Keybuk> git checkout -b ubuntu/stable/v2.15
<Keybuk> *sigh*
<cjwatson> I imagine the changelog in the bug is out of date
<cjwatson> I have no lamont/ubuntu/stable/v2.15 branch here ...
<cjwatson> branches should have URLs, damnit. hate
 * cjwatson tries re-cloning
<Keybuk> http://kernel.ubuntu.com/git?p=scott/util-linux.git;a=shortlog;h=refs/heads/ubuntu/stable/v2.15
<Keybuk> right
<Keybuk> I've pushed that
<cjwatson> what's the rune to set up automatic tracking for your branch, given a clone of git://git.debian.org/users/lamont/util-linux.git ?
<Keybuk> git remote add lamont git://...
<Keybuk> though it's not automatic
<Keybuk> you have to "fetch"
<ion> Ah, high-resolution versions. Awesome. http://videos.ubuntu.com/uds/karmic/plenary_1/
<pitti> bazaar.launchpad.net, where are you?
<cjwatson> Keybuk: I'm thoroughly confused about what branch that is
<cjwatson> Keybuk: it claims to be an Ubuntu branch, but the differences between the version I uploaded and it look like this: http://paste.ubuntu.com/218119/
<cjwatson> Keybuk: am I being stupid?
<Keybuk> that looks like you've diffed Ubuntu and Debian
<Keybuk> so..
<Keybuk> there are three GIT repos
<Keybuk> origin - this is Karel's upstream repo
<Keybuk> lamont - this is Lamont's repo on git.debian.org
<Keybuk> keybuk - this is my repo on kernel.ubuntu.com
<Keybuk> each contains many branches
<Keybuk> master - trunk line of development
<Keybuk> stable/v2.XX - stable release line
<Keybuk> and there's a waterfall between them
<Keybuk> so origin/master is merged into lamont/master to form the Debian package
<Keybuk> and that is merged into keybuk/master to form my copy of the Debian package
<Keybuk> and then merged into keybuk/ubuntu/master to form the Ubuntu package
<Keybuk> ie. keybuk/master is Debian, not Ubuntu
<Keybuk> likewise
<Keybuk> origin/stable/v2.15 -> lamont/stable/v2.15 -> keybuk/stable/v2.15 -> keybuk/ubuntu/stable/v2.15
<Keybuk> and you'll find there's a lamont/ubuntu/stable/v2.15 as well
<Keybuk> so basically, depending who did the last upload
<Keybuk> lamont/* or keybuk/* may actually contain the current Debian and/or Ubuntu packages
<Keybuk> I wish to note that this madness WAS NOT MY IDEA
<cjwatson> Keybuk: I'm diffing the last upload with ubuntu/stable/v2.15 in your repo
<Keybuk> cjwatson: the HEAD of my repo, or the release tag?
<cjwatson> 'git checkout keybuk/ubuntu/stable/v2.15'
<Keybuk> ahh
<Keybuk> right
<Keybuk> that makes sense
<cjwatson> 'git checkout -b ubuntu/stable/v2.15'
<Keybuk> I'm updating to 2.15.1
<Keybuk> along with merging back the hwclock stuff into Debian
<Keybuk> http://kernel.ubuntu.com/git?p=scott/util-linux.git;a=commitdiff;h=a1b46c1ff070feaab2387f7b1b1ac5a87389bd5b
<Keybuk> that's the patch I applied from you
<cjwatson> right, that looked correct for the Ubuntu branch
<cjwatson> FSVO "the"
<Keybuk> so what you're seeing is just me resolving some differences between Ubuntu and Debian
<Keybuk> ie. trailing / on dirs and such
<Sarvatt> yuck, timeout increase on arm wasnt enough for mesa
<Sarvatt> Session terminated, killing shell...make: *** [binary-arch] Terminated  ...killed. Build killed with signal 15 after 600 minutes of inactivity
<ogra> Sarvatt, pleasedont give it back, it hogs a buildd for 10h :)
<ogra> mcasadevall made that mistake already
<Sarvatt> the only change between that one and the previous that worked is in a driver that doesnt build on arm, must be something in the build environment that broke
<mcasadevall> Sarvatt, its lzma compression
<mcasadevall> Sarvatt, it takes too long and the build times out
<mcasadevall> Sarvatt, we're debating on what to do about it, some packages should now build with the longer timeout, mesa non-withstanding
<ogra> mcasadevall, can you fire off a local mesa build if you go to bed or something ? so we can see if it actually finishes if there is no timeout (and prefix it with "time" to see how long it took)
<mcasadevall> ogra, I run launchpad-buildd to determine it to rule out any issues with translation stripping and friends.
<ogra> i would do it here but dont have a trustworthy build system atm
<Sarvatt> somewhere between june 30th and july 7th lzma started being a problem then?
<mcasadevall> Sarvatt, I'm not sure what caused it initially; but the lzma compresison of large -dbg packages causes huge amounts of issues
<mcasadevall> Sarvatt, hence why KDE is completely FTBFS ATM
<Sarvatt> Finished: 	2009-06-30 (took 3 hours, 44 minutes, 41.0 seconds)
<Sarvatt> nothing changed besides an added patch that only touches a driver that doesnt build on arm
<Sarvatt> thats really odd
<mcasadevall> Sarvatt, when I did test builds on my local hardware, no issues. Its dying during compression
<Sarvatt> did KDE start failing to build on arm at a certain date or has it always?
<ogra> .oO( we should probably be on #ubuntu-arm with that conversation )
<nelhage> Does anyone have thoughts on bug #399368? In particular, it seems to me the new version pushed today is an example of an issue it's not really worth requesting a reboot for, but I'm wondering if I'm missing something.
<ubottu> Launchpad bug 399368 in dbus "dbus should not require a reboot on every upgrade" [Undecided,New] https://launchpad.net/bugs/399368
<ebroder> Do you strictly need a reboot to restart dbus? I don't think you do for, e.g., a gdm-less system
<ebroder> (Of course, I don't get popups about needing to reboot my gdm-less systems)
<mcasadevall> doko, ping?
<doko> mcasadevall: ?
<mcasadevall> doko, are we building with VFP by default for GCC?
<doko> mcasadevall: no
<mcasadevall> doko, I thought we decided to make that change at the start of the cycle
<mcasadevall> doko, what compiler flag will get me VFP enabled?
<doko> mcasadevall: -mfpu=vfp -mfloat-abi=softfp (and maybe you should add -march=armv7 -mtune=cortex-a8)
<slytherin> cjwatson: Does this approach ok to you to workaround build failures on powerpc - http://paste.ubuntu.com/217917/
<cjwatson> slytherin: it's being fixed on the buildd side, according to infinity
<cjwatson> so no, I don't think that workaround is OK
<cjwatson> it'd be a lot of work (a) to do it (b) to revert it later
<slytherin> cjwatson: Ok. If it is being worked on then I have no problem.
<cjwatson> the bug is apparently that the powerpc buildds are still on a dapper base system, unlike other architectures
<slytherin> I thought it was too much work to fix on buildd side.
<cjwatson> infinity seemed to reckon it was tractable in sbuild
<slytherin> hmm.
<cjwatson> he didn't elaborate on how
<infinity> The "when" is more important than the "how", really.
<infinity> And I tihnk I'm going to have to make time to do it this week.
<slytherin> infinity: I wish I could help anyway, but I have no idea about sbuild.
<ccheney> cjwatson: ping, germinate 1.16 in bzr is listed as released 2009-06-17 but its not in karmic yet?
<jml> cjwatson, I'm going to start working on it today
<cjwatson> ccheney: odd, I don't know what happened to it. I've reuploaded it to Debian
<cjwatson> jml: thanks
<jml> cjwatson, I've wanted to do it earlier, but I've been thwarted at every turn.
<jml> mostly by prep for open sourcing Launchpad.
<cjwatson> jml: a worthy cause, I'll admit ;)
<BUGabundo> is Colin around? wanna ask him about swap on file
<BUGabundo> clean install and I'll be testing it on karmic
<BUGabundo> cjwatson: ping ^^^^^^^
<cjwatson> BUGabundo: no progress on implementation yet
<BUGabundo> but will it work?
<BUGabundo> it is usable cjwatson?
<BUGabundo> will I be able to hibernate?
<cjwatson> it is not implemented yet
<cjwatson> there has been *no progress*
<cjwatson> it's targeted for a later milestone in karmic, not the one currently in preparation
<BUGabundo> I know I read it
<cjwatson> we are working on other things right now
<BUGabundo> but what was/is the current state?
<cjwatson> I have no idea
<BUGabundo> ohh
<cjwatson> I have not looked at it beyond what I did to write up the specification
<BUGabundo> ok
<BUGabundo> I'll be using
<BUGabundo> hope I don't mess it much
<BUGabundo> cjwatson: if you need further testing along the cycle ping me on #ubuntu+1 or identica
<cjwatson> absolutely everyone with new installs will be using it once implemented
<cjwatson> so we should get a fair bit of testing, I'd expect ;-)
<BUGabundo> well count on early testing on my side
<BUGabundo> but I guess no need to file bugs
<BUGabundo> until you start to touch it
<cjwatson> the spec isn't even owned by me ...
<cjwatson> Assignee:      Scott James Remnant
<BUGabundo> eheh
<BUGabundo> right
<ccheney> cjwatson: thanks
<BUGabundo> hey ccheney
<billybigrig> can someone in here help me?
<billybigrig> i had a problem with the daily kernel and dkms yesterday
 * BUGabundo hides
<billybigrig> and i forgot the fix for it
<BUGabundo> :)
<billybigrig> dkms won't build
<billybigrig> billybigrigger@cabo:/var/lib/dkms/nvidia/185.18.14/build should be a symlink to /usr/src/linux-headers-2.6.31-rc3-billybigrigger0714
<billybigrig> correct? to get my nvidia module to build in dkms?
<billybigrig> !logs
<ubottu> Official channel logs can be found at http://irclogs.ubuntu.com/ - For LoCo channels, http://logs.ubuntu-eu.org/freenode/
<cjwatson> ccheney: making its way into karmic now
<puff> Hey, I have an odd question that's fairly arcane (I think), where does suspend-to-disk save its data?  Does it use the swap partition?
<cjwatson> yes, that's right
<puff> cjwatson: Really?  Ah, good... then making my laptop's swap partition extra-large actually was a good idea.
<puff> I have been saying, for some time, "I have this feelnig that suspend-to-disk uses swap, so I make it alrge" band I thought, you know, I really should maybe, y'know ASK somebody who might KNOW.
<BUGabundo> puff: swap
<BUGabundo> Or eventually swap on file
<BUGabundo> eheh
<bardyr> Hey, where can i find the blueprint/specification template?
<puff> Thanks muchly.
<BUGabundo> that's what brought me here tonight ahah
<cjwatson> bardyr: http://wiki.ubuntu.com/SpecTemplate
<bardyr> cjwatson, Thanks
<cjwatson> Documentation/power/swsusp-and-swap-files.txt in the kernel source describes how things are meant to work when you're using a swap file
<cjwatson> (which is why I'm not worried about it, it's clearly been thought about it so at worst whoever's implementing proper swap file support gets to fix a few bugs)
<cjwatson> s/thought about it/thought about/
<cjwatson> ... and implement some little helper tool to go in the initramfs, possibly
<cjwatson> puff: for suspend-to-disk to work, you do indeed need swap >= RAM
<BUGabundo> yeah cjwatson
<BUGabundo> I do know that as swap it works very well since gutsy
<BUGabundo> but what may break is hibernate (or better, resume)
<cjwatson> sure
<cjwatson> like I say, it probably needs some work in the initramfs; but the presence of kernel documentation makes me confident that it's possible without too much difficulty
<puff> cjwatson: Again, much thanks,a dding that detail to my notes.
<BUGabundo> and since I use that a lot, I would like to have it on a working state, even if with _some_ bugs
<puff> cjwatson: swsusp-and-swap-files.txt, what would be the normal place an ubuntu user should look for that?  The linux kernel doc website or is there somewhere in a  normal ubuntu install (I don't see it in /usr/share/doc)?
 * BUGabundo wanna know too :)
<puff> http://www.mjmwired.net/kernel/Documentation/power/swsusp-and-swap-files.txt
 * BUGabundo checks
<cjwatson> puff: it'll be in the linux-doc(whatever) package
<cjwatson> linux-doc-2.6.28 on jaunty, plain old linux-doc from karmic on
#ubuntu-devel 2009-07-15
<ccheney> how do you flush your dns cache in ubuntu?
<lifeless> ccheney: what dns cache
<ccheney> i thought there was some sort of dns cache at the system level, maybe my problem is actually arp cache instead
<BUGabundo> restarting networking ?
<ccheney> my system can't connect to gtalk claiming no route to host i think due to it trying to connect before i authenticated with AP at the hotel
<lifeless> there is an arp cache
<lifeless> no route to host - you can see your route table by
<lifeless> ip route
<lifeless> you can get no route errors two ways
<lifeless> no route locally
<ccheney> yea just pidgin claims it not eg firefox
<ccheney> or ssh, etc
<lifeless> a router somewhere else sending back an ICMP error
<BUGabundo> ccheney: restart pidgin ?
<lifeless> routers can do that when they have no route. *or* when they don't want to let the traffic through
<ccheney> BUGabundo: it seems to not help restarting pidgin, i'll try rebooting my system to see if it changes
<BUGabundo> ccheney: that's a bit extreme
<BUGabundo> even for 10 sec boot systems
<BUGabundo> eheh
<BUGabundo> try restarting networking
<ccheney> hmm even total reboot didn't help :(
 * ccheney kicks the hotel
<BUGabundo> ccheney: mtr it ?
<pochu> ccheney: you should be using empathy anyway ;)
<ccheney> pochu: i'm using jaunty
<ccheney> i can see talk.google.com
<BUGabundo> not an excusse eheeh
<ccheney> with mtr
<BUGabundo> there is a PPA for empaty trunk
<BUGabundo> hey pochu
<BUGabundo> ccheney: ahhh pidgin updates?
<BUGabundo> check for the record on the server tab
<ccheney> hmm no pidgin updates available for me, i'm mostly up to date (as of sat night)
<ccheney> it was working at the office too, so i think they are just blocking it somehow at the hotel
<ccheney> it was working last night though so its a bit weird
 * ccheney heads off to dinner, bbl
<BUGabundo> ccheney: try https://imo.im
<ccheney> BUGabundo: thanks
<BUGabundo> np
 * ccheney heads out now to dinner
<cleary> hi - I hope I've got the right channel for my question, please redirect me if not -
<cleary> I'm in the process of customising a desktop gnome environment based on jaunty - the customisations need to packaged, and I'd prefer to try and get this more correct than not
<cleary> currently, I have replaced the ubuntu-artwork and ubuntu-wallpapers packages, providing modified gconf keys
<cleary> so that takes care of the various themes and the desktop background
<cleary> I need to make some fairly drastic changes to the panel though
<ScottK> This is not the channel you are looking for.
<cleary> currently, the panel layout seems to be controlled from the gnome-panel-data package, which provides two files
<cleary> /etc/gconf/schemas/panel-default-setup.entries and /usr/share/gconf/defaults/05_panel-default-setup.entries
<cleary> my panel changes basically mean I remove the top panel and move relevant applets to the bottom panel
<cleary> so I need to override those default files somehow (without modifying them directly, preferably)
<cleary> I know I can provide my own 90_foo.entries file in /usr/share/gconf/defaults/
<cleary> however, because I don't plan to use the top panel gconf entry at all, I'm wondering if the 05_...entries file will still create it
<cleary> what is the safest way for me to override these setting?
<cleary> ScottK: sorry - completely missed your bit
<cleary> ScottK: got a suggestion where I could go?
<cleary> the problem is, this stuff seems to be distro specific
<ScottK> Not particularly, but that's definitlely not development of Ubuntu.
<ScottK> I think there is an #ubuntu-installer channel.
<cleary> is there a desktop development focussed channel?
<cleary> +gnome even
<cleary> nvm, I'll have a look at #ubuntu-installer, and see if there's any relevant debian channels
<cleary> thanks
<pam> cjwatson: Thanks for the pointers. I am trying to test my merged syslinux package. The Ubuntu (non-Suse: 12-, 13- and 14- ones) gfxboot patches can't apply to the new comboot16 module and upstream doesn't know if they are still relevant. Testing this whole thing is kind of tricky actually :) For reference: http://syslinux.zytor.com/archives/2009-July/012866.html
<talltomWA> I just got done with a computer sci degree and am looking to take up an open source project, any ideas on where to start
<pitti> Good morning
<pitti> slangasek: you rock!
<pitti> slangasek: want me to accept gvfs for hardy-proposed now, or stall everything until after .3 was released?
<\sh> moins
<maxb> liw: Hello. Does apt-sync/zsync apply in any way to Packages files, or is it just about .deb files ?
<anilg> I've multiple repositories in my sources.list.. how do I print the packages in one particular repository (say a launchpad ppa repo)?
<dholbach> good morning
 * slangasek wavse
<maxb> anilg: Hi, that's not really a development question (as the topic says: "Development of Ubuntu (not support, not app development on Ubuntu)"). You'd be better placed asking that in #ubuntu. (Though ftr I don't think there is any command for this, and I'd probably resort to applying grep-ctrl to apt's raw lists files)
<ogra> hmm, why dont we have a proper commandline interface to tasksel ...
 * ogra cant belive nobody ever wrote something like that 
 * dholbach wavse to slangasek too
<anilg> maxb: thanks.. I did try #ubuntu
 * ogra joins the wavsing to slangasek 
<StevenK> ogra: We do, apt-get
<ogra> StevenK, apt-get can make me a list of available tasks ?
 * ogra checks the docs ... thats news to me
<StevenK> ogra: grep '^Task: ' /var/lib/apt/lists/silver.archive.ubuntu.com_ubuntu_dists_jaunty_*_binary-*_Packages | cut -d\  -f2- | tr ',' '\n' | sed -e 's/^ //' | sort -u
<ogra> lol
<ogra> well, then i rather parse /usr/share/tasksel/ubuntu-tasks.desc :)
<ogra> and depend on tasksel data
<StevenK> ogra: For what?
<ogra> rootstock
<StevenK> Ah
<ogra> i want to show a gtk list with available tasks plus a textfield where you can add sinle packages as csv list before you fire up the build
<ogra> so what i was actually lookinf for was something like "tasksel --list-tasks" and "tasksel --list-taks-descriptions" to just feed into the list :)
<StevenK> ogra: /usr/share/tasksel/ubuntu-tasks.desc will show you the *hosts* tasksel list, not the targets
<ogra> the target doesnt exist at that point
<StevenK> ogra: For the example of running rootstock on a Jaunty machine, but building a Karmic root
<ogra> hmm, yeah, i probably shuld pull the packages list from the archive and use your approach ...
<ogra> prob is that this changes my UI approach :/
<ogra> since i need to know the target release before doing that ...
<StevenK> ogra: You can pre-populate it, given data on the running system first.
<ogra> indeed, thats what i do anyway
<StevenK> ogra: But the task list might change if you're building for Karmic.
<StevenK> Actually, it *will* change, I can think of two tasks that Karmic has and Jaunty doesn't.
<ogra> by default it builds ubuntu-minimal and pulls all other data (locale, kbd settings etc) from the host
 * ogra ponders how to make that switchable on the fly without ending up with something like a wizard UI
<dholbach> ogra: mtp loves wizards!
<dholbach> mpt
<ogra> hmm, i should probably make the script stop generating *all* en_* locales inside qemu-system-arm ... might speed it up a bit
<ogra> dholbach, oh, since when ?
<ogra> i always thought he didnt :)
<dholbach> didn't you see the wizard costume he was wearing in Boston?
<ogra> heh
<ogra> hrm, why did my trap code in the script stop working
<nikolam> I have a problem with menu.lst
<nikolam> Every time hardy updates kernel it mess up the grup option for testing ubuntu instalaltion
<nikolam> and vice versa
<YokoZar> dholbach: I propose that all Fall UDSes that are in the US overlap halloween
<dholbach> YokoZar: I'm not sure I'm the right person to talk to :)
<YokoZar> Failing that, they should end with a costume party
<nikolam> I am editing menu.lst for Every kernel update on testing or stable since 6.10 and I am finally sick of it
<nikolam> sorry I maybe should post this ono ubuntu or ubuntu+1, sorry.
<YokoZar> btw dholbach, are there plans to let the 5-a-day stats page apply to individuals again?  It's been "groups only" for a long time now
<dholbach> YokoZar: bdmurray is working on that
<dholbach> YokoZar: it needs an RT ticket resolved because we need to process HUGE amounts of data
<YokoZar> ahh ok
<dholbach> like all ubuntu-bugs@ archives :)
<dholbach> the code is open
<dholbach> so if you want to help out, that's cool
<dholbach> hey mdz
<TheMuso> c
<mdz_> dholbach, hi
 * maxb boots intrepid and experiences nostalgia for how pretty it was :-/
<ogra> nostalgia ?
<maxb> usplash and notifications were both prettier in intrepid than jaunty/karmic, IMO
<ogra> well ... but its not even a year old
<ogra> boot a warty or hoary liveCD ... thats nostalgic :)
<maxb> I was running jaunty from alpha 3, intrepid seems a long time ago :-)
<hile> about names, just curious: so what will happen when ubuntu runs out of latin alphabet in release names? too far away to think about this?
<maxb> That will not be until 2017....
<highvoltage> the 2K17 bug. very serious stuff indeed.
<hile> need a committee to solve the issue!
<ogra> we will have taken over the world by then ... we'll just anhance the latin alphabet
<ogra> *enhance
<hile> that's a good plan
<highvoltage> hile: I guess it will start over with unpronouncable letters. and then you'll call it things like "the distribution formerly known as hoary"
<maxb> I dunno, I quite like the sound of "Ancestral Alligator"
<seb128> slangasek, \o/ for fixing the gvfs samba issue
<slangasek> seb128: thanks for your help setting me on the right track!
<seb128> ;-)
<dholbach> Â¡Â¡Â¡ please everybody help to clean up http://people.ubuntu.com/~dholbach/sponsoring/ !!! :-)
<liw> maxb, why ask in multiple forums, making sure that people miss the answer? I will answer via e-mail
<Q-FUNK> howdy!  could someone with upload rights please merge the two attached maintainer scripts at LP bug #399482 ?
<ubottu> Launchpad bug 399482 in bluez "bluez: upgrade from 4.45-0ubuntu1 to 4.45-0ubuntu2 fails" [Undecided,Fix released] https://launchpad.net/bugs/399482
<RAOF> Q-FUNK: Doesn't that say "fix released"?
<Q-FUNK> RAOF: it was entirely the wrong fix.
<ogra> Keybuk, erm, did the behavior of reboot change with upstart 0.6 ?
<ogra> Keybuk, reboot -fp doesnt see to do what it did before in my qemu-system-arm VM
<ogra> *seem
<Keybuk> ogra: what do you mean?
<wincide> hi all, i would appreciate an answer if someone know something about return codes when launching some proccesses... When i run some proccess and it finish its task, sometimes the return code in the terminal is like [1]   Done    |         [3]-  Done             or       [9]+  Exit 251
<ogra> Keybuk, i'm running a script that bootstraps a base system into a qemu image, fires up the image with a shellscript to proceed the second stage bootstrap and set up some stuff ... in the end the sript calls reboot -f which doesnt seem to behave like it did before
<Mez> ok, that's a major bug, gksu no longer works.
<ogra> it uses init=<path to script> and indeed doesnt invoke upstart
<wincide> i dont know the differences among [1] or a - / + after the number, or the exit code sometimes with + and other times with -   ..
<liw> wincide, it's your shell outputting those, so a good first step would be its documentation ("man bash" if you're using that), even if it is intimidating
<Keybuk> ogra: "doesn't seem to behave like it did before" ?
<Keybuk> this is what I'm trying confused about
<ogra> Keybuk, the vm doesnt shut down
<Keybuk> did you try strace reboot -f ?
<ogra> tricky to do in that setup
<ogra> but i just had an insane idea, i can kill the vm from the outside after debootstrap is done with its second stage, do a normal boot and make the configuration script an upstart job :)
<smb> hi, is currently someone around who knows a bit more on the userspace side of v4l1->v4l2 transition and applications only capable of v4l1. There is a regression bug on the kernel side (bug 352765) which I believe is rather tied to the applications and the compat lib.
<ubottu> Launchpad bug 352765 in linux "Logitech webcam doesn't work (v4l2 support needed)" [Medium,Confirmed] https://launchpad.net/bugs/352765
<Keybuk> ogra: reboot -f/poweroff -f really don't do much other than call the reboot() syscall
<ogra> Keybuk, ok, i thought they might try to route that through upstart or so now
<wincide> thx liw, buy i've reading all the bash man, and the closest term related to what i trying to find out, is just the number of proccess launched, but ,anything about this kind of return codes with + - or exit with + or - ....
<Keybuk> ogra: no, only if you don't call with -f
<ogra> the thing is that the kernel and VM are the same as before, only the image content is karmic
<Keybuk> without -f they call shutdown
<ogra> so its some software thats blocking here
<Daviey> Keybuk: Is this a good time to start thinking about switiching from init.d scripts to upstart?
<ogra> but i think i'll go with abusing upstart as installer, thats a funny idea
<ogra> and will actually give me all initscripts out of the box instead of me having to invoke them from the script one by one
<Keybuk> Daviey: to a limited degree, yes
<ogra> Keybuk, is there a limitation on the amount of runlevels or could i just add a runlevel 7 or 8 ?
<Keybuk> ogra: there are no runlevels 7 or 8
<Daviey> Keybuk: thanks.
<Keybuk> use 3, 4 or 5 - they're spare
<ogra> Keybuk, no, i want them to stay untouched
<Keybuk> you could use a different event than runlevel
<ogra> being able to add runlevel 7 and just dump my job scripts in there would be cool
<ogra> and delete everything related to 7 after i'm done
<cjwatson> pam: I'm a bit confused. Why not just start with the working assumption that the upstream gfxboot module is sufficient, and test that? You could test for screen-clearing after 'localboot' (i.e. "Boot from first hard disk") easily enough, and I'd be surprised if force-prompt weren't handled upstream since otherwise it doesn't work very well with the standard menu system
<ogra> hmm
<cjwatson> pam: surely we shouldn't be getting a reputation of asking upstream to support Ubuntu's changes; that's bad form
<cjwatson> wincide: it's described in the "JOB CONTROL" section of the bash manual page, specifically towards the end of the paragraph starting with "There are a number of ways to refer to jobs in the shell"
<wincide> im taking a look again, lets check it... thx
<ogra> Keybuk, oh, i suspect its even easier, i could just temporary replace /etc/init/rcS.conf
<ogra> and call my config the same way sulogin is started
<ogra> wow, thats so insane that i actually start to like it :)
<Keybuk> you could do that
<Keybuk> though that would mean forcing start into single-user mode
<ogra> Keybuk, thats fine what bothers me since a while is that my script needs to invoke all the rcS stuff, thats error prone, using upstart works around that :)
<ogra> and i can properly shut down
<Keybuk> ogra: the rcS stuff?  your script needs the recovery menu?
<ogra> no, but mounted / and proc etc etc
<Keybuk> ah, I see your confusing
<Keybuk> rcS.conf is for what to do *while* in single-user mode
<Keybuk> not the sysinit scripts
<ogra> oh, k
<Keybuk> (which Debian always confusingly put in rcS.d)
<Keybuk> rc-sysinit.conf is the one you want to look at
<ogra> ok, will do
<Keybuk> it runs rcS.d
<Keybuk> then runs telinit to switch to the next runlevel
<ogra> yep i see
<ogra> oh and telinit dies with my test image :/
<Keybuk> "dies" ?
<ogra> yeah
<ogra> but the image seems corrupt as well
<ogra> grmbl
<Keybuk> do you have a core dump?
<ogra> telinit "did not recieve a reply etc etc"
<ogra> i guess its the kernel i use for the VM
 * ogra tries with a jaunty versatile one 
<wincide> bye, thx for all
<ogra> weird, same issue
<ogra> Keybuk, was a corrupted fs ...
<ogra> works with a different image
<Keybuk> good to know
<ogra_> grmbl
<ogra_> whats up with my network today
<cody-somerville> Ummm... why was a package seemingly just accepted into the jaunty release pocket?
<cody-somerville> oh, uploads to partner get sent to jaunty-changes too
<ogra> cody-somerville, partner archive ?
<ogra> yeah
<ogra> udevd[9589]: udev: missing sysfs features; please update the kernel or disable the kernel's CONFIG_SYSFS_DEPRECATED option; udev may fail to work correctly
<ogra> mumble
<james_w> quadrispro: around?
<quadrispro> james_w: hi james
<james_w> hi
<james_w> I'm looking at ncurses
<james_w> what does "Install wide-character patches into /{,usr/}lib32." mean?
<quadrispro> james_w: only a moment, bug?
<quadrispro> found
<enrico> mvo: I saw your patch, I've been overly busy these days, I'll take care of it now
<quadrispro> bug 399625
<ubottu> Launchpad bug 399625 in ncurses "Merge ncurses 5.7+20090613-1 (main) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/399625
<quadrispro> james_w: nothing, maybe I forgot to do some change... i'm checking it (and unsubscribing sponsors team for now)
<james_w> quadrispro: thanks
<james_w> it looks as though that changelog entry might have just been carried forwards for lots of uploads when it wasn't needed
<mvo> enrico: thanks, no problem about the delay
<dpm> StevenK: what do you think about the reply from fbreader upstream regarding their contributor guidelines, is this going to be a problem? -> http://www.fbreader.org/docs/contributions.php
<enrico> mvo: uploaded, thanks a lot for the patch"
<enrico> s/"/!/
<mvo> enrico: cool, thanks!
<ogra> oh
<ogra> did the initscripts massively change in karmic ?
<ogra> especially the stop tasks in them ?
<cjwatson> seb128: could somebody please add a versioned Replaces on gnome-session to gnome-session-bin? I don't really want to accept the package in NEW since the missing Replaces will cause problems
<seb128> cjwatson, will do, thanks for noticing
<cjwatson> ta
<seb128> cjwatson, in fact isn't the Conflicts enough?
<cjwatson> seb128: I'm not convinced
<seb128> cjwatson, I think Josselin argued before that using Conflicts only is enough and will assure things are upgraded in the right order
<cjwatson> the safe rule is *always* to add a Replaces and it does no harm
<seb128> right, I'm doing that, I just failed to convince Josselin apparently during previous discussions
<seb128> I will ping him again about that
<cjwatson> is Conflicts actually necessary? it makes the upgrade painful
<cjwatson> using Conflicts means the old gnome-session package has to be entirely removed before installing the new gnome-session-bin
<seb128> well I would say only Replaces is required
<cjwatson> if possible, it would be better to use Replaces plus maybe Breaks
<seb128> Breaks is not required, it's really a Replaces situation I think
<cjwatson> right, in that case it's probably just the old-fashioned confusion between Conflicts and Replaces
<seb128> yes
<cjwatson> it's possible that he's technically right that Conflicts is enough, but it's definitely a suboptimal way to do it
<seb128> cjwatson, Replaces version uploaded, you can accept the binaries now the Conflicts should work too or wait for the new build
<cjwatson> ok, thanks
<seb128> np, thanks for checking the binaries and letting me know about the issue
<ivoks> could someone finally fix lvm2 bug 246324 ; it's trivial and makes life easier...
<ubottu> Launchpad bug 246324 in lvm2 "initramfs-tools lvm2-hookscript won't include lvm.conf and claim devices it shouldn't " [High,Confirmed] https://launchpad.net/bugs/246324
<lool> pitti: I've pushed a seed change to desktop-common to pull apmd on armel; apmd was demoted from main to universe in karmic, so I don't think I need a MIR to promote it back, do I?
<cjwatson> ivoks: done
<ivoks> cjwatson: awsome; thanks
<pitti> lool: right, we can just re-promote it; I just thought it was horribly outdated and ditched it from main
<lool> pitti: The Marvell SoC we target for karmic will rely on APM, yeah!
<lool> pitti: (I discovered that 10 minutes ago BTW)
<pitti> modern!
 * ogra wonders if devicekit-power can do APM at all
<mvo> enrico: did you push your upload to git yet?
<c_korn> is fast-user-switch-applet being dropped in karmic?
<enrico> mvo: ah, right, I forgot
<enrico> mvo: done.
<mvo> thanks!
<pitti> james_w: thanks for the package branch announcement
<seb128> c_korn, it's in gdm now
<pitti> james_w: one thing that's not quite clear to me, should the official brnaches be committed/pushed to, or are they read-only and only an auto-import?
<james_w> they should be pushed to
<james_w> you just can't yet
<james_w> see the part about permissions
<pitti> james_w: ah, so right now, they are read-only
<james_w> yeah
<pitti> james_w: other question, should they only be full-source, or packaging-only branches as well?
<james_w> so any commit you do are just "squashed" in to one
<james_w> full-source is the one true way!
<cjwatson> there was discussion at UDS of how to incorporate history from older packaging-only branches
<didrocks> pitti: I think we will have to update our desktop team workflow progressively to full-source branches :)
<pitti> james_w: right, but both debian and ubuntu have a huge set of packaging-only branches
<c_korn> seb128: http://www.ubuntu-pics.de/bild/18739/screenshot_003_qv7BQY.png you mean that?
<pitti> and at this point they are still better than using the auto-imports
<pitti> didrocks: yes, probably
<james_w> why are they better?
<seb128> c_korn, yes, cf gdm changelog for details
<seb128> c_korn, the ubuntu changes need to be ported to the gdm version
<james_w> (not being argumentative, I'd like to fix the issues)
<seb128> c_korn, what you have now is the upstream variant, tedg is working on porting the ubuntu changes
<seb128> didrocks, no; no change in the ubuntu desktop workflow
<gnomefreak> ah that explains the depends on gdm
<cjwatson> pitti: (FWIW there is no harm in continuing to use the old packaging-only branches outside the lp:ubuntu/karmic/ namespace until such time as the full-source branches are good enough)
<didrocks> seb128: not now, just when the branches will be ready to use (not read only as of now), don't you think?
<seb128> didrocks, we have something working I think we should not be the first to run in new things, we have enough to do without fighting tools and learning new way every week
<didrocks> seb128: I can't agree more :)
<seb128> james_w, one thing better with packaging only in vcs is the time it takes to fetch the source
<seb128> james_w, it takes over 15 minutes to get the nautilus source there where it takes 1 minutes to get the tarball and the debian dir from a vcs
<james_w> yes
<djsiegel_> StevenK: what's happening with https://launchpad.net/about-window ?
<james_w> I don't think that should be the only deciding factor though, and it is something that is being worked on and has improved a lot.
<seb128> james_w, well it's a matter of pro and con, and that's an annoying con without any real pro for full source in what we do now
<james_w> well, let me try and convince you of the pros
<seb128> james_w, ok ;-)
<james_w> seb128: nautilus isn't imported yet, and I'd like to do an experiment
<james_w> any other package of a similar size you work with a lot?
<seb128> james_w, gnome-control-center?
<james_w> nope :-)
<james_w> seems a lot of gnome isn't done yet :-)
<seb128> gtk+2.0 is a bit an extreme example
<seb128> gedit?
<seb128> or gvfs
<djsiegel_> pitti: scott ritchie reports that pcspkr sounds have been replaced with normal alert sounds in karmic https://bugs.edge.launchpad.net/ubuntu/+bug/77010
<ubottu> Ubuntu bug 77010 in hundredpapercuts "Overuse of system beep without volume control" [Undecided,Confirmed]
<seb128> gvfs is recent though
<pitti> djsiegel_: indeed, I saw his comment
<pitti> didn't check on that bug yet, though
<seb128> james_w, rhythmbox? just pick anything desktopish... ;-)
<djsiegel_> pitti: glory glory hallelujah
<pam> cjwatson: This is what I am trying to do (test if the patches are still relevant). About the mail: since Stefen is rewritting the patch again in C, just wanted to ping him about these fixes and incorporate them in the new version if necessary.
<djsiegel_> pitti: ok, I will check and mark fixed when I get a chance, should have a machine to test tomorrow
<cjwatson> pam: why not just plug it into an existing image and see if it works? :)
<pam> I don't have access to the C version yet, not released AFAIK
<pam> cjwatson: for the com16, sure
<cjwatson> kirkland: why am I getting the motd every time I start a terminal window? that's incredibly annoying
<james_w> seb128: empathy 38s vs 9s, so still some work to do
<james_w> seb128: but when there's a new one to grab it should be quicker in bzr
<seb128> james_w, that's already quite good my tests there where rather 10 times slower
<james_w> that's why we are using the new format :-)
<seb128> well there is a limit anyway which is the quantity of information you need to get
<seb128> even git which is reputed to be fast is some 6-7 times slower than getting just the source in tarball
<seb128> all the commits history is quite some datas
<kirkland> cjwatson: that will go away as soon as slangasek accepts the pam_motd patch
<kirkland> cjwatson: rm /etc/profile.d/update-motd.sh if you can't wait
<kirkland> cjwatson: update-motd package going away, see ubuntu-devel@ mailing list
 * kirkland -> returns to his holiday
<StevenK> djsiegel_: You know, that's been stalled for about 5 releases?
<djsiegel_> StevenK: yes I know
<djsiegel_> StevenK: do you have any interest or bandwidth to unstall it?
<cjwatson> kirkland: ok, thanks
 * manjo moving to ubuntu-kernel as per rtg's command
<fta> pitti, how long does it take to have a -dbgsym for a package? (say libdbus-1-3-dbgsym)
<pitti> fta: until it's on ddebs.u.c.? Should be within 6 hours
<pitti> 8, actually
<pitti> 10 3,11,19 * * *
<fta> pitti, hm, ok. thanks. i guess i'll wait
<fta> 19:10, is that UTC?
<jpds> Probably London.
<pitti> BST
<pitti> so, 1810 UTC
<fta> less than 3h.. ok, thanks
<slangasek> Keybuk: I see that upstart 0.6 provides /lib/init/upstart-job, but there's no Provides: upstart-job; oversight?  want a bug report?
<Keybuk> slangasek: ah, yes please
<mbiebl> Should also have a Conflicts/Replaces I guess
<Keybuk> yeah should be a super-switch thing
<Keybuk> mbiebl: btw. did you get any further with the "better" upstart-job than my hacky shell script?
<mbiebl> It's not much better, but it has support for being called by /etc/rc?.d/???servicename
<mbiebl> and it also tries to much all action that are supposed to be available (like force-reload)
<mbiebl> to corresponding upstart actions
<slangasek> mbiebl: should it?  we shouldn't ever have more than one upstart-job implementation on a given arch?
<Keybuk> mbiebl: can you file a bug and attach it?
<Keybuk> slangasek: upstart vs. sysvinit both providing it
<slangasek> since when is sysvinit going to provide it?  I thought the alternative implementation was going to be built from upstart source
<mbiebl> yeah, the idea was to provide a upstart-job implementation for sysvinit
<slangasek> since it needs to understand upstart job formats
<mbiebl> for people that don't want (or can make) the switch
<mbiebl> can't make, meaning upstart is not yet available on their arch
<slangasek> ah, I forgot that we were giving people a choice in some cases. :)
<Keybuk> right, but there are two alternate implementations in Debian
<Keybuk> or at least will be
<mbiebl> this alternate implementation is giving me some headaches though.
<mbiebl> not sure yet, how the stop action can be implemented
<slangasek> mbiebl: killall5 should be fine
<mbiebl> slangasek: I switched to #pkg-sysvinit
<kees> pitti: do you have https://blueprints.launchpad.net/ubuntu/+spec/security-karmic-apport-abort on your schedule?  I'd like to start using that feature now that it's in glibc.
<ogra> Keybuk, "init: rc-sysinit main process (380) killed by TERM signal" ... i assume i'm missing a kernel feature (fiddling with qemu arm kernels) would anything strike you as something i could miss from the top of your head ?
<ogra> apart from that message the VM works perfectly fine
<Keybuk> ogra: when did you receive that message?
<ogra> Keybuk, when the login prompt shows up
<Keybuk> "the login prompt" ?
<ogra>  * Setting up console font and keymap...                                 [ OK ]
<ogra>  * Starting system log daemon...                                                init: rc-sysinit main process (380) killed by TERM signal
<ogra>                                                                          [ OK ]
<ogra>  * Starting kernel log daemon...                                         [ OK ]
<ogra> Ubuntu karmic (development branch) dove ttyAMA0
<ogra> dove login: test
<ogra> thats the boot (through a serial console)
<Keybuk> ah right
<Keybuk> it's just what was in the syslog buffer then
<ogra> ah
<ogra> so it actually died before
<Keybuk> yeah, when it ran telinit
<ogra> hmm
<ogra> telinit itself didnt spill a message though
<Keybuk> why would it?
<ogra> because there is a stderr ?
<Keybuk> no, I mean why are you expecting an error from telinit
<ogra> because rc-sysinit gets killed and you said its caused by telinit ?
 * ogra has the feeling he doesnt get it
<Keybuk> rc-sysinit has
<Keybuk>   stop on runlevel
<Keybuk> the last command that rc-sysinit runs is
<Keybuk>     telinit "${DEFAULT_RUNLEVEL}"
<ogra> telinit default...
<ogra> right
<Keybuk> so telinit will generate the runlevel event
<Keybuk> which will forcibly stop the job its actually running from
<ogra> oh, so its no error at all
<Keybuk> so Upstart will tell you that it was killed by the TERM signal
<Keybuk> right
<ogra> then i wonder why i dont see it anywhere else ?
<Keybuk> the only reason you see it at all is because it's the last message in the syslog buffer
<Keybuk> and it ends up on the console for some reason
<ogra> yeah, and i see it on SDL qemu as well as on serial console ...
<Keybuk> that might be part of the reason why
<ogra> i would have blamed the serial console otherwise
<Keybuk> it's just an escaped log message
<Keybuk> nothing harmful
<ogra> ok
<ogra> thanks a lot for the clearification
 * ogra dances .... so i have a cotex-a8 kernel for qemu :)
<ogra> *cortex-a8
<maco> Keybuk, question about bootlogd
<Keybuk> maco: quickly...
<maco> you said the init script wont be removed because what if the user patches bootlogd to work, then theyll need it.  why dont we patch it to work and put it back in?
<maco> if such patches seem to already exist, that is
<Keybuk> if you want to do that, please do
<Keybuk> I'll happily sponsor the patches ;)
<maco> are you making an evil smile right now?
<apw> Keybuk, did X move to VT1 in karmic?  and where might i find that
<Keybuk> no...
<maco> ok. just checking that this isnt a "MUAHAHAHAH" moment
<Keybuk> apw: X moved all over the place in karmic; frankly it's all gone a bit quantum
<Keybuk> apw: you can tell which VT X is going to be on, or which VT X is actually on, but not both at the same time
<apw> heheh ...
<Keybuk> maco: it's somewhere on my TODO list, but it's a very long list, and it's quite near the bottom - so if you have some time, please do feel free to have go at it - if you get it all to work, I'll sponsor the upload
<apw> what actually decides where it thinks it wants it started
<Keybuk> maco: one of the obvious bits is that bootlogd would need to end up in sysvutils or whatever that package is called
<Keybuk> maco: check with pere on OFTC #pkg-sysvinit
 * apw is lost in a maze of twisty packages
<Keybuk> apw: ironically, now I think about it
<Keybuk> apw: my jokey statement was actually largely true
<Keybuk> apw: X when started calls the VTQUERY ioctl to ask the kernel for the first free VT
<Keybuk> apw: though I believe pitti has been doing some work to hardcode it to VT7, since BAD THINGS happen when X and getty share a VT
<maco> Keybuk, ok, will look into it
<chrisccoulson> hi cody-somerville - i just saw your GDM merge proposal
<Keybuk> apw: obviously we'd rather not hardcode X to VT7, which would mean not hardcoding getty to VT1-6 either <g>
<chrisccoulson> i think GDM still needs to depend on gnome-settings-daemon, else it doesn't theme properly
<apw> Keybuk, on my jaunty box its on VT7 and there is a vt7 on X's command line
<chrisccoulson> it used to get that dep via gnome-session
<Keybuk> apw: but there's some resistance from the sandal-wearing crowd to a first-come-first-served approach to VTs
<Keybuk> apw: then pitti has uploaded his patch :)
<apw> and i think my crashy box which isn't here with me, that it was on VT1, and i was trying to confirm and failed
<Keybuk> apw: that sounds plausible
 * apw will have to download some more packages i guess
<Keybuk> we have two options really
<Keybuk> keep hardcoding getty to vt1-6 on boot
<cody-somerville> chrisccoulson, Its generally not a good idea to take for granted dependencies you get through other dependencies for this exact situation <grins>
<Keybuk> err s/ on boot//
<Keybuk> hardcode X to vt7+
<Keybuk> then VT switch on boot
<Keybuk> (ugh)
<Keybuk> or just do VTs on a first-come-first-served basis
<Keybuk> ie. X would take VT1 on boot
<Keybuk> and the "six gettys" configured would get VT2-7
<chrisccoulson> cody-somerville - agreed ;)
<cody-somerville> chrisccoulson, Does it need gnome-settings-daemon or gconf?
<apw> Keybuk, yeah ...
<chrisccoulson> cody-somerville - it needs both
<Keybuk> apw: but then of course you could have two X logged in users, and two gettys
<chrisccoulson> does it not already have a gconf dependency?
<Keybuk> with X on vt1 and vt3, and getty on vt2 and vt4
<Keybuk> maybe we could use udev
<apw> yeah i thinl when i had two users they were VT-1 and 8
<Keybuk> /dev/tty/by-user
<ion> How about additional X sessions? They wouldnât get adjacent VTs.
<Keybuk> ion: everything would get "first free VT"
<apw> ion the user has no clue where they are now
<apw> they happen to be on 7 which is pretty mad
<Keybuk> 7 and 9 now usually
<Keybuk> user on 7, guest on 9
<apw> yeah see what is on 8
<Keybuk> because usplash took 8
<apw> ahh
<Keybuk> in this model, user would be on 1, and guest on 8 (assuming 6 gettys)
<apw> i think in the new user switcher you get a 'switch to someone' entry on your logout menu
<Keybuk> though it'd be generally unpredictable
<Keybuk> right exatcly
<apw> and it knows where it is and you son't have to know
<Keybuk> the right way to solve this is just to embrace the chaos
<Keybuk> and supply a more useful "VT switch" command ;)
<Keybuk> console equivalent of user switch
<cody-somerville> chrisccoulson, it does
<chrisccoulson> so, it will still pull in some gnome-components. but, depending on gnome-session-bin only will mean that gnome-session is not registered as an alternative for x-session-manager and it won't start some gnome-only components
<chrisccoulson> so it's slightly better ;)
<cody-somerville> chrisccoulson, say again
<apw> Keybuk, we could simply clear the first N vt's and push the console to 4 up or 6 and up
<apw> and leave nothing on 1-5 so VT would be there
<apw> Keybuk, how do i find out what makes 'system-services' apt-get source seems all confused by it
<pitti> kees: ah, saw your spec approval; sorry, didn't have time to look into that yet
<kees> pitti: no problemo; let me know if I can help.
<pitti> kees: well, patches/commits appreciated, as always :) it'll still take me a bit to get to, since I have some high prio/stuff that other people depend on to do
<kees> pitti: sure thing.
<cody-somerville> chrisccoulson, I'm going to try starting gdm without gnome-settings-daemon
<chrisccoulson> cody-somerville - no problem. i think you will lose the theme though
<cody-somerville> chrisccoulson, I'm sure we can figure something out :)
<cody-somerville> chrisccoulson, Thanks for your help btw with this. Its very *much* appreciated.
<cody-somerville> :)
<cody-somerville> brb
<chrisccoulson> you're welcome:)
<cody-somerville> chrisccoulson, it boots now atleast :)
<cody-somerville> chrisccoulson, no theme as you said
<chrisccoulson> excellent \o/ i did try booting a xubuntu live CD, and all i got was a broken gnome session
<chrisccoulson> does the new dependencies fix that?
<cody-somerville> chrisccoulson, It booted into Xfce and not gnome so I consider that a success :)
<cody-somerville> albeit I don't have "gnome" installer
<chrisccoulson> fantastic:)
<chrisccoulson> fantastic :) even**
<cody-somerville> chrisccoulson, hmm... looking at the logs it looks like gnome-session tried to start metacity for some reason
<cody-somerville> chrisccoulson, this is in /var/log/gdm/:0-greeter.log
<chrisccoulson> cody-somerville - it seems that GDM ships a metacity desktop file in it's autostart folder
<jcastro> liw: FYI: http://dev.chromium.org/developers/design-documents/software-updates-courgette
<jcastro> might be interesting to that deb zsync stuff
 * ScottK waves to jcastro.
<liw> jcastro, ack, thanks, I'll have a look
<jcastro> hi ScottK!
<ScottK> jcastro: I saw you found @kubuntunetbook
<jcastro> ScottK: My spies are everywhere.
<ScottK> jcastro: Yeah, well it's not like we're hiding ....
<jcastro> heh
<ScottK> jcastro: Feel free to hang out in #kubuntu-netbook if you want.  We have one of the plasma-netbook upstream devs in there with us if you want to supervise our upstream relations.
 * jcastro todo's it
<jcastro> ScottK: post-Debconf I will.
<ScottK> Wouldn't it be faster to just join ...
<ScottK> OK
<superm1> Hm. so can someone advise the best way to proceed to fix bug 399482?  If you upgrade from 4.45-0ubuntu{1,2} to 4.45-ubuntu3 and bluetoothd isn't running, the prerm will fail. Adding in a case to the preinst to check if upgrading from 4.45-0ubuntu1 or 4.45-0ubuntu2 and spawning bluetoothd is all I can see working right now
<ubottu> Launchpad bug 399482 in bluez "Upgrading from bluez 4.45-0ubuntu{1,2} to 4.45-0ubuntu3 or later fails" [High,Triaged] https://launchpad.net/bugs/399482
<ScottK> superm1: I think you can do something with dh_installinit --error-handler (see the man page).
<superm1> ScottK, ah that looks to be a useful alternative, i'll do some experimenting with it. thanks
<ScottK> You're welcome.
<geser> superm1: looking at http://women.debian.org/wiki/English/MaintainerScripts adding a "failed-upgrade" case to the new prerm seems to be the only way to work around this failure when execute the old prerm
<fta> pitti, is there a way to tell apport to keep several crash files for the same program+user?
<fta> pitti, and what happens when a chrooted program crashes? where is the crash file generated?
<cody-somerville> chrisccoulson, It seems like gdm is pretty much automatically logging into, for a lack of a better description, the gdm user, auto-launching a minimal gnome session and a GTK application to provide a GTK UI to perform the login.
<mrooney> evand: I heard maybe you handle ubuntu-devel mailing list whitelisting? I was wondering if I could be added as I keep getting those moderation notices every time I reply and my replies also aren't timely then
<chrisccoulson> cody-somerville - yeah, that sounds about right.
<cody-somerville> chrisccoulson, is there anything in particular that demands gnome-session or metacity or [insert other gnome thing here]... that is besides the fact that launching gnome-session appears to be hardcoded into gdm simple slave?
<evand> mrooney: I'm out for the evening, can you please send me an email to remind me and I'll take care of it tomorrow#
<slangasek> pitti: pulling empathy in by default seems to have cost us about 7MB on the CDs now; how are we going to make that up?
<mrooney> evand: sure thing, thanks!
<slangasek> pitti: a lot of that is libwebkit, which we'd avoided in previous releases - is there other stuff we can convert to webkit and bring in some savings?
<directhex> slangasek, sure. firefox.
<directhex> Laney, is the current tomboy in karmic size-reduced?
<Laney> should be
<directhex> let me check some dep chains to see if i can get you anything
<Laney> I was just doing the new tomboy
<directhex> hm. my f-spot patch landed. i already gave you 2.7 meg last week, slangasek!
<Laney> he's so demanding!
<sebner> lol
<slangasek> I only demand that CDs fit on CDs, the rest is the desktop team's doing. :)
<seb128> slangasek, webkit will probably be a requirement for GNOME too soon but that will not win anything since xulruinner will stay for firefox anyway
<seb128> slangasek, pitti suggested dropping the gimp user documentation today I think
<slangasek> that sounds like a good place to start
<slangasek> seb128: we also still have pidgin on here, is that going away soon?
<seb128> slangasek, that should be fixed with the seed update to drop pidgin-libnotify
<slangasek> ok
<seb128> slangasek, did you get a CD rebuild since?
<slangasek> I don't know
<slangasek> doesn't look like it
<seb128> slangasek, well we noticed the issue this morning and pitti unseeded pidgin-libnotify if there is still something pulling pidgin we need to investigate
 * slangasek fires off a quick alternate build to see
<chrisccoulson> cody-somerville - AFAICT, gdm needs gnome-session because gnome-session allows you to specify an autostart directory, to tell it where to load session agents from. i'm not sure if other session managers do that
<cody-somerville> chrisccoulson, AFAIK, xfce4-session can do that
<chrisccoulson> can it? i had a quick glance a couple of weeks ago and i wasn;t sure if it did
<chrisccoulson> GDM does something like "gnome-session --autostart /etc/gdm/LoginWindow/autostart", to stop it loading files from the normal system autostart directories
<johanbr> tkamppeter_, I have a pdf file (from latex) that cups in karmic treats very badly
<johanbr> the source pdf is 1 meg, the pdf output that cups gives to the print server is 826 megs
<johanbr> something you're aware of?
<tormod> johanbr, sounds like something for a bug report and upstream possibly
<tkamppeter> johanbr, please make the PDF file available to me. Thanks.
<Askalon> 'Buonasera
<Askalon> Siete tutti sviluppatori qui dentro?
<slangasek> Askalon: si, ma la lingua franca qui Ã© l'inglese
<Askalon> Quindi se parlo in Italiano rischio di non essere capito, giusto?
<charlie-tca> !it
<ubottu> Vai su #ubuntu-it se vuoi parlare in italiano, in questo canale usiamo solo l'inglese. Grazie! (click col tasto destro sul nome del canale per entrare)
<slangasek> Askalon: non esserebbe capito, no :)
<sebner> slangasek for italiano \o/
<slangasek> sebner: survival-level, at least :)
<sebner> slangasek: 8 years at school. knowledge forgotten -> 99%
<slangasek> seb128: oh my... https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/207072/comments/239 :)
<ubottu> Ubuntu bug 207072 in gvfs "nautilus does not display samba shares for machines inside an ADS network." [High,In progress]
<slangasek> well, at least that assures us there's no chance of regression ;)
<Askalon> 	
<Askalon> I can give you advice about an betterment?
 * ScottK has a special folder in his email with lots of advice about betterment.
<seb128> slangasek, arg, I don't have my hardy machine there but I will fix that tomorrow morning if nobody beats me to it
<cjwatson> Askalon: suggestions for improvement are generally best filed as bug reports; https://help.ubuntu.com/community/ReportingBugs
<cjwatson> Askalon: or, as that page notes, general ideas are better in brainstorm.ubuntu.com
<Askalon> OK THANK YOU
<ScottK> cjwatson: Do you a moment for an ISO image question/issue (I know it's late there and it's not urgent)
<cjwatson> ScottK: go ahead, if it's too involved I can always defer the answer ;-)
<ScottK> cjwatson: OK.  I noticed when I did a kubuntu-netbook install yesterday that the background during the live session was Ubuntu and not Kubuntu.  Where should I look for making a change to fix that?
<ScottK> BTW, the kubuntu-netbook ISO are working quite well so far.
<cjwatson> ScottK: hmm, IIRC that's controlled by which artwork packages are seeded, rather than by anything ISO-ish
<cjwatson> I think, anyway
<ScottK> cjwatson: OK.  I'll have a look and see if anything Ubuntu crept in.  Thanks.
 * ScottK downloads todays first to verify ...
<cjwatson> you do seem to have kubuntu-default-settings seeded
<ScottK> That's the current intention (we'll have a netbook specific settings package eventually)
<ScottK> cjwatson: The only thing I saw in the CD build log was some reference to edubuntu artwork.  I've no idea if it's related, but it seems odd the edubuntu addon stuff is getting run with netbook.
<cjwatson> ScottK: it does rather. which log is that?
<ScottK> cjwatson: http://people.canonical.com/~ubuntu-archive//cd-build-logs/kubuntu-netbook/karmic/daily-live-20090715.log
<cjwatson> ScottK: oh, right, that's nothing to worry about, it's just the presence of the Kubuntu education seed but it isn't actually used on your CD
<ScottK> cjwatson: OK.  Thanks.  I'm still left a bit mistified then.
<cjwatson> find the file that contains the wallpaper in question, dpkg -S, look for that package name?
<ScottK> Or rather mystified since I'm not getting wet.
<cjwatson> IIRC the default is /usr/share/backgrounds/simple-ubuntu.png -> ubuntu-wallpapers
<ScottK> cjwatson: OK.  I'm downloading today's ISO and I'll try that in a bit.  Thanks.
<cjwatson> but that isn't in your image ...
<cjwatson> according to http://cdimage.ubuntu.com/kubuntu-netbook/daily-live/current/karmic-netbook-i386.manifest anyway
<cjwatson> so I confess myself a bit baffled too.
<ScottK> That should give me a good pointer to see what's what once I get the image downloaded and converted.
<ScottK> I'll make sure it's still a problem on today's image before getting too excited.
<cjwatson> right
<ScottK> Thanks for the pointers.
#ubuntu-devel 2009-07-16
<cr3> does upstart still load configs from /etc/event.d? it seems mine isn't getting picked up anymore and I seem to be the only one in that directory now
<ion> /etc/init
<TheMuso> cr3: I think its moved, but can't remember where.
<cr3> when I looked at the bzr log, I found: retain loading from /etc/event.d for the time being
<TheMuso> hrm
<cr3> ion: I've noticed some .conf files directly in /etc/init but I've also noticed in the bzr log something about /etc/init/conf.d
<cr3> but the init(8) manpage does mention: /etc/init/*.conf
<johanbr> tkamppeter, actually cups sends a ps file
<johanbr> the print server doesn't use cups, but rather old-fashioned lpd
<johanbr> I guess that may be why... I'll dig a bit more
<cr3> slangasek: I noticed you participated in the boot performance sprint back in june which covered something about dh_installupstart. got a minute to hold my hand a bit?
<cr3> can someone suggest a package using upstart so that I can inspire myself from the packaging? I looked at apache2, for example, and it still uses sysv style
<ion> 0.6 was released so recently that there probably arenât such packages yet.
<ion> Except for upstart itself, of course.
<TheMuso> We've hit 400000 bugs.
<ScottK> Bug 400000
<ubottu> Bug 400000 on http://launchpad.net/bugs/400000 is private
<ScottK> That's no fun.
<slangasek> cr3: in upstart 0.6, the config has been moved to /etc/init
<slangasek> cr3: /etc/event.d is, AFAIK, no longer used
<cr3> slangasek: right, is there a suggested way to write my debian/rules file to account for this?
<slangasek> cr3: at this point, no; dh_installupstart has been submitted to the debhelper package, but not yet integrated
<cr3> slangasek: I'd rather not have to maintain a separate branch just for karmic, so it would be really sweet to have the same rules apply differently depending on the target where the package is built
<slangasek> ah, that definitely isn't going to be the case
<slangasek> not sanely, anyway
<cr3> slangasek: I don't mind, I've lost my marbles a long time ago
<cr3> slangasek: if I'm on my own, that's alright too, but I tend to converge towards checking what others have done beforehand
<slangasek> no one else is doing what you're describing, we're not crazy enough to try to use a single branch for multiple releases
<infinity> slangasek: Bah.  Why not?  Once the dh_ goo is there, you can easily if-block your dh_installwhatever based on distro and release.
<cr3> slangasek: either I revert back to init.d or I hack rules, I really don't want to introduce the overhead of maintaining several branches :(
<infinity> cr3: Build-dep on lsb-release if you don't already, and go to town with a branching rules file.
<slangasek> cr3: using init.d is the norm anyway, we're still in the process of /introducing/ best practices for shipping upstart jobs in place of init scripts
<cr3> slangasek: meh, I'm willing to be your guinea pig as long as I don't lose my soul in the process
 * slangasek isn't looking for guinea pigs
<cr3> gerbil then?
<infinity> ...
<cr3> infinity: I don't do that right now, might you suggest a project from which I could learn to do that?
<infinity> cr3: I'd suggest gcc, if you like reading.  There are simpler cases, though, I'm sure.
<james_w> dpkg-vendor is supposed to help with this now
<infinity> cr3: Odds are half of lamont's packages behave differently based on target distro.
<infinity> james_w: That gets you vendor, but not release, no?
<james_w> ah, true
<slangasek> cr3: no, my attention is on getting the toolchain bits in place; I think you're putting the cart before the horse, and I don't think your use case is interesting anyway. :)
<slangasek> having separate branches for each distroseries is the /norm/...
<cr3> I could probably do something like: dist_release := $(shell lsb_release -rs)... not sure if [ $dist_release -ge "9.10" ] works as expected though
<cr3> slangasek: yeah, but the norm typically doesn't touch a package once a release becomes stable except for sru. I maintain a separate repository where my package changes far more often for stable releases
<cr3> slangasek: I suspect that this is such a corner case that it's even less interesting :)
<infinity> cr3: -ge is an integer operation, so no, that doesn't work.
<infinity> cr3: On the other hand, "dpkg --compare-versions" totally DTRT for comparing release numbers. :)
<cr3> infinity: aha, so perhaps if [ `echo "$dist_release > 9.10" | bc -l` ]... I can already feel my soul leaving me
<cr3> infinity: oh right, forgot about that
<cr3> I actually wrote a sorting algorithm in shell using dpkg --compare-versions as the comparison function, fun!
<infinity> Ouch.
<infinity> That's kinda heavyweight for a sort.
<infinity> If only we had C compilers in the archive.
<infinity> (isn't writing a bubble sort everyone's second or third C project after hello world and, possibly an MUA?)
<cr3> infinity: exactly and, besides, the context was just to sort patches in a package before applying them, so the number of items to sort is likely to remain rather manageable
<lifeless> infinity: random_sort ftw
<dtchen> Caesar: unlikely pong
<rich3376> hello?
<rich3376> im not sure if im in the right place (most likely not) just want to ask someone a question if they would be kind enough to answer
<pitti> Good morning
<pitti> fta: several crashes per program/user> I'm afraid not, you need to copy the .crash files somewhere else for this
 * StevenK waves to pitti 
<pitti> fta: chrooted> hm, haven't tried that, but since the kernel itself triggers apport, the .crash should land in the outside area
<pitti> slangasek: I already did some changes yesterday which should make that up (drop gimp help and pidgin)
<pitti> slangasek: I'm afraid we can't avoid webkit much longer, too much of gnome is using it now
<slangasek> pitti: right, I realize we can't avoid webkit.  The changes you made appear to have done the trick as far as getting us down to size for now, thanks
<slangasek> pitti: can we get rid of gtkhtml this cycle?
<StevenK> slangasek: What about the poor dvd image?
<slangasek> StevenK: cjwatson was looking into that
<pitti> slangasek: unknown, I hope so
<slangasek> looks like evolution is the main culprit holding libgtkhtml3.14-19 in
<TheMuso> Please bare in mind that moving more and more to webkit reduces accessibility usage somewhat. I haven't tried the latest webkit a11y code, but still think there is a ways to go yet. I'd need to double check on that hoewver.
<TheMuso> however
<dholbach> good morning
<YokoZar> So, users on the Wine 1.0 package (default in Jaunty) should stay at Wine 1.0 for Karmic.  However if they have Wine beta's installed (via PPA or my repo), I'd like to transition them to the wine1.2 package (which conflicts/replaces/provides wine).  Apt won't do this automatically (instead it'll just leave their jaunty beta package) -- would some logic in update-manager be appropriate, or is there a better way to do this?
<YokoZar> Essentially I want If Wine Version <= 1.0.1-0ubuntu6 then install Wine, else install wine1.2
<mvo> YokoZar: I can add something like this to u-m
<YokoZar> Thanks mvo, I suspected we already had a place for this sort of thing
 * mvo adds it to gtg
<YokoZar> Actually the logic is just "if Wine version >= 1.1, then install wine1.2, else act normally"
<StevenK> YokoZar: If wine > 1.0.1-0ubuntu6 then install wine1.2, since otherwise apt will do the right thing
<YokoZar> StevenK: Thanks that's a bit better actually
<StevenK> pitti: Help? :-)
<StevenK> pitti: gnome-session 2.26.2-1ubuntu2 is in NEW, and doesn't list any new components, and gnome-session 2.26.2-1ubuntu3 has been published and built everywhere
 * ogra wonders if there is a way to use swap without having swapon available ...
<ogra> i know there existes a patch for linux 2.4 to use swap= as a kernel parameter ...
<ogra> *exited
<slangasek> quadrispro: the avidemux reject was out of binary new, not source new; you'll need to bump the version number
<quadrispro> slangasek: thank you
<pitti> StevenK: hm, it should build a new -bin
<pitti> StevenK: it looks strange indeed, -bin should be N
<tseliot> pitti: is there a man page for Jockey's new textual interface?
<wgrant> pitti: -bin was in -1ubuntu1 too.
<pitti> tseliot: not really, I'm afraid; it's the same arguments as for any other UI
<tseliot> pitti: can you give me an example?
<pitti> --help should work
<pitti> StevenK: I accepted it now, strange though
<tseliot> pitti: ok, thanks
<tweaker25> [03:35] <tweaker25> http://translate.google.com/translate?prev=hp&hl=fr&js=y&u=http%3A%2F%2Fforum.ubuntu-fr.org%2Fviewtopic.php%3Fpid%3D2808462%23p2808462&sl=auto&tl=en&history_state0=
<tweaker25> [03:35] <tweaker25> http://forum.ubuntu-fr.org/viewtopic.php?pid=2808462#p2808462
<tweaker25> [03:35] <tweaker25> http://translate.google.com/translate?prev=hp&hl=fr&js=y&u=http%3A%2F%2Fforum.ubuntu-fr.org%2Fviewtopic.php%3Fpid%3D2808462%23p2808462&sl=auto&tl=en&history_state0=
<tweaker25> [03:35] <tweaker25> http://forum.ubuntu-fr.org/viewtopic.php?pid=2808462#p2808462
<tweaker25> [03:35] <tweaker25> http://translate.google.com/translate?prev=hp&hl=fr&js=y&u=http%3A%2F%2Fforum.ubuntu-fr.org%2Fviewtopic.php%3Fpid%3D2808462%23p2808462&sl=auto&tl=en&history_state0=
<tweaker25> [03:35] <tweaker25> http://forum.ubuntu-fr.org/viewtopic.php?pid=2808462#p2808462
<dholbach> tweaker25: whatever you're trying to achieve by posting these links - this is not how it works here - I suggest you ask a proper question in #ubuntu-fr
<tweaker25> they aren't helping so I will get helped elsewhere
<tweaker25> even I have to do every chat of freenode
<dholbach> tweaker25: no, that's not how it works - you can't just post a bunch of links in all the channels and expect people to read it all up, translate it and then help you
<dholbach> also this is not a support channel, so please be patient and wait until somebody answers your question
<dholbach> tweaker25: you can try https://answers.launchpad.net/ubuntu too
<modder25> launchpad ???
<dholbach> it has a questions / answer tracker
<azeem> (tweaker25 even spammed #debian)
<dholbach> and you can ask in French there too
<dholbach> modder25, tweaker25: I suggest you calm down a bit and be patient or you'll get kicked from the channels for spamming
<modder25> even banned you think I have to worry about that I want my stuff working that's all
<slangasek> do you think people are going to go out of their way to help you when you're deliberately being rude and abusing IRC channels?
<dholbach> modder25: that's not how it works - please respect this and be patient, as slangasek said: people will be less likely to help you if you spam a bunch of channels - especially #ubuntu-devel and #ubuntu-motur is for coordinating work on Ubuntu developent
<modder25> but If I cannot have a response I will just be a linux irc channels lamer with proxies, vpn, vnc and more, I got plenty of tricks in my sleeve ...
<dholbach> oh man
<dholbach> that's boring
<dholbach> you won't get a good answer that way
<modder25> even if I don't get an answer, it will take days so I will have fun for days until I got an answer
<dholbach> that's the most boring kind of fun I can imagine
<modder25> boring be less than wait for nothing
<dholbach> please go ahead and file the ticket on https://answers.launchpad.net/ubuntu and be patient
<modder25> not of my kind sorry
<Hobbsee> oh dea
<agateau> hi
<agateau> upgrading from jaunty to karmic, initramfs-tools fails because it misses /lib/udev/vol_id. any idea?
<slangasek> agateau: sounds like a missing Breaks: on the udev package
<agateau> slangasek: I am not sure I understand what you mean :/
<slangasek> agateau: well, I'm mistaken in any case, because udev already Breaks: initramfs-tools (<< 0.92bubuntu30)
<agateau> slangasek: oh it's a flag for debian/control?
<slangasek> agateau: /lib/udev/vol_id has gone away, and this is deliberate; the package relationships are in place declaring this
<slangasek> yeah
<agateau> slangasek: any idea how I could unblock the upgrade?
<slangasek> agateau: what package failed to configure?
<agateau> slangasek: initramfs-tools
<slangasek> you should be able to continue from where it failed, and have apt clean everything up on its own
<slangasek> really?  that doesn't make any sense.
<slangasek> the initramfs-tools package in karmic doesn't use /lib/udev/vol_id
<slangasek> did apport give you an option to file a bug report?
<agateau> slangasek: it starts update-initramfs which starts cpio, which complains
<agateau> slangasek: no
<slangasek> can you post your /var/log/apt/term.log somewhere?
<agateau> sure
<agateau> slangasek: http://pastebin.com/f11b35e23
<agateau> slangasek: sorry it's all in french
<slangasek> agateau: no problem - but this log shows that the packages failing to configure are kdepim-groupware and gtk-doc-tools, I don't see any initramfs problems...
<agateau> slangasek: just saw this yes
<agateau> slangasek: i can paste you the terminal output if you want
<slangasek> I guess we need that, yes
<StevenK> pitti: Okay, thanks.
<agateau> slangasek: http://pastebin.com/m27525fb6
<slangasek> agateau: ok, it's trigger-related, I thought that might be the case; now I just have to see what's calling the trigger
<slangasek> agateau: and for that, I guess we need more of the terminal output from earlier :(
<agateau> slangasek: I can paste more
<agateau> just not sure it will be enough
<slangasek> agateau: I suspect that somewhere in the output there will be 'update-initramfs: deferring update (trigger activated)" - I need to see the name of the package being configured right before that
<agateau> slangasek: http://pastebin.com/m31bb5245
<agateau> seems to be ntfs-3g
<slangasek> aha
<agateau> slangasek: but this seems to happen later as well
<agateau> i do not have the complete output :/
<agateau> slangasek: console-setup is also triggering this
<slangasek> right
<slangasek> both packages have correct dependencies, though...
<slangasek> i.e., neither package can have its postinst called unless initramfs-tools is configured, which should only be possible while initramfs-tools are both at the jaunty version or both at the karmic version
<slangasek> agateau: as far as getting out of this: does 'sudo dpkg --configure -a' work?
<agateau> slangasek: no :/ that's the first thing I tried
<agateau> slangasek: my initramfs-tools is 0.92bubuntu38
<slangasek> gah, that makes no sense
<slangasek> agateau: grep -rl lib/udev/vol_id /usr/share/initramfs-tools /etc/initramfs-tools ?
<agateau> slangasek: http://pastebin.com/f205a1d1
<slangasek> ah!
<slangasek> ok, udev is missing a Breaks: on *casper* :)
<agateau> slangasek: should i try to dpkg -r casper ?
<slangasek> agateau: that might work, yes; if all else fails, "rm /usr/share/initramfs-tools/hooks/casper" to get around the dpkg breakage
<agateau> slangasek: ok
<slangasek> agateau: then file a bug on udev, saying that it needs Breaks: casper (<< 1.174) for vol_id :)
<agateau> slangasek: ok will do
<agateau> slangasek: thanks!
<slangasek> sure
<agateau> dpkg -r lupin-casper casper did the trick
<slangasek> pitti, Riddell: bug #339313 is still outstanding, no new information about its status in karmic?
<ubottu> Launchpad bug 339313 in ubuntu-release-notes "Kubuntu Jaunty: Cannot Connect To Wireless Network with WEP shared key" [Undecided,Fix released] https://launchpad.net/bugs/339313
<pitti> slangasek: I just know that it apparently got much worse recently (no wpa2 either any more) :(
<slangasek> :-(
 * pitti chuckles at some hal-info data
<pitti>     <match key="system.hardware.vendor" string="To Be Filled By O.E.M.">
<ogra> wow
<Ng> I have several old motherboards that identify themselves as that
<ogra> regulary bought at a shop ?
<YokoZar> ok launchpad just sent me the strangest bug email:  status new->triaged  followed by status triaged->new
<pochu> somebody quickly changed his mind?
<Ng> ogra: yeah, just dirt cheap motherboards ;)
<Riddell> slangasek: it's still as unpredictable as its always been.  we ship the most reliable version from upstream and that's about all we can do
<ogra> Ng, and slackish OEMs :)
<YokoZar> pochu: maybe...I wouldn't expect launchpad to email me then though...
<slangasek> Riddell: there's no option to buy upstream lots of caffeine and get them to make it behave sensibly? :)
<Ng> ogra: yep. I'm mildly sure one of them was an Asus
<Riddell> slangasek: upstream is currently in the process of re-writing it all again, we can only hope the outcome will be an improvement
<slangasek> eew :(
<pitti> YokoZar: It also happened to me, I think; I keep getting confused by the new edge layout of bug states and the old "change status/add commetn" dropdown
<pitti> and if you change the status iwth the ajax thing, and then add a comment, the previous status change is reverted
<YokoZar> pitti: Definitely a launchpad beta bug then
<wgrant> pitti, YokoZar: Bugs already exist about the commenting and double-click issues, and there's a long-standing bug about not emailing about quickly-reverted changes.
<sebner> pitti: I was told you are the hardware hero who can help me debugging my issue. My external harddrive can't get mounted, on recognising it I get errors. (devicekit related? works with windows and jaunty)
<Laney> (pastebin the errors?)
<sebner> Laney: don't rush :P
<sebner> that's the output I get from dmesg: http://paste.ubuntu.com/219650/
<dholbach> haha... the logout dialogue doesn't allow me to reboot or shutdown now!
<Laney> I just get kicked to gdm
<dholbach> I just can suspend or log out
<dholbach> feels like Hotel California
 * slangasek laughs
<ogra> dholbach, its back in the system menu again
<Sarvatt> even there it works like he said for me :D oddly on one machine i can shutdown after the "shutdown" in the menu that logs me out but on another machine i can only hibernate and suspend
<ogra> heh
 * ogra never shuts down unless update-manager tels him to ...
<ogra> bu i have all options in the shutdown dialog
 * Laney likes to save on electricity bills
<dholbach> ogra: it was in the system menu, but when I clicked it it didn't greyed out the shutdown option
<dholbach> I rebooted anyway and it's back now
<ogra> weird stuff
<ogra> i hope the DX team finally gets fusa ported
<ogra> so we have it all back as it was
<ogra> what annoys me most with the gdm fusa is that it uses my login picture, so i have to see my head as icon in the panel all the time
<ogra> i would work in front of a mirror if i wanted to see my ugly face all the time
<highvoltage> ogra: a mirror!? you know that you could just use cheese.
<highvoltage> (fwiw I also find it a bit annoying)
<pitti> hey sebner
<sebner> Pitt:)
<pitti> dholbach: fixed with this morning's consolekit upload
<pitti> ogra: ^ FYI
<pitti> sebner: hm, seems it's detected, and then breaks down halfway; do you see it in "devkit-disks --dump"?
<sebner> pitti: nope
<pitti> sebner: could you try with 2.6.30 or the jaunty kernel on karmic?
<sebner> pitti: I tried with .30 already but still not working. jaunty kernel doesn't seem installable on karmic anymore?!
<sebner> pitti: or do you mean looking at the --dump under .30er kernel?
<pitti> sebner: not installable> how so?
<pitti> sebner: I often see those if the drive is underpowered (with USB-powered drives)
<sebner> pitti: Package linux-image-2.6.28-11-generic has no available version, but exists in the database.
<pitti> but if it works fine under jaunty, it could be a kernel regresssion
<pitti> sebner: right, you need jaunty .deb sources, or just grab it from archive.u.c.
<sebner> pitti: jaunty was on a different pc though
<pitti> aah
<pitti> now, that changes things
<sebner> pitti: at least it works on windows (7) on *this* pc
<sebner> pitti: rebooting now in .30er kernel
<sebner> pitti: not working either
<pitti> sebner: does a jaunty live CD work?
<pitti> just to see whether it's a sw regression or a hw issue
<pitti> "hw specific issue"
<sebner> pitti: well, I used this external harddrive at jaunty times, it's working on another jaunty pc and on my windows. I tend to say it's devicekit but let's see
<pitti> could be
<sebner> pitti: I don't need to mention that I tried different ports  ^ ^
<pitti> sebner: you could try running devkit in debug mode
<pitti> sudo killall devkit-disks-daemon
<sebner> pitti: livecd or debug mode?
<pitti> sudo /usr/lib/devicekit-disks/devkit-disks-daemon
<pitti> and capture the log, what happens
<pitti> sebner: on your karmic system
<sebner> pitti: kk, kernel version doesn't matter?
<sebner> pitti: and usb already plugged in when starting the daemon?
<pitti> sebner: no, please plug it in while the logging is running already
<pitti> sebner: if it behaves the same with differnet kernels, it doesn't seem to matter, yes
<sebner> pitti: http://paste.ubuntu.com/219685/
<Keybuk> ok, I've just fallen in love with "git commit --amend"
<pitti> sebner: ok, so the kernel sends a remove event, presumably because of that usb error
<sebner> pitti: ok, any hint what we should do next?
<pitti> sebner: I'm afraid not; ubuntu-bug linux perhaps?
<pitti> I've seen other instances of this in the past
<pitti> but I have no idea why that happesn
<sebner> pitti: I've done bug search and I've already found an old linux bug report bug everything with error -110 and not -71 as I have
<Sarvatt> you getting lots of usb errors lately too sebner?
<sebner> Sarvatt: well only with my external harddrive. usb sticks are working
<Sarvatt> i started getting these flooding dmesg every now and then a few weeks ago when my webcam stopped working http://pastebin.ubuntu.com/219722/
<sebner> Sarvatt: exact the same errors as I get
<Sarvatt> looks like they started around july 1st or so
<sebner> Sarvatt: seems to be a devicekit/kernel error
<amitk> hmm.. my application menu disappeared after a karmic dist-upgrade just now
<amitk> so did preferences and administration
<amitk> in System
 * amitk tries logging out and back in...
<geser> my Applications menu was also empty but sendind a HUP signal to gnome-panel fixed it
<sebner> pitti: anyways, thx for your help. I'll file a bug
<pitti> sebner: sorry, no idea about that :/
<Sarvatt> does anything depend on usbfs? i was just guessing it was something about usbfs getting moved to embedded in the kernel so we probably dropped it
<Sarvatt> (in 2.6.31)
<pitti> Sarvatt: is that /proc/bus/usb? That has been deprecated years ago
<amitk> yup, logout and login fixes the menu again.
<ScottK> cjwatson: I believe I figured out my netbook image background problem (which based on your replies and where I think the problem is, I don't think I was explaining very well).  There's a debian-cd merge proposal waiting that should take care of it.
<cjwatson> ScottK: ok, thanks
<cjwatson> ScottK: oh, you meant *that* background :)
<cjwatson> merged
<ScottK> cjwatson: Yes.  Sorry I didn't explain myself very well.
<ScottK> Thanks.
<pitti> Riddell, ScottK: what bit of KDE watches /var/crash/ and spawns apport-kde?
<gleeb_> hey guys... anyone here who's working with mono?
<pitti> gleeb_: directhex is the primary mono maintainer
<Riddell> pitti: update-notifier-kde
<pitti> Riddell: oh, heh; should have guessed, thanks
<mterry> How does one request that a source package be removed (say if its binary packages are now provided by a different source package?)
<pitti> mterry: file a bug against that package and subscribe ubuntu-archive
<pitti> or bug an archive admin on IRC
<seb128> the binary case should not require a bug though
<pitti> mterry: what's the package?
<mterry> pitti, k.  oem-config is obsolete by ubiquity now
<pitti> mterry: right, looks like; I'll remove it
<mterry> pitti, oh, OK.  Thanks!
<pitti> [done]
<mterry> That was fast.  :)
<pitti> Riddell: would you mind doing s/apport-qt/apport-kde/ in update-notifier-kde? I can't commit to the branch (~kubuntu-members)
<Riddell> didn't I do that?  let me check
<Riddell> hmm, seems not
<Riddell> pitti: you're looking at lp:~jr/apport/kde-fix I take it?
<Riddell> pitti: update-notifier-kde done
<pitti> Riddell: no, I just apt-get source'd
<pitti> Riddell: thanks
<pitti> Riddell: I already merged that a while ago
<pitti> it's in karmic
<Riddell> good, thanks
<cr3> Keybuk: ping, was upstart changing from event.d to init announced somewhere? if so, I need to start paying more attention to such announcements :)
<Keybuk> cr3: it's in the Upstart NEWS
<Keybuk> that's installed as /usr/share/doc/upstart/NEWS.gz
<Keybuk> and I always include that in release announcements to upstart-devel, LP, etc.
<Keybuk> normally I tend to summarise it in debian/changelog (for any package I maintain, whether upstream or not)
<Keybuk> but since the version of Upstart in Ubuntu was so old, the summary of what changed was "everything"
<ttx> and the winner is... bug 400000
<ubottu> Launchpad bug 400000 in nautilus "nautilus crashed with SIGSEGV" [Undecided,Invalid] https://launchpad.net/bugs/400000
<mvo__> !
<ttx> Apport ftw!
<pitti> \o/
<pitti> that's the proof, seb128 makes our bug tracker explode
<seb128> pitti, lol
<cr3> where is synaptic configured to check for packages periodically and then popup a window or notification to the user currently logged in?
<mvo__> cr3: the interval for this is configured via system/administration/software sources
<cr3> mvo__: if I want another application to behave similarly across all flavours of ubuntu, this might not work then
<cr3> mvo__: could you suggest a way for me to automatically start an application when a user logs in (who might also get auto-logged in)
<mvo__> cr3: /etc/xdg/autostart
<mvo__> cr3: check e.g. the update-notifier desktop file in there - but I'm not sure if it will really work on all flavour
<mvo__> cr3: for that, somewhere in the xsession is a better bet
<mvo__> cr3: /etc/X11/Xsession.d/ - what is your use-case?
<cr3> mvo: my use-case is that I have situations where I want testing to automatically start after a system has been installed. I used to use upstart but I'd like the flexibility of running the application as the user in an X context and also as the user in a console context.
<cr3> mvo: whether the application actually does testing or not depends on a preseed value, which is set to not test by default
<cr3> mvo: for X, I could probably use /etc/X11/Xsession.d. for console, I probably need to use sysv init or upstart
<mvo> cr3: yeah, sounds like it. xsession.d is run early, i.e. before the full desktop is up, but if that is ok, then that should be ok I guess
<cr3> mvo: worst case, I can probably sleep for a while before doing anything
 * mvo nods
<cr3> mvo: thanks man!
<mvo> np
<Keybuk> not for the first time, I wish that dpkg-source -b had a --not-so-damned-picky argument
<Keybuk> actually
<Keybuk> you know what would be nice
<Keybuk> some kind of opposite to -i
<Keybuk> "only include changes that match this regexp"
<Keybuk> rather than "ignore changes that match"
<Keybuk> or just something like dpkg-buildpackage -S --only-debian
<jdstrand> Keybuk: hi-- so I am looking at bug #399954. While I can say that it did work ok on jaunty, the technique is obviously too brittle. So rather than figuring out why it broke on karmic and didn't on jaunty, I'm going to just say "let's change it"
<ubottu> Launchpad bug 399954 in dhcp3 "Karmic Boot hangs at "Configuring network interfaces"" [Medium,Triaged] https://launchpad.net/bugs/399954
<Keybuk> jdstrand: it only worked on jaunty because Upstart failed to clear utmp properly on shutdown
<Keybuk> so runlevel would return "2" or some nonsense
<jdstrand> Keybuk: ah, well that clarifies a lot :)
<Keybuk> wtmp, I mean
<jdstrand> ok, no matter
<Keybuk> suffice it to say, the jaunty runlevel tool was really buggy, and you were relying on those bugs ;)
<Keybuk> the reason the kernel change made it break, of course, was that the kernel enabled apparmor again
<jdstrand> Keybuk: sure, and I didn't realize I was relying on bugs, I thought that was expected behavior. so my thinking was always that I wanted to know when I left rcS, since apparmor should have been started by that point. is there a way to determine this?
<jdstrand> Keybuk: or is that idea flawed
<jdstrand> Keybuk: I could probably change the udev rule, but I don't think I want to do that
<Keybuk> I think this is one of those cases where we need to figure out how apparmor is supposed to work
<Keybuk> you're basically trying to delay an asynchronous operation until apparmor is started
<Keybuk> so here's a question
<Keybuk> why can't apparmor be started before udev?
<Keybuk> (I expect because apparmor is installed under /usr ?)
<Keybuk> which leads to my next question
<jdstrand> no, apparmor_parser is /sbin
<Keybuk> but libapparmor is in /usr/lib
<Keybuk> ok, apparmor_parser doesn't depend on that
<jdstrand> libabut apparmor_parser doesn't use libapparmor
<Keybuk> here's another question
<Keybuk> why can't you parse apparmor policies on the fly?
<Keybuk> instead of waiting for a "parse all the policies" to happen
<Keybuk> why not just have the dhclient script parse the dhcp-related policy if it hasn't already happened?
<Keybuk> that kind of model becomes *really* Upstart-friendly
<Keybuk> e.g.
<Keybuk>     start on starting cupsys
<Keybuk>     exec /sbin/apparmor_parser /etc/apparmor.d/cupsys
<Keybuk> if and when cupsys is started, the apparmor policy would be parsed for it *first*
<jdstrand> bear with me as I am not upstart script fluent yet, but that works fine for cups, when you have an upstart script, but doesn't the udev rule bypass that? I mean, we don't start cups via udev
<jdstrand> Keybuk: and btw, I don't care if apparmor loads all the policies at once or not-- I can just as easily do 'apparmor_parser -a /sbin/dhclient...'
<jdstrand> Keybuk: but I can't run that until I have /sys/kernel/security/apparmor/profiles
<Keybuk> I was just illustrating
<Keybuk> obviously while cups is an init script, you'd just paste the apparmor_parser code into it
<Keybuk> what creates /sys/kernel/security/apparmor/profiles ?
<jdstrand> let me check...
<jdstrand> actually, if sbeattie or jjohansen were around, they could answer much more quickly :) ^
<jdstrand> but I'm still looking
<cr3> pitti: in apport, why is there etc/default/apport and apport.default in the source tree?
<pitti> cr3: there isn't?
<pitti> cr3: neither in trunk, ubuntu bzr, nor karmic package
<pitti> cr3: I remember that this was the case for a few days, but I fixed that ages ago..
<cr3> pitti: err, I was looking at apt-get source apport on jaunty
<pitti> cr3: which version are you using?
<pitti> ah, perhaps
<cr3> pitti: cool, I was just checking if there might be a reason for that. as usual, you're way ahead of me :)
<pitti> the apport.default was a mistake
<jdstrand> Keybuk: it is available when you mount securityfs
<Keybuk> jdstrand: ah yes, the bendoverfs!
<Keybuk> what mounts that?
<pitti> cr3: yeah, the reason was just my stupidity (or rather trying to represent a file rename in a package diff.gz)
<jdstrand> Keybuk: /etc/init.d/apparmor
<Keybuk> jdstrand: since it's a kernel filesystem we could mount that in mountkernfs.sh
<Keybuk> then you could do on-the-fly apparmor policy setting whenever it was needed
<jdstrand> Keybuk: ok, then we move the mount into mountkernfs.sh, then I can just check if /sys/kernel/security/apparmor/profiles and run apparmor_parser ... if it is
<jdstrand> Keybuk: that is definitely cleaner. will have to implement mountkernfs.sh carefully though... ie if apparmor is available or if some other LSM (or none) are loaded
<Keybuk> why mountkernfs.sh ?
<Keybuk> surely that can just mount securityfs, whatever provides it?
<Keybuk> it's not apparmor-specific no?
<Keybuk> it looks like debugfs from what I can tell
<Keybuk> "intended to be mounted under /sys most of the time"
<jdstrand> oh, well if that is the case, then no problem
<rickspencer3> dholbach: can you join #quickly?
<jjohansen> Keybuk: everything in /sys/kernel/security/apparmor/ is created by the AppArmor kernel module, the fs is part of securityfs and shows up as soon as securityfs is mounted
<jdstrand> Keybuk: alright, thanks for your feedback. it was invaluable. I'll upload a new dhcp3 which will assume the securityfs change (which will fail to load the profile) so people can boot again
<jdstrand> Keybuk: then I'll test out the securityfs changes and upload when I have everything going correctly
<jdstrand> Keybuk, jjohansen: actually, looking at mountkernfs.sh it seems as long as I check for securityfs in /proc/filesystems (ie, like we do in sysfs), it should be easy
<kirkland> mvo: ping
<Keybuk> jdstrand: I think domount does that already no?
<kirkland> mvo: two more minor changes to update-manager and update-notifier ...
<Keybuk> jdstrand: ah, no, yeah copy the sysfs entry
<Keybuk> jdstrand: while you're in there, could you add debugfs as well (/sys/kernel/debug)
<kirkland> mvo: need to drop the dependency on update-motd, and add a versioned dependency on pam (>= 1.0.1-9ubuntu3)
<kirkland> mvo: i was just about to add that now, unless you would prefer to do so yourself?
<jdstrand> Keybuk: sure thing, and thanks again! :)
<jjohansen> jdstrand: hmm okay.  To actually find if apparmor is enabled you look in /sys/modules/apparmor/parameters/enabled
<jjohansen> it has bug currently, that I have just fixed
<jjohansen> if you have hit this already, sorry I am still catching up on the scroll back
<jdstrand> jjohansen: no, this was a bug in dhclient
<jdstrand> jjohansen: udev brings up dhcp interfaces before apparmor is started
<jdstrand> jjohansen: so I had a brittle method that worked around that on jaunty, and we were trying to figure out a robust method for karmic
<kirkland> mvo: actually,  libpam-modules (>= 1.0.1-9ubuntu3)
<jjohansen> jdstrand: yeah, I saw that but there is still a bug where /sys/modules/apparmor/parameters/enabled is reporting AA is enabled even when it isn't
<jdstrand> jjohansen: so, if /sys/modules/apparmor/parameters/enabled has '1', then I should be able to run apparmor_parser -a <profile> safely, correct?
<jdstrand> jjohansen: do you recommend I check for that and the existence of /sys/kernel/security/apparmor/profiles? for the time being?
<jjohansen> jdstrand: in theory yes
 * jdstrand goes to work
<jjohansen> jdstrand: the parser will actually check for that and fail if it can't find it
<jdstrand> jjohansen: how does one disable apparmor on the karmic kernel command line? I'm going to have to change documentation since initscript behavior is changing
<jdstrand> security=?
<jjohansen> jdstrand: you can currently do either apparmor=0 or security=XXX where XXX is not AppArmor
<jdstrand> (ie, simply removing the initscript won't disable apparmor any more)
<jdstrand> jjohansen: ok thanks
<jjohansen> however apparmor=1 is not enought to enable apparmor
 * jdstrand nods
<mvo> kirkland: thanks, I can do that - or you just commit it to bzr and I include it in the next upload, both is fine with me
<kirkland> mvo: i just did update-manager
<kirkland> mvo: doing update-notifier now
<kirkland> mvo: i'm prepping the upload, but the debdiff isn't clean; config.* modified; trying to figure that out now
<slangasek> ScottK, rgreening: what's the status of kubuntu netbook test cases?  I don't find anything under http://testcases.qa.ubuntu.com/, so I'm not sure what to set up on the ISO tracker
<brianchidester> slangasek: what do you mean by kubuntu netbook test cases?
<brianchidester> slangasek: is that for a specific build?
<slangasek> brianchidester: the kubuntu team is doing a netbook build for karmic
<brianchidester> slangasek: will that be a unr based build or something original?
<brianchidester> do you know?
<slangasek> brianchidester: I don't think it's based on UNR
<rgreening> slangasek: hey. I haven't anything up yet... not even sure where to start (seeing I was voluntold to work on it .. hah). Any pointers slangasek?
<slangasek> rgreening: mm, not really :/  Maybe ScottK has a notion of what the test case scope needs to be
<rgreening> brianchidester: it's going to use the new KDE netbook plasma desktop being developed. (eventually).
<brianchidester> rgreening: is this a community project then? and what does the kubuntu team have for qa resources?
<rgreening> brianchidester: for now, it's simply a tweaked kubuntu-default-settings for kubuntu-netbook metapackage (change some package defaults and fonts sizes, etc for better visibility on netbooks).
<slangasek> rgreening: at the last release meeting, ScottK indicated that work was started on the test cases though, wonder why that is?
<rgreening> slangasek: prob cause it sounded better :)
<rgreening> brianchidester: it is indeed a community project, like kubuntu is
<rgreening> I'm no QA expert... I helped write the usb-creator-kde front-end... I think thats why I was volunteered.
<brianchidester> rgreening: and consequently only community qa, ok
<rgreening> ya
<brianchidester> rgreening: the reason I am interested is because oem has fairly comprehensive test suite but does not have any kde test cases
 * rgreening thinks QA is Questions and Answers (just kidding)
<rgreening> I can help, but I need very specific things to test/doc/write-up... seeing I have no experience with this.
<brianchidester> rgreening: the plan for the not too distant future is a repository of test cases in testcases.qa.ubuntu.com but until then we (I) am doing work to collect/write them for us (oem)
<rgreening> ok
<brianchidester> but the answer is there has been no work done on that yet rgreening?
<rgreening> that would be accurate
<brianchidester> rgreening: and are you heading that up or is ScottK?
 * rgreening has been bogged down with my paying job.. doing perf reviews
<rgreening> I'm going to have to defer to ScottK...
<rgreening> unless I get some more detailed direction...
<brianchidester> rgreening: i don't mean to put any pressure on you, actually i want to help I just need to know who to coordinate with
<rgreening> brianchidester: I'm willing to help, but I need specifics. :) I'm a "here's the list of goals" kind of guy...
<rgreening> I PM'd ScottK, but he doesn't seem to be around at the moment...
<rgreening> ScottK: Is definately more knowledgable than I in this area.
<brianchidester> rgreening: then I will work with you on that, do we have a spec for the kubuntu netbook build? what is that going to be called by the way
<brianchidester> i would assume not knr
<rgreening> def no remix
<rgreening> it's not a remix :)
<Riddell> it probably is
<rgreening> lol.... Riddellwe discussed at uds, and didn't want to use the term remix
<brianchidester> rgreening: i think strictly speaking it is though the term is not clearly defined
<slangasek> it's called "Kubuntu Netbook"
<rgreening> ya
<brianchidester> ok cool
<brianchidester> and is there a spec for it yet?
<slangasek> the term is clearly defined, and then UNR goes against the definition
<brianchidester> that sounds to be a more accurate assessment yes
<rgreening> lol
<rgreening> brianchidester: let me see if I can locate the spec (unless Riddell can find it faster)
<Riddell> https://wiki.kubuntu.org/KubuntuKarmicNetbook
<rgreening> see. Riddell is faster than a speeding bullet. no wonder he's our super man :P
<brianchidester> Riddell: too bad someone didn't continue with that illiteration then we could have had a nice neat acronym for it like unr only KKK
<brianchidester> s/alliteration
<rgreening> ouch....
<rgreening> hah
<rgreening> K2N maybe :)
<rgreening> or 2KN
<brianchidester> so i'm the only one who thinks its a good acronym, i guess we wont go with it then
<rgreening> not unless you want to go join forces with the Satantic version of Ubuntu
<rgreening> :P
<brianchidester> rgreening: i will take a look at the spec and get back to you and ScottK with your checklist
<brianchidester> i always thought that was an interesting little variation...
<rgreening> brianchidester: that would be awesome. I can work from a checklist :)
<rgreening> heh
<brianchidester> alright cool, thanks
 * ogra waits for the xubuntu NR ...
 * directhex pokes james_w 
<cjwatson> brianchidester: ScottK has been using the abbreviation "KNE"
<slangasek> kees: 'incomplete' doesn't look like the correct state for bug #202089?
<ubottu> Launchpad bug 202089 in pulseaudio "Pulseaudio is blocking normal sound after resume" [Low,Fix released] https://launchpad.net/bugs/202089
 * slangasek sets back to 'triaged'
<jdstrand> Keybuk, kees: do you guys know of any security implications of having /sys/kernel/debugfs mounted by default?
<jdstrand> mdeslaur: ^
<brianchidester> cjwatson: thanks :-)
<brianchidester> cjwatson: what does the e stand for?
 * jdstrand -> afk
<cjwatson> brianchidester: edition
<brianchidester> assuming it kubuntu netbook...
<brianchidester> gor it
<cjwatson> (as in the wiki page name)
<kees> slangasek: okay, true
<cjwatson> err, or not
<brianchidester> s/gor/gotr
<kees> slangasek: I've flipped 326532 to triaged as well.
<cjwatson> as in the spec name
<kees> jdstrand: don't know.
<brianchidester> yeah i was wondering which page exactly
<kees> jdstrand: seems like it might have funny stuff in it
<brianchidester> yes i see
<jdstrand> kees: yeah, that is what I was thinking, but I don't know enough about it
<jdstrand> Keybuk: I'm not sure I feel comfortable mounting debugfs by default. I'd need to research it and don't have time atm. I think I will make my mountkernfs.sh change without it for now
<kees> jdstrand: sounds from other devs like it's not a good thing to have mounted by default
<kees> jdstrand: though in theory, it's all only read-only by root
<jdstrand> Keybuk: ^
<jdstrand> kees: thanks for looking into it-- google wasn't as forthcoming as I would have hoped :)
<kees> jdstrand: I asked gregkh, so it's not exactly a wide range of opinions.
<jdstrand> kees: it's enough that we are in agreement on concern and the original developer (iirc) of it feels it probably isn't best
<Keybuk> jdstrand: it gets mounted anyway if you use sreadahead
<jdstrand> it can be revisited if needed
<jdstrand> Keybuk: is sreadahead installed by default in all of Ubuntu now?
<Keybuk> but sure, I guess it's not suitable for a security team member to make the change if he's uncomfortable with it ;)
<Keybuk> jdstrand: planned to be in karmic
<jdstrand> Keybuk: huh, even server?
<Keybuk> jdstrand: sure
<jdstrand> interesting
<kees> can we make the mount point 0700  ?
<Keybuk> jdstrand: even servers care about a faster boot
<jdstrand> anyhoo, I'd rather not add it myself at this point
<Keybuk> kees: sure
<kees> I'm happier with that then.
<cody-somerville> chrisccoulson, I was just wondering if you were going to merge my branch in or if there was any problems with it
<cody-somerville> jdstrand, Do you know if Debian uses -Wl,-z,relro and -fstack-protector by default?
<jdstrand> cody-somerville: kees is the one to ask. I think they are doing some stuff with hardening-wrapper, but I don't know how much off-hand
<cody-somerville> jdstrand, kees: do you know if and how much of a performance impact some of these flags have?
<kees> cody-somerville: they do not use it by default.
<kees> cody-somerville: relro has literally zero performance cost
<kees> cody-somerville: stack-protector adds about 4 instructions per large-stack function, and has no measureable performance hit.
<kees> cody-somerville: there are about 29 packages in Debian using hardening-wrapper
<kees> cody-somerville: note that h-w adds PIE as well, which has about 4% performance loss, unless it is a very .text-code heavy application (like a JIT, scripting language, etc), where it can in some situations get as high as 15% loss.
<kees> cody-somerville: Ubuntu does not use PIE by default.  (note that the performance hit from PIE is ia32 only)
<kees> cody-somerville: why do you ask about relro?  (that's an uncommon feature.)  the "next step" for relro is to add -Wl,-z,now but that has start-up time issues, so I was planning to apply those on a case-by-case basis.
<andre_pl> I've noticed what I think is a regression from 8.04 to 8.10 with regards to PIL (python-imaging package) on packages.ubuntu.com, the only differences I see are python-central and zlib1g versions. the latter of which appears to have been bumped down a revisions. does anyone know perhaps why this happened or if it could be related to png transparency issues?
<cjwatson> I don't know about python-imaging but FWIW I think you're mistaken about zlib1g ...
<cjwatson>     zlib1g | 1:1.2.3.3.dfsg-7ubuntu1 |         hardy | amd64, i386
<cjwatson>     zlib1g | 1:1.2.3.3.dfsg-12ubuntu1 |      intrepid | amd64, i386
<cjwatson> (says rmadison)
<andre_pl> cjwatson: http://packages.ubuntu.com/intrepid/python/python-imaging http://packages.ubuntu.com/hardy/python/python-imaging
<andre_pl> that site must be wrong then
<cjwatson> andre_pl: oh, minimum version of the dependency isn't the same as what you'll actually have installed
<andre_pl> I see.
<cjwatson> andre_pl: that's probably just because there were changes in dpkg-dev a while back to try to weaken shared library dependencies a bit when stronger ones weren't necessary
<andre_pl> how can I deltermine exactly which version is installed? because the problems I'm see could definitely be caused by zlib, and it seems to be the only dependency that might be different.
<andre_pl> and heavily used by libpng
<cjwatson> dpkg-query -W zlib1g
<andre_pl> ok, so the intrepid version is slightly newer, -12ubuntu1 vs -7ubuntu1
<andre_pl> could it be catastrophic to try installing the hardy packages on jaunty?
<andre_pl> intrepid rather
<cody-somerville> kees, Just pondering about why people report that they feel Debian is faster than Ubuntu sometimes
<cjwatson> andre_pl: beware that it's a long-known bug in dpkg that it doesn't report dependency problems on downgrade
<cjwatson> andre_pl: so quite possibly yes, you'd have to be careful
<cjwatson> andre_pl: would be safer to unpack the old zlib1g in your home directory and use LD_LIBRARY_PATH to point to it
<andre_pl> is there a safer alternative? maybe a backport from 9.x?
<kees> cody-somerville: I would guess kernel, honestly.
<andre_pl> i suppose i could test on jaunty and see if it has the issue too
<cjwatson> andre_pl: can't say without knowing what the problem is :)
<cjwatson> (err, that's not really "please tell me what the problem is", since I doubt it's my area of expertise ...)
<andre_pl> haha, understandable. I'm willing to do all the legwork, I'm just not sure whats generally the safer option, bacport or downgrade.
<cjwatson> andre_pl: usually safest of all is "find patch, backport just that patch"; in the absence of that, for reasonably stable libraries backporting is on the whole safer because that way you don't tend to lose ABIs
<andre_pl> ok, i'll see what I can do, thanks
<andre_pl> cjwatson: is there somewhere I can find a changelog of each small revision to a package? because the PIL version differs slightly too.
<cjwatson> andre_pl: just look in /usr/share/doc/<package>/changelog.Debian.gz
<cjwatson> or if that's missing changelog.gz
<cjwatson> you can also get the source packages from Launchpad (https://launchpad.net/ubuntu/+source/<package>) and use debdiff (in the devscripts package) to compare them, if you want to get more detail than that
<andre_pl> cool thanks
<andre_pl> cjwatson: FWIW the bug exists in jaunty too
<andre_pl> i need a second hardy machine to test on i think.
<andre_pl> maybe i did something to fix it on hardy that I have zero recollection of
<cudev> Anyone know what the message "if-up.d/mountnfs [device__]: lock /var/run/network/mountnfs exist, not mounting" at boot time means? It is preventing me from bringing up my devices at interface cards at boot. Of my 6 nics, only the one with a static IP comes up, but I can bring up the others after boot using 'ifconfig device__ up"
<soreau> Hello
<soreau> I was wondering if compiz will be shipping with Karmic despite it's incompatibility with gnome-shell and if it will remain in the repos, which version will it be?
<seb128> soreau, why shouldn't compiz be shipped, there is some ten thousand softwares in ubuntu, why would you want to remove something lot of people are using just because it's incompatible with some other software?
<soreau> I never said I didn't want anything shipped, I was just asking for factual information in general
<soreau> I assume compiz-0.8.2 will be in the repos, but not the default WM with gnome-shell
<soreau> Maybe I should be asking if gnome-shell will be default in 9.10 because I am merely assuming that it will be
<seb128> soreau, no it will not, it's an new project which has 0 tarball yet
<seb128> soreau, it will not be default before 10.10 in any case
<soreau> huh
<seb128> soreau, it's a new project, has no tarball, has not been shipped by GNOME or any distro and has opengl requirements which don't fit for a default install
<soreau> seb128: Well thanks for the information
<seb128> you're welcome
<A|i> is it safe to install mysql-server-5.1 for hardy from jaunty repository? I cannot find it for hardy
<A|i> only this one: http://packages.ubuntu.com/search?keywords=mysql-server-5.1
<lool> Hmm I'm seeing hangs in update-grub; it seems to be a debconf issue, perhaps in grub, but these packages didn't change recently
<lool> bug #400397
<ubottu> Launchpad bug 400397 in kexec-tools "Errors (hanging,only continue with Ctrl-c) while prosessing kexec-tools" [Undecided,Confirmed] https://launchpad.net/bugs/400397
<lool> Could be new grub-common, but I don't see how
<cjwatson> lool: commented
<cjwatson> (summary: use db_stop only with ridiculous amounts of care or you will shoot yourself in the foot)
<cjwatson> lool: I suggest removing that db_stop line and testing that, since you have a test rig handy ...
<sladen> 400k++
#ubuntu-devel 2009-07-17
<donspaulding> the #ubuntu folks told me to come here, even though the most recent version I've found this problem on is Jaunty (haven't tried Karmic yet).  Late in Jaunty's dev cycle I ran into a problem where my T61 would work fine for hours, then it would start behaving weirdly and I'd realize the / fs was mounted read-only.  A subsequent reboot would result in being dumped to a shell after the automatic fsck failed with some UN
<donspaulding> I bought a new hard drive, thinking that was the problem, reinstalled Jaunty (before it had been an apt-get upgrade && dist-upgrade) and ran into the same problem.
<donspaulding> I installed suse 11.1, and haven't had a problem for 2 months.  Reinstalled the released version of jaunty yesterday, bam, same problem.  It doesn't seem to matter if I use kernel 28-11 or 28-13, both cause problems.  This guy (when not complaining) looks to have experienced the exact same thing as me http://abing.gotdns.com/posts/2009/ubuntu-904-jaunty-jackalope/
<donspaulding> anyway, I suppose people in this channel have moved beyond Jaunty, but in case it rang any bells with anyone, I wanted to bring it up.
 * TheMuso sighs at drive by comments.
<directhex> TheMuso, he pays for support, damnit, it should be instant!
 * TheMuso sighs at drive by comments.eh
<TheMuso> gah
<TheMuso> heh
<maco> wonder if he used lvm
<maco> i watched dtchen's ext3 choke and get mounted read-only then fsck ate the data
<maco> but he said he'd only seen it with lvm, and the error log sounded like something lvm-able
<TheMuso> I was wondering whether he was using ext4.
<directhex> reiserfs!
<lool> cjwatson: Works; thanks
<lool> pushed
<dholbach> good morning
<jussi01> dholbach: morning Daniel :)
<dholbach> hey jussi01
<ogra> ARGH !!!!
<dholbach> ogra: GOOD MORNING!!!!!!!!!!!!! :-)
<ogra> so todays update completely reordered all files on my desktop
 * ogra curses
<ogra> dholbach, hey, morning :)
<dholbach> happened to me too
<dholbach> don't bother reordering them :)
<ogra> well, thats how i keep track of priorities of stuff i work on :)
<ogra> little desktop icon clusters :)
<dholbach> that explains a lot
<dholbach> just kidding ;-)
<ogra> heh
<dholbach> try gtg - it's REALLY good stuff
<ogra> looks like something tomboyish
<dholbach> hm?
<ogra> gtg
<dholbach> I like it because you can categorise and tag stuff, assign due dates, etc.
<dholbach> it's good stuff
<ogra> looks like tomboy merged with a tasklist
 * ogra os only looking at screenshots
<ogra> StevenK, i bet you are bored ... and urgently want to push NCommander's uboot-imx through NEW :)
 * ogra knows StevenK always waited for doing that ...
<pitti> Good morning
<ogra> morning pitti
<pitti> hey ogra
<sbeattie> TheMuso: can I assign you to bugs 395208 and 399084? Or should they go to the kernel team or someone else?
<ubottu> Launchpad bug 395208 in alsa-driver "[9.10 regression] HDA power_save=10" [Undecided,New] https://launchpad.net/bugs/395208
<ubottu> Launchpad bug 399084 in alsa-driver "[9.10 regression] HDA power_save=10" [Undecided,New] https://launchpad.net/bugs/399084
<dholbach> hey sbeattie!
<sbeattie> hey
<TheMuso> sbeattie: Unfortunately I was not the one who decided to try that out, and have been thinking of disabling the powersvae stuff, since I don't know how to fix the hda kernel code to make things work properly.
<dholbach> sbeattie: what do you think about a regression test suite session at UDW? :)
<TheMuso> So unless dtchen has plans to work on this, I think it will be disabled.
<dholbach> sbeattie: maybe the security folks could do it together with you :)
<sbeattie> dholbach: where's the schedule?
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep
<dholbach> only one slot left
<dholbach> if you can't make it at the time, we could try to do some shuffling around
<dholbach> it'd be great if more people contributed to it
<dholbach> I guess 20:00 UTC is 11:00 your time
<sbeattie> dholbach: I agree, it'd be good to get more contributers, was just thinking about presenting it to bugsquad
<dholbach> nice, that sounds good
<dholbach> good thing with UDW is: you'd still have a bit of time to prepare
<dholbach> (although I'd imagine that you get so many questions, that demoing 3-4 examples and talk about it a bit more general would be enough)
<sbeattie> dholbach: that time is good, but that friday I'm taking as a vacation day...
<dholbach> argh :-(
<sbeattie> (long weekend in the US)
<dholbach> I could ask agateau, Riddell, bdmurray, jcastro and pedro_ if they'd be willing to swap
<dholbach> although pedro, bdmurray and jcastro already swapped once to accomodate others
<dholbach> I'm really keen to get the schedule sorted out today, as I'll be on vacatoin afterwards
<dholbach> I'll drop everybody an email
<dholbach> thanks a lot though sbeattie!
<dholbach> sbeattie: I'll pencil you in for now and we'll try to get the swapping done
<dholbach> sbeattie: which session title would you like to have?
<sbeattie> dholbach: good question.
<dholbach> "Effectively testing for regressions" or something?
<sbeattie> Sure, that sounds good as a working title.
<dholbach> excellent
<dholbach> if you want to get in touch with the security folks if they want to hold the session with you, that's cool
<dholbach> I'll send out the time swapping email in a sec
<dholbach> thanks so much for this, sbeattie!
<sbeattie> dholbach: thanks for herding us cats and organizing everything!
<dholbach> you wouldn't imagine how much chasing up people it is :)
<StevenK> pitti: Right, all of the UNR MIRs are either Invalid or Fix Commited, shall I push the Big Red Shiny Button and start moving stuff to main?
<pitti> StevenK: I saw that you backed out fbreader, so go ahead
<StevenK> pitti: Should I leave -doc packages in universe, or promote the lot?
<pitti> is it just me, or did the latest round of upgrades now cause two mixer applets to appear?
<pitti> StevenK: please promote them completely
<StevenK> pitti: I'm also going to leave cheese-hildon in universe.
<pitti> StevenK: component-mismatches will show what should go back
<pitti> but -doc and -dbg have some implicit auto-seeding
<RAOF> pitti: Don't think it's only you; #ubuntu+1 thinks so too :)
<StevenK> pitti: So cheese-hildon should go to main just to go back, or shall I just ignore it?
<highvoltage> cjwatson: good morning, are you around perhaps?
<pitti> StevenK: right, you can ignore that; I meant -doc etc.
<kirkland> mvo: morning
<mvo> hey kirkland - thanks for your uploads
<kirkland> mvo: sure :-)
<kirkland> mvo: question for you, though ...
<kirkland> mvo: so the update-motd package isn't needed any more
<kirkland> mvo: there's a blast of failed upgrades, and i don't quite understand why
<kirkland> https://bugs.edge.launchpad.net/ubuntu/+source/update-motd/+bug/400462
<ubottu> Ubuntu bug 400462 in update-motd "package update-motd (not installed) failed to install/upgrade: no package named `update-motd' is installed, cannot configure " [Undecided,Confirmed]
<mvo> are those in launchpad?
<kirkland> mvo: ^
<kirkland> mvo: ideas?
<kirkland> mvo: its strange ...
<kirkland> mvo: update-motd gets uninstalled, but then it looks like it wants to configure it
<mvo> they look all prety recenent
<kirkland> mvo: oh yeah, they're all as of today
<liw> kirkland, does update-motd have a postrm?
<kirkland> liw: i think it might have a prerm
<kirkland> liw: yeah, a prerm
<kirkland> liw: and a preinst
<mvo> kirkland: let me read the terminal logs
 * mvo wonders if its something to do with the latest dpkg changes
<mvo> kirkland: you can not reproduce the problem yourself or can?
<kirkland> mvo: i did reproduce the problem
<kirkland> mvo: but it only happened once
<kirkland> mvo: when i dist-upgraded
<mvo> kirkland: great, I will try to reproduce it in a VM then here, it might be a problem in libapt (also this part has not changed in a while) or dpkg changed in some way
<kirkland> mvo: cool, thanks.
<mvo> kirkland: was that on your server or your desktop machine? I noticed that most of the bugreports have a bluez failure, but that may just be coincidence
<kirkland> mvo: desktop, and yes, i have bluetooth on that system
<StevenK> pitti: Right, everything promoted, and everything set to Fix Released.
<pitti> StevenK: yay, thanks
<StevenK> pitti: Thank you :-D
<mvo> kirkland: thanks. there have been cases in the past were failures there caused this incorrect error message, but I will first try to reprocue
<mvo> kirkland: I can reproduce it (yeah!) - now the fun^Wdebugging can start :)
<kirkland> mvo:  ;-)
<kirkland> mvo: awesome, thanks.
 * mvo fills up his tea cup
<liw> I see it too
<kirkland> mvo: you can have that bug, update it, whatever ;-)
<mvo> kirkland: heh :) isn't it pretty late in your TZ now btw ?
<kirkland> mvo: yessir, very, very late
<kirkland> mvo: it's almost early, even :-)
<mvo> heh :)
<cjwatson> highvoltage: hi
<mvo> kirkland: I updated the bugreport, its debatable I guess if this is a bug in dpkg or apt, but apt can not know if a package is complettely empty on install
<kirkland> mvo: hmm, okay
<kirkland> mvo: so it's not a bug in update-motd then?
<mvo> kirkland: a workaround is to ship with a e.g. README.Debian, that should be ok, the upgrader will suggest to remove update-motd anyway
<mvo> kirkland: well, update-motd triggered it and it can work around it
<kirkland> mvo: okay, sure, that's easy
<liw> that's a fun little bug: gnome has no panels, so no way to shut down or open a terminal; using the power button gives a dialog that doesn't let me shutdown
<mvo> liw: and alt-f2 does not work of course?
<ogra> welcome to the world of gnome-shell :P
<liw> mvo, it might, if I could use it, but kvm isn't letting me
<liw> but I could ssh in and shutdown from the command line
<liw> ogra, har har
<liw> (some days I think I should just stop using desktop systems at all, but text-mode browsing sucks)
<ogra> use the framebuffer for the browser then :)
<kirkland> mvo: okay, just uploaded an update that does dh_installdocs, which puts a changelog, thanks, copyright file
<kirkland> mvo: so the package is no longer empty
<kirkland> mvo: that should work around it on my end, right?
<mvo> kirkland: yeah, that should fix the problem
<mvo> kirkland: I will look into dpkg for a alternative next
 * cjwatson takes a deep breath and attempts to update ia32-libs
<pitti> cjwatson: with the debian reimplementation or the regular way?
<pitti> either way, good luck!
<cjwatson> the usual way
<cjwatson> don't actually have an amd64 box to hand here :)
<mvo> kirkland: I send a bugreport (plus possible patch) to debian, lets see what the dpkg team thinks)
<cjwatson> I'm just doing it on ronne
<cjwatson> looks like I have to update a few packages to stop depending on NBS things first
 * pitti throws a new gdm at the buildds, now more sane \o/
<davmor2> cjwatson: if you want I open up ssh on one of my 64bit test boxes :)
<sebner> pitti: \o/, I thought only the insane can do great things! xD
<davmor2> sebner: Yay there's hope for me yet then :D
<sebner> lol
<cjwatson> davmor2: I'll stick it up in a PPA once I have something vaguely working, but I think testing it will require an actual graphical session
<pitti> tkamppeter: are the hplip udev rules upstream anywhere? (just replying to Tim Waugh's "device permissions" thread)
<sebner> pitti: gdm + git. Wow, that's really insane to make it sane :D
<pitti> sebner: easeier than keeping to pile up more and more patches
<cody-somerville> pitti, launchpad can import git branches ya know
<sebner> pitti: now mor tty1 for gdm upgrade right?
<pitti> sebner: right, but that was already fixed in a previous version
<pitti> cody-somerville: I know, but cloning it directly was much faster than requesting an import and waiting for it to finish
 * cody-somerville nods.
<cody-somerville> pitti, Are you going to have a chance to review my merge proposal?
<sebner> pitti our gdm hero \o/
<pitti> cody-somerville: I discussed that with seb128 yesterday, and he asked me to hold back; it seems that gdm really needs more than just g-s-bin
<seb128> it needs a settings daemon and a wm to work correctly
<cody-somerville> wm, yes
<cody-somerville> settings daemon maybe not so much
<cody-somerville> we can patch the desktop file to launch x-window-manager instead of metacity
<seb128> not sure that's this simple, needs testing
<seb128> gnome-session expect the software it runs to register to the session
<cody-somerville> I agree
<cody-somerville> I've tested it and xfwm4 does indeed timeout
<cody-somerville> however, I want to try and bring down the Xubuntu cd size back to normal so people can continue to test
<cody-somerville> with the way things are now, half of gnome gets pulled into Xubuntu
<seb128> use xdm?
<cody-somerville> ...
<cody-somerville> Thats not a very sustainable solution.
<seb128> why?
<seb128> it should do the start a session job just fine no?
<mr_pouit> but it's ugly?
<cody-somerville> and I heard from bryce that it doesn't setup the proper security context
<seb128> I've no good reply, GNOME upstream don't design their software to make sure they work without GNOME
<seb128> so the new gdm is harder to make work in a non GNOME context
<simon-o> cody-somerville: what about slim? that's fast and looks nice
<seb128> and I'm not sure they will take patches for that
<seb128> so maybe it's time to look at an another login manager for xubuntu
<cody-somerville> seb128, It may come to that but for now we're going to attempt to integrate the new gdm for Xubuntu
<seb128> ok, good
<seb128> you will have to solve the need for a settings daemon and the registration issue then
<mr_pouit> simon-o: "SLiM is looking for a new maintainer!" on its homepage
<simon-o> mr_pouit: Just saw that too, that's sad. They did a great job
<cody-somerville> seb128, For now, can we patch gdm to depend on gnome-session-bin and to launch x-window-manager instead of metacity?
<seb128> that will create those timeout registration error for some users if they don't have x-window-manager set to a working alternative
<seb128> and we still need gnome-settings-daemon to be pulled in
<seb128> without it there is no accessibility, no theming, etc
<cody-somerville> seb128, Sure but gdm isn't the only thing in Ubuntu that depends on g-s-d
<cody-somerville> seb128, and g-s-d is *not* a hard dependency
<seb128> well it's a recommends if you want
<seb128> ie it will be pulled in with gdm
<cody-somerville> seb128, Can we make it a suggest for now so that the daily builds can be useful?
<seb128> can't you try to come with a working solution?
<seb128> if we workaround it nobody will care and that will stay this way
<cody-somerville> seb128, I was thinking I would investigate patching gdm to run x-session-manager instead of gnome-session directly
<cjwatson> maybe the settings daemon should be an alternative too ...
<cjwatson> not sure how to make that a generic concept
 * cody-somerville nods.
<hile> btw what has changed that the settings daemon requires so much of gnome to run? or has it always required, but gdm did not require it?
<cody-somerville> hile, gdm got rewritten pretty much
<seb128> hile, gdm used to be a gtk software now it's basically a gnome session
<seb128> they use gnome-session + a custom autostart set
<hile> ok
<hile> makes sense, from gnome pov
<pitti> seb128: well, we'll still have g-s-d in the gnome CDs anyway, so lowering the dependency in gdm itself shouldn't hurt us at all?
<pitti> seb128: and gdm without accessiblity is still better for xubuntu than xdm (which doesn't have all those fancy things either)
<seb128> pitti, it's technically wrong though, it means somebody with a minimal install doing apt-get install gdm will get a non working gdm
<seb128> pitti, I'm happy to use alternative depends
<pitti> cody-somerville: would there be an appropriate g-s-d alternative for xubuntu, so that it could Depends: g-s-d | xfce-something ?
<seb128> ie gnome-session | xfce-session
<pitti> seb128: right, just thinking that
<cody-somerville> xfconf
<seb128> I'm not sure it will work without gdm changes but that's rather a xubuntu change
<seb128> let's add the alternative depends now and let them sort how they make that work for them then
<pitti> I guess xfconf will work fine if you also change metacity to xfwm?
<seb128> they still need a session manager though
<seb128> or something running the autostarts
<pitti> gome-session-bin?
<cody-somerville> for now, lets depend on gnome-session-bin
<seb128> no
<seb128> gnome-session | xfce-something rather
<cody-somerville> no, thats still wrong
<seb128> I'm not going to depends on gnome-session-bin that's not enough requirement to get gdm working correctly
<pitti> gnome-session-bin, gnome-session | xfce-session, metacity | xfwm, gnome-settings-daemon | xfconf
<pitti> ?
<seb128> we need gnome-settings-daemon too for example
<seb128> and gpm
<seb128> and some accessibility tools
<cody-somerville> those aren't dependencies
<seb128> they are
<cody-somerville> no they are not
<pitti> perhaps at this point it would make more sense to build another gdm-xfce with all the dependencies swapped?
<seb128> when you apt-install gdm on a minimal install you should get the full user experience
<seb128> Recommends if you want but gdm should pull those
<cody-somerville> seb128, and that'll happen but things like gpm would be a recommend and not a depend
<seb128> which doesn't fix your CD build issue
<pitti> seb128: my depends line from above would provide that
<cody-somerville> seb128, we already include gpm
<seb128> pitti, if you do that make sure it pulls also accessibility tools required, gpm, etc
<pitti> sure, it wasn't the complete line, just illustrating
<seb128> would be easier to have "gnome-session | xsomething"
<cody-somerville> we might decide to use gnome-session-bin
<pitti> ^ that still needs an additional gnome-session-bin
<seb128> right
<pitti> (which is a no-op for ubuntu)
<seb128> I'm not arguing that ;-)
<pitti> okay
<seb128> just don't drop the gnome-session depends if you don't add all the required components
<seb128> ie make sure that you do a minimal install, apt-get install gdm and get it working correctly
<seb128> not complaining about some tools missing or themes not working or something
<ogra> did we drop the old gdm completely ?
<pitti> ok, sounds like a plan
<seb128> yes
<pitti> cody-somerville: does that work for you, too?
<cody-somerville> gdm should not directly depend on gnome-session but instead gnome-session-bin but *should* as seb128 ensure that the right stuff gets pulled in like some of the stuff that automagically got pulled in when depending on gnome-session
<cody-somerville> *as seb128 said
<pitti> cody-somerville: i. e. the dependency scheme from above (gnome-session-bin, gnome-session | xfce-session, metacity | xfwm, gnome-settings-daemon | xfconf)
<pitti> cody-somerville: *nod*
<pitti> cody-somerville: then you just need to make sure that those alternative dependencies occur before gdm in the xubuntu seeds
<cjwatson> I don't think you even need that - germinate should add all directly specified packages before trying to resolve any of their dependencies
<pitti> ah, nice
<cody-somerville> pitti, so I would see the deps being like this for now: gnome-session-bin, x-window-manager, gnome-settings-daemon | xfconf
<pitti> cody-somerville: x-window-manager isn't a real package
<cody-somerville> pitti, right-o
<pitti> metacity | x-window-manager would work
 * cody-somerville nods.
<pitti> i. e. you need to specify a preferred real package
<pitti> kirkland: why did you reopen bug 400462 ?
<ubottu> Launchpad bug 400462 in update-motd "package update-motd (not installed) failed to install/upgrade: no package named `update-motd' is installed, cannot configure " [High,Confirmed] https://launchpad.net/bugs/400462
<cjwatson> gah, ia32-libs/fetch-and-build only works when all the binary packages it wants are in sync with its sources :-(
 * cjwatson waits another hour ...
<pitti> cjwatson: IIRC there was a magic env var to override the check
<pitti> I think I added that ages ago when I was annoyed by exactly that
<cjwatson> pitti: I don't see one, but it doesn't matter, I can do other things
<pitti> cjwatson: SOURCE_VER_MISMATCH=1
<cjwatson> oh so there is
<cjwatson> thanks
<pitti> I haven't played around with ia32-libs-tools yet, but it seems much easier to maintain
<pitti> (and avoids the OMG 400 MB packages)
<cjwatson> yeah, but I'm worried about the fact that it requires an extra manual apt-get dist-upgrade after the first upgrade
<cjwatson> if we're actually getting multiarch (which seems not entirely implausible now) then I'd sort of rather skip straight to that
<pitti> *nod*
<pitti> anything that gets us rid of this excruciating ia32-libs pain is a major step forward
<tkamppeter> pitti, I have still to inform the HP guys about their new UDEV rules.
<pitti> ogra, lool: do we have daily armel CD builds for UNR? (Stefan Vogelsang was interested)
<ogra> no
<ogra> we only build live images but are lacking kernels
<ogra> (s/live/ubuntu-desktop/)
<pitti> ogra: oh, so http://cdimage.ubuntu.com/ports/daily-live/current/ armel won't work either?
<ogra> right
<pitti> ok, thanks
<ogra> there is no content in the kernel package thats used
<ogra> so it wouldnt boot
<ogra> pitti, we're supposed to have kernels for the two arches we will build for by A4
<lool> pitti: We don't due to lack of OpenGL drivers or 2D version of UNR
<lool> pitti: I just deferred the specs for this cycle, as it's a bit late to add these now
<ogra> right, that too :)
<Keybuk> superm1: I really hate the Mini 10v's touchpad, like, seriously wtf
<Keybuk> ;)
<ion> I couldnât live without a wacom-enabled tablet PC anymore. :-P
<tseliot> Keybuk: what's the problem? (I might already be working on it)
<tseliot> about the touchpad, I mean
<Keybuk> tseliot: that the mouse buttons are embedded in it
<Keybuk> so it's impossible to click without violently moving the mouse pointer
<tseliot> Keybuk: my patch was accepted today: http://bugs.freedesktop.org/show_bug.cgi?id=21613
<ubottu> Freedesktop bug 21613 in Input/synaptics "Property to make part of the touchpad insensitive to movements" [Enhancement,Resolved: fixed]
<Keybuk> tseliot: I'd rather have an option to turn the buttons off and use tap-to-click
<tseliot> Keybuk: you have an option to do that
<Keybuk> where?
<tseliot> Keybuk: you can set it with xinput
<Keybuk> how?
<tseliot> Keybuk: xinput set-int-prop $YOU_DEVICE_NAME "Synaptics Click Action" 8 0 0 0
<tseliot> this should do it
<Keybuk> why the 8?
<Keybuk> that appears to have changed the property, but the buttons still work
<tseliot> 8 bit
<Keybuk> in fact
<Keybuk> that has disabled tap-to-click
<Keybuk> not the buttons
<tseliot> weird, let me check
<tseliot> Synaptics Tap Action should disable taps while Synaptics Click Action is supposed to disable clicks
 * tseliot has a look at the code
<tseliot> Keybuk: I don't see anything wrong in the code. Can you file a bug report about it and assign it to me, please?
<Keybuk> sure
<Keybuk> which package?
<tseliot> xorg-driver-synaptics
<tseliot> xserver-xorg-input-synaptics
<tseliot> Keybuk: ^^
<Keybuk> tseliot: thanks, bug #400697
<ubottu> Launchpad bug 400697 in xserver-xorg-input-synaptics "Cannot disable touchpad buttons" [Undecided,New] https://launchpad.net/bugs/400697
<ScottK> tseliot: How about the other patch?
<tseliot> Keybuk: thanks
<Keybuk> seriously though, this Touchpad is the kind of idea that must have gone straight from concept to production without passing through a brain in between
<tseliot> ScottK: the other patch is still work in progress. I have to make sure that it doesn't break other touchpads. I'm discussing this with upstream
<tseliot> heh
<ion> What â a touchpad that sucks even *more*? Is that possible?
<ScottK> Keybuk: tseliot's patches seem to tame it a bit.
 * ScottK is no longer considering throwing his through a window.
<tseliot> hehe
<Keybuk> tseliot: is that something that might not work on Jaunty but might work on Karmic?
<tseliot> Keybuk: I'm using the driver from upstream, therefore I don't think so
<tseliot> but anyway let me try on Karmic (just in case it's a kernel issue)
<Keybuk> it was jaunty-release that I tried that xinput on
<tseliot> ok, I tried it on Jaunty + upstream's x driver and it didn't work
<tseliot> it doesn't work on Karmic either
<tseliot> wait a second that just customises left clicks
<tseliot> Keybuk: my bad. It can be done from Xinput
<tseliot> s/can/can't/
<cudev> Can someone please expand upon what "if-up.d/mountnfs [device__]: lock /var/run/network/mountnfs exist, not mounting" means?
 * tseliot should RTFM more carefully...
<tseliot> Keybuk: sorry but you'll have to use the 1st solution that I suggested :-/
<Keybuk> tseliot: what was that?
<superm1> pitti, cody-somerville so in this new gdm upload, glancing thru the changelog still no solution for having it depend on gnome-session-bin yet right?
<cody-somerville> superm1, I thought we had a solution
<tseliot> Keybuk: use the driver from upstream and type: xinput set-int-prop $YOUR_DEVICE_ID "Synaptics Area" 32 0 0 0 4000
<pitti> superm1: that was discussed this morning, and I think we have a working agreement now
<Keybuk> tseliot: but I don't want to change the touchpad area
<Keybuk> I want to turn off the buttons
<superm1> Keybuk, the buttons dont go crazy when you change that area
<superm1> they act more like normal touchpad buttons
 * ogra hands Keybuk a soldering iron
<superm1> pitti, yeah i saw some of the discussion in scrollback, it just hasn't made it into "this upload" (i'm looking for when xubuntu and mythbuntu disks can start being tested again)
<Keybuk> superm1: but that will introduce an invisible magic line inside which the touchpad works and outside which it doesn't
 * superm1 hands Keybuk a permanent marker :P
<Keybuk> superm1: I have a hammer
<ogra> heh, you will sonn have a full toolbox if that goes on :)
<ogra> *soon
<tseliot> Keybuk: maybe try with xmodmap?
<tseliot> and change the pointer map?
<Keybuk> tseliot: second Q, which package do I install on karmic to get the wireless to work?
<tseliot> Keybuk: bcmwl
<pkt> why is packagekit-udev-helper not in ubuntu? (or is it in and I missed it?)
<Keybuk> tseliot: err, that area thing doesn't work either
<tseliot> Keybuk: doesn't it ignore movements and taps in the bottom area?
<Keybuk> nope
<tseliot> Keybuk: are you using the driver from upstream?
<tseliot> today's snapshot
<tseliot> Keybuk: I've found the solution
<tseliot> type: xinput set-button-map $YOUR_TOUCHPAD 12 12 12 4 5 6 7 8 9 10 11 12
<Keybuk> ... :-)
<tseliot> the trick is to set the 1st three buttons to a higher code
<Keybuk> set the first three buttons to button 12? :)
<tseliot> yes, or to whatever you like
<tseliot> it works well here
<Keybuk> just 12 12 12 works
<Keybuk> ah
<tseliot> that too ;)
<Keybuk> no
<tseliot> no?
<Keybuk> that disables tap-to-click as well ;-)
<Keybuk> tap-to-click is now sending button 12 too
<tseliot> I guess it's the same event
<tseliot> you can test it with xev
<tseliot> back to my 1st solution then
<tseliot> again
<Keybuk> which didn't work either ;)
<ogra> some thick duct tape ?
<tseliot> Keybuk: are you using upstream's code
<Keybuk> tseliot: I'm using Ubuntu
<tseliot> Keybuk: that's a no then
<tseliot> my patch was accepted today
<Keybuk> it's in today's Ubuntu?
<tseliot> no, here: http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=7179a0eb11a842d9d5a420f5702a411b0dc217a2
<tseliot> in freedesktop, that is
<Keybuk> oh, well, if you haven't _packaged_ it ;-0
<tseliot> I can put it in my PPA
<Keybuk> this machine's used for boot performance testing - I don't want to install anything on it that's not in the official repo to avoid skewing results
<tseliot> It's pretty much like the version in Karmic + a bunch of patches
<Keybuk> exactly <g>
<tseliot> ok, I'll bug someone to upload it to Karmic next week
<tseliot> ;)
<tseliot> better?
<Keybuk> much! :D
<tseliot> ok
<mvo> Riddell: could you please add me as admin to the software-properties project page? I would like to update some stuff and it seems like you own it currently :)
<kirkland> pitti: because it came back up
<Riddell> I do?  amazing what one is sometimes
<kirkland> pitti: talked to mvo last night, and it's a dpkg/apt issue
<pitti> kirkland: hey; sorry, context?
<pitti> kirkland: ah, right, the update-motd bug
<kirkland> <pitti> kirkland: why did you reopen bug 400462 ?
<ubottu> Launchpad bug 400462 in update-motd "package update-motd (not installed) failed to install/upgrade: no package named `update-motd' is installed, cannot configure " [High,Confirmed] https://launchpad.net/bugs/400462
<kirkland> pitti: a problem with empty packages
<kirkland> pitti: so i "fixed it" by putting a file (copyright) back into the package
<pitti> heh
<pitti> that's policy anyway
<kirkland> pitti: oh, i see what you mean
<pitti> kirkland: so it needs to be fixed harder, with some preinst magic?
<kirkland> pitti: my marking it confirmed, and my upload were racing one another :-)
<pitti> ah, ok
<pitti> so it shold really be closed
<kirkland> pitti: yessir
<Riddell> mvo: only one person or team can be Maintainer of a project it seems, I can set it to you, or is there a team which would be more suitable?
<mvo> Riddell: I don't know of a team, but we can create one, I just want to link trunk to the lp:~ubuntu-core-dev/software-properties/main branch
<cjwatson> mterry: what's happening with the librelp MIR? it seems to be on your plate for a correction?
<cjwatson> (but not assigned to you - seems a bit ambiguous)
<mvo> Riddell: if you could do that, then I'm happy :)
<Riddell> mvo: done, I think
<mvo> Riddell: cool, thanks
<kirkland> pitti: thanks for going through the kvm sru feedback ;-)
<kirkland> pitti: that was a lengthy, complex set :-)
<pitti> kirkland: you're welcome
<cjwatson> evand: foundations-karmic-usb-creator-for-windows is still "not started" in LP - that isn't accurate, is it?
<evand> ah, fixing
<evand> thanks
<Keybuk> cjwatson: err, we're installing ubuntuone by default now?
<cjwatson> Keybuk: per https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus
 * Keybuk explodes with fury
<Keybuk> clearly I should just give up
<cjwatson> desktop team matter, this is the first I knew about it although of course I knew it was planned
<Keybuk> cjwatson: can I mark boot performance as an abandoned spec then?
<Keybuk> there's no point if we're adding services that take 25s to start on their own!
<cjwatson> pitti: ^-
<cjwatson> we should regard this as a critical problem with the ubuntuone packages
<cjwatson> (and, if it can't be resolved, act appropriately for new features with critical problems)
<pitti> Keybuk: 25 seconds??
<Keybuk> pitti: yup
<Keybuk> 15s seems about average though
<Keybuk> that 25s may have been competing with apt-check (another thing I'm going to get annoyed about soon)
<Keybuk> even 15s is 150% of the entire boot time
<cjwatson> perhaps we should make anacron not attempt to catch up with cron jobs until well after boot
<pitti> I didn't notice any difference, but if it's taking so much time, we should start it a minute later or so
<cjwatson> you typically don't want them to run immediately you start up anyway
<Keybuk> cjwatson: it already does back up for a while
<Keybuk> pitti: I don't consider that a fix
<pitti> well, network sync can only be so fast
<pitti> and it's not even enabled by default; but if you do, you certainly want it to work?
<Keybuk> if you enable it, and turn on sync, and have files to sync, sure, it can take as long as it likes
<Keybuk> but on a default install
<Keybuk> on the first boot
<pitti> Keybuk: anyway, would you mind filing a bug about it, so that I can channel it to OLS, etc.?
<Keybuk> when I have not enabled it
<Keybuk> and I have no account
<pitti> (sorry, I'm in meeting)
<Keybuk> and I have no files to sync
<Keybuk> it should NOT TAKE FIFTEEN SECONDS!
<pitti> Keybuk: agreed, that's a bug
<Keybuk> pitti: I've filed bug #400746 and I have subscribed the release team
<ubottu> Launchpad bug 400746 in ubuntuone-client "ubuntu one client takes too long to start" [Critical,New] https://launchpad.net/bugs/400746
<pitti> Keybuk: splendid, thanks
<cjwatson> marked rc
<cjwatson> (i.e. release-targeted)
<mterry> cjwatson, Yar, I was in the middle of updating the bug with the upstream author's comments.  he basically said not to worry, but I'm verying what he said.  I'll update the bug today
<mterry> cjwatson, (^^ above was re: librelp MIR)
<cjwatson> kees: ^-
<pitti> Keybuk: thanks for pointing out
<james_w> al-maisan: thanks for the patch
<james_w> al-maisan: I think it might not quite be correct
<al-maisan> james_w: please explain.
<james_w> if I remember correctly the _parse_error just warns if strict == False
<james_w> so you would still get an error as it did the [-1] afterwards
<james_w> (just going on memory)
<james_w> some form of "return" or something would fix that
<al-maisan> james_w: good point .. let me address that.
<james_w> thanks
<james_w> then I'll try and fight with git to commit it upstream for you
<james_w> cjwatson: I've just implemented collision handling in the importers
<james_w> no guarantees that it will work, but it will at least try and do something now rather than freaking out
<james_w> you can't create merge proposals with the API yet, so I'm filing a bug instead and I'll create the merge proposals by hand
<al-maisan> james_w: I think all it takes is an additional return statement, see http://pastebin.com/m368d17ba
<james_w> sounds about right
<james_w> thanks al-maisan
<al-maisan> james_w: thank *you*
<cjwatson> james_w: nice, thanks for the note
<james_w> I'm glad I got it done by the time LP allowed everyone to right and it became "OMG!!!"
<\sh> hmm..I have a very strange ssh client problem...I have .ssh/config setup for hosts with pubkey auth...but it looks like that ssh client sends all keys found in .ssh/id_rsa.pub to the host..and the host is telling me "too many auth errors"...which seems very wrong to me...but I could be mistaken
<\sh> s/to the host/to the host which is not configured in .ssh\/config/
<al-maisan> james_w: would you be willing to sponsor the change? Otherwise I'll start harassing mvo ;)
<maco> \sh, by default it should try id_rsa and id_dsa but ignore id_rsa.2 and such
<james_w> al-maisan: I'm committing it upstream, I'll also ask them to upload it to Debian
<al-maisan> james_w: thanks!
<maco> perhaps that host doesnt like even getting the 2 of them?
<\sh> maco: tbh, I don't have a standard id_rsa / id_dsa all keys are named differently..
<maco> oh
<cjwatson> you aren't supposed to put multiple keys in id_rsa.pub
<cjwatson> one key and one key only
<\sh> cjwatson: it isn't :)
<cjwatson> "all keys found in .ssh/id_rsa.pub"
<cjwatson> what does that mean if you don't have multiple keys there?
<\sh> cjwatson: sorry..typo
<\sh> http://paste.ubuntu.com/220653/ <- my .ssh dir
<cjwatson> anyway, use IdentitiesOnly if ssh is sending more keys than you want
<cjwatson> ssh_config(5)
<\sh> cjwatson: and what if ssh-agent is not running?
<cjwatson> \sh: don't believe it, ssh doesn't magically send extra keys unless some agent has then
<kees> cjwatson: that was for Keybuk, not me, yes?
<cjwatson> them
<cjwatson> \sh: remember that things like gnome-keyring implement the agent protocol ...
<cjwatson> kees: no - you're the assignee of the librelp MIR bug right now, and the last person to ask a question on it
<\sh> cjwatson: so..if I say to /etc/X11/Xsession.options: don't start ssh-agent, and i remove the lines in /etc/gdm/Xession which are starting the ssh-agent, too (which I don't understand) then I have still something started like gnome-keyring which does the very same thing? sounds very insane to me
<kees> cjwatson: oh! sorry, missed the context on that.
<cjwatson> \sh: don't look at me, I'm not a fan of gnome-keyring pretending to be ssh-agent either
<kees> I just wish gnome-keyring had a timeout for it's ssh-agent emulation.
<\sh> cjwatson: I don't, really...but I really wonder why we have at least to "ssh-agent" starting mechanisms (one of X11 Xsession, which is configurable) and a static "start ssh-agent when you find it on the system" in /etc/gdm/Xsession script (without somehow any configuration) (and forget gnome-keyring or seahorse)
<TwoToneSpirit_Bi> #dd-wrt
<ogra> \sh, you cant have enough security ;)
<\sh> ogra: ssh-agent is not for security, it's for lazy people to not enter their passphrase
<ogra> i know :P
<cody-somerville> it also pops up a dialogue
<cody-somerville> so you enter it into the dialogue instead of la terminal
<\sh> (actually when they do use passphrases)
<ogra> but it has ssh in the name, so it must secure something :)
<pitti> slangasek: FYI, I forwarded the cdbs python change to debian bug 537373; it can't be applied until doko uploads the experimental python2.{4,5} to unstable, though
<ubottu> Debian bug 537373 in cdbs "cdbs: Use --install-layout=deb for Python" [Unknown,Open] http://bugs.debian.org/537373
<cody-somerville> lol
<cjwatson> cody-somerville: ssh can do that itself too
<cjwatson> depending on configuration
<cody-somerville> Interesting. I didn't know that.
<\sh> cody-somerville: you enter it once, and without a sane timeout it never shows any popup again...so start your session and leave it open for a while
<cjwatson> cody-somerville: in fact, ssh-agent itself never asks for a passphrase - that's ssh-add
 * cody-somerville cuddles his seahorse.
<\sh> cody-somerville: seahorse is broken with gnupg smartcards ... so I can't use it...
<ion> sh: I have a script that starts keychain in the session, and i source it from /etc/profile, /etc/zsh-beta/zshrc and /etc/X11/Xsession.d/89keychain. Gnomeâs own ssh agent seems to break it, though. I havenât got around to investigate/fix that yet.
<ion> sh: apt-cache show keychain
<\sh> ion: the fun part is, it started this morning when I updated jaunty with the latest updates...
<slangasek> pitti: ok, thanks :)
<\sh> anyways..this identitiesonly yes works ... thx cjwatson
<fbond> Hi.  How can I find out what time a version of a package hit the archives?
<ogra> launchpad
<fbond> ogra: launchpad has many pages ... can you be more specific?
<ogra> could you ?
<ogra> :)
<ogra> which package ?
<fbond> grub
<fbond> I can see the changelog there, or course.
<fbond> But that date is not the date that the packgae hit the archive necessarily, right?
<fbond> Oh, publishinghistory, eh?
<ogra> https://launchpad.net/ubuntu/karmic/+source/grub/0.97-29ubuntu56
<ogra>     * Published on 2009-06-30
<fbond> ogra: thanks
<cjwatson> that tells you when the source was published
<ogra> right
<cjwatson> to find out for a binary, go to the build page for the binary in question, and add an hour or so to the completion time there
<fbond> I'm really trying to figure out if a grub update went out for Jaunty between yesterday and today.  I'm seeing some strange failures with update-grub in an automated build I've been working on.
<jjohansen> has anyone else hit a bug where firefox throws up several hundred help tabs and you get dozens gnome terminal help windows?
<ogra> sounds like a kbd or xinput issue
<ion> Yeah, every time i fall asleep on the F1 key
<fbond> jjohansen: Using a KVM?  USB keyboard?
<jjohansen> fbond: no
<jjohansen> no usb keyboard and KVM is not currently running
<fbond> Err, KVM switch.
<infinity> That problem is usually my cat.
<jjohansen> or in my case kids, but I have seen happen spontaneously a few times now
<infinity> cjwatson: Binary publishing history works just by swapping +source for <arch>, as in something like https://edge.launchpad.net/ubuntu/karmic/i386/libc6
<infinity> cjwatson: (ie: no need to "count an hour past of build time")
<\sh> uhohah...karmic gnome looks really great...
<sebner> \sh: karmic \o/
<dholbach> have a good time without me - see you soon again! have a great WE my friends!
<sebner> dholbach: hf! I wish you nice holidays! :)
<cjwatson> infinity: oh, nice
<dholbach> thanks sebner
<cjwatson> infinity: though you still have to add a bit as that's the start of the publisher run, but same goes for source pubs
<infinity> cjwatson: *nod*
<ogra> tsk ... 1h after publisher run ... /me learned to could 600 min after upload ... at least for the armel stuff :P
<ogra> *count
<infinity> cjwatson: I've always thought an actual file-on-disk-on-primary-mirrors (so, not on cocoplum, but on $random_archive_ubuntu_com_machine) prober that then wrote the value back to the DB would be kinda cool, but pretty heavyweight.
<infinity> cjwatson: So, publishing history would show "published at 04:32; on primary mirrors at 04:56" or something.
<cjwatson> yeah
<cjwatson> then people'd want it to probe au.archive and stuff ;-)
<ogra> infinity, could you turn that 10h timeout back to normal since it didnt gain us something a package that has the issue just effectively blocks a buildd for half a day
<infinity> cjwatson: Well, there's no sane way to implement even my pipe dream, so it ain't happening. :)
<infinity> ogra: Yeah, doing so no.
<ogra> gracias
<infinity> ogra: Done.
<ogra> thanks a lot
<ogra> i hope we'll find out what it is soon
<infinity> ogra: I'm going to try to look into it a bit first thing next week.
<infinity> ogra: Do you have a package that's a reasonably short build that exhibits the issue?
<ogra> cool, i'll make sure i'll be around
<ogra> well, mesa is the quickest i guess
<ogra> though thats still a 3-4h build
<ogra> and it only seems to show up at dpkg-deb very late in the build
<ogra> at least thats what NCommander said
<infinity> Yeah, I know vaguely when and where it happens.  Just hoping I don't have to wait all day to see it and debug it. :)
<ogra> beyond mesa most KDE packages show the issue
<NCommander> hey infinity
<ogra> i dont think there is one thats actually a fast build among the problematic ones
<NCommander> infinity, the problem usually crops up in packages that are doing lzma compression on relatively huge datafiles
<ogra> NCommander, what are you doing here, you took the day off :P
<NCommander> ogra, I felt the need to be summoned
<ogra> yeah, i'll say "michael" next time if i mention you ... :P
 * NCommander is still finding everything he needs to pack :-/
<ogra> NCommander, did you see my toying around results today ? https://wiki.ubuntu.com/ARM/BuildEABIChroot
<NCommander> ogra, I found that to be extremly unstable
<NCommander> ogra, with unimplemented syscalls everywhere when I tried it
<NCommander> if its stable for you then, maybe upstream has improved it greatly
<ogra> did you try the 20 or so patches ?
<ogra> well, i added that patchset and afaik its what OBS uses as well
<NCommander> ogra, that's very sexy :-)
<ogra> it built mesa without issues and rolls chroots just fine
<NCommander> ogra, I think you found a solution for the buildd issue
<ogra> not for production use, there are surely still missing syscalls
<ogra> but for testbuilding at home its perfectly right
<NCommander> ogra, nifty. Nice work. You could try rebuilding the base system, thats usually a pretty good environment stress test.
<ogra> i might do tht on the weekend ... though its really not the porpose to act as buildd :)
<ogra> what do you think causes the timeout issue ? i'm curious
<NCommander> ogra, no idea. We ruled out hardware and the software individually
<ogra> sorry, i'm to tired :P
<ogra> i read "I think *I* found a solution for the buildd issue"
 * NCommander starts a caffiene drip into your ARM
<NCommander> er
<NCommander> wow
<NCommander> shoot me
<ogra> heh
<ogra> nah, i should really stop for the day ... to short night, long day and i'm still chatting
 * ogra decides to do so ...
<NCommander> Indeed
 * ogra calls it a day
<cjwatson> would anyone with a karmic amd64 system like to test https://launchpad.net/~cjwatson/+archive/ia32-libs-testing, please?
<cjwatson> see the changelogs for the list of bugs it's meant to fix
<jpds> cjwatson: http://paste.ubuntu.com/220760/
<slangasek> cjwatson: sure, pulling
<slangasek> oh, or that
 * jpds ponders dist-upgrading.
<slangasek> that wouldn't help, though?
<donspaulding> ok, so I updated my jaunty box to karmic (by editing sources.list && update && upgrade && dist-upgrade), rebooted and got a grub "Error 2" message on boot.  I'm back in with a jaunty livecd, how can I mount the karmic partition in the live environment and reinstall grub?
<slangasek> karmic doesn't have libc6-i386 (>= 2.9-18), that's pending the eglibc merge
<jpds> slangasek: Oh right.
<donspaulding> or rather, how do I reinstall grub for the karmic installation from the jaunty livecd?
<slangasek> cjwatson: darn, would've been happy to test since that would fix the flash+pulse problem, but I guess we're blocked on eglibc
<jpds> donspaulding: Try #ubuntu+1 for support.
<donspaulding> jpds: ouch, sorry didn't read the topic apparently.
<A|i> who's the packman for mysql-server?
<cjwatson> jpds: drat
<cjwatson> slangasek: eglibc is in NEW, if you fancy looking it over before the end of your week :)
<slangasek> heh, I can do that. :)
<A|i> would it be safe to install mysql-server-5.1 for hardy from jaunty repo?
<slangasek> A|i: it has the general problems common to any installation of a newer package on an older system - untested, and you may have to upgrade an arbitrary number of other packages to get it to install
<A|i> slangasek, my server is 8.04, and i cannot find any mysql 5.1 repo for it :/
<slangasek> A|i: you could request a backport: https://help.ubuntu.com/community/UbuntuBackports
<slangasek> personally, I think if you're going to bypass the integration and primary security support for the packages included in the LTS in order to get a newer version of a package as significant as mysql, you might as well upgrade the system to jaunty anyway
<kees> A|i: you'd gain the default compilter flag improvements too
 * kees is a broken record.
<ScottK> A|i: I doubt we'd approve such a backport either.  mysql packaging isn't generally designed to be co-installable.  Jaunty has some changes for that, Hardy doesn't.
<A|i> ScottK, how risky would it be to upgrade to jaunty from hardy on my server?
<ScottK> A|i: Directly, don't do it.  Upgrade via Intrepid.
<A|i> oh dear
<ScottK> Hard to say for sure, but if you want 5.1, running Jaunty is your best bet.
<ScottK> A|i: You don't intend to experiment with this on a production server do you?
<A|i> ScottK, ii'm trying to install 5.1 manually, honestly it's a mess
<A|i> even uninstalling mysql-server properly doesn't work fine
<A|i> ScottK, it is a production one
<ScottK> OK.  Experimenting on production boxes is just a recipe for tears.
<ScottK> A|i: #ubuntu-server is probably a the best channel to seek help.
<A|i> ScottK, it's an amazon ec2 instance, not really for production yet
<ScottK> Ah.  OK.
<A|i> good idea
<slangasek> kirkland: hrm, why is /usr/share/doc/update-motd/changelog.Debian.gz missing?
<jpds> Is there a why I can tell debuild to ignore the @*ubuntu.com Maintainer thing?
<slangasek> jpds: it doesn't complain unless you put 'ubuntu' in the version number, does it?
<slangasek> (if it complains for non-Ubuntu version numbers, you can file a bug and demand it be fixed ;)
<jpds> slangasek: Yeah, it doesn't complain without ubuntu, but the Maintainer field is set to tha @canonical address.
<cjwatson> if DEBEMAIL doesn't contain @ubuntu.com, then it's downgraded to a warning
<cjwatson> so DEBEMAIL=jpds@someotherdomain.com debuild -S
<slangasek> jpds: maintainer fields for packages in Ubuntu aren't supposed to be set to @canonical addresses...
<cjwatson> that said it's probably silly for dpkg to complain about cases where they are
<cjwatson> the point of that warning is to try to avoid people leaving the maintainer field set to the Debian maintainer's address, which we were explicitly asked by Debian not to do when making source changes
<cjwatson> clearly not a problem for @canonical.com
 * dupondje would like to know if somebody has coding experience with nautilus, as I have some question about a bug in it, which i'm fixxing
<jpds> slangasek: Not my package (terminator)...
<ScottK> Since it's just a warning, I just ignore it in cases it's not relevant (I don't change the maintainer in cases where I'm the Debian maintainer for example).
<cjwatson> it's only just a warning because your DEBEMAIL doesn't contain @ubuntu.com
<cjwatson> I suspect from the question that that isn't the case for jpds ...
<cjwatson>                if (defined ($ENV{'DEBEMAIL'}) and $ENV{'DEBEMAIL'} =~ /\@ubuntu\.com/) {
<cjwatson>                    error(_g('Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address'));
<cjwatson>                } else {
<cjwatson>                    warning(_g('Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address'));
<cjwatson>                }
<ScottK> cjwatson: That's correct.  I don't use my @ubuntu.com address, so the warning is correct.
<cjwatson> I actually do change the maintainer even for my own packages these days, but I do that because that means queries about the Ubuntu version go to a different mailbox, which I find slightly useful
<cjwatson> but not everyone does it that way ...
 * slangasek files a fun bug on openssh
<davmor2> slangasek: is it that it's not easy to say when drunk
<slangasek> no, it's bug #400876
<ubottu> Launchpad bug 400876 in openssh "openssh-server honors .hushlogin but doesn't tell PAM" [Undecided,New] https://launchpad.net/bugs/400876
<cjwatson> ... and it's time for me to head off for the weekend, amazing how that works
<cjwatson> I can look at it on Monday if you want :)
<slangasek> sounds good :)
<slangasek> I'm not sure it's a terribly high-prio bug anyway
<slangasek> not like there are lots of people who create .hushlogin and then later decide to remove it and are going to be upset about not seeing the legal disclaimer
<slangasek> cjwatson, jpds: eglibc accepted (a bit ago) and building now, so perhaps we can test ia32-libs in a few hours
<jpds> slangasek: Groovy.
<elmo> is eglibc replacing glibc?
<cjwatson> yes
<cjwatson> it's effectively just a distribution of glibc
<cjwatson> god, I *hate* the dialog-warning sound at the moment
<cjwatson> mterry: so now that we have librelp in main (as of a few minutes ago, thanks to Kees' (tentative) signoff), I'm just about to seed rsyslog; I assume I might as well just do that rather than making you create a branch for a one-liner. :-) Any objections?
<cjwatson> mterry: http://paste.ubuntu.com/220792/
<elmo> I can't decide which upsets me more; the fact that throw-everything-away-screw-legacy keybuk is the guy as worried as me about eglibc becoming the default.  or the fact that eglibc is becoming the default
<elmo> cjwatson: did they stregthen any of their API/ABI guarantees?
<mterry> cjwatson, heh, actually I already did make the one-liner branch, but yeah, that'd be great (though you're patch isn't keeping the sort order!)  :)
<cjwatson> verbally at least; the reason they don't give a strong one on the website is that they obviously aren't ABI-compatible if you disable option groups (facility provided by eglibc). We aren't doing that though, and they said they have zero interest in breaking ABI if you leave all the option groups on, and lots of pressure not to
<cjwatson> if they add any interfaces of their own they'll use EGLIBC@blah versioned symbols
<cjwatson> mterry: oh, let me grab that then
<elmo> cjwatson: that still means we risk binaries that run on ubuntu/debian but not e.g. fedora, suse, though, right?
<cjwatson> mterry: bleh, seeds are at best inconsistently sorted anyway :)
<cjwatson> I think it's extremely unlikely
<mterry> cjwatson, really the same thing, but here:   lp:~mterry/ubuntu-seeds/platform.karmic-rsyslog
<cjwatson> I don't think they're remotely interested in doing that; if I catch a whiff of that I'll take action
<kees> there, AppArmor now loads in under a second.  that should make Keybuk happy.  :)
<mrooney> Hey, can anyone point me to the wiki page for package-specific upload rights? I'm trying to figure out if it is for me
<cjwatson> (and it should be easy to check simply by seeing if any binaries use EGLIBC@ symbols
<cjwatson> )
 * elmo wanders off to practice his 'told you so' dance, just in case ;-)
<mterry> elmo, you should really have that locked and loaded already
<cjwatson> elmo: frankly I think we'll be considerably worse off if we have to maintain glibc ourselves without reference to Debian's packaging
<jdstrand> kees: awesome!
<cjwatson> mterry: ok, merged that, thanks
 * cjwatson ponders the wisdom of a Friday evening ubuntu-meta upload
<mterry> cjwatson, thank you.  I was worried I'd have to file a bug or harass someone
<cjwatson> what could POSSIBLY go wrong
<mterry> cjwatson, :)
<ScottK> cjwatson: Nothing as long as you stay offline until Monday.
<cjwatson> mterry: I assume we'll probably want to seed some of rsyslog's plugins as supported somewhere
<cjwatson> or something
<kees> jdstrand: just a few growing pains.  though your "it didn't cache anything" issue freaked me out.
<mterry> cjwatson, hmm, you mean install some plugins by default?
 * kees will pay money to see elmo's 'told you so' dance.
<cjwatson> mterry: no, supported just means they go in main
<mterry> cjwatson, right, but you said 'seed' and I got confused
<cjwatson> the way it is at the moment, the maintenance scripts will be prompting us to put rsyslog-mysql etc. back in universe
<cjwatson> supported is a seed ...
<mterry> cjwatson, ah ah.  :)
<cjwatson> not all the seeds are used for what's installed by default :)
<jdstrand> kees: :)
<cjwatson> (in fact, supported was one of the first three seeds)
<cjwatson> (but it probably wouldn't actually want to go in supported, maybe server-ship or something)
<cjwatson> or dvd or ... whatever
<mterry> cjwatson, hmm
<cjwatson> no rush, it won't fall out of main without manual action anyway
<cjwatson> oh, blah, rsyslog needs to have its priority bumped before ubuntu-meta/update will pull it in
 * cjwatson remembers about the weird special cases
<cjwatson> mrooney: https://wiki.ubuntu.com/UbuntuDevelopers#Per-package%20Uploaders
<mrooney> cjwatson: that sounds perfect, thanks :)
<cjwatson> StevenK: so is UNR all meant to be in main now? if so, I need to adjust component-mismatches
<agent_j> i'm trying to package a game, but it doesn't work. do i compile the game and then make the package, or do i just make the package without compiling first?
<cjwatson> your 'debian/rules build' ought to do any compilation required
<ScottK> agent_j: #ubuntu-motu is a better channel for basic packaging questions.
<agent_j> ok sorry
#ubuntu-devel 2009-07-18
<slangasek> jpds: eglibc/amd64 in accepted
<slangasek> s/accepted/done/
<slangasek> cjwatson: your alsa-plugins ppa upload conflicts with a same-versioned upload in karmic
<jpds> slangasek: All installed, how do I check that what ever was broken is fixed?
<slangasek> jpds: well, flash+pulseaudio is one; if you can play sound through the 32-bit sound plugin when other pulseaudio apps already have the sink open, then that's fixed
<slangasek> that's the one I'm interested in personally; but presumably if you're an ia32-libs user, you have other things you can do to regression test?
<slangasek> cjwatson: the new ia32-libs doesn't seem to contain /usr/lib32/alsa-lib/libasound_module_pcm_pulse.so AFAICS
<StevenK> cjwatson: Yup, that was the plan, for UNR to be in main.
<ashbringer> Is this the right channel to ask questions about configuring debian-installer? I'd like to add packages to be installed by default on the alternate CD, and I've followed the tutorial on the wiki to generate a repository I've tested and know to be installable-from, but for some reason the pgksel/include lines in the preseed file aren't being adhered to or something. What exactly do I need to do to get extra packages installed?
<hile> hmmh noticed that on karmic ca-certificates-java fails, if you have additional internal certs in ca-certificates.conf, or maybe it does not like the key format?
<hile> keytool error: java.security.NoSuchAlgorithmException: SHA384withECDSA Signature not available error adding
<hile> nevermind already reported, bug 392104
<ubottu> Launchpad bug 392104 in ca-certificates-java "[Karmic] Update to ca-certificates 20090624 prevents ca-certificates-java from installing" [High,Fix released] https://launchpad.net/bugs/392104
<hile> except the report claims it's fixed in 20090629 but I saw the bug today in this version
<alex-weej> can we add something to launchpad t
<cjwatson> slangasek: ok, I'll rev alsa-plugins
<alex-weej> *that detects if a user is marking a bug incomplete with that stupid stock message "we were wondering..." and punches them in the face
<cjwatson> slangasek: IMO lib32asound2-plugins ought to ship /usr/lib32/alsa-lib/libasound_module_pcm_pulse.so, surely?
<slangasek> cjwatson: it's built from pulseaudio source, not alsa-lib source
<cjwatson> libasound2-plugins: /usr/lib/alsa-lib/libasound_module_pcm_pulse.so
<alex-weej> about 3 years ago i went round reporting /lots/ of minor bugs that have never been fixed
<alex-weej> and idiots keep making me reconfirm them every release
<cjwatson> ... not here?
<slangasek> cjwatson: oh.
<slangasek> cjwatson: then... building it from alsa-lib source would make a circular build-dep, but I guess that's ok
<cjwatson> alsa-plugins actually
<cjwatson> oh, I think the problem is that pulseaudio doesn't have a biarch build, so alsa-plugins can't build that module
<cjwatson> so, um ... should I arrange to copy just *some* files from libasound2-plugins into ia32-libs, but not others?
<cjwatson> StevenK: ok, added to component-mismatches, we'll see what happens
<ogra> wow, did anyone try to listen to mp3's in karmic yet ?
<ogra> mine play at double speed and are pretty jumpy here
<Laney> what media player?
<ogra> i tested all gstreamer based up to now, RB, banshee, totem ...
<ogra> same with mplayer
<ogra> sounds like a CD with a crack
<Laney> no problems here :(
<ogra> hmm, intresting, xine has no output at all
<Laney> tried killing pa?
<Laney> killall pulseaudio, I mean
<ogra> ah, upgrading and reboot helped
<Laney> aha
<ogra> nah, i wouldnt be that evil to my soundserver :)
<Laney> flash demands I do it quite often
<ogra> works fine here
<Laney> better so far in karmic than it was in jaunty, but I still have to do it every now and again
<ogra> weird
<ogra> hmm, i wonder if there is a way to make gnome-terminal pick up the shell prompt while i'm in a chroot
<ogra> it always only shows the last dir i'm in ... given that all my chroots are in the same dir the terminals all have the same title
<ogra> Keybuk, shouldnt dbus pick up if i'm running it in a chroot (like hal does) and not try to start ?
<ogra> Adding new user `messagebus' (UID 103) with group `messagebus' ...
<ogra> Not creating home directory `/var/run/dbus'.
<ogra> invoke-rc.d: initscript dbus, action "start" failed.
<ogra> ...
<ogra> meh... indeed i didnt have proc mounted, ignore me
<scizzo-> hello, I was wondering..I am going through some of my old bug reports and was wondering about a 1 year old bug I commited. There is none assigned to it but is confirmed. What would actually be the best way to ask for confirmation from the various systems of that bug report? That is (hardy, gutsy, jaunty and karmic etc)?
<Ampelbein> scizzo-: can you tell us the bug number? maybe it's an upstream bug and needs to be reported to the developers of the software.
<scizzo-> Ampelbein: one second
<scizzo-> https://bugs.launchpad.net/ubuntu/+source/apt/+bug/181843
<ubottu> Ubuntu bug 181843 in apt "[hardy] apt-get doenst ask confirmation" [Undecided,Confirmed]
<scizzo-> Ampelbein: thank you
<Ampelbein> scizzo-: the last comment on that bug requests confirmation if the issue still exists. that is the correct way. Additionally, the report should be set to "Incomplete" while waiting for confirmations.
<scizzo-> Ampelbein: yes I added a comment to it to try and get confirmation if this issue still exists
<scizzo-> since I myself am not having the issue anymore however someone else might have come across it
<Ampelbein> scizzo-: so you have done the right thing. If there is no more confirmation for ~4 weeks you can safely close the report.
<scizzo-> Ampelbein: sounds good
<scizzo-> Ampelbein: thanks again
<Ampelbein> scizzo-: you're welcome.
<ogra> mumble, was rsyslog seeded buut not promoted yet?
<ogra> damned and i was this >< close to have armel ltsp client setups working
<ogra> hmm, oh, ok, -meta was only uploaded this morning
<ogra> then i wonder why debootstrap isntally the minimal deps differently
<ogra> *installs
<WanderingKnight> hey there
<WanderingKnight> I think I'm seeing a leak in X
<ogra> put a bucket under it :)
<WanderingKnight> xD
<WanderingKnight> on Kubuntu 9.04 amd64, using nvidia driver
<WanderingKnight> with kwin effects on
<WanderingKnight> on idle, after a couple of days, /usr/bin/X is taking up over 600 MB of RAM
<WanderingKnight> and swap usage is of 400 MB
<ogra> well, best is to file a bug, though if its in the binary nvidia driver itself its quite unlikely someone apart from nvidia could fix it
<WanderingKnight> yeah :/
<jpds> WanderingKnight: Have you tried using the nouveau drivers by any chance?
<WanderingKnight> nope, I need 3D
<ScottK> No one NEEDS 3d.
<ogra> 3D graphics designers do :)
<ogra> and probably game developers ...
<chrisccoulson> you'll need 3d when we eventually have to run gnome-shell (unless someone decides that it would be sensible to have a fallback)
<chrisccoulson> (of course, if you're running gnome)
 * ScottK isn't.
<ScottK> lool: Around?
 * chrisccoulson wishes git wasn't so hard to use
<ogra> dont use it ;) LP can import git trees
<chrisccoulson> ogra - i could try that i suppose. but sometimes if you write big patches in gnome, they prefer to review the work in a git branch
<ScottK> ogra: Also (last I heard) only head, not branches which is very limiting.
 * ScottK would love to import pkg-clamav git, but it's the packaging branch I care about ....
<c_korn> setup.py usually installs libraries of packages to /usr/lib/python2.6/site-packages/ but then the application cannot find it. what is going wrong here?
<hile> for reasons I don't understand the python uses dist-packages, site-packages is not on path
<c_korn> hile: ok, thanks
<hile> better look for the guides and reasoning behind this change so that you do things right with it (something to do preventing package updates messing up with manually installed ones)
<hile> maybe it was to allow compiling a python version manually, which would use dist-packages as usual, and the packaged one could exist same time, something like that?
<hile> anyway, there are good reasons, I guess you can find the docs by googling 'dist-packages python' or similar
<c_korn> seems to be fixed in karmic: lp 'dist-packages python'
<c_korn> oops
<c_korn> lp 362570
<ubottu> Launchpad bug 362570 in python2.6 "Python distutils installs into 'site-packages' instead of 'dist-packages' when a prefix is set" [Wishlist,Fix released] https://launchpad.net/bugs/362570
<ogra> cjwatson, dont we need to drop Priority: important from sysklogd and klogd ?
<ogra> wohoo !!! stgraber, i just built my first armel thin client !!
 * ogra commits the code changes to ltsp
<ScottK> ogra: ltsp is going to need changes for rsyslog if they aren't done already.
<ogra> why should it need any changes
<ScottK> ogra: I don't recall the details, but there were some ltsp specific changes in or ksyslogd package.
<ScottK> or/our
<ogra> there was a special case in the initscript to override /etc/default/syslogd
<ogra> given /etc/default/syslogd vanishes with syslogd users should simply use the /etc/default file of rsyslog so we dont have anything non-standardish again
<ScottK> OK.
<ogra> its more a documentation issue than a code change
 * ScottK nods.
<stgraber> ogra: yeah !!! you can boot them as thin client now ? you still don't have PXE equivalent right ?
<ogra> no, but the imx51 boards have redboot in flash
<ogra> i will need o work out the right runes for tftp'ing kernel and initramfs, then it will just work
<stgraber> ogra: nice
<ogra> i really didnt expect the changes to be that trivial, was really nice to discover that
<ogra> and i found an upstart induced bug :)
<Xodiac13026> i am trying to get ubuntu to install on my desktop for some reason it wont read it or read it here and there when i load up xp it has no problem loading it how can i install ubuntu
<Xodiac13026> ?
<Xodiac13026> can anyone please help me
<Xodiac13026> hello
<Simira> Xodiac13026: this is not a support-channel. Try #ubuntu-help our your community channel
<Xodiac13026> well all the other support channels wont help me so if you could take to them that would be appreciated
<Xodiac13026> theres only like 7 people in it and im on my laptop with windows xp
<Xodiac13026> trying to install to my desktop
<ScottK> Simira: The support channel is #ubuntu, not #ubuntu-help.
<Simira> ScottK: oh, sorry. I thought they were redirected because of the workload...
<ebroder> Any backporters around that could ACK bug #216761? I promise I'll leave people alone about this one once it gets backported :)
<ubottu> Launchpad bug 216761 in xen-3.3 "[hardy-backports] errors in xendomains init script" [Undecided,Fix released] https://launchpad.net/bugs/216761
#ubuntu-devel 2009-07-19
<lidaobing> hello, how to register a bug tracker? I want to register http://code.google.com/p/ibus/issues
<dmb> is there a way to see why a kernel paniced?
<dmb> after rebooting the system?
<dmb> or even a way to see why a kernel panics while its happening, when x is running?
<lidaobing> dmb, kerneloops package maybe can help you
<dmb> hmm, don't know if i could reproduce the issue
<Ampelbein> lidaobing: as far as i know, code.google.com has no public API so there is no bugtracker for it.
<lidaobing> Amaranth, but I can found some already registered bug tracker when I edit the project detail of ibus, which exist in a select box near the "Bug are tracked" label.
<andresmujica> bug 78395
<ubottu> Launchpad bug 78395 in malone "Support bug watches against Google Code's issue tracker" [Medium,Fix released] https://launchpad.net/bugs/78395
<lidaobing> andresmujica, sounds supported, but do you know how to use it?
<Ampelbein> andresmujica: thanks, i didn't know that this "works" now.
<Ampelbein> lidaobing: what bug do you want to link? or do you want to link a project to this tracker?
<andresmujica> let me see...
<andresmujica> check bug 365730  i've used it there
<ubottu> Launchpad bug 365730 in pychess "pychess can't be started" [Low,Confirmed] https://launchpad.net/bugs/365730
<andresmujica> https://edge.launchpad.net/bugs/bugtrackers/
<andresmujica> where you can add the new bugtracker...
<lidaobing2> found how to register a new bug tracker: https://launchpad.net/bugs/bugtrackers
<ebroder> What's the best way to query against package information for foreign architectures? packages.{debian.org,ubuntu.com} just isn't doing it for me
<cjwatson> ogra: sure, just couldn't do it at the same time as promoting sysklogd for various reasons - don't worry, we have automatic reports for this stuff
<cjwatson> ogra: (done now)
<ogra> cjwatson, thanks, took me a while to find out whats wrong, but i got along with --exclude in debootstrap then
<Manu123> hi
<Manu123> i build and install a package with dkms and at the install soources are not found
<Manu123> http://paste.ubuntu.com/221954/ make.og
<Manu123> thx for help
<jacquesdupontd> hi guys
<Manu123> hi
<jacquesdupontd> i come here to see if there's any knew clue to have full 3D acceleration with old ati card on jaunty ?
<jacquesdupontd> maybe a patch or something
<jacquesdupontd> anybody here ?
<ion> Nope
<maxb> jacquesdupontd: Since ATI/AMD have killed support, your only option is to see if either of the open source drivers are good enough
<Laney> psh
<Laney> my card isn't that old and ATI dropped support for it
 * Laney shakes fist at them
<maxb> Yeah, I have one of those cards too. Sucks. But on the plus side radeon oss driver is driving it quite nicely onw
<maxb> good enough for DVD watching, so I'm happy
<Laney> at least the metacity compositor works
<maxb> as does compiz
<Laney> really?
<Laney> it just tells me it can't be enabled
<maxb> radeon, or radeonhd ?
<maxb> compiz sulked last time I tried to make it work with radeonhd
<jacquesdupontd> maxb, thx for answering the thing is that i'm counting on open source drivers since they are really better than propriety drivers and for sure they are good enought i have compiz fusion working perfectly but i can't play some games that a bit annoying cause i like to play warsow for exampe and i've heard that some patches were aailable thats why im here to ask
<Laney> xserver-xorg-video-ati and xserver-xorg-video-radeon
<jacquesdupontd> yes i'm on them right now
<Manu123> http://paste.ubuntu.com/221967/ detailed error mess. at install
<Manu123> does anybody know what i have missed in the config proces?
<bluefoxicy> so here's a thought
<bluefoxicy> with multiple monitors, what does Ubuntu do?
<bluefoxicy> If I put a window on monitor 1, and another on monitor 2, do I get 2 blank monitors when I switch to another virtual desktop?
<azeem_> it's a question, not a thought
<bluefoxicy> I'd rather have an option to use independent virtual desktops.
<bluefoxicy> so let's say I have two monitors, 1024x768
<bluefoxicy> instead of having one 2048x768 workspace per virtual desktops, I want to put the mouse in monitor 1 and select desktop 7, and then in monitor 2 select desktop 4
<bluefoxicy> This seems to make more sense to me.  I'm pretty sure I'm the only person in the world that thinks this way.
<geser> I'm not sure but you aren't able to move applications between the monitors anymore then
<bluefoxicy> geser:  so modify metacity to be multi-monitor aware and pop the apps across virtual desktops
<bluefoxicy> then I could shift one monitor to another desktop, grab a window, and pull it over.
<geser> it seems to be (partly) aware of several monitors as I can maximize applications and they're only maximized on one monitor
<bluefoxicy> yeah
<bluefoxicy> but if you switch desktops,it switches both monitors, right?
<geser> yes
<bluefoxicy> this is not useful to me :)
<bluefoxicy> what if I have web browser on the right, e-mail on the left
<bluefoxicy> and now I pull up my bank site on the browser, and I want my accounting on the left?
<geser> I'd prefer it too when both monitors had seperated workspaces
<bluefoxicy> I hve to bring gnucash from another desktop, or put it on top the e-mail window, or something.  I can't just switch to the desktop it's on, in the left monitor.
<bluefoxicy> also if you're using GIMP, and want to keep multiple toolbox windows (?!) or multiple image windows together, but uncluttered, you could use different desktops and swap them individually.  Mix and match.
<geser> what seems to be missing is seperate workspaces for each monitor
<bluefoxicy> yes.
<forester> Sorry if this is off topic, but I'm having trouble finding a solution. I'm using xforwarding on ubuntu server 9.04 and get several lines of "Xlib:  extension "Generic Event Extension" missing on display "localhost:10.0"." every time I start a program. Anybody, know how to fix this problem?
<johanbr> tkamppeter, just thought I'd let you know that the pdf conversion problems I had with cups were due to the somewhat strange printer setup at work (printing to an old-style lpd daemon)
<johanbr> hacking the ppd to make cups prefer a pdf passthrough filter made everything work as expected
 * DktrKranz hugs pitti for solang upload
<tkamppeter> johanbr, OK, but can you send me the original PostScript file anyway, only to have a test file for the filters? Thanks.
<mgran> Hi, I'm trying to compile the open-source version of 0 A.D. (http://trac.wildfiregames.com/wiki/BuildInstructions) and it depends on a 'multi-threaded/thread-safe' spidermonkey build. Is the xulrunner package thread-safe, suitable to be used as a dependncy, or should I build my own THREADSAFE=1 spider-monkey from http://ftp.mozilla.org/pub/mozilla.org/js/js-1.60.tar.gz?
<simon-o> mgran: cool that's a great idea. You'll get compiler warnings if you have the single-threaded version of Spider-Monkey
#ubuntu-devel 2010-07-19
<Burgundavia> akgraner: ping
<akgraner> pong
<akgraner> Burgundavia, hey - just segway me into the conversation and I'll give you a rundown :-)
<lamont> what package has the "make me a bootable usb stick out of $THAT iso?" mad skilz in it?
<wgrant> lamont: usb-creator
<lamont> ta
<lamont> google had just about gotten me there, once I thought to look harder
<lamont> "... is the most advanced tool available able to make ..." <-- clear reason to relegate that package to universe
<lamont> [1]+  Segmentation fault      usb-creator-gtk
<lamont> hrmpf
<lamont> https://help.ubuntu.com/community/EncryptedFilesystemLVMHowto <-- /me thanks people for writing up things to make manual silliness easier.
<wgrant> lamont: Why not just use the automated options on the alternate/server CDs?
<lamont> wgrant: machine kinda lacks a CD, and I kind of lack a USB CD, and usb-creator doesn't belive in alternate CDs
<wgrant> lamont: Hm, odd. I thought that was meant to work.
<lamont> well, once I get this happy, I get to deal with dueling boot loaders, so I forsee an imaging or two of the hard drive before all is happy
<Arkaniad> Not fully sure if this is the place to ask this, but I might as well shoot. I'm trying to compile some C programs, namely ncurses. After struggling and thinking that I was missing an installed library and installing all of the ncurses-related packages, I found a larger problem: GCC, netbeans, ld etc don't know where to find the header or library files! what do I do to fix it?
<TheMuso> Arkaniad: is there any particular reason you want to build ncurses?
<Arkaniad> TheMuso: Well, considering that Java is my strongpoint, I just want to try other things. NCurses seems trivial and simple to do things, and I don't want to get into high-end GUI programming quite yet.
<Arkaniad> But the same thing happens when i try gtk.
<Arkaniad> I try going by #include<gtk/gtk.h>
<Arkaniad> But that doesn't work. Unresolved references. (I meant include <)
<Arkaniad> So it causes problems with everything
<Arkaniad> I can do #include <absolute path to header.h>
<Arkaniad> But then if the header references any other headers it goes kaput.
<Arkaniad> So as you can see, it's sort-of a showstopper.
<Arkaniad> So yeah.
<nigelb> geser, persia, soren: ping.  Can you send a list of people who have been granted ubuntu membership via dmb to the news-team so we can publish it?
<nigelb> We seem to be mising members coming from dmb
<hyperair> what was that kernel option that allows you to stop the initrd in its tracks?
<SwedeMike> hyperair: https://help.ubuntu.com/community/BootOptions
<hyperair> SwedeMike: thanks
<pitti> Good morning
<geser> Guten Morgen pitti
<pitti> hey geser
<wgrant> pitti: The logic in pkgstriptranslations scares me... you know that we can implement stuff in LP so you don't have to grep sources.list and apt-cache madison output, right?
<pitti> wgrant: right, that bug was filed, and it's now on the soyuz' team's work list
<pitti> wgrant: if it's any consolation, it scares me as well; we discussed it quite a bit before, and I think it's a "good enough" workaround for now
<slangasek> james_w, lifeless: if someone misses a --fixes when doing a commit, is there an interface for adding this metadata after the fact?
<james_w> slangasek: no, it is stored as a revision property
<slangasek> ok
<slangasek> lool: ^^
<slangasek> james_w: thanks :)
<james_w> slangasek: so it's either "uncommit" or "commit --unchanged --fixes"
<james_w> everyone acknowledges that it's not ideal that the interface for this is so narrow
<ccheney> slangasek: do you happen to know what the proper way to provide configuration for a package (say approx) in another package (uec-provisioning-mirror)?
<ccheney> slangasek: is there a way to do this programatically? or should it just provide a document in eg README.Debian telling the user what to do?
<ccheney> cjwatson: any ideas about what i asked slangasek above? :)
<cjwatson> ccheney: if you're working on another package's configuration file, then that other package has to cooperate, for example by providing a way to include configuration from a directory
<cjwatson> there's no policy-compliant way to override a package's configuration file in another package
<slangasek> ccheney: mmh, there's no generic way to do this without cooperation... ok I'll let cjwatson field this one ;)
<ccheney> cjwatson: ah ok, yea i know you could do a replaces but that is pretty bad idea
<ccheney> thanks guys :)
<cjwatson> yeah, if you try that then things will likely break the next time approx is upgraded
<cjwatson> or at least if it changes its copy of the file
<cjwatson> I suspect the behaviour is undefined then
<ccheney> ok
<ccheney> in approx case there is no default configuration so adding one for it might be useful, but its good to know the general case the package whose configuration you want to change needs to be the one to do it
<ccheney> for approx it has an example configuration file but its not set up to actually mirror anything by default
 * ccheney isn't sure whether changing approx in ubuntu is worth the delta though
<tumbleweed> ccheney: isn't apt-cacher-ng configured out the box?
<nigelb> james_w: fixing it onces it lands on LP is okay too? through the merge interface...
<james_w> nigelb: sorry, I don't understand?
<nigelb> james_w: er, missing --fixes
<mantiena-baltix> Hello all
<mantiena-baltix> I'm looking for Ubuntu 10.04.1 testing CD images, should I use these - http://cdimage.ubuntu.com/lucid/daily-live/current/ ?
<nigelb> yep, as the title says Ubuntu 10.04.1 LTS
<mantiena-baltix> nigelb: according to build logs these images contains packages from lucid-proposed repository, is this ok?
<mantiena-baltix> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/lucid/ubuntu/current/livecd-20100719-i386.out
<nigelb> im not sure, but I would suggest asking in #ubuntu-quality to confirm
<mantiena-baltix> nigelb: ok, thanks
<james_w> nigelb: you can add it at any time
<quadrispro> hi guys
<ccheney> tumbleweed: will have to take a look
<ccheney> tumbleweed: does it work well? a year or so ago when i tested out the various proxy/mirror scripts it seemed all were broken but approx
<tumbleweed> ccheney: my view is that all are broken except acng :)
<ccheney> tumbleweed: ok :) well if it actually works at all then its probably not broken :)
<tumbleweed> heh, yes. Before that I used squid, which also works well, but not as efficient
<smoser> cjwatson, can  i get some of your time today or tomorrow ?
<cjwatson> smoser: yes
<smoser> time that works best for you ?
<cjwatson> smoser: this afternoon is fine
<smoser> good deal. thanks.
<pitti> ev: I just replied to https://code.edge.launchpad.net/~ev/ubuntu/maverick/jockey/auto_install/+merge/30079, FYI
<ev> cool, thanks
<ev> okay, I'll make those changes
<pitti> ev: are you interested in writing a test case yourself?
<ev> pitti: sure, should be straightforward enough
<pitti> right
<tkamppeter> pitti, SRU uploaded for bug 576705.
<ubottu> Launchpad bug 576705 in gutenprint (Ubuntu Lucid) "Epson inkjet printer does not work on 10.04" [Medium,Fix committed] https://launchpad.net/bugs/576705
<pitti> tkamppeter: I saw, will do some queue action tomorrow morning
<pitti> thanks!
<Fazer2> hey, I have a problem with creating a DEB package for my Qt app
<Fazer2> I followed this tutorial - https://wiki.kubuntu.org/PackagingGuide/QtApplication
<Fazer2> but after  debuild -S  I get lots of errors and it fails
<Fazer2> I think the problem lies in debian/rules file, which I copy-pasted from the site
<Fazer2> I think I should modify it, but I don't know how
<Fazer2> the log is here - http://codepad.org/eBhgagFR
<micahg> Fazer2: try #ubuntu-packaging
<Fazer2> micahg: thanks
<geser> any archive admin around who could move gcj-native-helper from universe to main on i386? for all other archs the package is already in main but not for i386
<Riddell> Fazer2: did you get sorted?
<Riddell> geser: please file a bug, I'll get to it tomorrow
<Fazer2> Riddell: sorted? what does that mean?
<Riddell> Fazer2: did you get your packaging done?
<Fazer2> Riddell: I've read irc logs from your packaging sessions
<Fazer2> Riddell: no, I still have problem
<Fazer2> Riddell: I went to #ubuntu-packaging and yofel adviced me to use /usr/share/doc/debhelper/examples/rules.arch instead of the one from https://wiki.kubuntu.org/PackagingGuide/QtApplication
<Fazer2> Riddell: thanks to it debuild -S works now, but pbuilder build fails
<Riddell> Fazer2: what about just using debuild to compile the package?
<Riddell> Fazer2: also can you pastebin your debian/rules ?
<Fazer2> Riddell: ok, wait a sec
<ion> fazer2: Iâd use neither. A dh7-style debian/rules is nicer.
<ion> /usr/share/doc/debhelper/examples/rules.tiny
<Riddell> ion: let's not get distracted
<Fazer2> Riddell: http://codepad.org/JTVo6qmd
<Fazer2> Riddell: I changed the rules file now (I commented #$(MAKE) again) and now debuild command created the package
<Fazer2> Riddell: I mean, that lines with #${MAKE} were commented, when I removed the comments it didn't work, so I reverted it
<Riddell> Fazer2: how do you compile and install the application normally (when not packaging it)?
<Fazer2> Riddell: qmake-qt4 -config release
<Fazer2> Riddell: then make
<Fazer2> Riddell: I guess I should add make command XD
<Riddell> yes
<Fazer2> Riddell: because I can see the produced package doesn't include any binary
<Riddell> and  make install ?
<Fazer2> ok
<Riddell> Fazer2: add the make install under "Add here commands to install the package"
<Riddell> Fazer2: it'll need that prefix bit though to install it into debian/<package>/usr
<Riddell> you don't want to install it to /usr
<Fazer2> Riddell: ok, retrying now
<Riddell> Fazer2: with debuild ?
<Fazer2> Riddell: yes
<Riddell> good luck
<Fazer2> Riddell: so debuild does almost the same thing as debuild -S && sudo pbuilder build *.dsc, right? only that pbuilder builds in a clean environment
<Fazer2> Riddell: I still have no binaries shipped in the package... I'll show you the rules file - http://codepad.org/5PzsNkj6
<Riddell> Fazer2: right, but with pbuilder it's harder to fix mistakes and continue on, with debuild you can  use debuild -nc (no clean) and carry on without having to recompile everything, so I only use pbuilder as a final check
<Riddell> you don't need that first "make install
<Fazer2> Riddell: I also added these lines to my .pro file, as adviced in the Qt packaging guide - http://codepad.org/0VhzYZx8
<Fazer2> Riddell: should I remove it or move somewhere else?
<Riddell> just remove it
<Riddell> pastebin the .build file (in the directory above the sources)
<Fazer2> Riddell: I'll run it again with LANG=c, because it's in Polish now
<geser> Riddell: you can setup a pbuilder hook to drop you into a shell in case of FTBFS (see /usr/share/doc/pbuilder/examples/C10shell for an example)
<Fazer2> Riddell: http://codepad.org/goJWn0Sg
<Riddell> geser: faff :)
<Fazer2> Riddell: looks like I should do that with sudo
<Fazer2> Riddell: or shouldn't I?
<Riddell> "install: cannot create regular file `/usr/bin/huffman-coding-visualizer': Permission denied
<geser> my guess: the makefile don't care about the prefix value
<Riddell> the prefix isn't working on that make install command
<Riddell> Fazer2: so alternative approach..
<Fazer2> Riddell: would be...
<Riddell> comment out the "$(MAKE) prefix=..." line
<Riddell> uncomment the dh_install
<Riddell> line
<Fazer2> ok
<Riddell> and make a file   debian/install
<Riddell> it should contain the file you want to copy and the place it should be installed to
<Riddell> "huffman-coding-visualizer usr/bin/"  for example
<Riddell> assuming the huffman-coding-visualizer binary is in the top source directory
<Riddell> you can use  debuild -nc  to rebuild without compiling again
<Fazer2> Riddell: so the debian/install file content should be just that one line, right? - huffman-coding-visualizer usr/bin/
<Riddell> Fazer2: right
<Riddell> assuming that's the only file you need installing
<Fazer2> Riddell: right now, the only one; btw shouldn't it be /usr/bin and not usr/bin ?
<Riddell> no don't think so
<Fazer2> Riddell: ok, now the package contains the binary, I'll try to install it
<Fazer2> Riddell: it works :-)
<Fazer2> Riddell: I think I'll manage to do the last thing - add compiling a translation and installing it
<Fazer2> Riddell: thanks for the help! :-)
<Riddell> Fazer2: great
<Riddell> Fazer2: is the package something we should include in the ubuntu repository?
<Fazer2> Riddell: heh, it's a simple app made as a school homework
<Fazer2> Riddell: it presents how static and dynamic Huffman coding works
<Fazer2> Riddell: I think I'll add it to my PPA
<Riddell> that was going to be my next suggestion
<Fazer2> ;-)
<Riddell> Fazer2: of course now you know packaging you can help out with Kubuntu or MOTU or any of the teams :)
<Fazer2> Riddell: I just started and you want to recruit me so quickly? :-P
<Riddell> no time like the present
<Riddell> although at present I need to sleep
<maxwellian> Riddell: Silly question, but just to be sure: debuild -nc will stil recompile whatever needs to be recompiled based on source changes, right?
<dupondje> I guess we will merge the newest php version that got in debian today ? ^^
#ubuntu-devel 2010-07-20
<ari-tczew> please some main sponsors review bug, whether it can by synced or merged, thanks
<ari-tczew> bug 604802
<ubottu> Launchpad bug 604802 in commons-io (Ubuntu) "Merge commons-io 1.4-3 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/604802
<mantiena-baltix> morning all
<mantiena-baltix> Ubuntu 10.04.1 images from http://cdimage.ubuntu.com/lucid/daily-live/current/ contains packages from lucid-proposed repository, is this ok?
<mantiena-baltix> AFAIK it's a bug, but I don't know where I should report this bug :(
<Riddell> maxwellian: yes debuild -nc will still recompile whatever needs to be recompiled, it just doesn't run make clean
<twb> slangasek: ping
<Damascene> hi,
<twb> slangasek: in /usr/share/pam-config/foo on lucid, I can say "Session-Final:\nfoo", but not "Session-Final: foo".  That's a little annoying/unexpected.
<Damascene> asac, Bug #603022
<ubottu> Launchpad bug 603022 in mlterm (Ubuntu) "[MIR] mlterm" [Undecided,New] https://launchpad.net/bugs/603022
<Damascene> would you like to talk about the bug?
<asac> Damascene: no thats fine from what i understand
<pitti> Good morning
<asac> hi pitti
<\sh> hoi pitti, asac
<pitti> hey \sh
<pitti> hello asac
<asac> moin \sh ;)
<bdrung> crimsun_: can you unsubscribe ubuntu-sponsors when you sponsor a bug? bug #581786 seems to be sponsored.
<ubottu> Launchpad bug 581786 in ardour (Ubuntu Lucid) "Mute button not enabled by default in Ardour 2.8.6 Lucid AM64" [High,In progress] https://launchpad.net/bugs/581786
<bdrung> crimsun_: i can't see your upload to -proposed. so it's up to you to unsubscribe ubuntu-sponsors.
<smoser> Keybuk, could you look at upstart script branch in bug 43574 (not urgent at all)
<ubottu> Launchpad bug 43574 in xinetd (Ubuntu) "Needs Ubuntu-style init script" [Wishlist,Triaged] https://launchpad.net/bugs/43574
<smoser> and also, sometime this week i'd like to get your thoughts on bug 606373
<ubottu> Launchpad bug 606373 in linux-ec2 (Ubuntu) "cloud-init output does not get to console when booted with pv-grub and ramdisk" [Undecided,New] https://launchpad.net/bugs/606373
<LucidFox> seb128, does Murrine even have an upstream bugtracker?
<LucidFox> I couldn't find one
<seb128> LucidFox, gnome.org
<seb128> bugzilla.gnome.org
<LucidFox> Ah, found it
<LucidFox> seb128> Forwarded, https://bugzilla.gnome.org/show_bug.cgi?id=624805
<ubottu> Gnome bug 624805 in general "Widget rendering issues with Cairo 1.9" [Normal,Unconfirmed]
<seb128> LucidFox, thanks
<agutierr> Hello: Someone knows how to disable Halt/Reboot entries from indicator-applet-session in gnome? (editing gconf keys doesnt works)
<twb> agutierr: if you work it out, let me know.
<twb> agutierr: same goes for disabling "user switching"
<agutierr> arggg twb
<agutierr> I need this!!! :-(((
<twb> I "fixed" user switching by replacing gdm with xdm, which conveniently also sidestepped some gdm information disclosure fuckups (at least in the default theme).  The button still shows up, but clicking it does nothing.
<agutierr> twb, there is some shorcut for make it work?
<agutierr> user switch i dont care
<agutierr> but halt and reboot... :-s
<twb> You might want to try looking for dbus .service files and diverting/deleting them.  I haven't investigated that approach yet; it's just a hunch.
<LucidFox> seb128, should I CC you to that upstream bug?
<seb128> LucidFox, no, that's ok, just add the url to the launchpad bug
<twb> One of the other engineers here said that not being able to lock it via gconf mandatory settings was a bug introduced in 8.10 and still not fixed :-/
<agutierr> twb, removing permissions to /sbin/halt and reboot may be an option
<twb> agutierr: I bet polkit will fuck you there, since it'll setuid
<twb> *it'll *effectively* setuid
<agutierr> I know
<LucidFox> I wonder why this issue only occurs with those drivers, though
<agutierr> Argggg Bugubuntu
<LucidFox> and not, say, Nouveau 3D
<LucidFox> Does Maverick's version of Cairo use the cairo-gl backend?
<agutierr> twb, I think it takes less than recompiling the gdm & indicator-applet-session...
<twb> agutierr: I wasn't suggesting recompiling anything
<twb> IMO once you're rolling PPAs, you've lost
<agutierr> twb, yep, but now for me it the fastest option
<agutierr> recompiling and cp the binary
<twb> I wish GUIs would just die in a fire
<agutierr> ^_^
<LucidFox> seb128> Any ideas why this bug is only reproducible with the NVIDIA drivers? Could this be related to the cairo-gl backend?
<ricotz> chrisccoulson, hi, i am currently uploading a thunderbird 3.1.1build2 package to my ppa (it is not nobinonly), but maybe it is worth a look, it will be in ricotz/staging in a few minutes
<LucidFox> assuming it's even enabled in maverick...
<chrisccoulson> ricotz, carrying the ubuntu patches?
<LucidFox> ricotz, I've always wondered, what's nobinonly?
<chrisccoulson> LucidFox, it has the binary only files removed?
<ricotz> chrisccoulson, yes
<LucidFox> ah, makes sense
<chrisccoulson> ricotz, have you switched off the official branding?
<ricotz> chrisccoulson, i just used the orig.tar.bz2 and the packaging from maverick
<ricotz> chrisccoulson, using debsrc 3
<chrisccoulson> hmmm, we don't have 3.1.1 in maverick yet do we? unless i missed something ;)
<chrisccoulson> in any case, you probably need to build with the unofficial branding
<ricotz> chrisccoulson, no there is no 3.1.1 package yet, ok so my package does fit the ubuntu branding then
<chrisccoulson> ricotz, micahg is going to be packaging tb3.1 quite soon, and we're going to be shipping it in lucid too
<ricotz> chrisccoulson, ok, i know i talked to him earlier
<chrisccoulson> you say you downloaded the tarball, or did you create it with the packaging?
<ricotz> chrisccoulson, i used the official mozilla tarball + ubuntu packaging, without nesting it in the tar.gz
<chrisccoulson> ah, we create our own tarballs (by running debian/rules get-orig-source DEBIAN_TAG=THUNDERBIRD_3_1_1_BUILD2)
<ricotz> chrisccoulson, i think with moving to debsrc3 it isnt needed
<chrisccoulson> but you probably need to build it with the unofficial branding if you are uploading it to a PPA with the ubuntu patches (trademark restrictions)
<chrisccoulson> ricotz, we can't transition to debsrc3 yet (the packaging still has to support hardy)
<ricotz> chrisccoulson, hmm, ok
<chrisccoulson> we can only do that once hardy and jaunty have both gone EOL
<chrisccoulson> which is why we've not done it already ;)
<ogra> Keybuk, i have a hung screen in front of me saying: "udevd[85] failed to create queue file: No space left on devce"
<ricotz> chrisccoulson, alright
<ogra> Keybuk, any idea how that could happen ?
<chrisccoulson> but we will still probably use a debian/rules target to roll our own tarballs anyway (so we have a single process for creating snapshots and milestoned releases)
<ogra> Keybuk, oh, i'll take that back, it wasnt hung hard, just very slow (it just moved on)
<bilalakhtar> Someone, please sponsor bugfix #550955
<bilalakhtar> I mean, bug #550955
<ubottu> Launchpad bug 550955 in software-center (Ubuntu) "About window is modal and doesn't look like it" [Low,In progress] https://launchpad.net/bugs/550955
<maxwellian> Riddell: Thanks for the info!
<ogra> doko, does http://paste.ubuntu.com/466402/ look ok ?
<skillet> hi all
<skillet> is there a reason why ubuntu is on openssl 0.9.8k?
<skillet> 1.0 is out
<skillet> i see, probably due to freeze
<skillet> ok
<twb> skillet: lucid is stable, so it basically only gets security patches
<skillet> yes i am aware of this
<skillet> i just saw the release date of 1.0
<skillet> anyway
<twb> Unless you mean maverick is frozen -- I don't pay much attention to non-LTS releases
<skillet> im trying to work out why all the ec ciphers arent showing in the list, when they are in the .so
<cjwatson> we mostly follow Debian for openssl; http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578376
<ubottu> Debian bug 578376 in openssl "openssl: OpenSSL 1.0.0 is out" [Wishlist,Open]
<skillet> pff
<skillet> you trust those guys to handle openssl? :P
<cjwatson> yes
<cjwatson> (note that many people here are Debian developers; insulting Debian is not generally a way to win friends and influence people)
<skillet> sorry i am a security guy
<skillet> i was referring to the great debian ssl fail of '08
<cjwatson> lessons have been learned from the debacle a couple of years ago, and it's in the past
<cjwatson> I am deeply, deeply familiar with that
<skillet> ok then
<cjwatson> I was part of the response team in Ubuntu
<cjwatson> that doesn't mean we have to hold it against the Debian openssl package forevermore amen
<skillet> here's the problem
<twb> A large contributing factor to that fuckup was upstream 1) doing something weird/dumb without an explanatory comment; and 2) failing to respond to queries about (1) on their own mailing list
<twb> It's not like the Debian maintainer just decided one day to deliberately destroy the entropy.
<cjwatson> I don't think it's necessary to go over it in depth again - it's been analysed in considerable detail
<twb> Sorry, you're right.
<skillet> $ strings /usr/lib/libssl.so.0.9.8 |grep ECDHE-RSA-AES256-SHA
<skillet> ECDHE-RSA-AES256-SHA
<doko> ogra: well, this fix will make openjdk-6 fail to build (which is good). I really do not want openjdk-6 built on armel in maverick before the arm assembler interpreter is enabled again, because the interpreter will run 4-5 times slower and wasn't tested for a year
<skillet> $ openssl ciphers |grep ECDHE-RSA-AES256-SHA
<skillet> $
<skillet> none of the ec* ciphers are enabled
 * cjwatson prods a security team member across the table
<mdeslaur> skillet: let me take a look, one sec
<skillet> (on debian as well)
<ogra> doko, so i should upload it and wait until you uploaded the toolchain to give it back then ?
<ogra> doko, as i understood you yesterday thats the change we need
<doko> ogra: no, please don't upload openjdk until the arm assembler interpreter is re-enabled
<ogra> doko, k, does that hapen in the linaro toolchain ?
<ogra> *happen
<ogra> i.e. in a forseeable time
<doko> ogra: it has to happen in openjdk. rob is working on this
<ogra> ok
<ogra> i'll leave it to him completely then
<mdeslaur> skillet: try openssl ciphers -v ECDHE-RSA-AES256-SHA
<mdeslaur> skillet: it would appear "openssl ciphers" doesn't show it, even though it's supported
<skillet> mdeslaur: ahh ok, thanks
<skillet> i still cant use it though
<skillet> hmm ill do a test
<mdeslaur> skillet: feel free to open a bug if it doesn't actually work, and subscribe me to it.
<skillet> 21718:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:s3_srvr.c:1006:
<mdeslaur> skillet: ok, please file a bug with a test case in it, and I'll take a look
<mdeslaur> skillet: thanks
<skillet> mdeslaur: okay
<skillet> ill do some more tests first
<skillet> dont want to raise a false positive
<mdeslaur> skillet: sure, np
<slangasek> twb: heh, I don't think we'll change that; the syntax of those fields is that they declare /blocks/ of lines to insert in the config file, it would be confusing to /read/ to have these on the same line as the field name
<mdeslaur> skillet: don't forget to subscribe me to the bug, or ping me when it's open. Lunch now, bbl.
<twb> slangasek: I was expecting it to behave in an 822-y manner
<twb> (It was also confusing that I didn't need to indent the "body" of a field with whitespace)
<twb> For the typical case where I'm only ever adding a single line to each file, I don't find it confusing to have that line after the Foo:, but I don't care enough to argue about it
<\sh> hmm...when was the last day to upload new packages to universe for maverick?
<tumbleweed> \sh: there is no such day, it just gets harder. However before feature freeze you should have little difficulty
<\sh> tumbleweed: I thought so....good
<MattJ> http://packages.ubuntu.com/maverick/ is broken for me at least :/
<geser> MattJ: known problem, it's being worked on
<twb> slangasek: another bug for you: it doen't ignore backup~ files in pam-configs/
<twb> (Generally with .d/'s I try to follow run-parts(8) approach of only looking at a whitelist of sane file names, rather than trying to keep a blacklist of the most popular backup file formats.)
<MattJ> geser: Thanks, good to know
<ricotz> chrisccoulson, i remade the tb3.1.1 package using get-orig-source
<ricotz> chrisccoulson, will take quite some time to upload, i am back later
<Riddell> siretart: libx264-98 is in binary new, do you know who asked for that sync and are they going to do the transition for the rdepends?
<pitti> cjwatson: do you have a minute to review my gparted SRU?
<LucidFox> http://paste.ubuntu.com/466462/ <-- any ideas?
<coolbhavi> hello I ve a doubt (as asked in #ubuntu-motu), I m maintaining mobile-broadband-provider-info in debian and ubuntu .. How to request SRU in case of an exception? https://wiki.ubuntu.com/StableReleaseUpdates#mobile-broadband-provider-info
<Riddell> coolbhavi: an exception?  you mean a crash?
<smoser> cjwatson, what module do i need to provide to grub-mkimage to get 'if' support
<Riddell> coolbhavi: oh I see, it has exceptional SRU allowances
<Riddell> coolbhavi: make a new package, file a bug and find someone to upload it
<Riddell> coolbhavi: and subscribe the bug to ~ubuntu-sru
<coolbhavi> Riddell, yep The Readme file says "...The Package contains only informational files so it's safe for distributions to grab updates even during feature freeze and maintenance stages."
<coolbhavi> The update could also solve some of these bugs through regular check: https://bugs.launchpad.net/ubuntu/+source/mobile-broadband-provider-info
<coolbhavi> Riddell, so just adding a exception tag in the bug report is enough?
<smoser> cjwatson, never mind.
<smoser> (sh)
<DktrKranz> LucidFox: it's probably because of --keyring /usr/share/keyrings/ubuntu-archive-keyring.gpg, while trying to create a Debian chroot
<LucidFox> Well yes, but I had no such problem when using it on my work machine, which runs lucid
<LucidFox> I wonder if something broke in maverick
<kees> cjwatson: are we doing a techboard meeting?
<geser> kees: isn't the TB meeting next week? today is a DMB meeting
<kees> geser: I think my calendar is lying to me
<kees> geser: yup, you're totally right.
<kees> cjwatson: ignore me please :)
<siretart> Riddell: that is no sync, I prepared that package myself
<siretart> Riddell: and yes, that is a library transition like many others. rdepends need to be checked and fixed
<seb128> cjwatson, pitti: the ubuntuone-client 8 bugs are verification-done
<seb128> cjwatson, pitti: I think it would be worth getting for .1, it has been uploaded almost a month ago, the first upload failed to build though and they didn't use -v for the second one
<seb128> which is why the sru page lists none of the bugs
<pitti> seb128: aah, that explains it, thanks
<pitti> doing
<seb128> pitti, thanks
<pitti> hm, now I have to manually close them all
<seb128> pitti, get dobey to do it ;-)
<Riddell> siretart: shouldn't it have a -XubuntuY version number if it's not a sync?
<Riddell> siretart: accepted out of New
 * Riddell does the empty new queue dance
<JontheEchidna> \o/
<siretart> Riddell: err, do we really require that? udev is a prominent example that does not as well
<Riddell> siretart: no we don't, it just seems sensible if it's likely to be synced from debian ever (but since you'd be incharge of that most likely, you could coordinate it easily enough)
<siretart> Riddell: the package does not exist in debian
<siretart> but yes, in case it gets accepted somewhen in the future, I'll of course make sure that it can be easily synced
<cjwatson> pitti: looking
<cjwatson> pitti: Riddell asked for a test case in the bug
<cjwatson> pitti: do we need to handle both udisks and hal-lock being there?
<maxb> As the armel build queue is currently empty, may I please have a give-back of https://edge.launchpad.net/ubuntu/+source/subversion/1.6.12dfsg-1ubuntu1/+build/1853956 to establish whether it is a transient or systematic failure?
<cjwatson> maxb: given-back
<maxb> thanks
<pitti> cjwatson: yes, in case hal is running
<pitti> cjwatson: test case> can do, it's trivial; I'm in a meeting now, will do after that
<tgall_foo> anyone around that somewhat groks live-helper configs ?
<cjwatson> pitti: the current fix only calls udisks, and doesn't have the udisks && hal-lock case to match devkit-disks && hal-lock below
<pitti> cjwatson: so, hal isn't actually an issue on our live systems or Ubuntu, but I guess we'd need it if you run gparted on kubuntu
<pitti> cjwatson: then again, kubuntu doesn't have udisks
<pitti> but we could just add this, too, and then send it upstream again
<cjwatson> pitti: up to you, I can disregard it if you really don't think it matters
<pitti> cjwatson: I won't have time today to fix it harder; I think it's "good enough" for our purposes, but not 100% correct
<Riddell> pitti: if you're into SRUs bug 578215 could do with being copied over to -updates
<ubottu> Launchpad bug 578215 in kdebase-runtime (Ubuntu) "virtuoso-t eats my cpu, should be nice" [Medium,Confirmed] https://launchpad.net/bugs/578215
<pitti> Riddell: it's not marked verified
<pitti> Riddell: if it is, please do so and run sru-release lucid <pkgname>
<pitti> (fancy way of doing copy-package)
<Riddell> pitti: it has the verification-done tag, how else should it be marked?
<pitti> Riddell: oh, I looked at virtuoso-opensource
<pitti> Riddell: ah, that had a broken changelog, and thus didn't appear on http://people.canonical.com/~ubuntu-archive/pending-sru.html
<pitti> Riddell: if you release it, you need to close the bug manually
<Riddell> pitti: where is sru-release ?
<pitti> Riddell: script on cocoplum
<Riddell> oh right, was looking in ubuntu-archive-tools
<NCommander> pitti: ping, can you refix the mobile trendlines again :-)?
<nigelb> cjwatson: would it make sense if I brought the issue of sending mail at the end of the meeting?
<cjwatson> sure
<nigelb> okay :)
<pitti> NCommander: which? to what?
<pitti> NCommander: http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile-maverick-alpha-3.html looks quite fine to me
<NCommander> pitti: mobile burndown charts trendline
<pitti> NCommander: http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile.html looks broken, I'll fix that
<ogra> pitti, A3 is completely off
<NCommander> pitti: er, that doesn't look right to me. We had an issue with a spec not being properly targetted even thought work was happening on it from the beginning
<pitti> NCommander: ah, so it was mis-planning, rather than additional work coming in mid-cycle?
<ogra> should be at 22
<NCommander> pitti: mis-clicking :-)
<pitti> done
 * ogra hugs pitti 
<Riddell> Laney: you're not core-dev but you self confirmed a sync for main?  bug 607641
<ubottu> Launchpad bug 607641 in f-spot (Ubuntu) "Sync f-spot 0.7.1-1 (main) from Debian experimental (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/607641
<cjwatson> f-spot's in the cli-mono package set
<cjwatson> ./edit_acl.py -p laney query; ./edit_acl.py -P cli-mono -S maverick query
<Riddell> ah hah, thanks cjwatson
<maxb> Hmm. Is there anywhere I can ask "Is armel known to be broken right now?" ?
<maxb> In respect of messages like "sh: gcc: not found" and kdelibs5-dev being uninstallable,
<maxb> Oh, armel builders on Manual. /me assume Something Is Happening
<geser> maxb: "sh: gcc: not found" appears in every log, you can ignore that one
<Riddell> maxb: qt hasn't built on arm in a while so KDE bits are unlikely to work
<johanbr> is there anyone around who feels particular responsibility for texlive?
<johanbr> the current maverick version of texlive-publishers has some serious issues, it'd be nice to get it updated some time before release
<tantiv> Is there a reason partimage is only available on x86?  I checked the partimage server and all amd64 bugs were closed for the version currently built for i386.  I successfully built it from deb-src and it seems to work perfectly.
<bryceh> jcastro, you about?
#ubuntu-devel 2010-07-21
<jmg> damn
<jmg> who was the security guy that was helping me with openssl last night
<jmg> nick started with m
<ajmitch> mdeslaur?
<jmg> ya thats him
<jmg> thanks
<achiang> hm. i'm modifying a package that's using debian 3.0 format. i made a simple change to a file in the debian/ directory. i then prepared it for upload with debuild -S -sa -I -i. examining the diff between the two .dsc files, the changes are huge because it seems like the patches were applied before taking the diff...
<achiang> does that seem right?
<jmg> whoa
<jmg> is jjohansen dvdjon?
<soren> No.
<jmg> is anyone aware of an openssl 1.0.0 experimental package?
<micahg> jmg: debian bug 578376, you can subscribe to find out when it's released to experimental
<ubottu> Debian bug 578376 in openssl "openssl: OpenSSL 1.0.0 is out" [Wishlist,Open] http://bugs.debian.org/578376
<jmg> thats a shame
<jmg> i need it for my project
<achiang> hm, if i pass boot=casper, does that mean that scripts in init-* aren't executed?
<achiang> because that's what i'm noticing...
<achiang> hm, maybe that's not true. removing 'quiet' from the cmdline, i can see the debug output from init, and we're definitely doing the stuff in init-*
<achiang> interesting. so if i say console=tty5, e.g. then i don't see the plymouth splash screen
<pitti> Good morning
 * LucidFox waves
<diwic> pitti, Good morning. Btw, are you in Prague?
<pitti> diwic: hey, how are you? Yes, I am
<diwic> pitti, I'm fine, how are you? I should probably say hello to you some time.
<diwic> pitti, I have no idea of how you look like though, so it might be hard to find you.
<pitti> diwic: I'll head over to the plenary room in 2 mins; I wear beige short trousers and a blue collared shirt, and sandals :)
<pitti> (sounds like a blind date)
<diwic> pitti, :-) I'm wearing a blue LAC t-shirt today.
<kees> jcastro: http://people.canonical.com/~kees/search-eggtrayicon.txt  for mpt
<jcastro> kees: awesome, I'll put it on the wiki
<bigon> In dmesg You have old & broken userspace please consider updating mesa << is that know or should I open a bug?
<dupondje> Why is PHP5 not on the MoM ? :)
<ScottK> pitti, jdong, someone in ubuntu-sru: Would you please look at 569879 (xorg-server - it's in the queue).  It's marked for 10.04.1, so I'd really like to get it accepted so it can get tested.
<devfil> ScottK, ok
<mathiaz> lifeless: hi!
<mathiaz> lifeless: I'm trying to merge the puppet branch from experimental and run into the following error:
<ScottK> devfil: Thanks.
<mathiaz> lifeless: http://paste.ubuntu.com/466976/
<lifeless> mathiaz: please grab jam, hes in the main room
<mathiaz> lifeless: ok
<lifeless> jam: ^
<jam> mathiaz: I'm in the community room right now, where are you?
<mathiaz> jam: walking over to your room
<pitti> ScottK, devfil: accepted, thanks
<ScottK> pitti: Thanks.
<pitti> I saw the message on other systems as well, but it doesn't seem to cause crashes there
<doko> apw, slangasek: https://launchpad.net/~ubuntu-toolchain-r/+archive/ppa/+packages  (gcc-4.4-fsf), providing a `kgcc' binary
<ScottK> doko: How's it looking to get the Linaro changes into Maverick?
<slangasek> doko: oh, er, I didn't understand that you were intending this as the workaround for the current issue - I don't want to encourage the kernel team to futz around with a different toolchain for a short-term problem when we're already in the process of regression-testing images resulting from the test rebuild
<cjwatson> not so much a different toolchain as the same one they were previously using
<doko> and builds as multilibbed locally here too
<cjwatson> and while it's short-term in some sense, it unblocks us wrt the (non-linaro) arm team's concerns
<slangasek> cjwatson: which is what I understood I was killing my day trying to get an image generated for?
<mathiaz> james_w: hi - I ran into the following error: http://paste.ubuntu.com/466976/
<mathiaz> james_w: and fixed the conflicts
<mathiaz> james_w: what commit message should I use now?
<mathiaz> james_w: should I run bzr ci -m "Merge upstream."
<mathiaz> james_w: ?
<tumbleweed> mathiaz: bzr resolved
<mathiaz> tumbleweed: I've already done that
<mathiaz> tumbleweed: now I wonder if I do bzr ci or bzr merge-package
<tumbleweed> mathiaz: the message says: Please resolve these, commit and re-run the "merge-package" command to finish
<bigon> any idea why xulrunner-1.9.2 pkg configure get stuck in pbuilder ? seems blocked at /usr/lib/xulrunner-1.9.2.7/xulrunner-bin --gre-version
<tkamppeter> pitti, hi
<pitti> hello tkamppeter
<tkamppeter> It is about my 3 SRUs, you did not move them to -proposed in yesterday's SRU run.
<tkamppeter> pitti, could you do so so that we can get them into 10.04.1?
<pitti> tkamppeter: see robbiew's announcement, we need to freeze the SRU queue for the 10.04.1 prep
<tkamppeter> pitti, so I should tell the users to wait 2 or 3 weeks until 10.04.1 is out?
<pitti> more like 2
<tkamppeter> pitti, one could at least put them into -proposed so that the users get a working system, the final pass to put them into -updates one could do after 10.04.1. WDYT?
<pitti> tkamppeter: that's the problem, we actually need to freeze -proposed
<tkamppeter> pitti, so I should perhaps bridge the freeze via my PPA, simply to satisfy the users?
<pitti> tkamppeter: sounds great
<tkamppeter> pitti, I have an improvement suggestion: SRU freezes should be marked in the release schedule plans and announced by e-mail sometimes before, so that developers can better plan their time instead of creating new SRUs in the beginning of SRU freeze.
<pitti> tkamppeter: right; in fact the entire 10.04.1 process has been quite sloppy so far, since we don't currently have a release manager
<pitti> it'll get better from August on, when we have one again
<zul> pitti: i pushed the mysql sru fyi
<pitti> zul: ah, thanks
<tkamppeter> pitti, I hope the 10.04.1 will at least be held back until a solution for bug 554172 gets found.
<ubottu> Launchpad bug 554172 in linux (Ubuntu) "CUPS and other system services not starting at boot" [Critical,Confirmed] https://launchpad.net/bugs/554172
<pitti> tkamppeter: no, it won't; if we don't have a patch for a problem right now, we won't include it into .1
<pitti> zul: can you please upload to maverick, too?
<tkamppeter> pitti, so the LTS will probably have to live with it as upstart's architecture is a mis-concept, only solvable with highly invasive changes which one cannot apply as SRU?
<pitti> it's not a mis-concept; we still don't know why it fails on those machines
<zul> pitti: i already have
<pitti> zul: ah, the maverick task is still open
<pitti> tkamppeter: I don't remember any more, do we know whether other rc2.d/ scripts run?
<smoser> cjwatson, ok. you have a minute ?
<tkamppeter> pitti, AFAIK the problem is that the script to initiate running old System V startup scripts and the startup scripts itself need /dev/console, and very often this script already starts when /dev/console is not yet writable. What has to be done is to make a task waiting for /dev/console getting ready and making the task for starting the legacy scripts depending on the /dev/console task.
<pitti> tkamppeter: sounds weird (since /dev/console should already be there at initramfs time), but it shuold be easy to make /etc/init/rc.conf wait on that
<ScottK> tkamppeter: There will be a 10.04.2.
<pitti> and -updates, too
<ScottK> Yep.
<lifeless> mdz: where is this QA thing?
<doko> apw: gcc-4.4 package available in the ubuntu-toolchain ppa
<Synthead> is this the right channel if I need help making a .deb?
<micahg> Synthead: try #ubuntu-packaging
<Synthead> thanks :)
<dupondje> Why is PHP5 not on the MoM ? There is a newer version in debian, but seems not listed
<micahg> dupondje: it should be there
<dupondje> its not :)
<micahg> dupondje: it'll probably show up soon
<dupondje> its really a requirement to get the new version in ubuntu
<dupondje> should even be SRU'ed
<dupondje> fixing memory leaks and other shizzle :)
<micahg> dupondje: php SRUs are no easy matter, you should talk to the server team though if you think it's a priority
<failshell> hello. i was wondering how you guys handle the different branches of ubuntu when you build packages. i use pbuilder to build them, but i always have to edit debian/changelog manually for either hardy or lucid. is there a way to have this done automatically by pbuilder instead of doing with dch?
<failshell> do you have build machines for each branch?
<vish> hi,  are there no -dbgsym packages in maverick?
<vish> there seems to be only one pkg-create-dbgsym
<vish> rest seem missing.. or have they been moved?
<vish> need a replacement for libcamel1.2-14-dbgsym , in maverick , there is no -dbg for that one..
<geser> vish: what's wrong with the ddebs for it from http://ddebs.ubuntu.com/pool/main/e/evolution-data-server/?
<vish> geser: hmm , I'm trying it in a VM and it doesnt find it.. there seem to be only 1386 and amd64  packages..
<vish> VM maverick..
<geser> and you need which architecture?
<vish> genii: shouldnt the i386 work for a VM?
<geser> vish: if you VM is a i386 one then they should work
<vish> geser: hmm , oops , it was just synaptic being odd here!
<vish> it is not able to search , but when i scrolled it is there..
<vish> heh , should have stuck with apt-get ;p
<vish> geser: thanks!
<Chipaca> Hi all. I've got a debdiff that fixes #608341 ; who can I pester to sponsor the upload?
<tumbleweed> Chipaca: you subscribe ubuntu-sponsors
<Chipaca> tumbleweed: done.
<Chipaca> *now* who can I pester to sponsor the upload? :)
<Chipaca> the bug makes the package uninstallable, so I'd like to get it out there soonest
<tumbleweed> it's main, good luck :P
<Chipaca> repeating, just for luck before I head on out
<Chipaca> I've got a debdiff that fixes #608341 ; upload plz :)
<tumbleweed> Chipaca: it helps to get attention if you give the bug number in a form that ubottu understands
<beuno> bug 608341
<ubottu> Launchpad bug 608341 in rhythmbox-ubuntuone-music-store (Ubuntu) "package rhythmbox-ubuntuone-music-store 0.1.1-0ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Critical,In progress] https://launchpad.net/bugs/608341
<tumbleweed> that way the "Critical" stands out :)
<micahg> Chipaca: an in progress bug won't get sponsored
#ubuntu-devel 2010-07-22
<bitshuffler> Hi guys. Could anyone of you please be so kind to name me some properly done "noarch" package so I can have a look at its .dsc and control files?
<bitshuffler> (I'm happy with its name but since I don't run Ubuntu it is a bit hard to lookup)
<ScottK> bitshuffler_: What the RPM world calls 'noarch', we call Arch 'all'.
<ScottK> RPM arch is Debian Arch any.
<bitshuffler_> ScottK: thanks :)
<ScottK> bitshuffler_: You're welcome.
<crimsun_> bdrung: I can't unsub ubuntu-sponsors from #581786 else I would have.
<crimsun_> (Also, I have no idea why you can't see the upload...)
<soreau> Can anyone tell me the difference between kdelibs4-dev and kdelibs5-dev? Ultimately I'm trying to figure out which deps are needed to build kde4-window-decorator for compiz
<theRealSaint> hey, where do I go for kernel related queries on Ubuntu?
<theRealSaint> dpkg-gencontrol: error: package linux-image-2.6.35-rc5-custom+ not in control info
<theRealSaint> am getting this error while compiling a vanilla kernel on ubuntu
<SwedeMike> I'd imagine #ubuntu or #ubuntu+1 are the places to go, depending on what version you're running
<achiang> theRealSaint: why are you building a kernel? if all you want is a vanilla kernel, i believe there are mainline dailies (or at least -rc) that you can install
<theRealSaint> achiang, i am trying to tinker with the kernel. so i have my own changes to compile
<achiang> theRealSaint: if you're doing that, i usually find it to be much easier to just grab linus's git tree, make defconfig, make, sudo make modules_install, sudo make install, sudo mkinitramfs, reboot
<achiang> instead of messing around with packages, etc.
<achiang> but that's just me
<theRealSaint> achiang, that will mess up the installation
<theRealSaint> building debs helps me keep track of what is there
<theRealSaint> it's easier grub configuration, easier uninstall etc.,
<achiang> theRealSaint: it won't mess up anything if you're careful. ;)
<achiang> theRealSaint: well, you can try asking in #ubuntu-kernel for the proper way to do it, although i suspect they'll tell you to go read the wiki
<theRealSaint> achiang, which wiki? :)
<achiang> theRealSaint: maybe you have CONFIG_LOCALVERSION and CONFIG_LOCALVERSION_AUTO turned on. istr that's how the + character shows up
<achiang> theRealSaint: start here, https://wiki.ubuntu.com/KernelTeam poke around as necessary
<achiang> oops, start here: https://wiki.ubuntu.com/Kernel
<theRealSaint> achiang, ok. thanks...
<achiang> theRealSaint: https://help.ubuntu.com/community/Kernel/Compile
<achiang> i forgot to mention make firmware_install above
<theRealSaint> achiang, i was actually following that article when I encountered this error
<bilalakhtar> Please sponsor fix for bug #155930
<ubottu> Launchpad bug 155930 in synaptic (Ubuntu) ""Unmark all" clears the package list (!)" [Low,In progress] https://launchpad.net/bugs/155930
<LucidFox> http://revu.ubuntuwire.com/p/gnome-globalmenu <-- Is there a point for getting this into Ubuntu anymore?
<ccheney> does DH_ALWAYS_EXCLUDE not work on native packages?
<ccheney> it doesn't seem to be working for me
<ccheney> anyone happen to know how to work around the issue?
<ccheney> hmm seems to be -I as part of dpkg-source
<Chipzz> achiang: why are you suggesting ppl to work around the package management system? on an official ubuntu channel nonetheless?
<Chipzz> that is EXTREMELY poor advice to give, please don't do it again
<asac> RAOF: your netbook is really UNSTABLE ;)
 * asac reboots ;)
<asac> hah ... 2d session also crashes :(
<mdeslaur> chrisccoulson: any thought on the two patches in bug #241206 #16?
<ubottu> Launchpad bug 241206 in gnome-screensaver (Ubuntu) "Gnome Screensaver does not activate reliably" [Low,In progress] https://launchpad.net/bugs/241206
<RAOF> asac: Hm.  I *think* I downgraded the crashy Xserver 1.9RC from that netbookâ¦ :)
<lool> robbiew, doko: Hey, I understand there's an issue with linux on i386; do you want me to come down with a toolchain engineer to look into it?
<chrisccoulson> mdeslaur, i'll have a look at those in a bit
<mdeslaur> chrisccoulson: cool, thanks
<agutierr> someone knows how disable reboot/halt options from gnome?? (ubuntu 10.04) thanks!
<asac> RAOF: no problem ;)
<asac> gles works ;)
<asac> 2
<RAOF> asac: Yay!
<RAOF> asac: With what sort of performance?
<asac> RAOF: more frames than i get on a beagle :)
<RAOF> :)
<asac> about twice as many frames
<asac> so beagle has like 25/30 ... this has 50/60
<asac> unfortunately the battery ran out of fuel so i am charging now before i can go and show that to arm team downstairs ;)
<RAOF> :)
<lfaraone> pitti: Is there anything special to keep in mind if I were to attempt a merge in a newer version of CDBS in maverick?
<achiang> Chipzz: i'll note the exact same advice was given out on #ubuntu-kernel a few minutes afterwards
<Chipzz> then also note that ubuntu-kernel is a channel with lots of ubuntu developers, who *know* what they're doing and are capable of repairing any damage done to their system
<Chipzz> unlike someone who may just want to test a patch
<Chipzz> when I'm trying to patch something, I'll sometimes take the ./configure; make; make install route myself for testing too; but I keep track of my changes, and I'm able to undo anything I have done in the process
<Chipzz> it's certainly not sth I will recommend to anyone
<achiang> anyhow, if you feel the urge to yell at me again, i suggest private /msg.
<ogra> kirkland, pingaling
<pitti> lfaraone: nothing in particular; it has quite a solid test suite
<pitti> lfaraone: as for testing, I recommend building e. g. apport (it has l10n, multiple binaries, etc), then upgrading cdbs, building apport with that, an debdiffing the resulting binaries
<didrocks> Keybuk: is it normal that when I refresh netbook-meta, I get: Removed plymouth-x11 from netbook-recommends
<Keybuk> didrocks: I don't know what netbook-meta is, so I can't answer any questions as to its normal behaviour
<didrocks> Keybuk: it's the ubuntu-netbook metapackage
<Keybuk> that will depend on the seed contents, surely?
<pitti> didrocks: check the seeds history?
<\sh> slangasek: do you remember bug #504224 ?
<ubottu> Launchpad bug 504224 in mountall (Ubuntu Lucid) "NFS mounts at boot time prevent boot or print spurious errors" [Medium,Fix released] https://launchpad.net/bugs/504224
<didrocks> Keybuk: right, it depends on the ~ubuntu-core-dev/ubuntu-seeds/netbook.maverick seed which contains any recent change  related to it. Should look at the common part from the ubuntu desktop seed
<slangasek> didrocks: plymouth-x11 has just been removed from the desktop-common seed; Riddell checked with me since I was the one who added it last cycle at the point that plymouth binary packages got split up, in order to keep it out of kubuntu given that it's gtk-based; if you guys are using it, I would suggest adding it to your seed
<slangasek> \sh: vaguely
<\sh> slangasek: yesterday I ran into the very same problem with NFS shares mounted at boottime..with lucid...the only fix was to add "nolock" to the options..everything else didn't work
<didrocks> slangasek: is it the package containing the plymouth interface? that will mean that at next desktop refresh as well, we won't have plymouth interacting with X too. As I'm not the maintainer of this piece, I was thinking Keybuk would have known if this package is important to keep or notâ¦
<didrocks> slangasek: thanks for the info :)
<slangasek> didrocks: it's the package containing the plymouth frontend /that runs under X/, which TTBOMK no one is using today
<didrocks> slangasek: ok, let's go that way first (not adding it) and seeing tomorrow live. Thanks :)
<slangasek> \sh: you should file a new bug
<Keybuk> right, the X backend is intended for theme designers atm
<didrocks> Keybuk: ok, thanks. I won't include it so.
<\sh> slangasek: will do...
<dobey> hey all
<dobey> anyone have any idea why pysupport would be having my setup.py install stuff in usr/lib/python2.6/site-packages instead of usr/share/pyshared?
<dobey> nobody? :(
<lifeless> dobey: backport or current distro ?
<dobey> maverick
<lifeless> thats unusual
<dobey> lifeless: i got it fixed, but haven't figured out the issue though.
<dobey> lifeless: if i put the usr/lib/python2.6/... bits in the .install file, then the resulting package has them in usr/share/pyshared instead
<dobey> so something must happen *after* the .install parsing that does it
<EtienneG> slangasek, hey there; got a question for you, since you seems to be the author of pam-auth-update
<EtienneG> slangasek, let's say I wanted to write a profile a pam-auth-update profile for pam_group
<EtienneG> (whether or not this is a good idea, I am not sure yet)
<EtienneG> I see that libpam-modules does not provide any profile for the base module
<EtienneG> slangasek, my question is: 1. is there a good reason for that?, and 2. if I wanted to write such a profile, which naming convention should I use?
<EtienneG> re: naming convention above, I mean, how should I name the profile file to drop in /usr/share/pam-config/ ?
<bigon> are there any problems with amd64 builder?
#ubuntu-devel 2010-07-23
<JoshStrobl> Hello, I have packaged a folder into a .deb and using the "data" folder I directed the files to install in the /usr/share/themes and /usr/share/icons folders, however I realized that they need to be installed in the home directory. How would I be able to make the .deb install in the user's .themes and .icons folders?
<micahg> JoshStrobl: try #ubuntu-packaging
<JoshStrobl> Ok
<micahg> kees: ping
<hyperair> huh, dpkg no longer has perl? then what'll happen to debhelper?
<wgrant> hyperair: dpkg, not dpkg-dev, is become Perl-less.
<hyperair> wgrant: aah i see.
<wgrant> dpkg-dev still has an awful lot of it :(
<bilalakhtar> wgrant: are you freeeee ?
<wgrant> Hm?
<bilalakhtar> wgrant: can you sponsor bugfix #550955
<bilalakhtar> bug #550955
<ubottu> Launchpad bug 550955 in software-center (Ubuntu) "About window is modal and doesn't look like it" [Low,In progress] https://launchpad.net/bugs/550955
<wgrant> bilalakhtar: I can't upload to main.
<bilalakhtar> wgrant: you are not core-dev ?
<wgrant> No.
 * bilalakhtar mistook wgrant to be a core-dev
<wgrant> I'm a Launchpad dev, and formerly an active MOTU, but never a core-dev.
<pitti> Good morning
<ogra> can anyone from the MIR team process/pre-promote the shotwell MIR (bug 607758) it breaks all images currently
<ubottu> Launchpad bug 607758 in shotwell (Ubuntu) "[MIR] shotwell" [Wishlist,New] https://launchpad.net/bugs/607758
<fale> hello
<fale> how does ubuntu server creates ISOs? Does they use a script?
 * ogra wonders why "buildlive base" also fails with gtk/shotwell errors
<ogra> there shouldnt be *any* graphical stuff in a base livefs
<ogra> cjwatson, ^^^ any idea ?
<slangasek> EtienneG: no profile exists for pam_group because pam_group is blecherous and not to be encouraged.  A separate package outside of pam, which depends on the correct bits of pam, could provide such a profile.  The naming convention is s/^pam_// + .* on the module name.
<ogra> hmm, seems i should wak up before reading logs
 * ogra looked at the wrong log
<cjwatson> ogra: I am on top of shotwell etc.; you can skip it
<ogra> cjwatson, well, i'm resorting to base for my testbuilds now
 * ogra doesn really care for the image content atm
<cjwatson> zul: I checked with Keybuk; the problem with echoing a timeout message is that it basically doesn't work very well right now.  If you do 'start mysql' in X then the message will go to /dev/console, not your terminal!  On the whole, at the moment we reckon it would be better to simply remove both the timeout message and 'console output' - although 'console output' is safe in itself (as opposed to 'console owner', which is ...
<cjwatson> ... what I was remembering)
<zul> ack..in a meeting right now but ill get to it first thing
<cjwatson> zul: thanks
<glick> hi guys, im not sure if there is a serious bug in ubuntu, or if im simply using it wrong
<glick> I got folder sharing to work, using System->prefs->personal file sharing, and then right clicking on my public folder, and selecting share this folder
<glick> however, when i un check share this folder, and reboot
<glick> the folder is still shared
<glick> is that a bug?
<glick> or am i not doing something right?
<bigon> is there an issue with amd64 buildd?
<glick> is there an open bug report on not being able to unshare folders in ubuntu 10.04?
<glick> for some reason i cant unshare a folder that i once shared
<glick> i unclick share folder
<glick> even reboot
<glick> yet its still shared
<glick> if i type net usershare info
<glick> it doesnt show up, but its still shared
<glick> does anyone know how i unshare a foldeR?
<glick> i unclick the share button, yet its still shared
<glick> no output is generated from the comman net usershare info
<glick> yet its still shared
<LucidFox> Eep, what happened to Launchpad?
<bilalakhtar> Someone, please sponsor fix for bug #155930
<ubottu> Launchpad bug 155930 in synaptic (Ubuntu) ""Unmark all" clears the package list (!)" [Low,In progress] https://launchpad.net/bugs/155930
<hyperair> LucidFox: looks fine to me.
<LucidFox> Hmm, now it works... Used to give a "connection time out" error
<hyperair> how strange.
<ogra> cjwatson, hmm, for-project doesnt know about base/livecd-base ?
<cjwatson> ogra: it's a special case for some reason I do not recall; the crontab line is build-livecd-base
<ogra> cjwatson, yeah, i looked at that, it doesnt actualy roll an image it seems, just copies the livefs around
<ogra> jdstrand, could you let linux-ti-omap4 out of NEW so we can build images again ?
<jdstrand> ogra: k
<ogra> thanks :)
<jdstrand> sure
<cjwatson> ogra: 'buildlive base', according to the crontab
<cjwatson> not for-project
<ogra> cjwatson, yes, but how do i roll an image out of that without for-project ? :)
<ogra> sure i get a base filesystem, that worked just fine
<ogra> but i somehow need to call cron.ports_daily-preinstalled
<cjwatson> ogra: dunno, it wasn't designed for rolling images, it was designed for dumping out a squashfs that lamont could customise
<ogra> ah
<lamont> base isn't shipped
<lamont> or even generally built, afaik
<ogra> lamont, right, i'd like to be able to use the base fs with for-project
<ogra> i think its in the crontab
<lamont> for-project?
<ogra> 6 4 * * *	buildlive base; build-livecd-base
<ogra> for-project is the script from debian-cd that rolls the actual images
<ogra> i guess i need to add it then
<lamont> ah, ok.
<lamont> base comes from a time when ubuntu-base was a valid meta-package.  not sure it even lets one login
<lamont> then again, I haven't done anything with base in at least 4 years.
<lamont> wow.  time flies
<ogra> heh
<ogra> well, livecd-rootfs installs ubuntu-standard if base is selected
<lamont> much more likely to be usable then
<ogra> through the prreinstalled path it also pulls in jasper and oem-config ... so it creates a perfect cmdline image
<lamont> part of me wants to speculate that the target was non-desktop machines and having a livecd for them
<ogra> like a 256M beagleboard ;)
<lamont> ogra: I think the original target was maybe hppa
<lamont> but the beagle board is much  more cool
<ogra> well, so be beagle the new hppa then :)
<jpds> .
<lamont> ogra: no.  no it is not.
<smoser> cjwatson, so you think it would be ok for eucalyputus node controller to run-time depened on grub-rescue-pc, and mount grub-rescue-floppy.img, replace config, add user supplied multiboot image and then boot it
<pitti> ev: new jockey uploaded, BTW; please let me know if you have trouble with it
<ev> pitti: yay!  thanks!
<apw> cjwatson, i wonder if it might make sense to rescore the remaining gcc-4.4 builds in maverick
<doko> apw: I don't think so, because Linaro is enabled only on i386 and amd64
<pitti> I thought powerpc as well?
<apw> doko, not on ports ?
<doko> pitti: we will, but only the generic parts, not the powerpc specific backports. these won't be part of linaro gcc-4.5. if these changes would go into 4.4, they would be seen as an regression compared to 4.5
<doko> apw: no, it was never the plan to enable these for sparc and ia64 (which are likely to go away in maverick)
<apw> doko, though we need to upload the kernel after a compiler version number change, so we need to wait for them all to finish either way
<cjwatson> smoser: I *think* so
<cjwatson> smoser: in a "twitch" kind of way :-)
<cjwatson> apw: I've scored them up anyway
<smoser> we had said build time depend, but that seems more difficult to fix as it might require a no source change rebuild of eucalyptus-node controller to deliver the new grub rescue image.
<cjwatson> doko: ... and armel, according to the changelog
<smoser> the thing I *dont* like is that in dynamically creating it, a grub update could break running of guest instances.
<doko> cjwatson: armel had the linaro changeset already turned on with the last upload
<cjwatson> smoser: that's why I suggested grub-rescue-pc rather than grub-pc, since grub-rescue-pc doesn't do any bootloader installation (if I'm understanding you correctly)
<cjwatson> doko: ah, ok
<smoser> cjwatson, right.
<smoser> oh, cjwatson, grub-rescue-pc will get into main, right ?
<smoser> do i need to MIR that ?
<cjwatson> smoser: binaries from a source already in main don't need an MIR
<smoser> thats what i had thought, but i had become confused.
<pitti> cjwatson: I'm about to move the kernel to -updates; do you want to handle d-i?
<ScottK> pitti: Would you please rescore qt4-x11.  It finally built on armel last night, but now there's a new upload so archive skew is about to kill our ability to fix FTBFS if it doesn't get going (this would just affect powerpc and armel).
<cjwatson> pitti: ok, let me know when I can
<pitti> cjwatson: you can now, I moved it
<cjwatson> I'll wait 'til publish-distro finishes
<geser> could someone please give-back "bsh" on i386. It's in depwait on "default-jdk-builddep" which is provided by gcj-native-helper which is now in main on i386 too.
<soren> geser: done
<smoser> cjwatson, maybe i was confusing above.  the grub-rescue-floppy.img is a iso9660 fs, so i can't write to it.
<smoser> (i was thinking it was a floppy disk image -- ext2 or something -- that i could mount, replace config and unmount)
<rsalveti> kirkland: where is the qemu page that you were talking about?
<rsalveti> want to look just to see what is tested and "supported" :-)
<cjwatson> zul: regarding bug 608423, were you planning to do anything about point 2 in the bug report?
<ubottu> Launchpad bug 608423 in mysql-dfsg-5.1 (Ubuntu) "[lucid-proposed] post-start script broken" [Undecided,New] https://launchpad.net/bugs/608423
<zul> cjwatson: not yet...i need to find a better way to address it
<cjwatson> zul: upstart script fragments are always run with 'set -e', so the reporter's right
<cjwatson> zul: I think you want:
<cjwatson> ret=0
<cjwatson> /usr/bin/mysqladmin --defaults-file=$HOME/debian.cnf ping || ret=$?
<zul> cjwatson: good idea
<cjwatson> that's my standard construct for these things anyway
<zul> cjwatson: uploaded
<cjwatson> zul: thanks, will look when it generates the diff
<zul> cjwatson: no probs
<cjwatson> pitti: could you look at ubiquity/lucid-proposed?
<pitti> cjwatson: sure
<pitti> ERROR: queue does not have a debdiff
<pitti> meh
<pitti> old-style then
<pitti> cjwatson: if I may ask for gparted in return?
 * pitti rejects the older mysql upload
<pitti> zul: ^ FYI
<zul> pitti: ty
<pitti> cjwatson: done
<cjwatson> pitti: ah yes, will look
<cjwatson> done
<micahg> if I have a segfault in an armel build failure, could that be a transient error?
<ebroder> Can anybody give me some pointers on figuring out how the live CD build works?
<achiang> ebroder: what's your question"
<achiang> ?
<ebroder> I want to roll a custom live CD and I'd like to start from the same process that the official CDs use
<ebroder> And I have no idea where to start looking
<achiang> oh, i don't know what process the official CDs use, but you could probably start with apt-cache show live-helper
<lamont> ebroder: it's not pretty. nor does it port well
<lamont> https://help.ubuntu.com/community/LiveCDCustomization <-- ebroter
<lamont> ebroder: even
<lamont> the livecd-rootfs package builds the ugly mess that is the root filesystem.  while nearly unreadable, that bit is pretty straight forward.  replacing that rootfs on the CD is the easiest way to go for mass changes.  the scriptage to take the livecd rootfs and wrap an iso around it is, um, yeah.  I've avoided learning anymore about that than I have had to.
<ebroder> Ok, that's helpful. Do you know where the code to transform the rootfs into an iso is?
<ebroder> (is it in livecd-rootfs?)
<knittl> hi. does anybody know what "status 5" of ureadahead is?
<knittl> booting works fine, but ureadahead terminates instantly upon boot
<knittl> and i can't find proper documentation of ureadahead termination status codes either
<chughgaurav_> I know Java , can I contribute  in the development of Ubuntu ?
<jbebel> Is there anything that can be done to accelerate an archive.ubuntu.com packages file update?
<jbebel> Lucid isn't installable using d-i right now.
<jbebel> because linux-meta depends on a kernel that doesn't exist in the Packages file, though it is in the pool.
<jbebel> I'd also like to know why linux-meta was published 6 hours before the kernel it depended on.
<jbebel> Looks like i made it in now.
#ubuntu-devel 2010-07-24
<bigon> I guess xulrunner could be givenback on armel
<knittl> where is ubuntu1 syncdaemon started?
<ari-tczew> cjwatson: are you interested in merging clock-setup and finish-install? if not, I'm going to do it.
<ari-tczew> cjwatson: I've emailed you with this question.
<ximion> hi!
<ximion> does someone know how frequently the packages.ubuntu.com sites are updated?
<ximion> if is search for http://packages.ubuntu.com/search?keywords=geogebra&searchon=names&suite=maverick&section=all
<ximion> i get no results altough the package is in Ubuntu.
<ximion> => https://edge.launchpad.net/ubuntu/+source/geogebra
<sense> What is the difference between the use of {} and () for variables in Makefiles?
<ScottK> ximion: p.u.c is generally updated quite regularly, but there's an issue with Maverick at the moment, so the Maverick information is totally out of date.
<ximion> ScottK: Thanks for the information!
<Cheery> Bypassing Xorg has been likely around before, but I did a question: http://stackoverflow.com/questions/3326641/opengl-without-x-org-in-linux
<Cheery> but then.. you are likely looking for answer into that. otherwise ppl would have been done it lot times before.
#ubuntu-devel 2010-07-25
<xaver> slangasek: hello
<xaver> somebody told me you work on mountall too. i have some trouble since 2.13
<weedar> could lots of "Ubuntu Archive Auto-Sync" changelog-entries in Launchpad mean that the package was without a maintainer?
<nhandler> weedar: Do you mean without a Debian maintainer?
<weedar> nhandler: Well, no, the package I'm thinking of is openbios-sparc and I noticed only auto-sync entries in the changelog - The maintainer according to launchpad is the same as the maintainer in Debian
<nhandler> weedar: Yeah, most packages in Ubuntu don't have their own maintainer (like in Debian).
<weedar> nhandler: I initally thought it meant that the package just came straight from Debian, without anyone checking to see if it worked. I also wondered about the link under "Uploaded by", here: https://launchpad.net/ubuntu/+source/openbios-sparc/1.0-1
<weedar> It is a link to https://launchpad.net/~katie which doesn't exist. That is why I thought katie was the old maintainer for Ubuntu and that after she deleted her account all the links turned into "auto-sync"
<nhandler> weedar: Yeah, that is what the Auto-Sync means. The Debian version was automatically uploaded to Ubuntu without any changes.
<nhandler> That is how most packages wind up in Ubuntu
<ari-tczew> slangasek: I sent an e-mail to you for sponsoring request 2 merges - bug 609634 and bug 609620
<ubottu> Launchpad bug 609634 in fetchmail (Ubuntu) "Merge fetchmail 6.3.17-4 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/609634
<ubottu> Launchpad bug 609620 in exim4 (Ubuntu) "Merge exim4 4.72-1 (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/609620
<weedar> nhandler: In this case the package (openbios-sparc) provides bios rom blobs for sparc32 and sparc64, could I change it so the Ubuntu package only provided the sparc32 rom (since compiling for sparc64 seems impossible right now) or would I have to ask the Debian maintainer to change it in Debian?
<weedar> Or is there yet an alternative; That I could provide a openbios-sparc32 package and propose it replace openbios-sparc in universe, since the existing openbios-sparc source package fails to build and there is no install candidate for openbios-sparc?
<weedar> I'm sorry if my question(s) was/were poorly worded - I'm just trying to understand the "politics" behind Ubuntu packaging :-)
<robertzaccour> hey yall i got a question
<robertzaccour> will the libtheora bug be fixed in time for maverick?
<bilalakhtar> Someone, please sponsor fix for bug #155930
<ubottu> Launchpad bug 155930 in synaptic (Ubuntu) ""Unmark all" clears the package list (!)" [Low,In progress] https://launchpad.net/bugs/155930
<bilalakhtar> BlackZ: please sponsor bug #604910
<ubottu> Launchpad bug 604910 in uswsusp (Ubuntu) "Please merge uswsusp 0.8-1.2 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/604910
<bilalakhtar> lifeless: are you a core-dev ?
<lifeless> bilalakhtar: please let the queuing process do its job; I know its higher latency than we'd all like, but it does let people get in the flow of what they are doing.
<bilalakhtar> lifeless: I have been waiting for weeks
<bilalakhtar> lifeless: I completely understand you people are busy and there is a lack of sponsors
<BlackZ> bilalakhtar: is it urgent?
<bilalakhtar> BlackZ: not very much, but
<bilalakhtar> During the wait, a developer will push a new version of a package, thus forcing me to update my patches
<micahg> bilalakhtar: what's wrong with that?
<bilalakhtar> micahg: nothing, just mentioning
<bilalakhtar> sorry micahg
<micahg> bilalakhtar: well, you would then propose another merge anyway, right?
<bilalakhtar> micahg: yup
<micahg> bilalakhtar: so, since the queue is long, you're saving sponsorship time by keeping the merge up to date :)
 * bilalakhtar is doing exactly what he and micahg are discussing
<BlackZ> bilalakhtar: be patient, I think somebody will sponsor your upload but it can take weeks too. I can't look at it right now, sorry
<bilalakhtar> BlackZ: ok, I came here as FF is approaching. Won't trouble you devs anymore
<BlackZ> bilalakhtar: if the merge is requested before the FF it will not need an FFe
<BlackZ> s/an/a
<bilalakhtar> BlackZ: really? O_o Thanks for the info. I will be more patient from now onwards
<iceroot> hi
<iceroot> maybe you can help me with this. what is supported 5 years in the lts server-edition? the default installed packages? everything? everything expect ubuntu-desktop? everything expect using a gui? so what about the package vim? is it supported 3 or 5 years for example
<nigelb> doko_: whats your take on bug 13371?  Is the patch worth it?
<ubottu> Launchpad bug 13371 in bittorrent (Ubuntu) "Too many files opened at once" [Medium,Incomplete] https://launchpad.net/bugs/13371
<directhex> iceroot, for any package, try "apt-cache show packagename | grep ^Supported"
<directhex> someone made a list of everything via grep-dctrl. was it Laney?
<Laney> yeah
<Laney> http://orangesquash.org.uk/~laney/supported-5y
<Laney> guess the rest of the urls
<micahg> doko_: I think the recent gcc change might be preventing xulrunner from building on armel, I haven't set up a local environment yet to test with, but there was almost no difference between 1.9.2.7 which built and 1.9.2.8 which didn't
<directhex> micahg, so test-build 1.9.2.7 on a recent environment?
<micahg> directhex: good idea :)
<directhex> that's why i get paid the big bucks
<un214> what can be done about absolutely bogus dependencies?
<kees> apachelogger: hi! you around? your rekonq crash bug -- what kernel version were you running?
<kees> apachelogger: (in theory, it should be fixed already...)
<ari-tczew> does anybody works on merge cdbs and debhelper?
<ari-tczew> devscripts
<ari-tczew> thanks for respons
<MattJ> $ file /usr/share/backgrounds/warty-final-ubuntu.png
<MattJ> /usr/share/backgrounds/warty-final-ubuntu.png: JPEG image data, JFIF standard 1.02
<MattJ> Does that not strike anyone else as wrong? :)
<ion> mattj: The only wrong thing is the original decision on a filename like that that canât be changed later. :-P But filenames are just for humans. As far as computers are concerned, everything could be just an anonymous inode.
<MattJ> Yes, maybe... though eog refuses to open it
<MattJ> otherwise I wouldn't have noticed
<ion> Then there is a bug in eog. No software should base its decision of file type solely on the filename.
<crimsun_> MattJ: that's bug 172416
<ubottu> Launchpad bug 172416 in eog (Ubuntu) "eog determines image type from filename" [Low,Triaged] https://launchpad.net/bugs/172416
<MattJ> crimsun_: Ah ok, thanks :)
#ubuntu-devel 2011-07-18
<didrocks> good morning
<pitti> Good morning
<sladen> morgen pitti
<pitti> hey sladen, how are you?
<sladen> pitti: admiring the weather (dull), and my todo list (similar ;-)
<buxy> pitti: any way to get the apport retracer to do its work for https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/807845 ?
<ubottu> Ubuntu bug 807845 in dpkg (Ubuntu) "dpkg crashed with SIGSEGV in debsums" [Undecided,New]
<pitti> buxy: that's on my list today; the retracers crashed due to a fakechroot problem again
<buxy> ok, thanks
<dupondje> pitti: thanks for cups apparmor fix :D
<geser> good morning
<dholbach> good morning
<pitti> hey dholbach, guten Morgen
<pitti> dholbach: UDW all cut and dried now? *hug*
<dholbach> pitti, yep - I'll start writing the summary now, so you can see what other than your session happened :)
 * dholbach hugs pitti back
<pitti> cjwatson: if you dd a current iso to an USB stick, the device/partition headers look strange; blkid thinks that both sdb1 and sb are a mountable iso9660 file system
<pitti> cjwatson: and indeed that's right, as you can mount either of them
<pitti> cjwatson: but which one is the "right" one to automount if you plug it into a running ubuntu system?
<pitti> or doesn't it matter really?
<pitti> didrocks: ^ FYI
<jhunt_> pitti: Morning! FYI, my upstart fix for /run is failing in the test phase. Looks like a change in dbus behaviour in oneiric.
<pitti> hey jhunt_
 * jml waves
<RAOF> slangasek: Is there any chance that debhelper compat 9 could make substituting DEB_HOST_MULTIARCH less of a pain in *.install,*.{pre,post}{inst,rm},*.links, etc?
<pitti> jhunt_: you mean it doesn't actually pick up the things in /run/initramfs/ ?
<RAOF> jml: Hello!
<pitti> jhunt_: I tested it with the symlink and bootchart, and it seemed to work
<jml> RAOF: hi
<jhunt_> pitti: no, sorry. it just means that the "build" fails for upstart in the test phase. I believe -- as you say -- that the code change itself should work fine.
<jhunt_> pitti: we now get this error from dbus in a chroot: "Unable to autolaunch a dbus-daemon without a $DISPLAY for X11'"
<jhunt_> pitti: problem relates to starting an app using a session bus I believe. But this is different behaviour to natty.
<pitti> jhunt_: strange that this is related to the "check /run" change; or isn't it?
<jhunt_> pitti: it's not related to that change, but I can only presume the archive builds do not occur in a chroot env otherwise we wouldn't have a build of upstart for oneiric.
<pitti> we do have build chroots, but perhaps they are tweaked enough
<jhunt_> pitti: ok. I'd really like to understand what is being tweaked. Who would be the best person to talk to about that?
<pitti> jhunt_: probably lamont or infinity
<jhunt_> pitti: ah yes, thanks!
<cjwatson> pitti: IIRC the partition table is set up such that it doesn't matter
<cjwatson> RAOF: beware, controversy.  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614731
<ubottu> Debian bug 614731 in debhelper "support for env var substitutions in .install (helps multiarch)" [Wishlist,Open]
<RAOF> â¦and it just peters out.
<cjwatson> RAOF: but in a way that promises doom if we try to change it Ubuntu-specifically
<doko> did make the mistake to update the desktop to oneirc this weekend :-(
<doko> - context menu in firefox is broken, pop's up and I can't select anything
<doko> chrisccoulson: ^^^
<doko> - how do I change my workspace from 2x2 to 4x1?
<chrisccoulson> doko - known compiz bug
<doko> - how do I change the monospace font settings?
<chrisccoulson> doko - it will work again if you focus another window and change it back again
<chrisccoulson> (it's also broken in natty though)
<doko> didn't had to use it in natty ;p
<doko> seb128: ^^^
<seb128> doko, dunno about the compiz bug, you can change the workspace layout in ccsm
<pitti> doko: gnome-tweak-tool has the font settings now
<seb128> the font in dconf-editor
<seb128> gnome-tweak-tool depends on gnome-shell though, which is a bit over what you want to install to tweak a setting
<doko> seb128: ccsm?
<seb128> doko, it's a command
<seb128> it's from compizconfig-settings-manager if you don't have it installed
<doko> seb128: hmm, still can't find it in ccsm
<seb128> doko, click on the tools icon "option..." in the first category
<seb128> doko, it's the tab 5 in this dialog (need to scroll tabs to reach it)
<pitti> cjwatson, didrocks: ah, I found out why dd'ed isos don't show up in GNOME: they have partition type 0x17, which is "Hidden IFS (e.g., HPFS)"
<pitti> these are ignored
<didrocks> pitti: oh, so the behavior is expected, it's at least a start :-)
<pitti> well, FSVO "expected"
<didrocks> right
<pitti> didrocks: the raw device is ignored because there is a partition, to work around that common breakage with unclean first sectors
<doko> seb128: ok, found it, but changing this doesn't have any effect
<pitti> and the partition is hidden by udev rules to avoid showing recovery partitions
<doko> or do I need to restart compiz?
<pitti> tricky
<seb128> doko, are you sure you are running unity-3d?
<seb128> doko, ps ax | grep compiz?
<didrocks> pitti: urgh, indeed
<doko> seb128: apparently, I don't
<seb128> doko, ok, that probably explain why it doesn't work
<doko> seb128: so how to change that in unity-2d?
<seb128> try running compiz --replace or unity and see what if it complains and about what
<seb128> doko, what videocard and driver do you use?
<seb128> 3d should work if it worked in natty...
<doko> seb128: Intel GM965/GL960
<seb128> doko, does running "unity" works?
<brendand> anyone know why i might be getting 'unable to load addon translations' when doing debuild in Oneiric?
<brendand> what am i missing?
<doko> seb128: it did log me out, after reboot, the 4x1 setting works
<doko> but it's horrible to get there
<seb128> doko, right, ccsm is not a nice ui
<seb128> it might be worth trying ubuntu-tweaks
<seb128> http://ubuntu-tweak.com/
<doko> chrisccoulson, seb128: not sure, if that's known too ... typing less in a terminal, quitting with q, doesn't show you the scrollbar anymore :-/
<jjardon> Hi, Is there any chance to package glade 3.8 for oneiric?
<jjardon> Currecty the only available version is 3.10, but this version doesnt have libglade support
<jjardon> (3.8 and 3.10 are parallel instalables)
<seb128> jjardon, isn't libglade deprecated for years?
<jjardon> seb128: yes, but we need it to port applications that still using libglade
<seb128> jjardon, well I guess the old glade could be packaged if somebody has enough interest to work on that, it's not a priority though
<dupondje> StevenK: https://launchpad.net/ubuntu/+source/guile-gnome-platform/+changelog => Any idea why you added the ubuntu delta? Its long time ago, but you never know :p
<tkamppeter> hi, thunderbird stopped working completely for me, I get
<tkamppeter> GLib-GIO-ERROR **: Settings schema 'apps.gecko-mediaplayer.preferences' is not installed
<tkamppeter> Trace/breakpoint trap   (core dumped) thunderbird
<tkamppeter> Is this known?
<tkamppeter> chrisccoulson, hi
<chrisccoulson> hi tkamppeter
<tkamppeter> chrisccoulson, it seems that thunderbird is generally not working any more. I get
<tkamppeter> GLib-GIO-ERROR **: Settings schema 'apps.gecko-mediaplayer.preferences' is not installed
<tkamppeter> Trace/breakpoint trap   (core dumped) thunderbird
<chrisccoulson> that's not a thunderbird bug
<tkamppeter> chrisccoulson, is this known?
<chrisccoulson> nope
<chrisccoulson> that's caused by a plugin you've got installed (gecko-mediaplayer)
<chrisccoulson> (just a guess, going on the schema name)
<tkamppeter> chrisccoulson, so seems to be best to uninstall that plugin?
<chrisccoulson> tkamppeter, yeah
<tkamppeter> chrisccoulson, that's it, thunderbird is working again. Thank you.
<chrisccoulson> tkamppeter, no problem. i'll get that fixed, as i guess it also stops firefox from starting too
<tkamppeter> chrisccoulson, OK, is this bug 812053?
<ubottu> Launchpad bug 812053 in gecko-mediaplayer (Ubuntu) "Latest gecko-mediaplayer update in Oneric causes all browsers to crash" [Undecided,New] https://launchpad.net/bugs/812053
<chrisccoulson> tkamppeter, yeah
<chrisccoulson> how on earth there was ever an upstream release of this is beyond me, there's no schema file anywhere in the upstream source
<chrisccoulson> so it could never have worked for anybody
<tkamppeter> chrisccoulson, thanks. I have added a comment and a "me too" to that bug.
<chrisccoulson> tkamppeter, oh, i think we commented at the same time ;)
<Daviey> stgraber / Laney: people with PPU should be in ~ubuntu-dev, right?
<Laney> Daviey: yeah
<Daviey> Laney: ~serge-hallyn has PPU but not in ~ubuntu-dev
<Laney> alrighty
<Laney> done, thanks
<Daviey> rocking, thanks Laney
<Laney> "This is the team of developers who work on Ubuntu. They are called the "Masters of the Universe" because historically they were responsible for the long tail of packages outside the core of the OS."
<Laney> err, think not
<Daviey> Laney: I've never understood the logo either :)
<StevenK> dupondje: I can't recall, sorry. Intrepid was a *long* time ago.
<StevenK> dupondje: I suspect it was a FTBFS fix. If it builds without it, drop it.
<jdstrand> pitti: hey, I saw the changes to the cups profile for bug #812035. I'm not sure what is put in /run/samba by samba itself, but it seems like giving cups rw access to all of /run/samba/** might be too lenient
<ubottu> Launchpad bug 812035 in cups (Ubuntu) "Cups needs access to /run/samba/" [Undecided,Fix released] https://launchpad.net/bugs/812035
<jdstrand> pitti: what is cups trying to do with it and what does samba put in there?
<pitti> jdstrand: you think it might be enough to give it write permissions for /run/, to create the dir?
<pitti> the bug report had a denied privilege of 'c', which is undocumented
<pitti> seems to map to an mkdir call
<pitti> jdstrand: but apparently cups is trying to mkdir /run/samba/
<jdstrand> pitti: well, that is just it-- I don't know what cups is trying to do. '/run/samba/ rw,' would solve the immediate error, but I don't know if more would then come out after
<jelmer> it seems wrong for cups to look at /run/samba in either case, as the location of that directory can be changed in the samba configuration
<jdstrand> if it operates correctly without it, then maybe use 'deny /run/samba/ w,'
<jdstrand> that would silence the error
<jdstrand> (but make it harder to diagnose if the access was actually needed)
<pitti> jdstrand: thanks; I'll ask in the bug
<jdstrand> pitti: cool, thanks
<pitti> dupondje: ^
<pitti> asked in bug 812035
<ubottu> Launchpad bug 812035 in cups (Ubuntu) "Cups needs access to /run/samba/" [Undecided,Incomplete] https://launchpad.net/bugs/812035
<cjwatson> oh, bah, designing an interface that requires a function to be called when one fd is ready for reading *and simultaneously* another fd is ready for writing is probably not very select-friendly, is it
<dupondje> pitti: jdstrand: I added a remote printer on a SMB share
<dupondje> that caused to pop the error in dmesg
<dupondje> But printing worked!
<pitti> dupondje: ah, thanks
<pitti>   deny /{,var/}run/samba/ rw,
<pitti> jdstrand: ^ so that should do it?
<dupondje> I also searched the network
<dupondje> for printers
<dupondje> not on my computer at home atm
<dupondje> so can't test what action it was exactly :)
<dupondje> But 'search network printer' failed I think
<dupondje> 'Find Windows printer on SMB share' worked
<dupondje>  can test that again if you want
<ion> I take it dmz-cursor-theme wasnât dropped from ubuntu-desktop intentionally?
<jdstrand> pitti: it sounds like a reasonable start
<jdstrand> dupondje: please file a bug if printing to that printer gets weird if we update the profile to explicitly deny
<dupondje> i'll do :)
<RoAkSoAx> kees: howdy! I was wondering if you have an ETA on when will bug #800403 be reviewed?
<ubottu> Launchpad bug 800403 in resource-agents (Ubuntu) "[MIR] resource-agents" [Wishlist,New] https://launchpad.net/bugs/800403
<Laney> kirkland: are you aware that divitup's ssl certificate has expired?
<kirkland> Laney: i am, will get that fixed ;-)  I'm moving it to godaddy
<Laney> :-)
<kirkland> Laney: thanks for the reminder!  will get that ssl cert on order today
<Laney> np
<cr3> soren: thanks for copy-ppa-pkg.py in your ubuntu-archive-tools branch, came in very handy today
<bjf> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #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: bjf
<tkamppeter> mpt, hi
<worstadmin> So the guy says to me "Are you *suuure* that you aren't an actor" ohaha that's right Mr. Giraffe get all the marmalade.
<roadmr> hi folks, I have a source tree and when I debuild -S, the .tar.gz is huge because it's including .bzr, how should I invoke debuild so .bzr gets ignored/excluded?
<micahg> roadmr: use bzr-builddeb
<jamespage> lamont: ping re aspectj manual bootstrap build
<micahg> I have lm-sensors which is replacing lm-sensors-3, should I -v to the last lm-sensors upload or the last lm-sensors-3 upload?
<roadmr> micahg: excellent, a simple answer for a newbie question :) works like a charm, thanks!
<jono> didrocks, was it you who I spoke to at the Rally about the Qt Creator Design bug being fixed?
<didrocks> jono: I think we didn't speak about it together, but I clearly tried to figure out why there was this bug and know it will be fixed for Oneiric :)
<didrocks> jono: basically, step 1 is there, still need a new qt creator sync from debian + a small patch (but need new qtwebkit first)
<jono> didrocks, oh, cool, someone told me there was a fix and it was going in the week after the Rally
<jono> was just curious :-)
<didrocks> jono: right, but new qtwebkit came into the dance between :-)
<jono> didrocks, aha!
<jono> good times
<jono> lol
<didrocks> of course :-)
<didrocks> jono: I'll ping you once it's done (I have it working locally fyi)
<jono> thanks so much didrocks, you rock, as usual :-)
<didrocks> thanks :-)
<pdtpatrick> There are no plans in the making to be able to suppress the unity dock to the left are there?
<lamont> jamespage: see the portal
<lamont> I saw it's waiting for me, slim chance today, better chances tomorrow
<jamespage> lamont: great - thanks
<slangasek> RAOF: debhelper multiarch substitutions: there was a bug report requesting such a facility for debhelper (at least for .install, .links files, not for maintainer scripts), but there is unlikely to be progress soon on getting this merged
<jdstrand> dholbach: hi! fyi, I have created a wiki page for the security team's packages of the week: https://wiki.ubuntu.com/SecurityTeam/HighlightedPackages. Currently this is being importated into our GettingInvolved page (https://wiki.ubuntu.com/SecurityTeam/GettingInvolved#Fix_security_bugs)
<dholbach> jdstrand, awesome! I'll write about it tomorrow
<jdstrand> dholbach: it is also something that will be mentioned in our weekly irc meetings
<dholbach> that's awesome
<jdstrand> dholbach: thanks for your ideas/help with all of this :)
 * dholbach hugs jdstrand
 * jdstrand hugs dholbach back :)
<dholbach> :-D
<bdmurray> cjwatson: I was thinking about making an apport package hook for memtest that'd direct some bugs to grub2 since a lot of failures occur with the syntax of grub files
<Phr3d13> i know this isn't support, but can someone help me with my problem? trying to get a via vt6410 pci raid/ide card to see the drives attached to it, running ubuntu 11.04
<stgraber> geser: ping?
<ikonia> Phr3d13: if you know it's support why are you asking
<ikonia> Phr3d13: you've had the issue explained to you in #ubuntu before you got banned, so please don't bring support here
<Pici> 14:38:34 <Phr3d13>
<Pici> oops
<Phr3d13> my bad, just trying to get a better answer than ask via and "it isn't supported", sorry
<serue_> i didn't know there was 'submittodebian!'
<serue_> neat
<bdmurray> slangasek: do you know what 'Bus error' means in bug 790869?
<ubottu> Launchpad bug 790869 in eglibc (Ubuntu) "package libc-bin 2.13-0ubuntu13 failed to install/upgrade: subprocess installed post-installation script returned error exit status 135" [Undecided,New] https://launchpad.net/bugs/790869
<slangasek> bdmurray: I do, but how it happens there is a mystery :)
<slangasek> bdmurray: "bus error" is the signal when something tries to do unaligned memory access and the CPU rejects it; this doesn't happen on x86
<infinity> Yeah, I was just scratching my head at that.
<slangasek> (because the CPU never rejects it)
<slangasek> bdmurray: so we would need to reproduce this and catch a backtrace of the failing process to actually diagnose
<infinity> Maybe someone helpfully added alignment traps to the i386 kernel and it throws sigbus? :P
<slangasek> that would be excellent :)
 * micahg tries to ask his question again
<micahg> I have lm-sensors which is replacing lm-sensors-3, should I -v to the last lm-sensors upload or the last lm-sensors-3 upload?
<slangasek> micahg: what do you mean by "-v"?
<micahg> slangasek: debuild -v, to get the changelog entries in sources.changes
<slangasek> oh
<broder> other than bookkeeping, what's actually affected by that? LP closer detection?
<infinity> slangasek: Apparently, SSE* instructions can SIGBUS.
<slangasek> infinity: oh, woot!
<slangasek> micahg: I would use the last lm-sensors version
<micahg> broder: probably nothing, just wondering if people have any opinions
<slangasek> because there's a separate lm-sensors-3 package in the archive with a separate changelog
<micahg> slangasek: right, so lm-sensors-3 is being dropped from Debian with lm-sensors taking over again
<infinity> slangasek: Still pretty unhelpful to know without a backtrace, mind you.
<micahg> slangasek: it's essentially a source rename to a previously used source
<infinity> bdmurray: I have a sneaking suspicion that with the bug being 2 months old, you won't be able to ask the reporter if his system is still hosed and get him to backtrace ldconfig in gdb, but that would be nice. :P
<slangasek> micahg: yeah, I understand... I guess my answer might depend on what the changelog for this package actually looks like :)
<micahg> slangasek: I can pastebin the two options :)
<infinity> bdmurray: It's equally likely that it was a transient toolchain issue that's since been resolved and rebuilt, mind you.
<slangasek> micahg: so I think I actually don't care enough to load the links if you do ;)
<micahg> slangasek: k, it's only ~200 lines against the last lm-sensors upload, so not so bad, thanks
<awkisopen> How the heck are you guys gonna fix 54 bugs before the 29th
<roadmr> ... by averaging 4.909 a day :)
<awkisopen> .909? I guess the other .091 is committing
<micahg> awkisopen: patches welcome :)
<awkisopen> someday I'll figure out a way to give back to Ubuntu, I swear
<infinity> awkisopen: Cookies.
<slangasek> not that I think 54 bugs between now and the 29th is unrealistic, but I don't know what 54 bugs you're talking about or why the 29th is a deadline :)
<slangasek> so what's special about the 29th?
 * charlie-tca was wondering that too
<infinity> slangasek: You weren't planninh on having a "6 days before Alpha-3" party?
<infinity> slangasek: Cause I already bought balloons and sparklers.
<stgraber> ;)
<slangasek> infinity: actually that was the day I was going to prove upstart is better than systemd, didn't realize there was a party that day - perhaps I'll have to juggle my schedule
<awkisopen> Isn't the 29th when 10.04.3 comes otu?
<awkisopen> *out, even
<awkisopen> That's what I was referring to, anyway
<infinity> That's the 21st, in theory.
<awkisopen> https://launchpad.net/ubuntu/+milestone/ubuntu-10.04.3 says "expected: 2011-07-29"
<infinity> Oh, fair enough.  Perhaps someone juggled it.
<stgraber> awkisopen: https://wiki.ubuntu.com/LucidReleaseSchedule says 21st
<awkisopen> oh no now I'm confused :(
<awkisopen> I had my calendar marked for the 29th for months
<awkisopen> I'd be thrilled if it were indeed only 3 days from now
<sconklin> slangasek: any thoughts on what might be behind this? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/811999
<ubottu> Ubuntu bug 811999 in linux (Ubuntu Natty) "package linux-image-2.6.38-10-generic (not installed) failed to install/upgrade: subprocess dpkg-deb --fsys-tarfile returned error exit status 2" [Undecided,New]
<sconklin> there are more than just that one, possibly all duplicates
<bdmurray> sconklin: I've been cleaning those up
<bdmurray> sconklin: its something wrong with the .deb on the user's system
<infinity> dpkg-deb (subprocess): data: internal bzip2 read error: 'DATA_ERROR'
<infinity> Definitely corruption or a short file, but...
<infinity> Ew.
<sconklin> ok. Well, here's a list to start with - sorry there are two of each one. Scripting bug.
<sconklin> http://people.canonical.com/~sconklin/reports/regressions.html
<sconklin> almost all the Natty ones appear to be this problem
<bdmurray> sconklin: okay, i'll take care of them
<infinity> We could do a better job of verifying files before apt calls dpkg, surely?
<slangasek> awkisopen: ah yes, I suspect the milestone in launchpad didn't get updated when the schedule changed; it's unfortunately not somethign that tends to be at the forefront of people's minds.  As for 54 bugs, most of the bugs linked from the milestone are already fixed or "fix committed" (meaning the SRU is pending final publication), and a number of the others will likely not make the deadline.
<slangasek> infinity: maybe we do now, and didn't then?
<awkisopen> slangasek: Cool. I was wondering how it all worked. So you're saying it's likely that 10.04.3 is coming out on the 21st?
<infinity> slangasek: Yeah, things are probably much improved since yesterday when the bug was filed. ;)
<slangasek> infinity: it was filed against natty :P
<infinity> (I know)
<slangasek> actually, I guess that means it's unlikely to have been fixed since, doesn't it
<slangasek> it is strange to have an uptick in such reports in natty
<infinity> Well, it could be symptomatic of something else going pear-shaped (filesystem drivers, network issues, or heck, maybe some massive ISP just started doing broken transparent proxying six months ago)
<infinity> But none of that changes that we should probably be doing at least trivial checks on downloaded debs before passing them off to dpkg.
<doko> bdmurray: bug #812507, people start to translate the -fsys-tarfile :-(
<ubottu> Launchpad bug 812507 in openjdk-6 (Ubuntu) "package openjdk-6-jre-headless 6b22-1.10.1-0ubuntu1 failed to install/upgrade: defektes Tar-Dateisystem - Paketarchiv ist defekt" [Undecided,New] https://launchpad.net/bugs/812507
<bdmurray> doko: hrm
<geser> persia, maco: a status mail how far we are with ArchReorg would be helpful, I don't know either what the next step would be
<maco> agreed
<maco> we have package sets!  ....the end
<maco> all i got
 * persia wants to wait until after the DMB meeting is over, and there has been a chance to renew hydration, and then will blather for a bit (but I'm unprepared, so I may not be able to give entirely authoritative answers)
<slangasek> doko: doh.  Can you file a bug on the translation for that?  Since obviously commandline arguments shouldn't be translated
<geser> persia: no problem (and no hurry), I would be happy to even get some unauthorative answers
<doko> slangasek: hmm, which package
<dupondje> What happends with the idea to have a 'testing' repo in Ubuntu ?
<persia> dupondje: Someone raises it every couple years, and then it never happens.
<slangasek> doko: I don't know, I figured you're in a better position to work that out than I am since you might actually have german language packs installed :-)
<persia> The original setup has some philosophical basis that I've forgotten, but nobody has yet put up a strong enough arguments to overcome inertia (if that can be done)
<infinity> doko: looks like dpkg.mo to me.
<doko> slangasek: well, maybe ... the language packs itself don't help much
<persia> maco, geser: So, ArchiveReorganisation has two aspects: Permissions and Components.
<persia> Permissions: https://wiki.ubuntu.com/ArchiveReorganisation/Permissions
<infinity> (or so says "grep -r fsys-tarfile /use/share/locale")
<persia> This is largely done, except that is a need for Soyuz to grow a default packageset, and to stop using components as part of Ubuntu permissions.
<infinity> slangasek: And "I have no langpacks" isn't much of an excuse, dpkg is fully translated without. :P
<persia> There was a UDS spec about it, and jml wrote up some notes, and someone needs to review the notes, file some bugs, file an LEP, and set aside some time to help implement it.
<geser> persia: do we have enough packagesets or need some more need to be created to cover what we currently have?
<persia> geser: More packagesets are useful if there are developers for them.
<slangasek> infinity: that message isn't in the de/dpkg.mo
<slangasek> infinity: at least not in oneiric
<persia> And some packagesets need cleanup work (the server set is particularly in need of gardening)
<infinity> adconrad@cthulhu:/usr/share/locale$ grep -r Tar-Dateisystem /usr/share/locale && dpkg -S /usr/share/locale/de/LC_MESSAGES/dpkg.mo
<infinity> Binary file /usr/share/locale/de/LC_MESSAGES/dpkg.mo matches
<infinity> dpkg: /usr/share/locale/de/LC_MESSAGES/dpkg.mo
<infinity> slangasek: Probably fixed already, then.  It's there in natty.
<persia> Components: https://wiki.ubuntu.com/ArchiveReorganisation/Components
<slangasek> infinity: false positive, do it properly with msgunfmt :)
<geser> persia: should we continue to "push" people into package sets upload right where applicable?
<persia> THis is much less well along.  It needs identification of all the various uses of "main", and assurance that we have a solution that doesn't rely on "main" to move forward.
<persia> geser: Where applicable, yes.  Any specialist develolper team should probably have a packageset.
<maco> persia: do we need an "old-universe" package set so that the-people-formerly-known-as-motu can be grandfathered into their packages instead of losing them when they get added to xubuntu-desktop or whatever else?
<persia> I don't think we care if large chunks of the archive are outside packagesets, if some team to care for them doesn't organically appear.
<slangasek> infinity: the hits only translate the usage message for --fsys-tarfile, not the option itself (including in natty)
<persia> maco: At the UDS session, bigjools wanted that to be called "default"
<maco> i thought at UDS Dallas "motu take care of teh long tail  of not-in-a-packageset packages" was what was said
<maco> gosh was that dallas or barcelona? ....meh
<geser> persia: belong package sets to "Permissions" or "Components" or both?
<persia> maco: And MOTU are intended to lose access when things move into packagesets: if they want to keep working on those packages, they should join the relevant teams.
<infinity> slangasek: Oh, indeed.  That's a message about a corrupted archive.
<persia> Membership in many development teams should be an indicator that someone ought be core-dev.
<infinity> slangasek: The other one might be apt, come to think of it.
<cjwatson> bdmurray: sure ...
<persia> geser: Mostly permissions, although permissions was the largest of the meanings of "main" towards Components.
<persia> maco: Dallas
<micahg> cjwatson: got a minute?
<slangasek> infinity, doko: actually, the "subprocess dpkg --fsys-tarfile" message should *always* be untranslated, because it's the name+args of the process so dpkg never passes it to gettext for translation... so no bug here, I think
<slangasek> infinity, doko: the text message explaining what went wrong will be translated, but that's correct
<slangasek> msgid "corrupted filesystem tarfile - corrupted package archive"
<slangasek> msgstr "defektes Tar-Dateisystem - Paketarchiv ist defekt"
<persia> So, for components, I've done some of the research, and found "supported", "translated by rosetta", "receives priority attention by the security team", "undergoes security review", "undergoes code review", "undergoes maintainabilty review"
<geser> persia: the "Permissions" part moved forward with increased use of package sets, did the "Components" part moved forward too in the last months?
<bdmurray> so bug 797968 is the highest numbered bug I've found with "Bus error"
<ubottu> Launchpad bug 797968 in eglibc (Ubuntu) "package libc-bin 2.13-0ubuntu13 failed to install/upgrade: subprocess installed post-installation script returned error exit status 135" [Undecided,New] https://launchpad.net/bugs/797968
<cjwatson> dupondje: I'm pretty sure it will never happen.  I suggested it before Ubuntu was even created. :-)
<cjwatson> micahg: only if you warn me what it's about
<persia> I've also found a number of others which were nascent, and could be converted to packagesets before they got too far (like freeze definitions).
<persia> geser: I don't know of any work done in ArchiveReorganisation since March, which was me interviewing lots of stakeholders about "support".
<infinity> slangasek: Hrm.  So, we're just seeing a different return on that bug report?
<micahg> cjwatson: I uploaded lm-sensors, I thought it would be stuck in Binary NEW since it's a different source providing binaries, but it doesn't seem to be the case
<slangasek> infinity: maybe
<persia> I was unable to find an acceptable consensus, and am not personally working on AR for a while because that was frustrating.
<infinity> slangasek: (ie: not the "subprocess dpkg had a sad" return)
<micahg> cjwatson: I just don't want to break the world with a component mismatch
<cjwatson> micahg: https://launchpad.net/ubuntu/+source/lm-sensors/1:3.3.0-4ubuntu1 says it's accepted
<cjwatson> micahg: the only thing that goes through NEW is when the source/binary package name in question doesn't have an override
<cjwatson> LP doesn't care (much, and not at this level) if one source takes over another source's binaries
<persia> Oh, for Components, "mirroring" is another important thing to be sorted.
<geser> persia: so AR will stay in the current state until the pressure rises again to move it forward?
<micahg> cjwatson: ok, can you switch lm-sensors for lm-sensors-3 in core and promote to main?
<cjwatson> micahg: sure, tomorrow
<cjwatson> it won't break things tonight AFAIK
<persia> geser: As with everything in Ubuntu, if nobody works on it, nothing happens.
<micahg> cjwatson: ok, thanks, as long as it doesn't break stuff, I don't care much when it happens, thanks :)
<persia> I don't think it's fair for me to make a blanket statement about the progress of AR.
<maco> persia: by mirroring, do you mean the /pool/main/blahblahblah paths?
<geser> maco: more likely $country.archive.ubuntu.com
<persia> maco: Rather, that some mirrors have limited disk space and/or bandwidth.  We would need a way for mirrors to mirror packages based on packagesets or flavours, rahter than main/universe.
<maco> ah ok
<persia> geser: $CC.archive.ubuntu.com is always a full mirror, so those aren't as affected.  It's the smaller mirrors, private mirrors, etc.
<micahg> cjwatson: do I need to file any paperwork for this since it's just a source rename?
<cjwatson> no
<dupondje> Nobody happen to have a Intel Centrino Advanced-N 6230 ?
<micahg> dupondje: you might want to try askubuntu.com
<persia> geser: maco: Other questions, or do you feel you understand the current status to the degree you wish?
<geser> persia: thanks for the description of the current AR state, it really helped me to understand where we currently are with AR
<persia> geser: Please, feel free to ask my anytime.  I try to keep track of AR, and help new processes be AR-compatible, and really hope me taking a break doesn't mean we make no progress for a while.
<maco> persia: well, you said "help would be welcome"
<maco> persia: how do random non-canonifolk help?
<maco> i assume some stuff just plain requires IS involvement, for example
<maco> (which reminds me: omg the other day IS responded to an RT ticket the SAME DAY)
<persia> maco: You could pick up the Soyuz stuff where I left off (I'll dig up the detail status for you if you like).  You could interview folk for "support", but from my experience, I believe that needs Canonical folk.
<persia> (as I'd hate to share my frustration)
<maco> yeah uh....launchpad's code scares me
<nigelb> heh
<persia> Someone needs to tackle translations: understand the infrastructure, envision how it might work without "universe", write up an LEP and a blueprint for UDS.
<nigelb> it scares everyone who's touched it too.
<geser> I also get the impression that for a community member it's hard to help with AR in the current state as it needs planing through complete Ubuntu and also LP
<persia> Replacing MIRs is probably blocked by "supported".
<micahg> persia: there was a recent fix to allow translations for non-main packages in laucnhapd
<maco> persia: creating a "supported" package set just means poking cjwatson, though, doesn't it?
<maco> he seems to be keeper of the keys of packagesets
<sgnb> can someone here rebuild obrowser and ocaml-sqlexpr (with no changes, recompile with lwt 2.3.0-3)?
 * maco was surprised to learn the DMB cannot use edit-acl.py to add devs to packagesets after voting on them
<sgnb> bdrung: ^^^
<persia> geser: I've never found anything blocked because I'm not Canonical, although there are enough different Canonical stakeholders for "supported" that I'll admit I gave up.
<sgnb> (it should allow compilation of ocsigen)
<geser> maco: s/cjwatson/TB/ as any TB member can create package sets (if there is a consensus for the creation)
<cjwatson> there is a bit of packagesets that's currently SPOF me
<maco> SPOF?
<cjwatson> single point of failure
<persia> maco: It's more than packageset.  Currently "supported" is defined by a header in the Packages files, but doesn't actually represent a commitment by anyone (other than prioritisation by the Ubuntu Security Team) to actually provide any sort of "support".
<cjwatson> supported would be pretty hard to maintain as a single giant packageset
<maco> oh, so nothing to do even with canonical support contracts?
<cjwatson> but yes, the problem is a definitional one anyway
<persia> maco: There are notes on what is needed, and the code isn't much (add debtags support to Muon/Software Centre, define support in debtags, publish), but it first requires there existing lists of packages that are considered "suppoorted" by organisations, Canonical being the largest sponsor of Ubutnu Developers obviously is a priority stakeholder here.
<persia> maco: Support contracts by various entities (not just Canonical) is part of it, but it's complicated.
<geser> maco: you mean add PPU with edit-acl.py or add packages to an existing package set or add dev to the upload team of a package set?
<maco> geser: i think it was add PPU for a packageset to a dev
<maco> im not sure if that's the first or the third thing you said :P
<cjwatson> geser: any of the package sets that are automatically generated by seeds can only be extended (as in packages added to it) by me right now; fixing this is some kind of priority, along with everything else ...
<persia> I think this is a murky undefined corner of AR/Permissions.  My understanding is that the DMB is supposed to declare packagesets into existence, and that the Archive Admins are supposed to control which packages are in which packagesets.
<geser> don't we usually add a team which can upload the packages from that package set and the DMB can administer that team?
<persia> Oh, the DMB is also supposed to decide who has upload to which packagesets.
<cjwatson> granting a developer upload access to a package set should be doable by the DMB.  if you can give me a concrete example then I can investigate why
<cjwatson> geser: we haven't always bothered for small cases
<maco> cjwatson: its possible i was doing it wrong but let me try to find who it was
<persia> But this is inherited from N discussions in a changing landscape over the years (DMB didn'T exist when we agreed AA would chose which packages go where), and probably needs a dedicated new discussion to come to consensus.
<cjwatson> it is possible that "doable by the DMB" only works for the team-upload case
<maco> s/possible/likely/ :P
<cjwatson> but anyway the fundamental problem is that the DMB does not have any special status in LP, unlike techboard
<geser> persia: isn't package set creation TB land which was sort of delegated to DMB?
<dtchen> sgnb: done
 * geser checks the wiki
<micahg> well, IIRC, the DMB owns two packagesets which it should be able to make modifications to if I understand correctly
<cjwatson> and we sort of hacked around that by just saying "OK, the TB will do the mechanics for you on request"
<persia> geser: Yes, but nobody ever said anything about authority over the packageset contents.
<sgnb> dtchen: thanks!
<maco> cjwatson: it was John Rigby's application for the linux-linaro-* packages that i was trying to follow up on
<cjwatson> maco: if you can't do it, just mail it to the TB
<cjwatson> sorting it out any other way will be a long road :-/
<persia> Needs doing, but not anything we should block upon.
<maco> cjwatson: its been fixed now. was about a month ago. but i dont know whether i used edit-acl.py wrong or if its just not doable by dmb
<geser> maco: all we (the DMB) can do is add members to DMB-administered teams and add packages to DMB-owned package sets, the remaining task need to go to the TB
<maco> and i'm *pretty* sure my bash.history isnt that long
<maco> geser: ok
<maco> so should we make it a habit of making teams to match when we make new packagesets?
<persia> Considering that AA always took care of components, we probably ought adjust packageset change permissions to be union of DMB and AA or similar.
<cjwatson> yes.  but that is Hard.
<cjwatson> (AIUI.)
<persia> Unless we expect the DMB to take over regular migration of stuff for transitions, etc.
<cjwatson> maco: it's probably the most practical approach
<persia> cjwatson: It's hard to have a union of teams.  It's not hard to have a team with membership limited to AA+DMB that owns the packageset.  That said, it needs discussion and consensus before being done.
<maco> cjwatson: so then we just ask the TB "can you make packageset $name with packages x,y,z and permissions to $team" and then never have to bug you about that packageset again (for the most part...until it needs a new package)
<persia> When we approve a PPU, does this necessitate the creation of a packageset?
<maco> persia: we often vote to create a packageset if the set being requested seems reusable or is copied off someone else and is therefore obviously being reused
<persia> maco: Right, when there is a team.  My concern is that we grant packageset teams exclusive authority over packages unique to their packagesets (which is why packageset teams are required to have core-dev as a member).
<maco> persia: i did not know of this requirement
<micahg> persia: in terms of Archive Reorg, I don't think PPU should have a packageset
<persia> This is incompatible with our statement that we *do not* grant exclusive authority over packages for PPUs, once MOTU is implemented as the inverse of all packagesets.
<geser> maco: if the package set is DMB-owned (some are like mozilla, zope and some others) the DMB can add and remove packages from it once the TB created the package set
<persia> maco: Failure to abide by the requirement today has a low penalty, as Soyuz still supports component-based permissions.
<maco> so we're seeing graceful degradation
<persia> Although for *flavour* packageset teams, it has been strictly enforced, because it affects seed branches.
<maco> geser: i'm actually concerned with adding *devs* to it, not so much packages
<maco> i think adding devs is a hopefully-more-frequent occurance
<persia> maco: For PPUs, yes.  On the other hand, we're not actually granting most packageset teams what we promise we've granted them.
<maco> persia: packagesets arent supposed to be *totally* exclusive though right? because generalist is still supposesd to have access, except to restricted packagesets which would then only be core devs
<maco> is the restricted/unrestricted bit not implemented yet?
<persia> maco: No.
<maco> (or rather, only core devs + team members)
<geser> maco: package sets can overlap (and do it)
<persia> Restricted packagesets are supposed to be totally exclusive.  We should celebrate that our community is cooperative enough to not need any today.
<infinity> Wait, wait, wait.
<maco> kernel isn't restricted?
<infinity> Someone actually specced exclusive package sets?
<persia> Unrestricted packagesets are supposed to be exclusive to the packageset team (although packagesets can overlap, so specific packages may not be exclusive), which is why the teams are supposed to have core-dev as a member.
<infinity> Should I point out that this was the one huge problem I had with Maemo? :P
<persia> infinity: Yes.
<geser> maco, persia: wasn't the plan to "merge" core-dev and motu to generalist which have access to all package sets (except a few one like the kernel where even core-dev isn't enough)?
<persia> infinity: So, we don't have any today.  They are in reserve because some folk felt that we might have a social problem with some of the initial theories about implemenation of Archive Reorganisation.
<maco> https://wiki.ubuntu.com/ArchiveReorganisation/Permissions  <-i'm re-reading this
<persia> geser: Yes, there was a plan to make every MOTU core-dev.  Nobody executed the plan (athough cjwatson and dholbach did interview just about everyone towards implementing it).
<geser> persia: right, I remember that interview, was the result of it ever published?
<persia> geser: When the TB approved keeping MOTU as folk who specifically didn't have upload access to anything in any packageset, as a place for folk interested in general QA to play, that changed.
<maco> ok so reading that, generalist replaces core dev?
<persia> Masters of the Unseeded has considerably less upload authority than Masters of the Universe, but enough folk (including me) wanted it that we have it approved.
<micahg> It makes sense as there will still be a ton of packages that no one will explicitly care about
<persia> maco: I don't believe anyone currently still wants to rename "Ubuntu Core Developers" to "Ubuntu Generalist Developers", although that was once planned.
<persia> micahg: The alternate assertion is that everyone should be core-dev if they want to be a generalist.  I'm not convinced this makes it easy for new generalists to build reputation, but I'm not sure this opinion is consensus.
<micahg> persia: I think that raises the bar on who can be a generalist then which would hurt the part of the archive no one explicitly cares about
<persia> And just to be clear: I don't know of any "secret" discussions about AR that have happened since ~2008 (when there were some invite-only phone calls between the MC and TB).
<maco> micahg: i think the "no one explicitly cares" part is the Masters of the Unseeded, not the generalist
<persia> micahg: Then you share my opinion.  The counter argument is that we should be seeking to attract developers in areas where we have a demonstrated passion, and that once their skills are honed, it is safe to give them access to packages fewer people are watching.
<geser> isn't MOTU sort-of generalist too (currently)?
<micahg> maco: that's what I was commenting on, the necessity of that
<persia> geser: Yes.
<maco> geser: yup
<maco> geser: oh oh maybe its Novice Generalist and then core dev is Advanced Generalist? :P
<persia> In the original formulation of Archive Reorganisation, MOTU was to be abolished, and all current MOTU were to be strongly encouraged to become core-dev.  The new MOTU is entirely different than the old MOTU, except that it shares the name, and all historical members of MOTU were grandfathered as members initially (I thought I sent a long mail about this, entitled "Future of MOTU" back when the TB approved this)
<persia> maco: Err, no.  We don't want any semantics that imply that one category of developer is more "Novice" or "Advanced" than another.
<infinity> I honestly think trying to split those two roles is overengineering for a problem we don't actually have.
<persia> We're all "Ubuntu Developers", and anything else is just a reflection of our interests.
<persia> infinity: Which two roles?
<infinity> Debian's done fine for years with 1000 people who are essentially "core-dev", and they don't randomly upload GCC for the hell of it, though they CAN.
<cody-somerville> infinity, Its also much harder to become a DD.
<infinity> persia: Trying to have "people who care about lots of packages, but not core" and "people who care about core, but not lots of other packages", as if A or B will mess with each other somehow.
<infinity> cody-somerville: *shrug*... It's also simple to revoke privileges to someone who screws up a development release via touching things they don't understand.  And no one can screw up a stable release without it passing by several checks.
 * cody-somerville coughs.
<micahg> infinity: I think it's more about people that have demonstrated care for the archive, but not yet demonstrated ability with core packages
<persia> infinity: All true, and likely the basis for the argument that all generalists should be core-dev.
<infinity> micahg: People who care deeply about the archive will know if they shouldn't be touching glibc.
<cody-somerville> they might not know how to version an SRU though
<infinity> cody-somerville: And I know how to reject packages.  So?
<persia> infinity: As one of the folk involved in the ressurection of MOTU, our motivation was that there were lots of people who didn't feel they *should* be core-dev who were contributing useful random fixes to arbitrary packages.
<cody-somerville> infinity, the problem is when the archive admin doesn't know how to either and accepts it :P
<infinity> persia: Sure, I suppose there are people who don't want the "pressure" (?) of being allowed access to "scary stuff", but is it so hard for them to just refuse to upload those packages? :)
<infinity> persia: I don't upload toolchain bits on a whim, but I'm glad that I can when there's an emergency that requires it.
<infinity> cody-somerville: Not a team/permissions problem then, but an AA problem.
<infinity> cody-somerville: (And when that happens, please bring it up, so we can hunt down the offending AA and make sure we're all on the same page)
<sladen> I think peer-pressure mainly deals with the occasions when you do an upload and screw up.  The permissions are somewhat of a technical solution to a social problem
<persia> sladen: Yes, indeed. *but* given the history of Ubuntu, there was also a fair amount of social identity wrapped around "MOTU", which then members were unhappy about having removed when it was announced that MOTU would be no more.
<infinity> sladen: Jinx.  I just used "technical solution to a social problem" in a /msg to persia. ;)
<persia> infinity: Yeah, well.  I'm not sure we don't do well to cater to the inconfident.
<slangasek> I am going to burn that phrase in effigy
<slangasek> there are lots of social problems that should be solved with technical solutions
<slangasek> (I have not read the scrollback so I have no idea whether it's appropriate here, but grrr that makes me mad :)
<infinity> slangasek: Heh.
<infinity> slangasek: I agree that there are plenty of social problems that are readily solved by technical means.  Just not sure the current discussion is about one of them. ;)
<persia> slangasek: As with every use, it is both appropriate and not.
<infinity> Well, the current meta-discussion, wherein some things are definitely things that can be addresses technicaly, and some are not.
<slangasek> democracy: a technical solution to a social problem
<slangasek> debit card PINs: a technical solution to a social problem
<slangasek> ;)
<infinity> (Making it progressively harder and harder for people to upload packages because you're afraid that one clueless developer will upload glibc is a losing battle)
<bjf> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #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:
<bjf> @pilot out
<slangasek> infinity: true
<persia> Hrm?  I argued for the creation of the new MOTU.  I never intended that to be something that would make it harder to get access to other stuff.
<persia> We've historically been stingy about access to stuff that appears in images, and I don't think our standards for that have changed much.
<persia> The idea is to make it *easier* to get access to other stuff, if one is so inclined (but anyone who applies for MOTU who doesn't have a QA bent is probably applying for the wrong thing).
<persia> (in fact, the creation of the DMB probably makes it *easier* to be core-dev, as one no longer needs to undergo two interviews with two separate bodies, as one did from 2007-2009)
<persia> (with several promising candidates being approved at the first and denied at the second, or denied at the first, blocking the ability to apply at the second)
<slangasek> is that reflected in the numbers regarding time in queue for core-dev?
<geser> queue time for core-dev?
<slangasek> from application to approval
<persia> I'm not sure I understand "time in queue for core-dev".
<persia> Oh, certainly.
<persia> Used to be a 4-6 week process at the fastest.
<slangasek> really?  no one I've talked to lately has found the current DMB process anywhere near that fast :)
<persia> DMB has had some issues with meetings, but tends to be able to approve folk within a month the majority of the time.
<persia> slangasek: How do they measure?  From announcing their application to review, or some some other boundary?
<maco> i think we've only missed one meeting since march or so, and that was the Fourth of July
<geser> slangasek: we have recently problems to get quorum at the "early" meeting but that applies to all applications and not only core-dev
<slangasek> persia: that's what I'm going by, yes
<slangasek> geser: right
<maco> ugh yes and now the early meeting clashes with my commute (boss says now i must be here at 10, not 11, so now i have to leave home about 15 minutes after meeting starts... so i guess those mondays i get to go to work an hour early...)
<slangasek> it's possible my info is already dated; I was going by comments from March-ish
<maco> ah yeah in feb/march we had issues then moved the early meeting time by an hour
<stgraber> yeah, the early timeslot is always the issue, even since the change, the only meeting without quorum was an early one. Though the new time is definitely an improvement for me (as in, I can attend it now)
<geser> maco: mail the DMB and check with the other if we could move it again if it helps to reach quorum
<Laney> Compared to NM, DMB applications are a breeze :-)
<Laney> also I asked in a postscript to my bzr packageset mail whether we should be asking LP to give the DMB packageset administration rights
#ubuntu-devel 2011-07-19
<persia> infinity: Would now work for a discussion of syslog?
<persia> slangasek: I realise I never got back to you: under the prior system, after waiting for the (same class) of issues for MC quorum, applicants would need TB quorum, which was less frequent then than now.  This isn't to say that current latency is good.
 * slangasek nods
<RAOF> slangasek: Would a dh_multiarch make sense to process {install,links,maintainerscripts} in a way that doesn't bind debhelper and can be incorporated back into debhelper later once proved?  Mesa's gaining far to many *.in files :(
<slangasek> RAOF: it's not a question of proving it, I'm afraid it became a political issue with the maintainer; there's a chance this might get sorted next week at DebConf
<RAOF> While there are sometimes techincal solutions to social problems, rarely are there technical solutions to political problems. :(
<persia> There's no useful distinction between "social problem" and "political problem".
<persia> Solving both means getting interested folk to agree (often on some compromise).  Changing the technical environment can change the framework of the debate, and make compromise easier to achieve.
<persia> (consider $EDITOR and sensible-editor as technical solutions to political problems)
<RAOF> Ah, indeed.  I still hold a definition of âsocial problemâ and âpolitical problemâ that includes a useful difference, but that is indeed a fine example of a technical solution to a political problem.
<marios_manowar> is there any developer from the team that decided that the 2.6.32 kernel is still the kernel on 10.04.3 update?
<persia> The decisions don't quite work like that.
<persia> 10.04.3 includes all the updates published when 10.04.3 was released.
<persia> We all agree that we don't like to change upstream versions of anything in an update, if we can help it, because there are invariably regressions for some users.
<persia> So, in some sense, all the developers are responsible for the 10.04.3 kernel being 2.6.32, and there was never significant explicit debate about the matter for any team.
<marios_manowar> persia: I thought that there was a team especially for that. I saw that it was on 10.04.3's  launchpad page as a decision that it had to be clear and I wanted to learn more about that.
<marios_manowar> persia: so is it only for the reason you described before or there are more reasons? like stability, like it's tested more? and I 've not found such information on internet.
<persia> Which page?
<persia> If there was discussion, I'm also interested.
<ajmitch> the kernel is a special case - there are backported kernels available which receive support
<ajmitch> though I'm not sure to what degree
<infinity> ajmitch: Very little.
<persia> But I can't imagine anyone generating official install images that used a backport kernel.
<persia> Support is to the degree developers are motivated.  Anything else is wishful thinking.
<ajmitch> infinity: that's useful to know
<persia> Discussion of the sources of developer motivation is left for another time.
<broder> there was some discussion at UDS about including the backport kernels with point releases, but i don't remember the details, and i don't think there were any conclusive actions
<persia> Really?  More than just putting them in the pool as available?
<broder> the idea being that there's some expectation that you can take a CD, put it in a machine, and have it work
<broder> and for some hardware, you need the backport kernels to do that
<broder> but, i mean, there are obviously issues with regressions, disc space, etc.
<broder> the point release DVDs already ship with all the backport kernels, but i don't think anybody uses those
<persia> infinity, Since your idle counter is reset: I assert that systems without an installed syslog implementation are insufficiently Ubuntu to receive support through the typical channels.  Refute.
<infinity> persia: I assert that if you tried the usual support channels for support with a barebones rootfs, they'll fail you anyway. :P
<marios_manowar> persia: it was on the blueprints
<marios_manowar> https://blueprints.launchpad.net/ubuntu/+spec/kernel-lucid-kernel-decision
<persia> infinity, I can accept that assertion.  Can you accept mine?
<infinity> marios_manowar: That was deciding *before* lucid that it would use 2.6.32.
<broder> marios_manowar: uh, that's from back when lucid was first being developed
<persia> marios_manowar, Check the dates on that: that's from October 2009.
<infinity> marios_manowar: That same discussion happens every cycle (the kernel team decides which version is their target, and works toward that)
<persia> Well, November, but it *should* have been submitted in October.
<infinity> persia: Only because some of our "usual support channels" rely too heavily on scripted interactions with users, and would balk if a user said "well, I don't have logs."
<marios_manowar> ALL: ok, i feel stupid :-(
<persia> marios_manowar, And anyone is welcome to participate in the discussions as to which kernel should be used for each future release, although those planning to help maintain the kernel get more say, obviously.
<persia> infinity, Well, some of the scripts are executed on humans, but yeah, that's the source of my concern.
<infinity> persia: Yes, I said scripted interaction, as in the "scripts" you get with phone support ("Have you power cycled it?  We can't continue until you try that.")
<persia> I don't think the support teams are quite that bad.
<infinity> persia: This is a different sort of product, which might require a different level of support, I'm personally okay with that.  I mean, it doesn't have a kernel, it's not bootable, it's not installable.  These seem like larger "normal support" issues than "it has no syslog by default".
<persia> Well then, any objection if I document that we can only provide support for users who have some syslog implementation installed?
<persia> People who don't need syslog probably don't need that much support, or can fake enough answers that nobody will notice.
<infinity> persia: And yeah, some of the support channels are "that bad".  I've seen bugs closed for "insufficient info" because people didn't respond to a request for dmesg and various unrelated logs after including CORRECT info (like, say, a gdb backtrace of an obvious null pointer segv or something).
<persia> I'm not sure that the support teams and the bugsquad still have significant membership overlap, but yeah, I've seen terrible behaviour in bugs.
<persia> It's probably worth trying to realign bugsquad and the support teams, but that requires a healthy supply of tuits.
<infinity> persia: But we're planning to publish it with some sort of README to the effect of "this image will probably be useless without you doing some things to it: (list a few random things, like using it as a chroot, applying a kernel to it, whatever)"
<infinity> persia: So, a mention of what might be required to make it "supportable" is fine by me, as long as the README doesn't get so long that people ignore it. ;)
<persia> I was thinking that documentation should come in two flavours: short and long.
<persia> Short is just quick sentences, and a pointer to long.
<persia> Long can be long-winded: it's not for the TL;DR crowd anyway.
<micahg> infinity: these issues should be brought up on the bugsquad list so that people can learn from them
<marios_manowar> I will agree with persia in his/her documentation opinion
<infinity> micahg: To be fair, I've had these issues for literally years.  It's a battle I'm sick of fighting.
<infinity> micahg: Culturally, top to bottom, we seem to have developed an allergy in Ubuntu to open bugs, and that colours everything we do.
<infinity> micahg: And I'm from the school of "if it seems to be a legit bug, it's better to have it open for 6 years until someone gets around to fixing it than it is to close it and lose the reference because a user's report wasn't exactly what person N wanted".
<micahg> infinity: well, there was a discussion about a year ago about that, and the conclusion was what you just said
<micahg> and I brought this up at the last meeting to reinforce it
<infinity> persia: Oh, and re: long vs short, I had planned for short to be a REAME in the publishing directory (or pretty HTML, if it lands on releases), with a wiki pointer yes.
<persia> The key is really constant vigilance.  When we find such examples, we should try to recover them *and* make sure the person who made the mistake undersands their mistake *and* do so publically so that everyone else can also learn from that mistake, rather than making their own.
<infinity> micahg: So, how do I go about affecting a culture shift in processes that I've considered broken for half a decade? :)
<persia> infinity, We can do pretty HTML in the publishing directory now, but yeah, that's the short, and the long would be a wiki page.
<infinity> persia: The problem I've had in the past when re-opening false closures is that the triager seems to walk away with it not with a "I shouldn't have closed that bug because it was a real bug" attitude, but "I shouldn't have close that bug because that developer is insane and likes obscure bugs" attitude.
<infinity> persia: IOW, I can't seem to drill the point home that a bug is a bug, even if it doesn't include the perfectly scripted question/answer that they think it should have.
<persia> infinity, We need a better way to organise the communications, but micahg is right that by sending mail to the bugsquad list with the criticism when that happens, folk are more likely to understand.
<lifeless> communication is important
<infinity> (And I'm using the term "triager" loosely here, it's not just bugsquad, like I said, it's cultural.  I've had closure/reopen wars with core-devs, bugsquad folks, random well-meaning community folk, and even the original reporters(!))
<persia> lifeless, So, can we have a special checkbox in launchpad that indicates that the last commenter made a horrid mistake, and automatically sends the criticism to the bug contact?
<lifeless> oh I would love that
<lifeless> unsubscribed people making changes can be annoying
<persia> infinity, I suspect the majority of them are bugsquad: all developers are inherently bugsquad, and most random well-meaning folk probably clicked the "Sure, I look at bugs" button at some point.
<infinity> When the original bug reporter says "well, this seems like a weird/hard/confusing bug where the solution can't be readily determined from a 5 question script sequence" and I respond with "uh, no, what you've reported is a real bug, and we'll look into it when we have time", we have a serious culture problem.
<persia> lifeless, It's not just the unsubscribed being annoying, it's also for greater cohesion in the bug contact team.
<persia> infinity, Yes.
<lifeless> one way would be a reply-to function 'reply to a comment' vs 'comment on the bug'
<lifeless> we could use that to notify even unsubsubscribed folk
<persia> Wouldn't have the same name-and-shame benefit.
<lifeless> needs some design work around the concept
<persia> Unless we cc: all those to the bug contact for the project.
<lifeless> persia: it would still show as a comment on the bug
<lifeless> persia: which is plenty of name and shame
<persia> lifeless, I think you underestimate how many bugs there are in Ubuntu.
<infinity> persia: And okay, almost everyone may qualify as "bugsquad" if they're developers, but that doesn't mean we all dedicate time to actually doing bugsquadish things, or that we all subscribe to lists and such.
<lifeless> persia: I suspect I know better than you, given how much time I spend optimising LP to deal with them :>
<persia> Most active members of bugsquad only see a very limited subset, but they all ought see bug comment criticism.
<persia> infinity, OK.  Fair.
<persia> lifeless, With the insight into the volume of bugs you gained there, do you still believe that a comment in a bug is likely to be seen by a majority of folk who care for bugs?
<micahg> infinity: well, we have a special bugsquad team that's moderated, although the bar for entry is low
<infinity> I think the real thing that I'd like to be able to communicate to anyone who does triaging is that the ultimate target audience of bug reports is developers, not triagers.  I *love* that people want to help make bugs have more useful information or be reported more coherently before I get around to looking at them, but even if it's a badly-explained bug report, I'd prefer to see it and make that call than have someone else decide it's "not good enoug
<micahg> infinity: and I agree with persia, we should bring up these issues when they happen on the ML and they can be discussed at the meetings as well
<lifeless> persia: the crucial thing is feedback to the people making mistake
<lifeless> s
<slangasek> infinity: should the standard for that be anything other than "if the bug was marked triaged, don't mark it incomplete"?
<lifeless> persia: so I'm not assessing the mechanism on the same metric you are
<slangasek> infinity: btw, have you responded to the bug workflow survey? :)
<infinity> It takes me 3 seconds to read a bad bug report and decide it really is giberish, but it takes a lot more effort for me to trawl recent closures and look for ones that should be reopened.
<persia> infinity, I'd disagree with that: the ultimate audience of a bug report is someone able to provide a fix.  I don't care how they self-identify, or what status they think they have, or where they found the fix.
<micahg> persia: I think that qualifies as a developer in Ubuntu :)
<persia> lifeless, Ah, right.  I'm considering feedback to the people that made the mistake, and also to the class of people likely to make the mistake and/or the person overseeing the folk likely to make mistakes (depending on how the specific project happens to have defined the bug contact)
<lifeless> persia: so the docs already guide away from this mistake
<infinity> persia: Oh, sure, I don't mean capital-D Developer, whatever that might mean just, as you say "someone who might actually be able to fix the bug" (or legitimately prove that it's not a bug, not because it's short on info, but because it's obviously the user leaning on the "y" key while trying to type "q" or whatever)
<persia> micahg, I7d agree with you except for the number of bugs I've found with perfectly correct solutions to problems including a comment "I'm not a developers, but ...".
<lifeless> persia: overseers could probably watch (programatically) for status changes and audit easily enough
<micahg> persia: right, because we overload the term developer in ubuntu and not everyone is aware of that
<infinity> persia: I use the term "developer" loosely to mean "someone who's capable of working on the packages in some way", even if that's just providing a patch for a manpage (or, NOT providing a patch, but providing step-by-step instructions on how to fix it for someone who CAN patch it)
<persia> lifeless, The mistake of leaving a comment to derail a bug report?  Sure, but having a bundle of specifics, and a motivation by triagers not to get their name on that list can sharpen the stake a bit.
<infinity> (Another pet peeve of mine: people who think that without a well-formed patch, you don't have a fix)
<infinity> slangasek: Survey?  I may have missed this.
<lifeless> persia: I question the effect of negative reinforcement here
<micahg> infinity: https://lists.ubuntu.com/archives/ubuntu-devel/2011-July/033652.html
<infinity> micahg: Ahh, I haven't caught up on devel for a bit, thanks.
<persia> lifeless, I guess.  I encourage peer review and peer criticism, as long as it stays respectful, and about the *mistake* rather than the person.
<persia> Without that, I fear we're all likely to just pretend everything is good all the time.
<persia> But any system that has logged peer review inherently can be described as providing negative reinforcement.
<persia> In which case, it's mostly a matter of making sure the activity is still exciting enough and rewarding enough that folks are willing to accept the potential for criticism.
<lifeless> persia: sure, but structuring it as 'keep your name off this list' is name-and-shame vs direct feedback (even in public) that a particular action doesn't meet expectations
<infinity> slangasek: I think the problem with "incomplete" is that it's used and viewed as a negative thing.
<persia> lifeless, So, for Ubuntu, the public direct feedback belongs on the bugsquad ML (as we send criticisms of uploads to the devel ML).
<lifeless> why ?
<persia> lifeless, Which happens to be the bug contact for Ubuntu, so if LP cc'd the bug contact on these sorts of comments, it would work for Ubutnu.
<infinity> slangasek: I prefer "moreinfo", where it's obvious that the bug is in a feedback loop with the submitter, but isn't necessarily a "bad bug" that must be purged at the earliest convenience.
<lifeless> so incomplete and moreinfo are separate concepts
<slangasek> infinity: hum; I consider it bad if a bug doesn't get the necessary information to triage it for a long time, whether that's called "incomplete" or "moreinfo", and I think it's reasonable to expire such bugs out after a while
<lifeless> I think we have over simplified and made the system harder to use as a result
<infinity> lifeless: Incomplete is a broken-by-design concept, IMO.
<lifeless> infinity: in which regard?
<micahg> persia: the bug contact isn't the bugsquad ML AFAICT, but the ubuntu-bugs list
<infinity> slangasek: The problem I have with incomplete in a high volume system is that it's being marked that way by people who might not understand the bug in the first place.
<infinity> slangasek: And possibly timing out before it ever gets to someone who COULD determine that it's "complete enough".
<persia> micahg, Ah, then Hrm.  Anyway, needs user interaction design.
<slangasek> lifeless: ah, where "incomplete" is "insufficient info to confirm this is a real bug", and "moreinfo" is "real bug but we need help"?
<lifeless> slangasek: yes
<micahg> infinity: you definitely need to fill out the survey :)
<persia> I've seen bugs that *are* complete enough that got timed out because nobody who could determine they were complete encountered them in the window.
<infinity> ^
<slangasek> lifeless: hmmm, not sure that's a nuance that makes a major difference to our effectiveness in fixing bugs, but I see the point
<lifeless> slangasek: for instance, 'needsverification' could be expressed as 'moreinfo flag set' + 'fixcommitted'
<slangasek> sure
<micahg> persia: right, so it needs to be part of the culture that the person who sets it to incomplete watches for responses and acts on it
<lifeless> slangasek: and moreinfo wouldn't expire bugs
 * micahg wonders if this isn't better served being discussed in #ubuntu-bugs
<infinity> micahg: I've had people set my bugs to "incomplete" when the only response I could reasonably have was the get in a status war.
<persia> micahg, Doesn't help if the person who sets incomplete isn't capable of making that determination, which is what is often seen currently.
<lifeless> slangasek: incomplete can be modelled as 'NEW + moreinfo' in fact
<infinity> micahg: Because the bug WAS complete, but if I didn't engage in the pointless status war, it would get timed out. :P
<micahg> infinity: this is the type of thing that needs to be brought up on the ML
<infinity> lifeless: I also interpret incomplete as new+moreinfo, but others seem to interpret it as a synonym of invalid.  That's my issue.
<lifeless> infinity: filers or triagers?
<infinity> lifeless: (And the practice of auto-removing incomplete reports confirms this)
<infinity> lifeless: The whole system. :P
<lifeless> the whole system doesn't
<slangasek> infinity: ok, but in that case the root problem isn't that non-developers are triaging the bugs, it's that the set of people who are in a position to understand those bugs is stretched too thin to triage them in a timely manner; and that you can only address by getting more people who know what they're doing
<infinity> lifeless: If we auto-remove old incompletes, they ARE being called invalid.  Which may be inherently untrue once someone else reads the bug.
<slangasek> e.g., by working with the bug triagers to get them the tools they need to contribute effectively :)
<micahg> infinity: actually, they're being expired, not invalidated
<infinity> micahg: They're being closed.  I didn't say they're being changed to "invalid".
<slangasek> marking 'triaged' bugs as 'incomplete' would be a serious problem
<infinity> micahg: "no longer open" is "no longer open", regardless of the official status.
<slangasek> because that's undoing the work of deveolpers
<micahg> slangasek: right, I brought that up at the last bugsquad meeting
<slangasek> but marking 'new' as 'incomplete' is not, on the whole, worse than leaving 'new' marked as 'new'
<slangasek> with no response, ever, from a dev
<infinity> I dunno.  I have old Debian bug reports I plan to get to some day when I'm bored.  Or maybe some zealous community dude will send me a patch.  Or something.
<infinity> Old bugs aren't bad bugs.
<lifeless> infinity: bug in the system doesn't map directly to defect
<slangasek> infinity: no, but "I plan to get to some day when I'm bored" means "triaged" - if you're aware of it, you can mark it "triaged"
<infinity> Just because no one's had the time to look at it and determine its actual validity doesn't make it incorrect.
<lifeless> infinity: thatsa the point of expiry, because we get reports that aren't bugs
<lifeless> infinity: the reason the *default* is NEW, is so that someone can look at it.
<infinity> lifeless: Yes, but "incomplete" isn't "invalid", we've been there before. :P
<infinity> lifeless: This is, again, my problem with "incomplete".
<infinity> lifeless: Yes, some bugs are invalid.  We agree.
<infinity> lifeless: But bugs that might be valid with more info aren't invalid just because they're three months old.
<lifeless> If we have underskilled people asserting that the bug needs more data to be confirmed as a bug, *that* is a problem.
<TheMuso> c
<infinity> lifeless: And the triager thinking it needs more info might not be true from the POV of someonw who knows the software.
<lifeless> infinity: I agree re aging not implying expirable - see under 'I think we've oversimplified'
<infinity> lifeless: I have "Oh, I see what's happening there" moments all the time on bugs that someone else is still arguing about "moar log filez please" on.
<infinity> slangasek: I'll agree that in packages I care deeply about, I could do a bit of triaging here and there and mitigate some of these issues.
<infinity> slangasek: But with our decidedly anti-ownership maintainerless culture, there will be packages where no "skilled developer" looks at the bugs for a while.
<infinity> slangasek: I usually only notice bugs in various universe packages when I go to file a new one.
<infinity> slangasek: And I then go through the old-and-closed list to see if this is a longstanding issue, etc.
<slangasek> and do you often find the bug was on the new->incomplete->invalid conveyor?
<micahg> subscribe to packageset would help a little
<infinity> slangasek: Or new->incomplete->expired, which has the same UI effect.
<slangasek> hmm, really
<slangasek> ?
<slangasek> (not the UI effect, but that you often find this to be the case)
<infinity> Sadly, yes.  As micahg says, I should probably start taking notes and complaining to a wider audience.
<slangasek> yes please :-)
<marios_manowar> but i have a question for the whole bug report system! if ubuntu tries to be more and more user friendly, the average user won't have the experience of understand bugs and report them ( or only the second section ), will he?
<infinity> marios_manowar: We don't expect all users to report bugs.
<infinity> marios_manowar: The nice (?) thing about software defects is that most of them impact a reasonably large enough number of people that SOMEONE will end up reporting it.  Ish.  Except when that's not true. :P
<lifeless> aka 'all software sucks'
<marios_manowar> infinity: but i think that more experienced users may move to another distro
<infinity> marios_manowar: (That said, if you *are* technical enough to be reporting bugs, please don't refrain because you think someone else will be reporting it for you)
<infinity> marios_manowar: I'm not sure I really agree with that assertion.  People who love to fiddle with their systems might prefer other distros (and that's cool), but Ubuntu appeals not just to "new/non-technical users", but also to people who actually prefer using their computers rather than fixing them.
<infinity> marios_manowar: It's honestly why I ended up with Debian way back when, too.  The combination of a decent packaging system and a draconian policy made Debian much more hassle-free than other distros, so I could actually work.
<infinity> marios_manowar: Ubuntu's just another step in that direction for me.  I can break it when I want/need to, but its default state is meant to be the opposite.  And we try hard to get there.  And sometimes even succeed. ;)
<marios_manowar> infinity: i agree that the system has to be as stable as it can get. my worries are depend on that the unity for example is showing a simple interface that it 's similar to the philosophy of iPhone closed source OS.
<marios_manowar> infinity: i mean, ok, maybe this will point out that this look can be an open-source jewel too. but the actual distance from the native files is like it grows.
<infinity> marios_manowar: Not everyone's a fan of Unity or GNOME shell, or iOS, or Windows8, or Android, or, or, or... I imagine there will always be a market for "power users" who like "fancier desktops".  Thankfully, FLOSS operating systems allow for that quite readily. :P
<pitti> Good morning
<infinity> marios_manowar: (Using a classic GNOME session in Ubuntu is literally one click away on the login screen)
<infinity> pitti: Guten Morgen!
<pitti> hey infinity, how are you?
<TheMuso> /c/c
<TheMuso> gah
<infinity> Melting in the heat, and looking forward to winter. :P
<marios_manowar> infinity: ok, i think i should wait for 11.10 for getting a better view in the future ;)
<StevenK> infinity: It's 11degC over here, want to swap?
<infinity> StevenK: Gladly.  That sounds LOVELY.
<StevenK> infinity: Actually, define "heat"? :-)
<marios_manowar> StevenK: I am thin, can I come two?
<marios_manowar> *too
<infinity> StevenK: Was over 30 today, and probably closer to 40 in my office here.
<StevenK> That's a bit too hot
<infinity> Please send AC, stat.
<StevenK> How about we average them, 23degC sounds nice
<infinity> I'd rather have the 11.
<StevenK> Yes, but you enjoy -20, too.
<StevenK> Crazy person.
<marios_manowar> it was nice chatting with you all. have a good day!
<didrocks> good morning
<lifeless> slangasek: hah, speaking of wontfixing things wrongly:
<lifeless> bug 480444
<ubottu> Launchpad bug 480444 in linux (Ubuntu) "packet storm with linux NFSv4 client when calling ftruncate()" [High,Won't fix] https://launchpad.net/bugs/480444
<lifeless> persia: also
<lifeless> persia: ubuntu membership board asia. Its in your court AIUI.
<infinity> lifeless: Yay automation. :/
<infinity> lifeless: And you'll note that's happened to that bug more than once.
<lifeless> yes
<lifeless> clearly noone uses NFS
<StevenK> lifeless: Uh?
<StevenK> NFSv3 is *vastly* different to NFSv4, so don't tar them with the same brush
<StevenK> I happy use NFSv3 and have for years.
<infinity> StevenK: Upgrade and help squish bugs in the technically-superior-but-woefully-undertested successor? :P
<StevenK> But NFSv4 is the devil!
<infinity> So is Australia, but you still live there.
<infinity> So, y'know.  Embrace your inner crazy.
 * StevenK blinks
<StevenK> So I can just mount it as nfs4
<StevenK> Except that returns ENOENT
<StevenK> steven@liquified:~% mount | tail -n 1 | cut -d\( -f1
<StevenK> nfs:/ on /media/media type nfs4
<StevenK> Scary
<slangasek> StevenK: that bug is also reproducible with NFSv3
<StevenK> Oh, neat.
<slangasek> StevenK: am I the only one that tries to run bzr over nfs? :)
<lifeless> slangasek: no, kiko / async do/did
<slangasek> he must have a server version that doesn't trigger the bug :/
<StevenK> slangasek: I certainly don't run bzr over NFS.
<slangasek> StevenK: pff, hardly seems like you can claim to be using NFSv3 at all then ;)
<StevenK> Haha
<dholbach> good morning
 * slangasek waves to dholbach 
<slangasek> so speaking of nfs, why does the upgrade to nfs-utils 1.2.4 cause kerberos authentication to fail. :P
<dholbach> hey slangasek
<poolie> pitti: hello?
<pitti> hey poolie
<poolie> hi there
<poolie> can you advise me about our SRU proposal
<poolie> (thanks again in advance)
<poolie> https://code.launchpad.net/~jelmer/ubuntu/natty/bzr/sru-2.3.4/+merge/68020
<poolie> i think i technically have permission to merge and upload it, but i think i should get a sru-team +1 first?
<broder> poolie: ubuntu-sru dropped the requirement for a pre-upload ACK a few releases ago
<broder> these days they review SRUs from the *-proposed queues
<poolie> oh i see
<poolie> so, just merge it and upload to proposed?
<broder> yeah
<poolie> and then ping for review
<poolie> thanks
<broder> it won't actually get published to proposed until they approve it
<pitti> poolie: right, what broder says; we usually review from the queue
<tkamppeter> RAOF, hi
<RAOF> tkamppeter: Hi!
<tkamppeter> RAOF, how about the colord packaging?
<RAOF> tkamppeter: http://anonscm.debian.org/gitweb/?p=collab-maint/colord.git
<tkamppeter> OK, thanks.
<RAOF> It's mostly ready.  I need to discuss things with the icc-profiles maintainers, though.
<tkamppeter> RAOF, is pitti packaging that stuff?
<RAOF> The icc-profiles stuff?  I don't believe so.
<tkamppeter> RAOF, because of "owner: Martin Pitt".
<RAOF> Oh.
<RAOF> Yeah, he created the alioth repository for me.
<tkamppeter> RAOF, OK
<mvo> quick question to the kubuntu people, is "DESKTOP_SESSION" defined there (i.e. does echo $DESKTOP_SESSION print something)?
<RAOF> I would like pitti to give the package a review + upload to Debian at some point.  I should drop the shared-color-profiles Recommends: and ask for a review.  That needs a bit of a discussion, and the future rdepends of colord don't care about it.
<didrocks> mvo: KDM should set it last time I checked
<mvo> thanks didrocks
<didrocks> hum, gcc issue on the buildds?
<didrocks> https://launchpadlibrarian.net/75493155/buildlog_ubuntu-oneiric-i386.unity_4.2.0-0ubuntu5_FAILEDTOBUILD.txt.gz just after latest publish (previous uploads worked)
<tkamppeter> RAOF, thanks for the update.
<geser> didrocks: why gcc issue? check why libcompizconfig0 can't get installed (probably a dependency issue or a conflict somewhere down the dependency chain)
<didrocks> geser: sorry yeah, realized afterwards that I stopped at the first warning :)
<ev> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #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: ev
<smb> Known breakage? Oneiric xorg upgrade fails because it conflicts with /usr/share/doc/xorg which is also in xserver-xorg...
<pitti> smb: yes, discussed with RAOF an hour ago
<smb> pitti, ok, ta
<pitti> RAOF: just saw your xorg upload -- did you actually add preinst magic? the changelog doesn't say so
<pitti> smb: bug 812665 FYI
<ubottu> Launchpad bug 812665 in xorg (Ubuntu) "package xorg 1:7.6 7ubuntu1 failed to install/upgrade: trying to overwrite '/usr/share/doc/xorg', which is also in package xserver-xorg 1:7.6 7ubuntu2" [Critical,Fix released] https://launchpad.net/bugs/812665
<smb> pitti, Ok, then I don't need to bother anybody any longer. :)
<poolie> Riddell: hi, so the bzr 2.3.4 sru is waiting to go into -proposed?
<poolie> what's the precise term?
<poolie> and what is it we need to have to progress it?
<pitti> poolie: yes, it's in the queue: https://launchpad.net/ubuntu/natty/+queue?queue_state=1
<pitti> poolie: nothign, the SRU team regularly reviews the queue
<poolie> oh, ok
<poolie> that's great then
<poolie> and then into proposed, then we can regression test, and then ask again to promote it
<jml> Good morning Ubuntu
<poolie> good morning jml
<jml> poolie: hi
<Riddell> poolie: yes
<Riddell> poolie: it's in unapproved queue
<doko> slangasek: I'm wondering about this change in gcc-4.x: http://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-4.5/debian/patches/gcc-multiarch.diff?r1=4425&r2=4660&pathrev=4660
<doko> [ Steve Langasek ]
<doko>  * Don't append multiarch paths to any multilib paths except for the default;
<doko>     our biarch (multilib) builds need to remain independent of multiarch in
<doko>     the near term, so we want to make sure we can find /usr/lib32 without
<doko>     /usr/lib/i486-linux-gnu being available.
<doko> IMO always using MULTIARCH_DEFAULTS is wrong for every multilib'ed target, but maybe I miss something
<pitti> cjwatson: why does ubuntu-defaults-image call lb clean with sudo?
<pitti> ah, it writes files as root during lb build, nevermind
<apw> jhunt_, hey, did you sort your /proc/$$/fd issue ?
<jhunt_> apw: no. I might be missing something but the behaviour I'm seeing does look like a kernel bug to me.
<jhunt_> apw: well, kernel bug, or security policy :)
<apw> jhunt_, i don't think he had enough details to pass them on accuratly
<dupondje> geser: had time to fix my request yet for the ftbfs page ? :)
<geser> sorry not yet, but if you have time the code is at lp:~geser/+junk/qa-ftbfs
<cjwatson> SpamapS: bug 711425 is too late for 10.04.3 now :-(  just a reminder since I think we really do want to get that fixed for 10.04.4
<ubottu> Launchpad bug 711425 in sysvinit (Ubuntu Maverick) "portmap does not stop during shutdown, causing possible root fs corruption" [High,Triaged] https://launchpad.net/bugs/711425
<Amoz> dholbach, should the weird paragraph signs show on the right of the headers?
<pitti> cjwatson: hm, live-build doesn't automatically install a policy-rc.d file? I had to manually put it there when the chroot build failed on configuring dbus
<dholbach> Amoz, perhaps just on mouse-over like in the default?
<Laney> i'd rather a more discreet way of doing that
<Laney> just make the headings links which don't change colour?
<cjwatson> pitti: it does
<cjwatson> scripts/build/lb_chroot_sysv-rc
<cjwatson> cat > chroot/usr/sbin/policy-rc.d << EOF
<cjwatson> #!/bin/sh
<cjwatson> echo "All runlevel operations denied by policy" >&2
<cjwatson> exit 101
<cjwatson> EOF
<pitti> I noticed that when grepping, but it wasn't there; but perhaps this was an interrupted run, I just started a new one
<cjwatson> pitti: debootstrap doesn't though; although it does replace start-stop-daemon and initctl
<Amoz> dholbach, I'm pushing the fixes now, except the header fix. You have to decide which one you want :P
<Amoz> dholbach, all code should be monospace and shaded in a box, links removed, big Index link points to the packaging guide index.html startpage
<Amoz> dholbach, you got that last part?
<dholbach> Amoz, I'm just having a look at it
<Amoz> ah
<Amoz> cool
<Laney> /home/laney/temp/retheming/fixing-a-bug-security.rst:72: WARNING: unknown document: udd-intro.rst
<Laney> /home/laney/temp/retheming/index.rst:12: WARNING: unknown document: knowledge-base
<Amoz> Laney, how did you get that?
<Laney> make html
<dholbach> Laney, I think that might have come with one of the last revisions, not necessarily Amoz's edits
<Laney> yeah I wasn't trying to suggest that
<dholbach> :)
<Laney> I still see the paragraph symbols though
<Amoz> yeah
<Amoz> I didn't fix em
<Laney> ah
<Amoz> didn't know if you'd rather have the signs appear when mouse-over
<Laney> whatever you think is best
<Amoz> or just anchor the headers
<dholbach> Amoz, it doesn't seem to have an effect if we completely remove top-login and top-related, so it might make sense to completely get rid of them - what do you think?
<Amoz> dholbach, so we won't publish this guide online?
<dholbach> apart from that I think I'm happy for now - we can always extend the main-nav area (for offline use)
<Amoz> I think it would be nice to have some links to other places, if they're related to the packaging guide
<dholbach> Amoz, sure we will
<dholbach> Amoz, my idea was the following: have less links in the automatically generated version as that's what we ship in a package for offline use
<Amoz> ah of course
<dholbach> Amoz, and then have a script use that package as a basis for wherever we deploy it online, so it can blend in with that site better
<dholbach> that's how http://people.canonical.com/~dholbach/packaging-guide/html/ is put together, just there's no modification yet ;-)
<Amoz> so we can manually modify the published version with links and stuff
<dholbach> or let a script do it in a cron-job, but yes :)
<Amoz> oh well
<dholbach> do you think the approach makes sense?
<Amoz> absolutely, I'll remove the div's completeley... better not fudge up the layout grrr
<Amoz> I mean comment out the divs*
<Amoz> or do you want me to remove the code, dholbach ?
<dholbach> I think we can just remove them, they don't seem to have any effect as far as I can see
<Amoz> if you want to make an online version *with* the links, it's easier just to keep the code.. you can just let a script remove the <!-- comment tags --> to get the online version then
<dholbach> works for me
<dholbach> I think we just have to keep main-nav?
<Amoz> yeah I comment out the top-login and top-related divs
<Amoz> oh, wait, the whole top-nav is commented
<Amoz> there
<Amoz> and how about the paragraphs?
<dholbach> how easy is it to make them only visible when hovering over them?
<Amoz> dholbach, fixed
<Amoz> and pushed
<dholbach> sweet
<dholbach> I'll take a look in a bit
<Amoz> dholbach, just an idea, maybe a bad one, when ppl comment on merge proposals, like Iain did, it would be nice to have some todo-list for the proposal, automatically collecting todolists from the comments
<dholbach> maybe a whiteboard on the branch?
<Amoz> something like that yeah
<Amoz> would be easier if a few ppl make comments of improvements todo
<Amoz> maybe the comments are enough..
<dholbach> I agree that it'd be good to collect TODO items somewhere, as opposed to having them spread in various comments/emails/...
<Amoz> dholbach, i.e when I visist my retheming branch, I see a "needs fixing" from Iain, but I need to visit the actual merge proposal and browse to his comment to see what he wants me to fix. And if a lot of ppl comment on the branch... wow
<dholbach> yes
<Amoz> maybe place a box on the right, containing all the parsed lines from comments after a todo tag, a star * followed by one todo step/item
<Amoz> heh, hope you understand what I mean ..
<RAOF> pitti: Yes.  I repurposed the existing maintainer script generation infrastructure in debian/rules to generate the preinst foo.
<dholbach> Amoz, heh, you should have a chat with the launchpad team about this :)
<Amoz> dholbach, yeah I know this is not the right place, but an idea needs to be criticized
<dholbach> I'm on your side :)
<pitti> RAOF: ah, clever
 * cjwatson edits the 10.04.3 change summary and continues to wish that developers would actually explain what changes do in their changelogs
<cjwatson> instead of (anonymised) "Upstream patch 128691629716294.patch from 0.9 branch; LP: #nnnnnn"
<cjwatson> (well, OK, in the current case there was sort of a description embedded in the patch name, but really)
<Laney> where, what, why
<cjwatson> and the audience for SRU changelogs on the whole does not care what files you changed in the source package to effect the change
<dupondje> Aha a new natty kernel :D
<dupondje> lets hope this fixes my issue :D
<brendand> if a system has no dedicated video memory, does it take part of the regular RAM for video memory?
<dupondje> ye
<brendand> any fixed amount, or a percentage?
<Amoz> brendand, for me (nVidia ION) it's a fixed 256MB
<Amoz> I never heard of a percantage, but I might be wrong
<brendand> Amoz - hmmm, shouln't your NVidia card have dedicated memory for video?
<dupondje> think its always a fixed amount
<dupondje> cause the os can't even use it
<brendand> to really get to the point, a system has 4GiB of RAM, but /proc/meminfo reports ~2.8GiB. It's using the 64-bit kernel
<brendand> why?
<Amoz> brendand, my system (asus 1201n) has 2GB
<brendand> bug, or something else
<Amoz> but only ~1700MB is showing
<Amoz> brendand, free -m gives me 1754MB total
<brendand> and i get 3990GiB from free -m
<Amoz> brendand, sounds reasonable
<Amoz> what line at proc/meminfo are you referring to?
<pitti> brendand: wow, 4 TB? :-)
<brendand> pitti - no :P
<brendand> it's like the old 0.02c mistake
<brendand> Amoz - now i've started to referring to two different systems
<brendand> the 3990 is from the one i'm on now
<Amoz> 3990 MB
<brendand> the other one is actually a bug report i'm looking at
<brendand> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/812499
<ubottu> Ubuntu bug 812499 in linux (Ubuntu) "Just 2,8 of 4 GB RAM shown by Ubuntu." [Undecided,Incomplete]
<Amoz> brendand, when you say proc/meminfo reports ~2.8GiB, what line are we talking about?
<Amoz> ah
<brendand> MemTotal
<Daviey> jelmer: Hola, seeing a bunch of bzr uploads in Debian at the moment.. Does this mean bug #788533 is close to a fix?
<ubottu> Launchpad bug 788533 in bzr-svn (Ubuntu) "bzr-svn incompatible with bzr 2.4 or higher" [High,In progress] https://launchpad.net/bugs/788533
<jelmer> Daviey: hi
<jelmer> Daviey: not yet, there's a bug in subvertpy that's blocking bzr-svn at the moment
<Daviey> jelmer: :(.. thanks.
<brendand> looks like Radeon cards can be configured to 'steal' some RAM as video memory...
<jelmer> Daviey: (bug 803353)
<ubottu> Launchpad bug 803353 in subvertpy "segfault during iconv close from ra cleanup" [High,Triaged] https://launchpad.net/bugs/803353
<Daviey> jelmer: who cares about memory leaks? :).. thanks
<geser> install more RAM :)
<jelmer> SpamapS: hi
<cjwatson> micahg: I've switched the lm-sensors and lm-sensors-3 source overrides around now
<SpamapS> cjwatson: re bug 711425 .. right.. 10.04.3 has just crept up on me.. :-P
<ubottu> Launchpad bug 711425 in sysvinit (Ubuntu Maverick) "portmap does not stop during shutdown, causing possible root fs corruption" [High,Triaged] https://launchpad.net/bugs/711425
<SpamapS> jelmer: Hi... not forgetting you.. I need to run off and do some things.. be back in about an hour.
<cjwatson> SpamapS: me too, and I'm release-engineering it :-/
<bdmurray> ev: could you look at sponsoring my debdiff in bug 811419?
<ubottu> Launchpad bug 811419 in kerneloops (Ubuntu) "/etc/default/kerneloops executable" [Low,In progress] https://launchpad.net/bugs/811419
<ev> sure thing
<ev> bdmurray: uploaded
<bdmurray> ev: thanks!
<micahg> cjwatson: thanks!
<jelmer> slangasek: hi
<jelmer> slangasek: I'm looking at bug 812704 and was wondering what package you were running it against?
<ubottu> Launchpad bug 812704 in bzr-builddeb "backtrace with 'bzr bd --package-merge'" [Medium,In progress] https://launchpad.net/bugs/812704
<seb128> hey
<chrisccoulson> hi!
<seb128> should user admin frontends (let's say gnome-control-center user account) use adduser or useradd to add users?
<pitti> hmm; useradd is portable, adduser better for Debian/Ubuntu, but specific for tehse
<chrisccoulson> pitti - yeah, we mentioned that in #ubuntu-desktop too
<seb128> pitti, ok, I'm coming from the g-c-c side, the new user admin makes the default shell for users be sh
<seb128> i.e dash
<pitti> eww
<chrisccoulson> pitti - the issue is that accountsservice doesn't override defaults for the login shell
<seb128> since it calls useradd which default to sh
<pitti> seb128: we should certainly patch that to bash
<seb128> that's one bug
<chrisccoulson> and the default when using useradd is /bin/sh, but it is /bin/bash when using adduser
<seb128> right
<chrisccoulson> ok
<seb128> still does adduser add other value?
<chrisccoulson> i don't think so
<pitti> beyond that, I don't think that we need an UI to select the shell
<seb128> like dealing with copying default content to the user dir
<pitti> users who really want to can use chsh, and it's a special enough case IMHO
<chrisccoulson> seb128, accountservice users "useradd -m", which appears to do the same thing
<chrisccoulson> (ie, create the home directory)
<seb128> well the useradd manpage recommends using adduser
<seb128> so I guess there are difference between the two
<pitti> seb128: adduser copies skel, respects the system/user ID ranges, and creates proper usergroups
<pitti> ah, useradd also creates usergroups
<seb128> pitti, ok, so we should either ensure that accountsservices deal with all those or switcht o adduser
<chrisccoulson> pitti - it also copies /etc/skel
<pitti> chrisccoulson: right, I mention that
<tkamppeter> mpt, hi
<pitti> seb128: I guess calling adduser would be the smaller patch, and more robust?
<chrisccoulson> pitti - i meant that useradd copies that (as well as adduser)
<pitti> ah
<chrisccoulson> (when you use -m)
<chrisccoulson> or, at least that's what the manpage suggests. perhaps i should try it ;)
<pitti> "sudo useradd foo" doesn't
<pitti> useradd -m foo does, including skel
<chrisccoulson> yeah, i just tried that here too
<chrisccoulson> so, i'm not sure there's a need to patch accountsservice to user adduser is there?
<chrisccoulson> (but we need to change the login shell somehow)
<chrisccoulson> **to use
<pitti> patch it to use useradd -s /bin/bash?
<chrisccoulson> pitti - i think the issue with that is the default can't be changed by the administrator then
<pitti> perhaps we should also just change /etc/default/useradd to use SHELL=/bin/bash
<chrisccoulson> yeah, that's what i was thinking
<pitti> but that might affect system users, too
<pitti> not that it matters much for them
<seb128> well, do we want to default to dash for system users?
<seb128> I would like to get opinion from some of the foundation guys on that at least ;-)
<seb128> i.e cjwatson or slangasek
<seb128> ^
<pitti> might be a tad more efficient in corner cases, but not a big deal, I think
<chrisccoulson> that only changes the login shell though doesn't it? ie, the default shell (/bin/sh) will still be dash
<pitti> slangasek: do you think it would be correct to change the SHELL default in /etc/default/useradd to bash?
<pitti> chrisccoulson: yes, of cours
<pitti> e
<bdmurray> pitti: I'm looking at the match-error_messages function in the ubuntu general hook again an realized that VarLogDistupgradeApttermlog isn't check at all.  Do you have any thoughts on how to handle that well?
<cjwatson> interactive shells should be bash, not dash
<cjwatson> system users or no system users
<cjwatson> well, except that when creating a system user it generally doesn't really want an interactive shell
<cjwatson> so let me revise that, just leave it at the default for system users, but non-system users should get bash
<cjwatson> I don't think it would be correct to change /etc/default/useradd
<cjwatson> why can't accountsservice just use adduser though?
<cjwatson> that would be a sensible distribution patch
<cjwatson> and it would respect adduser.local which is impossible to do with useradd
<pitti> I tend to agree; we can also patch it in debian
<Amoz> uhm, guys, my bash path contains no sbin dirs, how did that happen? seems to be a permission problem
<pitti> Amoz: gdm/lightdm bug; it was fixed recently
<pitti> Amoz: are you on current oneiric?
<Amoz> nope
<Amoz> UGR
<Amoz> if that makes sense to you
<pitti> ?
 * Amoz likes gnomeshell, ubuntu gnome remix
<pitti> ah
<Amoz> natty
<pitti> Amoz: bug in gdm 3
<Amoz> -rwxr-xr-x 1 root root    71K 2010-07-02 09:28 ifconfig
<pitti> or, in Fedora terms, a feature
<Amoz> lol
<Amoz> is there a fix for it?
<seb128> pitti, chrisccoulson: btw bug #64700 is similar
<ubottu> Launchpad bug 64700 in puppet (Ubuntu) "newly added users have sh instead of bash shell" [Low,Triaged] https://launchpad.net/bugs/64700
<pitti> Amoz: the Ubuntu package now configures with --with-default-path=/usr/local/bin:/usr/bin:/bin:/usr/games
<pitti> you need that
<cjwatson> um, doesn't he also need /usr/local/sbin:/usr/sbin:/sbin
<Amoz> O_O
<cjwatson> or, you know, honouring pam_env
<Amoz> yeah that's what I thought..
<cjwatson> https://wiki.ubuntu.com/OneTruePath
<Amoz> lol
<cjwatson> (i.e. we fixed this in dapper, please can people not regress it)
<pitti> lightdm seems to DTRT
<Amoz> DTRT?
<cjwatson> hardcoding the default path in multiple places is explicitly contrary to that specification
<pitti> "do the right thing"
<Amoz> a
<pitti> cjwatson: *nod*; it was a quickfix in Debian to get back /sbin
<Amoz> my god... this router is killing me. no DNS
<slangasek> jelmer: 812704> that would have been rpcbind again - trying to use --package-merge was probably an error, it was the first thing I tried after getting the reject from LP
<slangasek> jelmer: so it may be sensible that the command doesn't work, but a nicer error would be helpful :)
<jelmer> slangasek: which branch/revno is that, just ubuntu:rpcbind?
<slangasek> jelmer: lp:ubuntu/rpcbind, -rtag:0.2.0-6ubuntu1
<jelmer> slangasek: merci
<alex__> if I'm packaging a gnomeshell extension (just some javascript and a python script) it should be packaged as a single binary?
<Amoz> ls
<slangasek> doko: the gcc-multiarch.diff is combined with a configure argument that sets MULTIARCH_DEFAULTS to *our* idea of a multiarch path.  I don't know if that's sensible from an upstream design POV, but I think that's inherited from aloiret's patches and I didn't see any reason to change it
<slangasek> doko: so for the default target, we do need to use the multiarch path because that's where all our system libraries are; and this is how we get it
<slangasek> pitti: /etc/default/useradd> I defer to cjwatson :)
<pitti> slangasek: ok, thanks
<pitti> seems we should just call adduser there, and be done with it, and do that right in Debian
<seb128> pitti, will open a bug in the bts about that
<slangasek> anyone else seeing some evolution component (probably the calendar factory) blowing up in oneiric, causing dbus to spin @ 100% CPU?
<seb128> no
<chrisccoulson> slangasek, yeah. every time i click on the datetime indicator
<seb128> I've seen evolution components blowing up but no dbus spinning
<chrisccoulson> indicator-datetime-service and e-calendar-factory flood the session bus here
<slangasek> chrisccoulson: right, that sounds like what I'm seeing.
<slangasek> chrisccoulson: is there a bug for it, by chance?  Also, do you use evolution google calendar support, or does this happen regardless of calendar contents?
<chrisccoulson> slangasek, i don't think there's a bug atm
<chrisccoulson> but yeah, i use it to access my google calendar too
<slangasek> I'll try to file one today
<slangasek> chrisccoulson: thanks
<seb128> slangasek, chrisccoulson: I'm using google calendar and don't get that issue
<pitti> for me it takes ages to load the google cals, but it doesn't spin the CPU
<seb128> same here
<mvo> in my upgrade tester the machien will not find the rootfs anymore on the first reboot, has anyone seen something similar?
<doko> slangasek: it works for the default multilib, but not for the non-default multilib. x86-64-linux-gnu is wrong for gcc -m32, it has to be i386-linux-gnu
<slangasek> doko: well, -m32 still uses only /usr/lib32, which is ok at least on a transitional basis - I don't think we have all the existing biarch packages transitioned to multiarch yet, do we?
<slangasek> I wasn't expecting biarch packages to start disappearing until multiarch provides a complete replacement
<doko> no, but this case is already handled by MULTILIB_OSDIRS. but you should be able to find things in the new location too. just seen when building multilib for armel
<tkamppeter> mpt, ping
<slangasek> doko: however, if you think that we should start using multiarch paths for the non-default multilib, I am not strongly opposed to this :)
<slangasek> doko: yes, I guessed that was the context
<bdmurray> ev: https://code.launchpad.net/~brian-murray/ubuntu/oneiric/plymouth/bug-787685/+merge/68429 mind reviewing that?
<ubottu> Ubuntu bug 68429 in flashplugin-nonfree (Ubuntu) "CRLF injection vulnerability in Adobe Flash Player plugin" [Medium,Fix released]
<bdmurray> heh that's kind of funny
<Amoz> lol
<Amoz> stupid bot!
<doko> thank you lintian
<doko> E: libhfgcc1: triplet-dir-and-architecture-mismatch lib/arm-linux-gnueabihf/ is for armhf
<ev> bdmurray: done
<ev> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #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:
<Amoz> I'm trying to create a native debian package, but somehow this is a bit over my knowledge
<kees> hallyn: so, it looks intentional, but can you confirm that the change to CAP_SETPCAP is intentional? (LP: #810022)
<hallyn> kees: I vaguely recall a patch by eric paris to that effect
<hallyn> kees: found it (commenting)
<kees> hallyn: a3232d2fa2e3cbab3e76d91cdae5890fee8a4034
<kees> hallyn: just found it too
<hallyn> :)
<kees> oh, you found the correct one, though.
<kees> ffa8e59df047d57e812a04f7d6baf6a25c652c0c
<kees> hallyn: so what's possible now that init has that cap by default?
<kees> hallyn: the meaning of the cap hasn't changed, so why is it suddenly safe to have?
<hallyn> kees: it's not sudden, it just wasn't done back when it was sudden.  What changed was cap_setpcap no longer allows you to pass capabilities to another task
<kees> hallyn: well that was pre-fscaps
<kees> hallyn: but, I guess that was actually kind of recent (intrepid and later)
<kees> hallyn: okay, cool. I'm satisfied :) thanks!
<kees> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #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: kees
<kees> man, merges are so ugly in bzr :)
<Laney> the launchpad diff is, but bzr itself can be used to get the diffs you want out
<kees> Laney: yeah, that's true. it's much nicer looking in actual bzr
<pdtpatrick> Why is it dual screen on ubuntu .. it treats the screens almost like separate X windows. With the message status menu on both screen? Is this part of the design and if so --- plans to try something else in the future?
<bryceh> pdtpatrick, is that with unity or "gnome classic (no effects)"?
<mdeslaur> Sweetshark: I think the libreoffice package currently in natty-proposed seems to have reverted to the default theme. Is this a known issue? What's the bug # for the SRU?
<SpamapS> jelmer: Can I assume you were pinging me earlier today to discuss the natty-proposed bzr upload?
<jelmer> SpamapS: hi
<SpamapS> jelmer: anyway, I notice that there's already a version in natty-proposed, 2.3.3 .. is this meant to supersede that?
<jelmer> SpamapS: your mind reading powers are working :)
<jelmer> SpamapS: yes, this supersedes the 2.3.3 SRU, in which we found a small regression
<jelmer> SpamapS: bug 786980
<ubottu> Launchpad bug 786980 in Bazaar 2.4 "bzr: ERROR: bzrlib.errors.ReadOnlyError: A write attempt was made in a read only transaction" [High,Fix released] https://launchpad.net/bugs/786980
<SpamapS> Alright, by the powers vested in me by the SRU team and in you by the micro release exception, I accept your upload, and pronounce you in need of verification.
<jelmer> SpamapS: Thank you sir.
 * jelmer bows
<mdeslaur> Sweetshark: never mind, found it
<pdtpatrick> bryceh, it is with unity
 * micahg hugs jelmer for remembering -v in th SRU
<SpamapS> micahg: indeed, thats been added to my list of checks to do during SRU. I wonder if there is an automatic way to flag this. :-P
<jelmer> SpamapS: if you use UDD then "bzr builddeb -S --package-merge" will do the right thing
<SpamapS> good tip
<SpamapS> I'm more coming at it from the reviewer's angle though.. how do I make sure you used --package-merge :)
<micahg> SpamapS: not offhand, you could check if there's a version in -proposed and if that version is included in source.changes
<lifeless> cjwatson: ping; bug 802985
<ubottu> Launchpad bug 802985 in eglibc (Ubuntu Hardy) "[lucid] /var/lib/dpkg/tmp.ci/preinst: 399: arithmetic expression: expecting EOF: "3.0-0-generic"" [High,Triaged] https://launchpad.net/bugs/802985
<lifeless> cjwatson: hallyn and I were just talking about this in -server; in the LP team we're doing a push on LXC for testing - both integration and local developer stories.
<lifeless> cjwatson: that bug will mean all the team members needing a workaround, which we can put in our PPA; do you have any thoughts about which workaround is best - or can we be confident the bug will be fixed before oneiric release?
 * SpamapS starts reconsidering his idea to add a feature to ifupdown after seeing the code... GAH
 * SpamapS finds a way to do it cleaner w/o a mod to ifupdown.. thank god
<infinity> lifeless: Fixing debootstrap to fetch from -updates is the correct solution; patches welcome.  Makes more sense than wasting time on workarounds, IMO.
<davmor2> kenvandine: you around still dude?
<kees> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #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:
<mwhudson> i want to build my own kernel (basically, the kernel that's in natty now + 2 patches)
<mwhudson> is there a bluffers guide to doing this sort of thing?
<poolie> yeah
<poolie> https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<lifeless> git clone the tree, install kernel-wedge and run it, then fakeroot debian/rules binary-generic
<mwhudson> poolie: ah hey, guess which bug is motivating me :)
<poolie> oh, external laptop displays?
<mwhudson> yeah
<poolie> I tremble for my country when I reflect that God is just -- tj
<mwhudson> sigh, the build-dep step is finally installing texlive on my system
<mwhudson> i avoided it for a while :)
<poolie> heh, i know
<poolie> also, the kernel is a lot bigger than it used to be
<mwhudson> yeah
<mwhudson> Receiving objects:   3% (64614/1983159), 21.44 MiB | 161 KiB/s
<mwhudson> this is going to take a while
<lifeless> yes
<lifeless> I can probably send it to you faster
<lifeless> SpamapS: yo
<mwhudson> actually, i might have a git clone of some random kernel version lying around somewhere
#ubuntu-devel 2011-07-20
<mwhudson> ok
<mwhudson> so what is git for 'bzr pull --overwrite'? :)
<RAOF> mwhudson: âgit reset --hard $ORIGIN/$BRANCHâ (generally origin/master)
<RAOF> After having run âgit fetch $ORIGINâ, obviously.
<mwhudson> RAOF: so i need to add the repo i want to blat over mine as a remote first?
<mwhudson> right
<RAOF> Yes.  As far as I know, the git doesn't have a concept of âjust pull from this repository pleaseâ
<mwhudson> i wonder what it's doing now
<RAOF> What have you asked it to do? :)
<mwhudson> git fetch git://kernel.ubuntu.com/ubuntu/ubuntu-natty.git
<mwhudson> ah now it's doing things
<RAOF> I have no idea what it's going to do :)
<RAOF> I don't *think* it's going to do what you expect, though.
<mwhudson> i think it fetched the objects from that repo into mine
<mwhudson> and nothing else
<RAOF> That seems both unusally helpful and unusually obvious for git.
<mwhudson> i could only tell this by running diff -r on the copy of the cloned repo i made before doing anything :)
<RAOF> I don't suppose git branch -a shows some new remote branches?
<mwhudson> nope
<mwhudson> so how do i add the branches from a remote?
<mwhudson> is it just
<mwhudson> git remote add natty git://kernel.ubuntu.com/ubuntu/ubuntu-natty.git
<mwhudson> git fetch natty
<mwhudson> ?
<mwhudson> maybe git fetch natty master ?
<TheMuso> mwhudson: git remote add natty as you wrote
<TheMuso> then use git branch -r to see what natty remote branches there are.
<TheMuso> To create a local mirror of a remote branch, you can do git checkout -b natty-master natty/master
<TheMuso> Which will create a local branch called natty-master which tracks natty/master
<mwhudson> git branch -r just says
<mwhudson>   origin/HEAD -> origin/master
<mwhudson>   origin/master
<TheMuso> Did you add natty as a remote?
<mwhudson> yes
<TheMuso> ok then you want to run git fetch natty
<mwhudson> ah ok
<mwhudson> that was running while i ran git branch -r
<mwhudson> now it's completed a bunch more stuff has appeared
<mwhudson> ah now arararagh i don't know which patch tjaalton backported
<mwhudson> oh phew, it's here: http://people.canonical.com/~lexical/bugs/lp791752/
<mwhudson> git 1 : 0 mwhudson
<mwhudson> ok building
<mwhudson> ah hum, i changed the version of the packaging
<mwhudson> which broke the build
<mwhudson> ah i changed the version of the packaged, but not something else
<lifeless> mwhudson: btw, #ubuntu-kernel usually gets this stuff :>
<mwhudson> ah point
<nemo> ok. why the !@#$ does pastebin.ubuntu.com require me to log in to download a paste as text?
<nemo> regretting ever having sent user to that url for support :(
<nemo> what silly silly silly idea
<nemo> agh. requires whitelisting session cookies too
<nemo> and doesn't work in w3m
<nemo> geez
<infinity> nemo: It was a simple solution to the very real problem of people distributing large binary files (like ISOs and movies) in raw pastebins.
<ion> A size limit wasnât? :-)
<nemo> ion: amen brother
<nemo> somehow everyone else manages
<infinity> ion: Size limits don't help.  It's trivial to split an ISO into thousands of chunks and shove them into a bunch of bins.
<infinity> ion: And yes, this happens.  A lot.
<nemo> um
<nemo> if someone is willing to go to all that trouble to distribute an ISO
<nemo> they can also trivially extract base64 bits from your pastebin without the raw thing
<infinity> nemo: This isn't theoretical.  If it was, no one would care.
<nemo> so that makes the annoyingness pointless
<infinity> nemo: The difference is that your assertion is theory, mine is fact. :P
<infinity> nemo: (I don't disagree with your theory, but that's not the real-world data we've seen)
<nemo> heh
<nemo> I bet you're the dude who instituted this :)
<infinity> Nope.
<infinity> But I'm fairly familiar with it nonetheless.
<nemo> ok. so you somehow ran into someone who was both clever and determined enough to split an iso into 10,000 pastebins, and do it in a way that would evade abuse detection, but too stupid to handle scraping
<nemo> ahhh well
<nemo> at least there's a reason for it
<nemo> I'll just use pastebin.com
<nemo> thanks for explaining though
<nemo> seeya!
<pitti> Good morning
<pitti> SpamapS, RAOF: I'll be on vacation the next two weeks; can you handle SRUs during that time?
<RAOF> pitti: Good morning!  I guess we can, yes.  I'll just punch down the queue more often.
<pitti> RAOF: also, I think it's time for you to be able to twiddle the buttons yourself
<pitti> RAOF: WDYT?
<RAOF> pitti: Also, I had an SRU-calibration question: bug #744929.  From past behaviour I'd expect that to be accepted as an SRU, but I think it is too close to âcore infrastructureâ and too far from âserious regressionâ to fit the criteria.
<ubottu> Launchpad bug 744929 in gnome-keyring (Ubuntu Natty) "After auto-login, prompted to unlock keyring multiple times" [Low,Triaged] https://launchpad.net/bugs/744929
<pitti> that's https://launchpadlibrarian.net/72725131/dont-prompt-multiple-times-rebased.patch, right?
<RAOF> YEah.
<RAOF> It looks reasonably safe.  It's just touching what I'd regard to be core infrastructure to fix a bug that doesn't seriously undermine the usability of the desktop.
<pitti> it certainly sounds like a regression, but it's indeed not a showstopper
<pitti> admittedly 4 identical password prompts suck a bit, but it seems there aren't so many dupes
<RAOF> I think this highlights a difference between accepted practice and what we've got written on wiki.ubuntu.com/StableReleaseUpdates.
<pitti> RAOF: TBH I'm a bit on the edge there; I probably would have accepted it, but I guess my treshold is now pretty low after so many years
<pitti> so I actually do appreciate a little more rigor in the process
<infinity> I'd probably accept it, FWIW.  I'm okay with any "obviously correct" bugfixes that don't change expected interfaces.  Ish.
<infinity> (But it's pretty case-by-case, which is why it's hard to codify such things in a policy)
<RAOF> Right.  As I said, from past behaviour I'd expect that to be accepted.  But were we to go by what's written on StableReleaseUpdates, I don't think it would be accepted.
<RAOF> Which means we should either update the documentation for what is acceptable in an SRU, or become stricter :)
<infinity> Or accept that the docs reference the baseline level of "strictness", and as people get more comfortable with the spirit of the law, they can make a few borderline judgements?
<infinity> Like I said, it's really hard to codify "acceptable updates" without erring on the side of caution.
<infinity> Cause accidentally going the other way is ungood.
<pitti> I agree
<pitti> and while each single of these patches might be acceptable, I'm still a bit uncomfortable about the sheer number of updates that we do this way
<pitti> some of them will eventually wreak havoc
<pitti> and when looking at the kernel updates, this already happens all the time :)
<infinity> Well, I'm also personally less inclined to fix every little bug in non-LTS releases too.
<RAOF> Kernels are quite special :)
<infinity> Whereas pushing well-tested and very correct patches to LTSes makes me happy.
<infinity> (Given that I'm one of the people who does, in fact, run then for years)
<pitti> RAOF: so if you want to reject this particular update because it doesn't fit the risk/benefit ratio, I think that's a very justifyable position
<StevenK> infinity: +1
<StevenK> infinity: I have an 8.04 machine around here some place
<infinity> StevenK: My co-lo machine is still hardy too.
<infinity> (Though, if mainlined Xen on 3.0 in oneiric proves stable, I might be tempted to upgrade pre-LTS..)
<didrocks> good morning
<RAOF> Oh, oh!  It's a didrocks!
<RAOF> Morning didrocks :)
<didrocks> hey RAOF ;)
<RAOF> When's the NBN going to deliver a fibre connection to my home, damnit?  Uploading 150Mb worth of evolution core to launchpad takes too long! :)
<lifeless> RAOF: retrace it locally.
<RAOF> lifeless: That's effort.  Whereas I've got so much practice bitching about upload speed it's near effortless :P
<lifeless> except for the whole uploading thing
<RAOF> Eh.  That's computerised effort.
<RAOF> â¦unless the upload 503s mere seconds before completing, of course.
<lifeless> ewll
<lifeless> to lp ?
<lifeless> that means it completed but the insert boomed
<lifeless> or the server instance was restarted
<lifeless> did you get the OOPS id ?
<RAOF> Apport doesn't give one; it hadn't opened the âplease wait while we process your dataâ page yet.
<lifeless> apport bug then
<SpamapS> pitti: I'm still not clear on kernel SRU's ..
<pitti> SpamapS: for accepting it's actually quite easy now
<SpamapS> ugh.. TwinView is totally busted right now
<pitti> SpamapS: https://bugs.launchpad.net/~ubuntu-sru/+assignedbugs?field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED
<pitti> SpamapS: that's the list of assigned SRU tasks, by the new kernel workflow
<pitti> SpamapS: if there are promote-to-proposed tasks, you exercise the corresponding copy-proposed-kernel invocations from pending-sru.html and close the tasks
<pitti> SpamapS: the main thing to watch out is to include all the -meta, -lbm etc. in the copying when there's an ABI bump
<pitti> SpamapS: for releaseing a kernel to -security/-updates you need cocoplum access, as launchpad still times out when using launchpadlib
<pitti> i. e. this part needs to be done by slangasek or cjwatson
<SpamapS> Ok, any gotchyas other than the -meta and -lbm packages?
<pitti> not really
<pitti> we stopped running sru-accept.py on them, the bot/kernel team does that now
<pitti> (with different verbiage etc.)
<pitti> SpamapS: it's very mechanical on our end now
<SpamapS> Ok, I'll give them a shot when I can.
<pitti> SpamapS: we just went through a round for all releases, so I don't expect further updates until next week
<SpamapS> pitti: I think we'll be able to keep the ship running.. we may even keep it from running aground. ;)
<pitti> SpamapS: skaet also did copy-proposed-kernel already, so she can help/explain as well
<pitti> lol
<pitti> thanks :)
<SpamapS> now to figure out why my twinview is refusing to show any windows
<infinity> SpamapS: I'm happy to help with -security/-updates kernel magic too, if required.
<superm1> pitti, re 799754, what about autologin?  ubiquity still would be writing out to /etc/lightdm/lightdm.conf, so if it's not a conffile that might be trouble
<lifeless> infinity: how deep does the 'use lucid-updates during debootstrap' change go, do you think?
<infinity> lifeless: Well, debootstrap isn't "deep" to start with, but mirror-handling and deb-fetching isn't particularly abstracted, so the change would touch several instances of shockingly-similar code.
<infinity> lifeless: And, in the process, you'd also fix a longstanding bug that if there are two versions of a package available in the same Packages file, debootstrap just picks the first one it hits. :P
<infinity> lifeless: (Which obviously would need to be fixed, to actually pick the highest version)
<lifeless> just trying to assess whether I can explain to francis why I'm hacking on debootstrap :P
<infinity> lifeless: It's something I always wanted to do if I found the tuits, and I could even potentially block time off later in this cycle to get David to agree to let me do it, but it's not something I could commit to right now.
<dholbach> good morning
<infinity> lifeless: So, if you can make it happen, please do.
<lifeless> heh :P
<lifeless> lxc is good for yak shaving apparently
<pitti> superm1: ubiquity shouldn't modify lightdm.conf as long as it _is_ a conffile
<pitti> superm1: but mythbuntu-default-settings and friends would install their's before ubiquity, so that should work?
<infinity> lifeless: debootstrap actually already has preliminary support for multiple archives.  Where that falls short for us is that we use "pockets", which means some ugly s/$dist/\1-{updates,security,proposed}/ all over the place.
<SpamapS> awesome.. so nvidia driver multi-monitor is completely broken on oneiric at the moment. :-/
<SpamapS> and nouveau is refusing to recognize my NV96
<superm1> pitti, yeah that would work as long as all packages installed it as a conffile
<pitti> superm1: why a conffile?
<superm1> my point was that ubiquity does modify that file in terms of changing automatic login
<superm1> for gdm it did the same for custom.conf
<pitti> I don't think it should be; multiple packages shipping the same conffile is icky to get right, as they'll cause conffile prompts
<pitti> superm1: custom.conf was not a conffile
<infinity> pitti: Multiple packages shipping the same conffile is just wrong, wrong, wrong.
<pitti> and ubiquity modifying lightdm.conf conffile is nasty and shoudln't be done
<pitti> infinity: my point
<RAOF> SpamapS: nouveau doesn't recognise your nv96?  Got a pastebin of dmesg+/var/log/Xorg.0.log there?
<superm1> pitti, so what should the right solution be here?
<infinity> superm1: You might be confusing "conffile" (dpkg-managed files) and "config file" here?
<pitti> superm1: *-default-settings should install a config file if it's not there already
<superm1> yes i think so
<superm1> how do you install something in /etc that isn't dpkg managed then?
<infinity> superm1: A non-conffile config file that is created in maintainer scripts is the only way to have multiple packages play willy-nilly with the same file.
<pitti> superm1: like, ship it in /usr/share/mythbuntu-default-settings/lightdm.conf and copy that to /etc/lightdm/ in postinst if not present already
<superm1> oh right
<superm1> okay that makes much more sense then
<pitti> then ubiquity can apply as much seddery on it as it wants
<pitti> and FWIW, yay for having so great names for config files vs. conffiles (which are also config files, of course)
<infinity> Yeah, it's muddy. :P
<pitti> so what I really ment was a non-conffile config file
<infinity> But we still require everyone to know debian-policy, right? :)
<pitti> (tell that to any non-DD and they will just stare at you in disbelief)
<infinity> pitti: Well, you can scrap the "conffile" thing and say "non-dpkg-managed config file", which probably gets the point across better.
<pitti> good idea
<superm1> yeah if i read that i probably wouldn't have scratched my head as hard
<SpamapS> RAOF: hrm, I don't think I do.. I've just reinstalled nvidia drivers.. really tired of fighting such a silly issue.
 * SpamapS is installing XFCE to see if it fares better than Unity
<pitti> superm1: anyway, with that sorted out, it would work in exactly the same way as with gdm's custom.conf
<pitti> SpamapS: don't you guys all just plain X with a single xterm and byobu anyway? :-)
<pitti> the "servity" desktop
<SpamapS> pitti: kirkland is always trying to get me to use byobu. Not exactly my cup of tea. ;)
<SpamapS> if I had it my way, I'd run the *stable* release of Ubuntu
<SpamapS> but c'est la vie.. we must dog food
<infinity> byobu is way too many bells and whistled (and constant pointless forking!) for a real CLI hack.
<infinity> s/whistled/whistles/
<SpamapS> infinity: I believe kirkland has been working on making the monitors resident... so they just work via pipes.
<infinity> SpamapS: Still, who needs monitors?
<infinity> Hold on, I had a great quote for just this occasion...
<SpamapS> I'm with you.. but kirkland has put so much work into it.. I try to give it a fair shake whenever there's a major development.
<infinity> < ron> procmeter3 does kind of look like the classic "I wanted to write a program, but don't actually have anything useful I want to do with computers" application
<infinity> That one.
<SpamapS> :-D
 * micahg remembers evoking that comment a couple days ago
<infinity> micahg: It was worth saving.
 * SpamapS feels lost
<nigelb> lovely quoet
<nigelb> *quote
<SpamapS> this giant 22" monitor on my desk just black.. :-/
 * SpamapS ponders kde for a nanosecond
<RAOF> I think KDE would be ok if I could get over the hump.  And learn to ignore options.
<SpamapS> well xfce will be fine until they fix unity
<Amoz> lol, willy- illy
<Amoz> nilly*
<poolie> :(
<pitti> RAOF: have a look at https://launchpad.net/ubuntu/natty/+queue?queue_state=1
<pitti> RAOF: of course I just processed all your ack'ed uploads some two hours ago, so there's nothing acceptable left right now
<pitti> RAOF: unless you want to accept strongswan
<pitti> RAOF: often I allow people to test the proposed package and fix oneiric in parallel, I just don't move these to -updates
<pitti> it's not something I like to do, or happens often, but if you want to try :)
<RAOF> Stronswan was the one I tentatively NAK'ed based on 3.0 (quilt) stylistic, right?
<pitti> RAOF: no, that was w-scan or so, I already rejected it
<pitti> RAOF: strongswan was delayed because a part needs fixing in oneiric
<RAOF> queuediff says Strongswan was the one not fully fixed in oneiric.
<pitti> wow, queuediff says that?
<RAOF> No, but it does open the bug :)
<RAOF> â¦which reminds me that I should have set the Ubuntu task back from fix released :)
<pitti> infinity: did you ever see a build failure like https://launchpadlibrarian.net/75531471/buildlog_ubuntu-oneiric-i386.libreoffice_1%3A3.4.1-1ubuntu1~ppa2_FAILEDTOBUILD.txt.gz ?
<RAOF> So, we *could* reject the gnome-keyring upload.
<pitti> After installing, the following source dependencies are still unsatisfied:
<pitti> libstlport4.6-dev(still installed)
<pitti> Source-dependencies not satisfied; skipping libreoffice
<pitti> RAOF: that's a lot less fun, though
<pitti> Sweetshark: ^ FYI
<infinity> pitti: Build-conflict.
<pitti> Sweetshark: ^ oh, do you have a build-conflicts: there?
<infinity> pitti: One of the build-deps is pulling in a build-conflict: Kaboom.
<pitti> infinity: curious that it only happens on i386
<pitti> infinity: thanks!
<pitti> RAOF: another thing you can do now is running sru-release; there is a natty package which can go
<RAOF> foolscap.
<pitti> yeah, and pithos
<RAOF> Hasn't pithos been there only 7 days?
<cjwatson> lifeless: 802985 is surely moot now because the oneiric kernel is now 3.0.0 not 3.0, and AFAIK lucid's libc6.preinst will have no problem with that
<cjwatson> lifeless: it's still a design issue, so the bug should stay open, but I see no reason why it should block you in any way
<infinity> cjwatson: Oh, it was just choking on format, not on kvers != 2.6?  I didn't look.
<Sweetshark> pitti: nah, thats not curious. stlport is only kept on i386 for binary compatibility with C++ extensions (a whole insanity of its own). amd64 dodged that bullet by means of the grace of late birth.
<RAOF> pitti: Have I somehow managed to project a âSRUs stay in -proposed for at least 10 daysâ policy where there is none?
<pitti> RAOF: it's 7 days :)
<RAOF> I blame the lack of a decimal calendar.
<cjwatson> infinity: yep
<Amoz> 0.8 week
<RAOF> pitti: So, that'd be âsru-release natty pithos foolscapâ to move those into -updates, right?
<pitti> RAOF: actually, I don't see the 7 days on thehw iki page
<pitti> RAOF: right
<pitti> RAOF: please open the associated bugs before, and check that they are fixed in oneiric
<cjwatson> infinity: lp:ubuntu/eglibc r157 was all that was needed to fix it; and having a 3.0.0 kernel on the host should do just as well
<pitti> RAOF: and that there are no late comments about "OMGbroken"
<cjwatson> RAOF: I think at one point it was 10 days; there was a time when I had that in my head too
<pitti> I had always believed that the maturing period was on the wiki
<Sweetshark> pitti: apropos OMGbroken. 3.3.3 in SRU seems to be just that (lost its themeing).
<pitti> Sweetshark: yeah, I saw :(
<RAOF> Heh.  Pithos hasn't been fixed in oneiric yet.
<cjwatson> pitti: I think it is now
<lifeless> cjwatson: well I had a bug on lxc-create duped on it overnight
<pitti> ah, "After one week of maturing in -proposed"
<pitti> I searched for "7", "10", and "days"
<Sweetshark> pitti: Im building it again to see, what the heck went wrong there.
<pitti> RAOF: ^
<cjwatson> lifeless: I bet they're still running a slightly old oneiric kernel.  just tell them to upgrade
<cjwatson> I've looked at the debootstrap change required; I know the code as well as most and it's still fairly scary
<lifeless> cjwatson: I'm upgrading now
<pitti> although this is only in the "special cases"
<cjwatson> so I'm a lot more comfortable with leaving it alone for the moment :)
<RAOF> pitti: Yeah, but that's only in the special-cases :)
<RAOF> Anyway, pithos isn't a candidate because it's not yet fixed in oneiric.
<cjwatson> the business of merging Packages files and taking the highest version will be the fiddly bit
<pitti> RAOF: ah, it's at https://wiki.ubuntu.com/ArchiveAdministration#Stable_release_updates
<infinity> cjwatson: Yeah, and that's the bug I want to fix ANYWAY.
<cjwatson> and probably needs to go in the pkgdetails code (which has two implementations, one in debootstrap and one in base-installer, and they need to be kept in sync interface-wise)
<infinity> cjwatson: (Nevermind the multiple Packages merging, which is a feature request, but the long-standing bug of not picking the highest version)
<cjwatson> yep
<pitti> RAOF: which is out of date wrt. "sru-pending", updating now
<infinity> cjwatson: Hugely annoying when bootstrapping sid with more than one version of some packages publishes.
<cjwatson> I agree it's a problem, but not blocking everyone on it would be pretty good
<infinity> published*
<pitti> RAOF: probably best to remove that entire paragraph, and fix the SRU page instead
<RAOF> pitti: Aha.  Anyway, I'll send foolscap off to -updates, as that *has* been fixed in oneiric and no one's claimed that it set their dog on fire.
 * cjwatson irritated to discover he made an archive mistake that he'd have told anyone else off for making
<cjwatson> grr
<RAOF> pitti: And maybe leave a link.
<pitti> RAOF: yeah, doing
<infinity> cjwatson: Which one?
<infinity> cjwatson: The by-hand stuff?
<cjwatson> d-i not copied to -updates properly, yeah
<cjwatson> did somebody do that for me?  timestamped yesterday
<infinity> S'ok, dist-upgrader hadn't been copied since before the LAST point release too.
<infinity> Clearly, people need to be re-educated on by-hand.
<cjwatson> *cough*
<cjwatson> was that you?
<infinity> And yeah, I fixed it for you.
<cjwatson> cool.  thanks and sorry.
<infinity> S'all good.
<infinity> Might want to check dist-upgrader in other releases, I only did lucid.
<infinity> Who knows what bugs we've fixed and never released!
<saamm> hello I like new gwibber but is there any chance that 5 minute update time limit will be reduced? thanks
<pitti> RAOF: docs updated
<pitti> RAOF: sru-release worked?
<RAOF> Yup.
<RAOF> Whoop whoop!
<pitti> nice
<pitti> oh, my server came back, brg
<cjwatson> published hardy-updates debian-installer properly
<RAOF> pitti: Will you have time to give colord a once-over & upload to Debian, or shall I troll for other sponsors?
<pitti> RAOF: no guarantees, I'm afraid; need to get some stuff done before my holidays and a3
<infinity> cjwatson: Hahaha.  Seriously?
<cjwatson> infinity: you're right, there's a bunch of other stuff that needs proper publication in -updates.  I'll look at it after the next publisher run
<infinity> cjwatson: Yeah, it might be time for a mail to the list. ;)
<cjwatson> infinity: yeah :-/
<cjwatson> lrwxrwxrwx 1 lp_publish lp_publish 19 Apr  6  2010 /srv/launchpad.net/ubuntu-archive/ubuntu/dists/hardy-proposed/main/installer-i386/current -> 20070308ubuntu40.14
<RAOF> pitti: That's fine.  Trolling for sponsors it is!
<cjwatson> lrwxrwxrwx 1 lp_publish lp_publish 19 Jul 20 08:00 /srv/launchpad.net/ubuntu-archive/ubuntu/dists/hardy-updates/main/installer-i386/current -> 20070308ubuntu40.14
<cjwatson> infinity: um, well - I suspect the fault is largely mine
<infinity> cjwatson: You can totally do it while the publisher is running.  Do your work in dists.new and race the clock.
<cjwatson> I've certainly at least been *around* when these were copied
<cjwatson> infinity: oh, sure, I documented how to do that in ArchiveAdministration even :-)
<cjwatson> infinity: but I prefer not to if there's no wild rush
<pitti> cjwatson: want me to add a warning to sru-release when you run it on debian-instsaller? it should at least point to the part of ArchiveAdministration which explains how to do it
<cjwatson> pitti: yes please
<infinity> pitti: And ditto for update-manager.
<pitti> infinity: uh, wasn't even aware of that one
<infinity> pitti: No one seems to be, from the state of the archive. :P
<pitti> committed
<Sweetshark> pitti, infinity: thanks for the stlport tip. For once, it wasnt me who broke it this time.
<infinity> Sweetshark: Always nice to be able to pass the buck. :)
<Amoz> dholbach, hi *waves*
<dholbach> heya Amoz
<Amoz> dholbach, I was thinking about brainstorm.ubuntu.com...
<Amoz> it's the old style 8-D
<dholbach> Amoz, might be worth talking to these people about it: https://launchpad.net/~brainstorm-admins/+members#active
<Sweetshark> infinity: in the rare occurances where I didnt bork it myself ;)
<infinity> cjwatson: Do we know if dist-upgrader actually correctly looks at ${dist}-updates?  If so, I think we've been, quite embarassingly, missing a lot of fixes to update-manager. :/
<infinity> cjwatson: (note that lucid-updates had *no* dist-upgrader directories until I copied the ones from -proposed yesterday)
<Amoz> dholbach, is there a more "prioritized" website somewhere with the old style?
<dholbach> Amoz, might be worth asking in #ubuntu-website
<mvo> infinity: its using the url from http://changelogs.ubuntu.com/meta-release
<mvo> infinity: often I did manually update it to point to the right version in -proposed (right as in the version that is also in updates). but having this correct by copying would be really good
<infinity> mvo: Ahh, I see.  So, you've been working around our failure.  Excellent. :)
<Amoz> dholbach, ah, of course..
<infinity> mvo: But yes, we really should be moving them properly for you and having you reference -updates.
<mvo> infinity: great!
<dholbach> Amoz, I'll try to sort out the license/copyright stuff for the packaging guide thing today
<Amoz> dholbach, niiiice
<pitti> hm, what did I misunderstand about bash's regexps? why is [[ "aaaa" =~ "a*" ]] false?
<poolie> i don't suppose you need to escape the *?
<pitti> no, and I alraedy tried that
<pitti> [[ "aaaa" =~ "aaaa" ]] works, but anythign more complex than that just fails on me :/
<pitti> ah, [[ "aaaa" =~ a* ]]
<poolie> no quotes
<poolie> yeah
<pitti> so seems quotes are special in [[ ]]
<poolie> perhaps only special on the right side of =~
<infinity> Quotes are special all over shell.
<infinity> Anything in quotes is immediately a string.
<poolie> > Any part of the pattern may be quoted to force it to be  matched  as  a  string
<infinity> You'll see the same problem when testing for numeric equality.
<pitti> ok, thanks
<pitti> now I just need to figure out where X="pitti/ppa"; [[ "$x" =~ [[:alnum:]-]+/[[:alnum:]-]+ ]] goes wrong
<poolie> well, i would have assumed like pitti the second argument to =~ was a string
<poolie> aside from the first X being uppercase?
<pitti> *headdesk*
<infinity> *cough*
<pitti> poolie: shame on me :)
<poolie> :) any time
<poolie> some problems are deceptively easy
<bdrung> wgrant: did you filed a bug for the failed import at https://code.launchpad.net/~wgrant/lintian/master
<bdrung> wgrant: i like to setup a daily build for lintian, but this code import fails
<cjwatson> poolie: this is why I avoid bash [[ ]] - its behaviour is totally nonintuitive
<cjwatson> better to use expr IMO
<cjwatson> or case
<cjwatson> case $string in pattern) ... ;; esac
<poolie> it does seems like a layer violation that it changes the quoting rules
<poolie> but, sh is full of them
<poolie> i would tend to use case too
<poolie> though, can you use regexps?
<cjwatson> sure, but this is yet a new set of quoting rules :-)
<cjwatson> no, but globs are often enough
<bdrung> tumbleweed: do you have done something to fix bug #801945?
<ubottu> Launchpad bug 801945 in ubuntu-dev-tools (Ubuntu) "[backportpackage] Fails to backport local .dsc file" [High,New] https://launchpad.net/bugs/801945
<poolie> actually, i would tend to use zsh globs in personal use scripts
<lifeless> cjwatson: ok, the oneiric cd for some reason hadn't installed linux-generic
<cjwatson> you can use regexps in expr
<lifeless> cjwatson: so kernel upgrades were not happening automatically
<cjwatson> life	that's odd
<cjwatson> poolie: the other reason I avoid [[ ]] is that much of my shell code has to run in plain POSIX sh
<poolie> right
<cjwatson> and it's easier for me to be in the habit of just writing in POSIX sh all the time
<pitti> cjwatson: so should I get rid of that [[ ]] stuff in ubuntu-defaults-image then, and rewrite it using expr?
<cjwatson> pitti: if it were me then I would use expr, yes
<poolie> i wonder if posix expr understands regexp matches?
<cjwatson> it's only one extra fork, I doubt it makes any realistic performance difference
<pitti> I can replace the ( ) backref matching with some string operations, will just look a little more complicated
<poolie> perhaps it's a quirk of linux we might try to use a minimal sh but not a minimal expr
<lifeless> cjwatson: indeed
<cjwatson> poolie: yes, it does.  http://pubs.opengroup.org/onlinepubs/9699919799/utilities/expr.html
<cjwatson> it's a basic RE anchored to the start of the string
<poolie> but only the operator ':' not 'match'
<wgrant> bdrung: There is a bug about that sort of thing already.
<cjwatson> correct
<bdrung> wgrant: can you give me a number?
<cjwatson> I just have http://pubs.opengroup.org/onlinepubs/9699919799/nfindex.html bookmarked for this kind of thing
<wgrant> bdrung: Bug #212195
<ubottu> Launchpad bug 212195 in Bazaar "Cannot use backslash character in file name (dup-of: 81844)" [Undecided,New] https://launchpad.net/bugs/212195
<ubottu> Launchpad bug 81844 in Bazaar "Handle backslashes in filenames more gracefully" [Wishlist,Confirmed] https://launchpad.net/bugs/81844
<dupondje> Somebody knows an easy way to get package version of a debian package in python?
<cjwatson> given what, a .deb?
<bdrung> wgrant: thanks.
<dupondje> cjwatson: given the package name. It should check the debian repo's
<bdrung> dholbach: is there a lp project that gathers code import bugs / daily build blockers?
<dholbach> there's a tag - hang on
<bdrung> dupondje: maybe python-debian?
<cjwatson> you could either use python-apt and download the appropriate tagfiles and such yourself, or else just call out to rmadison -u debian with subprocess
<lifeless> cjwatson: indeed, it is. I can get the date of the iso if that would help
<dupondje> ubuntutools.requestsync.lp.getDebianSrcPkg exists also it seems :)
<cjwatson> lifeless: the installer syslog would help more
<cjwatson> (and contains the date of the iso)
<dholbach> bdrung, https://bugs.launchpad.net/launchpad/+bugs?field.tag=recipe maybe?
<dholbach> bdrung, there's "code-import" too
<bdrung> dholbach: code-import seems more appropriate
<bdrung> thanks
<dholbach> de nada
<johnt> hi folks, can anyone help me with a debian installer question?
<cjwatson> johnt: possibly, what is it?
<johnt> cjwatson: im trying to figure out whats the best way to disable the screensaver on a preseeded install cd, if that makes sense. i'm sure there is an easy way to do it but i cant figure it out :(
<johnt> cjwatson: i tried using gconftool-2 but it doesn't seem to be present or working in the install environment. any ideas?
<cjwatson> johnt: you're probably trying to run gconftool-2 in the installer environment rather than in the target system.  are you using preseed/late_command?
<johnt> yeah - hold on one sec and ill tell you exactly what i have...
<cjwatson> and if so can I see the preseed/late_command you're setting?
<cjwatson> cool
<johnt> d-i preseed/late_command string in-target /usr/bin/gconftool-2 --type bool --set /apps/gnome-screensaver/idle_activation_enabled "FALSE"
<cjwatson> hm, that should work fine, although as good practice you should avoid hardcoding the path to gconftool-2 and just call it by its name
<johnt> cjwatson: does that look like it should work?
<cjwatson> do you have an installer syslog?
<cjwatson> well, you might need to think about which gconf database you're trying to edit, since you don't have a user context here
<johnt> probably - is the syslog stored somewhere on a system which has been installed using this preseed file?
<cjwatson> /var/log/installer/syslog
<johnt> ah cool - let me take a look...
<johnt> how do you tell it which gconf database to use?
<cjwatson> you might need something like '--config-source xml:readwrite:/etc/gconf/gconf.xml.defaults'
<johnt> cjwatson: strange - there doesnt seem to be an error in the syslog where the command should execute.
<johnt> cjwatson: should i use '--direct' ?
<cjwatson> johnt: oh, yeah, probably
<cjwatson> gconfd definitely won't be running
<johnt> presumably there is no server running in the install environment?
<cjwatson> indeed not
<seb128> cjwatson, johnt: what ubuntu version?
<johnt> 10.04
<seb128> cjwatson, johnt: that command will not work in oneiric, gnome-screensaver stopped using gconf in GNOME3
<seb128> ok
<cjwatson> (it may be different if you're writing a preseed file for the desktop installer, but you aren't)
<seb128> so that should work ;-)
<johnt> cool!
<johnt> cjwatson: ill give that a shot, thanks so much for your help - this problem has been bugging me for days!
<cjwatson> surprised there's nothing in the installer syslog; that would imply that gconftool-2 is just failing silently without printing anything to stdout or stderr, which would be weird
<johnt> i know - it doesnt make sense really
<cjwatson> sure you're looking in the right place?
<cjwatson> I'm generally happy to skim syslogs for people
<johnt> yeah - i can see the next command running successfully
<johnt> ill try it again and if i doesnt work ill paste the syslog :D
<bigon> RAOF: hi, about strongswan SRU did you have actually accepted the pkg? I see nothing in the lp
<pitti> RAOF: ah, strongswan accepted, too?
<johnt> cjwatson: still there?
<cjwatson> y
<johnt> that doesnt seem to have worked - have you got a sec free to help me figure out why?
<cjwatson> kind of, would be easier if you just described the problem
<cjwatson> waiting for people to be free at the same time doesn't really work on irc :-)
<johnt> ah
<johnt> well
<johnt> there still doesnt seem to be anything in the syslog
<johnt> the screensaver is still enabled in gconf-editor when i log in
<johnt> and /etc/gconf/gconf.xml.defaults/ seems to be empty for some reason
<johnt> sorry, the config file %gconf-tree.xml is empty
<johnt> http://dl.dropbox.com/u/124791/preseed_syslog.txt
<cjwatson> this doesn't explain your entire problem, but you can't set preseed/late_command multiple times like that
<cjwatson> rather than thinking of a preseed file like a program, think of it as setting a bunch of keys in a database which are then fetched later
<cjwatson> only the last one will be used
<davmor2> how do I go about requesting a driver for a wifi card is it just a bugreport with hardware details?
<cjwatson> (so that might actually explain your problem if you have some other preseed/late_command entry after that in your preseed file)
<cjwatson> for multiple commands, use:
<cjwatson>   d-i preseed/late_command string in-target gconftool-2 blah; in-target gconftool-2 blah; ...
<johnt> so you can only have one late_command?
<cjwatson> actually I think that does explain your problem, since you appear to have 'd-i preseed/late_command string in-target /opt/VScan/kav_install.sh' after the entries you quoted
<cjwatson> yes, but it can be a compound command
<cjwatson> as in multiple commands separated by ; or &&
<cjwatson> the whole thing is just passed to the shell
<johnt> ah ok cool
<johnt> so - why did the .sh run but the ones before it didnt?
<cjwatson> because you set the same variable multiple times; the last setting won
<johnt> ah
<johnt> ok - very cool
<cjwatson> it's not a program, it's a list of entries to insert into a database
<johnt> sure - i was kind of treating it like a script which was run line by line
<cjwatson> right, that's not an uncommon mistake to make
<johnt> other than that, does the syntax of the gconftool-2 command look right?
<cjwatson> johnt: I think so, but I am not a gconf expert, only an installer expert.  (again, though, you shouldn't hardcode the path to gconftool-2 - just write it as "gconftool-2", not "/usr/bin/gconftool-2")
<johnt> cjwatson: ok, cool ill change that. thanks again for your help - much appreciated!!!
<cjwatson> no problem
<hallyn> this bug about groupadd failing to lock gshadow (as in bug 813180)  deja vu.  is there a known other bug causing it?
<ubottu> Launchpad bug 813180 in qemu-kvm (Ubuntu) "package qemu-kvm (not installed) failed to install/upgrade: subprocess new pre-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/813180
<hallyn> i think we need a fix for groupadd to have *it* retry rather than failing dpkg -i
<johnt> cjwatson: are you still there?
<cjwatson> johnt: again, I recommend just saying what your problem is rather than checking if I'm here first
<johnt> ok, will do. having the FALSE in "" shouldnt make any difference right? also, is it ok to split up the string into multiple lines with \ ? finally - does each seperate command need its own "in-target"?
<cjwatson> FALSE in quotes or without makes no difference either way
<cjwatson> splitting up into multiple lines: answered in https://help.ubuntu.com/10.04/installation-guide/i386/preseed-creating.html
<cjwatson> either put in-target in front of each command, or use  in-target sh -c 'command; command; command'
<cjwatson> the latter will be a bit faster but you may or may not regard it as harder to read
<kirkland> infinity: there are two new utilities for byobu, byobu-quiet and byobu-silent, which disable all of the monitors
<kirkland> infinity: while still maintaining the keybindings, etc.
<kirkland> infinity: not that I expect to change your opinion, but when people make reasonable (and sometimes even unreasonable) critiques, I listen, and try to implement the suggestion
<kirkland> infinity: SpamapS: with respect to the forks, I've reduced them tremendously (by perhaps 90%)
<jjardon> Hi, Ubuntu One configuration will use the online accounts panel?
<seb128> jjardon, try asking to dobey, he's on #ubuntu-desktop for example, but I doubt it, at least for this cycle, they have something that works for a while not sure they plan to rewrite it
<seb128> jjardon, especially that they want their dialog to be cross platform I think and not linux specific
<jjardon> seb128: who is "they" ?
<seb128> jjardon, the ubuntuone team, they have a win client as well at least
<seb128> jjardon, so not sure how much they want os specific integration rather than a standalone dialog they can build on different platforms
<seb128> jjardon, dobey should know better
<jjardon> seb128: ok, I'll ask. thanks!
<seb128> yw
<tkamppeter> mpt, hi
<mpt> Hello tkamppeter
<tkamppeter> mpt, I have put together all about s-c-p and but it into a bug on GNOME. Have I correctly CCed you?
<tkamppeter> https://bugzilla.gnome.org/show_bug.cgi?id=654742
<ubottu> Gnome bug 654742 in Printers "GNOME printer setup panel is lacking advanced techniques for printer discovery, driver selection, and automatic print queue creation" [Major,Unconfirmed]
<smb> doko_, Is there some flag to prevent gcc-4.6 from using a .text.startup section for main?
<johnt> cjwatson: i got that working, thanks again for all your help!
<cjwatson> excellent
<davmor2> that would be a security issue then I can login without a password even though I select use a password to login from the oneiric installer :(
<kees> davmor2: that seems not good :)
<davmor2> kees: although the unity desktop doesn't start, and in ctrl-alt-f1 I need to login so may just be an issue with  light dm
<smb> Sounds like a state I had after install a while ago
<doko_> smb: don't know, would have to search myself
<smb> But it seemed to have changed after last updates
<smb> doko_, Hm, ok. Cause that seems to be the issue. When compiling with gcc-4.5 or with gcc-4.6+O1, it seems to bootstrap code remains the first thing, and that and the other code is in .text
<smb> doko_, But otherwise the everything else goes into .text but main gets into a .text.startup and then is reordered when linking
<doko_> smb: is this both oneiric?
<smb> doko_, Yes, compiled the same code in a oneiric chroot.
<Laney> cody-somerville: did you mail the TB about adding Rhonda's PPU access?
<davmor2> Oh interesting, lightdm shows my name Dave Morley for login, if I click on it, it seems to magically login,  however if I click on other and use my nick it then asks for the password and I get unity up and running
<smb> davmor2, Strangely I had just the same ting (except the unity running part) right after install last Friday. Since then I had been done upgrades and that went away. Even unity seems sort of willing in accelerated mode.
<cody-somerville> Laney, Not yet. I wasn't aware I had to.
<Laney> cody-somerville: Well, not necessarily mail, but you have to ask a TB member to do it
<micahg> could I get someone to give back gupnp-igd (main) on all archs?
<cjwatson> micahg: done
<micahg> cjwatson: thanks!
<climbe2> Problem!  If anyone is able to help.... running 10.04, recently upgraded to kernel 2.6.32-33, and can't boot up!!  See http://ubuntuforums.org/showthread.php?t=1807978 for my ongoing thread.  Any suggestions?!?!
<climbe2> #Ubuntu is very busy...too many people with too many problems.... #ubuntu-kernel has not replied
<climbe2> would love to hear from someone!
<Pici> climbe2: That doesn't make this a support channel. Either ask again in #ubuntu or try searching https://help.ubuntu.com or http://ubuntuforums.org or http://askubuntu.com/
<climbe2> oh, ok. Understood.  Thank you!
<Riddell> barry: don't forget the packaging guide reviews :)
<barry> Riddell: gotcha, thanks for the reminder ;)
<barry> Riddell: heading to lunch now, but will take a look after
<debfx> kenvandine: install pidgin currently pulls in half of gnome through indicator-status-provider-pidgin -> indicator-messages
<debfx> kenvandine: do you think we could drop the indicator-messages dependency?
<kenvandine> debfx, is it a depends?
<kenvandine> pidgin-libnotify recommends the provider
<micahg> kenvandine: we install recommends by default
<kenvandine> micahg, yeah... but we want a recommends there
<debfx> kenvandine: installing indicator-status-provider-pidgin is fine but does it really have to depend on indicator-messages?
<kenvandine> yes
<kenvandine> it can't work without it
<kenvandine> but indicator-messages shouldn't have any gnome depends
<kenvandine> it depends on libindicate and a indicator-renderer
<infinity> kirkland: It'll never be a product targetted at me (and that's fine, yay for free software not having to be one-size-fits-all), but I'm happy regardless to hear about the reduction in forks, and the slimmer options. :)
<debfx> kenvandine: indicator-messages -> indicator-applet -> gnome-panel
<kenvandine> indicator-applet | indicator-renderer (i think)
<kirkland> infinity: agreed;  definitely not targeted at everyone (or a sysadmin of your persuasion)
<infinity> kenvandine: That's a recommend.
<kenvandine> yes
<infinity> kenvandine: "apt-get --no-install-recommends install pidgin"?
 * micahg sees KDE doesn't have an indicator-renderer
<debfx> kenvandine: yes, but package mangers choose the first one if none is installed
<kenvandine> kde does have one
<kenvandine> i am pretty sure :)
<kenvandine> i know indicators work in kde
<kenvandine> something provides indicator-renderer
<micahg> kenvandine: it's not providing the indicator-renderer virtual package then
<infinity> Yeah, I don't see anything KDEish providing it.
<infinity> So, that might be the real bug here. :P
<kenvandine> somehow the indicators do get displayed in kde... at least they did
<micahg> right, that's why xubuntu doesn't have the same issue
<debfx> so plasma-widget-message-indicator should provide indicator-renderer?
<kenvandine> probably
<infinity> Almost certainly.
<kenvandine> something should, and that sounds right
<kenvandine> i am sure agateau in #ayatana knows for sure
<kenvandine> which package that is
<debfx> ah indicator-renderer is just about rendering StatusNotifierItems?
<kenvandine> debfx, yes
<kenvandine> indicator-messages is just the service that provides them
<debfx> ok, then plasma-widgets-workspace should provide indicator-renderer
<bdmurray> pitti: with regards to https://code.launchpad.net/~brian-murray/ubuntu/oneiric/apport/conffile-handling/+merge/68477.  Source package hooks aren't translated so this translating the string in hook utils seems inconsistent to me.
<dupondje> https://launchpad.net/ubuntu/+source/mlton/20100608-4 => Could some admin fix this? armel build waits on itself. Eventually sync the newest version from debian.
<lfaraone> !regression-alert bug 788351 causes 4/8 bytes of kernel memory to be overwritten in certain circumstances
<ubottu> Launchpad bug 788351 in linux (Ubuntu) "xfs ioctl XFS_IOC_FSGEOMETRY_V1 clobbers kernel stack" [High,Triaged] https://launchpad.net/bugs/788351
<ubottu> lfaraone: I am only a bot, please don't think I'm intelligent :)
<lfaraone> !regression-alert
<ubottu> cjwatson, jdong, pitti, skaet, ScottK, kees, Daviey, pgraner: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
<skaet> lfaraone,  ack.
<skaet> lfaraone, per pgraner,  the kernel to fix it is in -proposed.
<seb128> bdrung, hey
<bdrung> seb128: hi
<seb128> bdrung, you will be happy, desrt is fixing the glib units handling ;-)
<bdrung> \o/
<seb128> he deprecating the current function, changing the default and adding a function that let you specify if you want base-2 or base-10 units
<seb128> he->he's
<bdrung> great
<bdmurray> barry: how does computer-janitor sort the list of packages for removal?
<barry> bdmurray: sorts by name by default.  there's a menu item to sort by size, but that's broken because of bug 806574
<ubottu> Launchpad bug 806574 in computer-janitor (Ubuntu Oneiric) "computer-janitor-gtk crashed with AttributeError in reorder(): 'ListStore' object has no attribute 'reorder'" [Medium,Triaged] https://launchpad.net/bugs/806574
<bdmurray> barry: really mine didn't seem sorted at all - too late for a screenshot though
<barry> bdmurray: maybe file a bug, or follow up on the above?  i need to find time to get to it but i am planning on giving cj some love this cycle
<bdrung> seb128: thanks
<seb128> bdrung, thanks desrt, he's the one who worked on it ;-)
<bdrung> seb128: on which channel is he?
<seb128> bdrung, #ubuntu-desktop for example
<seb128> though he seems to be away from his computer now but he will read the backlog when he's back I guess
<Daviey> Anyone else noticed some oddities with python2.7 in the last few days?
<Daviey> Can't quite put my finger on it, but some things seem to not be functioing correctly
<jelmer> Daviey: there's a regression in the current snapshot in oneiric that breaks bzr
<jelmer> other than that, python2.7 seems to be fine here
<Daviey> odd, http://pb.daviey.com/gjyF/raw/
<broder> ScottK: ping? i wanted to get your opinion on bug #784617. my inclination is to just refuse outright, given the core-ness of the package and the scope of the r-dep testing, but i'd like a second opinion
<ubottu> Launchpad bug 784617 in lucid-backports "Please Backport Openssh-Client " [Undecided,New] https://launchpad.net/bugs/784617
<ScottK> broder: ssh backports are no sale.  I agree.
<broder> ok, i'll close it
<dupondje> Could somebody check https://launchpadlibrarian.net/75520549/buildlog_ubuntu-oneiric-i386.openmpi_1.4.3-2.1_FAILEDTOBUILD.txt.gz ?
<dupondje> Would like to get a direction on how to solve/debug.
<broder> dupondje: is there a .docs file?
<broder> the issue is that the AUTHORS file in the upstream source is a symlink
<broder> probably a relative symlink
<dupondje> broder: there is no .docs file
<smoser> barry, or doko_ around ? or, anyone have any ideas on bug 810019
<ubottu> Launchpad bug 810019 in distribute (Ubuntu) "UserWarning printed on import pkg_resources'" [Undecided,New] https://launchpad.net/bugs/810019
<broder> dupondje: yeah, the files are getting listed in the dh_installdocs invocation in debian/rules
<smoser> I don't see it on my desktop oneiric system, but see it on the ec2 images
<dupondje> Well it does 'dh_installdocs --all AUTHORS NEWS README'
<dupondje> so those file are installed
<broder> right
<broder> look at the AUTHORS file, though
<broder> it's probably a symlink
<dupondje> nope
<dupondje> its a text file in the source root
<barry> smoser: i don't see that on my oneiric box, but i don't think i have paste installed
<broder> hmm...maybe it's a pkgbinarymangler issue, then?
<barry> smoser: and that's an odd warning ;)
<smoser> barry, it shows up all the time.
<smoser> (bug has a simple 'python -c' reproduce)
<smoser> i can give you access to a system if you want
<dupondje> broder: no idea ... Any idea how I can debug this?
<barry> smoser: reproduced after installing python-paste
<barry> smoser: so my guess is paste is doing something weird/evil/illogical/insane/mean/nasty/dumb/bogus/wacked
<broder> dupondje: wait a second...i think the problem is that dh_installdocs is getting called twice for some reason
<dupondje> Its in binary-arch and binary-indep indeed
<broder> dupondje: with --all in both? that's a problem
<smoser> hm.. i wonder what recommends got python-paste pulled into the images
<dupondje> broder: both         dh_installdocs --all AUTHORS NEWS README
<dupondje> guess it only needs to be in the indep ? as that one builds the doc ?
<dupondje> or
<broder> dupondje: no, you should pass -a and -i in -arch and -indep respectivelyt
<broder> you shouldn't be acting on arch-indep packages in binary-arch, or arch-dep packages in binary-indep
<dupondje> so: dh_installdocs -a --all AUTHORS NEWS README right ?
<dupondje> and -i in indep
<broder> dupondje: no --all
<broder> in either
<smoser> thank you barry
<barry> smoser: good question.  i've updated the bug.  np!
<Daviey> barry: Seen this: http://pb.daviey.com/gjyF/raw/ ?
<barry> Daviey: nope, that's a new one for me ;)
<Daviey> :(
<Daviey> poor me
<barry> Daviey: you might check on #launchpad-dev
<Daviey> barry: i've seen some other oddities.. with 2.7 the last day.
<barry> Daviey: dang, that's not good
<Daviey> barry: if nobody else has seen it, it could just be a local issue.
<barry> Daviey: could be.  wfm ;)
<dupondje> broder: https://launchpadlibrarian.net/75642759/openmpi.debdiff guess this should do :)
<broder> dupondje: LGTM. give me a few minutes and i'll sponsor it
<dupondje> thanks for the assistance
<dupondje> guess i'll better post it upstream also :)
<broder> np
<broder> dupondje: since you're looking at the package already, do you have any idea what's up with bug #697229?
<ubottu> Launchpad bug 697229 in openmpi (Ubuntu) "openmpi link failure with ld --as-needed" [Undecided,New] https://launchpad.net/bugs/697229
<dupondje> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621978
<ubottu> Debian bug 621978 in src:openmpi "openmpi: FTBFS: libopen-pal.so.0: could not read symbols: Invalid operation" [Serious,Fixed]
<dupondje> got nmu'ed it seems
<broder> ah, so we can close it?
<dupondje> it just ftbfs on i386 due to that docs shizzle
<dupondje> else its fine
<dupondje> can be closes indeed
<broder> k, will do
<dupondje> reported the dh_installdocs bug upstream also :)
<dupondje> broder: https://bugs.launchpad.net/ubuntu/+source/openmpi/+bug/697229 => doesn't seem to be a ftbfs, but a bug in the package itself
<ubottu> Ubuntu bug 697229 in binutils (Ubuntu) "openmpi link failure with ld --as-needed" [Undecided,New]
<dupondje> checking if thats really fixed now
<broder> dupondje: ah, i see
<broder> dupondje: thanks for double-checking me
<Daviey> dupondje: surely a ftbfs if not transient, is usually a bug in the package itself?
<broder> Daviey: it's a bug from using the package
<broder> openmpi does some code generation of one kind or another
<Daviey> awesome.
<dupondje> indeed :)
<broder> dupondje: can you take care of reopening that bug if it isn't actually fixed?
<dupondje> i'll do
<broder> great
<dupondje> broder: seems not fixed :)
<broder> dupondje: alas
<dupondje> can you change it to New again ?
<dupondje> don't have the permissions it seems :s
<broder> sure
<smoser> barry, would you take a quick look at bug 813295
<ubottu> Launchpad bug 813295 in python2.7 (Ubuntu) "oneiric images do not run in eucalyptus" [High,Confirmed] https://launchpad.net/bugs/813295
<dupondje> broder: you requested a rebuild of openmpi ?
<broder> dupondje: i'm doing a local test build with your patch now
<broder> to make sure it works
<broder> i'll upload once that finishes
<broder> (it takes a *while* to build, apparently)
<dupondje> no stress :D
<barry> smoser: bug updated
<smoser> barry, thanks again.
<smoser> that issue is somewhat a big deal for us.
<barry> smoser: let's see if anything happens upstream, and i can back port a fix.  if it gets critical for you, ping me and i'll try to spend some time on it
<hallyn> is it possible to install debug symbols when running from live-usb?
<RAOF> hallyn: Yup, they're essentially just regular packages.
<hallyn> awesome, thanks :)
<RAOF> hallyn: You'll need to add ddebs.ubuntu.com to the sources.list first, though.
<hallyn> yup
<hallyn> I may need to get my hands on an amd board to test kvm
#ubuntu-devel 2011-07-21
<jbicha> barry: I am packaging gnome-games 3.1.3 and have updated it for dh_python2
<slangasek> cjwatson: I should be able to make the release meeting on Friday, provided I can work out what time it actually is ;)
<TheMuso> slangasek: I sent ubuntu-core-dev an invite to be a member of ubuntu-audio-dev a while back, but it wasn't followed up on. Should I be doing something differently?
<TheMuso> Granted I didn't chase it up, but not many others outside of ubuntu-audio-dev nave needed to touch the package.
<micahg> TheMuso: might get better results just asking an admin of the group to accept the invite
<TheMuso> micahg: Yeah this is true, will chase it up later.
<persia> TheMuso, Why does ubuntu-core-dev want to me a member of ubuntu-audio-dev?  I'm happy to press the button, but wonder about the use case.
<TheMuso> persia: So people like slangasek can do multi-arch/other work on audio packages and can upload without having to file merge requests, as has been done for alsa-lib.
<persia> TheMuso, Also, do you happen to know why there are invitations outstanding to both ~ubuntu-core-dev and ~ubuntu-dev?  Which do you want?  If both, why?
<micahg> should *not* be ubuntu-dev... IMHO :)
<persia> That ~ubuntu-audio-dev owns some package branches is a good reason :)
<TheMuso> persia: Yes, I know why the core-dev one is there, because I created it as above. As for ubuntu-dev, I don't know why thats there, if I accidentally created it, then it should be declined.
<TheMuso> Having worked without core-dev having access to ubuntu-audio-dev branches for a while, it hasn't been a problem, so I am personally happy with the status quo, but if others like slangasek think otherwise, then I'm fine with that too.
<micahg> persia: having ubuntu-dev a member would allow any contributing dev write access
<TheMuso> https://code.launchpad.net/~vorlon/alsa-lib/multiarch-merge/+merge/68624 is where it was raised.
<persia> TheMuso, ubuntu-core-dev accepted, ubuntu-dev declined.
<TheMuso> ok thanks.
<persia> micahg, No it wouldn't.  "Contributing Developer" is just confusing nomenclature for "Ubuntu Member".  To be part of ~ubuntu-dev, you need to have been granted upload permission for *something*.
<micahg> persia: I thought the only "ubuntu member" status the DMB could grant was through ubuntu-dev
<persia> micahg, Nope.  A special group for Contributing Developers was created, which is a member of ~ubuntumembers but not ~ubuntu-dev
<micahg> persia: ah, cool, well, then anyone with PPU :)
<persia> At one point what you say was true, but the MC asked the CC about it, because we had folk that we thought should be members, but not yet developers, and we didn't see why we had to tell them to go ask someone else, rather than just granting them membership.
<persia> And the CC directed the creation of a special team for the MC to grant membership indirectly, which the DMB has inherited.
<micahg> ah, good to know
<persia> But anyway, we assert that we trust anyone with a PPU with the power to modify user systems, which is a fairly high level of trust.  I don't think we'd want to exclude someone with PPU access from doing anything generally extended to all developers.
<persia> Whereas, ~ubuntu-core-dev is kinda different: to preserve the maintainer-of-all-software-in-the-archive characteristic, that team needs access to all packaging branches, all packages, etc.  Which means that it makes sense for it to join lots of other teams.
<persia> TheMuso, I'm reminded: please make sure that any bugmail currently received by the Ubuntu Audio Developers team isn't leaking to all core-dev.
<micahg> persia: right, which is what I think the goal was, that core-dev should be able to have branch commit access
<TheMuso> persia: Ubuntu-audio-dev gets no bugmail, that goes to ubuntu-audio.
<persia> micahg, Indeed: just wanted to have a complete set of statements in the logs :)
<persia> TheMuso, Ah, excellent.  Some teams are not so well organised.
<persia> TheMuso, So, a related question: would you want the members of ubuntu-audio-dev to be able to upload the packages for the branches owned by ubuntu-audio-dev, or does the team dynamic have a split between committers and releasers?
<pitti> Good morning
<pitti> bdmurray: ah, fair enough
<TheMuso> persia: ubuntu-audio-dev came about primarily so that PPAs of audio software could be made available in one place. It also allows other audio devs who do not have upload privileges to do packaging work. I still do the final checks and upload, or Daniel if he is around at the time.
<persia> TheMuso, makes sense.  If you decide to change at some point in the future, let me (or any DMB member) know, and we'll happily walk you through the process.
<TheMuso> persia: ok thanks.
<pook1e> I'm trying to build a package for testing in oneiric, and I'm getting "configure: error: Package requirements (indicator >= 0.3.0) were not met:" after it checks if indicator is installed. Any way around this?
<jbicha> pook1e: do you have libindicator-dev as a build-depends?
<pook1e> How can I check that?
<pook1e> Sorry, yes libindicator-dev is in the build-depends
<jbicha> pook1e: and you have libindicator-dev installed right?
<didrocks> good morning
<pook1e> I added libindicator-dev to my base tarball
<pook1e> But it's still giving me the same error.
<jbicha> pook1e: what package?
<pook1e> indicator-network
<pook1e> Trying to build it for oneiric-i386 with pbuilder.
<pook1e> Here's a paste of the end of the log, not sure if it will help or not: http://paste.ubuntu.com/648812/
<dnivra> hello. Which port of keyserver.ubuntu.com does gpg connect to when uploading the key? I am behind a proxy/firewalll and i think that's why it's failing.
<pitti> dnivra: you can explicitly use hkp://keyserver.ubuntu.com:80
<pitti> that ought to work
<slangasek> TheMuso, persia: like most such things, it doesn't become an issue until someone needs it... the Vcs-Bzr branches for several core library packages are owned by ubuntu-audio-dev, ubuntu-core-dev should have commit access there to avoid getting the archive out of sync
<pitti> dnivra: the standard port is something like 11037, i. e. most probably firewalled for you then
<dnivra> pitti: no feedback is given in case of a successful upload?
<slangasek> persia: thanks for the perm accept :)
<persia> slangasek, Absolutely.  If you find any other cases where ~ubuntu-core-dev can't do the right thing, I'm happy to help with group membership.
<slangasek> persia: ta
<dnivra> pitti: i guess it worked. Thanks!
<persia> slangasek, Note that I'm not generally in favour of misalignment between folks-who-can-push-to-packaing-branch and folks-who-can-upload, but that's more complicated to solve.  Some folk like getting reviews of their work, and other folk don't like to use bzr merge.
<slangasek> heh
<pitti> dnivra: I'm not sure
<dnivra> ah well I'll know when I upload the fingerprint in half an hour :)
<geser> dnivra: keyserver.ubuntu.com has also an web interface which you can use to query for keys
<cjwatson> slangasek: heh, OK, I'll let you arrange it with doko then ...
<slangasek> cjwatson: ack
<slangasek> TheMuso: while I'm at it, is it ok if I upgrade the alsa-lib package branch to a modern bzr format?
<slangasek> TheMuso: i.e., people will need to use bzr from lucid or better when working with the oneiric branch... seems reasonable to me, but I'll ask to be safe :)
<dholbach> good morning
<Amoz> dholbach, looks like the css is pointing to /media/img/ , not /media/images
<dholbach> Amoz, oopsie
<dholbach> I better get that fixed then :)
<Amoz> dholbach, where'd you get all that extra css code for light django theme?
<tkamppeter> I have problems with pbuilder, it does not create a new distro image, I get at the very end:
<tkamppeter> I: mounting /proc filesystem
<tkamppeter> mount: /proc already mounted or /var/cache/pbuilder/build//27206/proc busy
<tkamppeter> mount: according to mtab, /proc is mounted on /proc
<tkamppeter> W: Aborting with an error
<tkamppeter> I: cleaning the build env
<tkamppeter> I: removing directory /var/cache/pbuilder/build//27206 and its subdirectories
<tkamppeter> rmdir: failed to remove `/var/cache/pbuilder/build//27206/proc': Device or resource busy
<tkamppeter> rmdir: failed to remove `/var/cache/pbuilder/build//27206': Directory not empty
<dholbach> Amoz, we weren't supposed to use that branch - there was a newer one which I nicked it from
<dholbach> Amoz, it's all in the BORROWED-CODE file
<tkamppeter> I also cannot delete /var/cache/pbuilder/ccache/, I get "Permission denied" as root.
<Amoz> dholbach, I see
<Amoz> dholbach, also, the img/images directories seems to be spread out
<Amoz> it's a mess ^^
<dholbach> Amoz, I'll have a look in a sec
<TheMuso> slangasek: go ahead
<Amoz> dholbach, also, what is the indexes for in the guide? genindex.html for example? seems all the long names in the relbar will fudge the layout once one get to the konwledge base chapter
<dholbach> Amoz, I have no idea - you added it :-P
<Amoz> oh, did I? o.O
<Amoz> can I remove the general index link then?
<Amoz> it confuses me..
<dholbach> I think it's part of the sphinx theming bits
<dholbach> if it has no effect we should remove it :)
<Amoz> it's in the default theme.. hmm
<Amoz> but it's very intrusive there
<Amoz> because the theme is much smaller now, we can't have a lot of long names in that small bar =(
<slangasek> TheMuso: ta :)
<Amoz> dholbach, included the js-docs, now the search function works
<Amoz> or, it should
<dholbach> ah, nice
<Amoz> dholbach, I think we move down the searchbox from the relbar (where all the refs and chapters are supposed to be + next/prev )
<dholbach> sure - that works for me
<Amoz> a css hacker need to fix it though
<tkamppeter> pitti, hi
<pitti> hello tkamppeter
<tkamppeter> pitti, I have uploaded the first opackage of cloudprint last week and it is still in NEW (I had CCed you in a mail about my Google Cloud printing support plans). How will it get into the archive.
<pitti> the archive admins should get to it; but NEW processing seems to lag behind a bit indeed
<tkamppeter> pitti, or do I need to report a bug about including this package?
<pitti> no, that won't help
<Amoz> dholbach, we have a sphinx mystery. searchindex.js is probably a dynamic generated file for keywords and stuff. the question is where/how to generate it?
<tkamppeter> pitti, so in the worst case it will sit there until my planned UDS session happens?
<pitti> no, it shold really be processed within the next days
<dholbach> Amoz, I never played around with it, so I have no idea - I suggest we try to get everything else ready first and a file a bug report as a reminder
<tkamppeter> pitti, also no answer on my e-mail, probably such planning works only on UDS.
<Amoz> dholbach, yeah, I need to stop bugging you when thinking aloud. oops, there I did it again, sorry! :P
<tkamppeter> pitti, did you get that e-mail?
 * dholbach hugs amo
<dholbach> z
<Quintasan> Good morning.
<jelmer> hi Quintasan
<tkamppeter> pitti, still there?
<pitti> tkamppeter: what was "that" email?
<pitti> tkamppeter: had an appointment, back now
<tkamppeter> pitti, sorry, I did not include you, but FYI I will forward it to you.
<Laibsch> barry: I was wondering what a reasonable time-frame would be for dh_python2 and python-all > 2.6.6-3 to hit lucid? bug 811506
<ubottu> Launchpad bug 811506 in python-defaults (Ubuntu) "please backport python-all 2.6.6-3 or later to lucid (dup-of: 788524)" [Undecided,New] https://launchpad.net/bugs/811506
<ubottu> Launchpad bug 788524 in python-defaults (Ubuntu) "backport dh_python2 to lucid (and maverick if appropriate)" [Undecided,In progress] https://launchpad.net/bugs/788524
<tkamppeter> pitti, I have also another problem, with pbuilder. I cannot set up an Oneiric image. See my messages of 09:56am today in this channel.
<Quintasan> tkamppeter: This one with pbuilder is known, something wrong with debootstrap magic or something else
<Quintasan> tkamppeter: You can create a natty one and upgrade it
<Quintasan> Just use --save-after-login option
<tkamppeter> Quintasan, and how do I clean up the ccache, as I get "Permission denied" as root there?
<tkamppeter> Quintasan, unfortunately, it also does not build natty, same problem:
<tkamppeter> I: mounting /proc filesystem
<tkamppeter> mount: /proc already mounted or /var/cache/pbuilder/build//30385/proc busy
<tkamppeter> mount: according to mtab, /proc is mounted on /proc
<tkamppeter> W: Aborting with an error
<tkamppeter> I: cleaning the build env
<tkamppeter> I: removing directory /var/cache/pbuilder/build//30385 and its subdirectories
<tkamppeter> rmdir: failed to remove `/var/cache/pbuilder/build//30385/proc': Device or resource busy
<tkamppeter> rmdir: failed to remove `/var/cache/pbuilder/build//30385': Directory not empty
<tkamppeter> Quintasan, or should I --create on a Natty box, copy over the image and upgrade on an Oneiric box?
<Quintasan> *shrug*
<Quintasan> no idea, I was told that creating oneiric pbuilder was broken
<Quintasan> so I created a natty one and upgraded
<cjwatson> tkamppeter,Quintasan: that's bug 805886
<ubottu> Launchpad bug 805886 in util-linux (Ubuntu) "/proc does not get umounted after debootstrap" [Undecided,New] https://launchpad.net/bugs/805886
<cjwatson> --create on a natty box should work
<cjwatson> I don't believe it matters what target distribution you're trying to bootstrap
<tkamppeter> Thanks, Quintasan and cjwatson
<tkamppeter> cjwatson, do you have any idea about not being able to remove pbuilder's ccache as root?
<cjwatson> tkamppeter: I just told you the bug number
<cjwatson> it's because umount is unmounting / trying to unmount /proc rather than /var/cache/pbuilder/build//30385/proc.  you can't remove a mount point that still has something mounted on it.
<cjwatson> and it's a umount bug - it's being told the right thing and doing the wrong thing
<tkamppeter> cjwatson, this I understood, but I have a second problem.
<tkamppeter> cjwatson, I succeeded to unmount /var/cache/pbuilder/build//30385/proc manually by "sudo umount /var/cache/pbuilder/build//30385/proc". After that I wanted to delete /var/cache/pbuilder/ccache/*/* and get "Permission denied" as root.
<cjwatson> tkamppeter: I strongly suspect that you will find that it is still mounted, and that in fact umount decided to unmount /proc instead for you
<cjwatson> which is what I keep saying - umount isn't doing what you ask it, that's the bug
<cjwatson> check /proc/mounts (and if it doesn't exist, remount /proc ...)
<dupondje> pkg-config is needed as build-depend? Thats not default installed right ?
<cjwatson> dupondje: it is not build-essential, no.  if you need it you must build-depend on it.
<tkamppeter> cjwatson, thanks, that was it, there was still one dangling mount.
<infinity> cjwatson: I'm upgrading a system to oneiric here so I can test that umount bug, but can you test a hunch of mine?
<cjwatson> infinity: sure
<cjwatson> well, preferably if it doesn't involve a full debootstrap first
<infinity> cjwatson: The failing recipe is "mkdir proc && mount -n -t proc proc proc && umount ./proc", right?
<infinity> cjwatson: And I'm told that changing the name of the mountpoint fixes it.  But I'm curious if changing the name of the filesystem might.
<pitti> infinity: your recipe reproduces it here, anyway
<infinity> cjwatson: (ie: "mkdir proc && mount -n -t proc proc-test proc && umount ./proc")
<pitti> ^ confirmed
<pitti> infinity: that recenlty changed in sysvinit, so that was the trigger for the bug?
<pitti> i. e. sysvinit changed from "none" to "dev", "proc", "sys", etc.
<cjwatson> debootstrap doesn't involve sysvinit
<cjwatson> oh, I suppose it might depend on the host system though
<infinity> I think it's a bonafide mount bug, but one that wasn't exposed until recently.
<cjwatson> infinity: changing the name of the filesystem doesn't help
<infinity> What I suspect is happening is that it's incorrectly mapping path to fs-name, then umounting by fs name.
<infinity> cjwatson: Yeah, it shouldn't.
<infinity> cjwatson: Not if I'm right.
<cjwatson> $ mkdir -p proc && sudo mount -n -t proc proc-test proc && sudo umount ./proc
<infinity> cjwatson: Now that I think about it, anyway. :P
<cjwatson> umount: /proc: device is busy.
<pitti> I'm sorry; I meant initramfs-tools, not sysvinit
<pitti> that's what changed the /sys, /dev, /proc mounts etc. from "none" to named
<pitti> /usr/share/initramfs-tools/init
<infinity> I'll test more here when my netbook catches up to the present.
<infinity> Cause further testing would be asking people to reboot, I think.
 * cjwatson uses http://paste.ubuntu.com/649040/ to clean up after infinity's tests
<infinity> cjwatson: Does make one wonder why /bin/umount isn't that simple, doesn't it? :P
<pitti> cjwatson: ah, I used umount -l
<infinity> cjwatson: (And really, in the case where it's a verifiable local path with something mounted on it, it should be.  But I'm pretty sure it's failing to short there)
<infinity> Clever software, for the loss.
<cjwatson> I generally assume that complicated software had some reason to be that way, which I realise is unfashionable :-)
<cjwatson> http://www.joelonsoftware.com/articles/fog0000000069.html and all that
<infinity> cjwatson: mount and umount have tons of reasons to be complicated, but optimising for the simple cases is still smart.
<cjwatson> (I don't always agree with Joel - in fact I suspect I mostly don't - but that one should be required reading)
<cjwatson> infinity: *nod*
 * infinity is tempted to substitute random livecd-rootfses and live-builds in that article.
<cjwatson> notice how I was really, really slow to switch to live-build :-)
<infinity> I just loathe abstraction for, seemingly, the sake of abstraction.  It's not live-build's fault, it's been all the rage for a decade.
<cjwatson> livecd-rootfs had too little; live-build has too much
<infinity> Following my command-line arguments through a twisty maze to figure out where something actually HAPPENS drives me batty, in something that's, ultimately, that "simple" in what it does.
<infinity> And there are some glaring issues that I need to take up with upstream when I have round tuits.
<cjwatson> much though it pains me to say it, many of live-build's abstraction confusion issues are due to trying to do too much in shell
<cjwatson> and I think upstream knows that
<infinity> The largest of which being that "lb clean" should, under no circumstances, be able to fail, except if it fails to actually clean.
<infinity> cjwatson: Bite your tongue!  Shell is beautiful and pure and true.
<cjwatson> the whole way new command-line options need changes in several different places would be a lot easier to fix in a higher-level language
<infinity> (And a good language for a project like this, but he's overcomplicated it a tad, perhaps)
<cjwatson> I think the option processing would be better in Python, and then call out to hooks in shell
<infinity> cjwatson: CLI parsing could be done globally in shell much differently than he's doing.  But I don't much care what language it's in, at the end of the day.
<cjwatson> that would keep the virtues of shell as a glue language while avoiding the horrible bits
<infinity> cjwatson: The reason livecd-rootfs was shell was because, ultimately, it's entire job was to fork a lot.
<cjwatson> right, Python isn't a good multi-process glue language
<cjwatson> unless all the processes are themselves written in Python :-P
<infinity> Anyhow.  If "lb clean" would stop including a function library with "exit 1" throughout, I'd be happy enough for now. ;)
<infinity> "Oh, you didn't select a default kernel?  Well, you get a dirty build-tree.  Enjoy!"
<infinity> But yeah.  Worked around for now, I'll worry about patching it correctly later. :/
<cjwatson> I suspect the software history would've been different if livecd-rootfs code had been public from the start
<infinity> cjwatson: Maybe I can rewrite it in Perl before he rewrites it in Python? ;)
<infinity> cjwatson: Yeah, I tried to get it public sooner. :(
<infinity> I eventually won, but a bit too late.
<cjwatson> heh, I actually don't know exactly what dba's plans are there
<cjwatson> yeah, I remember
<infinity> Granted, had it been widely adopted, it would have grown a lot anyway.
<infinity> But perhaps in different directions.
<infinity> *shrug*
<infinity> Whatever works.
<infinity> In the end, once we've wrestled with it a bit to get our various recipes in place, the rest is just adding and removing tasks, kernels, random packages, etc.  Which is simple regardless of the underlying system.
<cjwatson> yeahyeah
<cjwatson> er, lag maded that sound sarcastic
<cjwatson> was meant to be "yeah"
<Daviey> lag: please don't make people sound sarcastic.
<lag> Jerks!
<lag> ;)
<infinity> lag: while you're at it, make sure cjwatson never typed "maded" again.
<infinity> s/typed/types/
<lag> HA!
<infinity> Making typos whils criticising others' is poor form...
 * lag loves that you were telling him off for typos, then made one yourself
<lag> :D
<infinity> S'ok, I made ANOTHER while telling myself off.
<lag> infinity: More than one
<infinity> I only see one. :P
<lag> Anyway... I need to go and do some real work now :)
<infinity> s/whils/while/
<lag> s/others'/others
<infinity> No.  I meant others'.
<infinity> As in, the typos belong to others.
<infinity> belonging.
<infinity> Feh.
<infinity> TYPING HARD.
<infinity> I give up.  I shold eat breakfast before I type anything else.
<mvo> cjwatson: is it worth moving zz-update-grub into the old grub package? I just ran into a case where it would generate the initramfs after it ran update-grub during a automatic natty->oneiric upgrade test. or will grub1 vanish anyway and is not worth spending time on it?
<mvo> (the fact that grub1 is used in the auto-upgrade tester is a different bug â¦  that I'm fixing now, ubuntu-vm-builder)
<cjwatson> mvo: zz-update-grub is used for grub2 too
<cjwatson> it's actually in both packages
<cjwatson> oh, wait, it's in Debian grub but not in Ubuntu
<cjwatson> yeah, I should fix that - not today though
<mvo> cjwatson: no worries, I can have a look
<cjwatson> mvo: yeah, if it's urgent, see Debian grub 0.97-62, 0.97-63, 0.97-64
<cjwatson> it's unfortunately non-trivial to merge but a compound cherry-pick would be fine
<mvo> thanks cjwatson
<kelemengabor> hi pitti, could you initiate a build of new base language packs for Natty? The full translation export is done, and it is necessary to fix bug #774238
<ubottu> Launchpad bug 774238 in gnome-user-docs (Ubuntu Natty) "Desktop help is untranslated in 11.04" [Undecided,Fix committed] https://launchpad.net/bugs/774238
<pitti> kelemengabor: sure; did you already discuss that with dpm, for the testing, regular schedule, etc.?
<kelemengabor> yes, the plan was to release a planned update last week, but we delayed that because of this
<dpm> pitti, yeah, kelemengabor is aware of that. He's taking over from TLE as the new langpacks rockstar :)
 * kelemengabor blushes
<dpm> :)
<pitti> dpm: disabling natty cronjob FYI
<pitti> marking 07-21 langpack as current
<pitti> kelemengabor, dpm: natty langpack build started
<kelemengabor> pitti: cool, thanks
<kelemengabor> pitti: I'm looking at https://wiki.ubuntu.com/Translations/LanguagePackUpdatesQA and it seems that we forgot to ask you to move those -proposed packages for Maverick to -updates for which we got a positive feedback
<kelemengabor> which is only Dutch
<pitti> I tought we already did a few
<kelemengabor> I just checked my Maverick vbox, and it says that the Dutch update is still in -proposed
<pitti> kelemengabor: released -nl packages to -updates
<kelemengabor> thanks!
<pitti> kelemengabor: right, I meant that we already moved a bunch of other langauges to -updates which got verified
<pitti> I suppose this also was the last maverick update ever?
<pitti> well, we'll need another one once firefox 6 lands in maverick-updates
<pitti> but for the regular schedule, I mean?
<dpm> I think there was still another one, let me check the schedule...
<kelemengabor> pitti: https://wiki.ubuntu.com/Translations/MaverickLanguagePackReleaseSchedule
<kelemengabor> yes, there is one more scheduled for early August
<pitti> we don't even have daily PPA cronjobs or regular exports from LP for maverick any more
<kelemengabor> perhaps it will see bug 690248 fixed :)
<ubottu> Launchpad bug 690248 in Ubuntu Translations "In Maverick 'About Ubuntu' displays Natty info" [High,Triaged] https://launchpad.net/bugs/690248
<pitti> RAOF, SpamapS: please don't release anything to lucid-updates until further notice from cjwatson (needs to stay locked down for 10.04.3 release)
<dpm> pitti, yeah, we accorded to request an export whenever we'd need a new langpack release for Maverick, but I think if we're doing one soon to fix 690248, we could say it's the last one
<dpm> kelemengabor, what do you think?^
<pitti> chrisccoulson: when do we expect firefox 6 for maverick?
<pitti> since at that point we'll definitively need a -base refresh
<chrisccoulson> pitti - you'll need to ask micahg that
<chrisccoulson> i've already done all the work though
<kelemengabor> dpm: I agree, that bug is the last reason for releasing an update for Maverick
<kelemengabor> if we can get it fixed, I think it will be safe to leave Maverick alone
<mvo> cjwatson: if you don't mind I will upload a new grub1 with the zz-update-grub cherry pick, that should make the auto-upgrader tester more happy again
<cjwatson> mvo: not at all, go ahead
<mvo> thanks
<dpm> ok, sounds good, thanks kelemengabor. pitti, so I think we could just do a final maverick langpack upload if we fix that bug
<pitti> dpm: and another one for ffox 6
<dpm> ah, yeah, good point then
<pitti> dpm: and my gut feeling is that 690248 isn't serious enough to warrant doing that twice
<pitti> i. e. could we just wait for ffox 6 and do one -base refresh then?
<pitti> maverick has lived with this for some 9 months, after alal
<kelemengabor> pitti: http://asciimiki.blog.hu/2011/03/31/11_04_vs_maverick_lol
<kelemengabor> this is what local kids think about it :(
<pitti> still, it hardly keeps maverick from actually working
<dpm> I don't have a strong opinion on this one. chrisccoulson, even if it depends on micahg, when do you estimate the ff6 upload to happen (I haven't kept up with the FF schedule, so I'm not sure it's a matter of weeks or months)
<chrisccoulson> dpm - well, firefox 6 is released on 2011-08-16
<chrisccoulson> but micah seems to want to stick with 3.6
<chrisccoulson> although, i've already spent lots of time this cycle preparing to push 6.0 out to maverick and lucid
<chrisccoulson> and everything (except language packs) is ready to go now
<chrisccoulson> dpm - the dates are here btw: https://wiki.mozilla.org/RapidRelease/Calendar
<smoser> barry, around ?
<pitti> RAOF, SpamapS: lucid-updates unfrozen
<dpm> thanks chrisccoulson
<pitti> dpm: langpack build done
<pitti> dpm: do you happen to have some time to grab e. g. the Catalan one from /srv/language-packs.ubuntu.com/natty-proposed/, build it locally, and test it?
<pitti> dpm: I'm pretty swamped today still, need to get some stuff done before my holidays next week
<dpm> pitti, sure. Let me do it after my call today. Going somewhere nice on holiday?
<pitti> dpm: we'll do a bicycle tour along the Inn river, from Switzerland through Austria to Passau, Germany
<pitti> with tenting
<dpm> pitti, wow, nice :)
<sladen> pitti: should be able to follow that down the Danube, to near Belgrade/Bosnia for Debconf
<slangasek> heh
<slangasek> yes, please bike to DebConf from Germany, shame these Dutch with their carpools :)
<pitti> I can't even bring my laptop!
<hallyn> I thought this was mentioned in the StableReleaseUpdates wiki page, but I can't find it right now.  Can I verify SRU fixes that I posted myself?  I thought there was something about neither the bug fixer nor bug submitter can do so...
<chrisccoulson> slangasek, did you open a bug about indicator-datetime-service/e-calendar-factory causing dbus-daemon to spin the CPU?
<hallyn> all right, i guess i found my answer.  free to verify, and two verifications == verification-done
<hallyn> looking at https://wiki.ubuntu.com/MainInclusionProcess, it looks like MIRs are placed against source packages.  However, multipath-tools is in main, while multipath-tools-boot, from same source package, is in universe.  Is that just an accident of history?  Or is there a reason for it?  (googling got me nowhere)
<slangasek> chrisccoulson: no, didn't open it yet - are you beating me to it?
<chrisccoulson> slangasek, i haven't opened one yet, but i probably will do once i've finished my current task
<chrisccoulson> and i'll try to figure out what's going on too. it's becoming quite disruptive now
<seb128> chrisccoulson, there is one
<seb128> chrisccoulson, works fine there, is that happening only if you don't use evolution?
<chrisccoulson> seb128, i'm not sure. i haven't used evolution since before the rally ;)
<seb128> does it stop being an issue if you start evo?
<chrisccoulson> seb128, i'll give that a try in a sec
<chrisccoulson> g'ah, all my window decorations just disappeared
<bdmurray> jhunt_: wrt bug 803977 should that be crashes and package reports?
<ubottu> Launchpad bug 803977 in apport (Ubuntu) "Add hook to attach Upstart override files" [Wishlist,Triaged] https://launchpad.net/bugs/803977
<chrisccoulson> restarting the decorator takes forever :/
<jhunt_> bdmurray: all scenarios when a user can create an upstart bug ideally.
<bdmurray> jhunt_: okay
<cjwatson> hallyn: we only promote the binary packages that the seeds actually demand
<cjwatson> normally we promote binary packages from sources that are already in main without any paperwork; although multipath-tools-boot sounds like something that should have a second pair of eyes on it anyway?
<cjwatson> a brief skim looks OK to me
<hallyn> cjwatson: waht exactly does 'the seeds demand' mean?
<hallyn> that it gets installed on a server or desktop default install?
<cjwatson> https://wiki.ubuntu.com/SeedManagement
<hallyn> thanks
<cjwatson> the details of exact seed names are probably out of date, but the general idea hasn't changed
<cjwatson> and no, there's lots of stuff in main that is not in any default install
<hallyn> cjwatson: thanks
<micahg> pitti: dpm, so WRT Firefox in Lucid and Maverick, I'm waiting to hear what upstream plans to do WRT EOL on the 3.6.x branch, I'd like to SRU the latest version in after they release the last 3.6.x
<micahg> but I suppose we could do maverick before Lucid
<slangasek> chrisccoulson: go for it :)
<cr3> barry: any updates about psycopg2 on oneiric?
<barry> cr3: i think we're giving the maintainer a few more days to respond to my query about our ubuntu delta.  if i don't hear from him by monday, we'll do a sync request and throw that delta away (i personally don't see much value in it)
<barry> cr3: the sid version should solve all our problems :)
<jelmer> slangasek: bug 803353 is the blocker
<ubottu> Launchpad bug 803353 in subvertpy "segfault during iconv close from ra cleanup" [High,Triaged] https://launchpad.net/bugs/803353
<hallyn> UDD problem: rmadison shows natty-updates has multipath-tools 0.4.8-14ubuntu10.1, but bzr branch lp:ubuntu/natty/multipath-tools gives 0.4.8-14ubuntu10
<hallyn> oops
<hallyn> i thought i'd looked for natty-updates bzr proj before and not found it
<cr3> barry: sid will save us all!
<hallyn> pls ignore :)
<hallyn> Daviey: are you around, and would you have 20-30 mins sometime today to verify bug 495394 (I'm around if you need any clarification on how to reproduce, though i tried to make the TEST CASE: part of SRU description clear)
<ubottu> Launchpad bug 495394 in libvirt (Ubuntu Natty) "autostart almost always fails on boot time host" [Undecided,Fix committed] https://launchpad.net/bugs/495394
<Daviey> hallyn: o/
<Daviey> hallyn: You want me to verify the bug, and check that your patch fixes it - then sponsor?
<hallyn> Daviey: yes, please.  well, i'm not sure that 'sponsoring' fits in with the SRU process, but whatever will push it into -updates asap would rock
<Daviey> hallyn: Yes, the process is to sponsor it into -proposed but blocks in unapproved queue, where SRU team review it before accepting it.
<Daviey> hallyn: is it okay to attack this tomorrow morning, my time?
<Daviey> the test case looks clear enough.
<hallyn> jdstrand: ^ is that early enough, or too late for you?
<jdstrand> hallyn: that is fine with me. thanks. would you mind pinging me? if they go to verification-done I will just prepare packages against -proposed
<jdstrand> (then wait)
<Daviey> jdstrand: is this blocking you?
<jdstrand> Daviey: I have a security update. I think I have preempted hallyn 2 times already and woould prefer not to do it a 3rd time since this seems close to being verified
<jdstrand> Daviey: if it gets urgent, I'll upload and we can start again. I'd rather not do that to poor hallyn again if I can help it :)
<hallyn> :)
<hallyn> jdstrand: Daviey: thanks!
<Daviey> jdstrand: okay, super.. i'll do it first thing in my morning, and maybe ask someone in ~ubuntu-sru to look at it - so it's ready for you when you start.
<jdstrand> Daviey: thanks. it would be nice to publish on monday :)
<Daviey> jdstrand: I'm sure you know this, but -proposed packages normally bake for a week regardless of verfication-done..
<Daviey> which means that if you publish on Monday with hallyn's change, that would be fasttracking that.
<Daviey> If it's not too destructive, it might be better for you to go first.. would hallyn's diff need refactoring?
<jdstrand> Daviey: those are sitting at 9 days.
<jdstrand> Daviey: all that is needed is verification-done (I waited until 7+ days before I started poking people)
<jdstrand> Daviey: I'm more than happy to do the patches without the -proposed fixes, but like I said, I did that to hallyn 2 times already for this exact bug
<jdstrand> Daviey: I wasn't proposing fast-tracking anything-- I was assuming that if it was verified, pitti or anohter sru member would copy to updates, then I would promptly push to security
<Daviey> jdstrand / hallyn: Ahh! I missunderstood.. I didn't realise it was already in -proposed.
<Daviey> that'll teach me to spout of before i read the bug/status
<jdstrand> cool, no worries :)
<cdbs> barry: ping
<barry> cdbs: pong
<cdbs> barry: In the dh_python2 porting spec, I have a WI assigned to me, to find out python-central ubuntu-only packages
<cdbs> barry: Could you take that up? I've been a lot busy lately and can't do much
<barry> cdbs: sure, you can assign it to me, we'll see if i get to it :)
<cdbs> barry: Oh wait, you had snatched that earlier, and its done already, nice
<cdbs> They say: Lots of things happen when you're not on the internet
<barry> yay for memory!
<hallyn> (sorry, running out in a min, but) lp:ubuntu/qemu-kvm is not in sync with the oneiric qemu-kvm package.  I assume it should be?
<pook1e> Hi guys, I was here last night asking about something but I had to leave so I couldn't get a definite answer. I'm trying to use pbuilder to build indicator-network for oneiric-i386. I've included libindicator-dev in my base tarball, but I'm still getting an error about indicator not being found. Does anyone know how to get around this?
<pook1e> Here is a snippet of the build log when it fails: http://paste.ubuntu.com/649554/
<RAOF> pook1e: You shouldn't need to include libindicator-dev in the base tarball; pbuilder should resolve all the build depends at build time.  Could you pastebin *full* build logs?
<RAOF> And by that I mean âfrom pbuilder invocation to the next shell promptâ
#ubuntu-devel 2011-07-22
<pook1e> Here it is, thanks RAOF. http://paste.ubuntu.com/649562/
<RAOF> pook1e: Ah.  Apparently because the .pc has been renamed to indicator-0.4.pc, so the configure.ac check is now incorrect.
<infinity> Because changing the name of your package every minor revision is a surefire way to make pkg-config useful.
<pook1e> RAOF: The .pc of libindicator? So is there something I need to change in configure.ac of indicator-network?
<RAOF> Yes.
<infinity> Probably want to make indicator-network look in both locations (preferring the new one), for ease of backporting.
<pook1e> Where would I change the name of the .pc file for libindicator then?
<poolie> pook1e: i guess configure.ac has a pkgconfig line saying what packages it needs or wants
<poolie> i don't think you refer to the name of the file directly
<pook1e> I was looking at "PKG_CHECK_MODULES([INDICATOR], [indicator >= $INDICATOR_REQUIRED_VERSION])"
<pook1e> Then there's also an indicator section where INDICATORDIR and INDICATORINCONSDIR are set.
<RAOF> pook1e: âPKG_CHECK_MODULES([INDICATOR], [indicator >= $INDICATOR_REQUIRED_VERSION])â is (at least one of) the bit you want to edit.  A simple fix would be indicatorâindicator-0.4; a better fix would be to add a 3rd parameter to the check so that PKG_CHECK_MODULES doesn't abort when it dosen't find the module and you can keep the existing checker as a fallback.
<pook1e> ROAF: Ah I see, got it. Thanks everyone for your help, much appreciated!
<pook1e> RAOF: I changed indicator -> indicator-0.4 in the configure.ac file and it still didn't work, stopped at the same place as last time. Any other ideas?
<pook1e> Do I need to change indicatordir as well? I tried but that didn't seem to fix anything.
<infinity> Hrm.  What happened to apt-listchanges and update-manager playing nicely? :/
<infinity> (Or, rather, playing nicely even when output is set to pager...)
<smoser> hallyn, http://package-import.ubuntu.com/status/
<pitti> Good morning
<poolie> o/ pitti
<pitti> hey poolie, how are you?
<poolie> great thanks
<poolie> just qa'd https://bugs.launchpad.net/bugs/813349 so per-revision diffs will start appearing in merge proposal pages
<ubottu> Ubuntu bug 813349 in Launchpad itself "hard to get from mp to per-revision diffs" [High,Fix committed]
<poolie> (not deployed yet)
<poolie> and then hopefully later other places
<pitti> wow, it was hard? I just used to click on the revision numbers in the "unmerged revisions" on the MP pages
<pitti> oh, inline
<poolie> well, perhaps not impossibly hard :)
<poolie> but, i think it's cooler this way
<poolie> will be more so if we can start showing them in more places, and also file content
<didrocks> good morning
<Quintasan> Good morning.
<RAOF> Are there any DDs here who'd like to review (and potentially sponsor) colord from alioth?
<persia> RAOF, If you don't get a response in a while, #debian-ubuntu@OFTC tends to contain a few such willing sponsors.
<RAOF> persia: Ta.
<pitti> â© â« where have all the (PPA) buildds gone, long time passing â«
<pitti> â¬ when will they ever build â­ â©
<RAOF> pitti: chrisccoulson hasn't woken up and firefoxed them to death? :)
<pitti> RAOF: amd64 are being fta'ed actually
<pitti> and the few remaining i386 are building a variety of things with 558 more jobs in the queue
<RAOF> Whee!
<chrisccoulson> hey RAOF!
<chrisccoulson> i can run the firefox daily builds now if you like ;)
<pitti> chrisccoulson: no, you can't, as they won't actually start today :)
<chrisccoulson> oh, fantastic. they've all disappeared again :(
<chrisccoulson> i need to think of a more reliable way of providing our daily builds. this seems to be a bi-weekly occurrence now
<pitti> would biweekly builds of firefox and chromium perhaps suffice?
<pitti> especially for releases like maverick which few, if any developer use any more?
<micahg> those builds are for users as well, not just devs
<pitti> yes, but the kind of people running lucid today are certainly not the kind who want to live on the bleeding edge?
<pitti> just asking whether two updates a week might suffice for these
<chrisccoulson> i think fta got some numbers somehow, which indicated that the number of people using chromium daily builds on lucid was actually still quite high
<chrisccoulson> not sure how he figured that out
<chrisccoulson> but it was a 5 figure number anyway
<micahg> he used the launchpad PPA stats
<chrisccoulson> and we have people from mozilla using our daily builds too (and they tend to stick with older ubuntu releases)
<persia> Do these people want "daily", or just "rather updated"?
<pitti> just considering that building firefox and chromium every day for four releases pretty much takes about two buildds fulltime
<micahg> pitti: and as long as I'm distracted, I'd be ok with doing a maverick jump to Firefox 6 the week of aug 21
<micahg> at least through -proposed/-updates
<persia> (as a side note, "biweekly" usually means once a fortnight)
<pitti> ah, I meant "semiweekly" then
<persia> Indeed you did :)
<pitti> persia: thanks
<pitti> heck -- "every three days"
<persia> I suspect most lucid users would prefer semiweekly, as "every three days" tends to wander over the week, making it unpredictable in practice if one isn't paying careful attention.
<persia> chrisccoulson, While tens of thousands of daily PPA users seems reasonable: how many of them actually update every day?
<chrisccoulson> in any case, i'd rather not provide builds at all than provide them twice per week. things change so frequently on trunk that having people running a build that's 2 days out-of-date isn't really all that useful (to us or mozilla). they need to run the latest code before reporting any bugs for example
<chrisccoulson> (and it's the first thing they'll be asked to do)
<chrisccoulson> persia, see my last comment :)
<Daviey> persia: You know biweekly definition is widely disputed?
<chrisccoulson> people shouldn't be running daily builds if they aren't updating daily IMO
<chrisccoulson> they should use something like beta instead
<persia> Daviey, I'm a grammarian.  Experimental linguistics is doing it wrong.
<persia> chrisccoulson, Makes sense.  How many of the tens of thousands of users appear to be submitting useful bugs that affect daily/lucid?
<micahg> pitti: did you catch my comment about Firefox 6 for maverick? (in response to the langpack query yesterday)
<pitti> micahg: yes, I did; thanks
<chrisccoulson> persia, good question ;)
<persia> chrisccoulson, To ask it differently: how many of those submitted bugs are ones you care about enough to do something with them?
<dholbach> good morning
<persia> It may be exceedingly hard to track the users, but it ought be relatively easy to track the effect of those users on your workflow.
<chrisccoulson> persia, i generally care about any bug submitted against the daily and aurora builds, as that's the correct time for people to report bugs (before the packages end up in the distro)
<persia> If they are a major contributor of useful-work-to-be-done, then they should be kept.  If they aren't, you might wonder if you want the extra bug traffic.
<persia> chrisccoulson, Running on which platform?  All?
<chrisccoulson> persia - i'm not sure. our apport hook is broken for the daily builds, so i don't have that information
<persia> Oh, nevermind then.  I suspect that with current information, it's undecidable.
<micahg> chrisccoulson: we never figured out what to do with that since a config file that points to the same project needs to be shipped in multiple source packages
<chrisccoulson> hmmm, i guess i'll figure that out at some point, when i get some time
<brendand> i have a newly installed system which is being tested automatically and i want to use nm to connect to a pre-specified AP - does anyone know which file the config needs to go in?
<micahg> chrisccoulson: there's an open bug in the ppa-bugs project assigned to me, feel free to grab it
<micahg> can I get someone to accept the tasks for me on bug 814464 please?
<ubottu> Launchpad bug 814464 in webkit (Ubuntu) "webkit 1.2.7 security update tracking bug" [Undecided,New] https://launchpad.net/bugs/814464
<RAOF> micahg: Done.
<micahg> RAOF: thanks!
<Riddell> Hobbsee: happy birthday
<dholbach> Hobbsee, happy birthday! :)
<dholbach> Riddell, why do the branches in your MPs for u-p-g depend on each other? like the one on chroots?
<geser> Hobbsee: happy birthday
<dholbach> Riddell, I'd love to review and merge a few of them, but I'd prefer if somebody like barry, jelmer or james_w could check out the UDD-specific bits
<Riddell> dholbach: the first few needed to depend on each other, then it just became a habit
<dholbach> ok
<dholbach> you know what - I'll see what I can review, add my comment and you can merge them in one go if one of the others reviewed the UDD bits
<poolie> dholbach: wow nice post about "what i like least"
<poolie> hooray for actually making use of gathered data
<dholbach> poolie, diwic asked the question :)
<jelmer> pitti: hi
<pitti> hey jelmer
<jelmer> pitti: should I be setting verification-done for bugs in bzr SRUs? The wiki page says it will be done by the SRU team.
<pitti> jelmer: if you test it, sure
<jelmer> pitti: Ok - thanks!
<ohsix> christ the 9 series compiz is not good; touching anything in ccsm is usually a crash and it's very hard to get it to go back to the settings you had just before you clicked on said thing
<Amoz> dholbach, merge merge
<dholbach> ehy Amoz
<Amoz> dholbach, you want me to delete the javascript stuff?
<dholbach> Amoz, yeah, I think that'd be good
<dholbach> I'can we disable search somehow completely?
<Amoz> whyyyy
<Amoz> sure can, but why? :P
<Amoz> dholbach, I mean, isn't it good to have a search function? :P
<dholbach> if it doesn't work? :)
<Amoz> dholbach, it worked with the basic theme, so it's just a small thing somewhere
<Amoz> dholbach, we just need to ask the sphinx devs for how to update the searchindex.js or something
<Amoz> developers make stuff work ;D
<dholbach> http://people.canonical.com/~dholbach/packaging-guide/html/search.html?q=something&check_keywords=yes&area=default looks a bit funny :)
<Amoz> sure does,  but it works
<Amoz> and hopefully that's a bug being fixed upstreams sooner or later, so why remove the search function if it (kind of) works... you're not Steve Jobs now ;)
<Amoz> but that's just me
<Amoz> very easy to put a visibility:none; property on the search box
<Amoz> and remove it when/if we get it to work
<dholbach> I just thought that it'd be the easiest work-around for now because 1) it doesn't work, 2) it duplicates jquery.js and other pieces which are part of other packages already
<dholbach> if we want to get it into the archive at some stage it'd be good not to duplicate those
<Amoz> dholbach, you're thinking about distributing the html-version as a package?
<dholbach> Amoz, it's already in a PPA
<Amoz> dholbach, yeah but do one have to generate it manually?
<dholbach> hm?
<dholbach> you just have to install the package
<dholbach> https://launchpad.net/~ubuntu-packaging-guide-team/+archive
<Amoz> and then isn't the PDF better to use for offline usage? but still you have a point with the jquery stuff anyway
<Amoz> so you want to remove the jquery and the search box for now?
<Amoz> then the layout should be fine again
<Amoz> dholbach, anything else before the merge?
<dholbach> I'd be happy - I'll talk to tumbleweed and Laney before again
<dholbach> when you're done, can you hit "resubmit proposal"?
<Amoz> sure
<dholbach> great, thanks Amoz!
<Amoz> dholbach, I made the ToC box static in width, so the layout won't bug out sometimes
<Amoz> dholbach, proposed!
<tumbleweed> dholbach, Amoz: I'm about to hop on a plane to debconf, but I was pretty happy with it
<tumbleweed> biggest issue I see is the double copyright footer
<Amoz> ah
<Amoz> which one should be there then?
<Amoz> Ubuntu devs, or canonical?
<tumbleweed> probably just the sphinx-generated one
<tumbleweed> Ubuntu devs, yes
<Amoz> hmm
<Amoz> looks ugly
<Amoz> dholbach, now check it!
<Amoz> I did some border-radius on the ToC
<Amoz> maybe it's not allowed to change the styling just like that, dunno how strict it is. but looks nico imo
 * Amoz goes lunching
<dholbach> Amoz, enjoy - I'll have a look and comment on it - do you know if any of the javascript stuff is necessary right now?
<dholbach> nevermind, I'll comment on the merge proposal
<Amoz> dholbach, the whole js import loop should be uncommented
<Amoz> so no js at all
<dholbach> Amoz, but they're still in the branch
<Amoz> ah
<Amoz> yeah
<Amoz> true
<dholbach> and every file we add needs to be documented in terms of copyright and license
<Amoz> I just remove the
<Amoz> codeeee
<Amoz> ah yeah, I might have added those manually ..
<dholbach> cool
<Amoz> I'll remove the jquery then
<Amoz> but the rest should be there if we want to start using the js again. I think there's a lot of other stuff using js actually
<dholbach> really?
<Amoz> dholbach, looks like it yeah
<Amoz> see the doctools.js
<Amoz> but it's depending on jquery I guess
<dholbach> ok, I need to go - I'll be back later
<Hobbsee> Riddell, dholbach, geser: Thanks!  :)
<Amoz> dholbach, I guess we could make it a child theme to the basic theme, just keeping the modifier layout.html, and so on
<dholbach> Amoz, that sounds interesting
<Amoz> dholbach, is there a way to diff all files in a given dir with another dir?
<dholbach> Amoz, diff -ruN dir1 dir2
<Amoz> no r
<Amoz> don't want the underdirs
<apw> pitti, did modem-manager get subsumed by somethign
<apw> pitti, ignore me, found it
<Amoz> dholbach, there
<Amoz> dholbach, check it
<smoser> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #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: smoser
<pitti> apw: no, it still exists
<apw> pitti, yeah i was being a 'tard
<tseliot> ogra_: ping
<slangasek> jelmer: so the bzr-svn packge branch FTBFS for me, but it doesn't look like a segfault; am I looking in the right place?
<jelmer> slangasek: how does it FTBFS for you, and what are you building on?
<slangasek> jelmer: oneiric clean chroot, hand-build with bzr bd, fails with http://paste.ubuntu.com/649954/
<barry> dholbach, Riddell i'll do some branch reviews this morning
<jelmer> slangasek: it builds fine outside of a chroot here on oneiric too, but I get the segfault on sid
<dholbach> barry, awesome!
 * dholbach hugs smoser
<dholbach> Amoz, looking
<jelmer> slangasek: that particular failure appears related to some upstream svn changes
<slangasek> jelmer: oh, so the segfault is sid-only? ok
<slangasek> jelmer: what about the build failure I *am* seeing in oneiric chroot?
<jelmer> slangasek: that particular failure appears related to some upstream svn changes
<slangasek> oh
<slangasek> well, hmm
 * jelmer ponders uploading to oneiric or figuring out what the issue is on sid
<slangasek> well, an upload to oneiric would be helpful to me in the meantime
<slangasek> my home build server has helpfully just gone offline so I need to cook another sid chroot locally before I can look at the other issue
<Amoz> i *hate* it when that happens.. home server offline -> not able to seed the new 10.04.3 release :(
<hallyn> hm, qemu-kvm in lucid-updates is at 0.12.3+noroms-0ubuntu9.12, but when i tried to push 0.12.3+noroms-0ubuntu9.13 to lucid-proposed it said that exists.  I take it that would be because such a version failed testing at some point?
<Daviey> hallyn: erm, you uploaded .13
<Daviey> hallyn: https://launchpad.net/ubuntu/lucid/+source/qemu-kvm/0.12.3+noroms-0ubuntu9.13
<Daviey> "moved to -updates" seems to have not happend.
<Amoz> dholbach, here again
<hallyn> Daviey: wtf?
<hallyn> Daviey: i was going on rmadison output and https://launchpad.net/ubuntu/lucid/+queue?queue_state=4&queue_text=qemu-kvm.
<hallyn> Daviey: so how does that go wrong in the first place, and how do we fix it?
<Daviey> hallyn: I'd check with pitti, it looks like it wasn't copied to -updates, but just deleted
<pitti> hm?
<Daviey> pitti: see above ^^
<pitti> in a bit
<pitti> skaet: https://wiki.ubuntu.com/DesktopTeam/Specs/Oneiric/LocalizedCDImageTools
<pitti> hallyn, Daviey: (sorry, got caught into a meeting) hm, very strange indeed; but the associated bug 790145 doesn't actually have any testing results
<ubottu> Launchpad bug 790145 in qemu-kvm (Ubuntu Maverick) "kvm husb: ctrl buffer too small" [Medium,Fix committed] https://launchpad.net/bugs/790145
<pitti> so it shouldn't have gone into -updats
<pitti> aah
<pitti> Daviey, hallyn: I think it got superseded by the security  update, and the "packages to clean up" portion just got confused, so it was removed with a misleading comment
<hallyn> pitti: but security update is 9.12, this is 9.13
 * pitti sets the lucid task back to triaged, as it's not in -proposed
<pitti> hm; I have absolutely no idea then
<pitti> probably easiest to just reupload as .14, and then we accept it into -proposed
<hallyn> pitti: lucid got testing results, maverick didn't.  That wouldn't hold it up right?
<Amoz> dholbach, merged your branch now, and pushed
<pitti> hallyn: no, the reporter said he tested 9.12, which was the security update; it didn't actually have the fix
<hallyn> oh, i see
<dholbach> Amoz, awesome - can you resubmit the proposal? I'll try to get others to review it as well :)
<dholbach> then we can go and file bugs for all the stuff that needs changing
<dholbach> but this is awesome :)
<hallyn> pitti: ok, i'll resubmit as 9.14, but i will feel bad about the poor testers :)
<dholbach> thanks again Amoz
<jdstrand> pitti, hallyn: fyi, I have another security update I would like to get out. if you are re-uploading and restarting the 7 days, maybe hold off til I get my update published next week?
<hallyn> jdstrand: for qemu-kvm?
<jdstrand> hallyn: oh, I thought this was libvirt. forgive me. nothing planned here for qemu-kvm
<hallyn> jdstrand: cool, thanks.
<hallyn> pitti: do you mind then if i combine the fixes for bugs 790145 and 524447 into one -proposed upload?
<ubottu> Launchpad bug 524447 in qemu-kvm (Ubuntu Maverick) "virsh save is very slow" [Medium,In progress] https://launchpad.net/bugs/524447
<ubottu> Launchpad bug 790145 in qemu-kvm (Ubuntu Lucid) "kvm husb: ctrl buffer too small" [Medium,Triaged] https://launchpad.net/bugs/790145
<pitti> hyperair: no, not at alal
<pitti> "all"
<pitti> bah, TGIF
<pitti> hallyn: no, not at all
<smoser> slangasek, or pitti could you take a look at my comment at https://code.launchpad.net/~ubuntu-branches/ubuntu/oneiric/mountall/oneiric-201106072111/+merge/63765
<pitti> hyperair: ignore me, -ETAB
<smoser> it looks like we can reasonably kill or merge that branch and kill it's entry in the sponsorship queue.
<hallyn> pitti: thx, on it
<Amoz> dholbach, proposed like a boss
 * dholbach hugs Amoz
<barry> Riddell, dholbach i've reviewed your mps.  really great work, thanks.  a few are marked 'needs fixing' just to address a couple of minor issues, but the others are approved.  Riddell can you land them yourself?
<Amoz> what is a mps? :)
<dholbach> barry, Riddell: awesome!
<dholbach> great work!
<dholbach> Amoz, mp = merge proposal
<Amoz> lol, ofc
<barry> Amoz: what's lol ofc?  (jk! :)
<Amoz> barry, I'm sure you heard about google  ;D
<Amoz> you've
<barry> Amoz: i heard that's some kind of social network thing?  :)
<Amoz> :D
<jdstrand> seb128: hey, so what is the status of evolution in oneiric? I've heard it was horribly broken not too long ago
<dholbach> Amoz, there's small conflict in your index.rst (because of changes that happened in lp:ubuntu-packaging-guide in the meantime, but I'll go and fix it)
<Amoz> barry, I thought that was called basefook?
<dholbach> tumbleweed was generally happy with it as well, so that should be good enough to land it
<Amoz> aaw
<barry> Amoz: i preferr bassfunk :)
<dholbach> daker did a review of the theme stuff some days ago and said that apart from a few nitpicks he was happy as well
<seb128> jdstrand, hi, it's working fine but calendar is slow (which is not new in oneiric if you are already on that serie) and has issue rendering some gpg signed emails (but doing a "view source" let you read those as a workaround)
<Amoz> barry, bookface
<barry> :)
<seb128> jdstrand, i.e the gpg issue is a rendering one, the email is actually fine and you can ctrl-u on those and read the source
<jdstrand> seb128: thanks
<Amoz> barry, I can't help but think of Poland when I see your name
<barry> Amoz: me too!  long twisted family history, there :)
<jdstrand> seb128: I see. I've got some concerns about evo maintenance if/when we move to tbird since we always seem to have evo bugs during devel. what is your take on this?
<jdstrand> (iirc, it won't drop from main because we have too many users)
<dholbach> Amoz, bug fixed! good work!
<seb128> jdstrand, I'm not sure to understand the question sorry, usually bugs and fixes are coming from upstream, we will keep follow the upstream updates as it's part of GNOME so I don't think the default choice makes any difference on how well it's maintained
<Amoz> dholbach, trÃ¨s bien
<Amoz> does this mean it's merging into the trunk now?
<jdstrand> seb128: that actually answered my question. my concern is that if we spent resources on maintaining evo beyond what you just said, those would be diverted to tbird and evo would not be in as good of shape
<jdstrand> s/concern is/concern was/
<dholbach> Amoz, bon travail, mon ami!
<Amoz> ^^
<Amoz> sehr gut!
<Amoz> dholbach, so.. what's next? :)
<dholbach> ok, line up every one, Amoz wants a new project to work on!
 * Amoz sneaks away..
<seb128> jdstrand, ok ;-)
<seb128> jdstrand, well, we do spend some time doing the evolution updates, forwarding bugs upstream and fixing some issues when needed but I think we will keep doing that as part of the GNOME work, I don't see the GNOME maintainers we have work on tb
<seb128> out of chrisccoulson
<seb128> so I don't think tb by default divert efforts from evo, the low amount of work we put in it will probably remain about the same
<jdstrand> seb128: thanks. that is reassuring :)
<chrisccoulson> i wouldn't say no to any help with thunderbird maintenance though :P
<seb128> yw ;-)
<seb128> chrisccoulson, and I wouldn't say no to a million dollars
<tgardner> slangasek, cjwatson: is xen hypervisor installation on your radar for 11.10 ?
<chrisccoulson> lol
<seb128> ;-)
<chrisccoulson> firefox and thunderbird are a beast, and i feel like i'm the only person maintaining them ;)
<seb128> we are lucky to have you ;-)
<chrisccoulson> heh :)
<pitti> ogasawara: wrt to the kernel release, can you please ensure that a kernel is NEWed before you uploaded the -meta?
<pitti> it rendered the CDs and kernel uninstallable yesterday
<ogasawara> pitti: will do
<slangasek> smoser: followed up on the merge request
<pitti> I binNEWed it then, but it's easy to avoid; just poke any archive admin
<pitti> ogasawara: thanks!
<slangasek> tgardner: xen> not on my radar, at least
<smoser> slangasek, thanks. now, just curious, what sets perms on /run/lock ?
<smb> tgardner, You sort of just install server and then the xen hypervisor and utils
<slangasek> smoser: the kernel - tmpfs is 1777 by default when mounted
<smoser> ah. wonder why keybuk added that mkdir -m then.
<smoser> and you dont think 'nodev' is useful on /run ?
<Amoz> this channel is english, no? why you speak chinese then?
<slangasek> Amoz: this channel is for Ubuntu development; if you're bothered by technical discussions, this is probably not the channel you want to be on :)
<Amoz> slangasek, so I guess this is serious friday? :(
<slangasek> smoser: according to the original diff, he added the mkdir because he *wasn't* mounting /run/lock as a separate filesystem; but that's something we need to do to ensure !root users can't DoS /run
<ScottK> mvo: Now that mpt has done his design work for https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-backports-ui I thought I'd check in with you and see what the chances of you having time to work on it soon are?
<slangasek> (because tmpfs has no reserved blocks or quota handling)
<slangasek> Amoz: casual, but serious
 * mpt hides from mvo
<smoser> slangasek, right.
<ScottK> mpt: Thanks for taking care of it.
<smoser> slangasek, so i cannot push to lp:ubuntu/mountall, or I would.  Do you want to do that, and then end that merge proposal with 'merged' ?
<smoser> i'm willing to submit a merge proposal, but that ends up just making more work, not less.
<ioport> ubuntu shut
<ioport> shit
<infinity> Classy.
<tgardner> smb, do you remember how Hardy worked for Xen? Someone will have to add the dom0 choice back into the menu and twiddle the grub line appropriately.
<smb> tgardner, At least the way I set it up was: do a server install and then install ubuntu-xen-server
<tgardner> smb, so we don't have to do it at install time?
<smb> tgardner, The grub line is already done in oneiric too
<tgardner> I guess that makes 11.10 a bit easier
<smb> tgardner, nope
<smb> tgardner, After installing the hypervisor and tools in oneiric, you also get a xen dom0 grub section automatically
<tgardner> smb, good. that makes life much simpler
<smb> Yep, only small difference there is that in hardy it went to the top of selections while on oneiric its not. And on hardy we had an extra xen kernel while in oneiric its even simpler and just the server kernel
<slangasek> smoser: yep, done!
<smb> I just need to talk to zul next week about a possible tweak for the grub package. As I found it useful to have the option of having seperate commandlines for normal kernel boots and dom0 kernels
<mvo> ScottK: lets see, its not that hard, but there are some gaps i nthe spec, I will talk to mpt about that
<ScottK> mvo: Thanks.
<Amoz> cjwatson, I heard you're good at ubiquity, maybe you could give me a hint how to solve the Orca bug, it reads out "Try $RELEASE".
<pitti> good bye everyone, see you in two weeks!
<nigelb> happy vacation pitti :)
<pitti> thanks!
<bdmurray> smoser: Could you sponsor my debdiff in bug 813282?
<ubottu> Launchpad bug 813282 in base-files (Ubuntu) "base-files: /etc/update-motd.d/* should be conffiles" [Medium,In progress] https://launchpad.net/bugs/813282
<smoser> bdmurray, no.
<smoser> but not because i dont want to. i dont have acl [yet].
<bdmurray> smoser: ah, didn't know
<dtchen> bdmurray: I'll look at it
<bdmurray> dtchen: thanks!
<jml> I've got two keys in my keyring with my email address. How does debuild decide which one to use by default?
<infinity> jml: The first one it finds with "gpg --list-secret-keys email@address.com"
<jelmer> jml: I think it just uses the first one, unless you set DEBSIGN_KEYID as environment variable or in ~/.devscripts
<infinity> jml: You can specify "-k$ID" on the command line to pick one.
<infinity> jml: Or set the variable, yes.
<infinity> (I have to do this anyway, as my key doesn't actually have half the IDs I use in changelogs)
<jono> folks, Mark Shuttleworth is doing a quick Q+A in #ubuntu-classroom on Freenode - ask questions in #ubuntu-classroom-chat - go and ask him your questions!
<jml> jelmer, infinity: thanks
<jml> jelmer: I'm ashamed to say that ~/.devscripts doesn't exist on my system.
<infinity> jml: It doesn't on mine either.
<infinity> jml: I just export DEB* variables in my profile.
<jelmer> jml: I only have one line there either. It says DEBSIGN_KEYID=1EEF5276
<jml> jelmer: hah
<Amoz> wow
<Amoz> oh god
<bdmurray> Where does the SRU team hang out?
<Amoz> did I miss the Q+A with Mark =(
<jelmer> bdmurray: I don't think they have their own channel, I usually just ping them in here.
<ScottK> bdmurray: pitti is on vacation, so pinging SpamapS is probably your best bet.
<SpamapS> bdmurray: sup?
<bdmurray> SpamapS: I wasn't sure whether nor not to have a bug per patch / fix for an SRU.  However, since the test cases are different I decided to have a bug for each one.
<SpamapS> bdmurray: that is the best way really. I'd rather we are slow getting an update out, but know when a regression was introduced, than have them all jumbled together.
<bdmurray> SpamapS: okay thanks
<smoser> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #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:
<jml> g'night all
<SpamapS> seems like Xorg has been at 25 - 30 % CPU all day, even when idle..
<SpamapS> fan has not turned off at all.. :-/
<tkamppeter> It seems that the last update has switched thunderbird from 5 to 6 and now I cannot see my mail folders any more.
<tkamppeter> Is this known?
<Ampelbein> tkamppeter: I can't reproduce, tried imap with a courier-imapd and a dovecot-imapd, as well as local mail folders.
<seb128> slangasek, there?
<tkamppeter> Ampelbein, chrisccoulson has already helped me on #ubuntu-desktop. Thanks.
<slangasek> seb128: heya
<seb128> slangasek, mbiebl was wondering why you dropped the libgail-utils.la in gtk's multiarch patch but not ubuntu's upload
<slangasek> seb128: because I did the Ubuntu upload first and further refined before submitting to Debian
<slangasek> :)
<seb128> mbiebl, ^
<seb128> slangasek, that's ok, we were just discussing why there is the diff and why you didn't drop the gdk and gtk ones as well
<seb128> since they were dependency_libs cleaned for a while they should be ok to drop in the upload
<jdstrand> Daviey, hallyn: hey. was curious what happened with the libvirt verification?
<slangasek> seb128: oh, well I have no idea why I didn't drop them all
<slangasek> *that* would just be sloppiness on my part
<seb128> slangasek, that's fine, we were just wondering if there was a reason we should know about ;-)
<mbiebl> seb128, slangasek: as said, if the list of rdeps doesn't look to scary, I'll remove them all
<slangasek> mbiebl: so in general, if the .la file is changing directories anyway, the dependency_libs revdeps are already broken by the change
<Daviey> jdstrand: i sucked at testing it, i didn't get as far as finding the fault.  Seems i was using lxc wrong.
<mbiebl> well, we could fix that up via a symlink
<mbiebl> I remember us discussing that :-)
<Daviey> jdstrand: I will strive to have another look over the weekend.
<Daviey> (hallyn gave me updated instructions)
<slangasek> mbiebl: ah, well, I've had that conversation a few times, don't remember who all with :)
<jdstrand> Daviey: thanks
<slangasek> mbiebl: the revdep lists for glib2.0 and gtk+2.0 are long enough that it's probably best to provide some compatibility
<mbiebl> slangasek: I'm currently checking the list for library packages
<slangasek> mbiebl: are you not just checking against http://release.debian.org/~aba/la/current.txt ?
<mbiebl> I do, but not all of them build library packages
<mbiebl> and only -dev packages are interesting, right
<slangasek> mbiebl: yeah
<mbiebl> slangasek: I'll just request a couple of binNMUs if the list is not to long and the packages are in a buildable state
<mbiebl> too long, even
<slangasek> ack
<mbiebl> wow, sugar-toolkit is even worse the libdb
<mbiebl> -84, -86, -88, -90, -92 ...
<ScottK> Yup.
<ScottK> lfaraone: ^^^
<lfaraone> mbiebl: :D I apologize.
<lfaraone> I stopped paying attention to Sugar last August and it probably is in a sorry state right now.
<ScottK> Please at least clean things up.
<SpamapS> Hrm.. OpenOffice is dying at a rapid pace for me. :(
 * SpamapS is considering buying a new laptop that he can put Natty on, just so he can get actual work done.
<SpamapS> oh cool.. when I strace it, it doesn't crash
<Daviey> SpamapS: if you are struggling on disk io, like i am - i found the same experience with thunderbird.
<mbiebl> slangasek, seb128: this seems to be the complete list of affected packages
<mbiebl> http://paste.debian.net/123817/
<mbiebl> all but two are currently ftbfs
<SpamapS> Daviey: I'm struggling with almost every single piece of the system at this point. I also can't boot w/o booting to recovery console first.
<seb128> mbiebl, doesn't seem worth keeping the .la
<mbiebl> those packages look pretty unmaintained
<Daviey> SpamapS: is this your mbp?
<slangasek> mbiebl: hah, nice
<SpamapS> Daviey: yes, its the only computer I own.
<mbiebl> seb128: yeah, I won't fiddle around with symlinks
<Daviey> SpamapS: yeah, i think there is a regression.. i'm getting dire disk io on mine.. although i think have different hardware versions.
<SpamapS> unless you can't my "backup" desktop machine.. which is basically just an old G5 mac. :-/
<SpamapS> Daviey: mine is a 5,1
<mbiebl> seb128: that amount of breakage is acceptable imho
<Daviey> SpamapS: 7,1 .. i would be suprised if it is related then.. but something isn't right.
<seb128> mbiebl, yeah, I think so
<SpamapS> Daviey: my only actual hardware problem is that nvidia twinview does not work in Unity.
<Daviey> SpamapS: fancy swapping then? :)
<SpamapS> Sure, I'll just drop it in the mail.
<SpamapS> Anyway, I'm kind of freaking out now because LibreOffice is completely unusable and I have a presentation in < 1 week.
 * SpamapS wonders if ratpoison will work.....
<ScottK> SpamapS: Don't buy a new laptop, just get a spare hard drive and swap it out.
<SpamapS> ScottK: I have been eyeing SSD's .....
<ScottK> Once you go SSD, you'll never go back.
<SpamapS> So, bug number 9 for me to discover/report this week is that Libreoffice only crashes in KDE
<Laney> S5 is alright for presenting
<ScottK> Hmmm.
<SpamapS> I've gone to XFCE .. which seems to work w/ my multi monitor and not crash libreoffice.. :-P
<Laney> if you don't want to use beamer, which is clearly the best ;-)
 * SpamapS would use console presenter if dot's ascii graph generation were better. ;)
<ScottK> Upload the preso to some cloud thingy.
<SpamapS> Actually that might be a nice theme since my presentation is about a cli tool.. :)
<SpamapS> I'm still confused why only the 'Ubuntu' session automatically starts ssh-agent
<Laney> is it not provided by seahorse, a part of gnome?
<SpamapS> Or is it that its the only one that actually tells it what ssh-askpass to use?
<SpamapS> the agents are running, but not in the environment
<SpamapS> weird..
 * SpamapS plans a trip to Fry's to buy a new SSD tomorrow
<SpamapS> ahh interesting.. neither xfce nor kde sets SSH_ASKPASS
<Daviey> SpamapS: i'm not convinced having a faster disk will resolve this.  It's like putting more wood on the fire, without shutting the door :)
<SpamapS> Daviey: Oh I'm not doing SSD to go faster. I'm doing it to go back to Natty.
<Daviey> ah
<Daviey> fair nuff
<SpamapS> It saddens me to say it, but its costing me quite a bit more than 1 hour a week.
<hallyn> SpamapS: i'd get an ssd, but all the horror stories leave me feeling like i'll just get one of the duds anyway, and i don't have time to research which ones are actually ok :)
<SpamapS> I'll just get the 2nd most expensive one. :-P
<SpamapS> Hrm, seems like there should be an svg to ascii converter
<Amoz> SSD <3
<Amoz> libreoffice will start in a flash
<aroman> hi, what's the Mac version about? http://cdimage.ubuntu.com/releases/oneiric/alpha-2/
#ubuntu-devel 2011-07-23
<ScottK> doko_: What should I include in a bug about an ld segfault to make it useful?
<penguin42> ScottK: Have you got a core/full back trace/what exactly do you need to do to trigger it?
<ScottK> penguin42: I can tell you how to replicate it.  The build log just says "collect2: ld terminated with signal 11 [Segmentation fault]"
<penguin42> ScottK: Fun, if you can get a core/ full back trace that would be nice, but if it's fully repeatable on a package build it's not too bad - if you've got the lines from the build log showing exactly which call to ld/gcc caused it to seg that would be nice
<ScottK> Sure.  I'll file a bug explaining the details and then point you at it.
<penguin42> is it x86?
<ScottK> penguin42: Yes.
<ScottK> penguin42: Bug #815141
<ubottu> Launchpad bug 815141 in binutils (Ubuntu) "collect2: ld terminated with signal 11 [Segmentation fault] with koffice" [Undecided,New] https://launchpad.net/bugs/815141
<ScottK> It failed on i386.  I didn't upload an update anywhere, so no idea what other archs it fails on.
<penguin42> ScottK: Don't suppose you have the package version for binutils do you?
<ScottK> penguin42: It's whatever's in oneiric
<penguin42> hmm
<penguin42> ScottK: I just apt-got the source to binutils and line 2544 is a comment, so I'm surprised it's getting an assertion fail there!
<ScottK> It hasn't changed in two weeks, so I'm sure that's the version used.
<penguin42> hmm curious
<penguin42> oh, I really should reread your bug
 * penguin42 installs libqtwebkit-dev and tries again
<Viper550> Is any particular version of virtualbox recommended for 11.10 A2?
<broder> is conflicts+replaces sufficient to deal with a conffile moving from one package to another?
#ubuntu-devel 2011-07-24
<Yewbacca> Hi there! What path does patches to the Ubuntu Xorg Intel driver take? Xorg.freedesktop -> Debian -> Ubuntu?
<Yewbacca> What path does patches to the Ubuntu Xorg Intel driver take? Xorg.freedesktop -> Debian -> Ubuntu?
<Ampelbein> broder: When moving files from one package to another, policy recommends Breaks/Replaces instead of Conflicts: http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
<BullShark> I'm having trouble compiling gnome-applets deb-src. here's the error output http://vpaste.net/11QJ3?bg=dark Please help
<oscalation> if i wanted to get started with development and bug hunting for ubuntu on a beginner/ entry level,  can someone point me to the correct channel and maybe a link or page to "get started". How to set up a dev machine, what levels of support are available ect ect
<penguin42> oscalation: You could start by some bug triaging and help on #ubuntu-bugs
<penguin42> oscalation: If you're more interested in fixing stuff, then do you program, if so which language and what are you interested in?
<oscalation> is there a primiary language that a dev should know that is prevalent for ubuntu?
<oscalation> i am learning ruby, and know some python
<penguin42> lots of stuff uses python, but packages use lots of things - quite a bit of plain C
<oscalation> penguin42, im new to programming in general, but ive found that c, compared to the ruby scripting language, is a pain.
 * penguin42 is more used to C 
<oscalation> just my opinion, maybe im wrong
<penguin42> oscalation: It needs a different way of thinking on some stuff - but that's OK - there is plenty of python code out there to fix and work with!
<oscalation> so in order to really help in the open source world, would you recomend i pick up c?
<penguin42> oscalation: You don't need to - there are lots of projects based around each language
<oscalation> is there any good links or pages that show new users how to get started in the dev world, like setting up your dev manchine/environment ect ect
<penguin42> oscalation: Just set up a normal ubuntu installation with the programming languages you use (they tend to have their own dev packages); get yourself a launchpad account so you can comment on bugs etc
<dnivra> oscalation: I think the link in the topic might help?
<oscalation> questions about gpg encr keys, im creating mine to sign my code of conduct, and its asking for my "real name".. once set, is this able to be changed ?
<oscalation> i go by a common pseudo name  that i plan to use
<slangasek> oscalation: you can always revoke a uid on a pgp key and replace it with others with different information (name, email, etc), but once any uid is published it remains part of the data associated with that key
<juliank> oscalation: Do not use a pseudonym
<oscalation> juliank, i've always lived by a moto to not use my real personal information online, especially when 60%+ of americans use an email service provider that pratically hands over their search and email logs to anyone that comes knocking
<oscalation> juliank, i do appreciate your insite though, am i missing something, is there a reason why i wouldnt want to use a pseudonym
<juliank> oscalation: Pseudonyms are not helpful for gaining respect, and are simply uncommon.
<penguin42> oscalation: It can also cause problems with licensing - e.g. how do we know that this code is really allowed to be open sourced if we don't know who wrote it
<oscalation> penguin42, good point
<persia> juliank: There's a number of folk in Ubuntu who contrinute with a pseudonym.  Most of the more widely known tend to also have a registerd name on their key, or have paperwork assuring they have unique control over that pseudonym.
<juliank> oscalation: You also can't ever become a Debian Developer using a pseudonym (or use Google+) - and you might want to do some of this in the future
<oscalation> though, im more inclined to use something like.. diaspora .. or anonymous services
<oscalation> persia, so your saying, they use a handle, but their gpg keys are signed with their real name assuring the handle is owned and used by this one person? correct?
<juliank> persia: I don't care who does what with a pseudonym. I ignore them, get angry, or both. I tend to view the use of a pseudonym in communication with me as unrespectful behavior.
<juliank> I want to know who I am talking to without having to hire someone to find out their identity
<penguin42> juliank: Assuming you know that it's a pseudonym
<oscalation> surely you can understand the need to protect free speech by allowing methods of anonymous communication and online services like search
<oscalation> i think the success of TOR, and the growing number of privacy aware services like freedombox and diaspora is proof in the making
<juliank> penguin42: Of course, yes. If I don't know that it's a pseudonym, I don't know it.
<oscalation> i do understand your points though
<penguin42> anyway, this is getting rather odd and off topic
<oscalation> understood
<penguin42> oscalation: I don't think people would get too annoyed if you were to bug triage using a consistent pseudonym if you think you need it, contributing code would probably raise a few more questions
<oscalation> penguin42, i can understand that, i think i should be ok with signing my key with my real identity though to be honest my gut tells me otherwise. The age of big brother is apon us. <0) puts on tinfoil hat
<juliank> oscalation: And for correctness, it's somehow good to know whether the person you're talking to is male, female, or something else
<oscalation> lol
<penguin42> juliank: Heck I'm awful at remembering that even when I do know
<persia> Yeah, most folk who receive code check copyright, and would prefer that the claim of copyright be a legal name in some jurisdiction.  Few folk care if it's a personal name, corporate name, registered pseudonym, etc.  A random name one picked for use online is ararely acceptable.
<oscalation> persia, wait, maybe i miss understood, what do you mean by a registered pseudonym
<oscalation> are you refering to a user how registers their gpg key with the UID of their real name, but uses a handle commonly throughout the community ?
<juliank> oscalation: In certain countries, you can register pseudonyms with the government (and have them in your passport and/or similar things) and use them for official things.
<oscalation> *user who
<penguin42> juliank: Wow, never knew that - weird!
<oscalation> lol wow... thats um..
<persia> oscalation: Most governments accept registration of an alternate name for general e.  Such a registration is generally accepted as a counterparty for contracts, which tends to allow software licensing, etc
<juliank> It's somehow important for well known artists who want to use their artist name everywhere
<oscalation> cant the information be verified by the keys though, the name assocaiated with the key should be irrelevant, as long as the keys match up then you know its me .. Mr+71nF01lHAT
<persia> Indeed.  Also used widely for very small businesses that don't want to have a corportation.
<persia> No.  You need to have a legal identity that holds copyright for the code you contrinute, which is completely independent of GPG.  Mind you, if you're not contributing code, translations, or artwork, but just doing bug triage or support, then it doesn't matter.  (but this is the development channel)
 * persia gives up because of latency
<nigelb> latency?
<oscalation> understood, do you all know of a email provider that has built in gpg support from their web interface ? im using gmail and.. yeah
<oscalation> im willing to use a pay service
<nigelb> I don't know how safe it is to use a client that does gpg on the web.
<nigelb> This means your private key needs to be with the provider.
<nigelb> What you might want to look for is extentions to browsers which adds that functionality.
<oscalation> nigelb, any recommendations ?
<juliank> oscalation: browser?
<oscalation> ff, open to use anything else open source though
<juliank> oscalation: You could use FireGPG
<juliank> oscalation: or not, it seems discontinued
<oscalation> website says its discontinued
<juliank> oscalation: Then use a real email client.
<oscalation> thunderbird?
<juliank> oscalation: I guess it's your decision which to choose. Thunderbird needs a plugin for GPG, AFAIK.
<Amoz> hm. sudo desktop-file-install --rebuild-mime-info-cache would be the right way to rebuild the .desktop files cache ?
<oscalation> got another question if thats ok
<oscalation> im all set up, im now attempting to request a mentor on the https://wiki.ubuntu.com/BugSquad/Mentors   page
<oscalation> it says to set up my ubuntu wiki page, how do i get to that, there is no link
<ahasenack> hi guys, anyone around to nominate a bug for a lucid SRU?
<ahasenack> https://bugs.launchpad.net/landscape-client/+bug/813477
<ubottu> Ubuntu bug 813477 in Landscape Client "Update landscape-client to 11.07.1.1" [High,Fix committed]
<RAOF> ahasenack: There aren't any tasks on that bug pending acceptance?
<ahasenack> RAOF: I can't add them
<ahasenack> ahasenack: meaning, I either don't have the privileges, or don't know how to do it. If I try to use "also affects distribution" and add ubuntu, it complains
<ahasenack> it was fixed in oneiric already (uploaded)
<ahasenack> er, talking to myself
<ahasenack> RAOF: ^^^
<RAOF> Hm, quite true.
<RAOF> That's not a permissions problem, though; I can't seem to add a lucid task either :)
<ahasenack> I was told "core-devs" and "bug supervisors" could
<RAOF> https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/813477
<ubottu> Ubuntu bug 813477 in Landscape Client "Update landscape-client to 11.07.1.1" [High,Fix committed]
<RAOF> *That* link should allow you to add a lucid task.
<micahg> RAOF: yeah, you have to focus on the Ubuntu task to nominate
<RAOF> micahg: Yeah.  It just occured to me to try that.
<RAOF> ahasenack: Done.
<ahasenack> RAOF: thanks a lot!
<RAOF> micahg: Is there an extant bug in launchpad about that?  Or should I file one?
<micahg> RAOF: idk, the permissions are tasked based since each project can have a different ACL, I think there's a bug for it
<micahg> RAOF: bug 249434
<ubottu> Launchpad bug 249434 in Launchpad itself "Can't nominate a bug for an Ubuntu release when in a non-Ubuntu context" [Medium,Triaged] https://launchpad.net/bugs/249434
<RAOF> Ta.
#ubuntu-devel 2012-07-16
<pp7> in 12.04 how do change the background color of just the panel?
<SpamapS> pp7: try #ubuntu
<pitti> Good morning
<infinity> bdrung: I have zero issues with people stealing my bug tasks as long as they also fix them (as you did).
<pitti> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti
<pitti> gah, 80 requests in the queue?
<SpamapS> sounds like we need to get back on top of piloting
<infinity> SpamapS: pitti will fix it!
<pitti> RAOF: FYI, rejecting your precise udev-proposed queue upload; I add herton's fix for bug 1017715 and reupload; I also commit your fix to the bzr branch
<ubottu> Launchpad bug 1017715 in udev (Ubuntu Precise) "Serialization problem of udev events with DM_COOKIE set" [Medium,Triaged] https://launchpad.net/bugs/1017715
<RAOF> pitti: Ah, cool.
<RAOF> pitti: Also, gah bzr. :)
<pitti> Vcs-Bzr: ...
<pitti> RAOF: same for oneiric-proposed
<pitti> RAOF: argh; do you have a minute for a quick SRU review?
<pitti> RAOF: I accidentally rejected udisks from oneiric-proposed instead of udev
<RAOF> pitti: Sure; what's up?
<RAOF> :(
<pitti> RAOF: so I wonder whether you can quickly review it from https://launchpad.net/ubuntu/oneiric/+queue?queue_state=4&queue_text=udisks
<pitti> or whether I should reupload it
<RAOF> pitti: That's a nice, simple review; accepted.
<pitti> RAOF: cheers
<RAOF> I don't suppose you could get my mail to the TB out of the moderation queue in return? :)
<stgraber> RAOF: accepted
<RAOF> Ta muchly.
<pitti> RAOF: ah, saw this too late; would have done with pleasure..
<pitti> thanks stgraber
 * pitti runs listadmin nevertheless
<StevenK> Ah, that reminds me. /me runs listadmin too
<RAOF> Heh.
<hyperair> pitti: regarding https://code.launchpad.net/~hyperair/ubuntu/quantal/dput/sftp-progress-indicator/+merge/112934, sftp.py is currently an ubuntu-only thing. can we have it merged into ubuntu's code anyway?
<pitti> hyperair: oh, it is? sorry about that, I'll upload it then
<hyperair> pitti: thanks
<hyperair> pitti: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505173 <-- cody-somerville submitted it to debian, but debian didn't want to install bzr to use dput with sftp.
<ubottu> Debian bug 505173 in dput "Patch to add dput sftp transport and host argument support" [Wishlist,Open]
<pitti> *nod*
<hyperair> Laney submitted a python-paramiko using version of sftp.py, but debian hasn't replied to that.
<hyperair> responded, i mean
<xclaesse> I've removed liboverlay-scrollbar, now applications print that: "Gtk-Message: Failed to load module "overlay-scrollbar"" --> any idea why they are still trying to load that module?
<dholbach> good morning
<RAOF> xclaesse: Probably because the session file that sets that environment variable is a config file, so we don't remove it on remove.
<xclaesse> RAOF, which file is that?
<RAOF>  /etc/X11/Xsession.d/81overlay-scrollbar
<xclaesse> good to know, merci
<RAOF> Passing --purge to the apt-get remove call would have removed that file, by the way.
<dholbach> hi xclaesse
<bretth> anybody know how i can catch the event, when the user clicks my appindicator?
<Sweetshark> cjwatson:could you copy over the two libreoffice packages in https://launchpad.net/~bjoern-michaelsen/+archive/libreoffice-quantaltest-20120601 to ppa:libreoffice/libreoffice-prereleases including binaries?
<RAOF> bretth: I don't believe that there's any such event. Also, you'll probably have better luck in #ubuntu-app-devel, which is the relevant channel.
<Sweetshark> cjwatson: and the one package in https://launchpad.net/~bjoern-michaelsen/+archive/libreoffice-precisetest-20120327 to ppa:libreoffice/ppa (<- different ppa) including binaries?
<bretth> RAOF, your right: https://bugs.launchpad.net/screenlets/+bug/522152
<ubottu> Launchpad bug 522152 in libappindicator (Ubuntu) "indicator-application does not send signals when a menu is shown/hidden" [Wishlist,Triaged]
<caribou> pitti: ping
<pitti> hello caribou
<caribou> pitti: morning, how are you doing ?
<caribou> pitti: I just saw your note about https://code.launchpad.net/~louis-bouchard/ubuntu/precise/kexec-tools/lp988512-no-vmcoreinfo/+merge/112086
<pitti> quite fine, thanks! how about you?
<caribou> I'm fine, one week away from vacation :)
<caribou> I do agree that the comments were misleading. I'll check with smb if he wants his fixed introduced, but so far, abandoning vmcoreinfo is simpler
<caribou> upstream has confirmed that vmcoreinfo was no longer needed anyway
<xclaesse> any idea why evolution is in English while all other apps are in French on ubuntu Quantal?
<pitti> we didn't yet get new langpacks
<pitti> and evolution thinks it's a good idea to change the translation domain with every major version
<pitti> so it always takes a bit for evo to catch up
<xclaesse> btw, cherry-pick gnome-shell's f1ba2b77949d4732cd22a1fc4fe2ef9a96d0c3a1 fix a lot of things
<xclaesse> like gnome-shell freezing each time I start evolution
<xclaesse> pitti, ok thanks ;:)
<xclaesse> :)
<xclaesse> any idea why evolution won't load GOA google account?
<cjwatson> Sweetshark: So I was getting quite close to you being able to do that in the web interface - how urgent is this (i.e. could it wait for a Launchpad deployment and feature flag tweak), and how often do you need to do this (i.e. would I get another handy real-world test case in a few days)?
<tkamppeter> Anyone around who knows about debconf internals?
<tkamppeter> OdyX, hi
<cjwatson> tkamppeter: yes
<tkamppeter> cjwatson, it is about bug 921875 and its duplicates. What causes postinst to exit with status 10? How can one help the users to get able to update again?
<ubottu> Launchpad bug 921875 in debconf (Ubuntu) "package foomatic-filters 4.0.4-0ubuntu1.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 10" [High,Confirmed] https://launchpad.net/bugs/921875
<cjwatson> don't reassign use-of-debconf bugs to debconf.  that's like reassigning C code crashes to gcc
<cjwatson> Reassigned back to foomatic-filters with advice
<Sweetshark> cjwatson: this is rather urgent (I want to blog about it today to get as much early testing for 3.6.0/3.5.5 as possible). another testcase is a few days: not guaranteed, but should be no problem: LibreOffice rc release cadence is once a week ..
<cjwatson> Sweetshark: OK, all copied now
<Sweetshark> cjwatson: thanks a lot!
<DktrKranz> infinity: if you're going to file a debian bug, would you mind passing me the bug# ?
<pitti> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<cjwatson> jdstrand: There's an ancient (2006) restriction in the LP code that forbids direct uploads to -security.  This dates from when -security was managed outside Launchpad; I think it's no longer relevant and would like to remove it.  I know that you always stage in a private PPA anyway, but do you have any reason to keep that hardcoded restriction?
<cjwatson> (Any such direct upload would need manual approval anyway.)
<davmor2> hey guys I'm attempting a fresh install of quantal the top bar seems to be missing from the current iso
<shadeslayer> hallyn: uhm, do you guys need help with the tiff transition?
<davmor2> sorry to clarify the top bar is missing from the install part
<cjwatson> davmor2: I suspect the indicator ABI has changed again
<davmor2> cjwatson: okay just highlighting it
<seb128> cjwatson, it should not
<seb128> cjwatson, there was no change in the ABI version at least and no unity or indicator rebuild required
<davmor2> seb128: this could be fall out from the new unity roll out that I happened to notice maybe?
<seb128> there was no recent unity roll out
<davmor2> seb128: I thought there was one last week or was I dreaming?
<cjwatson> Mind you, I get a top bar in today's image
<cjwatson> (in KVM)
<davmor2> cjohnston: so could be a driver/screen size issue then maybe
 * cjwatson is not cjohnston 
<davmor2> cjohnston: this is a laptop 1366x786 off the top of my head with an intel driver
<davmor2> cjwatson: sorry
<davmor2> cjohnston: sorry
<cjwatson> No idea.  Check logs ...
<davmor2> cjwatson: I'd love to but the whole system died on the webcam page let be try it again for you
<davmor2> cjwatson: this is on amd64 incase I didn't mention that
<davmor2> cjwatson: okay I have the bar this time bad burn maybe
<cjohnston> cjwatson: I have debated changing my nick... don't know how much it would help, might then just get tab-completed for someone else... plus after having one for years its hard to change
<cjwatson> I think the appropriate response is mocking people who don't check the results of tab-completion, not changing your nick :)
<cjohnston> that works too..
<vibhav> pitti: ping
<pitti> vibhav: hello
<vibhav> pitti: The fbasics debdiff you uploaded for me FTBFSes in armel and armhf
<vibhav> Though the changelog says "Work around gfortran ICE on armhf, build with -O0. LP: #642043." and "Work around gfortran ICE on armel, build with -march=armv6. LP: #642043."
<pitti> gcc: error: SHLIB_LIBADD: No such file or directory
<pitti> vibhav: that's not an ICE, it's just a plain bug in the build system
<pitti> looks like a forgotten $ or so
<vibhav> pitti: ah, is there any workaround?
<pitti> well, it needs to be fixed
 * vibhav takes a look
<vibhav> hmm, SHLIB_LIBADD doesnt seem to be defined anywhere, grep -rw SHLIB_LIBADD * returns nothing
<vibhav> also, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680417 seems relevant
<ubottu> Debian bug 680417 in ftp.debian.org "RM: fbasics [armel armhf] -- RoQA; long standing general ARM issue" [Normal,Open]
<vibhav> Though that is a remove-a-package bug
<tkamppeter> OdyX: hi
<DktrKranz> vibhav: it shouldn't happen anymore with very recent r-base upload
<DktrKranz> vibhav: also debian #679180 has some details about it.
<ubottu> Debian bug 679180 in r-base-core "arm* builds fail: SHLIB_LIBADD: No such file or directory" [Serious,Open] http://bugs.debian.org/679180
<BenC> infinity, cjwatson: What's the proper way to get something ported (to powerpc) that build-deps on itself (sbcl)
<vibhav> DktrKranz: I had a look at this bug though :)
<hallyn> shadeslayer: hm, afaik we should be about done.
<cjwatson> BenC: infinity can arrange for the powerpc build chroots to temporarily point to somewhere with binaries to serve as build-deps; but we'll still need to get those binaries from somewhere
<BenC> cjwatson: Could that just be a .deb that I build and sign?
<cjwatson> BenC: I think so
<cjwatson> BenC: Or packages from Debian, preferably, if that's possible
<Laney> I think the policy says that the debs which are used for the real build must have been rebuilt on Ubuntu
<BenC> cjwatson: sbcl isn't being built for debian-ppc either, but sbcl.org has linux-ppc binaries, which I'm using to do the original .deb
<BenC> Laney: that's fine, we can always do a build1 afterwards
<cjwatson> Or we can do a build pass before feeding bootstrap binaries as build-deps to LP
<ScottK> Laney: Eventually.  You can (and sometimes must) use non-Ubuntu debs for bootstrapping.  You just can't leave them there.
<Laney> I'm talking about the build that you feed to LP to bootstrap.
<cjwatson> I can't remember the number of layers, but anyway, all BenC needs to do is to provide the initial set
<Laney> So take your debs from wherever, do your bootstrap locally using it on Ubuntu, and give those debs to LP.
<Laney> https://wiki.canonical.com/InformationInfrastructure/OSA/BootstrappingPackages
<cjwatson> Gosh, actual docs (albeit internal)
<Laney> the process for the developer is basically ^. The rest of it is about how to mangle the chroots, mostly.
<ScottK> I thought the official process was harass lamont or infinity until they do it.
<Laney> I just ripped the arm off my chair. This working out must be paying off ...
<cjwatson> ScottK: I think they were trying to hand it over to the OSAs.
<cjwatson> Or at least lamont was.
<ScottK> I was sort of joking about that being official.
<shadeslayer> hallyn: oh .. the tiff transition page needs to be updated then I guess
<cjwatson> ScottK: don't you know Ubuntu better than that? :-)
 * Laney applies superglue. An excellent resolution.
<hrw> hi
<tkamppeter> OdyX, hi
<micahg> cjwatson: jdstrand is on vacation until Friday
<hrw> guys: if I use git checkouts as source how version should look? 4.1.1+git20120713-0ubuntu1 or other?
<hyperair> is anyone else receiving these annoying intuit payment mails?
<Laney> yes
<Laney> isn't it just spam?
<ogra_> depends, are there banks using phpmailer ?
<ogra_> :P
 * ogra_ gets it too btw
<hrw> ogra_: phpmailer was quite popular class for sending emails few years ago
<ogra_> hrw, i still doubt any bankl IT security person would allow it in their network :)
<ogra_> *bank
<hyperair> Laney: yeah, but every 5 minuets or so i'm getting a new one.
<hyperair> sigh
<hrw> guys: versioning question - someone?
<Laney> looks fine
<Laney> I'd put the commit ID somewhere too
<Laney> either in the version or in the changelog itself
<hrw> Laney: in changelog as those are two repos
<shadeslayer> hyperair: Laney yeah me too
 * shadeslayer is wondering what all the email noise is about
<BenC> infinity: So, I have a signed sbcl.deb where do we go from here?
<cjwatson> micahg: thanks
<hrw> heh, why I did not learnt git-buildpacakge earlier ;D
<hrw> ok, android-tools 4.1.1 on a way to quantal
<ogra_> grrr, silly dmraid
<micahg> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: micahg
<hallyn> how do i have debian/rules just do the 'make install' step?  (i'm pretty sure 'make install DESTDIR=debian/tmp' will work, but i want to make sure i'm doing the idential steps)
<micahg> isn't that dh_auto_install?
<micahg> ogra_: is there a reason you used lzma in ac100 tarball instead of xz?  AIUI lzma has no error correction (or is xz not supported there)
<ogra_> micahg, well, all out live images use lzma unless that recently changed
<ogra_> happy to use something else if thats the common standard now
 * micahg has no idea what's used in the live images
<ogra_> gz is simply to big and gets corrupted during unpack ...
<cjwatson> Our live images use neither lzma nor xz.
<ogra_> any higher compression will do for me
<ogra_> oh ?
<cjwatson> Neither is sanely rsyncable.
<ogra_> i thoguht we switched to lz in lucid
<cjwatson> No, we've repeatedly rejected that.
<SpamapS> why does it seem like there are always 50 - 100 haskell-* uploads every few days?
<ogra_> ok
<cjwatson> But if you're going to use something based on that algorithm, you should indeed use xz if possible.
<ogra_> well, our initrd on ac100 doesnt need to be rsyncable
<micahg> SpamapS: people were trying to get it installable, but there were more ABI changing uploads to do still
<ogra_> since it is wrapped in a bootloader binary file
<Laney> I think depwaits are just shaking out
<Laney> there haven't been any new uploads in a while.
<cjwatson> SpamapS: It has very strict ABI handling, so even just new upstream versions of lower-level components tend to require everything above them in the stack to be rebuilt.
<SpamapS> micahg: this is going on 3 cycles tho
<Laney> But that set of uploads was ill-advised anyway.
<micahg> SpamapS: hrm?  haskell rdeps need to be rebuilt for every upload
 * ogra_ switches to xz then
<SpamapS> that all makes sense.
<Laney> (I hobbled it so that I get to stay high up on the leader board)
<SpamapS> I wonder if we'll see similar batches of uploads with more golang packages
<micahg> probably
<Laney> ocaml is similar
<SpamapS> similar but less popular? ;)
<cjwatson> ogra_: Though do check that your kernel actually supports that :-)
<Laney> less trendy, probably less churny as a result
<ogra_> cjwatson, haha, just what i asked in the other channel :)
<BenC> Build Start in 15 minutes => HAHAHA, JK LOL, Build Starts in 2 hours
<bambee> hi, when I try to start a dhcp server, nothing happens (the daemon is not running in background). Even if I start it myself by hand it does absolutely nothing. I only get the following message in dmesg  :   " init: isc-dhcp-server main process (3512) terminated with status 1"
<bambee> it's on quantal
<infinity> BenC: Honestly, I'd rather you argued with the Debian maintainer to turn PPC back on there first.
<BenC> infinity: Silly boy, Debian doesn't listen to me anymore
<BenC> But I can try pretending to be someone else
<infinity> BenC: Thankfully, the whole project doesn't have to, just one maintainer. :P
<infinity> BenC: You are, in general, upstreaming your PPC fixed for other things, I hope?
<micahg> benc: any chance you have a quick fix for https://launchpadlibrarian.net/109855481/buildlog_ubuntu-quantal-powerpc.lightning-extension_1.6%2Bbuild1-0ubuntu1_FAILEDTOBUILD.txt.gz, we can finally get lightning for powerpc again if we can get a fix today
<BenC> infinity: Yes
<BenC> micahg: Looks like the same fix is needed from thunderbird/firefox
<BenC> micahg: Should I upload, or send to someone?
<micahg> benc: debdiff on a bug would be fine
<infinity> BenC: Are any source changes required for sbcl on PPC (other than enabling the arch in debian/control)?
<BenC> infinity: Nope, just had to bootstrap it with an sbcl linux-ppc binary I downloaded from sbcl.org
<jono> are you folks having issues with broken packages?
 * ogra_ never had issues with non-broken ones ...
<infinity> jono: You might need to be a biiiiit more specific.
<jono> these are my issues:
<jono> http://pastebin.ubuntu.com/1095250/
<BenC> ogra_: Every once in awhile, you should pick a fight with a working package just for kicks
<infinity> BenC: Grr.  Then that makes the Debian maintainer's "I can't debug this, so I'll disable every arch" thing even more annoying. :/
<infinity> BenC: I wonder if ARM would be in a similar Just Works boat.
<ogra_> BenC, boooring :)
<BenC> infinity: arm isn't shown in the assembly subdir, so it's probably a no-go
<jono> infinity, ^
<cjwatson> jono: So how come you don't have python3-minimal 3.2.3-4?
<jono> cjwatson, no idea
<ogra_> yeah
<cjwatson> jono: Try 'apt-get install python3 python3-minimal'.
<jono> I have just been upgrading as normal throughout the cycle
<BenC> infinity: mips, sparc, alpha, and hppa are though
<BenC> micahg: I'll get right on lightning
<cjwatson> Oh, wait, I'm reading it the wrong way round.
<jono> cjhttp://pastebin.ubuntu.com/1095253/
<jono> cjwatson, http://pastebin.ubuntu.com/1095253/
<infinity> jono: Looks like you might have an older version of python3 on hold for some reason?
<jono> infinity, oh?
<cjwatson> Current python3's dependencies are correct.
<cjwatson>  Depends: python3.2 (>= 3.2.3), python3-minimal (= 3.2.3-4)
<infinity> jono: Oh, but not from your second paste.
<infinity> jono: apt-get update? ;)
<ogra_> ++
<infinity> You may have updated in the middle of an arch skew, and not since.
<cjwatson> Or 'apt-get --reinstall install python3' might help too.
<cjwatson> But I have to go.
<jono> cjwatson, I just tried that, smae issue
<cjwatson> dpkg -l python3
<jono> infinity, I did that before I tried to upgrade
<jono> iF  python3        3.2.3-3      all          interactive high-level object-ori
<infinity> jono: Grabbing 3.2.3-4 by hand and "dpkg -i"ing it should work fine, but I'm rather confused how your system got here in the first place without some violence.
<jono> infinity, yeah, I am not sure, I have not been doing anything particularly crazy
<ScottK> Some people have been having to fix this by hand.  No idea why though.
<ScottK> I can't replicate it.
<infinity> ScottK: You mean, Jono's not the only victim?
<ScottK> No.
<infinity> ScottK: I can't figure out how one would arrive here...
<stgraber> I saw some bug trafic with people having similar issues
<ScottK> Me neither.
<ScottK> Is it possible for not all binaries from a package to make it into a publisher run?
<infinity> Although, the 'iF' could be a clue.  Maybe something was breaking postinsts?
<ScottK> The bug that was fixed in -3ubuntu1 or -4 was a postinst bug.
<infinity> ScottK: No, it's impossible for this to have been published skewed, both are arch:all, from the same build.
<ScottK> -3ubuntu1 finished seconds before a publisher run started.
<ScottK> I was surprised it made it.
<infinity> ScottK: But a postinst failing could perhaps have gummed up the works, and could explain why jono is "stuck" on -3
<jono> infinity, do you have a link to the python3  3.2.3-4 package I can download?
<jono> what is the LP project?
<ScottK> jono: python3-defaults
<jono> thanks ScottK
<infinity> https://launchpad.net/ubuntu/+source/python3-defaults/3.2.3-4/+build/3655725/+files/python3_3.2.3-4_all.deb
<bkerensa> infinity: I have a similar or same issue as jono
<bkerensa> my updates are failing because of py 3
<jono> ok installing the package manually fixed it
<jono> thanks cjwatson, infinity, ScottK
<BenC> micahg: patch applied and build started...
<BenC> micahg: bug #1025387 for reference...
<ubottu> Launchpad bug 1025387 in lightning-extension (Ubuntu) "FTBFS: powerpc build fails (requires patch from thunderbird)" [High,In progress] https://launchpad.net/bugs/1025387
<micahg> benc: thanks
<infinity> bkerensa: Same workaround should get you going again (download the above and manually install it).
<infinity> ScottK: So, how long was the window of exposure here, and should we look deeper into trying to figure out WTF is going wrong, or just recommend people fix it by hand and scream "la la la, development release, la la la"?
<ScottK> I think the latter.
<bkerensa> infinity: that fixed it... I will pass the fix along since I know a few people who ran into the same
<infinity> ScottK: This may be exposing a subtle apt bug, if it just blindly refuses to do anything sane about upgrading packages in 'iF' state...
<infinity> ScottK: I was going to blame dpkg, until jono and bkerensa told me that 'dpkg -i' worked just dandily.
<BenC> chrisccoulson, micahg: bug #1025387 has the debdiff and the build completed without error
<ubottu> Launchpad bug 1025387 in lightning-extension (Ubuntu) "FTBFS: powerpc build fails (requires patch from thunderbird)" [High,In progress] https://launchpad.net/bugs/1025387
<ScottK> infinity: It could be.  Personally, I did the "meh.  development release".  that doesn't mean everyone should.
<micahg> benc: that upstream URL seems wrong
<BenC> micahg: ?
<micahg> benc: in the debdiff you link to a webkit attachment
<BenC> micahg: I just copied the patch from thunderbird, I didn't change the file, so it contains the same URL I had originally downloaded it from
<micahg> benc: ah, ok
<BenC> If that is gone, I'm not sure where to look :/
<infinity> Not actually the same patch, though it's conceptually the same idea.
<micahg> benc: and you wrote this one? (just want to get the dep3 headers correct)
<BenC> micahg: Eh, I fiddled the original just enough to work
<BenC> But yeah, I guess you could say I wrote it
<BenC> Are i386 and amd64 dep-waits being force rebuilt?
 * BenC is wondering how they dropped so quickly
<BenC> infinity: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681808
<ubottu> Debian bug 681808 in sbcl "Enable powerpc build" [Normal,Open]
<BenC> But I'm doubting that will help quantal...
<micahg> benc: depwaits are rebuilt when the deps are met
<micahg> s/rebuilt/retries/
<micahg> *retreid
<micahg> meh :P
<Laney> build happen good time
<BenC> micahg: unless of course it's dep-waiting on a virtual package
 * BenC notices those don't automatically run
<tkamppeter> OdyX: ping
<infinity> BenC: Well, it'll need bootstrapping in quantal regardless, I'd just prefer not to have a one-line Ubuntu delta to debian/contorl forever.
<BenC> Is linux-any valid on Ubuntu?
<infinity> BenC: Yeah, any-* and *-any are valid.
<BenC> Thanks
 * infinity goes to make a bootstrap archive for ppc.
<infinity> BenC: Where are these (signed) binaries of yours for me to play with?
<BenC> infinity: http://www.swissdisk.com/~bcollins/sbcl/
<BenC> just a signed .deb, no .changes or anything, since it's original source
 * infinity nods.
<BenC> infinity: do you need the whole shebang (.dsc signed)?
<infinity> Nope.
<bryceh> hmm, bug #968845 was fixed in quantal and SRU'd to precise, however there are no bug tasks for precise, and 'Nominate for series' doesn't give an option to add them.
<ubottu> Launchpad bug 968845 in xserver-xorg-input-synaptics (Ubuntu Quantal) "bcm5974 touchpad doesn't work after S3 on MacBookAir" [Medium,Fix released] https://launchpad.net/bugs/968845
<bryceh> anyone know how to fix this?  bdmurray?
<BenC> Is it just me, or is any package that uses clang to compile just trying to be a hipster?
<infinity> BenC: clang has a few language extensions that some people think are useful.
<infinity> BenC: But if something is build-depending on clang and *doesn't* actually require it, that's a bug, and it should use gcc.
<BenC> I just wonder if anyone using clang is using those extensions
<infinity> BenC: I know of one package that definitely is, though I forget the name now.
<BenC> I could try to fix the segv in clang on ppcâ¦but I think I'll opt to test those packages failing because of it using gcc
<infinity> BenC: Fixing clang (and/or llvm) would be a good thing anyway.  It's here to stay, whether we like it or not.
<infinity> (Which reminds me, I still need to do some armhf violence to clang...)
<bdmurray> bryceh: tried the api?
<BenC> llvm is even further down my priority list
<infinity> BenC: Oh, it could also magically go away with a newer clang.  Can you test with Debian unstable?
<BenC> I fixed one compiler (ghc), verified bootstrap of another (sbcl) and attempted another (D-compiler)â¦I think I'm done now
<BenC> infinity: I might give that a short
<BenC> *shot
<infinity> BenC: If it works in unstable, then just poke me repeatedly in the head to merge that to quantal, it's on my TODO.
<infinity> BenC: Oh heavens, you tried to do things to D?
<BenC> D is telling me that 1024 / (8 * 4) is a divide by zero error
<BenC> and I'm not even exaggerating
<infinity> BenC: Oh, if you use the unstable clang, you'll probably have to toss in the Ubuntu "powerpc doesn't always have altivec, you braindead compiler" patch.
<infinity> BenC: I really need to push that upstream.
<BenC> Ok
<infinity> BenC: Alright, I've uploaded an sbcl that enables itself on PPC (and will, of course, dep-wait), and I'll enable the bootstrap bits in the PPC chroots in a bit and make it happy.
<BenC> infinity: saweet, thanks
<micahg> infinity: can you bump this please: https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa/+build/3661232
<micahg> I'd like to see one actually work, before uploading the rest
<stgraber> micahg: done
<micahg> stgraber: thanks
<micahg> infinity: disregard
<infinity> micahg: Disregarded. :P
<BenC> stgraber: you should have made the score 9001, so we could say "the build score, it's over 9000!"
<stgraber> BenC: fixed ;)
<BenC> Let the memes begin
<infinity> BenC: You're a bit late for that meme.
<BenC> infinity: Yes, but I've never had a chance to use it, so call me slow
<BenC> Is there a run of http://qa.ubuntuwire.org/ftbfs/ for precise (or any releases prior to quantal)?
<micahg> benc: http://qa.ubuntuwire.com/ftbfs/precise.html, but hasn't been updated since release, maybe ask wgrant if he could turn it back on
<BenC> micahg: thanks, I just wanted a quick comparison for quantal
<infinity> BenC: Trying to see if you're making any progress? :)
<maxLimit> how can i compile/debug the source code of totem using eclipse ?
<bdrung> Laney: the unar support in file-roller bug: #965757
<ubottu> Launchpad bug 965757 in file-roller (Ubuntu) "Use 'unar' rather than 'unrar' to extract RAR files" [Wishlist,Fix committed] https://launchpad.net/bugs/965757
<Laney> nice
<bdrung> http://unarchiver.c3.cx/formats
<Laney> how should it be fixed in the packaging?
<Laney> full-on Depends?
<bdrung> let's check how the other formats are linked.
<mdeslaur> looks like upstream unrar is now available under the gpl
<micahg> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<BenC> infinity: yes :)
<BenC> stgraber: While you're on a build score frenzy, can you bump: https://launchpad.net/ubuntu/+source/blktap/2.0.90-1ubuntu1/+build/3661194 please
<BenC> Trying to get some build-deps out of the way for xen related things
<bdrung> mdeslaur: where?
<BenC> Although useless on powerpc, it's nice to have when one day I feel the urge to do some porting
<stgraber> BenC: done
<BenC> stgraber: Thanks
<mdeslaur> bdrung: http://www.rarlab.com/rar/unrarsrc-4.2.4.tar.gz
<mdeslaur> bdrung: "...this product may be distributed under the terms of the GNU General Public License (GPL), in which case the provisions of the GPL apply INSTEAD OF those given above."
<infinity> DktrKranz: Ugh, why didn't you just give Edd my patch and be done with it?  There's no "negative side-effect" to using PCRE on all arches.
<infinity> DktrKranz: Adding a bunch of fragile arm-only logic just makes it all the harder to maintain any sort of consistency.
<mdeslaur> bdrung: never mind, I misread
<infinity> DktrKranz: It also seems rather silly to use substring matching to detect broken substring matching.
<bdrung> mdeslaur: where did you read that statement?
<infinity> DktrKranz: It's also not a glibc bug, FWIW.
<infinity> DktrKranz: (Well, not that I've been able to determine so far).
<mdeslaur> bdrung: it's from the acknow.txt file in the archive, but I misread it...it's for code included, not the whole thing
<infinity> DktrKranz: POSIX extended regexes in r-base are handled by a bundled library.
<mdeslaur> bdrung: it's still non-free, forget what I said
<bdrung> Laney: file-roller depends on bzip2, zip and unzip. most other extracting tools are in suggests.
<bdrung> Laney: IMO, unar should be recommended.
<Laney> feel free to do so if you can justify the space usage and get the MIR done :-)
<bdrung> then it would be installed by default and we could drop unrar from ubuntu-restricted-extras
<DktrKranz> infinity: my first patch was indeed PCRE as default, and was very much the same as yours (and I noticed yours a couple hours later, so I didn't even have the chance to "steal" it :)
<Laney> bdrung: although u-r-e is in multiverse so arguably it could be dropped right now
<bdrung> Laney: hm, unar would pull gnustep
<DktrKranz> infinity: but I must admit I don't know R at all, so I trusted edd knowledge about potential impact of extending PCRE everywhere
<DktrKranz> I checked the simple substring worked, and it did. The rest was only a bad copy&paste :)
<infinity> DktrKranz: Ahh, your looked shockingly similar to mine, I assumed origination that wasn't there. :P
<infinity> DktrKranz: s/your/yours/
<infinity> DktrKranz: (As such, disregard the "PS" to my follow-up to the Debian bug) :P
<Laney> bdrung: I think you can still replace the suggests
<Laney> even if you can't justify putting it in main because of this
<DktrKranz> infinity: also, I supposed the real problem was something related to eglibc because I didn't have any clue about how R handles the regexes
<DktrKranz> But my bisecting didn't found the culprit, so perhaps it's not eglibc at all
<infinity> DktrKranz: As for PCRE by default, honestly, it's not even about R, it's about PCRE being wildly more reliable than, well, any other regex engine.  A rewrite of all that code to just use PCRE for EVERYTHING would be the sanest approach, since we link it in anyway.  But that's some serious effort, and a lot of ifdef foo to make upstream happy in the case of people building --without-pcre
<DktrKranz> ewww
<infinity> (Or just make R have a hard depdency on PCRE, like so many other applications do, because people have realised it's the only reliable and portable implementation that doesn't suck)
<infinity> But, way more effort than I want to put into a language I don't care about.
<DktrKranz> ACK.
<bdrung> Laney: i think the ubuntu-restricted-extras needs to be reworked
<DktrKranz> Anyway, I hope we can solve this issue for good, and then forward our thoughts upstream, to let them handle the situation in the most appropriate way
<infinity> DktrKranz: If you feel like debugging further, I *suspect* the error either lies in the bundled tre (in src/extra/tre), or in the code in R itself that's calling it.
<infinity> DktrKranz: 20 to 1 odds say it's an alignment issue or something.
<infinity> DktrKranz: And, for added fun, the bundled tre is a forked version from upstream tre.  So, it could just be that it was subtly broken in the fork.
<DktrKranz> Ouch
<DktrKranz> but good news it's not eglibc's fault, it could have been a PITA...
<infinity> DktrKranz: It still *could* be eglibc's fault, as we're also calling into eglibc to mangle wchars and such, but if wchar was fundamentally broken in eglibc on ARM, I think I'd have seen a lot more fallout.
<infinity> DktrKranz: So, it's probably either R mis-mangling types or doing dodgy pointer math, or tre doing similar.
<DktrKranz> I'm going to see the exact time builds started to screw things up, maybe it's easier to bisect the guilty change
<BenC> http://qa.ubuntuwire.org/ftbfs/ <= empty: guess everything is built
<BenC> And it's back
<infinity> robert_ancell: Hey dude.
<infinity> robert_ancell: You do realise that gnome-mahjongg was renamed to mahjongg rather recently, right? :P
<robert_ancell> infinity, hey, how's it going?
<robert_ancell> infinity, yes, I just did it
<infinity> robert_ancell: How many more times will it go back and forth?
<robert_ancell> infinity, none
<infinity> robert_ancell: No.  I mean, it was renamed in the other direction last cycle.
<robert_ancell> was is gnome-mahjongg at one point?
<infinity> robert_ancell: Yes.
<robert_ancell> infinity, oh, I think we might have picked that up off Debian
<infinity> robert_ancell: It was gnome-mahjongg in oneiric and earlier.  We changed a ton of stuff for the last rename, :P
<infinity> Oh, you mean Debian may have had it uniquely-named, but upstream didn't, and for some boneheaded reason, we dropped the Debian uniqueness patch for precise?
<infinity> And now, you've decided to do it upstream?  Check.
<infinity> We can mangle the seeds again.  Just promise me it won't rename again in 6 months. :)
<robert_ancell> infinity, well, it will be split into a separate module at some point, so we'll have that to deal with upstream!
<infinity> robert_ancell: But... It won't rename? ;)
<robert_ancell> nope
<infinity> Alright.
<robert_ancell> that's why I wanted to give it a more unique name
<infinity> robert_ancell: Shame you didn't just commit this upstream in the precise cycle, rather than us carrying it by a different name for exactly one release. :/
<infinity> Oh well.
<robert_ancell> yeah, there was some disagreement upstream, but that's been resolved now
<epikvision> bazaar branches are usually out-of-date.
<epikvision> how can I pick up the latest package versions?
<Laney> the archive is authoritative
<infinity> epikvision: By which, Laney means "apt-get source" should get you what you want.
<infinity> (Or getting it from LP)
<epikvision> hahah, thanks infinity
<epikvision> I needed the translation.
#ubuntu-devel 2012-07-17
<ScottK> Now here's a descriptive changelog entry for you: "Bugger off cdbs, may it burn in hell."
<mdeslaur> lol
<\sh> a good one ;)
<slangasek> Closes: all the bugs, without a doubt
<robert_ancell> anyone know how to disable make check in dh7?
<ion> Iâd try âoverride_dh_auto_test:â first.
<slangasek> yes
<slangasek> if you want it disabled at the package level
<slangasek> if you want to disable it temporarily for a local build, DEB_BUILD_OPTIONS=nocheck
<robert_ancell> thanks
<slangasek> but why are you disabling tests? :)
<robert_ancell> slangasek, libsecret tests aren't running for some reason when building with debuild, but do work fine when using local build
<slangasek> missing build dep?
<robert_ancell> no, this is building locally in both cases (one using bzr-buildpacakge, one in git)
<robert_ancell> and I think at least one test required $DISPLAY
<slangasek> ah
<slangasek> ideally 'xvfb-run make test' then
<slangasek> er, check
<robert_ancell> but too many things are blocking on it now, so really need to get it working
 * slangasek nods
 * slangasek reads about libsecret.  Why is upstream replacing gnome-keyring? :P
<robert_ancell> it's a rewrite and it's no longer gnome specific
<robert_ancell> same authors
<slangasek> hmm
<slangasek> same interfaces? :)
<robert_ancell> nope
<slangasek> bleh
<robert_ancell> I think it's an opportunity to learn from past mistakes
<slangasek> well, I guess the set of revdeps is manageable anyway
<RAOF> You might also need dbus-test-runner, which someone should get to Debian, too.
<robert_ancell> btw, does anyone know the correct way to make GIR files install into /usr/lib/girepository-1.0 when the libraries are multi-arch?  Or should gir files be multiarch too>
<robert_ancell> ?
<slangasek> ideally they should be in the multiarch dir
<slangasek> since they are arch-specific and you may want them for more than one arch at a time
<robert_ancell> slangasek, does that work? There don't seem to be any other packages doing that
<slangasek> robert_ancell: there's precisely one package doing this currently: gir1.2-guestfs-1.0
<slangasek> dunno if it works
<slangasek> most don't because of the gir bits being from a different, non-multiarched source package from the C lib
<roaksoax> is quantal archive frozen or anything?
<ScottK> roaksoax: Not officially.  We're trying to collect a stack of packages to accept all at once for scalability testing.  see cjwatson's mail on freezing to Ubuntu devel.
<micahg> benc: BTW, I uploaded the PowerPC fixes for lightning to our staging PPA, I'm waiting on the branch that quantal is using to upload that one
<BenC> micahg: I saw it built successfully, glad I could help
<micahg> benc: thank you, that means we get coverage across the board 6 weeks early
<micahg> well, except for the broken neon on arm*...
<infinity> micahg: Which broken neon on arm?
<infinity> ScottK: We're not trying to get a stack of packages to do at once, just to do lots of different packages via the CLI tool to see if anything explodes or times out.
<micahg> infinity: the thing you fixed in quantal
<micahg> just having it enabled at build time
<infinity> micahg: Well, sure, but I fixed it, so I was curious about the "still broken" bit.
<ScottK> infinity: If we aren't we should.  When I had trouble with the web UI, it was mostly with multiple accepts.  Very rarely was it a single package.
<infinity> (Well, "fixed"... With a bit of a large hammer)
<micahg> infinity: well, I meant in the stable releases it'll be broken unless we need a respin
<micahg> or until th next train
<infinity> ScottK: If you have to slim down to a single package here and there, such is life.  At least that's trivial with the CLI (queue info | mangle output | xargs queue accept)
<infinity> ScottK: The concern is that there could be single packages that will end our world.
<micahg> but otherwise, we have all archs back (well, except for sparc/ia64, but who's running a lucid desktop on that these days anyways)
<ScottK> infinity: Yes, but it varies.  If you can accept them in large stacks, the odds you get screwed by one go down as the only times I ever had problems with specific individual packages were also times I was constrained by the number it would do before timeout.
<infinity> ScottK: *shrug*
<ScottK> And doing them one at a time you never know if you tried one of the 'harder' ones or not.
<infinity> ScottK: I'm literally just blindly batch-accepting what's in unapproved occasionally.
<ScottK> OK.
 * ScottK is trying to kill off Debian RC bugs tonight.  Got 5 so far today.
<BenC> infinity: How do orphaned packages get dropped from the archive?
<BenC> e.g. kde-runtime no longer creates kde-runtime-dev, but it's still a valid package (although uninstallable)
<BenC> at least one thing build-deps on it (plasma-mobile), but of course, it can't be built now (I'm planning on fixing the build-deps after I verify it)
<pitti> Good morning
<infinity> BenC: I've been waiting on the last merger of plasma-mobile to package up a new upstream snapshot that makes it sane and buildable again.
<infinity> BenC: We drop NBS packages when nothing is left depending on them.
<BenC> infinity: Ok, then I'll leave plasma-mobile till then
<infinity> BenC: Yeah, changing build-deps won't be enough, already been there. ;)
<infinity> BenC: Have you met http://people.canonical.com/~ubuntu-archive/nbs.html ?
<BenC> No, but thanks
<BenC> More lengthy than I would have guessed
<infinity> It'll start shrinking rapidly, now that Debian autosyncs are off.
 * micahg wonders when we'll get our first rebuild
<infinity> doko wanted to do one late last week.  He must have forgotten in the excitement of kayaking and bodysurfing.
<micahg> great, I'm curious to see what havoc gcc-4.7 and the various new upstream imported have wreaked on the rest of the archive
<infinity> gcc-4.7 shouldn't be too bad, in that rebuilds were done already and bugs filed.
<infinity> But I'm sure some where missed.
<infinity> I think getting the NBS list down before a rebuild is sane anyway.
<infinity> Since lots of stuff is FTBFS right now with broken or out-of-date build-deps.
<micahg> well, we have --as-needed by default :)
<micahg> although, that's old news
<infinity> I've not noticed any weird interactions between 4.7 and as-needed... Have you?
<infinity> Seems to be business as usual.
<micahg> no, not really, which means it's about time for me to go to sleep :)
<infinity> Toodles.
<pitti> cjwatson: just accepted two pacakges from quantal/unapproved using the local queue tool; great work on this!
<infinity> rbelem: Did anything ever come of the plan to update plasma-mobile in quantal with a newer version?
<cjwatson> ScottK,infinity: Lots of packages at once will definitely not be a problem with the API client.  The timeout is applied per request, and acceptFromQueue is a method on individual PackageUpload objects, so the client always (has to) accept one at a time regardless of how many you give it on the command line.
<cjwatson> ScottK: I know skaet occasionally reported problems with even accepting a single package using the web UI.
<cjwatson> But it's true that lots at once greatly increased the odds.
<dholbach> pitti, weird - now booting without 'quiet splash' seems to have worked *shrug*
<pitti> dholbach: yeah, it always works for me as well
<pitti> something weird with the plymouth integration of encrypted swap devices or so
<dholbach> but it got stuck 3 times before
<dholbach> maybe it's just intermittent
<bambee> hi, http://paste.ubuntu.com/1096244/  ^^
<seb128> cjwatson, hey, do you know if that ubiquity issue is know,being worked? (that's one of the most reported issues on errors.ubuntu.com)?
<seb128> https://errors.ubuntu.com/bucket/?id=/usr/lib/ubiquity/bin/ubiquity:ValueError:watch_debconf_fd_helper:process_input:wait:cleanup:preseed:%3Clambda%3E:command
<seb128> cjwatson, I find some similar looking bugs in launchpad bug I'm not sure they are exact matches
<seb128> cjwatson, like the title on bug #986804 matches but the bug has hardly any detail
<ubottu> Launchpad bug 986804 in ubiquity (Ubuntu) "ubiquity crashed with ValueError in command(): I/O operation on closed file" [Undecided,New] https://launchpad.net/bugs/986804
<pitti> seb128: do you know what's the yellow bits on http://people.canonical.com/~ubuntu-archive/pending-sru.html ?
<pitti> that seems to be new, and not documented in the header
<Laney> bdmurray explained in #-release
<Laney> it means "new comments since v-done" IIRC
<seb128> pitti, I was wondering the same thing today
<pitti> oh, I see the commit
<seb128> "  sru-report: as a first draft change the bug color to yellow if it's date_last_message is later than the publishing date of the package
<seb128> "
<pitti>   sru-report: as a first draft change the bug color to yellow if it's date_last_message is later than the publishing date of the package
<seb128> snap :p
<seb128> I like that they are sorted by time in proposed btw
<pitti> hm, why would that need date of last message? if someone flips it to v-done, it'd still be yellow?
<seb128> pitti, no, v-done are green
<pitti> ah, so that means "a bug which should be inspected by the SRU team"
<pitti> perhaps as a replacement for reading bug mail
<seb128> pitti, it's to see which ones might need an update, i.e are still verification-needed but got comments
<seb128> it might be that a commenter verified or reported a regression but didn't know to tg
<seb128> tag
<seb128> pitti, I guess so
<Riddell> Laney: I'm getting a curious build error when compiling against libxml2
<Riddell> http://paste.kde.org/518930/
<Riddell> Laney: if I rebuild libxml2 it goes away
<Riddell> do you recon it would work if I just rebuilt it in the archive?
<Laney> erm
<Laney> did zlib break abi?
<Riddell> Laney: it has had multiarch things going on
<Laney> hmm
<Laney> libxml2 was uploaded after zlib
<Laney> Riddell: is your chroot fully updated?
<Riddell> Laney: should be but let me try again
<Laney> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673297
<ubottu> Debian bug 673297 in libxml2 "mipsel: /usr/lib/mipsel-linux-gnu/libxml2.so.2: undefined reference to `gzopen64@ZLIB_1.2.3.3'" [Critical,Open]
<Riddell> Laney: that fixes it, thanks :)
<Laney> ;-)
<ogra_> pitti, pingaling
<ogra_> pitti, i'm testing ac100 images atm, while running "ubuntu-drivers list" gets me the proper return value (nvidiy-tegra), i dont get anything in the drivers gui
<pitti> ogra_: pongedidong
<ogra_> any hint where i should look ?
<pitti> ogra_: we don't have a drivers guy yet, it's still in a branch of didrocks'/cyphermox'
<ogra_> oh, so what i see it the old jockey
<pitti> yes, that'll go away
<ogra_> k, that explains also why it works on the pandaboard :)
<pitti> ogra_: "drivers guy" argh, "driver GUI"
<ogra_> (we didnt have a jockey hook for ac100, but for omap4)
<ogra_> pitti, thanks a lot
<pitti> I'm currently working on the backend API, then didrocks will have it finished in no time, I'm sure
<pitti> I hope we can land it for a3
<ogra_> yeah, yesterday ...
<ogra_> he is did*ROCKS* after all :)
<pitti> +1
<didrocks> ogra_: pitti is doing all the hard work, don't trust this free ad ;)
<ogra_> didrocks, verbally bluching wont help, you still rock ;)
<ogra_> *blushing
<didrocks> heh :-)
<pitti> didrocks: system_device_drivers() just pushed; feel free to use from git (just set PYTHONPATH) if you want to play with it already
<didrocks> pitti: \o/ thanks a lot!
 * didrocks pulls
<pitti> didrocks: I'll add a new mode to ubuntu-drivers ("by-device") so that you can use it in textual form
<didrocks> pitti: that will be really handy :)
<ogra_> btw, since i just built a new machine here and added two graphics adapters ... if someone would be insane enough to add radeon and nvidia cards at the same time to the same machine, can we finally handle that case ?
<ogra_> (iirc there were issues with the GL libs, i was wondering if multiarch saves us from that)
<pitti> ogra_: /usr/share/ubuntu-drivers-common/fake-devices-wrapper <command> (e. g. ubuntu-drivers or didrocks' GUI), and you'll have both of them :)
<ogra_> well, would they also *run* ?
<pitti> but yes, nvidia still replaces the system's GL libray; I woudl have thought that tseliot's alternatives handling might save us here, though
<ogra_> ah, yeah
<pitti> you can't run them both at the same time, I'd guess
<pitti> but at least switch between the two without changing packages
<ogra_> yup
<didrocks> pitti: ah, http://paste.ubuntu.com/1096566/ using the wrapper
<pitti> didrocks: in case you pulled already, please pull -f
<pitti> didrocks: yup, that's what I just fixed, sorry about that
<didrocks> no worry :)
<pitti> didrocks: fglrx isn't being tested in the test suite, bad me :/
<didrocks> pitti: you rewrote history, how dare you! (j/k)
<pitti> didrocks: but presumably I just did the very thing you tried
<didrocks> heh, seems so :)
<pitti> yeah, I prefer consistent commits, as long as the previous push hasn't been too long ago
<didrocks> pitti: was just kidding :)
 * pitti hugs didrocks
 * didrocks hugs pitti. Thanks for your good work!
<didrocks> pitti: looks perfect to me, but yeah, some case in the wrapper where you create a fake "manual_install" one will be good. Will fake that into the my system answer for now
<pitti> didrocks: any suggestions? http://paste.ubuntu.com/1096582/
<didrocks> pitti: you don't have an example from not comming from distro as far as I can see (but this is linked to the manual_install discussion we had I guess). Otherwise, the needed info seems there! Great :)
<didrocks> pitti: no ascii orders for attributes?
<pitti> right, no support for the manual flag yet
<pitti> didrocks: sorry, ascii orders?
<didrocks> pitti: like "builtin distro free" instead of "distro free builtin"
<pitti> didrocks: it's a pretty arbitrary order, but I can change it around if you want; but it's just a debugging tool anyway
<didrocks> pitti: right, I was wondering if later we want to do some platform tests using it
<pitti> didrocks: oh, it's a predictable (i. e. stable) order
<pitti> so you can string-match it if you want
<didrocks> ok, as long as we have examples on the order, that's fine :)
<brendand> why is user /usr/bin/python still pointing to 2.7 in quantal? i thought that was fixed?
<tseliot> ogra_, pitti: you can do that as long as you use open drivers for both cards ;)
<pitti> brendand: fixed how? "python" will always be python 2.x
<pitti> python3 is 3.x
<ogra_> tseliot, lol, well, then i wouldnt use ubuntu-drivers i guess
<brendand> pitti - ok. maybe a different issue then. but apport-cli points to python so is not running on quantal
<pitti> brendand: oh, bug
<brendand> pitti, right. so the approach is that the applications need to change their shebang, rather than point /usr/bin/python at 3.2?
<pitti> yes, as soon as they got ported to py3
<pitti> brendand: I made a note to fix the shebang of apport-cli
<ScottK> stgraber: FYI, the partman-target piece of Bug #992241 is done (in -updates) and I copied the pending Ubiquity SRU as well, so the path is clear to do the Ubiquity part of that one.
<ubottu> Launchpad bug 992241 in ubiquity (Ubuntu Precise) "Upgrading using the live cd wipes /var/lib/mythtv/*" [High,Triaged] https://launchpad.net/bugs/992241
<stgraber> ScottK: thanks. I'll prepare an ubiquity upload today.
<bdrung> dholbach: sponsors-queue crashes on my system with: lazr.restfulclient.errors.ServerError: HTTP Error 503: Service Unavailable
<bdrung> dholbach: does it work on your system?
<dholbach> let me see
<dholbach> bdrung, still running
<dholbach> bdrung, it works
<LambdaDusk> hi, I am trying to develop some graphics app, and somehow I get errors when trying to open a window with GLFW and GLUT... GLFW tells me nothing, but GLUT says something about a framebuffer missing
<bdrung> dholbach: it's reproducable here: http://paste.debian.net/179474/
<dholbach> bdrung, I won't have the time to look into it, I'm afraid
<Debolaz> LambdaDusk: It seems #ubuntu-app-devel might be a better place to ask.
<BenC> Laney: Any idea when ghc-7.4.2 is coming?
<Laney> 17/07 12:28:02 <erikde> oh, ok. will do.
<Laney> 17/07 12:28:37 <erikde> maybe not today, bit busy. should be over the next couple of days.
<BenC> It appears to fix a test suite failure in cryptocipher on ppc
<BenC> Ok, thanks
<xnox> any idea or bug # when theming aka square radio buttons will be fixed?
<xnox> seb128: or somebody else? ^^^
<seb128> xnox, no idea, I didn't even know they were broken
<seb128> kenvandine, ^
<xnox> seb128: are you using quantal? =)))
<kenvandine> they are a little ugly, not sure if there is a bug filed for it
<seb128> xnox, no, I'm on the 12.04.1 team
<mterry> sladen, you have some unpushed changes in ubuntu-mono.  Is trunk  OK to push to quantal?  (I have a imagemagick4->5 transition that I wanted to push)
<kenvandine> the theme needs quite a bit of love, which hopefully will happen real soon
<kenvandine> xnox, wouldn't hurt to file a bug
 * ogra_ has seen this being discussed here several times
<ogra_> would be surprising if there wasnt a bug already
<xnox> kenvandine: it looks as if, it's the fallout from theming brake upstream
<kenvandine> xnox, yeah
<xnox> ogra_: kenvandine: it's just I want to subscribe to know when it will be fixed "for real"
<kenvandine> there are quite a few things broken because of upstream changes and our theme not keeping up
<stgraber> yeah, highvoltage mentioned it once and mpt tracked it down to a gtk regression IIRC, I seem to remember an LP bug being mentioned
<mpt> iz gtk boog
<xnox> stgraber: was it something like "invalid network-manager & ubiquity, fix-release light-themes?"
<xnox> mpt: lolz =)
<xnox> mpt: do you have a bug number on a square post-it note at your desk by any chance? =)
<mpt> xnox, if anyone knows, it's Cimi
<mpt> I just asked him and he waved his hand jedi-like and said "everything will be fixed"
<highvoltage> xnox ftw [ funny ]
<xnox> bug 1015497
<ubottu> Launchpad bug 1015497 in gtk+3.0 (Ubuntu Quantal) "Cannot select gtk dropdown list value in multiple applications: ubiquity, landscape client" [High,Triaged] https://launchpad.net/bugs/1015497
<xnox> is the closest I can find
<smoser> kenvandine, can you sort out https://bugs.launchpad.net/ubuntu/+source/light-themes/+bug/762167
<ubottu> Launchpad bug 762167 in light-themes (Ubuntu) "missing dependency on gtk2-engines-pixbuf" [Low,Triaged]
<sladen> mterry: to the best of my knowledge, yes
<xnox> bug 1024099
<ubottu> Launchpad bug 1024099 in light-themes (Ubuntu) "Widgets look square" [Undecided,In progress] https://launchpad.net/bugs/1024099
<mterry> sladen, cool, thanks
<sladen> mterry: try it and see, and if not, poke me again and I'll do some more investigation about what it/was
<kenvandine> smoser, again...
<mterry> :)
<kenvandine> smoser, yes.,.. i will
<smoser> kenvandine, i dont think you ever uploaded. i pinged you once after you uploaded without the fix, but i'm sure it just got lost in the hussle.
<smoser> its partially my fault for not just doing an upload, but pushing to lp:ubuntu/ branch
<kenvandine> smoser, no i am sure i did upload it
<smoser> hm..
<smoser> ah.
<smoser> then the bug is just probalby in the wrong state.
<kenvandine> but the packaging branch got moved around a couple times
<smoser> (i see it just got moved from fix released to triaged)
<kenvandine> so it might have gotten accidentally reverted
<kenvandine> smoser, oh... we fixed it by not needing it
<kenvandine>     - Remove the need for gtk2-engines-pixbuf in the gtk2 theme,
<kenvandine>       saves some CD space
<kenvandine> smoser, so if it is still actually needed, it is a bug in the theme
<smoser> kenvandine, ok. good enough. then i think the users of that bug are generally just confused.
<smoser> so do you believe this to be fixed in precise?
<kenvandine> yes
<kenvandine> that version was in april
<smoser> if so, can you please comment on that in the bug.
<kenvandine> i just did
<smoser> great. thank you sir.
<kenvandine> np
<smoser> sorry for the fire drill
<kenvandine> no worries
<kenvandine> :)
<kenvandine> if it is still printing the warnings then the theme needs fixing
<kees> jodh: any plans to add seccomp-bpf to upstart? :)
<zul> can an archive admin review python-cliff, python-django-compressor, python-django-appconf, and python-tablib please
<jodh> kees: no plans this cycle. I wasn't even aware of this feature: although the kernel supports it, the include files and man pages don't appear to cover it yet.
<kees> jodh: it's in 12.04 via a backport. it's all in 3.5.
<maxLimit> Good evening
<nandersson> didrocks, hi, I am having a look at your project session-migration. Is there  a way to try that out in Ubuntu 12.04?
<nandersson> didrocks, I guess I could compile it and package it?
<didrocks> nandersson: just retake the same packaging, it should work
<nandersson> didrocks, Ok, thanks!
<didrocks> yw :)
<maxLimit> i tried to import totem source code to eclipse but i get an error message:
<maxLimit> make: *** No rule to make target `all'.  Stop.
<maxLimit> the message appears after building in eclipse
<hippiehacker> I'm off and on, I sent you an email 8)
<highvoltage> ogra_: hey ogra_, so you're officially ogra underscore now? :)
<ogra_> highvoltage, i'm ogra underscore since hmm, three years now ...
 * highvoltage takes long to adjust to these things
<ogra_> since i started using a proxy and got to lazy to fight with nickserv
<infinity> ogra_: Three year is some serious lazy.
<infinity> ogra_: Maybe you should just fix it? :)
<alazare619> how do you add a ppa to a chroot build phase with livecd-rootfs?
<ogra_> infinity, i will if i switch to a better proxy :)
<barry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: barry
<scientes> indirect linking isn't working for me with multiarch cross-building http://paste.debian.net/179495/
<jtaylor> scientes: kytokabinet is underlinked, either link it correctly or disable as-needed
<scientes> oh ok
<scientes> why does it work natively then?
<jtaylor> is kyotocabinet also not linked against lzma natively?
<scientes> it is
<scientes> i mean, it is linked against lzma
<scientes> although ldd doesn't work cause the binary is foreign
<jtaylor> you need to do the same for the cross build
<infinity> That's easily fixable.
<scientes> but i copied it to a armel host, and ldd worked
<scientes> yeah it seemed like something that the multi-arch stuf should handle
<scientes> infinity, what is easily fixable?
<infinity> scientes: The ldd thing is on my TODO.  I had hoped to sort it for wheezy (and maybe I'll still try to squeeze it in)
<scientes> do i just need to link against everything, even that which is indirect?
<scientes> ok, and when ldd gets fixed it should work?
<infinity> scientes: As for your linking issue, it shouldn't relate to the ldd thing, no.
<jtaylor> scientes: you also need to disable as-needed
<infinity> scientes: Could just be that the cross toolchain is lacking sane -Ls?
<scientes> infinity, is that in LDFLAGS, cause if tou see the paste i tried adding those
<infinity> scientes: I see a shocking lack of whitespace in -D_KC_APPLIBS="\"-L/usr/lib/arm-linux-gnueabi
<infinity> In fact, I'm not sure what that's meant to do. :P
<infinity> Oh, I see.  That's a big long list with the -lfoo as well.
<infinity> I'm misreading that bit.
<scientes> that first one works
<infinity> Misreading it as something that makes sense to pass to a compiler.
<infinity> Which that doesn't.
<scientes> its when its indirectly linked it doesn't
<jtaylor> thats because it isn't, kyto is not linked against lzma
<scientes> jtaylor, but it IS
<jtaylor> oh
<scientes> i copied to a a armel host and checked with ldd
<infinity> scientes: Does the exact same command line also work on armel?
<jtaylor> I misunderstood you before then
<scientes> infinity, good question
<jtaylor> ldd -r shows no undefined references?
<scientes> http://paste.debian.net/179516/
<scientes> infinity, yes it does work on arm, and creates the kcutiltest binary, which works
<infinity> Curious.
<infinity> I'm inclined to blame the crosss toolchain, but not entirely sure what to blame it for doing off the top of my head.
<scientes> with g++-4.7 too
<scientes> i had this problem with the emdebian squeeze g++-4.4
<scientes> then compiled it according to instructions here: http://gsoc.sitedethib.com/posts/apt-get_install_gcc-4.7-arm-linux-gnueabihf/
<scientes> and had the exact same problem
<infinity> At least it's consistent. ;)
<scientes> and i subbed armel and eabi, for armhf stuff
<infinity> Is this a source package I can test?  I suppose I could just do a minimal testcase, but that sounds like effort.
<scientes> if you do DEB_BUILD_OPTIONS=nocheck the kyotocabinet from unstable/quntal will work
<scientes> but it doesn't even get that far, so it doesn't really matter
<jtaylor> have you tried without as-needed?
<scientes> Steve Langasek on #multiarch on OFTC says its a known bug with ld
<infinity> Mmkay.
<slangasek> https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/UsingMultiArch, search on "DEB_LDFLAGS_APPEND"
<slangasek> in particular, -Wl,-rpath-link=/usr/lib/arm-linux-gnueabi:/lib/arm-linux-gnueabi:/usr/lib is used to work around this wrong default in the cross-binutils package
<infinity> This seems easily fixable in the cross toolchain...
<slangasek> nothing ever seems easily fixable in the cross toolchain, AFAICT :)
<smoser> SpamapS, around?
<smoser>  /etc/init/cloud-init-local.conf is: start on mounted MOUNTPOINT=/
<smoser> is that guaranteed to have /run or /dev/shm? access?
<SpamapS> no
<SpamapS> smoser: virtual-filesystems would guarantee that, I think.
<SpamapS> but does not block
<smoser> virtual-filesystems definitely would guarantee that.
<SpamapS> I haven't looked in a while when MOUNTPOINT=/ is emitted
<smoser> i think its not guaranteed.
<ScottK> Would someone who understands something about Java look at Bug 937710?  It appears that the SRU we just copied to -updates might not have fully resolved the bug.
<ubottu> Launchpad bug 937710 in visualvm (Ubuntu Precise) "[SRU] VisualVM does not start with openjdk 7" [Undecided,Fix released] https://launchpad.net/bugs/937710
<dylan-m> Thanks for the detailed code review, barry! I'll be able to jump into that later this week, I hope :) Mpt filed a bug report about the height of the updates list earlier today: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1025674
<ubottu> Launchpad bug 1025674 in update-manager (Ubuntu) "List of updates is much too short by default" [Undecided,New]
<dylan-m> Fixing it should be pretty painless. Just needs different defaults in dconf to start with. (Though some fancier design-related updates might lead to good places, too).
<barry> dylan-m: sure thing!  thanks very much for the branch.  since there's a separate bug on the details height, don't feel obligated to fix that in your branch.  i.e. it could be fixed in a separate branch, but if the fix is easy and you want to include it in your updated branch, feel free to do so!  please do link your branch to that bug if you do though.
<barry> dylan-m: and feel free to ping me if you have any questions or just disagree with me. :)
<YokoZar> Is there a way to get the slightly older firefox 13 source packages off launchpad anywhere?  I want to put them in a PPA
<scientes> YokoZar, debian has esr releases in wheezy, you could just rebuild those
<scientes> which is firefox 10
<scientes> otherwise you shouldn't run older versions of firefox, except for regression testing
<scientes> *bisecting
<YokoZar> scientes: right, that's what I want to do
<micahg> YokoZar: why ,that's not recommended
<scientes> YokoZar, just use mozregressions
<scientes> its super awesome and downloads the daily builds from ftp.mozilla.org
<YokoZar> micahg: I have an environment where we have to do a good chunk of manual work to support each new firefox release
<scientes> and they have them back for years
<micahg> YokoZar: you want the ESR then
<YokoZar> micahg: the proper solution to this is to grab packages from our own repository and update it when firefox updates
<scientes> ^^^^^^^^^^^^^+1 for esr
<cjwatson> YokoZar: aside from whether it's a good idea or not, https://launchpad.net/ubuntu/+source/<source package name>/+publishinghistory for any source package has everything
<scientes> YokoZar, precise runs firefox esr
<YokoZar> cjwatson: ahh yes I was hoping for that :)
<scientes> AFAIK
<micahg> scientes: hrm? we just pushed out 14
<scientes> oh yah
<scientes> whoops
<cjwatson> though it might time out for a big package like firefox.  you can use https://launchpad.net/ubuntu/+source/<source package name>/<source package version> directly
<scientes> micahg, you should also package esr
<cjwatson> well s/big/old/ I guess
<scientes> oh wow, you push out ff14 to even lucid
<micahg> YokoZar: as long as you're updating your own packaging to the latest release, or staying on the ESR, you're fine, otherwise, you're open to security issues (and even the ESR might have some, but hopefully not critical ones)
<micahg> scientes: have you read http://www.chriscoulson.me.uk/blog/?p=111
<scientes> micahg, so that is the real reaon you do not build libxul as a shared library anymore?
<YokoZar> micahg: Yes, I know, keeping up to date is a good thing :D  But the immediate impact is it will break some very custom-specific scripts here until I can forward-port the changes
<scientes> YokoZar, that is why you should run esr
<micahg> YokoZar: we have builds available in PPAs for you to adjust your stuff in advance
<scientes> micahg, i run ff nightly ;), if you put a sym link to it from ~/bin/firefox then even the .desktop files work
<YokoZar> scientes: I will migrate at the next ESR, at the moment I need some 12+ specific features
<micahg> YokoZar: 12 weeks notice here: https://launchpad.net/~ubuntu-mozilla-daily/+archive/firefox-aurora, 6 here https://launchpad.net/~mozillateam/+archive/firefox-next/+packages if you grab the build after the migration (which happens shortly after release)
<StevenK> RAOF: 'ubuntu-bug nvidia' no worky
<YokoZar> Noted micahg :)
<RAOF> StevenK: That's because there's no ânvidiaâ package; âubuntu-bug nvidia-currentâ works, right?
<StevenK> RAOF: Right, that does.
<StevenK> RAOF: I've restarted X and removed the module, so I'm not sure filing a bug now is the right thing to do. :-)
<RAOF> Heh.
#ubuntu-devel 2012-07-18
<YokoZar> We try to use "12.04" instead of "precise" in all user-facing communication, correct?
 * YokoZar just noticed Ubiquity still says things like "overwrite Ubuntu Precise" 
<barry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<TheMuso> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: TheMuso
<TheMuso> bryceh, RAOF, who should I be subscribing to take care of this patch, given you need to put it in debian git? https://bugs.launchpad.net/ubuntu-omap4-extras-graphics/+bug/1015292
<ubottu> Launchpad bug 1015292 in xorg-server (Ubuntu) "QT5 based applications fails with a segmentation fault with Pandaboard and the SGX driver" [High,In progress]
<TheMuso> ...or is it on your radar already?
<RAOF> TheMuso: You can subscribe me if you like. That wouldn't be on one of our lists, because ricardo has it assigned to himself.
<TheMuso> Right, and you wouldn't see it anyway since the package is not set to xorg...
<TheMuso> RAOF: Thanks, will do.
<nigelb> Laney: Congrats on core-dev! :)
<infinity> It was fixed.
<TheMuso> Given Debian is now frozen, what are other pilots doing if they encounter new upstream releases in the queue? I'm enclined to query the contributor why they think it should be updated, but other than that, I might just let through. THoughts?
<RAOF> TheMuso: I'd probably tend towards updating it, as long as the packaging isn't significantly divergent to Debian.
<TheMuso> RAOF: Thanks for the advice, thats what I've been thinking too.
<killown> sudo apt-get install libfreetype6-dev:i386  makes remove the follow packages build-essential dkms g++ gcc gcc-multilib libcairo2-dev libfontconfig1-dev libfreetype6-dev libgtk2.0-dev libimlib2-dev libpango1.0-dev libxft-dev nvidia-current tk-dev  tk8.5-dev virtualbox-dkms, what's going on with ubuntuÂ¿  same problem here https://bugs.launchpad.net/ubuntu/+source/wine1.4/+bug/944321/comments/19
<ubottu> Launchpad bug 944321 in wine1.4 (Ubuntu) "apt-get build-dep script for wine missing xorg and " [Undecided,Confirmed]
<pitti> Good morning
<TheMuso> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> cjwatson: seems queue is stumbling over accepting checkbox: http://paste.ubuntu.com/1097785/
<pitti> cjwatson: it's a standard LP timeout
<StevenK> pitti: It timed out in close_bugs_for_sourcepackagerelease, how many bugs does it reference?
<pitti> http://launchpadlibrarian.net/110354354/checkbox_0.14.2_source.changes
<pitti> 8 bugs
<pitti> that was the case that cjwatson already mentioned in his post
<StevenK> Right
<pitti> the workaround would be to upload that to -proposed, accept, let it build, and copy it over, i. e. what we are about to do automatically anyway
<pitti> but at least we now know it's a definitive issue
<StevenK> Bug closing during accept has always been an issue, TBH
<pitti> yeah, of course
<pitti> StevenK: I guess it's not trivial to make it use the same async bug closing as syncPackage()?
<StevenK> pitti: syncPackage() is not a LP method that I can see
<pitti> StevenK: ah, I mean copyPackage()
<pitti> I keep mixing up the two
<pitti> syncPackage was the older one
<pitti> (but probably still exists)
<StevenK> pitti: Right, so copyPackage() creates a job that does the copy -- no, it's not trivial.
<alazare619> anyone here familiar with livecd-rootfs
<alazare619> im trying to add a ppa to the building phase  but its not getting added
<pitti> alazare619: it's easier to use ubuntu-defaults-image from the ubuntu-defaults-builder package; see the manpage
<pitti> it directly supports building a live CD with an extra PPA/package
<alazare619> meh
<alazare619> :P
<alazare619> manpage ubuntu-defaults-image?
<pitti> alazare619: http://manpages.ubuntu.com/ubuntu-defaults-image
<infinity> StevenK / cjwatson: So, if we're timing out with only 8 bug closures, I'd say that's a resounding failure for the "can we remove queue from cocoplum before we try a real release freeze" test, at least until we can beef that up...
<StevenK> infinity: The function in question is close_bugs_for_sourcepackagerelease, and it's been horrid for a long while.
<infinity> cjwatson: (Unless we really want to live with the "upload somewhere that doesn't process bug closures and then copy" workaround during a release crunch, but that seems like a silly amount of self-imposed pain)
<infinity> StevenK: Yes, we're well aware of how horrid it is, it's specifically why we were doing the fake freeze test.
<StevenK> for bug in bugs_to_close: <work out target> bug.newMessage() ;  for more than two bugs is not full of puppies of rainbows
<infinity> StevenK: And if it's performing THAT badly, I'd say the test failed.
<pitti> well, is there a dramatic urgency of removing the cocoplum shell tool?
<pitti> I thought the main point was that everyone in ~u-archive can now process the queue
<infinity> pitti: IMO, no, but others seem to think differently. ;)
<cjwatson> pitti: interesting; it accepted it fine for me
<pitti> I don't see why we can't keep the shell tool until the "all uploads to to -proposed" machinery is in place
<cjwatson> pitti: FWIW sync*Source* was the older method :)
<pitti> cjwatson: hm, I tried two times, but I guess 8 bugs is close to the magic bounardy
<pitti> cjwatson: ah :)
<infinity> pitti: Trying two times probably primed the caches juuuust enough. :)
<pitti> heh
<cjwatson> I wanted to remove the shell tool because it's something like 2000 lines of code that *almost* doesn't need to be there
<infinity> cjwatson: I'm all for it being removed as soon as we can, but I'm not sure that's today, if 8 bugs is our limit.
<cjwatson> Yeah, doesn't sound ideal.  Disappointing.
<pitti> cjwatson: I guess we can at least start with severely trimming the list of people with ssh access?
<infinity> (Perhaps it's time for someone to actually think about profiling that there leviathan of a webapp)
<infinity> Or, make bug closures async.
<cjwatson> infinity: lifeless has been talking about making a notification service for a while
<pitti> cjwatson: (I don't mind having mine revoked, FTR)
<cjwatson> pitti: There's a little while yet before I start on that kind of thing
<infinity> cjwatson: In fact, pitti volunteered on behalf of others to revoke theirs too! ;)
<infinity> 00:01 <pitti> if cjwatson, you, and slangasek keep access, there should always be one person available for emergency accepts
<infinity> ^---
<pitti> the only reason for sshing there recently has been checkrdepends; but that in no way requires cocoplum access, just me getting out of old habits :)
<infinity> 00:02 <pitti> also, I think you're by far the most attractive archive admin
 * pitti files a bug against weechat about its string rewriting
 * infinity whistles.
<pitti> getting a towel to wipe clean my screen now
<infinity> pitti: I mostly use reverse-depends(1) now, but I don't trust it fully.  I should look into why that is and file bugs.
<pitti> infinity: the next best thing woudl be to run it on people, which also has a local mirror
<infinity> pitti: And, conveniently, a checkout of ubuntu-archive-tools.
<cjwatson> So turning bug closures into a job mightn't necessarily be *horribly* hard; one reason I haven't is that it seems to overlap with this notification service thing
<StevenK> cjwatson: I think it might be worthwhile to investigate a better API for that first, rather than just clammoring for a job.
<pitti> is there an estimate when we'll likely have the "everything into -proposed" machinery? because that would circumvent the problem, wouldn't it?
<cjwatson> StevenK: as in internal API?
<StevenK> cjwatson: Yes.
<infinity> pitti: I'm hoping I can make it go vaguely "soon", but then I'd also want to fix/change accepts into -proposed to automagically twiddle bugs to Fix Committed, which will hit the same wall.
<StevenK> cjwatson: The current code does a for loop over each bug, using BugTaskFlat we could fetch the relevant tasks in one fast query, feed the list of tasks and a message into BugSet.something, win
<infinity> pitti: Right now, we do that by hand with sru-accept, which is silly.
<pitti> infinity: *nod*
<infinity> Anyhow, I think I'm going to have an uncharacteristically early night.
<StevenK> infinity: Who are you, and what have you done with the real Adam?
<infinity> StevenK: I didn't say I'd succeed at it.  I'm just going to try.
<infinity> Fingers crossed.
<cjwatson> StevenK: there is a possibility that I may have a go
<cjwatson> if I can understand it
<StevenK> cjwatson: I'm certain both wgrant and I would be happy to have a pre-implementation call with you
<cjwatson> not to mention figuring out how to QA it ...
<StevenK> cjwatson: It may end up having to be a job, but maybe not
<infinity> cjwatson: File a bunch of bugs, write a tool that uses the new API to mangle them over and over, time it?
<cjwatson> infinity: caching
<infinity> cjwatson: Doesn't really need to be hooked up to accepts.
<infinity> cjwatson: File more bugs!
<cjwatson> for testing, StormStatementRecorder is probably more useful.
<StevenK> Yeah
<StevenK> Call close_bugs_for_spr and see if the statement count makes you sob or not.
<StevenK> If there are no tears, the test passes.
<cjwatson> The other problem is that it isn't just the target computation; doesn't it take time to notify each recipient too?
<StevenK> I'm not sure about that, but maybe
<wgrant> StevenK, cjwatson: Yes, the main problem is usually notifications.
<wgrant> cjwatson: Of course, the proper way to fix this is to make accepts async like copies
<cjwatson> Move the whole thing to jobs rather than just the bug closures?
<cjwatson> The problem there is that errors in the acceptance are more likely and more important than errors in bug closures, and making the whole thing async would complicate error notifications.
<wgrant> cjwatson: It would, but acceptance should really be the same code as copying.
<wgrant> Treating them differently is... odd
<infinity> cjwatson: It already notifies by mail (and I certainly get mail when a copy goes kablooey)
<cjwatson> infinity: There's no mail notification when an attempt to accept a package fails
<infinity> cjwatson: If we just augment that service to also mail the person who initiates the job (ie: the AA driving) on anything !accept.
<cjwatson> But OK, it's certainly *possible* for failed jobs to mail error notifications
<cjwatson> I'm not convinced the resulting UI is good
<wgrant> Well
<wgrant> It may not be good
<wgrant> But it will work
<infinity> Well, as wgrant points out, it's the same UI as copies.
<wgrant> Whereas what we have now does not work
<infinity> So, either it's all bad or all good.  Half bad seems weird.
<cjwatson> What we have now works about (from raw data during this experiment) 95%+ of the time
<infinity> And, if the copy experience isn't ideal, we should probably look at sorting that.
<infinity> Cause, frankly, except in freeze periods, I bet we copy almost as much as we accept directly.
<infinity> Okay, and not counting autosync stuff, but that could use an overhaul too.
<cjwatson> autosync just had an overhaul :P
<cjwatson> Once we get to the point of copying things, failures are rather less likely, and we guard against a lot of the plausible ones in the sru-report stage
<infinity> Define "failure" here?
<infinity> You mean genuinely broken packages that somehow explode the machinery in unpredicted ways?
<infinity> Or rejects?
<infinity> Cause we get rejects on copies.
<cjwatson> I mean QueueInconsistentStateError
<infinity> Kay.  Can't remember the last time I ever saw that on an accept either.  But you have accepted a lot more packages than I in the last few years.
<cjwatson> Looks like basically version clashes, file overlaps, and invalid components.  Maybe that's not so bad.
<infinity> Those should all be rejects.
<infinity> How are they not?
<cjwatson> Possibly these are last-ditch guards and they're supposed to be rejected earlier.  I forget.
<infinity> Well, I would assume the first two are trying to guard against some race whereby you could land clashes in the queue somehow.  But given that that should all happen serially with locking and such, well done if we still haven't fixed getting to that state.
<infinity> The latter, I have no idea how it would "slip in".
<infinity> (Except maybe a guard against a bug in the old queue tool allowing you to override something into oblivion?)
<infinity> Or a bug in rewriting of components from Debian.
<cjwatson> You know what would help?  A job runner that ran continuously watching for stuff to do, rather than running every minute
<cjwatson> infinity: Resurrecting rejections comes to mind
<cjwatson> (For the first two)
<infinity> cjwatson: Those should then pass through the same accepty machinery (that's not historically been true, but it really should be now, if it's not...)
<cjwatson> They do, but if they fail, you get QueueInconsistentStateError.
<infinity> Special.
<cjwatson> Which leaves them in rejected so in fact this is fine.
<cjwatson> I do think that the up-to-a-minute-or-so delay you get for copies would be Very Very Annoying for accepts.
<cjwatson> It's merely Annoying for copies, perhaps because we're used to it.
<infinity> cjwatson: Actually, for accepts, I'd find it less annoying.
<cjwatson> Really?
<infinity> cjwatson: I find it annoying for copies, because of the pile-on bug that copies often then need an accept.
<cjwatson> Well, OK
<infinity> cjwatson: I don't often need to follow-up an accept.
<cjwatson> But imagine you're iteratively processing the queue
<cjwatson> You'll often be going back and looking at what else is there right afterwards
<infinity> Accepts are fire-and-forget, until they produce something later (via a buildd).
<cjwatson> Frequent source of WTF moments
<infinity> Oh, I suppose there's that.
<infinity> DB addition to mark accepts as "accepting", so that UIs can choose not to display in-progress jobs, and twiddle then back if the async job fails?
<infinity> s/then/them/
<cjwatson> That'd be a new upload status (effectively another "queue", as we choose to see it)
<cjwatson> Well, not quite, because it would need to remember the old status
<infinity> Yeah.
<infinity> I didn't mean it as a status change, but just a flag.
<infinity> It would still be in its queue until the job finished and moved it to accepted.
<infinity> Just marked as "don't show up in high level UIs, I'm thinking".
<cjwatson> Maybe.  Kind of sounds like solving the problem by adding more data.
<infinity> Which then also gives you a "--show-in-progress" option to queue, if you want to see what's going on.
<infinity> Well, you can add a column, or you can AND the previous queue (I assume they're ints?) with some magic number to create a superqueue. :P
<infinity> But either way is adding data.  I don't know of a way to track state without doing so.
<infinity> Midgets, I suppose.
<infinity> We could hire midgets.
<infinity> To sit in the appservers.
<infinity> And keep watch.
<infinity> It miiiiight be bedtime.
<RAOF> I suggest pixies; they're cheaper.
<scientes> dpkg-shlibdeps: error: invalid dependency got generated: liblzma_private_symbols
<scientes> havn't gotten that one before
<alazare619> ok is the ubuntu-image-defaults a minimal iso?
<alazare619> or is it gnome?
<pitti> alazare619: it's an ubuntu desktop CD, i. e. with unity/gnome
<alazare619> is there a way to get image-defaults without gnome?
<alazare619> or am i just going to go the route of livecd-rootfs?
<pitti> not right now
<cjwatson> StevenK: Can you help me read https://oops.canonical.com/?oopsid=OOPS-010486e682dfae5a2594aa81edcedc98 ?  I assume times are in ms - does the fact that there's nothing going on >142ms, and not even any repeated statement occupying >156ms, mean that this is death-by-a-thousand-cuts?
<cjwatson> It would help if there were fewer blank lines :P
<lifeless> cjwatson: they aren't blanks
<lifeless> cjwatson: scroll to the right
<cjwatson> Oh, not blanks, insane indenting
<cjwatson> Right
<lifeless> backtraces
<cjwatson> Not quite sure why they're so ridiculously far over.
<lifeless> one of the queries has pushed the column width out
<lifeless> anyhow
<lifeless> key things:
<lifeless> Statement Count: 518
<lifeless> ^ thats way too many
<lifeless> min time is 1-2ms for a query
<lifeless> you need to aim for 15-20, and accept up to 50
<lifeless> if you click on repeated querys
<lifeless> and scroll far left
<lifeless> you see:
<lifeless> 34 reps of
<lifeless> SELECT Person.account,
<lifeless>        Person.creation_comment,
<lifeless>        Person.creation_rationale,
<lifeless> ..
<lifeless> 32 of bugsubscription lookups
<lifeless> 21 of sourcepackage id lookups
<lifeless> cjwatson: is +upload doing email notifications ?
<lifeless> cjwatson: oh, I see
<lifeless> this has been thoroughly analyzed already
<lifeless> bug 745799
<ubottu> Launchpad bug 745799 in Launchpad itself "DistroSeries:+queue Timeout accepting packages (bug structural subscriptions)" [Critical,Triaged] https://launchpad.net/bugs/745799
<lifeless> https://bugs.launchpad.net/launchpad-project/+bugs?field.tag=timeout and look for queue ;)
<StevenK> And then sob quietly
<alazare619> is there a livecd-rootfs irc?
<cjwatson> lifeless: So I would love pointers to general strategies for fixing this kind of thing within LP.  Is bulk-loading an appropriate hammer for this kind of nail?
<cjwatson> (Assuming for a moment that this is fixable without going async)
<lifeless> so, there are a few strategies
<lifeless> first is to look for places that aren't bulk loading already and do so
<lifeless> there is a person helper, for instance
<lifeless> however, all the bug helper code is notify-per-bug
<lifeless> so a loop on bug will be bulk loading internally but not globally.
<lifeless> you basically need to drive the cost of notifying a bug down to (say) 10ms.
<lifeless> which my proposed notification service would do
<cjwatson> StevenK suggested a BugSet method for that, so that we can bulk-load things for a set of jobs without having to have Soyuz code know about the bugs DB - right?
<lifeless> alternative, go async.
<lifeless> soyuz code is allowed to know about bugs stuff
<lifeless> its in the same DB
<xclaesse> after today's Quantal upgrade, evolution is showing lots of black areas :(
<lifeless> the different 'apps' aren't.
<cjwatson> Well, yes, but it's not necessarily elegant for it to do so :)
<lifeless> There are horrible contortions in place to avoid direct use of facilities in other modules. this is an antipattern.
<lifeless> it evolved due to siloed teams.
<lifeless> Long term we want a bunch of small elegant services
<lifeless> some of which will be domain specific
<lifeless> many others will be task specific but generic and cross domains
<cjwatson> Sure, but I don't think having soyuz/scripts/processaccepted.py manually reimplement bug notification in order to get global bulk loading is going to be nice
<lifeless> indeed, I wouldn't do that.
<cjwatson> That seems like something future developers would swear at
<lifeless> The problem here as I see is that you have N different notifications
<lifeless> not that global bulk loading is mising
<lifeless> you can either decide that you want one notification to N bugs.
<cjwatson> Well, N bugs are being closed in the same way
<lifeless> or go async (through a few different strategies)
<lifeless> N bugs on M packages :)
<cjwatson> This is accepting one package - M=1
<cjwatson> The notifications at present are only different in their subject line; the message chunks are identical
<chu> .28
<lifeless> the cheapest thing to develop would be async
<lifeless> I suspect.
<cjwatson> I can see where your suspicion arises.  Due to the (I think) inevitable UI warts of asynchrony, I'd like to spend a little time seeing if the cost of the synchronous approach can be brought down first
<lifeless> be my guest :)
<cjwatson> It's not like being faster will ultimately go to waste, since an async approach would probably involve some of the same code
<lifeless> note that one of the async strategies is to implement out of band notifications only
<lifeless> bug notifications are *already* that most of the time
<lifeless> so implementing a mechanism where only transient data is captured and spooled
<lifeless> would have a big payoff and no noticable UI difference.
<lifeless> an example of transient data being the assignee if its being *unset*
<cjwatson> Sorry, I think I'm failing to understand that
<lifeless> say you have a private bug
<lifeless> and you unassign and remove grants from the assignee so they can't see it anymore.
<lifeless> We would normally notify them that they are not the assignee anymore.
<lifeless> today, we capture *all* the recipients to a Job, and the Job just does some minor processing and per-recipient customisation.
<lifeless> If you don't capture all the recipients to the Job, the person being unassigned and ungranted would not be found when the Job scans for recipients.
<lifeless> So you need to capture data which is sensitive to the async processing, and merge it with the observed data when the Job runs.
<cjwatson> What I'm saying is that converting the core "do we accept or not" logic to a Job *at all* results in problematic UI; I care less about whether the notifications happen immediately
<cjwatson> The actual acceptance itself is relatively fast
<cjwatson> Maybe more queries involved in creating builds than is strictly ideal, but it's dwarfed by the notification time
<lifeless> cjwatson: I'm not suggesting that the core logic moves to a Job
<cjwatson> So if we were making anything async, it would be "please get round to closing these bugs when you have a minute"
<lifeless> cjwatson: I'm talking about the needed machinery to move all the heavy lifting of notifications to a Job
<lifeless> or yes, you could slice it there too
<lifeless> I'm all for making the existing code more efficient though :)
<cjwatson> IOW one strategy for this is to have a domain-specific job rather than trying to tackle the general notifications problem immediately - basically just moving close_bugs_for_sourcepackagerelease out
<lifeless> yah
<cjwatson> I think we could help a fair bit if we discarded the (implicit) requirement that the closure message for each bug have a "Re: <bug title>" subject, and just made it "Fixed by <name> <version>" or similar
<lifeless> thats not where the overhead is going
<cjwatson> Then we could create a single message and link it to every bug; and then it's a "bulk setStatus+newMessage"
<cjwatson> er linkMessage
<lifeless> its determining who to send to
<lifeless> its not sending the messages inline
<lifeless> thats already async
<lifeless> the late evaluation that is killing you is person and subscription loading, per-bug.
<lifeless> I have to run, sorry.
<lifeless> feel free to mail me and demand more rationale and detailed bits
<lifeless> after you've had a poke around
<cjwatson> OK, thanks
<cjwatson> quantal now open again
 * pitti looks at the weird ubuntu-drivers-common FTBFS, WTH? regression from last night's python3.2 upload?
<pitti> indeed, after dist-upgrading I now get this locally
<pitti> dear python, if you would at least be so kind to tell me which file you suddenly don't like any more
<didrocks> I'm afraid your good to add some print on your system :/
<pitti> why would copy_scripts() call detect_encoding()?
<pitti> ah, this now fails to copy an ELF file
<pitti> didrocks: filed as bug 1026016
<ubottu> Launchpad bug 1026016 in python3.2 (Ubuntu) "3.2.3-3 regression: copy_scripts crashes with UnicodeDecodeError" [Undecided,New] https://launchpad.net/bugs/1026016
 * pitti changes setup.py to work around this
<didrocks> pitti: thanks :)
<jamespage> is there a standard suffix that should be used with an upstream version number if a orig.tar.gz needs to be re-created due to over-zealous purging of files?
<jamespage> like +dfsg but the other way round - I was going to go for +repack
<OdyX> no standard afaik. but +repack is used here and there (see usb-modeswitch e.g.)
<arand> jamespage: +ds (debian source) is also used sometimes, I've never heard of +us though...
<cjwatson> I thought +ds was conventionally for tarball-in-tarball packaging
<cjwatson> (which is mostly obsolete now)
<OdyX> (or really should be obsolete)
<arand> I think it can be used for both, and I've seen tarball-in-tarballs that doesn't have that siffix...
<jamespage> think I'll go with +repack then
<cjwatson> arand: oh, yeah, anything can be used for anything :)  I was just speaking of usual convention.  +ds IME was used when people were converting straightforward-tarball packaging into tarball-in-tarball without an upstream version bump.
<Sweetsha1k> jamespage: ping?
<Sweetsha1k> jamespage: If you want you have the new LO in main, can you help with this MIR galore needed by the (reenabled) reportbuilder: http://pastebin.ubuntu.com/1097967/
<Sweetsha1k> jamespage: that would be swell
<hrw> does someone had situation when Chromium browser stopped accepting keyboard input? other apps take it fine, chromium is acceptint only mouse
<jamespage> Sweetsha1k, oh my - http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
<jamespage> maven explosion....
<Sweetsha1k> yikes.
<Sweetsha1k> can that be demavenfied?
<seb128> lol
<seb128> nice graph
<seb128> where nice is in fact "crazy"
<jamespage> Sweetsha1k, yes - we need to look at libbtm-java
<Sweetsha1k> I can disable this for this upload, but if we dont get reportbuilder back in main on quantal, the guys of bug 992232 are already grepping for their forks and torches ....
<ubottu> Launchpad bug 992232 in libreoffice (Ubuntu) "no libreoffice-report-builder in precise" [Undecided,Fix released] https://launchpad.net/bugs/992232
<jamespage> Sweetsha1k, either disable its testsuite or build objenesis with maven-ant-helper
<jamespage> but there are still 17 additional pkgs for MIR....
<jamespage> Sweetsha1k, I can help but not today - have to get something finished this morning and I'm on pilot duty this afternoon (allready postponed once...)
<cjwatson> OMG.  Well done to whatever it was for managing to render that remotely coherently
<cjwatson> I've never seen component-mismatches.svg need to render upward-pointing arrows before
 * pitti could hear graphviz' gears scream
<pitti> "Build-Depends: universe"
<tumbleweed> "Build-Depends: ${reverse-dependencies}"
<Sweetsha1k> jamespage: since you already isolated the 17 MIR that are still needed, could you drop them here? I would need to file one bug for each (or can we have one bug affecting multiple pkgs for this)?
<pitti> Sweetsha1k: you can do some grouping, especially for packages that are closely related
<pitti> but perhaps not just one bug with 17 tasks, that's too hard to track for MIR review
<pitti> perhaps "5 trivial java libs" in one bug, another one for a different kind of package, etc.
<cjwatson> Also Launchpad doesn't really deal particularly well with bugs with enormous numbers of tasks
<Sweetsha1k> pitti: <grumpie-old-man-voice>for me they are all in the java crap required by reportbuilder group</>
<pitti> heh
<pitti> Sweetsha1k: it seems this is coming up over and over again -- does the disabling of reportbuilder keeps getting accidentally reverted, or is that another deliberate attempt to enalbe it again?
<Sweetsha1k> pitti, cjwatson: I will go the 5 pkg per bug suggestion ... note that most of these MIR shouldnt be to heavy discussed.
<Sweetsha1k> pitti: reportbuilder was disabling in early in precise because of the maven-include-all-universeness of it and not reenabled for timing restraints. Some of the maveness is gone, but it seems some is still left.
<Sweetsha1k> s/it/its deps/
<mpt> Is there a way to upgrade from 12.04 to Q for testing without using update-manager? The update-manager -d method crashed (bug 1026068)
<ubottu> Launchpad bug 1026068 in update-manager (Ubuntu) "Quantal Crashes as upgrade starts" [Undecided,New] https://launchpad.net/bugs/1026068
<jamespage> Sweetsha1k, sorry - have my head in unpicking minified javascript from a new package - did not want to lose my place!
<brendand> mpt - sed /precise/quantal/ in sources.list and apt-get update/upgrade :/
<brendand> mpt, probably dodgy
<mpt> brendand, yeah, that misses out on the special upgrade scripts
<cjwatson> Not much in the way of quirks for quantal anyway
<mpt> ok, we'll do that then, thanks
<mpt> (For the benefit of anyone reading the logs later, the proper terminal way is apparently "sudo do-release-upgrade -d")
<Sweetsha1k> seb128: building 3.6.0~rc2 without reportbuilder right now. (yes, rc2 -- hopefully nothing too bad happened since rc1)
<seb128> Sweetsha1k, great
<Sweetsha1k> every time i am annoyed by lp being slow or timing out, I remember myself about the great mass of obsolete junk(https://launchpad.net/obsolete-junk) in it ...
<pitti> Sweetsha1k: WTH..
<Sweetsha1k> pitti: explains quite a bit, doesnt it ;)
<Sweetsha1k> pitti: I think we are including that project in LibreOffice too though, I guess. However, it is called binfilter at LibreOffice.
<pitti> haha
<seb128> cjwatson, hey, bash-completion needs to be merged with Debian, do you plan to do it (asking because it has your name next to it on merges.u.c) or would you welcome somebody else doing it?
<seb128> cjwatson, "needs to" is because the new version uses /usr rather than /etc for completion snippets and some GNOME packages (e.g glib) started to install to the new location, which doesn't work on quantal with our outdated version
<cjwatson> I've been failing to get round to that and would welcome somebody else doing it
<seb128> cjwatson, ok, I will do it, thanks
<cjwatson> Thanks
<killown> ubuntu developers can you fix this https://bugs.launchpad.net/ubuntu/+source/wine1.4/+bug/944321/comments/21
<ubottu> Launchpad bug 944321 in wine1.4 (Ubuntu) "apt-get build-dep script for wine missing xorg and " [Undecided,Confirmed]
<pitti> ev: followed up to your apport MP
<jamespage> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jamespage
<ev> thanks, looking into it now
<rbasak> cyphermox: could I have your comment on bug 1024408 please?
<ubottu> Launchpad bug 1024408 in ubuntu-meta (Ubuntu) "Quantal installs do not include software-properties-common by default" [Undecided,Confirmed] https://launchpad.net/bugs/1024408
<cyphermox> rbasak: yeah, it didn't come default
<rbasak> cyphermox: is there any other bug here apart from that it isn't default?
<cyphermox> but Javier is correct, there is a missing depends on python3-software-properties
<rbasak> cyphermox: wouldn't the dependency be the other way round? Usually other packages depend on the -common package
<cyphermox> python3-software-properties doesn't currently depend on it, and afaik doesn't need it for anything
<cyphermox> OTOH, software-properties-common needs some of the python libraries in python3-sotware-properties for add-apt-repository to work properly
<rbasak> I see, OK. So the bug is entirely valid.
<cyphermox> yes
<rbasak> (and in addition, if I want -common in the server seed, I should open another bug on that)
<cyphermox> yeah
<cyphermox> I can fix the depends now
<rbasak> OK, thanks! I guess it's not worth me doing a debdiff only for you to sponsor it :)
<cyphermox> well, nm, it's already there
<rbasak> Oh. So it is
<pitti> bdmurray: ah, I was about to upload apport 2.0.1-0ubuntu12 to precise-proposed when I saw that you already uploaded one
<pitti> bdmurray: can you please commit stuff to the bzr branch, so that we avoid stepping on each other's toes? thanks!
<pitti> bdmurray: I'll merge your upload there
<pitti> bdmurray: done, and reuploaded
<pitti> ev: do you still need https://code.launchpad.net/~ev/apport/native-package-field/+merge/115542 then?
<ev> ah no, deleting now
<pitti> ev: or is the existing tag sufficient?
<pitti> ev: ah, ok; I really appreciate that you discussed in a MP first, thanks!
<ev> sure thing - always best to check with these things, minor as they may initially seem
<tkamppeter> Anyone around who can help me on getting syncpackage working?
<tkamppeter> It gives a Python Backtrace with gnomekeyring.IOError
<tumbleweed> tkamppeter: see the entry for 0.199 in /usr/share/doc/ubuntu-dev-tools/NEWS.Debian.gz
<cjwatson> tkamppeter: 0.119
<cjwatson> err
<cjwatson> tumbleweed: 0.119
<tumbleweed> yes, that
<tkamppeter> tumbleweed, thanks, but it does not work for me. I am not SSHed in, but simply in a terminal window in both Precise and Quantal cases. Doing "export `dbus-launch`" anyway does not help, uninstalling python-gnomekeyring does not work as system-config-printer needs it.
<tumbleweed> tkamppeter: a normal gnome session?
<tumbleweed> does gnome keyring work for other things?
<tkamppeter> tumbleweed, a Unity session.
<tumbleweed> erm, yes that :)
<tkamppeter> tumbleweed, what else uses gnome-keyring, how can I quickly test?
<tumbleweed> network manager
<tkamppeter> tumbleweed, what works in both cases is apport-collect, but I am not sure whether it uses gnome-keyring (pitti?).
<pitti> launchpadlib does
<tkamppeter> tumbleweed, I have internet access on both machines (wired) and the Precise also wireless, this should come from network-manager or do I need to test something else?
<tkamppeter> pitti, so this means that gnome-keyrinmg works for me as I have apport-collected for both systems in bug 1026146.
<ubottu> Launchpad bug 1026146 in ubuntu-dev-tools (Ubuntu) "syncpackage gives Python traceback on gnomekeyring.IOError" [Undecided,New] https://launchpad.net/bugs/1026146
<tkamppeter> tumbleweed, I have reported bug 1026146 for the syncpackage problem.
<tumbleweed> if you fire up seahorse, can you see the contents of your keyring?
<agoradf> helo ther are som one spech italian?
<tkamppeter> tumbleweed, I have 2 PGP keys and 2 SSH keys, one of tne PGP keys I use also for dput. One SSH key is to log in on remote servers and another one to commit to Fedora repos.
<ogra_> agoradf, i think there is an #ubuntu-it channel
<agoradf> yes but have 0 user ok tanks
<tkamppeter> tumbleweed, seahorse, though it seems to work, writes the following on the console where I started it:
<tkamppeter> Gkr-Message: secret service operation failed: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
<tumbleweed> same thing we see from launchpadlib
<tumbleweed> sounds very much like you don't have a running gnome-keyring-d
<tumbleweed> *daemon
<tkamppeter> tumbleweed, this was on Quantal, on Precise I have seahorse not displaying my keys and in addition a
<tkamppeter> ** Message: failed to refresh: Couldn't communicate with key ring daemon
<tumbleweed> sounds like the same problem
<tkamppeter> tumbleweed, I have started gnome-keyring-daemon manually on Precise and now syncpackage and seahorse work.
<tumbleweed> it should start at login. Don't know why it isn't
 * tumbleweed disclaims all knowledge of the desktop
<tkamppeter> tumbleweed, same on Quantal, whereas seahorse already worked before, but now it shows more keys/passwords.
<tkamppeter> tumbleweed, thanks. I will add a comment to the bug report.
<davmor2> kenvandine: Hey dude, just thought I'd give you a quick headsup the updated empathy in Quantals call/ dial into conference feature is working, so it is just a precise issue :)
<davmor2> kenvandine: also I've written a bug for the app in Quantal the dial pad button is missing an icon, other than that it seem way better :)
<tkamppeter> Any Perl expert around? How do I determine whether File::Temp is in perl-base or whether it requires full perl?
<mdeslaur> tkamppeter: it's not, it's in perl-modules
<kenvandine> davmor2, thx
<mdeslaur> tkamppeter: just look at the package contents: /usr/share/perl/5.14.2/File/Temp.pm
<tkamppeter> mdeslaur, so it needs perl-base, perl, and perl-modules?
<mdeslaur> tkamppeter: just 'perl' should be sufficient to pull perl-modules in
<mdeslaur> but 'perl-base' isn't
<cjwatson> Yeah, you should not normally depend on perl-modules directly; depend on perl if you need something in there
<cjwatson> Be careful not to rely on perl/perl-modules for anything that might run with perl unconfigured during upgrades though (particularly anything run from a dpkg trigger); in such cases you may need to add code to fall back to calling tempfile or mktemp or similar
<mdeslaur> also, we don't have perl-modules on the desktop cd, so don't rely on that for stuff that needs to ship on it
<tkamppeter> mdeslaur, cjwatson, thank you very much.
<killown> also apt-get install build-essential:i386 is broken on 64bits
<diwic> Either xargs is broken, or I'm completely stupid. If I do ' ls | xargs echo "Hi " ', that should say "Hi Documents", "Hi Downloads" etc, right?
<diwic> I get "Hi Documents Downloads"...
<ion> Thatâs exactly how it is supposed to behave.
<micahg> diwic: ls | xargs --I{}  echo "Hi " {}
<micahg> diwic: -I, not --I
<cjwatson> diwic: or  xargs -n1
<diwic> micahg, cjwatson, ion thanks all and sorry for asking a support question in the wrong channel
<diwic> xargs -n1 seems indeed the simplest option
<stgraber> Laney: did you file/find a bug for that hang on shutdown/reboot of containers?
<stgraber> Laney: I started seeing it on my quantal machines here so I'm going to make sure it's properly escalated and fixed ASAP as it's likely to affect quite a bit more than just lxc
<jamespage> is there any general coordination around gcc updates?  there is a sensible MP for gcc-4.7 in the sponsorship queue but I see that doko appears to be the sole changelog author for as far back as I can see....
<ogra_> jamespage, doko maintains it in debian as well ...
<ogra_> while teher is coordination (and likely even other occasional uploaders) he is definitely the central person for it
<jamespage> ogra_, any idea where he is?  I've not seem him since last week on irc
<ogra_> vacation
<ogra_> and debconf before
<jamespage> ogra_, thats what I thought
<ogra_> probably infinity can help you if you ask nicely :)
<jamespage> ogra_, I think I'll leave it until doko is back - it looks like the transition needs to happen for most core tooling
<jamespage> insanely its for ia64 architectures only AFAICT
<ogra_> that still exists ?
<jamespage> anyway
<jamespage> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<jamespage> ogra_, it does in Debian - unless that is actually a false positive in the NBS report and can be ignored.
<ogra_> ah, debian, yeah ...
<infinity> jamespage: Which MP is this?
<infinity> jamespage: I'm playing fake doko while he's on vacation.
<ogra_> infinity, including the limping ?
<infinity> ogra_: He's stopped doing that.
<ogra_> ah
<psivaa> rbasak, i have added a comment on bug 1024408 to the effect the original bug is not still fixed
<ubottu> Launchpad bug 1024408 in software-properties (Ubuntu) "Quantal installs do not include software-properties-common by default" [Undecided,Confirmed] https://launchpad.net/bugs/1024408
<rbasak> psivaa: the "not in server seed" bug is bug 439566. add-apt-repository has never been pulled in by the server seed
<ubottu> Launchpad bug 439566 in ubuntu-meta (Ubuntu) "add python-software-properties to ubuntu-standard" [Wishlist,Triaged] https://launchpad.net/bugs/439566
<psivaa> rbasak, this is not about apt-add-repository it was about software-properties-common
<micahg> rbasak: it could be seeded directly in the server seed if it doesn't need to be in standard
<rbasak> micahg: I think it should be in standard. Lots of places use it. Eg. on an LP PPA page, the instructions are to use it.
<rbasak> micahg: on desktop it happens to be installed, but this may not necessarily be the case in future. I think we should seed it directly
<rbasak> psivaa: why should software-properties-common be in the server seed?
<micahg> rbasak: a server without network services wouldn't need it
<rbasak> micahg: so your vote is against add-apt-repository being in a default server install?
<micahg> err...I mean internet access ;)
<micahg> rbasak: no, I'm against it being in standard
<psivaa> rbasak, shouldn't it? i think pitti thought it should and i think you have commented in this bug "I'll open a separate bug to add software-properties-common to the server seed."
<rbasak> psivaa: add-apt-respository is inside software-properties-common
<micahg> rbasak: here's the definition of standard: https://wiki.ubuntu.com/SeedManagement#Standard
<rbasak> psivaa: to add add-apt-repository to a default server install, it must be added to some seed
<rbasak> micahg: "a variety of networking clients and tools"
<psivaa> rbasak,  yes but as i said this is not about apt-add-repository its about software-properties-common not being in the server seed
<rbasak> micahg: It's a stretch, but I think that makes add-apt-repository fair game
<rbasak> psivaa: so why should software-properties-common be in a server seed?
<psivaa> rbasak, shouldn't it? i think pitti thought it should and i think you have commented in this bug "I'll open a separate bug to add software-properties-common to the server seed."
<rbasak> psivaa: the reason I say it should is for add-apt-repository, and this is bug 439566
<ubottu> Launchpad bug 439566 in ubuntu-meta (Ubuntu) "add python-software-properties to ubuntu-standard" [Wishlist,Triaged] https://launchpad.net/bugs/439566
<rbasak> psivaa: you identified a separate dependency problem which has since been fixed
<rbasak> psivaa: there are two issues identified here, and there are two bugs
<micahg> rbasak: hrm, it can be used for local repos as well, so I guess it would be ok
<psivaa> rbasak, yes the dependency issue is fixed but that was not the original intention of the bug
<rbasak> psivaa: never mind what anyone else said. You reported this bug. Why did you report it? What do you want? What's the justification for what you want?
<rbasak> micahg: ok, thanks
<micahg> rbasak: you'll want to check the dependency chain though to make sure that it doesn't bloat standard
<rbasak> micahg: I'll update bug 439556 and submit a MP
<ubottu> Error: Launchpad bug 439556 could not be found
<rbasak> micahg: sure
<rbasak> bug 439566
<ubottu> Launchpad bug 439566 in ubuntu-meta (Ubuntu) "add python-software-properties to ubuntu-standard" [Wishlist,Triaged] https://launchpad.net/bugs/439566
<micahg> rbasak: and definitely a recommends, not a depends
<rbasak> psivaa: if the original intention of your bug is to have add-apt-repository by default, then you have a dupe of 439566. If it is for some other reason, then please say why
<rbasak> micahg: ack
<psivaa> rbasak, well, no one can have a definite reason for any package to be included in the default install, i agreed with pitti that *software-properties-common* should be included in the server seed
<rbasak> pitti: did you want software-properties-common seeded for add-apt-repository or something else?
<rbasak> psivaa: OK, I'll mark your bug as a dupe of 439566.
<psivaa> rbasak, ok go ahead, ill need to talk to pitti about that too and see if we need a separate bug for that
<rbasak> psivaa: hold on a moment
<rbasak> psivaa: do you realise that add-apt-repository is now *in* software-properties-common?
<rbasak> psivaa: sorry I should have mentioned that
<psivaa> rbasak, yes that i realise
<rbasak> To resolve 439566, which is really about adding add-apt-repository by default, I'll be seeding software-properties-common
<rbasak> So why do you want another bug?
<psivaa> rbasak, do you have a bug to seed software-properties-common
<rbasak> psivaa: it's 439566. I haven't changed the subject line
<rbasak> I'll do that now
<psivaa> rbasak, the bug i raised is for that
<rbasak> psivaa: so you have a dupe of bug 439566 then (which I've just renamed)
<psivaa> rbasak, the bug 102448 is i thought for the seeding of software-properties-common
<ubottu> Launchpad bug 439566 in ubuntu-meta (Ubuntu) "add software-properties-common to ubuntu-standard" [Wishlist,Triaged] https://launchpad.net/bugs/439566
<ubottu> Launchpad bug 102448 in Ubuntu "Netgear wpn511 does not activate properly" [Undecided,Fix released] https://launchpad.net/bugs/102448
<psivaa> rbasak, ok now i see
<psivaa> rbasak, I agree to mark 1024408 dupe now
<rbasak> psivaa: cool, thanks. Sorry, I could have communicated what I was trying to say better.
<psivaa> rbasak,  that's ok :) me being (kind of) new did not help either :)
<alazare619> hey im having a issue
<alazare619> with livecd-rootfs i have package live set to ubiquity-frontend-kde
<alazare619> how do i call it?
<cjwatson> Call what?
<alazare619> ubiquit-frontend-kde
<cjwatson> You mean when you're building the image, or when you boot the live image?
<alazare619> both
<alazare619> iso-hybrid image
<alazare619> when it boots it wont post to ubiquity
<cjwatson> Sorry, I'm really having trouble making sense of this question
<alazare619> ok, i built a image all the way through with livecd-rootfs
<alazare619> but when i go to load the image
<cjwatson> You can run just the "ubiquity" command to start the installere
<cjwatson> *installer
<alazare619> it wont default to ubiquity-installer-kde
<alazare619> should ubiquity-installer be put into chroot?
<alazare619> or binary?
<cjwatson> Uh, neither really.  "add_package live ubiquity-frontend-kde"
<cjwatson> It should end up in the squashfs
<cjwatson> What the image boots into is controlled by kernel parameters
<SpamapS> bryceh: http://launchpadlibrarian.net/109793324/mesa_8.0.2-0ubuntu3.1_8.0.3-0ubuntu0.1.diff.gz .. did you accidentally base your SRU upload to precise-proposed off quantal instead of precise-updates ?
<alazare619> cjwatson,  ok is there a ubiquity that doesnt use just kde or gtk libs
<alazare619> like is there a way to incorp a alternate installer?
<cjwatson> Those are two quite different questions.
<cjwatson> There is a text frontend for ubiquity, but it's not desperately well used or tested.
<cjwatson> (ubiquity-frontend-debconf)
<alazare619> ok what about using the alternate installer method
<alazare619> that is offered for say xubuntu etc
<alazare619> the "debian based" installer
<cjwatson> Alternate installers aren't built using live-build.
<alazare619> i understand that
<alazare619> other then that is there a ubiquity that doesnt depend on kde or gtk im trying to build a iso with only qt apps
<cjwatson> You can do it with our cdimage branch plus debian-cd; the entry point is bin/cron.daily.  Considerable setup required.  It needs a full local mirror.
<cjwatson> The "KDE" ubiquity frontend doesn't use that much of KDE.
<bryceh> Spads, nope
<cjwatson> It's just kdecore and kdeui.
<bryceh> SpamapS, nope, all the changes which were on the precise-updates tree are cherrypicks from 8.0.3
<cjwatson> And if a patch to make it pure Qt weren't too unreasonable, we'd probably take it.
<alazare619> ok and last question i have before i dive back into this is what would be needed to use livecd-rootfs /live-build with a ppa
<SpamapS> bryceh: its rather confusing to have a published version disappear from the changelog though.
<bryceh> SpamapS, well, all being "one"
<cjwatson> alazare619: You could crib the add_ppa function from ubuntu-defaults-image.
<alazare619> i added a file with somerepo.list.chroot to archives (with the repo deb http://whatever) and somerepo.key.chroot with its signing key but its not picking it up
<SpamapS> bryceh: consider the case where somebody has 8.0.2-0ubuntu3.1 and wants to see what changed since then
<cjwatson> If that doesn't work you'll have to debug it locally, I expect.
<SpamapS> bryceh: I'm not saying its wrong, but I've not ever seen it done, nor do I feel comfortable with it.
<cjwatson> Maybe turn on shell tracing (set -x) in /usr/share/live/build/scripts/build/lb_chroot_archives and see what it thinks it's doing.
<bryceh> SpamapS, so it would make you feel better if I s/(8.0.2-0ubuntu4) quantal/(8.0.2-0ubuntu3.1) precise-proposed/ ?
<SpamapS> bryceh: actually yes, that would be perfect. :)
<alazare619> cjwatson, i discovered i could do a hook its dirty bbut works for apt-get install python-software-properties then add the ppa at the end and pull the package i want from it
<alazare619> is there any way to sort the order hooks run in?
<bryceh> SpamapS, on bug #1013881 I don't think you should be blocking it.  The change is to remove a patch which failed SRU, so really it's irrelevant what the status of it is in quantal.  The patch can't be backported because it causes breakage, thus should be dropped.
<ubottu> Launchpad bug 1013881 in xkeyboard-config (Ubuntu) "Right-Ctrl key broken on French OSS keyboard" [High,In progress] https://launchpad.net/bugs/1013881
<alazare619> if i name the hook file name 001_somename.sh and 002_somename.sh will 001 run before 002?
<SpamapS> bryceh: not sure what you mean. It can't be fixed in quantal? Wouldn't that be 'Invalid' or 'Won't Fix' then, not 'In Progress' ?
<SpamapS> bryceh: the point is just to make sure the issue is handled in the dev release.. not that it is directly backported.
<SpamapS> bryceh: I can of course waive that need if there's something preventing the fix from landing in quantal
<SpamapS> like "I'm really busy and I promise I'll do it before October"
<slangasek> barry: ah, thanks for the quick turnaround on the apturl bug-
<SpamapS> anyway, time for a quick wrist break
<slangasek> SpamapS: so I've just followed up on that bug report.  1013881 was a report *against* a previous precise-proposed version of the package; the patch in question has been backed out of the SRU as a result of this bug report; quantal should not hold up the SRU for this bug
<slangasek> because in effect, that bug is already "fix released" in precise
<slangasek> by virtue of the SRU itself
<bryceh> SpamapS, let me rephrase.  A fix from quantal was backported to precise, and proposed as an SRU.  The SRU failed verification, thus it should not be present in precise.  However it was accidentally uploaded to precise anyway.  I'm saying it should be removed from precise, regardless of its status in quantal.
<bryceh> SpamapS, what to do in quantal is still sort of up to various upstream discussions that are still on-going.
<cjwatson> alazare619: They're run in shell pattern expansion order, so yes, 001 will come before 002.
<cjwatson> Or just alphabetical order if you like.
<alazare619> alpha-numerical order
<alazare619> yea
<bryceh> SpamapS, mesa_8.0.3-0ubuntu0.1_source.changes uploaded with resync'd changelog
<cjwatson> Technically the order probably depends on the locale.  LC_COLLATE=C if you care.
<barry> slangasek: no worries.  an api got changed incompatibly out from underneath it
<SpamapS> bryceh: AHH ok so the bug is to remove it, so quantal is irrelevant. Got it. I have to run but I'll review your mesa upload again and take a second look at xkb when I get back
<slangasek> SpamapS: fwiw I'm surprised this issue is coming up at -updates promotion time, since the SRU procedure says that's all supposed to be sorted before accepting into -proposed
<slangasek> (and in this case it was, it just wasn't obvious how)
<slangasek> SpamapS: I'm satisfied that xkeyboard-config is correct, I'll just promote it now and save you any further trouble :)
<dobey> when was C.UTF-8 enabled as a locale in Ubuntu?
<bryceh> slangasek, thanks
<slangasek> n/p
<mterry> SpamapS, ping about gem2deb MIR
<mterry> SpamapS, any ideas about the circular dependency with ruby-rspec?
<dobey> anyone know about C.UTF-8 locale at all?
<sladen> dobey: I don't.  Was it perhaps a machine in "C", with the actions of a script doing  sed -e s/.*/.UTF-8/  during the script in ~2005  (IIRC 4.10 was not UTF-8)
<dobey> sladen: afaict, 10.04 and 11.04 don't have C.UTF-8 either
<sladen> dobey: or is the question when the default was switched?  (from iso8859-15 -> UTF-8, which IIRC was 5.04)
<dobey> sladen: the default for C was never iso8859-15 afaik. it would have been us-ascii before
<sladen> dobey: either way, pitti appears in the changelogs.  pitti: ^^   ?
<bdmurray> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: bdmurray
<dobey> or well, not us-ascii exactly i guess
<dobey>  LC_ALL=C python -c "import sys; print sys.getfilesystemencoding()"
<dobey> ANSI_X3.4-1968
<infinity> dobey: C.UTF-8 showed up in precise.
<infinity> dobey: Well, it might have showed up earlier (I'd have to check changelogs), but it didn't work correctly until precise. :P
<dobey> ah
<infinity> dobey: Which reminds me, I need to petition for us to switch the default system locale some day.  That'll be a heated and fun discussion.
<dobey> well i think it works in oneiric
<infinity> dobey: FSVO "works".  It's not correct.
<infinity> Though, I suppose it mostly behaves.
<infinity> dobey: Were you actually hoping to rely on it in some fashion, or just exercising curiosity?
<dobey> also, it seems pretty obvious that "tlh" should be the default. no reason there needs to be a heated discussion about that.
<infinity> Real nerds don't speak tlh, they just make fun of those who do.
<dobey> infinity: i need UTF-8, and I thought C.UTF-8 was working on everything I am required to care about; but as it's not the case I guess I'll just switch to using en_US.UTF-8 for the places where I need to tweak
<dobey> infinity: exactly (sarcasm isn't easily visible via IRC). :)
<infinity> dobey: From precise on, C.UTF-8 should be fairly sane.  It *might* be sane for oneiric, depending on what you need.
<infinity> dobey: Where it fails sanity in oneiric might be in collation of characters over 255, and a few other odd corner cases, which you might not give a crap about.
<dobey> mostly i just need the UTF-8 part, because ANSI_X3.4-1968 == insanity
<dobey> yeah i probably don't care about those corner cases. but i do have to care about lucid for another 9 months
<SpamapS> hm, seems diffs linked to from +queue are getting the wrong host: 'lplibrarian-private-download.internal:8000'
<infinity> SpamapS: Known bug.
<SpamapS> ah ok
<SpamapS> kind of kills my ability to efficiently do SRU reviews for the day though. :-(
<infinity> Yeah, I was just fetching sources and diffing old skool.
<SpamapS> infinity: known "omg we have to fix this now" bug, or "when we get to it" ?
<infinity> You could also try a DC host that has access to that URL.
<infinity> Bug #1025515
<ubottu> Launchpad bug 1025515 in Launchpad itself "LP diffs are being linked at http://lplibrarian-private-download.internal:8000" [Critical,Fix committed] https://launchpad.net/bugs/1025515
<SpamapS> like people.c.c ?
<infinity> Possibly.
<SpamapS> cause diffing manually is pretty ridiculously painful ;)
<stgraber> I'm getting 403 from lillypilly
<infinity> SpamapS: Oh, and try to avoid the highbank-related SRUs.  I need to go over those with a fine-toothed comb.
<SpamapS> I wouldn't touch those anyway :)
<lifeless> SpamapS: infinity: that url bypasses acls, only LP hosts themselves have access to it
<SpamapS> yeah and without ssh -X'ing, its also not useful
<SpamapS> and I doubt any DC hosts have a decent browser :)
<SpamapS> trying to review SRU's w/ 5+ bugs is pretty ridiculous w/o queuediff
 * SpamapS will just shut it down until LP is fixed
<lifeless> SpamapS:  bug 1025515
<ubottu> Launchpad bug 1025515 in Launchpad itself "LP diffs are being linked at http://lplibrarian-private-download.internal:8000" [Critical,Fix committed] https://launchpad.net/bugs/1025515
<SpamapS> lifeless: yes I'm subscribed. Will return to SRU processing when that lands.
<infinity> Sweetshark: Uhm, build-conflicting against the default compiler (which libreoffice does on !x86) isn'ta terribly winning strategy.
<infinity> lifeless: Your bug link was about 20 lines too late.
<lifeless> infinity: doh
 * penguin42 wonders if libwebkitgtk-1.0's debug .so being 1.1GB is expected or actually a bug
<Laney> stgraber: bug 1021471
<ubottu> Launchpad bug 1021471 in linux (Ubuntu) "stuck on mutex_lock creating a new network namespace when starting a container" [Medium,Incomplete] https://launchpad.net/bugs/1021471
<stgraber> Laney: thanks
<Laney> I haven't been using it heavily enough recently to trigger it
<stgraber> I can reproduce it really easily here, so I'll try the scheduler change and see if I still get it
<Laney> how?
<Laney> after I reboot I can't repro on demand
<stgraber> lxc-start -n <container> => reboot in the container
<stgraber> happens 50% of the time here
<Laney> aha
 * Laney tries that
<stgraber> but the test machine is a slow atom single core, so that might explain why it's easy to reproduce here ;)
<Laney> nah, no good
<bdmurray> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<BenC> The build failure for libreoffice makes me unhappy
#ubuntu-devel 2012-07-19
<scientes> libreoffice is a beast
<scientes> why is libreoffice in universe in quantal?
<infinity> BenC: I might fix it later.
<stgraber> scientes: the libreoffice meta package seems to be in universe, the actual components (libreoffice-core, libreoffice-writer, ...) are in main
<phillw> BenC ping
<BenC> phillw: pong
<BenC> phillw: I think you're confusedâ¦supporting old Mac hardware is not a destiny that will lead to powerpc being around very long
<phillw> Hi BenC we have a rather stubborn bug, and ubuntu-release have suggested that you may be better placed to look at it?
<BenC> phillw: I'm trying to get kernel support for newer ppc32 architectures like e500mc
<BenC> phillw: I assume that was your comment on my blog post...
<BenC> phillw: Sure, what's up?
<phillw> nope, it was there to support the work that is done to continue supporting older kit, but that's a different matter
<phillw> bug 1007394
<ubottu> Launchpad bug 1007394 in mdadm (Ubuntu) "Quantal daily fails to complete installation" [High,Confirmed] https://launchpad.net/bugs/1007394
<BenC> phillw: I don't want to support older hardwareâ¦I want to support newer hardware :)
<BenC> phillw: Checking the bug (cooking dinner, so might be slow)
<phillw> thanks, it's a killer bug for alternate release.
<BenC> phillw: Does this happen on differing ppc platforms, or one specific machine?
<phillw> both of the ppc testers that lubuntu have have experienced it
<BenC> phillw: what is their hardware?
<BenC> G3, G4, ??
<phillw> I'm not 100% sure. apport didn't pull the information in.
<phillw> As they get desktop up okay, it shouldn't be too hard for them to provide the system data from their Macs onto that bug if it will help.
<phillw> it's only alternate that fails.
<BenC> Ok
<BenC> phillw: That's an odd bugâ¦mdadm doesn't hang on my quantal system...
<BenC> I'm not running the standard kernel though
<phillw> BenC it sure is, even more weird as one of the testers got the alternate install to install when selecting encryption!
<phillw> BenC, it is 3 am here & I've been up since 6 am. If there is anything more you want in terms of information, please do feel free to update the bug report :)
<BenC> phillw: ok
<pitti> Good morning
<NCommander> Ping, any archive admins around? I need a patch pushed from out of the proposed unaccepted queue
 * NCommander tackles pitti 
<pitti> rbasak: FWIW, I don't have a strong opinion whether add-apt-repository should be on the server images; so far it has been, so I was pointing out that in order to keep this, the seeds need to be changed to software-properties-common, as the script got moved there
<pitti> NCommander: you want SRU team members, not archive admins for that
<NCommander> pitti: it'sbeen awhile since Ididan SRU, but I thought it was from proposed->updates that need a SRU ack (and this is a bit ofa special case; this is the highbank hardware enablement. I can't properly test build d-i until the udebs are built)
<pitti> no, the SRU team reviews stuff in the -proposed queue
<pitti> well, they also promote verified packages to -updates, yes
<NCommander> crap
<NCommander> pitti: know any SRU team members awake atthi hour?
<pitti> RAOF should be
<pitti> probably infinity as well
 * RAOF is indeed awake
<NCommander> RAOF: infi	ping?
<pitti> I'm not sure whether they have a kind of roster these days, there was some talk about it
<RAOF> pitti: Yup, see https://wiki.ubuntu.com/StableReleaseUpdates#Publishing
<pitti> ah, there we go
<RAOF> NCommander: What's up, dawg? What do you need accepted?
<RAOF> *: actual acceptance gated on review.
<NCommander> RAOF: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1004018 - libdebaininstaller,base-installer,flash-kernel
<ubottu> Launchpad bug 1004018 in libdebian-installer (Ubuntu Precise) "Add highbank images" [High,In progress]
<NCommander> RAOF: hrm, seems one of the patches have fallen off the bug, I'll fish out the debdiffs if you need them individually
<RAOF> NCommander: If they're all in the queue then I'll grab them from theer.
<RAOF> We haven't actually reviewed debdiffs from bugs for as long as I've been in the SRU team :)
<NCommander> RAOF: they are, thanks for the look. These need to go into proposed so I can builda non-hacked up d-i and uload that,and all four must then progate to updates :-)
<NCommander> RAOF: I think the last time I SRU'ed something was in Dapper :-/
<RAOF> You'll need a real, live archive admin to do the acceptance; d-i requires manual fiddling with cocoplum access. (or did last time I checked)
<RAOF> NCommander: So, we hit the first question: *which* upload of flash-kernel in the precise-proposed unapproved queue should go in? :)
<NCommander> RAOF: d-i isn'tuploaded, these are its build-deps (d-i is a bit of a monster when we have to add new code)
 * NCommander looks atthequee
<RAOF> Ba baw.
<RAOF> Would you kindly upload a flash-installer that has both fixes in it? :)
 * NCommander hitshis head repeatively
<NCommander> Standby, downloadingand reviewing what the other fix is
<NCommander> hr
<RAOF> It's a fix for linaro kernels, apparently.
<NCommander> clickingthe difflink sends meto a.internalwesite
<NCommander> RAOF: I'll roll both together, but obviouslythen they havetobe ACK'ed together. I'msuprised LP allows multiples of the same package versions ina queue
<RAOF> Time to scream in #launchpad.
<NCommander> RAOF: easy enough tomerge, butIhave no way of testing this patch
<RAOF> I'm happy to assume that it does what the uploader says it does, after reviewing it for sanity.
<RAOF> They'll have to do the verification, obviously.
<RAOF> 12.04.1 is approaching; both these fixes seem reasonably easy to verify, so folding them into the same SRU should get both of them into precise-updates faster than splitting them up.
<NCommander> RAOF: merged together
<NCommander> RAOF: looks good from here,uploading, NACK the two existing uploads as soon as this pops in
<RAOF> Ta. I'll review that diff manually, then. Rejected both the previous ones.
<NCommander> RAOF: and uploaded
<NCommander> RAOF: got the pending email. I needtorunthe corner store, brb in 5
<RAOF> Thanks.
<StevenK> NCommander: In AK? Isn't it more like 35?
<NCommander> StevenK: depends where in AK you are
<RAOF> NCommander: That should be everything. While these diffs were all nice and trivial, please include the information requested in https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template in future âº
<TheMuso> ls
<TheMuso> whoops
<dupondje> https://launchpad.net/ubuntu/+source/libreoffice/1:3.6.0~rc2-0ubuntu1 seems to contain alot of spam changelog from ppa's.
<ScottK> dupondje: If the PPAs were used by a significant number of end users, I think that's not unreasonable.
<ScottK> (I don't do it that way, but I think it's not unreasonable)
<ScottK> and I think the LO PPA qualifies.
<Sweetsha1k> seb128: the i386 breaker is new to me. since the amd64 build succeeded I uploaded a 3.6.0~rc2-0ubuntu2 which disables running these kind of tests (subsequentchecks) an only do the basic tests so we get a i386 package in ASAP.
<seb128> Sweetsha1k, hey, thanks, on chinstrap as well?
<Sweetsha1k> on chinstrap. still building locally.
<cjwatson> RAOF: d-i no longer requires any such manual fiddling on cocoplum; in fact, there are no remaining packages that require that, since I got them all fixed recently
<cjwatson> RAOF: (and actually, it was never on accept that there was a problem, it used to be on copying from -proposed to -updates)
<RAOF> cjwatson: Hurray!
<RAOF> cjwatson: That's what I meant, if not what I said ;)
<Sweetsha1k> seb128: ETA for the build to finish: 20 minutes. ETA for the deb-packaging to finish ~1 hours.
<cjwatson> RAOF: I like being able to delete documentation ;-)
<seb128> Sweetsha1k, deb-packaging?
<seb128> Sweetsha1k, is that on i386? were you able to reproduce the issue from the builder?
<Sweetsha1k> seb128: the issue on the i386 builder was likely a fluke -- it we restart that build, Id assume it to complete.
<Sweetsha1k> seb128: so its just a instable test.
<seb128> Sweetsha1k, what about the arm* build issues?
<Sweetsha1k> seb128: quoteth infinity: "build-conflicting against the default compiler is no winning move"
<seb128> hehe
<seb128> that's true I guess ;-)
<Sweetsha1k> seb128: that sneaked in from debian very early in the cycle so I didnt see it. in the upload I simply removed the build-conflict. If there was a reason that is still valid today for it the build will break, but not worse than what we have right now.
<seb128> Sweetsha1k, right
<Sweetsha1k> so with this upload i386 should be fine, arm/ppc might be fine.
<hrw> tkamppeter: hi, bug 932882 strikes back in quantal ;(
<ubottu> Launchpad bug 932882 in gutenprint (Ubuntu) "Update of a printer driver package does not update the PPD files of the existing queues for this driver" [High,In progress] https://launchpad.net/bugs/932882
<jml> did anything unusually big happen to the archive in the last couple of days?
<seb128> hum, stupid question but is the quantal-proposed->quantal copies process documented somewhere?
<seb128> jml, you mean?
<seb128> jml, there was a freeze in effect for some days early in the week to test the new queue handling script cjwatson has been working on
<jml> seb128: I don't know :) My package scanner is taking way longer than usual, but I've got no actual access to the running copy, so I'm looking for as many sources of clues as I can get.
<seb128> jml, libreoffice and webkit got uploaded, if you consider those as big things that can happen to an archive ;-)
<cjwatson> I'm not aware of anything particularly weird
<cjwatson> seb128: process> no, because it's crap
<cjwatson> seb128: gtk+3.0 I assume?
<seb128> cjwatson, ok, so I want gtk copied from proposed to quantal
<seb128> cjwatson, ... yes :p
<seb128> cjwatson, should I do that myself or should I rather ping about it?
<cjwatson> As an archive admin, you're welcome to do it once it's built on all architectures and http://people.canonical.com/~ubuntu-archive/testing/quantal-proposed_probs.html is clean
<cjwatson> (At least regarding that package)
<cjwatson> Use sru-release (*cough* name)
<jml> seb128, cjwatson: thanks.
<seb128> cjwatson, ok, thanks
<cjwatson> With -r, obviously
<cjwatson> So e.g. I just ran 'sru-release -r quantal libfm'
<seb128> cjwatson, done it for gtk, thanks ;-)
<tseliot> infinity: are you around?
<smoser> any one know where /etc/dpkg/dpkg.cfg.d/multiarch went to in quantal ?
<tumbleweed> into a database (accessible via dpkg --print-foreign-architectures)
<tumbleweed> /var/lib/dpkg/arch, presumably
<smoser> right. i see that. notably i can add and remove now with: sudo dpkg --remove-architecture i386
<smoser> tumbleweed, thanks.
<tumbleweed> yup
<pitti> offli
<pitti> erk, focus fail, sorry
<seb128> pitti, that's not a strong password you got there :p
<pitti> in terminals this expands to offlineimap :)
<seb128> ;-)
<seb128> shrug
<seb128> webkit from quantal-proposed failed to build on armel :-(
<seb128> nothing useful in the build log
<seb128> the build seems it got killed after 16 hours
<seb128> let's retry it..
<micahg> seb128: does it still have --no-keep-memory?
<seb128> micahg, depending of the arch it builds on, the debian guys enabled it only for 32bits I think
<seb128> micahg, but the log doesn't suggest it ran out of memory or that ld got killed
<seb128> like it was happening
<seb128> it just seems the build environment was wipped out while building
<cjwatson> seb128: as if it were rm -rf'ed?
<cjwatson> seb128: if so, that's the standard ops method of killing a build
<seb128> cjwatson, in fact ignore that
<seb128> the log has a "Build killed with signal 15 after 180 minutes of inactivity"
<seb128> I wonder if the linking was at work for 3 hours?!
<seb128> webkit is slightly insane
<seb128> the previous build took 1 day 4 hours on armel, so I wouldn't be surprised if ld was taking some hours
<cjwatson> ah, well that's just the inactivity timeout
<seb128> yes
<seb128> I wonder if it was really unactive
<seb128> or if ld takes over 3 hours
<seb128> and if ld takes over 3 hours I wonder what's the way out
<micahg> seb128: well, on arm, you're going to run into memory issues fast as there's not much available (even if it doesn't fail on that)
<micahg> as in you'll start swapping like mad
<seb128> micahg, that doesn't tell me what to do though ;-)
<micahg> --reduce-memory-overheads might be a good idea on arm*
<seb128> is that a real option?
<seb128> ;-)
<micahg> if there were a working porter box, you could try it :)
<micahg> yes, indeed
<seb128> well, porter box wouldn't kill my build after 3 hours of unactivity
<seb128> so that wouldn't really reply to my question
<micahg> well, it shouldn't be 3, but 10 or 12
<micahg> at least on arm*
<cjwatson> Using the memory reduction options is probably the right thing to do
<cjwatson> 2012-02-10.log:14:12 <cjwatson> seb128: try ld --no-keep-memory
<cjwatson> 14:13 <cjwatson> seb128: possibly --reduce-memory-overheads too
<cjwatson> 14:15 <seb128> cjwatson, ok, thanks, I will have a look to --no-keep-memory and --reduce-memory-overheads
<micahg> seb128: also, they're building with -01 on armhf, maybe that should be done on armel as well
<micahg> cjwatson: sorry for not quoting you
<seb128> cjwatson, yeah, I did that in precise which worked fine
<seb128> cjwatson, Debian modified it to "only add  -Wl,--no-keep-memory for 32 bits architectures"
<micahg> arm* is 32 bit AIUI
<micahg> isn't it?
<cjwatson> Yeah, but maybe they got the test wrong?
<cjwatson> ifeq ($(DEB_HOST_ARCH_BITS),32)
<cjwatson>         LDFLAGS += -Wl,--no-keep-memory
<cjwatson> endif
<cjwatson> Hm, that should be OK
<seb128>                 LDFLAGS="-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,--no-keep-memory" \
<seb128> in the armel build log
<seb128> so it's already used
<cjwatson> OK, in that case try adding -Wl,--reduce-memory-overheads
<seb128> will do
<seb128> is it worth trying a retry first?
<cjwatson> not sure; it would probably only help if it's incredibly marginal
<cjwatson> it's not like the buildds are typically doing more than one thing at once
<seb128> ok, let me try -Wl,--reduce-memory-overheads then
<seb128> cjwatson, micahg: thanks
<cjwatson> --no-keep-memory => don't cache symbol tables in memory; --reduce-memory-overheads => change link map generation space/time tradeoff, decrease hash table size
<seb128> well --no-keep-memory helped to not reach the 32 bits memory limit at linking time
<seb128> cjwatson, I'm not sure the issue we have there is memory overhead
<seb128> it's mostly "c++ linking takes ages on complex code"
<seb128> will -Wl,--reduce-memory-overheads help linking speed?
<micahg> seb128: well, chromium takes 9.5 hrs on armel now, and they're using both of those flags last time I checked, so building twice, you should end up with ~19 hrs
<micahg> although it might not be a fair comparison as chromium is still way faster on x86 than webkit is for some reason, even accounting for building twice
<micahg> oh, right --parallel helps :)
<cjwatson> seb128: On memory-constrained systems, keeping the working set down may well make a big difference.
<cjwatson> It's entirely plausible that the slow link speed is because it's thrashing itself to death.
<cjwatson> Definitely worth trying at least.
<seb128> cjwatson, right, I'm about to upload with that, let's see how it goes, thanks again
<seb128> crap
<seb128> I pushed webkit to quantal and not quantal-proposed
<seb128> 3 minutes before the queue run
<seb128> cjwatson, is there anything I can do to undo that?
<mdeslaur> seb128: time-travel?
<seb128> mdeslaur, well it's not end of the world, it's not any worth that what we had for years
<NCommander> RAOF: ping?
<micahg> NCommander: if you're looking for an SRU member, you might want to try someone in a more awake TZ
<NCommander> micahg: recommendations?
 * micahg checks the rotation
<seb128> bdmurray
<seb128> it's his day today
<micahg> yeah, he may or may not be up yet though
<seb128> well, he's closer from being up that RAOF in any case ;-)
<micahg> very true :)
<seb128> otherwise try SpamapS or slangasek
<micahg> they're all in the same TZ
<cjwatson> seb128: Probably not
<cjwatson> seb128: Archive admins don't have access to the queue any more, it's webops only.  Though it was always a bit of a race anyway.
<seb128> cjwatson, yeah, queue has been running now anyway, sorry about that ... oh ok, well not worth bothering them
<bdmurray> NCommander: Hi, what do you have?
<NCommander> bdmurray: I'm doing highbank hardwareenablement, and I have a flash-kernel SRU accepted into proposedjust to find a typo breaks the installer on armhf+highbank. Need 42.2 pushed throughsoI can re-testd-iand finish the SRU
<ogra_> NCommander, didnt you have it reviewed before the accept ?
<NCommander> ogra_: code was fine, and worked. I forgotto escapea$ though which causdissues Ididn'tcatch
<ogra_> ah, evil !
<bdmurray> NCommander: for precise?
<NCommander> bdmurray: yeah.
<NCommander> ogra_: flash-kernel is exceptionally annoying to test because the udeb and deb getpulled from different places (if you bake the udeb right into the initrd which is how I usually test)
<ogra_> NCommander, yeah, i'm happy i didnt have to touch d-i yet ... though i will soon
<ogra_> f-k on live images is exceptionally easy to hack up :)
<NCommander> ogra_: eh, could be worse
 * NCommander beatsorga with a spork
<ogra_> what the heck is a spork ?
<ogra_> oh. a gÃ¶ffel !
<ogra_> heh
<cjwatson> http://en.wikipedia.org/wiki/Spork
<ogra_> yeah
<cjwatson> Fantastic, the German word is formed in the same way
<ogra_> hehe, yeah
<ogra_> NCommander, eeep !
<ogra_> NCommander, can you use -v in -proposed uploads so the bugs get closed from the changelog ?
<ScottK> NCommander: And so the bug's verification status shows up in the tools that the SRU team uses to see if stuff should be copied (i.e. this is not just cosmetic)
<NCommander> ogra_: er, thebug already got closed, I forgotto reopen it >.>;
<ogra_> NCommander, my bug ?
<NCommander> ogra_: er, wrong bug >.>;
 * NCommander whisltesquietly and dives out a window
<ogra_> pfft, on a one storey house thats lame
<bryceh> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: bryceh
<dupondje> Anyone an idea how I can debug foomatic driver? Getting the following on page when I print: "SPL-C ERROR : Including corrupted data"
<bryceh> anyone around who can set merge proposal statuses to merged?
<bryceh> well if anyone pops up that can close merges, these ones are done and can be set to Merged:  http://paste.ubuntu.com/1100394/
<stgraber> bryceh: doing, feel free to ping directly ;)
<stgraber> bryceh: done
<bryceh> stgraber, thanks!
<mterry> Does anyone here understand how gcc treats NANs very well?  I've got a FTBFS that seems to be due to gcc adjusting the bits in a NAN as it is passed around
<slangasek> "NAN"?  as in NaN?
<mterry> slangasek, yeah
<slangasek> do you mean that when gcc passes it around, it ends up with something that's no longer NaN?
<mterry> There's a package that uses a union of an int and a float, sets the int, then passes the float around, assigns that float to another similar union and reads back the int.  And the bits are different.  Still NaN when a float, but different bits
<mterry> This only affects i386
<slangasek> sounds to me like a valid thing for the compiler to do
<slangasek> and a possibly invalid use of a union :)
<cjwatson> Uh, I'd have to check chapter and verse, but that sounds awfully like undefined behaviour, yes
<mterry> Bummer.  Do you think there is a compiler flag to make that more reasonable?  Like "-no-mangle-nans" or something?
<mterry> Else I can just disable the test that's failing.  It doesn't seem like a super important aspect of the package
 * penguin42 seems to remember that the Intel x86 manual explicitly suggests doing things with different NaN encodings for your code to do different stuff
<mterry> (it's trying to detect the difference between signaling NaNs and quiet ones, but doing so with its own goofy union strategy)
<cjwatson> -fno-strict-aliasing perhaps
<cjwatson> have a look at gcc's docs on -fstrict-aliasing; it has some explicit examples of invalid uses of unions
 * mterry reads
<cjwatson> And I guess you could try lowering optimisation to see if that makes a difference
<smoser> anyone have thoughts on this or point to doc?
<smoser> if i have an initramfs module that has confgiuration that can be done. it can install a file into /etc/initramfs/conf.d
<smoser> then, that will get copied to the initramfs.
<smoser> for this module, from inside the initramfs i can see the "real root" filesystem
<smoser> if there is a config file in the rootfs, should i allow that to override the settings in the initramfs?
<smoser> to me it seems like /etc/initramfs/conf.d/$MODULE.conf should override the copy in the initramfs (if possible).
<astraljava> Hi gang! I'm running quantal Studio ATM. I have after installation installed -generic kernel, for testing the performance and all that. My question is: should I file a bug against update-manager when a recent update to 3.5.0-5 on -generic makes it suggest a reboot, when I'm in fact running the -lowlatency kernel, which is the default for Studio?
<micahg> astraljava: that's usually triggered in the package itself
<astraljava> micahg: Ok, so there's nothing intelligent happening to detect the flavor of the kernel running currently?
<micahg> astraljava: seemingly
<astraljava> Right, so no bug. Thanks!
<micahg> astraljava: well, that depends on your perspective
<micahg> astraljava: could be a wishlist
 * micahg -> #ubuntustudio-devel
<scientes> astraljava, check if it made itsself the default
<scientes> in /boot/grub/grub.cfg
<scientes> if not, then there is no point in rebooting, if it did, then thats a differn't bug
<astraljava> scientes: Yeah, after installing -generic, -lowlatency is where I'm getting booted at if I don't have any actions while grub is loading.
<scientes> astraljava, you might just want to remove linux-image-generic metapackage
<micahg> scientes: the point is it should DTRT regardless of what's installed, it just isn't very severe since it's a non-default case
<scientes> indeed
<astraljava> scientes: I won't, as I'll keep testing the performance differences throughout the cycle. The point behind the question was that whether update-manager should tell me to reboot when the kernel I'm actually currently running was updated or not.
<scientes> micahg, i wonder if it does this if you install the amd64 kernel on i386, thats a little more critical of a case
<scientes> astraljava, its probably lack of being able to get information back from "update-grub" trigger
<scientes> and not wanting to manually parse /boot/grub/grub.cfg
<infinity> We do nothing to try to detect which flavor you want if you install multiple.  The answer is "don't do that".
<astraljava> infinity: Okay, I find that totally understandable, and quite on mark of what I needed to know. Thanks! :)
<infinity> astraljava: As for the reboot trigger, it could PERHAPS be made more clever to try to detect if the flavour/arch combination matches the currently-running kernel, but that's a bit sketchy.
<infinity> (Would fail in the case of flavour renames, for instance, which we do from time to time)
<micahg> infinity: there are usually transitional packages with flavor renames, right?  the transitional postinst could do the handoff so to speak
<infinity> micahg: Maybe, but that feels like overengineering for a corner case.
<micahg> infinity: isn't that the fun part?
<infinity> :P
<micahg> :)
<astraljava> infinity: What flavor renames has there been? I don't recall any for Studio, but I haven't really been looking for others.
<micahg> generic-pae -> generic
<infinity> astraljava: powerpc -> powerpc-smp, generic-pae -> generic, server -> generic, virtual -> generic
<infinity> I might be missing a few.
<astraljava> infinity: Okay, I got the point, thanks. :)
<shadeslayer> hallyn: mterry opencv still needs transitioning to new tiff it seems, digikam won't get packaged until opencv depends on the new tiff
<shadeslayer> want me to do that?
<mterry> shadeslayer, ah sure.  Presumably just needs a rebuild?
<mterry> thanks
<shadeslayer> mterry: deps in control file need to be changed
<shadeslayer> libopencv-highgui-dev had a hard dep on libtiff4-dev
<mterry> shadeslayer, then maybe change them to a versionless libtiff-dev and pass the patch on to Debian.  Makes future transitions easier
<shadeslayer> ok
<infinity> micahg: Say, webkit just started pulling in half of universe via recommends.
<infinity> micahg: Care to make that not the case?
<micahg> infinity: was just about to tell seb128 about it :)
 * shadeslayer rebuilds opencv with modifications
<seb128> well, I don't care, I don't want to maintain stupid webkit...
<infinity> seb128: That's the spirit!
<seb128> whoever cares enough can fix it, I just updated because nobody does and the current version was broken
<micahg> infinity: seb128: I'm not supposed to be maintaining it in the dev release either :)
<infinity> Bah.  I'll fix it, it's just a Recommend.
<infinity> But TILM really should belong to the desktop team.
<seb128> infinity, it's a f**** package that takes over a day to fail to build on arm*
<shadeslayer> lol
<seb128> where fail to build is because ld takes over 3 hours and the buildd kills it thinking it's stucked
<seb128> I'm not touching that stuff again :p
<mterry> TIL that seb128 has been forever scarred by webkit
<seb128> mterry, ;-)
<seb128> mterry, want to maintain webkit for us? ;-)
<infinity> seb128: Yes, I've been down that road before too.
 * shadeslayer makes a mental note never to touch webkit
 * mterry shuts up again
<seb128> mterry, see!!!
<infinity> Anyhow, in this case, just dropping all the new gst-* Recommends to Suggests would probably be sane.
<seb128> mterry, I was just only too nice^Wstupid to try to fix it
<infinity> If we want gst-* plugins installed on the default system, pulling them in from webkit is the wrong answer anyway.
<seb128> infinity, yeah, I want to see if the arm* build fails first though
<micahg> infinity: well, just bad and ffmpeg
<seb128> infinity, just to avoid resetting an 1.5day build counter
<infinity> micahg: I see no reason to recommend the ones in main either.
<infinity> micahg: That should be a suggests either way, IMO.
<infinity> micahg: (In Debian too)
<micahg> infinity: why not, they add functionality to the library?
<infinity> micahg: But that's just one man's opinion.
<micahg> infinity: the idea is that webkit portal can use media content
<infinity> Lots of things add functionality, it doesn't mean they should "always be installed, except in exceptional circumstances".
<micahg> infinity: yes, but video and audio are important for a browser engine
<infinity> micahg: Maybe?  I dunno.  We lived without webkit recommending those up until now.
<shadeslayer> oh while there's some activity over here, is there a spec against the mac ISO builds?
<shadeslayer> because the 3.5 kernel supposedly supports everything
<micahg> although, technically, it should be the browser recommending them if it implements the audio/video API (unless that's not necessary in which case the recommends are correct)
<infinity> micahg: The point is probably moot, since gstreamer0.10-plugins-good is in every *-desktop seed anyway.
<infinity> micahg: But I still think that a library pulling in half the world as a default behaviour is wrong.
<micahg> sure
<infinity> micahg: Recommending gst-* fun from a user-facing application is one thing, but if you have some random dohickey that depends on libwebkit to do HTML rendering, that shouldn't pull in all of the gst madness.
<infinity> Cause, well, webkit is used all over the place for non-multimedia things.
<infinity> (So, I'd argue the "normal" use-case for libwebkit doesn't actually include that functionality at all)
<micahg> well, that's probably happening in a lot of libraries
<micahg> doesn't make it right though, so go ahead :)
<infinity> micahg: gst has a plugin architecture for a reason.  Blindly pulling in all the plugins when they're not used defeats the whole point. ;)
<infinity> (And yeah, for our desktop seeds, it's meaningless, we already install it all, but I'm just arguing packaging correctness)
<micahg> infinity: well, makes sense for a browser, you want to play everything
<infinity> Plus, the delta's super easy to maintain if we just s/Recommends/Suggests/ :P
<micahg> heh, right
<infinity> micahg: Absolutely makes sense for a browser.  libwebkit isn't a browser.
<bryceh> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<shadeslayer> mterry: https://launchpad.net/~rohangarg/+archive/experimental/+builds?build_state=building < could you sponsor those once they're built?
<mterry> shadeslayer, sure.  I'll leave a tab open, but if you notice before I do, ping me again
<mterry> I'm about to sign off though, so may get to it tomorrow
<shadeslayer> nah, I'm going to sleep in a couple of minues :P
<shadeslayer> sure, no rush
#ubuntu-devel 2012-07-20
<alazare619> alazare619> hey whats the format for a repository to be included in the chroot phase of livecd-rootfs
<alazare619> <alazare619> let me pastebin the setup i have
<alazare619> <alazare619> http://pastebin.com/RwRN9VQV
<TheMuso> alazare619: You should use the ubuntu-defaults-builder package if you want to add another archive like a PPA.
<alazare619> ive been told this many times
<alazare619> im not trying to build gtk etc
<alazare619> im building a ubuntu base from scratch
<pitti> Good morning
<ev> mpt: in case you wanted a closer look at those lines: http://10.20.66.185/
<oly> hi, after a few pointers with packaging python software, i have successfully built a deb but one thing that concerns me is where its going to install to
<oly> looking in rules and control files there does not seem to be any where i have setup a path
<oly> does that mean all files would install to root ie /
<oly> currently i have /project/sourcecode and /project/debian with the packaging files
<directhex> the convention is that packages use --prefix=/usr, and debhelper sets various parameters to set this. i don't know about python packaging specifically though
<tumbleweed> python modules get installed into the python dist-packages directory
<tumbleweed> if tehy aren't there, they aren't importable
<oly> well the path i need to install to is /usr/lib/rhythmbox/plugins/
<tumbleweed> aah, then tell it to do that
<tumbleweed> dh_auto_install -- --install-lib /usr/lib/rhythmbox/plugins/ (or something like that)
<cjwatson> To answer the general question, once you've built the .deb you can use 'dpkg -c foo.deb' to see its filesystem tree
<oly> okay i will look into dh_auto_install been following guides but could not find any that explained how you handle installing files to different locations
<ogra_> or dpkg -L foo if the package is installed already
<oly> okay, yeah i have not installed it on the basis i have no idea where the files would be going :)
<tumbleweed> even easier, just run "debc" in the build directory, after building
<ogra_> use dpkg -c foo.deb then, as cjwatson suggested
<tumbleweed> ogra_: as to what I was suggesting with dh_auto_install, that's an override, so:
<tumbleweed> override_dh_auto_install:
<tumbleweed>         dh_auto_install -- --install-lib .......
<oly> okay cheers for the info given me some thing to look into :)
<tumbleweed> under the hood, it's just passing that as an argument to setup.py install
<mterry> shadeslayer, uploaded opencv fix and threw over to Debian for ya.  Thanks!
<mterry> shadeslayer, I did edit the patch slightly.  You dropped the (>= 3.9.4) requirement on libtiff-dev.  I figured that ought to still be there
<ScottK> mterry: libtiff-dev is a virtual package, so versions are meaningless.
<mterry> ScottK, oh hmm.  touche.  shadeslayer, sorry for doubting you.  :)
<Riddell> mdeslaur: this says requires openmotif http://www.citrix.com/English/ss/downloads/details.asp?downloadId=2323812&productId=1689163
<mdeslaur> Riddell: yeah, just saw that...thanks
<tumbleweed> stgraber: ta (verifying my SRUs)
<stgraber> tumbleweed: np, that was an easy one ;)
<oly> got another pacakging query any one know what these messages are telling me and how i can fix them :)
<oly> dh_prep: No compatibility level specified in debian/compat
<oly> dh_prep: This package will soon FTBFS; time to fix it!
<oly> the debian/compat is in particular confusing as i have the file with value 7 in it
<cjwatson> You must have it in the wrong place, or it must have some other stuff in it as well, or something
<cjwatson> cat -et debian/compat
<oly> that return 7$
<oly> not sure where the $ came from
<cjwatson> That's from cat -e
<cjwatson> man cat
<cjwatson> So you must have the file in the wrong place, I guess
<oly> lol, not sure how as all my other packaging files are in the same place ie in ./debian
<oly> if it was the wrong place i would expect nothing to work :)
<oly> will dig a bit further :)
<oly> whats this one telling me This package will soon FTBFS; time to fix it
<oly> no idea what FTBFS stands for
<ogra_> failed to build from source
<oly> guessing its deprecation style notice and i should be using something else
<oly> aha thats usefull to know thanks :)
<ogra_> (or failing or fails ... not sure about the exact grammar here)
<oly> at least that gives me some clues :)
<oly> not that it helps me figure out what i will need fix, but googling that may give better results
<cjwatson> If you want further help you probably need to put the whole source package somewhere that somebody else can look at it
<oly> okay one sec i have it on launchpad
<cjwatson> oly: Sure, I could look at a package / build log / etc. on Launchpad
<oly> yeah jsut need to setup this machine so i can upload to launchpad again, i formatted it recently :p
<oly> lol silly me trying to upload the code outlined the issue obviously i have to commit the files before packaging picks them up :)
<SpamapS> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: SpamapS
<SpamapS> hallyn: https://code.launchpad.net/~serge-hallyn/ubuntu/quantal/pulseaudio/pa-upstart/+merge/112650 .. hey can you fix the spelling mistakes in the changelog?
<ogra_> hmm, since when did we stop adding users to the dialout group ?
 * ogra_ just noticed that he cant use an usb to serial adapter on a fresh precise install
<hallyn> SpamapS: you accuse me of spelling errors?  no scotch for you!
<hallyn> lemme check
<SpamapS> mmmm scotch
<SpamapS> hallyn: how would you feel about completely deprecating /etc/default/pulseaudio as part of this switch?
<hallyn> SpamapS: i don't particularly care :)  how do we properly do this without upsetting users?
<hallyn> SpamapS: setting ":set spell" in vim, how do I correctly spell SpamapS?  :)
<SpamapS> hallyn: if we replace the file with a comment that says "# This file is deprecated please edit /etc/init/pulseaudio.conf directly" then they'll get prompted for the config file merge
<SpamapS> hallyn: "superamazingdude"
<hallyn> they'll only get prompted if they had made changes then?
<hallyn> (cause i hate HATE prompts)
<hallyn> SpamapS: updated and pushed (but not yet tested)
<SpamapS> hallyn: you've got conflicts ;)
<hallyn> feh, how come bzr push didn't tell me that
<SpamapS> +	[ -r /etc/default/pulseaudio ] && . /etc/default/pulseaudio
<stgraber> slangasek: I'm taking a look at the sysvinit merge as one of the bugfixes is on the list for 12.04.1. Let me know if you already had some of it done somewhere.
<SpamapS> hallyn: because you pushed to your branch, not to the target
<SpamapS> hallyn: so now that you've deprecated /etc/default/pulseaudio, you should remove that line
<slangasek> stgraber: I haven't started on it, but please be very careful about reviewing the Debian changes... *particularly* the ones with my name on them
<slangasek> stgraber: because there are some changes in there regarding upstart compat in Debian that are not ready to go in, as-is, for Ubuntu
<hallyn> SpamapS: yup, merging and fixing
<hallyn> (bzr ci helps too)
<SpamapS> slangasek: so, does it make sense to use /run even if you're not expecting something to start in early boot, or should things just continue using /var/run indefinitely if they never expect to be early boot (like pulseaudio)
<stgraber> slangasek: yeah, looking at the delta we had and the amount of changes in Debian since the last release I'm starting to wonder if I really want to spend all that time on the merge and shouldn't instead just cherry-pick the bit I need (the /run/shm fix) ;)
<hallyn> stgraber: i do apologize for dumping that merge on you.  but ^ that's why I fjeered to do it myself :)
<hallyn> stgraber: d'oh, luke merged the upstart change.  canceling that merge request
<slangasek> SpamapS: I would go by whatever we put in debian-policy about this.  In terms of technical implementation, /run and /var/run are equally fine for quantal, and one is a symlink to the other /anyway/, but if this needs to be in Debian too, a pre-dep is still needed until after the wheezy release; the FHS itself hasn't been updated to obsolete /var/run
<slangasek> SpamapS: so my own position is to not do any work to move things to /run unless they're early-boot
<hallyn> SpamapS: too bad i can't just 'cancel' the request without deleting it - there is valuable info in there
<SpamapS> slangasek: so with PA being converted to an upstart job.. its not so much "doing work" as "making a choice"
<SpamapS> hallyn: ok so the item is merged?
<hallyn> SpamapS: yeah, though without the changes you'd recommended
<SpamapS> hallyn: well good we can now optimize ;)
<stgraber> hallyn: diffing the postinsts, looks like that's the bit we want right? http://paste.ubuntu.com/1102118/
<SpamapS> hallyn: its one of those death-by-1000-papercuts things.. but I am on board now with fully deprecating all /etc/default files used in upstart jobs
<SpamapS> hallyn: and in this case its a nice win because the pre-start will just spawn one /bin/sh, see the env var, and stop/exit
<SpamapS> for 90% of systems anyway
<SpamapS> actually...
<slangasek> SpamapS: converted to an upstart job> howso?
<SpamapS> I wonder if we shouldn't promote a different thing entirely in this case
<hallyn> SpamapS: othe rchanges you'd suggested too, like not startong on starting udev
<SpamapS> why are we using an env var?
<hallyn> SpamapS: what are the implications of not using env?
<slangasek> SpamapS: are we changing how we're starting pa?  We've always started it per-user
<SpamapS> hallyn: realistically.. we should just have the start on commented out, and a comment in there '# Uncomment this line to enable system mode'
<SpamapS> slangasek: the init.d script was for the off case
<SpamapS> or rather
<SpamapS> system case
<hallyn> stgraber: (looking, trying to remember)
<SpamapS> slangasek: it still defaults to not starting
<slangasek> SpamapS: right, ok
<SpamapS> but.. I'm looking at it and realizing it really shouldn't have a start on
<slangasek> SpamapS: so I would use /var/run, but I also don't think it's a big deal either way in that case
<stgraber> hallyn: that matches the git commit by slangasek and covers my understanding of the problem, though I'm not sure if we need more than just that bit
<SpamapS> slangasek: agreed
<slangasek> it's not like we're going to try to push a pa upstart job to Debian before wheezy
<SpamapS> yeah, and we're also not going to backport this to pre-oneiric
<hallyn> stgraber: I"m not sure,
<hallyn> stgraber: long as we're cherrypicking, https://bugs.launchpad.net/launchpad/+bug/974584/comments/21
<ubottu> Launchpad bug 974584 in sysvinit (Ubuntu Quantal) "Semaphores cannot be created in lxc container" [High,Triaged]
<hallyn> stgraber: they're not *quite* the same...  iow slangasek's suggestion would have been ' ! mountpoint /dev/shm', not /dev
<SpamapS> hallyn: so.. to wrap this up. I would remove the PULSEAUDIO_SYSTEM_START env var, and just replace that with a commented out start on
<hallyn> SpamapS: and still replace mkdir/chown/chmod with install :)
<hallyn> and fix the commented-out start on, and remove the .default
<SpamapS> hallyn: right
<SpamapS> hallyn: any idea whats with the post-start stuff?
<SpamapS> that seems like things that PA should be doing on its own
<hallyn> SpamapS: agreed, though i do recall the sysvinit script did it too.  yes we coudl just patch the daemon to do it
<SpamapS> hallyn: just seems like thats the wrong place to do it
<SpamapS> hallyn: anyway, I'll move on from this item.. bump me when you have an update and I'll take a gander
<hallyn> sigh
<hallyn> SpamapS: yeah I don't see any existing code for setting ownership of the the cookies.  Perhaps someone should push that upstream (configurable), but that won't likely be me
<SpamapS> hallyn: yeah just leave it
<SpamapS> hallyn: seems like the "system mode" of PA is a corner case anyway
<stgraber> hallyn: my diff was against what's in Debian which doesn't match what's in git. What's in git looks better: http://paste.ubuntu.com/1102146/
<stgraber> hallyn: and I agree that the mountpoint check should only be against /dev/shm as slangasek suggested
<hallyn> stgraber: great.
<stgraber> hallyn: pushing http://paste.ubuntu.com/1102150/ to a PPA for quantal and precise, will do some tests before I'm confident uploading that :)
<seb128>  @SRU team: is there any motivated member who wants to review the unity precise SRU just uploaded? we would like to get it early rather than late to keep open the possibility to do another SRU round for the 12.04.1 desktop freeze
<seb128>  
<seb128> some notes
<seb128>  - the list of bugs fixed in that SRU is quite long
<seb128>  - some of the bugs are not fully SRU-rules-compliant yet, but the vast majority is, the #ps guys are working on finishing testcases etc for the remaining ones
<seb128>  (I don't think we should block the SRU on that)
<seb128>  - the update got quite some solid testing already, some people are running it for a week and it went through several round of checkbox manual test and automatic testing
<seb128>  with some issues found and fixed during the week
<seb128>  
<seb128>  to do it short: it's going to be a bit tricky to review but it got solid automated and manual testing and we are confident it should create no issue
<seb128>  ;-)
<seb128> SpamapS, bdmurray, ScottK, slangasek, infinity: ^
 * ScottK is about to leave for his daughter's art show, so no.
<seb128> ScottK, thanks for replying anyway, enjoy the show ;-)
<slangasek> seb128: I have a train ride this evening which should be good for some SRU reviewing... but AIUI mdadm is still blocking on me so that's my first priority
<SpamapS> seb128: I'm on patch pilot today, and slangasek won't be able to do his normal SRU shift today I think. So I think you're down to bdmurray and infinity. ;)
<bdmurray> infinity: said he'd take slangasek's shift
<seb128> well I tried my chance anyway, I was expecting it would be hard to get review today ;-)
<SpamapS> seb128: I can look at the bugs w/o docs and see if they're worth waving through tho
<bdmurray> I may have some time in my afternoon
<seb128> slangasek, maybe the week of ppa, checkbox, automatic testing, jenkins etc gives you enough confidence to have an half an hour look in the train to spot anything stupid and if you don't wave it in? ;-)
<infinity> I'll be doing some of vorlon's SRUy bits today, yeah.  But if he wants unity, it's all his. :P
<seb128> well anyway I wanted to give some context
<seb128> it will get it when it gets in
<slangasek> seb128: maybe... it's mostly a question of whether I have enough half hours ;)
<seb128> thanks guys ;-)
<shadeslayer> mterry: thanks for the upload
<shadeslayer> small problem though, it's in dep wait, apparently it can't find libtiff-dev
<shadeslayer> well ... I think maybe because you versioned it ...
<shadeslayer> yep
<stgraber> hallyn, slangasek: so, while testing the fix for bug 974584 I found an even more common bug (that was likely thought to be 974584). Complete fix now looks like: http://paste.ubuntu.com/1102362/
<ubottu> Launchpad bug 974584 in sysvinit (Ubuntu Quantal) "Semaphores cannot be created in lxc container" [High,Triaged] https://launchpad.net/bugs/974584
<stgraber> I tested it in lxc and it seems to do the right thing here and I believe I guarded it even that it shouldn't affect any other scenario, but I'd really like to have you two take a look at it :)
<hallyn> stgraber: looking
<shadeslayer> so, could someone re-fix opencv ? ( Drop the versioning for libtiff-dev )
<stgraber> slangasek: basically, we have a workaround in lxc to make /dev/shm a symlink to /run/shm but it only works when /run/shm exist, which stopped being true late in the 12.04 cycle, so quite a lot of containers are still broken...
<stgraber> slangasek: that code I added detects these cases and fixes them before the rest of the code is executed. Without that bit, any initscripts update (or even reinstall) will fail in lxc (as apparmor will block the bind-mount)
<stgraber> hallyn: it looks like the "mountpoint -d" is magic enough to work at detecting bind-mounts, but if you know of a better way of detecting these, I'm happy to change the check
<hallyn> stgraber: no apart from picking through /proc/self/mountinfo - mountpoint -d is better
<hallyn> stgraber: but, can th emv work right if something is actively using the devshm?
<stgraber> hallyn: I expect some problems around that actually but I can't think of a better way to deal with it to be honnest... as long as all processes using a given shm entry have it open, it won't be a problem. I guess it'd probably become a problem if something else tries to open it before from the new location while some others still read it from the old/non-existing location.
<hallyn> stgraber: if anything caches the inodes #, i s waht i was thinking
<stgraber> hallyn: it also depends whether they are currently using /run/shm or /dev/shm, I'm trying to check that part now
<hallyn> stgraber: i supposeit *might* be safer to do something like "mv /dev/shm /dev/shm.bak; rsync -va /dev/shm.bak/ /run/shm/; compat_link /run/shm /dev/shm"
<stgraber> hallyn: the only difference I see with that approach is that you can still "see" the files, but the result for something using the shm entry should be identical
<stgraber> as anything that has an open fd will still be able to read/write and anything that doesn't won't know to look in /dev/shm.bak so will access the copy in /run/shm
<hallyn> stgraber: yup
<hallyn> but note if you don't do that, if something has a /dev/shm/xyz file open, your mv may fail, making upgrade fail (non-reproducibly)
<hallyn> i don't know if that's a real concern or not, just bringing it up
<jderose> hello, i'm hoping to find someone able to review/sponsor this couchdb 1.2.0 package - https://bugs.launchpad.net/ubuntu/+source/couchdb/+bug/1022515
<ubottu> Launchpad bug 1022515 in couchdb (Ubuntu) "Please sync (sort of) couchdb 1.2.0-1 from Debian unstable" [Undecided,Confirmed]
<stgraber> hallyn: why would mv fail if a file is open? I thought only Windows did that :)
<hallyn> stgraber: bc mv accross devices will 'cp; rm' right?
<stgraber> right, but you can rm a file that's still open
<hallyn> maybe it won't fail, maybe just the inode will be kept open.  true
<hallyn> stgraber: yeah nm.  go with what you've got :)
<stgraber> still doing one more test to see whether when both /dev/shm and /run/shm exist, entries are created in /run or /dev by default, to see how bad it's going to be on upgrade ;)
<mhall119> jderose: my usual go-to guys are all in Europe and gone for the weekend already :(
<jderose> mhall119: now prob, thank you :)
<jderose> mhall119: so when is the deadline for this sort of change without an exception?
<mhall119> lets check the schedule
<mhall119> Feature Freeze is the week of Aug. 23rd
<jderose> okay, good to know, thanks
<mhall119> np
<george_e> Who do I need to talk to to get access to this page: https://chinstrap.canonical.com/~racarr/unity-web-api-docs/unity-web-api-reference.html
<george_e> Apparently I don't have permission to access it.
<stgraber> george_e: chinstreap is Canonical-only IIRC, if it's meant to be public, racarr should move it to lillypilly (people.canonical.com) that's publicly accessible
<ScottK> george_e: First you have to get hired by Canonical.
<george_e> Oh... okay. Is there a copy of the documentation somewhere else that I can read?
<tumbleweed> google turns up http://developer.ubuntu.com/api/ubuntu-12.04/javascript/index.html
<george_e> tumbleweed: Ah, thanks.
<stgraber> the exact same page is actually: http://developer.ubuntu.com/api/ubuntu-12.04/javascript/unity-web-api-reference.html
<stgraber> but he's gone, so I guess he found the link :)
 * tumbleweed didn't stop to read it, but it looked unity-web-api ish
<tumbleweed> :)
<stgraber> hallyn, slangasek: did a bunch more tests and can't find anything obviously wrong with that change. Will push to quantal now so I can properly test debootstrap and will also push to precise-proposed. If anything else comes to mind, please shout and I'll fix.
<stgraber> will test in quantal with debootstrap as soon as it's published and do a precise => quantal container upgrade, these are the last checks I can't easily do with the PPA
<hallyn> stgraber: great, thanks
<SpamapS> hallyn: one more nit-pick..  pre-start is only one line, so it can be 'pre-start exec install ...'
<hallyn> i didn't know you could od that
<hallyn> SpamapS: pushed
<SpamapS> hallyn: yeah, the less script's, the less forks, the less microseconds wasted ;)
<hallyn> i'd like to see my boot time below 7 secs, so +1
<SpamapS> actually no.. no fork saved.. but one exec saved
<SpamapS> hallyn: you also have the issue with lightdm needing to slow down right?
<hallyn> SpamapS: not any more.  whatever suggestion you had made worked for me
<hallyn> SpamapS: i'm playing with vde2.  getting ready to push on its MIR.  especially since vdeqemu no longer ships with vde2.  (could be wrong, thought you'd been interested in the past)
<SpamapS> hallyn: uploading now (finally)
<hallyn> SpamapS: \o/
<SpamapS> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
#ubuntu-devel 2012-07-21
<slangasek> stgraber: so is that latter sysvinit change cleaning up after previous incomplete sysvinit migration code?
<slangasek> (I suppose that's why it might be in sysvinit instead of lxc?)
<slangasek> stgraber: also, can you please put a version guard on that upgrade code?
<stgraber> slangasek: yeah, and lxc doesn't have any package inside the containers, so we don't have a way of fixing them other than SRUing initscripts for that. In theory the check I uploaded shouldn't even match a setup that's not broken but I should have indeed added a version guard on top of that if someome actually wants the "broken" setup.
<slangasek> stgraber: <nod> the risk of a false positive is small, but I'm paranoid about upgrade code not having version checks; so please fix that in quantal and in the SRU :)
<stgraber> slangasek: please reject the SRU then, I'll prepare an updated postinst
<slangasek> stgraber: rejected, thanks
<stgraber> slangasek: re-uploaded to -proposed, testing the one to quantal to make sure I didn't mess up anything in the version check
<psusi> so I'm trying to figure out how to bootstrap an x32 system by practicing building i386 packages from amd64... if I run debuild -ai386, it seems to build an i386 binary package ( though dh_strip tries to run i686-linux-strip instead of strip, so I had to make a symlink ), but I can't figure out how to get debuild to pass gcc -march=i386
<slangasek> psusi: so debuild -ai386 will set DEB_HOST_ARCH and friends; packages that know about cross-building will take this as a hint to *do* cross-building, which means they'll look for a cross-compiler
<slangasek> psusi: so they will look for i686-linux-gnu-gcc - provide this and have it do the right thing
<psusi> slangasek, right... I guess that's why dh_strip was trying to run i686-linux-strip instead of just strip....
<psusi> but the actual build didn't complain about not being able to find i686-linux-gnu-gcc
<psusi> it seemed to run gcc and build just fine... just barfed at dh_strip, which I got around with a symlink
<slangasek> ideally i686-linux-gnu-gcc could be implemented by gcc itself just knowing what to do; but at a push, you can make it a short wrapper script that calls exec gcc -m32 $@
<slangasek> right, then your test package seems to not be cross-build-friendly
<slangasek> (which package?)
<psusi> but... while it built an i386 binary deb, the actual binaries are still amd64 since it isn't telling gcc the right -m
<scientes> slangasek, yes i tested using multi-arch for that, it works great!
<slangasek> depending on the package, it may be using gcc as a fallback
<infinity> psusi: Yeah, it's obviously hardcoding the compiler, which is not cross-friendly.
<psusi> hrm.... that could be
<slangasek> and maybe creating i686-linux-gnu-gcc will be enough to make it happy
<scientes> just using a -m32/-m64 wrapper for -afoo that can be satified by multilib
<slangasek> again, which package?
<infinity> Or, I suppose it could be cross-friendly but falling back in the absense of triplet-cc, yeah.
<scientes> slangasek, you need symlinks for binutils, and gcc/cpp/etc, and then it works
<slangasek> yes
<psusi> so... you are saying to get it to work, I have to write a wrapper gcc script to run gcc -m32?  can't get dh to be happy just running gcc and adding -m32 to the CFLAGS?
<scientes> but yeah i had that working great
<scientes> paulliu, yep, i'll go find what i was using
<scientes> paulliu, slacker_nl   this works: http://paste.ubuntu.com/1102847/
<scientes> i called it "gcc-32", and you could easily make a similar gcc-64
<psusi> it seems kind of silly to have to invoke all of the cross compiling machinery when the native gcc supports the "cross" arch, you just need to add a flag
<psusi> but you're saying that's just how you have to do it?
<scientes> psusi, the "c99" "c89" commands work exactly the same
<scientes> of course this is called by the full qualified name
<scientes> i got blocked on trying to wrap my head around how the packaging for gcc-defaults-cross might work
<scientes> i think it should be packaged like this IMHO
<psusi> so if you have to pretend you are doing a full cross compile... why doesn't our gcc package come with the cross compiler wrapper script to add -m32?
<scientes> psusi, it could either be part of (gcc|g++|gobjc)-multilib packages, or a seperate package
<infinity> psusi: You could certainly file a bug to that effect.
<psusi> how do you smack bzr bd into passing options to debuild?  it pukes on -ai386
<infinity> -- perhaps?
<infinity> (I don't use it, just a wild guess)
<ScottK> psusi: -- $OPTIONS
<psusi> good guess... I was thinking that but the man page doesn't show it ;)
<ScottK> Yes.  I've written bugs about it.
<ScottK> It's not a guess.  I knew because I couldn't find it either and had to ask.
<ScottK> "inconsitent interface" is on my reasons to avoid UDD kinds of things.
<ScottK> Who'd have thought -S -- -sa -us -uc was a good plan?
<psusi> hrm... when I add -ai386, it says /usr/include/linux/errno.h can't find asm/errno.h
<scientes> psusi, install libc6-dev:i386 ?
<psusi> ohh... I guess gcc expects a separate 32bit headers directory
<scientes> psusi, or rather apt-get build-dep -ai386 <package>
<slangasek> ScottK: it's equally valid to call it as -- -S -sa -us -uc, if that makes you happier ;P
<psusi> hrm.. so why does apt-get want to remove the native amd64 -dev packages to install the i386 ones?
#ubuntu-devel 2013-07-15
<pitti> Good morning
<ion> that
<pitti> ogra_, slangasek: has there been any further discussion on bug 1187189, i. e. how to do fw loading? with the flipped container model that might have changed?
<ubottu> bug 1187189 in linux-mako (Ubuntu) "Kernel crash and reboot when accessing video device" [High,Confirmed] https://launchpad.net/bugs/1187189
<pitti> wgrant, StevenK: wrt https://translations.launchpad.net/ubuntu/saucy/+language-packs, what's missing for starting exports now?
<wgrant> pitti: We need to adjust the export schedule
<wgrant> That's about it
<pitti> wgrant: for that to happen, which direction do I send beer to?
<pitti> to you?
<wgrant> 30 10 * * 1 nice -16 $LP_PY /srv/launchpad.net/production/launchpad/cronscripts/language-pack-exporter.py ubuntu precise --force-utf8-encoding -q --log-      file=INFO:/srv/launchpad.net/production-logs/rosetta/language-pack-exporter.log
<wgrant> 30 10 * * 2,4 nice -16 $LP_PY /srv/launchpad.net/production/launchpad/cronscripts/language-pack-exporter.py ubuntu raring --force-utf8-encoding -q --log-     file=INFO:/srv/launchpad.net/production-logs/rosetta/language-pack-exporter.log
<wgrant> 30 10 * * 3 nice -16 $LP_PY /srv/launchpad.net/production/launchpad/cronscripts/language-pack-exporter.py ubuntu quantal --force-utf8-encoding -q --log-      file=INFO:/srv/launchpad.net/production-logs/rosetta/language-pack-exporter.log
<wgrant> Is what we do atm
<wgrant> I'
<wgrant> I'd suggest s/raring/saucy/, s/quantal/raring/
<wgrant> So stopping quantal exports
<pitti> yeah, we don't use them any more
<wgrant> OK, I'll make that change. You'll handle your end?
<lifeless> wgrant: isn't that s/quantal/saucy/ ?
<wgrant> Not in that order.
<pitti> wgrant: adjusted, but disabled for now; I need to build full saucy packs initially
<pitti> I'll do that when I see the first full export on +langpacks
<wgrant> Thanks
<pitti> wgrant: thanks to you!
<dholbach> good morning
<ogra_> pitti, we dont/cant do fw loading on the ubuntu side since it is part of the HW initialization happening on the android side ... loading it in ubuntu we would miss configs and parameters ... if you have a better idea how to prevent it than diverting the rules that would be super appÃ¼reciated :)
<pitti> ogra_: i. e. we should revert the patch to grab firmware from /system and /vendor ?
<ogra_> pitti, there is a patch ? i thought slangasek dropped it when we added the diversion for the firmware rule
<pitti> ogra_: not a patch, we added /system/firmware and /vendor/firmware as fw lookup path
<ogra_> we explicitly dropped the rule, so udev shouldnt even attempt to load fw at all
<ogra_> which makes the patch useless i guess
<pitti> ogra_: ah, then I guess that was a no-op change
<pitti> ok, then I'll just revert it for now
<ogra_> the patch was before dropping the rule altogether, i guess steve just forgot about it
<ogra_> pitti, though it would be nice if udev could have a switch or some such to prevent fw loading, so that we dont need to divert the rule
<pitti> ogra_: well, disabling the rule means to install one extra empty file into /etc/udev/rules.d/
<pitti> ogra_: it can't get much easier than that; in particular, we don't want to change any existing file
<pitti> no need for a divert there
<pitti> just touch /etc/udev/rules.d/50-firmware.rules
<ogra_> oh ... upstart style disablement ?
<ogra_> ok
<pitti> no, udev rules overriding; that has worked for many years
 * ogra_ didnt know that exists 
<pitti> see /etc/udev/rules.d/README
<ogra_> ah, just an empty rule with higher sequence ... k
<pitti> ogra_: ok, that might simplify things on your end :)
<pitti> ogra_: no, not with higher sequence, with exactly the same name
<pitti> ogra_: /etc/udev/rules.d/foo.rules replaces /lib/udev/rules.d/foo.rules
<ogra_> ah, i missed thats /etc, sorry
<pitti> ogra_: as you can't undo the fw loading, a higher sequence number doesn't work here
<ogra_> right
<pitti> ogra_: so I guess that touching will happen in the image build process, or some u-phone specific package will ship it?
<ogra_> yeah
<ogra_> the lxc-android-config package holds all container stuff and related hacks
<ogra_> as long as we use ueventd we dont want udev to initialize the HW
<pitti> ogra_: ok; so I guess I'll follow up to the bug with that summary; thanks!
<ogra_> (it's startup is delayed untila after the container is done atm, and we'll get an upstart bridge into the container so we can depend on "ueventd settle" inn it for starting udev
<ogra_> )
<pitti> jodh: hey James, how are you?
<jodh> pitti: hi, good.
<pitti> jodh: wrt. the apport log file collect work item in https://blueprints.launchpad.net/ubuntu/+spec/foundations-1305-upstart-app-launching
<rbasak> Bug 1199318. He shouldn't have saucy-proposed enabled, but is this also a bug anyway? Is there a missing Breaks/Replaces in apache2-utils 2.4.4-6ubuntu2?
<pitti> jodh: I don't currently have any ~/.cache/upstart/application-*
<ubottu> bug 1199318 in apache2 (Ubuntu) "package apache2-utils 2.2.22-6ubuntu5 failed to install/upgrade: trying to overwrite '/usr/share/apport/package-hooks/apache2.py', which is also in package apache2.2-common 2.2.22-6ubuntu5" [Undecided,New] https://launchpad.net/bugs/1199318
<pitti> jodh: will these appear at some point, or has the semantics of that changed?
<pitti> rbasak: yes, there is
<jodh> pitti: this is teds baby. Seems to be on hold currently: https://code.launchpad.net/~ted/indicator-application/upstart-job
<rbasak> Thanks.
<pitti> ogra_: do you know how to launch a Qt app on phablet builds from ssh? i. e. the equivalent of setting $DISPLAY?
<ogra_> sudo -u phablet
<pitti> ogra_: I tried with the terminal app and an external keyboard, but the terminal app doesn't work very well with a keyboard..
<ogra_> that shoudl suffice
<pitti> hm, I'm already logged in as phablet
<pitti> ogra_: oh, indeed; it wasn't working the first time, but now it does
<pitti> ogra_: thanks!
<seb128> pitti, ssh phablet@ip.tablet
<pitti> yes, that's what I did
<seb128> pitti,  qmlscene debug.qml --desktop_file_hint=/usr/share/applications/ubuntu-weather-app.desktop
<seb128> you need the --desktop_file_hint
<seb128> iirc
<seb128> (that works there)
<ogra_> right
<ogra_> https://wiki.ubuntu.com/Touch/ReleaseNotes#Ubuntu_SDK_Alpha ... at the bottom has the instructions btw
<pitti> so just calling "gallery-app" reproducibly doesn't work until I actually launch it from the terminal there; seb128's command segfaults
<ogra_> seems you are missing env vars then
<seb128> pitti, weird, I run system-settings like that and it works for me
<seb128> system-settings --desktop_file_hint=/usr/share/applications/ubuntu-weather-app.desktop
<pitti> I'm actually trying to reproduce bug 1198277, which concerns app startup
<ubottu> bug 1198277 in Autopilot "Failed to create proxy object for gallery app" [Critical,In progress] https://launchpad.net/bugs/1198277
<pitti> seb128: "qmlscene debug-qml --desktop_file_hint=/usr/share/applications/ubuntu-weather-app.desktop" also crashes
<seb128> pitti, do you have a debug-qml?
<seb128> pitti, qmlscren debug.qml was my command in that example, replace by whatever you want to run
<pitti> so with autopilot I get a autopilot.introspection.dbus.gallery-app  object, but I don't see anything
<pitti> seb128: no, I though that was some standard qml file to launch an app
<seb128> pitti, "$ gallery-app --desktop_file_hint=/usr/share/applications/gallery-app.desktop" works for me
<pitti> seb128: ah, that way around
<seb128> pitti, oh, sorry
<dpm> I believe plain 'qmlscene app.qml' should also work for the purposes of just launching the app. That's how I've been launching the music app for testing it
<ogra_> for me too
<ogra_> (though i'm logged in with adb and use sudo -u phablet -i here
<ogra_> )
<pitti> seb128: confirmed, merci beaucoup !
<seb128> pitti, de rien ;-)
<pitti> nah, "ssh nexus" FTW :)
<popey> dpm: nope, you need more parameters or it doesn't show up
<pitti> ogra_: *applaud* vi installed by default!
<ogra_> haha, minimal pulls it in
<dpm> ah, perhaps what I did was just to launch the executable line in the .desktop file, then, which includes the parameters
<dpm> ignore my comment, then
<ogra_> not my doing :)
<Laney> huh, I'd been typing commands on the terminal of the device for all this time :P
<pitti> ogra_: OOI, the MAC address (and thus the supposedly stable IPv6 address) of this thing seems to change with every boot; is there a trick to get a stable IP on that thing?
<pitti> ogra_: or do you also just check the ip du jour every time?
<ogra_> i honestly didnt even knwo it changes :)
<pitti> ogra_: ah, you're using adb shell, not ssh?
<ogra_> yes
<pitti> ok
<ogra_> but even then, it shouldnt change, what device is that ?
<ogra_> probably worth a bug (though would need an android fix)
<pitti> ogra_: nexus7
<ogra_> ah, crap HW then :P
<ogra_> j/k
<xnox> pitti: i typically use the avahi hostname: ssh phablet@ubuntu-phablet.local
<xnox> or whatever it is, and I ignore host verification on *.local.
<popey> which is annoying if you have two phablet devices!
<xnox> popey: *sigh*
<tseliot> pitti: do you happen to remember if jockey.detection.get_hardware() is cached somewhere in Jockey? I'd like to access it from handlers without having to call the same function multiple times
<popey> the hostnames should be unique
<popey> we should get achiang generating awesome hostnames randomly for us
<pitti> xnox: that was actually the first thing I tried, but it doesn't seem to WFM
<xnox> popey: yeah, oobe app, which i am on the hook to write should let one choose the hostname.
<xnox> pitti: right, cause i had to manually install and configure avahi (disable some $new-kernel-feature)
<ogra_> popey, lol
<Laney> I loved bisquicks and want it back
<pitti> popey: yeah, way to break predictability of that, too :)
<pitti> xnox: aah
<Laney> I don't think I had to do anything to have avahi working to the device ...
<pitti> anyway, adb or adb forwaring is fine
 * ogra_ once had a "mofo" device thanks to that ...
 * xnox whistles at broken launchpad and goes to make coffee, whilst the failover is in progress.
<ogra_> GEEZ !
<ogra_> the Lp error page tells me i need to install flash ?!?!
<wgrant> Probably the Twitter streaming thing broken by a YUI update
<wgrant> That page doesn't get tested much...
<Laney> I just get a spinner
<pitti> me 2
<seb128> launchpad is back
<tseliot> pitti: is it a no? ^^
<pitti> tseliot: sorry; it is cached, see def _get_modaliases()
<pitti> tseliot: the second time it shoudl be very quick and not actually do anything except returning the cache
<xnox> seb128: yeah, it's back but not all cronjobs are back on.
 * xnox 's uploads not accepted.
<tseliot> pitti: ah, nice, I had missed the "if _get_modaliases.cache:" part. Thanks
<Laney> Is this: https://launchpadlibrarian.net/145001004/buildlog_ubuntu-saucy-i386.gst-plugins-bad1.0_1.0.8-1ubuntu1_FAILEDTOBUILD.txt.gz a bug in gst-plugins-bad or the toolchain? It builds on amd64/armhf but not i386/powerpc (but building there using gold does work)...
<infinity> Laney: Probably a link order issue, exacerbated by the silliness of using -nostdlib and -lc (who *does* this?)
<Laney> infinity: AFAICT nostdlib is a libtool-added thing when linking C++ libraries
<Laney> Grah
<Laney> http://stackoverflow.com/questions/10050389/repeating-libs-on-libtool-command-line â something like that does it
<Laney> slomo_: â â have you looked into this?
<cjwatson> pitti: Do you have a minute to give me a hand with PolicyKit?
<cjwatson> pitti: I'm trying to figure out how to tell it that installing click packages through PackageKit doesn't require admin auth
<cjwatson> pitti: At the moment I have the rather inadequate workaround shown in https://bazaar.launchpad.net/+branch/click/view/head:/pk-plugin/README
<seb128> cjwatson, /usr/share/polkit-1/actions/org.debian.apt.policy might be useful as an example?
<pitti> hey cjwatson
<pitti> cjwatson: sure
<cjwatson> seb128: The problem is that the action isn't distinct, so I need to match on the data
<pitti> cjwatson: oh, do we actually use PackageKit for that?
<cjwatson> pitti: I'm planning to
<pitti> cjwatson: aptdaemon has a concept of "high trust" packages, and already has a separate PK action
<pitti> such a counterpart doesn't exist in PK AFAIK, maybe we can add it
<cjwatson> aptdaemon isn't really a brilliant match
<cjwatson> It would be possible, but I've already got most of the rest working in PK
<stgraber> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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: stgraber, smoser
<cjwatson> I think the way you're supposed to do this in PK is to match on the package_ids data it passes to PolicyKit?
<pitti> cjwatson: so one option is to teach PK about such a class of applications that users can install without admin privs
<cjwatson> I can make those package_ids contain "click"
<cjwatson> But I can't work out how to match on that in a policy
<pitti> cjwatson: the other is to write a wrapper which gets run as root, checks the package ID, and calls PK (no password needed if teh caller is root)
<pitti> cjwatson: and then add a pkexec rule that any user can pkexec that wrapper on a local foreground session
<cjwatson> OK, neither of those makes me very happy - I already have a working packagekit plugin and don't desperately want to turn it all inside out
<pitti> cjwatson: you touch a sore point actually
<slomo_> Laney: no, and i don't see what it would help other than working around bugs somewhere else
<cjwatson> And I was really hoping not to have to modify PackageKit to do this, seeing as it *looks* as though I should be able to match on the details it passes?
<pitti> cjwatson: besides the rather static .pkla files current polkit versions have a JavaScript backend which allow this kind of flexibility; but we never got it as it requires mozjs, which is a rather dubious thing to pull into our central priv management
<cjwatson> Yeah, I noticed that
 * ogra_ doubts we would like mozjs on the touch images :)
<pitti> cjwatson: to my knowledge .pkla files can't match on details, only on user, group, session status, and action ID
<cjwatson> Urgh :(
<Laney> slomo_: I don't mean my solution, but the problem in general
<pitti> cjwatson: the original idea was that things like "install a package", "upgrade a package" etc. would be different actions
<pitti> cjwatson: so aptdaemon grew org.debian.apt.install-packages.high-trust-repo
<pitti> cjwatson: it seems the most workable approach right now is a pkexec'ed wrapper which calls PK with the repo/package name as root after checking that it's a click package/appropriate repository/etc/?
<slomo_> Laney: we're doing the same in the gstreamer android makefiles for various things, yes
<cjwatson> pitti: That's problematic since I need to know the calling user
<pitti> cjwatson: is PK actually fast enough for your purposes? last time I tried it it's still really slow
<Laney> slomo_: sec, I found the --preserve-dup-deps option which seems to work
<pitti> cjwatson: $PKEXEC_UID
<cjwatson> pitti: overhead 0.4 seconds, doesn't seem like a problem
<Laney> and seems to be designed for this purpose
<pitti> cjwatson: wow
<cjwatson> admittedly that's in lxc on an x86 laptop, but still, doesn't make me worried
<pitti> so, that'll be a bit of a convergence story blocker, but I guess we can work that out somehow to allow PK and aptdaemon to be co-installable
<cjwatson> If we're still using aptdaemon by the time we converge then I can work out how to make this work with aptdaemon too
<cjwatson> For now it seems like largely a waste of cycles to go through aptdaemon
<pitti> they mostly collide because aptdaemon ships a PK D-BUS compatibility layer
<pitti> cjwatson: of course, with a pkexec wrapper it could just as well call apt :)
<cjwatson> so I don't really understand the pkexec approach; how would that work given that the point of using packagekit here is to provide a d-bus API?
<pitti> cjwatson: root can call any PK-protected API without needing to authenticate
<pitti> cjwatson: i. e. that would do the "detail check" as a program
<cjwatson> ah, hm, right.  I wonder if I mightn't be better off hacking PackageKit to have a way to use a different action here
<pitti> cjwatson: do you actually use the PK signals for progress reports, etc? that would be much more difficult with a wrapper
<cjwatson> pitti: no progress reports worth reporting
<pitti> i. e. if you use signals, then a wrapper makes them hard to use (you'd need to relay them), and if you don't use signals we could just as well call apt in the pkexec wrapper instead of PK which just calls apt in the end, too
<pitti> (or dpkg, or click-install or whatever)
<pitti> cjwatson: download happens separately?
<Laney> slomo_: http://paste.ubuntu.com/5877506/ is what I've come up with
<cjwatson> pitti: haven't hooked up download yet but it's true that will want progress
<cjwatson> pitti: at the moment I'm just implementing install_files - but yes, install_packages ultimately should use the download service to fetch from apps.ubuntu.com or wherever it is and then install that
<mdeslaur> cjwatson, pitti: if you're going to write a pkexec wrapper, might as well not use packagekit and just call the click package installer with pkexec
<cjwatson> mdeslaur: I need a d-bus api, and it's a complete waste of time to invent my own
<cjwatson> I really want to use the pk api for this
<pitti> mdeslaur: yes, that's what I mentioned above as well; download would need to happen unprivileged then, though (i. e. not into some root-owned cache directory)
<cjwatson> so I feel the pkexec idea is interesting but probably a non-starter
<cjwatson> it looks like perhaps having some way to override pk_transaction_role_to_action_* mightn't be too hard
<cjwatson> until such time as we have a policykit where I can match on actions
<cjwatson> er, on details
<pitti> cjwatson: please don't hold your breath on that one; I'm honestly not a big fan of using mozjs for that either
<pitti> cjwatson: conceptually, what's actually wrong with your 10-click.pkla? we don't want people to install any non-app ubuntu package, right?
<Laney> slomo_: (LDADD not LDFLAGS)
<pitti> i. e. it's the division between *-app and "any package" which is the concern here
<cjwatson> well, on the phone, they *can't* install anything else since the system partition is read-only :)
<cjwatson> except in developer mode
<slomo_> Laney: why does it need -lc though? who removes it?
<cjwatson> I'm not very comfortable with leaving it totally wide open in developer mode though, and it just doesn't really feel right
<cjwatson> it'd certainly be a convergence problem
<pitti> cjwatson: yeah, like we don't want an app to install openssh-server wihtout the user knowing
<pitti> (known phablet:phablet user, etc.)
<cjwatson> If I could just get the plugin to override the action to org.freedesktop.packagekit.package-install.click / org.freedesktop.packagekit.package-remove.click, that seems like it'd be good enough for now
<cjwatson> ?
<cjwatson> also - I don't suppose .policy files can match on details, can they?
<pitti> cjwatson: yes, and we could just statically allow that (but preferably only for ResultActive)
<cjwatson> Yeah, I only did the other two because I was bored of going round and round on tiny changes :)
<dobey> what should one do if adt-run broke after the tests passed, and it's causing a package to be held in -proposed?
<cjwatson> dobey: broke as in infrastructure failure?
<pitti> cjwatson: I don't think .policy files can, but let me verify
<dobey> cjwatson: probably. adt-run threw an exception, but looks like it could be casued due to network issues at the time
<dobey> or possibly something else similar.
<cjwatson> dobey: get jibel to retry it
<dobey> jibel: ^^ can you retry software-center autopkgtest run?
<cjwatson> pitti: (though my current lxc instance apparently requires ResultAny=yes - presumably I don't have the right consolekit bits set up or something)
<pitti> dobey: I can also re-run them, so poke jibel and/or me
<cjwatson> or indeed logind
<dobey> pitti: ah ok. can you re-run software-center then? :)
<Laney> slomo_: It's something to do with the stack protector but I don't know why it's not added automatically
<jibel> dobey, done
<jibel> pitti, ^
<cjwatson> akthough I have logind installed here
<dobey> thanks jibel
<ogra_> cjwatson, our session doesnt register with it yet
<cjwatson> ogra_: this isn't touch, it's an lxc instance, but noted
<ogra_> ah, k
<pitti> cjwatson: (FTR, no details matching in *.policy)
<cjwatson> pitti: drat
<pitti> cjwatson: so dynamically changing the action in your plugin sounds like a nice approach
<pitti> cjwatson: and no details matching with the mozjs version either, so at least that's not what's blocking us
<cjwatson> oh, really?  I thought I read it was possible there
<cjwatson> though the policykit documentation is ... less than ideal
 * ogra_ waits for the point where cjwatson just decides to fall back to /etc/sudoers.d/ :)
<cjwatson> I don't mean to be annoying in rejecting the proposed solutions above, btw - partly I'm just reluctant to go back and redo several days of work with a demo deadline upcoming
<pitti> cjwatson: ah, maybe thourgh action.lookup('DETAIL') or so, but it's not documented explicitly
<pitti>    if (action.id.indexOf("org.freedesktop.udisks2.") == 0 &&
<pitti>         action.lookup("drive.vendor") == "SEAGATE" &&
<pitti> so indeed, with the mozjs bits one could most probably do that
<cjwatson> fortunately this isn't a demo blocker as such - can always specially prepare the image
<cjwatson> but would be nice not to have to
<infinity> cjwatson: Would it upset you terribly for grub2-signed to have a hard '=' dep on grub2, so grub2 can't migrate without signed being uploaded to match?
<cjwatson> infinity: not especially
<infinity> Right, I think I'll go and invalidate my last upload with another that does that, then.
<qengho> What is the behavior when a source package has some "any" and "all" arch packages? Not all builders make the "any" arch-independent package. I wish to be able to know from the environment in debian/rules if my sanity test should pass.
<qengho>  [the test verifies we packaged everything that the upstream "install" intended us to take]
<infinity> qengho: You mean not all builders make the "all" packages. :P
<qengho> I deleted some hard-coded "i386" madness yesterday, but it turns out it did something, and I'd like to do it the right way.
<infinity> qengho: In Ubuntu, the case is currently that i386 builds with "-b" and all other arches with "-B", meaning i386 produces the arch:all packages.  Relying on this to always be true wouldn't be ideal, however.
<qengho> Right.
<cjwatson> You can use dh_listpackages, or you could run your checks only in binary-arch
<cjwatson> (or dh_override_foo-arch)
<cjwatson> (the latter only available with debhelper >= 8.9.7)
<qengho> infinity, cjwatson: thank you. That helps.
<infinity> qengho: Anyhow, once you've come up with a plausible solution (via Colin's above hints, perhaps), you can test locally with "debuild -b" versus "debuild -B", there's nothing magic happening on the buildd side.
<qengho> infinity: Yep.  "bzr bd -- -B" I suppose will do it.  Testing now.
<dholbach> barry, did you hear back from mandel about the downloader packaging?
<barry> dholbach: last week, i heard it was in progress.  we talked about a few details (e.g. # binary packages, etc.) so i believe it is in progress.  no word since then
<cjwatson> pitti: so perhaps something a bit like http://paste.ubuntu.com/5877680/ for current pk master
<cjwatson> I'll need to backport that to 0.7 to test it though
<cjwatson> oh, and I suppose a .gir change
<pitti> cjwatson: nice and generic
<pitti> hughsie is very cooperative usually, so hopefully won't be too difficult to land this
<dholbach> barry, ok
<dholbach> barry, I just thought that it'd be good for it to land on the image soon, so folks can start integrating it in other places too - and it already looks like there's a lot of functionality in there
<slangasek> pitti: yes, I think /system/firmware and /vendor/firmware should be dropped again from udev for the time being
<barry> dholbach: agreed.  i need to find out where that's at.
<dholbach> barry, https://code.launchpad.net/~ubuntu-system-image/ubuntu-system-image/downloader is the link I was given last
<achiang> popey: i don't need a random hostname generator, as we already have discovered the best hostname in the history of hostnames, ever.
<dobey> jibel: the jenkins.qa.ubuntu.com is a mirror of the result data right? is there any way to see the jobs queue?
<sergiusens> dobey: it's just used for publishing, all jobs are behind a vpn
<jibel> dobey, jenkins.qa.u.c only publish the results once the test is done, before that the job queue is only visible on the private instances
<jibel> and build 44 of s-c is still running
<rbasak> infinity: I have a php5 merge ready. Apparently it's not in the server set though, so I can't upload :-/
<rbasak> I just assumed that php would be!
<rbasak> Daviey: do you think ~ubuntu-server-dev should be able to upload php5? Do you know why it can't? I'm not sure I really followed the way the set is determined.
<stgraber> rbasak: the server team packageset is auto-generated from the seeds, it's not something we manage manually
<stgraber> but even so, I'm surprised php5 wasn't included by the update script...
<rbasak> stgraber: right, but how? Anything seeded by server or server-ship?
<stgraber> ah, it's in core, so that may have been becaused flavours are also seeding it (at least mythbuntu appears to be)
<stgraber> I "think" that cjwatson's script puts packages in core when they're in use by multiple flavours (in this case server and mythbuntu), but we can probably have php5 be added as an exception to that rule
<cjwatson> I have a set of exceptions, yes
<cjwatson> Will add
<rbasak> Thank you
<rbasak> http://paste.ubuntu.com/5877847/ is my debdiff if anyone wants to sponsor it sooner.
<cjwatson> No point, it'll take minutes at most
<rbasak> OK, thanks.
<cjwatson> rbasak: done
<dobey> can anyone tell me why ubuntuone-client is held in saucy-proposed?
<rbasak> Thank you!
<dobey> jibel, pitti: ^^ i don't see a job for ubuntuone-client on the public jenkins page, but maybe there was an infrastructure problem there too?
<cjwatson> er it has nothing to do with them
<cjwatson> dobey: looks like it needs some binaries decrufted; looking
<dobey> oh
<dobey> cjwatson: ah ok. wasn't sure since i added autopkgtests in that upload as well
<dobey> thanks
<cjwatson> they don't appear to have been run
<infinity> Decrufting shouldn't be necessary, one would think...
<cjwatson> that's odd, but it isn't blocking -proposed
<infinity> NBS doesn't typically block migration unless there are NBS binaries in proposed.
<cjwatson> infinity: slightly odd but perhaps the result of (includes-arch-dep) -> (doesn't) transition
<infinity> cjwatson: Oh, all<->any can definitely cause a sad, I've seen that.
<infinity> Though, in this case, nothing's changed archiness.  But I guess the lack of builds at all on !i386 is confusing.
<cjwatson> anyway, it would have been stuck on ubuntuone-client-gnome needing to be removed even without that
<cjwatson> dobey: I should interpret bug 1196684 as a removal request for the ubuntuone-client-gnome source?  ubuntu-archive isn't subscribed
<ubottu> bug 1196684 in ubuntuone-client-gnome (Ubuntu) "Drop ubuntuone-client-gnome from archive" [Undecided,New] https://launchpad.net/bugs/1196684
<dobey> cjwatson: yes; i was going to subscribe -archive after i got the other two bits fixed, to avoid the hassle of someone saying "it will break these other things" :)
<dobey> cjwatson: why would ubuntuone-client be stuck on ubuntuone-client-gnome needing to be removed? because i removed the lib that -gnome depends on?
<cjwatson> well, done now
<cjwatson> dobey: yes
<dobey> ah ok
<dobey> thanks much
<cjwatson> avoiding that kind of breakage is 90% of the point of proposed-migration :)
<cjwatson> and decrufted now too, so that should help ubuntuone-client migrate
<dobey> great
<dobey> infinity: i guess because the source went any->all, though the binaries didn't change, would have hit that flag
<pitti> StevenK, wgrant: a PPA lplib object doesn't have getPackageUploads(); how would I get the raw translation tarballs from a PPA build like https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4763305 ?
<pitti> jibel: ^ can you take this? (no autopkgtest run for ubuntuone-client in saucy-proposed); need to run, and TBH I don't know why it doesn't appear in jenkins
<jibel> pitti, I'll take it
<jbicha> I wonder why saucy-changes is updating itself on such a delay
<seb128> jbicha, you mean?
<infinity> jbicha: Delayed mails on -changes aren't usually the list's fault, but launchpad's MTA having a bit of a sad.
<jbicha> seb128: apparently there have been no saucy uploads today since 03:00 UTC https://lists.ubuntu.com/archives/saucy-changes/2013-July/
<seb128> jbicha, oh, the archive ... the list is actually working fine
<jbicha> maybe I should subscribe...
<infinity> seb128: You have recent uploads on the list (like php5?)
<seb128> infinity, [ubuntu/saucy-proposed] system-image 0.6-0ubuntu1 (Accepted)
<seb128> is the most recent I got
<seb128> it's from half an hour ago
<seb128> php5 was just before it
<seb128> infinity, so, yes
<infinity> seb128: Kay, thanks for the anecdote.  Harassing someone about the archive being stalled. :P
<seb128> ;-)
<bdmurray> barry: I'm not having any luck verifying bug 1078697 using the provided test case
<ubottu> bug 1078697 in apt (Ubuntu Lucid) "Ubuntu archive is missing SHA-1/SHA-256 hashes for some packages" [High,Triaged] https://launchpad.net/bugs/1078697
<barry> bdmurray: looking
<barry> bdmurray: i wonder if the affected packages need to be rebuilt?
<bdmurray> barry: oh sorry, I mean I don't think it is failing for me with the apt in -updates
<bdmurray> barry: http://pastebin.osuosl.org/2587/
<barry> bdmurray: that pastebin is failing because there are no checksums in the output
<barry> bdmurray: http://paste.ubuntu.com/5878113/
<barry> (well, ignore the 1.0.0 version)
<barry> bdmurray: http://paste.ubuntu.com/5878120/
<dobey> jibel, pitti: looks like s-c failed again in the same way, with adt-run crashing. :(
<bdmurray> barry: got it, thanks
<jibel> dobey, this is a crash that happens when adt-run times out, so the real is elsewhere in the testsuite. Is there a test that requires access to internet resources?
<jibel> s/real/real failure/
<jibel> dobey, I'll re-run the testsuite and check what happens in the vm
<dobey> jibel: i have no idea what the tests do there. :)
<dobey> Laney: ^^ do you know?
<Laney> i'll check what you uploaded tomorrow
<Laney> dobey: but I was testing it with the stuff from lp:auto-package-testing if you want to do the same
<Laney> http://developer.ubuntu.com/packaging/html/auto-pkg-test.html#executing-the-test
 * Laney waves
<stgraber> cjwatson: when you have a minute, can you let through the e-mail I just sent to ubuntu-devel-announce
<dobey> what's the best way to get the architecutre in debian/rules with pure dh, to use in an if statement?
<slangasek> dobey: for policy compliance, you still want to query dpkg-architecture directly; e.g., DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
<slangasek> in practice this is usually already set in the environment by the build wrappers, but a package shouldn't rely on this
<dobey> ah, thanks slangasek
<cjwatson> stgraber: done
<stgraber> cjwatson: thanks
<stgraber> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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: smoser
<Noskcaj> roaksoax, kirkland: do either of you have a time for a testdrive "hackfest" or can you make a page explaining all the functions in testdrive? Either would hugely boost contributions to testdrive
<wgrant> pitti: distroseries.getPackageUploads(archive=archive)
<kirkland> Noskcaj: hi there...  okay, so here's the quick intro
<kirkland> Noskcaj: bzr branch lp:testdrive
<kirkland> Noskcaj: and you'll get the source
<kirkland> Noskcaj: the majority of the logic is in:
<Noskcaj> kirkland, I think howard and i could work out that much
<kirkland> Noskcaj: testdrive/testdrive.py
<Noskcaj> yes
<kirkland> Noskcaj: there's a handful of variables that define default virtualization options, but enable advanced users to make their own tweaks
<kirkland> Noskcaj: those can be set at the system level or at the individual user level
<kirkland> Noskcaj: in /etc/testdriverc or ~/.testdriverc
<kirkland> Noskcaj: we support a good number of Ubuntu flavors;  I understand you're interested in adding Kylin, which is cool
<Noskcaj> kirkland, i don't think you understood me. The idea of the hackfest (even if it's at a time howard and i can't get to), is to get new people involved and to have you and andres help everyone fix the rather large list of bugs testdrive now has.
<Noskcaj> the fact it's missing kylin, gnome, studio and i think edubuntu is the main thing
<kirkland> Noskcaj: okay, sorry, I did not understand you
<kirkland> Noskcaj: I thought that you personally wanted a tour of the code
<Noskcaj> kirkland, maybe some other time when i'm not getting ready for school. Either way it's more aimed at everyone willing to help, rather than just me
<kirkland> Noskcaj: I'm really sorry, but to be perfectly frank, that's not all that interesting to me
<kirkland> Noskcaj: it's pretty straightforward Python
<kirkland> Noskcaj: if people want to start attaching good patches and branches to open bugs, that's phenomenal, and I'll be happy to merge and release them
 * kirkland doesn't mean to sound like a jerk, he's just a busy guy
<Noskcaj> ok. That reminds me of the other thing, can you try and get someone else as an admin, you and andres are normally busy
<Noskcaj> If you do have a little bit of spare time, please look at howard's kylin merge. No one can work out what's wrong
<kirkland> Noskcaj: we will extend commit rights as soon as someone earns the privilege
<Noskcaj> ok
<kirkland> Noskcaj: that said, absolutely any MOTU in ubuntu can upload new versions of Testdrive, and are welcome to do so
 * kirkland looks at howard's branch
<Noskcaj> I'm mostly meaning commit stuff and fix the info page on launchpad (#testdrive doesn't exist).
<Noskcaj> :)
<kirkland> Noskcaj: description fixed.
<Noskcaj> thanks, If you wanted somewhere to still be support, maybe link #ubuntu-quality
<kirkland> Noskcaj: can you point me to the branch you want reviewed?
<Noskcaj> We know it, and the current release of testdrive won't open, but for different reasons. I was hoping you would be able to work out what broke. https://code.launchpad.net/~smartboyhw/testdrive/lp-fix-ubuntukylin-1170617
<kirkland> Noskcaj: I don't see anything obviously wrong in the review of the patch; let me test it
<Noskcaj> FYI: I don't think the branch is based on revision 413
#ubuntu-devel 2013-07-16
<hyperair> could anyone help with bug #1196828?
<ubottu> bug 1196828 in banshee (Ubuntu) "Cannot restart banshee after crash" [Undecided,Incomplete] https://launchpad.net/bugs/1196828
<hyperair> why would a process be <defunct> yet not get reaped by pid 1?
<RAOF> hyperair: Because it's a zombie? (ie
<hyperair> RAOF: zombies that have ppid=1 should be reaped immediately
<hyperair> RAOF: this one is a zombie that has ppid=1, but hasn't been reaped.
<RAOF> Hm.
<hyperair> http://unix.stackexchange.com/questions/11172/how-can-i-kill-a-defunct-process-whose-parent-is-init <-- this one doesn't have a solution either
<hyperair> i'm wondering if there's a kernel bug somewhere..
<pitti> wgrant: aah, thanks
<pitti> dobey: yeah, the s-c test times out (it's just a very ugly error message)
<pitti> dobey: as jibel said, if it works for you locally and with run-adt-test, supposedly it's trying to talk to some network server without a proper timeout?
<tvoss_> pitti, ping
<pitti> hey tvoss_
<dholbach> good morning
<cjwatson> xnox: Could you merge libkolabxml?  A new upload is needed for the php5.5 transition, and it might as well be a merge (or sync if appropriate).
<pitti> jibel: OOI, what was the reason for ubuntuone-client not getting an autopkgtest?
<pitti> jibel: (I just got a bunch of failure email which reminded me)
<jibel> pitti, I noticed last week that when a package is uploaded with tests for the first time, the test request is not submitted. Then if a dependency of this package changes then the job is created.
<jibel> pitti, I have not been able to reproduce the problem and find what causes it yet
<jibel> dobey, s-c tests hang on test_dataprovider on both archs, here is the output http://paste.ubuntu.com/5880305/ not much information though.
<Laney> jibel: Ah, I meant to disable that one
<Laney> dobey: jibel: Wait, none of the ones I disabled are actually disabled in the source
<Laney> Looks like the tarball wasn't generated quite right
<xnox> jibel: colord auto-pkg-test is a mistery to me, it has always failed (and now blocking my fix to transition). It looks like the tree does get built, but the test do not run from it, as there is no Makefile.
<RAOF> xnox: I thought pitti marked that one?
<pitti> not me personally, but (I think) infinity did
<xnox> .... but i now uploaded a new version, I guess the hint needs a version bump
<Laney> yes
<xnox> Laney: please bump, version hint on colord.
<Laney> ok
<Laney> but it's an incentive to look at fixing them
<pitti> xnox: I guess you see debian bug 711209
<ubottu> Debian bug 711209 in autopkgtest "autopkgtest: build-needed restriction doesn't actually run tests in built tree" [Normal,Open] http://bugs.debian.org/711209
<xnox> pitti: jibel: how come it says needs-build, yet the tree the tests are run from is not built.
<xnox> ah!
<pitti> xnox: I added a cheesy workaround for that in umockdev
<pitti> xnox: but it only happens if you do run-adt-test -S file://your..branch, not when running the tests from the archive
<xnox> pitti: I like that workaround.
<pitti> # work around broken "build-needed" behaviour (Debian #711209)
<pitti> RT="$ADTTMP/../../ubtree0-build/real-tree"
<pitti> [ -d "$RT" ] && cd "$RT" || true
<pitti> xnox: *cough*
<Laney> haha
<Laney> I thought you'd have done the build yourself
<RAOF> xnox: I've fixed the colord autopkgtests here; where are your changes, so I can fold them in?
<RAOF> xnox: I'll pull them out of -proposed, I guess?
<xnox> RAOF: yeah lp:ubuntu/saucy-proposed/colord is up to date.
<infinity> jibel: *pokity poke*
<infinity> jibel: WTF does the autopkgtest for linux do, and why does it never seem to end?
<infinity> cjwatson: Or is this a binary/source confusion bug?
<infinity> cjwatson: (Possibly, since it seems to be testing "linux/3.10.0.3.12", which is actually a metapackage from linux-meta...)
<ogra_> infinity, there seem to be jenkins issues, i wonder if that also affects that
<infinity> ogra_: This isn't the first time I've seen this, I've just forced it in the past because the kernels were vaguelt urgent.
<infinity> vaguely*
<ogra_> (serveral machines had power outages over night)
<jibel> infinity, "ld: final link failed: No space left on device", I'll adjust the size
<ogra_> heh, unrealted then :)
<xnox> OMG! https://github.com/mame/quine-relay
<infinity> jibel: So, I'm awful at navigating the Jenkins "UI" (and I use that term generously)... How do I find this?
<infinity> I'm still not convinced there isn't also a bug here with the source/binary version confusion.
<jibel> infinity, line 19926 of https://jenkins.qa.ubuntu.com/job/saucy-adt-linux/ARCH=amd64,label=adt/55/consoleText
<infinity> xnox: That's perverse.
<infinity> jibel: Ahh, special.
<infinity> jibel: Also probably a crap test to be run every time linux-meta is uploaded.  Is there a way to skip some dependency chains?
<infinity> jibel: (Given that's a compile test, which we want to run when some other deps are uploaded, but it's pointless to run it when meta is uploaded since we JUST BUILT THE KERNEL) :)
<jibel> infinity, there is no such way to skip some dependency chain in autopkgtest.
<jibel> In this case the test has been triggered by the upload of linux-signed
<infinity> jibel: Yeah, I realised that after I mentioned linux-meta.
<infinity> jibel: Though, I'd expect both to trigger it...
<smb> I saw this line on a few dist-upgrade runs after config dialogue boxes (just now again on Saucy). I don't think it is a real problem but maybe someone would want to know about it: Undefined subroutine &conffile::abs_path called at /usr/bin/ucfg line 529 <HASH> line 6.
<tvoss> pitti, ping
<infinity> smb: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709567
<ubottu> Debian bug 709567 in ucf "Undefined subroutine &conffile::abs_path called at /usr/bin/ucfq line 529, <HASH> line 13." [Grave,Fixed]
<infinity> smb: Already in -proposed.
<infinity> And would have migrated, if the mailman autopkgtest didn't fail.  Hrm.
<smb> infinity, Ah thanks. Maybe I should have searched LP just that I seem not very successful on that
<infinity> jibel: Okay, time for me to be annoying again, I have *no* idea how to read the mailman adt failure.
<pitti> tvoss: hey
<cjwatson> infinity: Is that not a straight test failure?
<cjwatson> (https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-mailman/7/ARCH=amd64,label=adt/artifact/results/log)
<jibel> infinity, https://jenkins.qa.ubuntu.com/job/saucy-adt-mailman/7/ARCH=amd64,label=adt/artifact/results/dsc0t-mailman-stdout
<infinity> Oh, indeed.  Navigating jenkins hurts my head.
<cjwatson> I wonder if that's actually a regression from Apache 2.4
<jibel> several tests fails with a 404
<infinity> I never know if I want random build artifacts or console output, or...
<infinity> Anyhow, it shouldn't block ucf, afaict.
<cjwatson> (Also, why do the Jenkins autopkgtest runs not show full apt-get output from installing dependencies, while adt-run by hand does?
<cjwatson> )
<dholbach> barry, did you have a chat with mandel already? :)
<barry> dholbach: waiting for a pong ;)
<tseliot> pitti: if I wanted to let a Jockey handler install another package in addition to the driver, shall I use backend.install_package() or is there a better way to do it?
<pitti> tseliot: that's fine to use
<tseliot> pitti: ok, thanks
<infinity> chiluk: When doing apt SRUs, it's nice to not generate thousands of lines of cruft by using a different version of autotools...
<dobey> Laney: what do you mean "the tarball wasn't generated quite right" exactly?
<Laney> dobey: The tests I disabled aren't disabled in there
<infinity> chiluk: (Alternately, just apply your patch and build with -nc, so it doesn't regen the autotools bits at all)
<dobey> Laney: you submitted a branch after i'd made the tarball. i included the patch in debian/patches/
<dobey> Laney: so if they aren't disabled, i guess that patch isn't being applied for some reason in the test run?
<Laney> dobey: Oh, well the patch is broken then
<Laney> Those === renamed file things aren't going to do anything
<dobey> you renamed files?
<Laney> yes
<dobey> oh
<dobey> why did i approve that :(
<Laney> hahaha
<dobey> i didn't notice that part
<Laney> It's how other tests were disabled in there
<Laney> so I just copied that
 * dobey is inclined to just rm -rf debian/tests and call it a day
<Laney> that would be quite extreme
<Laney> loads of them still work
<dobey> the archive builds for arm all happen on real hardware?
<infinity> dobey: Yes.
<xnox> though cosmic rays add a splash of surrealism on panda boards.
<ogra_> yeah, they have builtin cosmig ray collectors
<ogra_> *cosmic
<ogra_> its like the opposite of a tinfoli hat
<ogra_> want more rays ... wear a pandaboard
<dobey> ogra_: i keep trying to collect cosmic rays, but the neutrinos just keep passing through everything I put in front of them.
<ogra_> heh
<didrocks> jbicha: wrong dput?
<didrocks> 7.0.2+13.10.20130715.1-0ubuntu1~ppa1
<jbicha> didrocks: ooops
<didrocks> jbicha: can you get it blacklisted/removed? this version is untested
<didrocks> (70 failures in trunk last tests results, so better to not push the unknown)
<didrocks> sil2100: FYI, we'll maybe need to include the dummy changelog as well in trunk ^
<jbicha> Laney: can you kill that ^
<didrocks> and blocked it in proposed
<Laney> I'm guessing an AA could remove it
<didrocks> Laney: hum, I'm unaware how to do that though
<didrocks> complete removal of a package yes, a specific versionâ¦
<didrocks> and blocking proposed -> release so that it's not copied by errorâ¦
<jbicha> I guess I need to look into getting dput-ng to block uploading ~ppa to ubuntu as penance
<Laney> didrocks: remove-package -s saucy-proposed?
<cjwatson> remove-package has a --version option too
<Laney> IANAAA :-)
<jbicha> if the package is deleted I assume you won't need to touch trunk's debian/changelog
<didrocks> jbicha: I hope so :)
<cjwatson> (remove-package is actually remove-publication; it's just called remove-package because the more accurate name is not what most people would reach for)
<didrocks> cjwatson: ok, I got puzzled, thanks for the trick
<cjwatson> Anyway, you can certainly use -s saucy-proposed and just look at the prompt carefully
<didrocks> cjwatson: Laney: jbicha: done
<Laney> great
<didrocks> yeah, it matches :)
<Laney> another yay for proposed
<jbicha> I never used to have upload rights for unity
<jbicha> with daily landing, I don't particular want those rights either
<doko> ScottK, yofel, Riddell: I don't like the additional dependencies in pkg-kde-tools. makes a bootstrap harder. is lintian really needed, or can it be made a recommends?
<Laney> jbicha: I guess you could get such a hook included upstream
<Laney> please do write it
<yofel> doko: well, it is run during the kde builds, so I need some dependency that will pull it on the buildds
<yofel> it's not totally required though, we just don't really have any other easy way to run it
<doko> yofel, is lintian really run during a package build?
<yofel> doko: yes, because that's a lot easier than running it by hand over some ~160 packages
<doko> sorry, but this is insane
<yofel> I'm open for better ideas
<doko> infinity, lamont: is it finally time to run lintian after every build? this kde insanity is worse ...
<doko> or wgrant: ^^^
<infinity> Could be something done as part of proposed-migration.  I'm not sure it belongs in the soyuz/buildd realm.
<cjwatson> We have lintian.ubuntuwire.org
<cjwatson> Though somebody needs to update that to saucy, apparently
<infinity> Then again, I'm not happy with lintian *blocking* anything, so yeah, ubuntuwire seems sane enough an option.
<cjwatson> broder_: ^- IIRC that was your baby?
<cjwatson> I'd like to run lintian with something like the Debian ftpmaster profile as part of archive accepts, but not a high priority IMO
<yofel> doko: considering we need it mostly for our work-in-progress builds, I'll remove it from the archive package for now and just put a seperate build in our PPA.
<doko> yofel, that would be nice, yes
<broder_> cjwatson: mmm, yeah, i can get it kicked over to saucy. will try to kick it off today
<cjwatson> Ta
<doko> cjwatson, should we add updating that to the release opening procedures?
<cjwatson> doko: Feel free (NewReleaseCycleProcess)
<yofel> doko: lintian removal uploaded
<doko> yofel, thanks!
<chiluk> infinity, in regards to the apt sru...  sorry about that...
<chiluk> I swear I checked my bzr patch/commit, and didn't think that debuild -S would muck with the sources... I'll check my debdiff next time.
<Riddell> doko: yofel: could it be made a recommends?
<yofel> Riddell: afaik the buildd's use --no-install-recommends
<yofel> but maybe I'm wrong
<yofel> doko: ^ ?
<doko> yofel, yes, recommends would work
<doko>  1. Notify William Grant to update the ftbfs on qa.ubuntuwire.com.
<doko>  1. Notify Evan Broder to update lintian.ubuntuwire.com.
<doko>  1. Notify N.N. to update packages.ubuntu.com.
<doko> cjwatson, ^^^
<Laney> Rhonda
<doko> for packages?
<Laney> yep
<yofel> doko: oh ok, then I'll make that a recommends instead
<doko> Gerfried Fuchs?
<Laney> correct
<Laney> It says that on the index of p.u.c IIRC
<Riddell> thanks yofel
<infinity> chiluk: Well, perhaps I should reject it and we should re-do it.  It's a pretty painful diff as it stands.
<chiluk> infinity, that's fine with me... I'm up for figuring out how to do it better.
<chiluk> infinity give me a few, I'll upload a new debdiff shortly.
<chiluk> infinity the patch has already been correctly applied to lp:~ubuntu-core-dev/apt/precise .... do you still need a debdiff between the two revs?
<doko> yofel, Riddell: one more thing, does qt4-x11 have the b-d on pkg-kde-dev for this convenience, or is it really needed?
<yofel> doko: it needs it for the pkgkde_symbolshelper dh addon
<doko> yofel, yes, which is a bit problematic, because pkg-kde-dev needs qt to build :-/
<doko> so I think, I'll need to define a stage1 build for that to succeed ...
<infinity> chiluk: Oh, if it's a small and sane patch in the branch, I can just reupload it without the cruft.  Gimme a sec.
<chiluk> yeah ..
<chiluk> it's rev 2009
<yofel> doko: are we still talking about pkg-kde-tools? that doesn't need qt4 to build
<chiluk> at lp:~ubuntu-core-dev/apt/precise
 * yofel needs to run
<chiluk> infinity I'm still trying to figure out how I could have generated the debdiff such that the cruft didn't get generated.
<hallyn> slangasek: would you object to mountall adding nobootwait to the /sys/fs/fuse/connections and /sys/kernel/debug entries in /lib/init/fstab?
<chiluk> infinity I bzr cloned the branch ... ran debuild -S... patched ran debuild -S... and ran the debdiff against the resulting .dsc files.
<chiluk> are you saying I should have debuild -S -nc in both cases?
<slangasek> hallyn: why should they be nobootwait?
<infinity> chiluk: -nc would have worked.  Or using the same versions of autotools used in the previous build.
<slangasek> hallyn: they're kernel filesystems, they should be available immediately and should not cause boot delays due to mounting
<hallyn> slangasek: because they can't be mounted in a non-init user namespace
<hallyn> slangasek: well ideally 'optional' would mean ignore failure to mount
<hallyn> and i think it used to.  but since quantal it does not
<slangasek> hallyn: then 'nobootwait' is definitely the wrong flag for this
<hallyn> (in precise it does)
<hallyn> the fstab manpage says optional is only optional if the fs is unknown, unfortunately.
<hallyn> "fs is known, directory exists, but permission is denied" leads to hang
<hallyn> would you feel ok with changing that?
<slangasek> hallyn: 'optional' means 'ignore if the filesystem type is unsupported'
<hallyn> (like i say, in precise it did not lead to a hang)
<chiluk> infinity, are you looking at this debdiff? https://launchpadlibrarian.net/144802808/apt-fix-keep-alive.debdiff   because the only thing I see different is version number increments... my debuild -S was built with the same version of the tools.... sorry for being a noob with debian packagin.
<hallyn> slangasek: it also will ignore if the dir does not exist
<hallyn> (not according to the manpage, but if i read the code correctly)
<slangasek> hallyn: the behavior of treating mount failures as errors is quite deliberate; though it gets dicey when the failure is for a kernel filesystem, because that means you never get to plymouth to bypass the prompt.  Let me check some history on this
<slangasek> hallyn: so the right option here would be 'nofail'
<infinity> chiluk: I'm looking at the one uploaded.
<slangasek> however, see also bug #610869
<ubottu> bug 610869 in mountall (Ubuntu) "mountall ignores nofail mount option" [Medium,Triaged] https://launchpad.net/bugs/610869
<zul> mterry:  ping
<hallyn> slangasek: that doesn't work
<infinity> chiluk: http://launchpadlibrarian.net/145039448/apt_0.8.16~exp12ubuntu10.11_0.8.16~exp12ubuntu10.12.diff.gz
<mterry> zul, hi
<infinity> chiluk: Was that rebuilt by a sponsor, perchance?
<infinity> chiluk: Cause your debdiff is fine, I agree.
<slangasek> hallyn: it doesn't /work/, but it's the right flag to use ;)
<hallyn> ok
<slangasek> hallyn: mountall just needs to be fixed so that 'nofail' DTRT
<zul> mterry:  quantum and quantumclient got renamed to neutron and neutronclient whats the process for the MIR stuff for a source rename?
<hallyn> slangasek: well the manpage says "ignore errors for this device if it does not exist"
<chiluk> infinity, yeah bdmurray was likely the sponsor.
<hallyn> slangasek: i'm fine using nofail, just saying it doesn't 100% match the manpage
<slangasek> hallyn: also, bug #1152274
<ubottu> bug 1152274 in mountall (Ubuntu) "filesystem mount failures during boot halt boot with a blank screen" [Medium,Triaged] https://launchpad.net/bugs/1152274
<infinity> chiluk: Ahh, kay.  I'll re-sponsor it sans cruft.
<mterry> zul, you could file it and say such and it would be rubber stamped, alternatively maybe just poke an archive admin
<slangasek> ah; I think that should be changed in the manpage
<zul> mterry: ok cool
<slangasek> because with mountall, if the device doesn't exist there's never an error at all
<hallyn> slangasek: yeah i could repurpose that bug...
<chiluk> alright thanks infinity it's committed cleanly in the repo.
<hallyn> slangasek: would you want me to use that bug and provide a patch to use nofail?
<hallyn> slangasek: (or had you already started that?)
<infinity> zul: It doesn't need an MIR at all, if it's a straight rename.
<infinity> zul: Will need a bit of a NEW review for sanity, that's all.
<zul> infinity:  sweet
<slangasek> hallyn: well, that bug report is specifically about the silence of the hang; I wouldn't repurpose that bug, but if you're digging in this area of the code maybe you want to fix that bug too :)
<slangasek> hallyn: I'm happy for you to provide a patch to use nofail for these two mountpoints and to make nofail DTRT
<hallyn> slangasek: well, i only mentioned the two - alas /sys/kernel/security is also a problem for me
<hallyn> slangasek: alternatively, we could say "if in a container, ignore any kernel fs mount failures"
<slangasek> I wouldn't want to say that as a policy
<slangasek> however, you *could* override the mount options for these in /etc/fstab
<slangasek> that way, the container setup can configure things precisely for the way the container works, and mountall doesn't have to concern itself with the differences (which may change over time)
<hallyn> slangasek: well long as we're bastardizing the container I can just do /lib/init/fstab as well - we used to do that in maverick days.  problem is that leads to different rootfs for in or out of a container
<slangasek> ah
<slangasek> are there any container support packages included in the container root?
<chiluk> infinity, make sure to give me credit for the upload  ... I'd like to start applying for ubuntu-contributing dev here soon
<hallyn> certainliy nofail makes sense for debug and fuse/connections.  but from a hardware install pov, /sys/kernel/security seems inappropriate to be nofail :)
<slangasek> that is, packages which wouldn't be included in a standard system that's not being used as a container
<hallyn> slangasek: container creation no longer does any container-specific package install
<slangasek> right, making some of these nofail for non-container systems does make me a little anxious ;)
<hallyn> stgraber pushed a lot of that back to mountall/upstart etc
<hallyn> i suppose 'containernofail' could be added as a mount option :)
<slangasek> I'd really prefer not having to make mountall.c know what a container is
<hallyn> yeah
<hallyn> as an upstream-unacceptable fix we could have the kernel return success for those mounts and do a tmpfs mount :)
 * hallyn thinking outside the box like a pro
<slangasek> how about making them disappear from /proc/filesystems within the container? ;)
<infinity> chiluk: Also, from an "ew, ick" stylistic perspective, there's no readon to have the multi-maintainer header [ Bob Smith ] in an upload where the only change is by Bob Smith, and the uploader is also Bob Smith.
<hallyn> note it's not just 'in a container' but in a non-init user namespace.  lemme see how the code loks for that
<slangasek> hallyn: I don't understand the distinction there
<infinity> chiluk: I think I'll twiddle that before I upload, just because I'm OCD.
<chiluk> fine with me.
<chiluk> when I wrote the changelog entry, I think I was looking at the earlier changelog entries..
<infinity> chiluk: As a general rule, dch will DTRT and only add that header if someone else has done a change in the same version.
<chiluk> ah ok...
<bdmurray> barry: could you have a look at bug 771404 which is similar to bug 846044 which you worked on?
<ubottu> bug 771404 in dbus-python (Ubuntu) "aptd crashed with UnicodeEncodeError in _method_reply_error(): 'ascii' codec can't encode characters in position 20-28: ordinal not in range(128)" [Medium,Confirmed] https://launchpad.net/bugs/771404
<ubottu> bug 846044 in aptdaemon (Ubuntu Quantal) "software-center crashed with UnicodeEncodeError in get_dbus_message(): 'ascii' codec can't encode character u'\xfc' in position 65: ordinal not in range(128)" [Critical,Fix released] https://launchpad.net/bugs/846044
<hallyn> slangasek: if you do clone(CLONE_NEWUSER), the cloned task cannot mount those filesystems
<hallyn> now really, so long as all the files will be owned by host root, i suppose we coudl simply enable those mounts
<slangasek> hallyn: and why would you run clone(CLONE_NEWUSER) and expect to run mountall under it?
<hallyn> slangasek: so as to run a container inside a user namespace
<hallyn> why *wouldn't* i? :)
<hallyn> yeah lemme try just adding FS_USERNS_MOUNT to those file_system_type defs
<Elv1313> Hi, what is the official Contact API if I want to access Contacts from my Ubuntu Phone application?
<slangasek> hallyn: so is the point there that this doesn't affect *all* containers, only those using CLONE_NEWUSER?
<cjwatson> rbasak: We need another php5 merge to introduce dh-php5, I'm afraid.  Do you want to do that or shall I?
<hallyn> slangasek: correct.  normal containers start fine
<cjwatson> rbasak: (working through http://people.canonical.com/~ubuntu-archive/transitions/php5.5.html)
<rbasak> cjwatson: I can do it tomorrow, before lunchtime, if you like? I'm >EOD now.
<cjwatson> Cool, thanks
<cjwatson> I'm EOD soon too
<slangasek> hallyn: ah, ok.  So ideally we would ignore mount failures *only* when CLONE_NEWUSER is in place.. but I think we don't have a sane way to detect that
<cjwatson> rbasak: (I also just merged json-c, so it should be possible to make php-json build soon.)
<rbasak> I noticed Debian had updated since I started, but I figured that going from where I was would unblock things and I could catch up again at my leisure. Looks like I was wrong.
<cjwatson> rbasak: It unblocked most of it and I was certainly able to move on, just not quite all
<hallyn> slangasek: we could detect it with /proc/self/uid_map
<hallyn> slangasek: but let me see if just allowing those mounts looks at all problematic
<slangasek> hallyn: encoding that in mountall == not sane ;)
<hallyn> slangasek: agreed
<cjwatson> rbasak: In particular, xcache wants dh-php5
<cjwatson> rbasak: The number of interleaved transitions here is ridiculous; I'll be glad to get it out of the way
<infinity> chiluk: Re-uploaded.
<jibel> barry, dep8 tests have been removed from codespeak-lib during latest sync, is it on purpose?
<barry> jibel: no.  i guess they were missing from the debian packaging and i didn't see that.  i'll restore and get them into debian
<jibel> barry, Great, thanks!
<chiluk> awesome thankyou much infinity
<infinity> chiluk: And accepted, since I spent all that time reviewing and nitpicking anyway. :P
<chiluk> hah
<mdeslaur> ogra_: hey! you can't do this: dump DBUS_SESSION_BUS_ADDRESS into ~/.dbus-session, so we can source it
<ogra_> mdeslaur, thast exactly weht we do now and what we need to nort make all autopilot tests fail
 * ogra_ cabnt type anymore, way to less sleep this week
<ogra_> mdeslaur, i'm open for suggestions to fix it better ... just wont do it today anymore ... we need the dbus address in adb and ssh logins else the app tests cant run
<mardy> kenvandine: hi! Did you see that I made that environment inheriting in dbus-test-runner optional? Could you review it?
<mdeslaur> ogra_: oh, I see you've actually put it in ~/.cache/upstart and not ~/.dbus-session
<mdeslaur> ogra_: that's a bit better...I'll think about it some more
<ogra_> mdeslaur, there is a lot awful stuff in bashrc that sources such files, we need to find a sane way for this
<kenvandine> mardy, yes... that worries me less
<hallyn_> slangasek: that kernel patch works around the mountall hang, so I'll add that to my stash for now and see if I can get Eric to push it
<slangasek> hallyn_: oh, there was already a kernel patch that addresses this?
<hallyn_> slangasek: no, i wrote one
<slangasek> ok
<hallyn_> all the files end up owned by user/group -1, so no security issues
<vlad_starkov> Question: Having RAID1 on 12.04 I just found out that sdb is failed now. But `ls /dev/ | grep sdb` shows only sdb, but it should show sdb sdb1 sdb2. Anyone know what's going on?
<vlad_starkov> I mean, what could be cause of this issue?
<slangasek> vlad_starkov: this question would be better placed in a user forum, but a disk failure could prevent the kernel from reading the partition table at all in which case you wouldn't see sdb1 sdb2
<vlad_starkov> slangasek: I apologize for posting my question here. But I have almost emergency situation with unexpected disk failure on remote server in production. Just want to make sure that it is hardware failure. I changed these two disks about a month ego, they are new. Is it possible that it is not HDD failure but something else?
<vlad_starkov> slangasek: I even can't read SMART. smartctl -a /dev/sdb returns ">> Terminate command early due to bad response to IEC mode page".
<xnox> slangasek: don't you think overlayfs mounting /etc kind-of makes sense for cloud-images at boot?
<slangasek> xnox: overlayfs mounting /etc> not really; we've always regarded read-only root as requiring a pre-configured /etc
<xnox> ok.
<lifeless> xnox: please god no, overlayfs is too fragile
<lifeless> xnox: We're about to do the work needed to run read-only root on top of ubuntu cloud images, and our plan is to symlink the key files that we need to change, rather than any sort of overlay
<slangasek> xnox: do you happen to know if other fscks besides e2fsprogs special-case / wrt fsck-after-mount?
<xnox> lifeless: /me helped fixing bugs with upstart/etc-on-overlayfs, i'd also be happier without overlayfs layer there.
<xnox> slangasek: not off the top of my head, no. but can keep an eye out for that when doing merges.
<slangasek> I guess it wouldn't be obvious in a merge diff :)
<xnox> slangasek: but i do reboot & fsck tests ;-)
<xnox> so could read a bit of fsck source code.
<ogra_> lifeless, tar up /etc ... mount tmpfs to /etc ... untar tarball ... better than having to maintain a growing number of links
<xnox> ogra_: i'd think one would want reboot facility =)
<ogra_> xnox, so you do the same on shutdown, just backwards
<slangasek> I don't always preserve my system configuration across reboots; but when I do, I write it to my network card's EEPROM
<ogra_> haha
<xnox> slangasek: you must be working for Samsung! =)
<dobey> what's the best way to deal with symbols for multiple libraries in a package? separate .symbols file for each? anyway to make dpkg-gensymbols NOT put all the symbols in a single file?
<slangasek> separate .symbols files for each binary package
<infinity> dobey: dpkg deals with symbols at the package level, not the library level.  If you want them separate, you probably also have a case where you want the libraries in their own packages. :P
<infinity> (Given that putting multiple libs in one package is effectively calling that package a stable ABI)
<dobey> infinity: the libraries *are* in their own packages. and i passed -p to gensymbols. but it listed all the symbols for all libraries (from debian/tmp/)
<lifeless> ogra_: that locks you in a specific version of /etc, makes rebasing to a new release super hard.
<dobey> infinity: i guess i don't understand why -p was meaningless :)
<infinity> dobey: You might have wanted -p and -P
<slangasek> dobey: because dpkg-gensymbols will still act on all the libraries it finds; you need to also pass -P to tell it which directory to scan
<dobey> oh
<infinity> Surely, some higher level debhelper friendliness gets this vaguely right without having to invole dpkg-gensymbols with voodoo?
<infinity> Either way, the dpkg-gensymbols manpage is friendly enough, if a bit verbose.
<dobey> infinity: yeah, --help is at least more helpful than the UsingSymbols wiki page
<olli_> is there a good way to disable accessiblity in Saucy
<olli_> uninstalling at-spi2-core seemed like a lazy way to do it, but the whole desktop depends on it
<slangasek> olli_: what do you mean by 'disable accessibility'? stop the daemon from running?
<olli_> slangasek, yep
<slangasek> ok
<slangasek> I don't know how to do that (if it's possible)
<olli_> we are seeing one of the mir benchmarks fail with accessibility turned on
<infinity> One would think that should be fixed...
<olli_> infinity, from what I am told it's an issue in the test, happens on X and mir
<olli_> but yes, needs fixing
<infinity> Anyhow, an rgrep of /etc suggests you want /etc/xdg/autostart/at-spi-dbus-bus.desktop
<infinity> olli_: ^ removing that should do it.
<olli_> infinity, thx
<TheMuso`> olli_: If the sesion is using upstart user session jobs, you may also want to look at disabling the job in /usr/share/upstart/sessions/.
<olli_> TheMuso, we are on Saucy atm, so upstart shouldn't be an issue, should it? (unless I read my ps wrong)
<infinity> olli_: saucy being the only release with user sessions? :)
<olli_> robotfuel, infinity & TheMuso suggest to disable the init script or /usr/share/upstart/sessions/at-*
<olli_> depending on whether the session is using upstart user session jobs
<olli_> infinity, not sure I follow
<infinity> olli_: I was responding to your "we are on Saucy atm, so upstart shouldn't be an issue", which made little sense, as saucy is the only release that *does* use user sessions.
<olli_> infinity, yeah, figured my understanding of upstart user sessions was off
<olli_> is off
<olli_> robotfuel, having said that, forget the /etc change but use /usr/share/upstart/sessions instead
<TheMuso> olli_: robotfuel_, both will need changing, since even if the upstart user session job for at-spi in /usr/share/upstart/sessions is disabled, the .desktop file in /etc/xdg/autostart will still be examined and processed.
<TheMuso> The desktop file in the xdg dir existed long before the upstart job.
<xnox> TheMuso: those xdg autostart files that are converted to upstart-session jobs, should drop an override file into /usr/share/upstart/xdg/autostart with Hidden=True.
<xnox> TheMuso: such that only upstart job needs to be controlled, in an upstart user session.
<xnox> TheMuso: olli_: to disable upstart job "echo 'manual' > ~/.config/upstart/at-spi2-registryd.override"
<xnox> olli_: the autostart job shouldn't be a problem as long as the org.gnome.desktop.interface toolkit-accessibility is false in gsettings....
<olli_> robotfuel_, ^
<olli_> xnox, thx
<xnox> olli_: in general one can drop override files for upstart user sessions in: /usr/share/upstart/session, /etc/xdg/upstart/, /etc/xdg-ubuntu/upstart (or any other dir in XDG_CONFIG_DIRS), ~/.config/upstart
<xnox> olli_: all depends, if it's package level, system level, Desktop Environment level, user level.
<olli_> xnox, thx, that's good to know
<olli_> need it at system level or below
<olli_> robotfuel_, will give it a spin
<robotfuel_> xnox: thanks
<TheMuso> xnox: Oh right, didn't know that, thanks.
<TheMuso> xnox: I was wondering what that dir was for.
<xnox> TheMuso: if we are running under upstart-user-session, we add that one in.... XDG_CONFIG_DIRS=/etc/xdg/xdg-ubuntu:/usr/share/upstart/xdg:/etc/xdg to allow overriding parts that conflict or are racy.
<TheMuso> xnox: Right, thanks for the heads up.
<robotfuel_> most of the systems have passed the gtkperf test without freezing so it looks like sudo -u ubuntu gconftool-2 --set --type bool /desktop/gnome/interface/accessibility false might have disabled accessibility
<TheMuso> robotfuel_: Gsettings is used exclusively for accessibility these days, I am surprised that worked.
#ubuntu-devel 2013-07-17
<xnox> kirkland: did you mean to upload +byobu (5.46) released; urgency=low into raring? that's like even ahead of saucy =)
<cjwatson> xnox: drizzle's latest build failure looks like it could be improved by a merge from Debian - do you think you could do the honours as TIL?
<xnox> cjwatson: looking.
<sergiusens> cjwatson: hey, any idea how to solve this? http://pastebin.ubuntu.com/5882703/
<sergiusens> that's during lb
<cjwatson> sergiusens: looks like the .click file is somewhere not readable by the clickpkg user
<cjwatson> like a mode 700 directory owned by some other user or something
<sergiusens> cjwatson: a good, let me check, thanks
<cjwatson> BTW I think you should lose the -app suffix there
<cjwatson> Makes sense for the .deb packaging, not so much for click
 * cjwatson -> bed, again
<sergiusens> cjwatson: ok, I'm just grabbing whatever was in debian/control ... I'll strip it
<xnox> cjwatson:  pushed the merge to lp:~xnox/ubuntu/saucy/drizzle/merge, will sleep and upload tomorrow.
 * xnox Zzzzzzz
<Snow-Man> argghh..  why are the ipv6 addresses busted again? :(
<pitti> Good morning
<pitti> barry: did you happen to request syncing of codespeak-lib?
<pitti> the sync dropped our dep-8 tests, but I cannot  figure out from https://launchpad.net/ubuntu/+source/codespeak-lib/1.4.15-1 who requested the sync, and there is no bug report for the sycn either
 * pitti removes the package from -proposed again, as that's our only delta
<ScottK> pitti: https://launchpad.net/ubuntu/saucy/+source/codespeak-lib/1.4.15-1 does make me think it was barry.
<pitti> ScottK: aah, thanks
<ScottK> I think it's an LP bug that you only get that from the series specific page, but it's not like it'll ever get fixed ...
<pitti> dobey: ubuntuone-client's autopkgtest needs its stderr suppressed or redirected to stdout or a file
<pitti> dobey: are you on this already? want me to upload this? in the latter case, is there any hidden bzr branch I should use, or just apt-get source/dput?
<pitti> ev: I think the noninteractive UI needs some more thought
<pitti> ev: I don't think we should set this in /etc/default/apport, as (1) that's always difficult to change, but more importantly (2) don't we want the UI for "apport-bug", i. e. for bug reports? I thought the intention for this was to send crash reports silently?
<ev> pitti: difficult to change in what sense? We do want the crash reports to send silently, yes. Is that not the case here?
<pitti> ev: it's a conffile which people often change; we need to add the new option to the conffile, and it's difficult to have different values of it for desktop and phone builds
<pitti> ev: I meant that if you file a bug report (apport-bug package) you might actually want the UI
<pitti> ev: and that update-notifier or whatever sends the crashes on the phone should perhaps directly call apport-noui instead of apport-bug
<ev> pitti: right, but we're leaving it up to them to change. I can't see why we would ever change the value for it? Or am I misunderstanding conffiles?
<pitti> ev: we used to change the value of enabled regularly, and peopel still do it manually
<ev> I have no problem with directly calling apport-noui on the phone. Happy to create an upstart job for that which cargo cults the one bdmurray made for update-notifier
<pitti> ev: but anyway, aside from the conffile issue I think the different default for it in desktop and phone builds makes this impractical
<ev> ah, very good point
<pitti> ev: e. g. update-notifier directly calls /usr/share/apport/apport-gtk
<pitti> ev: so that option wouldn't work there
<pitti> ev: and conversely calling apport-bug manually ought to give some UI, even on a server (-cli)
<ev> well it now calls apport-collect in saucy
<ev> but yeah
<pitti> ev: oh? I just did apt-get source update-notifier, and it still calls apport-gtk
<pitti> ev: nothing is ever supposed to call apport-collect automatically
<ev> update-notifier 0.140
<ev> why? It's just a "pick the right UI" layer
<pitti> ev: you mean -bug, not -collect?
<pitti> ev: ah, so bdmurray didn't remove all the bits in ./src/update-notifier.h and src/crashh.c, and we instead just use the upstart job?
<pitti> (nice to have a job for this now!)
<ev> pitti: is there a difference? -collect is a symlink
<ev> iknowright!
<pitti> ev: oh yes, it checks argv[0] for what to do
<pitti> -collect -> update an existing bug, needs launchpadlib, python2, and LP credentials
<pitti> otherwise, "report a new bug"
<ev> ah, I missed that entirely
<ev> so not collect then
<pitti> ev: perhaps we can make apport-bug check $APPORT_UI instead? then update-notifier would set "gtk", or not set it at all, and our phone job would set "noui"?
<ev> okay, so to summarise: fix update-notifier to call apport-bug. Call apport-noui directly from an upstart job on the phone. Store the configuration for automatic reporting somewhere else?
<ev> works for me
<pitti> or call -ui directly, sure
<ev> any preference on where the configuration option should live?
<pitti> ev: u-n was already fixed, it's calling apport-bug
<ev> ah right
<dholbach> good morning! :)
<pitti> ev: do we need one at all?
<ev> pitti: so we could just use the apport enabled= toggle
<pitti> ev: phone upstart job would set $APPORT_UI, and otherwise calling apport-bug should DTRT?
<ev> we need to point this at something: https://wiki.ubuntu.com/ErrorTracker#Privacy_settings
<ev> do keep in mind that we'll want to provide UI on the desktop for automatic reporting as well
<pitti> ev: the "collect app crashes and errors"? that sounds like "enable"?
<ev> the developer "I know what these are, just send them"
<ev> yes
<ev> it's definitely enable/disable
<pitti> ah, for that
<ev> but the tricky bit is the developer on the desktop
<ev> yeah
<pitti> ev: that's a per-user setting, right?
<pitti> or does the admin set it globally?
<ev> I think it makes more sense as an admin setting, and we definitely want it that way on the phone
<ev> I think :)
<pitti> ev: then I don't mind adding that to /e/d/apport, as we don't change that file regularly any more
<ev> okay
<pitti> ev: except if you want this at automatic=1 at phone builds, which we can't do
<pitti> as it's a conffile
<ev> oh hm
<ev> I do want that :)
<pitti> if the phone cronjob will take care of it, and automatic=0 is fine there, the we can do it
<pitti> ev: how about a non-conffile /etc/apport/automatic flag file?
<ev> works for me
<pitti> phone builds/images can then create this, and no conffile conflicts
<ev> sounds good
<pitti> ev: http://paste.ubuntu.com/5883292/ ?
<ev> yup, perfect
<pitti> ev: still feels a bit strange for apport-bug (non-crash bug reports), but let's use this for now
<ev> okay
<pitti> ev: ok, committed
<pitti> ev: I'll do a new upstream release now and upload, unless you have something else?
<ev> thank you muchly
<ev> nope, please proceed
<pitti> ev: FYI, new feature, bumping to 2.11 (for your next NEWS entry)
 * ev nods
<pitti> ev: thanks for the discussion
<ev> thank you for discovering the problems with this
<pitti> start on (file FILE=/var/crash/*.crash EVENT=create)
<pitti> OMG that's so great; I've waited for this since 2005 or so :)
<pitti> jodh: ^ thanks!
<jodh> pitti: errm, np.
 * jodh waits for irclogs.u.c to update to see what he's done... :)
<pitti> jodh: adding support for start on (file FILE=/var/crash/*.crash EVENT=create)
<pitti> with that we should be able to eventually drop update-notifier
<jodh> pitti: ah - team effort: bdmurray actually wrote the job :)
<xnox> pitti: ev: if update-notifier declares a variable for "APPORT_UI" then on the phone, we can add "echo APPORT_UI=apport-no-gui > /etc/init/update-notifier.override" to set the default there. There are many things that are "tweaked" for the phone like this at the moment.
<ev> xnox: the problem comes with this not just being an option for phone
<ev> it's going to be an option on the desktop as well
<ev> so apw and infinity can say "just send the damn things. stop bugging me!"
<apw> oh please yes
<apw> ev, was it a deliberate decision that teh default for that dialog is cancel btw ?
<ev> what dialog?
<xnox> ev: i'd put my faith apw/infinity would manage to copy&paste one line of upstart override for that =) I mean the productivity boost and incentives are there =))))))
<apw> ev, your 'do you want to send this error to ubuntu' thingy
<pitti> apw: yes, in case it steals your focus or you don't read it all before (accidentally) pressing Enter
<xnox> apw: gtk+ deficiency, as by design there shouldn't be a default action, yet gtk+ forces one.
<ev> xnox: I never want to utter the words, "it's easy. Just open up a terminal and"
<apw> pitti, that is not a solution the solution is to _not_ steal my focus ever
<xnox> ev: upstart has dbus API.....
<ev> xnox: because DBus is easy
<ev> xnox: next you'll tell me that problems like these can be quickly solved in lisp
<pitti> apw: let's hope that unity8 fixes that :) it seems compiz doesn't
<ev> all you need are a few parenthesis. Simples.
<lifeless> snaaaake!
<ev> :D
<apw> pitti, fingers crossed ... though there is a simple solution i suspect, make the dialog a box with OK only and have it have a radio box on it, 'discard', 'send to ubuntu', 'thinking' and default that to thinking, and make the box just come back if you have 'thinking' set
<ev> yeah, the specification mentions the default action stuff: "The Esc and Enter keys shouldÂ notÂ do anything in an error alert, because you may have been just about to press one of those in the program that has the problem."
<ev> but I take it GTK+ doesn't let us do that?
<apw> pitti, obviosuly you can think of better words :)
<apw> pitti, then if you hit enter it just reappears
<ev> lifeless: good evening. Not sure if your new adventures involve a lot of big data, but if you still find that sort of thing interesting, I've really been enjoying the talks from Cassandra Summit '13 and Cassandra NYC '13: http://www.youtube.com/user/PlanetCassandra/videos?sort=dd&view=1&shelf_index=2
<ev> quite a bit of distributed systems stuff in there too
<ev> Adrian Cockcroft's talk on Netflix OSS in particular
<lifeless> ev: My new adventures are all to do with deploying clouds @ at scale.
<lifeless> ev: so big data enabling rather than big data doing; but I am definitely still interested!
<lifeless> ev: thank you for the link!
<ev> excellent :)
<ev> anytime
<xnox> ev: since you are not on #ubuntu-quality, replaying here: to allow admins with foreground session, execute actions without prompts, you can do so via pkla as shown here: /var/lib/polkit-1/localauthority/10-vendor.d/com.ubuntu.desktop.pkla
<ev> xnox: perfect, that's exactly what I'm already doing locally
<ev> I'd give you a pastebin, but I'm on a different computer
<pitti> however, caution applies
<ev> oh?
<pitti> xnox: please not; having any firefox plugin be able to format your internal hard drives or changing the boot sector is evil
<pitti> ev: ^ my response to "so that's what I need to change to make usb-creator stop asking questions again"
<xnox> pitti: would above be at all suitable for like - to stop apport asking for my password 16 times in a row?
<pitti> xnox: that'd be a badly written apport hook
 * xnox would have thought apport would at least cache the password, unless it's killed and spawned for each error.....
<ev> pitti: yes, this is something I'd only want set on the phone
<pitti> xnox: apport can't cache it as it doesn't know it, but it has an API to run several root commands in one go (and thus with one password)
<ev> I think the password prompt still makes sense for changing anything under com.ubuntu.WhoopsiePreferences on the desktop
<xnox> pitti: on the phone, with readonly rootfs, only "blessed" hooks are in....
<pitti> xnox: we need to disable one of (1) send bug reports noninteractively, (2) ask for password for root commands, or (3) be able to point to an arbitrary hook dir, otherwise we have a "full root access" hole for any user
<pitti> xnox: as the apport API is essentially a "run anything as root", it probably needs to stay password protected
<pitti> but we wouldn't see these on the phone as ev just disabled all these prompts in apport with the noninteractive UI :)
<xnox> pitti: plus, i'm not sure I understand the "badly written apport hook" argument, since at the moment i'm not protected against it and I don't buy "we asked you for a password, without telling you which hooks we will run, so it's your fault if it was a rotten hook, Haha kthnxbye"
<ev> just doing my part to make apport webscale
<pitti> xnox: I meant that it calls the "root_command_output()" function 16 times instead of using attach_root_command_outputs()
<lifeless> ev: does that involve throwing away 90% of errors?
<pitti> xnox: well, I never said I was particularly fond of these, as they don't tell you what they do -- but I bowed to several people demanding it
<pitti> (X.org or kernel bug reports, etc.)
<xnox> yeah =/
<pitti> of course these will just break again with the non-interactive UI
<ev> lifeless: I have not yet made the leap to deleting to increase all sorts of performance areas
<lifeless> :P
<ev> mostly because we're still learning, still going back and building indexes out of the entire data set
<pitti> but ev and I discussed some "need more information" flag on errors.u.c. for bug reports where we really need those, so we can refine that eventually
<ev> if I was really confident in our data model, then yes :-P
<tvoss_> pitti, ping
<pitti> tvoss_: pong
<ricotz> pitti, hi :), if you have time please take a look at http://paste.debian.net/plain/16505
<pitti> ricotz: oh, I thought make install forgot to install them
<ricotz> pitti, not really ;)
<pitti> ricotz: thanks, uploading
<ricotz> pitti, yw
<cjwatson> rbasak: Looks like I just need to fix dacs, and then everything not dependent on your php5 merge is probably safe to temporarily remove
 * cjwatson demotes/removes some packages for that transiiton
<cjwatson> *transition
<rbasak> cjwatson: OK, thanks. I just noticed that merges.u.c is using php5 5.4.15-1 as the base. It seems blind to saucy-proposed. Is this a bug?
<rbasak> I can work around it easily enough.
 * xnox ponders about using cjwatson's net-retriever deduplicator for transition-tracker & merges.u.c =))))))
<xnox> ... decides against it.
<cjwatson> xnox: There's a perfectly good (fast) one in the transition tracker, and merges shouldn't need it
<cjwatson> rbasak: Will check
<cjwatson> Oh, indeed, I think I never got round to making merges look at -proposed
<cjwatson> rbasak: Could you file a bug on merge-o-matic about this?  I'm not going to have time to sort it out just now
<rbasak> cjwatson: sure.
<cjwatson> xnox: (What I mean is that merges already has code to pick the newest source of several, ever since Debian started having multiple versions in Sources; all it should need is to concatenate saucy and saucy-proposed
<cjwatson> )
 * rbasak has filed bug 1202142
<ubottu> bug 1202142 in Merge-o-Matic "Blind to new development release -proposed pocket" [Undecided,New] https://launchpad.net/bugs/1202142
<cjwatson> Ta
<xnox> cjwatson: yet on people.canonical.com i see deduplicate-packages python script, which i don't have locally. So out of the box our "junk" branch doesn't do that =(
<cjwatson> xnox: Yeah, I think Laney wrote that and didn't commit, originally ...
<Laney> Seems possible
<Laney> feel free to do it
<xnox> Laney: is there way to run saucy & saucy-proposed locally without fiddling, as upstream?
<xnox> Laney: ah =) ok, patches welcomed ;-)
<Laney> The multiple suites thing is all local
<Laney> it skips the 'downloading' part of ben
<Laney> So that's why I didn't commit it
<xnox> Laney: i guess one day we will upgrade to newer ben?! =)
<Laney> I don't know if newer ben even handles this
<Laney> but yes - some time ago I started writing a charm to get it off lillypilly
<Laney> Then we don't need to block on IS and chroots and stuff
<cjwatson> Well
<cjwatson> Having it not tied into the archive-reports infrastructure would be problematic
<cjwatson> But we're getting a new machine to offload the archive jobs from lillypilly
<Laney> because of lag?
<cjwatson> Just because all the stuff on there is too much for one machine
<Laney> to the former
 * xnox thinks drizzle is amd64 only software....
<cjwatson> Right, it needs to be guaranteed up-to-date with the archive and update as quickly as possible
<cjwatson> I specifically put a fair amount of work into making it update as fast as it can, so that you can go round multiple layers more efficiently
<Laney> Ah, I was assuming that *stack had access to ftpmaster so it'd be the same
<Laney> Anyway, I think that precise is new enough for new ben so this new machine might be OK
<Laney> not that there's a huge need to move forward anyway
<cjwatson> Direct access to ftpmaster is heavily restricted
<cjwatson> And if it were on some other machine we'd need to figure out a way to trigger it from archive-reports
<cjwatson> Also, lillypilly is on precise
<Laney> the chroot is lucid though
<cjwatson> It's not so much the version of the host, as that IS were uncomfortable with installing -dev packages in the root
<Laney> but I'm sure that could be updated separately
<cjwatson> It might be worth seeing if fakechroot is good enough
<cjwatson> It certainly good
<cjwatson> er, could
<Laney> Yeah, seems I can ping ftpmaster but not rsync the dists tree
<Laney> oh well
<cjwatson> Wouldn't surprise me if fakechroot were good enough.  I don't think I tried that
<Laney> Would be useful to be able to self manage it
<xnox> Laney: ftpmaster seems to be http only even from lillypilly. no rsync there.
<cjwatson> xnox: Untrue
<cjwatson> xnox: We have special arrangements
<cjwatson> xnox: There are ubuntu-dists and ubuntu-germinate modules which lillypilly can access; it doesn't have blanket access, that's all
<cjwatson> xnox: See (internal) RT#47981 and RT#49414
<xnox> cjwatson: is ubuntu-dists module publicly accessible? (prefferable merged tree), at the moment I do rsync ubuntu's module dists directory, and then ubuntu-ports dists directory on top, without deletes....
<cjwatson> xnox: No.
<cjwatson> xnox: We're not going to open public rsync direct from ftpmaster.
<cjwatson> This is a very special-purpose deal.
<Laney> Ah, so I investigated.
<Laney> dose-distcheck has a --latest option - if ben migrates to this then we can stop deduping
<Laney> I still don't think it has multiple suite support though
<infinity> cjwatson: "we're getting a new machine to offload the archive jobs" -- Is that on again?  Is there an RT I can subscribe to?
<cjwatson> infinity: RT#63122
<infinity> cjwatson: \o/
<infinity> cjwatson: A mod_proxy or mod_rewrite passthrough of some sort is probably saner than shuffling things around via rsync every few minutes.
<infinity> I suppose I should tell the ticket this.
<Laney> I'll make some time to see if fakechroot works for ben
<Laney> If we're shuffling it anyway, might as well move then
<cjwatson> infinity: Yeah, particularly for the things with lots of inodes (germinate output et al)
<cjwatson> Laney: Cool
<infinity> cjwatson: rsync-over-ssh isn't particularly CPU friendly, apache proxies are a lot less angry, and the goal here is to make lillypilly happy, so yeah.
<tvoss_> ogra_, ping
<infinity> cjwatson: Commented on the ticket, anyway.  Up to IS if they want rewrite/proxy rules they have to manage.
<cjwatson> Ta
<cjwatson> infinity: The alternative would be exposing newmachine's http port directly and then having a redirect rule
<infinity> cjwatson: Yeah, which is even more CPU friendly, but client hostile.
<infinity> cjwatson: But worth noting as a third option.
<cjwatson> Will do
<ogra_> tvoss_, yo
<infinity> Oh, FFS, I can't add myself as a CC to a ticket?
<tvoss_> ogra_, do you happen to know if we have a perf build for the touch image?
<ogra_> tvoss_, i think we do, for deatils ask #ubuntu-kernel though, i never used it
<Laney> infinity: I think you have to ask for that, yeah :/
<doko> yolanda, when you touch graphviz for the lua update, could you have a look at building with ruby1.9 as well?
<yolanda> doko, just focused on rrdtool now, but we could add ruby to the list
<doko> ohh, rrdtool too
<yolanda> doko i'm finding that liblua isn't copying the libraries anyway... do you know about it?
<doko> no, I just did see that we were pulling 5.2 in main, without discarding 5.1
<cjwatson> yolanda: Could you leave graphviz until Apache 2.4 has landed in saucy, please?
<yolanda> cjwatson, yes, not touched graphviz still
<cjwatson> yolanda: You can see from http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt that it's a fiendishly complex transition already, and I don't want to complicate it further :)
<yolanda> i think that there is some problem with liblua, no libraries copied anywhere
<xnox> yolanda: recently with python3.3 transition in debian, multiple packages were spotted to compile and link bindings against libpython3.3*so yet not install or copy them anywhere.....
<xnox> could be similar, where upstream builds them, yet packaging didn't actually install them properly.
<yolanda> i'll take a look now
<yolanda> xnox, i found that libraries are copied into /usr/lib/x86_64-linux-gnu, instead of /usr/lib/lua
<yolanda> path should be /usr/lib/lua/5.2/, right?
<xnox> not sure. depends how lua operates, and whether it started using multi arched or not.
<cjwatson> Could also be an accident from higher debhelper compat levels.
<xnox> doko: ^ maybe you know correct paths for lua?
<doko> xnox, didn't look. lua itself is multiarch, didn't look at the layout for the modules and extensions
<yolanda> doko, xnox, it's multi arched, but something is wrong, just copying the files to /usr/lib/x86_64-linux-gnu/liblua5.2.so
<infinity> yolanda: Certainly sounds like that should be in a lower-level plugin directory like /usr/lib/x86_64-linux-gnu/lua/something, yeah.
<infinity> yolanda: But you'd have to look at what pre-multiarch lua did, and then logically twiddle that.
<rbasak> Having more issues with php5 including a build failure with my new merge. I'm working on it.
<doko> infinity, please could you merge eglibc?
<infinity> doko: Yes.  Is there a specific fix you're urgently waiting on, or do you just hate outdated version numbers? :)
<infinity> doko: (The merge is sitting here on my laptop, I'll get it up after another test or three)
<doko> infinity, I need a stable cross chroot, and would like to avoid to have it rebuilt soonish again
<dholbach> can somebody please reject https://code.launchpad.net/~logan/ubuntu/saucy/json-c/0.11-2ubuntu1/+merge/174910?
<doko> infinity, and yes, the reverted error code change causing some issues with python modules would be good to have too
<cjwatson> dholbach: done
<dholbach> thanks
<infinity> doko: Oh, the getaddrinfo() fix?  Yeah, fair enough.  I'll finish up testing.
<doko> yes
<caribou> smoser: I have a request for help from the Pilot
<caribou> smoser: I have a pending SRU and apparently I forgot to subscribe ubuntu-sru so it doesn't seem to appear in the queue
<caribou> smoser: LP: #1005901
<ubottu> Launchpad bug 1005901 in duplicity (Ubuntu Precise) "cannot change temp dir" [Undecided,In progress] https://launchpad.net/bugs/1005901
<barry> pitti: yes, i was going to restore the dep 8 tests once the sync cleared proposed, and i filed a pull request for the debian package to add the tests
<caribou> hmm this sponsor-patch script seems interesting...
<pitti> barry: ah, ok; well, the only delta was the dropping of the test, so I removed the sync from -proposed (it wouldn't propagate anyway)
<barry> pitti: in that case, i won't do anything until the debian bug gets closed.  once that's got the tests, i'll resync
<dobey> pitti: why does it need the redirection?
<pitti> dobey: stderr output counts as failure; useful to guard against unexpected warnings/criticals/etc., but of course rather useless if you do expect all that spewage on stderr
<pitti> so in that case a 2>&1 is the usual fix
<dobey> pitti: that sounds like a bug in autopkgtest if it's counting stderr output as failure
<pitti> it's the currently defined behaviour
<pitti> i. e. it doesn't happen accidentaly
<smoser> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<infinity> This has been argued in the past as a misfeature, yes, but it's the way it is.
<smoser> caribou, i'm not pilot, but i'll take a quick look and see if i cna't help
<caribou> smoser: the topic did say you were, sorry 'bout the noise
<caribou> smoser: it's a small backport that's already in quantal. sponsor-patch doesn't report anything I could see
<smoser> yeah, not your fault :)
<smoser> caribou, did you figure it out ?
<rbasak> I filed bug 1197005 about it
<ubottu> bug 1197005 in autopkgtest (Ubuntu) "Printing to stderr should not be considered a test failure" [Undecided,New] https://launchpad.net/bugs/1197005
<rbasak> It's a pain when developing tests, since eg. "set -x" writes to stderr.
<dobey> pitti: i think autopkgtest either needs to be fixed to not count stderr output as a failure, or to have a feature flag one can put in d/tests/control to redirect/ignore stderr
<caribou> smoser: I was able to figure out how to reproduce it & did test the fix from Quantal
<pitti> dobey: we generally want stderr failure; the feature flag is a nice idea
<rbasak> dobey: +1. I'd even go further. A test that needs stderr to be treated as a failure should flag it as such in debian/tests/control.
<rbasak> pitti: I disagree, for server packages at least. The way I've been writing tests, I explicitly check for the expected behaviour only right at the end of a long setup.
<smoser> caribou, so you want htat debdiff sponsored. is that it?
<caribou> smoser: yes, indeed
<barry> pitti: i'm a little perplexed at the lack of automatic notification for the package not clearing proposed, or getting dropped from it.  not saying *you* should have done the notification, but that the system should have.  or maybe it did and i missed it?
<rbasak> The long setup will fail due to "set -e", and even if a command doesn't correctly return exit status, then the behaviour check at the end of the test will notice and flag it.
<dobey> pitti: the problem of course is, if a completely unrelated thing dumps something to stderr, such as a gtk+ theme, it counts as a failure
<rbasak> OTOH, the stderr causing a test failure has severely harmed my test development velocity.
<pitti> barry: I don't think LP notifies you, that's why I pinged you explicitly
<infinity> barry: There's no notification when packages are removed.  It would be a lot of noise for routine removals.
<pitti> dobey: right, that's what we want it for -- new CRITICALs, for example
<barry> pitti: yeah, for which... thanks! :)
<dobey> pitti: yes, but i shouldn't get a failure in ubuntuone because the theme broke :)
<barry> infinity: would it be a lot of noise for proposed migration "failures"?
<dobey> or because twisted is using deprecated API
<infinity> barry: What failure was there?  pitti removed a package, that's not a failure, it's an explicit action.
<pitti> infinity: codespeak-lib's autopkgtest failed because the autopkgtest was dropped from the sync
<pitti> infinity: now, if the removal was legitimate we'd just remove the job, but we actually want it, so I removed the sync from -proposed again
<barry> infinity: what i mean by "failures" is any disruption in the normal migration pattern
<infinity> barry: I suspect uploaders being told every time something is stuck in proposed (on every britney run, how often do you want to get told?) would be an insane amount of noise.
<infinity> This particular case seemse to be a bit of a special case.
<infinity> And a direct ping seemed appropriate, since one would also want to expand on "why did you remove that?"
<dobey> infinity: well, getting a single notification that the autopkgtests failed in my upload, would be nice.
<infinity> dobey: That's meant to be happening (or maybe has already happened?)
<infinity> jibel: ^
<barry> infinity: maybe.  i'm not saying anything *needs* to be done, i'm just wondering out loud whether some notification, or possibly even status on a launchpad page wouldn't be better.
<kirkland> xnox: no...  sorry, let me see what went wront with my release script...
<cjwatson> dobey: I get e-mail notifications when my uploads' autopkgtests fail, and have done for a couple of weeks now.
<infinity> barry: I suspect push notifications of continued failure to migrate would be a non-starter.  A nicer pull mechanism than "learn to read excuses/output" might be pleasant.
<cjwatson> (Along with notifications when they go back to passing.)
<jibel> dobey, barry you should have received a notification on 1rst failure, then when the test pass again. If you didn't that's a bug I must fix.
<infinity> I wonder how painful it would be to mangle packages.qa.d.o to work for Ubuntu.
<cjwatson> jibel: Perhaps this is a case where the test has always failed ...
<dobey> jibel: i haven't seen any e-mail
<cjwatson> Although https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-ubuntuone-client/ was apparently only introduced recently
<infinity> dobey: Oh, is this on an upload YOU are doing, or something autolanded by a bot that bins email?
<jibel> cjwatson, no it was codespeak-lib that used to pass
<barry> jibel: i did not get anything
<dobey> infinity: uploads i made
<jibel> anyway, I'll have look
<infinity> Kay.
<Laney> The software-center pyflakes failure amuses me
<cjwatson> packages.qa.d.o is very useful.  It has a lot of parts though
<kirkland> xnox: doh.  I see what went wrong.  thanks.  I'm fixing it up now
<Laney> It's picking up bad syntax in .pc/
<dobey> Laney: oh, fun
<Laney> dobey: There's also ones which try to access the internets and fail
<infinity> cjwatson: Yeah, I'm not convinced it would be easy to "port" to launchpad, but we really don't have a better "package portal" than +source/<source> right now, which lacks a lot of useful info.
<infinity> cjwatson: Well, it lacks anything we don't do directly in launchpad.  So, proposed-migration, adt, pending merges, etc.  A p.qa.d.o-style portal could be handy.
<dobey> Laney: from pyflakes?
<Laney> no, other tests
<cjwatson> Laney: I'm sure I remember fixing something like that in some other package recently-ish
<cjwatson> (pyflakes vs. .pc)
<Laney> https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-software-center/47/ARCH=amd64,label=adt/console
<dobey> Laney: i knew i should have just done rm -rf debian/tests :)
<cjwatson> Easy enough to do anyway
<cjwatson> infinity: Yep
<cjwatson> infinity: I think it mostly takes a load of data sources scraped from elsewhere, so it's just a matter of coming up with a bazillion scrapers
<infinity> cjwatson: Indeed. It might actually prove to not be much effort at all.  Upload history is easy, bug scraping should be simple enough, etc.
<infinity> (In fact, doesn't it cheat on upload history by just being subscribed to -changes, rather than scraping anything there?)
<infinity> Anyhow.  Food for thought for a less busy day.
<infinity> So, 2017.
<barry> infinity: i find this page interesting: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-codespeak-lib/10/ARCH=amd64,label=adt/
<barry> infinity: the big red dot seems to tell me there's a problem, but the (no failures) and other data there doesn't seem to tell me why i got a big red dot
<Laney> dobey: I'll leave it with you now ;-)
<infinity> barry: You're not alone in finding jenkins output unnavigable.
<cjwatson> I'm not sure that's unnavigable Jenkins; I think perhaps that's something getting confused with a package going from (has tests) to (has no tests)
<pitti> yes, if you look at the console output or full "log" file you'll see the problem
<cjwatson> pitti: In this case the log basically just says no tests were run
<pitti> right, as they got dropped
<cjwatson> 2013-07-16 16:33:33: Failure: adt-run exited with status 8.
<cjwatson> Which is the documented "no tests" exit code
<pitti> yes, but we don't want this to silently pass
<cjwatson> So perhaps that's a bug in adt-britney or similar for running them in the first place
<pitti> it's actually quite deliberate
<pitti> I look at all failures (in case it's test machinery)
<cjwatson> From adt-run's point of view it's obviously correct
<pitti> cjwatson: if that was a deliberate removal, I had just removed the jenkins job
<cjwatson> From adt-britney's point of view, I disagree (if indeed that's what ran the job here)
<pitti> s/had/would have/
<pitti> but like that we can spot if a new upload damages debian/tests/; with counting 8 as success we wouldn't catch that
<cjwatson> There are a bazillion other ways for a developer to disable or neuter tests if they want to; there's no point in making this one difficult by having it require manual intervention
<cjwatson> Like I say, I'm not saying that the infrastructure shouldn't have failed on exit code 8
<cjwatson> I'm saying that this job shouldn't have been run in the first place - unless the package still had XS-Testsuite: autopkgtest?
<pitti> cjwatson: right, I think that gets picked up because it takes all packages in release and proposed which have XS-Testsuite:
<pitti> cjwatson: and as the saucy version still had it, it ran the codespeak-lib test in -proposed
<pitti> so, it's certainly arguable if this is a bug
<pitti> but the only effect is that jibel or me will confirm that the removal is legit and remove the job manually
<pitti> that shouldn't happen very often (in fact it never did so far), so I'm happy to take that extra review
<barry> pitti: exit code 8 was because the saucy version had autopkgtests but the proposed version did not?
<barry> (sorry, i got bumped off of irc for a bit)
<pitti> barry: right
<cjwatson> pitti: mm.  I'm concerned that our whole system is coming near to hitting cognitive overload for me, and I wrote a chunk of it, so I'm hoping to find things that are easier to simplify for developers
<pitti> barry: while this is a kind of success for adt-run, we don't count it as such in jenkins (quite deliberately, see above)
<barry> pitti: right, it seems reasonable to fail.  i think it's just a bug that the failure did not lead to a notification
<pitti> barry: it did, it sent out an email (that's why I looked into it, after all)
<pitti> barry: but it wasn't sent to you because it was a sync; I think that's a bug that we need to fix
<pitti> (I think.. I already deleted the email)
<barry> pitti: ah.  so archive admins got the email?
<pitti> barry: jibel and me get all adt failure emails, plus archive@u.c. (i. e. whoever appears as the uploader)
<pitti> but sending it to archive@u.c. is quite bogus
<pitti> it's not that easy to find out the actual requestor, but certainly possible
<cjwatson> archive@u.c doesn't actually go to anyone
<barry> pitti: and that happened because it was a sync.  okay, i think i got it now. :)  agreed that the sync requester should get notified.
<cjwatson> pitti: it's "creator" on the SPPH
<cjwatson> archive@u.c> at least as far as I know
<pitti> yes, confusingly the requestor isn't mentioned on https://launchpad.net/ubuntu/+source/codespeak-lib/1.4.15-1 (where I usually look)
<pitti> but it is on https://launchpad.net/ubuntu/saucy/+source/codespeak-lib/1.4.15-1
<pitti> so somewhere in LP's and lplib's guts it's stored
<cjwatson> Right, like I say, it's SourcePackagePublishingHistory.creator
<cjwatson> >>> lp.distributions["ubuntu"].main_archive.getPublishedSources(source_name="codespeak-lib", version="1.4.15-1", exact_match=True)[0].creator
<cjwatson> <person at https://api.launchpad.net/1.0/~barry>
<pitti> cjwatson: thanks; added to bug 1202208
<ubottu> bug 1202208 in Auto Package Testing "Wrong test failure notification for syncs" [Undecided,Triaged] https://launchpad.net/bugs/1202208
<pitti> jibel: ^ FYI
<barry> pitti, jibel, cjwatson thanks!
<jibel> barry, 2013-07-16 16:30:18,110 WARNING No public email address for barry. Falling back to changelog
<jibel> 2013-07-16 16:30:18,566 WARNING No changes files URL!
<jibel> barry, no public address, no notifications
<pitti> jibel: oh, so you already do look at this
<barry> jibel: nice
<pitti> jibel: (closed the bug)
<jibel> pitti, but there is a bug still, dobey should have receive a notification for ubuntuone-client
<dobey> jibel: checked all possible spam folders and didn't see a mail there either
<dobey> nor a notification for software-center
<rbasak> I've got a dpkg-gensymbols error in php5 because I'm dropping symbols that are defined in packages in universe: http://paste.ubuntu.com/5884368/. Do I: 1) patch debian/libphp5-embed.symbols to drop symbols that won't be available in the Ubuntu build; 2) Bump the warning/error level so that missing symbols won't result in a dpkg-gensymbols error; or 3) something else?
<infinity> rbasak: The qdbm stuff?
<rbasak> infinity: yes, and onig too
<infinity> rbasak: Well, the Onig is going the other direction.  Those are added, not dropped.
<infinity> rbasak: Bug in the Debian packaging, or have you done something odd in the merge?
<rbasak> I don't think I've done anything odd.
<rbasak> dpkg-gensymbols(1) says that by default disappearing symbols is treated as an error
<infinity> And rightly so.
<rbasak> Ah yes. So I think the qdbm stuff is causing the problem, not onig.
<infinity> rbasak: That's easier to deal with, but the Onig thing is more curious.  Where is that coming from?
<rbasak> Debian packaging defines qdbm symbols. We drop qdbm-dev, so those symbols are defined and appear to be missing.
<infinity> rbasak: A Debian build log doesn't show those popping up.
<jibel> dobey, don't waste your time the system didn't find your preferred email address
<rbasak> My full build log is http://paste.ubuntu.com/5884355/, but warning: it's big.
<jibel> despite there is one on LP
<dobey> jibel: why wouldn't it use the address in the debian changelog though?
<dobey> jibel: it should be using the changelog address for everyone, i think
<infinity> rbasak: Oh, Debian build logs don't show it because I'm looking at the next version that removes the symbols file again. :P
<infinity> rbasak: You might want to just merge -14 and forget the question for now.
<rbasak> Gah
<rbasak> Looks like -14 appeared in the last few hours :-/
<rbasak> Thanks
<infinity> Should be a trivial delta to slap on top of your current work.
<rbasak> Yep
<sergiusens> cjwatson: got this for the first time ever (for the first package installed on a vanilla system) http://pastebin.ubuntu.com/5884435/
<sergiusens> I can try and reproduce that later
<cjwatson> Haha
<cjwatson> Um
<cjwatson> Oh, duh
<cjwatson> sergiusens: Apply http://paste.ubuntu.com/5884438/
<sergiusens> heh
<dobey> Laney: hrmm, if s-c tests failed, how did it end up in release?
<cjwatson> It was probably forced since it's never worked
<dobey> ah ok
<dobey> gah. and branch import for s-c broke again
<dobey> why does it keep breaking :(
<cjwatson> sergiusens: just uploaded click 0.1.5 to fix that
<sergiusens> thanks
<hallyn> all right i seemt o have confused myself again.  if i need to run a setfacl in $package.postinst, does the acl package need to be in $package's pre-depends, or only in depends?
<yolanda> hi, anyone can guide me on ac_cv_search command? i'm trying to debug why a call isn't found on a library, in a configure script, but i'd like to debug that manually
<rbasak> -14 hasn't hit packages.qa.debian.org or packages.debian.org yet. Any idea where I can get the source package, or should I just wait?
<yolanda> is there any way that i can use it from shell?
<rbasak> hallyn: IIRC, the postinst is fine, unless you have a circular dependency.
<hallyn> rbasak: you mean in Depends: is fine right?
<rbasak> "all postinst scripts are run with their dependencies properly configured if this is possible." - http://www.debian.org/doc/debian-policy/ch-relationships.html
<cjwatson> yolanda: config.log usually has details.  No, you can't run it separately.  ac_cv_search is likely to be a variable not a command, in any case - perhaps you're thinking of AC_SEARCH_LIBS
<rbasak> hallyn: sorry, yes.
<hallyn> rbasak: that's the page i'm waiting to finish loading :)
<rbasak> hallyn: how are you connected? Carrier pigeon? :)
<cjwatson> rbasak: incoming.debian.org and check the uploader's sig by hand
<hallyn> rbasak: not ont he first hop, but not sure what's going on downstraem
<rbasak> cjwatson: brilliant. Thanks!
<infinity> rbasak: incoming.debian.org
<cjwatson> Too slow, old man
<infinity> cjwatson: Oh.
<infinity> rbasak: I wouldn't bother with checking the sig if the diff it auditably small, mind you. :P
<cjwatson> Yeah
<infinity> cjwatson: Say, feel like vomiting today?
<cjwatson> yolanda: You can also generally run the configure script under 'sh -x', for ginormous amounts of output.  Looking at config.log first is usually wise. :)
<infinity> cjwatson: I don't think I can sink lower than this for the week: http://paste.ubuntu.com/5884525/
<rbasak> dget ran dscverify (says the manpage), which appears happy. Is that sufficient?
<cjwatson> infinity: But next week you'll be ready to go lower, right?
<cjwatson> rbasak: Yep
<yolanda> cjwatson, looked at the log, it isn't finding a "lua_call" function, that should be contained in lua libraries
<infinity> rbasak: Sure, but like i said, you'll be applying the -13 -> -14 delta by hand anyway, so you get to verify the change regardless.  Who uploaded it is then less relevant.
<rbasak> infinity: yeah, I'll end up looking at the delta anyway
<rbasak> Thanks all
<infinity> cjwatson: I can never predict just how awful my hacks will get in my old age.
<hallyn> rbasak: thanks
<cjwatson> infinity: Fixing su might be a better plan. :)
<infinity> cjwatson: I'm slowly becoming lamont.
<yolanda> cjwatson, lua library is installed on that path: /usr/lib/x86_64-linux-gnu/liblua5.2.so
<infinity> cjwatson: The su fix would still lead to that 2-minute build spinning buildds until the sbuild timeout.
<cjwatson> yolanda: It might then be worth using sh -x to find the exact sequence of commands that it's running to determine that
<lamont> infinity: meh
<cjwatson> yolanda: It's probably missing a dependent library or something
<infinity> lamont: Feh.
<lamont> heh
<lamont> infinity: I acknowledge that you are becoming more awesome.
<infinity> lamont: You may be the only person who sees it that way, but I can't help but acknowledge your suprerior point of view on the matter.
<cjwatson> infinity: I think I'd have build-depended on procps and used pgrep, not that that improves the concept much. :)
<lamont> lol
<cjwatson> If only because the output is less nasty.
<infinity> cjwatson: pgrep effectively does the same thing, no?  "Find processes that match pattern, but exlude myelf, cause that's lolz"?
<cjwatson> Yeah, but less pain with awk.
<yolanda> mm, nm shows that the method is called now "lua_callk", not "lua_call"
<yolanda> some patch should be needed
<cjwatson> yolanda: lua_call is a macro now
<yolanda> cjwatson, the point is that configure script for rrdtools is trying to detect lua_call for building lua bindings
<yolanda> it doesn't find lua_call function and fails
<cjwatson> yolanda: That would normally still work even for a macro, I think, but it depends.  What's the configure.ac line in question?
<yolanda> i patched the configure.ac file, updated the call for lua_callk and works
<cjwatson> Usually autoconf tries to actually compile and link, rather than poking at the library with nm.
<cjwatson> Sure, but I'm not sure that's the right fix ...
<yolanda> i know...
<cjwatson> What's the configure.ac line in question?
<yolanda> let me pastebin my file
<cjwatson> I just need one line :)
<lamont> cjwatson: I don't think infinity finds any pain with awk... but that's how he is, maybe?
<yolanda> http://paste.ubuntu.com/5884566/
<yolanda> look at line 748, i patched that
<yolanda> now that bit works, but it fails on luaL_register, luaL_module and luaL_openlib
<cjwatson> I think that's missing the point.
<cjwatson> The problem may be that the macro requires certain arguments which autoconf's default macro expansion doesn't provide
<cjwatson> (But I'm in a meeting.  Give me half an hour)
<yolanda> cjwatson, i grabbed that patch from a fedora fix, just for guide: http://pkgs.fedoraproject.org/cgit/rrdtool.git/tree/rrdtool-1.4.7-lua-5.2.patch
<yolanda> let's talk later
<cjwatson> Sure, I understand the fix perfectly well, I'm just fairly sure it's possible to do better
<cjwatson> Fedora aren't always right :)
<dobey> what was the command to pull arbitrary dpkg source off launchpad?
<cjwatson> pull-lp-source
<xnox> stokachu: bdmurray: commented on https://code.launchpad.net/~hopem/ubuntu/raring/python-eventlet/lp1199037/+merge/175107
<stokachu> xnox: thanks ill work with dosaboy to get that updated
<xnox> the patch itself looks straight forward, so a sponsor could rewrite a changelog entry to fit SRU (version, bug ref, a sentence description) but it would be best for original submitter do a quick fix up of the version and LP: # as a learning excercise.
<xnox> stokachu: cool thanks.
<stokachu> xnox: definately, also do you guys have any automated tools for checking for a "bug closes" and version scheme?
<xnox> stokachu: oh, and the bug description impact / test case / bug description all look very good.
<stokachu> i'd like to be able to do a quick verification on an sru before bringing it up in the meeting
<stokachu> as a lot of the bugs come to me last minute
<xnox> stokachu: not really, especially since the checks must go against .changes file (check that here is LP closes bugs header and the bug is sensible, e.g. has sru task)
<xnox> stokachu: and similarly there is no way to offline check the correct version, it needs to be compared against what's in the other suites.
<stokachu> xnox: ok so this portion is still a manual process
<infinity> Note that there'd be nothing wrong with the original proposed version string in that upload.
<infinity> Given that it was never used, and it's << saucy.
<xnox> infinity: hm. ok. =)
<infinity> However, the bug ref is an absolute must for every SRU.
<infinity> Version rules are a bit more fluid. :P
<xnox> stokachu: but it's not a by-default recommended one as per https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
<xnox> =))))
<stokachu> xnox: yea thats the one i go by
<infinity> Do we link that from the SRU process wiki page?  Probably should.
<cjwatson> Believe so
<infinity> Still, I'm not anal about versions conforming to a perfect table of perfection, just that they are sensibly correct and not nutty.
<rbasak> I think it's easier for newcomers when there's a strict set of rules to follow and everyone follows them. Less variation makes it easier to learn by example.
<xnox> infinity: cjwatson: we do. I wonder if it should be magically included as a snippet in both though.
<xnox> cause adding a ready to copy&paste template for bug report improved the bug descriptions as lot!
<infinity> rbasak: Absolutely, hence the table.
<cjwatson> rbasak: The other side is that it's better not to force extra round-trips for things that don't really matter.
<cjwatson> So I'm all for prescriptive documentation, but also all for SRU admins having discretion.
<rbasak> cjwatson: absolutely agree. I more meant for experienced devs to lead with a consistent example, not for sponsors to create round trips for newcomers.
<rbasak> So I would still like uploaders to tweak uploads as necessary to conform to a perfect table of perfection :)
<infinity> rbasak: I break that table's rules with my own packages on a near-regular basis.  But there are some special packages in play here.
<infinity> rbasak: Anyhow, I think we're in violent agreement.  Pointing people to the table is good.
<rbasak> Yeah, exceptions are always exceptional :)
<brendand> is python coverage restricted to running things that end with .py?
<brendand> never mind...
<cjwatson> yolanda: So, maybe this isn't any better (it's rather longer but I think more accurate); I ended up with http://paste.ubuntu.com/5884705/
<cjwatson> yolanda: But luaL_register is a case where the API has genuinely changed in Lua 5.2.  If I were you I would be strongly inclined to punt this to upstream and let them sort it out :-)
<cjwatson> See e.g. http://lua-users.org/lists/lua-l/2013-05/msg00209.html
<cjwatson> Or compare https://github.com/keplerproject/luafilesystem/pull/17
<yolanda> cjwatson, let me check
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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: mdeslaur
<bdmurray> pitti: still about?
<rbasak> cjwatson: apache2 isn't in the server packageset too. Do you think this is also appropriate for an exception?
<rbasak> s/too/either/
<rbasak> This is for bug 1199318.
<ubottu> bug 1199318 in apache2 (Ubuntu Saucy) "package apache2-utils 2.2.22-6ubuntu5 failed to install/upgrade: trying to overwrite '/usr/share/apport/package-hooks/apache2.py', which is also in package apache2.2-common 2.2.22-6ubuntu5" [High,Confirmed] https://launchpad.net/bugs/1199318
<cjwatson> rbasak: I do, yes.  Done.
<hallyn> lifeless: hey - i've had a vm under virt-manager in raring running for most of today, no hint of memory leak yet.  Anything more I should do, like reload something a bunch of times?  Can you paste the .xml for th evms you had running to the bug?
<lifeless> hallyn: I can
<lifeless> mine is at  2601 root      20   0  934m  18m 7696 S   0.0  0.1   0:22.04 libvirtd
<lifeless> ah, virt-manager wasn't connected, reconnecting it. [it d/c'd when libvirtd hit that high ram...]
<lifeless> hallyn: configs uploaded
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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:
<hallyn> lifeless: thanks
<lifeless> hallyn:  2601 root      20   0  934m  21m 8352 S   8.6  0.1   0:50.80 libvirtd
<lifeless> hallyn: 3MB in 8 minutes; 1MB was immediate when I connected virt-manager.
<lifeless>  2601 root      20   0  934m  22m 8352 S   7.7  0.1   0:53.51 libvirtd
<lifeless> and another MB
<hallyn> what on eatth
<hallyn> earth
<lifeless>  2601 root      20   0  934m  24m 8352 S   4.6  0.2   1:03.86 libvirtd
<lifeless> hallyn: well yeah, this is why I filed a bug :)
<hallyn> but why am i not seeing it
<lifeless> hallyn: what columns are you showing per VM ?
<hallyn> ?
<lifeless> hallyn: I have VM, CPU usage and "Host CPU usage' all shown.
<lifeless> hallyn: just wondering if turning on the host cpu usage column might be triggering a different codepath in the daemon
<hallyn> trying that
<hallyn> nothing yet, will keep it running for awhile
<cjwatson> doko: Could you steer clear of apache2 and its stack, just until I ram it all into -proposed?
<cjwatson> I really hope adding lua5.2 hasn't attached some other transition to it
<lifeless> slangasek: "the aikido is strong in this one"
<lifeless> hallyn:  2601 root      20   0  934m  32m 8352 S   8.9  0.2   1:34.10 libvirtd
<slangasek> lifeless: reading d-devel? :)
<lifeless> slangasek: how *did* you guess?
<hallyn> i had to work so hard not to jump in at the repsonse about fedora.vs.ubuntu obPA
<slangasek> heh
<hallyn> "it's ubuntu's fault they bought our line last time.  so it only makes sense you should believe us this time"
<hallyn> lifeless: what exactly is that the output of
<hallyn> ps i assume, what options?  (I'm jst grepping for RSS in /proc/$$/status)
<hallyn> I'm up by 200k after a few minutes.  may or may not be onto something...
<hallyn> it's no 3M/s though
<lifeless> hallyn: top
<hallyn> oh, ok - libvirt isn't on the first page on my top :)
<lifeless> hallyn: press M :)
<hallyn> ok :)
<hallyn> thanks - wasn't thinking.  wel lit's not going up.  i'll have to try a few more things tonight
<lifeless> hallyn: clearly I can reproduce it at the moment :)
<lifeless>  2601 root      20   0  934m  43m 8352 S   6.3  0.3   2:27.94 libvirtd
<hallyn> lifeless: i notice you have two nics, that might be related
<hallyn> but, i'll look back through changelog and compare to your setup
<lifeless> pleia2 is running basically the same setup as I
<lifeless> we're dev/testing OpenStack stuff
<hallyn> say are you using openvswitch bridges for your vms?
<lifeless> yup
<doko> cjwatson, I checked that before the upload, that it doesn't interfer with it
<lifeless> hallyn: https://github.com/tripleo/incubator/blob/master/devtest.md covers the workflow we're working through/automating/polishing.
<lifeless> hallyn: I don't expect the content of the vm's to matter, so you can ignore all the diskimage-builder stuff etc, just climb through the setup-network, boot-seed-vm and create-nodes code.
<hallyn> thx
<lifeless> hallyn: also its a bit inconsistent in growth rate:  2601 root      20   0  934m 119m 8356 S   0.0  0.7   8:11.20 libvirtd
#ubuntu-devel 2013-07-18
<pitti> Good morning
<pitti> bdmurray: I am now; I got your mail
<rbasak> cjwatson: thanks! I'll retry.
<dholbach> good morning
<cjwatson> rbasak: OK - better do it quick because otherwise I might manage to land this whole stack in saucy first :)
<rbasak> cjwatson: done. It's building now :)
<cjwatson> cool
<doko_> SpamapS, online?
<tvoss_> xnox, ping
<yolanda> hi, what steps do i need to follow to test lua 5.2 and ruby 1.9 ? i checked package rubyluabridge but it defaults to ruby 1.8
<xnox> tvoss_: heya
<yolanda> xnox, do you know about that? how to test lua 5.2 bindings for ruby 1.9?
<xnox> yolanda: nope =) no idea.
<yolanda> found that rubyluabridge package but it forces ruby 1.8, so no clue
<Ph0bus> ruby is a wore
<cjwatson> Ph0bus: That's hardly appropriate here
<yolanda> cjwatson, do you know about how to test that bindings?
<yolanda> i'm a bit lost on it
<cjwatson> yolanda: Sorry, haven't the foggiest.  Perhaps contact the Debian maintainers, or the appropriate language development communities
<yolanda> ScottK seems to be the latest uploader
<yolanda> i'll try
<rbasak> infinity: have you upstreamed your golang header patch? Or does someone need to do this?
<cjwatson> Ph0bus> charming chap
<cjwatson> yolanda: Note that rubyluabridge was just auto-synced from Debian, so you might want to update your working tree if you're working on it
<cjwatson> (0.7.0-2)
<cjwatson> Or, well, would just have been auto-synced if bits of LP weren't disabled in preparation for a deployment
<yolanda> cjwatson, lp still shows 0.7.0-1 version
<cjwatson> See my previous comment :)
<yolanda> was typing at same moment :)
<cjwatson> But you can grab it from https://launchpad.net/debian/+source/rubyluabridge/0.7.0-2 in the meantime
<yolanda> ok
<yolanda> just working on other issue now and i'll grab later, great
<jamespage> doko, we where going to talk about go policies this week - when suits you?
<tvoss_> ogra_, ping
<ogra_> tvyup
<ogra_> eh
<ogra_> tvoss_, yup ?
<doko> jamespage, today is fine, after lunch? 2pm?
<jamespage> doko, yeah - thats good with me
<infinity> rbasak: I can push it to Debian, but I'd rather someone bypass them and upstream it directly for me, if we have a decent working relationship with them.
<cjwatson> yolanda: it's synced and (mostly) built now
<yolanda> great
<sil2100> mardy: hello!
<sil2100> mardy: I'm looking at lp:webaccounts-browser-extension right now
<sil2100> mardy: it's not daily-released right now, and I see there are no integration tests there - only unit tests
<sil2100> mardy: do you think it's possible to do integration testing with those branches?
<rbasak> infinity: OK, I'll ask.
<rbasak> infinity, jamespage: bug 1187722 is fixed now then, right, both for dpkg and golang?
<ubottu> bug 1187722 in golang (Ubuntu) "dpkg-shlibdeps fails on armhf ELF binaries that do not define architecture specific information" [High,Confirmed] https://launchpad.net/bugs/1187722
<infinity> rbasak: Oh, I didn't know there was a bug for it.
<infinity> rbasak: Closed.
<doko> infinity, eglibc ping
<mardy> sil2100: I doubt it, it's something very difficult to test
<mardy> sil2100: unless it's possible to programmatically login into facebook
<infinity> doko: See /msg
<doko> thanks
<sil2100> mardy: ACK
<rbasak> infinity: no problem. I just wanted to check that there aren't any tasks remaining, apart from upstreaming.
<infinity> rbasak: Nah, my simple 3-line patch should DTRT and be upstreamable.
<rbasak> ack
<rbasak> I've asked Dave to look into it.
<yolanda> cjwatson, i checked rubyluabridge package, but it still forces ruby 1.8
<cjwatson> yolanda: Sure, I don't actually know about it, I was just letting you know that there was an update since you said you were working on it
<yolanda> i messaged ScottK to talk about it
<Daviey> yolanda: Do you have a partially done branch or dsc you can throw somewhere?
<yolanda> Daviey, for the ruby issue?
<yolanda> i just grabbed rubyluabridge but it has a patch forcing to ruby 1.8, i was told to test with 1.9 so not sure about how to act
<Daviey> yolanda: Right, ScottK did an NMU in Debian, perhaps he has more info.  Looking at the upstream project, certainly no fix there.
<yolanda> Daviey, i pushed a MP for rrdtool, that one is working
<Daviey> yolanda: super
<ev> any archive admins around who want to NEW something for me? https://launchpad.net/ubuntu/saucy/+queue?queue_state=0&queue_text=whoopsie-preferences
<dobey> Laney: sigh. i wonder how these tests ever passed in autopkgtestâ¦
<pitti> software-center? they never did
<dobey> pitti: really? the entire time that software-center has had autopkgtest setup, it's never actually passed?
<pitti> yes, despite several pings they've never been fixed
<pitti> FWIW, if nobody has the time or cares, and there is an upstream test suite that at least succeeds locally, it could just be dropped
<dobey> i don't know if the tests work locally
<dobey> the tests are doing a lot of nasty broken things
<SpamapS> doko: online now. Wassup?
<doko> SpamapS, did you try to cross-build mysql in the past?
<dobey> pitti: ok, since they've never actually worked, i just uploaded a software-center that just removes debian/tests and the X-Testsuite:, please do what you need to do to the jenkins job/britney as a result of that :)
<pitti> dobey: ack
<pitti> jibel: ^ on that note, I'll remove the job from the actual jenkins; does britney look at that, or at the public mirror?
<jibel> pitti, none of them the status is kept on lillypilly. it must be removed from there.
<pitti> jibel: hm,  where do I find that?
<pitti> jibel: proposed-migration/autopkgtest/data/adt/saucy-proposed/amd64/saucy-proposed_amd64_software-center ?
<pitti> jibel: just wipe that?
<sergiusens> cjwatson: seems I made a mistake with the click hook by using people.canonical.com (external name), what's the host or fqdn that the builders see? lillypilly.canonical.com, just lillypilly or another internal domain?
<stgraber> sergiusens: archive-team.internal but that's a view of people.canonical.com/~ubuntu-archive
<dobey> dholbach: hi! can you take another peak at bug #1199017 please? i've updated the dsc/debian.tar for it. thanks
<ubottu> bug 1199017 in Ubuntu "[needs-packaging] ubuntuone-credentials" [Wishlist,New] https://launchpad.net/bugs/1199017
<sergiusens> stgraber: ah, so I need one more step
<dholbach> dobey, will do
<sergiusens> ogra_: ideas? ^^
<ogra_> sergiusens, oh, i totally forgot
<dobey> pitti: so i'm not sure what to do about the u1-client autopkgtest issue. will you add the feature flag to ignore stderr? hacking up the tests to work around autopkgtest behaving differently than everything else seems wrong to me :)
<stgraber> sergiusens: where are those files on lillypilly?
<sergiusens> stgraber: http://people.canonical.com/~sergiusens/click_packages/ but they can be anywhere
<sergiusens> stgraber: you can copy them ... this is what I do  ~sergiusens/click_ready/click_copy.py https://jenkins.qa.ubuntu.com ~/public_html/click_packages
<ogra_> sergiusens, i tallked to cjwatson already ... but wanted to wait for you :) ... the machine is reachable under a different name ond only ~/ubuntu-rachive can be seen ... i think running your copy script from an ubuntu-arechive cronjob and have it dump into ~/ubuntu-archive/public_html/click-packages would be best
<ogra_> stgraber, ^^^
<stgraber> I just put a symlink, looks like it's working: http://people.canonical.com/~ubuntu-archive/click_packages/
<sergiusens> stgraber: awesome
<stgraber> on disk, that's a symlink to /home/sergiusens/public_html/click_packages
<ogra_> stgraber, well, i'm not sure the access from cadejo works that way
<stgraber> ogra_: let me check that
<stgraber> ogra_: it does
<ogra_> sergiusens, so now we need to change the url to http://archive-team.internal/ in livecd-rootfs
<ogra_> (with the proper path indeed)
<stgraber> ogra_: I just tried with wget http://archive-team.internal/click_packages/com.ubuntu.calendar-app_0.4_all.click -O /dev/null from nusakan and that worked fine
<ogra_> stgraber, you have a login on cadejo ?
<sergiusens> ogra_: do you feel jealous? :-P
<stgraber> ogra_: no, but nusakan has access to that vhost/proxy server
<ogra_> nusakan doesnt help :)
<ogra_> the buildd needs to be able to see it
<ogra_> i can see it pulls the seeds from http://archive-team.internal/seeds/
<ogra_> http://archive-team.internal/ being lilliypilly
<ogra_> (see live-build/auto/config)
<stgraber> ogra_: archive-team.internal == 91.189.89.174 which is a separate IP from the main lillypilly IP, so if cadejo can access it, then it has the same view as I'm getting from nusakan which works when access archive-team.internal/click_packages, so I'm 99% sure it'll work fine from cadejo
<ogra_> ok
<ogra_> let me change livecd-rootfs and upload
<stgraber> (the remaining 1% would be IS sending that traffic to squid and having some ACLs restricting to sub-directories of archive-team.internal, but I very much doubt they'd do that)
<ogra_> sergiusens, stgraber, livecd-rootfs change and uploaded
<ogra_> lets see how the next build goes
<pitti> dobey: we can add the feature flag (bug appreciated, so that I don't forget and we can coordinate who will do it); hacking autopkgtest is always a lot of "fun", might take a bit
<dobey> pitti: ok, i'll get a bug filed
<cjwatson> sergiusens: So, I'd prefer for the ubuntu-archive user to be fetching the click packages itself rather than symlinking into your home directory
<cjwatson> sergiusens: Not least because archive-team.internal will soon be a separate *machine*, not just a separate IP address
<cjwatson> sergiusens: Is it possible to run click_copy.py on lillypilly?  I couldn't figure out which Jenkins base URL to use
<sergiusens> cjwatson: this is what I do  ~sergiusens/click_ready/click_copy.py https://jenkins.qa.ubuntu.com ~/public_html/click_packages
<SpamapS> doko: no, I have noly ever built it for x86
<SpamapS> only
<SpamapS> doko: well and arm ... it has some signed char issues IIRC
<cjwatson> sergiusens: Huh, could've sworn I'd tried that, thanks
<cjwatson> sergiusens: I'll cron that in a bit then
<ogra_> yay
<sergiusens> thanks
<cjwatson> sergiusens: do you have it cronned at the moment?  what's the frequency?
<sergiusens> cjwatson: I don't, wanted to get an intial build before stressing anything, the click packages are built once a day, so once a day is good enough
<sergiusens> a good time would be before the actual touch build but not really as important
<ogra_> cjwatson, something like 6 or 7am UTC should be fine
<pitti> jibel: did you notice my question about removing the britney software-center check?
<pitti> pitti | jibel: proposed-migration/autopkgtest/data/adt/saucy-proposed/amd64/saucy-proposed_amd64_software-center â just wipe that?
<jibel> pitti, yes that's the file, but if the source with a XS-TEstsuite header is still available in the release pocket it will recreate it.
<pitti> jibel: ah, chicken-egg problem
<jibel> pitti, yes. the copy must be forced, in any case that won't hurt since the tests have been removed.
<sil2100> Wellark: hi!
<sil2100> Wellark: could you tell me what's up with lp:~unity-team/unity-action-api/nohud ? Is it supposed to be daily-released as well? Should this land to distro?
<jodh> jibel/pitti: hi - can I pester you about bug 1158391? I need to get DEP-8 integration tests working for upstart in the next few weeks so really need the ability for an autopkgtest env to spin up a nested kvm instance say and prod it in various ways.
<ubottu> bug 1158391 in Auto Package Testing "ability to have a DEP-8 test run a test in a separate full system environment" [High,Confirmed] https://launchpad.net/bugs/1158391
<rbasak> Perhaps I should write an adt-virt-libvirt at some point
<rbasak> Or just a direct adt-virt-kvm
<rbasak> xnox: I'm having some trouble reproducing your apache 2.4 upgrade problem. I tried installing libapache2-mod-wsgi first, but the upgrade didn't fail.
<xnox> rbasak: i'll try to recreate my setup and i'll let you know.
<rbasak> THanks
<rbasak> Looks like apt chose in my case to configure libapache2-mod-wsgi before apache2.2-bin but after all unpacks.
<rbasak> I'm not quite clear on the ordering required to reproduce it.
<pitti> jibel: ah, thanks
<pitti> Laney: can you do the magic to let software-center in despite failing tests? (-proposed removes the tests deliberately)
<Laney> pitti: how are there failing tests then?
<cjwatson> Laney: Apparently something in the stack is not good at handling removed tests and considers them a failure
<pitti> Laney: it never succeeded, but jibel says our britney integration requires forcing this once
<cjwatson> That is, adt-britney incorrectly requests a test run when there are no tests in that case
<Laney> Yeah, seems like a bug
<Laney> as long as jibel knows about it :-)
<cjwatson> Should be sufficient to force-badtest it
<Laney> indeed, but I didn't want to without making people at least aware
<pitti> well, that saved us from accidentally losing tests yesterday
<pitti> and it's the first time we actually remove a test (and I hope that won't happen too often)
<mdeslaur> rbasak: are you planning on merging php5 5.5.0+dfsg-15 ?
<rbasak> mdeslaur: wow. Struggling to keep up!
 * rbasak looks
<rbasak> mdeslaur: I understand why you asked now. If I do, I won't get around to it until tomorrow afternoon at the earliest I think. Do you need it sooner?
<mdeslaur> rbasak: I can do it now if you don't mind
<rbasak> mdeslaur: sure, go ahead. Or just a cherry-pick if that's appropriate. At the pace they're going I expect to do at least another merge before release.
<mdeslaur> rbasak: ok, I'll handle it...just wanted to make sure you didn't start something already. Thanks!
<stgraber> cjwatson: hey, so I'm looking at those ubiquity and grub2 changes to always install and use the shim on EFI. My current plan is to simply remove the sb check in ubiquity so we always install shim-signed, grub2-signed and linux-signed, then change grub-install to always set the shim as the boot entry if it exists and grub2-signed is installed. Did I miss anything?
<rbasak> mdeslaur: OK. Thanks for checking!
<sil2100> Wellark: if you're around, could you backlog to the question I posted earlier?
<sil2100> Wellark: thanks
<cjwatson> stgraber: You need to change grub-installer as well, before ubiquity
<cjwatson> (i.e. both grub-install and grub-installer)
<Laney> ev: Hey, I'm just looking at your system-settings MP... is it supposed to work on desktop?
<Laney> your first isValid() call returns false here for me
<ev> Laney: it needs activity-log-manager installed at the same time. I'm working on splitting out the dbus service into the whoopsie-preferences package
<Laney> ev: I already had that
<Laney> I can see it in d-feet (but get polkit errors when I try to query the methods)
<ev> oh right, sorry
<ev> the other part is you need to abuse /var/lib/polkit-1/localauthority/10-vendor.d/com.ubuntu.desktop.pkla
<smoser> pitti, i'm looking at ./debian/extra/initramfs.top in lp:ubuntu/systemd
<smoser> http://paste.ubuntu.com/5887973/
<ev> Change crash reporting settings]
<ev> Identity=unix-group:admin
<ev> Action=com.ubuntu.whoopsiepreferences.change
<ev> ResultActive=yes
<ev> Laney: ^
<smoser> the ROOTDELAY lines blame to you. i dont think that you authored them, but i'm wondering if you could provide some insigth there.
<stgraber> cjwatson: ah right, forgot that one, thanks
<pitti> smoser: no idea, I'm afraid; I mostly took what we had in the old udev scripts, and I was afraid to remove it
<pitti> smoser: but it is certainly a gross hack
<pitti> smoser: as with wait-for-root it should just work
<smoser> pitti, i've never seen it before
<smoser> it is not in raring
<pitti> smoser: ah, then maybe it came in through debian
<smoser> they dont have that file in their systmed package
<pitti> smoser: right, not in version 44, it's from the 182 packages
<pitti> smoser: anyway, is that creating a problem?
<pitti> smoser: we can certainly take it out, but it seems like a no-op
<smoser> for context, on azure, we had been booting with the 'rootdelay=' which is a similarly crappy hack to deal with the fact that their scsi disks are terribly underperformant.
<smoser> and now we're seeing bug 1202700 because of this sleep.
<ubottu> bug 1202700 in linux (Ubuntu Saucy) "saucy kernel 300 second hang before root mounted rw on azure" [Medium,Confirmed] https://launchpad.net/bugs/1202700
<smoser> its not a no-op for sure.
<smoser> if you boot with rootdelay= it most definitely causes a sleep of that long.
<pitti> smoser: yes, but I meant if that didn't exist in raring, why would this parameter exist?
<smoser> the parameter in raring goes to wait-for-root
<smoser> it increases its default timeout
<smoser> (and it still doe sgo there in saucy, it just also gets used here :)
<utlemming> rootdelay for the kernel means wait up to X for the root to appear, but doesn't have to wait that long
<smoser> utlemming, it doesn't mean anything to the kernel.
<pitti> smoser: aah, ok; so we shared the parameter, but now got a second implementation
<smoser> just to 'wait-for-root'
<smoser> and initramfs.
<smoser> well, it seems it came and went in debian.
<smoser> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=414842
<ubottu> Debian bug 414842 in udev "udev: Add support for the ROOTDELAY parameter" [Serious,Fixed]
<smoser> i suspect somehow we merged bad or something...
<pitti> no, they just implemented it differently
<smoser> hm..
<pitti> the wait-for-root program is an ubuntuism, it's not in debian
<smoser> well, wait-for-root is better.  :)
<pitti> so the sleep shoudl certainly go away from the initramfs script then
<utlemming> smoser: https://www.kernel.org/doc/Documentation/kernel-parameters.txt
<pitti> smoser: wait-for-root is better> for sure :)
<smoser> utlemming, it must do nothing if there is an initramfs.
<pitti> smoser: the part that I don't understand is why that parameter is needed at all; it still smells like a bad hack
<pitti> sleep is never the right answer for those kinds of problems
<smoser> pitti, it is.
<smoser> well, right.
<utlemming> pitti: for Azure, it was requested by MS
<smoser> on azure its necessary
<smoser> because their devices suck
<smoser> the disks might just not wake up for 300 seconds
<smoser> and you should pretned that is not a bug
 * smoser ends rant
<smoser> anyway.
<smoser> pitti, so you support me just dropping those lines in our systemd ?
<pitti> smoser: ah, so is that mostly to just extend the timeout of wait-for-root? (that defaults to 60 seconds, I think)
<utlemming> the actual reason, given by MS is that on earlier version of Azure, the network backed devices might have the full the disk presented during the time of boot.....but smoser summed it up nicely
<pitti> smoser: yes, sure
<smoser> pitti, thanks for your help.
<pitti> so for ubuntu, that command line argument should mostly change the 60 seconds wait-for-root timeout, not actually sleep for that time
<smoser> pitti, it does
<pitti> with that semantics it would make sense, WDYT?
<pitti> ah, good
<pitti> smoser: thanks!
<smoser> or at least it used to :)
<smoser> but i'll make sure.
<pitti> smoser: committed to my local packaging git
<smoser> ah.
<pitti> smoser: I plan some other systemd debugging/fixes tomorrow, is that enough? or do you want it uploaded now?
<smoser> well then.
<smoser> thank you.
<smoser> i was going to do it
<smoser> but good enough
<smoser> in looking, i find that cryptsetup also reads ROOTDELAY
<smoser> but it does a 'while sleep .1' for 10 x ROOTDELAY.
<smoser> so thats much better than 'sleep ROOTDELAY'
<smoser> but it should probably still use wait-for-root
<cjwatson> jbicha: Um, when you synced https://launchpad.net/ubuntu/+source/packagekit-qt, you did realise that that would break future attempts to upload 0.7-series packagekit, right?
<xnox> jodh: looks like pre compiled headers work fine with gcc4.8. So must be something with abi-compliance-checker!
<jodh> xnox: interesting - I'll take a look tomorrow.
<stokachu> is there a way to tell bzr to use-existing-dir within the conf file?
<jbicha> cjwatson: I only synced it after packagekit 0.8 had been in saucy-proposed for ~6 weeks
<jbicha> anyway, the pk8-compatible aptdaemon should be nearly ready for saucy https://code.launchpad.net/~aptdaemon-developers/aptdaemon/main
<jbicha> I was surprised that pk-qt didn't get stuck in -proposed like the rest of the pk8 stack, and no I didn't realize that would prevent uploading "newer" pk7 updates
<dobey> anyone know why i would get a symbols change error immediately after generating the symbols file, building a source package with the new file, and then trying to build the binaries in pbuilder? it makes no sense to me, and i can't figure out how to make it not happen
<cjwatson> jbicha: ah, right, packagekit got deleted from -proposed ...
<cjwatson> jbicha: indeed, I saw about aptdaemon, I just have packagekit changes to land in advance of that.  I'll work around it
<dobey> should i just pull the .symbols file for now and not worry about it?
<cjwatson> wg 28
<cjwatson> doh
<jdstrand> cjwatson, mdeslaur, sbeattie: I just responded to the ubuntu-appstore-developers list asking for confirmation that we agree on the new json structure. can you guys respond (so everyone can be unblocked)?
<jdstrand> it sounds like we are, but wanted to be sure
<sbeattie> jdstrand: responded
<mdeslaur> jdstrand: yep
<jdstrand> sbeattie: I'll ditch the unconfined profile too
<mdeslaur> jdstrand: hum? unconfined profile?
<jdstrand> sorry,unconfined template
<mdeslaur> what do you mean by "ditching it"?
<jdstrand> mdeslaur: well, sbeattie mentioned we could remove it, but now that I think about it, I think we may still want it
<mdeslaur> we can't remove it, the upstart job still needs to switch to it
<cjwatson> replied
<cjwatson> There's no rush to ditch unconfined
<jdstrand> mdeslaur: right
<jdstrand> cjwatson: thanks
<dobey> anyone?
<sbeattie> mdeslaur: ah, right.
<cjwatson> jdstrand: It turns out that 30C heat in a country without pervasive aircon is not the optimal weather for doing complex rearrangements of hook execution code, but I'm trying ;-)
<cjwatson> (Not that I expect complaints about heat to get much sympathy from your neck of the woods)
<mdeslaur> hehe :)
<jdstrand> cjwatson: haha :)
<jdstrand> actually, we've had unseasonably cool and rainy weather here this week :)
<slangasek> (if you can't stand the heat, stay out of Texas?)
<ScottK> Plus Texas is the land of pervasive air conditioning.
<jdstrand> and fans. don't forget the fans
<mdeslaur> stepping back from the BBQ is kind of like air conditioning
 * jdstrand is getting hungry
<xnox> dobey: well, please provide logs of the local build and pbuilder. cause e.g. symbols of libraries used can link into your symbols, especially if local build is on raring and pbuilder on saucy-proposed.
<dobey> xnox: that seems like a complete failure of the system if so. the symbols provided by a library shouldn't change between raring and saucy
<xnox> dobey: depends what you code. if you include a boost template, boot transition from 1.49 to 1.53 between raring and saucy suddently the same API compatible template changes functions, boom you can new/changed symbols in a saucy rebuild.
<dobey> does that only happen with c++ or something crazy?
<xnox> dobey: that's not the only case.
<xnox> dobey: e.g. gcc-4.8 change symbol visibility / export rules slightly, enough to break bionic and loading binary drivers on android.
<xnox> dobey: and that's pure c
<xnox> (with with assembly)
<dobey> so yes, "something crazy" :(
<xnox> dobey: so nobody can tell what's going on between your local build and pbuilder, without seeing the logs.
<xnox> dobey: i'm sure, our toolchain is deterministic producer of symbols in same or compatible environments.
<xnox> =)))))
<dobey> :(
<xnox> dobey: better give the URL to the source package in question and the logs of local build vs saucy build.
<stgraber> cjwatson: is bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/saucy/grub2/saucy/ the right branch for grub2? the status of the patches in this one appears to be a bit weird (they're applied but .pc is empty, so quilt refuses to push/pop patches)
<xnox> stgraber: lp:~ubuntu-core-dev/grub/ubuntu ?
<xnox> nah, that one looks old.
<xnox> stgraber: does http://people.canonical.com/~cjwatson/dpkg-quilt-setup help at all?
<stgraber> xnox: ah I think it'd yes, that also explains what I'm seeing in the branch I think
<dobey> xnox: well, if gcc changed things, then that must be it
<xnox> stgraber: i remember using that for some of patches-applied-pc-dir-vcs-ignored packaging styles
<stgraber> (well, except that .pc exists in my case but is empty ;))
<xnox> dobey: don't assume, can you not like pastebin the diff of symbols that pbuilder generated for you?
<jdstrand> sbeattie: if we have this in the click manifest:
<jdstrand> "hooks": {
<jdstrand>   "myapp": {
<xnox> stgraber: =)))))) patches-applied-.pc/*-vcs-ignored packaging styles
<jdstrand>   "apparmor": "apparmor/myapp.json",
<dobey> xnox: well, i did gensymbols on raring (local), and pbuilder on saucy, so yeah. it explains it. plus pbuilder didn't fail when building on raring.
<dobey> xnox: and the symbols are all low level red-black tree things in qt or something :(
<jdstrand> sbeattie: I understand the a symlink will be created that is of the form $name_myapp_$version
<jdstrand> sbeattie: what is creating that symlink?
<dobey> that should not be exported anyway, but yay c++ is crazy
<jdstrand> oh, you know, let me reread the spec
<xnox> dobey: c++filt makes those symbols not look crazy. but is it still compatible?! =/
<jdstrand> "On install, the package manager creates the target path as a symlink to a path provided by the Click package"
<jdstrand> sbeattie: nm
<dobey> xnox: http://pastebin.ubuntu.com/5888378/
<xnox> dobey: looks to me like abi got broken http://paste.ubuntu.com/5888384/
<xnox> dobey: and it's not in the Qt* symbols anything. Are you using C++11?
<dobey> xnox: no: -std=c++0x is what is passed to g++
<stgraber> slangasek, cjwatson: So, I've got: http://paste.ubuntu.com/5888394/ http://paste.ubuntu.com/5888396/ http://paste.ubuntu.com/5888397/
<stgraber> I "think" that's all that needs changing but I can't very easily test it as the real test is spinning a new media with all of those landed
<dobey> would be nice if the symbols stuff could avoid things that aren't directly from the library.
<stgraber> so my plan is to push that to the archive today, spin a new desktop image as soon as I can, test that in an OVMF VM without SB, confirm I boot through shim, and if that's the case, then push the same change to precise tomorrow
<dobey> but yes, definitely a change in stl there
<xnox> dobey: well, if it's a change in templates, it does get included in your library, it also means at the moment that ABI is broken and you need to recompile all reverse-dependencies as raring packages will fail with this saucy build lib.
<dobey> xnox: is there really no way to make this work correctly on both saucy and raring with the same symbols file?
<xnox> dobey: the problem here is not about "getting symbols to work", but that abi is broken and incompatible library is getting built.
<xnox> the solution here is to either: bump the soname or fix the abi to stay the same.
<dobey> there is no change in abi in the code. this is a problem of g++ breaking things
<dobey> all i want to do is have a package that can be built on both saucy and on raring, without changes
<dobey> why is that so hard to do?
<xnox> well a crashing application doesn't care where the problem is, apart from that libfoo.so.2.0.0 is missing symbols.
<xnox> dobey: it is most likely in your code. By the say specifying -std=c++0x is unstable abi as that's what c++11 was known as before releasing.
<dobey> "they say" ? who is they? and where do they say that?
<dobey> (and it's not my code, i didn't write libsdtd++)
<xnox> dobey: Gnu GCC upstream -- enable experimental features to support c++11 standard.
<xnox> dobey: the package specified to build with that standard enabled one way or the other, thus it's in the package's code. as c++0x is not the default.
<xnox> (packaging or upstream)
<xnox> SET (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++0x -O2 -g -Wall -Werror -fPIC") in https://bazaar.launchpad.net/~ubuntuone-control-tower/ubuntuone-credentials/trunk/view/head:/CMakeLists.txt
<xnox> dobey: try compile on raring without specifying "-std=c++0x" and compile on saucy, and compare the symbols between the two.
<xnox> "Important: GCC's support for C++11 is still experimental. Some features were implemented based on early proposals, and no attempt will be made to maintain backward compatibility when they are updated to match the final C++11 standard."
<xnox> http://gcc.gnu.org/projects/cxx0x.html
<doko> dobey, why do you include symbols of libstdc++ at all in the symbols files?
<dobey> doko: i didn't make a choice to do so
<doko> dobey, but you do have the choice to fix it
<dobey> i'm trying to understand why those symbols are there, and how to fix it
<dobey> but telling me my library broke ABI just because it was built on a different version of ubuntu doesn't help me
<xnox> doko: how? mark them as (optional)? but isn't the abi broken?
<doko> xnox, how would it? it's not part of the API of this library
<dobey>  error: non-static data member initializers only available with -std=c++11 or -std=gnu++11 [-Werror]
<dobey> bah
<xnox> (yeah, c++0x is now aliased to c++11, due to standard rename after final publication)
<xnox> dobey: (c++|regex|optional)"std::.*@Base 13.07" in the symbols file, should make any removals/changes ignored under std::* namespace.
<dobey> xnox: where is that documented? http://wiki.debian.org/UsingSymbolsFiles is not especially helpful here :-/
<xnox> dobey: man dpkg-gensymbols and https://wiki.ubuntu.com/DailyRelease/FAQ#I.27m_exposing_a_new_C.2BAC8-C.2B-.2B-_symbols_in_my_library.2C_it_seems_that_some_packaging_changes_are_needed.2BICY-
<xnox> dobey: the later shows how to use "c++" filter/tag, but not the others "optional, arch, ignore-blakclist, symver, regex"
<dobey> xnox: what should be in the .symbols file though? the mangled symbols, or the filtered ones?
<dobey> it's not exactly clear what the preference is for that
<xnox> dobey: so by default one uses symbols as they are _Zloadsofgibberish@Base 1.0, but that's not very nice for C++ since some of mangled names are architecture specific due to different sizes of things.
<dobey> xnox: so it would also likely fail building on i386 or arm, even if it didn't fail on amd64, with the mangled symbols?
<xnox> dobey: thus ideally for most symbols one would use full symbols (those that stay the same across all arches), and for arch specific ones use (c++)"myclass::foo()" name, to avoid commiting symbols.i386 symbols.armhf etc...
<xnox> dobey: correct.
<xnox> dobey: because c++ is crazy, i preffer to use (c++) for all c++ symbols, to have demangled names across the board. That does hide some changes, where mangled name changes to indicate some abi change, yet demangled name is staying the same.
<xnox> but that's the price one pays for it.
<dobey> it would be nice if gensymbols just did the right thingâ¦
<xnox> dobey: to catch remaining changes, I'm working on making dh-acc which takes complete dump of symbols & headers for each arch and generates and checks both ABI and API compatibility.
<xnox> by using abi-compliance-checker
<xnox> but that's still work in progress.
<xnox> dobey: i think, it would be all ok in your case and "done the right thing..." if c++0x/c++11 was not used =/
<dobey> xnox: well, no. it wouldn't have the (c++)Foo::bar()@Base for all the symbols, they'd still be mangled
<dobey> and it would still probably include things that aren't really part of the library itself, i presume
<xnox> dobey: yeah, true, since the std::* is for some reason exported in your example.
<xnox> let me find another example i did.
<xnox> dobey: https://code.launchpad.net/~didrocks/qtubuntu-sensors/symbols/+merge/170603
<xnox> in that one there are actually all symbols part of the api, and no other stuff from std::*
<xnox> dobey: i'm not that good with c++ but it is strange that std::* symbols are getting exported.
<dobey> and QByteArray::* is also being exported
<slangasek> stgraber: testing the whole thing might require an image, but surely the grub2 package itself could be tested locally?  since the grub2 package should fix this up on upgrade as well
<dobey> why is all this stuff being exported here i wonder :(
<dobey>  (c++)"QString::QString(char const*)@Base" 13.07
<dobey> for example
<slangasek> stgraber: although, does the installer not install grub2-efi-amd64-signed for us in that case? hrm
<dobey> that doesn't belong there. we don't provide the QString object
<xnox> dobey: i never had formal C++ education, so it's all even more fuzzy to me =)
<infinity> xnox: Make the upstart testsuite stop sucking.  Thanks.
<slangasek> (grub-efi-amd64-signed, I mean)
<xnox> infinity: yeah, that would be good..... managed to reproduce it outside of launchpad?
<xnox> infinity: i could disable it on powerpc/buildds, but it does seem wrong, w.r.t. how and why it's hanging.
<infinity> xnox: Erm, I probably can, except the thing that triggered the memory was mir, not upstart.  It's one of those days.
<slangasek> stgraber: so actually, that's a point... what does http://paste.ubuntu.com/5888394/ wind up doing on upgrade, if grub-efi-amd64-signed (or shim-signed) is not installed?  seems like it'll fail?
<infinity> xnox: Can I blame you for the Mir testsuite too? :)
<xnox> infinity: sure! =) if that helps you work, why not.... =)
<infinity> Awesome.  Done.  Big jerk.
<slangasek> stgraber: ahhh nope, I see -     if [ "$uefi_secure_boot" = yes ] && [ -e "$efi_signed" ]; then
<stgraber> slangasek: right, it won't fail but won't install the missing package either. So upgrades won't magically fix systems, they'd still have to install the packages or reinstall.
<stgraber> slangasek: though by the nature of the bugs reported so far, I doubt it's a big problem as people aren't likely to be able to boot the system in the first place
<xnox> a quirk could be added to do-release-upgrade?!
<stgraber> xnox: well, any system that booted isn't likely to be affected by the bug so I don't see what that'd gain us
<slangasek> stgraber: right, there is that :-)
<slangasek> stgraber: anyway, that does mean a useful test of grub post-install would be to install grub-efi-amd64-signed + shim-signed, rerun grub-install on a non-SB system, and see what happens
<stgraber> slangasek: yep, doing that now
<xnox> stgraber: is there a bug description? i'd like to be able to have efi machine install, upgrade bios, toggle secureboot on, reboot and it boots/works.
<slangasek> stgraber: it gains us future-proofing against firmware changes down the line, fwiw
<stgraber> slangasek: confirmed that a non-SB system becomes SB-ready once shim-signed and grub-efi-amd64-signed is installed (and not before those two are)
<stgraber> xnox: the bug I'm trying to address here is https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1184297
<ubottu> Ubuntu bug 1184297 in ubiquity (Ubuntu Precise) "Secure boot failed, claiming boot is against security policy" [High,Triaged]
<slangasek> stgraber: ok, cool
<stgraber> xnox: so I'm mostly interested by new installs of 13.10 and 12.04.3
<stgraber> slangasek: so I'll upload the new grub2 and grub-installer, wait for those two to publish in the release pocket, then push ubiquity and test a new daily, if all looks good, I'll push the same to precise-proposed tomorrow
<slangasek> stgraber: LGTM
<stgraber> if we really wanted all existing users to get the shim by default, the easiest way would be for grub-efi-amd64 to depend on grub-efi-amd64-signed and shim-signed (or recommend them)
<stgraber> not sure it's something we want to do just yet though
<xnox> stgraber: i see. so i guess i can simply install *-signed here to be like everyone else ;-)
<stgraber> xnox: yep, install all the -signed then the grub I'll upload in a minute and it'll just work
<slangasek> making grub-efi-amd64 depend on grub-efi-amd64-signed would present bootstrapping problems
<stgraber> good point
<dobey> xnox, doko: ok, i got a version building, but it has some +symbols mentioned in the build log, for a bunch of Qt stuff, which also shouldn't be exported. would prefer to just make it so this stuff isn't getting exported if you have any ideas, but if i have to add the optional/regex flag for them, i guess i can do that too.
<xnox> dobey: .symbols file is merely a dpkg check. nm -C -D *.so still shows all of those symbols exported.
<xnox> dobey: if compiled like so:
<xnox> g++ -fvisibility=hidden -Wl,-z,relro -Wl,-Bsymbolic-functions -std=gnu++11 -fPIC -I. -I/usr/include/qt5 -I/usr/include/qt5/QtCore -I/usr/include/qt5/QtNetwork -I/usr/include/libsecret-1 -I/usr/include/glib-2.0/ -I/usr/lib/x86_64-linux-gnu/glib-2.0/include/ -DPROJECT_VERSION='"foo"' -shared -Wl,-soname,1.0 -o libfoo.so *.cpp
<xnox> dobey: i get a reduction from 736 -> 467 symbols exported, but it still shows a lot of stuff exported.
<xnox> dobey: there is some indication that when a derived class is exported, its parents class' symbols also get exported
<dobey> xnox: i don't think we're deriving from QString or QByteArray anywhere. only QObject or maybe something higher level
<slangasek> the surest way to control what symbols are exported is to use a version script
<xnox> slangasek: do you have an example for c++ code though?
<xnox> -fvisibility-inlines-hidden brings me down to 393 exported symbols.
<dobey> i wonder if it's moc that's causing the problem
<slangasek> no, I expect the version script for C++ might not be very pretty :)
<slangasek> but would support globbing
<slangasek> on symbol names, not on C++ function names
<xnox> but like even things like "oauth_free_array" are still exported, which is C functions, from a linked library
<cjwatson> stgraber: Those all look basically right to me.  Thanks.
<cjwatson> (Belatedly)
<xnox> slangasek: dobey: even with version script matching against public* results in 189 symbols exported with many unneeded ones
<xnox> http://paste.ubuntu.com/5888666/
<xnox> which is better than current 736 symbols.
<xnox> (down to 189 at the moment)
<dobey> xnox: not sure where you got the 736 from
<xnox> well nm -C -D *.so | wc
<xnox> or is that not the same as exported symbols?
<dobey> xnox: add --defined-only do that nm?
<xnox> dobey: down to 1 symbol, I guess I overdid it now =)
<xnox> great, now I only have std::* symbols exported and none of the UbuntuOne::* =(
<dobey> i have 170 with -fvisibility-inlines-hidden and -Wl,--as-needed
<xnox> dobey: yeah, that looks good. all the C stuff is gone, but there is till a bit of std::* left and Q* stuff.
<dobey> yeah, i'd love to know how to get rid of the stl and qt stuff
<xnox> dobey: http://accu.org/index.php/journals/1372 seems like a proper description of versioned script for C++
<xnox> dobey: win!
<xnox> dobey: http://paste.ubuntu.com/5888713/
<xnox> dobey: -Wl,--version-script=exports.version   , where exports.version has
<xnox> dobey:
<xnox> http://paste.ubuntu.com/5888715/
<xnox> slangasek: ^^^ just like dpkg-gensymbols has (c++) filter for names, so does GNU linker.
<dobey> wonder if i should bother with the --as-needed then
<xnox> dobey: i don't think you should. at the moment this is a catch all script. but you can wrap it with UBUNTU_ONE_13.07 { }; for example to version your symbols, and then you can change the abi, by exporting updated symbol under new version.
<xnox> dobey: as done later on in the article from http://accu.org/index.php/journals/1372
<xnox> dobey: so, now my question, is why doesn't "the toolchain do the right thing by default", it's not that hard to syntactically see what's getting exported / public.
<dobey> yeah, i don't know :)
<xnox> dobey: thanks for bringing this issue up, this was fun =)
<dobey> xnox: well, i suppose using globs together with symbol versioning, is not a great plan
<dobey> would need to be explicit for that
<xnox> dobey: there is -export-symbols-regex that can be used instead of writting it out in a file for simple regexp.
<dobey> xnox: it would be easier if c++ didn't require #include of private headers, to satisfy usage of things from them in the private section of a class
<dobey> because i really don't want to export *all* the symbols, only some of them. but since we're forced to install extra headers, it's a bit of a pain
<dobey> hopefully i can figure out a way to fix that soon though, and only export the things we want/need to export
<xnox> now, you are just getting picky =)
<dobey> well, i just don't want people to use API that is almost certainly going to break :)
<xnox> =)))))))
<dobey> oops
<dobey> /home/dobey/Projects/canonical/ubuntuone-credentials/authlib-export-map/libubuntuoneauth/requests.h:44: undefined reference to `vtable for UbuntuOne::OAuthTokenRequest'
<dobey> plenty of those when it tries to build the test program that links
<dobey> that's with UbuntuOne::*; in the version script
<dobey> the 'vtable for FOo*' are definitely not in the nm output now :-/
<dobey> so this sucks :(
<dobey> oh, wtf; cmake is being stupid. it's trying to add the -Wl,--version-script= to the test target as well. even though i only added to the lib target.
<Noskcaj> roaksoax, kirkland: I've made wiki page for the testdrive hackfest. wiki.ubuntu.com/QATeam/Testdrive/Hackfest If either of you could be online through part of it that would be great. I'm still looking for someone to run it from 1600-2000UTC
<sarnold> pitti: hello :) I think the retracer service may be sick; https://bugs.launchpad.net/bugs/1201254 was filed three or four days ago, but still has the 'need-i386-retrace' tag and coredump file attached
<ubottu> Error: ubuntu bug 1201254 not found
#ubuntu-devel 2013-07-19
<pitti> good morning
<pitti> sarnold: thanks for pointing out; seems something again swallowed the failure cron mail :/
<pitti> sarnold: restarted
<pitti> wgrant: hm, saucy langpack export is supposed to happen twice a week now, right? but https://translations.launchpad.net/ubuntu/saucy/+language-packs still doesn't have any packs
<pitti> dobey: FYI, bug 1197005
<ubottu> bug 1197005 in autopkgtest (Ubuntu) "Add "expect stderr" restriction" [Medium,Triaged] https://launchpad.net/bugs/1197005
<doko> jibel, pitti: looking at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html, and trying to understand why two test for perl fail ...
<pitti> doko: adequate just recently got a new test via debian which fails; that can probably be overridden by the release team with a badtest marker
<doko> saucy-adt-adequate doesn't show any useful hints, at least I can't see any
<pitti> abi-compliance-checker also never succeeded, so its test needs to be fixed
<pitti> adequate             SKIP Test breaks testbed but testbed does not advertise revert-full-system
<pitti> ah yes
<pitti> we need to teach autopkgtest that this is ok when running in a VM, I'll think about that
<pitti> in the meantime, a badtest marker should do
<doko> does debian run these tests at all?
<doko> pitti, ^^^
<pitti> doko: not in a central jenkins instance
<pitti> (at the moment)
<Laney> I haven't managed to get the same environment that jenkins provides, especially wrt. internet access
<Laney> see- software-center was passing in run-adt-test for me
 * Laney forces adequate
<Laney> pitti: shouldn't that have been regarded as a pass anyway though?
<Laney> all tests skipped because we don't know how to run them
<pitti> Laney: yes, it should
<pitti> Laney: we still want to know about those, but ideally it woudln't block propagation in this case
<Laney> yeah
<Laney> some kind of pass-but-investigate-me state
<sil2100> gema: hi!
<sil2100> gema: I have filled in 2 bugs that are currently blocking the daily-release of the unity stack
<sil2100> gema: LP: #1202972 and LP: #1202976
<ubottu> Launchpad bug 1202972 in Unity "Nux ABI break without Unity dependencies bump" [High,New] https://launchpad.net/bugs/1202972
<ubottu> Launchpad bug 1202976 in Unity "Unity preview autopilot integration tests failing" [High,New] https://launchpad.net/bugs/1202976
<gema> sil2100: are those bugs in the code or in the tests or where?
<sil2100> gema: the first one I might be able to help with, but the autopilot test failures needs some attention from upstream
<doko> pitti: how often is the autopkgtest information in update_excuses updated? (looking at the failing test for gcc-4.8, which now passes)
<sil2100> gema: about the test failures, hm, not sure what's wrong really - those look more like real failures, or something
<gema> sil2100: ack
<pitti> doko: I guess each time the publisher runs, so something like every 20 mins presumably
<sil2100> gema: someone from the unity team I think should check those out
<gema> sil2100: we are working on triaging problems on a pad today: http://pad.ubuntu.com/test-triaging
<gema> sil2100: I added your bugs to my list
<didrocks> thanks sil2100, gema ;)
<gema> didrocks: anything else that is blocking you, add to that pad, plz
<didrocks> gema: I asked sil2100 to add those, all the rest is published and AP tests run successfully on the desktop
<didrocks> (and are now copied to distro)
<didrocks> gema: there are mir-related fixes/issues we are working on, but it's not in distro yet :)
<gema> didrocks: ok
<sil2100> There's also a webapps problem, but I'll look into that later, I have hoped Robert resolved the issue yesterday
<didrocks> sil2100: he did an additional merge for components
<didrocks> sil2100: maybe he didn't get that deployed or the full list right
<doko> pitti, strange, because the successful test run was at 4:52am
<pitti> doko: you mean the scipy one, right?
<doko> pitti, yes
<pitti> jibel, cjwatson: ^ any idea why https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-python-scipy/ succeeded hours ago, but http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html still shows it as FAIL?
<jibel> pitti, looking
<jibel> pitti, odd, I see no record of the successful build apart the result in jenkins
<pitti> jibel: while I'm hackign on autopkgptest, anything else that is urgent on your list?
<pitti> https://launchpad.net/ubuntu/+source/autopkgtest/+bugs?orderby=status :)
<jibel> pitti, nothing else urgent on my list
<pitti> jibel: d'accord, merci
<jibel> pitti, oh, there was the LXC driver
<jibel> is it something that you think is ready to merge upstream?
 * pitti looks for the MP
<pitti> https://code.launchpad.net/~racb/ubuntu/saucy/autopkgtest/lxc/+merge/172856
<pitti> jibel: it looks okay from my POV, I just haven't tested it yet as I don't have a real container setup
<jibel> pitti, okay, I'll do more test with that backend and update the MP
<rbasak> xnox: I still haven't been able to reproduce your apache 2.4 upgrade failure. AFAICT, since the modules used to depend on apache2.2-common and that package no longer exists, and the new ones depend on apache2-api-20120211, the apache 2.4 postinsts generally runs first, and then the module ones. So I can't find a combination that breaks.
<seb128> cjwatson, hey, do you have click packages example somewhere to download? (I want to install some on my touch image to play with click list and the system settings ui)
<ogra_> seb128, http://people.canonical.com/~sergiusens/click_packages/
<ogra_> they are also in todays image
<ogra_> oh, wait, old url
<ogra_> seb128, http://people.canonical.com/~ubuntu-archive/click_packages/
<ogra_> thats the right one
<xnox> rbasak: let me roll back to july 18th 10am and upgrade again.
<rbasak> xnox: if you could grab the unpack/configure ordering on the upgrade when it fails, that'd be awesome. And which package's postinst failed?
<xnox> rbasak: apache2 post-inst failed.
<xnox> due to broken config.
<xnox> (well not acceptable config)
<apw> pitti, hey ... we have just had an autopkgtest failure on nova, following a xen upload, and it says there is a dependancy issue, is there any way to find out what the dep issue is reported in the log for this jenkins job: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-nova/ARCH=amd64,label=adt/lastBuild/
<seb128> ogra_, thanks
<rbasak> xnox: do you know which file? Is this an incompatible change to a custom config, or the default config supplied by a package?
<xnox> rbasak: so i had perl, php5, wsgi apache2 modules installed and enabled with apache2 preform server, at postinst of apache2 (2.4) it was failing to load php5 (2.2) module due to abi incompatibity. Doing the same scenario but dist-upgrade from raring, results in proper ordering (php before apache-php module before apache itself)
 * rbasak pokes
<rbasak> xnox: do you think there's a bug here, or if this needs further investigation? I haven't managed to figure out how to get that scenario to happen at all, since the old libapache2-mod-php5 depends on apache2.2-common, and the new apache2-bin conflicts with apache2.2-common. So how does apache2's postinst (which Depends on apache2-bin) get run while the old libapache2-mod-php5 is still configured?
<xnox> =/
<rbasak> xnox: could you pastebin me a log of the failure case, maybe? Or are you unable to reproduce it now?
<pitti> apw: http://people.canonical.com/~ubuntu-archive/testing/saucy-proposed_probs.html has quite some hints
<pitti> apw: otherwise, enable saucy-proposed in sbuild/chroot/locally and dig down with apt-get
<doko> yolanda, are you currently doing +1 maintenance?
<yolanda> doko, what do you mean?
<doko> yolanda, ok probably not ;)
<doko> yolanda, could  you put source uploads for your lua5.2 fixes to p.o.c, or chinstrap?
<yolanda> doko, i created MMP
<yolanda> MP
<yolanda> do you want the urls?
<doko> well, with merges, I have to create the packages myself ...
<yolanda> doko, what do you need then, the debdiffs?
<yolanda> i can push them
<doko> yolanda, no, diff.gz, dsc, and changes file
<yolanda> doko, ok, let me push them
<yolanda> doko, pushed, they are in /home/yolanda in chinstrap
<doko> yolanda, not readable
<yolanda> permissions?
<yolanda> i added +r
<doko> yolanda, one more thing about rubyluabridge, could you check if it builds with the default gcc?
<yolanda> doko, not sure i understand you, sorry
<doko> yolanda, it build-depends on gcc-4.6
<doko> and for rrdtool, could we consider removing the ruby1.8 package?
<yolanda> doko, about rubyluabridge, i'll try to unpin the dependency
<yolanda> for rrdtool, i don't know, if that is needed or not
<yolanda> if you think it could be removed we can push it
<ev_> if someone could new whoopsie-preferences, I'd greatly appreciate it: https://launchpad.net/ubuntu/saucy/+queue?queue_state=0&queue_text=whoopsie-preferences
<doko> $ apt-cache rdepends librrd-ruby1.8
<doko> librrd-ruby1.8
<doko> Reverse Depends:
<doko>   librrd-ruby
<doko>   rrdtool-dbg
<doko> yolanda, ^^^
<doko> looks fine for removal
<dobey> pitti: cool. what's the exact restriction flag? and when can i start using it? :)
<pitti> dobey: when> in a few hours, when it autosyncs from Debian
<doko> ev_, looking
<ev_> thansk
<pitti> dobey: Restrictions: allow-stderr
<dobey> pitti: ah, great. thanks!
<doko> ev_, symbols file?
<yolanda> doko, ok, i'll do it
<ev_> doko: hm? Why is that necessary?
<doko> ev_, well, not necessary, but good style, and usually required for promotion to main
<doko> but if this stay in universe, it's probably ok
<ev_> am I missing something? I don't see GTK+ or cairo shipping a .symbols file.
<ev_> doko: it's intended for main
<doko> ev_, complain to seb128 or didrocks
<ev_> doko: if you point me in the direction of a dh9 package that does this right, I'll happily fix it as 0.4
<seb128> ev_, ls /var/lib/dpkg/info/libgtk-3-0*symbols ?
<seb128> ev_, ls /var/lib/dpkg/info/libcairo*symbols
<ev_> oh, I was assuming they'd be output in dpkg -L
<ev_> which is obviously not the case
<seb128> no, that's like postinst, etc
<ev_> indeed
<cjwatson> libpipeline is a simple dh9 library package that has .symbols
<seb128> ev_, you don't have a lot to do, just run dpkg-gensymbols in the build tree after build to generate the file
<seb128> ev_, typically dpkg-gensymbols -p<lib> -v<version> -Odebian/<lib>.symbols
<cjwatson> for a library you wrote yourself it's fairly easy to handcraft it too
<ev_> fixing
<seb128> ev_,  you might want to "export DPKG_GENSYMBOLS_CHECK_LEVEL=4" in the rules as well (to stop the build on .symbols being outdated, so you don't forget to keep it uptodate ... the default behaviour is to just print the diff during the build)
<ev_> thanks guys
<seb128> yw
<emper0r> hi
<emper0r> got trouble with chattr.. flag permisions when activate +i options
<emper0r> any idea ?
<emper0r> debian works fine
<ev_> doko: fixed as whoopsie-preferences 0.4
<dobey> xnox: ping
<yolanda> doko, rubyluabridge builds fine with default  g++
<doko> ev_: why 0.0.0, when you only have versions like 0.x? anyway, accepting
<yolanda> doko, do you want me to resend rubyluabridge or you are ok with setting the g++ dependency?
<doko> yolanda, I'll do it
<doko> thanks for checking
<yolanda> np
<yolanda> working in the 1.8 drop of rrdtool now
<doko> uploaded
<yolanda> doko, should we drop the librrd-ruby1.8 package?
<doko> yolanda, yes, I think so. keep in mind there is a dependency on it in librrd-ruby
<dobey> xnox: i'm having some trouble trying to add a --version-script to ubuntuone-credentials. it seems UbuntuOne::* being global and everything else local isn't enough to actually link to the library. the tests program is failing to link due to missing vtables :(
<doko> dobey, can you paste the script, and the missing symbols?
<dobey> sure, one second
<yolanda> doko, pushed new files for rrdtool to chinstrap
<dobey> doko: http://pastebin.ubuntu.com/5890930/
<yolanda> doko, did you see the FTBFS for rubyluabridge? do you know what's the problem?
<dobey> doko: also, i'm not sure why, but for some reason cmake seems to want to pass the -Wl,--version-script= to the link line of the text program too, though i've only defined it for the library target :-/
<dobey> not sure if that is relevant
<doko> dobey, well, the vtable for UbuntuOne* are missing
<dobey> doko: yes, but why?
<doko> because they don't match?
<dobey> you can't define "vtable for *" in the version script
<doko> use the unmangled names
<doko> mangled
<doko> yolanda, no, didn't look yet
<dobey> i don't understand
<doko> dobey, how do the mangled symbols for the vtables look like?
<dobey> doko: ah, i don't know
<doko> dobey, find out, and then add this outside the extern C, but inside the global section
<dobey> ok, i'll try. thanks
<seb128> ev_, hum
<seb128> dpkg: error processing whoopsie-preferences_0.4_i386.deb (--install):
<seb128>  trying to overwrite '/usr/bin/whoopsie-preferences', which is also in package activity-log-manager 0.9.7-0ubuntu3
<ev_> oh, I thought I handled that with a breaks/replaces
<seb128> ev_, ^ known issue?
<seb128> you break/replaces << 0.9.7
<seb128> but I've 0.9.7-0ubuntu3 which is >  0.9.7
<seb128> while still shipping that file
<ev_> seb128: argh, sorry about that
<ev_> uploading a << 0.9.8
<seb128> ev_, do you plan to get activity-log-manager 0.9.8 uploaded as well?
<ev_> seb128: yes: https://code.launchpad.net/~ev/activity-log-manager/split-out-diagnostics-service/+merge/175820 and https://bugs.launchpad.net/ubuntu/+source/activity-log-manager/+bug/1203042
<ubottu> Ubuntu bug 1203042 in activity-log-manager (Ubuntu) "Clean up packaging for 0.9.8" [Undecided,New]
<doko> ev_, that won't help with upgrades, you need a new w-p too
<ev_> doko: hm? If whoopsie breaks && replaces on << activity-log-manager 0.9.8, surely that fixes it?
<seb128> ev_, ok, I'm going to block the ubuntu-system-settings merge on that to happen, otherwise you will make it conflict with ubuntu-desktop
<ev_> seb128: *nods*
<ev_> thanks for the catch
<seb128> np
<seb128> ev_, is whoopsie-preferences supposed to show an UI?
<ev_> still working on addressing the other points in the ubuntu-system-settings MP
<ev_> seb128: it's just a DBus service. The UI is provided by ubuntu-system-settings and activity-log-manager.
<doko> ev_ ahh, I thought you would upload activity-log-manager
<seb128> ev_, ok, you might want to move the binary out of /usr/bin then, it's a bit confusing
<ev_> doko: ah, I understand your previous statement now. Thanks for the warning all the same :)
<ev_> seb128: sure, will do
<seb128> thanks
<ev_>  /usr/share/whoopsie-preferences/whoopsie-preferences?
<seb128> ev_, I was thinking /usr/lib/whopsie... but in fact quite some services ship in /usr/bin so maybe don't bother
<ev_> okay
<stgraber> slangasek: ok, so the SB bug is confirmed to be fixed on saucy. I just did a test install in a non-SB OVMF VM and I properly boot through shim post-install
<stgraber> oh, but I didn't get linux-signed... that's odd
<stgraber> hmm, grep seems to indicate a base-installer change may also be needed...
<rbasak> xnox: I think I have it. On raring I installed libapache2-mod-php5, then changed sources.list to saucy, then "apt-get install libapache2-mod-php5". That gives me a postinst failure with apache complaining about an undefined symbol in libphp5.so. Does that sound familiar?
<stgraber> cjwatson: would that explain it? (linux-image-signed being removed by ubiquity even though 'linux-signed-generic%s' % altmeta is in the keep list because the kernel code in base-installer checks for SecureBoot too)
<rbasak> It tried to bring in the new apache 2.4 as expected, but didn't succeed.
<stgraber> cjwatson: if so, I'll drop that code in base-installer too (always have it return linux-image-signed if the system is UEFI)
<dobey> doko: hrmm, i'm not quite sure how i can get the mangled string for the vtables :-/ nm output when built without the symbols file, just prints "v vtable for Foo::Bar" too :-/
<dobey> and LD_DEBUG=symbols doesn't help much either
<jbicha> rbasak: I think that's bug 1202653
<ubottu> bug 1202653 in apache2 (Ubuntu) "package apache2 2.4.4-6ubuntu4 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Confirmed] https://launchpad.net/bugs/1202653
<rbasak> jbicha: that's it. Thanks!
<stgraber> cjwatson: just noticed you're off today, so I'll just do the change in base-installer, rebuild ubiquity and re-test this afternoon, if that works then I can prepare a cheryr-pick of that whole stuff for precise (starting to sound unlikely to be ready today though)
<rbasak> I've reproduced in Debian so I'll file there.
<slangasek> stgraber: great :)
<slangasek> ev_, seb128, pitti: who is managing the launchpad retracers now?  I keep noticing that they're being bursty in their retracing (just saw some retraces of 7-day-old bug reports), which I guess means someone unblocked something but I suspect the root cause has not been addressed
<seb128> slangasek, it's mostly pitti, I've access to them but don't watch them too much those days
<seb128> slangasek, they usually go down hitting transient issues
<seb128> like launchpad timeouts
<slangasek> ok
<seb128> then they don't restart until somebody look at the issue and removes the lock
<slangasek> but it seems that when someone notices, they just clear it, which means the problem never gets any better :)
<seb128> the problem being "launchpad timeouts" most of the time
<seb128> which is not something easy to fix :/
<slangasek> well, I would say the problem is the retracer can't handle a launchpad timeout gracefully
<seb128> right
<slangasek> stgraber: signed kernel> even without the Lenovo issue, that's what we want
<seb128> I'm sure pitti would welcome patches on apport to improve that ;-)
<seb128> (hint hint hint;-)
<slangasek> well, if someone can point me at a backtrace or something of the retracer.. :)
<seb128> slangasek, I'm starting wondering if we should just drop bug reporting to launchpad/those retracers
<seb128> and claim that e.u.c is the way to go
<slangasek> is errors not using the same retracers?
<seb128> no
<slangasek> ok
<slangasek> so I still find it useful to have launchpad backtraces for my own crashes... when they get retraced successfully
<seb128> slangasek, ssh porter-i386.canonical.com; sudo -u ubuntu-archive -i; less log/amd64.txt
<seb128> slangasek, if you want to see the retracer logs
<slangasek> ok, thanks
<seb128> slangasek, http://paste.ubuntu.com/5891264/ seems a typical timeout one
<hyperair> micahg: ping. are you maintaining gtk-theme-config?
<zul> mterry: ping  I wanted to get #1203124 and #1203122 on your radar (horizon is blocked on these)
<dobey> bah. finally get the vtable issue "fixed" and now cmake's target_link_libraries is buggy, and appending the linker flags to all targets in the build, rather than only the one i specified :(
<infinity> dobey: With --as-needed, that shouldn't matter terribly, should it?
<dobey> infinity: it matters if i want different version scripts for different libraries in the same source tree.
<infinity> dobey: Oh, I jumped in in the middle, didn't realise you were talking about linker scripts, thought you just meant -lfoo stuff.
<dobey> well, any flags i add. while --as-needed my "fix" linking of unneeded libs, it doesn't fix symbols not being exported due to the version script, in libs where they should be exported :-/
<doko> dobey, I'm always eager to ask somebody else about cmake. so please become an expert ;-P
<dobey> doko: i'm tired of being an expert on build systems :)
<olli_> ;)
<infinity> xnox: So, uhm.  My upgrade just now killed init.
<infinity> xnox: That seems less than ideal.
<infinity> xnox: The kernel panic this inevitably causes made it a bit difficult to see exactly what package was being unpacked/configured at the time, but libjson-c and upstart were both in the upgrade set.
<infinity> xnox: Smells of stateful re-exec gone horribly wrong, perhaps?
<infinity> xnox: Ahh, it was definitely libjson-c2's postinst, since that was all "dpkg --configure -a" had to do when I ran it.
<infinity> xnox: So, yeah.  re-exec shouldn't kill init.  Please. :)
<infinity> stgraber: jodh: slangasek: ^^
<zul> can someone promote oslo-sphinx please (https://bugs.launchpad.net/ubuntu/+source/oslo-sphinx/+bug/1199872) its blocking nova from building
<ubottu> Ubuntu bug 1199872 in oslo-sphinx (Ubuntu) "[MIR] oslo-sphinx" [High,Fix released]
<infinity> zul: When I have a functional laptop again, sure.
<zul> infinity:  thanks
<jodh> infinity: please raise an apport bug when you can so someone can look at the captured state data.
<infinity> jodh: I'm not sure what data there is to capture, given that dead init == kernel panic.
<jodh> infinity: just use apport - it does the magic :)
<infinity> I'm dubious, but sure. :P
<jodh> infinity: also, please note on the bug if you had been building package in a chroot prior to the upgrade.
<infinity> (I have to finish the upgrade first, my desktop no worky, all I have is consoles)
<jodh> infinity: who needs more ? :)
<infinity> jodh: I may or may not have had active schroot sessions.  No idea.
<slangasek> infinity: the segv handler for pid 1 is the same as for any other, you hopefully have a crash report in /var/crash
<slangasek> infinity: is this a saucy host?
<infinity> slangasek: saucy host, yes.  And sure, I have an sbin_init in /var/crash, but it's 0-length.  See above, re: kernel panic when init dies.
<slangasek> infinity: the kernel doesn't panic until the segv handler ends.
<slangasek> infinity: what version of upstart did you have installed at the time?
<infinity> That theory doesn't jibe with the mode 000 0-length file in /var/crash, but sure.
<slangasek> that just means the crash handler didn't sensibly fsync
<slangasek> and it's not a theory, that's how it's all desined
<slangasek> designed
<infinity> slangasek: 1.9.1-0ubuntu1
<slangasek> infinity: ok.  that's the buggy one, so you were caught by bug #1199778
<infinity> Well, okay, if the handler doesn't fsync, then that's a slightly broken design. ;)
<ubottu> bug 1199778 in upstart (Ubuntu Raring) "upstart crashes if re-exec'ed with active chroot sessions" [Undecided,New] https://launchpad.net/bugs/1199778
<slangasek> do you have chroots that don't correctly divert invoke-rc.d? (policy-rc.d et al)
<infinity> Well, I was caught by that if I had active chroots.  But it's a fair chance I did, because I'm me.
<infinity> I don't know for sure, mind you.
<infinity> slangasek: All my schroots use a policy-rc.d
<slangasek> it's not just "active chroots", it's "chroots that upstart has managed to run services under"
<jodh> infinity: see if you have a /var/log/upstart/upstart.state file
<infinity> Hold on.  Upgrade done, let me reboot and see if I have a desktop again.
<slangasek> and yes, there may be a bug report somewhere about the lack of fsync for apport when handling init
<infinity> Or should I check for said file before I reboot and make it sad?
<slangasek> or maybe it was just an IRC conversation I had with ev or bdmurray
<slangasek> infinity: the reboot won't cause the file to be created
<infinity> Ahh, I have no such file anyway.
<slangasek> ok
<infinity> So, while I have a sane policy-rc.d, I do note that upstart does spew syslog with sadness about configuration directories disappearing every time a chroot is torn down.
<infinity> So, it's clearly doing something in there.
<slangasek> hum.
<infinity> Even though I'd prefer it didn't.
<infinity> Let me reboot so I can more usefully be a copy-and-pastey person.
<slangasek> upstart only knows about the chroot if something inside the chroot talks to it
<slangasek> which policy-rc.d should be sufficient to prevent
<infinity> Hrm.  Maybe that hasn't happened in a while.  Or my grep-fu sucks.  Or it's somehow magically avoiding syslog.
<infinity> (I tend to notice the vomit in the ringbuffer)
<infinity> Great, now I can't sort out how to trigger the upstart/dmesg vomit.  So, either it was a bug/misfeature that's been fixed, or I have no idea under what conditions I make it happen.
<infinity> Oh, wait.  Hah.  Just made it happen.
<infinity> [  580.782353] init: /var/lib/schroot/mount/saucy-amd64-5bf993dc-9abc-458b-b9c4-b1af3e38ba44/etc/init: Configuration directory deleted
<infinity> slangasek: So, all I did in that schroot was a dist-upgrade that pulled in the new libjson-c2 and upstart.
<infinity> slangasek: But maybe the new upstart also fixes this somehow?
<infinity> (I wouldn't expect it to be touching the chroot at all, though...)
<infinity> Of course, if my schroots don't trigger ischroot(1)...
<infinity> Double-U Tee Eff...
<infinity> Oh, wait.  Yes they do.  I was reading the return backwards.
<infinity> slangasek: So, I am actually fairly curious about how upstart decides it wants to latch on to my chroot.
<infinity> slangasek: And the winner is: upgrading udev in the chroot.
<xnox> infinity: argh.
<infinity> xnox: False alarm on the dead init, if it's the bug that was just fixed (since I was on the previous version).
<xnox> infinity: i think in the last update we put back the asserts in the stateful re-exec, believing that chroot session bug was fixed.
<infinity> xnox: Though, the part where upgrading udev in a chroot appears to make upstart decide my chroot is its plaything is very curious.
<xnox> infinity: the bug was in the "new version" asserting upon deserialisation....
<infinity> (And yes, I have a policy-rc.d that is correctly stopping udev's restart in postinst)
<xnox> infinity: and host upstart, should ignore re-exec requests comming from chroot session.
<xnox> i think you can still be pointing to a real bug here.
<infinity> xnox: http://paste.ubuntu.com/5892015/
<infinity> xnox: That's possibly just cosmetic, but it's curious that it cares about files in my chroot AT ALL.
<slangasek> infinity: so the upstart postinst calls 'initctl version' even when in a chroot, to figure out based on the running version what upgrade path to use; and it does this even when in a chroot.  We discussed this, but jodh was sure this wouldn't be enough to trigger creation of a chroot session on the host upstart
<slangasek> oh, upgrading udev
<slangasek> that's interesting
<infinity> slangasek: Yeah, indeed.
<infinity> slangasek: And my policy-rc.d is clearly working, as seen in the paste.
<infinity> slangasek: So, Whiskey Tango Foxtrot.
<slangasek> infinity: so all the udev postinst does is 'invoke-rc.d udev restart'
<infinity> slangasek: Right, and that bit's being denied.
<infinity> slangasek: Hence the WTF.
<slangasek> fun
<infinity> slangasek: Verified it's not my chroot setup.  Enter/exit without doing anything is non-spew-inducing, as is entering the chroot and upgrading some other things.
<infinity> So it's clearly udev, but.  Wha?
<slangasek> what release is in the chroot
<slangasek> ?
<infinity> slangasek: Amusingly, upgrading upstart doesn't trigger this.  So, yay you.  Boo, udev.
<infinity> slangasek: Based on the prompt, I'm guessing that's saucy. :P
<slangasek> right, because udev's misbehavior can't possibly be my fault ;)
<infinity> Oh, you mean what upstart release?
<infinity> 1.8-0ubuntu7
<slangasek> no, I meant what OS release
<infinity> saucy-amd64
<slangasek> but apparently somewhat out of date?
<s1lence> Does anybody from canonical in here have a way to reach the legal team? The images of the ubuntu edge were mirrored to imgur and canonical should probably file a takedown request.
<infinity> lil bit, yeah.
<s1lence> I know this is the inappropriate channel but I don't know where else to ask
<xnox> s1lence: not sure what "imgur" is. Do you have a link? and what images? most of our images are allowed to be redistributed.....
<infinity> xnox: imgur is an image hosting site, and... Wait.  You've never heard of it?
<infinity> xnox: Do you have teh internetz over there?
<xnox> infinity: i use emacs.... =)
<s1lence> xnox, imgur is an image hosting service for reddit, I have a link i'll pm you. The part of the server with the images 403'd within a few minuites
<slangasek> infinity: so invoke-rc.d calls 'initctl version' before doing anything else, including before checking policy-rc.d.  Can you check whether calling 'initctl version' in the chroot is sufficient to reproduce?
<infinity> slangasek: Ahh, doing that before checking policy seems wrong regardless, no?  (but will check)
<slangasek> no, because initctl version is supposed to be innocuous
<slangasek> and invoke-rc.d is overdesigned in such a way that it has to know what the "normal" policy is before calling policy-rc.d
<infinity> slangasek: That didn't trigger the bug, no.
 * infinity installs some random something else with an upstart job to see if this is just invoke-rc.d, or something fundamentally weird and udevy.
<slangasek> mmk
<infinity> Right, so same thing installing sshd.
<slangasek> infinity: how about 'initctl show-config'?
<infinity> slangasek: Yep, that does it.
<slangasek> infinity: please file a bug on upstart+sysvinit
<slangasek> infinity: also, please try 'telinit u' (after saving any open documents :P) to confirm that this no longer crashes init
<infinity> slangasek: ow.
<slangasek> infinity: does that mean it crashed init?
<infinity> Sure did.
<slangasek> xnox: ^^ your move.
 * xnox reads.
<infinity> Let me do this fresh for a clean reproducer.
<infinity> Okay, so.
<infinity> schroot (with overlay)
<infinity> initctl show-config (in chroot)
<infinity> exit chroot
<infinity> sudo telinit u
<infinity> Boom.
<xnox> slangasek: i'd ponder the following move - Castling: upload revert to remove asserts & file in https://wiki.kubuntu.org/UbuntuDevelopment/RevertLog
<infinity> Not 100%, though.  I had to try a few times.
<xnox> or let me work from that to see a fix.
<slangasek> xnox: what version do you expect to revert to? 1.9.1-0ubuntu1 also crashed
 * xnox uses http://people.canonical.com/~jhunt/upstart/scripts/get_state.sh
<xnox> slangasek: good point.
<slangasek> as for removing asserts that are causing init to crash when it shouldn't, that sounds like a prima facie good idea to me
<infinity> Huh, and that spam really doesn't end up in syslog, only in the kernel ringbuffer, that's why my grep-fu wasn't finding it.
<slangasek> right, something has gone wonky over the last few cycles wrt upstart's kernel ringbuffer messages not making it to syslog
<slangasek> I think this may have been a kernel change, not sure
<xnox> slangasek: i had a report from a precise user about that. which if not reproducible with 12.04.0 would certanly point at the kernel.
<infinity> slangasek: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1203188 <-- For the spam.
<ubottu> Ubuntu bug 1203188 in upstart (Ubuntu) "initctl show-config in ephemeral chroot causes dmesg spam" [Undecided,New]
<infinity> slangasek: I guess we don't need a bug for the crash, we can just re-open the closed one?
<xnox> infinity: yeah, reopen.
<infinity> xnox: Reopened and commented.
<slangasek> infinity: I wanted a separate bug about the fact that invoke-rc.d was triggering the creation of a chroot session in upstart
<slangasek> which is lower priority than "having a chroot session in upstart causes upstart re-exec to explode"
<infinity> slangasek: Sure, that's the bug I filed.  Or, can be made to say that. :P
 * slangasek nods
 * infinity is now paranoid about using his chroots.  Or upgrading anything.  Ever.
 * xnox is running testsuite against the dump after "show-config & exit chroot"
<xnox> infinity: use --no-sessions for init (can be a kernel arg), but then you will not be able to start any daemons in your chroots (which might be advisable)
<xnox> it "Disable chroot sessions."
<infinity> xnox: Not starting daemons in my chroots is generally a feature.
<infinity> xnox: --no-sessions passed directly to the kernel, you say?
<xnox> infinity: yeah, that supposedly gets passed to init with our magic integration. Documentation: http://upstart.ubuntu.com/cookbook/#add-verbose-or-debug-to-the-kernel-command-line
 * infinity adds that to /etc/default/grub and gives it a whirl.
<infinity> xnox: That worked a treat.  <3
<xnox> infinity: your welcome =)
<xnox> infinity: (null):session.c:513: Not reached assertion failed in session_from_index
<xnox> \o/
 * xnox has a unit test.
<xnox> slangasek: smells like we do not tear down session completly when it's gone.....
<xnox> infinity: cute, upstart still has all jobclasses in memory, even after you quit chroot session and thus goes berserk when it realises they are not there on re-exec /o\
<infinity> shadeslayer: Wouldn't it make sense to upload kde4libs before all the things that build-depend on it? :P
<shadeslayer> infinity: true, but our automation script just prepares all the packages and uploads them, but yeah, you're right :)
<shadeslayer> anyway, gtg, early flight tomorrow, night! :)
<infinity> 'Night.
<xnox> infinity: http://paste.ubuntu.com/5892302/
<infinity> xnox: Oops.
<xnox> infinity: that also means, we have not yet ever statefully re-exec with a chroot session and has always been falling back to non-state-re-exec.
<xnox> infinity: i'm gonna write a few more tests here, before doing merge proposal.....
<infinity> xnox: Shiny.  I no longer care, of course, because --no-sessions has made me happier than I've been in years.
<infinity> xnox: But I imagine other users of ephemeral chroots (Colin, Andy, y'know, people we like) might be grumpy about their machines panicking. ;)
<xnox> infinity: i wonder if pitti can be recruited to write upstart re-exec tests, afterall should be interesting for developer in test =)
<xnox> infinity: at least i am adding tests for all the bugs we are catching with chroot re-execs here.
<slangasek> xnox: re-exec is not expected to preserve any state for chroot sessions at this point.  It *is* expected to not blow up init...
<xnox> slangasek: by the looks of it, we never clean up chroot sessions, even after chroot path is deleted.
<slangasek> so I hear
<xnox> slangasek: and as I said, over when the first blow-up of init happened, that there shouldn't be any asserts on the deserialisation path, and instead they should bail out into stateless re-exec. But still be inspirit of "do not preserve chroot sessions, and try to statefully re-exec host init"
<slangasek> yes, I agree
<xnox> slangasek: also the function in question, had an obvious bug, and it doesn't seem to have a unit-test. http://paste.ubuntu.com/5892302/
<xnox> slangasek: infinity: i think we got lucky, cause both you and I had _2_ sessions, instead of just one =)
<xnox> still doing full build, and full test here.
<slangasek> xnox: ok, cheers
<slangasek> mdeslaur: there's a libjpeg-turbo SRU sponsored by you in the queue, that has no bug references
#ubuntu-devel 2013-07-20
<slangasek> mdeslaur: (so I'm rejecting it)
<mdeslaur> slangasek: ok, thanks
<mdeslaur> slangasek: found it, I'll re-upload in a few minutes
<slangasek> pitti: what's the SRU verification process for udev, given the stated SRU exception for the keymaps?
<shadeslayer> kenvandine: hi, if you have a moment I'd like to talk about mcp-account-manager-goa
<shadeslayer> and decoupling the dependency on empathy
<jbicha> shadeslayer: I think mcp-account-manager-goa is useless without empathy
<jbicha> unless something else uses telepathy + goa that I don't know about...
<ari-tczew> can we merge a package in main from debian experimental?
<jbicha> ari-tczew: yes
<ari-tczew> thanks jbicha
<melodie> hello
<ari-tczew> hello
<melodie> hi ari-tczew
<infinity> ari-tczew: You can, but you should have a pretty good reason for it.
<melodie> does someone know how the file /lib/plymouth/themes/ubuntu-text/ubuntu-text.plymouth is called, in the Live CD? I'd like to make a custom one which would not rely to the package it belongs to, but I don't know how to do that
<ari-tczew> infinity: It fixes one FTBFS (due to missing depends) and another user-bug.
<infinity> ari-tczew: experimental, by its nature, is designed for people to make mistakes and not clean up their messes (not upgrade paths are required from experimental packages to their eventual unstable uploads, etc), so syncing or merging from experimental means you're taking responsibility for some things the Debian maintainer doesn't have to.
<infinity> ari-tczew: Which package is this?
<ari-tczew> infinity: libav
<ari-tczew> and ftbfs fixes for package handbrake
<infinity> Erm.  No.
<infinity> Dude.
<infinity> That's starting a massive transition, not just fixing an FTBFS.
<infinity> Please talk to siretart about the current state of libav and its rdepends before you commit us to that for the sake of fixing handbrake. :P
<infinity> (It'll break hundreds of other packages to fix the one)
<ari-tczew> I believe.
<infinity> Yes, we should do the libav transition, no, you shouldn't start it to fix handbrake.  Its FTBFS really isn't a big picture thing here. :)
<infinity> (And I won't start that transition until I have people committed to finishing it)
<infinity> siretart: What's the current state of libav9?  Are we close to being able to do a vaguely smooth transition?
<infinity> ari-tczew: So, in conclusion: please, please, please don't merge or sync libav from experimental.  We'll do it when we're ready to push the whole stack.
<jbicha> infinity: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706798
<ubottu> Debian bug 706798 in release.debian.org "transition: Libav 9" [Normal,Open]
<ari-tczew> infinity: I have already took a look on a merge and I saw it's not so easy, so I'm leaving this one.
<infinity> jbicha: Oh good, siretart's on top of it.  Last time I asked, it wasn't quite ready.  Still, for sanity, I'd rather he handle it (or push it through the release team and friends) than have it started by someone trying to fix a random FTBFS. ;)
<jbicha> infinity: it sounds like as long as you don't care about audacity, it's ready
<melodie> I rephrase my question just incase:
<melodie> does someone know about how plymouth-theme-*-text packages generally are called in a Live ?
<melodie> s/packages/configuration file/
<ari-tczew> is MoM broken?
<Noskcaj> ari-tczew, i doubt it. Why did you ask?
<ari-tczew> Noskcaj: I saw a few packages which are already synced, but still exist on MoM
<Noskcaj> ari-tczew, If they've been synced in the last day, it's possible MoM didn't pick up on it
<Noskcaj> if not, something is broken
<ari-tczew> Noskcaj: IIRC, it has been synced on 13th
<ari-tczew> so one week ag
<ari-tczew> ago *
<dupondje> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1203211
<ubottu> Ubuntu bug 1203211 in linux (Ubuntu) "Kernel 3.10.0-4 fails on graphical boot with i915 (MacBook Pro 8,2)" [Undecided,Confirmed]
<dupondje> can we assign that to somebody ? :)
<dupondje> seems like i915 is broken :(
<ari-tczew> Noskcaj: example: sflphone in universe
<infinity> ari-tczew: MoM only (incorrectly) operates against the release pocket, and sflphone is in proposed.
<infinity> ari-tczew: This is a known bug/misfeature, but not an indication that it's stalled/broken.
<ari-tczew> infinity: is there a bug reported?
<infinity> ari-tczew: No idea, but it's known to the people who need to know, we've just not gotten around to fixing it.
<ari-tczew> infinity: OK.
#ubuntu-devel 2013-07-21
<kenvandine> can someone help me figure out why unity-scope-click is stuck in proposed?
<kenvandine> it's not on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<jbicha> kenvandine: did you see http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<kenvandine> no... grrr
<kenvandine> can someone delete the ppc binary?
<kenvandine> it deps on something that won't build on ppc
<kenvandine> so we dropped ppc for the scope too
<jbicha> (it has to "pass" excuses before showing up on output)
<kenvandine> humm, seb128 said it was on output earlier and told me to drop ppc
<kenvandine> oh, i guess it was there before for a different reason
<kenvandine> depwait
<infinity> kenvandine: Done.
<kenvandine> infinity, awesome, thanks!
<infinity> kenvandine: I'm a bit irked by all the arch: specifying going on in these stacks.  Having dep-waits forever would be more pleasant.
<infinity> kenvandine: This will be a mess to undo when qt5 is fixed on ppc (or x32, or arm64, or...)
<kenvandine> indeed
<kenvandine> :/
<siretart> infinity: I think we are long overdue for the libav9 transition. and I think we already were for raring. The last time I asked the response was we do not want to have another libav transition ahead of debian, though. and I guess you already noticed the debian transition bug.
<siretart> ari-tczew: ^^
<Noskcaj> I also support updating libav9. It's current versioning is very confusing
<dupondje> seems like modprobe is broken somehow :(
<infinity> siretart: Well, if we're fairly sure the Debian transition will start "soon", perhaps this week is a good time to start on Ubuntu.  Would be nice to clear up the one or two packages that are still broken, though.
<infinity> dupondje: kmod hasn't changed in months.  Could be potentially some toolchain change between the -3 and -4 kernel builds that blew something up.  Rebuilding the previous kernel on a current saucy might show this.
<dupondje> hmz
<dupondje> to hot for a rebuild today :P
<dupondje> daily kernels are build with same toolchain ?
<dupondje> cause current daily works fine
<infinity> No idea how the dailies are built, to be honest.
<infinity> And it could just be a cosmic ray one-time miscompilation too.  A rebuild of the current kernel could be enlightening.
<dupondje> let me rebuild it :)
<infinity> dupondje: It could also be something as simple/silly as depmod having failed to run, but I would expect much more spectacular failure then. :P
<siretart> infinity: well, debian is in kind of a "transition jam" state, and it is very hard to predict when the transition starts. I could be tomorrow, or in 3 months
<dupondje> infinity: rebuild of -4 failed, still broken
<infinity> dupondje: Kay.  So, a rebuild of -3 to see if it breaks would be useful, perhaps.
<dupondje> doing no :)
<dupondje> now*
<ari-tczew> which way is better to do a merge? bzr or normal debdiff?
<jbicha> ari-tczew: generally I prefer to use packaging-only bzr branches as more or less described at https://wiki.ubuntu.com/DesktopTeam/Bzr
<jbicha> I had too many problems in the past running 'bzr mu' in the past with full bzr branches
<ari-tczew> jbicha: so for you better to sponsoring is debdiff than bzr branch?
<jbicha> ari-tczew: well I can build a debdiff from a bzr merge but I find a diff of just the debian/ directory to be the easiest to read and review
<ari-tczew> ok
#ubuntu-devel 2014-07-14
<pitti> Good morning
<pitti> cyphermox_: acpi-support> it's still used for some corner cases AFAIK, mostly for events which don't produce a proper evdev event yet
<pitti> cyphermox_: or at least not at the time of the last review; the proper thing is to fix the kernel drivers to generate evdev events, of course, but that needs the affected hw for verifying
<pitti> darkxst: tests with their own dbus interface> not enough context, I'm afraid; where do you see that? tests can set up their own fake services of course
<darkxst> pitti, the tracker tests, require the Tracker dbus interface to be running
<pitti> mapreri: ah, the arm64 fix is upstream? I don't know how harmful a missing semicolon is (should be tested under GNOME, KDE, XFCE), supposedly not important
<pitti> darkxst: ah, autopkgtest or build time checks?
<darkxst> build time, maybe they would be better as autopkgtests, but they are not setup as installed-tests currently
<pitti> darkxst: so the upstream tests require a running tracker? that sounds just broken
<pitti> darkxst: they ought to start tracker from the build tree and test that, preferrably on a private dbus instance
<darkxst> pitti, yup right now they are testing the installed tracker (which is non-existent when building in a chroot)
<darkxst> I will file an upstream bug
<pitti> darkxst: ah, ok
<pitti> darkxst: then this indeed can't even run during package build time, and should be run as autopkgtest
<pitti> darkxst: the autopkgtest can then do something like dbus-launch make check-installed (or however it's called)
<darkxst> pitti, so dump the tests/ code into a -tests package?
<pitti> darkxst: no, please don't; if they are built (i. e. not in python or shell, but compiled), add a "Restrictions: build-needed"
<pitti> darkxst: oh, I suppose it might follow the GNOME direction of providing installed tests
<pitti> darkxst: like glib's; but preferrably they should still also be able to run against the build tree, so that developers can easily run them as well
<darkxst> pitti, unit-tests are all compiled (I think), functional tests are mostly python (although these seem to end up installed when enabled)
<pitti> darkxst: I think creating more binary packages for tests is clutter
<darkxst> pitti, but isnt that what glib/gjs etc do?
<pitti> darkxst: glib does, and probably a few more packages; building glib just takes a while, so it's more justified there
<darkxst> pitti, right, just didrocks suggested we should really get the unit-tests running if we want to MIR tracker
<mapreri> pitti: yes, I sent the patch to upstream myself. The validator report the messing semicolon as an Error.... I can try under XFCE and unity (I use i3) later today.
<loa> xnox, hi, can you look at my bug report?
<xnox> loa: yes, but not right now. Will investigate later today.
<loa> xnox, it was my first atempt in bug reporting i don't know how clear i done it.
<loa> xnox, ok.
<darkxst> pitti, can you take a look at bug 1283551
<ubottu> bug 1283551 in Ubuntu GNOME "gjs-console crashed with signal 5" [Medium,Triaged] https://launchpad.net/bugs/1283551
<darkxst> really wanted to SRU that back into trusty, but having to rebuild all typelibs seems like a pain there ;(
<darkxst> we do get about 3000 crashes a week from that bug though ;(
<pitti> darkxst: err, why do we have to rebuild *all* typelibs?
<pitti> darkxst: I haven't digged into that crash in detail, but that seems like a small corner case
<pitti> the ownership of the instance parameters is pretty much always "none" for methods and "full" for constructors, and that's what pygi/gjs/etc. should assume if it's not otherwise specified
<pitti> so this should only need a rebuild of a typelib which has an API that behaves differently?
<pitti> darkxst: I assume the rebuild is necessary to get the ownership annotation of the instance parameter into the typelib?
<darkxst> pitti, its hard to tell which api need the transfer ownership
<pitti> darkxst: but it should be obvious for the particular crash you wanted to fix?
<darkxst> pitti, unfortunately not possible to get a gjs backtrace, from coredumps ;(
<darkxst> would need gdb replay foo for that
<darkxst> i.e. there is no way to tell which module cause the crash :(
<pitti> infinity, slangasek: now that we have enough space on germanium, do you actually still see any reason to also split ddebs by component? they could just all go into "main" on ddebs, which eliminates the entire problem of having binaries in main+universe, binNEW, change-overrides, etc.
<tseliot> cking, pitti: I hadn't noticed that kengyu said he'd work on this alternative approach to solve the Unity corruption problem on S3: https://lists.ubuntu.com/archives/fwts-devel/2014-July/004987.html
<tseliot> cking, pitti: so I worked on the same issue adding support for sysfs and logind to fwts. Would my work still be useful? Or shall I throw it away?
<pitti> erk, acpi-fakekey??
<pitti> that doesn't even work on most machines, it's a really nasty hack from the distant past
<pitti> tseliot: how is that related to suspend issues?
<tseliot> pitti: https://bugs.launchpad.net/fwts/+bug/1339588
<ubottu> Ubuntu bug 1339588 in Firmware Test Suite "The unity menu bar does not redraw after S3 wake up on GeForce 830M [10de:1340] GeForce 840M [10de:1341]" [High,In progress]
<pitti> tseliot: perhaps you gave me the wrong fwts-devel URL?
<pitti> tseliot: I'm familiar with the pm-utils/quirks/etc. parts we've discussed recently, but adding a copy of acpi-fakekey to fwts seems both unrelated and undesirable
<tseliot> pitti: I haven't talked to kengyu yet (he seems to be offline atm) but I think the point of the patch is to trigger S3 using the function key so that logind is notified (?). That's the link from the private bug report
<tseliot> pitti: let me subscribe you to the private report
<pitti> tseliot: is that supposed to test the Fn key functionality or suspend? because these shouldn't be mixed
<tseliot> pitti: I'm not sure. Hopefully #1332411 (which you can access now) will give you some insight
<tseliot> also cking might know more about it
<cking> tseliot, i'm not entirely sure what the desired solution was; I just commented on the fact that adding an executable to fwts was undesired
<tseliot> oh, ok
<cking> tseliot, can you respond to keng-yu's patch and explain what you are doing to resolve this issue if it is related?
<tseliot> cking: sure
<cking> thanks
<pitti> cking, tseliot: followed up
<tseliot> thanks
<cyphermox_> pitti: I understand, but I'm not sure exactly what hardware is affected.
<pitti> cyphermox_: that's the very problem :)
<cyphermox_> pitti: I'll double check, but I may have at least some of the supposedly affected hardware in my possession; I use a thinkpad, and I have a toshiba at home, possibly also an asus netbook
<cyphermox_> my thinkpad certainly doesn't require the acpi-support stuff
<cyphermox_> (or at least not the radio toggle button)
<pitti> cyphermox_: yes, neither does mine; a few years ago slangasek had one which required acpi-support for the wifi toggle AFAIR
<cyphermox_> my main concern is pretty much just ripping out as much as the wifi toggle code as we can, in preparation for starting to use urfkill on desktop too
<pitti> cyphermox_: yes, I'd gladly get rid of acpi-support
<cyphermox_> ;)
<LocutusOfBorg1> can anybody please sponsor gambas3 for me?
<LocutusOfBorg1> I'm the last uploader
<LocutusOfBorg1> (if we exclude a rebuild)
<LocutusOfBorg1> http://paste.debian.net/109663/
<shadeslayer> mvo_: ping
<mvo_> shadeslayer: pong
<shadeslayer> mvo_: what's the status of appstream in ubuntu? alternatively, whom should I talk to about it?
<mvo_> shadeslayer: beside support for downloading the new data via apt AFAIK there is noone working on the integration, but if someone steps up and starts that effort, that would certainly be supported
<mvo_> shadeslayer: maybe worth doing a calll for volunteers in a blog post or something like that?
<shadeslayer> mvo_: ok, what needs to be done in Ubuntu specifically? because I know that the package manager in Kubuntu is pushing for it
<shadeslayer> so muon will get appstream support in the next release
<mvo_> shadeslayer: hm, metadata extraction on the serverside would be needed, but that is probably pretty straightforward as this is already availalbe, but in a slightly different format
<shadeslayer> mvo_: https://lists.ubuntu.com/archives/kubuntu-devel/2014-July/008540.html
<mvo_> shadeslayer: yeah, it will just be that the extraction needs to move to a different format it seems
<shadeslayer> roger
<stokachu> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<hallyn> apw: stgraber: what is the cleanest way to compare current kernel versions to an expected one from a script?  Is there a helper for that, or should i just parse uname -r myself?
<Laney> bdmurray: are you going to be around for DMB later?
<bdmurray> Laney: yes
<Laney> okay, cheers
<Laney> I'm trying to work out if I can be away. :)
<apw> hallyn, nothing i know of, the tools use uname -r
<stgraber> hallyn: I usually parse /proc/sys/kernel/osrelease
<hallyn> ok, thx, awk it is :)
<hallyn> slangasek: ok, so for ITP for cgmanager, assuming my last upload will be promoted for utopic, what's the right thing to do with the packaging for debian?  Do I start with a clean empty changelog, or do I keep the utopic changelog and add an entry for 0.27-1 ?
 * hallyn goes back to testing in jessie in either case
<slangasek> pitti: I don't have any opinion on ddebs.u.c splitting by component, except that from what I saw of the code, I'm concerned that this doesn't really make solving the problem any easier, it just moves it around a bit
<slangasek> cyphermox_: the last laptop I know used the acpi-support wifi toggle was the T60; I don't remember if my X201 did.  I can say that at the time, the "toggling" behavior being provided by !acpi-support was suboptimal, the behavior I wanted (which acpi-support gave me) was to rotate through the antenna on/off positions rather than being a soft version of the hardware kill switch
<slangasek> hallyn: keeping the history and adding an entry for 0.27-1 is fine
<cyphermox_> slangasek: thanks
<hallyn> cool, thanks
<cyphermox_> slangasek: sound like it's not the right time to remove it then, and it probably will interact badly with urfkill for that behavior
<slangasek> yeah, maybe
<hallyn> hello SRU team, just a note that bug 1321365 has been verified for trusty;  could it be promoted to trusty-updates?  (i've got two new bugs to look at SRUing :( )
<ubottu> bug 1321365 in libvirt (Ubuntu Trusty) " virsh (ppc) fails with "missing /proc/device-tree/cpu "" [Critical,Fix committed] https://launchpad.net/bugs/1321365
<cjwatson> hallyn: done
<hallyn> cjwatson: thanks!
<infinity> pitti: The only problem with not splitting by component is that ddebs depend on real debs, so installing a ddeb from main probably shouldn't depend on a deb in universe and confuse people.  That said, the sort of users who use ddebs probably don't care.
<hallyn> slangasek: working with http://people.canonical.com/~serge/cgmanager-0.27.1/cgmanager_0.27-1.dsc
<hallyn> hm, no, there' sa problem in that
<hallyn> stgraber: d'oh, i think i need to add a --pidfile option to cgmanager :(
<hallyn> pitti: hi, would you ahve time today or (more likely) tomorrow to vet the systemd-shim update to work with cgmanager?
<doko> pitti, can you give back https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-cantor/lastBuild/? ?
<cjwatson> doko: I can.  Done (in d-jenkins, so you won't see it on jenkins.qa for a bit).
<cjwatson> pitti: ^-
<hallyn> stgraber: no, guess not - i'm just having weird libnih behavior.  oh well.  i may have to bug jodh :)
<rpadovani> Saviq, xnox o/ I have a question about sbuild. It's the first time I use it and I want to create an armhf host of utopic. I use as shell zsh, and I have problem with sbuild -A -d utopic --host armhf package*.dsc
<rpadovani> it says zsh: no matches found: package*.dsc
<rpadovani> So I tried sbuild -A -d utopic --host armhf package\*.dsc
<rpadovani> E: Invalid source package*.dsc
<rpadovani> And a lot of other combinations with quotes, double quotes and backslash. Do you know if there is a way to work with zsh? Thanks :-)
<sarnold> rpadovani: note that "package*.dsc" is just a placeholder for the actual dsc file from your package..
<rpadovani> sarnold, mhhh I'm not sure to understand. If I want to create a click package for Ubuntu touch using a chroot and I don't want to use QtCreator, what's the way? I think I have to use sbuild, isn't it?
<sarnold> rpadovani: sorry, no idea there :) i'm just saying that "package*.dsc" might mean "org.rpadovani.something-123.456.dsc"  or something similar :)
<sarnold> rpadovani: run "find . -name '*dsc'" and see if you find a .dsc sitting around nicely waiting to be built :)
<rpadovani> sarnold, ok, thanks for your information :-) I need to understand what is the package I supposed to build
<xnox> rpadovani: sbuild is used to (a) create / manager chroots of varius debian-like releases (b) to build debian binary packages (.deb) from debian source package formats (most commonly .dsc)
<xnox> rpadovani: clicks are neither.
<xnox> rpadovani: maybe you want $ click chroot --help ? which uses sbuild behind the scenes, but enables to create/crosscompile native sdk clicks for i386, amd64 and armhf.
<xnox> rpadovani: most of our "clicks" use CMake build system to compile stuff and use helper snippets and templates for the click manifest / config keys.
<shadeslayer> could someone share some insight on https://launchpad.net/ubuntu/+source/kdbusaddons/5.0.0-0ubuntu1
<rpadovani> xnox, aha! Thanks for the suggestion about click chroot! I'll check :-)
<shadeslayer> the build works fine on amd64 on my local machine as well
<hallyn> slangasek: ok, updated http://people.canonical.com/~serge/cgmanager-0.27.1/cgmanager_0.27-1.dsc , this works nicely under experimental.  Now trying under systemd just to see...
<bdmurray> slangasek: why might Contents-armhf.gz be out of date here? http://ports.ubuntu.com/ubuntu-ports/dists/utopic/
<bdmurray> slangasek: I'm guessing its out of date because of the liburcu1 / liburcu2 change on 7/10
<slangasek> bdmurray: how out-of-date is out of date?  The file on pepo hasn't been updated since July 3
<slangasek> I don't recall how frequently these are meant to be updated, though I'm reasonably sure it's not daily
<xnox> bdmurray: well, because the creation of that file is racy and often fails on publication. Currently it has been loosing that race since 3rd of July.
<slangasek> aha
<xnox> slangasek: cjwatson was offering for me to poke lp to fix that =)
<bdmurray> well that presents a problem for the apport retracers
<slangasek> xnox: it would seem to be a very good idea if you did so
<xnox> bdmurray: i386/amd64 ain't no better =) http://archive.ubuntu.com/ubuntu/dists/devel/
<bdmurray> xnox: yeah, I saw that too :-(
<xnox> slangasek: before or after i get rid of cts pinging me about plymouth 0.9.x =) ? something to do with piles of golden bricks being shipped.
<xnox> slangasek: i haven't started poking those jobs yet, but it should be easy enough to schedule them to not nuke the in-flight contents that's getting generated.
<slangasek> xnox: before
<xnox> slangasek: =)))) i like you.
<bdmurray> xnox: I'd appreciate an update with whatever happens
<xnox> bdmurray: i should file tracking bug, if there isn't one yet.
<bdmurray> xnox: that'd be helpful ;-)
<bluesabre0> o/
<cjwatson> xnox: Let me know if you need help.
<cjwatson> xnox: See also https://bugs.launchpad.net/launchpad/+bug/1013583, in case that's useful
<ubottu> Ubuntu bug 1013583 in Launchpad itself "contents-generation could be 2x faster by not regenerating Packages/Sources" [Low,Triaged]
<xnox> cjwatson: well there is a nice branch from mvo attached to that one =) i may review it on the side as my efforts of getting into apt / reading C++ better.
<cjwatson> xnox: That may already be on production; not sure.  Still a matter of rejigging LP to use it.
<xnox> ack.
<psusi> cjwatson: I noticed the new parted package is in the NEW queue.. I though that was just for packages that were actually new?
<xnox> psusi: new, is new in a sense of new binary packages, always.
<xnox> psusi: e.g. libparnedN+1 is probably new.
<xnox> psusi: libparted2* in this case are new, among others.
<xnox> barry: do you have time to review https://code.launchpad.net/~xnox/launchpadlib/py3-new/+merge/225691 ? If not, I was planning on merging it and starting a PPA with porting effors of various key projects.
<xnox> e.g. ubuntu-archive-tools and ubuntu-dev-tools
<xnox> and like lptools.
<xnox> cause i think a few more issues will be uncovered by porting those.
<barry> xnox: i did review it, but maybe i should have also set the status to approved? ;)
<barry> xnox: and yay!
<xnox> barry: ah, I see.
<xnox> barry: hm, let me "uncover the inline diff comments"
<barry> xnox: i used the inline comment system
 * xnox fails
<barry> yeah
<xnox> barry: i'm not sure what's wrong with these inline comments, somehow e.g. in github they are in yourface obvious.
<barry> xnox: i see them when i visit the page, but maybe that's because i wrote them?
<barry> e.g. lineno 466
<xnox> i need to click "show inline diff comments" on the comment and then they appear.
<stgraber> cjwatson, slangasek: e-mail to ubuntu-devel-announcement for one of you to moderate, thanks!
<cjwatson> psusi: Right, as xnox says.  Quite normal and expected.
<cjwatson> stgraber: done
<cjwatson> psusi: Near the end fo the road now though. :-)
<cjwatson> *of
<stgraber> cjwatson: thanks
<xnox> barry: awesome stuff. merged.
<barry> xnox: \o/
<xnox> barry: how about more awesome reviews of dubious re-casts of strings to strings multiple times? =) https://code.launchpad.net/~xnox/lazr.restfulclient/fixes/+merge/224945
 * barry looks
<xnox> barry: please don't cry =)
<xnox> barry: i think importing HttpLib2Error as SSLHandshakeError is the peak highlight.
<barry> xnox: yeah, i was just wondering about that one - trying to see if there are any docs on that change
<barry> xnox: commented
<xnox> barry: replied. but will fix up tomorrow. Time to Zzzzzz =)
<TJ-> xnox: do you have a few minutes to discuss your mdadm bootdegraded patch for bug #1279741 ?
<ubottu> bug 1279741 in mdadm (Ubuntu) "Degraded array check, may not do what it says it's doing" [Undecided,Fix released] https://launchpad.net/bugs/1279741
<xnox> TJ-: not now, i'm in the UTC+1 timezone. Can you send me an email instead?
<slangasek> cjwatson: 1ab7964e9fa4b495f263a036159f28140da7237b on console-setup makes me want to scream
<TJ-> xnox: I'll open a bug report, but I was just trying to get a sense of the reasoning, since it appears to have broken booting from RAID1 degraded mirrors for several users I've supported.
<cjwatson> slangasek: Thanks Anton
<cjwatson> "hi, I briefly found internet in Bulgaria and here's everything I did for the last month"
<slangasek> :/
<slangasek> I think he meant to say high-proof reading
<cjwatson> That was very much his MO on partman for some time
<saiarcot895> Hi all, do are packages in ppa:openjdk-r/ppa slated to go into the main repos?
<slangasek> bonus points for random mixing of 'elif' and 'else if' <sigh>
<hallyn> desrt: (on the off chance that you are checking irc, but hopefully you are not :)  finally figured out one needed change to your cgm.1 systemd branch - the JobRemoved signal needs the scope name in the 3d arg and "done" in 4th.  With that, all seems good.  (Only other change I'm doing is making systemd force itself into / cgroup at startup)
<jarreed0>  So I have an idea for the Ubuntu Touch OS. It is something I use everyday on my android. It is a tilt control setting were if my phone tilts enough to be placed in my pocket or if my android is set face down the screen will lock. If I would like this specifically and other tilt controlls, like turning auto-tilt on and off, to be implemented into the Ubuntu Touch OS how would I go about making a setting page on the status b
<jarreed0>  lled "Tilt Controls" were I can implement these controls and other ones. Also by doing so will it have to be an app for some one to install or who would I contact to get it intergrated into the system so its built into everyones Ubuntu Touch phone. I posted this idea on the xda forums. I was told that it was an interesting idea and to try posting this here and on #ubuntu-touch
<hallyn> desrt: updates are in github.com/hallyn/systemd-shim #cgm.2
<hallyn> will ping pitti about it in the morning
<xnox> cjwatson: slangasek: what's that about? =) bulgarian patches =)
<cjwatson> xnox: console-setup
<cjwatson> the Debian developer in question at least used to live in Bulgaria with very occasional internet access, and showed up once a month or so with a patch dump and then went away again
<cjwatson> but that was a while ago :)
<slangasek> yes, the justification for a garbage-dump git commit in 2013 is less clear
<xnox> cjwatson: sounds legit =)
 * xnox giggles at DDs arguing about matching multiple hashes and how that somehow protects the archive "better"
#ubuntu-devel 2014-07-15
<hallyn> slangasek: i'm doing another fresh jessie install so i can test the proposed cgmanager (and systemd-shim and lxc whiel i'm at it).  what will be the next step in getting cgmanager into experimental?
<slangasek> hallyn: none; why would I upload it to experimental instead of unstable? ;)
<hallyn> slangasek: bc i originally tagged it with experimental? :)
<slangasek> pssh :)
<mbiebl_>  hallyn: please upload it directly to unstable
<hallyn> slangasek: should i change the changelog msg then?
<slangasek> hallyn: if you wish, though I figure it's fair game for me to adjust that during sponsorship
<hallyn> hm.  stgraber: do you think cgmanager in debian ought to mount name=systemd, or not?
<hallyn> i guess it should
<hallyn> (else lxc fails)
<stgraber> hallyn: yeah, it probably should. Maybe make this conditional to logind's presence?
<stgraber> hallyn: as in [ -e /lib/systemd/systemd-logind ] && args="$args -m name=systemd"
<stgraber> hallyn: hmm, actually, I think we want to do it unconditionaly
<hallyn> stgraber: mbiebl was talking about no longer having the logind start script mount the cgroups, so i think that could break
<hallyn> better to just always mount it
<stgraber> hallyn: because otherwise if you have a host without logind but a container with logind, things will fail due to lack of name=systemd
<hallyn> good point
<hallyn> all right lxc works fine in jessie with cgmanager;  one more rebuild of systemd-shim to test that bit
<hallyn> slangasek: had to update http://people.canonical.com/~serge/cgmanager-0.27.1/cgmanager_0.27-1.dsc anyway for one more one-line fix, so i changed release to unstable.  works here with lxc and systemd-shim, so i'm now stepping back from it.
<pitti> Good morning
<pitti> infinity: ddeb deps> ah right; so I guess, time for a more intrusive rewrite then, and then I can avoid everything else which makes this thing so slow, and also avoid having to maintain the cronjobs every release
<pitti> doko_: did you see that the new twisted seems to break quite a number of rdeps?
<pitti> hallyn: I can have a look
<pitti> hallyn: is there a github pull request or similar for that?
<hallyn> pitti: hey!  no pull request yet;  waht would the pull request be to?  desrt's tree?  (he has a cgm.1 branch which i'm based off of)
<hallyn> for now it's just in github.com/hallyn/systemd-shim #cgm.2
<pitti> hallyn: ah, ok, can look there
<hallyn> cool
<pitti> hallyn: might take a bit though, I'm currently swamped in requests/todos
<hallyn> pitti: understandable - going to bed now;  I can look for review/sponsor in #debian-systemd tomorrow if need be.  thanks in either case
<Saviq> seb128, hey, will you guys have time to review https://code.launchpad.net/~mterry/ubuntu-system-settings/locking-hash/+merge/224346 ?
<seb128> Saviq, I wouldn't mind a review from the security team on that one, they had lot of good reviews comments and specific notes on the first review (see the bug report)
<seb128> Saviq, I can have a look today but I want a security ack before approving it
<Saviq> seb128, yeah sure
<Saviq> seb128, we're working on it on that front as well
<seb128> great
<doko> pitti, yep, not unusual
<Tribaal> Hi all. I opened a branch against an ubuntu package and would appreciate it if someone could have a look at it (it's waiting for sponsorship - but I'd like to make sure I followed the process properly).
<Tribaal> Here's the bug: https://bugs.launchpad.net/ubuntu/+source/ubumirror/+bug/1341523 A "just wait" answer would be good enough :)
<ubottu> Ubuntu bug 1341523 in ubumirror (Ubuntu) "Update to upstream 0.4" [Undecided,In progress]
<jamespage> cjwatson, around? bug 1341618 just got bought to my attention
<ubottu> bug 1341618 in grub2 (Ubuntu) "grub 1.99-21ubuntu3.15 will not boot on some hardware" [Undecided,Confirmed] https://launchpad.net/bugs/1341618
<cjwatson> jamespage: left a comment
<jamespage> cjwatson, ta - i'll poke Spads again
<sil2100> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sil2100
<Spads> cjwatson: I've asked the APAC folks who had first-hand experience to elaborate.  thanks.
<zyga> hey, I'm back from holidays and my sbuild/schroot setup is now broken (all utopic), I seem to get a message saying that my chroots are not owned by root (they are owned by sbuild)
<zyga> googling didn't really help me much
<zyga> the exact message is:
<zyga> E: sid-amd64-sbuild-625b5676-4967-4132-b55e-cd4d95cb5fe5: Failed to lock chroot: /var/lib/sbuild/sid-amd64.tar.gz: File is not owned by user root
<darkxst> pitti, running a autopkgtest with build-needed, doesn't pick up the build depends from the main package?
<pitti> darkxst: it does
<pitti> darkxst: well, for building
<pitti> darkxst: not for the test
<darkxst> pitti, I have to use --disable-unit-tests on the main build or it fails (unless I override that with ||true)
<pitti> darkxst: that's not indended -- building the package should behave like on a buildd
<darkxst> pitti, tracker tests won't run in buildd
<pitti> darkxst: so tracker's debian/rules shoudl already use --disable-unit-tests during build?
<pitti> darkxst: sorry, I'm afraid I still don't understand the question/problem
<darkxst> pitti, yes it does, we want to run the unit-tests but they can't be run at build time
<darkxst> since they need the tracker dbus interfaces
<zyga> hmm
 * zyga digs through schroot code to understand what is causing the problem
<pitti> darkxst: yeah, sounds like these unit tests are rather broken :/ (they ought to start a private D-BUS instance with the locally built tracker)
<darkxst> pitti, so right now I have a autopackage test with "make -c tests check"
<pitti> darkxst: ah, wrapped in a dbus-launch or so?
<darkxst> xvfb-run
<Saviq> jodh, hey, on bug #1222705, do you have a phone with Ubuntu on it by any chance?
<ubottu> bug 1222705 in upstart (Ubuntu) "init assert failure: alloc.c:633: Assertion failed in nih_unref: ref != NULL" [High,Confirmed] https://launchpad.net/bugs/1222705
<jodh> Saviq: I don't have a phone (still waiting ... :)
<Saviq> jodh, the most reproducible case is "restart unity8" on the phone for us, let me try and get you some logs
<jodh> Saviq: thanks
<Saviq> jodh, will try and reproduce on emulator, too
<zyga> hmm
<zyga> it seems that all chroot files need to be owned by root because of $reasons
<zyga> ok, let's try
<zyga> \o/
<zyga> ok
<zyga> that worked
 * zyga looks at schroot changelog
<darkxst> pitti, so the tests run in a fresh chroot?
<pitti> darkxst: yes, with only the test dependencies installed
<Saviq> jodh, https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1222705/comments/18
<ubottu> Ubuntu bug 1222705 in upstart (Ubuntu) "init assert failure: alloc.c:633: Assertion failed in nih_unref: ref != NULL" [High,Confirmed]
<jodh> Saviq: ta
<darkxst> pitti, so would be better to --enable-unit-tests and ignore test failure on build, then just run the tests from autopkgtest?
<darkxst> or add all the build-deps to the tests/control ?
<pitti> darkxst: you can do that, or you find a way to just build the tests (make -C tests) and run them against the installed tracker
<jodh> Saviq: could you also attach the /var/crash/_sbin_init.*.txt?
<pitti> darkxst: you can add @builddeps@ to the test dependencies if you want to build stuff in your test script
<Saviq> jodh, sure, let me get some symbols in it first
<jodh> Saviq: thanks, if you could also trigger the crash with the Session Init running as 'init --user --debug', that would also be fantastic.
<Saviq> jodh, hmm any idea how would I go about that with lightdm auto-starting the session?
<jodh> Saviq: well you could just 'initctl log-priority debug' before starting the tests.
<Saviq> jodh, oh yeah that'd work
<jodh> Saviq: last time I checked, lightdm runs the script /usr/bin/ubuntu-touch-session which you could hack to add '--debug' if you'd prefer.
<Saviq> jodh, added two attachments to the bug, not sure if there's any more useful info
<uki> Is there anyway I can easily have gdb with python2 support on ubuntu 13/14 instead of python3?
<uki> All my gdb scripts are broken as the newer gdb uses python3
<darkxst> uki, you need to make your scripts python3 compatible
<uki> darkxst: any easier way to downgrade?
<darkxst> uki, only if you rebuild gdb against python2
<darkxst> not possible with archive versions
<uki> ah i see, thats sounds good. so id have to "apt-get source", uncompress the deb and rebuild?
<uki> darkxst: ^^
<darkxst> uki, I have never tried, its pretty easy to convert most scripts. but at the very least you would need to modify build-depends
<uki> darkxst: im comfortable with python3, yes, but im using an entire lib written for use within gdb thats written in python2. conversion isn't really desirable at this point.
<darkxst> uki, try run the scripts through 2to3
<sil2100> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
 * sil2100 lunch
<darkxst> pitti, will xvfb-run pass through test errors? or do I need to trap them somehow?
<pitti> darkxst: it passes through stdout/err and exit code, so no need for anything special
<sil2100> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sil2100
<darkxst> pitti, so this should be fine then? http://pastebin.com/ESPq5FNs
<Saviq> jodh, just reproduced the same crash under i386 emulator, do you know the steps to get one?
<pitti> darkxst: if that builds the unit tests and works, it looks fine
<darkxst> pitti, runs fine locally with adt-run
<pitti> darkxst: @builddeps@ because "make -C tests check" actually builds more stuff than what gets build with dpkg-buildpackage?
<LocutusOfBorg1> xnox, did you read this? https://github.com/performous/performous/commit/79eff6c44b76f26366588e12a606a77bd6e97a83
<LocutusOfBorg1> :)
<darkxst> pitti, yes, as mentioned earlier main build has --disable-unit-tests
<pitti> darkxst: right, but the test doesn't call ./configure again, that's why I wondered; so if that make call does it, then fine :)
<pitti> darkxst: btw, if that works, the tests should also work during package build if you run them through xvfb-run in debian/rules override_dh_auto_test
<Saviq> jodh, https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1222705/comments/24
<ubottu> Ubuntu bug 1222705 in upstart (Ubuntu) "init assert failure: alloc.c:633: Assertion failed in nih_unref: ref != NULL" [High,Confirmed]
<darkxst> pitti, no I tried that first, but they require the tracker dbus, which of course isn't installed (although I will file a bug upstream about fixing that)
<jodh> Saviq: thanks, I'll ping you if I need anything else.
<Saviq> jodh, cheers
<darkxst> pitti, they also require a utf-8 locale and $HOME set, fwiw
<pitti> darkxst: ah, ok; thanks!
<smb> xnox, It is a rather minor issue but I thought to document it anyway. Now what again would be the package related to current desktop installer?
<cjwatson> ubiquity
<sil2100> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<smb> cjwatson, thanks
<kgunn> ChrisTownsend: hey there, i'd normally pester stephen on this...
<kgunn> but, we're getting darn close to landing qtcomp
<kgunn> but we need one mp (1 line change)
<kgunn> https://code.launchpad.net/~gerboland/unity8-desktop-session/qtcomp/+merge/225884
<kgunn> reviewed
<kgunn> would you mind ?
<kgunn> there have been a few of us that have tested the silo against unity8-desktop
<kgunn> https://wiki.ubuntu.com/Unity8/QtComp
<kgunn> and it worked fine
<ChrisTownsend> kgunn: Hey.  Sure, I can take a look.  Is the suggestion that Stephen made been done?
<kgunn> ChrisTownsend: uh.... :P
<ChrisTownsend> kgunn: Also, that MP is marked WiP, but I assume it's ready for review since you are asking me:)
<kgunn> greyback: ^ yeah, can we flip the switch to review ?
<greyback> kgunn: done. Unsure what checklist to enter though
<ChrisTownsend> kgunn: And when you "tested in the silo", does that mean unity8-desktop-session is already in a silo and this just needs approved so it can be published?
<kgunn> greyback: something sensible....like, no api break, been tested as part of https://wiki.ubuntu.com/Unity8/QtComp
<kgunn> ChrisTownsend: yes, its a collection of MP's that all have to go at once...and its been under test by us & the community for over a week now
<kgunn> and something we need for rtm
<kgunn> hence my underwear being slightly wadded
<ChrisTownsend> kgunn: Ok, makes sense.  I wasn't sure if a new silo, etc. needed to be set up.
<ChrisTownsend> kgunn: lol, we'll get it in.
<kgunn> ChrisTownsend: yeah, we're just in the process of collecting approvals....and will just flip the switch on that silo from testing to "attempt to land"
<ChrisTownsend> greyback: kgunn:  So is bregma's comment about this also needing to be added to data/unity8-mir.conf legit.  You say it works already, so maybe that's not necessary, but I'm just wondering if it still needs to be there just to be safe.
<greyback> ChrisTownsend: yep I just saw that. I'll do it to be safe
<ChrisTownsend> greyback: Cool, thanks.
<ChrisTownsend> greyback: Let me know when you have that pushed and I'll approve.
<greyback> ChrisTownsend: just pushed
<ChrisTownsend> greyback: Ok, thanks
<greyback> thank you!
<ChrisTownsend> kgunn: greyback: Approved
<greyback> one down....
<kgunn> woohoo
 * ChrisTownsend Hopes kgunn's underwear is slightly less wadded.
<kgunn> lol thanks ChrisTownsend
<ChrisTownsend> kgunn: np!
<Riddell> mvo_: ping, are you able to help debug an apt issue with me?
<mvo_> Riddell: maybe, what is the issue you see?
<Riddell> mvo_: I'm making a new meta package
<Riddell> for kubuntu-plasma5-meta
<Riddell> it's in the kubuntu-ppa/next
<Riddell> but when I apt-get install kubuntu-plasma5-desktop it doesn't want to install because powerdevil says it breaks on kde-workspace-data
<Riddell> mvo_: how do I tell it it's fine to remove kde-workspace-data ?
<Riddell> if I explicitly   apt-get install kubuntu-plasma5-desktop powerdevil  it's fine with removing kde-workspace-data and anything else that's needed
<mvo_> Riddell: this is against utopic? give me a sec to see what the resolver tells me
<Riddell> mvo_: yep
<Riddell> mvo_:  sudo apt-add-repository ppa:kubuntu-ppa/next ; sudo apt-add-repository ppa:ci-train-ppa-service/landing-005
<mvo_> Riddell: ok, give me a minute to setup a chroot
<Riddell> mvo_: oh I have an ec2 if you give me your ssh key
<Riddell> mvo_: ssh ubuntu@ec2-54-91-220-158.compute-1.amazonaws.com
<hallyn> mbiebl: slangasek: pitti: so systemd-shim is nto useful in experimental as is anyway, so could we upload the patched version to experimental as soon as cgmanager goes into unstable, to make progress with systemd-208 after it gets some wider testing?
<mvo_> Riddell: thanks, I will use that then
<mvo_> Riddell: you have not added the ppa in the ec2 instance yet, is that correct?
<mvo_> Riddell: unicorns eh :) ?
<Riddell> mvo_: I have, in /etc/apt/sources.list.d/
<mvo_> Riddell: aha, what is the binary package name I need to install to trigger the problem?
<Riddell> mvo_: I've only installed kubuntu-desktop, the issue is with kubuntu-plasma5-desktop
<mvo_> Riddell: thanks, that was the name I missed
<mvo_> Riddell: so apt tries to keep it because installing it would causing removals of a package with a higher "score", but there is something more going on it seems. with the ppa and the landing silo I can not install kubuntu-desktop ( kubuntu-desktop : Depends: plasma-desktop but it is not going to be installed)
<Riddell> mvo_: I don't think I've tried that, plasma 5 overlaps with the old stuff in various places so I'm not trying to support going back the way
<mvo_> Riddell: which seems to come from a conflict of plasma-workspace against klipper
<mvo_> Riddell: aha, ok
<Riddell> mvo_: so maybe I should just keep the name of the meta package the same as kubuntu-desktop
<mvo_> Riddell: the breaks in powerdevil says "Breaks: kde-workspace-data (<< 4:4.98.0)" - would that be a option? a updated kde-workspace-data ?
<Riddell> mvo_: nah kde-workspace is going away in plasma5 land
<mvo_> Riddell: that may well make sense, if kubuntu-desktop is going to vanish
<mvo_> Riddell: ok, that is good to know, give me a sec then
<mvo_> Riddell: if its going away then you may simply add a transitional package for those, I don't really know much about the way kde is packaged (or develooped :) so take my advice with a grain of salt. but if it is not co-installable, well :)
<Riddell> mvo_: hmm yes that's another idea
<mvo_> Riddell: a direct conflict/break in the kubuntu-plasma5-desktop would also work
<Riddell> aah yes
<Riddell> good, I'll play around, thanks mvo_
<mvo_> Riddell: good luck and sorry that this is so complicated, I wonder/wondered if it would be worth  to add/support a "obsoletes" tag just like in rpm
<sil2100> didrocks: so, I was wondering... since in cu2d whenever, let's say, the cu2d-apps-head-2.1build job has finished with success, jenkins automatically started the cu2d-apps-head-2.2check job
<sil2100> didrocks: while I didn't see any triggers configured from the jenkins side
<sil2100> didrocks: nor in the cu2d scripts being executed
<didrocks> sil2100: there was master job IIRC
<didrocks> let me check
<sil2100> Ah
<sil2100> !
<didrocks> https://wiki.ubuntu.com/DailyRelease/StackPublish#Different_phases_of_one_stack
<didrocks> this diagram can help
<sil2100> didrocks: I see the job, hah, makes sense now
<didrocks> soâ¦
<sil2100> Thanks!
<didrocks> you have the master job
<didrocks> which triggers the prepare jobs
<didrocks> which was traking the prepare-project ones, one per project on that stack
<didrocks> then, master was chaining (once prepare finishes successfully or only having warnings) to 2 jobs in parallel
<didrocks> build and check
<didrocks> both were chaining to the publish one
<didrocks> this is a simplified case, there is the waitonstacks in reality, but not needed for that demonstration
<didrocks> sil2100: does that make sense? ^
<sil2100> didrocks: makes sense indeed, thanks :)
<didrocks> yw ;)
<bdmurray> xnox: did you have a look at the issue regarding Contents.gz or did we win the race condition?
<brendand> does anyone know how to use a binary from the build at build time?
<brendand> i want to use a binary provided by the package i'm writing tests for, in the tests
<cjwatson> mangle paths, or run the tests in question via autopkgtest
<xnox> bdmurray: no, not yet. will look into it today.
<xnox> LocutusOfBorg1: \o/
<xnox> smb: so which bug did you file about ubiquity?
<smb> xnox, bug 1342071
<ubottu> bug 1342071 in ubiquity (Ubuntu) "Invisible installer dialog on VM iso installation" [Low,New] https://launchpad.net/bugs/1342071
<smb> installer dialogue is a bot off as I mean the "eject media and press enter" back on the framebuffer
<xnox> smb: yeah. and i don't know how to make it more reliable.
<smb> xnox, Hm, ok. Probably I should investigate a bit more into it. I was not sure it ever really was brought up and I get surprised every cycle when I play around with VM installations :-P
<smb> At least as long as I do them manually and not through netinst
<xnox> smb: i think we should be doing systemd style pivot into a shutdown initramfs that shows that text....
<xnox> smb: at the moment however it's a jumbo between kernel, plymouth messages and that text.
<smb> xnox, Yeah, this has been a pain in other senses as well (racing on the way up). Though I cannot help myself from being doubtful that systemd is less painful when taking over the world.
<xnox> smb: i haven't yet planned how to do ubiquity with systemd.
<xnox> smb: i believe we will have to conflict and/or replace targets. or something like that.
<smb> xnox, Its not so much knowledge that makes me doubtful. Though I cannot decide myself whether I should call it pessimistic or realistic. >:)
<brendand> is there any variable i can use in debian/rules to reference the directory like 'build-area/url-dispatcher-0.1+14.10.20140619/obj-x86_64-linux-gnu'
<brendand> i.e. the directory where binaries are built into
 * hallyn feels all accomplished now that he created a debian mentors account
<hallyn> slangasek: dunno if it helps in anyway, but i pushed cgmanager to mentors.debian
<xnox> hallyn: \o/
<xnox> hallyn: let me review that =)
<xnox> hallyn: well there are lintian errors already =)
<hallyn> xnox: the bad-distribution-in-changes-file unstable error?
<xnox> hallyn: nah, I'll comment on mentors, I see a few other issues.
<hallyn> cool, thanks
<hallyn> xnox: when responding to feedback with a new pkg, do i bump the version as i would in archive/ppa, or do i just delete and re-upload?
<hallyn> (re-upload would be suboptimal as feedback-as-teaching is lost)
<xnox> hallyn: well, with mentors.
<xnox> hallyn: you would keep the version the same, but keep adding things in the changelog.
<xnox> e.g. * Fixed foobar and bar in jars.
<xnox> hallyn: and published a second comment about binaries.
<hallyn> xnox: i did look for an ITP bug to close, but didnt' see one.  the, uh, other cgmanager upload didn't close one so i assumed that was an optional formality.  is it not?
<xnox> hallyn: in Debian, the person who "Intends To Package" should open an "Intends To Package" bug against "WNNP" package. And close it on the first upload into debian.
<xnox> hallyn: I don't see any prior uploads in Debian.
<xnox> hallyn: there is no ITP bug equivalent in Ubuntu.
<xnox> https://www.debian.org/devel/wnpp/
<hallyn> xnox: right, there is a cgmanager (0.20 version) upload to ftp.debian somewhere.  that's the one i meant.
<hallyn> ok, will open that bug then
<xnox> hallyn: you may use $ report-bug or just construct email by hand. They are cc'ed to debian-devel by default, so you can see plenty of examples.
<xnox> hallyn: i really don't see cgmanager 0.20 upload, that got accepted.
<hallyn> it didn't get accepted
<hallyn> argh, i hate the symbols files :)
<doko> xnox, please don't revert gobjc back, won't help, and won't help for gfortran either. tvoss did promise to be ready today, so we can point to 4.9 again
<xnox> doko: why will it "won't help" ?
<xnox> doko: and it's not a revert, per se. At the moment a non-matching library was getting installed for the default compiler... Not sure how fortran operates, but it seems to be buildable.
<xnox> doko: unlike fortran, which is a binary in path, cc1obj is just an internal gcc private executable. one uses gcc to compile objc code.
<doko> xnox, same as f951
<xnox> doko: ok, so when you/slangasek reverted to 4.8, why was it not done for gobjc, gojbc++ and fortran as well? given that it left those in complete FTBFS state.
<xnox> (in -proposed and -release)
<doko> xnox, because fortran is an ABI transition which already was in progress
<slangasek> xnox: because we were implementing an immediate short-term fix for a critical phone issue, leaving a few packages ftbfs in the short term is acceptable collateral damage in the general case
<doko> and I didn't want to investigate if it is safe to revert gobjc
<slangasek> xnox: and gcc-4.9 is supposed to be made the default again RSN
<doko> if you did investigate, then sure, that might be safe
<hallyn> xnox: looking at the dpkg-gensymbols output for libcgmanager0, it gives me symbol@Base...  with netcf it gives me symbol@NETCF_version.
<hallyn> problem with my .pc file?
<xnox> hallyn: not the .pc file -> that one just encode paths to your header files & which libraries to link/depend on.
<xnox> hallyn: if you want to version your symbols, you'd need to use libtool symbol versioning facilities.
<hallyn> xnox: and if i don't want to?
 * hallyn looks to see what doing that might entail
<xnox> hallyn: you are fine just as it is. if later you want to update a symbol you would be able to provide two versions of the same symbol and mark one of them the default.
<xnox> hallyn: or like, just don't break you api/abi =)
<hallyn> xnox: but then how do i generate a symbols file,
<hallyn> i thought the "*@LIB_version package-version" was the whole point
<xnox> hallyn: the debian/libcgamanger0.sybmols?
<xnox> https://wiki.debian.org/UsingSymbolsFiles ?
<xnox> hallyn: the point of debian/*.symbols file to list _all_ symbols and when they were introduced. Such that you can catch if they change or get removed, and also get correct dependencies depending on which apis are used.
<hallyn> yeah that's where i'm looking.  that gives me a huge list, which you seemed not to want for netcf
<hallyn> ok - i'll upload with the results of that- thanks
<xnox> hallyn: right, so netcf is special. Upstream has versioned all of their symbols very tightly, hence debian/libnetcf1.symbols is ok to use wildcards to get all symbols covered.
<xnox> hallyn: but that doesn't help to catch, if e.g. upstream make a mistake.
<xnox> hallyn: e.g. I like dbus-cpp symbols files the best.
<hallyn> netcf does that in src/netcf_public.syms?
<hallyn> dbus-cpp symbols?
<hallyn> the package?
<hallyn> nope
<xnox> hallyn: this symbols file for libcgmanager is correct one http://paste.ubuntu.com/7800703/
<hallyn> xnox: ok, that's what i've got (except 0.27 :)
<xnox> hallyn: in libnih, we do version symbols using a libtool versioning script e.g. https://github.com/keybuk/libnih/blob/master/nih/libnih.ver hence they are not @Base.
<xnox> hallyn: so just stick that into debian/libcgmanager0.symbols and you are done.
<hallyn> xnox: thanks.
<hallyn> xnox: (still looking at dbus-cpp)
<xnox> hallyn: that one is c++ hence symbols are different per-platform and 32/64/big/little.
<mbiebl> cyphermox_: calestyo being pleasant as always (re that NM bug)
<mbiebl> anyway, since we basically all agree, I'll try to cook up a patch and run it by you
<cjwatson> brendand: "build-area/url-dispatcher-0.1+14.10.20140619" is almost certainly just your current directory; no need to put that together.  For the rest of it you want "obj-$(DEB_HOST_GNU_TYPE)".  You should normally put "DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)" near the top of debian/rules to make sure that variable is initialised.
<cjwatson> brendand: But "obj-$(DEB_HOST_GNU_TYPE)" is something that your package's own build system controls - it's not set by anything central.  So if your package is buggy it's possible it's being set from something else, e.g. DEB_BUILD_GNU_TYPE.  You should really grep your package's source code to find out where that's set.
<cjwatson> brendand: Or perhaps your package's build system.  For instance some cdbs classes set $(DEB_BUILDDIR) to that.
<cjwatson> Or indeed some debhelper modes.
<infinity> robert_ancell: 1:2.8.3-0ubuntu1build1 really?
<infinity> robert_ancell: ITYM -0ubuntu2 ;)
<robert_ancell> infinity, which package?
<infinity> robert_ancell: That was calligra.  I noticed it cause I was looking at the FTBFS.
<robert_ancell> Ah, I think I did that because I don't have access to lp:~kubuntu-packagers/kubuntu-packaging/calligra
<robert_ancell> but I'm not sure it's valid :)
<infinity> robert_ancell: For future reference, "dch -R" intelligently does the right thing (-NbuildN for unmodified Debian stuff, increments -NubuntuN for not)
<robert_ancell> ta, didn't know that
<infinity> robert_ancell: Oh, if it was intentional cause you expected them to throw it away, that sort of makes sense, ish. :)
<robert_ancell> yeah.
#ubuntu-devel 2014-07-16
<cyphermox_> mbiebl: ack, any time
<xnox> cjwatson: infinity: there was something-rather about ppc64el and stuff failing to convert to/from vectors e.g. "could not convert from '__vector(4) __bool int' to 'bool'" seen in latest performous build.
<xnox> what was it?
 * xnox goes to grep my irc logs
<eam> Hi, I'm looking to talk to someone about this linking policy: https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition what is the right forum?
<eam> I'm concerned these recommendations result in shared objects unsuitable for loading via dlopen()
<eam> The few packages I've examined for interpreted languages which load C stubs appear to completely disregard the build recommendations (which, as far as I can tell is the right approach)
<hallyn_> mbiebl_: the systemd-shim patches are up in https://mentors.debian.net/package/systemd-shim
<pitti> Good morning
<pitti> hallyn_: still here? do you know why desrt didn't yet push the patches to trunk? because he didn't have time to test them yet, or is there something known-broken still?
<Tribaal> hi all, how can I make sure my package (waiting for sponsorship) is following the right procedure?
<Tribaal> shoud I just wait?
<Noskcaj> Tribaal, link to it?
<Tribaal> Noskcaj: https://code.launchpad.net/~tribaal/ubuntu/utopic/ubumirror/1341523-upstream-release/+merge/226654
<Noskcaj> The version is normall -0ubuntu1, not ubuntu0
<Tribaal> Noskcaj: ok, will fix
<Noskcaj> or for this, ubuntu1
<Noskcaj> (no -0_
<Noskcaj> )
<Tribaal> Noskcaj: oh ok
<Tribaal> Noskcaj: pushed. Looks better?
<Noskcaj> yeah
<Tribaal> Noskcaj: so now, I just need to wait for someone to pick it up right? No other steps needed?
<Noskcaj> Don't subscribe sponsors to the bug, it has nothing to be sponsored
<Tribaal> Noskcaj: oh?
<Noskcaj> And they are auto-subscribed to the branch
<Tribaal> Noskcaj: what do you mean? sponsorship is not needed for branches?
<Noskcaj> The sponsors team is subscribe to a merge (the branch) which is different to the bug
<Tribaal> ah
<Tribaal> ok
<Noskcaj> You would subscribe them to the bug if you were using a debdiff
<Tribaal> Noskcaj: ahhh ok
<Tribaal> Noskcaj: so, that explains the double entry in http://reqorts.qa.ubuntu.com/reports/sponsoring/index.html I suppose
<Noskcaj> yep
<Tribaal> ok, I'll unsbscribed them then
<Noskcaj> You mention the a few bugs are fixed in this release. If they are shown at https://bugs.launchpad.net/ubuntu/+source/ubumirror , you should probably close them in the changelog
<Noskcaj> The packaging could have a minor update too, but it's less important
<Tribaal> Noskcaj: I don't understand your packaging minor update remark
<Noskcaj> standards-version should be bumped to 3.9.5, debhelper version to 9, remove the upstream-vcs link
<Tribaal> Noskcaj: will do.
<Noskcaj> ok
<Tribaal> Noskcaj: pushed. Should look better
<pitti> xnox: hm, I still have rtc in /etc/modules in my just freshly upgraded VM; I thought you fixed that already?
<Noskcaj> Tribaal, Use http://paste.ubuntu.com/7802062/ as you changelog. You should try to cover everything changed.
<Tribaal> Noskcaj: should I set myself as maintainer?
<Noskcaj> yeah. It seems that you are
<Tribaal> Noskcaj: fair enough
<Noskcaj> d/copyright could probably be improved, but that's an issue for another day
<Tribaal> Noskcaj: pushed.
<Tribaal> Noskcaj: yes, I'll update upstream as well (there is a lot of things to do there still :) )
<Tribaal> like adding man pages
<Noskcaj> ok. I suggest you use lintian to find these packaging issues in future. it helps a lot
<Noskcaj> Now we wait for someone with upload rights (i.e. not me) to look at the package
<pitti> hallyn_, desrt: ah, I was wondering why there was only one systemd cgroup, and all processes are in that -- seems systemd-shim should grow a dependency to cgmanager now
<Tribaal> Noskcaj: ah, yes, thanks for the tip about lintian
<Tribaal> Noskcaj: I should have thought of it mysellf
<Tribaal> Noskcaj: thanks a lot for you help
<pitti> stgraber, hallyn_, desrt: so this can't go to Debian yet as cgmanager isn't in Debian -- do you plan to upload it there?
<pitti> stgraber, hallyn_, desrt: oh, it's already in the NEW queue
<pitti> splendid!
<pitti> hallyn_, desrt: one nitpick is that it doesn't seem to clean up sessions on logout, I suppose because cgroup_unit_stop() isn't implemented?
<pitti> hallyn_: I uploaded https://launchpad.net/ubuntu/+source/systemd-shim/6-3ubuntu1 with the added dependency
<pitti> hallyn_: I think the next steps are to implement cgroup_unit_stop(), merge this into trunk, release 7, and upload that to Debian as soon as cgmanager gets out of NEW
<pitti> hallyn_: FYI, http://people.canonical.com/~pitti/tmp/systemd-208/
<Noskcaj> pitti, debian now has upower 0.99. Any progress on porting python-dbusmock?
<Noskcaj> This shall be a mess
<pitti> Noskcaj: still on my ever-growing TODO list; but I suppose it's a very simple fix, I already had it working with 0.99
<Noskcaj> ok
<Noskcaj> We're still waiting on the ubuntu-touch team, so it's not super urgent here, only "be done by 14.10" if you can
<pitti> yes, that should be no problem at all
<xnox> pitti: we didn't remove it on upgrades in the end. It's not added on fresh installs I think.
<xnox> pitti: or did it get _added_ on upgrades?!
<pitti> xnox: no, I think just not removed
<xnox> ack.
<pitti> xnox: no, I think just not removed
<pitti> xnox: sorry, -EFOCUS
<LocutusOfBorg1> xnox, thanks
<LocutusOfBorg1> and also thanks to cjwatson ;)
<LocutusOfBorg1> I think the libav transition is getting almost done, right? ;)
<cjwatson> See my recent comments in #ubuntu-release
<cjwatson> (on irclogs.u.c if you don't have scrollback)
<cjwatson> It's definitely close, but still a couple of tricky bits
<pitti> hallyn_, stgraber: current phone boots/works fine with updated shim and systemd 208 as well \o/
<LocutusOfBorg1> wonderful!
<pitti> mbiebl_: so yay, it seems systemd 208 is finally unblocked, once cgmanager makes it through Debian's NEW queue
<cjwatson> \o/
<pitti> mbiebl_: >= 205, I mean
<Laney> pitti: would you be able to run `edit-acl -p xubuntu-uploaders -S trusty -P xubuntu add' please?
<pitti> Archive Upload Rights for xubuntu-uploaders: archive 'primary', package set 'xubuntu' in utopic
<pitti> Archive Upload Rights for xubuntu-uploaders: archive 'primary', package set 'xubuntu' in trusty
<pitti> Laney: ^ done
<Laney> thank you!
<pitti> yw!
<Laney> bluesabre: ^^^
<bluesabre> thanks pitti and Laney :D
<Noskcaj> Would anything break if http://people.canonical.com/~platform/desktop/ubuntu-desktop.html was patched to us packages.qa.debian.org/package rather than packages.qa.debian.org/p/packages.html ?
<Noskcaj> all lib links are broken because of how this is coded
<pitti> no, nothing should break; I think this is seb128's code
<Noskcaj> Would in be too early to swap to tracker.debian.org?
<seb128> Noskcaj, pitti: code is  lp:ubuntu-desktop-versions and patches are welcome
<Noskcaj> seb128 i'm pushing a fix for lib links not working
<Noskcaj> and was wondering if we should swap to tracker.debian.org
<seb128> what is the difference/why would it be better?
<Noskcaj> It's the replacement to packages.qa.debian.org .
<xnox> seb128: tracker.debian.org is the sexy new replacement for packages.qa.debian.org
<Noskcaj> I'll find the "official" list of why it's better
<xnox> seb128: it literary blown my mind away when i saw it for the first time =)
<seb128> xnox, seems quite similar to be from a content perspective
<xnox> seb128: yeah, content is the same, it's just eye-candy =)
<pitti> yeah, it almost has the same information; I'm missing the suites in the upload list, though
<seb128> I find it less easy to read/parse
<seb128> Noskcaj, no objection from me to the change in any case
<xnox> it's python/django vs perl
<seb128> yeah, I guess as any change it takes some getting used to
<Laney> it's mean to be reusable for derivatives / more modular, IIUC
<Laney> meant
<Noskcaj> I'll put the first merge up tonight, it's past "computer off time"
 * pitti files a bug about getting the suites back
<Noskcaj> g'night
<seb128> Noskcaj, night
<pitti> ah, debian bug 754805
<ubottu> Debian bug 754805 in tracker.debian.org "tracker.debian.org: no info about where the package has been "accepted" (e.g. unstable or experimental)" [Normal,Open] http://bugs.debian.org/754805
<cjwatson> mm, I don't think the all-white thing is an improvement, I find it harder to scan visually
<cjwatson> but I guess that's just CSS so I suppose I can userstyle it if I really care
<pitti> yeah, the red title bars made the various boxes visually easier to find and tell apart
<seb128> +1
<seb128> that's what I meant by "
<seb128> "I find it less easy to read/parse"
<pitti> Noskcaj: so dbusmock's upower tests still succeed here with upower from trunk; I'll check your PPA
<doko> Mirv, seb128: please don't upload no change rebuilds with a new ubuntuN suffix. All these uploads should have a buildN suffix if no ubuntuN suffix exists. seen for your Qt3 uploads in June
<xnox> seb128: cjwatson: pitti: there is a bug filed about "too white washy look" asking to bring back the debian magenta colours.
<seb128> doko, qt3? me?
 * xnox we have qt3 in the archive?.... sounds like a bug
<doko> qt5 then, anyway
<seb128> I've uploaded qt5?
<cjwatson> With Qt5 it really helps to actually name the full source package
<cjwatson> Since there are quite a few of them
<seb128> doko, not sure what you are talking about there, can you give some specifics?
<xnox> doko: what's the source package name? quite a few qt packages are "forked" from debian and thus it starts off with 0ubuntu1 and hence no way to use "binNMU suffix" upon no change rebuilds. Plus there are gazzilion of qt5 src packages....
<doko> xnox, seb128, Mirv: at least gammaray, but there seem to be more
<seb128> doko, I've nothing to do with that upload
<doko> fcitx-qt5
<seb128> doko, that one is in sync
<seb128> doko, did you actually mention my name because of an upload I did or was that an error?
<xnox> doko: right that looks like the set of things that Mirv mass-rebuild in a huge ppa/train landing.
<seb128> not sure what youa re trying to blame me for there
<xnox> doko: I guess Mirc didn't know about $ dch -r at the time, nor any of the people who approved all of those uploads.
<cjwatson> -R
<Mirv> doko: yes, there's a filed bug about not forgetting about those
<Mirv> fcitx-qt5 was fixed by another sync from Debian, gammaray is still there
<Mirv> it was actually a last minute decision to not care about that smallish issue to not delay the landing, but it was spotted
<Mirv> now there seems to have been another gammaray release in debian today, so that could be synced to fix bug #1332143 for good
<ubottu> bug 1332143 in gammaray (Ubuntu) "Sync again from Debian some time after Qt 5.3 landing" [Undecided,New] https://launchpad.net/bugs/1332143
<xnox> cjwatson: does "memmove (e, e + 1, (char *)(*env + *len) - (char *)e);" look safe? or what was the glibc saga w.r.t. memory moves & copies being backwards and thus overriding src before it got copied to dst?
<cjwatson> the thing you're referring to was with code incorrectly using memcpy rather than memmove, or equivalent
<cjwatson> that looks safe although those casts look clumsy and I'm sure it's possible to do better
<cjwatson> may not be very performant
<cjwatson> obviously haven't checked the lengths
<cjwatson> presumably (*env + *len) and e are part of the same object otherwise the pointer arithmetic is undefined
<xnox> cjwatson: ah, ok.
<xnox> jodh: ^
<zyga> pitti: ping
<zyga> pitti: are you still the best person to talk to about i18n in ubuntu?
<pitti> hello zyga
<zyga> pitti: I have a problem and a proposed solution but I'm looking for advice and feedback
<pitti> zyga: I don't think there is "a" best person, we haven't had a designated i18n maintainer for years
<zyga> pitti: ok :-)
<zyga> pitti: I'll take that as yes anyway :D
<pitti> so probably best to just ask here
<zyga> pitti: so, there idea is as follows, we'd like to build search indices along with some of our packages, so that after installation apps can load package data (think of it as pluggable levels in a game) and search without having to reindex
<zyga> pitti: now the caveat, we want that to be i18n, we have translations for everything in gettext and we could build localized search indices at package build time
<lifeless> pitti: i18n is a 'solved problem' :)
<zyga> pitti: to do that correctly though, I think, we'd have to get the locale for each supported language and maintain that as a part of our package, we'd also ship all the translations as a part of the "level/add-on" package
<zyga> pitti: I was looking for any suggestions or any best practices to look at
<pitti> (will read in a bit, need to empty brain state)
<zyga> pitti: thanks!
<pitti> zyga: why do you need the locale? do you need time/date/monetary formatting in there? For just gettext() having the mo or po files is sufficient
<pitti> zyga: and intltool-extract/intltool-merge even support that kind of operation for common formats
<zyga> pitti: I don't think we need any of the locale features you've mentioned, you are right, we can just load those translations directly, using python, and generate the index this way
<zyga> pitti: still, we'll end up with translated index (or one larger index with translations, haven't though if we should try that yet)
<mapreri> It's more than 30 hours since last merge-o-matic update. What's up?
<mapreri> cjwatson: â
<cjwatson> mapreri: poked
<mapreri> cjwatson: thanks
<cjwatson> dpkg-source's new strictness on patch headers has had a lot of sequential fallout as people gradually fix packages
<cjwatson> each time there's a fix merge-o-matic tries to diff against the old version and finds it can no longer unpack it
<cjwatson> so I have to go and nuke the old version out of the pool
<mapreri> umh, ok
<cjwatson> mapreri: I've at least arranged for it to mail me about failures now
<cjwatson> (Hadn't done that before because it was too noisy on success, but I think I've fixed that now)
<mapreri> cjwatson: at leas I don't need to poke you every time (I think this is the 3rd) :)
<cjwatson> Yeah, assuming the mail path works, this way I should actually notice
<xnox> mvo_: would you like to steal my aptitude merge? =)
<mvo_> xnox: sure
<mvo_> (famous last words I guess)
<xnox> mvo_: that would be amazing, thanks =)
<xnox> mvo_: well, it's not that bad. It's hardly console-setup merge ;-)
<mvo_> haha, yeah, its not quite of epic proportions yet :P
<cjwatson> mapreri: Excellent, failure mails work
<mapreri> cjwatson: \o/
<cjwatson> mvo_: Just thinking about how to backport your apt/trusty upload to precise for use on the production publisher - has the libapt-pkg ABI really not changed since precise?  That would be handy if so
<cjwatson> mvo_: I'm thinking that we could leave both libapt-inst1.4 and libapt-inst1.5 installed, and so not have to rebuild python-apt
<Saviq> pitti, hey, do you know if -dbgsym packages were supposed to (or could) be available in the silo PPAs?
<mvo_> cjwatson: I think this would work, but I can look into doing a real backport of this feature to precise. my understanding was that a upgrade to trusty was planed and thats why I stopped pursuing the backport
<cjwatson> mvo_: I'd rather upgrade this independently; usually the apt-ftparchive upgrade is the riskiest part of the publisher upgrade
<cjwatson> mvo_: Given that we're targeting trusty anyway, we could just as well use this as the next best thing to a proper SRU verification
<cjwatson> And then upgrade the publisher systems to trusty a bit later
<cjwatson> That will take longer though - we'll probably want a trusty buildbot, we'll need to upgrade dogfood, and there are some other bits and bobs
<cjwatson> And we probably ought to finish the precise upgrade everywhere first :)
<mvo_> cjwatson: ok, that makes sense. I can double check the abi again, but I don't think we broke it.
<caribou> Q: When applying a debdiff that removes a quilt patch, is it mandatory to "quilt pop -a" first before applying the debdiff ???
<caribou> I have a case where debuild complains of locally modified files if I don't unapply the quilt patches before
<cjwatson> caribou: It's the path of least confusion
<caribou> cjwatson: so there is no upfront mandatory procedure then
<caribou> cjwatson: i.e. what I am doing of unapplying the patches first is correct
<caribou> cjwatson: so when I ask for sponsoring of that debdiff, the sponsor will not come back at me saying "your debdiff doesn't apply unless I unapply the other patches first"
<cjwatson> Sounds fine
<caribou> cjwatson: thanks
<cjwatson> Saviq,pitti: Should be.  Is this the same as the question tvoss asked on #ubuntu-ci-eng?
<pitti> Saviq: yes, PPAs can be configured to produce dbgsyms, they will be right in the PPA repo then
<pitti> Saviq: I don't know how exactly (if you don't see it in the PPA config page), infinity will know then
<cjwatson> pitti: I've checked, they're all configured right and I see output for at least some silos
<cjwatson> Which is why I'm asking if it's the same question 'cos then I don't have to track down the details twice because people had a conversation elsewhere and then asked two separate people in two different channels at about the same time ;-)
<mvo_> xnox: almost done with aptitude, why did you add dh-autoreconf? if it needs to be there I would like to put a rational in the changelog :)
<mvo_> (or drop it to keep the delta small)
<xnox> mvo_: most likely added during bootstraps of arm64 & ppc64el.
 * xnox reads diff
<xnox> mvo_: wait. I have added patches that modify configure.ac (the cherrypicks for boost1.53 compat) and thus hence had to use dh-autoreconf to get them working.
<xnox> aptitude-0.6.8.2/debian/patches/0002-support-again-Boost-1.53.patch
<mvo_> xnox: aha, good. so I can drop it, thanks
<mvo_> xnox: the fixes for boost are upstream now
<hallyn_> pitti: hi, systemd-shim isn't handling Stop right now, but the sessions are being removed on (on my systems) because cgmanager is setting remove-on-empty
<hallyn_> oh, is Stop a forcible kill of the session?
<pitti> hallyn_: hm, not here; I tried with "ssh test@localhost", that adds sessions but doesn't clean them up
<pitti> hallyn_: depends, that's configurable (we don't enable it by default)
<hallyn_> pitti: I bet your system has cgroup-lite installed, or it otherwise pre-mounted the cgroups before cgmanager started.  in that case cgmangaer won't do autoremove
<hallyn_> (since it doesn't watn to step on toes)
 * pitti boots VM to check
<pitti> hallyn_: no, not installed (it's pretty much a stock utopic install with new shim and systemd only)
<pitti> hallyn_: I also get this when logging in a new user on tty1, checking with "loginctl", logging back out, and checking loginctl again under X
<hallyn_> pitti: running upstart?
<pitti> hallyn_: upstart
<pitti> hallyn_: so user-1001.slice/session-c2.scope cgroup does get removed
<pitti> hallyn_: user-1001.slice stays around
<hallyn_> pitti: can you set cgmanager_opts="--debug" in /etc/default/cgmanager, reboot the vm, and pastebin /var/log/upstart/cgmanager.log?
<hallyn_> oh, ok
<pitti> hallyn_: but it doesn't disappear from logind
<hallyn_> yeah,
<pitti> hallyn_: I think this might just be because the notify_on_removal callback doesn't work?
<hallyn_> that's actually bc the way desrt did it he made the slices not their own
<hallyn_> "thing"
<pitti> hallyn_: so I think that the cgroup itself is removed fine, just logind doesn't get to kknow
<hallyn_> oh, ok
<hallyn_> hm.  then yeah i guess we need stop.
<hallyn_> does logind need to get  JobRemoved ffor the StopSession?
<hallyn_> and, pardon my terminology - will it be a StopTransientUnit method?
<pitti> I also still have /run/systemd/sessions/c2
<hallyn_> yeah bc the logind upstart job created /run/systemd
<pitti> hallyn_: I don't know exactly, but I think that's just StopUnit
<hallyn_> or, no.
<hallyn_> ok
<hallyn_> pitti: I"ve promised to do some other things today, but will try to get to StopUnit asap
<pitti> hallyn_: it's not a big deal, it just caught my eye (as sessions will pile up in logind)
<hallyn_> desrt's code was so clean that at this point it should be pretty simple
<pitti> hallyn_: for now, this is working very nicely already, great work!
<pitti> hallyn_: it works well on the phone too, so we can certainly land that soon
<pitti> that == systemd 208 (and 214, which is being prepared in Debian)
<hallyn_> awesome :)
<hallyn_> well, here's teh sad part, i assume 214 will need a patch to systemd-shim
<hallyn_> bc somewhere between those the StartTransientUnit message format changed
<hallyn_> to add an (always empty) aux segmenet
<hallyn_> segment
<pitti> hallyn_: in the message signature?
<pitti> hallyn_: that would be fine, it could offer both signatures
<pitti> s/message/method/
<hallyn_> pitti: oh, ok - i dont' know how to do that, but cool.
<hallyn_> that's for the message from logind to systemd-shim, nto the other way around
<pitti> hallyn_: it just adds two methods, one with each signature (like in C++)
<pitti> hallyn_: but anyway, that's not critical for now; I think we first want to go to 208 as that's reasonably well tested in Debian already
<pitti> there's little reason to get ahead of Debian (even 204 is working well enough)
<hallyn_> cool
<mbiebl_> hallyn_, pitti: should I poke an ftp-master regarding cgmanager?
<pitti> mbiebl_: can't hurt, especially now that 208 is in unstable
<pitti> mbiebl_: I was quite surprised, doesn't this effectively break logind for every sysvinit user?
<mbiebl_> pitti: and thanks for the reminder regarding the session cleanup
<hallyn_> mbiebl_: maybe ping slangasek ?
<cjwatson> hallyn_: Steve isn't a Debian ftpmaster
<hallyn_> oh, i thought he was
<hallyn_> that is, i thought he said he was a few days ago.  mustve misunderstood
<cjwatson> hallyn_: https://www.debian.org/intro/organization#distribution
<cjwatson> he's an archive admin in Ubuntu
 * hallyn_ educates himself
<hallyn_> xnox: see debian bug 754910 - looks like the work we did yesterday may turn out in vain
<ubottu> Debian bug 754910 in wnpp "ITP: cgmanager" [Wishlist,Open] http://bugs.debian.org/754910
<mbiebl_> hallyn_: oh, luca just told me that both were kicked
<hallyn_> that's productive
 * hallyn_ grumbles and goes to do some btrfs coding for lxc
<pitti> hm, Daniel's upload was much older
<pitti> but hallyn filed the ITP, dbm's didn't even have an ITP
<pitti> both seem good reasons to take hallyn_'s *shrug*
<mbiebl_> grml
<hallyn_> I don't undestand why he'd want to go this route
<mbiebl_> it's not like daniel hasn't enough packages already...
<hallyn_> his is far too old to suffice for systemd-shim...
<hallyn_> oh well.
<pitti> so changing the owner back to hallyn_ and reuploading seems appropriate to me
<pitti> pwning someone else's ITP isn't exactly polite
<DktrKranz> the problem is daniel's upload predates the ITP
<hallyn_> replied to the itp
 * pitti sent a grumbling, but restrained followup too
<xnox> I'm failing at my command-line & emacs skills. I've downloaded an email in mbox format and now want to reply to it, how do I do that?
<pitti> DktrKranz: yes, but that's dbm's problem, not hallyn_'s
<pitti> that's what ITPs are for, so that other people know that you are working on something
<xnox> DktrKranz: he hasn't filed ITP.
<xnox> DktrKranz: and he is not the best maintainer of the two.
<hallyn_> xnox: usually 'mutt -f <file>' works, unless you need to re-add the From: line above each msg
<xnox> hallyn_: i've never used mutt =)
<pitti> $ cat ~/bin/mutt_open_mbox
<pitti> #!/bin/sh
<pitti> exec gnome-terminal -x mutt -f "$1"
<pitti> that's my handler in firefox for the "mbox" links in Debian bugs
<pitti> quite nice
<xnox> would that open emacs for me to type reply & email it via my smtp?!
<pitti> xnox: well, it's just an mbox -- any MUA should be able to read that?
<xnox> The program 'mutt' can be found in the following packages:
<xnox>  * mutt
<xnox>  * mutt-patched
<xnox> Try: sudo apt-get install <selected package>
<pitti> xnox: well no, it's calling mutt
<pitti> xnox: feel free to adjust to emacs, of course :)
<hallyn_> one of these days i want to spend a day using emacs for email.  just to get comfy with it
<hallyn_> (like i did with ed :)
<DktrKranz> xnox: I fully agree with both, but if we had accepted the package before hallyn_, we would have been lost anyway
<stokachu> bdmurray, ping
<loa> xnox, hello. Did you check that bug about degraded raid?
<xnox> loa: nope. Will do soon, working on mdadm 3.3 update.
<loa> xnox, with fixes for that?
<xnox> hallyn: pitti: i have also replied to that bug.
<loa> xnox, who are you? you dev from ubuntu?
<loa> work on mdadm looks very important.
<xnox> loa: nah, i'm nothing special.
<loa> but why always all go around you? :D
<xnox> loa: i simply idle on irc too much. that's all.
<loa> idle? Spending too much time here?
<xnox> pitti: hallyn: in the end, i've opened the mbox file in thunderbird and hit reply button =)))))
<hallyn> xnox: whatever works :)  the worst is when mail archive mbox files need to be massaged in perl before you can open them.
<xnox> hallyn: on my books "massaged in perl" is a rare fetish i have never participated in =)
<hallyn> missing out, dude :)
 * hallyn back to btrfs
<bdmurray> stokachu: hey
<achiang> hi, when doing an apt-get install of a package, i notice that during the installation, apt wants to remove another package (modemmanager), which is almost certainly a bug. how do i track down why this package is marked for removal?
<cjwatson> apt-get -o Debug::pkgProblemResolver=true, usually
<achiang> i mean, it's obviously a conflicts or something like that, but i can't figure out which new package is causing the conflict
<achiang> ah
<achiang> thx
<cjwatson> output is a bit opaque but for something like this it should be decipherable
<achiang> hm, no, that didn't seem to help - http://pastebin.ubuntu.com/7804018/
<cjwatson> urr.  at this point I'd either swear and break out grep-dctrl, or invoke mvo
<Laney> aptitude time ;-)
<roadmr> achiang: hm, ofono is in your list of packages to install, and it directly Conflicts: modemmanager
<seb128> achiang, you can try to "apt-get install ubuntu-sdk modemmanager" and see the output
<cjwatson> oh yeah, that's a good idea too
<seb128> but it's likely going to get down to what roadmr said
<achiang> roadmr: duh, i didn't see ofono in there.
<roadmr> achiang: -o Debug::pkgDepCache::AutoInstall=true will show you how ofono came to be in your list of packages to install
<achiang> thanks for the better eyes
<roadmr> achiang: :D glad my tired, squinty eyes could help :D
<achiang> roadmr: ah, that debug line is very helpful, thank you
<achiang> http://pastebin.ubuntu.com/7804068/
<achiang> lines 259, 260...
<smoser> anyone able to tell me what i'md oing wrong
<smoser>  http://paste.ubuntu.com/7804080/
<smoser> seems gpg --verify has race conditions in it.
<smoser>  http://paste.ubuntu.com/7804138/
<smoser> ^^ cleaned up a bit.
<sandstrom> Anyone know how I can find Boris Ostrovsky on irc? (https://launchpad.net/~boris-ostrovsky)
<mbiebl_> Noskcaj: hi, can you please prep a new release for xfce4-systemload-plugin for upower 0.99
<mbiebl_> all that seems to be missing is a dch -r
<mbiebl_> Please update svn accordingly and/or point me to a .dsc
<rbasak> dannf: your fix for 1324992 looks fine. I'll modify your changelog entry to 1.1.5-3ubuntu3.1 as well, shall I, and upload to Trusty, as Utopic and Trusty are currently identical?
<rbasak> (upload to Trusty also)
<Noskcaj> Could someone please retry django-celery? I think the build failure has been fixed by a newer version of celery that we now have
#ubuntu-devel 2014-07-17
<pitti> Good morning
<pitti> Noskcaj: python-dbusmock is fixed for upower now, FYI
<pitti> Noskcaj: django-celery built, so apparently someone quietly retried it already
<Noskcaj> pitti, good to know
<popey> â¹ bug 1314796 has broken my utopic chroot
<ubottu> bug 1314796 in cgmanager (Ubuntu) "[systemd] cgmanager needs systemd unit or init.d script" [Undecided,Triaged] https://launchpad.net/bugs/1314796
<apachelogger> mvo_: have you moved apturl functionality into the software center already? I am currently preparing kubuntu ports to qt5 and probably will move the kde side of apturl into muon, so as far kubuntu is concerned apturl will probably become unused in 15.04
<mvo_> apachelogger: yes, software-center can deal with the apturl stuff
<apachelogger> mvo_: groovy, we can probably consider retiring apturl then
<mvo_> +1 for that
<pitti> jodh: thanks for your patch in bug 1342586, I'll apply to git!
<ubottu> bug 1342586 in systemd-shim (Ubuntu) "[utopic] [proposed] cgmanager breaks lightdm login" [Undecided,New] https://launchpad.net/bugs/1342586
<pitti> jodh: what do you mean with "the packaging branch is out of date"?
<jodh> pitti: the systemd bzr branch is out-of-date
<pitti> oh, bzr
<pitti> jodh: how urgent do you think is this?
<jodh> pitti: the bugfix or the branch issue? :)
<pitti> jodh: I don't care about the bzr branch, I have an ubuntu branch in the debian systemd packaging git :)
<pitti> jodh: I mean the crash
 * pitti tries booting with systemd on utopic du jour
<jodh> pitti: well, it means you can't update very easily, so pretty important I'd say.
<pitti> jodh: booting with systemd works fine here, but right, lightdm not crashing is a bummer; I'll upload
<darkxst> hey pitti
<darkxst> how is dependencies.txt generated? see bug 1342923, which lists libglib2.0-0 2.40.0-2, but the retrace has "/build/buildd/glib2.0-2.41.2~git20140710.60fe7b46" from a ricotz ppa (which the retracer can't know about since its not listed in dependencies.txt)
<ubottu> bug 1342923 in Ubuntu GNOME "tracker-store crashed with SIGSEGV in _IO_vfprintf_internal()" [Undecided,New] https://launchpad.net/bugs/1342923
<pitti> darkxst: it's asking apt on the reporting system about the versinos
<darkxst> pitti, but is it getting the wrong version perhaps?
<darkxst> we have five retraces (for the same crash) that show a symbol from ricotz glib snapshot, but the retracer does not know about that ppa, since its not listed as an [Origin: /] tag
 * darkxst wonders, we have seen lots of failed retracers, with no real reason why, perhaps this is related, pitti?
<pitti> darkxst: that bug does have packages from the PPA in dependencies; does the PPA actually have a newer glib version?
<ricotz> pitti, hi, the reporters dependencies.txt refers to glib 2.40.0-2 which suggests only the gnome3-staging ppa is in use, but the trace mentions a snapshot version which happen to match the version i have/had in my ppa
<ricotz> (the gnome3-staging ppa doesnt contain a newer package glib)
<tseliot> pitti: hi, so, about this reverse dependency thing, bumblebee only "suggests" bumblebee-nvidia, which, in turn, depends on the nvidia drivers: https://lists.ubuntu.com/archives/ubuntu-release/2014-July/002955.html
<tseliot> pitti: a suggested dependency shouldn't really cause any troubles, should it?
<pitti> tseliot: no, we don't install them by default or consider them in component-mismatches/britney
<tseliot> pitti: so is that a false positive?
<pitti> Recommends: nvidia-prime (>= 0.5) | bumblebee
<pitti> tseliot: so supposedly a bug in component-mismatches then
<tseliot> pitti: ok, thanks
<xnox>  cjwatson: just noticed https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1274320 when working on mdadm update. Is there anything that can/should be done to resolve this?
<ubottu> Ubuntu bug 1274320 in grub2 (Ubuntu) "Error: diskfilter writes are not supported" [High,Triaged]
<xnox> e.g. I just did a stock raid1 mdadm install and ideally i wouldn't be seeing such messages on boot.
<dannf> rbasak: sure, that'd be great (1324992 -> trusty)
<rbasak> dannf: done already :)
<cjwatson> xnox: I have a patch in my Debian inbox which I think will quieten that
<xnox> cjwatson: \o/ cool.
<Guest71295> hi, I am trying to port ubuntu to powerpc 32 bit little endian.  Am I in right place to ask question?
<Guest71295> Does any one know what debian arch name for PowerPC 32 bit little endian?
<cjwatson> I'm not sure one has been assigned, though my guess would be powerpcel.  It would be necessary to work with the Debian dpkg maintainers as pretty much the first step
<Guest71295> thanks cjwatson!  That's what I thought and currently using it.  I sent email to Debian dpkg maintainer (3 of them) and I haven't gotten a message yet.
<cjwatson> Yeah, nothing in dpkg.git
<cjwatson> Right, but you'll have to wait for that first.  No point doing a bunch of work and then having to redo it all.
<Guest71295> OK.  I will wait for the "confirm" message then.   I would be better to work on something else then. (such as porting xbuilder which seems ceased to support Trusty)
<Guest71295> Anyway, I don't have a machine (power8 or so) yet, so I have finished test build powerpc64le multilib with Cross Linux From Scratch, and I am trying to finished
<Guest71295> my work with my favorite linux distro, ubuntu.
<Guest71295> well, anyway, thank you cjwatson. I will come back if there is any standout progress.^^
<hallyn_> stgraber: cgmanager appears to be stuck in utopic-proposed.  but it passed jenkins.  how do i tell why it's hung up?
<cjwatson> hallyn_: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#cgmanager
<cjwatson> lxc autopkgtest regression
 * hallyn_ notes that url
<hallyn_> cjwatson: thanks
<hallyn_> interesting.
<hallyn_> stgraber: these look like what pitti was pinging you about the other night;  i somehwo thought you'd resolved them - https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-lxc/lastBuild/ARCH=amd64,label=adt/console
 * doko shouldn't do a test build with nocheck and introduce a typo in the check code :-/
<xnox> =))))))) happens.
<hallyn_> cjwatson: d'oh, i bet the lxc failure was due to the same kernel cgroup kernel bug as the cgmanager test was
<achiang> stgraber: i'm about to start investigating what it might take to create a deb that would automatically setup an LXC container + other bits. is there any prior art i could look at?
<ogra_> achiang, like lxc-android-config ? :)
<achiang> stgraber: my first thought is to stick a lot of manual setup stuff into the maintainer scripts
<achiang> ogra_: good pointer, i'll take a look at that one
<ogra_> (it does exactly that)
<ogra_> we rely on unpacking the rootfs in initrd thuogh ... you would have to do that bit somewhere else for yours
<ogra_> (the container rootfs that is)
<achiang> ogra_: my use case is to create a metapackage that encapsulates a utopic lxc container and holds the ubuntu-sdk bits inside, for deployment on trusty
<hallyn_> stgraber: yeah, lxc-test-unpriv fails with the utopic-release kernel (3.16), passes with 3.15, so i assume it's the cgroup-rmdir that's failing;  presumably the ubuntu upstream kernel will also allow it to pass (will test in a minute)
<hallyn_> stgraber: anything we can do to let lxc promote anyway?  i suppose i need to find the kernel patch that caused this and try to get it cherrypicked? :(
<hallyn_> hm, i'll see which rc fixes it at least
<ricotz> doko, hi, seems like graphviz isnt initializing the plugins after upgrading, it refers to libgvc5-config-update rather then libgvc6-config-update in postinst and postrm
<doko> ricotz, ok, looking
<doko> ricotz, fixed in proposed
<hallyn_> stgraber: d'oh.  found the cause of the lxc test failures in jenkins
<hallyn_> sending a patch to m-l in a min
<hallyn_> hm, this might be a contender for worst commit msg ever, but here goes
<hallyn_> stgraber: please ack and push as quickly as possible, and we should get it into utopic-proposed asap to get jenkins to pass
<ricotz> doko, thanks
<achiang> stgraber: in your blog, why do we need to install things like ubuntu-artwork and dmz-cursor-theme? https://www.stgraber.org/2014/02/09/lxc-1-0-gui-in-containers/
<hallyn_> bc #unicorns
<achiang> hallyn_: was that addressed to me? or is that some weird irssi command? :)
<hallyn_> achiang: to you :)
<achiang> hallyn_: ha. ok, but... i don't get your joke. (it's a joke, right?)
<hallyn_> unicorns, pretty artwork...  sorry.  i'll leave now
<hallyn_> ok i'm going to push those two patches to git and to utopic
<hallyn_> cjwatson: xnox: what is "utopic-release"?  is that for things which are held back by jenkins failures?  or a synonym for -updates?  or what?
<hallyn_> (new lxc pushed, hopefully that will unblock cgmanager 0.27)
<stgraber> achiang: mostly so things don't look bad :)
<Chipaca> is there a way to specify, in a control file, that a package depends on the same version of another package that is built from the same source?
<stgraber> achiang: I believe that was mainly visible with steam
<stgraber> achiang: and possibly also relevant to skype if you want it to look like a gtk app
<achiang> stgraber: ah, ok. i mean i was wondering... if you're using chrome in a container, why do you need a wallpaper?
<achiang> stgraber: but anyway, makes sense, thanks
<Noskcaj> Host can i make infernal not attempt to build on i386?
<Noskcaj> *how
<Noskcaj> Since not all i386 machines have SSE2, the debian maintainer has set binaries to only build on amd64, but us building arch: all on i386 means it attempts to build there
<xnox> hallyn_: "utopic" is ambigious. on archive.ubuntu.com/ubuntu/dists/ we have 4 suites - "utopic", "utopic-updates", "update-proposed", "utopic-security". However on launchpad those map to utopic series with - "releae", "updates", "proposed", "security" /pockets/
<xnox> hallyn_: britney / proposed migration is as follows - all uploads are redirected into "utopic-proposed" from where they migrate to "utopic" (aka utopic-release) if are installable and adt tests pass.
<xnox> hallyn_: updates and security pockets are only opened after series becomes stable, at that time "release" pocket is frozen ("utopic" suite on the archive.ubuntu.com).
<xnox> hallyn_: more about proposed migration is on https://wiki.ubuntu.com/ProposedMigration
<xnox> hallyn_: on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#cgmanager you will be able to track if new lxc unblocks things.
<xnox> hallyn_: the new lxc is still building and hasn't been tested yet =)
<hallyn_> xnox: d'oh, i see.  so -release is a synonym for just 'utopic' bc it's devel release.  sorry, i was being a moron
<stgraber> achiang: note that it's "ubuntu-artwork" not "ubuntu-wallpapers" (though I suspect it pulls that latter in). So that's the combination of icon themes, gtk themes, ... that make Ubuntu looks like Ubuntu
<hallyn_> thanks
<achiang> stgraber: ack
<achiang> i was sloppy in my comment
<xnox> hallyn_: yeah, terminology is fuzzy =)
<hallyn_> all right while i wait for that i can finally look at the StopSession for systemd-shim
<achiang> stgraber: if i am in an lxc environment, is there some issue with loading libraries outside of standard LD_LIBRARY_PATH? i have put the ubuntu-sdk in a container and am trying to build my app, which builds a shared lib in a local dir. upon trying to test, i get an error about not being able to load it
<stgraber> achiang: I can't really think of anything special there. LXC doesn't do any fancy ld configuration or anything.
<achiang> stgraber: hm, must be something else then.
<achiang> stgraber: i'll keep digging, thanks
<achiang> stgraber: ABI mismatch of sorts. i had built the lib outside the lxc on trusty host, then attempted to run a QML app inside the utopic lxc
<achiang> stgraber: rebuilding inside utopic lxc fixed everything :)
<stgraber> achiang: good to hear lxc wasn't to blame :)
<achiang> stgraber: i'm sure that 90% of the time when i touch something and it breaks, for me specifically it can be root caused to pebkac ;)
<stgraber> :)
<achiang> stgraber: anyway, my little adventure with lxc is proving fruitful. lxc-izing the ubuntu-sdk helps minimize the dev pain if a user wants to stay on utopic
<achiang> sorry
<achiang> if a user wants to stay on trusty
<achiang> but target utopic
<achiang> stgraber: i haven't got there yet, but there will be bits that will require unity8 hosting inside lxc on trusty... i understand you're working on something like that. so when you're off holidays, maybe i can ping you
<stgraber> achiang: right, christownsend and I have been working on running a whole unity8 session inside LXC on trusty. I've heard some progress have actually been made on that today though I'm still waiting for the details.
<lifeless> has anyone else see reschedules not happenign
<lifeless> like, when it should happen it goes nowhere
<lifeless> state BUILD task -
<mwhudson> lifeless: mischan?
<mwhudson> if not i have no idea what you mean :)
<Noskcaj-school> Can someone please retry the kanla build in utopic? It should work now.
<lifeless> mwhudson: yup
<lifeless> mwhudson: openstack foo
<lifeless> sorry
<cjwatson> Noskcaj-school: retried
<mwhudson> lifeless: heh nw
<UserError> What is with the signon-ui/signond dependencies?
<UserError> I mean really.
#ubuntu-devel 2014-07-18
<hallyn_> xnox: so now lxc passed jenkins;  cgmanager is still listed as blocked;  does someone need to manually hit a switch, or will this resolve itself?
<cjwatson> hallyn_: should catch up automatically
<cjwatson> you'd think
<cjwatson> yeah, I *think* it will, the master job apparently only finished 13 mins ago
<hallyn_> ok thanks :)
<cjwatson> I: [Fri Jul 18 00:28:01 2014] - Collected autopkgtest status for lxc_1.1.0~alpha1-0ubuntu2/cgmanager_0.27-0ubuntu7: PASS
<cjwatson> looks good
<cjwatson> yep, it's migrating
<hallyn_> \o/
<hallyn_> that should ease things for folks wanting to run systemd
<hallyn_> or something
<hallyn_> i forget what the problem actually was
<cjwatson> sarnold: Have you had any luck with the librevenge MIR?  This is one of the approximately two remaining things blocking the giant libav (etc.) transition, and I think I just made a start at unblocking the other one
<sarnold> cjwatson: not yet, still handling the emergency dialer merges
<cjwatson> OK
<sarnold> cjwatson: I expect to start the librevenge review tomorrow; depending upon how large it is, either finish tomorrow night or monday
<cjwatson> Great, thanks.  We probably can't land the other piece until Monday anyway
<cjwatson> (Always assuming that the gallery-app people don't hate my patch)
<sarnold> hehe
<slangasek> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: slangasek
<achiang> hallyn_: stgraber: have you guys seen a hugetlb error when creating a new lxc container? https://pastebin.canonical.com/113772/
<achiang> oops, that is canonical.com pastebin... one sec
<achiang> http://pastebin.ubuntu.com/7812203/
<hallyn_> achiang: cat /proc/self/cgroups, are you in a cgroup you own?
<achiang> hallyn_: that error goes away after a reboot suggesting that something in the installation process is weird
<hallyn_> my guess would be the login was done before systemd-login0 or systemd-shim was installed (depending on release), so you didnt' have your own cgroup;  then you installed those, rebooted, logged in, and got a cgroup you owned
<achiang> hallyn_: hm... ok, i suppose i could investigate that hint. ftr, this is the exact script i'm using -- https://gist.github.com/achiang/70fb462d27af75be2794
<achiang> hallyn_: it dies on line 86 for at least 1 other person; then restarting the PC, it picks up from there and seems to be ok
<hallyn_> achiang: yeah - systemd-services gets installed there on line 6
<achiang> hallyn_: right...
<hallyn_> hm, no wait
<achiang> hallyn_: um. should it be installed earlier or something?
<hallyn_> how is this script used?
<hallyn_> user-data?
<hallyn_> it looks like you're running the script as a user ($HOME, etc) but you're doing apt-get without sudo
<achiang> hallyn_: it's meant to be run as a normal user with sudo privs, and it's meant to automatically create an LXC container for a piece of software (ubuntu-sdk)
<hallyn_> is it meant to be run under sudo?
<achiang> yes
<hallyn_> ok, then (a) verify my theory by doing a 'cat /proc/self/cgroups' before the lxc-start,
<hallyn_> and then (b), if that's verified, then you can just add
<hallyn_> apt-get install cgmanager-utils; cgm create all $(logname);  cgm chown all $(logname) $(loguid) $(loggid);  cgm movepid all $(logname) $$
<hallyn_> (subsituting loguid and loggid with something real)
<achiang> hallyn_: ok, i'll ahve to chase this tomorrow on a fresh VM since things already work here for me
<achiang> hallyn_: good hints, thank you
<hallyn_> np - good night
<slangasek> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
 * Elbrus is looking for the procedure to request a transition.
<Elbrus> Debian transitions gnustep, I think it is wise if Ubuntu followed
<Elbrus> s/transtions/transitioned/
<RAOF> Elbrus: There isn't really an equivalent procedure.
<Elbrus> ah
<RAOF> At least as far as I know :)
<Elbrus> how is the transition tracker filled then?
<RAOF> Automatically, I believe.
<Elbrus> http://people.canonical.com/~ubuntu-archive/transitions/
<Elbrus> aha
<RAOF> If gnustep is in Sid, though, we'll automatically go through that transition when it's autosynced.
<RAOF> Unless it's got Ubuntu changes.
<Elbrus> which it is not, because it has ubuntu specific changes...
<Elbrus> yes
<Elbrus> so I will need to look into that
<Laney> Nah, those things are created manually
<Elbrus> apperently the last time Ubuntu didn't fare well on gnustep transition (if I am to believe the Debian maintainer)
<Elbrus> Laney: so how to request one similar to https://release.debian.org/transitions/html/gnustep.html
<Laney> I'll make one for you
<Laney> You going to handle the rebuilds/porting/whatever?
<cjwatson> "last time" - when was that?
<Elbrus> 10.04 if my memory of last tuesday serves me right
<cjwatson> I remember doing some work on a gnustep transition a while back, I don't remember it going particularly badly
<cjwatson> oh, that was long before we implemented proposed-migration
<cjwatson> nowadays p-m (basically the equivalent of Debian's unstable->testing) means that we tend to notice such things
<Elbrus> let me look up the bug I was thinking of
<cjwatson> the Debian maintainer is probably out of date on our processes
<cjwatson> however, could you please wait?
<cjwatson> I'm terrified of anything else getting tangled up with the gigantic libav transition before we finish it
<Elbrus> https://bugs.launchpad.net/ubuntu/+source/systempreferences.app/+bug/561920 and it's four brothers
<ubottu> Ubuntu bug 561920 in systempreferences.app (Ubuntu) "SystemPreferences crashed with SIGSEGV" [Medium,New]
<Elbrus> waiting no problem
<cjwatson> I hope we'd probably have noticed that class of things nowadays, although the bug suggests that the package dependencies were inadequate if it managed to start but not crash, so maybe not.
<Elbrus> actually, I am currently helping updating the gnustep stack, so when that is done in Debian a transition might be right time..
<cjwatson> However, transition trackers normally just look at dependencies, so how much that will help ...
<cjwatson> Elbrus: Chances are we'll auto-sync the start of the transition, if it's reasonably soon, and then notice.
<Elbrus> cjwatson: don't think so as there are ubuntu specific changes
<Elbrus> might be good to block fixing that somehow then...
<cjwatson> libav should be done next week, so probably not a problem.
<cjwatson> Certainly if Laney feels inspired to set up a transition tracker then great.
<Laney> Elbrus: can you adjust http://paste.ubuntu.com/7813325/ to taste?
<cjwatson> Incidentally, the reason we don't have much of a transition request procedure is that many of our transitions arrive by auto-sync from Debian, so it would be somewhat futile :)
<Elbrus> cjwatson: ack
<Elbrus> but how are "binNMU's" handled then in Ubuntu?
<cjwatson> Manual rebuild-only uploads
<cjwatson> (sadly)
<Elbrus> Laney: I believe the libobjc[34] stuff is really old and not relevant anymore
<cjwatson> I suspect I do the vast majority of them and I have some scripting for it so it doesn't take too much of my time
<Elbrus> ah, how sad ;)
<cjwatson> One of these days I'll implement binNMUs in Launchpad and persuade people to take it
 * Elbrus doesn't have the permissions to do those, so they will all need acknowledgments from motus
<cjwatson> If it's on a transition tracker I can just do them in bulk, not a problem
<cjwatson> Rather than faffing about getting approval
<Elbrus> (or me should finally apply for motu status)
<Elbrus> ok, cool...
<Elbrus> mind you, holidays are near, it might shift to after my holidays (not much time/internet combi available).
<cjwatson> will be much easier if it can be before our Debian import freeze for 14.10 on 7 Aug
<Elbrus> hmm, I'll see what I can do
<cjwatson> thanks
<Elbrus> Laney: http://paste.ubuntu.com/7813472/
<Elbrus> seems like Ubuntu already has the base part, so only gnustep-gui is required
<Elbrus> cjwatson: the Ubuntu diff is already incorporated in Debian, should I request a cync now, or wait until after libav?
<Elbrus> s/cync/sync/
<cjwatson> Elbrus: Let's wait
<Elbrus> ack
<Laney> Elbrus: kay, I pushed that as a "planned" transition
<Laney> Should show up at http://people.canonical.com/~ubuntu-archive/transitions/ soon
<Elbrus> cjwatson: how do I see (without me guessing) when you are done with the libav transition?
<cjwatson> Elbrus: on https://launchpad.net/ubuntu/+source/libav, the "6:10.2-1" entry will move to "release" rather than "proposed"
<Elbrus> ack
<mapreri> pitti: all the ubuntu deltas in scribus are now merged in debian. Do you mind sync scribus for me? :)
<R33D3M33R> hello: big problem after todays upstart upgrade -> cannot login anymore, please check: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1343800
<ubottu> Ubuntu bug 1343800 in upstart (Ubuntu) "upstart 1.12.1-0ubuntu4.1 breaks xsession start with lightdm" [Undecided,Confirmed]
<cjwatson> R33D3M33R: we already published 1.12.1-0ubuntu4.2 to fix that
<R33D3M33R> great,t hanks!
<cjwatson> R33D3M33R: can you try that and confirm?
<cjwatson> R33D3M33R: if that fixes it, please mark your bug as a duplicate of bug 1343905
<R33D3M33R> just a second
<ubottu> bug 1343905 in upstart (Ubuntu Trusty) "Empty desktop in Xubuntu 14.04 on reboot after upgrading upstart package" [High,Fix committed] https://launchpad.net/bugs/1343905
<R33D3M33R> sorry, I cannot upgrade since the repo I use, isn't synced yet, but judging by the symptoms the bug is really the same
<R33D3M33R> found files, installed, rebooted, logged in with no problems -> marking as duplicate
<cjwatson> R33D3M33R: thanks
<barry> pitti: around?
<smoser> xnox, you had some primer about packaging for systemd i think ?
<smoser> some doc. and how to enable it. which i thought was differen tthan https://wiki.ubuntu.com/systemd
<smoser> hm..
<smoser> stgraber, around ?
<xnox> smoser: dh $@ --with systemd
<xnox> smoser: and drop units into debian/*
<smoser> didy ou have some doc ? i swear i saw something.
<xnox> smoser: there is this https://wiki.ubuntu.com/SystemdForUpstartUsers
<xnox> smoser: but it doesn't cover packaging
<smoser> xnox, thanks
<stgraber> smoser: yep
<smoser> would you expect http://paste.ubuntu.com/7814920/ to work
<smoser> stgraber, ^
<smoser> er... what i am trying to do is replace upstar twith systmmed
<smoser> in the download container uptoic
<stgraber> smoser: the apt-get install should succeed, now I doubt the container will start because systemd is silly and usually tries to mount some pretty scary stuff which gets rejected by apparmor and make it hang
<stgraber> smoser: we'll have to come up with either some patches to systemd for that or maybe a variant of the container config that includes the few more bits that are needed
<smoser> hm.
<smoser> yeah. the apt-get install does work
<smoser> but yeah, it hangs basically no boot
<stgraber> smoser: you may want to look at e.g. the fedora config in /usr/share/lxc/config/ to see what kind of stuff may be needed. Also setting lxc.aa_profile = unconfined will help as a first step
<smoser> stgraber, hm..
<stgraber> oh and there's no chance that this would work in an unprivileged container because systemd currently just crashes if you try to start it in there (and yeah, we need to figure out a solution for that soon...)
<smoser> dont care about unpriv
<smoser> at the moment
<smoser> but this will be expected to work at some point
<smoser> obviously when /sbin/init == systemd
<smoser> i was looking at cloud-images systemd
<smoser> and ifgured it'd be easier to try first with lxc
<smoser> (or at least faster)
<smoser> but maybe i'll have more success looking first at kvm
<smoser> i wanted to get a baseline working thing to look at.
<stgraber> yeah, I'd expect kvm to be easier as that's what everyone's been using to test systemd so far :)
<LocutusOfBorg1> can anybody please sponsor this?
<LocutusOfBorg1> https://bugs.launchpad.net/ubuntu/+source/gccxml/+bug/1344039
<ubottu> Ubuntu bug 1344039 in gccxml (Ubuntu) "Sync gccxml 0.9.0+git20140716-1 (universe) from Debian unstable (main)" [Undecided,New]
<LocutusOfBorg1> this will (hopefully) fix the insighttoolkit4 problems in ubuntu
<LocutusOfBorg1> and the new insighttoolkit4 is going to be uploaded in debian tomorrow I think
<LocutusOfBorg1> so would be nice to see it building ;)
<LocutusOfBorg1> thanks!
<loucura> Hi! Is any Ubuntu developer aware of this critical ubiquity bug: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1265192 ?
<ubottu> Ubuntu bug 1265192 in ubiquity (Ubuntu Trusty) "Install/reinstall wipes out all/other partitions" [Critical,Triaged]
<loucura> It's causing people to lose data when installing Ubuntu.
<loucura> And the 1st point release for Trusty is coming very soon, so fixing this before that would be great (and there's a workaround/fix provided in the comments).
<hallyn_> pitti: ok, so looking into stopping user sessions for systemd-logind;  first off, utopic still has systemd-204, which actually isn't utilizing systemd-shim at all i don't think;
<hallyn_> pitti: when i use systemd-208, i have to edit /etc/systemd/logind.conf to set KillUserProcess=yes before StopUnit is sent;  in the other code path, unfortunately, it uses org.freedesktop.systemd.Scope method Abandon
<Unit193> hallyn_: Tried shim/cgmanager to see how it'd work (I'm using 214+a few backports in trusty), had to enter password on hitting shut down, and suspend/hibernate were greyed out.
<hallyn_> Unit193: 214??
<hallyn_> where did you get the packaging for that?  ported from 208?
<Unit193> Uhh, forget I said that and pretend I said 208? ;)  (Pulled from Debian experimental VCS and added most of the Ubuntu delta.)
<hallyn_> Unit193: ok, i would drop the ubuntu delta (that's what i'm doing here), just do the following:
<hallyn_> 1. set the Depends on libpam-systmemd from "systemd-sysv" to "systemd-sysv | systemd-shim",
<hallyn_> 2. somehow arrange to create /run/systemd at boot,
<hallyn_> 3. arrange for dbus-send --system --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.StartServiceByName string:org.freedesktop.login1 uint32:0 to be done at boot,
<hallyn_> and finally
<hallyn_> 4. edit /usr/share/dbus-1/system-services/org.freedesktop.login1.service to set Exec=/lib/systemd/systemd-logind
<Unit193> #1 is part of the delta.  And, alright.
<hallyn_> yeah, but the systemd-204 delta is huge :)
<hallyn_> and i'm sure we'll want to keep some of that in the end, but a lot of it we won't
<hallyn_> mind you im' doing this in a server vm, so i'm not dealing with any of the desktop side effects - so what i'm saying may not help you, but a smaller delta makes it easier to talk to debian and systmed folks
<Unit193> Right, I mostly went with what made sense for me to have (cgmanager support patches I didn't need, so dropped.)
<hallyn_> perhaps i should push a proposed package to ppa to work from
<achiang> hallyn_: stgraber: is there a way to pass a command line env var to a command while using lxc-attach?
<achiang> CMD_LINE="QML2_IMPORT_PATH=$LIBDIR qmlscene telegram.qml"
<achiang> lxc-attach --clear-env -n ubuntu-sdk -- sudo -u ubuntu -i cd `pwd | sed 's/achiang/ubuntu/'` && $CMD_LINE
<achiang> gives an error
<Unit193> hallyn_: http://paste.openstack.org/show/ZmJflIQxnlkQLxYaLWpV/ isn't so bad.
<achiang> oh, maybe i'll try setting that before the cd
<hallyn_> achiang: i don't understand the question :)  you want to clear the env but set one particular variable?  Simples might be to just have a script clear env, set what you want, then call lxc-attach
<achiang> hallyn_: actually, i think i figured out the rune i need
<hallyn_> Unit193: I'm going to set up a utopic desktop vm to play with this some more
<hallyn_> achiang: excellent :)
<hallyn_> Unit193: but first i'm going to push something to ppa so i can talk with others more sensibly
<Unit193> hallyn_: Good plan!   Have fun!  I have mine pushed to a PPA, if you want to have a strange starting point. :P
<hallyn_> Unit193: yours being based on 214?
<hallyn_> (http://paste.openstack.org/show/ZmJflIQxnlkQLxYaLWpV/)
<Unit193> Of course.
<hallyn_> hm, lemme start with 208, then perhaps update to yours for a test - which ppa?
<Unit193> /notice
<achiang> hallyn_: with lxc-attach, can it only run a single command inside the container? i have something that looks like this: lxc-attach --clear-env -n ubuntu-sdk -- sudo -u ubuntu -i cd `pwd | sed 's/achiang/ubuntu/'` && ./build.sh
<achiang> the && ./build.sh is getting run outside the container
<achiang> i think this is probably an issue with my bash quoting
<achiang> let me stick quotes around that...
<hallyn_> yeah, and maybe even "( cmd && cmd )"
<hallyn_> let us knwo what exactly you find works, that'llb e instructive
<hallyn_> note you can also just write a python function and call it using the lxc python api's attach :)
<achiang> ugh, no likey bash quoting
<hallyn_> achiang: sudo lxc-attach -n u1 -- bash -c "ps -ef && echo $?"
<hallyn_> worked for me
<achiang> let me try
<achiang> hallyn_: success. thanks!
<hallyn_> \o/
<achiang> 2014 and we're still fighting the shell
<hallyn_> plars: hey, so this could relate to the trouble you've been having;  i just installed a utopic vm from the desktop install dvd, and the final shutdown is not finishing.
<hallyn_> (note that never happens to me with installs from the netboot iso)
<plars> oh?
<plars> well, get this
<plars> today - it passes
<plars> mostly
<plars> a lot better than it used to at least
<plars> psivaa has been playing with it today
<plars> we have no idea what made it start working though
<plars> trusty and utopic both
<plars> maybe something changed in the images and this was a legitimate bug we were hitting?
<plars> I have no idea
<hallyn_> sigh.  but this is not even using preseed - it's just hanging on the 'stopping crypto disks'
<hallyn_> yeah, bug in eitghe rkernel or installer?
<hallyn_> lemme ctrl-c and see if it boots up now
<plars> maybe, yeah
<plars> best guess so far is that /target wasn't unmounting at the end, and we were getting a good run of grub
<hallyn_> booted up fine
<hallyn_> yes, that sounds plausible
<hallyn_> so anyway my vm is good.  and yeah that'll wreak havoc on any install automation
<hallyn_> wonder if the same happens with trusty iso
<hallyn_> cjwatson: (or whoever) - building systemd-208 fails due to a set of #includes (attr/xattr.h and sys/xattr.h) that are not getting along;  i've been working aroudn it locally by putting '#ifndef XATTR_CREATE' around the sys/xattr.h XATTR_CREATE blob, and copying that blog into attr/xattr.h
<hallyn_> (see https://launchpadlibrarian.net/180250815/buildlog_ubuntu-utopic-amd64.systemd_208-6ubuntu1%7Eppa1_FAILEDTOBUILD.txt.gz)
<hallyn_> i'm not sure what the best way to resolve this is
<hallyn_> maybe i shoudl take the weekend to clear my head and fix it whatever way seems cleanest then...
<hallyn_> well, for now i'll push packages with the dumb fix to my ppa i guess
<cjwatson> hallyn_: Sounds like a libc thing - you probably want infinity
<hallyn_> ok, will wait.  really one could argue it's all my own fault as i'd tried to address this in kernel+libc upstream a few months ago, and obviously didn't fully fix it.
<hallyn_> i'm putting the lazy fixes into ppa:serge-hallyn/systemd for now
<sarnold> slangasek: the new shadow package mterry uploaded has some quilt patches that apply with fuzz during build: https://launchpadlibrarian.net/180235013/buildlog_ubuntu-utopic-amd64.shadow_1%3A4.1.5.1-1.1ubuntu2_UPLOADING.txt.gz -- I thought the quilt patches had to be perfect or the build would fail. what am I missing?
<Laney> sarnold: That limitation is for source format 3.0 (quilt) packages - this one is format 1.0 and driving quilt itself (via cdbs)
<sarnold> Laney: ah! so what-patch lies :)
<Laney> if it says quilt then that's not a lie
<Laney> maybe it could differentiate between quilt and 3.0 (quilt) though
<sarnold> Laney: ah perhaps it already does and I didn't know how to read it ;)
<sarnold> Laney: thanks :)
<sarnold> slangasek: Laney answered, feel free to ignore ;) thanks
<Laney> I don't blame you for finding the slightly different implemtations of quilt confusing. :)
<sarnold> Laney: hehe, I wonder how many times I've worked with a similar package without even noticing :)
<sarnold> It was just a worry that I had screwed up somehow and got fuzz locally when there sholdn't have been any in The Real Package..
<Laney> It's probably good practice to defuzz a patch anyway
<sarnold> it's in 'shadow', what could go wrong? :)
<mterry> I don't think *I* caused the fuzz, but yeah, I didn't notice it was fuzzed in order to defuzz
<xnox> "In this situation, gzip /dev/inside to deflate, then pipe the compressed air to /dev/input to clean your keyboard. Avert your eyes when you do."
<xnox> awhhhhh =) if only that was true =)
#ubuntu-devel 2014-07-19
<saiarcot895> If there is a arch-dependent  package that depends on an arch-indep package (like foobar-common), should the arch-indep package have Multi-Arch: foreign?
<cjwatson> saiarcot895: Maybe; what's important isn't whether it's architecture-independent, but whether it provides architecture-independent interfaces
<cjwatson> The answer is usually yes, I just don't want to give a categorical yes because there are edge cases :)  read the spec
<saiarcot895> cjwatson: If the package is just a metapackage, then that would be a more-likely yes?
<cjwatson> saiarcot895: are you sure you mean metapackage there?
<cjwatson> it would be unusual for a -common package to be a metapackage (i.e. contain only dependencies)
<saiarcot895> cjwatson: no, these are two separate cases
<cjwatson> metapackages - maybe, although usually not much depends on metapackages so it doesn't really make a lot of difference
<cjwatson> and normally you won't actually be able to install a metapackage from a foreign architecture since the stuff it depends on will need to be native, so its main benefit would be if you were trying to cross-build something that build-depends on a metapackage
<cjwatson> which is pretty rare
<saiarcot895> true
<Elbrus> is there a way to get to the files in a (failed) build? the gnustep-base package is failing (for different reasons on different archs) but maybe config.log can yield some information for the ppc archs
<cjwatson> Elbrus: I'm afraid they're deleted after the build
<cjwatson> Elbrus: Make your package cat config.log if configure fails?
<cjwatson> e.g. ./configure ... || { cat config.log; exit 1; }
<cjwatson> Elbrus: In fact, dh_auto_configure does that automatically, so perhaps you should upgrade to that
<cjwatson> Elbrus: I thought I asked not to start the transition until libav was ready?  Fortunately it doesn't seem to have intersected that yet ...
<Elbrus> cjwatson: gnustep-base is not part of the transition...
<Elbrus> unless I am mistaken...
<cjwatson> Ah
<Elbrus> it is only gnustep-gui that needs the transition
<Elbrus> I thought to get the rest in shape
<Elbrus> well, and gnustep-back can only be done after gnustep-gui...
<fabio__> hi
<fabio__> sorry you can put in the context menu of the option will format a pendrive? and maybe even disassemble? as it was before 14:04?
<fabio__> sorry my english..
<Elbrus> can somebody tell me why gnustep-base on i386 was suddenly rebuild (and more important, why it succeeded without changes AFAICT)
<Elbrus> is somebody working on it?
<Elbrus> than I better stop with my proposal...
#ubuntu-devel 2014-07-20
<msx> hi, i know this question isn't specifically about upcoming ubuntu but I can't find the answer anywhere, not in the web not in #ubuntu - albeit i didn't tried on the mailing lists yet - so here it goes: how do i activate unity screen lock from command line?
<darkxst> msx, you would need to use dbus
<darkxst> not 100% sure, but I think unity uses org.gnome.screensaver Lock()
<msx> darkxst: hi! I was suspecting that as I just found that the service responsible for locking the screen is called ubuntu-panel-service
<msx> darkxst: will lock that way, thank you :)
<darkxst> msx, see gdbus call
<msx> hmm, didn't know about it, will definitely give it a read, thanks again :D
<TJ-> msx: "dm-tool lock"
<msx> TJ-: trying...
<msx> weeee!!!
<msx> darkxst: TJ-: thanks!!
<soze123> I couldn't find any information about unity panel applet api for C, does anyone happen to know?
<Taggg> where are the gtk logs in ubuntu?
#ubuntu-devel 2015-07-13
<micahg> robert_ancell: hi, I just wanted to let you know that I was already working on the merge of lintian in case you added it to your list
<robert_ancell> micahg, no, wasn't doing any merging. Just sick of lintian whining at me that wily didn't exist :)
<micahg> ok, thanks
<pitti> Good morning
<pitti> jamespage: python-swiftclient in -proposed seems to have dropped its autopkgtest, why?
<pitti> (nothing in the changelog)
<infinity> pitti: Bah.  My systemd update was missing a piece.  Just noticed on a fresh install.
<pitti> infinity: ah, from initramfs? or udeb?
<infinity> pitti: udeb is fine, initramfs, however, needs 70-persistent copied or I just renamed everyone. :P
<pitti> oh, whoops :)
<infinity> La la la.
<pitti> infinity: why does this need to happen in initramfs in the first place?
<pitti> we never did, AFAICS, and let udevtrigger sort it out?
<pitti> it seems okay to do it in initramfs as well, but that's entirely new
<infinity> pitti: It needs to match in initramfs and the real system, if you want people to have a hope of consistency.
<infinity> pitti: I guess I could see the inverse argument for initramfs not doing either method and people just hoping that eth0 is a thing.
<pitti> infinity: but it never did so far, if we never copied 70-persistent to initramfs
<infinity> pitti: So, we can either back out my bits entirely, or I need to copy 70-persistent, but the current state is broken.
<infinity> pitti: I was going to go for the copying, so it's consistent at both points in the boot.
<pitti> infinity: right; as I said, I think it's fine to copy 70-persistent too, but having non-kernel interface names in initramfs apparently has never bothered anyone so far
<infinity> pitti: Yeah, it's not bothered anyone before, I imagine, because it mostly matched the running system, except for weird cases where people intentionally rename out of detection order.
<infinity> pitti: And, honestly, very few people make use of initramfs networking features.
<pitti> right
<pitti> just about the only thing I can think of is open-iscsi
<infinity> Anyhow, I think it's probably sane to just make them match.
<infinity> So, I'll do that.
<pitti> agreed
<infinity> pitti: Good thing I installed from vivid and upgraded instead of using a wily daily...
<infinity> pitti: Tested and uploaded.
<infinity> ... and confused by the lack of gpg agent in my fresh install.
<pitti> infinity: oh, you too? I have that too since today
<pitti> i. e. probalby since yesterday's dist-upgrade
<infinity> Ahh, so it's new, not something I did wrong.
<infinity> That's comforting.
<infinity> pitti: Going to blame the gnome-keyring merge.
<infinity> pitti: Which has "disable gpg agent" in the changelog, so seems like a good thing to blame.
<pitti> wut?
<pitti> * Disable gpg agent as it is incomplete and incompatible with many uses of
<pitti>     GnuPG 2.x. (Closes: #760102).
<infinity> pitti: Evidently, we're meant to use pinentry-* now, but not sure how that works...
<pitti> ah, but we still use gpg 1
<infinity> pitti: Or maybe we're supposed to switch to GPG2 as well. :P
<pitti> pinentry-gnome3 I suppose
<pitti> yeah, at some point we should I guess
<infinity> pinentry-gnome3 is installed.  Can't see that it does anything.
<pitti> we've been holding back on that because there only used to be pinentry-gtk2
<pitti> but apparently now we have a GTK 3 variant
<infinity> Yeah.  I guess maybe I need GPG2 to make this work.
<pitti> I suppose .. right, that
<infinity> And we need to sort out dependencies a bit for non-gtk3 flavours.
 * infinity installs gnupg2 to see what happens.
<infinity> Hrm.  Not much without also renaming its binary, I guess.
<infinity> Ahh, or debsign -pgpg2
<pitti> infinity: works here
<pitti> infinity: i. e. I installed gnupg2, restarted my session, now I get an (admittedly rather bare-bones) dialog
<pitti> I just tested gpg -c foo.txt
<infinity> pitti: Oh, cute, it works with both versions, but only if gpg2 is installed?  That doesn't make much sense.
<infinity> Maybe it's cause gnupg2 pulled in gnupg-agent.
<pitti> yeah
<infinity> Yeahp, that does it.
<infinity> Looks like a transition is in order anyway at some point soon.  Should probably discuss that a bit before we jfdi.
<dholbach> good morning
<infinity> pitti: Anyhow, if you could commit my systemd one-liner to Debian git, that'd be snazzy.
<infinity> pitti: I left them all on one line in the hook, despite them being out of order that way, so it's less noise if we decide it's dumb and back it out later. :P
<pitti> infinity: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=b8fdd6f8f
<infinity> pitti: Ta.
<infinity> I wonder why pinentry-gnome3 isn't named gtk3... The deps seem mostly harmless and non-gnome.
 * infinity shrugs.
<pitti> seb128 just appeared, maybe he can give us some insights :)
<pitti> seb128: we want our GPG keyring agent back! :-)
<pitti> seb128: installing gnupg2 apparently helps, but it doesn't happen on upgrade
<infinity> So, gnome-keyring depends on pinentry-gtk3, that's probably going to need relaxing for other flavours.  Maybe.  And we'll need some seeding around the place to pull in the right agents and pinentries.
<seb128> pitti, it's a Laney transition, https://lists.ubuntu.com/archives/ubuntu-desktop/2015-July/004671.html
<seb128> why would that depends be an issue for flavors?
<seb128> those we us *gnome*-keyring already have gtk3
<seb128> we->who
<infinity> Literally everyone seems to have gnome-keyring seeded right now, though that may be a transient dep and a mistake.
<infinity> Nope, this was true in vivid too.
<infinity> gnome-keyring doesn't actually seem to contain GUI components of its own, so any pinentry backend will do.
<infinity> Which makes it suitable for all desktops.
<infinity> Indeed, kubuntu ships gnome-keyring and pinentry-qt4, but now they'll get -gnome3 as well.
<infinity> Laney: You probably want to s/pinentry-gnome3/pinenty/ on that gnome-keyring dep, and then seed the appropriate one for each desktop.
<infinity> Laney: And it looks like we also want gnupg-agent seeded.
<Mirv> doko: did you change anything regarding the 016 PPA other than uploaded qca2? weirdly, the qtdeclarative-gles which built just fine 1h ago now failed to resolve dependencies when rebuilding it (no changes, just correct version number). there were no other finished builds in between.
<infinity> pitti: In the shiny new autopkgtest infra, do you plan to make arch builds individually addressable?
<infinity> pitti: I always feel bad every time an arch fails and I retry all of them to fix it.
<pitti> infinity: you mean only re-run one arch?
<infinity> pitti: Yeah.
<pitti> infinity: yes, it only works that way
<infinity> pitti: Oh, good.
<pitti> we can do some helper scripts to retry all of them, of course
<infinity> pitti: I see zero need for such a helper. :P
<pitti> I don't yet have helper scripts, though; we'll create them as we need
<doko> Mirv, no, just qca2. yesterday, I uploaded the GCC 5.2 rc2, but that shouldn't change anything
<pitti> infinity: the stuff auto-retries "tmpfail" results up to three times, btw; that should also help
<infinity> pitti: In all my years, I've never thought "man, it sucks when I have to retry a build on 6 arches in LP", but I sure would hate it if retrying on one built them all.
<pitti> infinity: where tmpfail == testbed failure (nova hiccups, apt-get update checksum fail, etc.)
<doko> Mirv, seb128: when trying to build qtwebkit-source (qt4), the build fails, there doesn't seem to be a b-d on libjavascriptcoregtk-1.0-dev. is this expected?
<infinity> pitti: That should help a bit indeed.  I guess it depends on where we see weird failures.
<pitti> infinity: we could also add retry-once-on-regression, I figure
<pitti> but I don't have that yet; I want to see infra problems exposed for now
<infinity> pitti: Yeah, let's not paper over problems we don't have just yet.
<Mirv> doko: ok, I'm very puzzled now but I'll try to reproduce it in chroot or something
<infinity> pitti: I was just reminded of my complaint due to the broken infra issues that killed i386 for dbus and open-iscsi just now (both retried and succeeded now)
<infinity> pitti: So, y'know, was just a drive-by whine. :)
<doko> Mirv, you uploaded to trusty ... ;-P
<pitti> infinity: .. which seems settled for now?
<Mirv> doko: I'm not familiar with qt4's webkit, but if it's any same as qt 5 then it probably bundles its own javascriptcore fork
<infinity> pitti: Well, they worked on the second try, so "yes".
<pitti> infinity: there is one AMQP queue per release and arch, so we can retry tests on that granularity
<Mirv> doko: ahhahah...
<pitti> infinity: I mean settled wrt. the new stuff
<Mirv> doko: thanks ...
<infinity> pitti: Oh, yeah.  New stuff having a granularity of DAS seems just fine by me.
<pitti> infinity: I'm unsure whether I should block the rollout of this (run cloud stuff on the side) on re-review of slangasek; I'll ask him this evening
<infinity> pitti: (DistroArchSeries in LP talk, if that was gibberish to you)
<doko> cjwatson, could you get the haskell component mismatches under control?
<pitti> infinity: nah, I figured :)
<infinity> pitti: And note, it really should have the "distro" component of that DAS, so we can later reuse and abuse this infra for PPAs and derived distros.
<infinity> pitti: But I'm guessing it's lightweight and hackable enough that you can extend it later.
<pitti> infinity: yes, no problem; but I plan on adding PPA support as arguments of a release/arch/package test request
<pitti> infinity: as PPAs are orthogonal to selecting a distro name
<infinity> pitti: Quite, they're an archive.
<pitti> infinity: my selfish motivation is to move my manual daily-ish systemd upstream CI test to that cloud thing ASAP :)
<infinity> pitti: If you hack in archive support, derived distros are simple too.  Would be nice if it could map 1:1 to LP's view of distro archives, but that's probably not hard.
<pitti> infinity: shouldn't be, as long as we have some available cloud image to run tests in
<infinity> pitti: (For instance, PPAs can exist for both ~user/ppaname/ubuntu and ~user/ppaname/ubuntu-rtm)
<pitti> the only exercise is to map something like "trusty-amd64" to an image
<pitti> PPAs will always be added/dist-upgraded on the fly per-test, so they are easier
<infinity> pitti: Cloud images could be tougher.  Hrm.  The only tarballs we guarantee to have for derived distro are lp-buildd chroots.  But, it's a mostly moot point for now as we don't have any active derived distros we care about anymore.
<pitti> infinity: we could always set up a vmdebootstrap daily cron job
<pitti> as long as that distro is buildable out of debootstrap (which really ought to be a given -- if not, go away)
<pitti> in fact I'd like to do that for at least Debian sid
<infinity> pitti: Heh.  Well, we'll cross that bridge if we're ever forced onto it.  Was more making sure the infra was flexible enough to do it, not that we dotted all the Ts and crossed the Is.
<pitti> I locally run it occasionaly, but nicer to have some machine do it for me
<pitti> running a test on Debian is certainly something that interests me, and I do it locally all the time
<pitti> (with vmdebootstrap image)
<infinity> pitti: There are a lot of things I'd like to do with Debian in Canonical infra...
<infinity> pitti: Like provide PPAs.
<infinity> pitti: Which we should have done years ago.
<infinity> pitti: But now that Debian's supposedly planning their own version, perhaps it's too late to be good citizens and do so.
<doko> Mirv, Riddel, ScottK: qca2 in debian b-d's on qtbase5-dev, while in Ubuntu it b-d's on libqt4-dev. any reason for that?
<doko> ahh, Debian's version has additional qt5 packages
<Mirv> doko: it looks to me that sitter might have accidentally dropped qtbase5-dev from  2.1.0-0ubuntu2  upload, it was there in ubuntu1 but I don't see a mention in changelog about dropping it
<Mirv> oh, not accidentally, 2.1.0-0ubuntu1 was stuck in proposed, so probably on purpose
<sitter> qca2 is qt4, qca2-qt5 is qt5. I am not sure why it would depend on qtbase5 in debian
<doko> ahh, Debian builds from one source
<sitter> that would explain it I guess
<sitter> there was some upstream tension over supporting qt5 in the same (upstream) source tarball which is why we ended up with two source packages
<doko> Mirv, sitter: is there a short doc how to use the pkg-kde-tools to update the qt/kde symbols files?
<Mirv> doko: http://pkg-kde.alioth.debian.org/symbolfiles.html . I do for example pkgkde-symbolshelper patch -p libqt5concurrent5 -v 5.4.2 < concatenated_all_buildlogs and review the result
<sitter> doko: http://pkg-kde.alioth.debian.org/symbolfiles.html look for 'pkgkde-symbolshelper batchpatch'
<sitter> there's also this bugger which supposedly automatically gathers up all logs from launchpad and patches them in http://paste.ubuntu.com/8573918/
<cjwatson> doko: No, I can't, sorry.  Last I checked Haskell was entirely in universe, so if it's in c-m it's due to something I didn't touch, and somebody who cares about *that* should disentangle it.  Looks like maybe ffms2 started build-depending on pandoc?
<cjwatson> doko: Simplest change would be to find another markdown processor that's a bit more main-friendly to implement https://anonscm.debian.org/cgit/pkg-multimedia/ffms2.git/commit/?id=1c0216de2945a955480e6dd84a2f05729936691e (since that can't just be reverted if the upstream doc format changed), I guess.  I don't actually mind if Haskell ends up in main, but I suspect something where you may have to rebuild all reverse-dependencies when ...
<cjwatson> ... applying a code change may be hard to get past the security team.
<infinity> *cough*Go*cough*
<mitya57> cjwatson, python3 -m markdown <foo.mkd >foo.html
<mitya57> main-friendly :)
<cjwatson> Which is fine by me, but somebody will have to test that for ffms2 - I'm not going to have time
<mitya57> Will need a tiny bit of patching
<mitya57> cjwatson, doko: http://people.ubuntu.com/~mitya57/tmp/pymkd.diff, after that
<mitya57> sed s/---/-/g doc/ffms2-api.md | python3 -m markdown -x fenced_code -x headerid >doc/ffms2-api.html
<mitya57> Can upload that if you want
<cjwatson> It's fine by me
<cjwatson> Thanks
<mitya57> So doing that
<infinity> mitya57: If the implication there is that the upstream docs aren't 100% correct markdown, could you push a patch upstream too?
<infinity> mitya57: (Or is that a bug/misfeature in the py3 md parser?)
<mitya57> Doing that already :)
<cjwatson> python-markdown's docs say that it adheres a bit more strictly to the markdown spec on list formatting than other formatters do, and that they consider this a bug in *other* formatters.
<infinity> Of course they do.
<infinity> I would expect nothing less from the people who brought me PEP-8.
<cjwatson> But you're not bitter.
<infinity> Not even a little.
<mitya57> Actually pandoc (which is used in Debian) behaves the same as Python-Markdown
<mitya57> http://johnmacfarlane.net/babelmark2/?text=-+Item+1%0A++-+Item+2%0A++-+Item+3%0A-+Item+4
<cjwatson> Odd, so why didn't that fail before?
<cjwatson> Oh, I guess it kind of did.  Just more warnings or something?
<mitya57> No, it just rendered it as a single list, not as list + sublist
<mitya57> Oh, python-markdown is in main while python3-markdown isn't
<mitya57> So let's pull the latter too :)
<infinity> mitya57: If they're from the same source, that's a no-op.
<mitya57> Yes
<infinity> Fixing now.
<mitya57> Uploaded & submitted upstream as https://github.com/FFMS/ffms2/pull/222
<infinity> mitya57: Promoted.  I'm sure your upload will beat the promotion, so you might need to retry if it doesn't dep-wait properly.
<mitya57> Huh, the pandoc doesn't even render lists correctly
<mitya57> And codeblocks
 * mitya57 files a Debian bug
<mitya57> amd64 and i386 already built, the others will hopefully build too
<infinity> mitya57: Oh, that's cause ffms2 is in universe.
<infinity> I assume c-m exploded cause something else is trying to pull it in.
<mitya57> :-/
<infinity> x264, looks like.
<mitya57> Anyway I fixed the docs because pandoc was broken :)
<infinity> Heh.
<infinity> Sounds sensible to me.
<infinity> stgraber: We still have ltsp wanting mate-desktop.  Wasn't someone going to fix that?
<ogra_> to what ?
<ogra_> (Unity7 isnt really remote friendly)
<infinity> ogra_: To whatever it was before the merge from Debian? :P
<mitya57> If you think you need MATE, then you need GNOME Flashback :)
<infinity> -  gnome-session | x-session-manager | x-window-manager,
<infinity> +  mate-desktop-environment | gnome-session | x-session-manager | x-window-manager,
<ogra_> not sure what was used before ... i just know that Unity doesnt work inless yyou use some costly protocol like VNC
<infinity> That shows up in a couple of places.  Probably just needs the prefs inverted and we're good.
<infinity> I would have done it myself, but given that I literally never use LTSP, I thought it saner to leave it to people who know what it'll do if I "fix" it.
 * ogra_ thinks stgraber's plan was to actually leave all maintenance to debian nowadays ... without ubuntu delta ... 
<infinity> ogra_: Well, he still has a delta, so that's not working out.
<ogra_> oh ?
<infinity> ogra_: But, if that's the plan, it should probably drop out of main.  Which I'd be fine with too.
<ogra_> why would you drop it from main ?
<infinity> ogra_: To avoid pulling MATE in.  Or whatever other random deps Debian adds.
<ogra_> ah ... well, i guess that should be fixed :)
<mitya57> infinity, another solution which doesn't require delta will be killing mate dependency in debian as well
<ogra_> or just re-ordering
<infinity> The Debian order seems deliberate, from the changelog.  THey want to prefere mate.
<infinity> Which is fine.
<infinity> But doesn't work for us.
<infinity> But I'm not sure why it's even *in* our supported seed anyway.
<infinity> I still assume that's just from way back when all flavours were in main.
<infinity> And that hasn't been a reality for years.
<Guest99726> mitya57: GNOME flashback didn't work a while ago because it was checking for extensions (or rather versions) NX cannot provide currently - I've heard of the newest GNOME version working again, but haven't checked myself
<ogra_> infinity, well, we developed it (mainly) ... it is a part of edubuntu (which falls under your last statement)
<infinity> ogra_: Sure, but we clearly don't put much effort into supporting it any more, so "we developed it" doesn't matter.  We developed a lot of stuff that's not supported.
<Guest99726> (might be working "just fine" over VNC though, but that's not all the technology out there)
<mitya57> Guest99726, it was a problem not in gnome-flashback, but in gnome-session, is fixed now
<mitya57> There may be problems with gnome-shell, but flashback should work
<Guest99726> okay
<shadeslayer> chrisccoulson: no firefox update for precise?
<mdeslaur> shadeslayer: I'm sure chrisccoulson would welcome some help to fix bug 1471949
<wgrant> chrisccoulson: It seems you dropped my arm64 build fix in your recent wily firefox upload.
<infinity> chrisccoulson: (which should also have ended up in all the stable branches too, but I didn't commit to anything but wily, sorry)
<roaksoax> infinity: howdy!! I just uploaded MAAS 1.7.6 for SRU to resolve bug #1413388 found after upgrades to 1.7.5 in -proposed. Anychance you can process it today? Thanks!
<infinity> roaksoax: Why are the SRU versions higher than the wily version?
<infinity> roaksoax: Oh, you literally just uploaded the matching wily one.  Okay.
<larryone> Hi,  the Amazon AMIs for vivid are still labeled as DEVEL - is that intentional?
<larryone> are there any vivid AMIs that are production ready?
<infinity> utlemming: ^
<larryone> (looking at http://cloud-images.ubuntu.com/locator/ec2/, the dropdown for Version refers to 15.04 DEVEL only)
<roaksoax> infinity: indeed :) I uploaded wily first though, I guess it takes more time to show up provided it has to build and all
<roaksoax> infinity: and thank you!
<infinity> larryone: That's probably just a display bug, those should have been marked stable when vivid released.
<infinity> larryone: But Odd_Bloke or utlemming can confirm and fix.
<larryone> infinity, yea, just looking now under http://cloud-images.ubuntu.com/releases/15.04/release-20150707/
<larryone> looks like I can fire away with it
<rbasak> pitti: any thoughts on having apport and/or dh_installinit provide the failure output swallowed by systemd automatically, without having each maintainer write an apport hook? Seems like something that could be done automatically. Eg. teward's diff at http://launchpadlibrarian.net/211346485/nginx_1.6.2-5ubuntu3_1.6.2-5ubuntu3.1.diff.gz
<pitti> rbasak: err yes, absolutely; that should really not be in a specific package
<pitti> rbasak: but rather in /usr/share/apport/general-hooks/ubuntu.py or even generic.py
<pitti> that's actually nice
<pitti> I've been annoyed for years by the tons of "postinst failed with exit code 1" bug reports which didn't otherwise have any useful log
<pitti> with systemd we finally have some generic way of extracting information at least
<rbasak> Well, the init.d error output served me well in the past
<rbasak> But I think systemd swallows that now
<pitti> well, invoke-rc.d should at least say something like "foo failed to start"
<pitti> (not that this would be much helpful, of course)
<rbasak> Right
<rbasak> The only other pain point in the past was if a daemon logged to its own logfile and not to stderr, or after forking, so the init.d script didn't pass it through, but in general the apport hooks should pick up that logfile anyway
<stgraber> infinity: hey, so vagrantc was supposed to get this sorted out in Debian, let me check what's going on and at least just do it in Ubuntu instead
<pitti> rbasak: right, but I thought your goal was to avoid having to create individual package hooks for that?
<rbasak> pitti: isn't that unavoidable if a daemon insists on writing to its own logfile only?
<rbasak> Or can systemd pick that up somehow?
<pitti> rbasak: ah, of course
<pitti> but then the journal should at least say "pid 123 died with SIGSEGV" or so
<teward> i was pinged xD
<rbasak> "pid 123 exited with status 1"
<rbasak> :)
<pitti> so for stuff not just logging to the journal we of course still need per-package hooks
<pitti> but at least for the journalling ones we could generalize
<rbasak> Yep. No need to block teward's SRU for that though I hope.
<pitti> and we already have everything of level "warning" and above in bug reports
<teward> rbasak: already poked infinity and it was 'accepted
<pitti> just not info etc.
<teward> rbasak: [2015-07-13 09:58:42] -queuebot/#ubuntu-release- Unapproved: accepted nginx [source] (vivid-proposed) [1.6.2-5ubuntu3.1]  <--
<pitti> so in theory the JournalErrors.txt should have most errors already
<teward> pitti: https://launchpadlibrarian.net/208651217/JournalErrors.txt  <-- see https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1463383
<rbasak> Doesn't that assume that every daemon is logging in a way that ends up in the journal with appropriate levels?
<stgraber> infinity: manually applying the change vagrantc said he'd push to Debian and uploading that to wily
<teward> pitti: that's why i wrote the hooks i needed in there
<rbasak> I don't think either of those are true
<teward> pitti: as it stands systemd is swallowing the failure reasons
<teward> whether that's the nginx start script or systemd I am not sure which is swallowing
<teward> but it's not putting usable info into that errors page
<teward> s/page/file/
<pitti> hm, is nginx of Type=forking?
<rbasak> I don't think that "more journald support" is the right answer here. We should arrange to just provide stderr in the case of simple failures.
<pitti> well, stderr is exactly what goes into the journal :)
<pitti> (and stdout too)
<teward> i'll have to check the type, it might be forking...
<rbasak> But not in the bug
<rbasak> (AIUI?)
<teward> pitti: yes it's type forking
<pitti> Type=forking
<pitti> ExecStop=-/sbin/start-stop-daemon --quiet --stop --retry QUIT/5 --pidfile /run/nginx.pid
<pitti> err yes
<pitti> that eloquently avoids all logging of course :)
 * teward grumbles
<pitti> this is just wrong -- start-stop-daemon should never be used in a unit
<teward> pitti: Debian doesn't know how to do it then
<teward> :p
<pitti> yeah, this is waaay to complicated
<pitti> teward: ok, now I understand your frustration :)
<teward> pitti: i internalize most of that ranting.  or go to the gun range to vent it.  but in either case, yes, frustration!
<teward> pitti: IMO the package hooks I did for nginx for Vivid and Wily are just a workaround to the core issue
<teward> but solve the failure to get usable bug info on the postinstall script failure
<pitti> yeah, that unit should be fixed properly
<teward> at least for the flurry of bugs we've seen currently
<teward> (which rbasak is well familiar with xD)
<pitti> teward: yes, your hook looks fine as a workaround for at least vivid
<pitti> ExecStartPre=/usr/sbin/nginx -t -q -g 'daemon on; master_process on;'
<pitti> ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;'
<pitti> ExecReload=/usr/sbin/nginx -g 'daemon on; master_process on;' -s reload
<pitti> this just can't be right
<pitti> why does this have to be called twice?
<teward> pitti: and Wily, for now, as I put the hooks there too
<teward> (they landed in Wily first)
<pitti> (bbl)
<shadeslayer> mdeslaur: oh wow that looks mental
<mdeslaur> shadeslayer: yeah :)
<doko> jamespage, ping on debian #778058
<jamespage> doko, sorry
<jamespage> doko, oh - I'm going to get that removed
<jamespage> doko, along with percona-xtradb-cluster-5.5
<jamespage> we don't have those in Ubuntu any longer, and upstream can't commit the time to maitaining them in Debian
<doko> ok, thanks
<doko> jamespage, also, who should sort the ruby component mismatches? server (-> puppet), or foundations? it won't be me this time
<jamespage> doko, I'll have to pass that over to rbasak and smoser :(
<smoser> pitti, https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1473527
<smoser> does my guess make any sense there? is there some reason that a program with StandardOutput=journal+console should not open /dev/console ?
<smoser> (other than it not making a lot of sense... the wierd thing is that it is only transient failure)
<pitti> smoser: I can't answer that off the top of my head, need to investigate
<smoser> doko, i hope that'd be rbasak i guess.
<pitti> smoser: with the tee'ing to journal+console it might be that /dev/console is already opened/busy?
<smoser> pitti, that does make sense. but you'd think it would fail all the time then.
<smoser> i guess systemd must be reading output from program, then opening /dev/console and closing /dev/console for each time it writes or something.
<smoser> meaning i only race on it.
<pitti> right; I remember some pull request which had to be reworked because "don't keep /dev/console open all the time, only when you need it"
<pitti> supposedly because of that
<pitti> but as I said, I don't have firm knowledge about this, need to investigate
<infinity> Time for an ubuntu-cloud plymouth theme that cloud-init can write pretty progress to? :)
<ogra_> lol
<infinity> (not being entirely facetious; that's the whole point of plymouth is multiplexing console I/O)
<smoser> pitti, thanks.
<smoser> you'd think /dev/console can be opened multipel times.
<smoser> otherwise i'd expect really arbitrary failures in a lot of places... anywhere that writes to /dev/console  to sometimes fail.
<smoser> and also that breaks my plan for fixing this, which was to have cloud-init not do StandardOutput=journal+console, but rather to just itself parse /proc/cmdline and figure out what the right console targets are and writing there directly.
<smoser> as that would then be a race condition.
<smoser> it sure would be nice to have a way to write to all 'console=' items that was safe to use.
<doko> W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/wily-proposed/main/i18n/Translation-en  Hash Sum mismatch
<doko> W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/wily-proposed/universe/i18n/Translation-en  Hash Sum mismatch
<doko> can't get a clear apt-get update ...
<teward> shoutout to pitti for the excellent guidance on apport package hooks.
<teward> rbasak: https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1474039  <-- evidence that the package hooks add in the information that's missing (it's not a real bug, but i had forced a test case to prove it xD)
<ubottu> Launchpad bug 1474039 in nginx (Ubuntu) "(Test Case Evidence for #1472683) package nginx-full 1.6.2-5ubuntu3.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Low,Invalid]
<larryone> infinity, thanks for you're advice from earlier, now up and running in our test environment with 15.04
<larryone> our first systemd machine =0)
<teward> infinity: with regards to the changes to make the net ifnames be the systemd version that 15.10 is moving towards, first-glance looks like it'll work.  we'll see after we go through installation if it stays that way.  (ens## is the numbering pattern it's using, lets see if all works)
<teward> infinity: confirmed that the changes you made for the ifname stuff is working - upon install the primary interface is configured as it should be and network access is confirmed
<smoser> infinity, would you care to take a look at https://bugs.launchpad.net/ubuntu/+bug/1474090
<ubottu> Launchpad bug 1474090 in Ubuntu "ppc64 cloud images boot only once" [Undecided,New]
<yofel> cyphermox: hi, did you make any progress with updating the packagesets?
<SpamapS> cjwatson: Interesting grub question for you: Is there any good reason grub shouldn't be able to detect and work with a 1.8TiB root partition with no /boot? Part 2: is there any bad reason it doesn't work like that now?
<Daviey> SpamapS: MBR or GPT?
<cjwatson> SpamapS: No /boot would probably require some customisations to various GRUB defaults involving /boot/grub.  It should be workable but may require runtime tweaks.
<cyphermox> yofel: oops.
<cyphermox> will re-run, perhaps here it will work faster
#ubuntu-devel 2015-07-14
<infinity> smoser: So... What are you doing on first boot to change the filesystem?
<pitti> Good morning
<cyphermox> pitti: morning
<smb> pitti, Morning. I hate to be the anal guy, but... any thoughts about the ifup@.service changes I was looking at? bug 1466790
<ubottu> bug 1466790 in ifupdown (Ubuntu) "dhclient does not remain running on boot" [Undecided,New] https://launchpad.net/bugs/1466790
<dholbach> good morning
<pitti> smb: still on my TODO, haven't forgotten
<smb> pitti, Ok, thanks. It might be helpful in other ways than the specific bug I reported. At least I think it might. But that slightly different handling of sub-processes of processes started with ExecStart compared to ExecStart(Pre|Post) feels like it could cause weird things
<pitti> smb: I have some other bug reports in Debian about ifup@; I need to take some time to analyze them all, probably they are related
<smb> pitti, I can imagine. It seems like anything triggered by an ifup call in ExecStartPost will be suffering. That includes dhclient but also ntpdate
<pitti> smb: right, ExecStart{Pre,Post} must not start anything long-running
<pitti> smb: so I suppose I need to put both ifup's into ExecStart
<smb> pitti, Right, that was my proposal (actually put all 3 calls into ExecStart and explicitly mark the service as type=oneshot)
<pitti> smb: we used to have oneshot, but that's not correct either as it blocks the boot if ifup hangs (slow DHCP, missing cable, etc.)
<smb> pitti, Hm but at least from the man page multiple ExecStart are only allowed for oneshot
<pitti> smb: right, but that's not a serious limitation
<pitti> smb: ExecStart=/bin/sh -c 'if ifquery; ... ifup auto; ifup allow-hotplug;'
<smb> pitti, The other option might be to move back to the Vivid style maybe (and have one ExecStart with a shell command executing the 3 commands...
<smb> Oh yes, that. :)
<pitti> right, I'll probably do that, and check history why I changed it
<pitti> but I want to take some time to properly understand and test this in different scenarios
<smb> Ok, sure. Just had the feeling that maybe other instances too may have missed the implications of "must not start long running"
<smb> Somehow to me that means the command should not take long to run, not that it is not allowed to start something in the background
<infinity> pitti: Can we sort out how to make "test logs" linked to by debci have proper content encoding headers so my web browser unzips them instead of forcing me to download them and unzip them manually?
<pitti> infinity: incidentally, the remaining TODO on https://git.launchpad.net/~pitti/+git/autopkgtest-cloud/tree/TODO :)
<pitti> infinity: that's not debci, it's swift; I'll look into that
<infinity> pitti: Right, hence why I said "linked to from", not "served by". :)
<pitti> anyway, IKWYM
<infinity> pitti: Though, some httpd implementations will serve the right mime-type if you just fudge the filename as foo.txt.gz
<infinity> pitti: Which, if it would, could avoid arguing with the server itself.
<SpamapS> cjwatson: thanks! I'll explore adding a /boot capability to my image builder instead. :)
<doko> siretart, aspectc++ ping
<pitti> wow, at first I thought I had a bug in autopkgtesting, but https://tracker.debian.org/pkg/ruby-rails-assets-markdown-it--markdown-it-for-inline actually exists
<LocutusOfBorg1> ginggs, congrats for the AM approved :)
<Unit193> LocutusOfBorg1: How's vbox 5.0 looking to you then? ;P
<pitti> infinity: filed as bug 1474271 FYI
<ubottu> bug 1474271 in Auto Package Testing "fix MIME type of log.gz" [Medium,Triaged] https://launchpad.net/bugs/1474271
<LocutusOfBorg1> Unit193, ready to upload, we are discussing if unstable or experimental
<LocutusOfBorg1> for sure I'll ask for an Ubuntu sync, if it lands in experimental :)
<seb128> hum, language-pack-touch-zh-hans is blocked in wily-proposed because of a Boottest regression which seems to be flackyness again, could somebody retry it?
<Laney> seb128: AFAIK you should have the permission to do that
<Laney> but it looks like infinity already got there
<seb128> k, going to try next time
<seb128> I was on the public jenkins, I guess I need the private one to retry?
<Laney> If you go to http://d-jenkins.ubuntu-ci:8080/view/Wily/view/BootTest/job/wily-boottest-language-pack-touch-zh-hans/ and log in you should see a "Build Now" which does it
<Laney> pitti: sort of related, does your new autopkgtest infrastructure let anyone retry tests? :)
<Laney> hopefully not *anyone*, YKWIM
<pitti> Laney: not right now; you need the AMQP credentials for that and be in the data center
<pitti> Laney: I'll create some convenience script on snakefruit, or ubuntu-archive-tools or something
<pitti> Laney: btw, as I'll be on holidays next week, would you have half an hour or so for me to give you a quick tour about it?
<pitti> Laney: i. e. some minimal worker admin in case this stuff hits a bug
<Laney> Ah right - hopefully the goal is to let all uploaders do that
<Laney> pitti: 'kay, in an hour or so?
<pitti> Laney: sounds good
<pitti> Laney: just in case I need to sort out stuff with IS, can you ssh wendigo.canonical.com?
<Laney> pitti: yeah, and I seem to have access to prod-ues-proposed-migration
<pitti> Laney: alright, then you are all set
<pitti> Laney: sent a cal appointment with a hangout, please feel free to move it around as you see fit
<Laney> ack, just want to not lose my brain state
<pitti> infinity: meh, I give up on bug 1474271 for now :/
<ubottu> bug 1474271 in Auto Package Testing "fix MIME type of log.gz" [Medium,Triaged] https://launchpad.net/bugs/1474271
<pragomer> I am remastering Ubuntu with package wireshark. On the live cd I get permission error /usr/bin/dumpcap. I found this solution when I execute it on the live system: http://pastebin.com/JttCCLKD   But when remastering usermod says, in the chroot, MYUSERNAME does not exist. How else can I solve this?
<cjwatson> You'd need to put it in a casper-bottom script in the initramfs - the live user is created at boot time
<pragomer> ah ok. this was also the direction of my thoughts cjwatson.. doing it in the the init script.. so casper-bottom is a stage where the user is already built?
<cjwatson> pragomer: it's created in 25adduser there, so anything after 25 should be fine
<arges> pitti: not sure who I should be talking to, but for the autopkgtests run by ubuntuci. Who should I ask to unblock ddebs.ubuntu.com ?
<arges> It causes my crash autopkgtest to fail.
<Mirv> FYI some more Qt packaging moved to Debian git, so now moved are: qtbase, qtdeclarative, qt3d, qtlocation (+ all that are synced as is). I keep http://is.gd/Q5huYG doc up to date (linked to also from https://wiki.ubuntu.com/Touch/QtTesting)
<pragomer> cjwatson: thank you very much
<pitti> arges: sorry, WDYM by "unblock"?
<arges> pitti: i know there was discussion about the ubuntu tests only having internet access to the archive. I wonder if ddebs.ubuntu.com access is blocked (as it seems from looking at the log)
<smoser> infinity, nothing is happening on first boot. the script there shows everyything, entirely automated failure.
<smoser> s/nothing/nothing of particular interest/
<smoser> not even apt-get upgrade or anything.
<pitti> arges: ooh! you mean the source package "crash"?
<pitti> arges: I had some trouble parsing that sentence, now it makes much more sense :)
<arges> pitti: yes
<arges> pitti: : )
<pitti> arges: I see it in the logs of http://autopkgtest.ubuntu.com/packages/c/crash/wily/amd64/ too, I'll have a look
<pitti> apparently we can't exclude *.ubuntu.com in $no_proxy, this one does need a proxy
<infinity> smoser: Well, something must be happening to it, or the second boot would be the same as the first...
<smoser> agreed. i can give you access to diamond if you'd like.
<infinity> smoser: I'm assuming either the PReP partition or the partition table in general is being broken.  Hard to say which.  Unless qemu itself is breaking your image for you, which seems unlikely.
<smoser> i'm suspecting growpart right now. checking that.
<Daviey> [A
<Daviey> [A
<infinity> Daviey: Go on, say [A again.  I dare  you.
<Daviey> [A
<infinity> Oh.  Well done, then.
<smoser> it would seem to be growpart related . :-(.
<Daviey> [A
<Daviey> [A
 * smoser tries to imagine what emotion that is.
<Daviey> Sorry all, having odd locale problems.. generating odd control characters on pg/up.
<seb128> does anyone know who handles http://ubottu.com/meetingology/logs ?
<seb128> that gives a permission error
<teward> seb128: perhaps poke -irc, but i think they've had issues with the bots lately?
<seb128> teward, did that (as you noticed on the other channel, thanks ;-)
<teward> :)
<ScottK> It should be possible to get qscintilla2 and a stack of other packages to migrate with a few no change uploads, FYI.
<infinity> slangasek: Do you know what the ddebs.u.c lag is, compared to archive.u.c?
<infinity> slangasek: (ie: how long after publishing a deb should I expect to wait for a ddeb?)
<slangasek> infinity: afraid not, no.  bdmurray, do you know?
<bdmurray> infinity, slangasek: I do not know.
<infinity> Check.
<infinity> I could try to divine from the code, but I'm not that impatient to know the answer.
<roaksoax> /w/win 9
<mwenning> hi guys is there an irc channel for lxd?
<stgraber> mwenning: #lxcontainers
<stgraber> (same as lxc, cgmanager, lxcfs, ...)
<cjwatson> $ ssh -t germanium sudo -iu ddebs crontab -l | grep 'ddeb-retriever --quiet today'
<cjwatson> 40 */2 * * * ~/ddeb-retriever/ddeb-retriever --quiet today
<cjwatson> infinity: ^-
<infinity> cjwatson: Yeah, I know.
<infinity> cjwatson: You'll note I logged in well before you did. ;)
<cjwatson> I didn't note that, note the lack of interactive shell above :)
<infinity> cjwatson: NOTE HARDER.
<infinity> cjwatson: The more interesting thing I'm confused by now is that the latest ddeb-retriever run appears to have decided that wily has no kernels.
<infinity> Not sure what to make of that.
<cjwatson> Maybe only on some arches?
<infinity> cjwatson: I'd like to think we have kernels on all arches.
<cjwatson> Yeah :)
<cjwatson> Anyway, late meeting tonight, so I was doing some of that not working thing.
<infinity> I approve of this message.
<infinity> cjwatson: Huh.  You're right.  Only on some arches.  Curious.  Maybe it needs a 'yesterday' run to unconfuse itself.
 * infinity tries forcing the issue.
<infinity> cjwatson: Oh, crap.  Wait.  That timestamp windowing you and pitti worked out for only grabbing builds from X to Y.  Is that build completion date or build accept date?
<infinity> cjwatson: Cause I'm now thinking that leaving an amd64 build in UNAPPROVED for more than a day might have fooled ddeb-retriever's tiny brain.
<infinity> In fact, I'm sure that's what happened...
<cjwatson> Hm.
<cjwatson> BPPH creation date.
<cjwatson> Which you'd think would be accept date.
<cjwatson> But you can manually stuff a different timestamp in and it'll try again.
<infinity> cjwatson: Yeah, I'll do that.
<infinity> cjwatson: But out of curiosity, what's the BPPH creation date for https://launchpad.net/ubuntu/+source/linux/4.0.0-4.7/+build/7636518 ?
<infinity> FInished building on the 9th, but I only accepted it yesterday.
<infinity> Guessing the date is the 9th.
<cjwatson> infinity: 2015-07-14 17:05:58.537532+00:00
<infinity> cjwatson: Okay, very confused.  I guess I need to read this code. :/
<cjwatson> infinity: You sure another today run wouldn't have sorted it out?  I'm thinking maybe there's a race with BPPHs that have been dominated or something
<cjwatson> Pretty difficult to tell without logging, though.
<infinity> cjwatson: I've done a few more today runs with no luck.  But, there's a threshold file that makes it skip ahead.
<infinity> cjwatson: So, it might have raced a bit, then skipped ahead.
<cjwatson> There's a one-hour grace period on that threshold, which ought to be enough.
<infinity> INFO: Retrieving Launchpad publications since 2015-07-14 17:53:13+00:00
<infinity> Clearly too late.
 * infinity knocks it back two hours and tries again.
<cjwatson> Right, but a previous run ought to have covered it at least once.  Weird.
<infinity> cjwatson: Huh.  And now I'm stumped.  Even that didn't download the amd64 kernel ddebs.
<infinity> cjwatson: Even weirder (and this doesn't seem possible), one armhf ddeb is there, but not both...
<infinity> slangasek: Remember when you offered to look at this? :P
<infinity> slangasek: http://paste.ubuntu.com/11879214/
<infinity> slangasek: The missing amd64 ddebs make "sense", in that a whole build is gone, though I can't figure out how to force ddeb-retriever to find it.
<infinity> slangasek: But the armhf thing is even weirder.  generic-lpae is there, but generic is missing.  How does half a build go missing?
<cjwatson> Is it maybe failing to associate them with the deb partners?
<cjwatson> There's some fairly baroque code for that IIRC
<infinity> cjwatson: But only for this one version?
<cjwatson> Yeah, that's odd.  Crank up logging and trawl through the output?
<cjwatson> --verbose
<infinity> That was a lot more verbose than I'd expected...
<infinity> cjwatson: No mention of the missing kernels in a verbose log: http://paste.ubuntu.com/11879283/
<infinity> Oh, but my time hack got reverted.
 * infinity undoes that and tries harder.
<slangasek> oh man, you have time hacks?!
<slangasek> I want time hacks
<infinity> slangasek: It's not nearly as cool as the movies make it sound.
<carlgeorge> Rackspace is looking for a Linux Engineer with experience building Ubuntu and/or Debian packages.  http://rackspace.jobs/san-antonio-tx/ubuntu-linux-engineer/2532116AFB2B4E7093C154362DFB5F5B/job/
<slangasek> mdeslaur: is there any chance you could help with bug #1474541?
<ubottu> bug 1474541 in sbsigntool (Ubuntu) "sbsigntool broken by update to openssl 1.0.2c" [Undecided,New] https://launchpad.net/bugs/1474541
<mdeslaur> slangasek: hrm, I'll take a look at it tomorrow
<slangasek> mdeslaur: thanks :)
<xnox> slangasek: i hope you are not jealous =)
<xnox> slangasek: http://spi-inc.org/corporate/votes/2015-board-election/
<Unit193> xnox: "Congrats"? :)
<xnox> Unit193: thanks.
<slangasek> xnox: I was just celebrating here that you got the position so I didn't have to
<slangasek> :)
<xnox> slangasek: ;-) if you have any requests or insight, i'm all ears.
#ubuntu-devel 2015-07-15
<pitti> Good morning
<Unit193> Heya.
<Unit193> sbeattie: Hello!  In apparmor you have  Depends: initramfs-tools  when it'd be better to have  Depends: initramfs-tools | linux-initramfs-tool  and will close bug 1109029 for apparmor.  (Biggest reason to do this would be the experimental dracut utility, I did this change locally with success.)
<ubottu> bug 1109029 in udev (Ubuntu) "Depend on linux-initramfs-tools" [Wishlist,Confirmed] https://launchpad.net/bugs/1109029
<dholbach> good morning
<infinity> pitti: *nudge*
<pitti> infinity: *eek*
<infinity> pitti: Feel like debugging ddeb-retriever a bit?
<pitti> infinity: still the linux ddebs?
<pitti> infinity: debugging britney ATM, but I can append it to my ever-growing pre-holiday TODO :)
<infinity> pitti: Yes.  Missing all the amd64 ddebs for 4.0.0-4.7, and half (??) the ddebs for armhf.
<infinity> pitti: And no amount of fudging dates and trying to force the issue got any of the missing ones to show up in --verbose output at all, so I'm a bit stumped.
<pitti> if the combined brain power of cjwatson (as the author of this) and you didn't figure it out quickly, I suppose it'll take me a good half day at least; I made a note of it, but I'd really like to fix britney first
<infinity> pitti: Well, Colin didn't really have time to dig deeply, he just suggested "run it with verbose and have a look". :P
<pitti> heh, ok :) here's hope that it's simpler then
<infinity> pitti: And my python is much worse than yours, so I figured it made more sense to ask you to look than to muddle through.
<pitti> yep, absolutely; I'll see to doing that today
<pitti> Laney: ah, two workers died with some "Authorization Failure" error; want to practice restarting them?
<pitti> Laney: I can't make much sense of that, it looks like a transient error
<pitti> Laney: (worker-9 shouldn't be restarted, as that was my manual one and it tends to hit the quota, but the other one should be)
<Laney> hey pitti
<Laney> do they exit on that kind of error?
<Laney> i.e. just start a new instance manually?
<pitti> Laney: yes; I have a couple of retries in the code, but not for this kind of failed swift login yet
<pitti> Laney: you see which worker crashed?
<pitti> Laney: (grep -r Traceback log)
<Laney> pitti: Yeah, I did "tail *.log" to see the exception
<pitti> ah, good
<pitti> Laney: so you can just start a new one like launch-workers would:
<pitti> autopkgtest-cloud/worker/worker --config worker.conf > log/worker-2.txt 2>&1 &
<pitti> Laney: again, sorry for the bare-bones handling, but I want to see what it's crashing on before adding lots of (possibly endless-loopy-) auto-retries
<Laney> pitti: no worries - seems to be running now
<pitti> Laney: filed as bug 1474729
<ubottu> bug 1474729 in Auto Package Testing "worker failed on transient swift login exception" [Medium,Triaged] https://launchpad.net/bugs/1474729
<pitti> Laney: thanks; back to 8 workers
<pitti> Laney: I'll send an RT to open up SMTP, so that we can get cron (or other) notification mails
<Laney> pitti: good idea - can you rig it up so the workers mail when they bail out?
<pitti> Laney: yes, that was the intent
<Laney> ack
<pitti> Laney: tracked as bug 1474734
<ubottu> bug 1474734 in Auto Package Testing "Robustify against transient worker failures" [Medium,Triaged] https://launchpad.net/bugs/1474734
<pitti> Laney: if you encounter bugs, please keep filing them against auto-package-testing
<pragomer> Did remastering of ubuntu. For beeing able to use wireshark as non-root, I use this http://pastebin.com/CguX7sik    as an init-script. The script is under /usr/share/initramfs-tools/scripts/init-bottom/ , but it has no effect. When executing the script manually in live-system, it works.. but does not automatically. any ideas?
<cjwatson> pragomer: I did specifically say casper-bottom
<cjwatson> Also it would need to chroot
<cjwatson> Look at the other casper-bottom scripts for patterns to follow
<cjwatson> But basically you'll need "chroot /root" before each of those lines
<pragomer> hi.. I tried casper-bottom, did not work. thats why I took the latest stage (according to manpage of initramfs-tools last is init-bottom)
<pragomer> its an init script.. so I do not need any chroot, right?
<cjwatson> pragomer: No, wrong :)
<cjwatson> It's not an init script
<cjwatson> You fixed it in the wrong way by moving it out of casper-bottom to init-bottom, and the stuff in init-bottom is NOT init scripts
<cjwatson> Move it back to casper-bottom and add the "chroot /root" bits
<cjwatson> And what's its file name?
<pragomer> please look. I use it like that: http://pastebin.com/pVamXHwZ
<cjwatson> 27, OK
<cjwatson> But please listen to me otherwise
<pragomer> ok.. putting it back to casper-bottom
<cjwatson> I'd also suggest making it 27wireshark rather than 27-wireshark - none of the other files there have that dash
<cjwatson> The reason to be picky about it being in casper-bottom is that if you put it there then you can clean up your stuff by making it be in a package that ships the file there
<cjwatson> And then that package is harmless when installed on non-live systems
<cjwatson> Since casper-bottom is only used on live systems
<cjwatson> Anyway, in either case, all of the stuff in initramfs-tools scripts is run in the initramfs context, with the real root filesystem on /root at that point
<pragomer> ok.. please wait.. I am trying it
<doko> Laney, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016/+build/7654349  could you fix this and upload to the silo?
<pragomer> cjwatson: so you mean I have to put an chroot /root in front of every line of the "27wireshark" script?
<cjwatson> pragomer: yes, because all of those commands must be executed in the real root filesystem
<pragomer> cjwatson: oh.. learned something.. I thought that at this stage "I would be in the real system"
<cjwatson> pragomer: also, pretty sure you mean addgroup --system not addgroup -system
<cjwatson> pragomer: you are not, no
<pragomer> cjwatson: but I works with only "- system".. becaus the script as it works (when executing it manually)
<cjwatson> pragomer: don't you prefer to follow the documented correct form?
<pragomer> sure :-)
<cjwatson> If -system works, you are lucky, but have no right to expect to remain lucky
<pragomer> ok.. remastering runs.. have to be 30min afk.. reporting to you later . thank you so much until here..
<Laney> doko: yes, but not immediately - could you file a bug in debian too please?
<doko> Laney, sure.
<pragomer> cjwatson: you said these scripts in casper-bottom are no "init-scripts".. how should I call them? boot-scripts?
<cjwatson> pragomer: initramfs boot scripts
<pragomer> cjwatson: jippie. it worked.. main fault was the chroot I think.. thank you so much for you help
<cjwatson> cool
<pragomer> just if you want.. another small problem.. when doing the remaster via chroot everything runs automatically to the end, except the question about if wireshark should create this wiresharkgroupe (its dpkg-reconfigure wireshark).. this I always have to accept manually..
<pragomer> I mean when installing via chroot apt-get install wireshark
<cjwatson> pragomer: DEBIAN_FRONTEND=noninteractive, probably
<pragomer> cjwatson: cool.. never heard this.. how do I use this? with apt-get install?
<pitti> just put it in front of apt-get install, yes
<cjwatson> it's an environment variable that controls the operation of debconf.  you'd set it ... that
<cjwatson> if you want a non-default answer to the question it asks, you'll need to preseed that, probably using debconf-set-selections
<pragomer> cjwatson: very cool.. thank you so much
<pragomer> cjwatson: sorry.. I used it like that : http://pastebin.com/BSbixgM7   And it did not work. Doing it wrong?
<pitti> pragomer: no, not a separate command -- put it *right in front* of the apt-get, like chroot ... DEBIAN_FRONTEND=noninteractive apt-get
<pitti> your's is a no-op
<pitti> well, it works if you would add an "export" before it
<pitti> (seriously, this is really basic shell knowledge..)
<pragomer> you are right.. sorry.. I never really needed to export shell environment.. but now I remember.. thank you pitti
<cjwatson> It wouldn't even work with export, since chroot starts a new shell
<cjwatson> but yes, please look up shell syntax before asking
<pitti> arges: when you said "unblock ddebs.u.c.", you only meant the new/informational cloud test runs, right? (http://autopkgtest.ubuntu.com/packages/c/crash/wily/amd64/)
<pitti> arges: as the ones on the (still) production infra fail for a different reason (WARNING: /usr/lib/debug/boot/vmlinux-4.0.0-4-generic and /proc/version do not match!)
<pitti> like in http://d-jenkins.ubuntu-ci:8080/job/wily-adt-crash/12/ARCH=amd64,label=adt/console
<pitti> arges: looks like some weird parsing error, or perhaps /proc/version has changed with the new kernel or so?
<infinity> pitti: Eh?  The crash autopkgtest failure is because of the missing ddebs thing I was complaining about.
<pitti> infinity: ah, ok
<infinity> pitti: Installed kernel is -4.7, but ddebs for -4.7 are missing, so it installs -4.6
<pitti> infinity: it sounded like arges meant the "can't access ddebs.u.c." error which we saw on the cloud tests
<pitti> (which I'm also fixing)
<pitti> infinity: I'm through with the worst britney stuff, will look at kernel ddebs after lunch
<infinity> pitti: crash also has a bug in its autopkgtest where it fails to check -proposed for ddebs if the installed kernel is from -proposed, but that's not your fault. :P
<doko> Laney, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792494
<ubottu> Debian bug 792494 in src:evolution-data-server "evolution-data-server fails to build with GCC 5 from experimental" [Important,Open]
<Laney> doko: is it okay to just change the symbols file like that?
<Laney> (thanks for the bug)
<doko> Laney, are the symbols part of the library API?
<pitti> cjwatson, infinity: FYI, the date argument ("today", "yesterday" or "YYYYMMDD" is obsolete now, this just applied to apache-based downloads; I'll drop it for clarity
<Laney> doko: I would guess not, seem leaked from icu, but didn't check thoroughly
<doko> Laney, have a look if these are weak symbols
<Laney> doko: seems so
<doko> then you can probably skip these
<Laney> is a good patch to add old and new with optional?
<doko> wouldn't hurt. but if you sync/merge, please update the ci-train ppa as well
<Laney> ok, will do, waiting for a bugfix before updating to 3.16
<pragomer> Hi... whats wrong about: for i in $(find . -type f); do ls -l "$i"; done     Has problems with "space character"
<TJ-> pragomer: "find . -type f -ls"
<TJ-> pragomer: What you currently do is assign the space-separated output of the find command to i, so any files with spaces in their paths will get split up in different iterations of i
<cjwatson> And if you're doing something more complicated than ls, then either use -print0 | xargs -0 or use one of the -exec variants (preferably -exec command {} + or -execdir command {} +)
<mdeslaur> slangasek: patch for sbsigntool in bug 1474541
<ubottu> bug 1474541 in sbsigntool (Ubuntu Wily) "sbsigntool broken by update to openssl 1.0.2c" [High,New] https://launchpad.net/bugs/1474541
<pragomer> TJ-: Cant I get the complete folder path - included space characters - into $i ??
<pragomer> print0 | xargs -0 is great I know... but I need the file-path in a variable to specifiy an output path
<doko> TJ-, do you still want to backport openjdk-8?
<pitti> cjwatson, infinity: bazinga! http://bazaar.launchpad.net/~ubuntu-archive/ddeb-retriever/trunk/revision/159
<pitti> the old test saw that -4.7 was already there, but failed to realize that it only had armhf/i386/ppc binaries; it didn't look at the ddeb's architecture
<pitti> so anything which would build several hours before or after other architectures would be affected
<pitti> I'll re-run the thing from Mid-April on (thanks Launchpad for keepign all ddebs!)
<pitti> I also committed http://bazaar.launchpad.net/~ubuntu-archive/ddeb-retriever/trunk/revision/160 to make this a bit less painful exercise
<cjwatson> pragomer: find -print0 gives you the full path from the start directory, just as your earlier broken command was trying to do
<infinity> pitti: <3!
<pitti> http://ddebs.ubuntu.com/pool/main/l/linux/ has the ddebs now, just not indexed yet (as I was running with --download-only)
<infinity> pitti: I'm going to quit ~we-love-pitti, just so I can rejoin.
<pitti> lol
<cjwatson> pragomer: there are ways to get it into a variable for further processing, but doing it safely in the presence of unusual characters in file names requires very careful use of shell and if you're having difficulty with setting environment variables correctly then I think that would be a bit much!  You might be better off with a more powerful language at this point.
<cjwatson> pitti: ah, excellent, thanks for that!
<cjwatson> my bad
<cjwatson> pitti: 160> you'll lose out on Pending, but maybe that's OK as you'll probably get them later anyway
<pragomer> cjwatson: find . -type f | while read i; do vcs "$i" -n 4 -o "$i.png"; done
<pragomer> find . -type f | while read i; do vcs "$i" -n 4 -o "$i.png"; done
<cjwatson> and you can't match those directly either
<pitti> cjwatson: yeah, that's what I thought; I just saw an awful lot of Deleted (from -proposed) and superseded scroll by
<pragomer> vcs is a script to get images out of videos... and it expects -o output path
<pitti> cjwatson: so I don't think it's a net delay, as we match them against Packages.gz anyway
<pragomer> in this case it only handles the first file found
<pitti> cjwatson: if someone wants to use that without apt, they can just as well grab the ddeb directly from LP
<infinity> pragomer: find | while read; seems to work for me?
<cjwatson> pragomer: find . -type f -print0 | xargs -0r -I{} vcs {} -n 4 -o {}.png
<infinity> That's more foolproof, sure.
<infinity> But while read is working fine too.
<infinity> $ find . -type f | while read i; do echo "$i"; done
<infinity> ./bar baz/file2
<infinity> ./foo/file1
<cjwatson> while read works as long as your filenames do not contain newlines, indeed.
 * infinity nods.
<cjwatson> Which is pretty rare and breaks lots of other stuff, but you never know.  I prefer to write code that won't break even in that case, if I can.
<cjwatson> pitti: Right
<infinity> Newlines in filenames really should have been banned by POSIX.  Such pure evil.
<cjwatson> Also, | while read can be useful, but it also has pretty surprising behaviour with variables set inside the loop
<cjwatson> Oh, while I'm here, this works fine too:   find -type f -execdir vcs '{}' -n 4 -o '{}.png' \;
<pragomer> cjwatson: thank you so much: worked fine with xargs.. didn know how to get the input in the variable {}
<infinity> cjwatson: execdir.  That's a new one to me.  I assume {} is basedir()ed, despite the manpage leaving that detail out? :P
<infinity> Err, basename()d.
<pragomer> thank you @LL !!
<cjwatson> infinity: Yes.  The info docs clarify, although even then only if you read the section on -exec as well.
<infinity> cjwatson: Well, that's super handy.  Now to figure out how to etch that in a bit of brain mush that survives more than a few minutes, so I never use -exec again.
<caribou> Question regarding rsyslog merge : in the pre-merge version (7.4.4) there is no test being run on package build
<caribou> in the Debian version (8.9.0) tests are introduced
<caribou> but a few tests, according to the upstream dev, may be racy and cause false negative.
<caribou> There is a few I hit regularly when I build but most of them run fine.
<infinity> caribou: If it turns out that those racy tests are problematic, disable just the broken ones?
<caribou> infinity: that's the question I was about to ask
<infinity> caribou: Really, if a test is known-racy, it's not much of a test at all, and upstream should be skipping them until they're fixed. :/
<infinity> caribou: But we can skip them if they won't.
<caribou> infinity: well, according to rainer, they only work in very specific controlled environment
<caribou> infinity: ok, I'll disable them. Thanks!
<infinity> caribou: Anyhow, baby and bathwater, la la la, don't disable the whole testuite just cause a few tests are crap, figure out how to disable the crap ones.
<caribou> indeed, especially since there are quite a bunch of them that run fine
<infinity> caribou: If upstream knows what these controlled environments are, they should be checking for them, and skipping the tests if they're not in said env.  Many packages conditionally run some tests that way.
<caribou> true
<infinity> ie: python skipping a whackload of tests of there's no network, coreutils skipping some tests if it doesn't find certain types of files (my favoutite one being "found no files in /tmp that aren't owned by you -- skipping")
<caribou> btw, https://merges.ubuntu.com/main.html seems to be borked
<cjwatson> [Wed Jul 15 13:48:21 2015] [error] [client 10.172.192.14] OSError: [Errno 13] Permission denied: '/var/www/.launchpadlib'
<cjwatson> sigh
 * cjwatson goes to fix
<cjwatson> caribou: fixed, thanks
<caribou> cjwatson: thank to you !
<TJ-> doko: openjdk-8 has been working fine for me so far but I'm not familiar with any test-suite that should be run through to detect regressions against existing packages
<slangasek> mdeslaur: thanks!
<infinity> pitti: That ddeb-retriever is taking an impressive amount of time. :)
<doko> Mirv, looks like slangasek uploaded some more qt packages to the silo. do you consider these part of qt5?
<doko> On 7 July, Matthias mentioned that he's also planning the GCC 5 transition,
<doko> and we don't want to do both transitions at the same time, so Python 3.5 is up
<doko> first.
<doko> barry, slangasek: I didn't say that python3.5 is first ... this is cowboying ...
<doko> we'll do the GCC change around July 30, so maybe add it as a supported version before, but don't change the default
<slangasek> doko: the mail says specifically that he's uploading today to add python3.5 as supported, not default
<barry> doko, slangasek right.  only supported as of today
<pitti> infinity: yeah, mopping up all ddebs since April :) I suppose that'll take a full day or so
<pitti> infinity: I thought we should bite the bullet, as this probably affects a lot more debs
 * pitti -> badminton, cu tomorrow
<slangasek> tyhicks: hey, the bug log on bug #1430557 says you were working on this issue... are you still working on it?  the current behavior is truly hateful :)
<ubottu> bug 1430557 in schroot (Ubuntu) "sbuild / schroot unmounted encrypted home directory" [High,Triaged] https://launchpad.net/bugs/1430557
<tyhicks> slangasek: I was working on a different bug, which may be a dupe of that bug
<tyhicks> let me get "my" bug
<tyhicks> slangasek: https://launchpad.net/bugs/1427264
<ubottu> Launchpad bug 1427264 in schroot (Ubuntu) "using ecryptfs, creating frameworks fail to bind mount issues" [High,In progress]
<tyhicks> slangasek: I submitted a patch to upstream but they haven't commented
<tyhicks> slangasek: I'll poke the bug again
<slangasek> ok
<doko> tjaalton, could you have a look at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016/+sourcepub/5214294/+listing-archive-extra ?
<doko> tjaalton, nm, found it
<ari-tczew> bdmurray: thank you for your efforts for making Merge-o-Matic better! \o/
<ari-tczew> bdmurray: could you in a bit free time take a look on bug 681375 ? I guess it'd easy to fix for you :-)
<ubottu> bug 681375 in Merge-o-Matic "Adding unnecessary blank line at the end of debian/changelog" [Undecided,New] https://launchpad.net/bugs/681375
<pitti> slangasek: FYI, I set up a second autopkgtest worker on the other scalingstack region, so I now have 20 instances max
<pitti> slangasek: with that the performance looks like roughly on par with the current infrastructure
<pitti> slangasek: counting the number of "in progress" on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html (also on trusty/vivid) it even seems to be a tad faster
<pitti> slangasek: so, yay :)
<slangasek> pitti: nice!  do we have the capacity on scalingstack today to cut over?
<pitti> slangasek: given the above, I'd say yes
<slangasek> pitti: unless the launchpad team is going to come yell at you for using 20 instances? :)
<pitti> slangasek: it still needs some handholding and analyzing the tmpfails, but yesterday and today I was doing mostly just that
<pitti> slangasek: yeah, I still hope I'm not stepping on wgrant's feet with that, I asked on the RTs several times
<pitti> slangasek: anyway, IS said they are going to add a new beefy box to each of the regions RSN, so we can get some more power
<pitti> slangasek: e. g. today with doko's python3.5 enablement I'm using the full steam; but on most days it's not running on max capacity
<pitti> slangasek: so, I think I'll continue to sort out problems this week, Laney volunteered to keep an eye on it next week while I'm on holiday
<pitti> slangasek: and after that I think we should be good to switch over
<pitti> slangasek: still need to teach britney to take these results into account instead of the old adt-britney ones of course, but that should be easy
<slangasek> pitti: awesome!
<pitti> slangasek: I sent an RT for opening access to armhf and ppc64el boxes FYI, let's see how that goes
<pitti> we can use that as an example of how we're going to AMQPify and de-jenkins-ify e. g. boottest, and add real iron testing to this
<pitti> I'd really like to get rid of this 'orrible duplication of boottest.py in britney
<pitti> PSA: taking down autopkgtest.ubuntu.com and re-deploying from scratch
<pitti> because I can :)
<pitti> (I simplified/moved some bits, want to test the charm)
<slangasek> pitti: ok, you've decided it's worth wiring this up to the existing armhf and ppc64el boxes, rather than waiting for scalingstack on those?
<pitti> slangasek: well, it's not much work really, and having a worker which talks to LXC or e. g. adb which isn't in the cloud is useful IMHO
<slangasek> ok
<pitti> if it's not too much trouble for IS to open up the firewall holes, that is
<pitti> I explained the general intent, and hope we can discuss this now
<pitti> so that when we need it for e. g. boot test, or real iron testing of snappy or whatnot, we've been through that procedure once
<pitti> hah, and http://autopkgtest.ubuntu.com/ is back (syncing results in a few mins)
 * pitti fell in love with juju
<cjwatson> slangasek: I don't think our quotas are going to magically deflate or anything just because pitti's using his quota - our number of virt builders doesn't decrease.  There might be overcommit, I don't know
<cjwatson> slangasek: but I have a ticket in for turning brownie and comet into scalingstack compute nodes, and if IS are planning to add another couple, that would be great
<pitti> cjwatson: I don't know whether there's overcommit, but given that both buildd and test VM workloads tend to come in peaks, it would make sense to have it
<pitti> I added some logic to retry after 5 mins if nova fails due to hitting the limit
<cjwatson> pitti: I assume that the new beefy boxes are independent of the existing buildds we're reusing, since as far as I know all the ex-buildds are going into lgw01 (otherwise they'd have to be physically moved)
<cjwatson> pitti: yeah.  shouldn't be too much of a problem
<pitti> cjwatson: ok; please let me know if it does impact you, then I'll dial it back a bit
<cjwatson> pitti: TBH, our metrics aren't great, we might not notice for quite a while *cough*
<pitti> ATM I'm using 16 instances (8 on each region) max in parallel (I didn't want to max it out yet)
<cjwatson> I think we'd basically just start caring if the virt queue started growing
<pitti> cjwatson: well, do you get some error if nova boot fails with a quota issue?
<cjwatson> pitti: it would probably cause builders to fail to reset.  that does happen occasionally
<cjwatson> I rather suspect that it would be a ridiculously opaque failure mode of some kind
<cjwatson> aren't the quotas in terms of number of instances though?
<cjwatson> we don't scale our number of instances dynamically, any adjustments there would be done by IS
<pitti> cjwatson: there's quotas for #instances, #cpus, #mem, and #disk, all independelty
<pitti> cjwatson: e. g. I hit a quota with my 8th instance when I allocate 3 m1.large
<pitti> (some tests need an m1.large, most use m1.small)
<pitti> cjwatson: "nova absolute-limits" FYI
<cjwatson> pitti: our use is static though, we just reboot lots (effectively)
<pitti> cjwatson: ah, that would help; so I can't "steal" capacity from buildds then
<pitti> I keep creating and destroying images
<pitti> err, instances
 * pitti waves good night
<bdmurray> barry: does python-apt need to be rebuilt with python3.5?
#ubuntu-devel 2015-07-16
<barry> bdmurray: yes, it will
<bdmurray> barry: okay, I did that then
<Unit193> pitti: Howdy.
<pitti> Good morning
<pitti> hey Unit193, how are you?
<Unit193> I think I'm alive, but I'd have to check. :)
<Mirv> doko: no, those other Qt packages are not from qt.io upstream, so not part of Qt as such. but our stack has a lot of other Qt/QML modules too.
<pitti> I'm stunned, what am I doing wrong?
<pitti> -rw-r--r-- 1 root root 289 Jul 16 08:11 /etc/init/autopkgtest-worker.conf
<pitti> $ sudo initctl status autopkgtest-worker NAME=1
<pitti> initctl: Unknown job: autopkgtest-worker
<pitti> I even tried initctl reload-configuration and rebooting
<pitti> (that's on trusty)
<pitti> s/status/start/ of course (it fails with any command)
<sarnold> pitti: tru initctl --system
<pitti> same
<sarnold> pitti: iirc trusty introduced the user session stuff, and automatically uses --user if the right environment variable is available
<pitti> sarnold: right, but no $UPSTART_SESSION and no user upstart instance running
<pitti> either way, --system doesn't help, and I'm calling this through sudo
<pitti> "initctl status ssh" works fine, it just doesn't seem to like my custom job
<pitti> this is an "instance" job, but trusty has other jobs with "instance"
<pitti> Jul 16 08:25:04 autopkgtest kernel: [  768.186277] init: /etc/init/autopkgtest-worker.conf:12: Unknown stanza
<pitti> aah!
<pitti> here's to useful error messages
<sarnold> aha :)
<LocutusOfBorg1> hi folks, how do you feel about syncing virtualbox from experimental?
<LocutusOfBorg1> I uploaded yesterday 5.0
<LocutusOfBorg1> I don't see a way to sync from experimental with requestsync
<seb128> LocutusOfBorg1, -d experimental?
<LocutusOfBorg1> oops bad monday :) thanks
<LocutusOfBorg1> that kind of monday that persists until saturday I mean
<seb128> lol, I see
<LocutusOfBorg1> usually with backportpackage -d means "destination"
<LocutusOfBorg1> so I got confused ;)
<LocutusOfBorg1> bugs filed, thanks
<seb128> yw!
<dholbach> good morning
<seb128> hey dholbach
<dholbach> hey seb128
<doko> Laney, seb128, Mirv: poppler ftbfs with the current qt5, see http://paste.ubuntu.com/11887104/
<doko> triggered by
<doko> # enable all the hardening options
<doko> export DEB_BUILD_MAINT_OPTIONS = hardening=+all
<doko> that's what adds the -fPIE
<Mirv> right, Qt 5.4.2 bans now -fPIE usage
<Mirv> more info at http://code.qt.io/cgit/qt/qtbase.git/commit/?id=36d6eb721e7d5997ade75e289d4088dc48678d0d + http://code.qt.io/cgit/qt/qtbase.git/commit/?id=3eca75de67b3fd2c890715b30c7899cebc096fe9
<doko> I'm now just uploading a poppler with that commented out to the silo 16
<Mirv> with GCC 5
<Laney> doko: not "-pie"?
<doko> no, -fPIE triggers the macro
<cjwatson> FYI, all newly-created amd64/i386 LP builds will now be dispatched to scalingstack (lcy01-*/lgw01-*), even if they're in non-virtualised archives such as the primary Ubuntu archive or ci-train silos
<cjwatson> Retries of builds created prior to this change will still go to the bare-metal build farm for now, until we're confident enough in things to do the more invasive database surgery
<Laney> doko: Sorry, was checking - I mean hardening=+all,-pie
<doko> Laney, sure, but's the default in Ubuntu anyway
<Laney> well we're not using that here, so needs fixing
<pitti> Laney: does that look correct? http://paste.ubuntu.com/11887745/
<pitti> kde4libs is blocking too much, and apparently there's no interest in fixing it
<pitti> Laney: so far I modded results.history, but this should last a bit longer
<Laney> pitti: looks right to me - do you have a hint entry in the britney config file?
<pitti> Laney: no, I'm going to commit that next
<Laney> right
<pitti> Laney: http://paste.ubuntu.com/11887766/
<Laney> nod
<pitti> Laney: both committed; I'll check excuses
<Barbariandude> Hello! I'm anxiously awaiting the arrival of AMDGPU from the 4.2 kernel. If I were to compile and test it myself (for my R9 285 GPU), would I also need to compile and install the AMDGPU branch of Mesa as well?
<commander_> #ubuntu-devel
<commander_>  hello i am packing a Qt webkit based application am confused what should i put as dependencies my app executable ldd output is here in pastebin http://pastebin.com/mfgdrEtz
<commander_> popey,  hello i am packing a Qt webkit based application am confused what should i put as dependencies my app executable ldd output is here in pastebin http://pastebin.com/mfgdrEtz
<ikonia> try ##ubuntu-app-devel ?
<ikonia> oops one #
<ikonia> not two
<commander_> ikonia, thanks i joined it
<commander_> yeah i got it
<bdmurray> barry: python-apt has an autopkgtest regression, did something else need uploading first?
<barry> bdmurray: it's unclear.  it builds right?  i wasn't able to do any dep-8 tests in the ppa, so my first order of business will be looking at clearing python3-defaults promotion issues
<bdmurray> barry: yes, it builds. here is the failure - https://jenkins.qa.ubuntu.com/job/wily-adt-python-apt/lastBuild/ARCH=amd64,label=adt/artifact/results/log/*view*/
<barry> bdmurray: ah, PendingDeprecationWarning printed to stderr
<barry> shouldn't be hard to fix
<barry> bdmurray: i'll take that one first
<bdmurray> barry: okay, thanks!
<pitti> infinity, Laney, slangasek: FYI: "run-autopkgtest --help" on snakefruit if you want to (re-)run an autopkgtest; e. g. "run-autopkgtest -s wily -a i386 libpng" (if you skip -a it'll run on all arches)
<pitti> infinity, Laney, slangasek: ^ in the cloud, that is
<pitti> infinity, Laney, slangasek: it's very simple-minded right now, and we'll probably extend it to do stuff like "re-run all failed/tmpfail tests" or something such, we'll learn the use cases over time
<pitti> but that should be good enough for next week while I'm away
<pitti> infinity: yay, the ddeb-retriever run from hell finally finished
<Laney> pitti: cool, thanks - I guess the eventual goal is to provide something for uploaders in general to retry stuff?
<pitti> Laney: if we can somehow hook u1 auth to that, sure
<pitti> sso, I mean
<pitti> Laney: then again, we've never had this anyway, so it's not a regression
<Laney> no, but it's been an annoying wart of the current setup that only (~canonical â© (~ubuntu-core-dev âª ~ubuntu-release)) or so can retry things
<pitti> Laney: well, I'm not sure whether we want so many people hit retry buttons all the time, given our limited resources
<pitti> but in practice we actually have the opposite problem, not enough people watching excuses.html
<pitti> but then again, cleaning up requires lots of overrides, which is ~u-release
<pitti> I spent an hour yesterday to flush out tons of stuff that got stuck
<Laney> not pretending that retrying can fix everything, does help sometimes though
<pitti> yes, especially with uninstallables
<pitti> Laney: anyway, it's a question of "how to get SSO there", not "I want to keep my toys for myself"
 * Laney nods
<Laney> for me it's "I don't want to have to do button clicking for people" and "I don't like requiring membership of ~canonical for Ubuntu dev tasks". :)
<Laney> WTF, 16:12 and I haven't had lunch
 * Laney brb
<jamespage> mterry, hey - thanks for all the MIR reviews - much appreciated
<mterry> jamespage, yw, good break from other work for me  :)
<jamespage> and if there are any archive-admins around, we have a hole load of main promotions that can be done for wily to unblock dep-waits for numerous openstack bits and pieces
<slangasek> pitti: will there be a way for developers to rerun a test from the web ui, like exists today for jenkins?
<pitti> slangasek: lots of work and doesn't seem like a blocker, so not at the top of my list right now
<pitti> if we can get it behind SSO, sure
<slangasek> pitti: right, no need for it to be at the top of the list, I just don't like the idea of retries having to be managed by a small set of people with ssh access to the right server
<pitti> slangasek: extending this to "everyone in canonical" is reasonably easy, but as it requires VPN extending it beyond that is lots more work
<pitti> err, not actually VPN, we just need to open the firewall; but again, need to find a way to put SSO in front of rabbitmq
<slangasek> right, so having that in the web interface would be nice :)
<pitti> ac
<pitti> k
 * Laney likes that the same discussion just happened twice :P
<bdmurray> mvo: regarding apt-clone if o.origin is empty and archive is not now, is it fair to say the package was installed from a .deb file?
<mvo> bdmurray: most likely in this case the Release file has nothing/not much set in its headers. there is no distinction right now for "from-some-archive" or "from-dpkg-directly"
<bdmurray> mvo: got it
<barry> where is codespeak-lib 1.4.30-1?  this failure makes no sense: https://launchpadlibrarian.net/211833349/upload_7660667_log.txt
<hjd> barry: Hm... If you search for the binaries, you can find that they do indeed exist http://packages.ubuntu.com/wily/python3-py, but seem to have come from a completely different package https://launchpad.net/ubuntu/+source/python-py
<barry> hjd: ah from that changelog it looks like maybe codespeak-lib source package should be removed from the archive?
<hjd> Looks like it. Just found https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792109
<ubottu> Debian bug 792109 in ftp.debian.org "RM: codespeak-lib -- ROM; renamed to python-py" [Normal,Open]
<barry> hjd: looks like i should remove-package -s it from ubuntu too
 * barry something else since apparently -s doesn't mean "source" any more
<barry> slangasek, infinity perhaps has permission for ^^ ?
<bdmurray> pitti: Do you have any plans for an apport upload before your holiday? I'm thinking about bug 1470572.
<ubottu> bug 1470572 in apport (Ubuntu Vivid) "native-origins.d information causes apport to strip origin information from Package" [High,Triaged] https://launchpad.net/bugs/1470572
<bdmurray> slangasek: in MIR bug 1315313 oxide-developers ended up being subscribed to the package which isn't a team in the package to team mapping. Do you think the MIR process should include a list of team names?
<ubottu> bug 1315313 in ninja-build (Ubuntu) "[MIR] ninja-build" [Undecided,Fix committed] https://launchpad.net/bugs/1315313
<slangasek> bdmurray: as long as there's a process for adding other teams to the list also
#ubuntu-devel 2015-07-17
<infinity> pitti: We'll want to probably turn that into an SSO-gated web service at some point, so we can keep the "if you can upload, you can retry tests" paradigm.  But it's probably fair to say that not many people do that right now (and it's also unfortunately limited to just Canonical), so we can live with a bit of a regression while we sort it.
<infinity> pitti: Oh, and I see both Laney and slangasek already covered that.  Nevermind. :P
<pitti> Good morning
<pitti> bdmurray: I do, yes; I want to loo into bug 1474539 still
<ubottu> bug 1474539 in apport (Ubuntu Wily) "FTBFS with Python 3.5" [High,In progress] https://launchpad.net/bugs/1474539
<pitti> infinity: how is it a regression? non-canoncial folksk can only see the public jenkins which is read-only like autopkgtest.u.c.
<infinity> pitti: It's a regression because now even fewer people have access than before.
<pitti> infinity: and we can make run-autopkgtest available for everyone in canonical (if we widen the firewall to allow more hosts than just snakefruit)
<infinity> pitti: Sure, if it was accessible from lillypilly or something, but then that would be a regression in another direction, if you're doing no authorization agaisnt LP creds, since now non-devs would be able to abuse it.
<infinity> pitti: Ultimately, it should have the same permissions that "retry a build" has in LP itself, that is, anyone who can upload should be able to retry.
<infinity> s/who can upload/who can upload that package/
<pitti> I didn't do SSO yet; do you happen to know some doc pointers how to do that?
<infinity> pitti: Not so much, no.  I'd probably ask William for pointers in the right direction.
<pitti> well, I guess I'll ask on canonical-tech@ after my holidays
<pitti> I have about three day's worth of stuff to catch up with today already anyway :)
<infinity> pitti: Heh.  Yeah, this isn't critical, especially since it's running in parallel until you get back.
<pitti> ok, gutenprint is being ridiculous: http://autopkgtest.ubuntu.com/packages/g/gutenprint/wily/i386/
<pitti> I bumped the timeout three times, I introduced a "long tests" category yesterday with a timeout of ~ half a day
<infinity> pitti: But we definitely don't want snakefruit-only people to become the gateway for this, and I'd rather not see "anyone with a lillypilly account can mangle any test" either.
<pitti> and it's *still* not enough
<pitti> infinity: ~ubuntu-core-dev sounds about right for now, I'd say
<infinity> pitti: Though, having the "webapp" bit stay on snakefruit might not be awful.  And then a small CGI that does proper LP validation, and a CLI tool in ubuntu-dev-tools that talks to that?
<pitti> Canonical folks in ~ubuntu-core-dev, I mean
<infinity> pitti: It certainly doesn't need a pretty GUI.
<pitti> we don't really want to open this up too wide, especially not once we start supporting PPAs
<infinity> pitti: I disagree.
<infinity> pitti: I had the very same knee-jerk reaction/argument that you did about resource usage and the "retry" button on LP.
<pitti> we don't even yet have enough capacity to keep up with the flood at peak times now
<wgrant> pitti: OpenID integration is pretty easy for you. Use python-openid (probably without a team restriction) against login.ubuntu.com, then use launchpadlib's lp.people.getByOpenIdIdentifier to look up a person which you can give to archive.checkUpload for permission checks.
<infinity> pitti: But, in the end, it seems that people fall into a few groups: 1) people who know how it works and have access and don't abuse it, 2) people who don't know how it works and never press it, 3) people who abuse resources by retrying over and over.
<infinity> pitti: The size of set 3 is tiny.
<infinity> pitti: And when we find them abusing resources, we yell at them and carry on.
<pitti> infinity: okay
<pitti> checkUpload() seems fine to me
<pitti> those are people who have been vetted at some point
<infinity> pitti: Anyhow, since you're now sharing the same cloud as LP buildds, same rules applying also makes sense.  Jerks will be jerks, but they're actually amazingly rare.
<pitti> I just really don't want to open this up to the whole world
<infinity> pitti: And we employ most of them, so they already have access in the canonical+core-dev set. :P
<infinity> *cough*
<pitti> wgrant: ack, I'll look into that; I'll file a bug for now to record this
<infinity> pitti: Of course, we'd all like to live in a world where the infra is so reliable that retries never need to happen, because a failure is always a real failure, but I'm pretty sure we'll never get there. :)
<pitti> bug 1475491
<ubottu> bug 1475491 in Auto Package Testing "provide web-based "retry test" functionality" [Undecided,New] https://launchpad.net/bugs/1475491
<infinity> (We sure never got there with package builds)
<pitti> yeah, for sure
<pitti> we can do better than the current infra for "temp" failures (uninstallable, weird test bed boot/reboot failures), but there's enough left
<pitti> right now I do most retries due to testbed failures
<pitti> and that's what I'd like to reduce massively
<infinity> pitti: Yeahp.  Temp/testbed failures not happening would be a huge help.
<pitti> so that most retries should then be for flaky tests
<pitti> like this pitti guy whose udisks2 tests are flapping *cough*
<infinity> pitti: But then, the nature of autopkgtest being integration tests means that Package B will fail because Package A sucks, so fixing A means I need to retry B.  Putting that power in the hands of developers helps a lot.
<pitti> so, what do I do about gutenprint..
<infinity> pitti: Though, I suppose we could also be smarter about retriggering in such cases?
<pitti> infinity: no, if you upload A, B will re-run automatically
<infinity> pitti: remove-package -m "lolwut" gutenprint
<pitti> I can't imagine that the DD is actually running these successfully
<infinity> pitti: Only if A and B are hard interdependents.  Something, somewhere, will always be broken in an unexpected way.
<pitti> oh, OdyX -- I'll ask him
<infinity> pitti: Like, say, the "ddebs was bust, so crash tests failed" case.
<pitti> infinity: right; transitive deps, etc.
<pitti> infinity: I'm not arguing to take away the retry button :)
 * infinity nods.
<pitti> just saying that I didn't get to implementing one yet
<infinity> MAKE IT BIG AND SHINY.
<pitti> it's like systemd -- one-man show, too much to do, the less important stuff has to wait :)
 * pitti does the daily libreoffice retry (speaking about flappy tests)
<pitti> once the cloud stuff becomes primary in britney and it actually tells apart between always fail/regression, I'm really pondering to have britney retry a regression once
<infinity> pitti: I wonder if we could do flap detection based on history.  ie: if a test's recent history is >> 33% fail (or some arbirtary number), retry a few times.
<pitti> infinity: yes, britney can do that, it has the test history in a big dict
<infinity> pitti: And once that creeps back up to 100% (fail or success), back off.
<pitti> infinity: so "retry once after a regression" or retry more often based on pass percentage etc., but I figure the above simple thing should already help
 * didrocks remembers to have been yelled to propose that to the QA team a couple of years ago (even if we still put a warning that this testsuite was flacky)
<pitti> if it fails more often, then the dev should really do something about it
<pitti> ooohh, a didrocks !
<didrocks> for autopilot tests, not autopkgtests at the time
<didrocks> hey pitti ;)
<pitti> didrocks: bienvenue !
<pitti> didrocks: as-tu eu des bonnes vacances ?
 * pitti te donne une accolade
<didrocks> pitti: merci ! oui, les vacances Ã©taient superbes ;)
 * didrocks donne une accolade en retour
<infinity> didrocks: For tests originating from Ubuntu/Canonical, I think it's sane to set the bar higher.
<infinity> didrocks: For tests we inherit from Debian, while we should certainly file bugs and ask them nicely to fix things, it's annoying to be "held hostage" by racy/flapping tests.
<pitti> didrocks: well, we had higher standards back then indeed; but since then infinity's and my retry finger went sore
<didrocks> infinity: yeah, but when it ends up on people doing the production to press "retry" because nobody fixesâ¦ :/
<pitti> TBH a lot of the Debian tests we import just always fail, and they aren't that much of a problem
<infinity> didrocks: I think "my finger hurts" is totally a good reason to yell at my coworkers to fix their *!^%! tests.
<pitti> the biggest problem there is when they regress and nobody fixes them
<infinity> didrocks: But for inherited tests, I'd rather build in some slop.
<didrocks> agreed in some way. And yeah, the biggest risk is this "this should be a flaky tests", when actually, it started to be a flaky regression
<infinity> didrocks: Quite.  If the test itself is working as advertised, but the code its testing has become nondeterministic/racey/whatever, that's harder to notice.
<infinity> And, honestly, unless we start tracking metrics and hitting developers over the head with test *history*, it's not a thing we're currently dealing with.
<infinity> Our test strategy is very binary.
<didrocks> yeah, and sometimes random as well, just based on gut feeling if things needs to enter or not because of time-constraint
<infinity> We certainly have the data to make it non-binary, though, we just need to figure out how to present that to people.
<didrocks> and not hurt feelings
<didrocks> while still showing up responsabilities (and the ownership feeling that people should have anyway)
<Mirv> scaling stack builders broken? https://launchpadlibrarian.net/211871932/buildlog_ubuntu-wily-amd64.qtdeclarative-opensource-src-gles_5.4.2-0ubuntu5_BUILDING.txt.gz
<Mirv> "long apt-get: relocation error: /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12: symbol _ZTVNSt7__cxx1119basic_istringstreamIcSt11char_traitsIcESaIcEEE, version GLIBCXX_3.4.21 not defined in file libstdc++.so.6 with link time reference"
<Mirv> -long
<Mirv> or I think this is related to the GCC5 silo only ^ doko
<doko> urgh, let me look
<doko> Mirv, argh, wrong config :-/ will fix
<doko> Mirv, fixed gcc building
<doko> Mirv, for local chroots, you might want to downgrade apt
<Mirv> doko: thanks
<doko> mvo, apt ping
<mvo> doko: should I add a workaround for the miscomplication with gcc-5? I can do that and upload with a abi change to the ppa - or should we force -O2 everywhere?
<doko> mvo, yes, please do. and forcing -O2 for now
<Mirv> mitya57: heya! any idea what's causing the pyqt5 autopkgtest regression? it's blocking a qtdeclarative landing, but failed already on Wednesday (last successful run on Saturday): https://jenkins.qa.ubuntu.com/job/wily-adt-pyqt5/ARCH=i386,label=adt/
<Mirv> maybe it's related to recent python-apt uploads rebuilding for python3.5
<doko> Mirv, gcc-5 fixed again in silo16 (armhf still building). if you upload before the build finishes, then b-d on gcc-5 (>= 5.1.2-11)
<Mirv> doko: thanks! I'll just kick a rebuild as possible the one upload I already did.
<Mirv> (wily got updated so therefore another upload to 016 too)
<pete-woods> packaging question - my builds have started failing on wily very recently
<pete-woods> an it looks like this bit of debian/rules that I didn't write is going wrong: http://paste.ubuntu.com/11892236/
<pete-woods> it looks like it installs the .py stuff for the autopilot tests for the package (indicator-network)
<pete-woods> this feels like copy/pasted code
<pete-woods> so just wondered if there was a newer "canonical" version of this magic lump of stuff
<pete-woods> or if it should be doing something different altogether
<pitti> how does it go wrong?
<pete-woods> pitti: https://launchpadlibrarian.net/211892414/buildlog_ubuntu-wily-amd64.indicator-network_0.5.2%2B15.10.20150717.1-0ubuntu1_BUILDING.txt.gz
<pete-woods> + python3.5 setup.py install --root=/Â«BUILDDIRÂ»/indicator-network-0.5.2+15.10.20150717.1/debian/tmp --install-layout=deb
<pete-woods> /bin/sh: 3: python3.5: not found
<pete-woods> (snip_
<pitti> /bin/sh: 3: python3.5: not found
<pete-woods> yeah
<pitti> pete-woods: ah, the package most probably build-depends on python3-dev, but it needs python3-all-dev
<pitti> pete-woods: or python3 where it needs python3-all
<pete-woods> pitti: thanks, will try that :)
<pitti> as it iterates over all supported versions
<pitti> and we now have 3.4 and 3.5
<pitti> this only works while there's just one supported version
<pete-woods> yeah, just figured that variable would list what's actually installed
<pete-woods> I guess it doesn't do that
<pitti> no, what Ubuntu supports
<pete-woods>                python3-dbusmock (>= 0.15),
<pete-woods>                python3-setuptools,
<pete-woods> is what we build-dep on
<pitti> yeah, you need python3-all then
<pete-woods> just add that in addition?
<pitti> (all python packages should have this)
<pitti> s/should/must/
<pitti> pete-woods: yes
<pete-woods> pitti: awesome, will get that changed :)
<pete-woods> possibly worth a ubuntu-developers email about this, as I suspect it will have caught out a number of people
<pitti> we've been through several ptyhon transitions; it should mostly affect new packages since we moved to 3.4
<pete-woods> sure, I just mean that a bunch of people probably blindly copied and pasted this lump of debian rules
<pete-woods>  / inherited it (in my case)
<pitti> the rules are fine
<pitti> it's debian/control's build-deps which are not :)
<pete-woods> right, but if they didn't understand the rules
<pete-woods> then they probably didn't do the control file right
<pitti> well, it's actually questionable whether you need to install autopilot helpers for *all* supported python3 versions, as they should all be in teh same path
<pete-woods> way outside my python expertise
<pete-woods> I usually like to see nearly empty debian rules
<pitti> yeah, this looks like a workaround of a broken upstream build system
<pitti> with proper build systems and pybuild it should be near-empty
<lifeless> barry: / doko: so this https://bugs.launchpad.net/ubuntu/trusty/+source/python3.4/+bug/1367907
<ubottu> Launchpad bug 1367907 in python3.4 (Ubuntu Trusty) "Segfault in gc with cyclic trash" [Undecided,Triaged]
<doko> lifeless, pending, waiting on slangasek to approve the upload in the queue
<lifeless> \o/
<lifeless> slangasek: anything we can do to help with that ?
<lifeless> doko: thanks
<Mirv> cyphermox: I filed a wishlist item bug #1475633 about syncing wpa to at least Debian stable's 2.3, depending on what seems best for the next LTS
<ubottu> bug 1475633 in wpa (Ubuntu) "New upstream version 2.4 / please merge with Debian 8's wpa 2.3" [Undecided,New] https://launchpad.net/bugs/1475633
<smoser> cyphermox, http://archive.ubuntu.com/ubuntu/dists/trusty-proposed/main/installer-amd64/current/images/netboot/ubuntu-installer/amd64/
<smoser> i think we need that kicked for bug 1402042, right ?
<ubottu> bug 1402042 in MAAS 1.7 "console= parameters need to be added before -- on kernel cmdline" [High,Triaged] https://launchpad.net/bugs/1402042
<smoser> maybe i'm wrong, but the timestamp on files there (jul 5) would seem to indicate that i can't verify that yet
<infinity> smoser: d-i will need a rebuild for that, yes.  I'll do that today, along with bumping the kernel versions.
<smoser> infinity, thnak you
<infinity> smoser: You're wlecmoe.
<infinity> smoser: We don't normally rebuild d-i for non-ltses, do we need this fix in utopic?
<smoser> i'm personally fine to leave utopic broken.
<smoser> but without fixing vivid maas has no stable release > trusty that it can expect sanity in installation.
<infinity> smoser: vivid should be fine already.
<infinity> smoser: It shipped with this fix.
<smoser> right.
<smoser> well, i'm ok leaving utopic broken, but you should check that with cyphermox  and slangasek .
<smoser> especially as it would seem the upload of d-i has been done.
<infinity> smoser: Althought, that said, utopic's had two d-i uploads post-release anyway, so why not one more.
<smoser> cool.
<infinity> smoser: No upload of d-i was done, just d-i-utils, but maybe that's what you meant.
<smoser> sure
<infinity> Hrm, a precise upload was done too.  Not sure I see the point in that, since precise doesn't use any of the affected kernels...
<infinity> smoser: Did you request precise for consistency's sake on the maas side?
<smoser> precise is a supported lts :).
<infinity> smoser: Sure, but it's also not broken.
<infinity> smoser: Since the bug here is newer kernels stripping '--', and precise doesn't run any of those kernels.
<smoser> well maas has ot install precise.
<smoser> and it would then have to either say "if i'm installing precise, then use -- otherwise use ---"
<smoser> and i think its much nicer if it just uses ---
<smoser> the code in maas that does this is not currently aware of the release that is being installed.
<infinity> smoser: Okay, that's what I was asking.  It does mean altering d-i to use --- as well, which is a behaviour change for non-maas users, but maybe they won't notice or care.
<cjwatson> The change to debian-installer-utils tolerates both, so it's a compatible change.
<infinity> cjwatson: Oh, I guess the d-i change was just how d-i boots its own images, wasn't it?  /me goes looking for the commit.
<infinity> http://launchpadlibrarian.net/199169893/debian-installer_20101020ubuntu366_20101020ubuntu367.diff.gz
<cjwatson> Indeed.
<infinity> Yeah, so I guess it's safe to not bother backporting that, since maas, I assume, boots linux/initrd with its own configs and doesn't use d-i's bootloader setup.
<infinity> Alright.
<infinity> smoser: Okay, I'll do a no-change d-i rebuild in precise and utopic for you for this as well, then.
<smoser> thank you infinity . and yeah, the change sure seems to be backwards compatible. outside the case wehre someone wanted '---' to be on their command lines.
<cjwatson> I think it might possibly be a good idea to backport that to avoid confusion with newer kernels, but it probably isn't required, indeed.
<cjwatson> Certainly a smaller/slightly-safer change if you avoid that.
<infinity> Oh, whee, that bug has the deleted tasks bug, so no d-i/precise task for me.  Oh well.
<infinity> cjwatson: If people are installing >> 3.18 with precise d-i, they're also rebuilding d-i, and they can keep both pieces if they don't backport that change, IMO. :P
<infinity> cjwatson: Certainly not a supported config from my POV.
<infinity> Or 3.15... Whatever it was.
<infinity> Hrm, if that really was 3.15, then utopic is broken too.  Neat how it never got noticed or reported until well into the wily cycle...
<infinity> s/wily/vivid/
<cjwatson> infinity: Yeah
<cjwatson> I'm fairly sure it was reported
<cjwatson> Just not tracked down
<cjwatson> ICBW though
<infinity> Earliest report I see is https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1411124
<ubottu> Launchpad bug 1427252 in installation-guide (Ubuntu Utopic) "duplicate for #1411124 installer ignores preseeding settings added after --" [High,Triaged]
<infinity> Hrm, yeah.  I'll backport that to utopic too.  Whee.
<pitti> utopic? doesn't that die in like 2 weeks?
<pitti> infinity: ^
<infinity> pitti: Yeah, but may as well make it work anyway. :P
<lolek> hi everybody, is this correct # for asking question related to dpkg features?
<lolek> I'm trying to do something like conditional build similar to this: http://www.rpm.org/wiki/PackagerDocs/ConditionalBuilds
<cjwatson> lolek: Very recent versions of dpkg have build profiles (https://wiki.debian.org/BuildProfileSpec), but it's new and not supported in all the higher-level pieces yet.
<infinity> smoser: Okay, cyphermox has other reasons to do d-i/trusty today, so he'll cover that one.  I'll get utopic up in a bit.
<infinity> smoser: And a no-change on precise.
<cjwatson> lolek: Otherwise you can just pass environment variables down, but if it requires different build-dependencies and you don't want to modify the source package, then you need build profiles.
<lolek> :/
<lolek> so I need to somehow make my own way to make different rules file depends on some conditions?
<cjwatson> If build profiles don't work for you, yes.  Sorry.
<infinity> lolek: Assuming you only care about >= wily, BuildProfiles are the right way.
<cjwatson> infinity: (well, they don't work in LP yet ... were you going to get round to those apt/python-apt SRUs?)
<infinity> cjwatson: He never said anything about LP. :P
<cjwatson> I know, but it's #ubuntu-devel :)
<smoser> well, 1402042 was reported in vivid cycle.
<cjwatson> most people around here at least end up in PPAs at some point.
<infinity> cjwatson: And, erk.  I've almost entirely forgotten about apt SRUs.  Thanks for the reminder. :/
<infinity> smoser: Right, all the bugs were reported in the vivid cycle, despite utopic, apparently, also having the bug.  That's what I was whining about. :P
<pitti> so my friends, that's it -- holiday o'clock! see you in 10 days!
<infinity> cjwatson: Yeah, but adding build-profile support to PPAs (as in, allowing people to set profiles) will be (a) work, and (b) a big can o' worms.
<infinity> pitti: Have fun!
<infinity> pitti: Don't do anything I wouldn't do!
<infinity> pitti: Do ALL THE THINGS I would do!
<pitti> infinity: like bicycling, tenting, and swimming?
<infinity> pitti: I've done all those things.
<pitti> infinity: as long as you've also eaten lots of ice cream, I'm good then!
<infinity> pitti: Though, they're not my first choices when I think "how could I improve my happiness?" :P
<cjwatson> infinity: Full support is non-trivial.  Not rejecting or failing to build packages that use that syntax in debian/control is much easier.
<cjwatson> Right now, direct uploads are rejected, and imports from Debian work but fail to build.
<infinity> cjwatson: Right, the backports to not break on syntax need to happen.  No dispute there.
<cjwatson> pitti: enjoy :)
<infinity> pitti: You staying on IRC and detached so you can get 2000 lines of nick highlights when you come back, or being sensible and logging off for once?
<pitti> nah, during holidays I usually kill bip :)
<infinity> pitti: Cause if you're staying around, I think I'll just prefix everything I say with your nick for the next week.
<pitti> I'll feel terribly disconnected and lonely without IRC, but the heck.. /me pulls the plug and waves
 * infinity sheds a tear.
<smoser> barry, you marked bug 1398059 as opinion are you hard stuck on that opinion?
<ubottu> bug 1398059 in python-virtualenv (Ubuntu) "virtualenv -p python2.6 fails with ValueError: zero length field name in format" [Low,Opinion] https://launchpad.net/bugs/1398059
<barry> smoser: do you really need python 2.6? ;)
<barry> smoser: it's a low impact change, so if you really do have a need for it, i'm not opposed to fixing it
<smoser> barry, well, cloud-init 0.7.x does support 2.6, and i want to support with cloud-init 2.0
<smoser> so being able to tox -e py26 is really nice (using deadsnakes repo)
<barry> smoser: is wily enough or do you need it to be sru'd?
<smoser> wonder if it works on trusty.
<smoser> trusty + wily'd be enough for sure.
<smoser> i absoultely agree that if there was a long stream of bugs on this, then it'd not be worth it.
<barry> smoser: hopefully when and if i get back to virtualenv work, this should be much better in the latest upstream version.  no eta on that (lots of hairy yaks need shaving first)
<barry> smoser: bug updated
<slangasek> doko: sorry, I missed that you had responded to my questions on the SRU bug - accepting it now
<slangasek> tyhicks: hmm why did you reassign bug #1473225 to pam? it looks to me that the submitter is right that this needs fixing in /etc/pam.d/login, which belongs to the login package, not pam
<ubottu> bug 1473225 in pam (Ubuntu) "with encrypted home, /etc/legal is printed twice on every login" [Undecided,New] https://launchpad.net/bugs/1473225
<tyhicks> slangasek: bah, I goofed up :)
 * tyhicks changes it back
<slangasek> tyhicks: ok :)
<bdmurray> mvo: Do you plans to fix bug 1383214 in Trusty?
<ubottu> bug 1383214 in wine1.6 (Ubuntu Vivid) "msiexec no longer works" [High,Fix committed] https://launchpad.net/bugs/1383214
<mvo> bdmurray: I'm not sure if its affected, if it is its probably trivial to backport the fix for that
<infinity> bdmurray: If the assumption that it's related to gcc-4.9 is correct, then trusty wouldn't be affected, just >= utopic
<infinity> mvo: ^
<mvo> infinity: ta
<infinity> Unless the 4.9 change was backported to the 4.8 branch, of course.  Those GCC people are special.
<mvo> :) it was a bit of a drive-by fix tbh, I don't know that much about wine. but it works for me(tm) :)
<bdmurray> mvo: Okay, thanks
<lifeless> slangasek: morning ?
<slangasek> lifeless: good morning!
<lifeless> slangasek: I have a question for you
<lifeless> 00:01 < lifeless> barry: / doko: so this https://bugs.launchpad.net/ubuntu/trusty/+source/python3.4/+bug/1367907
<ubottu> Launchpad bug 1367907 in python3.4 (Ubuntu Trusty) "Segfault in gc with cyclic trash" [Undecided,Triaged]
<lifeless> 00:01 < ubottu> Launchpad bug 1367907 in python3.4 (Ubuntu Trusty) "Segfault in gc with cyclic trash" [Undecided,Triaged]
<lifeless> 00:01 -!- MacSlow is now known as MacSlow|lunch
<lifeless> 00:03 < doko> lifeless, pending, waiting on slangasek to approve the upload in the queue
<lifeless> 00:01 < lifeless> barry: / doko: so this https://bugs.launchpad.net/ubuntu/trusty/+source/python3.4/+bug/1367907
<lifeless> 00:01 < ubottu> Launchpad bug 1367907 in python3.4 (Ubuntu Trusty) "Segfault in gc with cyclic trash" [Undecided,Triaged]
<lifeless> 00:01 -!- MacSlow is now known as MacSlow|lunch
<lifeless> 00:03 < doko> lifeless, pending, waiting on slangasek to approve the upload in the queue
<lifeless> 00:07 < lifeless> slangasek: anything we can do to help with that ?
<lifeless> but sufficient unto the porpoise :)
<lifeless> 00:09 < lifeless> doko: thanks
<lifeless> erm, double paste, single rainbow.
<barry> lifeless: i think slangasek already approved it
<lifeless> barry: I refreshed the bug, and couldn't see anything
<lifeless> barry: perhaps I'm looking in the wrong place...
<barry> lifeless: i could be wrong.  i think i saw a python3.4 package fly by, tho not sure the contents
<infinity> He accepted the python backport of doom, yes.
<infinity> https://launchpad.net/ubuntu/+source/python3.4/3.4.3-1ubuntu1~14.04
<infinity> And if it ever finishes on armhf, I might even let it out of NEW.
<lifeless> infinity: ahha, thanks
<lifeless> slangasek: sorry for the ping-nag
<slangasek> ah :)
<slangasek> hmm yes, the bug didn't get updated, that's odd
<slangasek> I know the bug was linked from the .changes file
<infinity> slangasek: sru-accept after the fact?
<bdmurray> slangasek: which bug? bug 1348954 was updated
<ubottu> bug 1348954 in python3.4 (Ubuntu) "update Python3 for trusty" [Undecided,Confirmed] https://launchpad.net/bugs/1348954
<slangasek> bdmurray: 1367907
<infinity> slangasek: Yeah, that's not in the .changes.
<infinity> Launchpad-Bugs-Fixed: 1264554 1348954
<slangasek> hrm
<slangasek> indeed not
<slangasek> I did somehow see that bug while reviewing the sru though
<slangasek> must've manually followed a changelog link
<infinity> It's impressive that an upload with a 37PB diff only fixes two bugs.
<lifeless> infinity: 37 **P**B ?
<Unit193> Well they do say Ubuntu got bloated... ;)
<infinity> lifeless: That might have been hyperbole.
<lifeless> infinity: just possibly :)
<lifeless> infinity: so the builds all finished; is it in NEW still ? [I'm not sure where to check these days]
<infinity> lifeless: It should be published in -proposed.
<lifeless> infinity: it is, thanks. clarkb just tested the build
#ubuntu-devel 2015-07-19
<watsug> Hi, I am using the Ubuntu SDK to try and go through the tutorial app "meanings". As per the tutorial https://developer.ubuntu.com/en/apps/html-5/tutorials/meanings-app-html5-tutorial/, you should the javascript to the app.js file, i dont have one, is this the same as the application.js file? The file doesn't look like it does in the tutorial? Have
<watsug> much changed in how the apps are built?
<dobey> watsug: this channel is more about the development of the base ubuntu system itself and is more packaging oriented. you want #ubuntu-app-devel for development of apps with the sdk. :)
<watsug> Okay, thank you!
<ochosi> hi everyone, why does status.ubuntu.com not receive any updates anymore?
#ubuntu-devel 2016-07-18
<pitti> stgraber: that worked fine, thanks
<tsimonq2> o/ pitti, how are you? :)
<tjaalton> did someone use MST with intel? I hear unity doesn't work right with it
<brendand> there seems to be an issue with qemu-img on yakkety - is anyone aware of this: http://paste.ubuntu.com/19876087/
<brendand> ah wait - maybe i don't have that image created#
<brendand> yeah, nm
<mwhudson> ogra_: aaaaaaaaaaaaaaaaaaaaa
<mwhudson> ogra_: at least some of my problems were because i wasn't running snapcraft to make ubuntu-core as root
<infinity> tinoco: Was anyone ever going to verify the SRUs for LP: #1529815 ?
<ubottu> Launchpad bug 1529815 in isc-dhcp (Ubuntu Trusty) "InfiniBand DHCP flow with PRA and DHCP relay not working" [Medium,In progress] https://launchpad.net/bugs/1529815
<Odd_Bloke> infinity: You were going to upgrade the kernel on the one powerpc builder that was still old (sagari?).  Has that happened?
<infinity> Odd_Bloke: Nein.
<Odd_Bloke> infinity: Ack; I'll leave our workaround in place then. :p
<ogra_> mwhudson, ah, ouch ...
<juliank> The python-apt uploaded triggered some regressions in ubuntu-make and click autopkgtests, but did not seem to cause them, AFAICT.
 * juliank is not sure what exactly is going on and does not have the time to investigate that
<Mirv> xnox: hi! any ideas about s390x https://launchpadlibrarian.net/273695893/buildlog_ubuntu-yakkety-s390x.qtbase-opensource-src_5.6.1+dfsg-3ubuntu1~1_BUILDING.txt.gz ? (search for "alignment 128")
<xnox> Mirv, how is Q_DECL_ALIGN actually implemented? with c++ alignas stuff?
<Mirv> xnox: lots of lots of ifdef, but yes maybe http://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/global/qcompilerdetection.h?h=5.6.1
<Mirv> if __has_feature(cxx_alignas) -> yes
<xnox> Mirv, smells like https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70066 to me
<ubottu> gcc.gnu.org bug 70066 in c++ "alignas imposes the wrong limit on data members" [Normal,Unconfirmed]
<Mirv> xnox: as a data point it did compile on Debian
<xnox> Mirv, fails on armhf too with same error so not s390x specific
<xnox> Mirv, reading the bug report... setting "CXX=c++" might change behaviour and succeed.
<xnox> Mirv, would be interesting to see if it builds in debian experimental with gcc6
<xnox> worth opening a bug report on launchpad about it, and then start forwarding to qt upstream and gcc upstream.
<xnox> doko is still away i'm gueesing?!
<xnox> or could you look into ^
 * xnox ponders to create minimal example from above
<Mirv> xnox: thanks for looking into it! it did fail similarly on xenial too. and it did succeed in debian experimental before it was uploaded to unstable. bug #1603991
<ubottu> bug 1603991 in gcc-5 (Ubuntu) "requested alignment 128 is larger than 64 on armhf and s390x" [Undecided,New] https://launchpad.net/bugs/1603991
<michael-vb> sladen, mitya57: https://bugs.launchpad.net/ubuntu/+source/libdbusmenu-qt/+bug/1604009
<ubottu> Launchpad bug 1604009 in libdbusmenu-qt (Ubuntu) "Empty menus in global app-menu in VirtualBox second window" [Undecided,New]
<nacc> slangasek: fyi, i think jquery-goodies is stuck in yakket-proposed becuse it was mismerged (the build-dep on yui-compressor was dropped, but the rules change to use it wasn't). In any case, I just filed a sync request (LP: #1604095)
<ubottu> Launchpad bug 1604095 in jquery-goodies (Ubuntu) "Sync jquery-goodies 11-3 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1604095
<slangasek> nacc: hmm, I noticed the build failure but didn't think it was a mismerge, I would've expected my merge process to catch that.  If the new version has the PHP7 compat fix, I'll happily sync that and wash my hands of it ;)
<nacc> slangasek: it seems like the change from "  * Use yui-compressor instead of uglifyjs (universe)." was only half-carried forward (specifically not s/node-uglify/yui-compressor/ in debian/control. But yeah, the sync will just fix it fine
<tinoco> infinity: i'll verify #1529815 by the end of this week. will reprovision the IB lab so I can make sure its good.
<slangasek> tinoco: note that "By the end of this week" means it will miss 16.04.1; the point release is this week, and image mastering is happening ASAP for validation for a Thursday release
<slangasek> tinoco: so there's probably no possibility of it being done in time for 16.04.1 if there's lab reprovisioning required first - just want to make sure you understood (and 16.04.1 was the reason for infinity's ping)
<sarnold> tinoco: hmm, pitti mentioned a verification-failed on a different bug, which appeared to get an automated validation-failed tag by a bot... my instinct is that the filed bug has nothing to do with the apparmor profile fiddling
<tinoco> sarnold: i think both SRUs were together and the other one failed, right ?
<sarnold> tinoco: .. the error in the log is "invoke-rc.d: initscript isc-dhcp-server, action "start" failed." but the apparmor profile that was modified was for /sbin/dhclient
<sarnold> tinoco: "failed" in that some random guy filed a bug with that version number
<sarnold> tinoco: not in the sense of "I tested it and it didn't fix my problem"
<tinoco> oo damn
<tinoco> so whats the best move here ?
<tinoco> i can verify 1529815 by tomorrow
<tinoco> just asked for IB machines and I was given access to 2 (which i can use to verify this)
<sarnold> tinoco: bdmurray already removed the verification-failed flag from 1568485 and added bot-stop-nagging to 1574226 ... I don't know if The Process would still allow 1529815 through but I think pitti's reason for rejecting it a month ago wasn't correct
<tinoco> yep.. if it allows i can verify lp1529815 by tomorrow
<tinoco> if not, i can propose a new patch for trusty and we can re-start sru
<rbasak> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping.
<infinity> tinoco: So, worth noting that version of dhclient is already built into d-i, because it was built with -proposed on...
<infinity> tinoco: Would likely be ideal to get your verification done ASAP tomorrow and I can respin images to match.
<infinity> tinoco: (Just xenial is all I care about right now)
<tinoco> infinity: will do first thing tomorrow. will ping you when done. tku!!
<infinity> tinoco: Ta.
<infinity> roaksoax: If you want that maas fix on 16.04.1 media, verify the bug ASAP once it's built.
<roaksoax> infinity: verified
<slangasek> roaksoax: thanks, I'll publish it shortly
#ubuntu-devel 2016-07-19
<nacc> cyphermox: someone in #ubuntu is indicating the grub update hard-froze several of their systems similar to https://ubuntuforums.org/showthread.php?t=2330915 's report. Any ideas?
<halvors> Hi.
<halvors> Where can i submit a request for the strongswan package to be updated to the newest upstream version? The current version is 5.5.0 the version on the repositories is 5.3.0
<halvors> I mean of course for the yakkety tree,
<halvors> three*
<sarnold> halvors: I think the requestsync program will do the right thing
<nacc> halvors: it needs to be merged, not sync'd
<nacc> sarnold: --^
<sarnold> ahh
<sil2100> tjaalton: hello!
<sil2100> tjaalton: I wanted to poke you about bug LP: #1585942
<ubottu> Launchpad bug 1585942 in mesa (Ubuntu) "Mesa causes a segmentation fault on arm64 (wrong count of uniform locations)" [Critical,Confirmed] https://launchpad.net/bugs/1585942
<sil2100> tjaalton: we're doing some xenial-arm64 based work for ubuntu touch and this blocks us as it is causing certain unit tests to fail during build
<sil2100> tjaalton: (so we can't get all arm64 binaries that we need)
<tjaalton> sil2100: ok, it's in yak now but the pkg is in NEW. and you need it for xenial too
<sil2100> tjaalton: is that mesa 12.0.1-3ubuntu1 ?
<tjaalton> ys
<tjaalton> +e
<sil2100> tjaalton: I see it's a new upstream release as well, will we need all of it in that case?
<tjaalton> no
<tjaalton> just that "devel first" wasn't true until this :)
<tjaalton> sil2100: the other components of the bug don't need updates for xenial?
<tjaalton> sil2100: uploaded
<tjaalton> i'll worry about a new point-release after vacation.. hoping 11.2.2 would be out by then
<rbasak> tinoco: your debdiffs in bug ssh-rsa
<rbasak> AAAAB3NzaC1yc2EAAAADAQABAAACAQDirUcwitpDz3WNArkqGco7pSv1BQPuSxPwcqxojMMMVflpDGjj8GYlIERLnAn2o2WZsQSBQ1TmD0O6evb2otwhW1m6xegj2/hv/CFVSy3UjjE7QVyewCUbA8JJkPRbnLo80yuuw+mbq4YXYphSmZoptnGxPXHC/HAnryzY9uqjr7u5cCMMUG8Ien74KKzRf2/P4ghJTkjdBttta/qlz1Iz9kH3CxYjXFAgTFaD7MQld7NOKx95Hp2WkMkiJXDMHXoSf7RNgrPuh65gGQVlsIrswrEBbSUGmzn1OPTCFeGmneekI1F8lB4447uaSsUQa+UiODbyhhNz9fU2c7lppOZoKxAPPpwnQgEcxOU2FL3IXkb5azk94Fqw
<rbasak> Kxvljo13IkuUvFDqGP0kLiWqh7k79v9tjR9fwI9krRJ4N6iz3RosjAxPS3ff9xs3lnSf2GxVootdUC564x98iT2CYJEqrCmoMdtiivnsIrRjUVjGO6xSAoIqYi+A+5ljTJwKAGqjQ0bkJwi0Rn++CnL44VnsHTWbQ7UtdRJZo0lvKY+1vXIcCApTD8wcb1uD/6nuS9HDy5xwOuxbamR1fqfKzsuuxwbzcO75Azu+q+2tIWnQKxbn56dWQTcY7QG2Q9CDWxsiRoHPl2ADx+7qcZGm7M7prDK/C6G0sxgseG/i6OZChAx1PQ== CPaelzer@Launchpad-RSA # ssh-import-id lp:paelzer
<rbasak> Uh, sorry.
<rbasak> cpaelzer: ^ :)
<rbasak> tinoco: your debdiffs in bug 1570678 look fine, but may I also add "to fix crash on ppc64el" to the changelog? Users review changelogs, so I think it's useful to summarise the justification for the SRU itself in them.
<ubottu> bug 1570678 in percona-xtradb-cluster-5.5 (Ubuntu) "mysqld got signal 11 during setting up root password on package installation on ppc64el" [Medium,In progress] https://launchpad.net/bugs/1570678
<rbasak> tinoco: otherwise it sounds like just a performance thing.
<rbasak> tinoco: also the trusty debdiff version is wrong - it should end 0.14.04.2.
<sil2100> tjaalton: thanks!
<sil2100> tjaalton: hm, did you upload mesa to xenial?
<sil2100> tjaalton: ah! Yes, I see it in the unapproved queue, thanks!
<sil2100> tjaalton: I checked it before but somehow my eyes missed it, ignore me ;)
<sil2100> Thanks again!
<Odd_Bloke> Grr, sbuild is unmounting my encrypted home directory when I build trusty packages.
<rbasak> darkxst: please could you re-review/sponsor the patch in bug 1550210? I have been cherry-picking from the sponsorship queue today, but am not confident in following what you said.
<ubottu> bug 1550210 in imagemagick (Ubuntu) "Desktop file does not open ImageMagick from the menu" [Medium,Triaged] https://launchpad.net/bugs/1550210
<tinoco> rbasak: sure.. would u fix it during sponsorship or you would like me to change debdiffs and re-attach ?
<cjwatson> pitti: Would you mind having a look at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-ci-train-ppa-service-landing-019/xenial/ppc64el/u/ubuntu-system-settings-online-accounts/20160718_054019@/log.gz ?  I've tried playing around in chdist and can't work it out.
<rbasak> tinoco: I'm happy to fix during sponsorship. I'll do it today.
<tinoco> rbasak: tks!! i'll verify isc-dhcp-server sru then.
<cpaelzer> The policy doc isn't entirely clear to me - can .symbols files hold comments?
<cpaelzer> There is some rather uncommon behaviour that I'd like to add as comment so the next one looking at it doesn't have to go all the way again
<ogra_>        Note that you can put comments in symbols files: any line with â#â as
<ogra_>        the first character is a comment except if it starts with â#includeâ
<ogra_>        (see section Using includes).  Lines starting with â#MISSING:â are
<ogra_>        special comments documenting symbols that have disappeared.
<ogra_> http://man7.org/linux/man-pages/man1/dpkg-gensymbols.1.html
<cpaelzer> thanks ogra_!
<ogra_> :)
<cpaelzer> a lot of documentation is great until you won't find it due to all the docs :-)
<infinity> tinoco: Any progress on isc-dhcp?
<pitti> cjwatson:
<pitti> Broken ubuntu-system-settings:ppc64el Depends on powerd [ ppc64el ]
<pitti>  powerd | 0.16+16.04.20160204.1-0ubuntu1         | xenial/universe  | source, amd64, armhf, i386
<pitti>  powerd | 0.16+16.04.20160204.1-0ubuntu2~xenial1 | yakkety/universe | source
<pitti> cjwatson: it's not just because there is no powerd on ppc64el?
<ogra_> powerpc is power(d)less !
<pitti> powerd is really broken in yakkety
<pitti>  powerd | 0.16+16.04.20160204.1-0ubuntu2~xenial1 | yakkety/universe | source
<pitti>  powerd | 2016.06+16.10.20160706.1-0ubuntu1      | yakkety/universe | all
<pitti> or rather, the source is not building any binaries any more, and powerd is a transitional package; although in the overlay they reverted that and brought back powerd
<pitti> so, not a clue, being on a sprint, something for later..
<cjwatson> pitti: Yeah, but when I try it with chdist and the right set of archives for this test, it picks gnome-settings-daemon instead
<cjwatson> pitti: (the dependency is powerd | gnome-settings-daemon or some such)
<pitti> indeed, and it doesn't seem to like that either
<pitti> I'll keep a tab for the log
<tinoco> infinity: im doing it right now
<ricotz> jamespage, hi, I guess something went wrong with ceph since it doesn't get stripped
<jamespage> ricotz, yeah I'm baffled
<jamespage> apparently I've forgotten all of the important stuff about distro devel
<jamespage> hmm override_dh_strip is still in .PHONY
<ricotz> jamespage, this might help https://anonscm.debian.org/cgit/pkg-mate/plank.git/commit/?id=fdf38328bea736e64c906f2c3cefecf232622df2
<mdeslaur> kees, infinity, stgraber: tech board meeting now
<tinoco> infinity: done. lp1529815 verified.
<tinoco> sorry for taking so long, i had to steal some HW in the lab
<jamespage> ricotz, thanks for the pointer
<jamespage> tomorrows work
<slangasek> cjwatson: snappy is making use of grub2's loopback and squash4 modules to access kernel/initramfs from inside the kernel snap package at boot time.  I've just noticed neither of these are in the signed EFI binary.  Do you have any concerns about either of these being signed for SB?
<cjwatson> slangasek: seems reasonable
<slangasek> cjwatson: ok.  any particular level of auditing you think is needed on these, or should I just add them?
<cjwatson> slangasek: loopback should be trivial.  squash4, may be worth doing a general sanity audit of the code looking for places where a corrupt filesystem might convince it to jump into space
<slangasek> that was my intuition as well, though I had hoped I was wrong ;)
<slangasek> ok, will look for someone sane to audit
<cjwatson> It's not *too* long
<slangasek> :)
<cjwatson> Thanks
<teward> bugs with commands such as `tail` should be filed against coreutils, right?
<nacc> teward: looks like it (at least for tail)
<teward> nacc: that's what I thought
<teward> ('tail -n #' no longer prints just that number of items, like its manpage says, in yakkety)
<teward> nacc: see #1604511
<teward> if you're curious :P
<nacc> teward: doesn't seem like the current delta shoudl have that effect (or if it does, undocumented). Wonder if it's an upstream regressin/change
<teward> nacc: indeed.  That said, this is a ***massive*** change
<teward> because `tail -n` has always been there
<nacc> teward: yeah, seems unintentional :)
<cjwatson> I don't buy it.
<teward> cjwatson: that it's a change or that the bug exists?
<cjwatson> The version of coreutils in yakkety is the same as that in xenial.
<infinity> I can't reproduce.
<teward> hmm
<teward> *nukes server, starts again*
<cjwatson> It works fine in xenial, and coreutils by nature has very few external dependencies.
<teward> cjwatson: yeah, this is making me scratch my head, because this is *new* behavior
<infinity> teward: It can *look* like it's behaving that way if you lose all your line endings to some weird binary corruption.
<cjwatson> What does "tail -n /var/log/apt/history.log | wc -l" say?
<infinity> But I definitely can't reproduce your example.
<teward> oh you know what...
<teward> it looks like this is a problem with the system i'm connecting from to the server - its SSH client uses hard breaks instead of soft wraps for when data goes over the line
<teward> my bad.
<teward> as a result, one to many lines listed >.>
<teward> this is why i hate NOT having my ubuntu system for testing things
<teward> (Bug invalid)
 * teward grumbles
<teward> i should've checked that, sorry for noise
<teward> i asked rbasak to peek, but anyone else want to do a review of a merge debdiff for any blaringly evil screwups I may have made?  Not uploading immediately, but would like to get a review before I PPA build it for testers to test it.
<teward> (see debdiffs on https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1580252 if you care to, otherwise i can wait)
<ubottu> Launchpad bug 1580252 in nginx (Ubuntu) "Please merge nginx 1.10.1-1 (main) from Debian Unstable (main)" [Wishlist,In progress]
<infinity> - This is a dependency package to install either nginx-core (by default),
<infinity> - nginx-full, nginx-light, or nginx-extras.
<infinity> + This is a dependency package to install either nginx-full (by default) or
<infinity> + nginx-light.
<infinity> teward: You undid that change, looks like.
<nacc> teward: might be my own ignorance, but it's kind of hard to follow that all the delta has been accounted for with each ubuntu version, as the stuff that (presumably) has been dropped isn't explicitly mentioned (e.g., 1.9.15-0ubuntu1 mentions adding a build-dep, and it's mentioned as being carried forward in 1.10.0-0ubuntu1, but 1.10.1-0ubuntu1 makes no mention of it?
<infinity> teward: And some php5/php7 stuff.
<teward> oops
<teward> this is why i need eyes on things :P
<infinity> teward: I don't have the patience right now to go over the meat of the merge, though.
<teward> not a problem :P
<teward> :) *
<infinity> It's complicated enough that it's one of those "the best way to review would be for me to do my own merge and then compare" situations.
<teward> nacc: the readd of libluajit-5.1-dev as a build-dep is less of a delta.
<teward> infinity: ack
<teward> nacc: Debian already ahd it
<teward> has*
<teward> nacc: 'readd' was 'drop the delta'
<nacc> teward: i see; i guess my practice is to have each changelog mentioned in a previous version accounted for, that's all i meant
<nacc> *each changelog entry
<teward> ahhh ok
<teward> I only have ever documented the remaining changes between the merge and *debian*, but eh
<teward> infinity: it's a PITA, this one, because Debian implemented their 'hybrid' packages.  that said, the packaging needs to update ahead of anything openssl 1.1.0 ever being available, to prevent future FTBFS
<teward> (i.e. 1.11.x at least in the interim non-LTS releases)
<teward> no clue on the 1.1.0 openssl timelines though
 * infinity nods.
<nacc> teward: sure, that makes sense too, i think; since i'm still relatively new, it's more of future-proofing that i've not forgotten something :)
<teward> there's HTTP/2 fixes i want in there too
<teward> s/I want/that should be/
<teward> i've got a case of the lazies / work-busys so it's one of those things I can let sit a few days
<teward> nacc: indeed.  I actually grab the last "Remaining changes:" section, and run a checklist to see if it's already been dropped in the changelogs between, or if there's anything new, etc.
<teward> so to each their own, being overly verbose doesn't hurt.  I just prefer saying "These are the differences"
<teward> ... that reminds me, thanks infinity for the php stuff, that's missing from the delta changelog
<nacc> hrm, trying to figure out why icinga failed to build on on non-amd64 (https://launchpad.net/ubuntu/+source/icinga/1.13.3-2ubuntu1). I just ran sbuild locally with and without proposed in a i386 schroot and it build fine in both. My delta shouldn't have resulted in any real changes, and it's already been rebuilt once in yakkety (so it's not a binary copy-forward).
<infinity> nacc: How did you call sbuild?
<nacc> infinity: http://paste.ubuntu.com/20067963/
<infinity> nacc: It has nothing to do with "non-amd64" it's "not building arch:all in the same pass".
<infinity> nacc: Get rid of -A, watch it fail.
<nacc> infinity: ah i see
<nacc> infinity: thank you
<nacc> infinity: fwiw, the existing yakkety version also ftbfs w/o -A, so did a default flag change in the builders?
<infinity> nacc: No.
<infinity> nacc: But dpkg-buildpackage changed to require policy-required targets, and call them.
<nacc> infinity: ah, ok
<infinity> nacc: So, you're likely missing build-arch/build-indep
<nacc> infinity: yep, digging into that now, looks to also already be filed as a debian bug
<nacc> infinity: thanks, have a fix now, will send it in and to debian
<nacc> rbasak: ok, icinga with the latest version should !FTBFS again, and all our delta has been submitted to debian
<rbasak> nacc: may I add "to fix FTBFS" to your changelog entry? In case a merge turns out to be needed, knowing why will help.
<nacc> rbasak: sure!, thanks
<nacc> rbasak: sorry, i thought about that, but wasn't sure it was applicalbe given that it was only in -proposed, but in retrospect it obviously is
<rbasak> np
<nacc> rbasak: ideally, debian will take it via that bug (to which i sent the debdiff)
<nacc> rbasak: ok, upon review, and talking to tgm4883 a bit, i'm ont sure there is an easy way to do what you want. The 'defaultfor' implementation in puppet takes as input a hash (not a condition) and just tests for (in the case of an array) membership. I don't think there's any way for me to test for non-membership (which is what you were usggesting).  The systemd_spec.rb chagne is for testing only
<nacc> (afaict), so maybe is less urgent. I think if upstream does take this change (https://github.com/puppetlabs/puppet/pull/5069) we could add a regex, but ubuntu's versions don't lend themselves to a clean (all versions greater than 15.04 regex that i can think of)
<rbasak> nacc: what I don't understand is that surely this logic already applies but in reverse, and that's what the bug is? It's defaulting to upstart on Ubuntu (but presumably not other distros), except for particular releases where it defaults to systemd. Why can this not be reversed using the primitives that already exist?
<rbasak> nacc: do you see what I'm saying? What am I missing?
<nacc> rbasak: i see what you're saying now
<nacc> rbasak: doesn't mean i know how to do it yet :) but yeah
<nacc> rbasak: ah i see where the confusion is, i think
<nacc> rbasak: so in the version in yakkety, there is no such 'default'
<nacc> rbasak: it's all version-specific (upstart or systemd)
<nacc> rbasak: http://paste.ubuntu.com/20088025/
<nacc> rbasak: the issue is the 16.04 version is not specific to that
<nacc> sorry, the 16.04 puppet does not have those version-specific changes, so the default for all "ubuntu" is upstart still
<rbasak> nacc: what does 16.04 do
<rbasak> ?
<nacc> rbasak: http://paste.ubuntu.com/20089298/
<nacc> rbasak: note, i just tried something, i installed the current yakkety version
<rbasak> nacc: OK, so can we make Yakkety do what Xenial is doing but in reverse?
<valorie> hello folks, yofel put out the tester call last night: 16.04.1 candidates are out: http://iso.qa.ubuntu.com/qatracker/milestones/363/builds
<rbasak> nacc: I think it's fine to deviate from upstream on this as it's clearly less broken this way. In fact, IMHO that's exactly what upstream should do, too.
<nacc> rbasak: hrm, i see what you're saying
<valorie> however all links seem to be broken - zsync, rsync, wget from http, straight from http
<nacc> rbasak: except if upstream did that, then they couldn't test their upstart support on 14.04 with the latest puppet
<rbasak> nacc: why not? upstart on 14.04 would have upstart defined as defaultfor 14.04, no?
<valorie> http://paste.ubuntu.com/20013301/
<valorie> if this is not the proper place to report, where is?
<rbasak> nacc: upsteam defaultfor 12.04, 14.04 and maybe 15.10, and systemd default for everything else ubuntu.
<rbasak> (also 10.04 if wanted)
<nacc> rbasak: one sec
<nacc> rbasak: let me try and write out what I understand
<infinity> valorie: s,daily,xenial/daily, and you're good to go.
<infinity> stgraber: I'd love you forever if there's an easy way to fix all those that doesn't involve hand-editing every project. :/
<valorie> infinity: the test site should be fixed though?
<infinity> valorie: Ideally, yes.  See above complaint to stgraber.
<valorie> good
<valorie> that did indeed work, so I'll spread the fix around #kubuntu-devel
<valorie> thanks
<infinity> valorie: Ta.
<nacc> rbasak: ok, now i'm really confused; the test script that sdeziel provided *only* fails on 16.04 if you have the upstart package installed ...
<infinity> valorie: FWIW, a fresh respin is in progress as we speak.
<infinity> nacc: I'm not entirely caught up on backscroll, but testing distros and versions of distros to determine the init system is just plain wrong.
<infinity> nacc: Assuming that's what's happening.
<infinity> nacc: [ -d /run/systemd/system/ ] is the way to know you're using systemd, for instance.
<nacc> infinity: might be well and true, but i assume that's something i'd just file with puppet and let them figure out? / it's their choice to do it wrong, if they so choose?
<rbasak> infinity: even worse, 16.10 is hardcoded to be systemd. My objection is that it'll explode as soon as Yakkety+1 opens.
<infinity> nacc: Sure, it's their choice to be stupid, I guess, but it's our choice as downstream to be less stupid.
<rbasak> Which IMHO is worse than hardcoding.
<infinity> And if people use upstream puppet on Ubuntu, it's in our best interest to make upstream be as not stupid as we are.
<rbasak> than *just* hardcoding, that is.
<nacc> well, i'm trying to figure out *if* we're broken at all
<nacc> rbasak: i think there might be a bug in that if you have the upstart package installed (not necessarily configured to be your init-system, afaict), puppet does the wrong thing
<rbasak> nacc: I did think the logic was "default to upstart, except for *these* releases". If that's wrong then I don't object so much.
<nacc> but by default it seems to be controlling services correctly
<stgraber> infinity: I probably have a script or some sql somewhere that I used for trusty
<nacc> rbasak: so roughly, ubuntu 16.04's code-logic: everyting ubuntu is upstart; ubuntu 16.10's code logic: these releases are upstart, these releases are systemd.
<infinity> stgraber: If you could do that again, that would be lovely.
<stgraber> infinity: basically the tracker knows about the pattern for the current dev release (no series name) and then this can be overriden per-series
<nacc> rbasak: but i'm still trying ot understand exaclty what checks for that and where and why :)
<stgraber> infinity: let me check, I "think" there is a "copy-downloads" script on limequat for that
<infinity> stgraber: Yeah, I know.  But editing each one by hand sucks. ;)
<infinity> Anyhow, I need drugs and sleep.
<rbasak> nacc: in 16.10, what happens if the release doesn't match?
<nacc> rbasak: that's what i'm trying to figure out now (and also why it seems to "work" in 16.04 w/o any patches)
<rbasak> OK
<nacc> infinity: ah! i think upstream puppet does what you're suggesting on debian, but not ubuntu; not sure why ...
<nacc> infinity: also, this is purely about hte 'default's, i think it still checks for presence somewhere else
<stgraber> infinity: done, I think
<stgraber> I messed things up twice while doing the change but looks like yakkety and xenial links are plausibly right now
<infinity> stgraber: Danke.
#ubuntu-devel 2016-07-20
<snkcld> when i run "sbuild -A -d xenial-amd64 bluez_5.37-0ubuntu8.dsc", i am getting an error at "renaming `/etc/apt/trusted.gpg' to `/etc/apt/trusted.gpg~' failed: Invalid argument", i tried stracing (following forks) but i can not seem to find the error... any clue why this is happening? the fact that its related to a file rename makes me think it might be a
<snkcld> filesystem issue (im on btrfs), but im able to create files with a ~ just fine
<nacc> snkcld: i wonder if /etc/apt/trusted.gpg maybe doesn't exist for some reason?
<snkcld> on the it seems to exist on the host and in the chroot
<nacc> snkcld: yeah, i meant in the schroot; ok
<nacc> snkcld: sbuild-update --keygen is mentioned at https://wiki.ubuntu.com/SimpleSbuild
<snkcld> ok let me run through those steps once more
<nacc> snkcld: sure
<nacc> pitti: if you're around, had a samba question for you (re: MR: #293440 and LP: #1604630)
<ubottu> Launchpad bug 1604630 in samba (Ubuntu) "16.04 SAMBA missing winbind packages during install" [Undecided,New] https://launchpad.net/bugs/1604630
<jbicha> pitti: or whoever, why does oslo-sphinx's 'Testsuite: autopkgtest-pkg-python' fail with 'SKIP no tests in this package'
<jbicha> it also says autopkgtest: build not needed and doesn't look like it even installs the oslo-sphinx binaries
<snkcld> nacc: same thing
<nacc> snkcld: strange ...
<snkcld> i entered the chroot, and was able to install e.g. vim just fine
<snkcld> but that wouldnt invoke gpg anyway
<snkcld> any idea what command might be running, which is invoking gpg, to have it rename trusted.gpg?
<snkcld> OH, i think i am onto something: "mv: cannot move '/etc/apt/trusted.gpg' to a subdirectory of itself, '/etc/apt/trusted.gpg~'"
<snkcld> it seems that trusted.gpg~ is seen as... a directory?
<snkcld> though its a file, when i look at it
<snkcld> eh, that may have actually been me invoking "mv" incorrectly, ignore that
<snkcld> nacc: do you happen to be using btrfs or not?
<snkcld> i noticed this, too, btw: "This does not work if /tmp is mounted under btrfs due to incompatibilities with aufs"
<snkcld> fwiw: /tmp does not seem to be mounted as tmpfs
<pitti> nacc: I have no clue about samba I'm afraid
<jamespage> pitti, hey - would you have a little time to help me figure out why I managed to bloat out the ceph packages with debug symbols with my last upload?
<jamespage> https://launchpad.net/ubuntu/+source/ceph/10.2.2-0ubuntu3/+build/10487267
<jamespage> I thought that dropping the dh_strip overrides and the -dbg packages would be sufficient to kick in the builds based stripping
<jamespage> but evidently not
<infinity> dh_strip_nondeterminism <-- Did dh_strip get renamed in a recent debhelper?
<infinity> pitti: ^
<infinity> Oh, no, that's different entirely.
<infinity> jamespage: dh_strip doesn't seem to get called in your build at all now...
 * infinity scratches his head.
<jamespage> infinity, I do have an override_dh_strip in .PHONY still
<infinity> jamespage: That could be it
<jamespage> that's my suspicision - but with a 4 hour build turnaround atm I'd like to have a high confidence that's all good
<infinity> jamespage: http://paste.ubuntu.com/20154493/
<jamespage> infinity, ta
<infinity> jamespage: Store --no-act away somewhere for future use.  Very handy. :P
<jamespage> infinity, great tip - thanks
 * jamespage ties a load of builder up for a bit
<pitti> jdstrand, tyhicks: I'm trying to update /etc/apparmor.d/abstractions/dbus-session-strict for the dbus peer address /run/user/<uid>/dbus (which replaced the abstract @/tmp/dbus* thing)
<pitti> jdstrand, tyhicks: however, I keep getting "unix rule: invalid value for addr='/run/user/*/bus'" errors
<pitti> with peer=(addr="/run/user/*/bus"),
<pitti> I also tried with changing * to 1000, or with /run/user/**, nothing works
<pitti> and the manpage doesn't say how to specify path based sockets; halp?
<pitti> infinity: yes, dh_strip_nondeterminism is for reproducible builds, replacing time stamps etc.
<infinity> pitti: Yeah, I realized after reading the manpage. :P
<infinity> pitti: Also, peer=(addr="@/run/user/[0-9]*/bus"), ?
<pitti> but @ is wrong
<pitti> it's not an abstract socket, it's a path
<infinity> Oh.
<infinity> pitti: Does the dmesg audit have anything interesting to say?
<pitti> [  159.822302] audit: type=1400 audit(1469003934.773:28): apparmor="DENIED" operation="connect" profile="/usr/lib/telepathy/mission-control-5" name="/run/user/1000/bus" pid=2862 comm="mission-control" requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=1000
<pitti> pretty much what you'd expect
<pitti> oh
<pitti> maybe we need to give separate permissions for the file
<pitti> that wouldn't fix the syntax issue, but explain why it still doesn't work with completely dropping peer=
<pitti> I added   /run/user/*/dbus rw,
<pitti> and recache/restart, no change
<LocutusOfBorg> hi, can anybody please have a look at ben?
<LocutusOfBorg> http://people.canonical.com/~ubuntu-archive/transitions/html/html/ocaml.html
<LocutusOfBorg> Clicking on "transitions" brings to file://index.html
<LocutusOfBorg> probably missing a ../
<LocutusOfBorg> looks like the issue is fixable here? http://bazaar.launchpad.net/~ubuntu-transition-trackers/ubuntu-transition-tracker/ben/view/head:/frontends/ben_monitor.ml
<LocutusOfBorg> Laney, ^^ :)
<LocutusOfBorg> hi jbicha, do you plan to have a look at libpqxx sadness?
<LocutusOfBorg> I would like to avoid having a delta from debian that is an epoch bump
<hrw> hello
<hrw> anyone with grub2 knowledge?
<hrw> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1603083
<ubottu> Launchpad bug 1603083 in grub2 (Ubuntu) "please provide a standalone grub image" [Undecided,New]
<hrw> added test image, renamed bug
<infinity> hrw: What's the usecase for a standalone image?  We provide an image for netboot.
<hrw> infinity: cirros image (minimal one for openstack) needs grub-efi binary to be bootable on aarch64, x86-64/efi platforms
<hrw> infinity: initially I used centos grub-efi binaries but smoser (cirros maintainer) prefers to use ubuntu one
<hrw> I renamed bug in meantime: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1603083
<ubottu> Launchpad bug 1603083 in grub2 (Ubuntu) "standalone grub image does not see GPT partitions" [Undecided,New]
<hrw> infinity: ideas?
<infinity> hrw: Not currently, it was just a drive-by question.  I don't have the time today to think much about it.
<hrw> infinity: ok
<jamespage> infinity, yeah small debs and ddeb's - https://launchpad.net/ubuntu/+source/ceph/10.2.2-0ubuntu4/+build/10492159
<jamespage> thanks for your help
<infinity> jamespage: NP.
<hrw> hm. looks like I found solution ;D
<hrw> have to test
<hrw> does ubuntu images contain /.disk/info file?
<hrw> long time since I used ubuntu
<hrw> nevermind
<nacc> pitti: ok :)
<smoser> tjaalton, i just filed https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1604819
<ubottu> Launchpad bug 1604819 in xorg-server (Ubuntu) "intel driver (intel_drv) not loaded" [Undecided,Confirmed]
<smoser> latest xorg-xserver ends up with me using vesa driver.
<tjaalton> smoser: read my comment, it's not using vesa but modesetting which is the new default
<tjaalton> fbev/vesa are lower on the list of fallback drivers
<tjaalton> *fbdev
<smoser> was just reading your changelog entries, and yeah figured it was related to those.
<tjaalton> the real bug is the flickering screen, which is likely a kernel bug that -intel hid away
<smoser> possibly, yeah.
<tjaalton> you can try with newer kernel mainline builds first, and add results there. then use the xorg.conf until there's something else to try
<tjaalton> intel will look into all these from now on
<tjaalton> got their word on that :)
<smoser> so how to add that xorg.conf ?
<tjaalton> read the comment :)
<smoser>  /usr/share/doc/xserver-xorg-video-intel/xorg.conf just has the single Section
<tjaalton> and it's enough
<smoser> thats all thats necessary ? (been probably 5 happy years since i've looked at an xorg.conf)
<tjaalton> smoser: thanks for testing 4.7-rc7, mind give 4.6 a spin?-)
<tjaalton> *giving
<smoser> shoot
<smoser> i was just going to tell you thank you for your help and that i was going on my way :)
<tjaalton> hehe
<smoser> tell me what to try and i will
<tjaalton> mainline build of 4.6.x
<smoser> 	v4.6.3-yakkety/ seems latest
<smoser> right?
<tjaalton> yep
<smoser> ok. will try
<smoser> you should probably re-title that bug to somethign that is remotely close
<smoser> :)
<tjaalton> I did
<tjaalton> back to what it was
<smoser> ok.
<tjaalton> leave a note on the bug if 4.6 works, I'm signing off now
<nacc> bdmurray: so 7 of the php7.0 sru 'errors' are these debconf issues I don't have a lead on (and don't seem to be related to the package necessarily): https://errors.ubuntu.com/problem/e4de08d8bf5a70d8b04970d2a3823529b7a56706 (and similar)
<nacc> mdeslaur: --^ as well
<nacc> bdmurray: mdeslaur: i'm looking through the other ones
<mdeslaur> hrm, yeah, I don't think that's related to the actual package. I see those types of errors from time to time, but I've never looked at what was causing those.
<mdeslaur> bdmurray: do you have any idea what causes those? ^
<mdeslaur> is it when someone cancels an install half-way though?
<bdmurray> mdeslaur: Nope, I've no idea.
<mdeslaur> bdmurray: you've seen them too, right?
<mdeslaur> launchpad is full of them
<bdmurray> mdeslaur: yes, I've seen them for lots of different packages
<nacc> yeah, it's very strange; it does seem like a broken pipe (that line in the perl file)
<rbasak> I wondered if it was some nuance of how maintainer scripts are supposed to speak to debconf, such as the need for db_stop or something like that.
<nacc> rbasak: yeah, i was putting it on my list to dig, but given that it's kind of everywhere, i think it's not something we introduced (and there have been bugs like that for the php7.0 already in xenial)
<bdmurray> nacc: I've starting the phasing of php7.0 again
<rbasak> nacc: sure
<nacc> bdmurray: thanks!
<nacc> bdmurray: i'll keep triaging the reports and reproducing those that seem like they might be real -- a few have all error reporting disabled, so the logs aren't helpful :)
<jdstrand> pitti: /run/user/<uid>/dbus looks like a named unix socket and therfore should used a file rule instead of a unix rule. eg: owner /run/user/[0-9]*/dbus rw,
<pitti> jdstrand: right, I tried that; does that completely replace the unix (connect ...) rule then?
<pitti> we need to allow both for a while
<pitti> jdstrand: because restricting connection to peer=(addr="@/tmp/dbus-*"), excludes the named socket apparently
<jdstrand> pitti: it would for the session bus if the session bus is now using a named socket, yes. but upstream would use both
<pitti> jdstrand: I added "/run/user/[0-9]*/dbus rw," and that didn't seem to help
<jdstrand> pitti: the unix rule is for an abstract socket and a completely different rule, so yes, you need the file rule I gave. a system that only uses a named socket would not need the unix rule
<jdstrand> pitti: with /run/user/[0-9]*/dbus rw, what is the denial?
<nacc> rbasak: fyi, i'm verifying all the bacula bugs are already fixed (by pushing to debian and upstream) in 16.10, will update them accordingly
<pitti> jdstrand: ok, good to know; I'll try again in a few mins
<jdstrand> pitti: s/but upstream would use both/but upstream apparmor would specify both for cross-distro support and transition/
<jdstrand> pitti: note that there might be other services that use libdbus that might create an abstract socket that matches @/tmp/dbus-* that would fail without the unix rule. ibus was one (but I patches im-config in yakkety for that), but there might be others (though I don't think in main). it should be obvious from the denial though
<pitti> jdstrand: right, I wasn't meaning to remove the abstract one, just to *also* allow the path based one
<pitti> jdstrand: so that things work with dbus-user-session and without
<jdstrand> sounds great
 * jdstrand nods
<nacc> rbasak: also, did you see my debug of the mysql-server vs. bacula install path?
<jdstrand> pitti: note I see in backscroll the path is /run/user/1000/bus
<nacc> rbasak: i think, in retrospect, it's not a bug, just a quirk of the way bacula and dbconfig work
<jdstrand> pitti: your rule is /run/user/[0-9]*/dbus
<jdstrand> ie, dbus vs bus
<pitti> jdstrand: argh, how silly; thanks!
<jdstrand> np
<pitti> (that was Adam's rule, but I might have done the same)
<infinity> bus, dbus, whatever. ;)
<seb128> pitti, https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1604872
<ubottu> Launchpad bug 1604872 in apparmor (Ubuntu) "dbus abstraction not compatible with dbus-user-session" [Undecided,New]
<pitti> jdstrand: I feel so silly now, thanks :)
<pitti> works fine
<pitti> jdstrand: I'll attach to seb128's bug
<jdstrand> thanks
<pitti> jdstrand: is there an upstream git you want a PR for?
<infinity> pitti: I apologize deeply for infecting you with my thinko. ;)
<pitti> infinity: I already screwed it up before, so no worries :)
<infinity> pitti: Oh, then I take it back.  No apology for you.
<jdstrand> pitti: a patch to the https://lists.ubuntu.com/mailman/listinfo/apparmor is the normal way. otherwise you can add an upstream apparmor task and the patch to the bug
<pitti> jdstrand: thanks, I'll do that then, as I'm not subscribed
<pitti> jdstrand: done
<rbasak> nacc: that's OK then I guess. As long as we're no worse than Debian.
<nacc> rbasak: ack
<mhall119> infinity: there's an email from the CC to the DMB list that is waiting on moderation, can you let it through?
<mhall119> seb128: willcooke: ^^ same thing for the ubuntu-desktop ML
<infinity> mhall119: Not sure I have the DMB list password.
<mhall119> infinity: it's owned by the TB according to mailman, so anybody from that team should be able to approve it
<infinity> mhall119: That's not how mailman moderation works...
<mhall119> it's just a reminder that the biannual checkin with the CC is tomorrow at 1700 UTC in #ubuntu-meeting
<mhall119> if you can't approve it, can you send a reminder yourself?
<infinity> Oh.  I thought we already had one of those.
<infinity> Or maybe that was to the TB.
<mhall119> infinity: you have one very cycle :)
<infinity> mhall119: We got a mail to the dmb list today.
<infinity> From: Svetlana Belkin <belkinsa@ubuntu.com>
<infinity> Subject: Re: Check-In With Community Council
<infinity> mhall119: So, I tihnk we're good.
<mhall119> ah, someone let it through then, thanks :)
<willcooke> mhall119, done
<mhall119> thanks willcooke
<mterry> bdmurray, per bug 1275083, unity-api-team seems better than unity-api-bugs it seems, for the package-subscribers script
<ubottu> bug 1275083 in ubuntuone-credentials (Ubuntu) "[MIR] ubuntuone-credentials" [Undecided,New] https://launchpad.net/bugs/1275083
<bdmurray> mterry: thanks, I've commented on the bug.
<mterry> bdmurray, thanks!
<semiosis> hi again.  any movement on my vagrant issue?  bug 1565985
<ubottu> bug 1565985 in cloud-images "vagrant vb ubuntu/xenial64 cannot mount synced folders" [Undecided,In progress] https://launchpad.net/bugs/1565985
<semiosis> https://code.launchpad.net/~semiosis/livecd-rootfs/fix-for-1565985/+merge/298305
<semiosis> thanks in advance
<dobey> anyone know how to make sbuild build unsigned packages? my search-fu is apparently not working so great
<dobey> as in, i want it to build unsigned binaries
<semiosis> dobey: pbuilder?
<dobey> semiosis: no, i need to use sbuild. just looking for a way to make it build unsigned, to avoid extra hassle of needing to generate and secure keys
<dobey> (ie, i'm trying to fix something that runs sbuild in clouds to not build signed packages)
<dobey> also, sbuild-update --keygen doesn't seem to want to generate keys for me
<tumbleweed> dobey: sbuild shouldn't be caring about signatures on packages
<tumbleweed> it does need to sign its internal archive, though
<dobey> tumbleweed: sign its internal archive?
<dobey> tumbleweed: why does it need this and to sign it?
<slangasek> because apt refuses unsigned archives by default, and sbuild needs to support building packages against other packages that it has built and subsequently published internally
<dobey> ok. can i make sbuild not use the internal archive stuff then? these are throw-away CI builds in jenkins
<tumbleweed> I think you should figure out the problem with sbuild-update --keygen
<dobey> i guess not because the dummy package it creates is in that archive :-/
<nacc> slangasek: germinate question for you; how serious is it for the seeds to refer to nonexistent packages in your mind? I recently (with pitti's help) fixed an issue in the samba-server task where a non-existent (but necessary functionality-providing) pacakge was listed (smbpass-winbind -> libpam-winbind migration). Looking through
<dobey> tumbleweed: well, that's not the core issue i was trying to solve
<nacc> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.xenial/_germinate_output, I do see it mentions "nknown samba-server package: libpam-smbpass". I also see that for several other packages (including some from server-ship).
<sarnold> dobey: since packages themslves aren't signed, I'm not sure where sbuild fits in to this; they only get "signed" when they get moved into a repository, no?
<dobey> ie, distributed management of infrastructure is a lot more annoying/difficult when you have private keys to keep private
<slangasek> nacc: it is an issue that the seed owners should take seriously, because it leads to problems like the one described here where functionality goes missing from the seed due to an unnoticed package rename
<tumbleweed> dobey: why do you have to keep them private?
<nacc> slangasek: ack, thanks!
<slangasek> nacc: if you look carefully, you will certainly find that server is not alone in terms of stale seed contents :/
<dobey> tumbleweed: well, i guess this specific instance it might be ok if the private keys are in a vcs, since they're only for internal sbuild thing
<nacc> slangasek: yeah, that's why i was sort of asking the relative priority :) I will at least try to get server cleaned up
<dobey> sarnold: i think we got past that point already :)
<sarnold> dobey: okay :) hehe
<sarnold> dobey: are you already using a tool to manage the internal repo?
<dobey> sarnold: no, i'm not trying to manage an internal repo. just trying to make managing a jenkins instance which uses sbuild to build things for testing MPs, a bit easier
<sarnold> dobey: the security team has scripts around apt-ftparchive, and by default we leave our internal repos unsigned, so if you haven't selected one already, apt-ftparchive may work alright
<dobey> sarnold: this is the internal repo which sbuild uses for itself, so i guess that wouldn't help here
<sarnold> dobey: alright, if I've understood .. in the schroot you're using, change the apt.sources lines from "deb ..." to "deb [trusted=yes] ..."
<sarnold> (and deb-src too)
<slangasek> sarnold: that's all pretty deep fiddling with the sbuild setup.  The better answer is just to either put your private creds in the VCS, or let sbuild create them as part of the setup job, and not care
<dobey> sarnold: i don't have shell access to those. the jenkins jobs currently won't even let me create the chroots, without the keys
<slangasek> fwiw if we really are talking about signed packages rather than signed changes, that's just an option to dpkg-buildpackage: -uc -us
<jbicha> LocutusOfBorg: for libpqxx-dev, I'm hoping we can ignore the epoch once bug 1588570 is taken care of
<ubottu> bug 1588570 in libpqxx3 (Ubuntu) "please remove libpqxx3 from the archive" [Wishlist,New] https://launchpad.net/bugs/1588570
<dobey> slangasek: no, i'm talking about the sbuild keys. i just didn't understand exactly what they were used for when i originally asked how to not use them
<slangasek> ok
<LocutusOfBorg> jbicha, not sure but I hope so
<LocutusOfBorg> :)
<dobey> so probably the best solution here would be to just let sbuild generate its keys during setup
<cjwatson> dobey: I've been meaning to make sbuild use [trusted=yes] instead of the local key thing, but there are compatibility issues when building for old releases
<dobey> ah, entropy is an issue :-/
<infinity> cjwatson: trusted=yes showed up in trusty, right?  So when precise EOLs, we can go to town!
<infinity> (Which is coming up)
<cjwatson> I think I was still thinking of doing some kind of cheap version detection, but something like that.
<infinity> cjwatson: Well, -d is passed through pretty much everything, you can just strstr for precise and be done with it.
<infinity> cjwatson: Assuming anything !precise and !wheezy (or whatever Debian releases don't support it) are fine, and screw people with weird distros.
<infinity> Close enough, anyway.
<cjwatson> Could also just do a version comparison on apt.
<nacc> rbasak: ok, i've submitted a sru debdiff for bacula
<dobey> cjwatson: having trust=yes would be awesome, indeed
<dobey> hrmm, how does one delete an sbuild schroot which somehow still has resources in use?
<dobey> ie /proc /sys /dev/shm and /dev/pts
<dobey> somehow the suggested rm -rf for deleting a schroot on the wiki page, seems like a bad idea
<nacc> well, those are all virtual filesystems, right? meaning the /proc in /var/lib/schroot/chroots/ is empty
<dobey> are they not bind mounts? and either way, wouldn't they need to be unmounted first?
<nacc> dobey: i don't htink they are bind mounts (at least not /proc or /sys, but i might be wrong)
<nacc> https://wiki.ubuntu.com/SimpleSbuild#Deleting_a_schroot
<nacc> dobey: --^ you mean those stanzas?
<dobey> yes
<nacc> dobey: to be clear /var/lib/schroot/chroots/* is the 'source' chroot (I think); sessions is where a running sbuild/schroot would be
<dobey> 19:59:16 rm: cannot remove '/var/lib/schroot/chroots/vivid+overlay-amd64/dev/pts': Device or resource busy
<dobey> well, i just want to know how to get rid of it, on a remote vm in a cloud that i don't have direct shell access to
<nacc> dobey: oh with overlays, it might need to be not running?
<cjwatson> dobey: schroot -ec <session id>  usually WFM
<nacc> right, that should end the running session; which won't necessarily delete the underlying chroot (aiui). But maybe overlays are different?
<dobey> i don't know that there is an active session
<nacc> dobey: are you able to lsof that file (I think that's the command) and see what is using it?
<dobey> oh, ffs, trusty umount doesn't have -R option apparently :-/
<dobey> ok, some fancy mount|grep schroot|... magic and i managed to get everything unmounted, so hopefully this will all do the right thing now
<dobey> 20:43:13 cp: '/etc/localtime' and '/var/lib/schroot/chroots/xenial+overlay-i386/etc/localtime' are the same file
<dobey> any idea why that would happen?
<infinity> Yup.
<slangasek> dobey: because you should install the SRU version of ubuntu-dev-tools, 0.155ubuntu2
<infinity> (Or the yakkety version)
<dobey> 20:48:11 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
<dobey> hrmm
<infinity> dpkg -l ubuntu-dev-tools ?
<dobey> slangasek: oh, it's not an SRU on trusty?
<infinity> Oh, no.  Only yakkety and xenial.
<infinity> People use trusty?
<slangasek> this bug affects trusty?
<infinity> Probably.
<slangasek> I assumed it was a regression in the released version of mk-sbuild in xenial, didn't look further
<infinity> The bug was in new userspace, thus new chroots.
<infinity> I believe.
<dobey> hrmm
<infinity> Well, "bug".
<slangasek> if it's a behavior change in debootstrap, then yes, mk-sbuild in trusty might need help
<dobey> ï¿¼ 0.153ubuntu1updates (universe)2016-07-03
<infinity> As in, those files changed type, and thus couldn't be copied over anymore.
<dobey> err, paste from lp sucks
<infinity> Went from file to link, I think.
<infinity> Or something.
<infinity> I dunno.
<infinity> *hand wavy*
<infinity> But yes, probably needs fixing in trusty and precise too.
<dobey> so it looks like 0.153ubuntu1 is installed
<slangasek> infinity: oh, you're right.  I had assumed this was always the case, but now I realize it's an assume-/usr-is-present-ism
<slangasek> so yes, mk-sbuild in trusty should also get an SRU
<slangasek> somebody who runs trusty can drive that ;)
 * infinity stares at dobey.
<dobey> i'm just trying to put out this firebomb :(
<dobey> i guess these clouds are all still 14.04 at least until 16.04.1 (and then until IS gets time to upgrade things)
<slangasek> it's a one-liner patch to mk-sbuild, fwiw
<dobey> mk-sbuild is just a text script right?
<slangasek> yes
<slangasek> you can probably cowboy patch it in your setup script, if that's what you're thinking
<dobey> indeed
<dobey> oh bugger, my entering-commands-in-a-web-form-to-run-on-a-remote-system-fu is not as strong as i'd thought
<mwhudson> sooner or later i'm going to have to figure out how to make 'chdist apt' work
<nacc> mwhudson: was about to cobble something together, but yakkety's version has the support :)
<nacc> 2.16.6 added it
<mwhudson> nacc: oh cool
<mwhudson> will the world catch on fire if i install the yakkety version on xenial, i wonder...
<nacc> mwhudson: i'm pretty sure (in quick testing) that apt also accepts APT_CONFIG as the env variable, so it's just a matter of adding apt as a command option
<mwhudson> yeah, i'm assuming it's not hard
<nacc> i think itmight be literally adding:
<nacc>     when ('apt') {
<nacc>         aptcmd('apt', @ARGV);
<nacc>     }
<nacc> to the parser
#ubuntu-devel 2016-07-21
<goddard> can you get a library for a snap package that isn't in the repo
<goddard> it was in 14.04 but 16.04 has an upgraded library that isn't compatable
<sarnold> goddard: probably #snappy is going to be more active
<goddard> k
<pitti> nacc: not serious, germinate just ignores it; but of course it will not be what we intend
<infinity> sgclark: kubuntu 16.04.1 testing looks pretty lacking.  Are there people working on it?
<infinity> yofel: ^
<sgclark> infinity: sorry, I have not had time to do much on kubuntu recently due to realjob.
<infinity> sgclark: Wasn't implying you need to be doing the testing, but maybe you know some people to poke.
<infinity> (given that we release today...)
<sgclark> sure. I can poke lol
<mwhudson> so um, http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#golang-1.6 <- why is golang-dbus listed as in progress?
<mwhudson> it finished hours ago
<infinity> mwhudson: I beg to differ, looks like it never ran.
 * infinity triggers another.
<mwhudson> infinity: oh hm, guess so, http://autopkgtest.ubuntu.com/packages/g/golang-dbus/yakkety/amd64/ has one more run than http://autopkgtest.ubuntu.com/packages/g/golang-dbus/yakkety/i386/
<infinity> mwhudson: More important is the trigger column.
<mwhudson> oh right
<mwhudson> running now, thanks
<infinity> mwhudson: I know. ;)
<mwhudson> and now it's not
<mwhudson> bah, missed a rebuild
<mwhudson>  ups no, i'm an idiot
<Odd_Bloke> slangasek: Finally dug in to your comment on semiosis' MP: (https://code.launchpad.net/~semiosis/livecd-rootfs/fix-for-1565985/+merge/298305) :)
<infinity> Odd_Bloke: Commented.
<xnox> my understanding was that qemu&kvm merged. and all virtualisation is executed with "qemu" binary and it could be hardware accelerated (kvm) or not (user)
<xnox> systemd-detect-virt says qemu... even though libvirt says hypervisor is kvm
<xnox> is systemd-detect-virt == "kvm" obsolete and never happens anymore?
<semiosis> Odd_Bloke, infinity: want me to remove the virtualbox-guest-dkms from the vagrant image??
<semiosis> s/??/?/
<infinity> semiosis: It shouldn't be necessary.
<semiosis> testing it now
<infinity> semiosis: And removing it means you're not pulling in dkms, compiler, etc.
<semiosis> +1
<Odd_Bloke> I'm building a test box with it removed using the proper infrastructure, too.
<Odd_Bloke> semiosis: Could you test the box at http://bit.ly/2abcYqz ?
<mdeslaur> doko: any plan on fixing bug 1353729 ?
<ubottu> bug 1353729 in gcc-4.8 (Ubuntu) "[4.9 Regression] ICE in final_scan_insn, at final.c:2952 (aarch64-linux-gnu)" [Undecided,Confirmed] https://launchpad.net/bugs/1353729
<semiosis> Odd_Bloke: your yakkety image and my xenial image both worked great.  i changed my branch to not install the dkms package.
<Odd_Bloke> infinity: Your comment is now addressed: ^
<Odd_Bloke> I have a Python package whose setup.py installs a library and some scripts; I want to split these up in to python-foo, python3-foo and foo (where foo Depends on python3-foo).  At the moment, I'm using override_dh_python3 to move /usr/bin out of python3-foo in to foo, and override_dh_python2 to remove /usr/bin from python2-foo.
<Odd_Bloke> Is there a better way to handle this?
<Odd_Bloke> (I'm also calling dh_python{2,3} in each of those overrides)
<techsayan> Hi, I was trying to assign group permissions in my server, can someone help me out setting up group permissions on the system level rather than file/directory level?
<semiosis> techsayan: i think that #ubuntu-server is a better place to ask that
<techsayan> semiosis: thanks
<andrewsh> cyphermox: are you the wpa guy in Ubuntu?
<andrewsh> cyphermox: any idea when https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1528173 may be done?
<ubottu> Launchpad bug 1528173 in wpa (Ubuntu) "org.freedesktop.DBus.Properties.GetAll fails always for fi.w1.wpa_supplicant1.Interface interface" [Undecided,In progress]
<cjwatson> Odd_Bloke: How about debian/foo.install containing usr/bin, debian/python-foo.install containing usr/lib/python2.*, and debian/python3-foo.install containing usr/lib/python3?
<cjwatson> Works for me in germinate.
* infinity changed the topic of #ubuntu-devel to: Xenial (16.04.1) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<jamespage> pitti, hey - I uploaded a fix for my broken ceph 10.2.2 SRU for xenial - any chance you could take a look?
<pitti> jamespage: travel+changing train + team meeting, can you please ping some other SRU team member?
<pitti> (sorry)
<jamespage> pitti, sure np - arges - would you have time to look at ^^ ?
<sil2100> Laney: hey!
<sil2100> Laney: or hm, unhey, nevermind ;)
<arges> jamespage: does this override whats currently in proposed?
<nacc> pitti: yep, thanks! I've sent an e-mail to ubuntu-server for the tasks, etc that seem to be out-of-date and relevant there
<jamespage> arges, yah
<arges> jamespage: ack
<nacc> rbasak: ok, looking at memcached, need your input :)
<slangasek> Odd_Bloke, semiosis: uploaded to yakkety
<Odd_Bloke> slangasek: Thanks!
<coreycb> arges, could you reject ceilometer 1:6.1.1-0ubuntu1 from the xenial queue?  we have a newer version in the queue now.
<Odd_Bloke> slangasek: We would really, really like this backported to xenial as well (because that box has all these issues); shall I help semiosis prepare the diff that just got merged as an SRU?
<jamespage> arges, ta
<slangasek> Odd_Bloke: yes, if you can help drive that livecd-rootfs change for SRU that would be splendid
<slangasek> Odd_Bloke: the trusty branch should be current and targetable: https://code.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trusty-proposed
<sil2100> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping.
<sil2100> The community council would like us to check in on #ubuntu-meeting now
<micahg> not for another 25 min
<sil2100> Since they said that if none from the desktop team will show up, they'd like us to go first (so now)
<pitti> tyhicks, jdstrand: hi! I'll soon be blocked by the outstanding apparmor merge with debian; is that something you can look into, or should I find some time for that?
<pitti> (or potentially a sync, Debian took a lot of our changes)
<doko> bdmurray, xnox: what's the status about python-cassandra? I only can see an open issue with python-cassandra-driver
<jgrimm> bdmurray, still on SRU duty? looking for a bit of assist on curtin SRU
<jgrimm> bdmurray, 0.1.0~bzr399-0ubuntu1~14.04.1  needs to replace 0.1.0~bzr389-0ubuntu1~14.04.1 in trusty-proposed (I've 'verification-failed-trusty' today to make it explicit we don't want 389)
<doko> mdeslaur, reading backlog, what is the question?
<bdmurray> jgrimm: I'll have a look
<mdeslaur> doko: mysql wasn't building with the updated gcc-4.8 in trusty because of bug 1353729
<ubottu> bug 1353729 in gcc-4.8 (Ubuntu) "[4.9 Regression] ICE in final_scan_insn, at final.c:2952 (aarch64-linux-gnu)" [Undecided,Confirmed] https://launchpad.net/bugs/1353729
<mdeslaur> doko: I've found a workaround now, so don't care anymore, thanks
<doko> mdeslaur, if workarounds work, that would be my preferred solution. If fixes are in 4.8.5, then we could try to backport. But there are nontrivial gaps between 4.8 and 4.9 ...
<mdeslaur> ok, thanks
<nacc> jbicha: fyi, the reason i held off on my merge was both maas and openstack have dependencies on the version of python-django
<jbicha> nacc: ok, it that's still relevant, could you add that to the bug so someone doesn't unknowingly sponsor it then
<nacc> jbicha: yep, i'm doing that now
<jbicha> thanks
<nacc> jbicha: sorry i forgot to update my bug while I was digging into that
<nacc> jbicha: if you want to throw your build into a PPA, the affected teams would be able to test, i'm guessing
<jbicha> I might just wait until 1.10, the main reason I opened the bug was because I made a minor improvement to the pymysql patch
<nacc> jbicha: just an fyi: https://merges.ubuntu.com/main.html, i'm marked as handling it :)
<jbicha> nacc: oops, I didn't think to look there
<nacc> jbicha: it's ok :)
<nacc> jbicha: looks like openstack (upstream) may not be compatible with the latest django (just updated the bug w/ a comment)
<jgrimm> thanks bdmurray!
<jdstrand> pitti: I'm going to defer to tyhicks and/or ratliff on that. I could do it, but would need them to tell me what to deprioritize
<nacc> hggdh: good effort to get that individual to point to a an actual discussion; sad response
<hggdh> nacc: yes. Pity, though. OTOH, not the first time that I see something similar from him/her
<nacc> hggdh: agreed
<nacc> my goodness, I consider myself to be overly verbose, but this Xen character is something else
<snkcld> where can i find the repo that contains the ubuntu bluez package code?
<nacc> snkcld: what do you mean by repo? i usuually would just do `pull-lp-source -d bluez` (or without -d if you are ok with it untarring locally)
<snkcld> well, according to the "ubuntu distributed development" page... it says thats the "traditional" way, so im just trying to figure out how i can clone the code for the bluez package via bzr
<snkcld> "With Ubuntu Distributed Development all packages in the Ubuntu (and Debian) archive are automatically imported into Bazaar branches on our code hosting site Launchpad"
<nacc> udd is dead :)
<nacc> i believe
<snkcld> ahahah
<snkcld> ok then! that answers it
<nacc> snkcld: i'm working on a git-alternative of sorts, but it's not quite as feature-rich yet
<snkcld> is pull-lp-source what you use then? and you do the whole debdiff thing?
<nacc> snkcld: yeah, basically
<nacc> snkcld: let me point you at some of the tooling
<nacc> https://wiki.ubuntu.com/UbuntuDevelopment/Merging/GitWorkflow
<nacc> snkcld: i recommend, if you're comfortable with git, using pull-lp-source -d and then git dsc-commit
<snkcld> i am very comfortable with git
<nacc> jgrimm: fyi, importing memcached now
<jgrimm> nacc, thanks sir
<snkcld> i got to go, but thanks nacc
<nacc> jgrimm: did rbasak do at? I think you asked fro that too?
<nacc> snkcld: np, feel free to ping here with questions
<snkcld> why "-d" ?
<snkcld> nacc:
<jgrimm> nacc, looks like it -> https://git.launchpad.net/~usd-import-team/ubuntu/+source/at
<nacc> snkcld: download-only
<nacc> snkcld: that way you can use git-dsc-commit to import into a git repository
<nacc> snkcld: otherwise it'll just extract the source package into an appropriately named directory; i guess you coudl git init in there, but it's justa n extra step :)
<nacc> jgrimm: ok, thanks for checking
<jgrimm> np, thank you
<nacc> jgrimm: https://code.launchpad.net/~usd-import-team/ubuntu/+source/memcached/+git/memcached
<nacc> rbasak: fyi, memcached works now --^ pushed a few commits, and also the retry logic for lp actually works (and it just happened to me a few times, so tested too :)
#ubuntu-devel 2016-07-22
<pitti> Good morning
<tsimonq2> o/ pitti, how are you? :)
<pitti> tsimonq2: quite well, thanks! back home now. how about yourself?
<tsimonq2> great :)
<mwhudson> is there a way of producing the changelog merge-o-matic produces locally?
<mwhudson> ah maybe ~rbasak/ubuntu-git-tools/git-reconstruct-changelog
<mwhudson> no, more git-reconstruct-changelog
<rbasak> mwhudson: also git-merge-changelogs? That's probably the trickier bit.
<jamespage> doko, hey - my recent uploads for ryu address your original MIR review points for bug 1500950
<ubottu> bug 1500950 in ryu (Ubuntu) "[MIR] ryu" [High,New] https://launchpad.net/bugs/1500950
<jamespage> it would be nice to get that worked through if possible to unblock neutron from proposed migration
<jamespage> :)
<pitti> doko: is the python3-defaults in https://launchpad.net/ubuntu/trusty/+queue?queue_state=1 still actually relevant? bug 1348954 does not have a trusty task for it nor a description of the changes, and the changelog doesn't say either
<ubottu> bug 1348954 in python3-defaults (Ubuntu) "update Python3 for trusty" [Undecided,Confirmed] https://launchpad.net/bugs/1348954
<xnox> on a side note - i really hate libvirt & qemu source code
<jtaylor> speaking of it in 14.04->16.04 apparmor prevents libvirt from starting, missing capability net_bind_service
<xnox> sarnold, ^
<semiosis> Odd_Bloke: hey i was real busy with $dayjob yesterday and didnt have a chance to reply.  i'm really excited to see the merge accepted.  let me know what the next steps are if I need to do anything for the xenial SRU.  thanks!!!
<Odd_Bloke> semiosis: So if you'd like to, I was hoping I could convince you to prepare the SRU patch. :)
<Odd_Bloke> semiosis: (I have a sprint week of meetings next week, so will be unlikely to get to it any time soon)
 * semiosis arm doesnt take much twisting
<semiosis> i'll do it!  is there a doc I can read about the process?  any tips?
<Odd_Bloke> semiosis: https://wiki.ubuntu.com/StableReleaseUpdates is the documentation.
<Odd_Bloke> You'll need to get someone to target https://bugs.launchpad.net/cloud-images/+bug/1565985 to xenial (I don't have the powers, unfortunately).
<ubottu> Launchpad bug 1565985 in cloud-images "vagrant vb ubuntu/xenial64 cannot mount synced folders" [Undecided,In progress]
<semiosis> Odd_Bloke: thanks I'll read the docs.  how much longer will you be around today in case I have questions?
<Odd_Bloke> semiosis: Around 90 minutes, though I'll probably see pings in IRC after that. :)
<lfaraone> I'm intending to make update-initramfs reference https://help.ubuntu.com/community/Lubuntu/Documentation/RemoveOldKernels if the disk is full -- should I link to it directly (moved out of Lubuntu) or reference some other URL redirector?
<lfaraone> I'm intending to make update-initramfs reference https://help.ubuntu.com/community/Lubuntu/Documentation/RemoveOldKernels if the disk is full -- should I link to it directly (moved out of Lubuntu) or reference some other URL redirector?
<sarnold> jtaylor: that seems surprising, I've used libvirt remotely on 16.04 LTS without having to do anything.. got a bug number?
<jtaylor> sarnold: do you have that cap in your apparmor file?
<sarnold> jtaylor: no, there's no net_bind_service. Now I'm insanely curious..
<jtaylor> sarnold: and its in enforce?
<sarnold> jtaylor: yeah, and I can't spot any DENIED entries in my logs
<jtaylor> sarnold: I'll try my desktop
<jtaylor> hm I got a different apparmor profile
<jtaylor> oh no it was just reorded by aa-logprof
<jtaylor> and it works which is weird
<jtaylor> maybe an upgrade from 14.04 leaves some configuration file which triggers some other behavior?
<sarnold> it could be you've got a different libvirt config, I'm surely not a power user..
<jtaylor> me neither, i'll file a bug with the logs
<sarnold> thanks
<jtaylor> sarnold: bug 1605727, ubuntu-bug was run on my desktop so its not the same as the affected machine
<ubottu> bug 1605727 in libvirt (Ubuntu) "libvirt-bin start prevented by apparmor" [Undecided,New] https://launchpad.net/bugs/1605727
<sarnold> jtaylor: do you have "network netlink," in your profile?
<jtaylor> sarnold: the apparmor profile?
<jtaylor> yes its in there
<sarnold> ah, good. hmm.
<nacc> Akuli: how did you decided on 50?
<nacc> Akuli: are you 100% sure there are no commands that are 50 characters?
<teward> nacc: I think we need to clarify "command" here
<Akuli> just a random number
<nacc> Akuli: that's probably not a suitable fix then :)
<nacc> teward: it's whatever is passed to "command-not-found" afaict
<teward> nacc: "If I enter an invalid command that is a few thousand characters long"  <-- what's the likelihood of this?
<Akuli> but that part is easy to change, preferably it should be in a setting file
<Akuli> well if someone else like me feels like hey i have boring lets try that :)
<teward> nacc: right, but what's the likelihood of something thousands of characters long really being paseed through to the command-not-found?
<Akuli> well
<dobey> teward: cats do it all the time
<Akuli> today i froze my system twice with that so
<Akuli> there you go
<teward> dobey: cats. :P
<nacc> teward: it's any arbitrary string you type at the terminal, i think (by default)
<teward> Akuli: not my point
<nacc> teward: i'm *guessing* it's a page overflow
<dobey> Akuli: why were you trying to type an arbitrary string that's so long into the terminal?
<nacc> or some other buffer overflow
<teward> nacc: right, but what's the practical likelihood that someone's going to have to type in 2000+ characters
<Akuli> i have no idea :)
<Akuli> i don't think its a buffer overflow
<nacc> teward: practically, no, but it shouldn't crash the system if you do, right?
<Akuli> i mean. its python
<nacc> then why is it crashing your system?
<Akuli> because there's no check for the length
<nacc> you mean it OOMs your system?
<dobey> its' not crashing the system
 * teward grabs a lorem ipsum string 3000 long
<Akuli> has spaces
<dobey> it's making the system unusable
<Akuli> won't do
<Akuli> dobey, indeed unusable
<nacc> dobey: ah, ok
<Akuli> 5 minutes of fighting with running out of ram
<sarnold> four seconds of looking four the executable /usr/src/linux-headers-4.4.0-21/tools/testing/selftests/rcutorture/bin/kvm-recheck-rcu.sh
<dobey> well really, it should have a length equivalent to that of the filename length restriction
<nacc> sarnold: :)
<teward> E: Cannot Reproduce @ 1000, 2000.
<Akuli> i have no idea what that is, people who know that better than i do can change that
<nacc> dobey: ack, that seems most appropriate for a true fix
<dobey> teward: you have too much RAM
<dobey> teward: cat /dev/urandom | command-not-found
<Akuli> i think their command searching function should be O(1) anyway
<sarnold> *snort*  /usr/lib/x86_64-linux-gnu/ubuntu-system-settings/private/Ubuntu/SystemSettings/SecurityPrivacy/UbuntuSecurityPrivacyHelper
<Akuli> not O(n) like it seems to be
<nacc> dobey: is that 255 characters still? or is that the best common default (iirc, it's fs-specific)
<teward> dobey: i'm doing this in a 512 RAM VM?
<teward> at 6500+ and not able to reproduce
<teward> with that low resources it should die off
<Akuli> it needs to be command
<Akuli> not arguments
<teward> well
<dobey> nacc: 255 sounds good to me
<teward> it took 35 seconds for my 8GB system to run, and only took 400MB
<dobey> Akuli: i think that's well understood :)
<teward> dobey: 255 sounds good to me too, because what sane command would be more than 255 characters long
<teward> excluding malware executable strings
<dobey> teward: nothing sane is even that long
<Akuli> um
<Akuli> what sane program name would be more than 255 characters long
<teward> Akuli: none.
<Akuli> right
<teward> dobey: then could we not use even less than 255?>
<dobey> ones in german might have a "name" that long, but the exectuable command shouldn't be :)
<teward> TBH
<nacc> http://paste.ubuntu.com/20490401/
<teward> I really think this is a 'corner case'
<dobey> teward: very certainly a corner case
<nacc> it's a usability issue, arguably
<dobey> teward: well i think the limit should match what is allowed by dpkg
<Akuli> nacc, you have a syntax error in your code
<nacc> Akuli: bah
<Akuli> unbalanced parenthesis
<teward> dobey: what's the upper limit there then?
<nacc> http://paste.ubuntu.com/20490547/
<nacc> Akuli: --^
<teward> bah almost out of power >.<
<teward> (on my laptop)
<dobey> teward: i'm not entirely sure. it would be whatever the tar format limit is, for the tar format version being used
<nacc> i dont' think it's accurate to print 'command not found' as it wasn't searched for
<dobey> which i /think/ is 255
<nacc> i mean, 255 is a sane limit; there might be more optimal choices
<Akuli> nacc, it was
<Akuli> bash searches the command before command-not-found runs
<sarnold> someone should hunt around java applications that install things into /opt. if anyone's going to have ultra-long command names that seems like the group that would do it :)
<Akuli> without command-not-found it would print 'command not found' no matter what
<dobey> well it wasn't found and it's not going to be searched for in the package archives, either
<dobey> sarnold: but they have to all get wrapped in a shell script with a shorter name, becuase it's the arguments to java that are long, there
<Akuli> hmm
<Akuli> i tried that in a virtual machine, and it started attempting to kill command-not-found
<Akuli> but the vm is frozen anyway
<Akuli> reading the code more, the fix is actually pretty awful
<Akuli> it ignores options.ignore_installed
<dobey> that's a bit rude
<Akuli> indeed
<dobey> no, i mean your statement is
<Akuli> i meant, it doesnt do anything with options.no_failure_message
<Akuli> sorry i was confusing two things
<dobey> i meant, you called nacc's work "actually pretty awful" when the time was taken to help create a patch for your problem, which was only reported today, and is really an extreme corner case, while you refuse to "download the source for a 3 line change" to make a patch
<dobey> ie, it's rude :)
<Akuli> i made the original implementation
<Akuli> nacc just changed one number
<Akuli> oh wait..
<Akuli> he changed much more than i thought he did
<Akuli> that looks great to me
<emanuel7> how is php 7.1 plans ?
<emanuel7> need an rebuild everiting ?
<emanuel7> another transition, and bug everyone againg for ftbfs ?
<emanuel7> ups, I mean again
<nacc> emanuel7: there aren't any php7.1 plans right now?
<nacc> emanuel7: i don't think it's packaged in debian or ubuntu yet
<emanuel7> thanks for rapid feedbak, @nacc
<nacc> emanuel7: np, i think php7.1 is still in beta anyways
<nacc> emanuel7: let me see if debian has anything cooking
<nacc> emanuel7: with the understanding that if it exists anywhere, it would be 16.10+, probably 17.04
<emanuel7> you are the packager ? also in debinan ?
<nacc> emanuel7: i did the php7 transition (with help) in ubuntu
<nacc> emanuel7: and work with the debian maintainers a bit
<nacc> emanuel7: https://anonscm.debian.org/cgit/pkg-php/php.git/log/?h=master-7.1 looks like they have some stuff in git, but not yet packaged/published
<emanuel7> it will help to pan early...
<emanuel7> plan
<nacc> emanuel7: what version of ubuntu are you referring to?
<emanuel7> of course the latest one
<nacc> emanuel7: 16.04 will never have php7.1
<nacc> emanuel7: unless you mean 16.10?
<nacc> emanuel7: that's why i asked.
<emanuel7> I mean the developing one 16.10, and of course debian unstable
<emanuel7> or testing
<emanuel7> look at golang
<nacc> emanuel7: debian unstable has no php7.1 either
<emanuel7> they get testing
<emanuel7> at beta now
<nacc> emanuel7: i'm not sure what you're saying
<nacc> emanuel7: there is no packaged php7.1 in debian or ubuntu
<emanuel7> https://lists.ubuntu.com/archives/yakkety-changes/2016-July/004343.html
<emanuel7> ok golang is not the latest version
<emanuel7> now is rc3
<nacc> emanuel7: i thought you were asking about php?
<emanuel7> the same about php
<nacc> same what?
<emanuel7> why not testing the latest version ?
<nacc> !latest | emanuel7
<ubottu> emanuel7: Packages in Ubuntu may not be the latest. Ubuntu aims for stability, so "latest" may not be a good idea. Post-release updates are only considered if they are fixes for security vulnerabilities, high impact bug fixes, or unintrusive bug fixes with substantial benefit. See also !backports, !sru, and !ppa.
<emanuel7> there are fixes for bugs, not changes in language
<emanuel7> and that is all I will say about
<nacc> emanuel7: you are saying random statements, I'm having trouble following.
<emanuel7> @nacc usually the newer version is better, fixes bugs, etc.
<udevbot> Error: "nacc" is not a valid command.
<nacc> emanuel7: php7.1 is not bc with php7.0 necessarily, they add features, etc. It's not just bugfixes, if you simply glance at the NEWS file upstream.
<nacc> emanuel7: and, again, php7.1 is not yet published in debian, so we don't have it in ubuntu
<emanuel7> that is why I made an parallel to an other language like golang.
<emanuel7> ok
<nacc> and just like php5, php7.0 will presumably continue to get bugfixes
<dobey> and you're free to build newer versions in a PPA to test if you need to
<nacc> dobey: +1, good point
<dobey> or get involved with the packagers of php in debian if you want more testing of it in unstable.
<dobey> but you need to go to the debian channel for that, not here :)
<emanuel7> what I want to say is deep respect to people doing the transitions, tons of work going unnoticed
<nacc> emanuel7: ^5, it's a pain :)
<nacc> emanuel7: i wills ay, i don't think php7.1 will be the same
<nacc> emanuel7: what will probably ahppen is php7.1 will be an alternative in the metapackages (e.g. php) and it will "just work"
<nacc> that's an eventuality, though
<semiosis> Odd_Bloke: the SRU -- https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1605795
<ubottu> Launchpad bug 1605795 in livecd-rootfs (Ubuntu) "[SRU] livecd-rootfs ubuntu-cpc vagrant image builder" [Undecided,New]
<Unit193> flexiondotorg, infinity: Know what's up with the whole -core thing?  Not heard anything about it for a while is everything still pending on the reviewers?
<infinity> Unit193: Yeah, I need to revisit it.  Especially since flexiondotorg bought me beer.
<Unit193> Hah!  What type?
<infinity> Unit193: Whatever random hefeweizen the hotel bar had on tap. :P
<Unit193> infinity: FWIW, core is pretty popular with our users, got an email about a point release too. :P
<infinity> s/core/base/ ;)
<infinity> And noted.
<infinity> Hopefully I can find some down time when I get home.
<Unit193> Eh...
<Unit193> Right now it's pretty well known as 'Core', though it seems it'll get renamed soonâ¢  Thanks, hope you do get time.
#ubuntu-devel 2016-07-23
<kalxas> hi mdeslaur
<kalxas> I am having an issue with the latest version of usb-creator and I would like some advise
<kalxas> mdeslaur, I am one of the developers of OSGeoLive, a geospatial distribution based on Lubuntu. Our recent release is going to be based on Xenial and we found out that our 4GB iso is not working with usb-creator anymore.
<kalxas> I have opened a ticket here: https://bugs.launchpad.net/ubuntu/+source/usb-creator/+bug/1605803
<ubottu> Launchpad bug 1605803 in usb-creator (Ubuntu) "usb-creator in Xenial fails to write customized ubuntu iso files" [Undecided,New]
<kalxas> and this is our internal ticket: https://trac.osgeo.org/osgeo/ticket/1761
<kalxas> I am wondering how the upstream iso is produced in order to work with the recent usb-creator
<kalxas> is there anyone around, involved with production of ubuntu iso files?
<kalxas> hi all
<kalxas> I am looking for the source code that is used to create the recent lubuntu iso files
<kalxas> I have been pointed to http://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/files for ubuntu
<kalxas> but I am working on a lubuntu spin off
#ubuntu-devel 2016-07-24
<kilbith> hey guys, I've seen your announce to switch to modesetting DDX by default... IMO it's a bad decision since that driver is highly unstable -- like screen tearing on web browsing, big slow down on webkit window (ex. gnome online account), etc.
<kilbith> at least on Haswell
<b4r> @topic "Path Pilots:"?
<udevbot> Error: "topic" is not a valid command.
<b4r> @k
<udevbot> Error: "k" is not a valid command.
<xnox> infinity, for some weird reasons, my /usr/share/timezone/Zulu file on 16.04 had modification date Jul 18, and it clearly was not UTC, but GMT (UTC+1) and made my postgresql queries sad.
<xnox> now fixed, by doing $ apt install --reinstall tzdata
<xnox> and restarting postgres.
<xnox> are you aware of any dodgy software that messes things up like that.
<xnox> ?
<xnox> or maybe pitti
#ubuntu-devel 2017-07-17
<marco25> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860805...im having similiar issue in ubuntu..anyone know of a fix
<ubottu> Debian bug 860805 in beignet-opencl-icd "beignet-opencl-icd: OpenCL fails with: drm_intel_gem_bo_context_exec() failed: Device or resource busy" [Serious,Fixed]
<mwhudson> well that's odd
<mwhudson> https://launchpad.net/ubuntu/+source/python-argcomplete/1.8.1-1/+build/12554534 fails in strange explosive ways on lp but passes locally for me
<mwhudson> oh well, time to go for now
<jamespage> sil2100: hi!
<jamespage> bug 1649616 is now verification complete - so could we get the updates from that release and for bug 	1696139   into -updates please?
<ubottu> bug 1649616 in keystone (Ubuntu) "Keystone Token Flush job does not complete in HA deployed environment" [High,In progress] https://launchpad.net/bugs/1649616
<ubottu> bug 1696139 in neutron-fwaas (Ubuntu Zesty) "[SRU] ocata stable releases" [Undecided,New] https://launchpad.net/bugs/1696139
<jamespage> that made no-sense
<doko> willcooke: who is currently caring about libreoffice? asking because the failing autopkg tests on i386 is blocking gcc/binutils migration to the release pocket
<jamespage> sil2100: basically the bugs we discussed last week are all ready to roll :)
<rbasak> I'm unable to contact micahg. I haven't seen him here in a while and his @ubuntu.com email bounces.
<rbasak> Does anyone have an alternate contact for him?
<willcooke> doko, osomon, but he's on PTO.  seb128 might be able to help there
<seb128> doko, willcooke, it's a kernel bug
<seb128> doko, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865303
<ubottu> Debian bug 865303 in src:linux "libreoffice: Libreoffice Java features crash with Linux 3.16.43-2+deb8u1" [Serious,Open]
<seb128> doko, willcooke, oSoMon handed me a libreoffice update that disable tests as a workaround before going on holidays but I would prefer the kernel to be fixed because if we ignore the issue at build we are still going to get a libreoffice that segfaults at runtime
<sil2100> jamespage: ah! Excellent, thanks for the reminder
<sil2100> jamespage: on it in a minute :)
<jamespage> sil2100: ta
<rbasak> bdmurray, cyphermox , sil2100: I'd like to miss the DMB meeting tonight if possible as I have somewhere better to be. We don't have any applications. There's one ML request I'm happy to take, and I've completed my one action.
<rbasak> So rather than me waiting to find out that there's nothing to discuss: anything to discuss?
<cyphermox> rbasak: sounds good
<rbasak> Thanks! Also I presume people will want longer to consider my email.
 * bdmurray is aghast at somewhere better to be
<bdmurray> rbasak: I've nothing else to discuss at the meeting though.
<rbasak> Thanks :)
<sil2100> rbasak: yeah, nothing here as well - I saw your e-mail and I still need to think about it
<sil2100> rbasak: I'll add the ML action to the agenda and assign it to you so we don't lose track
<sil2100> Is that ok?
<rbasak> sil2100: sure. Thanks!
<jackpot51> Is there a reason gnome-initial-setup doesn't get started from GDM when no users are present?
<jackpot51> (In Artful)
<jbicha> jackpot51: could you file a bug? I believe that worked in zesty
<jackpot51> Sure jbicha, it is here: https://bugs.launchpad.net/ubuntu/+source/gnome-initial-setup/+bug/1704879
<ubottu> Launchpad bug 1704879 in gnome-initial-setup (Ubuntu) "gnome-initial-setup does not start when no users are available on Artful" [Undecided,New]
#ubuntu-devel 2017-07-18
<pitti> Laney: the systemd debs from that PR test fine locally, I can't reproduce the eternal hang; if I start a few tests manually with some changes, could I bother you with killing them again?
<pitti> Laney: the log included in the tarball was just a random interruption, it didn't show the actual tmpfail; so I would turn off the reboot smoke test at first and see how far that gets
<LocutusOfBorg> jamespage, I'm doing a sync of glusterfs
<Laney> pitti: sure
<LocutusOfBorg> can you please double check the systemd files?
<Laney> I wonder why this isn't reproducible elsewhere though
<Laney> given that it's extremely consistent in scalingstack
<pitti> Laney: ok, thanks; I started with disabling "upstream" and "boot-smoke" tests, to establish a base line (https://github.com/systemd/systemd/pull/6392)
<Laney> pitti: you're triggering these manually, right?
<Laney> :)
<pitti> Laney: queues have drained, did lgw01 came back and went though them all, or was some more surgery involved? :-)
<Laney> it came back
<pitti> Laney: yes, I won't add them to webhooks for now, just selected manual tests on a packaging branch
<Laney> they just had to turn it (nova-compute) off and on again
<pitti> haha
<wgrant> It'll hopefully be redeployed soonish, so it'll be more reliable.
<wgrant> I'm this evening bringing up staging s390x vbuilders on bos02, which is deployed in a slightly more sensible way that will eventually be rolled out everywhere.
<wgrant> icehouse is getting a bit old.
<Laney> I've been hearing rumours about that
<LocutusOfBorg> cpaelzer, pleeeeease can you merge multipath-tools? I would like, but I failed understanding some changes
<pitti> Laney: just 6 amd64 tests running in parallel, still cloud woes?
<Laney> pitti: quota; things backed off
<cpaelzer> LocutusOfBorg: hehe
<cpaelzer> LocutusOfBorg: I was waiting on cyphermox, but you know what if time permits I can prepare a merge and hand it to both of you for a review
<cpaelzer> I'm PTO soon, so I'd not like to upload before leaving for a while
<cpaelzer> will see If I can squeeze some of that in this week and let you know LocutusOfBorg, cyphermox
<LocutusOfBorg> thanks
<LocutusOfBorg> it should be a matter of grab-merging it, the merge failures should be trivial for a person who have done it previously
<LocutusOfBorg> but I don't want to touch it
<cpaelzer> LocutusOfBorg: I have the merge complete, was a bit ugly since some debian changes conflicted with ours but I think I was able to resolve
<cpaelzer> LocutusOfBorg: will build and test now, once that is done I'll throw at you and cyphermox for review and upload
<LocutusOfBorg> just ping and I'll have a look, lovely thanks!
<jbicha> LocutusOfBorg: btw I had already done liburcu rebuilds except for netsniff-ng
<jbicha> so liburcu could have migrated now but it has to wait for the autopkgtests to be redone :|
<LocutusOfBorg> jbicha, sorry, for some reasons they were listed in the bad list
<jbicha> what bad list?
<LocutusOfBorg> I crafted a list of stuff to rebuild, probably in some wrong way
<jbicha> LocutusOfBorg: https://people.canonical.com/~ubuntu-archive/proposed-migration/artful/update_output.txt and update_output_notest.txt provide a sort of tracker if you can read it
<LocutusOfBorg> the notest would have done the trick probably, thanks!
<LocutusOfBorg> I still prefer rdepends but I fail sometimes because I do it against artful, never found a way to make it look for artful-proposed
<jbicha> I think the autopkgtests were good by now though
<LocutusOfBorg> not by this morning :)
<jbicha> not any more, but they were good except for netsniff-ng
<cpaelzer> LocutusOfBorg: cyphermox: I set you both as reviewer on the multipath-tools merge, should be in your inbox from LP
<LocutusOfBorg> I prefer cyphermox and to wait some bits
<LocutusOfBorg> to make liburcu migrate
<cpaelzer> As I said I'm soon away a bit, so time will pass :-)
<LocutusOfBorg> cpaelzer, debian/tests/control gone?
<cpaelzer> from the delta maybe, should be all in debian now
<cpaelzer> I upstreamed all we had to Debian so we can drop delta
<cpaelzer> it is still there, just checked
<LocutusOfBorg> I see it has been upstreamed differently but ok
<juliank> apt 1.4.7 just entered that apt ppa for zesty (https://launchpad.net/~deity/+archive/ubuntu/apt). I rebuild the changes file for zesty, but kept the .dsc and .tar.xz unchanged from the debian stretch update. For the SRU (bug 1702326), we can either pick the update like this, change the distribution info in debian/changelog, or change distro + version to something like 1.4.7+16.10.1.
<ubottu> bug 1702326 in apt (Ubuntu Zesty) "New microrelease 1.4.7 for zesty" [Medium,Triaged] https://launchpad.net/bugs/1702326
<juliank> I can also update the SRU bug then to handle any other stuff that might have been forgotten in the 1.4.{1,2,3,4,5,6} SRUs
<juliank> Not sure if anyone else has been sharing a branch between a debian stable and an ubuntu stable release yet
<juliank> Optimally, I'd syncpackage it but (a) Launchpad did not pick it up from stretch-proposed, and (b) no diffs for SRU reviewers :(
<juliank> So currently, it's more of a fake sync
<cyphermox> cpaelzer: I review multipath-tools; feel free
<cyphermox> I'll do another run of testing with everything together (ie. from d-i) once it's in the archive.
<cpaelzer> thanks cyphermox
<cpaelzer> I'll address whatever review comes up tmrw morning and if nothing blocking I'll upload
<cpaelzer> e.g. a few of nacc's automated nack's don't count on this, but I want to check them still
<cpaelzer> thanks for the offer on the extra round of testing
<juliank> grr. i want to close *all* segv and friend bugs in apt.
<slangasek> stgraber, kees, infinity, mdeslaur: TB meeting in 2?
<mdeslaur> ack
<slangasek> (if stgraber is around to chair, I guess I should have checked with him when I was face-to-face with him 10 minutes ago :P)
<stgraber> slangasek: http://paste.ubuntu.com/25119707/
<stgraber> slangasek: downloads the build chroot from LP, turns that into a LXD image and creates a container from it. If the image already exists, just re-uses it (unless -u is passed to force an update). It repacks the build chroot to rename the directory that's in it and add the needed bit of metadata for LXD. Seems to work okay here.
<LocutusOfBorg> cyphermox, so you take care of multipath upload? thanks
<cjwatson> juliank: Do you know of something left to do in Launchpad for bug 1417717?  https://translations.launchpad.net/ubuntu/artful/+source/apt/+pots/apt-utils looks fine to me now (especially by comparison to vivid).
<ubottu> bug 1417717 in Ubuntu Translations "apt-utils marked for translate, but data unavailable" [High,Confirmed] https://launchpad.net/bugs/1417717
<slangasek> stgraber: excellent, thanks
<juliank> cjwatson: I don't know, I don't see when the files where last imported
<juliank> All I see in the queues are "Needs Review"
<juliank> The last time I saw something different (last year?) they failed IIRC
<cjwatson> juliank: OK, that's not a Launchpad problem, that's up to translations admins to garden the import queue if appropriate
<juliank> I just wonder where the failed ones went
<cjwatson> juliank: And I think the import queue is mostly obj-*/**/*.pot which is probably boring ...
<cjwatson> juliank: Do you know if there have in fact been failures in artful?
<juliank> No
<juliank> It was back in xenial days
<juliank> In any case apt does not use the translations yet AFAIUI, but if they are at least working on the translate side, that's good.
<juliank> Gotta add some langpack hack into apt add some point, so it prefers langpack ones over its own files
<cjwatson> juliank: The way the imports are apparently per-architecture due to these obj-* directories is pretty suboptimal.  Is there a way to avoid that?
<juliank> Well, there are always ways to make that different, but that's the build directory debhelper picks, and I build the pot files in the build directory
<juliank> It would be enough to just try the import on amd64 and ignore the others or something
<juliank> I think that's the same with most packages really, or does any build arch-specific po(t) files?
<cjwatson> Most packages ship them in source tarballs
<cjwatson> Though they do often get updated
<cjwatson> (usually in place though, not in obj-* directories)
<cjwatson> Anyway, we can just import them all I imagine
<cjwatson> Let me see what I can do
<juliank> Well, we combine and split the files, as we have one domain to translate really (apt-all), but several target domains (apt-utils apt-doc, etc)
<juliank> We only ship the apt-all .pot and .po files in the source package, as we want them to be translated as one, as they can share strings
<juliank> There was the idea to just move to one "apt" translation domain and ship them in apt-common or something
<juliank> That's about 3 MB of translations
<cjwatson> juliank: I'm a bit confused by the separate .sh.pot and .c.pot templates - are those intentional?
<juliank> cjwatson: They are the results of running xgettext against sh and the c++ files, and merged into the normal .pot
<cjwatson> juliank: I think it might make things less confusing if you removed those temporary files ...
<juliank> There's a lot of weird caching and stuff in the build system going on
<cjwatson> juliank: At least before dh_builddeb runs
<juliank> cjwatson: I guess it's easier to just rename them .c-pot and .sh-pot or something :)
<cjwatson> That would work too, yes
<cjwatson> I'll block them for now
<juliank> cjwatson: I'm really thinking about just dropping the split translation domains and stuffing it into apt-common or something, that reduces .mo space requirements from 5.7 to 2.7 MiB on a system with both apt and apt-utils installed; and fixes all issues with launchpad imports
<juliank> Then it just gets po/apt.pot and po/*.po :)
<juliank> Forget the 5.7 quote, it's more like half of it (2.8)
<juliank> xnox: If net-update is really disabled everywhere now, I'd prefer dropping the code from apt-key. I was just triaging bugs :)
<juliank> If we don't really want it anymore, let's just kill it :)
<juliank> If anyone here is interested in merging all apt translations into apt-common: The sizes are: just apt: 2374622; with apt-utils: 2930575, combined: 2806311
<juliank> That is +0.5 MB for a tiny chroot without apt-utils, and -0.1MB for a normal system with both
<cjwatson> juliank: I've done the requisite clickyclicky now
<juliank> cjwatson: Thanks
<juliank> I guess the code for making langpacks work is to just call bindtextdomain("/usr/share/locale-langpack") under some condition (as in: an apt translation exists in there). Preferably I'd like to try both, but unfortunately it does not seem gettext allows that
<juliank> And well, do the binding fun in library init functions
<juliank> or in InitConfig or something
<juliank> The alternative would be to have an "apt-langpack" domain that the langpack uses and then just check apt-langpack first and fall back to the normal domain if that fails
<juliank> (per-msgid fallback)
<juliank> The hacky solution is probably to just decide based on which .mo file is larger
<rbasak> pdeee: I'm working on the SRU exception documentation. Thank you for the docs you had prepared in relation to this. I'm going for documenting a full standing exception based on that documentation, so we don't need to detail every change on every update. My draft (work in progress) is at https://wiki.ubuntu.com/StableReleaseUpdates/Certbot. Can you suggest anything specific that we could use as a
<rbasak> process to make sure that a proposed update (once built and available to users) is good, which we can ensure is done before pushing the update out to users?
<rbasak> bmw: ^
<juliank> cjwatson: Re bug 1123272 - I think we could potentially improve apt downloading speed by 50% by switching from MD5+SHA1+SHA256 to MD5+SHA512 (as SHA512 is 50% faster than SHA256, and we drop one hash, though md5 would be nicer to drop)
<ubottu> bug 1123272 in apt (Ubuntu) "high cpu usage on download (not optimised SHA256, SHA512, SHA1)" [Wishlist,Confirmed] https://launchpad.net/bugs/1123272
<juliank> Because apt validates them all, that seems to be a bottleneck for high-bandwidth, slow-cpu users
<juliank> things might look different on 32-bit system, no idea
<juliank> grr, people in 1123272 are annoying
<juliank> in bug 1123272
<juliank> "APT downloads have CPU bottleneck, everything is fine with CURL"
<ubottu> bug 1123272 in apt (Ubuntu) "high cpu usage on download (not optimised SHA256, SHA512, SHA1)" [Wishlist,Confirmed] https://launchpad.net/bugs/1123272
<juliank> lol
<juliank> Seriously, we run 3 hashes on the input, and curl does like nothing.
<juliank> Will things improve if we run verification and download in parallel?
<Unit193> juliank: Pretty sure the slowdown I hit might be re-compressing.
<Unit193> *might be*, I don't know.
<juliank> Unit193: Well, that only happens with pdiffs or acquire::gzipindexes
<juliank> and achieves about 200 MB/s or so
<juliank> or was it 1GB/s?
<Unit193> On your hardware*
<juliank> ehm, 2 GB/s
<juliank> Yes, but it's a 5 year old midrange laptop CPU
<cjwatson> juliank: Or we could only check the strongest.  There's not much point in checking multiple hashes
<juliank> cjwatson: Well, yeah, mostly, they are all MD constructions anyway
<juliank> But if we add something like SHA3 or BLAKE2b, we probably do want to run all available ones (one per family)
<sarnold> you'll never please security nuts
<juliank> We can at least make checking of untrusted hashes optional
<sarnold> yeah no point in burning cpu time on md5
<Unit193> sarnold: Teeechnically since md5 and sha1 are broken, if you check both then it's "safe enough" :>
<juliank> Well, SHA1 is also marked untrusted
<juliank> But then it also checks file size via the same mechanism
<sarnold> Unit193: yeah I haven't seen any polyglot sha1 and md5s. yet.
<juliank> So you need to factor in cost or special case filesize
<juliank> Optimally, right now, we'd use SHA-512 on 64-bit, and SHA-256 on 32-bit platforms
<juliank> As SHA-512 is about 50% faster than 256 on 64-bit, or even more
<Unit193> sarnold: BTW, seen anything in security team about irssi or gnome-exe-thumbnailer?
<sarnold> Unit193: I've seen the gnome-exe-thumbnailer bug, dunno if it's had any progress yet
<sarnold> juliank: yeah; or maybe blake2*mumble* everywhere?
<Unit193> sarnold: Was just uploaded to Debian, has CVE-2017-11421 now.  I poked md<tab> a few days ago about Irssi, as I'd already done themerge.
<ubottu> gnome-exe-thumbnailer before 0.9.5 is prone to a VBScript Injection when generating thumbnails for MSI files, aka the "Bad Taste" issue. There is a local attack if the victim uses the GNOME Files file manager, and navigates to a directory containing a .msi file with VBScript code in its filename. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11421)
<juliank> sarnold: Well, I'd like to couple blake2 with a sha2, to have something very-well-researched in there
<juliank> And BLAKE2b is fast on 64-bit only, on 32-bit you'd want BLAKE2s
<ahasenack> hi, could someone please accept my nominations for bug #1698758 ?
<ubottu> bug 1698758 in libapache2-mod-auth-pgsql (Debian) "Encrypted password causes segmentation fault" [Unknown,New] https://launchpad.net/bugs/1698758
<juliank> So ship SHA256+SHA512+B2s+B2b?
<sarnold> juliank: oh there's an idea that never occurred to me
<sarnold> four hashes but check the fastest two on each platform? heh
<juliank> and then pick (SHA512, B2b) or (SHA256, B2s) depending on whether 64 or 32 bit
<Unit193> Unfortunate that b2sum only supports one method.
<juliank> Yep
<juliank> The coreutils variant was stripped down
<juliank> The initial one supports all variants
<juliank> B2b + SHA512 should run in like 5.3 seconds or so here
<juliank> for 1GB
<juliank> Like 20% slower than SHA256 on its own
<Unit193> juliank: What, other than b2sum and openssl 1.1, does blake/keccak?
<cjwatson> sarnold: polyglot sha1/md5 was demonstrated something like ten years ago
<cjwatson> more, I think
<cjwatson> sarnold: it's about six bits harder than sha1 alone
<sarnold> cjwatson: sorry, I meant _collided_ sha-1/md5 polyglots..
<cjwatson> sarnold: that's the Joux multicollisions result, surely?
<sarnold> cjwatson: let me go read! :D
<cjwatson> sarnold: I admit I don't know if there've been *specific* collisions demonstrated, only the theory
<juliank> Unit193: librsync, argon2 algorithm, the noise protocol, amongst others, use blake2
<juliank> See https://blake2.net/#us
<Unit193> juliank: Sorry, I was referring to frontend commands.
<juliank> Oh
<Unit193> Figured you might know offhand.
<juliank> I don't think there are any other tools
<juliank> SHA3 is done by nettle-hash in nettle-bin
<juliank> and well by rhash, but that's incredibly slow IIRC
<juliank> I guess we'll add a helper to apt shortly
<juliank> Like /usr/lib/apt/apt-helper hash-file or something
<juliank> It's really not a lot of code, and quite useful :)
<mapreri> cjwatson, infinity: I'm looking at the devscripts delta, and I wonder whether we really need it.  If 'needs-recomends' doesn't pull the recommends that's an autopkgtest bug, not something that should be done in devscripts.
<mapreri> also it looks rather odd.
<mapreri> I'd personally say to just sync it now, and see how it goes with the upcoming perl transition
<cjwatson> mapreri: I disagree that it's an autopkgtest bug that it doesn't pull recommends.
<cjwatson> mapreri: But you can sync it if you promise to be responsible for cleaning up any resulting breakage in the next Perl transition, I guess (and if the debhelper dependency is no longer needed either)
<mapreri> well, if I write 'Restriction: needs-recommends' it means I really want the recommended packages installed, doesn't it?
<mapreri> cjwatson: I was about to add those packages in devscripts.git in debian, but then realized that to me they look mostly noise/cruft...
<cjwatson> mapreri: I'm not sure it necessarily means that they should be treated as hard dependencies for the purposes of the dependency resolver; I don't remember the details, I just remember it being difficult to reason about
<cjwatson> mapreri: Mostly I don't want us to have to disentangle the whole mess again, so perhaps do me a favour and don't go through the whole Perl stack removing all of the workarounds of that form in one go?
<mapreri> I have no intentions (nor the time!) to go through all of perl :)
<mapreri> was just interested in devscripts
<mapreri> cjwatson: I'll just sync devscripts, and keep an eye on it after the perl transition starts :)
<mapreri> cjwatson: do you know if ubuntu plans to do it at the same time of debian, or when?
<xnox> i'm not sure if needs-recommends was ever implemented properly
<cjwatson> mapreri: don't know
<cjwatson> I assume depends on timing with respect to freezes as usual
<bmw> rbasak: what kind of testing did you have in mind and what limitations are there on the environment the tests can be run in?
<doko> mwhudson: is cloud-init now the only thing blocking 3.6 as the default?
<doko> tumbleweed: debconf ping
<mwhudson> doko: yeah, i think so
<mwhudson> doko: i mean there's a bunch of failures in universe still but most of those are in the archive too
<mwhudson> whut https://launchpadlibrarian.net/329584191/buildlog_ubuntu-artful-amd64.pylint_1.7.2-0ubuntu1_BUILDING.txt.gz
<doko> mwhudson: as a work around, would it be possible to use 3.5 explicitly?
<mwhudson> pretty sure that built locally
<mwhudson> oh well
<mwhudson> doko: the patch to cloud-init is known and i think smoser thinks the last upload included it
<doko> I mean, that would mean that we have to keep 3.5 as supported, but it would be a way forward
<mwhudson> so as a cloud-init upload is needed i'd rather see if we can use the right fix...
<mwhudson> afk for 5-10 sorry
<rbasak> bmw: integration/functional test level, for the entire set of proposed certbot updates for a particular Ubuntu release. I'm interested in catching things that are introduced after your tests for release, so things like packaging issues and differences in dependency versions and so on.
<rbasak> bmw: I'd like whoever is driving the SRU (hopefully you or someone under your direction) to be able to do this, so any environment available to you really. Both manual and automatic tests are fine with me.
<rbasak> bmw: the idea is that we will build built binaries for the proposed SRU. This will be opt-in to all users interested in testing.
<rbasak> bmw: once verified by whatever process we can try to define now, the Ubuntu SRU team will release the packages (exactly the same build) to "automatic updates", rather than opt-in. Anyone with certbot packages installed who grabs "all" updates (apt upgrade, etc) will get them.
<mwhudson> oh that build passed locally because it installed the package from pypi :(
<bmw> rbasak: got it
<bmw> probably the best thing to run for that is our integration tests against a version of boulder (Let's Encrypt) running locally
<bmw> we have instructions for how to do this here: https://certbot.eff.org/docs/contributing.html#integration-testing-with-the-boulder-ca
<bmw> but they'll differ a bit when using it with the built packages
<bmw> it's also worth noting that our integration tests aren't included in the built packages so the instructions for how to get and run them will be a bit different
<bmw> I'm happy to write up something describing how to do this
<rbasak> bmw: sounds good! If we can define these tests, would you be able to arrange to get them performed per proposed SRU? So for the 0.14.2 SRU, that'll be three times: for 16.04, 16.10 and 17.04.
<rbasak> (16.10 will be EOL soon)
<rbasak> bmw: if you could do that please, then we can put the test definition in the formal policy document for Ubuntu SRUs, and then use it as part of the release process.
<rbasak> bmw: this is all that's left to define really. Apart from that, we're ready :)
<bmw> that's exciting :)
<bmw> I'll write up how to do it and run them for the three versions of Ubuntu tomorrow
<rbasak> Thanks!
<rbasak> bmw: no need to run them yet though. Let's define the process first. For the SRU we'll need them run against the proposed built packages, and we don't have those yet.
<bmw> oh that's my misunderstanding
<bmw> I thought those were done and reviewed
<rbasak> The code changes are ready and reviewed.
<rbasak> And I've built locally and in a PPA etc.
<rbasak> But the build for publication to the Ubuntu archive is done in a separate environment. I can only push source to that, not binaries.
<bmw> ah okay
<bmw> I'll probably need help in my instructions for how to install packages from there, but I'll write up the rest
<rbasak> bmw: https://wiki.ubuntu.com/Testing/EnableProposed - this might be a little out of date. The CLI method should still work.
#ubuntu-devel 2017-07-19
<bmw> thanks
<rbasak> bmw: once we have the test process defined and approved, then I can upload/accept the reviewed branches into the proposed pocket for building.
<rbasak> bmw: I'd like the agreed test process to end up in https://wiki.ubuntu.com/StableReleaseUpdates/Certbot, but it's fine for that to refer to some other versioned document.
<bmw> OK
<bmw> I'll largely write the instructions there with a couple external links
<snayzix> Hellp
<snayzix> Is someone here ?
<doko> apw: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/armhf/l/linux/20170718_191215_9b786@/log.gz  is this temporary and should be retried?
<apw> doko, i would say so, yes
<doko> chrisccoulson: I see that indicator-messages was demoted, but thunderbird still depends on it. can it be built without indicator-messages?
<didrocks> doko: we still want unity to use it
<doko> didrocks: so promote it again?
<didrocks> so, the unity session still ship the indicator
<didrocks> hum
<didrocks> I was told that packages in main can build-dep on packages in universe, and so, was ok to demote
<didrocks> (and it's only a build-dep, no lib linking in any package in main)
<didrocks> (I guess that's why it doesn't show as source wanted to migrate in main in component_mismatch if I'm correct)
<doko> didrocks: right, but it has a runtime dep as well: thunderbird-gnome-support/amd64 unsatisfiable Depends: libmessaging-menu0
<didrocks> doko: we should demote thunderbird-gnome-support
<didrocks> that's why I dropped it to suggests
<didrocks> (thunderbird suggests thunderbird-gnome-support and unity-session recommends thunderbird-gnome-support)
<doko> didrocks: it's seeded
<didrocks> by:
<didrocks>   ubuntukylin-desktop
<didrocks>   ubuntu-mate-desktop
<didrocks> which as in universe
<didrocks> is it seeded anywhere else? I don't see it in http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.artful/all
<didrocks> I unseeded from supported in revno: 2550
<didrocks> timestamp: Thu 2017-07-13 10:15:52 +0200
<didrocks> is there anything else missing?
<doko> hmm
<didrocks> also, I did a ./change-override -c universe thunderbird-gnome-support thunderbird-gnome-support-dbg
<didrocks> on that day
<didrocks> unsure why it's again in main
<didrocks>  thunderbird-gnome-support | 1:45.8.0+build1-0ubuntu1 | artful/universe | amd64, arm64, armhf, i386, ppc64el, s390x
<didrocks> I guess a mismatch in publication between -proposed and release pocket
 * didrocks demotes in artful-proposed as well
<didrocks> and that should get it to the release pocket
<smoser> mwhudson, doko cloud-init in archive is fine with 3.6
<smoser> bah. it should have but it doesnt. uploading one that does now.
<smoser> uploaded
<jbicha> didrocks: it's listed in supported
<didrocks> jbicha: where?
<didrocks> would be nice to have a pointer :p
<seb128> wgrant, hey, I think I hit that issue some cycles ago but any idea why evolution-data-server/evolution don't have their .po imported in launchpad for artful?
<seb128> hum, and did launchpad change? my script doing getPackageUploads()[0].custom_file_urls hits a
<seb128> AttributeError: https://api.launchpad.net/devel/ubuntu/artful/+upload/16007844 object has no attribute 'custom_file_urls'
<seb128> that used to work :-/
<cjwatson> seb128: custom_file_urls stopped being exported on the devel API version in 2012.  Either use 1.0, or (better) use the customFileUrls() method instead
<cjwatson> seb128: (I made it stop being a property on devel for performance - in most cases where we want to serialise a PackageUpload to JSON we don't need to worry about computing those URLs, so moving them to a method that callers that explicitly need them can use performs better overall)
<seb128> cjwatson, thanks, that works
<wgrant> seb128: iirc eds puts its version in its template name, so each release needs manual approval. check its import queue
<seb128> I tried that early but wrongly, I somewhat didn't see it was a method and used ".customFileUrls" and got confused
<seb128> wgrant, we changed it to stop doing that, I accepted the unversionned template and fixed the template details afaik
<seb128> wgrant, I wonder if I overlooked something
<seb128> wgrant, well, https://translations.launchpad.net/ubuntu/artful/+source/evolution-data-server/+imports
<seb128> no .po there
<seb128> and we had a source upload yesterday after the new template was imported
<seb128> wgrant, https://launchpad.net/ubuntu/artful/+upload/16007657/+files/evolution-data-server_3.24.4-0ubuntu1_amd64_translations.tar.gz
<seb128> the build tarball has them
<wgrant> seb128: what are the PO paths like in that tarball?
<wgrant> (i'm on my phone)
<seb128> wgrant, source/po/<locale>.po
<wgrant> hmm. i'll have to debug tomorrow, unless cjwatson is feeling adventurous
<seb128> I wonder if that's again an issue with the translations sharing option
<wgrant> oh, possibly, yes
<seb128> https://translations.launchpad.net/ubuntu/artful/+source/evolution-data-server/+sharing-details has " Automatic synchronization of translations is enabled. "
<wgrant> i forget exactly how that logic works. it can never share atm since the template names don't match, but it probably doesn't hanske that case. might be best to unshare
<cjwatson> I traced the upload path enough to check that the upload jobs were happening, but debugging translations sharing tends to be beyond me
<seb128> seems other desktop apps have share enabled as well though
<seb128> hum
<seb128> http://bazaar.launchpad.net/~vcs-imports/evolution-data-server/trunk/view/head:/po/fr.po
<seb128> download file gives me an empty file
<seb128> I wonder if that's specific to that file or another new launchpad issue
 * seb128 tries another code page
<cjwatson> we haven't touched loggerhead in ages
<wgrant> none of these are new launchpad issues
<seb128> it works on other urls so I guess something about that file
<wgrant> your script was half a decade out of date, and eds does translations weirdly
<seb128> was doing
<seb128> :p
<seb128> but yeah, I know e-d-s is a weird case
<seb128> should be better now that the domain stops changing
<seb128> the fr.po being empty is not on my side though afaik
<cjwatson> download> https://bugs.launchpad.net/loggerhead/+bug/1153721
<ubottu> Launchpad bug 1153721 in loggerhead "File download fails (downloads empty file)" [Low,Triaged]
<seb128> cjwatson, thanks
<seb128> I didn't know "loggerhead" was the right project for that
<seb128> now I do :-)
<cjwatson> I can rename it to pit-of-despair if you like
<seb128> heh
<cjwatson> loggerhead's download thing looks broken in at least two ways
<cjwatson> 1) the view assumes that the file-id is path-encoded but it isn't
<cjwatson> 2) if you path-encode it manually (e.g. / => %2F) it then claims the file doesn't exist - I think it only works if the file-id is in the top directory of the branch, but I don't have a clear idea of why
<seb128> k
<seb128> well, I'm doing a checkout now
<cjwatson> this must have been broken since at least 2012, possibly earlier, possibly forever for all I know
<seb128> cjwatson, wgrant, translations import worked after unsetting the translations sharing box and doing an upload, https://translations.launchpad.net/ubuntu/artful/+source/evolution-data-server/+imports , I feel like we didn't do that before for a reason though but I can't remember so let's see if that has other side effects
<seb128> thanks for the help!
<dreamcat4> hi there. i'm a bit stuck with the installer, i ran it then selected 'continue testing'
<dreamcat4> however /target is still mounted and will not unmount
<dreamcat4> perhaps there is some /dev /proc stuff mounted into it?
<dreamcat4> ok... nothing is working for me (and umount /target still fails)
<dreamcat4> need help
<wxl> dreamcat4: if you're looking for support, #ubuntu is the place to be
<dreamcat4> wxl: oh nevermind then. but maybe you should know this to be a bug then?
<dreamcat4> as it didnt happen with the 16.04 installer prior
<wxl> dreamcat4: i know of no bug
<wxl> dreamcat4: i would start by looking at the integrity of the image
<dreamcat4> sounds like a complete waste of time to me...
<wxl> well, best of luck
<dreamcat4> it happened only with the default option 'erase whole disk'
<dreamcat4> when i instead started with 'ubiquity --no-bootloader', and then selected 'something else' (fresh install), and created only single ext4 partition (into a zvol). then /target was not left kept mounted anymore, upon selected 'continue testing' at end of installation
<dreamcat4> ... seems to be a bug that only appears under certain conditions
<dreamcat4> like i said: didnt happen with 16.04 installer
<dreamcat4> this is current (17.10 nightly builds) desktop ISO
#ubuntu-devel 2017-07-20
<mwhudson> is it possible to have patches in a 3.0 (quilt) source package if the upstream source has dos line endings?
<mwhudson> or should i repack the source to get rid of them
<dobey> i'm pretty sure i've done that before
<dobey> (used 3.0 quilt with upstream source that has CRLF)
<mwhudson> dobey: hmm
<mwhudson> dpkg-source: info: building python-py using existing ./python-py_1.4.34.orig.tar.gz
<mwhudson> (Stripping trailing CRs from patch; use --binary to disable.)
<mwhudson> patching file testing/code/test_assertion.py
<mwhudson> Hunk #1 FAILED at 143 (different line endings).
<mwhudson> dobey: i get that ^
<dobey> trailing CRs? sounds like Mac format
<dobey> or sounds like the patch was made using an editor that didn't deal with line endings properly
<dobey> i think i hit a similar issue a long time ago once, with stuff in bzr, due to some editor wanting to screw with line endings rather than using what the file already has. iirc, fix was use an editor that didn't screw with the line endings
<mwhudson> the patch was downloaded from github (with unix line endings) and then hit with unix2dos to try to match the tarball
<mwhudson> heh so if i remove the ^Ms from the patch directives in the file but leave them in the content it works...
<mwhudson> which is pretty gross
<dobey> yeah
<dobey> the directives have to be LF only
<dobey> cheers
<mwhudson> dobey: thanks
<mwhudson> does anyone (wgrant maybe?) have tips for debugging builds that fail on lp but succeed in a schroot locally?
<mwhudson> my current bear is this one: https://launchpad.net/ubuntu/+source/python-argcomplete/1.8.1-1/+build/12554534
<wgrant> mwhudson: Have you looked at what info you could convince it to print that might be useful?
<wgrant> Also are you testing on Linux 4.4 locally?
<cjwatson> That looks like the sort of failure that might be sensitive to whether the build's stdin is connected to a terminal.
<cjwatson> Maybe.
<mwhudson> cjwatson: hmm could be
<mwhudson> cjwatson: sbuild < /dev/null ?
<cjwatson> Worth a try.
<mwhudson> ok
<mwhudson> wgrant: yes i'm on 4.4
<cjwatson> Though surely sbuild does that for itself.
<cjwatson> Maybe also try TERM=unknown
<cjwatson> (or unsetting TERM)
<cjwatson> If you get desperate you could try juju deploying cs:launchpad/launchpad-buildd with the adjustments in http://bazaar.launchpad.net/~cjwatson/launchpad-buildd/charm/view/head:/charm/README.md to set up a pretty close simulation of an actual buildd, though that's still a bit of hassle ...
<cjwatson> (Doesn't handle the LP end, so you either have to set that up too or manually send it RPC commands as per https://dev.launchpad.net/Soyuz/HowToUseSoyuzLocally)
<mwhudson> hmm not that desperate yet
<mwhudson> cjwatson: TERM=unkown seems to have done it
<mwhudson> yep
<cjwatson> out of interest does unset TERM behave the same way as TERM=unknown?
<mwhudson> cjwatson: don't know
<mwhudson> trying now but need to run away fairly soon
<mwhudson> cjwatson: unset TERM seems to pass fwiw
<juliank> Travis is celebrating: "Trusty is soon to become the default." Oh well
<ogra_> juliank, well, its not to hard to simply use a chroot for your tests in travis ;)
 * juliank uses a docker container
<ogra_> or that
<juliank> But still, being excited about shipping 3 year old software is weird
<ogra_> well, it is fresh for another two :)
<mwhudson> doko: is idle-python3.6 being in universe a new thing?
<cjwatson> mwhudson: Interesting.  I've left that as a comment on https://code.launchpad.net/~cjwatson/launchpad-buildd/sbuild-schroot/+merge/327634
<mwhudson> doko: i guess idle3 needs demoting too?
<mwhudson> cjwatson: well i've fixed argcomplete the other way now
<mwhudson> ah yeah idle-python3.5 is in main
<doko> mwhudson: it get's pulled by the default idle-python
<cpaelzer> two times the last 20 minutes - Failed to fetch http://archive.ubuntu.com/ubuntu/dists/trusty-proposed/main/i18n/Translation-en  Hash Sum mismatch
<cpaelzer> anything going on, I thought we were out of that mismatches
<cpaelzer> hmm not reproducible anymore it seems - I'll come back if it keeps showing up
<tsimonq2> xnox: Hey there! So I was glancing at the Universe section of merges.ubuntu.com and I see your name on quite a large amount of packages towards the bottom. Mind if I work on merging those things from Debian, or would that be duplicating work?
<xnox> tsimonq2, no, as most of those will be force sync.
<xnox> tsimonq2, as that is debian copying the ocaml trasition that I have already completed in ubuntu.
<xnox> tsimonq2, most of these shoud drop off, with no merge required.
<tsimonq2> xnox: Ah ok, I didn't look into those much, I just took a rather preliminary glance.
<tsimonq2> xnox: So I should leave those packages alone or would you be OK with me requesting force syncs (by filing bug reports, I have no archive access...)?
<xnox> i'm going through the list now, and will force sync things =/
<tsimonq2> Ok, cool.
<tsimonq2> xnox: Thanks!
<xnox> if you want to steal my merges, feel free to steal _old_ merges, not 0-day merges =)
<tsimonq2> Sure :)
<bdmurray> cpaelzer: If you are not in a hurry with releasing the fix for bug 1593907 maybe we should wait another week?
<ubottu> bug 1593907 in ntp (Ubuntu Zesty) "ntpdate startup routine prevents ntp service from launching up on Ubuntu 16.04 server on system boot; manually starting ntp service works: [FIX in DESCRIPTION], just need to apply it and release a new version" [High,Fix committed] https://launchpad.net/bugs/1593907
<cpaelzer> bdmurray: I'm ok waiting
<bdmurray> cpaelzer: copy that
<bdmurray> cpaelzer: Also why did you say next week in bug 1644507? Its good by my math for time in proposed.
<ubottu> bug 1644507 in libvirt (Ubuntu Zesty) "[SRU] virt-aa-helper denied access to qcow2 backing file running nova in a snap" [Medium,Fix committed] https://launchpad.net/bugs/1644507
<Unit193> mdeslaur: Howdy.  Someone mentioned you were out thus may not have seen my query the other day.  Not sure if you've got the Irssi update prepped or not, but I had done https://launchpad.net/~unit193/+archive/ubuntu/staging/+sourcepub/8039406/+listing-archive-extra so if that "helps".
<mwhudson> people who run linters in their test suite really are just asking for trouble
<Unit193> Yes.
<mwhudson> (says the person who uploaded a new pylint last week)
<Unit193> mwhudson: Had a chance to look into that golang package again? :>
<Unit193> At least pandas is up!
<mwhudson> Unit193: i probably would have if i hadn't completely forgotten about it
<mwhudson> Unit193: which one was it?
<mwhudson> and yeah, glad pandas started working
<Unit193> golang-github-jacobsa-crypto
<mwhudson> oh this was the one with the insane build tags, right?
<Unit193> Yep!
<Unit193> "Nice" regressions: https://launchpad.net/ubuntu/+source/golang-github-jacobsa-crypto
<Unit193> Affecting gocryptfs, which ftbfs on a couple arches with that, but the version not in -proposed builds fine.
<mwhudson> doh, uploaded a fix to my ppa but of course it only builds on amd64 :)
 * mwhudson changes it to arch: any temporarily
<mdeslaur> Unit193: hi! you're looking for someone to sponsor your merge?
<mdeslaur> Unit193: I can do it tomorrow
<Unit193> mdeslaur: Generally yes, though it's one that fixes a CVE so wondered if it was on your radar or if you'd already done it.
<Unit193> CVE-2017-10965 CVE-2017-10966 Debian #867598
<ubottu> Debian bug 867598 in src:irssi "irssi: CVE-2017-10965 CVE-2017-10966" [Important,Fixed] http://bugs.debian.org/867598
<ubottu> An issue was discovered in Irssi before 1.0.4. When receiving messages with invalid time stamps, Irssi would try to dereference a NULL pointer. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-10965)
<ubottu> An issue was discovered in Irssi before 1.0.4. While updating the internal nick list, Irssi could incorrectly use the GHashTable interface and free the nick while updating it. This would then result in use-after-free conditions on each access of the hash table. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-10966)
<mdeslaur> we rated those CVEs as "low", so we won't fix them until the next round of more urgent CVEs come out
<mdeslaur> but I will sponsor your merge
<mdeslaur> thanks
<Unit193> OK, sounds fair.  Then thanks!
<mwhudson> Unit193: golang-github-jacobsa-crypto uploaded
<mwhudson> Unit193: i guess you might want to steal the patch back to debian if it works
 * mwhudson goes to do a bit more dd new member process work
<Unit193> mwhudson: Fantastic!  Thanks a bunch.
<Unit193> mwhudson: Do you happen to know if 'go install -ldflags=...' resets Debian build flags?
<mwhudson> Unit193: i don't think debian build flags are respected in the slightest by the go tool
<mwhudson> i have a half-forgotten action item somewhere to maybe change that
<Unit193> I thought not, just making sure the patch I submitted was sane.  I prefer not to touch golang. :3
<mwhudson> or at least consider making PIE the default
<Unit193> (For reference: Debian 868070_
<ubottu> Debian bug 868070 in gocryptfs "gocryptfs: '--version' option is useless, containing only 'gocryptfs'" [Normal,Open] http://bugs.debian.org/868070
<Unit193> )
<mwhudson> "pytest 3.1.3-1ubuntu1 stuck in artful-proposed for 1 day" oh man it's going to be there a lot longer than that
<tsimonq2> hehehe
#ubuntu-devel 2017-07-21
<mwhudson> so this isn't intimidating AT ALL: http://people.canonical.com/~ubuntu-archive/proposed-migration/artful/update_excuses.html#python3-defaults
<sarnold> honestly that's a lot more Pass results than I expected
<sarnold> "python-oslo.messaging/5.28.0-0ubuntu1" ... I thought openstack had decided to stick with python 2.7?
<sarnold> why's all the openstack stuff being run against python3?
<blahdeblah> that sounds like a poor life choice
<sarnold> hey some people like to rip off their bandages all at once and some people prefer to pull it off slowly little by little.. each their own :)
<mwhudson> sarnold: yeah the pass rate is pretty good, it's the sheer scale that's a bit offputting
<tsimonq2> I honestly don't get why Python 2.7 is still around... maybe I'm just too young to remember the pre-Python 3 (that rhymed...) days
<mwhudson> openstack itself is python 2 only for now, but the dependencies all build for python 3 (or don't) in preparation i believe
<tsimonq2> I installed Arch on a system the other day and it was unpleasant to figure out the hard way that some of my scripts are Python 2.7-specific...
<mwhudson> having /usr/bin/python be python 3 is just evil and wrong though
<tsimonq2> Why though? I don't get it... :P
<blahdeblah> fo0bar_: ^ Is there an echo in here? :-)
<Unit193> sarnold: Still with me?
<tsimonq2> I can't poke my usual sponsor for this one... could someone please review and/or upload the patches attached to bug 1641912?
<ubottu> bug 1641912 in gtk+2.0 (Ubuntu Xenial) "Please backport two recent-manager patches" [Critical,In progress] https://launchpad.net/bugs/1641912
<tsimonq2> (that sentence is flawed, why would someone blindly upload...?)
<tsimonq2> (reason being, this needs a Core Developer)
<sarnold> Unit193: sorry, stepped out for a dogwalk and then apparently a nap :)
<sarnold> tsimonq2: I got tired of python's constant "you're doing it wrong" way before 2.7 was even released. I figured everyone else would have given up on it too well before 3.0 days. I figured 3.0 was going to kill python entirely.
<mwhudson> python3-defaults migration actually not that bad
<mwhudson> about half of them are failures because of
<mwhudson> python3-forge        FAIL stderr: /usr/bin/py3versions:57: DeprecationWarning: invalid escape sequence \d
<infinity> sarnold: Turns out that people like to be told what they want.  That's why Python beat Perl, GNOME beat KDE, and iThings took over the world.
<sarnold> infinity: sarbuntu's going to be awesome! just vim, mutt, urxvt, firefox pre-loaded with pentadactyl, and we'll take over the world!
<blahdeblah> I, for one, welcome our new sarnold overlord
<sarnold> huzzah!
<infinity> sarnold: I feel like you might need a window manager to move your terminals and firefoxes around.
<sarnold> infinity: yeah, but i'm not a monster. i3 or dwm.
<sarnold> also irssi. I forgot irssi.
<sarnold> anyway time for dinner :)
<sarnold> (man they're going to love rust. loads of rules.)
<infinity> sarnold: Other than urxvt (I used gnome-terminal "because it's there", and due to some strange sense of responsibility to dogfood), you've described literally my entire setup.
<infinity> sarnold: Oh, except for mosh.  Can't live without mosh in that mix.
<infinity> (because my irssi and mutt are remote)
<Unit193> sarnold: Heh, well too late now! :P
<Unit193> (Because you're no longer up.)
<cpaelzer> bdmurray: I round to weeks, checking in on wednesday mostly
<cpaelzer> bdmurray: so it was too early this week (s wednesday)
<cpaelzer> bdmurray: but will be next week
<cpaelzer> bdmurray: sorry for that math simplification confusing you
<marco25> any plans on fixing this bug?? https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1656065
<marco25> ubuntu 17.04 is a peice of crap in case you guys want feedback
<ubottu> Launchpad bug 1656065 in firefox (Ubuntu) "Firefox and plugin-container (Chrome_ChildThr): segfault at 0 ip, sp error 6 in plugin-container/libxul.so" [Undecided,Confirmed]
<marco25> you guys need to make an installer than can downgrade easily to 16.04 for the punishment i have endured
<marco25> please just call non lts beta...thats basically what is
<marco25> so tonight you wonderful ubuntu devs...go into the website and where you see non lts programs you can put beta
<marco25> there
<marco25> THANKS!!!
<rbasak> Four people reporting affected since January? That's hardly a major problem.
<rbasak>  kernel: [31159.073997] [<c10fd30c>] oom_kill_process+0x5c/0x80
<marco25> ROFL
<marco25> you mean that bug
<rbasak> That's an out of memory condition.
<rbasak> Not a bug.
<marco25> well we can talk about the other bug that was freezing my pc for about 2 months..
<marco25> that had like hundreds of comments
<rbasak> Please do it in #ubuntu.
<rbasak> Unless you're here to help fix a bug.
<marco25> well the other bug says 4 people...that is obviously not everyone cause it effects me and my name aint there..
<marco25> i wish you would fix that bug it was reported in january
<rbasak> I've closed the bug as Invalid.
<marco25> out of memory not a bug so how you propose i fix it ...?
<marco25> rofl
<marco25> wow you are helpful..
<rbasak> See my comment in the bug. It links to an essay which explains why the bug report is not actionable.
<marco25> you should close ubuntu 17.04 zesty as invalid
<marco25> my memory is fine
<marco25> you notice everyone is on zesty right? ding ding ding
<marco25> i can look at it
<marco25> its probably zesty though just saying
<marco25> your joking by that link right?
<marco25> what more you want than the error reported in the kernel log?
<marco25> and everyone is using zesty?
<rbasak> Full steps to reproduce please.
<marco25> its random..
<marco25> no particular website
<rbasak> Honestly, I think a bug report is the wrong place for you to get help with this.
<rbasak> You don't yet know if the problem is a bug or not.
<rbasak> And community helpers don't hang around in the bug tracker. They hang around in places like #ubuntu and askubuntu.com.
<rbasak> The bug is also very confusing, mentioning 16.04 as well, and apparmor even though apparmor in Firefox is not enforcing by default.
<marco25> i think they mentioned apparmor because he thought it may have something to do with it
<rbasak> Perhaps, but as apparmor isn't enforcing on Firefox by default, we hardly have steps to reproduce.
<marco25> i tried to tell #ubuntu when my pc was freezing it was zesty that didnt believe me either sigh
<marco25> until they saw a trouble ticket with hundreds of comments..that got the ball rolling
<rbasak> A large proportion of "my system went wrong" reports turn out to be users misconfiguring their systems in some way. So it isn't productive to treat these as bugs that need fixing by developers until it is clear that there is actually a bug in the first place.
<rbasak> Some of these could be treated as bugs of the type "the system would be more resilient to the user doing <X>", and we'll happily accept those reports, but they're hardly sky-falling type bugs.
<LocutusOfBorg> jbicha, I'm going to fix sane-backends
<ginggs> make sane-backends sane again!
<nacc> Laney: are you planning on doing a debhelper merge soonish?
<Laney> nacc: not in particular
<Laney> if you want to take it off my hands, feel free - otherwise I can put it on my list for next week
<nacc> Laney: ok, i can do it, some debian packages are starting to get deps on newer dh it seems, thanks!
<Unit193> nacc: Mason support desired?
<Laney> we have that
<nacc> Unit193: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866978
<ubottu> Debian bug 866978 in src:freeradius "freeradius FTBFS: recipe for target 'override_dh_missing' failed" [Serious,Fixed]
<nacc> Unit193: they did a fix in freeradius, and then dropped it by debhelper fixing it but now depend on that fix being present
<Laney> keeping up is a good idea
<Laney> the merge itself should be easy enough
<Laney> owning any regressions in ubuntu, however, ... :)
<Laney> 10.4 was a bit bumpy
<nacc> Laney: yep, i'll take it on (will at least file a bug today, i may not get to the merge until first thing next week (after a few swap days))
<nacc> Laney: yeah, I'll try and read through everything in the changelog to be prepared :)
<Laney> nacc: ok, I've written it on my list - I'll claim the bug if I get there before you
<Laney> thanks for the poke
<nacc> Laney: np
<nacc> Laney: thank you!
<LocutusOfBorg> thanks, I have some transitions blocked by debhelper too
<Laney> LocutusOfBorg: you can also feel free to do it
<Laney> :-)
<LocutusOfBorg> I was going to ask you some days ago, but then I moved to something else
<LocutusOfBorg> you know, breaking debhelper is something I'll be happy to put on my CV
 * LocutusOfBorg pun intended
<mwhudson> hmm i see quite a few 'temporary failure in name resolution's on armhf autopkgtest
<Laney> yep
<Laney> going to abuse stgraber into looking at that with me when I see him at debconf :-)
<jbicha> LocutusOfBorg: thank you for sane-backends!
<jbicha> hmm, we're going to need another sane-backends upload though for Debian RC bugs
<Bluefoxicy> heh how useless
<Bluefoxicy> suspend doesn't work from the log-in screen in 17.04. Log into gnome-shell, suspend from the menu.
<jbicha> Bluefoxicy: there are some hidden ways to suspend from the login screen LP: #1697143
<ubottu> Launchpad bug 1697143 in gnome-shell (Ubuntu) "GNOME Shell's Suspend feature is hidden in power menu" [Medium,Confirmed] https://launchpad.net/bugs/1697143
<jbicha> close your laptop lid, long-press the Power button in the top right of the screen, or hold Alt and press that Power button
<Bluefoxicy> jbicha:  desktop doesn't have a lid.
<Bluefoxicy> and you can hold alt and press power in gnome shell
<Bluefoxicy> but on the log-in  screenâyou know, where you enter your password to get to the desktop?âthere's a Suspend thing in the menu
<Bluefoxicy> that doesn't work.
<Bluefoxicy> you have to log in before you can suspend
<Bluefoxicy> apparently it won't auto-suspend from the log-in screen, either
<Bluefoxicy> so if it's suspended and you lose power, then it'll come back up and just stay on until someone logs in
<Bluefoxicy> work time
<LocutusOfBorg> jbicha, I don't know if the fix was sane or not
<jbicha> heh
<jbicha> LP: #1705691 points to the remaining issues
<ubottu> Launchpad bug 1705691 in sane-backends (Ubuntu) "sane-backends 1.0.27 has several RC bugs" [High,Triaged] https://launchpad.net/bugs/1705691
<LocutusOfBorg> jbicha, can't you nmu in debian and then sync?
<jbicha> I'm not a DD yet
<LocutusOfBorg> I can sponsor
<jbicha> sane-backends isn't syncable without https://bugs.debian.org/868265
<LocutusOfBorg> just give me a debdiff
<ubottu> Debian bug 868265 in sane-utils "sane-utils: Don't recommend sane-backends-extra" [Normal,Open]
<LocutusOfBorg> true...
<LocutusOfBorg> so, fix the 4 bugs and ask me to sponsor
<LocutusOfBorg> jbicha, in your opinion: can we avoid a transition by adding something like: Provides: libsane?
<LocutusOfBorg> to libsane1
<cjwatson> Does anyone remember where the page with pie charts with most frequent uploaders to each Ubuntu release was?  I seem to have lost it
<xnox> cjwatson, http://bazaar.launchpad.net/~stefanor/+junk/ubuntu-activity/files is the code for it, it used to be on people.ubuntuwire.org done by tumbleweed
<LocutusOfBorg> sorry Laney I'm giving up wrt debhelper, it was trivial, but now it fails on repack
<cjwatson> ubuntu-activity, that was the keyword I needed to search logs
<cjwatson> http://people.ubuntuwire.org/~stefanor/ubuntu-activity/ stops at yakkety though
<cjwatson> xnox: thanks
<xnox> some of it seems to work, but i guess the underlying ubuntuwire database is dead / stopped due to ubuntuwire outage =/
<xnox> maybe wgrant or tumbleweed or Laney know more
<smoser> anyone have an idea.... prior to artful (and probably using gdm3/gnome) i had a bluetooth headset that pretty much "just worked".
<smoser> now, i turn it on, the bluetooth icon shows up in the panel at the top.. its definitely connected, but the audio wizard doesn't show it, so i can't put any sound through it or use its mic.
<smoser> anyone seen this ?
<seb128> smoser, by "wizard" you mean settings?
<seb128> smoser, and no, a stack of bluetooth and pulseaudio issue got fixed and it's supposed to work much better than it used
<smoser> yeah
<smoser> wizard.
<smoser> where did i come up with that word
<smoser> seb128, yeah, gnome settings 'audio' button
<seb128> smoser, what about control center -> audio panel ?
<jbicha> LocutusOfBorg: I don't know (about Provides avoiding transition)
<LocutusOfBorg> jbicha, dropped symbols, needs transition
<LocutusOfBorg> I'm uploading shortly
<wgrant> xnox, cjwatson: ubuntu-activity fixed.
<wgrant> udd got a bit big.
<wgrant> needed some RAM shuffling
<LocutusOfBorg> stefanor might need to rerun the script now?
<LocutusOfBorg> does it have a cronjob?
<wgrant> LocutusOfBorg: I already have.
<wgrant> The page shows artful now.
<cjwatson> oh, cool, thanks
<LocutusOfBorg> maybe my ff cache needs a kick :D thanks
<cjwatson> gosh, that's quite significant, Canonical/community upload ratio dropped below 50% in the zesty cycle for the first time
<cjwatson> I guess mostly because LocutusOfBorg started doing Haskell transitions, but still :-)
<wgrant> Heh
<LocutusOfBorg> remove haskell from that chart!
<doko> mwhudson: I setup http://people.canonical.com/~ubuntu-archive/transitions/html/python3.6.html
<smoser> seb128, what is that ? i'm sorry i just dont know the right words.
<LocutusOfBorg> one day Ill undertand why I'm on that graph both with my name and nick
<smoser> i click panel (on top) -> settings icon -> it pops up a window 'All Settings'. i click 'Sound'
<seb128> smoser, right, that's the settings panel
<seb128> smoser, I though you were just trying to use the indicator
<Faux> Ooh, I see an ssl1.1 transition on there. Is it going to happen before 18.04?
<smoser> seb i think that pulse audio just doesn't see it. the bluetooth settings shows it and shows 'Connected'
<tsimonq2> sarnold: Wow, OK.
<smoser> but 'pactl list' doesn't show anything
<smoser> does anyone have pulseaudio/gnome/bluetooth working on artful ?
<LocutusOfBorg> jbicha, sane-backends uploaded
<LocutusOfBorg> can you please give it a look?
<jbicha> you could probably just use << 1.0.27 for your breaks/replaces
<jbicha> LocutusOfBorg: btw, it FTBFS on non-amd64
<LocutusOfBorg> sigh
<LocutusOfBorg> reuploaded
<LocutusOfBorg> I tested amd64 only lol
<Laney> that's one way to stay at the top of the upload chart
<LocutusOfBorg> I was fixing the upgrade path issue, so I did two builds, old-new
<LocutusOfBorg> btw I wouldn't have spotted that bug even by doing an i386 build, because by default pbuilder does arch all+any
<tsimonq2> Laney: Any chance you could take a look at my patches on bug 1641912? I see you're the most recent uploader in Zesty and Artful.
<ubottu> bug 1641912 in gtk+2.0 (Ubuntu Xenial) "Please backport two recent-manager patches" [Critical,In progress] https://launchpad.net/bugs/1641912
<Laney> tsimonq2: ok - but probably not today
<tsimonq2> Laney: Sure :)
<ginggs> tsimonq2: i'm looking at nodejs now
<tsimonq2> ginggs: Wonderful.
<tsimonq2> ginggs: Meaning, my patch merging from Debian or on your own? Either works. ;)
<ginggs> ginggs: i mean i'm looking your merge of nodejs now
<ginggs> tsimonq2: even ^
<tsimonq2> ginggs: ack, thanks :)
<tsimonq2> ginggs: Oh shoot, I didn't see the merge was that new...
<ginggs> tsimonq2: what do you mean?
<tsimonq2> ginggs: I got the merge off of merges.ubuntu.com and didn't see that it was only 2 days old
<tsimonq2> ginggs: I'll usually wait a couple of days to make sure I'm not duplicating work, and since I don't have archive upload access (yet), I'll have to use bug reports for now, and not everybody checks those before uploading...
<ginggs> tsimonq2: nothing wrong with that, and i had written 'feel free to take' in the comments column of https://merges.ubuntu.com/universe.html
<tsimonq2> ginggs: Oh ok, just wanted to make sure ;)
<tsimonq2> And now I remember, that's why I took it :P
<ginggs> tsimonq2: uploaded, thanks for the merge! - that should keep the autopkgtesters busy for most of the weekend
<tsimonq2> ginggs: Thanks :D
<tsimonq2> ginggs: I'll keep my eye on it
<bmw> rbasak: in case you didn't see it, I put instructions for how to run integration tests on proposed certbot updates in the bug on launchpad
<rbasak> bmw: I saw it, thanks! Sorry I haven't managed to look at it yet. It's in my queue.
<bmw> great! just wanted to follow up
<sarnold> infinity: hah, yes, mosh is double-plus good. I couldn't tolerate gnome-terminal well enough to even dogfood it. :( (unity in xenial's finally pretty good, it almost pretends to be a tabbed window manager, and it hasn't forgotten any settings in ages)
<tumbleweed> cjwatson: I wouldn't really trust the canonical vs non-canoical data in ubuntu-activity
<tumbleweed> it's full of thumbsuck, and doesn't understand that people move in and out of canonical
<tsimonq2> Logan: Hey there, so I was just looking at kanatest and I was wondering if it was force syncable or if we still need to maintain part of the delta. Debian created a patch that applied part of our delta but not all of it. You're the last uploader in Ubuntu so I wanted to see what you thought. :)
<tsimonq2> Logan: Here's the patch that Debian has now: https://anonscm.debian.org/viewvc/pkg-games/packages/trunk/kanatest/debian/patches/remove-DISABLE_DEPRECATED-flags.patch?view=markup
<cjwatson> tumbleweed: fair enough
<tsimonq2> Logan: It completely removes "-DGDK_PIXBUF_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED" in Debian but in Ubuntu we remove "-DGDK_PIXBUF_DISABLE_DEPRECATED" in two different places. Thoughts?
#ubuntu-devel 2017-07-23
<Logan> tsimonq2: taking a look
<Logan> tsimonq2: should be safe to sync - I'd do a test build first to ensure that it still doesn't complain about the implicit pointer conversion
<mwhudson> sigh, distro development:
<mwhudson> python-setuptools is held in proposed by the diffoscope autopkgtests which fail for a reason that is 100% not due to setuptools
<mwhudson> diffoscope has its own version in proposed which ftbfs for an entirely different reason
<mwhudson> and it builds in sid
<mwhudson> fabulous
<Unit193> Sounds like you're having a wonderful day.
<mwhudson> i guess the autopkgtest failure should be hinted
<mwhudson> and the other crud can be left for the next person
<Unit193> Can I bother you really horribly and request a retry of gocryptfs on the failing arches?
<mwhudson> Unit193: how horrible indeed!
<mwhudson> (done)
<Unit193> Thanks, good sir.
<mwhudson> what'
<mwhudson> s the easiest way of poking a file into a chroot?
<mwhudson> schroot
<Unit193> You mean, cp foo.deb /var/cache/pbuilder/build/28204/buildd/ ? :P
<mwhudson> well sbuild for that, yes
<Unit193> I've only done that once or twice when the build failed and it dumped off into the chroot.  Never used sbuild in my life. :3
<mwhudson> fair enough
<mwhudson> ah both schroots mount a shared scratch area
<mwhudson> grrr http://paste.ubuntu.com/25158654/
<slangasek> tdaitx: do you know why the new openjdk-9 package seems to cause an autopkgtest regression (reproducible) on s390x?
<xnox> i should go to sleep if slangasek & mwhudson are awake =)
<mwhudson> xnox: you sure you don't want to agonize over details of binutils behaviour changes?
<xnox> binutils is dark magic to me, and when the dark magic changes i get very nervous. Cause i'm like - was the previous dark magic too grey?!
#ubuntu-devel 2018-07-16
<tsimonq2> Bluefoxicy: What source package are we talking about?
<doko> bdmurray: could you have a look at the valgrind autopkg test failure triggered by apport? (note that that might change again with today's binutils upload=
<doko> )
<bdmurray> doko: I'd have phrased that as the apport autopkgtest failure triggered by valgrind if you are talking about http://autopkgtest.ubuntu.com/packages/a/apport/cosmic/amd64
<doko> yep
<GunnarHj> bdmurray: Can you please do me a favor and drop the freshplayerplugin uploads in the bionic and xenial queues. (I'm just preparing new variants which I will propose instead.)
<bdmurray> GunnarHj: Sure!
<GunnarHj> Thanks bdmurray!
<bdmurray> doko: I retried it and it passed for amd64
<doko> bdmurray: did you retry for other archs as well? for other packages as well?
<bdmurray> doko: retrying for i386 too, is there anything else?
<doko> bdmurray: at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html I see triggers for valgrind, python-apt, mate-terminal, .... sorry if I'm missing some
<bdmurray> doko: Okay I see what you are looking at now and I'll likely just be clicking retry
<sil2100> !dmb-ping
<ubottu> cyphermox, jbicha, micahg, rbasak, sil2100, slashd, tsimonq2: DMB ping.
<doko> cpaelzer: qemu needs a MIR for capstone
#ubuntu-devel 2018-07-17
<cpaelzer> doko: thanks for the info, I thought I checked all new things (the gtk change brought a lot), will take a look at capstone if it will be a MIR or a drop of the Dep
<cpaelzer> ok checked, I'll do both after breakfast
<xnox> doko, boost1.67 is accepted in debian, should i be preparing and uploading boost-defaults update?
<doko> xnox: yes please, the tracker already is there. please wait with the binNMUs for the gcc-defaults upload
<xnox> doko, ok, will do that.
<ginggs> bdmurray, doko: apport's tests eventually passed after several retries
<didrocks> ginggs: the failing tests have a timeout() and so, are racy IMHO
<didrocks> ginggs: bug #1780767
<ubottu> bug 1780767 in apport (Ubuntu) "Some tests are flaky due to timeout" [Undecided,New] https://launchpad.net/bugs/1780767
<xnox> doko, libquadmath0 is available on ppc64el, but it is not a dependency of libgfortran
<xnox> doko, does fortran need to be built with quadmath enabled? or is that not available?
<xnox> doko, imho https://paste.ubuntu.com/p/9DtqmSmfqT/
<xnox> note the "without architecutres are on amd64, i386, ppc64el" which imho should be the case across the board for all of these, no?
<doko> hmm, it's enabled ...
<xnox> doko, well, in gfortran i see that quadmath usage appears to be guarded with #if defined(GFC_REAL_16_IS_FLOAT128)
<xnox> which might be not true on ppc64el or somesuch?
<xnox> basically, i looks like i need to redo my meson fix to exclude ppc64el, wince quadmath is available, but currently not in use by libgfortran on ppc64el.
<juliank> slangasek, cjwatson We got a wishlist bug in Debian about adding support for zchunk, a chunked compression format thingy to apt. My understanding is that our problem with pdiffs is that we update too ften for them to work, but I just thought zchunk might be something that works for us
<juliank> It's what Fedora plans to use for its repo metadata
<juliank> It would be complicated since it relies on range requests and stuff
<juliank> and I think, us storing the files unmodified and compressed in apt's list dir
<doko> xnox: libgcc-8-dev depends on libquadmath0, but libgfortran doesn't need it apparently
<xnox> doko, https://packages.ubuntu.com/cosmic/libgfortran5
<xnox> doko, libquadmath0 (>= 4.6) [amd64, i386]
<xnox> doko, or you mean it doesn't need it on ppc64el only?
<juliank> It does sound interesting, tough
<doko> xnox: it's linked, but apparently not needed:  -lquadmath -lz -lm  -Wl,-z -Wl,relro -Wl,-z -Wl,relro -Wl,--version-script=../../../src/libgfortran/gfortran.map -shared-libgcc   -Wl,-soname -Wl,libgfortran.so.5 -o .libs/libgfortran.so.5.0.0
<xnox> O_o
<xnox> i don't know how to detect this correctly in meson terms; so i'm hardcoding to use -lquadmath with fortran under special flags on ubuntu on intel-only then.
<xnox> cause -lquadmath on any arch, unconditionally is then wrong.
<Woodpecker> Hey id like to have a page on ubuntu.com scrubbed that contains my contact info. Its cuasing me issues. https://wiki.ubuntu.com/community/Kivi
<halvors> I found bugs in systemd-networkd which breaks DHCPv6 Prefix Delegation. Fixes are easy to patch, is it possible to request to get backported 2 commits from systemd master into ubuntu's packages 237 version?
<halvors> I found a bug in systemd causing DHCPv6 Prefix Deletion not to work, is it posible to get commits backported from upstream master to 237 ubuntu package? Small changes needed in order for this to work.
<sarnold> halvors: take a look at https://wiki.ubuntu.com/StableReleaseUpdates for a guide on getting fixes into a release
<halvors> So basically this would take mounths full time to get fixed?
<halvors> sarnold: Sadly seems to be so much work that i'm better of just patching it myself and not to share it with the community :(
<halvors> sarnold: I'm not an ubuntu developer.
<tsimonq2> halvors: One week minimum.
<tsimonq2> Not months.
<tsimonq2> And really, if you're willing to test, it's just putting patches in a idrectory.
<tsimonq2> *directory
<halvors> If it get's fixed in debian, will it downstream to ubuntu stable?
<tsimonq2> Not to Ubuntu stable.
<halvors> tsimonq2: Not patches, links to git commits.
<tsimonq2> Are you willing to backport the commits yourself?
<tsimonq2> It's not too hard if you know the codebase, I'd say.
<tsimonq2> Here's a handy guide: https://raphaelhertzog.com/2012/08/08/how-to-use-quilt-to-manage-patches-in-debian-packages/
<halvors> tsimonq2: I don't know the codebase, i'm as i said not an ubuntu developer.
<tsimonq2> halvors: I'm an Ubuntu Developer and I don't know the systemd codebase well. ;)
<halvors> It's not a matter of backporting actually, just
<halvors> tsimonq2: applying commits to the codebase manually from git upstream?
<tsimonq2> Sorta.
<tsimonq2> The way we do it is put the patch files in debian/patches and then list the patch files in debian/patches/series.
<tsimonq2> All you have to do is get the patch to apply and put a DEP-3 header there.
<tsimonq2> That link I pasted earlier has a lot of details.
<tsimonq2> I'm willing to help you through submitting a patch through a bug if you can test your changes and do the backporting work :)
<halvors> tsimonq2: I'm not familiar with that tool, but i could use dpkg-source --commit as well?
<tsimonq2> halvors: I've never used that myself.
<halvors> tsimonq2: Nice :)
<halvors> tsimonq2: Think that is a tool for adding a patch to /debian/patches after getting source from apt source systemd
<halvors> "apt source systemd" command
<tsimonq2> Right
<tsimonq2> That'll grab the packaging, grab the source, and extract it in a nice way.
<halvors> tsimonq2: Will do, just need to get one more fix commited to upstream systemd.
<tsimonq2> halvors: OK, feel free to keep in touch with me either here or via tsimonq2@ubuntu.com
<tsimonq2> halvors: Thanks for your interest in helping :)
<halvors> tsimonq2: Nice :) Ofcourse, really hate experiencing bugs that i know is fixed in upstream version of packages ;)
<tsimonq2> halvors: I do too, but there's only so many of us...
<halvors> tsimonq2: Yeah.
#ubuntu-devel 2018-07-18
<Unit193> LocutusOfBorg: Heh, hopefully you're happy now?  Started the DD process.
<doko> tsimonq2: fyi, qtubuntu ftbfs
<ginggs> doko: ack, he is aware
<doko> oSoMoN: please could you have a look at the libreoffice ftbfs in -proposed? it also blocks xmlsec1 migration
<doko> and gcc-N of course ...
<oSoMoN> doko, sure thing
<LocutusOfBorg> Unit193, I'll be really happy once you become core-dev too :p
<Unit193> LocutusOfBorg: I'm trying for MOTU right now, also why would I want core-dev?
<LocutusOfBorg> motu is fine :D
<tsimonq2> doko: Was just following up with the Mir team on bug 1708326; they seemed surprised it hadn't been removed yet. :P
<ubottu> bug 1708326 in qtubuntu (Ubuntu) "RM: obsolete product" [Undecided,Invalid] https://launchpad.net/bugs/1708326
<juliank> Looking for feedback to my interpretation about libomxil-bellagio triggers: https://bugs.launchpad.net/ubuntu/+source/appstream/+bug/1780996/comments/49
<ubottu> Launchpad bug 1780996 in guile-2.2 (Ubuntu Bionic) "Convert triggers to noawait" [Undecided,In progress]
<juliank> s/to/on/
<cpaelzer> hi, I have a case where an apt upgrade will upgrade 6 packages belonging together
<cpaelzer> I'm suspicious that the one we looked at so far does all right but another one in the transaction does trigger bad things
<cpaelzer> I wonder is there a way to e.g. step through all actions triggered
<cpaelzer> so this goes through all unpack/remove/maintscript calls of these packages
<cpaelzer> and I'd want to watch status while I can go forward slowly
<rbasak> I think you can do everything apt does by calling dpkg manually?
<rbasak> Is that what you mean?
<cpaelzer> I wondered, but won't that insist on the same dependencies done in one pass
<cpaelzer> e.g. dpdk -i on one of them breaks due to missing depends
<rbasak> Oh, I see
<cpaelzer> and on all of them would be the same as what an apt uprgade would give me
<rbasak> looking at the manpage, dpkg has --unpack and --configure
<rbasak> So you might be able to do it that way using --force-depends etc if necessary
<rbasak> (IIRC, dpkg won't complain about depends until the configure stage, so I don't think force should be necessary)
<rbasak> Could I have a second ~ubuntu-sru opinion on bug 1750356 please?
<ubottu> bug 1750356 in apache2 (Ubuntu Bionic) "Apache2: BalancerMember worker hostname (65.character.host.name) too long" [Low,In progress] https://launchpad.net/bugs/1750356
<rbasak> The patch feels (necessarily) quite invasive, changing API between modules, etc.
<rbasak> So higher regression risk, in my view.
<rbasak> Is the impact worth it?
<rbasak> bdmurray_: since you're already familiar with bug 1780501, do you want to take the SRU review for that? Or are you wanting someone else to take it as you're involved?
<ubottu> bug 1780501 in vte2.91 (Ubuntu Bionic) "Traceback calling Vte.Terminal.feed_child()" [High,Triaged] https://launchpad.net/bugs/1780501
<bdmurray_> rbasak: I'll write up the test case etc but it'd probably be good to have someone else review it
<rbasak> bdmurray_: OK no problem, but I think I'm just about out of time today :-/
<bdmurray_> rbasak: No problem, its a lower priority than the 18.04 point release anyway.
<dmj_s76> Trevinho: did the patches for https://bugzilla.gnome.org/show_bug.cgi?id=786929 ever get into the Ubuntu packages?
<ubottu> Gnome bug 786929 in general "Attaching a monitor to laptop while in suspend and then waking up laptop will reliably crash gnome-shell" [Major,Resolved: fixed]
<dmj_s76> I'm getting reports that sound very much like that bug.
<coreycb> doko: do you know if anyone is working on an imagemagick merge? (for python-wand)
<doko> coreycb: no, not yet
<coreycb> doko: ok i'll work on that then if that is ok, since it's blocking me
<doko> coreycb: much appreciated
<ricotz> doko, hi, while there are a lot of transitions happening, is there an eta for icu 62?
<doko> ricotz: I didn't plan for that
<ricotz> doko, ok
<Trevinho> dmj_s76: not yet, I've cherry-picked them for gnome-3-28 but we need a new release for that, I've already asked Florian... Maybe you can enforce the request :)
<dmj_s76> Trevinho: So we just need a 3.28 point release of mutter?
<Trevinho> Yep
<Unit193> teward: Going to fix CVE-2018-14055 and CVE-2018-14056? ;)
<ubottu> ZNC before 1.7.1-rc1 does not properly validate untrusted lines coming from the network, allowing a non-admin user to escalate his privilege and inject rogue values into znc.conf. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14055)
<ubottu> ZNC before 1.7.1-rc1 is prone to a path traversal flaw via ../ in a web skin name to access files outside of the intended skins directories. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14056)
<Unit193> Fancy that, lp 1781925.
<ubottu> Launchpad bug 1781925 in znc (Ubuntu Cosmic) "Vulnerabilities in znc package CVE-2018-14055 CVE-2018-14056 " [Medium,In progress] https://launchpad.net/bugs/1781925
<Unit193> Hi.  http://people.canonical.com/~ubuntu-archive/proposed-migration/cosmic/update_excuses.html#xfce4-terminal seems to have been uploaded at a bad time as apport is now failing.  The buildd is now yelling at me, can someone fix apport? :)
#ubuntu-devel 2018-07-19
<rbasak> Looks like apport regularly fails and people tend to retry until it works :-/
<rbasak> Based on http://autopkgtest.ubuntu.com/packages/a/apport/cosmic/amd64
<Unit193> rbasak: AFAIK, I can't hammer that button (nor does it quite seem like the right thing to do, but *clearly* the Xfce terminal didn't break it...)
<sarnold> aww rats. they show me the button but I can't hit the button either. :(
<Unit193> Well if it's big and red...
<sarnold> push the button, frank
<Unit193> Also, unfortunately limnoria has had issues with the 'scheduler' plugin's tests, so I have had to hammer the button ~4 times but that was a PPA. :/
<tsimonq2> I hammered the button.
 * sarnold dubs thee Thor
<tsimonq2> :D
<doko> tsimonq2: vlc ftbfs with new qt
<tsimonq2> doko: known issue, I'll poke Sebastinas
<tsimonq2> .
<Laney> Would be nice if someone could look at why the tests are unreliable rather than just retrying them all the time
<Laney> Or just delete them if nobody cares
<ginggs> Laney: fwiw, there is a bug LP: #1780767
<ubottu> Launchpad bug 1780767 in apport (Ubuntu) "Some tests are flaky due to timeout" [Undecided,New] https://launchpad.net/bugs/1780767
<Laney> I saw it
<Laney> So maybe I should say it would be nice if somebody would fix that bug?
<ginggs> Laney: can you tell which version of autodep8 is installed on the autopkgtesters? i believe there are changes in 0.13 needed for the octave* autopkgtests
<Laney> ok
<Laney> there we go, it's updated
<Laney> this is a git checkout, manually pulled
<ginggs> Laney: thanks!
<doko> tsimonq2: I'll leave the qtwebengine-opensource-src no-change upload (ffmpeg) for you ....
<tsimonq2> Thanks
<doko> nine chromium builds on armhf/arm64 ...
<GunnarHj> Hi mvo, was the snapd POT generation issue fixed also in 2.33?
<GunnarHj> https://github.com/snapcore/snapd/pull/5408#issuecomment-403242613
<GunnarHj> Would be good to be able to close bug #1758684.
<ubottu> bug 1758684 in Ubuntu Translations "LP only imported a fraction of the snappy translation template" [High,In progress] https://launchpad.net/bugs/1758684
<mvo> GunnarHj: it is fixed in 2.34 which just hit -proposed
<mvo> GunnarHj: afaict 2.33 does not have the fix yet
<GunnarHj> mvo: Shouldn't it have it too so we make sure that also bionic, xenial etc. has a correct template?
<mvo> GunnarHj: I uploaded 2.34 with the i18n fix to {trusty,xenial,bionic,comsic}-proposed, so hopefully the template is fixed really soon. or am I misunderstanding the question?
<GunnarHj> mvo: Aha, thanks, I missed that. Please disregard my question then.
<mvo> GunnarHj: sure, thank you and thanks again for noticing the issue in the first place, that was a nice catch
<GunnarHj> np
<tsimonq2> doko: qtwebengine> . but minimum 25 hour build time on arm64, assuming it passes...
<doko> tsimonq2: well yes, we need to ...
<tsimonq2> doko: I don't see any reason why it shouldn't pass.
<tsimonq2> O_o https://launchpadlibrarian.net/379223521/buildlog_ubuntu-cosmic-i386.qtwebengine-opensource-src_5.11.1+dfsg-2ubuntu3_BUILDING.txt.gz
<tsimonq2> doko: What do you think about this patch for that FTBFS? https://build.opensuse.org/package/view_file/openSUSE:Factory/libqt5-qtwebengine/chromium-66.0.3359.170-gcc8-alignof.patch?expand=1
<doko> tsimonq2: looks fine to me
<doko> cancelling the builds
<tsimonq2> doko: Did you want to apply the patch or should I?
<tsimonq2> (I don't care either way)
<cjwatson> seb128: LP has emitted the first cosmic language pack build, and it looks reasonably sensible.  Following https://wiki.canonical.com/Launchpad/Translations/UbuntuOpenings, I've unhidden translations for cosmic.
<seb128> cjwatson, excellent, thanks!
<cjwatson> seb128: Can you arrange for langpack-o-matic to start building langpack uploads, and announce to translators etc. if everything looks sensible to you?
<seb128> cjwatson, I will do!
<cjwatson> Cheers
<cjwatson> Sorry it took so long ...
<LocutusOfBorg> acheronuk, dpkg: error processing archive /tmp/apt-dpkg-install-tbIFQg/022-cantor-backend-lua_4%3a18.04.3-0ubuntu2_amd64.deb (--unpack):
<LocutusOfBorg>  trying to overwrite '/etc/xdg/cantor_lua.knsrc', which is also in package cantor 4:18.04.3-0ubuntu2
<acheronuk> LocutusOfBorg: I know. looking at it
<LocutusOfBorg> thanks! it is currently blocking some autopkgtests, this is why I'm worried
<LocutusOfBorg> (octave btw, don't ask me why)
<acheronuk> LocutusOfBorg: fix uploaded I hope. simply forgot that file is separately installed by debian/rules, hence duplication
<LocutusOfBorg> ack thanks!
<abeato> cyphermox, hi, did you have a chance to take a look at my MPs for NM? : https://code.launchpad.net/~alfonsosanchezbeato/network-manager/+git/network-manager/+merge/349468 and https://code.launchpad.net/~alfonsosanchezbeato/network-manager/+git/network-manager/+merge/349465
<seb128> abeato, it would make sense to have a bug with the rational/test plan and have it mentioned in the changelog, also would probably make sense to update cosmic to 1.12 rather than doing backports like that
<abeato> seb128, this is the bug: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1781597
<ubottu> Launchpad bug 1781597 in network-manager (Ubuntu) "[SRU] WoWLAN settings are not supported" [Undecided,New]
<abeato> seb128, yes, I am plus one in having 1.12 in cosmic if that is possible
<abeato> seb128, I'll also update the MPs to add the bug number, I forgot about that
<doko> a lot of ftbfs with the new ffmpeg ...
<seb128> abeato, thanks, and yes, the mp was neither linked to the bug nor having the reference in its changelog
<abeato> seb128, the MPs are in the bug description, I have just tried to link the branch, but it looks like that is not working for git repos
<seb128> :/
<rbasak> I've linked them for you.
<rbasak> You can't link to a git branch directly. AIUI this is intentional as git branches are typically ephemeral
<rbasak> But you can link to an MP.
<rbasak> To do that link to the bug from the MP.
<abeato> rbasak, thanks, I had not tried that :)
<seb128> I was looking for that since I though it used to be possible
<seb128> but I didn't find the button on the mp page
<abeato> seb128, I've added the bug to the changelog in both MPs
<rbasak> seb128: it's "Link a bug report". Under the Status, Proposed branch, etc table.
<cyphermox> abeato: sorry, I will definitely not have time today to look at NM -- and I haven't really touched NM in nearly two years
<abeato> cyphermox, ok, I guess maybe I should have ping jbicha too :)
<abeato> jbicha, fyi I'd like to SRU LP: #1781597
<ubottu> Launchpad bug 1781597 in network-manager (Ubuntu) "[SRU] WoWLAN settings are not supported" [Undecided,New] https://launchpad.net/bugs/1781597
<seb128> rbasak, thx, I see it now :)
<seb128> abeato, jbicha is not around recently, I wouldn't count on it
<seb128> we need a n-m maintainer :/ willcooke was trying to get headcount for that
<dmj_s76> Looks like a new 3.28 Mutter release!
<acheronuk> LocutusOfBorg: can you get new abi-compliance-checker uploaded?
<LocutusOfBorg> acheronuk, in debian?
<LocutusOfBorg> this would require a bug and a patch probably...
<acheronuk> LocutusOfBorg: header compile tests fail with GCC-8 in proposed. fix is in a-c-c 2.3
<coreycb> doko: have you seen any hangs in py3.7 in waiter.acquire()? for example: https://paste.ubuntu.com/p/SwXsCcghjt/
<coreycb> seems to be a race somewhere with thread locking but need to dig more
<danialbehzadi> Hi. I put two apps in my ppa and set one of them as a dependency in control file of the other one like this: traktor (>= 1.4)
<danialbehzadi> But when I try to install it, I get this strange error: carburetor : Depends: traktor (>= 1.4) but 1.4-0~201807171920~ubuntu18.04.1 is installed
<danialbehzadi> I wonder what does it meanâ¦
<nacc> danialbehzadi: you have asked in #launchpad already
<danialbehzadi> nacc: Yeah. I wondered if there was the wrong place, cause it doesn't relate to launchpad itself, but to development on a debian platform
<nacc> danialbehzadi: ah ok; is the version you mentioned (1.4-0... ) the one from your ppa?
<danialbehzadi> nacc: Yes
#ubuntu-devel 2018-07-20
<rbasak> nacc: I think I can just sync php-defaults now. Please could you check for me that this is sane?
<rbasak> I'm basing this on https://git.launchpad.net/ubuntu/+source/php-defaults/log/?h=debian/sid and https://git.launchpad.net/ubuntu/+source/php-defaults/log/
<xnox> RAOF[m], mir ftbfs in cosmic now =( something about GMock i think
<xnox> -- Cannot enable coverage targets because neither lcov nor gcovr are found.
<xnox> CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
<xnox> Please set them or make sure they are set and tested correctly in the CMake files:
<xnox> GMOCK_INCLUDE_DIR
<xnox> RAOF[m], actually, i may have been able to fix it.
<xnox> RAOF[m], sigh https://paste.ubuntu.com/p/Q3PFD3rb4J/
<RAOF[m]> xnox: there are differences of opinion as to what constitutes a point release on the Mir team ð
<doko> ftbfs is independent of any opinion
<doko> tsimonq: are you involved with ffmpeg? http://people.canonical.com/~ubuntu-archive/transitions/html/ffmpeg.html
<xnox> RAOF[m], fair enough =) we are talking about cosmic, not bionic. And it needs investigation how come miral gains new symbols, and if they are legit.
<xnox> RAOF[m], the google-mock -> libgmock-dev change is straight forward, the symbols are not though =/ please commit the build-dep change, and the symbols changes and make an upload to cosmic sooner; rather than later.
<xnox> RAOF[m], probably not as a full point release but just a ubuntuX upload direct to cosmic.
<RAOF[m]> xnox: the symbols are almost certainly deliberate; you might want to check against the packaging in github.com/MirServer/Mir
<RAOF[m]> (which used to be automatically distro'd, but the bileto workflow is no more)
<xnox> RAOF[m], right, i see that you fixed gmock change differently (by using a new googletest path; instead of changing the dep to the new libgmock-dev package) I guess either is fine.
<RAOF[m]> I'll get on to that on Monday, when I've returned from holiday ð
<xnox> RAOF[m], yeah \o/
<ahasenack> Laney: around?
<tsimonq2> ahasenack: He said in -desktop yesterday that he'll be gone until Tuesday.
<ahasenack> ah, ok
<ahasenack> was looking for someone who could help with stuck tests in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#autofs
<tsimonq2> hmm, idk
<doko> oSoMoN: any update about libreoffice?
<oSoMoN> doko, on it, the various failures are not obvious so I'm working on pushing a 6.0.6~rc1 update, hoping that the failures will go away with it
<abeato> sil2100, hey, I was wondering if it would make sense for ubuntu-image to accept a folder with a rootfs as an alternative to creating it with live-build
<abeato> sil2100, talking about classic here
<abeato> sil2100, as live-build is a rather complex machinary and in many cases you would prefer to run it by yourself and then creating a full volume starting from the rootfs created by lb
<sil2100> abeato: might be something worth thinking about
<sil2100> abeato: it could be done pretty easily, can't instantly think of any objections (besides the principle of u-i doing most of the job for us)
<sil2100> abeato: could you fill in a featue request for it on LP?
<abeato> sil2100, sure thing
<sil2100> Thanks o/
<abeato> yw
<abeato> sil2100, https://bugs.launchpad.net/ubuntu-image/+bug/1782795
<ubottu> Launchpad bug 1782795 in Ubuntu Image "[Feature] Accept folder with rootfs as alternative to using live-build" [Undecided,New]
<tsimonq2> Anyone else having problems with debootstrap?
<tsimonq2> For the second time in this past week, it's erroring out on a corrupt Packages.gz...
<tsimonq2> Only with debootstrap; works when manually downloading and verifying cached copies.
<tomreyn> someone else reported problems with debootstrap on bionic on irc the other day. i forgot the details, though.
<tomreyn> tsimonq2: what's the system you're running it on running? also 18.04?
<tsimonq2> tomreyn: Nope, up-to-date Cosmic.
<tomreyn> tsimonq2: oh, using deboostrap from cosmis also then?
<tomreyn> *cosmiC
<tsimonq2> Yup.
<ScottE> For what it's worth, a "debootstrap --arch amd64 bionic /tmp/z" from bionic worked for me
<tsimonq2> Perhaps it's only when creating Cosmic chroots.
<nacc> rbasak: wil do; give me 5 minutes
<nacc> rbasak: yes, sort of. We lose branding (s/Debian/Ubuntu/) but since we no longer diverge that seems fine. NOte that PHP needs some love in 18.10 afaik.
<ScottE> tsimonq2 just for the heck of it, I did a debootstrap of cosmic from bionic, then chrooted into that and debootstrapped cosmic - it worked OK. Don't know if that helps, but perhaps it's a useful bit of info.
<rbasak> nacc: thanks. I'm aware of pkg-php-tools. What else needs attention? Is there a summary/report I can use?
<tsimonq2> ScottE: Hmm.
<nacc> rbasak: not sure, but i have a bunch of pakcages that need syncing that can't because they needed phpunit 6 (now 7, maybe?) updates
<rbasak> nacc: ah, basically "grep-merges Nish"? That gives me a list to get started, thanks :)
<nacc> rbasak: yeah
<tomreyn> tsimonq2: fwiw, i also run, on a fully updated bionic amd64 VM, using debootstrap from cosmic, "debootstrap --arch amd64 cosmis /mnt/cosmic" and "debootstrap --arch amd64 cosmic /mnt/cosmic", both of which ran without warnings.
<tomreyn> and the same with cosmic's debootstrap from within the bionic cosmis chroot, debootstrapping cosmic.
<tsimonq2> O_o
<tsimonq2> huh
<tomreyn> so in case this was not well explained: bionic -> coscmic debootstrap -> chroot on bootstrapped cosmic -> debootstrap cosmic
<tomreyn> this worked without warnings / errors.
<hallyn> lvm2 in bionic is missing link from /lib/x86_64-linux-gnu/libdevmapper.so.1.02 to /lib/x86_64-linux-gnu/libdevmapper.so.1.02.1.  That should've been autocreated by the build right?
<dannf> GunnarHj: re: console-setup - i wonder if '[ -n "XDG_CURRENT_DESKTOP ]' shouldn't be '[ -n "$XDG_CURRENT_DESKTOP" ]'
<infinity> dannf: It should be indeed, but that test also seems bogus.  Why would it matter if I'm upgrading from a console session or X?
<infinity> dannf: (ie: I tihnk it's a happy accident that the test is always true, cause I think it shouldn't be testing that at all :P)
#ubuntu-devel 2018-07-21
<Unit193> Can someone with powers please retry the apport failure?
<Unit193> http://people.canonical.com/~ubuntu-archive/proposed-migration/cosmic/update_excuses.html#xfce4-terminal
#ubuntu-devel 2018-07-22
<mwhudson> Unit193: done
<mwhudson> (48 hour service!)
<Unit193> mwhudson: Thank you very much!
#ubuntu-devel 2019-07-15
<Fudge> hey guys, trying to spin up an image for Vinux, Linux for vision impaired with no success. keeps on failing at bootstrap stage checking debian security for disco which is not right, this is my auto/config file. https://paste.ubuntu.com/p/VJWv643hYz/
<wxl> mdeslaur: finally submitted that merge request to make usb-creator-kde work. if i could get a quick approval on this, i can move forward with the SRU. https://code.launchpad.net/~wxl/usb-creator/usb-creator/+merge/370094
<valorie> ooo, cool wxl
<valorie> ask in the #kub chan for testers
<valorie> too
<wxl> ah yeah thanks i forgot about that
<valorie> it nearly always worked for me
<valorie> not WELL, but it worked and made working live sessions and well-installed ISOs
<wxl> well it hasn't worked since xenial. i can tell you that
<valorie> I used it at LFNW
<valorie> and at SeaGL
<wxl> not sure which version valorie but i know it doesn't work in lubuntu back to xenial and i can also confirm at least in bionic it doesn't work in kubuntu https://askubuntu.com/questions/1158249/puzzling-message-from-startup-disk-creator/1158252#1158252
<valorie> OK
<valorie> I have been upgrading for quite a few cycles
<valorie> so I might not have the latest of that
<wxl> it's remotely possible kubuntu's got some magic library or something in it but i doubt it given the fix
<wxl> bug report confirms it in kubuntu 17.04, 16.04.3, 18.04
<valorie> right, it's been inconsistent
<cpaelzer> I'm wondering about a component mismatch that IMHO should have happen but wasn't triggered in Eoan, I summarized it in the related MIR at https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/1570617/comments/28
<ubottu> Launchpad bug 1570617 in edk2 (Ubuntu) "[MIR] edk2" [Undecided,In progress]
<cpaelzer> apw: doko: you are the AAs that should be awake the earliest, if you (or anyone else) can help me out understanding what I'm missing in this case that would be great
<wxl> valorie: you should check to see if it's still working and if it is, drop me a line with the version you're on
<valorie> Sysinfo for 'valorie-Oryx-Pro': Running inside KDE Plasma 5.16.3 on Ubuntu 19.04 (Disco Dingo) powered by Linux 5.0.0-20-generic, CPU: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz at 3399-3400/3800 MHz, RAM: 11302/32115 MB, Storage: 311/1144 GB, 237 procs, 6.67h up
<valorie> let me find a thumb key
<tobikoch> Laney: kenvandine: vorlon: I added proper error checking, where the base of a snap is determined. Together with mvo's sanity check on seed.yaml, this should prevent inconsistently seeded images like the one in bug #1828500.
<ubottu> bug 1828500 in livecd-rootfs (Ubuntu) "snapd fails always in Optimised Ubuntu Desktop images available in Microsoft Hyper-V gallery" [Undecided,Confirmed] https://launchpad.net/bugs/1828500
<cpaelzer> (sorry) repeating my question from earlier this morning hoping more peopl are around now
<cpaelzer> I'm wondering about a component mismatch that IMHO should have happen but wasn't triggered in Eoan, I summarized it in the related MIR at https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/1570617/comments/28
<ubottu> Launchpad bug 1570617 in edk2 (Ubuntu) "[MIR] edk2" [Undecided,In progress]
<cpaelzer> apw: doko: you are the AAs that should be awake the earliest, if you (or anyone else) can help me out understanding what I'm missing in this case that would be great
<Unit193> At 4am on a Monday?  noooo.
<sil2100> cpaelzer: hey! So one reason why it might not be showing up is because the component-mismatches page is outdated
<sil2100> cascardo: outdated and actually looking just weird - the timestamp is from 2019-07-12 20:30
<sil2100> cpaelzer: ^
<sil2100> cascardo: (ignore my earlier message, highlighted wrong person)
<cpaelzer> sil2100: yeah you are right, but my main issue is that it actually migrated to -release
<cpaelzer> with the known mismatch in place
<cpaelzer> thanks for the hint on the page being outdated thou!
<apw> cpaelzer: is  it a mismatch as recommends?
<cpaelzer> yes
<cpaelzer> was it changed that recommends are no more mismatches?
<apw> or is suggests the missmatch
<cpaelzer> they are recommends for sure, I double checked the build log and posted that in the bug that I linked
<cpaelzer> I also checked in a eoan container and apt-cache show confirms what I expect
<cpaelzer> apw: did you find why the qemu<->edk2 component mismatch was not triggered?
<apw> cpaelzer, seemts the reporting is broken; being fixed right now
<cpaelzer> In my case I waited for the mismatch and hence reported it since it migrated without
<apw> cpaelzer, in your case you broke it :)
<cpaelzer> do we need to be afraid that other mismatches might have slipped in the last few days?
<cpaelzer> wut
<cpaelzer> tell me what I did wrong so I can avoid it apw
<apw> cpaelzer, the report was bust by your name
<cpaelzer> lol
<apw> cpaelzer, but also i don't think we gate on it
<apw> we fix things in it
<cpaelzer> no gating and fixing the report which was disliking my special char
<cpaelzer> ok that would match what I ahve seen then
<cpaelzer> thanks for taking care of it apw
<apw> oh i did nothing; i am mearly a messenger
<apw> /
<cpaelzer> so the solution for now is to drop my lovely ubuntu logo to get things working again?
<apw> cpaelzer, na, the report is being repaire
<cpaelzer> or are you already fixing the script
<cpaelzer> thanks
<LocutusOfBorg> doko good morning, syncpackage -f python3-stdlib-extensions?
<rbasak> cpaelzer, apw: while you're on the topic, kronosnet shows in https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg as not approved, but the bug https://bugs.launchpad.net/ubuntu/+source/kronosnet/+bug/1811139 is "In Progress" which the documentation defines as approved. I couldn't explain to rafaeldtinoco why the report disagrees.
<ubottu> Launchpad bug 1811139 in kronosnet (Ubuntu) "[MIR] kronosnet" [High,In progress]
<cpaelzer> rbasak: its status is approved
<cpaelzer> it waits for an AA to resolve it by promoting
<cpaelzer> but it doesn't show up in https://people.canonical.com/~ubuntu-archive/component-mismatches either (maybe due to the same issue)
<cpaelzer> apw: said he fixed the script
<cpaelzer> so it might show up when this is regrenerated
<Laney> it is now
<Laney> As for rbasak's observation, if that's the correct interpretation of MIR process then it'd be fixed in the script at around https://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/view/head:/component-mismatches#L386
<cpaelzer> arr you are right, since the change that triggers the mismatch is in the archive it needs to move to Fix committed
<cpaelzer> fixed the status on the bug
<rbasak> cpaelzer: I got that from your diagram (can't find the link right now)
<cpaelzer> rbasak: there https://wiki.ubuntu.com/MIRTeam#Process_states
<cpaelzer> we missed step 4->5
<cpaelzer> since in the case of kronosnet the change triggering that has already happened
<rbasak> Ah. I see.
<rbasak> The report should be able to accomodate that though, right?
<rbasak> If the MIR bug is In Progress but the component mismatch is present, then treat it as if it's Fix Committed.
<cpaelzer> the line that Laney referred showed me that without the status change (which I now have done) it will not be added to "approved_mirs"
<cpaelzer> not sure where in the report that makes it end up differently without reading the rest
<mdeslaur> wxl: sure! I'll look at it today
<cpaelzer> rbasak: I tihnk on the next run you should now get "yellow" instead of "darkkhaki"
<LocutusOfBorg> ahasenack, I uploaded squid with a workaround for LP: #1835831
<ubottu> Launchpad bug 1835831 in squid (Ubuntu) "FTBFS: gcc9 stringop-truncation and others" [High,New] https://launchpad.net/bugs/1835831
<LocutusOfBorg> so we unblock a bunch of other stuff
<LocutusOfBorg> since the issues are there since the begin...
<rbasak> cpaelzer: thanks!
<cpaelzer> rbasak: the updated report is online - your color changed, but kronosnet is still not listed in the text output
<cpaelzer> rbasak: you might want to run the tool from ubuntu-archive-tools yourself and check why?
<kenvandine> tobikoch: thanks
<LocutusOfBorg> doko, I'm moving ncurses transition to old, I don't think it is useful anymore, right?
<LocutusOfBorg> xnox, I'm removing also some ssl1.0 transition tracker...
<xnox> sure
<LocutusOfBorg> thanks
<LocutusOfBorg> xnox, if you have time, can you please tell me why dh-cargo needs that .buildinfo hack?
<LocutusOfBorg> "Touch .cargo_vcs_info.json to update timestamp"
<LocutusOfBorg> I kept the delta, but I'm happy to drop it
<xnox> LocutusOfBorg:  because launchpad rejects builds with bogus zero unix timestamp.
<xnox> LocutusOfBorg:  whilst dak was patched to whitelist dh-cargo .cargO_vcs_info.json file
<LocutusOfBorg> xnox, interesting, how can I check if in the meanwhile LP has bee fixed?
<LocutusOfBorg> because I tried to upload a dh-cargo in sync in my ppa and the deb was published
<cjwatson> We don't consider this a bug in LP
<cjwatson> The check is still present - if you didn't run into it then your test was bad
<LocutusOfBorg> cjwatson, it seems obvious that my test is not good, because I don't know "which" deb is getting rejected... I guess not dh-cargo itself
<LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/17272858
<cjwatson> I dunno, sorry
<cjwatson> I would assume it's things that are built using dh-cargo
<LocutusOfBorg> yes, probably, but apt-file shows really few files
<LocutusOfBorg> anyway, I hope xnox will answer me, so I can update the changelog with some more verbose information, or open a bug explaining what is going on and how to reproduce
<LocutusOfBorg> the fix might be good for debian too, even if they patched dak
<cjwatson> Also pretty sure that xnox is wrong that dak was patched to whitelist those files, since there's no mention of "cargo" in dak
<cjwatson> It's possible that Dinstall::PastCutoffYear is configured to something that isn't what's in the git tree
<cjwatson> Or that it's accidentally broken for some other reason, or I dunno, something else
<LocutusOfBorg> I think we should ideally have one Ubuntu bug for each package that has delta... so we can track if we can discard it or not
<LocutusOfBorg> or at least verbose changelogs, or debian bugs...
<LocutusOfBorg> probably new rust packages are the culprit, my bionic apt-file didn't show that many as the eoan version
<ginggs> I've needed to touch files to fix timestamps rejected by LP in another package, dak was happy with them.
<ahasenack> xnox: hi, in case you are not aware: https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1836329
<ubottu> Launchpad bug 1836329 in apache2 (Ubuntu) "Regression running ssllabs.com/ssltest causes 2 apache process to eat up 100% cpu, easy DoS" [Critical,In progress]
<LocutusOfBorg> cjwatson, why can't the infra accept them to avoid that kind of troubles?
<LocutusOfBorg> ginggs, you don't remember which one, right?
<ginggs> LocutusOfBorg: no, possibly some node thing
<cjwatson> LocutusOfBorg: It's very clearly wrong and is often a mistake
<cjwatson> It would be good to figure out why dak is accepting them, because according to a plain reading of its code AFAICS it should be rejecting them
<cjwatson> It may be a dak bug
<cjwatson> grep for PastCutoffYear in dak and you'll find a check that is very similar to the one in Launchpad (which is in lp.archiveuploader.nascentuploadfile:BaseBinaryUploadFile.verifyDebTimestamp)
<cjwatson> In fact we got the check from dak in the first place - it wasn't a Launchpad invention
<LocutusOfBorg> ok, the reasoning behind what I say is that we should understand if there is a bug and fix it, and I'm willing to forward it in Debian if needed of course
<LocutusOfBorg> in the meanwhile I could reproduce it
<LocutusOfBorg> https://launchpadlibrarian.net/433190036/upload_17272877_log.txt
<cjwatson> IMO the correct fix is on the dak side to make it reject such binaries, since from its code it clearly intends to do so
<cjwatson> Then it will be obvious that packages need to be fixed in Debian in the small number of cases they haven't been already
<LocutusOfBorg> sure, I fully agree
<LocutusOfBorg> this is why I raised the question about this delta... thanks for helping me
<cjwatson> Ah, so there does exist a Lintian exception for cargo_vcs_info.json
<cjwatson> What's not clear is why dak's BinaryTimestampCheck apparently isn't being used
<cjwatson> It seems bogus to me to make exceptions, because the original justification for the extreme-time-travel check was that it could cause errors on extraction (perhaps with non-dpkg tools, I'm not sure)
<xnox> cjwatson:  dak autorejects got moved to lintian autorejects, which whitelists cargo.
<cjwatson> xnox: I don't see the relevant check being disabled in dak though
<xnox> was my understanding of how it now works.
<cjwatson> Can you demonstrate it to me from the dak code?
<xnox> cjwatson:  ok. I will trace all the pieces then.
<cjwatson> As I say, BinaryTimestampCheck still seems to exist and to be used
<rafaeldtinoco> ahasenack: for the samba gvfs regressions, I can't see anything apart from a flaky test for async/scheduled calls (when doing a Gio.File.new_for_path()->trash() call)
<ahasenack> rafaeldtinoco: ok, let me retry them
<rafaeldtinoco> ahasenack: if they still fail in that point I can suggest a sleep time in between the thrash call and the assert
<ahasenack> rafaeldtinoco: mark the timestamps of the current red tests (it's part of the log filename)
<rafaeldtinoco> ok
<ahasenack> rafaeldtinoco: so you know if the log you are seeing is the one from now, or from the retry
<xnox> cjwatson:  https://paste.ubuntu.com/p/XzCGS66ycH/ that check only checks timestamps on the control tar members; not on the data tar members.
<xnox> (i adjusted the callback locally, and ran it against debian's deb with a similar file)
<xnox> if it was interated on the data, it would have raised a reject.
<xnox> *itterated
<xnox> https://github.com/Debian/dak/blob/master/daklib/checks.py#L530 -> iterates control tarball only
<ahasenack> xnox: vorlon: hi, I need some guidance wrt https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1836329
<ubottu> Launchpad bug 1836329 in apache2 (Ubuntu) "Regression running ssllabs.com/ssltest causes 2 apache process to eat up 100% cpu, easy DoS" [Critical,In progress]
<ahasenack> I reproduced the bug
<ahasenack> I tried one patch which might have had something to do with it, https://github.com/apache/httpd/commit/524608b65ec410e797a7283e6e142f8e5a74be26
<ahasenack> but that didn't fix it
<ahasenack> now I can keep digging, or revert, and thus reopen https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1833039
<ubottu> Launchpad bug 1833039 in apache2 (Ubuntu Cosmic) "18.04/Apache2: rejecting client initiated renegotiation due to openssl 1.1.1" [High,Fix released]
<ahasenack> the subject of that latter bug is misleading, it basically affects clients using ssl certificate authentication. Each https connection gets delayed 15s or so
<xnox> ahasenack:  .... use nginx? =)
<xnox> ahasenack:  first day back from holiday =)))))) sorry for the party mood still =)
<vorlon> when I learned that apache2 doesn't have support for being an SNI reverse-proxy, I became an nginx convert :P
<vorlon> ahasenack: I think the correct answer here is that we need to keep digging
<ahasenack> xnox: same for me
<ahasenack> (day back after pto)
<ahasenack> vorlon: question is basically if the 100% cpu usage for a process after the scan is worse than the 15s delay for people using client cert auth
<vorlon> ahasenack: both regressions are unacceptable to leave in -updates; if you want me with my SRU hat to make a call on which regression is worse and if it warrants a revert, I'll take a minute to think about it
<ahasenack> (for the uploading a revert point)
<ahasenack> vorlon: ok. I have a ppa setup to fix the first case, which affected people have tried and vouched that it fixed their ssl client cert auth case
<vorlon> ahasenack: if you can keep working on finding a fix in the meantime, I'll chew on the question of reverting - thanks for escalating
<ahasenack> hm, except I deleted it
<ahasenack> vorlon: ok
<xnox> vorlon:  ahasenack: well, one way to revert to tls1.2 only is to rebuild apache against openssl1.0
<ahasenack> xnox: tls 1.3 is not available in that apache version
<ahasenack> even the first bug, with client cert auth, was on tls 1.2
<xnox> ahasenack:  indeed, that's why revert from openssl 1.1.1 to 1.0.2
<ahasenack> why not 1.1.0?
<ahasenack> or whatever was there before
<ahasenack> same soname?
<xnox> we don't have 1.1.0 available
<xnox> we only have 1.0.2 and 1.1.1 available now.
<xnox> (and lots of things depending on libssl1.1 > 1.1.1 now, hence can't downgrade libssl1.1 to 1.1.0 easily anymore)
<xnox> however
<xnox> i don't know if apache modules link against libssl directly or indirectly too, and if they all have to have the same libssl (i.e. mod_python mod_perl etc..)
<xnox> ahasenack:  also does that ssl test cpu usage reproducible on eoan too?
<xnox> apache master?
<ahasenack> xnox: something for me to test, I was also wondering
<ahasenack> but eoan doesn't have latest upstream yet
<ahasenack> 2.4.38, upstream is at 2.4.39
<ahasenack> we are with debian still on this one
<ahasenack> xnox: good point on the indirect deps, that could be a mess if mod_ssl only is using an older ssl, and some other module is linked with 1.1.1
<TJ-> ahasenack: was trying to debug it on a server of mine (18.04) that has 2.4.29-1ubuntu4.7 but there are no dbgsym packages for that version, which has stumped me. I was going to attach gdb to the spinning processes
<ahasenack> TJ-: did you add the dbg repo?
<TJ-> ahasenack: oh indeed, the lists are in /var/lib/apt/lists too but there's no "apache2-bin-dbgsym"
<TJ-> ahasenack: looking at the raw ddebs.ubuntu.com the versions are 2.4.38-2ubuntu2 2.4.18-2ubuntu3.10 2.4.7-1ubuntu4.22
<ahasenack> TJ-: I don't control any of that, I just upload the source. I'd expect this to be just taken care of automatically
<TJ-> ahasenack: hmmm! the build log shows it built apache2-dbg (so no -dbgsym)
<TJ-> ahasenack: so its apache2-dbg/bionic-updates,bionic-proposed 2.4.29-1ubuntu4.7
<TJ-> ahasenack: link to the gdb "bt full" https://iam.tj/projects/ubuntu/apache2-libssl1.1-spinning.txt
<ahasenack> during a renegotiation test
<ahasenack> I was really hoping this would fix it: https://github.com/apache/httpd/commit/524608b65ec410e797a7283e6e142f8e5a74be26
<ahasenack> at least it sounded related
<TJ-> ahasenack: and here's the other thread - this looks more like it - stuck in _int_malloc() https://iam.tj/projects/ubuntu/apache2-libssl1.1-spinning-malloc.txt
<TJ-> ahasenack: in apache's ssl_engine_io.c there's an interesting comment: "We rely on SSL_get_error() after the read, which requires an empty error queue before the read in order to work properly." ... so if rc = SSL_read(inctx->filter_ctx->pssl, buf + bytes, wanted - bytes); returns < 0 the code hits the else {...} block ... I suspect then its following if (ssl_err == SSL_ERROR_SYSCALL) { ... and then
<TJ-> hitting the if (APR_STATUS_IS_EAGAIN(inctx->rc) {...} and then finally "continue;  /* Blocking and nothing yet?  Try again. */" -- which means it'll spin inside the while(1) {} endlessly
<TJ-> ahasenack: OK, it's not the SSL_ERROR_SYSCALL its the SSL_ERROR_WANT_READ clause. I added a breakpoint in there are line 715, gdb reports "ssl_err = 2" which is SSL_ERROR_WANT_READ
<ahasenack> I see some mentions of clearing ssl errors in the commit log
<ahasenack> https://svn.apache.org/repos/asf/httpd/httpd/trunk@1845768
<ahasenack> let me try 2.4.39 in the meantime
<ahasenack> latest upstream
<ahasenack> TJ-: xnox: vorlon: apache 2.4.38 from eoan works fine
<ahasenack> I'll keep trying some interesting commits
<ahasenack>     * modules/ssl/ssl_engine_io.c (bio_filter_out_write,
<ahasenack>       bio_filter_in_read): Clear retry flags before aborting
<ahasenack>       on client-initiated reneg.
<ahasenack> like that
<TJ-> ahasenack: This one looks likely: https://github.com/apache/httpd/commit/524608b65ec410e797a7283e6e142f8e5a74be26#diff-f9e8db5f4b7fae788784f623962bf96a
<ahasenack> TJ-: I tried it :(
<ahasenack> TJ-: it's in https://launchpad.net/~ahasenack/+archive/ubuntu/apache-regression-test-2/
<ahasenack> unless I made a silly mistake applying the patch
<ahasenack> dpkg-source: info: applying ssl-read-rc-value-openssl-1.1.1.patch
<ahasenack> maybe multiple will be needed
<TJ-> ahasenack:  looking more closely, that patch doesn't touch the if (ssl_err == SSL_ERROR_WANT_READ) { path
<TJ-> ahasenack: maybe the same approach is needed for SSL_ERROR_WANT_READ
<TJ-> whoever thought "while(1)" was a good idea needs shooting!
<TJ-> ahasenack: right, a BIG clue. ssl_io_input_read() is being called with len == 0 !
<TJ-> (gdb) p len
<TJ-> $2 = (apr_size_t *) 0xffe62aa8
<TJ-> (gdb) p *len
<TJ-> $3 = 0
<TJ-> ahasenack: in which case there's never going to be any more data to read
<ahasenack> what's the defined behavior in that case for that ..._read() call?
<TJ-> I'm not sure...but *len is copied into bytes and wanted and those are used to call SSL_read() and as I currently understand it, the code "SSL_read(inctx->filter_ctx->pssl, buf + bytes, wanted - bytes" is effectively "SSL_read(inctx->filter_ctx->pssl, buf + 0, 0 - 0"
<TJ-> ahasenack: digging deeper, SSL_read() is returning -1, which originates from ssl_read_internal() and one place where that obviously can be caused is if (s->handshake_func == NULL) {...} but also it could be one of the two 'return' statements, such as "return s->method->ssl_read(s, buf, num, readbytes);"
<ahasenack> ssl ain't easy
<TJ-> note though the value of 'num' here is 8192: Breakpoint 4, SSL_read (s=0x57164400, buf=0xf5691040, num=8192) at ../ssl/ssl_lib.c:1771
<TJ-> which implies wanted == 8192 and bytes == 0 or similar
<TJ-> ahasenack: hypothesis:  if the cause is  if (s->handshake_func == NULL) {...} might that imply a protocol mismatch of some form?
<ahasenack> or an aborted connection, the log is full of those
<TJ-> I think we can rule this one out - I dropped a breakpoint inside that block and it doesn't trigger
<ahasenack> I'm now testing https://github.com/apache/httpd/commit/7fa21ea6602b30cc43d4f485777545dd73bb25a6 and the one about the SSL_read() rc
<TJ-> it isn't s->mode == SSL_MODE_ASYNC clause either. s->mode == 16 which is I think # define SSL_MODE_RELEASE_BUFFERS 0x00000010U
<TJ-> which makes it the: " return s->method->ssl_read(s, buf, num, readbytes); "
<TJ-> which *looks like* TLSv1 ?
<TJ-> (gdb) p s->method
<TJ-> $11 = (const SSL_METHOD *) 0xf704dba0 <tlsv1_server_method_data>
<TJ-> (gdb) p s->method->ssl_read
<TJ-> $12 = (int (*)(SSL *, void *, size_t, size_t *)) 0xf6fdda20 <ssl3_read>
<ahasenack> TJ-: hey, that last one might have fixed it
<ahasenack> TJ-: wanna give it a try to confirm? https://launchpad.net/~ahasenack/+archive/ubuntu/apache-regression-test-2/+packages
<TJ-> ahasenack: for some reason add-apt-repository is hanging on me! hope this isn't related to the bug!
<ahasenack> TJ-: haha
<ahasenack> lp could be slow
<ahasenack> or fetching the gpg key for the ppa
<ahasenack> from the key server
<ahasenack> xnox: vorlon: I applied https://github.com/apache/httpd/commit/524608b65ec410e797a7283e6e142f8e5a74be26#diff-f9e8db5f4b7fae788784f623962bf96a and https://github.com/apache/httpd/commit/7fa21ea6602b30cc43d4f485777545dd73bb25a6 and that seems to work
<ahasenack> maybe just one is needed, remains to be checked, but looks like progress
<vorlon> \o/
<ahasenack> TJ-: I'm eod, but will peek in here later tonight
<TJ-> ahasenack: sorry, turns out my host has lost IPv6 connectivity; I'll test it once I've got that fixed, and I'll comment on bug  #1836329
<ubottu> bug 1836329 in apache2 (Ubuntu Bionic) "Regression running ssllabs.com/ssltest causes 2 apache process to eat up 100% cpu, easy DoS" [Critical,In progress] https://launchpad.net/bugs/1836329
#ubuntu-devel 2019-07-16
<LocutusOfBorg> [13:24:50] <ansgar> LocutusOfBorg: To be honest, I wonder if we really need this check.
<LocutusOfBorg> cjwatson, ^^ :)
<LocutusOfBorg> what happens if debian drops it?
<cjwatson> The main problem is that we don't have Lintian autorejects in LP
<cjwatson> So it's not easy to just say, OK, we'll rely on those
<cjwatson> We could perhaps weaken it in some way
<seb128> is there a way to get an /usr/bin/python when installing python3 packages only?
<LocutusOfBorg> cjwatson, right now I uploaded the dh-cargo in Debian and will sync later
<cjwatson> OK
<LocutusOfBorg> I don't care about future for now :)
<LocutusOfBorg> it will probably take time before Debian drops the check anyway
<xnox> LocutusOfBorg:  cjwatson: you did see my paste from yesterday right? dak only checks control.tar members timestamps, not data.tar.
<xnox> i guess that data.tar checks got moved to lintian autorejects. or never existed.
<xnox> (but i somehow remember dak checking data.tar before)
<LocutusOfBorg> xnox, I lost it, but you are right
<LocutusOfBorg> it has been lost in this commit https://salsa.debian.org/ftp-team/dak/commit/77dc932880d95b604f1e4c7527403804fb7a833c
<xnox> https://paste.ubuntu.com/p/XzCGS66ycH/ that check only checks timestamps on the control tar members; not on the data tar members.
<LocutusOfBorg> and now restored https://salsa.debian.org/ftp-team/dak/commit/19c6730d8d9421e3021a3a3a5f12717e9e1e3e5d
<LocutusOfBorg> xnox, yes, but it was a bug in dak
<xnox> ah
<xnox> ok
<LocutusOfBorg> so better fix
<xnox> great!
<LocutusOfBorg> instead of carrying a delta forever :)
<LocutusOfBorg> it has been lost when python-apt gained the feature
<LocutusOfBorg> just a mistake
<xnox> awesome!
<LocutusOfBorg> I want to get rid of such deltas whenever possible, for example today I submitted upstream one of your delta
<LocutusOfBorg> https://github.com/gridcf/gct/issues/95
<cjwatson> xnox: Right, it was after I EODed but OK.  Thanks for getting that restored, LocutusOfBorg
<cjwatson> A long-standing mystery solved
<xnox> scooby doby dooo
<LocutusOfBorg> :D
<Laney> rcj: you good with mvo's latest version?
 * Laney is ready to Pull The Trigger
<ahasenack> TJ-: thanks for the testing and assistance!
<mvo> thanks Laney !
<maks_piechota> Hi there! I'm new in Ubuntu development and as a first step I would like to build and install current main branch on my computer. Is there any tutorial how to do it?
<TJ-> maks_piechota: have you got several weeks? building the main archive will take a looooong time! Alternatively, just install from a prebuilt ISO like everyone else
<maks_piechota> many thanks
<maks_piechota> I havent thought about that
<maks_piechota> where could I find it?
<maks_piechota> on launchpad?
<maks_piechota> I've found this? https://launchpad.net/ubuntu/+source/gnome-shell/3.32.2-2ubuntu1
<TJ-> maks_piechota: https://ubuntu.com/download/desktop
<TJ-> maks_piechota: hang on, when you said "main branch" did you mean for a single package?
<maks_piechota> nope, maybe I would better explain what I'm trying to achieve
<maks_piechota> I'm looking for opportunities for active contribution in Ubuntu project as a developer, and I think the first thing to do is to install Ubuntu version that is developed currently
<maks_piechota> not the released one
<maks_piechota> alternatively I would appreciate any tips on how to prepare environment where I could make some code changes, build and test
<rcj> Laney: just gave it a +1 for my testing with the ubuntu-cpc project.  Not sure if the code solves the problem for your project.
<TJ-> maks_piechota: I'd recommend you start here: https://wiki.ubuntu.com/UbuntuDevelopment
<juliank> tip of the day: lxc exec $container eatymdata bash
<maks_piechota> TJ-: so the way is to install the newest Ubuntu 19.04 then build and test particular package?
<ahasenack> xnox: hi
<ahasenack> xnox: https://github.com/apache/httpd/commit/7fa21ea6602b30cc43d4f485777545dd73bb25a6 is enough to fix https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1836329
<ubottu> Launchpad bug 1836329 in apache2 (Ubuntu Bionic) "Regression running ssllabs.com/ssltest causes 2 apache process to eat up 100% cpu, easy DoS" [Critical,In progress]
<ahasenack> xnox: but I also found https://github.com/apache/httpd/commit/524608b65ec410e797a7283e6e142f8e5a74be26 which is openssl 1.1.1 related
<Laney> rcj: thanks - it's somewhat of a black box to me but it seems fine
<ahasenack> and I'm wondering if I should include both, or just the one that fixes that explicit problem. I fear we could be chasing openssl 1.1.1 regressions for some time still, one by one
<ahasenack> but that last patch also notes there is a behavior change, in the commit message
<ahasenack> xnox: any opinion?
<xnox> ahasenack:  first one is fine "stop retrying, as we are about to terminate the connection"
<rcj> Laney: you could always revert tobikoch's patch to fix bases and rebuild the desktop image to see if it catches the failure.
<xnox> ahasenack:  the second one -> i wonder if it affects 1.1.1, or ...a, ....b, ....c
<ahasenack> xnox: don't know, and it mentions http2 failures
<ahasenack> "When no data could be read, our code returned EAGAIN up until OpenSSL 1.1.0, but APR_EOF for OpenSSL 1.1.1."
<xnox> ahasenack:  it looks small enough too. (a few reindents)
<xnox> ahasenack:  i think you should take both patches.
<ahasenack> ok
<ahasenack> " Old documentation indicated a difference between 0 and -1, and that -1 was retryable.  You should instead call SSL_get_error() to find out if it's retryable."
<ahasenack> yeah
<ahasenack> SSL_read(3)^
<TJ-> ahasenack: it looks sane to me to have both patches
<ahasenack> yep
<mdeslaur> wxl: I merged usb-creator and released the new version into eoan
<mdeslaur> wxl: thanks!
<Saviq> oSoMoN: hey, re: nested virt, the doc you linked to suggests this only works on AMD CPUs, do you have that?
<oSoMoN> hrm, how could IÂ possibly not read that essential bit that mentions AMDâ¦ /me digs a hole and hides very deep underground
<oSoMoN> kvm it is, then
<Saviq> :)
<Saviq> glad I could help :D
<oSoMoN> thanks Saviq
<oSoMoN> https://docs.oracle.com/cd/E97728_01/F12470/html/nested-virt-support.html is even more explicit, I wish I had landed on that page first
<tomreyn> vorlon: when you have a minute, could you double check whether bug 1798992 should have been a dupe of bug 1801629? it is my impression that they discuss different issues.
<ubottu> bug 1801629 in OEM Priority Project "duplicate for #1798992 direct dependencies of ubiquity should not be autoremovable" [High,Fix released] https://launchpad.net/bugs/1801629
<ubottu> bug 1801629 in OEM Priority Project "direct dependencies of ubiquity should not be autoremovable" [High,Fix released] https://launchpad.net/bugs/1801629
<vorlon> tomreyn: are *you* seeing this problem in 19.04?
<vorlon> someone else followed up and said they saw it in 19.04 but not enough detail to be sure their issue is the same as yours
<vorlon> the installer was fixed such that there should not be packages left pending autoremoval due to ubiquity's (normal) removal at the end of the install
<tomreyn> vorlon: i'm just testing it with the *k*ubuntu 19.04 installer - is this a suitable test?
<tomreyn> it does use subiquity
<vorlon> tomreyn: kubuntu does not use subiquity
<tomreyn> and after minimal install reports 136 packages can be upgraded and about as many can be auto removed
<tomreyn> sorry i mean ubiquity
<vorlon> tomreyn: ok.  yes, kubuntu w/ ubiquity on 19.04 is a suitable test
<vorlon> tomreyn: please send the exact output to the bug wrt packages marked for autoremoval
<vorlon> what is "minimal" install here?  I thought minimal desktop install was only enabled for Ubuntu, not Kubuntu
<tomreyn> vorlon: should i also remove the dupe status then?
<vorlon> tomreyn: yeah
<tomreyn> minimal installation is an option on the kubuntu installer GUI
<vorlon> hmm
<vorlon> tomreyn: it's quite possible this issue is specific to the minimal install profile
<tomreyn> yes, i believe it is.
<tomreyn> vorlon: i posted an update now. thanks for your feedback.
<tomreyn> fginther: you had added tag id-5c69703c382c5e410989f269 to this 1798992 bug back in february - i assume this means you somehow assigned this to yourself - could you check the state of this assignment (and update it as needed, if needed)? thank you!
<wxl> i can't upload to usb-creator, so i've attached debdiffs for an SRU. the status would be changed to in progress when a sponsor uploads or is it something i should do now?
<ginggs> wxl: just subscribe ubuntu-sponsors, the sponsor should change the status after upload
<wxl> ginggs: cool, thx. :)
<ginggs> wxl: yw!
<juliank> New dpkg in proposed for x, bb, dd; please go bug hunting, especially on bb and x
<juliank> disco was tiny, but the others are larger, so more chance something went wrong in cherry-picking
<juliank> I installed ubuntu-desktop with it in a bionic container, and upgraded to cosmic, and that was fine
<juliank> But the more people test it, the better
<infinity> juliank: Backports of trigger changes?
<juliank> infinity: yes
<infinity> Fun, fun.
<juliank> infinity: guillem had the list of commits prepared, so I ran git cherry-pick on that list and fixed a few conflicts :)
<infinity> juliank: How confident are we that guillem's change there will resolve all our looping woes?
<juliank> guillem seems pretty confident
<infinity> guillem always seems confident.
<infinity> That's his default mode.
<juliank> It certainly worked for the ubuntu-mate-desktop cosmic -> disco upgrade
<infinity> Okay, cool, if it fixed an actual complex testcase, that's promising.
<juliank> infinity: The problem I guess for testing is that I did not upload a fixed version to cosmic, because no time to release anyway
<infinity> juliank: Nonsense, you have 2 days to validate it!
<infinity> juliank: (But more seriously, if having a fixed version in cosmic is likely to make fewer cosmic->disco upgrades explode, I'm fine with it landing past EOL and leaving the archive open for that)
<sarnold> (and seven days for it to migrate?)
<juliank> Both cosmic and bionic are at 1.19.0.5, so I can just up-cherry-pick the patches and upload it
<infinity> I'm not at all against that, TBH.
<infinity> Even though I've never hit the bug, LP is proof that it hits a lot of people.
<infinity> The fewer people we leave stranded with broken upgrades, the better.
<juliank> ack
<bdmurray> The automated upgrade testing is having issues due to triggers looping so that might be a useful test.
<juliank> nice
<infinity> juliank: Also, when you said "in proposed", did you mean "in the queue"?  I don't see BB and XX in the archive.  Maybe you have an SRU lackey working on those. :)
<juliank> infinity: bdmurray approved them, takes some time to build and release :)
<infinity> juliank: I was looking at LP, not rmadison.
<infinity> Ahh, he just missed the last publisher is all.
<juliank> I see the disco one in LP
<vorlon> infinity: I had assumed glibc 2.29-0ubuntu3 had been built with gcc-9 (and thus, was gcc-9-ok) but I see that it's not - and the glibc 2.29-0ubuntu3 rebuild autopkgtest now fails
<vorlon> infinity: is this tracked anywhere?
<infinity> vorlon: Erm, it's not built with gcc-9 at all.  A rebuild test wouldn't change that.
<infinity> (we hardcode version, we don't use gcc-defaults)
<vorlon> infinity: ah
 * vorlon digs further then
<infinity> The usual culprit for rebuilds exploding is binutils.  Unless it's testsuite regressions, which can often be kernel.
<infinity> Also, there's all the kernel header messes.
<vorlon> binutils hasn't changed between the passing and failing tests; but gcc-8 has
<vorlon> infinity: gcc-8 8.3.0-16ubuntu3 used to build glibc 2.29-0ubuntu3, also used on the last passing glibc autopkgtest.  gcc-8 8.3.0-19ubuntu1 used in the now-failing test
<infinity> vorlon: What's the failure (if you still have the log open)?
<infinity> If not, I'll go look in a sec.
<vorlon> infinity: FAIL: conform/POSIX2008/arpa/inet.h/conform et al
<infinity> vorlon: I blame the kernel for that.
<infinity> Maybe/probably.
<infinity>     Namespace violation: "SIOCGSTAMPNS_OLD"
<infinity>     Namespace violation: "SIOCGSTAMP_OLD"
<infinity>     Namespace violation: "fds_bits"
<infinity>     Namespace violation: "val"
<infinity> Yeah, that's kernel header changes.
<infinity> sforshee: I know you looked at that.  Was your conclusion that it needed fixes kernel-side, glibc-side, or both?
<vorlon> right
<juliank> infinity, bdmurray: Uploaded to cosmic
<infinity> juliank: Ta.
<sforshee> infinity: looked to me that the fixes were needed on the glibc side
<infinity> vorlon: Anyhow, if those are the only failures, I think we can also do some badtest or skiptest jiggery to get the compiler/kernel/glibc in before uploading a glibc that retriggers the world.  Assuming glibc is where the fix goes.  Cause holding everything up on another week-plus test cycle sounds less fun.
<infinity> sforshee: Kay.
<vorlon> infinity: I have already marked glibc badtest per the above
<infinity> Check.
 * infinity runs to find tacos in between meetings.
<infinity> CURSE YOU TUESDAY.
<vorlon> (the only thing it's curretnly blocking is libselinux)
<infinity> Oh, linux migrated.  I didn't notice that.  Okay, things are less dire than I was imagining.
<infinity> But also, how did that actually work?
<infinity> Triggered with the new linux, glibc passed.  That can't possibly be right.
<vorlon> infinity: the trigger was on linux-meta, not linux, and linux-libc-dev is built from linux :P
<infinity> Oh, right.
<infinity> Well job.
<vorlon> corner cases within corner cases
<infinity> This is definitely something broken about moving all linux tests to linux-meta triggers, since I'm specifically a reverse trigger for linux-libc-dev.
<infinity> Need to think about that at some point, somehow.
<vorlon> infinity: yeah, we're finding all the interesting bugs in p-m triggers this month
<vorlon> (the gcc vs gcc-defaults one should be resolved now)
<mwhudson> what's the expected lag time for the package importer?
<rbasak> mwhudson: about an hour
<rbasak> (worst case)
<mwhudson> rbasak: apparently it crashed
<mwhudson> (i asked somewhere less public files)
<mwhudson> *first
<rbasak> Looks like it's in the process of restarting
<rbasak> I have been refactoring to make it more reliable, but that work's not finished yet.
<rbasak> and in the meantime Launchpad API calls started hanging less so I deferred that work focusing on other things.
<Unit193> Oooh, fix my bugs! :>
<rbasak> If it keeps doing this then I can focus on finishing the watchdog stuff
<rbasak> Though I need to get this MySQL transition done firts
<mwhudson> uhh is there no way to have a link in monospace text in the wiki?
<TJ-> mwhudson: backticks ?
<TJ-> mwhudson: the only way I can see it /could/ be done is adding an option to the link, as in [[target|alt-text|class="some-class-that-sets_font-family:monospace"]] but I don't see any such class in the CSS
<mwhudson> TJ-: backticks don't work on inside or outside :/
<TJ-> no, I tried that :)
<TJ-> there's a class "backtick" attached to <tt> elements but unfortunately that class is not defined in CSS
<TJ-> the only attributes that can be used: Available attributes: class, title, target, accesskey
<mwhudson> find some xss hack that will let me add a <style> element to the page? :)
<mwhudson> TJ-: i made it work sorta kinda https://wiki.ubuntu.com/FoundationsTeam/AutomatedServerInstalls
<mwhudson> rbasak: has it crashed again or is it just taking a long time to catch up? src:casper still doesn't seem to have my upload from yesterday
#ubuntu-devel 2019-07-17
<sarnold> "This document is entirely a description of something that does not yet exist"
<sarnold> I like that :)
<mwhudson> sarnold: turns out writing documentation for your new feature is quite a good way to shake out stupid ideas1
<mwhudson> !
<sarnold> mwhudson: yes! I tried that once and realized that as much as I wanted to write one specific tool, I had no idea what I wanted that tool to do :D
<TJ-> mwhudson: is it the YAML section you're trying to format?
<TJ-> mwhudson: if so, might be useful - now YAML is used an many places - to ask the sysadmin team to add https://moinmo.in/ParserMarket/YAML to MoinMoin
<sarnold> mwhudson: *thanks* for the "creating an autoinstall file" section :) that's got ot be the number one complaint with preseed files, no one knows how to make one or what to put in them.
<mwhudson> sarnold: heh yes although that part is extra double not existing
<sarnold> mwhudson: but you're *thinking* about it, which is promising
<mwhudson> any other comments welcome of course, it's probably almost time to send it to ubuntu-devel@
<sarnold> mwhudson: can you include the netplan yaml directly inline into the network: field?
<mwhudson> sarnold: yes
<sarnold> mwhudson: alright, how about cloud-init configs?
<sarnold> mwhudson: ssh keys from launchpad / github etc?
<mwhudson> sarnold: cloud-init no, pending actual sensible use case
<sarnold> mwhudson: heh, fair, I wondered even as I typed it :)
<sarnold> mwhudson: ssh hostkey?
<mwhudson> sarnold: not sure i see value importing keys vs just having the key there, i guess it's easier to type
<sarnold> mwhudson: a random blob to shove into /dev/random?
<sarnold> mwhudson: how about a way to say packages that *shouldn't* be included?
<mwhudson> sarnold: not sure i understand
<sarnold> mwhudson: which part?
<mwhudson> sarnold: late_commands supplies you with an indefinite amount of rope to tie around your own neck...
<sarnold> mwhudson: heh
<mwhudson> sarnold: either of the last two?
<mwhudson> sarnold: you mean packages that are usually part of ubuntu server to not install? that doesn't seem like a great idea
<sarnold> but installing a package to just then apt-get purge it is a bit funny vs just not installing it itn the first place. not a huge deal I guess..
<mwhudson> sarnold: install is blatting a squashfs onto disk
<sarnold> AH
<mwhudson> you don't get to only blat part of it :)
<sarnold> man this thing's gonna be *fast*
<sarnold> mwhudson: the random blob is to try to give a machine enough entropy to do things like generate ssh host key without taking ten minutes or asking someone to type gibberish on the keyboard
<mwhudson> sarnold: how does that work? do you drop a file on disk somewhere for the kernel to read on first boot?
<mwhudson> anyway none of the ways of getting the autoinstall config to the installer seem especially secure so i'm not sure how wise putting secrets in there would be
<sarnold> mwhudson: hm. good point. :/
<mwhudson> i guess we can support fetching it over https
<Unit193> So we can have zstd squashfses, when initramfses? :3
<sarnold> mwhudson: you can cat random data into /dev/random and the kernel will use it, but not account for it; you've got to issue an ioctl to get the kernel to account for it, whiuch usually means using rng-tools
<sarnold> mwhudson: okay I think one last one.. raid configs?
<mwhudson> sarnold: are supported by curtin
<sarnold> mwhudson: nice. I remember folks saying that the newish installer didn't support their favourite raid setup as well as debian-installer
<mwhudson> i think i've fixed most of that now
<sarnold> yay :)
<sarnold> thanks mwhudson
<Unit193> https://bugs.launchpad.net/ubuntu/+source/python-acme/+bug/1836823 sounds like fun!
<ubottu> Launchpad bug 1836823 in python-acme (Ubuntu) "python-acme will break on November 1st" [Undecided,New]
<rbasak> mwhudson: it's still catching up. I ran casper manually for you.
<LocutusOfBorg> why is getgroups() not working on launchpad builders?
<LocutusOfBorg> https://github.com/gridcf/gct/issues/95
<mwhudson> rbasak: thanks
<cjwatson> LocutusOfBorg: a bug report on launchpad-buildd would be a much better way to ask that question
<LocutusOfBorg> cjwatson, if you say that it might be a bug I would happy to report it :)
<LocutusOfBorg> I'm trying to reproduce locally before opening a bug
<cjwatson> I mean if you have a local launchpad-buildd setup already then sure :)
<LocutusOfBorg> cjwatson, I was trying with pbuilder
<LocutusOfBorg> and other sbuild isntances
<cjwatson> they may or may not be close enough
<LocutusOfBorg> but it works...
<cjwatson> I know of no particular reason why we'd want the group setup to be invalid for this, so it seems likely to be a detail nobody else has run into before for whatever reason
<LocutusOfBorg> thanks I'm not usually inclined to just open bugs because meh, its mostly always my fault :)
<LocutusOfBorg> I'm trying debomatic and then I'll open it
<cjwatson> Might be something like a mismatch between the buildd gid in the base VM and the chroot which nothing fixes up
<LocutusOfBorg> LP: 1836870
<ubottu> Launchpad bug 1836870 in launchpad-buildd "getgroups() fails on launchpad builders." [Undecided,New] https://launchpad.net/bugs/1836870
<LocutusOfBorg> Logan, hello, can you please do something for groovy? sync/merge?
<roaksoax> //win 8
<doko> Laney: uploaded a new gcc-9. I doubt that things will be magically fixed, but would appreciate a glib2.0 rebuild and mutter check
<SlickMcRunFast> Which channel would the ubuntu graphics driver PPA hangout on?
#ubuntu-devel 2019-07-18
<lag> Does anyone know when Mesa will reach v19.1 in Ubuntu?
<seb128> lag, tjaalton would know
<lag> seb128: Thanks Sebastien
<seb128> np
<tjaalton> maybe today
<lag> tjaalton: That would be awesome - thanks
<lag> tjaalton: Will just propagate to AArch64 pretty quickly too?
<lag> s/just/that/
<tjaalton> the holdup was a regression in libgles2 which would've needed libglvnd to provide the pkgconfig file for it, but it hasn't been merged yet there.. so I've reverted the regression in mesa instead
<tjaalton> and now there's 19.1.2 too
<lag> tjaalton: I just need the changes landed in 19.1, but anything above that would be grand
<tjaalton> all archs will build the same, so it should be useable from proposed at least by tomorrow
<enyc> LocutusOfBorg: so, where d these packages waitinangi for an archive-admin go?
<enyc> not the same as bionic-proposed ?
<ginggs> enyc: they go here: https://launchpad.net/ubuntu/bionic/+queue?queue_state=1
<LocutusOfBorg> enyc, we can read you yes
<LocutusOfBorg> enyc, I uploaded the packages in my ppa and in unapproved queue
<LocutusOfBorg> you can test packages in my ppa *now*
<LocutusOfBorg> the packages in unapproved queue will be accepted and then go automatically in bionic-proposed
<ginggs> assuming they are accepted :)
<LocutusOfBorg> after somebody verifies the fixes, no regressions are opened and a week or two, they will migrate in bionic-updates
<LocutusOfBorg> lol true story!
<LocutusOfBorg> e.g. 5.2.30 should be rejected because I already uploaded 5.2.32
<lag> tjaalton: Which versions of Ubuntu will see the update to 19.1.x?
<tjaalton> lag: 19.10
<tjaalton> will actually get 19.2.x
<lag> tjaalton: Works for me, thanks
<enyc> LocutusOfBorg: hrm talking of virtualbox... maybe this should be improved by next LTS rather than in bionic-updates but... :-
<enyc> LocutusOfBorg: the packaging, including -ext-pack  provides no warning/help/support/etc  for  adding users to vboxusers  group for usb passthrough support
<enyc> LocutusOfBorg: i really theink eithre default permissions should be changed t not erquire this group,  or  [BOTH a warning about the fact that user is not in vboxusersgroup  should occur with usb passthrough  AND  some facility to add users to vboxusers group should be provided]
<LocutusOfBorg> I agree
<ginggs> LocutusOfBorg: maybe have a look how wireshark does it
<LocutusOfBorg> problem is: should new users being automatically added to it?
<LocutusOfBorg> they all work for current users
<LocutusOfBorg> anyway yes, adding current user might already be nice
<enyc> LocutusOfBorg: i would figrnst question what this permission system is doing and what it is protecting against
<enyc> LocutusOfBorg: i guess some kind of raw access to all usb devices  sort of thing
<LocutusOfBorg> enyc, ls /dev/vboxusb/ -l
<LocutusOfBorg> created via udev with ./src/VBox/Installer/linux/VBoxCreateUSBNode.sh
<LocutusOfBorg> bridging usb devices into an internal vm might be a security issue?
<LocutusOfBorg> e.g. what if the server has an external usb-attached hdd and some user is using it to steal data?
<LocutusOfBorg> I mean, for example for shared servers
<Unit193> Ah, looks like LP is finally catching up on Debian uploads.
<LocutusOfBorg> Unit193, you beat me for 3 minutes (exo)
<LocutusOfBorg> but I syncd apparmor-profiles-extra
<Unit193> exo is one of our packages, I'm of course keeping an eye on it (since I'm involved in Xubuntu as well as pkg-xfce.)
<Unit193> thunar is the one I've been waiting on..
<cjwatson> Yeah, I broke it for a bit, sorry
<Unit193> Well thanks for fixing it too. :)
<GunnarHj> wgrant: I'd like to call your attention to this request for a new language:
<GunnarHj> https://answers.launchpad.net/launchpad/+question/682131
<GunnarHj> Looks straightforward to me. 'Everything' is in place - team, locale in glibc, etc.
<wgrant> GunnarHj: Looking
<wgrant> GunnarHj: I've added the language and added the team to ubuntu-translators.
<GunnarHj> wgrant: Excellent, thanks! (The latter I would have access to, I think.)
<wgrant> Yep
<GunnarHj> wgrant: A detail: What's the reason for including the country code, i.e. "mjw_IN" instead of just "mjw"?
<wgrant> True, probably no need to split it.
<wgrant> GunnarHj: Fixed.
<GunnarHj> wgrant: Good; think that's better. Then if someone would create a mjw_BD locale, for instance, they can share translations.
<enyc> LocutusOfBorg: so far VirtualBox in PPA test, can't find anything working worse than 5.2.18 -- but 5.2.32 is indeed working with 5.0.0-20 kernel from LinuxMint 19.1
<LocutusOfBorg> enyc, host and guest?
<LocutusOfBorg> both virtualbox and virtualbox-hwe?
<LocutusOfBorg> also guest-additions?
<enyc> LocutusOfBorg: host, intel 64bit  linuxmint 19.1  (largely ubuntu 18.04.x),  virtualbox,  +ext-pack + guest-additions   all insatll and work
<enyc> LocutusOfBorg: guest -- pile of Windows  machines in this case,  guest additions install fine
<enyc> LocutusOfBorg: did not find a sepaarate -hwe virtualbox package  except guest addiions for ilnux which isn't my usage case
<rbasak> Is it safe to cast an int * to a bool * in general?
<rbasak> (specifically an stdbool.h bool, ie. a _Bool)
<rbasak> I'm patching something for the MySQL transition that uses std::vector<my_bool> to manage an array so that can point to individual elements
<rbasak> But now that my_bool is a bool, std::vector<bool> is specialised and uses bitfields, so we can't get pointers to them.
<rbasak> If I use std::vector<int> instead then I get pointer conversion errors since the MySQL API does require bool pointers.
<rbasak> Save for massive refactoring I don't see how I can fix this without some kind of pointer compatibility between a bool * and some other data type.
<rbasak> Or, any way to get around the standard std::vector<bool> specialisation? A typedef maybe?
 * rbasak tries _Bool directly
<rbasak> _Bool didn't work
<rbasak> The compiler still uses thd std::vector<bool> specialisation in that case AFAICT
<jamespage> doko: any chance you could process a few RM's for us - specifically:
<jamespage> https://bugs.launchpad.net/ubuntu/+source/glare/+bug/1836143
<ubottu> Launchpad bug 1836143 in python-glareclient (Ubuntu) "[RM] glare, python-glareclient" [Undecided,New]
<jamespage> https://bugs.launchpad.net/ubuntu/+source/python-ceilometerclient/+bug/1836142
<ubottu> Launchpad bug 1836142 in python-ceilometerclient (Ubuntu) "[RM] python-ceilometerclient" [Medium,Triaged]
<jamespage> https://bugs.launchpad.net/ubuntu/+source/openstack-resource-agents/+bug/1836623
<ubottu> Launchpad bug 1836623 in openstack-resource-agents (Ubuntu) "[RM] openstack-resource-agents" [Medium,Triaged]
<jamespage> as we're unpicking python 2 from the openstack package set, would be better to clean that lot out rather than have to spend cycles on refreshing them
<jamespage> thanks :)
<coreycb> doko: here's the full list of RM bugs for us: https://paste.ubuntu.com/p/bDMPrkpysX/
<rbasak> Wrapping the bool inside a struct and making an std::vector of that seems to have worked.
<ricotz> hi, is there any progress in fixing https://launchpad.net/ubuntu/+source/systemd/240-6ubuntu10 ?
<seb128> ricotz, I think Balint is out today/tomorrow but maybe bdmurray or vorlon know of the status?
<ricotz> seb128, hi, I see
<vorlon> seb128, ricotz: no, this wasn't on my radar yet (due to the extent of the backlog of foundations packages stuck in -proposed that we're working through).  I expect it'll be on rbalint's plate on Monday
<seb128> thx vorlon
<seb128> ricotz, was it any specific problem created by that upload/the fact that it doesn't build (out of blocking the fix described to reach eoan)?
<ricotz> seb128, sorry, no specific problem here, other than it is non-installable here for quite a while, and systemd is not just some random package ;)
<seb128> ricotz, do you enable eoan-proposed? you shouldn't :)
<ogra> waveform, do you know if agherzan plans to fix ram allocation ? it would really be nice if we could use the full 4GB on a 4GB pi4 (his u-boot only inits 1GB, using my kernel directly from config.txt gets me the full range of RAM)
<waveform> ogra, good question - I've yet to even get it successfully booting on a pi4 (though I'm not using his patch directly - tried combining it with our current u-boot version, but evidently we need a later base)
<ricotz> seb128, I guess a few people should, I came across some packaging oversights in the past ;)
<waveform> ogra, I would assume so though as that's one of the major benefits of the 4 so it's rather incomplete without it
<ogra> yeah, that will be a pain, i'D got with a fresh checkout of the base (luckily i'm a bit more free with my core developer images not being official :) )
<ogra> *i'd go ..
<ogra> your alternative would be to put a giant patch on top of our base and then put the pi4 stuff on top
<ogra> iirc the deb sources are really old
<waveform> u-boot in eoan has been bumped to 2019.04 so not *that* old (that's the version I attempted to bung the patches on - got a successful build that'd also boot a pi3 happily, but not the 4)
<waveform> still, the patches are on master so we may need to bump u-boot further to 2019.07 (which is going to be my next attempt) - and yes, it's a huge patch so it's pretty ugly but if it's all one patch it should be easy enough to drop when support officially makes it upstream
<ogra> well, u-boot is relatively safe to go with the very latest usually ...
<ogra> (i always use the latest when i start with a new gadget snap for a new board, typically thats even an improvement )
<waveform> indeed - and given we're already at 2019.04 for eoan it wouldn't be a huge leap to 2019.07
<ogra> yeah
<ogra> and we're at a point in the cycle where bumping it should still be okayish
<rbasak> ddstreet: nice job with the bind9 deadlock!
<ogra> waveform, btw, do you know if omxplayer should already be able to play 4k (i just updated my omxplayer-pi snap today (i'm building from the popcornmix tree) and seem to not be able to play anything bigger than 1080p)
<ogra> the console on the pi4 seems to come up fine in 4k though (the font is so small, its nearly unreadable (
<waveform> ogra, what's the format of the file? If it's h264 then no: the h264 decoder block in the GPU is the same as on the vc4 so it's limited to 1080p60
<waveform> ogra, that said I don't know if omxplayer has been updated to handle the h265 block yet
<ogra> ah, no, it were all h264 trailers i tested ...
<ogra> (4k ones though)
<waveform> ogra, ah - apparently omxplayer doesn't support h265 yet: https://www.raspberrypi.org/forums/viewtopic.php?p=1484297#p1484297
<ogra> ah, thanks a lot !
<waveform> kodi's the only (current) means of playing 4k on the 4
<ahasenack> hi, is bileto out of comission for eoan?
<ahasenack> all I get is "all tests passed", and when clicking on the report, it says all tests are running and have always failed
<bdmurray> seb128: Should I have any snaps installed immediately after installing and rebooting eoan?
<santa_> rbalint: hi. I have seen you made the last systemd upload, thanks for your work. I have found an issue with it:
<santa_> executing this produces a hang: "systemctl start network-online.target"
<santa_> this doesn't happen with the previous package version
<santa_> and that "systemctl start network-online.target" is important imho, because it's used by the autopkgtest LXD backend after rebooting testbeds
<ahasenack> you can start a target? I didn't know that
<ahasenack> what does it do?
<santa_> btw it hangs with the machine already up and the network already up, not sure what would happen in other conditions
<santa_> ahasenack: I don't know much about systemd, but I guess it would start the network
<santa_> or exit inmediately if it's already up
<seb128> bdmurray, better to check with #snappy for details but the initial setup takes a while, we had issues with that in disco and the initial setup, it can easily take a few minutes for them to be ready (and there is also an issue with the 5.2 kernel, but it shouldn't impact the initial install since it requires more snap to be installed to trigger from what I understood)
<bdmurray> seb128: well its been a while and still no snaps
<seb128> kenvandine, ^ do you know if they are currently known issue with snap missing on new eoan installs?
<kenvandine> that means the seeded failed
<kenvandine> or is hung
<kenvandine> bdmurray: which image was it?
<kenvandine> i think that might only be fixed in the pending image
<kenvandine> the current might be broken
<bdmurray> kenvandine: I downloaded the current from today
<kenvandine> current, not pending right?
<kenvandine> i think current is from Monday
<bdmurray> that's correct
<kenvandine> which has a broken seed
<tjaalton> lag: sorry, no 19.1.2 this week
<gQuigs> am I doing something wrong or does systemd not build in Eoan?  - https://launchpad.net/~bryanquigley/+archive/ubuntu/1796501/+packages
<gQuigs> 322/514 test-json                               FAIL     0.22 s (killed by signal 11 SIGSEGV
<vorlon> gQuigs: https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20190614-gcc9-eoan.html#foundations-bugs and https://launchpad.net/ubuntu/+source/systemd
<gQuigs> cool, so it's not just me, ty
<gQuigs> although the first amd64 build.. got lucky? - as arm64 failed with my same error..
#ubuntu-devel 2019-07-19
<hallyn> hey guys - i installed eoan livecd onto my laptop today (downloaded the livecd this weekend).  after install, it wouldn't boot until i copied /EFI/BOOT/mmx64.efi to grubx64.efi
<sarnold> hallyn: how does that keep coming back?
<sarnold> 1798171
<sarnold> I tripped over that on disco images just before release..
<hallyn> sarnold: well the ubuntu wiki entry i saw seemed to be the opposite problem :)
<hallyn> ppl were told to move grubx64.efi to mmx64.efi, and ppl reported it worked
<hallyn> oh, which this bug is also saying?
<hallyn> so it seems like after this, some conffile switched to using the other filename? <shrug>
<sarnold> hallyn: ohhh. I misread that you had the mmx64 and were missing grubx64. hrm.
<hallyn> yeah - so the env variable pointing to the other file got fixed so now we need the original name?  maybe...
<Shibe> Hi. Anyone know why the ubuntu 5.2.1 and 5.2 builds are failing for amd64?
<Shibe> https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.2.1/
<Shibe> /home/kernel/COD/linux/include/linux/uuid.h:62:1: error: '-mindirect-branch' and '-fcf-protection' are not compatible
<Shibe> this seems to be the error in the build logs
<seb128> hum, does anyone know what's going on with the ppc64el builders? I've a "start in 1 hour" build which is like that for 2 hours now
<milloni> hi everyone: i've got a question about heap protection in ubuntu
<milloni> https://wiki.ubuntu.com/Security/Features#heap-protector states that you are using the proection that glibc provides
<milloni> does that mean that packages are generally built with `-lmcheck`?
<ogra> waveform, seeing bug 1837209 ... i'm pretty sure the fkms overlay breaks fb0
<ubottu> bug 1837209 in Snappy "Splash screen fails to display on recent pi core18 images" [Undecided,New] https://launchpad.net/bugs/1837209
<ogra> waveform, try completely commenting the dtoverlay line and see if that helps
<waveform> ogra, thanks for the tip - handy to know. Still, psplash does work *after* boot even with the vc4 overlay in place - but /dev/fb0 exists by that point and there's a pile of kernel modules loaded which presumably have something to do with that (vc4, fb_sys_fops, etc.)
<ogra> waveform, yeah, i think i had to ask ppisati in the past to include them for 4.4 back in the days
<coreycb> sil2100: hi, would you happen to be able to handle some RM bugs for us? we've been dropping py2 openstack packages and once we get these packages removed it should unblock our eoan-proposed backlog - https://paste.ubuntu.com/p/bDMPrkpysX/
<sil2100> coreycb: hey! hm, let me try getting to those in a moment
<coreycb> sil2100: hey! thanks that would be great
<hallyn> error: too early for operation, device not yet seeded or device model not acknowledged
<hallyn> sarnold: added a note to that bug ...  <shrug>
<sarnold> hallyn: thanks
<hallyn> thank you
<hallyn> but i'm really getting cranky with my inability to install lxd-client bc snappy is being a tool
#ubuntu-devel 2019-07-20
<hallyn> hm, i'm going to have to do some spelunking, but boot is really really slow now with eoan...  like spinning rust slow.  was 5s, must now be like 35s.
<hallyn> gonna blame lvm for now, might be that same pvscan bug smoser found in redhat...
<tsimonq2> hallyn: Can you repro with a fresh install?
<hallyn> this was a fresh install
<tsimonq2> Hmm.
<hallyn> where previous was 18.04 (lubuntu) on a smaller m.2 ssd
<tsimonq2> $ sudo systemd-analyze
<tsimonq2> Try that.
<hallyn> Startup finished in 1min 13.095s (kernel) + 5.472s (userspace) = 1min 18.567s
<hallyn> graphical.target reached after 5.465s in userspace
<hallyn> mind you with the other disk i never bothere dlooking into ... luks was taking a long time to get going.  or maybe it's uefi.  what do i know, you kids with your flash disks andf lash mobs and uefi and idunno
<tsimonq2> O_o
<hallyn> :)  sorry, i'll dig deeper and figure out where it's hanging
<hallyn> the weird thing was journalctl -ab seems to not show the hanging,
<hallyn> all i see on the screen is msgs about nto finding ubuntu_vg
<hallyn> on next boot i have the quiet gorp taken out of grub.cfg, so maybe i'l llearn more
<tsimonq2> Interesting.
<tsimonq2> hallyn: I don't know if I can provide much more advice, but please do tell me what the problem ends up being.
<tsimonq2> Maybe it's worth fixing in the archive. :)
<hallyn> tsimonq2: yeah, i'd open a bug but don't even know where to file it yet :)  will probably not touch a computer all weekend, but will dig on monday
<tsimonq2> ok :)
#ubuntu-devel 2020-07-13
<LocutusOfBorg> tianon, hello, do you have any clue for this? https://autopkgtest.ubuntu.com/packages/d/docker.io/groovy/amd64
<LocutusOfBorg> looks like docker.io is regressed in release, maybe snapd related, or -ENOCLUE...
<Laney> mwhudson: if you can subscribe foundations then we could try to find an AA to promote it, see bug #1861268
<ubottu> bug 1861268 in jeepney (Ubuntu) "[MIR] jeepney" [Medium,New] https://launchpad.net/bugs/1861268
<Laney> (or someone else)
<Laney> sil2100: ^- maybe you could do that? to unbreak image builds
<sil2100> Laney: hey! What exactly? No backlog!
<LocutusOfBorg> sil2100, https://irclogs.ubuntu.com/latest/%23ubuntu-devel.html :)
<sil2100> Ah, ok! I can look at that indeed
<Laney> ð
<sil2100> Laney: did that, but we need to make sure the package gets a subscriber
<sil2100> I thought I can do that, but I can't
<sil2100> Who can add a subscriber for it?
<Laney> sil2100: I thought you would be able to: https://launchpad.net/~foundations-bugs/+members#active
<sil2100> Oh
<sil2100> hm, ok, I was simply unable to find this team on the dropdown list
<sil2100> Indeed I could
<Laney> w00t
 * Laney watches rmadison
<rafaeldtinoco> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | 20.04 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Focal | If you can't send messages here, authenticate to NickServ first | Patch Pilots: rafaeldtinoco
<rafaeldtinoco> morning o/
<rafaeldtinoco> alright.. I'll start with FTBFS of zsys on armhf and its grub2-common dependency issue on s390x.
<ahasenack> Laney: hi, this ticket (and a few others) has been in that "queued" state since last week, just before you switched britney over to the "new thing": https://bileto.ubuntu.com/#/ticket/4146
<ahasenack> do I need to retrigger it somehow, flip the test to unapproved and back to approved, or even re-upload?
<Laney> ahasenack: I have no visibility into bileto I'm afraid
<ahasenack> sil2100: do you? ^
<sil2100> hmm
<sil2100> ahasenack: looking
<oSoMoN> Laney, I notice on the new proposed-migration page that migrations are now blocked on build deps (specifically firefox on nodejs), that's new, is it intended?
<sil2100> ahasenack: oh, ouch, so actually britney is crashing for all the tickets right now, might be due to some of the latest changes in britney2!
<sil2100> ahasenack: (for bileto)
<Laney> oSoMoN: it is new, and yeah
<oSoMoN> that puts more pressure on me fixing all these node-* failed tests, it caught me off guard
<oSoMoN> but IÂ suppose it makes sense
<Laney> Right. Consider if this happened around release time. We'd migrate firefox, and then copy nodejs up to the next release and delete it from current-proposed, and then firefox would become unbuildable
<oSoMoN> yeah, it definitely makes sense
<Laney> seems to extra suck in this case though
<Laney> :(
<oSoMoN> nodejs transitions between major versions always suck because of API changes and so many reverse deps
<ahasenack> sil2100: ouch
<Laney> doesn't bileto use a fork or something?
<sil2100> Laney: no, it updates from https://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu master ;)
<Laney> sil2100: ah, and then what?
<Laney> well, I made a branch pre-rebase-2020<something> if you just want to pin to the old thing for now
<sil2100> Laney: oh, might be useful, but I guess I'll dig a bit deeper first about what's up, thanks!
<ahasenack> LocutusOfBorg: zoneminder migrated \o/
<LocutusOfBorg> ahasenack, yep :D
<sil2100> Laney: hey! Do you by any chance know how the result.cache files are generated? e.g. the ones from https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/results.cache
<Laney> sil2100: it's a json dump of some internal data structure
<Laney> I didn't know they were online!
<ahasenack> hah :)
<Laney> that link points to the wrong file now
<Laney> (the path changed)
<sil2100> \o/
<Laney> shall I fix those?
<Laney> it's called autopkgtest-results.cache now btw
<Laney> sounds like there's a script grabbing this file from there, that'll need to be fixed for the new name
<sil2100> Laney: oh, yeah, let me use that name then! Since bileto uses it and I saw the crashes were casued by trying to read old test results from the cache
<sil2100> So I'll switch to the new path name now
<Laney> and it lives under data/groovy/state, not data/groovy-proposed/autopkgtest
<Laney> have a look under ~ubuntu-archive/proposed-migration on snakefruit
<Laney> I'll delete the old results.cache files so it's not confusing
<sil2100> Laney: is it exported publicly on the lillypilly ubuntu-archive mirror?
 * Laney double checks the 'backup' is still there ;-)
<Laney> sil2100: that's a proxy to snakefruit
<Laney> if you mean the people.c.c/~ubuntu-archive thing via the web
<sil2100> Yeah, I'm trying to find it there but I guess it's not there yet?
 * Laney type type type
<sil2100> Maybe I'm too impatient, or blind
<sil2100> Probably both!
<sil2100> ;)
 * Laney tries to remember which way round ln -s goes again /o\
<Laney> sil2100: ok it's there
<sil2100> I always remember the order by remembering that if you do ln -s ../../../some_file, by default it will create a symlink to that file in the current directory with the same name
<ahasenack> I never remember
<ahasenack> I just never use -f in the first try :)
<Laney> :)
<Laney> I remember it like this: if you want to make a symlink a/b -> c, type ln -s c a/b
<Laney> i.e. swap the order from what ls -l would show you
<cjwatson> I remember it like this: if you think of it as "make a copy, except the destination gets a symlink rather than an actual copy of the file", then it's the same way round as cp
<tianon> LocutusOfBorg: interesting -- I think mwhudson might be better to look into that than I am though; it's failing in the "docker-in-lxd" test and seems to be failing during "lxc exec docker -- cloud-init status --wait" which AFAIK is before it's even attempted to install docker.io? :/
<tianon> (or really, anyone who's more familiar with LXC, but I think mwhudson wrote most of that test)
<SudoBash> any one in here work on managing puppet under ubuntu?
<rbasak> !dmb-ping
<ubottu> ddstreet, rafaeldtinoco, rbasak, sil2100, slashd, teward, tsimonq2: DMB ping
<rafaeldtinoco> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | 20.04 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Focal | If you can't send messages here, authenticate to NickServ first | Patch Pilots:
<rafaeldtinoco> ill be back tomorrow. for now I was fighting with armhf migrations (and my lxd and kvm environments). So expect armhf /arm64 migrations to be worked on tomorrow
#ubuntu-devel 2020-07-14
<rafaeldtinoco> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | 20.04 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Focal | If you can't send messages here, authenticate to NickServ first | Patch Pilots: rafaeldtinoco
<cpaelzer> xnox: dannf: do you for 1883114 have a working setup/script/...?
<cpaelzer> as I'm forced to remove https from the e1000e rom for bug 1882671 I wanted to test if your setup is affected
<ubottu> bug 1882671 in iPXE "unbalanced UEFI TPL manipulations in iPXE with DOWNLOAD_PROTO_HTTPS enabled" [Undecided,New] https://launchpad.net/bugs/1882671
<cpaelzer> but the bug you used only lists how to check if https support is compiled in, not how to actually use it
<cpaelzer> so I wonder if the actual use-case exists somewhere already
<dannf> cpaelzer: i don't
<xnox> cpaelzer:  i don't have a working setup for 1883114 but i'm trying to find time to make that work. With 1883114 the idea is that UEFI firmware can do https boot directly, and then it looks as if one is inside a hard-drive, which happens to have http/https in the "disk-drive path"
<xnox> cpaelzer: stuff in 1882671 is iPXE which is separate / different.
<xnox> i think/hope the two things are independent of each other.
<cpaelzer> xnox: I was hoping that as well, but they are not perfectly separate
<cpaelzer> xnox: EDK2/OVMF formware will use the lower layers (stuff in ipxe-qemu beginning with efi-*) SNP to do low level things, but if the efi-* roms have more than just basics built in the lines start to blur which component does what
<cpaelzer> this is what made it fail in the bug that I try to fix
<xnox> ouch
<xnox> cpaelzer:  is it borked in groovy too? or having https-enabled edkII makes things "better"?
<cpaelzer> xnox: as far as I can tell it made it better
<xnox> cpaelzer:  so i should SRU edk2 sooner, rather than later, i guess
<xnox> cpaelzer:  but there is one more fix that needs to go in.
<cpaelzer> there is a chance that my fix for ipxe-qemu requires the EDK" with HTTPS enabled
<cpaelzer> so +1 on your fix better being or later - but OTOH no urgency from me
<cpaelzer> my change can wait
<cpaelzer> I'm only looking for extended testing, that is why I asked for that setup
<xnox> cpaelzer:  we know that our grub is not good enough, so testing this stuff at the moment is more-or-less "follow openSUSE instructions and try to https boot their NET.iso"
<xnox> and saying that, makes me sad.
<cpaelzer> yeah https://en.opensuse.org/UEFI_HTTPBoot_Server_Setup also is the #1 documentation hit one finds
<xnox> indeed.
<cpaelzer> once this works well for us we really should add that to the serverguide then as the suse docs is quite different (e.g. how to enable ssl on apache)
<xnox> cpaelzer:  for a simple test, downloading their net.iso putting it on https; enrolling said https server cert; should be enough to test netbooting their net.iso
<ahasenack> hi sil2100, how's bileto today?
<sil2100> ahasenack: hey! Better, but there's still one more crash that I'm seeing now, will fix it in a moment
<ahasenack> ok
<ahasenack> thanks for working on it
<sil2100> geh, phew, found the last one
<sil2100> Apparently the new britney2 now defaults with a --distribution of Debian instead of 'ubuntu'
<sil2100> But I added an explicit --distribution parameter to the britney command
<Laney> phew, we already set that for the main runs ;-)
<sil2100> This run now should be better I hope
<oSoMoN> LocutusOfBorg, when you have a moment, can you sponsor https://salsa.debian.org/js-team/node-grunt-contrib-nodeunit/-/merge_requests/1 ?
<sil2100> GunnarHj: hello! Did you manage to send out the call-for-testing for bionic?
<niub> o/ quick and easy question: what's the package that replace libvirt-bin in Focal: libvirt-daemon?
<GunnarHj> sil2100: Not yet, but I will later today.
<GunnarHj> sil2100: Btw, I installed langpacks for some languages from focal-proposed, and my computer is still not burning. :)
<sil2100> \o/
<sil2100> ;)
<sil2100> That's certainly a good sign!
<sil2100> ahasenack: bileto britney seems to be working now! Please give me a poke if you see something not working as intended
<sil2100> uh, the logfile from this britney run is 123M big
<oSoMoN> LocutusOfBorg, also, node-iconv-lite needs a no-change rebuild against the version of node-iconv in groovy-proposed: https://people.canonical.com/~osomon/+1maintenance/node-iconv-lite.debdiff
<oSoMoN> LocutusOfBorg, another trivial node-* related MR that needs sponsoring: https://salsa.debian.org/js-team/node-immutable-tuple/-/merge_requests/1
<oSoMoN> if there are MOTUs/core devs around, IÂ have a bunch of node-* autopkgtests that need triggering, here is the list: https://paste.ubuntu.com/p/qdrPkhQRjX/
<oSoMoN> thanks in advance!
<LocutusOfBorg> oSoMoN, will do them
<oSoMoN> cheers
<LocutusOfBorg> grunt-contrib-nodeunit done
<LocutusOfBorg> iconv-lite done
<LocutusOfBorg> immutable-tuple done
<LocutusOfBorg> retries done in some seconds
<LocutusOfBorg> let me know if you need anything else!
<LocutusOfBorg> oSoMoN, why is the node-iconv-lite change needed?
<LocutusOfBorg> looks like the built deb is really the same as the previous one
<ahasenack> sil2100: thanks! Will try it now
<oSoMoN> LocutusOfBorg, node-iconv is a build dep of node-iconv-lite, IÂ assume because the tests are run at build time
<rafaeldtinoco> maint+1: opened zsys upstream bug for armhf regression of its own regression tests issue (object file serialization / de-serialization issues when comparing 2 objects as it looks)
<rafaeldtinoco> working on sqlite3 issues and libgpg-error
<rafaeldtinoco> sergiodj is working on rsync migration issues
<rafaeldtinoco> fyio ^
<rafaeldtinoco> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | 20.04 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Focal | If you can't send messages here, authenticate to NickServ first | Patch Pilots:
<ahasenack> oh, nice macro
<mwhudson> morning
<sarnold> morning mwhudson :)
<mwhudson> Laney: my browser thanks you for making update_excuses.html so much smaller
<xnox> Laney:  it is nice.
<xnox> no idea how it went from 23M to like 3M
#ubuntu-devel 2020-07-15
<Unit193> Kind of loads better/faster in a browser in that case, for a little it was just faster to use w3m for me. :3
<mwhudson> xnox: it's that it no longer includes autopkgtest lines with no regressions i think
<sarnold> or always had regressions, right?
<sarnold> or was that a different page..
<xnox> sarnold:  it no longer includes thousands of lines of perl-* Passed Passed Passed Passed Passed Passed (x100000000 times)
<Unit193> :D
<sarnold> xnox: Passed!
<Unit193> Thankgoodness the passed is in the past.
<sarnold> xnox: is that because you broke all the perl things? or removed them? :)
<Laney> xnox: mwhudson: thanks (mainly on behalf of elbrus - go tell him in #debci) :>
<cpaelzer> niub: libvirt-bin was replaced in like xenial or so
<cpaelzer> niub: the one replacing it will be libvirt-daemon-system
<cpaelzer> withut the -system suffix you just get the binaries but not the service/system integration
<niub> cpaelzer: so I should install libvirt-daemon libvirt-daemon-system libvirt-clients, am I right?
<cpaelzer> niub: libvirt-daemon will be a dependency of libvirt-daemon-system so no need to install the former directly
<cpaelzer> niub: and libvirt-clients you only need if you want the front end on the same system (like virsh and such)
<cpaelzer> if you plan to manage is only from remove you don't need -clients
<doko> wgrant: did the riscv64 build configs changes, after that one was built initially? https://launchpadlibrarian.net/488638702/buildlog_ubuntu-groovy-riscv64.guile-2.2_2.2.7+1-5ubuntu1_BUILDING.txt.gz
<cpaelzer> ddstreet: rbalint: the systemd autopkgtest success rate has dropped a lot in groovy it seems
<cpaelzer> we all know they are complex and a bit flaky, but recently it seems worse - is there any work in progress to improve that again?
<niub> cpaelzer: ack, thx
<cpaelzer> arr, I have continuous issue with the autopkgtests of open-iscsi, caspar and ubuntu-image
<cpaelzer> They all work well when run in a local autopkgtest vm
<cpaelzer> due to that it is hard to debug, but OTOH wrong to mask them as badtest
<cpaelzer> I was wondering if there is anything known going on with the infrastructure that might cause this?
<cpaelzer> if so let me know
<cpaelzer> there are no open bugs against any of these packages explaining it
<cpaelzer> rafaeldtinoco: ^^ for open-iscsi and in case this came up on +1 duty as a topic
 * cpaelzer dives into test logs in case there is anything that helps ...
<cpaelzer> hmm, one could actually be a memory shortage
<cpaelzer> I keep forgetting where we flag tests as "huge"
<cpaelzer> but it seems these days all tests are huge, can tat be true
<cpaelzer> only the huge queue has entries atm on http://autopkgtest.ubuntu.com/running
<cpaelzer> and they all use --flavour autopkgtest
<cpaelzer> ok I was able to prove for one of the tests that memory shortage is the trigger (512M fails, 2G works)
<mwhudson> cpaelzer: hm what's casper doing
<cpaelzer> Laney: whenever it comes to autopktest infra you seem to know the answer - I beg your pardon for pinging you, but do you happen to know? ^^
<cpaelzer> mwhudson: I was debugging down to the bone open-iscsi so far which surely is lack of memory
<cpaelzer> mwhudson: I can look at caspar next and let you know in a bit
<cpaelzer> mwhudson: last 7 on https://autopkgtest.ubuntu.com/packages/c/casper/groovy/amd64 all failed
<Laney> cpaelzer: try running with -- qemu ... --ram-size 1536, that's what the instances get
<Laney> 'huge' doesn't mean that it runs on a bigger instance
<cpaelzer> ok will do a check at this size ..
<cpaelzer> I thought it meant that in the past
<cpaelzer> what does it still mean - longer timeouts?
<Laney> nope
<Laney> it means the package triggered more than 20 tests for that arch
<cpaelzer> oh, TIL - thanks!
<mwhudson> cpaelzer: hm is it always failing in the same place? are you sure it isn't actually a qemu regression?
<mwhudson> anyway i'm going to bed, ttfn :)
<cpaelzer> not a fail to work, but I was starting to wonder if memory consumption might have increased
<cpaelzer> sleep well mwhudson
<cpaelzer> beacuse it seems all issues I ahve left are tests running guests crashing for memory which is suspicious at least
<cpaelzer> The tests all seem to run with TCG which isn't too much tested otherwise
<cpaelzer> I think I'm onto something - thanks for listening mwhudson and Laney
<mwhudson> yes system emulation
<mwhudson> apparently nested virt will be a thing soon and we can stop testing system emulation soon? :)
<ogra_> waveform, sil2100, https://github.com/snapcore/pi-gadget/issues/48 one for you ...
<ogra_> (trivial to fix)
<waveform> ogra_, ta - I'll take a look
<ogra_> thx !
<waveform> ogra_, hmmm - quick question, should I add all the optional extra UARTs the pi4 introduced while I'm at it?
<ogra_> yeah, definitely
<waveform> yeah, figured that might be worth it while adding these bits
<waveform> okay
<rafaeldtinoco> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | 20.04 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Focal | If you can't send messages here, authenticate to NickServ first | Patch Pilots: rafaeldtinoco
<rbasak> kanashiro: around? Your updated vagrant SRU looks fine, though do you want to use -v2.2.6+dfsg-2ubuntu1 for the source build so that the changes file incorporates both changes?
<rbasak> If you're not around I can just accept - it's not important in this case
<rbasak> (since the same bug number is in the previous upload so Launchpad-Bugs-Fixed is not affected)
<kanashiro> rbasak: if this is something you really want I can do it later today
<rbasak> kanashiro: it's not necessary. I just wanted to give you the option :)
<rbasak> (sometimes it is for this sort of case but not this time)
<kanashiro> rbasak: so I'd say you can go ahead with the current version, context switch for this minor thing does not worth IMO :)
<rbasak> Sure, OK
<ahasenack> sil2100: hi, about bileto,
<ahasenack> sil2100: I'm not seeing the kopanocore tests themselves in https://bileto.ubuntu.com/excuses/4142/groovy.html
<ahasenack> and it does have dep8 tests
<ahasenack> same for python-certbot-apache: https://bileto.ubuntu.com/excuses/4144/groovy.html
<ahasenack> it says tests are green, but I see no tests run
<Laney> ahasenack: we don't show all-green lines any more
<ahasenack> Laney: oh
<ahasenack> Laney: is there a way to see the log anyway, or is it discarded?
<Laney> ahasenack: yeah, you can go to https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy-ci-train-ppa-service-4144/?format=plain
<Laney> then substitute the last part for the entries there
<UnivrslSuprBox> If I use a snap application that uses xdg-portals, snapd starts xdg-portals-gtk and performs my request. When this occurs, gnome-shell knows to "lock" the dialog that appears to the window that it's coming from and dims the application. How does the shell know to do this? What code handles popping up the dialogs modally?
<UnivrslSuprBox> This seems interesting to me because the application is in confinement and the dialog opening modally is outside
<UnivrslSuprBox> I ask because we need to replicate this behavior in Lomiri and having some direction to how someone else did it would be nice. But if I'm in the wrong place please point at me and laugh.
<juliank> UnivrslSuprBox: If you don't get an answer here, maybe ask in like #gnome on GimpNet https://wiki.gnome.org/Community/GettingInTouch/IRC#Community_.26_Core_Experience
<juliank> UnivrslSuprBox: or try #ubuntu-desktop
<juliank> Though they should be reading here too ...
<UnivrslSuprBox> Thanks! I'll idle some time longer.
<rbalint> cpaelzer, regarding the systemd autopkgtests there are a few valid regressiond being fixed in latest uploads and infra plays a role i think
<rbalint> cpaelzer, do you observe flaky tests running them locally in qemu?
<oSoMoN> LocutusOfBorg, mind triggering the following node-* tests? https://paste.ubuntu.com/p/FxPzTd5wtQ/
<ginggs> oSoMoN: doing...
<oSoMoN> cheers
<ginggs> oSoMoN: LocutusOfBorg: .
<ahasenack> hi, I have a config file I want to move from package A to a new package B, so that's case #7 of https://wiki.debian.org/PackageTransition
<ahasenack> my problem is how to preserve changes the user might have made to that config file
<ahasenack> I initially just added A.maintscript with rm_conffile, for the case if the user just upgrades A, I want the config file gone (if unchanged). That works
<ahasenack> but if I then install B, the default config file is installed, and it won't have the changes the user made when he had A version 1 installed
<ahasenack> and if A ad changes, I end up with the A config file backed up, but the new config file from B as the default
<ahasenack> *had changes
<rafaeldtinoco> cpaelzer: just fyio, sergiodj and I are working in qemu regressions specially because of nettle (depending on its migration)
<rafaeldtinoco> and nettle will unblock many stuff from migrations
<rafaeldtinoco> currently we're checking qemu->casper
<rafaeldtinoco> and then qemu->open-iscsi and qemu->systemd
<rafaeldtinoco> ls
<rafaeldtinoco> casper works fine locally :\, Im investigating lintian issues in all arches (arm64 / ppc64el - same test, s390x - other test) .. etc
<rafaeldtinoco> more fun tomorrow
<rafaeldtinoco> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | 20.04 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Focal | If you can't send messages here, authenticate to NickServ first | Patch Pilots:
<mwhudson> xnox: wanna talk about imsm a bit
<mwhudson> ?
<xnox> Yes.
<mwhudson> xnox: so you do ... stuff in the bios
<xnox> I have next call at half-past the hour.
<mwhudson> which results in a "mdadm container" in the OS
<mwhudson> xnox: voice or here?
<mwhudson> i don't mind
<xnox> mwhudson:  here is fine.
<xnox> mwhudson:  if you want voice, i will need to go outside.
<mwhudson> ok
<mwhudson> here is fine for me too
<mwhudson> you can then slice this container up into actual block devices
<mwhudson> you can choose a different raid level for each slice
<mwhudson> but each slice spans all disks in the container
<mwhudson> accurate so far? ^
<xnox> more or less.
<mwhudson> can you also create these "slices" (what's the proper word?) in the bios? i wasn't sure about that
<xnox> container => mark and slur-up all the disks to make them ismsm. Think of it as doing "pvcreate" on them, to say they will be used for Intel Raid.
<xnox> there is md127 that correlates to container, and it's mostly to query the controller that firmware and userspace agrees which disks are under intel raid management.
<xnox> so the slices..... those just look like normal RAID devices, that yeah, can be of any size and parity as needed.
<xnox> kind of like lvcreate
<xnox> but they appear on the host as "md126, md125, md124" devices.
<xnox> with their "physical" volume claiming to be like the container (md127) or like all the disks.
<xnox> but yeah the parent device behind them is kind of fake.
<xnox> terminology wise, one creates RAID device
<xnox> inside a RAID container
<xnox> that happens to consume hard-drives that must be connected to the right ports on the motherboard that have the raid stuff.
<xnox> mwhudson:  https://www.intel.co.uk/content/www/uk/en/support/articles/000005789/technologies.html
<xnox> mwhudson:  here are the bios docs, and the picture how it normally it looks in bios, if one boots with "ctrl+i"
<xnox> so yeah they say "Create RAID Volume"
<xnox> as if one is creating a normal mdadm raid volume.
<mwhudson> xnox: can you partition these raid devices? can you put the ESP on one?
<xnox> mwhudson:  yes, yes.
<xnox> mwhudson:  it is more normal to create raid volumes, rather than partitioning them.
<mwhudson> xnox: also is there any difference from our point of view between expensive server VROC and consumer laptop RST?
<xnox> mwhudson:  i.e md126 esp, md125 rootfs
<xnox> mwhudson:  rather than md126p1 esp, md126p2 rootfs
<mwhudson> xnox: how do you mark the ESP if it's a raid device?
<xnox> mwhudson:  create md126, format it with fat32 and put ESP label on it.
<xnox> mwhudson:  create uefi boot entry by fsuuid as usual.
<mwhudson> usually the label is a partition type code in the GPT
<mwhudson> but ok
<xnox> mwhudson:  firmware has UEFI intel matrix raid driver, meaning that UEFI firmware has drive(....) for the container, and the raid volumes created.
<xnox> hence it can find ESP on them, as if they are were real hardware raid disks.
<xnox> mwhudson:  sure, just do whatever one would do to it normally. Pretend that md126 is your typical sda1
<mwhudson> xnox: i don't know how that works given there is no partition table in this case but well, a problem for another day
<xnox> mwhudson:  i didn't get on that system they shared with us, i think i can live convert it to what it should look like from an initrd.
<xnox> mwhudson:  you can create partition table too, if that's better. I think that's what we did in Rackspace OnMetal cloud.
<xnox> mwhudson:  i.e. create RAID1 all disks, all the things.
<xnox> which md126, create GPT on it, create partitions on it, etc.
<xnox> that's what d-i did too
<xnox> and everyone at Intel were happy with that, because it just worked.
<xnox> mwhudson:  it feels to me that in essence, one has to call `sudo mdadm --detail --detail-platform` if that has raid capabilities
<xnox> mwhudson:  when user creates raid, it should assemble container, and use mdadm commands with metadata set to imsm format.
<mwhudson> xnox: so d-i basically creates a single device in the container and lets partman-auto have at taht?
<xnox> mwhudson:  yes.
<mwhudson> so subiquity should (a) hide any disks that are part of a container
<xnox> mwhudson:  i think for raid0 one can even fake the imsm controller in a vm.
<mwhudson> (b) do something like what d-i does when you choose the container in the guided view
<mwhudson> xnox: ah i was wondering if there was qemu support for all this
<xnox> mwhudson:  often when people buy servers from intel preconfigured with raid1 all disks.
<xnox> and if one has it auto-assembled, guided should offer to "autopartition md127 Intel Raid"
<xnox> mwhudson:  or people can choose to destroy md127 continer, and then all disks become eligible for manual partitioning.
<mwhudson> i guess the container needs to be a new kind of thing in the UI
<mwhudson> xnox: oh, i assumed that would be something you'd have to do in the bios
<xnox> mwhudson:  it's either or.
<mwhudson> can you create a container from the linux side too?
<xnox> mwhudson:  yes.
<mwhudson> oh
<mwhudson> what is the benefit of this vs bog standard md raid again? :)
<xnox> mwhudson: on-disk format is very simple. The VROC key / controller, just has CPU assisted quick parity calculations and recovery/data moving, such that CPU can do that without actually pushing data up to kernel and back down to disk.
<mwhudson> i guess performance and the firmware support for reading from the raid devices
<xnox> mwhudson:  and to use the CPU assisted calculations, one has ensure that the disk is in the format that cpu knows to read directly.
<mwhudson> oh being able to do recovery behind the scenes sounds pretty nice
<xnox> mwhudson:  benefit is that they wrote proprietary/BSD UEFI driver that Microsoft signed.
<xnox> mwhudson:  actually recovery still needs to be started by something, and monitored.
<xnox> mwhudson:  what you will find when container is assembled is that mdmon@md127.service is started which needs to stay alive until after pivot to finalrd.
<xnox> mwhudson:  or firmware has equivalent.
<mwhudson> xnox: oh ok
<xnox> mwhudson:  it's a small agent basically to get cpu notifications, and push down messages. "Yes, borken, start repair"
<xnox> "is it done yet?"
<xnox> "is it done yet?"
<xnox> "is it done yet?"
<xnox> "ok, pretending it is healthy now"
<xnox> fake things in /proc/mdstat
<xnox> mwhudson:  let me try to get onto that machine
<mwhudson> xnox: so on a imsm-capable system (how do you detect that) subiquity should support "mdraid containers" which can be made out of disks (not partitions) and can have raid devices created within them
<mwhudson> i guess "disks connected to the right ports"
<mwhudson> can you create multiple containers out of disjoint subsets of candidate disks? i guess so
<xnox> you can have many controllers too
<xnox> typically and different disks connected to each one
<xnox> sudo mdadm --detail --detail-platform
<xnox> is what you call to check if there are any controllers that support intel matrix raid.
<xnox> that call can be done on any machine
<xnox> iDRAC thing is scary
<mwhudson> ah so disks are connected to a controller
<mwhudson> xnox: sorry attention wandered for a bit there
<mwhudson> so if you're creating a container, you then have to choose which controller (if >1) and then can choose disks attached to that controller
#ubuntu-devel 2020-07-16
<xnox> mwhudson:  somewhat, yes.
<xnox> mwhudson:  i think firmware ui hides that. As it simply goes "create raid volume" and it only lets you pick disks from same controller, if there are multiple.
<xnox> mwhudson:  and i have never actually used a system with more than one controller. so it's theoretical i think.
 * xnox is not even sure why one would have multiple controllers, maybe passthrough to a VM?!
<sarnold> lots of disks?
<sarnold> multipath?
<xnox> sarnold:  in the context of Intel VROC raid, it would not be multipath, but actual disks.
<xnox> sarnold:  i mean the disks could be nvme, and pretend that they do multipath, and confuse multipath -ll by saying that they all have WWID, and they are multipath devices with # of paths being One.
<xnox> but that's separate.
<sarnold> xnox: well, that certainly confused me :)
<mwhudson> even better if the exported wwn is 0x0000000
<mantas-baltix> Hi
<mantas-baltix> Could someone tell why packaging recipe builds doesn't start today? Yesterday builds were started after few minutes, but this morning I'm waiting more than hour, see https://code.launchpad.net/~baltix/+archive/ubuntu/ppa/+recipebuild/2608185
<mantas-baltix> for about 60 minutes I see info "Start in 7 minutes (2610)" or something, like "Start in 11 minutes (2610)" ;)
<Unit193> https://lists.ubuntu.com/archives/ubuntu-devel/2020-July/041089.html There's a bug, I've pinged people multiple times including the person that made the bad merge, all to be ignored. \o/
<mitya57> mantas-baltix: maybe better to ask on #launchpad
<cjwatson> mantas-baltix: build farm trouble after a network outage; being investigated
<cjwatson> (and yes, this is more of a #launchpad thing)
<mantas-baltix> cjwatson, thanks
<seb128> rbalint, hey, do you know what's going on with the systemd autopkgtests?
<seb128>  /bin/systemctl: /lib/s390x-linux-gnu/libselinux.so.1: no version information available (required by /bin/systemctl)
<seb128> errors like that and the initramfs updates failing
<seb128> bdmurray, hey, could you review again the wslu/focal SRU, you had some comments about the bug descriptions and those have been updated I think it's ready for review again
<rbalint> seb128, not ye, looking at it
<seb128> rbalint, thanks
<rbalint> seb128, could you please drop libselinux from proposed?
<rbalint> seb128, breaks glibc autopkgtest as well and the switch to versioned symbols did not fully work out breaking systemd :-\
<seb128> bigon, ^ do you know about those issues with the libselinux update?
<seb128> rbalint, is that issue existing in Debian? it doesn't seem reported in the BTS yet
<rbalint> seb128, it breaks glibc autopkgtest and waiting just lets it breaking other packages
<rbalint> seb128, i don't see Debian's systemd affected yet because it FTBFS :-\
<seb128> rbalint,
<seb128> makedb.c:849:3: error: âsecurity_context_tâ is deprecated [-Werror=deprecated-declarations]
<seb128> the glibc errors do sound like something that should be easy to fix though, wouldn't that be a better step forward to fix it rather than rollback libselinux?
<ebarretto> seb128, rbalint, this might help https://github.com/SELinuxProject/selinux/commit/9eb9c9327563014ad6a807814e7975424642d5b9
<rbalint> seb128, https://salsa.debian.org/selinux-team/libselinux/-/merge_requests/3 ?
<rbalint> seb128, also filing a bug referencing this mr
<seb128> rbalint, thx
<xnox> seb128:  rbalint: imho, libselinux broke all symbols
<xnox> they used to be @Base but now they are @LIBSELINUX_1.0
<xnox> no?
<xnox> comparing 3.0 & 3.1
 * xnox goes to run abi check on them.
<rbalint> xnox, yes, see the mr
<seb128> rbalint, removed from proposed now, thanks for the details
<xnox> rbalint:  well, i mean libselinux1 & soname must change.
<xnox> rbalint:  cause old binaries are installable with new libselinux1, yet don't work?!
<rbalint> xnox, they seem to work, but checking that
<rbalint> xnox, bumping so version and renaming the package would be cleaner, i agree
<xnox> rbalint:  i think it does
<rafaeldtinoco> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | 20.04 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Focal | If you can't send messages here, authenticate to NickServ first | Patch Pilots: rafaeldtinoco
<xnox> rbalint:  previously it was without a version, so i think any versioned symbol satisfies that.
<xnox> rbalint:  so yes merge is good enough, to set minimum version, as new binaries will pick versioned symbol and will not work with old lib.
<xnox> rbalint:  but yeah, old binaries will work with new library that ships versioned symbols
<juliank> xnox, doko back on the pip thing, we could ship /usr/bin/pip in python3-pip as a symlink, and divert it in postinst and use trigger to undivert it on pip3 install. That way, we don't create an unowned file in /usr/bin at least
<xnox> juliank: simply shipping pip in python3-pip package in focal sounds fine.
<xnox> juliank:  does it break anything if it's python3 version?
<juliank> xnox: Well I feel like if you install python-is-python2 it gets confusing?
<xnox> On  Debian,  pip  is  the  command to use when installing packages for
<xnox>        Python 2, while pip3 is the command to use  when  installing  packages
<xnox>        for Python 3.
<xnox> in the manpage
<xnox> but i'm not too sure that is actually true
<juliank> it was true
<juliank> Not sure we had a pip2?
<xnox> juliank:  on groovy manpage says that, yet pip is python3
<juliank> yes, on groovy pip became pip3 but nobody updated mnapage
<xnox> juliank:  take groovy python3-pip and put it into focal-backports?!
<juliank> possible
<juliank> easiest option
<bigon> 15:54 < seb128> bigon, ^ do you know about those issues with the libselinux update? << glibc tests seems to fail because a type(?) is deprecated and that warnings are somehow threated as errors
<bigon> (like you said just bellow)
<bigon> for systemd, no I don't know
<rbalint> bigon, i just file a bug to BTS which will show up soon, but the failure at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/amd64/s/systemd/20200716_044131_250e2@/log.gz
<rbalint> bigon, #965136
<bigon> mmmh
<bigon> IIRC adding a version to symbol was OK and @base (the default) was supposed to match all the version (or something like that)
<bigon> (but obviously not the opposite)
<juliank> that matches my understanding
<rbalint> bigon, yes, but looking for the versioned symbol in older libselinux does not work :-(
<rbalint> bigon, so packages built with 3.1-1 need to be rebuilt
<bigon> because the application asks for symbol@version1 and the libs only provides symbol@base
<bigon> right
<bigon> rbalint: uploaded
<bigon> thx
<bigon> but thinking about this I'm a bit surprised, shouldn't dpkg-shlibdeps see that symbol@version1 is not in the .symbols file and fall back to the version from the shlibs file?
<bigon> which is not the upstream version if I'm not wrong
<bigon> libselinux 1 libselinux1 (>= 3.1)
<bigon> scratch what I said..
<mwhudson> vorlon: did you ever get to the bottom of why grub-efi-amd64 was getting seeded?
<mwhudson> cpaelzer: ah hah so it really is a qemu regression
<rafaeldtinoco> sqlite3 was blocked because of seqtools, seqtools had an issue on armhf -> fixed, new seqtools version uploaded, will try to address some of the python3 issues for sqlite3
<rafaeldtinoco> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | 20.04 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Focal | If you can't send messages here, authenticate to NickServ first | Patch Pilots:
<vorlon> mwhudson: ish; we made some seed changes on kubuntu and those seemed to dtrt
#ubuntu-devel 2020-07-17
<mwhudson> vorlon: i love systems where inputs and outputs are so clearly correlated
<cjwatson> mwhudson,vorlon: I thought it was clear enough: grub-efi-amd64-signed is explicitly seeded and depends on grub-efi-amd64 | grub-pc; germinate picked the first one because it had no reason not to, but explicitly adding grub-pc to the same seed satisfied that dependency so it didn't need to do anything heuristic
<cjwatson> mwhudson,vorlon: Though the "!grub-efi-amd64" entry in Kubuntu's ship-live seed is still incorrect and unnecessary, and should be reverted
<sil2100> GunnarHj: hey! Did you hear any feedback regarding the focal 20.04.1 base-langpack refresh that's in -proposed?
<rafaeldtinoco> @pilot on
<udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<rafaeldtinoco> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | 20.04 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Focal | If you can't send messages here, authenticate to NickServ first | Patch Pilots: rafaeldtinoco
<tsimonq2> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | 20.04 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Focal | If you can't send messages here, authenticate to NickServ first | Patch Pilots: rafaeldtinoco, tsimonq2
<tsimonq2> rafaeldtinoco: Are you following FIFO? LIFO?
<tsimonq2> I don't want to step on toes.
<rafaeldtinoco> tsimonq2: Im going through pkgs in "unknown"
<rafaeldtinoco> nettle was blocking lots of old packages from server and foundations
<rafaeldtinoco> and systemd
<rafaeldtinoco> so Im tackling those
<rafaeldtinoco> qemu tcg was blocking some others (mem constrains, so some regressions are because qemu dies) as explained by cpaelzer
<rafaeldtinoco> old packages = various days in excuses
<tsimonq2> Sounds good, thanks.
<tsimonq2> (FWIW, I usually FIFO the sponsorship queue, and once I've sorted through most of them, I'll take a look at the excuses page.)
<rafaeldtinoco> hum.. I started on monday (we are doing the weekly rotation) .. and I went for the FTBFS in [main] (getting zsys for armhf FTBFS)
<rafaeldtinoco> and then I started tackling excuses specially for [main]
<rafaeldtinoco> I think I missed the sponsoring queue part
<rafaeldtinoco> :\
<tsimonq2> I'm glad the weekly rotation started. :)
<tsimonq2> I'm doing this for fun (I don't work for Canonical).
<tsimonq2> http://reqorts.qa.ubuntu.com/reports/sponsoring/
<rafaeldtinoco> yep
<rafaeldtinoco> im there
<tsimonq2> Sweet.
<rafaeldtinoco> nice.. thanks for syncing
<tsimonq2> I'm looking at freecad (I asked the Debian maintainer to review the patch, I'm polishing it otherwise).
<tsimonq2> No worries.
<tsimonq2> Speaking of the sponsorship queue, I pushed a few commits making some minor stylistic changes. Who can git pull on prod?
<tsimonq2> What is the best way to tell whether someone is still working for Canonical (and thus active)?
<cjwatson> tsimonq2: That's not information that we give out in general
<cjwatson> You can probably infer the "active" part from Launchpad karma though
<tsimonq2> cjwatson: Fair enough.
<tsimonq2> I am seeing a good amount of older patches in the queue that come from people that I'm not sure are still active.
<tsimonq2> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | 20.04 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Focal | If you can't send messages here, authenticate to NickServ first | Patch Pilots: rafaeldtinoco
<GunnarHj> sil
<GunnarHj> sil2100: I've heard no complaints about the focal-proposed langpacks.
<ahasenack> hi, I'm trying to test changing a dependency in an ubuntu-meta package, and I don't want to commit the change to the seeds yet
<ahasenack> I thought I could mess arount the update.cfg file of the src:ubuntu-meta package, and point to a git repo/branch of mine
<ahasenack> I managed to get it (the update script) to clone my branch for ubuntu, and platform, but now it's failing on "languages"
<ahasenack> is there a quick doc/guide to do this, or is it hopeless and I just just commit, or rather perhaps, just manually add the dependency to d/control?
<tsimonq2> ahasenack: Do you have a log?
